I was playing around the bitfile generation on CW305. I followed steps for CW305-Arm-DesignStart on the github and wanted to try ARTIX-7 CPA ATTACK.ipynb on the jupyter to make sure that I am on the right track. Therefore, I tried this part after bitfile generation was completed :
I have a “defines.v” file on my xilinx vivado, but I am not sure if I should add cw305_defines.v too. If you think that is the problem, please let me know how I can do that.
I don’t know what is ARTIX-7 CPA ATTACK.ipynb – it’s not one of our notebooks.
As explained here, you can run our AES attack notebooks (assuming of course that you’ve used our AES target firmware), with one modification: you’ll need to call Setup_DesignStart,ipynb instead of Setup_Generic.ipynb.
Hi jpthibault,
First of all, sorry for the confusion. The title was written too professionally that’s why I thought that it was your notebook I forgot to say that the target device was CW305. I traced your advice (thanks!) and decided to add “slurp=False” to my program target. It worked and completed the attack. However, I am not able to recover the correct encryption key, so I am planning to increase the number of traces, do you think it works or what would you do when you came up with this problem?
I have successfully completed CW305-Arm-DesignStart and generated bitstream. I have been trying to implement PA_HW_CW305_1-Attacking_AES_on_an_FPGA located in jupyter/archive.
I adjusted the capture setup using Setup_DesignStart.ipynb and kept trace capture, attack and test as is. When I scope the target, blue led (LED 6) turns on and it toggles when I start capturing traces. In addition, green led(LED 5) is off, and red led(LED6) toggles periodically so I am sure that clock signal and uart communication are good.
I followed arm-design-start guide and didn’t change anything in verilog, but I am not able to recover none of key bytes but two. If you see what I missed out, I am willing to hear.
As its says in its introduciton PA_HW_CW305_1-Attacking_AES_on_an_FPGA shows how to break a hardware AES target, which is not what you have here with the CW305-Arm-DesignStart project.
The DesignStart project gives you an FPGA-based Arm Cortex core which does not contain hardware AES; assuming that you compiled the simpleserial-aes firmware for it, it’s running software-based AES; basically the same target that you would be running on our STM32 target. Now the Arm core is in an FPGA instead of an ASIC; that does not mean you need to attack it like you would a hardware target.