2007. 10. 30 (Tuesday) Kim Jinyoung Chap 9. Key Management. Introduction to Computer Security. Matt Bishop. 2007. 10. 30 (Tuesday) Kim Jinyoung

Contents Introduction. 9.1 Session and Interchange Keys. 9.2 Key Exchange. 9.3 Cryptographic Key Infrastructures. 9.4 Storing and Revoking Keys. 9.5 Digital Sinatures. Conclusions.

Introduction. Key management refers to the distribution of cryptographic keys. The mechanisms used to bind an identity to a key; and the generation, maintenance, and revoking of such keys. Notations. 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 (nonrepeating random numbers)

9.1 Session and Interchange Keys. Alice wants to send a message m to Bob. Assume public key encryption. Alice generates a random cryptographic key ks and uses it to encipher m To be used for this message only. Called a session key. She enciphers ks with Bob;s public key kB. kB enciphers all session keys Alice uses to communicate with Bob. Called an interchange key. Alice sends { m } ks { ks } kB.

9.1 Session and Interchange Keys. Benefits. Limits amount of traffic enciphered with single key. standard practice, to decrease the amount of traffic an attacker can obtain. Prevents some attacks. Example : Alice will send Bob message that is either “BUY” or “SELL”. Eve computes possible ciphertexts { “BUY” }kB and { “SELL” }kB. Eve intercepts enciphered message, compares, and gets plaintext at once.

9.2 Key Exchange. GOAL : to enable Alice to communicate secretly to Bob, and vice versa, using a shared cryptographic key. Criteria : Key cannot be sent in clear. - Attacker can listen in. - Key can be sent enciphered, or derived from exchanged data plus data not known to an eavesdropper. Alice, Bob may trust third party(“Cathy”). All cryptosystems, protocols publicly known - Only secret data is keys, ancillary information known only to Alice and Bob needed to derive keys. - Anything transmitted is assumed known to attacker.

9.2.1 Classical Cryptographic Key Exchange and Authentication. Bootstrap problem : Alice can’t send it to Bob in the clear! Assume trusted third party, Cathy. Alice and Cathy share secret key kA. Bob and Cathy share secret key kB. Use this to exchange shared key ks.

9.2.1 Classical Cryptographic Key Exchange and Authentication. Simple Protocol. Problems. How does Bob know he is talking to Alice? Replay attack : Eve records message from Alice to Bob, later replays it. Session Key reuse : Eve records 2nd message, Bob re-uses session key. Protocols must Provide authentication and defense against replay.

9.2.1 Classical Cryptographic Key Exchange and Authentication. Needham-Schroeder protocol.

9.2.1 Classical Cryptographic Key Exchange and Authentication. Denning–Sacco Modification. Assumption : all keys are secret. Question : suppose Eve can obtain session key. How does that affect protocol? In what follows, Eve knows ks.  Bob thinks he is talking to Alice. Bob is really talking to Eve.

9.2.1 Classical Cryptographic Key Exchange and Authentication. Needham-Schroeder with Denning–Sacco Modification. T : timestamp using timestamps to enable Bob to detect replay. This modification requires synchronized clocks. Weakness : if clocks not synchronized, may either reject valid messages or accept replays. Parties with either slow or fast clocks vulnerable to replay. Resetting clock does not eliminate vulnerability.

9.2.1 Classical Cryptographic Key Exchange and Authentication. Otway-Rees Protocol by avoiding the use of timestamps. T : timestamp Uses integer n to associate all messages with particular exchange. Do not use timestamps. Not vulnerable to the problems that Denning-Sacco modification has. Eve acquires old ks, message in third step. Eve forwards appropriate part to Alice. Alice has no ongoing key exchange with Bob : n matches nothing, reject. ongoing key exchange with Bob : n does not match, also reject.

9.2.2 Kerberos. Kerberos. Ticket. Authenticator. Computer network authentication protocol. Based on Needham-Schroeder with Denning-Sacco modification. client-server model, and it provides mutual authentication : both the user and the server verify each other’s identity. Central server plays role of trusted third party (“Cathy”). protected against eavesdropping and replay attacks. Ticket. Issuer vouches for identify of requester of service. Authenticator. Identifies sender.

