Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Analysis of the Linux Random Number Generator Zvi Gutterman, Benny Pinkas, and Tzachy Reinman.

Similar presentations


Presentation on theme: "1 Analysis of the Linux Random Number Generator Zvi Gutterman, Benny Pinkas, and Tzachy Reinman."— Presentation transcript:

1 1 Analysis of the Linux Random Number Generator Zvi Gutterman, Benny Pinkas, and Tzachy Reinman

2 2 Talk Outline  Introduction  Properties required of pseudo-random number generators.  Description of the Linux Pseudo-Random Number Generator (LRNG).  Security analysis.  Recommendations for improving future implementations.

3 3 Introduction Randomness – a crucial resource for cryptography. Random Number Generators – critical building blocks of almost all cryphtographic systems. Weak random values may result in an adversary ability to break the system. Physical source of randomness – too costly.  use pseudo-random number generator.

4 4 Introduction The state of generator is seeded. Periodically refreshed by entropy which is gathered from physical sources such as Timing disk operations Human interface The state is updated using an algorithm which outputs pseudo-random bits.

5 5 Properties required of pseudo- random number generators Pseudorandomness – the generator’s output looks random to an outside observer. In many scenarios the adversary might learn the state of the generator: bypassing access restrictions of the operating system, reading the state from memory or hard disk.  the pseudorandomness requirement is not sufficient. Forward security – past output of the generator looks random to an observer, even if the observer learns the internal state at a later time.

6 6 Properties required of pseudo- random number generators Pseudorandomness – the generator’s output looks random to an outside observer. Forward security – past output of the generator looks random to an observer, even if the observer learns the internal state at a later time. Backward security – future output of the generator looks random, even to an observer with knowledge of the current state, provided that the generator is refreshed with data of sufficient entropy. The attacker is assumed to know the code of the generator.

7 7 The Linux Pseudo-Random Number Generator (LRNG) Structure of the LRNG: Three asynchronous components: translates system events into bits which represent the underlying entropy – collecting entropy. adds these bits to the generator’s “pool” – adding entropy. When bits are read from the generator, generates the output of the generator and the feedback which is entered back into the pool – extracting entropy.

8 8 Structure of the LRNG-details Three entropy pools: primary, secondary, urandom. For every pool - a counter for counting an estimate of the entropy (=amount of physical randomness) which is added to the pool.

9 9 Structure of the LRNG - details Initialization: Operating system startup includes the initialization of the LRNG with Time-of-day Additional disk operations and system events This sequence operations might be predicted  LRNG saves a random seed at shutdown and writes it back to the pools at startup.

10 10 Structure of the LRNG - details Collecting entropy: Each sample of “randomness” originating from system events is collected as two 32-bit words: First word – measures the time of the event Second word – the event value, usually an encoding of a pressed key, a mouse move, or a drive access.

11 11 Structure of the LRNG - details Adding entropy: In each round of state and output computation. Entropy bits are added to the primary pool from external sources. Primary pool is full  entropy is added to the secondary pool. Secondary pool is full  return to the primary pool. Entropy (from external sources) is never added to the urandom pool.

12 12 Structure of the LRNG - details Extraction process: Updating the pool’s contents Extracting random bits to the output: From the urandom pool when using /dev/urandom or get_random_bytes. From the secondary pool when using /dev/random. From the primary pool when one of the other pools doesn’t have enough entropy. Decrementing the entropy counter of the pool.

13 13 Extraction Algorithm Extraction Algorithm Scheme for the urandom and secondary pools: Apply SHA-1 to the first 16 words. Add part of the result to location j. Apply SHA-1’ to the right half of the pool Add parts of the result to locations j-1, j-2. Apply SHA-1’ to the 16 words ending at location j-2. Use the result to compute the output (by folding). SHA-1’: Use for their five initial constant values the five output words of the previous hash result j is the current position in the pool

14 14 SHA-1’ SHA-1 Extraction Algorithm 01631 01631 160 j jj-1j-2 pool folding output SHA-1’

15 15 General structure of the LRNG Entropy Sources keyboard mouse disk interrupts CAEAEAEE /dev/random (blocking) /dev/urandom Get_random_bytes (non-blocking) Primary Entropy Pool 512 bytes Secondary Entropy Pool 128 bytes Urandom Entropy Pool 128 bytes A A A A

