Who’s right
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Who’s right

  • 349 views
Uploaded on

A presentation I gave as part of my studies on the Research Readings in Information Security course at Glasgow University, covering the recent scare over discovery of a vulnerability in online RSA......

A presentation I gave as part of my studies on the Research Readings in Information Security course at Glasgow University, covering the recent scare over discovery of a vulnerability in online RSA keys.

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
349
On Slideshare
346
From Embeds
3
Number of Embeds
1

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 3

http://www.linkedin.com 3

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Who’s Right? Recently-discoveredVulnerabilities in RSA Keys Robert Dallas Gray 1
  • 2. The Problem‣ 12 February 2012: ‘Ron was Wrong, Whit is Right’ 2
  • 3. The Problem‣ 12 February 2012: ‘Ron was Wrong, Whit is Right’ - A paper by Arjen K Lenstra et al 3
  • 4. The Problem‣ 12 February 2012: ‘Ron was Wrong, Whit is Right’ - A paper by Arjen K Lenstra et al - Found 0.2% of RSA keys ‘offered no security’ - Concluded that generating keys for ‘multiple secret’ cryptosystems is inherently riskier than for ‘single secret’ systems (e.g. ElGamal, DSA) 4
  • 5. The Problem‣ 12 February 2012: ‘Ron was Wrong, Whit is Right’ - A paper by Arjen K Lenstra et al - Found 0.2% of RSA keys ‘offered no security’ - Concluded that generating keys for ‘multiple secret’ cryptosystems is inherently riskier than for ‘single secret’ systems (e.g. ElGamal, DSA) 5
  • 6. The Problem‣ 12 February 2012: ‘Ron was Wrong, Whit is Right’ - A paper by Arjen K Lenstra et al - Found 0.2% of RSA keys ‘offered no security’ - Concluded that generating keys for ‘multiple secret’ cryptosystems is inherently riskier than for ‘single secret’ systems (e.g. ElGamal, DSA) 6
  • 7. The Problem‣ 12 February 2012: ‘Ron was Wrong, Whit is Right’ - A paper by Arjen K Lenstra et al - Found 0.2% of RSA keys ‘offered no security’ - Concluded that generating keys for ‘multiple secret’ cryptosystems is inherently riskier than for ‘single secret’ systems (e.g. ElGamal, DSA) 7
  • 8. What is RSA?‣ RSA is an algorithm for public key cryptography 8
  • 9. What is RSA?‣ RSA is an algorithm for public key cryptography‣ First publicly described by Ron Rivest, Adi Shamir, Leonard Adleman, 1978 9
  • 10. What is RSA?‣ RSA is an algorithm for public key cryptography‣ First publicly described by Ron Rivest, Adi Shamir, Leonard Adleman, 1978‣ Also the name of the security company founded by Rivest, Shamir and Adleman in 1982 10
  • 11. What is RSA?‣ RSA is an algorithm for public key cryptography‣ First publicly described by Ron Rivest, Adi Shamir, Leonard Adleman, 1978‣ Also the name of the security company founded by Rivest, Shamir and Adleman in 1982‣ Acquired in 2006 for $2.1bn 11
  • 12. Public Key Cryptography‣ Each principal has two keys: - One public - One private 12
  • 13. Public Key Cryptography‣ Each principal has two keys: - One public - One private 13
  • 14. Public Key Cryptography‣ Each principal has two keys: - One public - One private‣ Public key crypto can be used to: - Encrypt private conversations 14
  • 15. Public Key Cryptography‣ Each principal has two keys: - One public - One private‣ Public key crypto can be used to: - Encrypt private conversations - Sign messages 15
  • 16. Public Key Cryptography‣ Each principal has two keys: - One public - One private‣ Public key crypto can be used to: - Encrypt private conversations - Sign messages - Authenticate principals 16
  • 17. Encryption‣ Alice sends her public key to BobBob Alice 17
  • 18. Encryption‣ Alice sends her public key to BobBob Alice 18
  • 19. Encryption‣ Alice sends her public key to Bob‣ Bob encrypts a message using Alice’s public keyHello Alice! a3e506b3aa1Bob Alice 19
  • 20. Encryption‣ Alice sends her public key to Bob‣ Bob encrypts a message using Alice’s public key‣ Only Alice’s private key can decrypt the messageHello Alice! a3e506b3aa1Bob Alice 20
  • 21. Encryption‣ Alice sends her public key to Bob‣ Bob encrypts a message using Alice’s public key‣ Only Alice’s private key can decrypt the messageHello Alice! a3e506b3aa1 a3e506b3aa1 Hello Alice!Bob Alice 21
  • 22. Signing‣ Alice sends a plaintext message to Bob Hello Bob!Bob Alice 22
  • 23. Signing‣ Alice sends a plaintext message to Bob - Plus a version of the message encrypted with her private key Hello Bob! b2e3f600d5 Hello Bob!Bob Alice 23
  • 24. Signing‣ Alice sends a plaintext message to Bob - Plus a version of the message encrypted with her private key‣ Bob decrypts the ‘signature’ using Alice’s public key, verifying that it matches the plaintext messageHello Bob! Hello Bob! Hello Bob!Hello Bob! b2e3f600d5 b2e3f600d5 Hello Bob!Bob Alice 24
  • 25. Signing‣ Alice sends a plaintext message to Bob - Plus a version of the message encrypted with her private key‣ Bob decrypts the ‘signature’ using Alice’s public key, verifying that it matches the plaintext message - He can be sure the message came from AliceHello Bob! Hello Bob! Hello Bob!Hello Bob! b2e3f600d5 b2e3f600d5 Hello Bob!Bob Alice 25
  • 26. Authentication‣ Alice creates a certificate containing, e.g., her email address, and her public keyBob Alice 26
  • 27. Authentication‣ Alice creates a certificate containing, e.g., her email address, and her public keyBob Alice @ 27
  • 28. Authentication‣ Alice creates a certificate containing, e.g., her email address, and her public key - She has the certificate signed by a trusted authority (using the trusted authority’s private key)Bob Alice @ 28
  • 29. Authentication‣ Alice creates a certificate containing, e.g., her email address, and her public key - She has the certificate signed by a trusted authority (using the trusted authority’s private key)Bob Alice @ @ 29
  • 30. Authentication‣ Alice creates a certificate containing, e.g., her email address, and her public key - She has the certificate signed by a trusted authority (using the trusted authority’s private key)‣ Bob can decrypt the certificate using the trusted authority’s public keyBob Alice @ @ 30
  • 31. Authentication‣ Alice creates a certificate containing, e.g., her email address, and her public key - She has the certificate signed by a trusted authority (using the trusted authority’s private key)‣ Bob can decrypt the certificate using the trusted authority’s public key - He can be sure that the public key he retrieves belongs to AliceBob Alice @ @ @ 31
  • 32. Practical Uses‣ Public Key Crypto is calculation-intensive - So it’s not generally used to encrypt full conversations 32
  • 33. Practical Uses‣ Public Key Crypto is calculation-intensive - So it’s not generally used to encrypt full conversations - It’s used for authentication 33
  • 34. Practical Uses‣ Public Key Crypto is calculation-intensive - So it’s not generally used to encrypt full conversations - It’s used for authentication - And to encrypt ‘handshake’ procedures – during which the encryption for the full conversation is negotiated between principals 34
  • 35. Practical Uses‣ Public Key Crypto is calculation-intensive - So it’s not generally used to encrypt full conversations - It’s used for authentication - And to encrypt ‘handshake’ procedures – during which the encryption for the full conversation is negotiated between principals - For example, to authenticate chip-and-pin cards - In this case the issuer is the trusted third party 35
  • 36. Practical Uses‣ TLS or SSL - Transport Layer Security (new) or Secure Sockets Layer 36
  • 37. Practical Uses‣ TLS or SSL - Transport Layer Security (new) or Secure Sockets Layer - Allows secure communication between applications 37
  • 38. Practical Uses‣ TLS or SSL - Transport Layer Security (new) or Secure Sockets Layer - Allows secure communication between applications - Typically a web browser (client) to a hosted application or server 38
  • 39. Practical Uses‣ TLS or SSL - Transport Layer Security (new) or Secure Sockets Layer - Allows secure communication between applications - Typically a web browser (client) to a hosted applications or server 39
  • 40. Practical Uses‣ TLS or SSL - Transport Layer Security (new) or Secure Sockets Layer - Allows secure communication between applications - Typically a web browser (client) to a hosted applications or server 40
  • 41. Practical Uses‣ TLS or SSL - Transport Layer Security (new) or Secure Sockets Layer - Allows secure communication between applications - Typically a web browser (client) to a hosted applications or server 41
  • 42. How SSL/TLS Works‣ Client is presented with a certificate, issued by a trusted authority - Certificate verifies site name, email address or DNS entry - Binds this to a public key‣ Client can then be sure the given public key belongs to the intended server‣ Client can use public key to encrypt negotiation of a shared key to encrypt session traffic 42
  • 43. X.509 CertificateCertificate: Data: Version: 1 (0x0) Serial Number: 7829 (0x1e95) Signature Algorithm: md5WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com Validity Not Before: Jul 9 16:04:02 1998 GMT Not After : Jul 9 16:04:02 1999 GMT Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb: 33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1: 66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66: 70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17: 16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b: c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77: 8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3: d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8: e8:35:1c:9e:27:52:7e:41:8f Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption 93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d: 92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92: ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67: d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72: 0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1: 5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7: 8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22: 68:9f 43
  • 44. X.509 CertificateCertificate: Data: Version: 1 (0x0) Serial Number: 7829 (0x1e95) Signature Algorithm: md5WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com Validity Not Before: Jul 9 16:04:02 1998 GMT Not After : Jul 9 16:04:02 1999 GMT Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb: 33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1: 66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66: 70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17: 16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b: c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77: 8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3: d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8: e8:35:1c:9e:27:52:7e:41:8f Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption 93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d: 92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92: ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67: d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72: 0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1: 5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7: 8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22: 68:9f 44
  • 45. How does RSA work?‣ Requirements for public key crypto: 45
  • 46. How does RSA work?‣ Requirements for public key crypto: - If a message is encrypted with one key, the other key must decrypt it 46
  • 47. How does RSA work?‣ Requirements for public key crypto: - If a message is encrypted with one key, the other key must decrypt it - The private key MUST NOT be discoverable from knowledge of the public key 47
  • 48. Nuts and Bolts‣ Alice chooses two large prime numbers p, q 48
  • 49. Nuts and Bolts‣ Alice chooses two large prime numbers p, q‣ She creates the modulus for the public key by multiplying p by q: - n=p×q 49
  • 50. Nuts and Bolts‣ Alice chooses two large prime numbers p, q‣ She creates the modulus for the public key by multiplying p by q: - n=p×q‣ She applies a function to n to create a new number, k - The function is Euler’s Totient Function - It counts the number of positive integers <= n that are relatively prime to n - Relatively prime numbers share no common factors other than 1 50
  • 51. Nuts and Bolts‣ Alice chooses two large prime numbers p, q‣ She creates the modulus for the public key by multiplying p by q: - n=p×q‣ She applies a function to n to create a new number, k - The function is Euler’s Totient Function - It counts the number of positive integers <= n that are relatively prime to n - Relatively prime numbers share no common factors other than 1‣ She finds two numbers e, d such that e × d % k = 1 51
  • 52. Nuts and Bolts‣ Alice’s public key is composed of: n (the modulus) and e (the exponent) 52
  • 53. Nuts and Bolts‣ Alice’s public key is composed of: n (the modulus) and e (the exponent)‣ Her private key is d 53
  • 54. Nuts and Bolts‣ Alice’s public key is composed of: n (the modulus) and e (the exponent)‣ Her private key is d‣ A message m can be encrypted by raising it to the power e and taking the result modulo n. - m_enc = me % n 54
  • 55. Nuts and Bolts‣ Alice’s public key is composed of: n (the modulus) and e (the exponent)‣ Her private key is d‣ A message m can be encrypted by raising it to the power e and taking the result modulo n. - m_enc = me % n‣ It can be decrypted by raising it to the power d and taking the result modulo n. - m_dec = m_encd % n 55
  • 56. Summary‣ Both public and private keys depend on the two large primes p, q‣ The security of RSA depends on the difficulty of recovering these two numbers once they have been multiplied together (factoring)‣ If p and q can be found from a public key, the private key can be reconstructed and security is lost 56
  • 57. ‘Ron was Wrong, Whit is Right’‣ The researchers collected about 6.4m RSA public keys from the web - Sources: X.509 certificates, PGP keys 57
  • 58. ‘Ron was Wrong, Whit is Right’‣ The researchers collected about 6.4m RSA public keys from the web - Sources: X.509 certificates, PGP keys‣ About 71,000 moduli occurred more than once - Some thousands of times 58
  • 59. ‘Ron was Wrong, Whit is Right’‣ The researchers collected about 6.4m RSA public keys from the web - Sources: X.509 certificates, PGP keys‣ About 71,000 moduli occurred more than once - Some thousands of times‣ About 13,000 moduli ‘offer no security’ - The private keys can be recovered by anyone who can replicate the researchers’ work 59
  • 60. ‘Ron was Wrong, Whit is Right’‣ The researchers collected about 6.4m RSA public keys from the web - Sources: X.509 certificates, PGP keys‣ About 71,000 moduli occurred more than once - Some thousands of times‣ About 13,000 moduli ‘offer no security’ - The private keys can be recovered by anyone who can replicate the researchers’ work‣ The loss of security affects about 21,000 X.509 certificates and PGP keys - Of which about a quarter are probably still in use 60
  • 61. Conclusion‣ RSA ‘provides 99.8% security at best’ 61
  • 62. How were the keys broken?‣ Euclid’s algorithm - An efficient method of computing the greatest common divisor (gcd) of two numbers 62
  • 63. How were the keys broken?‣ Euclid’s algorithm - An efficient method of computing the greatest common divisor (gcd) of two numbers‣ The researchers ran the algorithm on all pairs of moduli 63
  • 64. How were the keys broken?‣ Euclid’s algorithm - An efficient method of computing the greatest common divisor (gcd) of two numbers‣ The researchers ran the algorithm on all pairs of moduli - The vulnerable moduli shared a common factor - Knowledge of that factor allowed calculation of the other prime factor 64
  • 65. Nuts and Bolts‣ n1 = p1 × q1 65
  • 66. Nuts and Bolts‣ n1 = p1 × q1 n2 = p2 × q2 66
  • 67. Nuts and Bolts‣ n1 = p1 × q1 n2 = p2 × q2 - Moduli n1 and n2 are each composed of two unknown prime numbers 67
  • 68. Nuts and Bolts‣ n1 = p1 × q1 n2 = p2 × q2 - Moduli n1 and n2 are each composed of two unknown prime numbers‣ gcd(n1, n2) = p - If the greatest common divisor of n1 and n2 is > 1, we know p1 = p2 = p 68
  • 69. Nuts and Bolts‣ n1 = p1 × q1 n2 = p2 × q2 - Moduli n1 and n2 are each composed of two unknown prime numbers‣ gcd(n1, n2) = p - If the greatest common divisor of n1 and n2 is > 1, we know p1 = p2 = p‣ If we know p … 69
  • 70. Nuts and Bolts‣ n1 = p1 × q1 n2 = p2 × q2 - Moduli n1 and n2 are each composed of two unknown prime numbers‣ gcd(n1, n2) = p - If the greatest common divisor of n1 and n2 is > 1, we know p1 = p2 = p‣ If we know p … - We can calculate q1 AND q2 - We can now reconstruct the private keys for moduli n1 and n2 70
  • 71. Conclusion, revisited‣ The researchers claim that the use of ‘multiple secrets’ in RSA is a design problem - Because RSA needs two secret prime numbers, if factors are shared, all keys sharing a factor are vulnerable to factorisation‣ Other systems only need one secret number - It is easier to choose one secure secret than to choose two - If two keys are shared, only those two are affected 71
  • 72. Reactions‣ Dan Kaminsky: - ‘Survey is good. Thesis is strange’ - The data is instructive, but demonstrates an implementation problem, not a design problem 72
  • 73. Reactions‣ Bruce Schneier: - ‘The cause of this is almost certainly a lousy random number generator’ - Design and testing of RNGs is hard - Could some RNGs have been deliberately compromised? 73
  • 74. Reactions‣ Lenstra et al claim ‘single-secret’ algorithms like Diffie-Hellman are more secure – ‘Whit is right’. - At the 2012 RSA Security Conference, Whit and Ron discussed the issue - Whit (Diffie) said the problem could be just ‘one random number generator’ and suggested ‘outing’ it - Ron (Rivest) conceded that he was ‘sometimes wrong’, but that there ‘wasn’t really much substance’ to the paper 74
  • 75. Design vs Implementation‣ Users of RSA need to ensure that random number generation is done properly - According to Schneier, RNG is ‘hard’‣ Other cryptosystems would also be affected by poor random number generation - But RSA may be more vulnerable owing to its ‘multiple secret’ design 75
  • 76. Design vs Implementation‣ Users of RSA need to ensure that random number generation is done properly - According to Schneier, RNG is ‘hard’‣ Other cryptosystems would also be affected by poor random number generation - But RSA may be more vulnerable owing to its ‘multiple secret’ design‣ Can an implementation problem which allows users to render the system insecure be considered a design problem? 76
  • 77. Epilogue‣ February 15 2012: New research released 77
  • 78. Epilogue‣ February 15 2012: New research released‣ Paper by Heninger, Durumeric, Wustrow Halderman is awaiting responses from concerned parties before publication‣ Researchers were able to compromise 0.4% of harvested RSA keys 78
  • 79. Epilogue‣ February 15 2012: New research released‣ Paper by Heninger, Durumeric, Wustrow Halderman is awaiting responses from concerned parties before publication‣ Researchers were able to compromise 0.4% of harvested RSA keys‣ But affected servers were almost all embedded devices – routers, firewalls, VPN devices, etc. - Keys would be used for internal IPSec or SSH 79
  • 80. Epilogue‣ Around 200,000 devices probably compromised – possibly whole classes of device - Keys are probably generated on device startup, introducing RNG issues (same seed used for many devices)‣ The data surveyed is probably essentially the same as Lenstra et al’s - Secure web servers are probably not affected by the vulnerability 80
  • 81. Who’s Right?‣ Questions? 81