Where is the leakage of information?

When i did the Tutorial B5 Breaking AES (Straightforward) and Tutorial B6 Breaking AES (Manual CPA Attack), i was really sure that i understanded that the point that we are atacking, exactly after subbytes. So if with my hypotetical key the value after subbytes its equal to 0x63 the power consumption is related with his hamming weight.
So to check it i changed the sbox for another values. After that i run the attack again, but the result was that i was able to recover the key (needed some more measures, not many). How is it possible?

Hi Nick,

Yeah, you’re right regarding how the attack is working and changing the SBox should mess up your attack. How did you change it?

Alex

Hello Alex, thanks for the answer.
I used this lookup table:
#define new_Sbox { 0x96,0x87,0x87,0x87,0x0f,0x96,0x96,0x3c,0xc3,0xf0,0x96,0xd2,0x0f,0x2d,0x5a,0x87,
0x3c,0x78,0x3c,0x87,0x0f,0xa5,0xb4,0x0f,0x5a,0x2d,0x5a,0x5a,0x69,0x5a,0x87,0x3c,
0x4b,0x0f,0x69,0xd2,0xc3,0xc3,0x0f,0x3c,0xc3,0x5a,0x1e,0x0f,0x87,0x2d,0xc3,0xe1,
0xf0,0x3c,0xd2,0x3c,0xe1,0x69,0xf0,0x69,0xf0,0xe1,0x78,0x1e,0x1e,0xd2,0x4b,0x87,
0xf0,0x78,0xd2,0xe1,0xe1,0x96,0xa5,0x5a,0xa5,0xc3,0x2d,0x4b,0xd2,0x1e,0xd2,0x78,
0xa5,0x2d,0xf0,0x1e,0xd2,0x0f,0x4b,0xa5,0x96,0x3c,0x4b,0xc3,0xb4,0xb4,0xa5,0x3c,
0x2d,0x1e,0x5a,0x0f,0xb4,0xb4,0xc3,0x78,0xb4,0x0f,0xf0,0x87,0xa5,0xc3,0x69,0x5a,
0xa5,0x5a,0xb4,0x78,0x69,0x69,0xc3,0x0f,0x4b,0x4b,0x2d,0xd2,0xe1,0x0f,0x0f,0x2d,
0x3c,0xf0,0xe1,0x1e,0xa5,0x69,0xb4,0xe1,0x3c,0x5a,0x87,0xc3,0x96,0xa5,0xe1,0x87,
0x96,0x78,0xb4,0x2d,0xd2,0xd2,0x69,0x78,0xb4,0x1e,0x4b,0xe1,0x2d,0xa5,0xf0,0x2d,
0x1e,0xc3,0xc3,0xf0,0xb4,0xf0,0xd2,0xa5,0x3c,0x2d,0x5a,0x96,0x69,0x69,0x1e,0x87,
0x1e,0x3c,0xc3,0x96,0x78,0x2d,0xb4,0x5a,0x96,0xa5,0x0f,0x1e,0x96,0x87,0x5a,0xf0,
0x4b,0x87,0xd2,0xd2,0xe1,0x5a,0x4b,0x3c,0x1e,0x2d,0x87,0xe1,0xb4,0x4b,0x78,0x78,
0x87,0xc3,0x4b,0x96,0xb4,0xf0,0x0f,0xf0,0x96,0xc3,0xa5,0x4b,0x78,0x3c,0xe1,0x69,
0x1e,0x0f,0x69,0xe1,0x96,0x2d,0x78,0x69,0x69,0xe1,0x78,0x1e,0x3c,0xa5,0xd2,0x2d,
0x78,0x5a,0x78,0xf0,0x4b,0x1e,0xb4,0x96,0xb4,0x69,0xd2,0xf0,0x4b,0xa5,0x4b,0xe1};

static uint8_t Sbox[256]=new_Sbox;

Where every value of Sbox have a hamming weight = 4.

I just changed it in aes.c of tiny-AES128-C directory. After that i compile it, programed the CW303 and run the attack.
Why the attack still find the secret key when every byte of the sbox have the same HW?

Can you confirm that your new SBox is actually being used? Is the ciphertext changed from what it was before? Also, there’s another crypto library called AVRCRYPTOLIB, can you confirm that’s not being used instead of TINYAES?

Alex

Hello Alex! Thanks for answer.

Yes, the ciphertext change:
image
I changed the file aes.c and used “make PLATFORM=CW303 CRYPTO_TARGET=TINYAES128C” on the correct carpet.
I took 500 traces, with 1250 points of offset and 4000 sampling points.
Here are the results (if u take more traces u eventually will get the complete secret key):

I dont know what is going on here. If you want to try it the only thing u need is to comment the original sbox and paste this one (this sbox only have bytes with HW=4 if u look closer to it the right 4 bits of every byte are the same that the 4 left bits of every byte of the original sbox):

