Kristjan Kelt. Survey of random number generators on various platforms

Transcription

1 Kristjan Kelt Survey of random number generators on various platforms University of Luxembourg 2013

2 Objective Investigate random number generation in several open source libraries, frameworks and applications that are based on cryptography Investigated Pure-Python ECDSA PyBitmessage BitcoinJS Bitaddress.org CryptoCat Part II (if time permits), Trusting random generators (based on Intel RDRAND)

3 Importance Good random generator is cornerstone of good cryptography Everything that must be hard to predict needs a good random source

4 Importance Example attack September 2006, buy commenting out few lines in OpenSSL library, Debian developers created a bug that rendered OpenSSL random source useless Bug was discovered May 2008 by Luciano Bello All cryptographic keys generated on Debian (or derived distributions like Ubuntu) with OpenSSL turned out to have only 15 bit entropy provided by process id) All keys generated were possible to break with brute force

5 Importance Second attack example In 2013 vulnerability in Android SecureRandom class implementation was described by Michaelis, Meyer, Schwenk Cascade of bugs reduced entropy to 31 bits making random numbers generated on Android guessable Vulnerability was previously used to steal at least 55 BTC from different wallets that used keys generated on Android

6 What is a good random number? Is 7 a good random number? What about ? Or 9?

7 What is a good random number? They all can be either good or bad random numbers depending on how they are generated

8 Entropy Entropy is just the size of the pool from where the numbers are randomly picked Entropy of 1 coin flip is 1 bit To get more entropy (in bits), we need more flips (random events) Real random numbers are hard to generate (read: slow) both for brain and computer But entropy can be mixed, combined and distilled Unfortunately entropy is also consumed fast by todays cryptographic applications

9 Benefits PRNG (Pseudo random number generator) Provides statistically good distribution Need very low entropy as a source (i.e. current time) Fast Why are PRNGs not secure? Predictability Linear dependencies

10 CSPRNG (Cryptographically Secure Pseudo Random Number Generator) Requirements Forward secrecy Backward secrecy State security Sufficiently large entropy RFC 1750 Randomness Recommendations for Security, Schiller, Crocker, Eastlake 1994 Cryptanalytic Attacks on Pseudorandom Number Generator, Schneier, Kelsey, Wagner, 1998

11 Generalized CSPRNG, with periodic reseeding Proposed in 1998 by Schneier, Kelsey, Wagner, Hall in Cryptanalytic Attacks on Pseudorandom Number Generators

12 Presentation of investigated random number generators First operation system provided generators were investigated Then platform libraries and browsers Finally libraries, frameworks and applications in question

13 Operating systems

14 Linux*** Hardware entropy source feedback in user space when available Application /dev/urandom /dev/random Saved entropy during boot Non blocking pool Blocking pool Entropy pool get_random_bytes Entropy sources *** without Intel RDRAND

15 Linux (few comments) Entropy estimator seems to be based upon Kolmogorov complexity rather than Shannon entropy (2012 Pousse, Short communication: An interpretation of the Linux entropy estimator) Analysis of the Linux Random Number Generator by Gutterman, Pinkas, Reinman 2006 The Linux Pseudorandom Number Generator Revisited by Lacharme, Röck, Strubel, Videau 2012

16 OSX Entropy sources /dev/random /dev/urandom Entropy pool (non blocking) Entropy sources Yarrow-160

17 Windows XP Application CryptGetRandom?????

18 Windows Vista & 7 Application CryptGetRandom BCryptGenRandom??????????? =

19 Windows 8 Application CryptGetRandom???? BcryptGenRandom FIPS?? NIST?? CryptographicBuffer. GenerateRandom?????????????????? =? =

20 Platform libraries

21 Python Application os.urandom (direct wrapper) random.systemrandom /dev/urandom CryptGetRandom Linux, OSX Windows *

22 OpenSSL Application RAND_bytes (OpenSSL has different engines but according to documentation seeds at least once at first call) /dev/urandom CryptGetRandom Linux, OSX Windows *

