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

Vasily Dolmatov dol at reedcat.net
Thu May 10 13:46:03 UTC 2018



> 10 мая 2018 г., в 15:32, Pavel Shatov <meisterpaul1 at yandex.ru> написал(а):
> 
> 08.05.2018 15:39, Joachim Strömbergson пишет:
> 
>> Pavel Shatov wrote:
>>> 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.
>> As long as we can guarantee (as in really guarantee) that we never
>> get a drop on the input by mistake (glitches, drops etc) then sure Your, Stuges and Fredriks knowledge on supply, board design, signal integrity will be needed here.
> 
> I kind of understand Peter's concerns about register's reset input being
> over sensitive and that potentially it can react to a glitch, but, well,
> taper detection input is supposed to be sensitive, isn't it? I believe
> that with careful board design we can avoid any glitches. I may be
> wrong, but what I understood from Jacob's talk during the f2f was that
> reaction time is very important. In that sense not having any
> synchronous elements between tamper inputs and flip-flop reset inputs is
> more attractive, because if we want to sample inputs pins, we need at
> least a 2-stage synchronizer to not run into metastability, so the
> reaction time will be 3 clock cycles at least.
3 clock cycles - how many microseconds? ;)

I wonder the possibility of accessing master key storage chip  and extracting keys from it in ___ (please fill in the number ;) ) microseconds after for instance opening the surrounding case.

The possibility of accidentally wiping the keys without _real_ reason seems more harmful to me.

dol@


> 
> 
> -- 
> With best regards,
> Pavel Shatov
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cryptech.is/archives/tech/attachments/20180510/a077d576/attachment.html>


More information about the Tech mailing list