I am trying to collect 100,000 trace on my chipwhisperer board at the moment. The traces below are collected using the default AES CW305 configuration that comes with chipwhisperer. As I collect traces, I get the following effect that as time goes on, the traces tend to drift.
What exactly is the cause of this, do I need to increase the buffer time to remove the effect? For now, I calculate the median of the trace to readjust it around 0 which seems to work fine for now but I am curious as to what exactly is causing this.
I’m guessing this is due to the AC-coupled measurement setup - these traces have a nonzero average. As time goes on, this offset is gradually removed by the high pass filter (the cap on the front end charges). If this pattern went on long enough, the top of those traces will probably settle a little above zero.
Is it also possible that you’re not sampling synchronously? This could explain the variable amplitude of the peaks (e.g. sometimes you’re sampling right on the clock edge and get a stronger peak, sometimes you’re sampling a bit early or late). What are your scope.adc and target clock settings?
Jean-Pierre
I Have two PLL clocks, one set at 1 MHz that goes to the FPGA(AES) and the other, set to 32 Mhz, that goes to the ADC.
target.pll.pll_outfreq_set(1E6, 1)
target.pll.pll_outfreq_set(32E6, 2)
Ok that looks fine - strike my previous comment, I’m just not used to seeing oversampled AES power traces.
I thought the last small peak in each trace was indicative of some asynchronous sampling issue but that’s probably just the end of the AES operation.
If you’re running the stock CW305 AES example, does the attack succeed in breaking the AES key in the expected number of traces?
Jean-Pierre
Yes, it is of less performance obviously but it succeeds nonetheless. I am currently collecting more traces where every 500 traces I relock the adc clock and giving it a 1 minute break to hopefully remove the sensor drift. I can update if it works.
