Does AES-NI offer better side-channel protection compared to AES in software? Also, it would be great of you could provide according references in your answer.
$\begingroup$
$\endgroup$
Add a comment
|
3 Answers
$\begingroup$
$\endgroup$
4
Yes, AES-NI was specifically designed to be constant-time and thus offers better side-channel protection than (some) software implementations. Note however that these day there exist quite fast side-channel resistant software implementations for AES, which are in-use by the better crypto libraries. AES-NI mainly offers a speed advantage over these implementations.
From the Intel® Advanced Encryption Standard (Intel® AES) Instructions Set Whitepaper:
The AES instructions are designed to mitigate all of the known timing and cache side channel leakage of sensitive data (from Ring 3 spy processes). Their latency is data-independent, and since all the computations are performed inter nally by the hardware, no lookup tables are required. Therefore, if the AES instructions are used properly (e.g., as in the following code examples) the AES encryption/decryption, as well as the Key Expansion, would have data-independent timing and would involve only data-independent memory access. Consequently, the AES instructions allow for writing high performance AES software which is, at the same time, protected against the currently known software side channel attacks
-
4$\begingroup$ "and since all the computations are performed internally by the hardware, no lookup tables are required" ... that's worded strangely. You can use or forgo tables in either hardware or software. $\endgroup$– Maarten Bodewes ♦Commented Feb 4, 2017 at 16:27
-
3$\begingroup$ @MaartenBodewes Hardware implementations usually use boolean logic to save gate area, so it likely was lapsed from the technical writer's mind. AFAIK most FPGAs use table implementations. $\endgroup$ Commented Feb 5, 2017 at 7:08
-
3$\begingroup$ Also having tables is not a problem per-se, what is a problem is having tables in memory that is not constant-time. $\endgroup$ Commented Feb 5, 2017 at 13:10
-
1$\begingroup$ It likely meant that no lookup tables are required in the cache, which is what side-channel attacks against AES often abuse. $\endgroup$– forestCommented Mar 7, 2018 at 6:53
$\begingroup$
$\endgroup$
5
With regards to timing-based side channels (those that can potentially be exploited remotely, as opposed to, say, power analysis), the AES-NI opcodes are constant-time. See for instance Intel Intrinsics Documentation, that describes the C-like function that can be used to leverage these opcodes: the opcode throughput and latency are fixed, which means "constant-time".
Now, of course, this is better than "software implementations" only insofar as:
The opcodes are used properly; e.g., if doing CBC decryption in the context of SSL/TLS, even if the AES itself is handled in a constant-time way, the CBC padding processing can also leak substantial amounts of secret information.
The "software implementations" that you compare with are not themselves constant-time. See for instance the Käpser-Schwabe implementation of AES-CTR, that leverages to SSE2 register for a remarkably fast and constant-time code; or, in "plain C", my own code.
The really good point of the AES-NI opcodes is that they provide very good performance. Measures speak for themselves:
The AES-NI code in CBC decryption and CTR modes could be made even faster; this code processes four blocks in parallel, but the underlying CPU would be more comfortable with eight parallel blocks; OpenSSL achieves more than 4 GB/s on the same machine (but it hardly matters for SSL/TLS, since the HMAC or GHASH for integrity check will be the bottleneck).
So we can say that the AES-NI opcodes offer as good as you can get protection against side channels, in absolute terms; and they are much better than anything else on the same platform when evaluated relatively to the achieved performance. It is common to see trade-offs between security and performance in cryptographic algorithm implementations.
answered Feb 4, 2017 at 16:28
-
$\begingroup$ "The AES-NI opcodes offer as good as you can get protection against side channels"; actually, I've heard complaints that the AES-NI instructions might not give sufficient protection against DPA-style attacks. I have not evaluated these complaints to see if they have a point, but I have heard them... $\endgroup$– ponchoCommented Feb 4, 2017 at 16:38
-
1$\begingroup$ @poncho I am voluntarily restricting myself to time-based side channels. It can be assumed that on any platform that ressembles a PC, secrets probably bleed all over the place when considering power analysis. $\endgroup$ Commented Feb 4, 2017 at 16:53
-
$\begingroup$ Actually, Cryptography Research is selling AES implementations that they claim are resistant to power analysis (and similar side channels). I would agree with you about an AES implementation that wasn't specifically designed by a person with deep understanding of side channels... $\endgroup$– ponchoCommented Feb 4, 2017 at 18:13
-
$\begingroup$ In hardware, you can just double all of the registers to dual-rail encode everything. It means there's no power information lost because you see symmetry in the device current. I have no idea why this is not generally done except for the fact that you double the area. $\endgroup$– b degnanCommented Feb 5, 2017 at 1:27
-
$\begingroup$ @bdegnan It is likely because modern IBM-style PCs are not designed with security against physical attacks in mind at all. For people who need this property, they tend to buy hardware with NATO SDIP-27 certification. It's easier to simply clean your entire power supply of EMSEC issues than it is to design the CPU to be immune to power analysis attacks. $\endgroup$– forestCommented Mar 7, 2018 at 6:58
$\begingroup$
$\endgroup$
8
In addition to the good answers by Thomas Pornin and SEJPM, I will also add a hypothetical downside related to side-channel attacks and AES-NI: nearly undetectable targeted hardware attacks.
It's fairly trivial to write a backdoored CPU that will run arbitrary code when a certain data pattern is triggered. This is hard to detect in the hardware and can be remotely triggered as long as you can get data into the affected CPU (e.g. by sending a IP packet).
However, this backdoor is merely a door, and requires a payload to actively exploit. This means that the actual exploit runs in software, and is easily exposed. It leaves a big smoking gun, and it requires the payload to work on an unknown machine.
But the AES-NI instructions allow for a new, incredibly targeted attack. Simply by modifying a chip to store the last n keys passed to AES-NI instructions you have a nearly undetectable key escrow, allowing you to get out the keys at a later time (e.g. by using a certain data pattern that gets replaced with the key). This is incredibly stealthy, and may work for years before it is actually detected.
-
$\begingroup$ I'm having problems why AES-NI necessarily makes this easier. This exploit comes in two phases; one is something that detects that an AES key is in use (and stores it internally in the CPU); the second phase is exploit code that extracts the contents of that secret location, and returns that. AES-NI would be involved only in the first phase (and you could equally as well have the CPU detect the instructions involved in, say, the OpenSSL AES key expansion logic. You highlight the second phase; how would AES-NI make that easier? $\endgroup$– ponchoCommented Feb 5, 2017 at 12:05
-
$\begingroup$ "and you could equally as well have the CPU detect the instructions involved in, say, the OpenSSL AES key expansion logic" this is not feasible to do while maintaining a well-functioning CPU that looks normal under inspection with a microscope. It can also lead to a lot of false positives and/or missed opportunities. The first phase is a lot harder than you think to do stealthily. But you are accurate in that once the key has been put into the CPUs hidden escrow, phase 2 has nothing to do with AES-NI anymore. $\endgroup$– orlpCommented Feb 5, 2017 at 12:44
-
$\begingroup$ I actually didn't disagree with how difficult phase 1 is (although I wouldn't worry about inspection by a microscope; instead, I would worry about the stability and uniqueness of the AES code; I'm also not certain that AES-NI makes it quite as easy as you make out); I was chiefly objecting to your second paragraph, which seemed to claim that phase 2 was difficult (and actually, I don't believe it is, at least when compared to phase 1, even with AES-NI). $\endgroup$– ponchoCommented Feb 5, 2017 at 17:54
-
$\begingroup$ @poncho My second paragraph is intended to convey the opposite. Are you perhaps confused with "this is hard to detect in the hardware"? I meant that the backdoor is hard to detect, not the pattern. $\endgroup$– orlpCommented Feb 5, 2017 at 19:00
-
$\begingroup$ Actually, I miscounted; I meant the third paragraph, with "This means that the actual exploit runs in software, and is easily exposed"; actually, with a bit of cleverness, it's not that hard to hide it assuming the cooperation of the CPU manufacturer (hint: not all instructions are deterministic...) $\endgroup$– ponchoCommented Feb 5, 2017 at 19:03