1. 1 Secure Key Exchange: Diffie-Hellman Exchange Dr. Rocky K. C. Chang 19 February, 2002

2. 2 The secure key exchange problem Before two users can use a private key for encryption or for message authentication, how did they come up the key? –Out-of-band, in-band, or a hybrid How do two IPSec nodes set up their security associations (SAs)? –Encryption algorithms, authentication algorithms, session keys, etc. In general, the problem is how to derive a secret (key, identity, etc) between two users over an insecure network? –The second problem is how to use the secret (keys) to secure their messages from a certain layer up.

3. 3 The secure key exchange problem An acceptable solution (a secure key exchange protocol) to this problem is required to handle –Source authentication –Message authentication –Data confidentiality –Protection against denial-of-service attacks, such as, flooding of messages, replay messages, etc. Internet Key Exchange (IKE) protocol is the default method for IPSec. –IKE is an application-layer protocol using the well-known UDP port 500. –IKE is a general key exchange protocol.

4. 4 Perfect forward secrecy One important requirement for key exchange protocols is perfect forward secrecy (PFS). –PFS: “disclosure of long-term secret keying material does not compromise the secrecy if exchanged keys from earlier runs.” –For example, using public-key to exchange secret keys does not have PFS. –There is currently no other solution to provide the PFS except for the Diffie-Hellman exchange. As a result, the Diffie-Hellman exchange has been included in all well-designed key exchange protocols.

5. 5 Diffie-Hellman key exchange An initiator (I) and a responder (R) must agree on a Diffie-Hellman group that consists of a large prime number, p, and an integer g. I then generates a large random integer x, and computes X = g x mod p. –I sends X to R. Upon receiving the message, R then generates a large random integer y, and computes Y = g y mod p. –R sends Y to I. Both I and R compute a secret key k by –I: k = Y x mod p = (g y mod p) x mod p = g xy mod p –R: k = X y mod p = (g x mod p) y mod p = g xy mod p

6. 6 Diffie-Hellman key exchange

7. 7 Properties of D-H key exchange The group (p, g) is not a secret. x (or X) or y (or Y) is a half-secret. –To recover the key from p, g, X, and Y, one needs to compute the discrete logarithm to recover x or y. –Additional requirements for p: (p - 1)/2 is also a prime and must be large. –g is primitive mod n. –For example: p = 2 768 - 2 704 - 1 + 2 64 * { [2 638  + 149686 } and g = 2. There is no known tractable method for finding the discrete logarithm of an exponentiated number modulo a large prime number.

8. 8 Problems with D-H key exchange It does not prevent replay or flooding attacks. –Sending a series of request packets with different spoofed source IP addresses –A partial solution: use of cookies It does not authenticate participants. –Man-in-the-middle attacks, such as third-party insertion, deletion, interception, or modification of messages. –Need to authenticate the Diffie-Hellman exchanges. It does not have a negotiation mechanism for specifying the particular encryption or authentication algorithms to use with the generated key. –Need additional mechanisms.

9. 9 A man-in-the-middle attack

10. 10 D-H + cookies A cookie exchange guards against simple flooding attacks sent with bogus IP sources addresses or UDP ports. I generates a cookie (of length between 64 and 128 bits) C I, and sends it to R. R then generates a cookie C R, and sends it with C I to I. To launch a flooding attack, the attacker has to –complete a cookie exchange with the victim for each spoofed source IP address (read the cookie sent by the victim for each cookie exchange.)

11. 11 D-H + cookies

12. 12 Requirements for cookie generation The cookie must depend on the specific parties. –This prevents an attacker from obtaining a cookie using a real IP address and UDP port, and –then using it to swamp the victim with requests from randomly chosen IP addresses or ports. It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. –This implies that the issuing entity will use local secret information in the generation and subsequent verification of a cookie. –It must not be possible to deduce this secret information from any particular cookie.

13. 13 Requirements for cookie generation The cookie generation and verification methods must be fast to thwart attacks intended to sabotage CPU resources. A recommended technique is to use a cryptographic hashing function, such as MD5. –An incoming cookie can be verified by regenerating it locally from values contained in the incoming datagram and the local secret random value. –For example, cookie = PRF(secret, source and destination IP addresses, source and destination UDP port numbers)

14. 14 Initiator and responder cookies The Initiator secret value should be different for each cookie exchange and the secret value is cached. –An alternative, of course, is to cache the cookie itself instead of the secret value. –It is recommended that the cookie be computed over the secret, source and destination IP addresses, and source and destination UDP port numbers. The responder secret value may be the same for many different initiators. –This secret value should be changed periodically. –It is recommended that the cookie be computed over the secret, the Initiator cookie, source and destination IP addresses, and UDP port numbers.

15. 15 Authenticating D-H exchanges Symmetric-key based authentication –Use a pre-configured shared key, or each other’s public keys to establish a shared key. –Use a pseudo-random function (PRF), such as keyed MD5, for authentication: I includes PRF(shared key, ID I, X, Y, C I, C R ) in the message sent to R. The inclusion of X serves to authenticate (to R) that X came from I. The inclusion of Y serves to prove to R the freshness of the message (assuming Y was freshly chosen by R). ID I serves to reassure the parties about the correct binding between the exchanged key and I’s identity.

16. 16 Authenticating based on symmetric keys

17. 17 Authenticating based on symmetric keys Without knowing the shared key, the man-in-the- middle would not be able to compute the correct PRF values. The expensive Diffie-Hellman computation can be postponed after the authentication step. To conceal the identities of the parties, the last two messages may be encrypted (using a different key).

18. 18 Authenticating based on asymmetric keys Use digital signatures or public key encryption. Some people are against the use of digital signatures because of its nonrepudiation property (e.g. SKEME). –If during a key exchange between I and R, I is required to sign R’s identity, then this signature can be re-used later by R for other purposes. –If digital signatures are used in a key exchange protocol, then these signatures should not be used to sign the identities. –Can we prevent R from inserting his identity in the information to be signed by I?

19. 19 Acknowledgements These lecture notes are based on –M. S. Borella, “Methods and Protocols for Secure Key Negotiation Using IKE,” IEEE Network, pp. 18-29, July/Aug., 2000. –N. Doraswamy and D. Harkins, IPSec, Prentice Hall, 1999. –P. Karn and W. Simpson, “Photuris: Session-Key Management Protocol,” RFC 2522, March 1999. –H. Krawczyk, “SKEME: A Versatile Secure Key Exchange Mechanism for Internet,” Proc. Internet Society Symposium on Network and Distributed System Security,” Feb. 1996.