1. CMSC 414 Computer and Network Security Lecture 14 Jonathan Katz

2. 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…

3. Session keys  Maintain independence of sessions –E.g., prevent replay of messages from other sessions  If key compromised, only one session affected –Forward secrecy – even if long-term key compromised, session keys unaffected  Reduces effectiveness of cryptanalysis

4. Adding key exchange  Not sufficient to simply “add on” key establishment before/after authentication –Splicing attack…  Need “authenticated key exchange”

5. Public-key based…  Include E pk (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 E pks (R 1 ); server sends E pkc (R 2 ); session key is R 1 +R 2 –Reasonable…though no forward secrecy –Why isn’t it a problem that the ciphertexts are not authenticated? –Implicit vs. explicit authentication

6. Authenticated Diffie-Hellman  Add signatures/MACs and nonces to Diffie- Hellman protocol –Subtle details involved…need to ensure freshness and asymmetry –Achieves forward secrecy

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

8. Mediated authentication (KDCs)

9. KDCs  Key Distribution Centers  Advantages of symmetric-key crypto, without O(n 2 ) keys –But requires a trusted intermediary –Single point of failure/attack  Kerberos is a famous example

10. Basic idea  Every user i shares a key K i with the KDC  When Alice wants to talk to Bob, the KDC authenticates the request from Alice, chooses random K, and sends Enc Ka (K), Enc Kb (K) to Alice –Alice forwards Enc Kb (K) to Bob  Alice and Bob use K to communicate  Note that the KDC can read all communication!

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

12. Mediated authentication  Simple protocol: –Alice requests to talk to Bob –KDC generates K AB and sends it to Alice and Bob, encrypted with their respective keys  No authentication of KDC here, but impostor can’t determine K AB  Other drawbacks: –KDC has to initiate session with Bob –Alice may try to communicate with Bob before Bob hears from the KDC

13. Improvement…  Have KDC send to Alice the encryption of K AB 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 (using K AB )

14. Kerberos  Simpler; assumes loosely coordinated clocks  A  KDC: N, “Bob”  KDC  A: Enc K A {N, “Bob”, K AB, ticket}, where ticket = Enc K B {K AB, “Alice”, exp-time}  A  B: ticket, Enc K AB {timestamp}  B  A: Enc K AB {timestamp+1}

15. Desiderata and summary  This is not an exhaustive list!  These are concerns to be aware of; in some cases you may decide that certain threats are not a concern  Better to formally define a security model and prove security (but here we will be informal)

16. Desiderata and summary  Adversary initiating session as client (i.e., client impersonation) –No impersonation (obviously!) –No off-line dictionary attacks –Should not learn information that will subsequently allow impersonation of server to client –Be aware of server decrypting/signing unauthenticated challenges –Splicing messages into the session  Similar for server impersonation (though this is a harder attack to carry out)

17. Desiderata and summary  Eavesdropping –Should not learn information that would allow for later impersonation (possibly to another replica of Bob) –Messages should be encrypted –No off-line dictionary attacks  Server compromise –Should not learn client’s long-term secret/password –Forward secrecy –Impersonation of client to server (possibly a replica)

18. Certificate authorities and PKI

19. PKI overview  In our discussion of public-key crypto, we have assumed users know each others’ public keys  But how can public keys be reliably distributed? –Download from web page insecure against man-in-the- middle attack –Can be obtained from CD-ROM or in person, but this is impractical in general  One solution: bootstrap new public keys from public keys you already know! –Certificates vouch for binding of public keys to names

20. Certificates  One party can vouch for the public key of another  Cert(A  B) = Sign SKA (“B”, PK B, info) –“info” can contain expiration time, restrictions, etc.  Can view this as a directed edge in a graph:  If you know A’s public key (and trust its certification), you can learn B’s public key PK A PK B

21. Transitivity/“certificate chains”  Can learn keys via multiple hops:  Semantics are slightly different here: you may trust A to certify B, but do you trust A to certify that B can certify others? PK A PK B PK C Cert(A  B) Cert(B  C)

22. Transitivity  Can also infer trust from multiple (disjoint?) paths to the same public key for the same identity –Edges may also have weights indicating level of trust –A difficult problem in general PK A PK B PK C PK D PK E Public keys I already know

23. Usage of certificates  “Trust anchors” = set of public keys already known (and trusted to certify others)  How to obtain certificates?  Some possibilities: –B “collects” certificate(s) for itself, sends these all when starting a connection –A finds certificates/certificate chains beginning at its own trust anchors and terminating at B –A tells B its trust anchors, B (finds and) sends certificates or certificate chains beginning at those trust anchors and terminating at itself

24. Certificates in the real world  PGP keyserver (http://pgp.mit.edu)  CAs embedded in browsers –(Firefox:) Options→Advanced