3 ms·

Skimmed the article quickly. This is a practical application of a timing attack on AES by Bernstein. They seem to be able to recover complete keys in all SSL li

by pedrocr 13y ago

Skimmed the article quickly. This is a practical application of a timing attack on AES by Bernstein. They seem to be able to recover complete keys in all SSL libraries tested(gcrypt, openssl and polarssl). This is also completely fixed by using the hardware AES implementation in recent processors, so should basically fix itself with time as all the cloud providers upgrade systems. Does anyone know if AES is particularly susceptible to these side-channel attacks? Are the Bernstein constructs in NaCl safer because of being easier to implement in constant time? Edit: Apparently NaCl even includes a constant time AES implementation[1] so it would be nice to have seen it compared in this paper. [1] http://nacl.cr.yp.to/features.html http://nacl.cr.yp.to/features.html

p4bl0 13y ago
What's important is not only "constant time implementation" but rather, as it is written on the page you linked that there are "no data-dependent branches". Because when you have branches, even if they are perfectly balanced in time (i.e., number of instructions), it is still possible to attack on recent processors with pipelines (like in smartphones for instance), because the processor will start computing the more probable branch in advance (and if you know how it works you can compute which branch that is) and then it will actually be faster if it is actually this branch that is taken than if it is the other. It's a bit like cache timing attacks, but with code instead of data.
- pedrocr 13y ago
  I was reading the features page in the NaCl site and it seems timing attacks require very careful coding to avoid. The processor will leak information all over the place (instruction count, TLB, cache, etc). NaCl even includes constant time 16 and 32 byte string comparison functions. Instead of hoping everyone writes constant-time code are Intel/AMD working on virtualization extensions to fix these? Maybe allowing high-end CPUs to partition their cache/TLBs/BPUs per virtual host and virtualizing the instruction pointer and other cross-VM leaks.
  - pjscott 13y ago
    Using the AES-NI instructions completely gets rid of the attack on AES, and hopefully future ciphers will be designed from the start for side channel resistance.
    - p4bl0 13y ago
      > Using the AES-NI instructions completely gets rid of the attack on AES. I would be very, very careful before saying that. Actually I wouldn't even say it. Hardware implementation are also subject to side-channels, even when they include countermeasures. Leakage models we have for hardware are not accurate enough, and maybe they can't be. Take for instance with the power consumption side-channel: not every bit in a register leak the same (when being set or reset, they do not consume the same amount of energy / emit the same amount of EM radiation), and the actual leak depends on so many thing that the only way to know it is to measure it in the precise environment of the threat on the actual hardware that may be subject to attack. Actual hardware behavior is so difficult to predict, and side-channel attacks manage to exploit any bias, leak, glitch, anything. Plus, there is still the possibility of fault injection attacks…
    - pedrocr 13y ago
      You're still hoping for no bugs and only considering the case of crypto. Maybe there are other interesting secrets recoverable with techniques like these from software written without such cares. Edit: I wonder if similar timing attacks can be used against the VMs of scripting languages to recover code. It would be a neat hack.
higherpurpose 13y ago
I know RNG's can be vulnerable to hardware backdoors or backdoor-like weaknesses of some kind, but are hardware AES implementations vulnerable to that, too?
- pedrocr 13y ago
  Extremely vulnerable I'm sure. It should be trivial for a hardware backdoor to get the key out of the AES-NI instructions and then have some kind of secret instruction to give the key to the attacker. The attacker would just need to spin up a VM on the same CPU and start extracting keys. But if you already don't trust Intel/AMD you're screwed anyway. Hardware backdoors are really scary and unverifiable.

by pedrocr 13y ago

p4bl0 13y ago

What's important is not only "constant time implementation" but rather, as it is written on the page you linked that there are "no data-dependent branches". Because when you have branches, even if they are perfectly balanced in time (i.e., number of instructions), it is still possible to attack on recent processors with pipelines (like in smartphones for instance), because the processor will start computing the more probable branch in advance (and if you know how it works you can compute which branch that is) and then it will actually be faster if it is actually this branch that is taken than if it is the other. It's a bit like cache timing attacks, but with code instead of data.

pedrocr 13y ago
I was reading the features page in the NaCl site and it seems timing attacks require very careful coding to avoid. The processor will leak information all over the place (instruction count, TLB, cache, etc). NaCl even includes constant time 16 and 32 byte string comparison functions. Instead of hoping everyone writes constant-time code are Intel/AMD working on virtualization extensions to fix these? Maybe allowing high-end CPUs to partition their cache/TLBs/BPUs per virtual host and virtualizing the instruction pointer and other cross-VM leaks.
- pjscott 13y ago
  Using the AES-NI instructions completely gets rid of the attack on AES, and hopefully future ciphers will be designed from the start for side channel resistance.
  - p4bl0 13y ago
    > Using the AES-NI instructions completely gets rid of the attack on AES. I would be very, very careful before saying that. Actually I wouldn't even say it. Hardware implementation are also subject to side-channels, even when they include countermeasures. Leakage models we have for hardware are not accurate enough, and maybe they can't be. Take for instance with the power consumption side-channel: not every bit in a register leak the same (when being set or reset, they do not consume the same amount of energy / emit the same amount of EM radiation), and the actual leak depends on so many thing that the only way to know it is to measure it in the precise environment of the threat on the actual hardware that may be subject to attack. Actual hardware behavior is so difficult to predict, and side-channel attacks manage to exploit any bias, leak, glitch, anything. Plus, there is still the possibility of fault injection attacks…
  - pedrocr 13y ago
    You're still hoping for no bugs and only considering the case of crypto. Maybe there are other interesting secrets recoverable with techniques like these from software written without such cares. Edit: I wonder if similar timing attacks can be used against the VMs of scripting languages to recover code. It would be a neat hack.

higherpurpose 13y ago

I know RNG's can be vulnerable to hardware backdoors or backdoor-like weaknesses of some kind, but are hardware AES implementations vulnerable to that, too?

pedrocr 13y ago
Extremely vulnerable I'm sure. It should be trivial for a hardware backdoor to get the key out of the AES-NI instructions and then have some kind of secret instruction to give the key to the attacker. The attacker would just need to spin up a VM on the same CPU and start extracting keys. But if you already don't trust Intel/AMD you're screwed anyway. Hardware backdoors are really scary and unverifiable.