CW305 - trying to burn custom AES on FPGA but can't capture traces

Embedded Security ChipWhisperer Hardware
#1

Hi,
I’m working at a company that makes its own AES implementation in verilog. I wanted to pen-test that implementation and try different attacks on it.

To make things simpler, what I did was to take the working AES vivado project that comes with the tutorials and replace the ‘aes_core.v’ file with ours while keeping all the interfaces the same (input and outputs). It passed the synthesizing and implementation, generating bitstream and no timing errors whatsoever.

To simplify it even more, I am using the “Breaking Hardware AES on CW305 FPGA” tutorial the same way but with my new bitstream instead of the original project’s one.

The problem is that I can’t capture any traces and get the following output:

WARNING:root:Timeout in OpenADC capture(), trigger FORCED
WARNING:root:Timeout in OpenADC capture(), trigger FORCED

I’ve been trying to change the PLL clocks but it didn’t work.

  1. Can you guess what the root problem might be?
  2. Is there any way to debug this? (I’m new to Vivado, some guidance would be appreciated)

Thank you,
Ohad.

#2

Hi Ohad,

The error message you get indicates that the ChipWhisperer capture hardware isn’t receiving a trigger input. The trigger is carried on the IO4 pin of the 20-pin connector. The trigger must be generated by the target when it begins encryption. In the reference design, it’s this line in cw305_top.v:

assign tio_trigger = aes_busy;

So, the first thing I would check is whether your AES core is providing this signal. If you think it is, you can confirm it by looking at the IO4 pin with a logic analyzer. It is meant to be low when the encryption core is idle, and high when it is encrypting. The 0 -> 1 transition is what triggers the CW to start capturing power samples.

The next thing to look at is whether clocks are properly routed: as noted in the tutorial, you need to set the J16 dip switch to 0, and K16 to 1.

Were you able to run the CW305 tutorial on the reference target? If you haven’t yet, I recommend that you do, it will help narrow down whether your problem lies with your custom AES core or not.

Once you’ve established that you can run the attack on the reference bitfile successfully, then you can move on to why things aren’t working with your own AES core. Consider adding an ILA to the design to probe internal signals and see what’s going on. If you’re new to ILAs, Xilinx has lots of material showing how to instantiate and use ILAs.

Regards,
Jean-Pierre

1 Like
#3

Thank you for your helpful response!

I suspected ‘aes_busy’ but I didn’t understand how to use the ILAs to prove it. I was able to setup a debug for it but I need to further learn how to use it.

Also, I did try the tutorial as it was before my changes and it worked fine and the pins are properly set. I simulated my aes_core.v alone (without the cw305_top.v and the other files, on a different environment) and I can see the busy become 1 just one clock after the key and data are being loaded. Also, a few clocks later the correct output appear and busy goes back to 0. So I guess it should work.

I’ll try using the ILA and see if I find the problem.

Thanks again,
Ohad.

#4

Hi all,

Just an update for future reference to anyone that will have the same problem.
Found the problem and it really was that the aes_busy was stuck on high in my design. The root cause for this in my case was that my implementation uses a reset input and I used usb_trigger as reset, which goes high when sending data (or something close to that) but my reset should be high for a single clock and not for the whole process of course. This problem caused aes_busy to stay high forever.

Thanks again for the help Jean-Pierre!
Ohad.

#5

Awesome, glad to hear that and thank you for the update.
Jean-Pierre