Chapter 9: Key Management

1. Chapter 9: Key Management • All algorithms we have introduced are based on one assumption: keys have been distributed. But how to do that? • Key generation, distribution, storage, revocation • Bind key to identity (owner)

2. Overview • Key exchange • Session vs. interchange keys • Classical, public key methods • Cryptographic key infrastructure • Certificates • Key revocation • Digital signatures

3. Session, Interchange Keys • Session key: associate with a communication only; is used for a short period of time • Interchange key: associate with a principal; usually is used to establish session keys; is used for a longer period of time

4. Session, Interchange Keys • Alice wants to send a message m to Bob • Alice generates a random cryptographic key kA,B and uses it to encipher m • To be used for this message only • Called a session key • She enciphers kA,B with Bob’s public key kpub_B • kpub_B enciphers all session keys that Alice uses to communicate with Bob • Called an interchange key • Alice sends { m } kA,B || { kA,B} kpub_B

5. Benefits • Limit the amount of traffic that is enciphered with a single key • Use interchange keys to encrypt session keys • Use session keys to encrypt data • decrease the amount of traffic an attacker can obtain • Prevents some attacks • Example: Alice will send Bob a message that is either “BUY” or “SELL”. Eve computes possible ciphertexts { “BUY” } kpub-B and { “SELL” } kpub-B. Eve intercepts enciphered message, compares, and gets plaintext at once • Called “forward search”

6. Threats to key distribution/establishment procedures: • Who is the other party of the communication • She says that she is Alice, but is she? • Is the key generated for the communication b/w me and Alice? • Who are the two parties for the key • Does the other party actually know the key? • Is the key fresh? • Two ways to guarantee this

7. Key Exchange Algorithms • Goal: Alice, Bob get shared key • Key cannot be sent in clear • Attacker can listen and get the key • Key can be sent enciphered, or derived from exchanged data plus data not known to an eavesdropper (pre-distributed) • Alice, Bob may trust a third party • All cryptosystems, protocols publicly known • The only secret data are the keys, and some pre-distributed information to Alice and Bob (for key derivation) • Anything transmitted on the network is assumed to be known to attacker

8. Classical Key Exchange • Bootstrap problem: how do Alice, Bob begin? • Alice can’t send the key to Bob in the clear! • Assume a trusted third party, Cathy • Alice and Cathy share secret key kA,C • Bob and Cathy share secret key kB,C • Use this to exchange shared key kA,B

9. Simple Protocol {request for session key to Bob } kA,C Alice Cathy { kA,B } kA,C || { kA,B } kB,C Alice Cathy Alice, { kA,B } kB,C Alice Bob

10. Methods to fix the problems • About two communication parties: • The names of two parties should be clearly identified in the encrypted messages • The other party needs to show that he/she actually knows the key • Challenge-response • Freshness of the key: • Use time stamp • Or use freshly generated random numbers

11. Otway-Rees Protocol • Does not use timestamps • Does not need clocks to be synchronized • Uses integer n to associate all messages with particular exchange

12. The Protocol n || Alice || Bob || { r1 || n || Alice || Bob } kA Alice Bob n || Alice || Bob || { r1 || n || Alice || Bob } kA || { r2 || n || Alice || Bob } kB Cathy Bob n || { r1 || ks } kA || { r2 || ks } kB Cathy Bob n || { r1 || ks } kA Alice Bob

13. Argument: Alice talking to Bob • Why a number n • To link all messages of this exchange together • How does Alice make sure: • This is b/w her and Bob • The random number r1 is linked to this connection b/w Alice and Bob. Only Cathy can open the 2nd message and see it. • The key is fresh • Because of the random number r1 • The other party actually knows the key • Not guaranteed in the protocol, but will see in the following data communication

14. Public Key Key Exchange • Here interchange keys are known to everyone • eA, eB: Alice and Bob’s public keys known to all • dA, dB: Alice and Bob’s private keys known only to the owner • A simple protocol to establish the session key • ks is the desired session key { ks } eB Alice Bob

15. Problem and Solution • Vulnerable to forgery or replay • Because eB is known to everyone, Bob has no assurance that Alice sent the message • Simple fix: uses Alice’s private key to double encrypt the message • Ks: is the desired session key { { ks } dA } eB Alice Bob

16. Notes • Assumes Bob has Alice’s public key, and vice versa • If not, they must get the public keys of the other party from a server • If a public key is not bound to an identity, attacker Eve can launch a man-in-the-middle attack (next slide) • Solution to this (binding identity to keys) discussed later as public key infrastructure (PKI) • Man-in-the-middle: Eve pretends to be Alice to Bob, and pretends to be Bob to Alice

