Hacker News new | ask | show | jobs
by hvidgaard 3285 days ago
All it does is messuring power consumtion and uses knowledge about the implementation to calculate the key.

Unless steps have been taken to equal power consumption between different paths, theoretically there is nothing stopping this from working on a hw implementaion of AES.

3 comments

There is a paper on stealing RSA keys, by listening to the sound the power supply of a laptop makes, from 4 meters away with a microphone. Works wonders!
You're referring to https://www.tau.ac.il/~tromer/acoustic/ and the line of related papers.

That's absolutely great work, but this work uses very different techniques: the authors of that line of papers feed inputs to the crypto core that amplify the dependency on the key, e.g. by ensuring that a square-and-multiply does all or no squares depending on a single bit of the key.

AES doesn't have the kind of algebraic structure that would allow such amplification, so we mostly have to do it the hard way. Fortunately, we had some very talented interns and significant in-house (analog and digital) signal processing expertise. (From colleagues' previous jobs.)

> theoretically

Hardware implementations are designed to make this hard. They also use a lot less power, so any measurements are more difficult / take longer.

...how about a random-power-consumer? would it help?
No, not at all. A raised SNR can be overcome in almost all circumstances by making more measurements, i.e. correlation, since noise is not correlated, it is removed. For the same reason random delays don't help against timing attacks.
Curious: how about generating noise which is correlated to signal and actively tries to modify output to some "random" noise?
That's how DPA works as far as I understand.
Not if you calculate keys nonstop, then have another machine pick from a huge list later.
Perhaps you could quantize the level.
Generally mitigations like adding random things only delay attacks like this, they don't prevent them.

Like adding random timings won't prevent timing attacks, adding random sized strings won't prevent chosen plaintext or padding attacks, etc...

Wonder if you can hash the cryto algorithm.
This was even tested with CTR and GCM (I know this for a fact), which were not a problem at all. Surprisingly GCM was somewhat easier than hashing modes. But also CBC was detectable after a few blocks.
Cryptography Research (now RAMBUS) developed solutions against these DPA attacks. Real solutions are much more complex than just "random-power-consuming"

See: https://www.rambus.com/security/dpa-countermeasures/