|
Conceptually, public key cryptography makes exchanging keys very easy.
-
Alice -> Bob : { ksession } eBob
where eBob is Bob's public key. Bob deciphers the message and obtains the session key ksession. Now he and Alice can communicate securely, using a classical cryptosystem.
As attractive as this protocol is, it has a similar flaw to our original classical key exchange protocol. Eve can forge such a message. Bob does not know who the message comes from.
One obvious fix is to sign the session key.
-
Alice -> Bob : Alice, { { ksession } dAlice } eBob
where dAlice is Alice's private key. When Bob gets the message, uses his private key to decipher the message. He sees the key is from Alice. Alice uses her public key to obtain the session key. Alice could also include a message enciphered with ksession.
These protocols assume that Alice has Bob's public key eBob. If not, she must get it from a public server, Peter. With a bit of ingenuity, Eve can arrange to read Bob's messages to Alice, and vice versa.
-
Alice -> Peter : { send me Bob's public key } [ intercepted by Eve ]
-
Eve -> Peter : { send me Bob's public key }
-
-
-
Alice -> Bob : { ksession } eEve [ intercepted by Eve ]
-
Eve -> Bob : { ksession } eBob
Eve now has the session key and can read any traffic between Alice and Bob. This is called a man-in-the-middle attack and illustrates the importance of identification and authentication in key exchange protocols. The man-in-the-middle attack works because there is no binding of identity to a public key. When presented with a public key purportedly belonging to Bob, Alice has no way to verify that the public key in fact belongs to Bob. This issue extends beyond key exchange and authentication. To resolve it, we need to look at the management of cryptographic keys. |