Live data from Hacker News

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

fox-it.com

61–69 of 69 posts

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

#61

Earlier quoted context omitted.

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.

Good point. The case wasn't grounded but that is more common for embedded targets/laptops.

We haven't looked at attacking desktops but the fact that there is a market for tempest shielded desktops (from OSPL, etc.) is perhaps an indication that it might still be possible...

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

#62

Earlier quoted context omitted.

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.

[deleted]

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

#63
post #10

Earlier quoted context omitted.

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

That's how DPA works as far as I understand.

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

#64
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…

> Side-channel-resistance is a property of the algorithm, not of the implementation.

I don't think this part is true. There are constant time software implementations of AES: https://crypto.stackexchange.com/a/92/21442

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

#65
post #10

Earlier quoted context omitted.

...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?

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

#66

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…

> Side-channel-resistance is a property of the algorithm, not of the implementation. I don't think this part is true. There are constant time software implementations of AES: https://crypto.stackexchange.com/a/92/21442

Oops, sorry, I absolutely meant it the other way round: "Side-channel-resistance is a property of the implementation, not of the algorithm."

(Designing easier-to-implement-securely algorithms does help.)

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

#67
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…

Side channel resistance can be increased in the implementation. Some things like comparisons can be done in constant time or in variable time. If the algorithm includes comparisons it might be side-channel resistant only with certain implementations.

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

#68
An intelligent noise generator that runs as the second hardware thread on the same CPU using should be able to protect the encryption. If the second noise-generation thread is able to randomly stop the encryption thread and do itself some random crypto, it should be able to fool the eavesdropper which will assume that the signals of the noise thread is produced by the encryption thread.

One can also think about modifying the implemenation of OpenSSL and others by inserting a lot of noise in the algorithm itself.

One can also ask chip designers to modify the circuitry to produce a lot of noise during AES instructions. Or do the opposite in circuitry: use something comparable to active noise cancellation in headphones.

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

#69
Off topic, but I always wondered how defense forces deal with encryption of channel when they collaborate with other forces from different countries. You would somehow be able to add a new participant to the group. Would this require re-issue of keys?
Post reply on HN