Is AES S-Box resistant to side-channel attacks?

Question

I know that implemntations with T-tables such as Golang's are prone to side-channel attacks, but is AES's S-Box wihtout any additional table also insecure ?

Answer 1

I assume the question is 'suppose you had an AES implementation that uses a precomputed SBOX table (and no other tables); can we do a key recovery attack using a timing or cache side channel?'

The answer to that question is "yes (at least potentially; we have to make some assumptions on the CPU hardware; at the very least, if it actually does have a cache)"

Here is a simple (and plausible) scenario where it is easy to recover some of the key bits (actually, we can recover them all, however that'd require more explanation)

Assume that we are on a CPU with 16-byte cache lines (that is, the cache stores things in 16 byte chunks; if the CPU reads in a location, the memory controller reads in all 16 bytes of that chunk). We also assume that the sbox happens to be aligned at a 16-byte boundary (and so it occupies 16 cache lines) - actually, it'd be easier to exploit if it were misaligned; however for now, we'll assume aligned.

And, for our cached-based side channel, we can flush the cache, present a plaintext block, ask AES to encrypt it, and then check the cache to see which cache lines of the sbox were read in. I'll cover the timing-based version of the attack below.

Here is how the attack would work: we flush the cache, and present a random plaintext, run it, and see which cache lines the sbox occupied. The AES processing performs 160 sbox references (assuming AES-128); if we model each reference as random, then we have about a 1 in 2000 chance that there is some sbox cache line that is not referenced by any of the 160 reads. Now, if (say) the cache line that corresponded to the 5X entries (that is, the sbox indicies with a high nybble of 5), then we can deduce that it was never refenced in the initial round; that is, for each byte $B_i$ of the plaintext and each key byte $K_i$, we have $B_i \oplus K_i \ne 5X$; that is, we can deduce what the high nibble of each key byte is not.

We can repeat this process until we've eliminated all possibilities for the high nybble of each key byte except for the correct one - this gives us half the key. And, this would take maybe 30,000 or 50,000 probes (depending somewhat on whether we get to pick the plaintexts or have someone else generate random ones). And, it's easy enough to recover the lower nybble as well (say, by relying on the second round sbox references); that would take more explanation.

As for how you would convert this into a timing attack (using the same base assumptions, except that the attacker cannot determine which cache lines are in the cache after the AES operation, but can measure the time), we can perform the same base attack, however before the AES operation, we set the cache so that 15 cache lines within the sbox are in the cache and 1 line is not, and then perform the AES operation. If the 1 line is referenced, the CPU will read that line into the cache (which is an expensive operation; there's a reason CPU manufactures include a cache), and that would measurably increase the time. By measuring the time, we can deduce whether that cache line was referenced, and hence we can proceed with the same attack (albeit with rather more probes required; we're getting data on whether a specific cache line was read, not data on all 16).