[Cryptech Tech] dev-bridge board

[Peter Stuge]

Randy Bush wrote:
> for security boundary reasons,

Unfortunately, nothing supports that argument.


> the alpha board, and any follow-on, will not have uncastrated usb.

I think "uncastrated USB" as you call it (haha) has *fewer* security
and reliability implications than a homemade parser for an unreliable
byte stream.


> we already had this discussion; let's not repeat it.

The decision is based on fear and uncertanity, not on facts. I'll keep
saying that as long as someone else claims that it helps security. :)

But I understand that you will stay with your decision.


I've offered to help with the only difficult part; USB protocol design.
I estimate that it would take a few hours to think through with Rob and
Paul. Maybe we can have a go at that if we meet sometime soon.

Now - one actually does not have to exclude the other.


What I mean is that a USB protocol does not neccessarily have to
be implemented in the STM32 - it could be implemented in another
controller which replaces the (expensive and stupid) FTDI UART.


Replacing the FTDI UART with a small USB-capable processor would
allow the best of both worlds - a UART is still the interface to
the STM32F429, but a meaningful USB protocol is the interface to
the host software.

I had forgotten that the USB interface only needs to be full speed
so I had ruled this option out.


There are tons of candidate processors to choose from. I have many
years of experience with the NXP LPC1342/43 Cortex-M3; among other
things I've used it in a workshop on how to create USB devices and
easily write host software. That material is online at http://cbs.stuge.se/

The required components given 3.3V are CPU (LQFP48), two ceramic supply
caps, a crystal, two caps for the crystal, two series resistors for USB
D+ and D-, one 1.5k 1% pull-up and one digital transistor or FET to
control USB presence from the device.

The hardware might even be simpler than for the FT232, the software
allows a good USB host protocol, and with this approach someone will
still have the pleasure of writing a serializer/deserializer, but
with the potential added benefit that they would be running quite
close together and in very similar environments - maybe allowing even
more code reuse.


//Peter