CS 6324: Information Security More Info on Key Establishment: RSA, DH & QKD

Transcription

1 ERIK JONSSON SCHOOL OF ENGINEERING & COMPUTER SCIENCE Cyber Security Research and Education Institute CS 6324: Information Security Dr. Junia Valente Department of Computer Science The University of Texas at Dallas contains material from: Dr. Alvaro Cardenas February 12,

2 Announcement: - Watch video (about crypto APIs): - Quiz next Tuesday, February 19 th based on the contents of this video. February 12, February 12,

3 Outline ² RSA & DH - KEY ESTABLISHMENT ² Quantum ² Summary February 12, February 12,

4 More Details on RSA - RSA algorithm > Involves four steps: generation of keys, key distribution, encryption, decryption - based on the difficulty of factoring integers Let s see more details now! February 12, February 12,

5 RSA - Rivest, Shamir, Adleman 1977 Steps for generating the keys 1) Select two distinct prime numbers:! and " A prime number is one that is only divisible by 1 and by itself: 2, 3, 5, 7, 11, 13, 2) Calculate the product of them: # =! " 3) Calculate the Totient of #: & ' =! ) " )!, ", and & ' are kept private 4) Choose an integer * such that ) < * < & ' and * and & ' are coprime. Coprime numbers do not share any other factors except for 1, i.e., 670 8, & ' = ) 5) Calculate the value of +: +, * )./0 & ' or + = * 1) mod & ' Using Extended Euclidean algorithm + is kept private February 12, February 12,

6 RSA - Rivest, Shamir, Adleman 1977 Steps for generating the keys The security of RSA is based on the difficulty of factoring two large prime numbers. Note:! " = $ & ' & Easy to compute! " if you know the factorization of " Hard to compute! " if you do not know the factorization of " Theorem: If () & +,-! " then /, / 1 - / +,- ". February 12, February 12,

7 Vanilla (insecure) RSA Summary Key generation algorithm: 1. Choose random primes! and " 2. Define # =! " and & ' =! ) " ) 3. Compute * and + such that +, * )./0 & '. (e.g., * = 1, 17, 65537) Assuming we calculated:!, ", ', & ', 8, 0. Then, public key = (', 8) and private key = (', 0) Encryption algorithm: *<=>?@A( ', 8, B) =. 8./0 ' Decryption algorithm: +*=>?@A( ', 0, =) = C 0./0 ' Vanilla RSA is insecure! Because it is deterministic: the same message has the same ciphertext. Recommendation: RSA- OAEP and RSA-KEM. February 12, February 12,

8 RSA Example: Key Generation 1. Choose two random primes:! = #$ and % = $& 2. Compute ' =! % = #$ $& = )))$ 3. Compute * + =! & % & = #- $. = )//. 4. Select 0 = ) (such that & < 1 < )//. and 234 0, * + = &) 5. Compute 6 = 1 7& mod * + 6 = ) 7& mod )//. 6 = 2147 public key = +, 0 = ()))$, )) private key = +, 4 = ()))$, /&#$) Note: Everyone knows N but it is difficult to compute * + and derive the secret key February 12, February 12,

9 RSA Example: Encryption & decryption public key =!, # = (&&&', &) private key =!, ) = &&&', *+,' Let s encrypt m = 688 If we want to decrypt: - =. #./)! - = 011 &./) &&&' - = 2842 m = - )./)! m = *1,* *+,'./) &&&' m = 688 Hint: Feel free to use an online tool (e.g., Wolfram Alpha) to calculate the modular exponentiation. February 12, February 12,

10 Key Distribution Problem: Key-Exchange in TLS using RSA A Browser C Give me your certificate VeriSign certificate Public key Encrypt one-time key with server s public key $%jilwd Encrypted shopping fhwh$%... Amazon.com B Both the browser and server have their key pair. The browser generates a premaster key, and encrypts using the server s public key (after verifying the signature in the certificate binding a public key with the server s identity). C Both the browser and server use the premaster key to generate additional keys, e.g., keys for symmetric encryption and MAC. A B February 12, February 12,

11 Forward secrecy Limitation with RSA key transport We want Forward Secrecy (aka Perfect Forward Secrecy): - (Past) session keys should remain secret even if the adversary compromises the long-term key(s) (e.g., secret key) of the parties. As we saw last class, when we use RSA for establishing keys between two parties it does not provide forward secrecy. Example: If an attacker records all messages exchanged and in the future obtains B s secret key (e.g., compromises a server), then it can extract the premaster secret and obtain old session keys (and decrypt old encrypted traffic). We can achieve forward secrecy using Diffie-Hellman Key Exchange protocol February 12, February 12,

12 Diffie-Hellman Protocol: Key-Exchange using DH Based on the assumption that it is hard to compute the discrete logarithm Given!, where! = # $ %&' ( - It is assumed to be computationally intractable to obtain $ from! - for large random primes ( February 12, February 12,

13 Diffie-Hellman Protocol: Key-Exchange using DH Key generation algorithm: Two parties agree on! and " (public info) where! is a large prime (e.g., 600 digits) and " Is an integer in {1,,!}. Alice chooses a random # in {1,,! - 1} and calculate $ = " # &'(! A Alice, $ "# &'(! Bob, * " ) &'(! B Bob chooses a random ) in {1,,! - 1} and calculate * = " ) &'(! * Only Alice knows about #, and only Bob knows about ). February 12, February 12,

