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 was a software implementation.
I wonder if and how effective this attack would be against devices with hardware implementations of AES.
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 very quickly, cheaply, and without needing to open most enclosures.
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.
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.
Hardware implementations are designed to make this hard. They also use a lot less power, so any measurements are more difficult / take longer.
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.
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.
(Of course, ECB is almost certainly a bad idea if you're trying to build an actual application!)
Of course, everyone uses plastic nowadays... ;-)
Forward secrecy is defined with respect to key agreement schemes and not symmetric crypto per se.
Totally don't get it in the slightest.
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 waves where the key is known, the attacker can then guess the key bit by bit.
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.
Or alternatively run the algorithm through an emulator that does the same thing.
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-chacha...
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 (as forg0t_username says, masking helps - but this is an entire field of study. Look at some CHES conference papers to get an idea.)
I don't think this part is true. There are constant time software implementations of AES: https://crypto.stackexchange.com/a/92/21442
This attack is reading data directly from the bus between RAM and the CPU. You can not make an algorithm that survives that.
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.
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.)
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.)
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.)
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.
(Designing easier-to-implement-securely algorithms does help.)
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. ;-)
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.
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...
Like adding random timings won't prevent timing attacks, adding random sized strings won't prevent chosen plaintext or padding attacks, etc...