CMSC 414
Computer and Network Security
Lecture 15
Jonathan Katz
Announcement
 Anyone interested in a summer internship at NIST
related to programming in support of quantum key
distribution (no prior knowledge of QM required),
please contact me
Basic authentication protocols…
 Server stores H(pw); user sends pw
– “Secure” against server compromise, but not
eavesdropping (or replay attacks)
 Server stores pw, sends R; user sends Fpw(R)
– If pw is a high-entropy key, then this is secure against
eavesdropping (but not server compromise)
– If pw is a password, then this is insecure against an offline dictionary attack
A public-key protocol
 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?
 Can we achieve security against eavesdropping
and server compromise without public-key
crypto?
Lamport’s protocol
 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
 Deployed as S/Key
Some drawbacks…
 Secret expires at some point and a new secret must
be shared
 Security against active attacks?
– 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 if public-key authentication is used
– Advantages even if a symmetric key is already shared…
Session keys
 Reduces effectiveness of cryptanalysis
 If key compromised, only one session affected
 Prevents replay of messages from other sessions
Basic key exchange
 Public-key based…
 Diffie-Hellman key exchange
– Secure against passive eavesdropping…
– …but insecure against a man-in-the-middle attack
Adding key exchange
 Not sufficient to simply “add on” key
establishment before/after authentication
– Splicing attack…
 Need “authenticated key exchange”
KDCs
 Key Distribution Centers
 Advantages of symmetric-key crypto, without
O(n2) keys
– But requires a trusted intermediary
– Single point of failure/attack
 We will see an example (Kerberos) later
Multiple intermediaries
 Allows users in different domains to communicate
securely
 Use multiple KDCs…
– Can have all pairs of KDCs share a key
– More likely, there will be a hierarchy of KDCs
Authentication Protocols
(Chapter 11, KPS)
Overview
 Protocol design is subtle
– Small changes can make a protocol insecure!
– Historically, designed in an “ad-hoc” way, by checking
protocol for known weaknesses
– Great example of where provable security helps!
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