CMSC 414 Computer and Network Security Lecture 14

1. CMSC 414Computer and Network SecurityLecture 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 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…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(n2) 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 Ki with the KDC • When Alice wants to talk to Bob, the KDC authenticates the request from Alice, chooses random K, and sends EncKa(K), EncKb(K) to Alice • Alice forwards EncKb(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 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 may try to communicate with Bob before Bob hears from the KDC

13. 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 (using KAB)

14. Kerberos • Simpler; assumes loosely coordinated clocks • AKDC: N, “Bob” • KDCA: EncKA{N, “Bob”, KAB, ticket}, where ticket = EncKB{KAB, “Alice”, exp-time} • AB: ticket, EncKAB{timestamp} • BA: EncKAB{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. PKA PKB Certificates • One party can vouch for the public key of another • Cert(AB) = SignSKA(“B”, PKB, 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

21. Cert(AB) Cert(BC) PKA PKB PKC 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?

22. PKA PKB PKC 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 PKD PKE 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