Public Key Cryptographic Key Exchange and Authentication

written by: Bill Kuriko; article published: year 2007, month 04;

In: Root » Computers and technology » Data security

  Share  
|
  PL  |  NL  |  FR  |  ES  |  PT  |  IT  |  DE  |  DK  |  NO  |  SE  |  FI  |  GR  |  JP  |  CN  |  KR  |  RU  |  AE


Conceptually, public key cryptography makes exchanging keys very easy.

  1. 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.

  1. 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.

  1. Alice -> Peter : { send me Bob's public key } [ intercepted by Eve ]

  2. Eve -> Peter : { send me Bob's public key }

  3. Peter -> Eve : eBob

  4. Eve -> Alice : eEve

  5. Alice -> Bob : { ksession } eEve [ intercepted by Eve ]

  6. 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.

Share

Disclaimer

1) E-articles is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringement, please read the terms of service and contact us or use the "Report this article" button on this page to investigate the problem.
2) E-articles is not responsible for inaccuracies, falsehoods, or any other types of misinformation this article may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here.