It seems like it's (ab)using the metastability[1] of the dual inverter circuit as the input source. Since metastable states can persist for arbitrary long periods (with asymptotic probability), the bias testing and reset mechanisms are needed.
I assume they're controlling the system to ensure that the thermal noise dominates, and that the de-bias feedback loop and signal conditioner can strip out any low frequency thermal changes (like, temperature forcing through heavily loading CPU).
There are some really neat attacks that use thermal system properties to leak or force information. A submission from a while back: http://news.ycombinator.com/item?id=2872274 struck me as particularly sneaky.
Is there a risk that, after running for a long time, the dual inverter circuit (hardware) could degrade into a "stuck" or severely biased state? At some point, the conditioner probably can't compensate. Is there a method for software to query the RdRand's "health"?
It's easy to see that {process-id, parent-id, timestamp} can lead to a pretty predictable random number seed. But Amazon also had another easily available source of randomness : the timestamps of other customer's orders.
Why not generate a random #, and index to a random customer, and re-seed? One extra DB lookup and you've got a whole lot more randomness (like a private lava-lamp) to access.
Both sides have to generate secure random numbers in order to perform an ephemeral diffie-helmann exchange securely; if the client's random number is insecure, a man in the middle attack becomes possible.
Non-DH-based exchanges are even worse - the entire exchange hinges on a random number generated by the _client_. The server effectively doesn't even have a chance to generate a random number at all.
Using a physical process is generally going to be harder to exploit than a software one. There's going to be the possibility of uneven distribution (customer order timestamps may cluster at certain parts of the day, rather than being evenly distributed), as well as the (granted, small) possibility that on some small site without Amazon scale, the attacker can generate enough entries that it can reasonably assume one of them will be picked by the random index.
Now that's a perfect example of something that seems obvious in hindsight, but obviously wasn't since the problem has existed for so long without a solution.
It's also nice to see a more EE oriented post on hacker news now and again.
No. There has been no shortage of perfectly workable designs for hardware random number generators patented over the years. If anything, it's something that engineering types with a fondness for crypto obsess about too much.
The reality is that it's just not that hard to generate quality random numbers after a few seconds have passed after bootup on a busy system. Nothing needs gigabit rates of random numbers.
The cases where applications have had lousy random numbers have all been boneheaded implementation bugs (like the early 90s Netscape one the reference).
There are two reasons why this had not been implemented until now:
1. Low demand. It's entirely practical for applications to generate random numbers in software, especially with help from the kernel. With a hardware RNG on some chips, a fallback implementation would still have to be available and people who care about their CSPRNGs in software wouldn't fully trust Intel's numbers anyway.
2. Additional design, documentation, and testing burden. Every feature has a cost. The cryptographic qualities of random numbers are nearly impossible to test as a black box.
VIA's "Nehemiah" core C3 CPUs had hardware random number generation, as well as hardware AES assist, way back in 2003. (And, of course, VIA's "PadLock" instructions and Intel's RdRand instruction + AES-NI instructions are totally different. Hooray for continued x86 instruction set fragmentation!)
Edit: It just occurred to me that you're probably referring to the implementation, not the existence of a hardware RNG in x86. Doh!
"The nominally random number Netscape [1.x] used to form a secret key was based on just three values—time of day, process identification number, and parent-process identification number—all of them predictable. This allowed the attackers to reduce the number of keys that they needed to try, and to find the right one much sooner than Netscape had anticipated."
[+] [-] shabble|14 years ago|reply
I assume they're controlling the system to ensure that the thermal noise dominates, and that the de-bias feedback loop and signal conditioner can strip out any low frequency thermal changes (like, temperature forcing through heavily loading CPU).
There are some really neat attacks that use thermal system properties to leak or force information. A submission from a while back: http://news.ycombinator.com/item?id=2872274 struck me as particularly sneaky.
[1] https://secure.wikimedia.org/wikipedia/en/wiki/Metastability...
[+] [-] cpeterso|14 years ago|reply
[+] [-] mdda|14 years ago|reply
Why not generate a random #, and index to a random customer, and re-seed? One extra DB lookup and you've got a whole lot more randomness (like a private lava-lamp) to access.
[+] [-] bdonlan|14 years ago|reply
Non-DH-based exchanges are even worse - the entire exchange hinges on a random number generated by the _client_. The server effectively doesn't even have a chance to generate a random number at all.
[+] [-] shabble|14 years ago|reply
One interesting story about exploiting a poor RNG in Online Poker: http://www.cigital.com/papers/download/developer_gambling.ph...
https://webcache.googleusercontent.com/search?q=cache:AdC18Y... is another one, where the PRNG seed for a shared Nethack server wasn't random enough, and could be discovered and synchronised for fun and cheaty profit.
[+] [-] Empedocles99|14 years ago|reply
http://en.wikipedia.org/wiki/40-bit_encryption
Seems to agree with me.
[+] [-] oasisbob|14 years ago|reply
They link to this page with more details: http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] learc83|14 years ago|reply
It's also nice to see a more EE oriented post on hacker news now and again.
[+] [-] marshray|14 years ago|reply
The reality is that it's just not that hard to generate quality random numbers after a few seconds have passed after bootup on a busy system. Nothing needs gigabit rates of random numbers.
The cases where applications have had lousy random numbers have all been boneheaded implementation bugs (like the early 90s Netscape one the reference).
There are two reasons why this had not been implemented until now:
1. Low demand. It's entirely practical for applications to generate random numbers in software, especially with help from the kernel. With a hardware RNG on some chips, a fallback implementation would still have to be available and people who care about their CSPRNGs in software wouldn't fully trust Intel's numbers anyway.
2. Additional design, documentation, and testing burden. Every feature has a cost. The cryptographic qualities of random numbers are nearly impossible to test as a black box.
[+] [-] rwg|14 years ago|reply
Edit: It just occurred to me that you're probably referring to the implementation, not the existence of a hardware RNG in x86. Doh!
[+] [-] yuhong|14 years ago|reply
Another reason to disable SSLv2 on servers, BTW.
[+] [-] marshray|14 years ago|reply
[+] [-] snowtiger|14 years ago|reply