[Cryptech Tech] dev-bridge board

[Peter Stuge]

Hi Paul,

Paul Selkirk wrote:
> Current status: I have a stable build/test environment for the
> dev-bridge board. Everything is in the sw/stm32 repo. This builds
> Fredrik's board self-tests "natively", and builds Rob's libhal tests
> with a thin wrapper around main(), and some missing libc support functions.

Cool!


> We are currently hashing out a libhal RPC mechanism to allow a PKCS #11
> application running on a host to talk to the STM32 (and thus the FPGA)
> over USB.
> 
> I have a few questions I'm not qualified to answer, because I don't
> understand the board well enough.
> 
> 1) I'm currently using the USB as a UART. On the host side, I read and
> write bytes over /dev/ttyUSB0. Is this sufficient/acceptable,

In my humble opinion it is not.


> or should we try to use the USB Device interface? And if we do that,
> what device class? 0x0B Smart Card, I guess?

Two choices:

* Either implement CCID and look and quack like a duck, to be
  compatible with GnuPG and (OpenSC and pcsc-lite), of which the
  latter is not really stellar code. The former I have little
  experience with.

* Or implement a vendor-specific, publically documented, interface.

The latter, along with making a small bend to the side for Microsoft,
allows the hardware to work plug-and-play across all common OSes with
immediate userspace access to USB communication e.g. via libusb,
without kernel drivers involved.


Many initially believe that vendor-specific is somehow dirty and must
be avoided at all cost, but when doing something that does not 100%
fit one of the standardized device classes then a vendor-specific
interface is not only perfectly fine, but indeed the only wise choice.

How dirty an interface is depends on how well documented it is, not
whether it is using a standardized device class.


> But that path ends in implementing a CCID or PC/SC interface on the
> device, so I'd rather avoid that.

Please let's avoid that. Neither T=0 nor T=1 have a place in a modern
implementation of anything involving security.

USB natively allows and enables structured communication directly
from the application code to the device code - it is pointless and
redundant to mess around with any kind of serialization or other
framing, on top of an emulated stream (ACM/ttyUSB) on top of a
structured transport (USB).


What operations does the p11 need to access?


> 2) Can we use a portion of the ARM internal flash memory for data
> storage? If so, what address range?

Others can answer this better, but in general I can say that all
Cortex-M chips I've seen can write to internal flash from application
code.


> 3) How do we access the Master Key Memory? I see that it's a 23K640-I/SN
> 64K SPI Bus Low-Power Serial SRAM. Is there code to talk to it?
> HAL_SPI_MODULE_ENABLED is not defined in the default HAL configuration.

I guess someone needs to implement the SPI protocol to access it.
It's pretty straight-forward; send a READ (03h) command followed by
24 bit address, then read back as much data back as you want and the
chip supports. Some SPI memory increment the address over their
entire size on READ, some only support reading a page at a time this
way.


//Peter