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 –Can use same password (but different salt) when password “expires” –Protects against pre-computation  Deployed as S/Key

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!

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…

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

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

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

KDCs  Key Distribution Centers  Advantages of symmetric-key crypto, without O(n 2 ) keys –But requires a trusted intermediary –Single point of failure/attack  Kerberos is a famous example

Basic idea  Every user i shares a key K i with the KDC  When Alice wants to talk to Bob, the KDC authenticates the request from Alice, chooses random K, and sends Enc Ka (K), Enc Kb (K) to Alice –Alice forwards Enc Kb (K) to Bob  Alice and Bob use K to communicate  Note that the KDC can read all communication!

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

Authentication Protocols (Chapter 11, KPS)

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!

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

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

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

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

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

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…

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