Transcript CMSC 414 Computer and Network Security Lecture 23 Jonathan Katz

CMSC 414
Computer and Network Security
Lecture 23
Jonathan Katz
HW4
Mutual authentication in 3 rounds?
 Can we compress the previous protocol to 3
rounds?
– Client sends their name, R’
– Server sends f(k, R’) and R
– Client sends f(k, 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
A public-key protocol
 Client sends Encpks(R)
 Server sends R, Encpkc(R’)
 Client sends R’
 Security?
– Vulnerable to chosen-ciphertext attacks…
– Seems better to use signatures
 How does the client obtain pks and skc?
– One option is to download “credentials” from another
site using a password
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?
 (Note: the fix suggested in the book is bad)
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
– A lot of subtle details involved…
Authentication with password +
public key
 Say that only the server has a known public key
(e.g., SSL)
– Server sends R
– Client sends Epk(R, password, session-key)
 Insecure in general…
– But secure if encryption scheme is CCA-secure
 Can be extended to give mutual authentication
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
Mediated authentication
(using a KDC)
Mediated authentication
 Simple protocol:
– Alice requests to talk to Bob
– KDC generates KAB and sends it to Alice and Bob,
encrypted with their respective keys
 No authentication of KDC here, but impostor can’t
determine KAB
 Other drawbacks:
– KDC has to initiate session with Bob
– Alice’s message to Bob may arrive before KDC’s
message to Bob
Improvement…
 Have KDC send to Alice the encryption of KAB
under Bob’s key
– Reduces communication load on KDC
– Resilient to message delays in network
 Bob and Alice follow with mutual authentication
and key exchange