Live data from Hacker News

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

fox-it.com

51–60 of 69 posts

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

#51
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.

Modern tooling will look for correlations; (fixed) useless instructions per se don't help, since the signal can still be found in the original instructions.

However, the attacks all rely on reducing noise by combining measurements. Introducing sufficiently-long random delays or sufficiently-big variations in clock speed can make it harder to combine measurements, and can thus stop such attacks. Unfortunately, making trace alignment hard is not so much a provably-correct fix as a contest between the hardware designer's ability to be really annoying and the attacker's intuition (to find usable synchronization points) and sheer persistence.

(If you want to rely on such things, you really need to get a top-notch hardware attack lab such as Riscure to look at your countermeasures; you really want to test against an experienced attacker's intuition.)

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

#52
post #16

Can someone ELI5 how this works? Would be much appreciated <3

Basically, the current in a circuit is dependent of the data manipulated: changing a value from 0 to 1 or 1 to zero generates a current to (dis)charge the gate capacitances. Maxwell's equations state that a current generates an electromagnetic field, and this field is perceived by the antenna. The attacker is then seeing electromagnetic waves related to the data manipulated. By carefully comparing the waves with wave…

This is an excellent summary.

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

#53
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.

The most vulnerable part of symmetric crypto algorithms is the S-box tables, (8 to 8 bits in AES) in most AES implementation realized as 8 to 32 bit T-tables. It is possible, but harder and slower to implement AES without, so it is usually not done.

Of software implementations, the Serpent algorithm, that was one of the candidates for AES, can be implemented without any lookup tables and fully key-independent memory access patters. That will make an attack like this very unlikely to succeed.

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

#55

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

Doesn't the device case act as a faraday cage?

Less so than we expected; a metallic case definitely reduces the signal strength, but IIRC for the one case we tried placing, the small-loop antenna directly on the case still gets you a good-enough signal to break this (pretty basic) AES implementation. Someone could definitely do more research into that, though - we only did a one-off experiment.

Of course, everyone uses plastic nowadays... ;-)

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

#56

Earlier quoted context omitted.

Doesn't the device case act as a faraday cage?

Less so than we expected; a metallic case definitely reduces the signal strength, but IIRC for the one case we tried placing, the small-loop antenna directly on the case still gets you a good-enough signal to break this (pretty basic) AES implementation. Someone could definitely do more research into that, though - we only did a one-off experiment. Of course, everyone uses plastic nowadays... ;-)

> but IIRC for the one case we tried placing, the small-loop antenna directly on the case still gets you a good-enough signal

Was the case grounded?

Laptops are mostly plastic and some non-grounded metal. Desktops are mostly grounded steel.

Steel may be permeable enough for a tempest attack. I don't know.

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

#57
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.

Side-channel-resistance is a property of the algorithm, not of the implementation. As technion says, ChaCha20 was designed such that the evident software implementation resists such attacks; however, Schwabe and Kasper also have a high-quality software implementation of AES. Hardware implementations are a different beast altogether, and a lot of expertise has gone into making hardened AES implementations in hardware…

ChaCha20 does not survive tempest attacks like this one. No algorithm does.

This attack is reading data directly from the bus between RAM and the CPU. You can not make an algorithm that survives that.

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

#58

Earlier quoted context omitted.

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!)

Yes, ECB, although other modes would only require superficial changes. In practice the harder task is actually identifying the mode in use!

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

#59
post #18

Earlier quoted context omitted.

Could this be used to break my existing hard drive encryption, or does it only apply to the key generation stage?

In theory, yes. In practice, just grabbing your unlocked laptop and running off is a lot simpler than our/my colleagues' attack. ;-)

A "mind if I share that table" attack might be much more useful than explicitly taking some laptop and running away with it. It completely depends on your threat model.

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

#60

Earlier quoted context omitted.

Side-channel-resistance is a property of the algorithm, not of the implementation. As technion says, ChaCha20 was designed such that the evident software implementation resists such attacks; however, Schwabe and Kasper also have a high-quality software implementation of AES. Hardware implementations are a different beast altogether, and a lot of expertise has gone into making hardened AES implementations in hardware…

ChaCha20 does not survive tempest attacks like this one. No algorithm does. This attack is reading data directly from the bus between RAM and the CPU. You can not make an algorithm that survives that.

To clarify: in one of the attacks discussed we mostly picked up a signal from the address lines - that is, we exploited the fact that AES' RAM access patterns correlate with the key.

ChaCha20 is sufficiently constant-everything (which includes not having any key-dependent RAM access patterns) that we'd probably need to pick up the data (not just address) lines. That turns out to be (mildly?) harder in this particular combination of attack target and measurement setup.

We do make appliances designed to survive (or at least strongly resist) such attacks, but admittedly we don't rely on naive software AES implementations operating on external RAM. ;-)

Post reply on HN