Does AES-NI offer better side-channel protection compared to AES in software?

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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.