Hello everyone,
I’m currently sampling power traces of a custom target with a simple aes software implementation.
In my Setup the CWLite isn’t providing the device clock so I’m sampling asynchronously.
These are two of the caputred power traces:
You can clearly see the aes rounds in the trace. However you can also see interrupts in both traces (between 2800-4200 in the first trace and between 0-1000 and 8400-9000 in the second trace).
These Interrupts happen at random moments during the aes encryption and because of that I need to remove them from the power trace. However because they are random I have no idea how to remove them from each trace where they may be at complettly different positions. The only “good” thing about the interrupts is that they all have the same curve which you can see in the first trace.
Any input on how to remove them would be more than welcome.
My current idea is to use a trace that only contains the interrupt and check if the same values are in a full aes trace +/- some percent and if so remove that part from the aes trace.
I’d say some sort of sum of absolute difference is probably your best bet for removing the interrupt from the trace. You might still end up having a few cycles of jitter in there though. You really only need a few cycles where the SBox load is happening, so you might be better off just trying to sync around that and ignoring the interrupt.
Do I understand correclty, that I only need cycles of the SBox load from the first aes round?
I would strongly recommend to sync your target board and CW Lite!
Do you mean hardware interrupts?
If yes, you can ignore them and continue collecting of the power traces. Just increase the number of traces being collected. The “wrong” power traces should not affect your results in the case if interrupts do not happen too often at the specific point of time.
But syncing the target board and CW lite is very very important.
These Interrupts are internal and happen mutliple times a second so often in fact that the average of 10000 power traces doesn’t represent aes anymore.
I can’t run my target via the CWlite clock. But even if I could, the problem with the interrupts would still persist.
How many times (briefly) do interrupts happen in a second?
And what is the performance of an AES engine?
I just want to estimate how strong interrupts can affect the power traces.
There are about 2000 interrupts per second and the aes operation takes about 1-2ms
Is it a single core CPU? If so, and interrupts have close to random behaviour, indeed, it will be difficult to cut off interrupt handler tracks.
You can try to use SAD to align the traces but I am not sure it will perfectly work.
Could you give more details about the system? Is it MCU with application running on it or is it full CPU with Linux?
Of course. It’s a simple single core16 MHz MCU. The only things the MCU does are 1. updated system time (thats what the interrupts do) 2. wait for aes encryption commands (via a serial interface) and encrypt the given plaintext with a secret key.
That will make attacks harder but certainly still possible. After all this is not unlike many real-world targets.
However you’re taking on 2 challenges at once: asynchronous sampling and interrupts. If you can’t make it work, try learning how to deal with each in isolation.
I think I already solved the asynchronous sampling problem. I calculated how long aes takes and choose my adc.samples, clock.adc_src and clock.clkgen_freq accordingly.
I would still like to know whether, this assumption is correct or not.
Yes, for our SW AES targets we use leakage from the first round sbox output.
Our SCA101 lab 4.2 teaches this.
1 Like
Alright thank you.
Regarding the interrupts. I wrote a function that finds interrupts in a trace and removes them. I then pad every trace with 0 so that every trace has the same length. I then put all traces in a project and run SAD.
Update: It worked, removing the interrupts, and using cpa returned the correct key.
1 Like
