CMSC 414 Computer and Network Security Lecture 13

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 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. SAAF Impala K 1. R FK(R) Namibia K

Mi. G-in-the-middle – what went wrong? 3. SAAF Impala 4. R FK(R) K 2. Angola R 5. Russian Mi. G 6. 1. R FK(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 Do. S 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 Enc. PK(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(R 1); server sends Epkc(R 2); session key is R 1+R 2 – 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