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<
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<
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.
X.509: only issuer (CA) can revoke certificate.
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. Key Points
1. Key Exchange Protocol 1. Can exchange keys using a trusted 3rd party. 2. Must counter replay attacks. 2. Public Key Cryptography 1. Based on one-way trapdoor functions. 2. Diffie-Hellman Key Exchange w/o trusted 3rd party. 3. Confidentiality: encipher with public, decipher with private 4. Integrity: encipher with private, decipher with public 3. Public Key Infrastructure 1. Manage keys, trust relationships (signature chains). 2. X.509 (SSL) certs use hierarchical system based on CAs. 3. PGP uses web of trust. References
1. Matt Bishop, Introduction to Computer Security, Addison-Wesley, 2005. 2. Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone, Handbook of Applied Cryptography, http://www.cacr.math.uwaterloo.ca/hac/, CRC Press, 1996. 3. Bruce Schneier, Applied Cryptography, 2nd edition, Wiley, 1996. 4. John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.
Released under CC BY-SA 3.0
. This presentation is released under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license . You are free: . to Share — to copy and redistribute the material in any medium . to Adapt— to remix, build, and transform upon the material . to use part or all of this presentation in your own classes . Under the following conditions: . Attribution — You must attribute the work to James Walden, but cannot do so in a way that suggests that he endorses you or your use of these materials. . Share Alike — If you remix, transform, or build upon this material, you must distribute the resulting work under this or a similar open license. . Details and full text of the license can be found at https://creativecommons.org/licenses/by-nc-sa/3.0/