Live data from Hacker News

Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

fox-it.com

41–50 of 69 posts

Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

#41
post #19

Are there any modern crypto algorithms that are, by design, immune from an attack such as this? Would not having any key-dependent code paths be sufficient to prevent this attack? If it is possible to be immune by design to power analysis, timing and tempest attacks, is there a list of such algorithms somewhere that I can look it up? My google-fu hasn't returned anything useful.

No algorithm is secure by design against these DPA attacks. They exploit data-dependencies.

The only 'provably secure' (e.g., on paper (+)) countermeasure you can apply to these symmetric schemes is something typically called masking. You can view masking as using secret sharing techniques to split up all intermediate computation into independent operations. To defeat masking an attacker needs to be able to re-combine the data dependent information leakage associated with all the split components. This is always a possibility.

Thus it becomes a risk/cost tradeoff. The more you mask, the more secure you become, but at a cost of speed/area/power draw.

(+) It's decidedly non-trivial to implement a masking scheme such that you get the theoretical security. This is an active research area.

Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

#42

Well, in many cases AES keys are used one time, and there's also forward secrecy that guards it from decryption even if the key leaked.

This is a common countermeasure. You need to be aware that you maybe just be moving the problem. In settings in which key agreement techniques aren't used you'll be deriving new symmetric keys from an initial secret using a KDF. You now need to make sure that the KDF is DPA-resistant.

Forward secrecy is defined with respect to key agreement schemes and not symmetric crypto per se.

Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

#43
post #3

This was the AES implementation this was tested against: The trace below shows our signal for one block of AES-256 encryption running on a SmartFusion2 target. We use OpenSSL's implementation of AES on the ARM Cortex-M3 core of the SmartFusion2. There are clear, distinct patterns for each stage of processing. We see I/O to and from the Cortex-M3, calculations for the key schedule, and the 14 encryption rounds. So it…

We (that is, our interns and my colleagues) also attacked a straightforward/naive hardware implementation in an FPGA (reconfigurable hardware); we/they achieved at least a few centimeters of distance (using the open-loop antenna shown.) A truly hardened hardware implementation would be very hard to attack. The contribution of this work is mostly in showing that you can break realistic-but-not-great implementations ve…

The interesting work here is definitely on the measurement/acquisition side. Ultimately if it's an unprotected AES you're going to be able to exploit some leakage given enough measurements.

This is pretty consistent with recent results that attack more 'exotic' targets; the post-acquisition phase uses the same old techniques that were 'discovered' in the very early 2000's. It seems to be that once you've found the things you need to do to get clean measurements you can just use the straightforward linear-dependency related stuff or do a simple profiled attack if that suits.

Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

#44
post #19

Are there any modern crypto algorithms that are, by design, immune from an attack such as this? Would not having any key-dependent code paths be sufficient to prevent this attack? If it is possible to be immune by design to power analysis, timing and tempest attacks, is there a list of such algorithms somewhere that I can look it up? My google-fu hasn't returned anything useful.

Check out Leakage-Resilient cryptography, which aims to provide security against a bounded number of bits leaking. Here's a good survey paper from 2010: https://cseweb.ucsd.edu/~pmol/Documents/RE.pdf

Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

#46

This is research by my close colleagues; I'm happy to answer any questions.

What mode of operation of AES was used for the analysis?

ECB, I think? The focus was definitely on attacking the crypto core per se.

(Of course, ECB is almost certainly a bad idea if you're trying to build an actual application!)

Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

#47
post #19

Are there any modern crypto algorithms that are, by design, immune from an attack such as this? Would not having any key-dependent code paths be sufficient to prevent this attack? If it is possible to be immune by design to power analysis, timing and tempest attacks, is there a list of such algorithms somewhere that I can look it up? My google-fu hasn't returned anything useful.

Check out Leakage-Resilient cryptography, which aims to provide security against a bounded number of bits leaking. Here's a good survey paper from 2010: https://cseweb.ucsd.edu/~pmol/Documents/RE.pdf

Leakage-resilient cryptography is cool, but it's very much a mathematics-first approach: the independence assumptions required for the mathematical proofs simply don't hold in the physical world, and it's not clear what an assumption about "may not leak more than lambda effective bits" means (the attacker has 10 GB of measurements, mostly noise; can we expect to remain secure?)

The leakage-resilient work with which I'm most familiar also looks more like "algorithmic countermeasures" (e.g. changing keys frequently) than like something which would protect an AES core per se; but that's also a function of the work I'm most familiar with (the work of my old advisor Pietrzak.)

Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

#48
post #19

Are there any modern crypto algorithms that are, by design, immune from an attack such as this? Would not having any key-dependent code paths be sufficient to prevent this attack? If it is possible to be immune by design to power analysis, timing and tempest attacks, is there a list of such algorithms somewhere that I can look it up? My google-fu hasn't returned anything useful.

No algorithm is secure by design against these DPA attacks. They exploit data-dependencies. The only 'provably secure' (e.g., on paper (+)) countermeasure you can apply to these symmetric schemes is something typically called masking. You can view masking as using secret sharing techniques to split up all intermediate computation into independent operations. To defeat masking an attacker needs to be able to re-combin…

How about a "security through obscurity" countermeasure for sensitive systems where we'd use a special compiler that adds a bunch of "noise" in the generated algorithm (useless instructions etc...)?

Or alternatively run the algorithm through an emulator that does the same thing.

Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

#49

Earlier quoted context omitted.

We (that is, our interns and my colleagues) also attacked a straightforward/naive hardware implementation in an FPGA (reconfigurable hardware); we/they achieved at least a few centimeters of distance (using the open-loop antenna shown.) A truly hardened hardware implementation would be very hard to attack. The contribution of this work is mostly in showing that you can break realistic-but-not-great implementations ve…

The interesting work here is definitely on the measurement/acquisition side. Ultimately if it's an unprotected AES you're going to be able to exploit some leakage given enough measurements. This is pretty consistent with recent results that attack more 'exotic' targets; the post-acquisition phase uses the same old techniques that were 'discovered' in the very early 2000's. It seems to be that once you've found the th…

Fully agreed - the post-acquisition stuff is mostly Riscure's (very nice, but standard/not-novel-per-se) Inspector tool.

Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]

#50
post #48

Earlier quoted context omitted.

No algorithm is secure by design against these DPA attacks. They exploit data-dependencies. The only 'provably secure' (e.g., on paper (+)) countermeasure you can apply to these symmetric schemes is something typically called masking. You can view masking as using secret sharing techniques to split up all intermediate computation into independent operations. To defeat masking an attacker needs to be able to re-combin…

How about a "security through obscurity" countermeasure for sensitive systems where we'd use a special compiler that adds a bunch of "noise" in the generated algorithm (useless instructions etc...)? Or alternatively run the algorithm through an emulator that does the same thing.

Yeah techniques like instruction re-ordering, messing with the clock, etc are legitimate options. However all they will effectively do is decrease the signal-to-noise ratio of the system; increasing the number of measurements the adversary will need to require.

The power of averaging is such that these extra security added by these types of countermeasure can rapidly drop to zero. Despite this there are some use cases and deployment environments in which this might still be worth doing.

Ultimately the game for people deploying SCA-resistant hardware is effectively to fix a period of time in which a single key is used, and add sufficient countermeasures to ensure that the attacker can't get the key within that period. 'Perfect' security isn't a strict requirement at all, nor is it possible to achieve.

Post reply on HN