AES_CONST_VAR uint8_t sbox[256] = {
//0 1 2 3 4 5 6 7 8 9 A B C D E F
0x96,0x87,0x87,0x87,0x0f,0x96,0x96,0x3c,0xc3,0xf0,0x96,0xd2,0x0f,0x2d,0x5a,0x87,
0x3c,0x78,0x3c,0x87,0x0f,0xa5,0xb4,0x0f,0x5a,0x2d,0x5a,0x5a,0x69,0x5a,0x87,0x3c,
0x4b,0x0f,0x69,0xd2,0xc3,0xc3,0x0f,0x3c,0xc3,0x5a,0x1e,0x0f,0x87,0x2d,0xc3,0xe1,
0xf0,0x3c,0xd2,0x3c,0xe1,0x69,0xf0,0x69,0xf0,0xe1,0x78,0x1e,0x1e,0xd2,0x4b,0x87,
0xf0,0x78,0xd2,0xe1,0xe1,0x96,0xa5,0x5a,0xa5,0xc3,0x2d,0x4b,0xd2,0x1e,0xd2,0x78,
0xa5,0x2d,0xf0,0x1e,0xd2,0x0f,0x4b,0xa5,0x96,0x3c,0x4b,0xc3,0xb4,0xb4,0xa5,0x3c,
0x2d,0x1e,0x5a,0x0f,0xb4,0xb4,0xc3,0x78,0xb4,0x0f,0xf0,0x87,0xa5,0xc3,0x69,0x5a,
0xa5,0x5a,0xb4,0x78,0x69,0x69,0xc3,0x0f,0x4b,0x4b,0x2d,0xd2,0xe1,0x0f,0x0f,0x2d,
0x3c,0xf0,0xe1,0x1e,0xa5,0x69,0xb4,0xe1,0x3c,0x5a,0x87,0xc3,0x96,0xa5,0xe1,0x87,
0x96,0x78,0xb4,0x2d,0xd2,0xd2,0x69,0x78,0xb4,0x1e,0x4b,0xe1,0x2d,0xa5,0xf0,0x2d,
0x1e,0xc3,0xc3,0xf0,0xb4,0xf0,0xd2,0xa5,0x3c,0x2d,0x5a,0x96,0x69,0x69,0x1e,0x87,
0x1e,0x3c,0xc3,0x96,0x78,0x2d,0xb4,0x5a,0x96,0xa5,0x0f,0x1e,0x96,0x87,0x5a,0xf0,
0x4b,0x87,0xd2,0xd2,0xe1,0x5a,0x4b,0x3c,0x1e,0x2d,0x87,0xe1,0xb4,0x4b,0x78,0x78,
0x87,0xc3,0x4b,0x96,0xb4,0xf0,0x0f,0xf0,0x96,0xc3,0xa5,0x4b,0x78,0x3c,0xe1,0x69,
0x1e,0x0f,0x69,0xe1,0x96,0x2d,0x78,0x69,0x69,0xe1,0x78,0x1e,0x3c,0xa5,0xd2,0x2d,
0x78,0x5a,0x78,0xf0,0x4b,0x1e,0xb4,0x96,0xb4,0x69,0xd2,0xf0,0x4b,0xa5,0x4b,0xe1};

I also used a sbox with every byte with HW=0 and the attack didnt work. But i still dont know whats going on. If you or someone can help me to understand this i would appreciate it very much!

I can somewhat replicate on the STM32F3. My best theory is that the leakage between different bits isn’t exactly the same (perhaps for the hamming weight of nibbles) and, since your new SBox is still related to the old one, there’s still enough of a relationship there to break the key.

I’d guess that if you remove the relationship between the new SBox and the old one, the attack would then fail.

Alex

2 Likes

I thounght something like that but im not convinced. The CW303 is a 8bit microcontroller, the complete byte should change in at the same time and the most significant nibble should add enugh “noise” to be able to compare the power consumption with the expected consumption. Well I will continue looking if for some other reason for this behavior/results. If u find something let me know! Thanks for the help!

Some additional thoughts: I haven’t worked out the math but my intuition tells me that in using an sbox which is not actually an sbox (because it’s no longer a bijection: several inputs are being mapped to the same output), the underlying principle of the attack no longer holds?
What if you try with a different sbox that is actually a 1:1 mapping (every distinct input byte gets assigned a distinctive output byte).

Also, the Jupyter tutorials that were developed for CW5 show more of the details how the attack works; recommend you have a look (but you’ll have to upgrade to CW5). For example in this one here, you can easily play with the sbox on the attack side, instead of the target side:

Thanks for the reply, i will try different sbox to see if i can conclude something. But it still look like black magic for me.
If someone have more thoughts i will be glad to read them!

Im not sure if i understand correctly, but the problem with that different sbox with HW=4 in every byte its that the attack still work. And i dont understand why.

Nice riddle!
The theory about the nibbles sounds plausible. I am not yet so familiar with the Chipwhisperer capabilities, but can you compute correlation with the S-box output in known-key scenario using other units than bytes? If so I would do that (either bitwise or nibble-wise). If not how about a workaround: the nibble you changed will be set to zero, such that only the “suspicious” original one keeps its effect and computing either correlation with known key or trying the attack with this newly defined S-box? That may provide more insights whether the nibble-theory is going in the right direction or not.

Well im working in a countermasure that work with nibbles, as far i understand the chipwhisperer take masures of the power consumption from the microcontroller that you want to analyze. If you modify somehow your cipher algorithm to work on nibbles instead of bytes or if your microcontroller have a 4bit bus instead of 8 (or more) you will see whats going on in nibble level. Right now im working with many kinds of look-up tables for conclud which one leak more or less information. But i still dont completely understand why they leak info. Thanks for your reply and your ideas i will try them!

Hi,

Really the fact that the SBox is non-linear here makes the attack work (plus the fact that these circuits fundamentally leak data), which you don’t want to change for non side channel cryptography reasons. I don’t think there’s really anything you can do in software to protect against side channel attacks like this - the mitigations have to come from hardware.

I think this stuff is a bit better explained in our new tutorials, so you may want to check those out as well.

Alex