Sullivan randomness-infiltrate 2014
1 like983 views
Nick Sullivan's presentation discusses the vulnerabilities and exploits related to compromised random number generators, which can severely undermine computer security systems such as Bitcoin and TLS/SSL. He highlights various forms of RNG compromise, including algorithmic weaknesses and poor seeding, and emphasizes the critical role of cryptographic randomness in ensuring security. The talk also covers several notable examples and risks associated with cryptosystems dependent on RNG, urging a collective recognition of this issue within the security community.
Sullivan randomness-infiltrate 2014
- 1. Nick Sullivan @grittygrease May 16, 2014 Exploiting Randomness Some fun exploits you can do with a compromised random number generator
- 2. Who Am I? • Cryptography Engineer, Security Researcher • Lead the CloudFlare Security Engineering Team • Work with Cryptography at scale • Builder and Breaker 2
- 3. Randomness 3
- 4. Randomness • What is randomness? • Why is randomness important? • How bad randomness can destroy a computer security system 4
- 5. Randomness • Broken random number generator is very problematic ! • This talk demos attacks on: • Bitcoin • TLS/SSL 5
- 6. Randomness • Random number generators can be compromised in multiple ways ! • Explicit subversion • Algorithmic weakness • Poor seeding ! • All three are exploitable 6
- 7. The Internet is broken 7
- 8. The Internet is broken • A failure of trust at scale • Slow adoption by community of new standards • DNSSEC • Perfect Forward Secrecy • Fundamental parts of it are broken • Revocation — as shown by Heartbleed vulnerability 8
- 9. A trying year • Events since June 2013 exposed fragility • Threats moved from theoretical to concrete • Opinions of the “paranoid” are now mainstream 9
- 10. Leaked documents • Purported attempts to subvert public standards and open source projects • Subversion of random number generation • I can talk about this since I was never involved 10
- 11. Dual_EC_DRBG 11
- 12. Dual_EC_DRBG • It was reported that RSA took 10 million to make Dual_EC_DRBG default in BSAFE in 2004 • Removed as default in 2013 12
- 13. Dual_EC_DRBG • Clumsy, slow random number generator based on elliptic curves • Came with two “random” starting points • Missed opportunity(?) if they are random • Starting points can be chosen such that creator has a back door • Patented by Vanstone and Brown (2005) • 32 bytes of data reveal entire stream 13
- 14. Dual_EC_DRBG • Internal state is entirely dependent on the seed 14
- 15. Dual_EC_DRBG • TLS client hello only reveals 28 bytes of random • RSA implemented non-standard “extended random” TLS extension • Reveals the full 32 bytes of consecutive data required 15
- 16. Dual_EC_DRBG • “On the Practical Exploitability of Dual EC in TLS Implementations” - 2014 • Lange, Bernstein, Green, et al. • Looked into OpenSSL-FIPS, SChannel, BSAFE, used trojaned points ! • Findings • TLS for each are fingerprintable • TLS session key in seconds to hours of computation — passively 16
- 17. Dual_EC_DRBG - Takeaways • Many protocols include random values (nonces, IVs, session ids, etc.) • Internal state can be recovered with this data • All future random can be derived from internal state 17
- 18. Intel RDRAND 18
- 19. Intel RDRAND • IvyBridge and later random number generator — in hardware • Designed to be fast • Has an AES-based “whitening” step at the end 19
- 20. Intel RDRAND 20
- 21. Intel RDRAND • Exploitability: it’s a hardware instruction • Virtualized environments - override from hypervisor • Microcode updates ! • Verifiability • Designers have not looked at production chips in Haswell • Is there a backdoor in silicon? Hard to tell. 21
- 22. Intel RDRAND • FreeBSD and Linux patched to make RDRAND sole source of entropy • Eventually patches were blocked or reverted • Linux now mixes RDRAND into /dev/random ! • What motivated these patches? 22
- 23. Intel RDRAND - takeaways • Randomness can come from hardware • Should be mixed with other sources • Looking at randomness does not reveal backdoors 23
- 24. A bit about entropy 24
- 25. A bit about entropy • Why is RDRAND dangerous on its own, but ok to mix? ! • Statistical randomness is not enough • Cryptographic randomness needs • To be unpredictable • To have high entropy 25
- 26. A bit about entropy • Entropy is the amount of information contained in a sequence of numbers • If you know the sequence, it is predictable ! • The digits of pi are statistically random, but are predictable • The entropy is equivalent to the definition: “ratio of circumference to diameter of a circle” • This sentence only needs a few bytes to express 26
- 27. A bit about entropy • Entropy is in the eyes of the beholder • Known information takes away from the entropy • Digits of pi have high entropy to someone who doesn’t know math ! • The NIST random beacon is not cryptographic randomness • Generated with high entropy process, but disclosed to the world 27
- 28. A bit about entropy • Encrypted the digits of pi with a 128 bit AES key • Tell the world that’s what it is ! • The entropy to you is low • The entropy to the world is 128 bit 28
- 29. A bit about entropy • Same with Dual_EC_DRBG • Say P = nQ • The relationship between P & Q can be computed by solving ECDLP • That takes ~2^128 computations • The entropy to the world is 128 bits • The entropy to whoever knows n (the creator) is almost zero given 32 consecutive bytes 29
- 30. A bit about entropy • Independent entropy is additive • RDRAND is ok to mix in, it can only increase randomness 30
- 31. The Digital Signature Algorithm (DSA) 31
- 32. The Digital Signature Algorithm (DSA) • Public Key cryptography primitive proposed in 1991 • Allows the owner of a private key to sign hash of a message • The public key is used to verify the signature 32
- 33. The Digital Signature Algorithm (DSA) • Where is it used? Everywhere. • What kind of key is your ssh key? • ECDSA: elliptic curve variant used in TLS, bitcoin 33
- 34. The Digital Signature Algorithm (DSA) • Core complaint: DSA and ECDSA require cryptographic randomness • Repeated signature with same random value reveal the private key 34
- 35. The Digital Signature Algorithm (DSA) • Signature • Pick a random k • Convolute k with private key and hash of message • Publish R, S ! • Solve DLP on R -> k 35
- 36. The Digital Signature Algorithm (DSA) • Any known k • Extract private key • Any repeated k with same private key • Extract k 36
- 37. The Digital Signature Algorithm (DSA) • The Math 37
- 38. The Digital Signature Algorithm (DSA) • The Math 38
- 39. The Digital Signature Algorithm (DSA) • Breaking DSA 39
- 40. Bitcoin 40
- 41. Bitcoin • Fundamental security based on ECDSA • Public key hash is your Bitcoin address • Private key allows you to spend • ECDSA signature proves transaction 41
- 42. Bitcoin • OP_CHECKSIG • Verify that a payment was made 42
- 43. Bitcoin • Two transactions by same Bitcoin address with same random value k ! • Signature includes S, R • R = kG, where G is base point • If R1 = R1, most likely the same k was used 43
- 44. Bitcoin • Demo • /fun - hash1="270666214c4a9654e2b0c40cbe6e57331ab2d8034f8c648944d5d3c7550b46dc" - sig1="4830450221009ac20335eb38768d2052be1dbbc3c8f6178407458e51e6b4ad22f1d 91758895b02201b0d10a717ffccbfe5483bb7aa1cdcdc2a4e8775c706aaeddbcbfd55df190 dd5012103ffffc29d98bf4eec11e6948387bdf5928848dca7b83bfde8e0e627e66c706576" - hash2="9bc17698be66f12460b7d7f87e47e1bbc03203194d0cf539ca9b862b23742b0a" - sig2="4830450221009ac20335eb38768d2052be1dbbc3c8f6178407458e51e6b4ad22f1d 91758895b0220507b798addf5097c11fb4ed40518b2c3e468feb3d09a1fea837cf9d16ae2 5ef6012103ffffc29d98bf4eec11e6948387bdf5928848dca7b83bfde8e0e627e66c706576" 44
- 45. Other DSA risks • VPN signatures • IPSec uses DSA, ECDSA • OpenVPN • SSH keys • Secure boot chain • low entropy boot environments • Codesigning keys 45
- 46. Symptoms of DSA break • Look at the R value • Repeating R means your key is compromised 46
- 47. RSA 47
- 48. RSA • Public Key Cryptosystem • Basis of the Public Key Infrastructure • Security is based on strength of factoring large numbers ! • RSA modulus N has two factors P & Q • RSA key pairs created by randomly generating P & Q 48
- 49. RSA • Taiwanese government id: each person has a unique RSA key 49
- 50. RSA • Factoring P*Q is hard • Factoring P*Q and P*R is easy: Chinese remainder theorem • You can also find the GCD of a large number of numbers ! • Factoring RSA keys from certified smart cards: Coppersmith in the wild - 2013 • This is exactly what Bernstein, Heninger, Lange did 50
- 51. RSA • They found that some even had recognizable patterns 51
- 52. RSA • Result of bad entropy initialization, bad RNG • No Demo, https://factorable.net covers it 52
- 53. RSA • Need to attack before keys are created • Bootloading, early execution vulnerable to weak PRNG • TrueCrypt? GnuPG? Probably. • Rely on system to generate RSA keys • Routers and embedded devices - ephemeral RSA keys 53
- 54. RSA • What are the symptoms? • No symptoms, totally passive • Where can you harvest public keys? • Scan the internet • PGP lists - keybase.io? 54
- 55. TLS 55
- 56. TLS • The crown jewel of Internet encryption is SSL/TLS • Breaking this removes privacy on the internet • I will demonstrate one attack and point out two others 56
- 57. Handshake • Breakdown of RSA handshake ! • Random from client • Decryption from server 57
- 58. Handshake • Breakdown of DHE handshake ! • Random from Client • Random from Server 58
- 59. DH on the wire • Client sends aG • Server sends bG • Pre-master secret is abG 59
- 60. Perfect Secrecy • RSA is vulnerable to client randomness bugs — session key leak • ECDSA is vulnerable to server randomness bugs — private key leak • DH is vulnerable to both client and server randomness bugs 60
- 61. TLS • Demo • node.js server with a modified OpenSSL binding for the RNG • Do a handshake • Measure it, steal DH private key, decrypt stream 61
- 62. Vectors of attack 62
- 63. Vectors of attack 63 Application Userland CSPRNG sharedlib /dev/random Kernel timing Hypervisor RDRAND
- 64. How to exploit more generally • Override RDRAND in hypervisor • Other protocols: OpenVPN, IPSec • Where to find randomness for context: nonces, IVs • Trojan the OS image — /dev/random or system openssl • Extracting RNG state through remote memory disclosure: heartbleed 64
- 65. More examples from history • RSA • Debian RNG • ECDSA • Sony Playstation 2 • Android Wallet • Examples: iOS 7.0 bootloader RNG — change BIOS 65
- 66. More targets • Other things that depend on good RNG ! • Session cookies • Kaminsky’s DNS poisoning attack mitigation • Suite B - ECDSA Certificate Authorities 66
- 67. Conclusion • Randomness is important • Subverting PRNG • Can be done in different layers • Very hard to detect • Exploit bugs in PRNG • Repeated random breaks DSA 67
- 68. Nick Sullivan @grittygrease May 16, 2014 Exploiting Randomness Some fun exploits you can do with a compromised random number generator