9.2.2 Kerberos. Ticket. Authenticator. Credential saying issuer has identified ticket requester. Example : ticket issued to user u for service s. ku,s is session key for user and service. Valid time is interval for which ticket valid. u’s address may be IP address or something else. Authenticator. Credential containing identity of sender of ticket. Example : authenticator user u generates for service s. kt is alternate session key. Generation time is when authenticator generated.

9.2.2 Kerberos. Example : Alice’s goal is to print a file using the service Guttenberg. authentication server : Cerberus, ticket-granting server : Barnum. 1. Alice requests ticket (kerberos authentication) 2. Kerberos issues ticket for Barnum 3. Alice requests ticket from Barnum 4. Barnum issues ticket 5. Alice uses ticket for transmission 6. (optional) Guttenberg send it to confirm the request. Cerberus Barnum Alice Guttenberg ① ② ③ ④ ⑤ ⑥

9.2.2 Kerberos. Problems. Relies on synchronized clocks. If not synchronized and old tickets, authenticators not caches, replay is possible. Tickets have some fixed fields. Dictionary attack possible. Kerberos 4 session keys weak (had much less than 56 bits of randomness); researchers at Purdue found them from tickets in minutes.

9.2.3 Public Key Criptographic Key Exchange and Aythentication. Here Interchange keys known. eA, eB : Alice and Bob’s public keys known to all. dA, dB : Alice and Bob’s private keys known only to owner. Simple protocol. ks is desired session key. { ks } eB Alice Bob  Problem : Vulnerable to forgery or replay. Bob does not know who the message comes form. Simple fix uses Alice’s private key. Alice Bob { { ks } dA } eB Can include message enciphered with ks.

9.2.3 Public Key Criptographic Key Exchange and Aythentication. Assumes Bob has Alice’s public key, and vice versa. If not, each must get it from public server, Peter. If keys not bound to identify of owner, attacker Eve can launch a man-in-the-middle attack. Cathy is public server providing public keys. Solution to this (binding identity to keys) discussed later as public key infrastructure (PKI).

9.3 Cryptographic key Infrastructures. 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. Crucial as people will use key to communicate with principal whose identity is bound to key. Erroneous binding means no secrecy between principals. Assume principal identified by an acceptable name. Example : Certificates. Identify of principal. Corresponding public key. Timestamp. and other information. CA = { eA || Alice || T } dCathy Problem : Bob needs Cathy’s public key to validate certificate. Two approaches : Merkle’s tree, signature chains.

9.3.1 Certificate signature Chains. 9.3.1.1 X.509 : Certification Signature Chains. X.509 is an ITU-T standard for public key infrastructure (PKI). standard formats for public key certificates and a certification path validation algorithm. The Directory Authentication Framework. Certificate format Version version of the X.509 certificate Certificate Serial Number unique among the certificates issued by this issuer. Signature algorithm identifier for CA identifies the algorithm, used to sign the certificate. Issuer’s Distinguished Name uniquely identifies the issuer. Validity Period the times at which the certificate becomes valid and expires. Subject’s Distinguished Name uniquely identifies the subject to whom the certificate is issued. Subject’s Public Key Information This identifies the algorithm, and the subject’s PK. Issuer’s unique identifier issuer Distinguished names may be recycled. added version 2 Subject’s unique identifier This field like field 8, but for the subject. Type Criticality Value added version 3 Type Criticality Value CA Signature This field identifies the algorithm and parameters used to sign the certificate, followed by the signature.

9.3.1 Certificate signature Chains. 9.3.1.1 X.509 : Certification Signature Chains. X.509 Certificate Validation. Obtain issuer’s public key. The one for the particular signature algorithm. Decipher signature. Gives hash of certificate. Recompute hash from certificate an compare. If they differ, there’s a problem. Check interval of validity. This confirms that certificate is current.

