1. 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. 2 Overview Key exchange –Session vs. interchange keys –Classical, public key methods Cryptographic key infrastructure –Certificates Key revocation Digital signatures

3. 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. 4 Session, Interchange Keys Alice wants to send a message m to Bob –Alice generates a random cryptographic key k A,B and uses it to encipher m To be used for this message only Called a session key –She enciphers k A,B with Bob’s public key k pub_B –k pub_B enciphers all session keys that Alice uses to communicate with Bob Called an interchange key –Alice sends { m } k A,B || { k A,B } k pub_B

5. 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” } k pub-B and { “SELL” } k pub-B. Eve intercepts enciphered message, compares, and gets plaintext at once Called “forward search”

6. 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. 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. 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 k A,C –Bob and Cathy share secret key k B,C Use this to exchange shared key k A,B

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

10. 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. 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. 12 The Protocol AliceBob n || Alice || Bob || { r 1 || n || Alice || Bob } k A CathyBob n || Alice || Bob || { r 1 || n || Alice || Bob } k A || { r 2 || n || Alice || Bob } k B CathyBob n || { r 1 || k s } k A || { r 2 || k s } k B AliceBob n || { r 1 || k s } k A

13. 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 2 nd 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. 14 Public Key Key Exchange Here interchange keys are known to everyone –e A, e B: Alice and Bob’s public keys known to all –d A, d B: Alice and Bob’s private keys known only to the owner A simple protocol to establish the session key –k s is the desired session key Alice Bob { k s } e B

15. 15 Problem and Solution Vulnerable to forgery or replay –Because e B 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 –K s: is the desired session key Alice Bob { { k s } d A } e B

16. 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. 17 Man-in-the-Middle Attack AliceCathy I need Bob’s public key Eve Cathy I need Bob’s public key Eve Cathy Bob’s pub key e B Alice Bob’s pub key e E Eve Alice Bob { k s } e E Eve Bob { k s } e B Eve intercepts request Eve intercepts message

18. 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. 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) C A = { e A || Alice || T } d C

20. 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. 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. 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. 23 X.509 Validation and Cross- Certifying Certificates: –Cathy > –Dan –Cathy > –Dan > Alice validates Bob’s certificate –Alice obtains Cathy > –Alice uses (known) public key of Cathy to validate Cathy > –Alice uses Dan’s public key to validate Dan >

24. 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. 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 Bob Fred Giselle Ellen Irene Henry Jack Arrows show signatures Self signatures not shown

26. 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. 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. 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. 29 Public Key Digital Signatures Alice’s keys are d Alice, e Alice Alice sends Bob m || { m } d Alice In case of dispute, judge computes { { m } d Alice } e Alice and if it is m, Alice signed the message –She’s the only one who knows d Alice !

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