6 ms·
Once again, if you believe this is a real issue, you're logically enjoined from using practically any hardware cryptography, including the AES instructions or a
by ekidd 13y ago
Once again, if you believe this is a real issue, you're logically enjoined from using practically any hardware cryptography, including the AES instructions or any HSM.
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.
- deleted 13y ago[deleted]
- JulianMorrison 13y agoYou are assuming the nominal output is the only output. This is a software perspective: output_block = aes(input block) This is a hardware perspective: output_block, cpu_state = aes(input block, cpu_state) …but the CPU only gives you the output_block. The cpu_state is a hidden global. Goodness knows what it's leaking.
- deleted 13y ago[deleted]
- nullc 13y agoThis doesn't preclude RdRand from being _worse_ however. 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).
- hannibal5 13y agoYour argument is just smart-ass argument for the sake of argumentation. 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.
- tptacek 13y agoThis is a baffling comment given that researchers have alrady found multiple side channels in Intel CPUs that have created viable key leaking attacks. It's possible to have this problem merely by accident.
- hannibal5 13y agoComparing potential side channel attack to the possibility to weakening practically all ssl keys that use Intel chips makes massive error in scale. Side channel attacks would work against specific targeted people. Weakening random numbers would work at the mass surveillance level.
- 13y ago