5 ms·

You are assuming the nominal output is the only output. This is a software perspective: output_block = aes(input block) This is a hardware perspective:

You 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 ago
This 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 ago
Your 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 ago
  This 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 ago
    Comparing 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.
  - nightcracker 13y ago
    Such side channels can be avoided in a proper implementation by avoid things like table lookups and conditionals based on secret data.
ekidd 13y ago
This is a good point, but only if your attacker has access to cpu_state somehow. To do this, they would need to do one of the following: 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.
- tptacek 13y ago
  No, this 1-3 list is not comprehensive; it ignores the entire literature on side channels and covert channels. 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.
  - makomk 13y ago
    They could try sneaking in a timing-based covert channel but surely that would be externally observable? The expected latency of those instructions is specified down to the last cycle, and since encryption is often performance-critical code people will be looking at their behaviour in detail.
  - ekidd 13y ago
    My apologies for summarizing things a little too casually, and thank you for the excellent papers. I'm especially impressed by the cross-campus timing attack in Boneh. 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.)

deleted 13y ago

[deleted]

nullc 13y ago

This 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 ago

Your 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 ago
This 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 ago
  Comparing 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.
- nightcracker 13y ago
  Such side channels can be avoided in a proper implementation by avoid things like table lookups and conditionals based on secret data.

ekidd 13y ago

This is a good point, but only if your attacker has access to cpu_state somehow. To do this, they would need to do one of the following: 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.

tptacek 13y ago
No, this 1-3 list is not comprehensive; it ignores the entire literature on side channels and covert channels. 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.
- makomk 13y ago
  They could try sneaking in a timing-based covert channel but surely that would be externally observable? The expected latency of those instructions is specified down to the last cycle, and since encryption is often performance-critical code people will be looking at their behaviour in detail.
- ekidd 13y ago
  My apologies for summarizing things a little too casually, and thank you for the excellent papers. I'm especially impressed by the cross-campus timing attack in Boneh. 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.)