[Cryptech Tech] USB interface

[Peter Stuge]

Hi,

I've proposed a different USB interface than the FTDI chips used on the
Alpha a few times.

I described it again to Joachim off-list, he requested that I post here,
so here we go.

Background:
On the Alpha PCB the STM32 has one 3.3V UART for the USER port and
another 3.3V UART for the MGMT port. These connect to two FTDI chips,
which then go to the USB connectors on the edge of the board/box.

Proposal:
Replace FTDI(s) with small MCU(s) with a programmable USB peripheral.

This could be done only for USER, or for both USER and MGMT. The two
are unrelated, but the advantages of replacing FTDI hold for both ports.

The particular MCU I propose is an Atmel SAMD11. This is a small ARM
Cortex-M0+ with a hardware USB peripheral and clock recovery from USB.

Rationale:
* Programmable USB hardware enables a PC-facing interface tailored to
applications rather than forcing applications to tailor to the HSM.

* The FTDI chip is limited to one specific USB behavior.
(And the implementation is particularly wasteful and noisy.)

* The interface in the STM32 can change independently of PC software.

* The USB interface seen by the PC can change independently of STM32 firmware.
(We've toyed with the idea of appearing as a USB network interface.)

* USB has fields such as "device version" and "device protocol".

* USB hardware handles checksums and transmission errors/retransmission.
The RPC protocol could probably be simplified, reducing code complexity.

* ARM Cortex-M allows interface code reuse between STM32 and SAMD.
(Not register level, but as much above that as we find useful.)

* USB clock recovery (fairly unique to SAMD) means very simple hardware.
The FTDI chip and and supporting components would be replaced by three
components; SAMD, one pullup on its SWDIO pin, and an SWD header. 3.3V
has plenty of capacitance elsewhere and clock recovery makes a crystal
unneccessary.

Drawbacks:
* Programmable USB hardware means that someone has to program it.

Linus and I are doing this in our project. I've created a (new)
daugtherboard for the Alpha USER port, with a USB hub, a SAMD11 and a
CMSIS-DAP SWD debugger (in a second SAMD11), for convenient iteration
through a single cable. This is obviously for development only.
A production version would have nothing but the SAMD11.

I've used the SAMD11 several times but I haven't yet pushed the UART
so fast, and SAMD11 hardware architecture (UART has only 1 byte FIFO)
means that the firmware must set up DMA, which is where I am at. I
think Paul had this on the STM32 already. Polling and interrupts are
both too slow.

If someone is genuinely interested in this daughterboard we can talk
about getting you one.


Security implications:
* I can think of no negative security implications with this change.
The SAMD11 is not reprogrammable via its USB port, only via its SWD pins.

* I do not propose to implement the USB interface in the STM32, even
though this is technically possible, and no less secure.

* Positive security implications are imaginable.
The new flexibility in how the device appears in the PC means that
permissions can be managed in ways other than what is possible through
the TTY subsystem.


Backward compatibility:
* It is possible to create a firmware to make SAMD11 backwards compatible
with the FTDI interface. Either by replicating the FTDI protocol 100% or
as a standardized (and less inefficient) CDC-ACM interface. Admittedly,
CDC-ACM is really only for analog line modems accepting AT commands, but
there is some precedent for abusing CDC-ACM to get USB-UART, and at least
it is a standardized device class.


I appreciate any thoughts or questions you have on this.


Kind regards

//Peter