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