[Cryptech Tech] Lattice boards for developing a custom master key memory

Peter Stuge peter at stuge.se
Sat May 5 10:09:29 UTC 2018


Joachim Strömbergson wrote:
> > I like this idea, but I would definitely stick with a synchronous
> > bus such as SPI.
> 
> What would you say are the main reasons for using SPI?

It makes everything explicit.

Timing and packet/message/command boundaries are each given an
explicit signal, which allows for very clear and IMO simple behavior.


> To me, a UART is simpler to not screw up.

Perhaps the UART itself, but please also consider the layers above it.

With a byte stream, all protocol state changes are data-dependant -
timing and all boundaries are implicit. This makes it impossible to
separate framing from message processing, essentially forcing a
layering violation. :\


> We have a simplistic SPI master for the current master key serial SRAM.
> But it would need to be extended to be able to handle other
> records/commands etc.

Since both ends of this connection are made by CrypTech, we are
now able to design the communication protocol as we see fit.


> The chief disadvantage I see is performance.

I also don't consider performance on this connection a priority.


> > The iCEstick includes an FTDI USB chip for easy flashing, but only 
> > has 24 IOs spread over three connectors, only has a 12 MHz
> > oscillator and is designed to only be powered via USB.
> > 
> > Note that HX1K has no PLL in the VQ100 package used on both these 
> > boards, so no clock can run faster than the oscillator. But a good
> > design should not rely on a clock for tamper detect anyway, I think
> > that should be asynchronous.
> 
> Good point on power supply. The stick would only be used for testing and
> prototype development. Then we either have to design our own board that
> fits on top of Alpha headers, or adapt something like the TinyFPGA
> board. I think the stick is a good start for now.
> 
> As far as I see it, 24 I/Os are more than plenty (a few I/Os for the
> interface, one or two for tamper detect and possibly a few for debug)

All right.


> Regarding the clocking. The control FSM handling storage including
> tamper reaction will be clocked.
> 
> The tamper event inputs needs to at least be sampled in a proper manner.
> Just having a level input that pulls the reset of a register sounds to
> me like asking for an over sensitive system that will cause reliability
> issues and bad surprises. Please, explain why this would be good design.
> I'm probably missing something smart.

I would like an asynchronous input and for any signal filtering to stay
outside the MKM, in order to achieve the minimum tamper response time.

The 12 MHz iCEstick clock has an 83 ns period.

That's almost 20 times the latency of an iCE40HX global input (5.00 ns
tCO Clock to Output - PIO Output Register (Using Global Buffer clock
without PLL) on p.28 of iCE40LPHXFamilyDataSheet.pdf DS1040) for one
single sample...


//Peter


More information about the Tech mailing list