CIT 480: Securing Computer Systems Key Exchange and Public Key Cryptography Topics 1. Key Exchange Problem 2. Public Key Cryptography 3. Diffie-Hellman Key Exchange 4. RSA Cipher 5. Digital Signatures 6. Public Key Infrastructure 7. Key Storage and Revocation Key Exchange Algorithms Goal: Alice, Bob obtain shared secret key. Requirements: – Key cannot be sent in clear: • Attacker can intercept key. • 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 or data used to derive keys. • Anything transmitted is assumed known to attacker. Classical Key Exchange Bootstrap problem: how do Alice, Bob begin? – Alice can’t send key to Bob in the clear! Assume trusted third party, Cathy – Alice and Cathy share secret key kA. – Bob and Cathy share secret key kB. Let Cathy generate shared key ks. – Cathy can send key securely to either A or B. Simple Key Exchange Protocol { request for session key to Bob } kA Cathy { ks } kA || { ks } kB Cathy { ks } kB Alice Bob Protocol Notation X sends Y a message Z encrypted with key k. X → Y : {Z} k Concatenation of bit sequences A and B A || B Key subscripts indicate ownership kA is the key belonging to user A(lice) kA,B is a key shared by A(lice) and B(ob) Nonces (nonrepeating random numbers) r1, r2 Key Exchange Protocol Threats { request for session key to Bob } kA { ks } kA || { ks } kB { ks } kB Alice Bob Sniffing Replay attacks Modifications Eve Simple Key Exchange Vulnerabilities How does Bob know he is talking to Alice? Replay attack: Eve records message from Alice to Bob, later replays it; Bob may think he’s talking to Alice, but he isn’t. While Eve can’t read message, replay may be enough to become authentication or cause another action. Session key reuse: Eve replays key exchange message from Alice to Bob, so Bob re-uses session key. If Eve knows old key, then she can decrypt communication. If Eve does not, she can collect more data for cryptanalysis. Needham-Schroeder + Denning-Sacco Mod Bob will reject message if timestamp T is too old. Alice || Bob || r1 Alice Cathy { Alice || Bob || r1 || ks || { Alice || T || ks } kB } kA Alice Cathy { Alice || T || ks } kB Alice Bob { r2 } ks Alice Bob { r2 – 1 } ks Alice Bob Public Key Cryptography Two keys Private key known only to owner. Public key available to anyone. Applications Confidentiality: • Sender enciphers using recipient’s public key, • Receiver deciphers using their private key. Integrity/authentication: • Sender enciphers using own private key, • Recipient deciphers using sender’s public key. Requirements 1. It must be computationally easy to encipher or decipher a message given the appropriate key. 2. It must be computationally infeasible to derive the private key from the public key. 3. It must be computationally infeasible to determine the private key from a chosen plaintext attack. One-Way Trapdoor Functions Trapdoor one-way Function: One-way function whose inverse is easy to calculate only if given a special piece of information. Example: Prime factoring – Easy to calculate product. – Difficult to calculate prime factors from product. – Easy to calculate one prime factor, given others. Note: Better attacks than brute force exist. – While prime factoring is hard, it’s not as hard as a brute force search of all keys. – 128-bit keys are not sufficient for public keys! – Key size required depends on which trapdoor fn used. Diffie-Hellman Key Exchange Compute shared key w/o trusted 3rd party. Based on discrete logarithm problem – Given integers n and g and prime number p, compute k such that n = gk mod p. – Solutions known for small p. – Computationally infeasible for large p. Shared Constants – prime modulus p, – integer base g ≠ {0, 1, p–1} Algorithm 1. Alice chooses a random private key k 2. Computes public key A = gk mod p and sends to Bob. 3. Bob chooses a random private key k’ 4. Computes public key B = gk’ mod p and sends to Alice. 5. Alice computes secret key k 1. K1 = B mod p 6. Bob computes secret key k’ 1. K2 = A mod p 7. Encrypt messages w/ symmetric cipher using K1=K2 as the shared secret key. Example Assume p = 53 and g = 17 Alice chooses kAlice = 5 5 Then KAlice = 17 mod 53 = 40 Bob chooses kBob = 7 7 Then KBob = 17 mod 53 = 6 Shared key: kAlice 5 Alice computation: KBob mod p = 6 mod 53 = 38 kBob 7 Bob computation: KAlice mod p = 40 mod 53 = 38 Diffie-Hellman Activity Assume p = 51 and g = 19. Find a student to pair with. – Each student picks a random private key. – Compute public key with irb. irb(main):001:0> (19**7).modulo(51) => 43 Share your public key with your partner. – Compute shared, secret key using irb. – Compare shared key with partner. – If they match, congratulations! – If they don’t, find out what went wrong. RSA 1. Modular exponentiation cipher. 2. Treat message blocks as large numbers. 3. Based on the difficulty of factoring large numbers into primes. RSA Algorithm Choose two large prime numbers p, q – Let the modular base n = pq. – Choose e < n such that e relatively prime to φ(n). – Compute inverse of e, d to use as private key. Public key: (e, n) Private key: d Encipher: c = me mod n Decipher: m = cd mod n Digital Signatures Construct that authenticates origin & contents of message in a manner provable to a disinterested third party (“judge.”) Nonrepudiatable – Sender cannot deny having sent message. – Proves that sender’s key was used to sign message. – What if you claim key was stolen/compromised? • Court would have to decide. Signing and Verification Cryptographic Key Infrastructure Problem: how to bind identity to key Classical: not possible as all keys are shared – Use protocols to agree on a shared key (see earlier.) Public key: bind identity to public key – Crucial as people will use key to communicate with principal whose identity is bound to key. – Digital signatures require association of key with identity. – Assume principal identified by an acceptable name. Certificates Create a token (message) containing: • Identity of principal (here, Alice) • Corresponding public key • Timestamp (when issued) • Other information (perhaps identity of signer) signed by trusted authority (Cathy.) CA = { eA || Alice || T } dC Use Bob downloads Alice’s certificate – If he knows Cathy’s public key, he can decipher the certificate • When was certificate issued? • Is the principal Alice? – Now Bob has Alice’s public key. Problem: Bob needs Cathy’s PK to validate cert. – Problem pushed up a level. – Solution: signature chains. Issuers Certification Authority (CA): entity that issues certificates; Cathy, the trusted 3rd party – 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 • Each CA issues certificate for the other CA. Notation: Certificate X issued for Y X<<Y>> Certificate Signature Chains Create certificate: – Generate hash of identification information of requester. – Encipher hash with issuer’s private key. Validate – Obtain issuer’s public key. – Decipher enciphered hash. – Recompute hash from certificate and compare. X.509 (SSL) Certificate Validation Obtain issuer’s public key – The one for the particular signature algorithm Decipher signature – Gives hash of certificate Recompute hash from certificate and compare – If they differ, there’s a problem Check interval of validity – This confirms that certificate is current Pretty Good Privacy (PGP) PGP is the most commonly used email encryption system. Follows OpenPGP standard, so other software like GPG can be used compatibly. Problem: how to distribute public keys to mail recipients while binding the keys to the corresponding identities. PGP Key Distribution Two main techniques: 1. Face-to-face key exchange. 2. Key exchange via a trusted 3rd party. Trusted 3rd party could be 1. Subject of face-to-face key exchange. 2. Verified by another trusted 3rd party. Indirect validation results in Signature chains, where there is a path of digital signatures that one can follow to reach a 3rd party trusted because of face-to-face key exchange. OpenPGP Signature Chains OpenPGP certificates verified via “web of trust” – No hierarchy of CAs to follow like SSL certificates. – Certificates can be signed by multiple parties. OpenPGP certificates structured into packets: – One public key packet. – Zero or more signature packets. – Recipient rates trust level of each signature. Validating Certificates Alice needs to validate Bob’s OpenPGP cert Arrows show signatures – !: Fred,Giselle,Ellen. Self signatures not shown Alice gets Giselle’s cert Jack – Knows Henry slightly, but signature at “casual” trust. Henry Alice gets Ellen’s cert Ellen Irene – Knows Jack, so uses his cert Giselle to validate Ellen’s, then hers to validate Bob’s. Fred Jack<<Ellen>>Ellen<<Bob>> Bob Storing Keys Multi-user or networked systems: attackers may defeat access control mechanisms. 1. Store encrypted key in local system. • Can store in file, database, registry, etc. • Decrypted key resident in memory while in use. 2. Use physical devices like “smart card.” • Smart card performs encryption. • Computer transfers plaintext to card. • Card transfers ciphertext to computer. • Card can be stolen, analyzed to find key. Key Revocation Certificates invalidated before expiration – Usually due to compromised key. – May be due to change in circumstance (e.g., someone leaving company.) Problems – Is entity revoking certificate authorized to do so? – Can revocation information circulates to everyone quickly enough to avoid a compromise? CRLs A Certificate revocation list lists certificates that are revoked, with their IDs and revocation dates.