Running the PA_DPA_3-AES_DPA_Attack script on the XMega board I get the following warning when capturing traces, “Trigger not found in ADC data. No data reported!”. The script also fails to read the correct key. Only 2 or so bytes are correct.
This might be a but with some specific settings of scope.adc.offset or similar. If you try bumping it around a bit does it still happen? Also if you can increase the scope.adc.samples (say set it to 3000) might help understand if it’s just some borderline problem.
For some reason this attack works well on the arm boards. The CW308T-STM32F3 board for example is the normal one we use (which is same chip on CWLITEARM target). The CW308T-STM32F3 requires a base-board however, it doesn’t plug directly into the CWLITE Capture side.
The quick solution is if you pick up a CW308 Kit (part number NAE-CW308-04), this includes an CW308T-STM32F3 target with the “UFO Baseboard”. You can then run the build as the “CWLITEARM” (the CWLITEARM includes the same target as the STM32F3 target board).
Will try to replicate the no data message. Not sure why you see it there but not in other tutorials, could just be a problem with the firmware or something not sending trigger out as expected (but it should be the same firmware even between the DPA & CPA attack).
Yes - the UFO board basically supports almost all sample attacks - it works a lot better with the glitching tutorials as well (in our experience).
As it has both the XMEGA & STM32F3 you can do tutorials that only work on Arm or XMEGA respectively. If you want to perform a hardware AES attack, you need an additional target such as the CW308T-STM32F4HWC (which has a hardware AES accelerator, the “normal” included targets don’t for export compliance reasons).
The single-board solutions have either the XMEGA or STM32F3 targets. Either way you’ll have some (but not all) tutorials possible - if you’ve got the 2-part now for example you can do the SPA attack on RSA that you wouldn’t be able to do with a STM32F3 board (NAE-CWLITE-ARM). With the 2-part you can later connect to external targets, so it has the advantage over the single-board solutions there.
We can check into the DPA attack on the XMEGA with your setup - it should work eventually but with more traces (it was working at one point for sure).
Also - I checked the DPA on an external XMEGA target. I think I’ve figured out what happened (and will update tutorial with more details). First, I think the compiler version may have changed which slightly affects the code location. This makes some of the defaults non-ideal.
Here i adjusted the scope.adc.offset and scope.adc.samples. On my board I noticed some clipping of the power waveform so reduced the gain (the max value is +/- 0.5 on the waveform). If you didn’t see clipping don’t adjust gain down (I was using UFO board and not the 2-part version, so the resistor is a little different):
elif PLATFORM == "CWLITEXMEGA" or PLATFORM == "CW303":
scope.gain.db = 25
scope.adc.samples = 2000
scope.adc.offset = 2300
N = 5000
The second change comes in the analysis section. Find this code:
for tnum in range(numtraces):
if (intermediate(textin_array[tnum][subkey], kguess) & 1): #LSB is 1
one_list.append(trace_array[tnum])
else:
zero_list.append(trace_array[tnum])
That block needs to have a “window” that blocks out some of the early signal for later bytes. Basically we are seeing some ‘ghost peaks’ that are confusing the algorithm. If you run the attack with only updating the offset & sample number (leaving block above as-is), you can do the plots to see the peaks for bytes 0,1,…15. We actually want to window around some of those peaks. I took a bit of a guess at the windowing locations, I found moving ahead by 50 samples worked fairly well for each byte.
for tnum in range(numtraces):
if (intermediate(textin_array[tnum][subkey], kguess) & 1): #LSB is 1
one_list.append(trace_array[tnum][subkey*50:])
else:
zero_list.append(trace_array[tnum][subkey*50:])
It wasn’t perfect still, I think the window isn’t actually ideal (I just ballparked the number). The “ghost peak” problem is fairly well-known, see for example https://eprint.iacr.org/2005/311.pdf .
Thanks for your help. I tried your code changes. It still does not get the correct key, but it is much better than before. It fails to get 4 of the bytes, where before it only got one or two. Do you think we can eventually get a reliable way of getting a key on this attack for the XMEGA?
Yup - should work fully! It needs more tuning on the window most likely - I’m going to work on updating that lab to explain how to do that (rather than just throw some “good numbers” in magically).
So will take a bit longer, but you can see with that change even how it made a much bigger difference!
We are trying to determine how to connect our board to CW. I don’t see any information on the 2-part board. Could you please direct me at any documentation on how we can do this?
Which board are you trying to connect to the ChipWhisperer? The pinout can be found here if you’re trying to connect to an external board. The CW308 has another 20pin connector on it that you can connect to the Lite via a 20pin cable if you’re using that. See the following picture for an example (replace the CWPro with the Lite):
Thanks for your help. We are trying to connect one of our parts to the CW-Lite 2-part board. What is the other connector? And, are there any instructions or specifications on how we can build our board for our chip?
In that case, this pinout tells you what each of the pins on the 20 pin connector does (power out, ground, communication lines, etc). You’ll also need an SMA connector on the other board for voltage measurement and/or glitching. The board will require the following:
20 pin connector following the pinout linked earlier
Shunt resistor between V+ (3.3V from CW or regulator output) and Vcc of microcontroller
SMA connector connected to low side of shunt resistor
Capacitors only on high side of shunt resistor
A shared clock between the ChipWhisperer and the target. The ChipWhisperer can either output a clock or take one as an input.
All IO voltages need to be 3.3V
Of course, you also have the option of making a CW308 compatible board with a shunt resistor. See: https://wiki.newae.com/CW308T-STM32F for an example of a CW308 compatible board.
@coflynn Feel free to chime in if I’m forgetting anything.