CS 4803 Computer and Network Security Alexandra (Sasha) Boldyreva - PowerPoint PPT Presentation

Diffie-Hellman key exchange • Secure against passive eavesdropping… • …but insecure against a man-in-the-middle attack CS 4803 Computer and Network Security Alexandra (Sasha) Boldyreva Authenticated key exchange 1 2 Adding key exchange Overview • Not sufficient to simply “add on” key establishment before/after • Protocol design is subtle authentication • Small changes can make a protocol insecure! • Need “authenticated key exchange” • Historically, designed in an “ad-hoc” way, by checking protocol for known weaknesses • Great example of where provable security helps! 3 4

Example Example • “Reverse” challenge-response • User sends time, MACK(time) • I.e., send a ciphertext and have user decrypt it • What if she had used encryption, or a hash? • Mutual authentication (if decrypts “validly”)?? • What about just sending MACK(time)? • Weaknesses? • Considerations? • Uses encryption for authentication • Requires (loosely) synchronized clocks • Must guard against replay… • What if user has same key on multiple servers? • Clock reset attacks • No mutual authentication 5 6 Adding mutual authentication Using timestamps? • Double challenge-response (symmetric key) in 4 rounds • User sends time, MACK(time), server responds with MACK(time+1) • Variant in which user sends nonce first? • Insecure (reflection attack)… • Vulnerabilities? • Also vulnerable to off-line password guessing without eavesdropping • To improve security, make protocol asymmetric • Security principle: let initiator prove its identity first 7 8

Establishing a session key Public-key based… • Double challenge-response; compute session key as FK(R+2) • Include Epk(session-key) in protocol? • Encrypt session-key and sign the result? • Secure against passive attacks if F is a pseudorandom permutation… • Potentially vulnerable to replay attacks • Active attacks? And how to fix it… • User sends E(R1); server sends E(R2); session key is R1+R2 • Reasonable… 9 10 One-way authentication Authenticated Diffie-Hellman • If only the server has a known public key (e.g., SSL) • Add signatures/MACs and nonces to Diffie-Hellman protocol • Variation: HMQV (improved MQV) • Server sends R • Client sends Epk(R, password, session-key) • Insecure in general!!! • But secure if encryption scheme is chosen appropriately • Can extend to give mutual authentication 11 12

Using session keys Mediated authentication • Generally, want to provide both secrecy and integrity for • E.g., using KDC subsequent conversation • Simple protocol: • Use encrypt-then-MAC • Alice requests to talk to Bob • Use sequence numbers to prevent replay attacks • KDC generates KAB and sends it to Alice and Bob, encrypted • Periodically refresh the session key with their respective keys • Note: no authentication here, but impostor can’t determine KAB 13 14 Improvement… Needham-Schroeder • Have KDC send to Alice the encryption of KAB under Bob’s key • A � KDC: N1, Alice, Bob • KDC � A: KA(N1, Bob, KAB, ticket), where ticket = • Reduces communication load on KDC KB(KAB, Alice) • Resilient to message delays in network • A � B: ticket, KAB(N2) • B � A: KAB(N2-1, N3) • A � B: KAB(N3-1) 15 16

Analysis? Otway-Rees • N1 assures Alice that she is talking to KDC • A � B: NC, KA(NA, NC, Alice, Bob) • Prevents key-replay, helps prevent attack when Bob’s key is • B � KDC: KA(…), KB(NB, NC, Alice, Bob) compromised and then changed • KDC checks that NC is the same… • Important: authenticate “Bob” in message 2, and “Alice” in ticket • KDC � B: NC, KA(NA, KAB), KB(NB, KAB) • Uses encryption to authenticate… � • B � A: KA(…) • Leads to actual flaw if, e.g., ECB mode is used! • A � B: KAB(timestamp) • Vulnerable if Alice’s key is compromised • Bob’s ticket is always valid • Note: KDC already authenticated Bob • Use timestamps, or request (encrypted) nonce from Bob at the very beginning of the protocol 17 18 Analysis? Kerberos • (May discuss in more detail later) • NC should be unpredictable, not just a nonce • Otherwise, can impersonate B to KDC • A � KDC: N1, Alice, Bob • Send first message: (next NC), “garbage” • KDC � A: KA(N1, Bob, KAB, ticket), where ticket = KB(KAB, • B forwards to KDC along with encryption of the next NC Alice, expiration time) • Next time A initiates a conversation, replay previous • A � B: ticket, KAB(time) message from B • Still uses encryption for authentication… � • B � A: KAB(time+1) • Serious attack if ECB is used • Replace KAB with NC 19 20