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. Notation • XY : { Z || W } kX,Y • X sends Y the message produced by concatenating Z and W enciphered by key kX,Y, which is shared by users X and Y • AT : { Z } kA || { W } kA,T • A sends T a message consisting of the concatenation of Z enciphered using kA (A’s key), and W enciphered using kA,T, the key shared by A and T • r1, r2: nonces (non-repeating random numbers)

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

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

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

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

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

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

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

11. Problems • Now let us look at Bob: • Does Bob knows the other party? Not really • Does Bob knows the key is for him: Yes • Does the other party actually know the key? Not sure • Is the key fresh? Not sure • Some attacks may exist • Session key reuse: Eve talked to Bob and got a session key. She replays this message and pretends to be Alice to talk to Bob

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

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

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

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

16. Argument: Alice talking to Bob • How does Bob make sure: • This is b/w him and Alice • The random number r2 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 r2 • The other party actually knows the key • Not guaranteed in the protocol, but will show in the following data communication

17. Replay Attack • Possible attack • Eve acquires old ks and the message in the third step • The message is: n || { r1 || ks } kA || { r2 || ks } kB • Eve resends the message to Alice • Alice has no ongoing key exchange with Bob: n matches nothing, so is rejected • Alice has ongoing key exchange with Bob: r1 does not match, so is again rejected

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

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

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

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

22. Cryptographic Key Infrastructure • Goal: bind identity to key • Classical: not possible as all keys are shared • Use protocols to agree on a shared 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

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

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

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

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

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

28. 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!)

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

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

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

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

33. Common Error • Classical: Alice, Bob share key k • Alice sends m || { m } k to Bob This is not a digital signature • Why? Third party cannot determine whether Alice or Bob generated message

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

35. RSA Digital Signatures • Use private key to encipher message • 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

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