Attacking CW308T-S6LX9 FPGA target with CPA does not uncover the keys


I’m using the CPA based tutorial below, but changing target to CW308T-S6LX9 FPGA. However, it does not uncover the correct keys.
Anyone tried this?



You’ll need to use a different leakage model, as explained in the tutorial for our other FPGA target:

If you’re using CW5 you’ll also need to use the develop branch in order to pick up this fix.



I’m using CW5 but on Vbox VM. Is there a tutorial on how to load that fix into my VM?


There is no tutorial. If you’re keen on using the VM you should be able to backport the changes without much difficulty. I don’t remember off the top of my head where the code resides inside the VM, but you can find out by running this in your Jupyter session:

import chipwhisperer as cw

Having said that, I recommend installing the develop branch. Follow the instructions here.



Still not getting the correct guesses!
Here’s what I did:

I used this tutorial to capture the 5000 traces, then saved the project under a name. “tutorial-pa-cpa-2-openadc-cwlitexmega”
So the traces are captured with the scope settings in the helper scripts “Setup_Generic”.

Them I used this other tutorial, but started at the “Attack” section, set the project_file to the above name, and ran the attack.

Anything I’m not doing correctly?


1- What do your traces look like? If you’re running the xmega script to capture your traces, it’s using ADC gain settings tuned to the xmega target and you likely need to adjust for the FPGA target. Always a good idea to look at your traces. You should also shorten the capture since the FPGA AES implementation takes a lot less clock cycles than the xmega.

2- What happens when your run the attack? Is it converging towards the correct key?


  1. Here’s my trace and the scope settings. The number of samples is 129.

  1. The correlation actually converges toward zero during the attack. Now remember that the leakage model is ‘last_round_state_diff’. So we’re not recovering the actual key but the key of the last AES round.
    However I’m not getting a big difference between the best correlation and the next, as shown below.


Trace looks great! I have to ask: are you 100% sure that’s you’re running the fixed attack code?
If you changed the code in the VM, did you re-start the kernel after changing the code?

The way the attack works with the last_round_state_diff model is that it will show the PGE and key guess (highlighted red) for the round 10 key (e.g. not the key that you fed the FPGA). The notebook then rolls the key expansion backwards to get back to the original key.



Ya I’m pretty sure I have these changes in the VM. I restarted the VM a couple times for various reasons. So I have that in the kernel.
During the attack, the correct key (red) bounces around in out of the of the display window. Ultimately the correlation coefficients stopped in the single digit (4-6) percentage.
Anything else I can try? Any tweak to the CPA algo?