CMSC 414Computer 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”

NamibiaK

1. R

2. FK(R)SAAFImpala

K

MiG-in-the-middle – what went wrong?

NamibiaK

Angola

1. R

2. R

3. R

4. FK(R)

5. FK(R)

6. FK(R)

SAAFImpala

K

RussianMiG

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 rounds1. 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