[Cryptech Tech] Fwd: Re: Cryptech HSM enquiry

[Joachim Strömbergson]

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

Aloha!

First: Welcome to Cryptech! Thanks for good questions and comments. I'll
try to respond and hopefully some others from the team will be able to
chime in (and correct me if/as needed.)


Thotheolh Tay wrote:
> ---------- Forwarded message ---------- From: "Randy Bush"
> <randy at psg.com <mailto:randy at psg.com>> Date: 8 Sep 2015 2:29 pm 
> Subject: Re: Cryptech HSM enquiry To: "Thotheolh Tay"
> <twzgerald at gmail.com <mailto:twzgerald at gmail.com>> Cc:
> 
>> I noticed that the Novena board was used as the HSM. That means the
>> use of ARM and probably Xilinx were used.

That is correct. The Novena uses a i.MX6 ARM based MCU as processor and
a Spartan6 FPGA. The Alpha board will use a STM32 Cortex M4 based MCU
from ST and a Xilinx Artix-7 device. The Cryptech design is however not
esp hard coded to work on these MCUs or FPGAs, but tries to be vendor
agnostic.


>> 
>> 1.) May I know how the secret keys are stored ?

AFAIK on the Novena the keys are stored in the SD-card wrapped using AES
KEYWRAP. On the Alpha board the keys will be stored in a separate key
storage memory. They will be wrapped using AES KEYWRAP using a Key
Master Key stored in the battery backed (and tamper detect controlled) RAM.


>> 2.) I would like to know if inter-bus communications are encrypted
>> and signed as well ?

Not within the tamper boundary, that is not between the MCU and the
FPGA. The inter cores connectivity in the FPGA is not encrypted or signed.


>> 3.) Tamper resistance keystorage can be provided by smartcards or
>> SIM
> cards
>> in your Alpha board model. A JavaCard enabled smartcard may accept
>> certain smartcard protocols to process the secret key instead of
>> using a power-backed memory chip that is not tamper resistance.
>> 
>> The weakness of the Alpha board design in regards to tamper is it
>> needs to protect the entire board instead of just a chip and a huge
>> net might be less effective and efficient than a protected chip.
>> Thus, the use of smartcard(s) in such a place for the master key
>> would be advantageous.

Yes, there are a number of interesting chips that provides secure
storage. There are for example specific master key memory chips that
provides easy erasure and remanence protection.

The problem with all these chips and the reason why we don't use them in
the Alpha board design is that these chips are all closed source and
black boxes. The vendors claims that the devices works as specified, but
you don't really know. They probably do, at least most of the chips
manufactured. And for several of these security chips, if you want to
know anything material about them you need to sign a NDA or similar.

Cryptech tries to be as open as possible and not rely on security claims
that can't be verified by anybody anytime. We may fail in different
ways, but that is the ambition as far as I see it.

Therefore we want to use standard chips with as few extra appliances,
kitchen sinks and added functions that we can't provide the source code for.

We could use one of these chips and use them as Master Key Memory,
persistent key storage etc. But we wouldn't base the security on these
mechanisms. We could also ditch the TRNG from the FPGA and simply use
the TRNG in the STM32 MCU. But since we don't have the source and thus
the control we don't use it. (We could possibly use it as a third
entropy source.)


>> The master key can unwrap a subordinate key and pass it to the FPGA
>> or ARM chip which you now only need to wrap the two chips and RTC
>> in tamper shields and pot. The inter-bus can be left exposed as
>> long as chips are using end-to-encryption and signing of bus
>> messages.

The keys will be wrapped or unwrapped inside the FPGA. Outside the FPGA
they should be protected. The interface between the MKM and the FPGA
needs to be protected.


>> Things like equipping an attached display and keyboard or scroll
>> wheel
> must
>> also be secured via the display unit having it's own crypto chip
>> and same for the scroll wheel and keyboard to ensure end-to-end
>> security.

This is a good point. So far we haven't consider specifics for connected
display and keypad, but we have seen some interest in having that
functionality present in some way. JakobS is the one in the core that I
think have spent most brain activity on these matters. Jakob?

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

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJV7tdfAAoJEF3cfFQkIuyN6qQP/3bzzjWCqqczfWrTj0lVk+aP
gKF3ktTXroU+Y8TtuTDuHGeA2DdiU9ycm7pfKNGQ+5ZucHywnipYk/sSZOncCiPu
UWePusPCwKfGSw4iMOQ8mitSBRLFTEnsq1mo0YRpDdrjwDR91lO/af/OaPGCj4Rj
qyqT9a6KgncTjsPvlwcaNlQJN9nj8cxZa9iRRc+vMqSsR2wMArwzINFomRVDaMmj
BgWw1lhg8uu/BWh7hSeOPM89CylgaKVAvYPNNF3ckqfR6hfww1LECSWCpBICufGD
LUl35rL2dyR3+6ztOONSTIpVaIwwKcyq0OLL7gboBMfx2UQoGV3Rl+cQP5Pkv2cx
/b7nP6CUIIin8RrLq3LpuAH+gMIHk5+i+pQSA2iRxZ/uVFWivcjDfgvPk6/72Vhk
cbeydrN3ddaUX4k1hoNy8/Y98tIuXrVD5pF0RaJeMC1fIjQN5iwY35IaWDSN/LF0
Df8ta5IkIq8fZL4KMJt807jmWF1uUqA2Lm6Qxw2oImKVAMKLK7hcnWazvoXUayPM
eZ6ekBjW+lWrT74Neho1o9CVLd5L4ZEh+D9a72HNeOCqXFIxtynf6aVtcJcEx2QI
1TiOykf4lUcdwzqTr/j09Jx7esDHJYr2y9j0CjldFmiXq9Iulcy870+zWC1S+0Ba
AYjjpnGmdQsgQU0DY7ot
=Awjv
-----END PGP SIGNATURE-----