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 was a software implementation.
I wonder if and how effective this attack would be against devices with hardware implementations of AES.
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 very quickly, cheaply, and without needing to open most enclosures.
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.
All it does is messuring power consumtion and uses knowledge about the implementation to calculate the key.
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.
There is a paper on stealing RSA keys, by listening to the sound the power supply of a laptop makes, from 4 meters away with a microphone. Works wonders!
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.)
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.
This was even tested with CTR and GCM (I know this for a fact), which were not a problem at all. Surprisingly GCM was somewhat easier than hashing modes. But also CBC was detectable after a few blocks.
Cryptography Research (now RAMBUS) developed solutions against these DPA attacks. Real solutions are much more complex than just "random-power-consuming"
I remember reading about such attacks for the first time in Neal Stephenson's book Cryptonomicon under the term "Van Eck Phreaking". Looks like its gotten a lot easier in recent years!
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.
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.)
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.
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 (as forg0t_username says, masking helps - but this is an entire field of study. Look at some CHES conference papers to get an idea.)
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.
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. ;-)
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.
The keyword you're looking for is masking. Masked implementations of AES resist this exact attack without problem. Higher-order attacks are then needed, and those require exponentially more computation.
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.)
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.
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.
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...
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.
"Algorithmic countermeasures" - that is, switching keys quickly - can indeed hinder side-channel attacks. Be careful not to introduce more problems than you solve, though - hand-rolling your own crypto is something to leave to a team of experts (because you definitely want someone reviewing your design!)
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?
I read it a few times and still don't understand how you can get like the 4k of private key data or whatever it is out of a radio signal - and they don't even mention keys they're talking about the algorithm itself.
That gives the correct flavour, but note that we use a different side-channel than timing - this is really a hardware attack, so we e.g. pick up 0->1 transitions in the address bus.
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 waves where the key is known, the attacker can then guess the key bit by bit.
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.
it can read when the keys are used, i believe, but the attacker would need to know when the keys were used to identify the right time. However at 30cm this is someone standing at your desk waiting for you to fire up an instance or something.
I'm all for the sharing of information and responsible disclosure etc, but when a company that makes stuff that is supposed to be protected from this sort of attack, then shows how if you dont buy their stuff you are at risk from anyone who can follow their plans and has $200, which they likely couldn't do yesterday, it doesnt seem to be as consumer friendly as it could be. more protection racket perhaps,
We're just showing the capability; it's not like we're throwing a ready-made attack kit on the internet. And it's not like we could coordinate disclosure with "everyone who has ever shipped an AES implementation".
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.