17. Man-in-the-Middle Attack I need Bob’s public key Eve intercepts request Alice Cathy I need Bob’s public key Cathy Eve Bob’s pub key eB Cathy Eve Bob’s pub key eE Eve Alice { ks } eE Eve intercepts message Bob Alice { ks } eB Bob Eve

18. Cryptographic Key Infrastructure • Goal: bind identity to key • Public key: bind identity to public key • It is crucial since people will use the public key to communicate to the principal whose identity is bound to the public key • Erroneous binding means no secrecy between principals • We assume that principal identified by an acceptable name

19. Certificates • A certificate token (message) contains • Identity of principal (here, Alice) • Corresponding public key • Timestamp (when issued, when expire) • Other information (perhaps identity of signer) signed by a trusted authority (here, Cathy) CA = { eA || Alice || T } dC

20. Use • Bob gets Alice’s certificate • If he knows Cathy’s public key, he can decipher the certificate • When was the certificate issued? • Is the principal Alice? • Now Bob has Alice’s public key • It does not have to come from Alice • Problem: Bob needs Cathy’s public key to validate certificate • Problem pushed “up” a level • Two approaches: • Certificate hierarchy: VeriSign signs certificate for EBay, EBay signs Alice, now you get Alice’s public key if you trust VeriSign • Signature chains: friend tells friend

21. Certificate Signature Chains • Create certificate • Generate hash value of the certificate content • Encipher hash with issuer’s private key • Validate • Obtain issuer’s public key • Decipher enciphered hash • Re-compute hash value from certificate and compare • Problem: getting issuer’s public key

22. Issuers • Certification Authority (CA): entity that issues certificates • It will be easy if the whole world has one CA • Multiple issuers pose validation problem • Alice’s CA is Cathy; Bob’s CA is Don; how can Alice validate Bob’s certificate? • Let Cathy and Don cross-certify each other • Each issues certificate for the other

23. X.509 Validation and Cross-Certifying • Certificates: • Cathy<<Alice>> • Dan<<Bob> • Cathy<<Dan>> • Dan<<Cathy>> • Alice validates Bob’s certificate • Alice obtains Cathy<<Dan>> • Alice uses (known) public key of Cathy to validate Cathy<<Dan>> • Alice uses Dan’s public key to validate Dan<<Bob>>

24. PGP Chains • Locate a chain of people that trust and issue certificate for the next one in the chain • In PGP, the public key of one principal can be signed by multiple signatures of different people • Notion of “trust” embedded in each signature • Range from “untrusted” to “ultimate trust” • Signer defines meaning of trust level (no standards!)

25. Validating Certificates • Alice needs to validate Bob’s certificate • Alice does not know Fred, Giselle, or Ellen • Alice gets Giselle’s cert • Knows Henry slightly, but his signature is at “casual” level of trust • Alice gets Ellen’s cert • Knows Jack, so uses his cert to validate Ellen’s, then hers to validate Bob’s Arrows show signatures Self signatures not shown Jack Henry Ellen Irene Giselle Fred Bob

26. Key Revocation • Certificates invalidated before expiration • Usually due to compromised key • May be due to change in circumstance (e.g., someone leaving company) • Problems • Who can revoke certificates: Entities that are authorized to do so • How to let every one know: Revocation information circulates to everyone • Network delays, infrastructure problems may delay information

27. CRLs • Certificate revocation list lists certificates that are revoked • X.509: only certificate issuer can revoke certificate • Added to CRL • PGP: signers can revoke signatures; owners can revoke certificates, or dedicate others to do so

28. Digital Signature • Construct a message that we can prove its origin and integrity of contents to a disinterested third party (“judge”) • Sender cannot deny having sent message (the service is “nonrepudiation”) • Limited to technical proofs • cannot deny one’s cryptographic key was used to sign • One could claim the cryptographic key was stolen or compromised • Legal proofs, etc., probably required; not dealt with here

29. Public Key Digital Signatures • Alice’s keys are dAlice, eAlice • Alice sends Bob m || { m } dAlice • In case of dispute, judge computes { { m } dAlice } eAlice • and if it is m, Alice signed the message • She’s the only one who knows dAlice!

30. Digital Signatures • Key points: • Never sign random documents, and when signing, always sign the hash of the document • Mathematical properties can be turned against signer • Sign message first, then encipher • Changing public keys causes forgery

31. Key Points • Key management critical to effective use of cryptosystems • Different levels of keys (session vs. interchange) • Keys need infrastructure to identify holders, allow revoking • Key escrowing complicates infrastructure • Digital signatures provide integrity of origin and content • Much easier with public key cryptosystems than with classical cryptosystems • Two types of attacks • Forward search and man-in-the-middle