1 / 24

CMSC 414 Computer and Network Security Lecture 14

CMSC 414 Computer and Network Security Lecture 14. Jonathan Katz. 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?

ashtyn
Download Presentation

CMSC 414 Computer and Network Security Lecture 14

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related