1 / 19

CMSC 414 Computer and Network Security Lecture 22

CMSC 414 Computer and Network Security Lecture 22. Jonathan Katz. Lamport’s protocol. 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

jlozier
Download Presentation

CMSC 414 Computer and Network Security Lecture 22

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 22 Jonathan Katz

  2. Lamport’s protocol • Server stores Hn(pw), sends n; user sends Hn-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 • Deployed as S/Key

  3. Some drawbacks… • 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!

  4. 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…

  5. Session keys • Reduces effectiveness of cryptanalysis • If key compromised, only one session affected • Prevents replay of messages from other sessions

  6. Basic key exchange • Public-key based… • Diffie-Hellman key exchange • Secure against passive eavesdropping… • …but insecure against a man-in-the-middle attack

  7. Adding key exchange • Not sufficient to simply “add on” key establishment before/after authentication • Splicing attack… • Need “authenticated key exchange”

  8. KDCs • Key Distribution Centers • Advantages of symmetric-key crypto, without O(n2) keys • But requires a trusted intermediary • Single point of failure/attack • Kerberos is a famous example

  9. Basic idea • Every user i shares a key Ki with the KDC • When Alice wants to talk to Bob, the KDC authenticates the request from Alice, chooses random K, and sends EncKa(K), EncKb(K) to Alice • Alice forwards EncKb(K) to Bob • Alice and Bob use K to communicate • Note that the KDC can read all communication!

  10. Multiple intermediaries • Allows users in different domains to communicate securely • Use multiple KDCs… • Can have all pairs of KDCs share a key • More likely, there will be a hierarchy of KDCs

  11. Authentication Protocols (Chapter 11, KPS)

  12. Overview • Protocol design is subtle • Small changes can make a protocol insecure! • Historically, designed in an “ad-hoc” way, by checking protocol for known weaknesses • Great example of where provable security helps!

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

  14. “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…

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

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

  17. 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?

  18. 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…

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

More Related