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?

tutorial-pa-cpa-2-openadc-cwlitexmega

You’ll need to use a different leakage model, as explained in the tutorial for our other FPGA target: https://github.com/newaetech/chipwhisperer-jupyter/blob/master/PA_HW_CW305_1-Attacking_AES_on_an_FPGA.ipynb

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

Jean-Pierre

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
cw.__file__

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

Jean-Pierre

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?

Jean-Pierre

  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.

Jean-Pierre

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?

I manually added 5.1.2 changes to my VM by replacing “processKnownKey” with “process_known_key” in the files given. But do I need to anything about the statement highlighted below that appears in the change header? What do I do specifically for that?

"Fix PGE calculation and known key highlighting.

This was broken for attacks which don’t target the base key, due to a
mix of process_known_key and processKnownKey. Changed all remaining
camelCase to snake_case."

Hi,

I’m not sure I follow – “changed all remaining camelCase to snake_case” is what you did by replacing “processKnownKey” with “process_known_key”.

That’s not the only change in the commit however, which may be why you’re still not having success.

We released CW 5.1.3 a few weeks ago, which incorporates the fix, so just install that, no need to patch anything, and you should be good to go.

Jean-Pierre

I downloaded and installed 5.1.3 64bit version, but there’re references to variable “processKnownKey” instead of “process_known_key”. for example, see below from algorithmsbase.py, lines 66-67
What’s the process for manual patch?

def processKnownKey(self, inpkey):
    return self.model.processKnownKey(inpkey)

Also, I uninstalled everything and download the .zip source code. Then ran the install commands. When I run the second command " pip install -r jupyter/requirements.txt --user", i get the following error"

ERROR: Could not open requirements file: [Errno 2] No such file or directory: ‘jupyter/requirements.txt’.

I checked the jupyter folder and it is empty.

The first command seems to have run successfully. Here’s the output:
"
(base) PS C:\Chipwhisperer\chipwhisperer-5.1.3> python -m pip install -e . --user
Obtaining file:///C:/Chipwhisperer/chipwhisperer-5.1.3
Requirement already satisfied: configobj in c:\users\atmozipo\appdata\roaming\python\python37\site-packages (from chipwhisperer==5.1.3) (5.0.6)
Requirement already satisfied: pyserial in c:\users\atmozipo\appdata\roaming\python\python37\site-packages (from chipwhisperer==5.1.3) (3.4)
Requirement already satisfied: numpy in c:\programdata\anaconda3\lib\site-packages (from chipwhisperer==5.1.3) (1.16.4)
Requirement already satisfied: pyusb in c:\users\atmozipo\appdata\roaming\python\python37\site-packages (from chipwhisperer==5.1.3) (1.0.2)
Requirement already satisfied: scipy in c:\programdata\anaconda3\lib\site-packages (from chipwhisperer==5.1.3) (1.2.1)
Requirement already satisfied: six in c:\users\atmozipo\appdata\roaming\python\python37\site-packages (from configobj->chipwhisperer==5.1.3) (1.11.0)
Installing collected packages: chipwhisperer
Running setup.py develop for chipwhisperer
Successfully installed chipwhisperer
"

That’s very strange. I’ve just checked the git 5.1.3 tag, the VM, the .zip, and the .tgz downloads and none of them have references to processKnownKey.
Can you double-check that you’ve downloaded what you think you downloaded, and that you checked what you think you checked? :wink:

Re: Jupyter, the release page does say as much!
" NOTE: The source releases do NOT include the jupyter submodule."
You can download the Jupyter submodule separately from here.

BTW just to be sure I ran the CW305 tutorial with the 5.1.3 VM and it works as expected.

Jean-Pierre