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

2. Challenge-response  Client and server share a key k  Generically: server sends R; user sends f(k, R)  For which f will this be secure?  What if R is non-repeating, but predictable?  Drawbacks –No mutual authentication –No key exchange –Dictionary attack if k is low entropy –Insecure against server compromise

3. “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”)??  Which f are suitable?  Weaknesses? –Uses encryption for authentication (Note that a MAC cannot, in general, be used) –Vulnerable to dictionary attack just by false attempted login (not eavesdropping) –Authentication of server assumes no replay…

4. Single-flow protocol  Use time instead of a server-generated challenge  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

5. Public-key protocol  What if we instantiate challenge-response or reverse challenge-response with signatures or public-key encryption? –Is it secure?  Possible resistance to server compromise (as we have seen already)  Is it a problem that the adversary can get the client to sign an arbitrary value? –Use different keys for different purposes

6. Adding mutual authentication  Double challenge-response in 4 rounds  Client sends their name  Server sends a nonce R  Client sends f(k, R) and R’  Server sends f(k, R’)  Again, what f should be used?

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

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

9. Using timestamps?  User sends, server responds with MAC K (time+1) –What if they used encryption instead?  Vulnerabilities? –Symmetric protocol…

10. A public-key protocol  Client sends Enc pks (R)  Server sends R, Enc pkc (R’)  Client sends R’  Security? –Vulnerable to chosen-ciphertext attacks… –Seems better to use signatures  How does the client obtain pks and skc? –One option is to download “credentials” from another site using a password

11. 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?  (Note: the fix suggested in the book is bad)

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

13. Authenticated Diffie-Hellman  Add signatures/MACs and nonces to Diffie- Hellman protocol –Note: achieves forward secrecy –A lot of subtle details involved…

14. Authentication with password + public key  Say that only the server has a known public key (e.g., SSL) –Server sends R –Client sends E pk (R, password, session-key)  Insecure in general!!! –But secure if encryption scheme is chosen appropriately  Can be extended to give mutual authentication