With a second Chipwhisperer LiteArm I became the same results, so it should not be a defective hardware.
For a test I also added some delays inside the capture script and noticed that the period became smaller (less traces per Period) so it has constant time.
I also tested it with a Chipwhisperer CW303 with the same setup, there i do not get the sawtooth course.
Hi @giuli,
if I understand correctly what you’ve done, I think what you’re seeing are essentially artifacts.
First let me confirm my understanding: for your mean_nop.png, you did a capture of ~600 samples, averaged those samples, and repeat 20000 times to plot the average as a function of capture number?
If so, consider this:
In your first plot, you can see that the power oscillates between high and low values, but with an additional added “jump” which stabilizes by sample ~200. Now the target may be doing exactly the same thing at every clock cycle between sample 0 and 500, and you’d still see that jump. I’ve seen jumps like this when the target goes from idle (drawing very little power) to a state where it suddenly draws a lot more power. Something about capacitance I think and the sudden change in current draw.
What I’m getting at is that what you see then is not necessarily an accurate representation, in absolute terms, of what instruction the processor is doing. It is however accurate in relative terms – e.g if the processor did a power-hungry operation followed by a light one, you would see that. Or, a correlation power analysis to break AES could still succeed.
The amplitude of the jump depends of course on what the processor was doing before the measurement begins. So the mean will vary if your starting conditions are not constant, and perhaps this is what is happening here.
Hope this helps – let me know if I was completely wrong in my assumptions!
J-P
Yes, your understanding is correct.
DPA attacks are still working but with only about 50 Traces necessary the effect of the Sawtooth is I guess irrelevant for them.
And also because I use random data as an input the effect should be averaged out over the Sawtooth course.
Your assumption that it is related to what the processor did before the recording does not explain to me the periodic course of the traces
with a period duration of about 1.5 minutes and also the linear progression. I have no idea where any effects can come from in a µC with such a high period of time.
To my understanding the microcontroller should always be in the loop.
while(1){
simpleserial_get();
}
I already measured the supply voltage with an oscilloscope, but it seems to be quite constant.
This means that it must come from the µC the capture setup.
Furthermore I measured the output of the ARM-Target on the Measure pads and could not notice the Sawtooth there.
But I don’t know if this is because the Sawtooth course comes from the measurement setup (e.g the amplifier or the ADC) or I could not see it because of my settings on the oscilloscope.
This wouldn’t explain why I can only measure this effect with the chipwisperer-lite arm and not with the chipwisperer lite, because to my knowledge both capture boards are identical.
So far I pre-processed the data with a normalization what removes the effect of the Sawtooth what worked fine for me. But I am still very interested in what is causing this effect.
I would guess that the periodic effect actually originates from your computer: somewhere in the stack of layers between Python and the physical serial link, something causes the time between successive captures to not be constant, and to have a particular periodic behaviour.
Try inserting an additional delay between captures. If that delay is sufficiently greater than the variance in delay that is inherent to your system, then the effect of the variance should disappear?
I have already tested it with additional delays and noticed a smaller period, less traces per Period, it looks that the pattern has constant time.
Without the added delays I get around 20-24 Traces/sec
The other thing you can do is use the capture offset feature, so that the capture starts a precise amount of time after the trigger is issued. If the target is always doing the same thing between trigger and start of capture, this can also help reduce the variance observed.
Basically you’re trying to create identical starting conditions for your capture every time. The advantage of the capture offset is that it will always be the same because it’s not subject to the whims of a multi-tasking OS.
So, you have three things you can tweak: the time between captures, the capture offset, and what the target is doing between trigger and capture. By playing with these, hopefully you can sufficiently reduce the variation in your measurements.
