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
– 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 <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
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
 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?
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
Using timestamps?
 User sends <time, MACK(time)>, server responds
with MACK(time+1)
– What if they used encryption instead?
 Vulnerabilities?
– Symmetric protocol…
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
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)
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
Authenticated Diffie-Hellman
 Add signatures/MACs and nonces to Diffie-
Hellman protocol
– Note: achieves forward secrecy
– A lot of subtle details involved…
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