290 likes | 293 Views
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.
E N D
CMSC 414Computer and Network SecurityLecture 13 Jonathan Katz
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) 6. FK(R) Russian MiG 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 • Client sends their name • Server sends a nonce R • Client sends MACK(R) and R’ • 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