Download
1 / 68
680 likes | 846 Views
On the (in)security of the random number generators of Linux and Windows. Benny Pinkas, University of Haifa Zvi Gutterman, Leo Dorrendorf, Tzachy Reinman, Hebrew University. In this talk. What are PRNGs (pseudo-random number generators)?
E N D
On the (in)security of the random number generators of Linux and Windows Benny Pinkas, University of Haifa Zvi Gutterman, Leo Dorrendorf, Tzachy Reinman, Hebrew University
In this talk • What are PRNGs (pseudo-random number generators)? • Why are they important? Why should the generators of Windows/Linux be investigated? • The generator used by Windows • Its algorithm, and its weaknesses. • A little on the generator used by Linux • Its algorithm, and its weaknesses. • Security issues when using a generator in a systems without a hard disk.
Usage of random bits • Many applications need random bits for their operation • This is particularly true for security applications • All cryptosystems are only secure if they use random keys • “… Pick a keyK at random …” • In practice looks like CryptGenRandom(Key, 16) • Relevant for SSL, SSH, etc.
Usage of random bits:session ids • http is stateless. Session ids can make http stateful. Session id, blah-blah Session id, blah-blah Session id, blah-blah • Knowledge of session ids enables to impersonate clients. • Session ids must therefore be random/unpredictable. • [GM05] showed how to guess session ids in the Apache Java implementation for Servlet 2.4
Usage of random bits:preventing TCP spoofing • TCP sequence numbers should be unpredictable • to prevent “packet spoofing” • I.e., prevent attackers from pretending to come from fake IP addresses • "completing" a TCP handshake with a victim server without ever receiving any responses from the server. • Predictable TCP sequence numbers enable such attacks
Security • Applications are designed to be secure when using truly random bits • Random bits are hard to get • instead use pseudo-random bits (from a pseudo-random number generator - PRNG) • Applications are now only secure if pseudo-random bits are indistinguishable from random • Otherwise an attacker can, e.g., • Guess cryptographic keys (SSL in Netscape [GW96]) • Guess session ids (Apache session ids [GM05])
random u Distinguisher D ???? Pseudo-random generator • Pseudo-random number generator: a deterministic function mapping a short, random, secret seed, to a long output which is indistinguihsable from random. pseudo-random generator seed G G(s) s long output (random, short) a deterministic function
Possible Random Number Generators • Pure hardware generator (of true randomness) • Cost / portability / interface issues • Application based PRNGs • Too little noise available for seeding • Implementer can make mistakes • (The generators provided by most programming languages are insecure for security related applications) • Operating system based PRNGs • Seeding can use system based noise/entropy (process scheduling, hard disk timing, etc.) • PRNG can be implemented and hidden in the kernel • Implementer is less likely to make mistakes…
Why investigate the PRNGs of major operating systems? • Implementers of applications use the pseudo-random number generators provided by the major operating systems • But… • The algorithms and code of these generators were never published ! • We don’t know how they are initialized ! • Yet their output is crucial for almost any security application !
OS Operating system based PRNGs • The PRNG keeps an internal state, which advances (in a deterministic way) when output is generated. • The state is periodically refreshed with entropy generated by the operating system. • Different than the theoretical model of a PRNG.
OS ?? ?? Operating system based PRNGs • When analyzing PRNG security, we assume that everything but the initial seed (system entropy) is known to the attacker • The OS manufacturer might try to hide the algorithm, but reverse engineering can find it… secret secret
OS Desired property 1: Pseudo-randomness Output is indistinguishable from random (Therefore, it can be used instead of truly random bits)
system entropy Statei-1 Statei+2 Statei+4 Statei Statei+1 outputi-1 outputj outputi+4 outputi outputi+1 outputi+3 Desired property 2: Backward security (break-in recovery) • An attacker that learns the internal state cannot learn future outputs of the generator, assuming that sufficient entropy is used to refresh the state. compromised Statei+3
Desired property 3: Forward security • Given statei+1 it is hard to compute statei (i.e., an attacker which learns the internal state cannot learn previous outputs of the generator). • A mandatory requirement of the German evaluation guidance for PRNGs. HARD compromised
Why is forward security important? • Security systems are secure as long as attackers cannot access secret keys • Determined attackers might be able to access keys • How can we minimize the damage of key exposure?
Minimizing the damage of key exposure • Threshold crypto: (space dimension) • Use n servers. Critical operations require participation of t (<n) servers. Attacker must break into t servers in order to break security. • Example: secret sharing, threshold signatures. • Proactive crypto (space + time) • At end of every day the n servers exchange messages and change their state. Attacker must break into t servers at the same day to break security. • Disadvantages: At least t servers are needed for any operation (e.g., signatures).
Key evolution • Use time dimension. • The sensitive information (e.g. key) is frequently updated. • Adversary which learns the current key cannot break security of past operations. • “Forward security”: current users do not have to worry about attacks which might happen in the future.
Forward secure PRGs [K,BY,BH] • Also, the proof of the HILL construction of PRGs from one-way functions can be extended to show forward security.
Forward secure signatures • A single public verification key. • A different private signature key per day. • Signatures with all private keys can be verified with the same public key. • At the end of the day the signature key is erased. • Forward security: An attacker which obtains today’s private signature key, cannot learn the keys of previous days.
Forward secure signatures • Basic scheme [Anderson] • Private keys: a certification key + 365 day keys • Public key: public verification key of certification key • Initialization: • Use certification key to sign 365 certificates: “Key PKi is the public verification key of day i”. • Erase certification key • Day i: • Sign using Ki. Add to the signature the verification key PKi, and the certificate of day i. Erase Ki at end of day. • Improvement [K]: • O(1) storage. Use a forward-secure PRG to generate private day keys. Sign certificates using a hash tree. • Many more improvements (time vs. space).
Cryptanalysis of the Windows random number generator With Leo Dorrendorf, Zvi Gutterman Hebrew University ACM CCS 2007
CryptGenRandom • The only API provided by Windows OS for getting secure random numbers • The world’s most common PRNG • Used by Internet Explorer to generate SSL keys • Its exact design and code were unknown (until now) • Security by obscurity?
Our research • Examined the binary code of Windows 2000 • Windows 2000 is still the 2nd/3rd most popular OS • PRNGs of all Windows systems are said to be similar • Identified the algorithm used by the PRNG • Did not have access to the source code. • Used static and dynamic reverse engineering. This was not easy. • Verified the algorithm by writing a user-mode simulator which outputs the same values as the OS. • Showed attacks on forward and backward security
The main loop (never before published!) CryptGenRandom(Buffer , Len) // output Len bytes to buffer while (Len >0) { R := R get_next_20_rc4_bytes () State := State R T := SHA-1’( State ) Buffer := Buffer | T // | denotes concatenation R[0..4] := T[0..4] // copy 5 least significant bytes State := State + R + 1 Len := Len − 20 }
output Two 20 byte long registers CryptGenRandom(Buffer , Len) // output Len bytes to buffer while (Len >0) { R := R get_next_20_rc4_bytes () State := StateR T := SHA-1’( State ) Buffer := Buffer | T // | denotes concatenation R[0..4] := T[0..4] // copy 5 least significant bytes State := State + R + 1 Len := Len − 20 } SHA-1 is a hash function
Several instances of RC4 generate output used by the generator Uses RC4 and SHA1 CryptGenRandom(Buffer , Len) // output Len bytes to buffer while (Len >0) { R := R get_next_20_rc4_bytes () State := State R T := SHA-1’( State ) Buffer := Buffer | T // | denotes concatenation R[0..4] := T[0..4] // copy 5 least significant bytes State := State + R + 1 Len := Len − 20 } RC4 is a stream cipher
Odd usage of and + CryptGenRandom(Buffer , Len) // output Len bytes to buffer while (Len >0) { R := R get_next_20_rc4_bytes () State := State R T := SHA-1’( State ) Buffer := Buffer | T // | denotes concatenation R[0..4] := T[0..4] // copy 5 least significant bytes State := State + R + 1 Len := Len − 20 }
CryptGenRandom • Scoping: a different state is kept for every thread • RC4 states in static DLL space. R and State stored in the stack. • For an attacker, it is easier to learn this data compared to a system where this data is stored in the kernel. • Initializationgathers 3584 bytes of system data (most of this data is predictable). • Internal states, OS and CPU queries, registry keys, etc. • Applies SHA1 and RC4 to this data to compute the initial RC4 states. • Initialization is crucial for security. • Reseeding: after a process reads 128 Kbytes of output from CryptGenRandom initialization is repeated. • New system entropy is only collected at time of rekeying.
EASY EASY Attack on backward security (learning future outputs) • Since we know the algorithm, if we learn the state we can compute future states and outputs until the next entropy refresh.(This requires no cryptanalysis.) • This is not surprising • but since entropy is refreshed every 128 Kbytes of output for each thread (e.g., never for IE), the attack is very severe. • The generator should have been refreshed more often.
Don’t know how to attack the pseudo-randomness of the generator • The main loop • Uses RC4 and SHA1 to advance state • Applies SHA1 to (part of) state to compute output RC4, SHA1 SHA1 • We don’t know how to distinguish the PRNG’s output from random, or compute state from output.
RC4, SHA1 Also easy!!! SHA1 Attack on forward security (learning previous states) • RC4 is a good stream cipher, but it was not designed to provide forward security: given its state at time i+1 it is easy to compute its state at time i. • This enables us to break the forward security of the generator • Main result (for CryptGenRandom) : given Statei+1 it is possible to compute Statei with 223 work. • Attack is based (among other things) on exploiting the relation between + and
An even simpler attack on forward security • Suppose we know the initial values of State and R • These variables are never initialized, but rather take whatever value is on the stack location in which they are stored. • These values are quite predictable. • Given current value of RC4 state(s) we can rewind them to the initial values • Now, given initial values of all registers we can simulate the RNG.
Implications • MSFT: “this is a local information disclosure vulnerability and has no possibility of code execution and cannot be accessed remotely.” • But, • New remote execution attacks are found every week. • Our attack can be used to amplify their effect.
Implications: possible attack scenario • Attacker gets access to the machine • Buffer overflow, temporary physical access (@ café). • Attacker learns a single state. • Does not need to control the machine afterwards.
128KBytes of output The new attack • Attacker can now compute all states and outputs from the previous to the next entropy refresh • Does not need any more interaction with the system • Can now, e.g., decrypt all SSL connections. (hundreds of SSL sessions)
Previously known attacks - key loggers • Attacker can only learn about the machine in the period of time it owns it • Cannot learn about the past • To learn about the future it needs along-lived channelwith the attacked machine
The attack on forward security:what is known when the attack begins
Looking at the previous round(40 bits are missing in every register)
False positives • The attack checks 240 options for the missing 5 bytes • True value always gives a match. Each other value gives a (false positive) match with probability 2-40. • False positives are identified if they have no preimages. Not really a problem, since we expect O(k)false positive at time t-k (analysis using martingales). … t t-1 t-2 t-3
Overhead of our attack • A simple attack requires 240 invocations of SHA1 • A more intricate attack (using the relation between + and ) requires 223 work on average • Our implementation of this attack runs in 19 seconds (no optimization) • Dag Arne Osvik implements SHA1 on the PlayStation 3 • Performs 83 Million SHA1 invocations per second • can implement our attack in 1/10 of a second! • Details of improved attack on whiteboard.