23 Browsers

24 Firefox since version 21 Application window.crypto.getrandomvalues() NIST SP Hash_DRBG (SHA256) (seed length 440 bits, reseeded after 2^48 bytes, generator is shared between threads) /dev/urandom CryptGetRandom Linux, OSX Windows *

25 Internet Explorer since version 11 Application window.crypto.getrandomvalues() BCryptGetRandom Windows 7, Windows 8

26 Webkit (Safari, Chrome, Opera, browser specific) Application window.crypto.getrandomvalues() ARC4 stream cipher based random number generator (seed length 1024 bits, reseeded after bytes, generator is shared between threads) /dev/urandom CryptGetRandom Linux, OSX Windows *

27 Libraries, frameworks and applications in question

28 CryptoCat Chat Application Salsa20/20 (seed size 256 bits, reseed never) window.crypto.getrandomvalues

29 Pure-Python ECDSA (library) Application Class PRNG Sha256 + counter util.randrange (small wrapper around os.urandom) Class SigningKey (default NIST192p) os.urandom

30 PyBitmessage (library) addressgenerator Application OpenSSL.rand (a library wrapper) OpenSSL.RAND_bytes OpenSSL library

31 BitcoinJS Library crypto.js contains Crypto.util namespace that with function randombytes that uses Math.random() Library rng.js, provides class SecureRandom on pool initialization calls window.crypto.random in case of specific browser version (this interface does not exist) Then continues to fill pool with Math.random() Finally adds current time (in ms) to the end of the pool

32 BitcoinJS Library rng.js, prototype SecureRandom When generating first random byte, creates a ARC4 generator seeded by current pool + current time Seed size is 1024 and it is calculated over potentially larger entropy pool Generator is never seeded again

33 BitcoinJS At the top of the rng.js is a suggestion to call rng_seed_time() on body.onclick and body.onkeypress As generator is never seeded again, it has effect only till first byte is generated Does not suggest mouse movements Sample user interface implementation does not follow this suggestion

34 BitcoinJS Application SecureRandom.nextBytes ARC4 (seed size 1024, from potentially larger entropy pool, never reseeded) Math.random() Mouse and keyboard Current time

35 Bitaddress.org Incorporates code from different libraries including BitcoinJS Uses similar SecureRandom class but indeed follows the suggestion to fill the pool based on random user generated events Uses mouse move event in addition Uses current time and mouse pointer coordinates (X*Y)

36 Bitaddress.org Uses seed count to collect enough entropy Seed count threshold is generated with Math.random() (from Crypto.util.randomBytes)

37 Bitaddress.org When generating random bytes, checks for existence of window.crypto.getrandomvalues When present, returns bytes using this interface instead In practice this renders seed counting useless as it does not change seed for the window.crypto.getrandomvalues

38 Bitaddress.org Application SecureRandom.nextBytes OR ARC4 (seed size 1024, from potentially larger entropy pool, never reseeded) window.crypto.getrandomvalues

39 Full Random Generation Chains Pure-Python ECDSA PyBitmessage Bitaddress.org (including parts of BitcoinJS) CryptoCat

40 Pure-Python ECDSA random generation chain Application Class SigningKey (default NIST192p) util.randrange (wrapper around os.urandom) os.urandom (direct wrapper) /dev/urandom /dev/urandom CryptGetRandom Non blocking pool Entropy pool????? Linux Entropy pool????? OSX????? Windows *

41 PyBitmessage random generation chain Application addressgenerator OpenSSL.rand (a library wrapper) OpenSSL.RAND_bytes /dev/urandom /dev/urandom CryptGetRandom Non blocking pool Entropy pool????? Linux Entropy pool????? OSX????? Windows *

42 CryptoCat random generation chain Chat Application Salsa20/20 window.crypto.getrandomvalues Firefox NIST SP Hash_DRBG (SHA256) window.crypto.getrandomvalues Webkit ARC4 /dev/urandom /dev/urandom CryptGetRandom Non blocking pool Entropy pool????? Linux Entropy pool????? OSX????? Windows *

