Hi all, I’m trying to do some project where would I need to compare a “right trace” to a “wrong trace”, similar as how it’s done in Lab 2_1B where depending on the password that you send on cap_pass_trace you receive a different trace.

Is there any way to this on Lab 4_2 or 4_3? Like, the trace of something encrypted with the right key and trace with a wrong one, or guesses of a wrong key vs the right key.

It’s probably a bit too ambitious to try to recover a key like that. The power trace differences between different data is much smaller than between different code/execution paths. Additionally, you need a way to convert the hamming weight of that data back into data that is actually useful.

Alex

I see, thanks for the tip!

Alex, if it isn’t asking too much, could you explain what exactly happens in Lab 4_1 to 4_3? I’m still trying to wrap my head around it and understand CPA.

I’ll be also glad for any papers or research about CPA so that I can understand it better.

Thanks for all the help!

In Lab 4_1, we establish that there’s a linear relationship between the power trace and the Hamming weight of the data being manipulated: `p_trace = const*hamming_weight(data) + noise`. In the case of this lab and AES in general, we select the SBox part of the AES algorithm (`data = SBox(key ^ plaintext)`) for reasons explained in lab 3_2 (tldr: at this point in the AES algorithm, none of the bytes have been mixed together, meaning one byte of data depends on one byte of the key and one byte of the plaintext. If you go a bit further in the algorithm, each byte of data depends on four bytes of the key and four bytes of the plaintext, eventually going up to the full 16 bytes of key/plaintext). We capture a bunch of power traces for different values of `data`, group them by their hamming weight, and average them to reduce the impact of `noise`, which varies randomly per trace, but should have a fairly constant average value. In Lab 4_1, we only do this at the point in time where the SBox operation is happening. The relationship between the average of the grouped traces and the hamming weight of the data is then plotted, giving a mostly straight line.

You only get this linear relationship if you both group the traces correctly (i.e. you calculate `hamming_weight(SBox(key ^ plaintext))` correctly) and if you use the correct point in time in your power trace. If you either wrong, your power trace will effectively be all noise and therefore give a non-linear result. In a real attack, you won’t know the key or the correct point in time in your power trace, but if you try this relationship at every point in your power trace with every possible key, only the one with the correct key at the correct point in time will give a linear plot. This is basically what we do in Lab 4_2, but instead of plotting all this data (5000 samples * 256 possible keys = 1.28 million plots for just one key byte), we calculate the correlation for each sample/key grouping. We then find the highest absolute correlation (since we don’t care if the const in the original equation is positive or negative), which should give us both the correct key byte and the correct point in time where the operation is happening. This gives us one byte of the key. We can then repeat this for the rest of the key bytes to get the rest of the key.

Alex