[Cryptech Core] MKM access from FPGA

Paul Selkirk paul at psgd.org
Wed May 25 04:57:52 UTC 2016


tl;dr: I've been trying to validate Joachim's mkmif core, with limited
success. As in, I read 0xffffffff from all locations.

To play along, get an alpha board, an st-link programmer, a large cup of
coffee, and a fully-updated set of repos.

To build the bitstream, go to core/platform/alpha/build, and run 'make
mkmif'. This builds a minimal bitstream with just the mkmif core.

To configure it onto the alpha, go to sw/stm32, build cli-test ('make
cli-test'), and flash it onto the ARM ('bin/flash-target
project/cli-test/cli-test'). Attach a USB cable to the MGMT interface
(the one on the right), and run 'projects/cli-test/filetransfer --fpga
../../core/platform/alpha/build/alpha_fmc_mkmif.bit'. Reboot the board
after updating the FPGA configuration.

(Tangent #1: For fun, run this under 'time' - it takes 11m40.614s at
921600 baud. The bitstream file is apparently a full image of the FPGA,
so it's 9.73MB, give or take a few bytes for the length of the file
name. This particular build compresses down to 47KB (99.5% compression
rate), which would save 105 seconds of transmission time. But we still
have to deal with the nearly 10 minutes that it takes to write to flash.
This should really be its own topic.)

To test, stay in sw/stm32, build test-mkmif ('make libhal-test'), and
flash it onto the ARM ('bin/flash-target
project/libhal-test/test-mkmif'). Move the USB cable to the DATA
interface (the one on the left), and watch the results.

(Tangent #2: 921600 is above the max speed supported by screen, so
you'll need to use something like picocom.)

What I see is this:

Trying to adjust the clockspeed.
write  020a [ 00 00 00 20 ]
read   020a [ 00 00 00 20 ]
Trying to init to the memory in continuous mode.
write  0208 [ 00 00 00 04 ]
read   0209 [ 00 00 00 02 ]
read   0209 [ 00 00 00 03 ]
Trying to write 0xdeadbeef to the memory and then read back.
write  0210 [ 00 00 00 00 ]
write  0220 [ de ad be ef ]
write  0208 [ 00 00 00 02 ]
read   0209 [ 00 00 00 02 ]
read   0209 [ 00 00 00 03 ]
write  0210 [ 00 00 00 00 ]
write  0208 [ 00 00 00 01 ]
read   0209 [ 00 00 00 00 ]
read   0209 [ 00 00 00 03 ]
read   0209 [ 00 00 00 03 ]
read   0220 [ ff ff ff ff ]
read ffffffff, expected deadbeef

There's way too much byte-swapping in the code, but the tracelog above
convinces me that I'm writing the write bits to the right registers.

I *think* I originally mixed up miso and mosi in the .ucf file, so I
corrected that, but with no change in output.

The schematic has a  comment "CS pull-up to disable MKM by default
(allows programming of AVR)." To effect this pull-up, I installed the
"battery" jumper in JP4, and went from reading all 1's to all 0's.
Change is not necessarily progress.

As I understand it, Joachim developed this core on the Novena, talking
directly to a 23K640 memory chip on a breadboard (not through a
MC74AC244DW line driver/switch).

I'm sure I'm missing something simple and obvious (along the lines of
miso/mosi or a jumper), but I can't see what it is.

MKM is important to this project. We need to show that we can sequester
the master key, and blow it away if the device is tampered (even if the
"tamper" is just a panic button).

				paul


More information about the Core mailing list