1. CMSC 414 Computer and Network Security Lecture 13 Jonathan Katz

2. Keyed Authentication Protocols

3. Symmetric-key setting  In what follows, k refers to a high-entropy cryptographic key –If k is low-entropy (e.g., derived from a password) these protocols are vulnerable to off-line attacks

4. Basic authentication protocols…  Server stores k; user sends k  Server stores H(k); user sends k  Server stores H(k); user sends H(k)  All the above are secure against client- impersonation attacks (only) –May be enough in some settings –How about eavesdropping? –How about server compromise?

5. Challenge-response  To prevent replay, need to add something that distinguishes one session from another –Ensure “freshness”  General paradigm: server sends a “challenge” and the user provides a correct “response”  Challenge should (at least) be non-repeating –Counter, –Time – though see later –Random value (nonce)

6. Challenge-response  Client and server share a key k  Generically: server sends R; user sends f(k, R)  What is the “right” f to use here?  Drawbacks –Dictionary attack (for eavesdropper) if k low entropy –Insecure against server compromise

7. “Friend-or-foe” Namibia K 1. R 2. F K (R) SAAF Impala K

8. MiG-in-the-middle – what went wrong? Namibia K Angola 1. R 2. R 3. R 4. F K (R) 5. F K (R) 6. F K (R) SAAF Impala K Russian MiG

9. Challenge-response  What if R is non-repeating, but predictable (like a counter)?

10. Single-flow protocol  User sends –What if she had used encryption, or a hash? –What about just sending MAC K (time)?  No server state; single message  Considerations? –Requires (loosely) synchronized clocks –Must guard against replay… –What if user has same key on multiple servers? –Clock reset attacks; clock DoS attacks! –No mutual authentication

11. “Reverse” challenge-response  Server sends f(k, R) and client sends R –I.e., send a ciphertext and have user decrypt it  Mutual authentication (if decrypts “validly”)??  Weaknesses? –Uses encryption for authentication (Note that a MAC cannot, in general, be used) –Vulnerable to off-line dictionary attack after client impersonation (eavesdropping unnecessary) –Authentication of server assumes no replay…

12. Better mutual authentication  Double challenge-response in 4 rounds 1.Client sends their name 2.Server sends a nonce R 3.Client sends MAC K (R) and R’ 4.Server sends MAC K (R’)

13. Mutual authentication in 3 rounds?  Can we compress the previous protocol to 3 rounds? –Client sends their name, R’ –Server sends MAC K (R’) and R –Client sends MAC K (R)  Seems ok…

14. Mutual authentication in 3 rounds  Insecure! (reflection attack using two server connections…) –Also vulnerable to off-line password guessing without eavesdropping –To improve security, make protocol asymmetric –No such attack on original protocol Security principle: let initiator prove its identity first  A good illustration that designing secure protocols is very subtle! –Another warning against modifying existing protocols even in seemingly “innocuous” ways

15. Overview  Protocol design is subtle –Small changes can make a protocol insecure! –Another warning against modifying existing protocols even in seemingly “innocuous” ways –Historically, designed in an “ad-hoc” way, by checking protocol for known weaknesses –Great example of where provable security helps!

16. Server compromise  The symmetric-key protocols we have seen are all vulnerable to server compromise –Can we address this?

17. A public-key protocol w/ signatures  Server stores pk; user stores sk  Server sends R; user signs R –Using a secure signature scheme…  Is this secure against eavesdropping/server compromise? –What if we had used encryption instead?  Note: attacker can get user to sign anything… –Key should be used only for authentication

18. Using public-key encryption?  Server chooses random R, sends Enc PK (R)  User sends back R  Secure? –Note that an attacker can run a chosen-ciphertext attack –If we use a CCA-secure scheme, ok!  Attacker can get user to decrypt anything –Key should be used only for authentication –General principle: different keys for different purposes

19. Server compromise?  Can we achieve security against eavesdropping and server compromise without public-key cryptography?

20. Lamport’s protocol (S/Key)  Server stores H n (pw), sends n; user sends H n-1 (pw) –Server updates user’s entry…  Can also add “salt” to hash –Server sends salt to user as first flow –Allows user to use same password on different sites –Can use same password (but different salt) when password “expires” –Protects against pre-computation

21. Some drawbacks…  Stateful protocol  Secret expires at some point and a new secret must be shared  Security against active attacks?  E.g., “low number” attack –Can use “paper-and-pencil” method to prevent this… –…but at that point, better solutions are also possible!

22. Session key establishment  There are very few applications for which authentication alone is sufficient! –Can you think of any? –What do you do once you are authenticated?  Generally, need to establish a session key to authenticate (and encrypt) subsequent communication –Also efficiency advantages to using symmetric-key techniques even if public-key authentication is used –Advantages even if a symmetric key is already shared…

23. Why use session keys?  Reduces effectiveness of cryptanalysis  If key compromised, only one session affected –Even if long-term key compromised, session keys unaffected – forward secrecy  Prevents replay of messages from other sessions

24. Adding key exchange  Not sufficient to simply “add on” key establishment before/after authentication –Splicing attack…  Need “authenticated key exchange” –Need to ‘bind’ the authentication and the key exchange

25. Forward secrecy  (Past) session keys should remain secret even if the adversary compromises the long-term key(s) of the parties

26. Establishing a session key  Use the (secure) double challenge-response protocol from earlier; let the session key be F k (R+1) –Is this secure? –How to fix? –No forward secrecy…

27. Public-key based…  Include E pk (session-key) in protocol? –No authentication of the ciphertext  Encrypt session key and sign the result? –No forward secrecy… –Potentially vulnerable to replay attacks  Client sends E pks (R 1 ); server sends E pkc (R 2 ); session key is R 1 +R 2 –Reasonable… –Why isn’t it a problem that the ciphertexts are not authenticated? –Implicit vs. explicit authentication

28. Authenticated Diffie-Hellman  Add signatures/MACs and nonces to Diffie- Hellman protocol –Note: achieves forward secrecy –Subtle details involved…need asymmetry

29. Using session keys  Generally, want to provide both secrecy and integrity for subsequent conversation –Use authenticated encryption (e.g., encrypt-then-MAC) –Use sequence numbers to prevent replay attacks –Use a directionality bit –Periodically refresh the session key