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

[Pavel Shatov]

05.05.2018 13:09, Peter Stuge пишет:
> 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.
> 

I tend to agree with Peter, in my opinion SPI seems more appropriate.

> 
>> 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...
> 

Speaking of asynchronous signals, I think the original idea was to have 
several tamper detection inputs in the tiny MKM FPGA. Suppose that they 
are active-low, this way as soon as a tamper event from a certain sensor 
is detected, the corresponding input goes low. Tamper detection inputs 
can be AND'ed together and routed to the reset signals of the flops 
where the master key stored. This way the master key can we wiped 
asynchronously and even if the clock signal is stopped for whatever reason.


-- 
With best regards,
Pavel Shatov