I’ve been running the demo on the CW305 target with an external measurement station (PicoScope). It worked perfectly and setting up everything took less than a day.
On this setup, it looks like the communication between the computer the board is the bottleneck for measurement acquisition.
I am only able to perform 280 encryption/sec without recording the traces. On targets where I can save the communication latency, I can encrypt and record go up to 6,000 encryption/sec.
To do so, I follow the guide lines of  (Fig. 2) where only a seed is sent to a controller.
Then the controller derives (based on the seed) and sends the inputs for the targets. It looks like such a thing could be implemented on the SAM3U.
Is such a feature implemented in the firmware ? I was not able to find it. If not available, do you plan to implement it ?
Have a nice day,
I don’t believe we’ve implemented it, but we did do something similar for the Ballistic Gel: https://github.com/newaetech/ChipSHOUTER-ballisticgel/blob/master/firmware/cw521/usb.c using an xor shift. It does sound like a good idea, but I can’t really give an ETA for it on our end. If you wanted to try implementing it yourself, it probably wouldn’t be too hard. The firmware for the CW305 is at https://github.com/newaetech/ChipSHOUTER-ballisticgel/blob/master/firmware/cw521/usb.c.
What interface are you talking to the AES core with?
Basically because it’s somewhat user-defined, it’s a little trickier to make a “nice” API here. If you’ve got an example can possibly try and help out as well.
i.e.: Assume using the register-based interface, if you keep the same address we use in the example AES implementation that you write key/text to it would be easier to make a more generic API. But in theory people can use any interface they want of course between the SAM3U & FPGA.
One caveat I thought of - we’re building the CW305 firmware in Atmel Studio, it didn’t have the nice stand-alone makefile that we added to other projects (like Ballistic Gel). I just pushed a commit for a “should work” Makefile (tested quickly using Ubuntu on Windows), it’s a little hacky right now as you need to run a “make clean” after every time.
If you’re using Atmel Studio the project might just open in that, which gives you debug etc.
Thanks, I am able to compile the firmware on my Linux station. I just had to
mkdir build/src/pdi before.
I had a closer look to the firmware this morning and I think that I will be able to implement such a method quite rapidly. I’ll do that by keeping the register based interface but directly writing the registers from the SAM3U and then triggering an encryption. I’ll add a few registers within the SAM3U.
My last issue is that I am not able to update the SAM3U firmware. I tried following this method https://chipwhisperer.readthedocs.io/en/latest/api.html#firmware-update but since I do not have a scope attached to the CW305, it does not work. According to CW305 - USB device not found (CW Windows) , it does look to be a bit long. Could you point out the actual instructions ?
You should be able to erase the SAM3U firmware by shorting JP5, as per sheet 8 of the CW305 datasheet, which will bring you to step 4 of the firmware update.
Hi Alex and Colin,
Thanks for all your tips, I modified and firmware and added a (bad) PRG on the SAM3U. I am now able to capture + process (SNR on all the bytes) more than 10,000 traces per second.
My modifications are Quick and Dirty but if you are interested, I can try to clean it and share it with you.
Yeah, that would be much appreciated
Whoa - 10K/second is pretty nice! Yeah that would be great to see - feel free to use your own branch etc if you don’t think it’s clean enough, but honestly we hack in a LOT of stuff directly already
I fixed the missing
pdi directory - forgot to add that one (in theory the makefile should build those directories - I didn’t bother to give you a quick fix).
We’ll update the CW305 docs too - it now lives at a new address on rtfm.newae.com as of last week. This will make it a lot easier to keep this stuff up-to-date, but those docs were also missing the ‘how to program SAM3U’ question!
I cleaned a bit my code and I did a pull request (code at https://github.com/obronchain/chipwhisperer/tree/batchrun). It turns out that we can also go up to 70k/second which is really crazy (I hoped I didn’t messed up). I used the interface between the SAM3U and the FPGA in a black box fashion. Could you describe on what protocol it is based ? I belief it is that part to allows to reach such a large throughput.
Just to illustrate a bit what it gives, I’ve a plot of the enc/second according to the “batchsize”, meaning the number of encryption triggered by the SAM3U. Basically, we see that by increasing the batchsize, we got a better throughput. The different curves are for different random inputs. The graph below is the same inputs but without using batchrun.
The two last figures are plotting the trigger (with the same scale).
By using batchRun() with a batchsize of 10 we got this
And without batchRun() we have: