[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