AES CPA attack with CW305 and Picoscope

[mattia_mirigaldi]

Hi all,

I have the CW305 target board and I’m using the PicoScope to run the attack Breaking Hardware AES on CW305 FPGA.

The jupyter notebook of my test can be found here SCA_test_jupyter/mattia_sca at master · mattiamirigaldi/SCA_test_jupyter · GitHub
There’s also an HTML file with the results of the attack.

I’m using the PicoScope 5000a series ( model: 5244D ).
One probe of the PicoScope is connected to the SMA X5 connector and it is AC coupled.
The other probe is connected to TP1 for the trigger, it is DC coupled and I’m using a threshold of 2 V (rising edge).
I’m using the pico-python library (GitHub - colinoflynn/pico-python: PicoScope Python Interface).

I have two major problems that I’m not able to fix.

1. The encrypted plaintext read from the FPGA is wrong

The target object of the CW305 is instantiated with the command
target = cw.target(None, cw.targets.CW305, fpga_id='100t', force = True)
So I’m expecting that the FPGA is programmed with the bitstream of the AES-128 HW implementation.

The plaintext to the FPGA is written with the function
target.fpga_write(target.REG_CRYPT_TEXTIN, text)

The trigger of the encryption is done by calling functions
target.fpga_write(target.REG_USER_LED, [0x01])
target.usb_trigger_toggle()

Once the trace has been captured the encrypted value is read with the function
response = target.fpga_read(target.REG_CRYPT_CIPHEROUT, 16)

To check if the read encrypted value is correct I compared to the expected one using the AES cipher.
cipher = AES.new(bytes(key), AES.MODE_ECB)
cipher.encrypt(bytes(text)
But the assertion between expected ciphertext and read one fails.

2. Trace captured are attenuated by an order of magnitude

The plot of the power trace has a pattern similar to that expected, but the voltage values captured are more or less attenuated by an order of magnitude.
I do not know why, as the probe does not perform attenuation. Does the SMA X5 connector automatically attenuate by 10?

I’ve tried the sbox_output attack, but it fails. I think it has to do with the wrong output result from the AES HW implementation.
But it may also be due to an error in how I create the Trace object.

In summary, why am I reading the wrong ciphertext, and why the traces are attenuated?

Thanks in advance for the support

[jpthibault]

1. I think you’re not getting the expected encryption result because you forgot to reverse the plaintext byte order, as we do here: https://github.com/newaetech/chipwhisperer/blob/develop/software/chipwhisperer/capture/targets/CW305.py#L558
2. The X4 output is not attenuated by the CW305 board; it’s from an LNA output: CW305 Artix FPGA Target - NewAE Hardware Product Documentation. You should increase the gain on your picoscope.

Otherwise, I would recommend:

• make sure your traces are aligned
• you’ll likely need more traces; x4 synchronous sampling usually needs about 2000 traces, so I would expect asynchronous sampling to require more (even with a higher oversampling rate)

[mattia_mirigaldi]

Hi, really thanks for the reply.
By byte-reversing the writing of the key and plaintext to CW305, the attack worked!
I first followed the example in the whitepaper(sec 5.2). It might be a good idea to specify in the paper the endianness of the CW305.

Regarding the loss in the power measurement, do you think is it due to the length of the cable, or is it due to an impendence mismatch between PicoScope and X4?

Lastly, is there any way to achieve synchronous sampling?

[jpthibault]

Ah, sorry for the confusion caused by the whitepaper; we will fix that.

If you’re using a proper cable (e.g. one that came with your picoscope), it’s unlikely that impedance mismatch or cable length are the problem; I would just increase the gain until you get a good signal range.The power measurements here are quite small; for example with our ChipWhisperer capture hardware, we set the gain to 25 dB for the CW305 AES attack.

I think that some of the higher-end Picoscope models accept an external reference clock; you can try providing one of the CW305 clock outputs as a reference and see if that improves your results.