Hello, I need to use a separate oscilloscope to measure the side-channel leakage on CW305 and perhaps use a PC to directly communicate with the board. is it possible to run CW305 in stand-alone mode like what we do with the STM32F target? I have searched for tutorials but it seems that the documentation on this is limited.
Absolutely. Maybe the documentation and tutorial don’t say it explicitly, but if you follow the reference CW305 design (hardware/victims/cw305_artixtarget/fpga/vivado_examples/aes128_verilog/), then you’re pretty much there.
The reference design uses USB to communicate directly with the host computer. Make sure you have the target input clock to set to PLL1. Power comes from either USB or the DC jack. All that’s left for you to do is connect the trigger to your scope.
Thank you for the timely reply! I will definitely give it a try.
I have tried what you said and it does work. Currently we can use a python script to handle the communication. Additionally, can we directly use a serial port to communication with the board? Since we would like to use this board with Riscure Inspector, this would save us a lot of work with controlling the encryption using Inspector.
The reference design for our Spartan6 UFO target uses UART:
You can borrow the UART implementation from that design; I believe there are also some UART IP blocks available in Vivado.
Hi Jean-Pierre, sorry to bother, here is a follow-up question.
Now I would like to use the USB connection for serial communication, how can I mount the simpleserial protocol on the SAM3U firmware? I am finding it a bit hard to debug.
No bother - CW305 documentation around this is a bit light (we’re currently writing an application note to fill that gap). Our CW305 SAM3U firmware doesn’t support simpleserial communication. Instead, it offers a direct memory interface with an 8-bit data bus and 21-bit address bus. This interface runs at 100 MHz so it’s much higher bandwidth than simpleserial.
If you look at
capture/targets/CW305.py, you’ll see the
fpga_read methods which allow you to do reads and writes over this interface.
In our reference AES target bitfile, these reads and writes go to the registers defined in
This should point you in the right direction; let me know if you have more questions.
I should also note that this area just got a clean up over in the develop branch, on both the Python and Verilog sides; if you don’t mind being on the bleeding edge, you might find things a bit easier to follow there. However the principles remain exactly the same.
In that case, is it possible to get the SAM3U USB interface to talk with Inspector? Or as a walk-around, can I use Pico and Lecroy oscilloscopes with the Chipwhisperer Python code?
1- Do you mean connecting the CW305’s physical USB port to Inspector? That’s not how CW305 was designed to operate. “USB interface” is an overloaded term here, when I referred to USB interface in the above posts, I am talking about the parallel bus between the SAM3U and the target FPGA. This bus isn’t accessible to anything else. We call it “USB interface” because the host PC can read/write the target FPGA on this interface via the USB connection between the PC and CW305.
2- You can acquire trace with any scope and bring them in into Python. This is easiest if the scope can be controlled from Python. In the case of some Picoscopes, there is pico-python – I’m not sure of its current status but I did use it with ChipWhisperer a few years ago.
Yes I was wondering if I could make use of CW305’s physical USB-B port and let it communicate with Inspector. I am planning to test some other ciphers such as AES256 and ECC, so some parts in the communication needs to be modified.
Based on my understanding, if I want to let Inspector (or any customized third-party capturing software) communicate with CW305, the best practice would be to implement a serial port protocol in the Artix-7 FPGA and use the pins in JP3 to communicate with Inspector, is this correct?
I can’t really comment on the best way to support proprietary hardware or software. Everything in and around the CW305 is open-source, and there are several ways to interface to it; the best way for you will depend on what your needs are.
Well then, say I want to use the USB-B port for customized communication with Inspector, is this going to be practical?
If Inspector can talk to Python somehow, you could use the existing CW305 Python library. I haven’t used Inspector alas so can’t comment on how well it could work there, Riscure should have a pretty good idea of what’s needed for a Python interface (I suspect it’s possible, as it looked like some of their other stuff was talking Python).
If you are implementing your own core then, you can run the communications similar to how we do now. You’ll basically follow the ChipWhisperer examples for sending data to the target, but those functions get called by Inspector.
We have an appnote related to porting stuff to the CW305 that will likely be of interest to you! Coming “soon” (hopefully draft in next week or so).
Well sorry for the delay. We are using an old version of Inspector hence there is no Python interface provided, but we are able to implement our own interface.
I’ll briefly describe how I did it in case that some one comes across this post with the same question:
Inspector supports TCP/IP communication, so I wrote a simple socket server to handle the communication between Inspector and the CW305. (Note: The communication has to be handled by socket with bytes sent and received, HTTP servers do not work here.) This server talks to the board by invoking the CW305.py library. I have to hold on to my seat tight because the communication speed is quite amazing.
By the way, thank you for the CW305 HW ECC library, this is definitely of interest to me!
Thanks for following up - no worries on delay here, if anything it means I have less to do
But appreciate the details of the implementation - that should be very useful for anyone else & it’s great knowing it worked (and of course relevant XKCD - https://xkcd.com/979/).
Also - I think we never posted the draft link here too - see http://media.newae.com/appnotes/NAE0010_Whitepaper_CW305_AES_SCA_Attack.pdf (see later section - the earlier stuff is generic DPA information).
Most of the material has already been committed to GIT repos around however so nothing too new in there!