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 off-line 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