-----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----- _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
