This is a software perspective:
output_block = aes(input block)
output_block, cpu_state = aes(input block, cpu_state)
If your software— by design— eliminates side channels and isolates out timing. Then your hypothetical evil AES() would have a hard time screwing you over— it still might, somehow, but the window may be very narrow.
The only way to narrow the exposure from a bad rdrand is to never use it directly (e.g. without whitening via a CSPRNG with other truly random inputs).
1) Run code directly on the secure machine. Personally, I normally assume that if an attacker can run code, it's already Game Over. This includes running Java bytecodes and supplying data to media codecs, all of which can potentially be escalated to running code, and then further escalated to root.
2) Gain external access to cpu_state without running code, perhaps via a back-doored network card that colludes with the CPU. This would be pretty impressive, but it would also require some degree of network access. You can protect against this by sticking your whole computer behind a serial line and writing an extremely simple custom protocol in Go. This would make perfect sense for a credit card vault, for example.
3) Run a really exotic attack, such as the ones described in Reflections on Trusting Trust. For example, if the chip is willing to pattern-match on certain instruction sequences in the Linux kernel and replace them with compromised microcode, then we're in trouble. But if Intel ever got caught doing something this blatant, it would be a first-rate PR nightmare.
The nasty thing about a bugged hardware RNG is that it could silently compromise most of your encryption even if you had amazing perimeter security. And even if the attack were revealed, your chip vendor could claim it was just a dumb mistake.
Have you read any of these papers? I respectfully guess that you haven't. You're in luck. Go read Boneh's "Remote Timing Attacks Are Practical", and Osvik & Tromer's local spy process paper.
My knowledge of convert channel attacks and timing attacks mostly dates to the 90s. Here's what little I know, for whatever it might be worth:
1. If your crypto primitives take variable time and your attacker can see that, you're hosed. Any encryption system with variable time encryption is useless unless you can somehow quantize it safely.
2. Eliminating covert channels is very nearly impossible. The literature on this goes way back, and it's ugly.
Should most users defend against these attacks? The timing attacks, yes. But I would assert that if a hardware encryption module appears to operate in constant time, most users should trust it. But as always, it depends on your threat model.
For something like a serious credit card vault, I still think your best bet is to get it off the network, build and audit a custom protocol that only passes a known set of messages, rate limit those messages, and quantize message timings. At that point, your biggest problems are bribery, insiders and physical security.
But if you do all that, I can't imagine why you would want to generate your encryption keys using somebody else's black-box hardware. Entropy pools are a good idea, even if you decide to trust your hardware AES implementation.
(And yes, I'm still oversimplifying. Hacker News is no substitute for a real threat analysis and security audit, nor for a conversation with whoever regulates or insures your business.)
For this threat, most active attacks are not particularly useful. They may capture encrypted data at a different point in transit than the one that originated it, making most side channel attacks difficult or impossible.
But a compromised RNG can be almost impossible to detect, and yet render almost any crypto system trivially breakable offline after the fact. The NSA has already once created a DRBG for which there could be a secret key that could determine the internal state of the generator with only 32 bytes of its output http://www.schneier.com/essay-198.html
I agree that being too wary of your hardware can lead you down a rabbit hole of paranoia, and that on the whole, we have much bigger problems to solve than hypothetical backdoored hardware random number generators (I have not seen any evidence that Intel has included a backdoor, merely people saying that because it's a black box we can't tell that they haven't). But since a good RNG is absolutely essential to so much crypto, and a compromised RNG would make it so easy for an adversary who passively monitors all communications and would like to have the option to decrypt them at their leave at a later date, I think that this is more worth worrying about than problems with the AES instructions.
Having CPU state that somehow leaks information past operating system is not realistic road for take. It would be known for thousands of Intel engineers.
Having tiny feature in chip that contains purposefully but not obviously vulnerable design that needs high level cryptographic knowledge to understand and compromises security is completely different matter.
EDIT comparing potential side channel attack to the possibility of weaken practically all ssl keys that use Intel chips is error in scale. Side channel attacks would work against specific targeted people. Weakening random numbers would work at the mass surveillance level.
Side channel attacks would work against specific targeted people. Weakening random numbers would work at the mass surveillance level.
Why is true? Let's assume that a chip has hardware AES support, and the team which designed the AES module is working for Eve (the standard generic attacker). What can Eve do to compromise the AES encryption without getting caught?
She can't have the AES module encrypt the data with a known key, because then it won't decrypt correctly. She can't leak the key data, because we already know what size output we're expecting. Basically, AES is a well-understood function, and as long as we control the inputs, we can verify that the outputs are correct. It's not a 100% guarantee, but the risk to the attacker (and the chip vendor) are enormous.
But a hardware RNG offers some especially nice features for attackers:
1) It's an essential part of many security algorithms. 2) If a weak random sequence is fed through a stream cipher, the output is indistinguishable from a very strong RNG. 3) It's possible to generate weak RNG sequences by "accident", which would allow the chip vendor to deny wrongdoing. It's like writing 'if (uid = 0)' instead of 'if (uid == 0)' in an obscure kernel security check—it looks accidental but leaves an enormous backdoor.
So there are ways to deniably and almost-undetectably sabotage a hardware RNG, and by doing so, you could vastly reduce the keyspace of anything from cryptographic keys to SSL sessions to TCP sequence numbers.
Personally, I use AWS all the time, but that's because I understand the threat model. If I can't accept the threat model of AWS, then I encrypt data on a local machine using keys generated from /dev/random. Different applications demand different threat models.
Besides, the costs of feeding a hardware RNG through an entropy pool are relatively low. So why not do the professional thing, and in the process, protect against backdoored or buggy hardware RNGs?
Now, if your chip vendor is willing to engage in high-risk attacks with no plausible deniability, then you're pretty much hosed.