1 / 18

CMSC 414 Computer and Network Security Lecture 24

CMSC 414 Computer and Network Security Lecture 24. Jonathan Katz. Mediated authentication (using a KDC). Needham-Schroeder. A  KDC: N 1 , Alice, Bob KDC A: Enc KB {N 1 , “Bob”, K AB , ticket}, where ticket = Enc KB {K AB , “Alice”} A B: ticket, Enc KAB {N 2 } BA: Enc KAB {N 2 -1, N 3 }

jessie
Télécharger la présentation

CMSC 414 Computer and Network Security Lecture 24

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 24 Jonathan Katz

  2. Mediated authentication (using a KDC)

  3. Needham-Schroeder • AKDC: N1, Alice, Bob • KDCA: EncKB{N1, “Bob”, KAB, ticket}, where ticket = EncKB{KAB, “Alice”} • AB: ticket, EncKAB{N2} • BA: EncKAB{N2-1, N3} • AB: EncKAB{N3-1}

  4. Analysis? • N1 assures Alice that she is talking to KDC • Prevents key-replay; helps prevent attack when Bob’s key is compromised and then changed • “Bob” authenticated in message 2, and “Alice” in ticket • Uses encryption to authenticate…  • Leads to reflection attack on Bob if, e.g., ECB mode is used in round 4 • Vulnerable if Alice’s key (even an old one) compromised • A ticket is eternally valid • Fix using timestamps, or by Alice requesting a nonce from Bob at the very beginning of the protocol

  5. Otway-Rees • Addresses the ticket invalidation problem, in fewer rounds

  6. Otway-Rees • AB: N, “Alice”, EncKA{NA, N, “Alice”, “Bob”} • BKDC: EncKA{NA, N, “Alice”, “Bob”}, EncKB{NB, N, “Alice”, “Bob”} • KDCB: N, EncKA{NA, KAB}, EncKB{NB, KAB} • BA: EncKA{NA, KAB} • AB: EncKAB(timestamp)

  7. Analysis? • Why does Alice believe she is talking to Bob? • (Unfortunately, relies on encryption for authentication) • Why does Bob believe he is talking to Alice? • Note: N should be unpredictable, not just a nonce • Otherwise, can falsely authenticate Bob to Alice

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

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

  10. Desiderata and summary • Adversary initiating session as client • (Easiest attack to carry out) • No impersonation (obviously!) • No off-line password guessing • 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 adversary accepting connections from client (though this is a harder attack)

  11. 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 password • Forward secrecy • Impersonation of client to server(?)

  12. Certificate authorities and PKI

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

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

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

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

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

  18. Certificates in the real world • PGP keyserver • CAs embedded in browsers

More Related