Hi,
I ran the ANSSI SW-hardened AES-128 implementation on a CW STM32F303 UFO target board (in an earlier thread I was directed to this github directory for .hex files: https://github.com/jmichelp/chipwhisperer-firmware). I ran a TVLA on it, and ended up with this result:
My question is what is the reason for the tail at the beginning, which exceeds the 4.5 sigma line? I used the fixed vs. random data dataset procedure described by Rambus.
Thanks!
Which variant of the firnware did you use?
If the firmware name includes “KEYSCHEDULE” in it this could explain the spike at the very beginning as the keyschedule is thus included in the capture. Although it should be protected.
Also, keep in mind the implementation is slower than a textbook AES and includes at the beginning pre-computations before actually doing the encryption operation. I’m not sure that 20k samples is enough to reach the first rounds of AES. Maybe you need to use the “offset” parameter to skip some samples after the trigger and capture further down the algorithm.
Unfortunately, Chipwhisperer doesn’t allow you to see the trigger signal (even a reconstructed one). This would allow to see the full windows during which the encryption runs so there’s a bit of trial and error here or you need an external scope and some maths 
Hi!
I just used the MASKEDAES_ANSSI. I didn’t know that the pre-processing took that many samples. I’ll try out with the offset parameter or use a scope with a deep memory capacity to do the job.
You mentioned in a previous thread that standard CPA should not be able to retrieve the keys. Intuitively, why is that? Is it because of some de-synchronization? I don’t know too much about CPA in the frequency domain, more or less heard that there is such a thing. Would something like that be able to extract the keys, without doing profiling attacks? (just curious about the capabilities of the different SCA techniques)
Actually it is possible to reconstruct the trigger signal!
scope.adc.trigger_count returns the number of ADC clock cycles for which the trigger was seen active for the last capture.
Jean-Pierre
I didn’t know it was since last capture. I thought the counter never gets reset to 0 and thus becomes less useful.
It should reset when the scope is re-armed.
Jean-Pierre
Thank you both for the replies. But back to my original reply, why, intuitively, would classical CPA not work, and would frequency CPA techniques work?
Thanks!
A second follow-up question, are ML and DL solutions more an academic exercise, or are there published cases where it works for very practical scenarios as well, as e.g. when you don’t really know the point to attack?