CW305/Ibex data corrupted

Embedded Security
1

Hello! I have programmed my cw305 with a bitfile built from the Ibex demo repo for cw305, and programmed it with hello world firmware as described by cw documentation. Everything seems to work fine, but when I check the output it is something like this:

Hell/ orld!00000 01   Hnpqt F!lue: 0000 00F
Hello WorLd 000002   Input Value: 0000000F
Heldo World! 000 0 0#   Input Value* 0000 00F
Hello Wnrl$  00000004   InpuT Value: 0000000F

This isn’t consistent, and different characters are changed every time. Simpleserial aes trace captures seem to fail for the same reason. It is unlikely to be a hardware issue as I have tried the same procedure with the bitfile provided on the cw repo (not Ibex), and I was able to capture traces and break aes just fine.

Any help would be appreciated!

2

Fail how?

Which bitfile worked fine? Our pre-built Ibex bitfile, or our pure AES FPGA bitfile (i.e. the one used by this notebook?)

3

Some series of value errors followed by an ack error which aborts the capture.

(ChipWhisperer Target WARNING|File SimpleSerial.py:423) ValueError: invalid literal for int() with base 16: '\x06C'
(ChipWhisperer Target WARNING|File SimpleSerial.py:423) ValueError: invalid literal for int() with base 16: '9)'
(ChipWhisperer Target WARNING|File SimpleSerial.py:423) ValueError: invalid literal for int() with base 16: '\x054'
(ChipWhisperer Target WARNING|File SimpleSerial.py:423) ValueError: invalid literal for int() with base 16: '"0'
(ChipWhisperer Target ERROR|File SimpleSerial.py:327) Ack error, couldn't decode return z0

alternatively at the end:
(ChipWhisperer Target ERROR|File SimpleSerial.py:321) Ack error: Z00

The pure AES one worked, both prebuilt (default Setup_Ibex.ipynb) and manually built Ibex bitstreams have the same problem. It might be some uart problem with the core itself?

4

The difference between the AES and Ibex targets is that for AES, all communication is done over the 305’s USB interface. The 20-pin cable only serves to provide the target’s clock and trigger line to your capture device (CW-Lite / Husky / …).

With Ibex, target communication is over the 20-pin cable’s IO1 and IO2 lines. So I wonder if the cable is the issue. Do you have a different cable you can try? Or try wiggling it. Or, if you have a CW308 or CW313 target board, those also use IO1/IO2 – do those targets work?

5

Using a different cable did not solve the issue unfortunately

6

And have you tried a different target which uses IO1/IO2 (like any of our CW308 or CW313-based targets)?

Another thing you can do is scope the IO1/IO2 lines.

7

I have a CW308 UFO and CW308T-STM32F, but I’m not sure how this works with Ibex as the only targets seem to be CW305 and CW312. Unless you’re suggesting to try the AES application, but this might not be very informative since it’s apparently not the cable and pure AES works on the CW305?

8

I’m trying to pinpoint the problem. That you’re able to run this notebook means that your CW305 board is likely fine. The big difference between the HW AES target and Ibex is that Ibex uses the IO1/IO2 lines to communicate with your host computer (HW AES does not), and the problem you’ve observed is that communication on these lines appears unstable.

By checking whether communication works reliably with CW308 + STM32, we can get closer to figuring out the issue. So, please try this notebook, with SS_VER set to SS_VER_2_1.