Mitigating Side Channel Attack (SCA)

The SCA power attack described in 2016 article called "Power Side Channels in Security ICs: Hardware Countermeasures", depends on the measurement of power consumption fluctuations during AES-128 execution, for either known plain text, or known cipher text. In addition, the attacker has the ability to change the cipher text (CPA attack). Nevertheless only one of them, either the plain text or the cipher text need to be known to the attacker.

Suppose one avoids exposing both of them, for instance by using secret internal key AND secret internal counter for counter (CTR) mode encryption. In that case the AES-128 block cipher encrypts a counter that is not known with a key that is not known.

Additionally the cipher text is located in an external Flash. And finally, the attacker cannot change the cipher text, as described in the article.

Is such a scheme still exposed to side channel attacks?

• You are right of course, however, my case is slightly special, in the sense that its AES_CTR that its both key and initial CTR value are internal in a silicon device, cannot be inspected nor changed, and only the cipher text which is constant as well resides externally. The question is whether SCA can still be performed under these conditions. Thanks – Evgeni Vaknin May 7 '18 at 9:10
• is the external flash an external ic where i can also snoop the power? – b degnan May 7 '18 at 22:06
• Do you always decrypt the same cipher text with the same key? – j.p. May 8 '18 at 5:21
• Yes. Each time the chip is booting it decrypts flash content with the same key and counter initial value that are stored internally in a secure manner. – Evgeni Vaknin May 8 '18 at 6:47
• Yes, the flash is an external chip where you can snoop the power. You can also record the data, as it is transferred over SPI I/F to the processor. However, the data is encrypted, as said. – Evgeni Vaknin May 8 '18 at 7:02

As you are always decrypting the same flash content with the same key, statistical attacks like DPA do not work, as they try to find dependencies between two random variables (one being an intermediate value predicted using parts of the key and the other one being the measured current consumption(s)), where in your case one of them is constant.

The only uses an attacker can get from several measurements (instead of using just one) is to take the average to reduce the noise or to apply an attack that exploits the noise. Otherwise the attacker basically has to use an attack that works with a single power trace.

If an attacker is able to run the identical software on an identical device where (s)he can choose the key and the cipher text, (s)he can use it to run the profiling phase for a template attack, and hope that both devices have very similar power characteristics.

As template attacks calculate likelihoods depending on the observed noise, you can combine the results of several measurements to improve your chances to recover key and data.

From my experience the success probability for a very skilled attacker (using an optimal template attack implementation combined with key enumeration techniques) are relatively low if the AES is implemented in hardware, but pretty good for a software implementation on a leaky device.

The one of good way to prevent is to use masking countermeasures on non-linear transformation (e.g. subbyte transformation in AES). The side-channel is leaked much on non-linear part.

So as @t.b.a. said, even if you can hide as much as you can, but still attacker can capture the physical leakage from the secret value processed inside a module. But when you implement masking countermeasure (e.g. generate random number, r and masking it like r ^ x, x is the secret value), the attacker only capture (useless) leakages comes from the wrong secret value(r ^ x).

But non-linear function, f, is not satisfied as f(x ^ r) != f(x) ^ f(r), so you need to make a modified non-linear function to follow the property of a linear function,g, g(x ^ r) = f(x) ^ f(r).

• This works also for SW implementation? – Evgeni Vaknin May 10 '18 at 8:49
• Yes, Actually, leakage can be much easily detected from SW implementation. Because it can only process data by 8-bits or 32-bits, etc based on its CPU type. – Kronos May 10 '18 at 14:53