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

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Thanks for good comments and suggestions.

Peter Stuge wrote:
> 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. :\

Good points.

I think we stick with the SPI interface. The current interface will need
to be updated a bit. The good thing is that the low level clock, data
in, data out part of it has been tested and used up to mbps speeds.


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

Hmm. Having board level filters is good suggestion. The two things that
I'm worried about are:

1. Glitches and unintended loss of master keys. If legitimate Cryptech
users loose their master key and thus all other keys, secrets protected
by the Cryptech HSM, the viability of the Cryptech HSM as a usaable
device will quite probably take a serious (fatal) dent. This must not
happen. We thus need to ensure that we can kill the master key. But not
make the system more vulnerable to glitches.


2. System state confusion. The MKM, esp as a somewhat smarter device
than a simple SRAM needs to know the state of the key (has it been set
or not, is it time to flip its bits to protect against remanence).
Pulling reset will cause state confusion. This however is a design
issue. We can design the FSM logic in such a way that if the key is
really gone, the FSM can know (and inform the rest of the system) about it.

So, 1 is much more important to ensure/solve than 2. If you (and Pavel)
think it can be solved asynchronously then ok.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Assured AB
========================================================================

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJa8ZlVAAoJEF3cfFQkIuyNjJYP/ivOwIg85JRFCuxCFFyCyIoA
2B1d1fNQey1rBdMmp49XhkZumP9lP3qy1Pmdb1WGJrfVknGBY4vCEVChqER0IawJ
RBuQ+f+cHB5lAV7p6YAFa90kkkcgSHYp+K8EZ8UHTMmp+zw3pyTkVDyk6S6q7l/r
qKwLuksZZhoiG0rPfKMyH81i1apuCKLsXt/sxI5dDT6NDj+DYJWrUQsvX4ougU30
c2uP/cO2j5nfwaYKHtJ/thVVW5ZdP37QqRk4IcELG7REtyBbcyCXMuPHWTArqXWI
gDq66tjgusFrvNguV6n48ao8Lok6lqD4w835MGW/ld/BZqdedkeUjTgBU803C4Z0
UkSDNsQ3sMSZZyl2Ss4Dtuq7w/2toy7Gqtldcu8a9SioaNUqZSSqGFMh31G8vJk0
fWLuyE9AFXkIfoY17z87S0QteVA7c90QIl5wRnhuV0QjleLEAXJTKZWo/+CsiVBx
VXNSa+ptKA9foGOWIWMaekfq//EIWx5C8U137yvuyBvhrkP7pVtl03GY7LXM0eHY
9AI5uK/D8LVscpCl0LGw1YSdMudiOHT5hlYga8jbEVEif8xpG4Q5rW0hAWHKaWst
IOh+PHIeA0lVcqdCid588ZHNN0IeCG7cfOYXheZa5IIR1ggQseNmPXr3mVD26LYf
mqUm1+ctVu9YGD5h/Fdh
=EARy
-----END PGP SIGNATURE-----