9.3.1 Certificate signature Chains. 9.3.1.1 X.509 : Certification Signature Chains. Certification Authority (CA) : entity that issues certificates. Multiple issuers pose validation problem. Alice’s CA is Cathy; Bob’s CA is don; How can Alice validate Bob’s certificate? Have Cathy and Don cross-certify Cathy Dan each issues certificate for the other. Validation and Cross-Certifying. Alice Bob Certificates : Alice validates Bob’s certificate. Cathy<<Alice>> Dan<<Bob>> Cathy<<Dan>> Dan<<Cathy>> Alice obtains Cathy<<Dan>> Alice uses (known) public key of Cathy to validate Cathy<<Dan>> Alice uses Cathy<<Dan>> to validate Dan<<Bob>>

9.3.1 Certificate signature Chains. 9.3.1.1 X.509 : Certification Signature Chains. 메시지 암호화. X. 509 인증서. <그림. 공개 키와 개인 키를 이용한 메시지 암호화 / 복호화> <그림. 전자 서명 생성과 확인>

9.3.1 Certificate signature Chains. 9.3.1.2 PGP Certificate Signature Chains. Pretty Good Privacy : a computer program that provides cryptographic privacy and authentication. PGP is an encipherment program widely used to provide privacy for electronic mail throughout the Internet, and to sign files digitally. OpenPGP certificates structured into packets. One public key packet. Zero or more signature packets. Public key packet : Version( 3 or 4 ). Creation time : When the certificate was created. Validity period : (version 3 only) the number of days that the certificate is valid. Public key algorithm, associated parameters. Public key.

9.3.1 Certificate signature Chains. 9.3.1.2 PGP Certificate Signature Chains. Version 3 signature packet. Version (3) Signature type (level of trust) Creation time (when next fields hashed) Signer’s key identifier (identifies key to encipher hash) Public key algorithm (used to encipher hash) Hash algorithm Part of signed hash (used for quick check) Signature (enciphered hash) Version 4 signature packet more complex. PGP certificates differ from X.509 certificates a single key may have multiple signatures. the signature for a single key may have different levels of trust. the users of the certificates can determine the level of trust for each signature.

9.3.1 Certificate signature Chains. 9.3.1.2 PGP Certificate Signature Chains. Example : Validating Certificates. Suppose alice needs to communicate with Bob. Alice needs to validate Bob’s OpenPGP cert. 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. Allows show signatures. Self signatures not shown. Jack Henry Ellen Irene Giselle Bob Fred

9.4 Storing and Revoking Keys. 9.4.1 Key Storage. Key storage arises when a user needs to protect a cryptographic key in a way other than by remembering it. On a single-user system, this consideration is irrelevant. Multi-user system or Networked systems : attackers my defeat access control mechanisms. Encipher file containing key. Attacker can monitor keystrockes to decipher files. Key will be resident in memory that attacker may be able to read. Use physical devices like “ smart card”. Key never enters system. Card can be stolen, so have 2 devices combine bits to make single key.

9.4 Storing and Revoking Keys. 9.4.2 Key Revocation. Certificates invalidated before expiration. Usually due to compromised key. May be due to change in circumstance. Problems. Entity revoking certificate authorized to do so. Revocation information circulates to everyone fast enough. Network delays, infrastructure problems may delay information. CRLs (Certificate Revocation List) lists certificates that are revoked. X.509 : Only certification issuer can revoke certificate. : added to CRL. PGP : signers can revoke signatures; owners can revoke certificates, or allow others to do so. Revocation message placed in PGP packet and signed. Flag marks it as revocation message.

9.5 Digital Signatures. A digital signature is a construct that authenticates both the origin and contents of a message in a manner that is provable to a disinterested third party. Classical : Alice, Bob share key k. Alice sends m||{m}k to Bob. Is this a digital signature? Wrong!! This is not a digital signature!! Why? Third party can not determine whether Alice or bob generated message. dAlice and eAlice be Alice's private and public keys, respectively. Alice sends Bob the message m || { m }dAlice. The judge merely obtains eAlice and computes { { m }dAlice } eAlice. If the result is m, Alice signed it. This is in fact a digital signature

9.5 Digital Signatures. 9.5.1 Classical Signatures. All classical digital signature schemes rely on a trusted third party. Alice, Bob each share keys with trusted third party Cathy. To resolve dispute, judge gets { m }kAlice, { m }kBob, and has Cathy decipher them; if messages matched, contract was signed.

