New implementation following PA_HW_CW305_1-Attacking_AES_on_an_FPGA

Greetings,

First, I implemented “PA_HW_CW305_1-Attacking_AES_on_an_FPGA” demo, and I recovered subkeys successfully. Next, I read the whitepaper, implemented " Tutorial CW305-1 Building a Project", and recovered subkeys successfully. Now I want to make a subtle change to aes_core.v or any other AES related verilog code, and observe plotted traces and recovered subkeys as part of learning the capabilities of CW products.

Therefore, I tried to change something in aes_core.v, but I got the encryption error as shown in the picture below. Every time I try to make subtle changes to verilog blocks(aes_core.v, aes_ks.v, or even cw305_reg_aes.v), I either get the error below, or I get the same result as the demo.

Is there a way that I can play around with the given AES to observe various traces and numbers of subkeys?

Target board: CW305-100T
Capture Box: CW1200

Thanks,

I suggest you simulate your modified code to debug what might have broken.

Alternatively, use ILAs to debug on-target.

Hello,

I recently ran into the same issue when trying to execute the “PA_HW_CW305_1-Attacking_AES_on_an_FPGA” attack on a custom implementation of AES-128 using CW1200 and CW305. The simulation results of the top module generates expected output (see figure below); however when I generate the bit file and use it, the attack complains about receiving a wrong ciphertext. Any help is appreciated (see figure below).

Thank you

You’ll have to debug your design to find out what’s happening; I suggest using an ILA so that you can compare against your simulation results.

Thank you for pointing that out. The “busy” output was not looking correct first when observed in the ILA’s waveform. After some minor fixes it looks fine now (see below).

Now my implementation generates the correct ciphertext; however, the attack fails. Is this attack implementation specific? I presumed that as long as the busy signal is ON during the encryption process and OFF otherwise then the attack should work?

Thank you for your help again.

No, that’s not at all how it works. The rising edge of the busy signal triggers the start of the capture. It’s important that this happens at a constant time with respect to the encryption operation.

How long “busy” is kept high has no bearing on the capture or the attack. ChipWhisperer will count how many cycles it was high, and this can be useful to know how long is the target operation (though you already know that from simulation). But you still need to set scope.adc parameters to capture what you want to capture. See this note for more on that.

Yes - that is why we teach different AES attacks for different implementations.

I recommend this notebook for learning about using the right leakage model for FPGA implementations of AES.