Sullivan randomness-infiltrate 2014

Exploiting RandomnessSome fun exploits you can do with a compromised random number generator

Nick Sullivan @grittygrease May 16, 2014

Who Am I?• Cryptography Engineer, Security Researcher

• Lead the CloudFlare Security Engineering Team

• Work with Cryptography at scale

• Builder and Breaker

2

Randomness

3

Randomness• What is randomness?

• Why is randomness important?

• How bad randomness can destroy a computer security system

4

Randomness• Broken random number generator is very problematic

!

• This talk demos attacks on:

• Bitcoin

• TLS/SSL

5

Randomness• Random number generators can be compromised in multiple ways

!

• Explicit subversion

• Algorithmic weakness

• Poor seeding

!

• All three are exploitable

6

The Internet is broken

7

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

A trying year• Events since June 2013 exposed fragility

• Threats moved from theoretical to concrete

• Opinions of the “paranoid” are now mainstream

9

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

Dual_EC_DRBG

11

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

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

Dual_EC_DRBG• Internal state is entirely dependent on the seed

14

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

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

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

Intel RDRAND

18

Intel RDRAND• IvyBridge and later random number generator — in hardware

• Designed to be fast

• Has an AES-based “whitening” step at the end

19

Intel RDRAND

20

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

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

Intel RDRAND - takeaways• Randomness can come from hardware

• Should be mixed with other sources

• Looking at randomness does not reveal backdoors

23

A bit about entropy

24

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

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

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

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

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

A bit about entropy• Independent entropy is additive

• RDRAND is ok to mix in, it can only increase randomness

30

The Digital Signature Algorithm (DSA)

31

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

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

The Digital Signature Algorithm (DSA)• Core complaint: DSA and ECDSA require cryptographic randomness

• Repeated signature with same random value reveal the private key

34

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

The Digital Signature Algorithm (DSA)• Any known k

• Extract private key

• Any repeated k with same private key

• Extract k

36

The Digital Signature Algorithm (DSA)• The Math

37

The Digital Signature Algorithm (DSA)• The Math

38

The Digital Signature Algorithm (DSA)• Breaking DSA

39

Bitcoin

40

Bitcoin• Fundamental security based on ECDSA

• Public key hash is your Bitcoin address

• Private key allows you to spend

• ECDSA signature proves transaction

41

Bitcoin• OP_CHECKSIG

• Verify that a payment was made

42

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

Bitcoin• Demo

• /fun -hash1="270666214c4a9654e2b0c40cbe6e57331ab2d8034f8c648944d5d3c7550b46dc" -sig1="4830450221009ac20335eb38768d2052be1dbbc3c8f6178407458e51e6b4ad22f1d91758895b02201b0d10a717ffccbfe5483bb7aa1cdcdc2a4e8775c706aaeddbcbfd55df190dd5012103ffffc29d98bf4eec11e6948387bdf5928848dca7b83bfde8e0e627e66c706576" -hash2="9bc17698be66f12460b7d7f87e47e1bbc03203194d0cf539ca9b862b23742b0a" -sig2="4830450221009ac20335eb38768d2052be1dbbc3c8f6178407458e51e6b4ad22f1d91758895b0220507b798addf5097c11fb4ed40518b2c3e468feb3d09a1fea837cf9d16ae25ef6012103ffffc29d98bf4eec11e6948387bdf5928848dca7b83bfde8e0e627e66c706576"

44

Other DSA risks• VPN signatures

• IPSec uses DSA, ECDSA

• OpenVPN

• SSH keys

• Secure boot chain

• low entropy boot environments

• Codesigning keys

45

Symptoms of DSA break• Look at the R value

• Repeating R means your key is compromised

46

RSA

47

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

RSA• Taiwanese government id: each person has a unique RSA key

49

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

RSA• They found that some even had recognizable patterns

51

RSA• Result of bad entropy initialization, bad RNG

• No Demo, https://factorable.net covers it

52

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

RSA• What are the symptoms?

• No symptoms, totally passive

• Where can you harvest public keys?

• Scan the internet

• PGP lists - keybase.io?

54

TLS

55

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

Handshake• Breakdown of RSA handshake

!

• Random from client

• Decryption from server

57

Handshake• Breakdown of DHE handshake

!

• Random from Client

• Random from Server

58

DH on the wire• Client sends aG

• Server sends bG

• Pre-master secret is abG

59

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

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

Vectors of attack

62

Vectors of attack

63

Application

Userland

Kernel timing

CSPRNG

Hypervisor RDRAND

/dev/random

sharedlib

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

More examples from history• RSA

• Debian RNG

• ECDSA

• Sony Playstation 2

• Android Wallet

• Examples: iOS 7.0 bootloader RNG — change BIOS

65

More targets• Other things that depend on good RNG

!

• Session cookies

• Kaminsky’s DNS poisoning attack mitigation

• Suite B - ECDSA Certificate Authorities

66

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

Exploiting RandomnessSome fun exploits you can do with a compromised random number generator

Nick Sullivan @grittygrease May 16, 2014