9.5 Digital Signatures. 9.5.2 Public Key Signatures. We observe that using RSA to authenticate a message produces a digital signature. Operation : RSA involves a public key and a private key. Example : Create the public key and private key. 1. P = 7, Q = 17 2. n = PQ = 7*17 = 119 3. Ø(n) = (P-1)(Q-1) = 6*16 = 96 4. e = 5 5. de = 1 mod 96, d<96, d=77 (5*77= 385 = 1+4*96)  public key = { 119, 5 }, private key = { 119, 77 } The public key can be known to everyone. Messages encrypted with the public key can only be decrypted using the private key. 1. Choose two distinct large random prime numbers P and Q. 2. Compute n=PQ. 3. Compute the positive integer : Ø(n) = (P-1)(Q-1). 4. Choose an integer e such that 1<e< Ø(n), and e and Ø(n) share no factors other than 1. - e is released as the public key exponent. 5. compute d to satisfy the congruence relation de≡1 (mod Ø(n)). - d is kept as the private key exponent.

9.5 Digital Signatures. 9.5.2 Public Key Signatures. Example : Create the public key and private key. 1. P = 7, Q = 17 2. n = PQ = 7*17 = 119 3. Ø(n) = (P-1)(Q-1) = 6*16 = 96 4. e = 5 5. de = 1 mod 96, d<96, d=77 (5*77= 385 = 1+4*96)  public key = { 119, 5 }, private key = { 119, 77 }

9.5 Digital Signatures. 9.5.2 Public Key Signatures. Encrypting messages. Encrypting messages : C = me mod n Decrypting messages : m = Cd mod n Example : M = 19, public key = {119, 5}, private key = { 119, 77} Encrypting messages : 195 mod 119 = 66 Decrypting messages : 6677 mod 119 = 19 195 mod 119 = 66 Public key = {119, 5} 6677 mod 119 = 19 Private key = {119, 77} M = 19 Alice transmits her public key {n, e} to Bob and keeps the private key secret. Bob then wishes to send message M to Alice. Bob knows Alice’s public key. (ciphertext) C = me mod n. Decrypting messages. Alice can recover m from C by using her private key exponent d by the following computation : m = Cd mod n. Given m, she can recover the original message M. Example : M=19, public key = { 119, 5 }, private key = { 119, 77 }

9.5 Digital Signatures. 9.5.2 Public Key Signatures. Encrypting messages : C = me mod n Decrypting messages : m = Cd mod n Example : M = 19, public key = {119, 5}, private key = { 119, 77} Encrypting messages : 195 mod 119 = 66 Decrypting messages : 6677 mod 119 = 19 195 mod 119 = 66 Public key = {119, 5} 6677 mod 119 = 19 Private key = {119, 77} M = 19

9.5 Digital Signatures. 9.5.2 Public Key Signatures. Example #1 : Alice, Bob communicationg. nA = 95, eA = 59, dA = 11 nB = 77, eB = 53, dB = 17 26 contracts, numbered 00 to 25. (A~Z) Alice has Bob sign 05 and 17 : - c = mdB mod nB = 0517 mod 17 = 3 - c = mdB mod nB = 1717 mod 77 = 19 Alice computes 05 X 17 mod 77 = 08; corresponding signature is 03 X 19 mod 77 = 57; claims Bob signed 08 Judge compute ceB mod nB = 5753 mod 77 = 08 - Signature validated; Bob is toast.

9.5 Digital Signatures. 9.5.2 Public Key Signatures. Example #2 : Alice agree to sign contract 06. nA = 95, eA = 59, dA = 11 nB = 77, eB = 53, dB = 17 26 contracts, numbered 00 to 25. (A~Z) Alice enciphers, then signs : - (meB mod 77)dA mod nA = 0653 mod 77)11 mod 95 = 63 Bob now changes his public key. - Computes r such that 13r mod 77 = 6; say, r = 59; - Computes reB mod Ø(nB) = 59 X 53 mod 60 = 7 - Replace public key eB with 7, private key dB = 43 Bob claims contract was 13. Judge computes : - (6359 mod 95)43 mod 77 = 13 - Verified; now Alice is toast.

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

Thank You!