43 Bitaddress.org random generation chain Math.random() Application ARC4 SecureRandom.nextBytes Mouse and keyboard OR Current time window.crypto.getrandomvalues Firefox NIST SP Hash_DRBG (SHA256) window.crypto.getrandomvalues Webkit ARC4 /dev/urandom /dev/urandom CryptGetRandom Non blocking pool Entropy pool????? Linux Entropy pool?????????? OSX Windows *

44 Conclusion In general most investigated projects got things right Only really problematic project is BitcoinJS that can not be used directly out of the box Bitaddress.org that extends on BitcoinJS got the things (relatively) right though

45 Conclusion continues Random number generation consist very often different linked random number generators Cryptography application writer must understand full random generation chain of target platforms

46 Questions or Part II (if time permits) Trusting Random Generators

47 Trusting Random Generators Dual_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) Intel RDRAND instruction in Linux

48 Dual_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) Part of NIST Special Publication A National Institute of Standards and Technology Recommendation for Random Number Generation Using Deterministic Random Bit Generators Contains 4 specifications Contains possible backdoor Showed by Dan Shumow and Niels Ferguson at the CRYPTO 2007 conference in August Still used (after 2007) by RSA security (confirmed) and possibly by Intel and Microsoft (suspected) Backdoor somewhat confirmed in 2013

49 Intel RDRAND in Linux Documentation of Linux random driver (comments of random.c) states that hardware random sources are not part of the kernel and entropy from them should be feed back into the pool externally 2011 Intel engineers approached Linux and suggested to incorporate Intel RDRAND instruction directly into Linux kernel as an architectural entropy source

50 Intel RDRAND in Linux Everything went (relatively) smoothly and patches went into kernel Fast forward to third quarter of 2013 when revelations of Dual_EC_DRBG came out Suddenly people noticed that documentation of RDRAND mentions NIST SP A But this contains also Dual_EC_DRBG But Linux uses RDRAND

51 Intel RDRAND in Linux Linus Torvalds made a statement that Kernel maintainers actually know what they are doing Output of RDRAND is mixed into entropy pool before it is returned to the user Theodore Ts said "I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction.

52 Intel RDRAND in Linux (change history) void get_random_bytes(void *buf, int nbytes) { - extract_entropy(&nonblocking_pool, buf, nbytes, 0, 0); + char *p = buf; + + while (nbytes) { + unsigned long v; + int chunk = min(nbytes, (int)sizeof(unsigned long)); + + if (!arch_get_random_long(&v)) + break; + + memcpy(buf, &v, chunk); + p += chunk; + nbytes -= chunk; + } + + extract_entropy(&nonblocking_pool, p, nbytes, 0, 0); } EXPORT_SYMBOL(get_random_bytes); author Linus Torvalds <torvalds@linux-foundation.org> :29:07 (GMT) committer Linus Torvalds <torvalds@linux-foundation.org> :29:07 (GMT)

