1 / 14

CMSC 414 Computer and Network Security Lecture 16

CMSC 414 Computer and Network Security Lecture 16. Jonathan Katz. 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

hua
Download Presentation

CMSC 414 Computer and Network Security Lecture 16

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMSC 414Computer and Network SecurityLecture 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 <time, MACK(time)> • What if she had used encryption, or a hash? • What about just sending MACK(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 <time, MACK(time)>, server responds with MACK(time+1) • What if they used encryption instead? • Vulnerabilities? • Symmetric protocol…

  10. A public-key protocol • Client sends Encpks(R) • Server sends R, Encpkc(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 Fk(R+1) • Is this secure? • How to fix? • (Note: the fix suggested in the book is bad)

  12. Public-key based… • Include Epk(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 Epks(R1); server sends Epkc(R2); session key is R1+R2 • 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 Epk(R, password, session-key) • Insecure in general!!! • But secure if encryption scheme is chosen appropriately • Can be extended to give mutual authentication

More Related