14 Diffie-Hellman Protocol: Key-Exchange using DH Key generation algorithm: To generate the key! "# : * Only Alice knows about &, and only Bob knows about +. A Alice, " %& '() * B Bob, # % + '() * Alice calculates! "# using: # & Bob calculates! "# using: " + # & = (% + ) & =! "# = % &+ = (% & ) + = " + February 12, February 12,

15 Diffie-Hellman Protocol: Insecure against man-in-the-middle 6, -) = ) $ =# $ + A 1 7 chooses random $! # $ %&' ( ) # + %&' ( 2 6 chooses $ MiTM chooses + 3 5! # $ %&' ( 4 ) # + %&' (, -) =! + =# $ + B chooses random + 8, -! = ) $ =(# + ) $ = # $+ 9, -! =! + =# $+ The attacker relays traffic from Alice to Bob; and reads it in the clear. February 12, February 12,

16 Diffie-Hellman Protocol: Key-Exchange using DH Original: public info: +, # * Only Alice knows about $, and only Bob knows about &. A '!% = (# & ) $! # $ % # & B '!% = (# $ ) & Modify to solve DH problem (example): public info: +' %, +, #, +'! Assume A & B have,'!! # $,' % public key pairs: A B - A has +'!,,'! Verify signature - B has +' % # &,,-# % (# &, # $,!) %,,' % using +' %,-#! (# $, # &, %) Verify signature using +'! February 12, February 12,

17 Diffie-Hellman Protocol: To prevent MITM attacks, we need Authenticated Diffie-Hellman - Add signatures / MACs and nonces to Diffie-Hellman protocol - Achieves forward secrecy (Ephemeral DH) Make sure! and " are randomly selected every time February 12, February 12,

18 Outline ² RSA & DH - Key Establishment ² QUANTUM ² Summary February 12, February 12,

19 Key Distribution So Far: How do parties agree on a symmetric key? - Using only symmetric key primitives e.g., use a Key Distribution Center (KDC) like Kerberos - Using asymmetric key concepts: RSA key transport, or DHE - Sometimes use: Quantum Key Distribution - enables two parties to produce a shared random key, only known to them - uses components of quantum mechanics February 12, February 12,

20 Requires two channels between Alice and Bob: Quantum Key Distribution (QKD) is only used to produce & distribute a key We assume an eavesdropper (Eve) can interfere in any way with the quantum channel. We can then use the key with any encryption algorithm to securely transmit a message February 12, February 12,

21 Quantum Channel: - Key is a stream of photons or light - Polarization of photons (states): horizontal, vertical, and two diagonals (angle of +45 or -45 ) - Filters: can distinguish horizontal states from vertical ones, and +45 from Photons have a property called spin and can change when passed through a filter February 12, February 12,

22 Translating a photon spin into a key: Idea: If Alice wants to send: , she can send: Or: She selects a basis (filter) to send the photons February 12, February 12,

23 Quantum Key Distribution: General idea States cannot be measured without disturbing the original state We have a linear polarization basis (+) and a diagonal basis (x) Alice and Bob communicate over the public channel and both disclose the basis they used. Then, they both discard measurements where Bob used a different basis. February 12, February 12,

24 Quantum Channel: February 12, February 12,

25 Note: In addition to Quantum Key Distribution (QKD), there is also another topic called Quantum Computers. February 12, February 12,

26 Quantum Computer: (Breaking Crypto?) - Can solve the factoring problem (using Shor s algorithm) and the discrete logarithm problem - Potential to break RSA, ECC, ElGamal, etc. - Not clear if they can scale, plus new research says if the RSA key is long enough (a terabyte-size key) it might not be broken. February 12, February 12,

27 NSA warning: To move away from crypto vulnerable to quantum computing February 12,

28 NSA warning: Recommendations February 12, February 12,

29 NSA warning: Do they know something we don t? February 12,

30 NSA warning: Mitigations February 12, February 12,

31 Outline ² RSA & DH - Key Establishment ² Quantum ² SUMMARY February 12, February 12,

32 Crypto Warnings: Crypto appears deceptively simple - Why does it so often fail? Important to distinguish various issues: 1. Bad cryptography, bad implementations, bad design, etc. 2. Even good cryptography can often be circumvented by adversaries operation outside the model 3. Even the best cryptography only shifts the weakest point of failure to elsewhere in your system 4. Systems are complex Avoid the first, be aware of 2-4 February 12, February 12,

33 Limitations of cryptography: Cryptography is a tremendous tool And the basis for many security mechanisms Most security problems are not crypto problems In general, crypto - is not the solution to all security problems - is not reliable unless implemented properly - is not reliable unless used properly Misuse of crypto is fatal for security February 12, February 12,

34 Crypto Libraries: Some recommendations - Use existing, high-level crypto libraries Watch video (about crypto APIs): - cryptlib - NaCl Quiz next Tuesday, February 19 th - KeyCzar (designed for usability) based on the contents of this video. - libsodium - These provide an appropriate interface to crypto algorithms - Avoid low-level libraries, i.e., Java Cryptography Extension (JCE) too much possibility for misuse - Avoid writing your own low-level crypto. February 12, February 12,