53 Intel RDRAND in Linux (change history) static void add_timer_randomness(struct timer_rand_state *state, unsigned num) { struct { - cycles_t cycles; long jiffies; + unsigned cycles; unsigned num; } sample; long delta, delta2, -637,7 static void add_timer_randomness(struct timer_rand_state *state, unsigned num) goto out; sample.jiffies = jiffies; - sample.cycles = get_cycles(); + + /* Use arch random value, fall back to cycles */ + if (!arch_get_random_int(&sample.cycles)) + sample.cycles = get_cycles(); + sample.num = num; mix_pool_bytes(&input_pool, &sample, sizeof(sample)); author Linus Torvalds <torvalds@linux-foundation.org> :36:22 (GMT) committer H. Peter Anvin <hpa@linux.intel.com> :49:45 (GMT)

54 Intel RDRAND in Linux (change history) Function add_input_randomness is called by add_input_randomness add_disk_randomness

55 Intel RDRAND in Linux (change history) static void init_std_data(struct entropy_store *r) { + int i; ktime_t now; unsigned long -974,6 static void init_std_data(struct entropy_store *r) now = ktime_get_real(); mix_pool_bytes(r, &now, sizeof(now)); + for (i = r->poolinfo->poolwords; i; i--) { + if (!arch_get_random_long(&flags)) + break; + mix_pool_bytes(r, &flags, sizeof(flags)); + } mix_pool_bytes(r, utsname(), sizeof(*(utsname()))); } author Theodore Ts'o <tytso@mit.edu> :28:01 (GMT) committer H. Peter Anvin <hpa@linux.intel.com> :18:21 (GMT)

56 Intel RDRAND in Linux (change history) static void init_std_data(struct entropy_store *r) { + int i; ktime_t now; unsigned long -974,6 static void init_std_data(struct entropy_store *r) now = ktime_get_real(); mix_pool_bytes(r, &now, sizeof(now)); + for (i = r->poolinfo->poolbytes; i > 0; i -= sizeof flags) { + if (!arch_get_random_long(&flags)) + break; + mix_pool_bytes(r, &flags, sizeof(flags)); + } mix_pool_bytes(r, utsname(), sizeof(*(utsname()))); } author Linus Torvalds <torvalds@linux-foundation.org> :23:09 (GMT) committer Linus Torvalds <torvalds@linux-foundation.org> :23:09 (GMT)

57 Intel RDRAND in Linux (change history) If the CPU supports a hardware random number generator, use it in xfer_secondary_pool(), where it will significantly improve things and where we can afford it. Also, remove the use of the arch-specific rng in add_timer_randomness(), since the call is significantly slower than get_cycles(), and we're much better off using it in xfer_secondary_pool() anyway. author Theodore Ts'o <tytso@mit.edu> :21:01 (GMT) committer Theodore Ts'o <tytso@mit.edu> :17:46 (GMT)

58 Intel RDRAND in Linux (change history) Mix in any architectural randomness in extract_buf() instead of xfer_secondary_buf(). This allows us to mix in more architectural randomness, and it also makes xfer_secondary_buf() faster, moving a tiny bit of additional CPU overhead to process which is extracting the randomness. author H. Peter Anvin <hpa@linux.intel.com> :26:08 (GMT) committer Theodore Ts'o <tytso@mit.edu> :37:20 (GMT)

59 Intel RDRAND in Linux (change history) static void extract_buf(struct entropy_store *r, u8 *out) { [...] + /* + * If we have a architectural hardware random number + * generator, mix that in, too. + */ + for (i = 0; i < LONGS(EXTRACT_SIZE); i++) { + unsigned long v; + if (!arch_get_random_long(&v)) + break; + hash.l[i] ^= v; + } + + memcpy(out, &hash, EXTRACT_SIZE); + memset(&hash, 0, sizeof(hash)); } Code of the previous slide author H. Peter Anvin <hpa@linux.intel.com> :26:08 (GMT) committer Theodore Ts'o <tytso@mit.edu> :37:20 (GMT)

60 Possible attack of Intel RDRAND in Linux Taylor Hornby At the first sight there is no problem as RANDOM xor INDEPENDENTLY_BIASED = RANDOM What if RDRAND is used as a marker to activate malicious behavior of the CPU? Then when it sees the RDRAND followed by XOR, it could bias the RDRAND output according to the second input of the XOR (in this case the state of the entropy buffer)

61 Intel RDRAND in Linux (change history, current fix of the previous problem) Previously if CPU chip had a built-in random number generator (i.e., RDRAND on newer x86 chips), we mixed it in at the very end of extract_buf() using an XOR operation. We now mix it in right after the calculate a hash across the entire pool. [ ] author Theodore Ts'o <tytso@mit.edu> :06:02 (GMT) committer Theodore Ts'o <tytso@mit.edu> :32:13 (GMT)

62 Conclusion Random number generator in the CPU can not be trusted