16 16 Attack breaking Forward Security: The attack reveres the state of a single pool. Assume that in its last update it wasn’t refreshed with new entropy. Assume that the add operation is a simple addition modulo 2 32 -1. Let pool i denote the state of the pool at time i. Input: pool t. Computes pool t-1.  Computes previous output  Forward security is not satisfied. Security Analysis

17 17 Breaking Forward Security Simple attack: for the secondary and urandom pools - case where all but three words of the pool (j,j-1,j-2) are identical in pool t and pool t-1. Given pool t there are 2 96 candidates for pool t-1. Transition from pool t-1 to pool t is defined by the Extract algorithm.  Apply the Extract algorithm to each candidate and check if the result = pool t. yes  put candidate in a short list. The true value of pool t-1 is in the computed list.

18 18 Breaking Forward Security Simple attack - cont: The list is short: There are 2 96 -1 false candidates for pool t-1 [j-2,j]. Each of them has probability of  1/2 96 to become a false positive. Pr[#false positives = k]  where n=2 96 -1.  There are no false positives with probability  1/e. There is a single false positive with probability  1/e, etc. Time Complexity: 2 96 assuming that we model SHA-1 as a random function, so the probability of computing the right value of pool t [j-2,j] is 1/2 96

19 19 B reaking Forward Security Efficient attack: for the secondary and urandom pools - case where j is in the range [18,31].  pool t [0,15]= pool t-1 [0,15]. Given pool t,apply SHA-1 to words [0,15] and compute the value that was added to location j.  it is possible to compute pool t-1 [j]. Initialization vector for the second application of SHA-1 is computable from pool t-1 [0,15]. Extraction alg

20 20 Breaking Forward Security Efficient attack - cont: the attack algorithm: go over all 2 64 potential values of pool t-1 [j-2,j-1], apply SHA-1 to pool t-1 [16,31] and compute the resulting values that were added to locations j-2 and j-1. if these values are not equal to the difference between the values of these locations in time t and in time t-1 dismiss the candidate of pool t-1 [j-2,j-1]. the true value of pool t-1 is not dismissed. False positives appear with probability distribution where n=2 64 -1. Time Complexity: 2 64 Both simple and efficient attacks can be modified to fit the primary pool.

21 21 DoS Attacks There is no limitation on the number of bits a user can read from the random devices per time unit. However, /dev/random blocks its output when the entropy estimate is low until additional “noise” is added.  DoS attacks which block all users from reading /dev/random bits: read bits from /dev/random. use get_random_bytes in higher rate than of the entropy input events. the urandom non-blocking pool from which these bits are taken is refilled from the blocking primary pool.  DoS for the primary and secondary pools. Solution: limit the amount of entropy that can be extracted.

22 22 Guessable Passwords Usually, the first user-operation is user login, and the first input entered by the user is the password.  the state of the LRNG might be a deterministic function of the initial password entered by the user.  the attacker might identify the password by going over all possible password values and checking which one results in the LRNG observed output. Solution: remove the influence of the values of keyboard events on the LRNG. Keyboard entropy should be based on the timing of its events.

23 23 Other Attacks Creation of Noise: when the primary pool is full the entropy is added directly to the secondary pool, from which it is output when /dev/random is used.  the adversary can create noise that directly affects the LRNG output. Solution: flush the entropy to the primary pool, even if it is full Another break in the forward-security of the LRNG: the Extract algorithm first updates the pool and then computes its output  an adversary that learns the internal state of the LRNG learns the state of the pool which was used to compute the last LRNG output, and then can compute this output. Solution: switch the order of operations

24 24 Recommendations  Fixing the LRNG.  Implementing a quota for the consumption of random bits.  Adopting a simpler generator such as the Barak-Halevi construction.  In multi-user environments - giving each user its own random-number generator, where each generator should be refreshed with different data.

25 25 Thank you Mira Gonen gonenmir@post.tau.ac.il

26 26 Home Assignment #4 1. What are the properties required of pseudo- random number generators? 2. Shortly, describe the basic structure of the LRNG. 3. a. Describe an attack breaking forward security for the secondary and urandom pools. b. Describe an attack of the LRNG that is different from the one in item a, and give a possible solution. 4. How can the LRNG be improved?


Download ppt "1 Analysis of the Linux Random Number Generator Zvi Gutterman, Benny Pinkas, and Tzachy Reinman."

Similar presentations


Ads by Google