CMSC 414
Computer and Network Security
Lecture 13
Jonathan Katz
Keyed Authentication Protocols
Symmetric-key setting
 In what follows, k refers to a high-entropy
cryptographic key
– If k is low-entropy (e.g., derived from a password)
these protocols are vulnerable to off-line attacks
Basic authentication protocols…
 Server stores k; user sends k
 Server stores H(k); user sends k
 Server stores H(k); user sends H(k)
 All the above are secure against client-
impersonation attacks (only)
– May be enough in some settings
– How about eavesdropping?
– How about server compromise?
Challenge-response
 To prevent replay, need to add something that
distinguishes one session from another
– Ensure “freshness”
 General paradigm: server sends a “challenge” and
the user provides a correct “response”
 Challenge should (at least) be non-repeating
– Counter,
– Time – though see later
– Random value (nonce)
Challenge-response
 Client and server share a key k
 Generically: server sends R; user sends f(k, R)
 What is the “right” f to use here?
 Drawbacks
– Dictionary attack (for eavesdropper) if k low entropy
– Insecure against server compromise
“Friend-or-foe”
2. FK(R)
SAAF
Impala
K
1. R
Namibia
K
MiG-in-the-middle – what went
wrong?
3. R
SAAF
Impala
K
4. FK(R)
Angola
2. R
5. FK(R)
Russian
MiG
6. FK(R)
1. R
Namibia
K
Challenge-response
 What if R is non-repeating, but predictable (like a
counter)?
Single-flow protocol
 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
“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”)??
 Weaknesses?
– Uses encryption for authentication
• (Note that a MAC cannot, in general, be used)
– Vulnerable to off-line dictionary attack after client
impersonation (eavesdropping unnecessary)
– Authentication of server assumes no replay…
Better mutual authentication
 Double challenge-response in 4 rounds
1. Client sends their name
2. Server sends a nonce R
3. Client sends MACK(R) and R’
4. Server sends MACK(R’)
Mutual authentication in 3 rounds?
 Can we compress the previous protocol to 3
rounds?
– Client sends their name, R’
– Server sends MACK(R’) and R
– Client sends MACK(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
Overview
 Protocol design is subtle
– Small changes can make a protocol insecure!
– Another warning against modifying existing protocols
even in seemingly “innocuous” ways
– Historically, designed in an “ad-hoc” way, by checking
protocol for known weaknesses
– Great example of where provable security helps!
Server compromise
 The symmetric-key protocols we have seen are all
vulnerable to server compromise
– Can we address this?
A public-key protocol w/ signatures
 Server stores pk; user stores sk
 Server sends R; user signs R
– Using a secure signature scheme…
 Is this secure against eavesdropping/server
compromise?
– What if we had used encryption instead?
 Note: attacker can get user to sign anything…
– Key should be used only for authentication
Using public-key encryption?
 Server chooses random R, sends EncPK(R)
 User sends back R
 Secure?
– Note that an attacker can run a chosen-ciphertext attack
– If we use a CCA-secure scheme, ok!
 Attacker can get user to decrypt anything
– Key should be used only for authentication
– General principle: different keys for different purposes
Server compromise?
 Can we achieve security against eavesdropping
and server compromise without public-key
cryptography?
Lamport’s protocol (S/Key)
 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
Some drawbacks…
 Stateful protocol
 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…
Why use session keys?
 Reduces effectiveness of cryptanalysis
 If key compromised, only one session affected
– Even if long-term key compromised, session keys
unaffected – forward secrecy
 Prevents replay of messages from other sessions
Adding key exchange
 Not sufficient to simply “add on” key
establishment before/after authentication
– Splicing attack…
 Need “authenticated key exchange”
– Need to ‘bind’ the authentication and the key exchange
Forward secrecy
 (Past) session keys should remain secret even if
the adversary compromises the long-term key(s)
of the parties
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?
– No forward secrecy…
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
– Subtle details involved…need asymmetry
Using session keys
 Generally, want to provide both secrecy and
integrity for subsequent conversation
–
–
–
–
Use authenticated encryption (e.g., encrypt-then-MAC)
Use sequence numbers to prevent replay attacks
Use a directionality bit
Periodically refresh the session key