CW305 - CW Lite 2 CPA Attack Unsuccessful


I have implemented a CPA attack on AES running on the CW305 following the procedure described in the NAEAN0010: Power Analysis on FPGA Implementation of AES Using CW305 & ChipWhisperer white paper at NAE0010_Whitepaper_CW305_AES_SCA_Attack.pdf ( My hardware setup is also exactly the same as described in the white paper and utilizes the CW Lite 2.

I have programmed the CW305 using the provided default impl_100t bitstream verified that my CW305 indeed has a 100t variant, but unfortunately, regardless of however many traces I collect, I am unable to extract the cipher key. I have tried up until 40000 traces with no success.

Attached is the jupyter notebook containing the capture and CPA logic I am using, in addition to various graphs for analyzing CPA results such as PGE as a function of number of traces collected. (3.1 MB)

It does not seem like the attack is making any progress given an increasing number of traces, so I believe something is wrong and the attack will not improve regardless of the number traces I collect.

I have also tried utilizing last_round_state_diff leakage model instead of sbox_output as described in CW305 CPA Attack not working - Embedded Security / ChipWhisperer Hardware - NewAE Forum.
However, the last_round_state_diff leakage model did not yield a successful attack after 25K traces either.

What is causing CPA to fail like this? Are there any parameters that can be tweaked to improve the attack? Any feedback or suggestions would be greatly appreciated. Thank you.

A few things:

  1. You definitely want the last_round_state_diff leakage model.
  2. Have a look at our CW305 AES demo; it should run successfully out of the box.
  3. I don’t understand your clock setup; you’re driving the PLL0 clock to the X6 SMA, which the CW-lite can’t get. Look at the notebook above for our recommended clocking setup. I suspect this is where the issue lies. Always a good idea to look at the power traces too, it will give you a hint if something is off like this.


Utilizing the last_round_state_diff leakage model along with making the appropriate changes to the clock setup as shown in the notebook provided resolved the issue and the attack now executes successfully. Thank you for the follow up!

Great, thanks for the update! CW305 gives you a lot more clocking options than our other targets, so it’s important to understand them.

1 Like

Hi Jean-Pierre,

Follow-up question, what are the units from the trace that is plotted from the notebook you linked? I understand that the x-axis is samples. However, I do not know what the y-axis is. Is it voltage, power or some other type of magnitude?

Furthermore, I see that the notebook is setup to capture 129 samples at 4x the frequency of the crypto-core correct? How many cycles does the AES core implemented in the reference bitstream of the CW305 take to execute?

Thank you.

Answered here:

As the notebook says, “We’re only capturing 129 samples (the minimum allowed), and the encryption is completed in less than 60 samples with an x4 ADC clock. This makes sense - as we mentioned above, our AES implementation is computing each round in a single clock cycle.”

In case you haven’t noticed, there is a basic simulation testbench that you can run to see exactly what the target does:

Go there and run:

make DUMP=1
gtkwave aes.gtkw&

(you may need to install gtkwave and iverilog, which is easily done on Ubuntu with apt install ...)
You will see that the AES encryption is done in 11 clock cycles.

This attack doesn’t require knowledge of what is happening on which clock cycle; you just need to ensure that you are capturing the portion of the AES encryption that is targeted by the attack (in this case, the last round). Beyond that, the attack doesn’t require knowledge of how long the encryption takes.


1 Like

I see! That makes sense, the entirety of the AES operation does not even need to be captured. Thank you for the clarification and prompt follow up. I will take a look through those references you provided!