Many information security systems rely on cryptographic schemes that need truly random numbers be secure. In recent months there have been several high profile news stories about weaknesses or potential compromises in both software and hardware random number generators. A compromised random number generator is difficult to catch because it can output random looking data that is predictable to an attacker only. In this talk I describe how to go from knowledge of a weakness in a random number generator to a full security compromise. We will look at examples including how to fully decrypt a TLS stream, how to compromise a bitcoin wallet by looking at the ECDSA signatures on the public block chain, how to factor improperly generated RSA keys, and more. There will be live demos and discussions of interesting ways to pull off these attacks.

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