[Cryptech Tech] Working memory on HSM for decrypted private key components?

[Joachim Strömbergson]

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

Aloha!

Rob Austein wrote:
> At Tue, 15 Dec 2015 09:02:10 +0100, Joachim Strömbergson wrote:
>> My impression is that there has been a back and forth about this.
>> The current solution (to mu mind) is that the keys are stored in
>> external Flash controlled by the ARM. When to be used they are
>> unwrapped using AES KEYWRAP by the CPU, but using the AES-core and
>> the master key, which is only accessible from the FPGA.
> 
> Hmm, that's a variant I don't remember.  Would need a Verilog path 
> between MKM and loading the key into AES core (and, I suspect, a 
> restriction on reading the key out of the AES core in that case...).

Yes. Neither of which is not really that hard to do in HW. Basically
there would be a second set of key registers internally and when given
the command to do enc/dec with the internal key, it would be selected.

> I guess that protects the master key, thus sort of protects against 
> breach of keys that were sitting idle.  Doesn't help for private
> keys in use at time of breach.

No. The CPU could react to breach signalling. And if the keys can reside
in the FPGA even during usage (which would require changing the HW/SW
partitioning of functionality), the FPGA could have dedicated erasure
functionality that would react directly on a breach detection and kill keys.

For me the important thing is that with the Alpha board we get the
infrastructure in place in terms of FPGA, tamper MCU and MKM to support
different variations of key storage, protection etc.


>> The whole keywrap mechanism could be implemented in the FPGA which
>> would mean that keys are only used in the FPGA and not exposed in
>> cleartext.
>> 
>> But, at least for RSA keys, the CPU needs to be involved in order
>> to generate them.
> 
> Yeah, Pavel and I are both skeptical about implementing Miller-Rabin 
> in Verilog.

You are not alone. The easiest way imho would be to insert a small,
constrained CPU core and add the alg in SW for it. But that CPU would be
fairly inefficient and only run in say 100 MHz. (Could be faster
depending on core used.).


> You'd need an path from the private key generator to the point 
> multiplier.

Yes, which however is not very hard to do. The big consequence with all
these things is that the FPGA starts moving from a collection of
co-processor cores that SW can call to something that do things
independently. We would add some sort of internal controller,
arbitration (for handling/stalling commands from the CPU when the FPGA
is using the resources by itself.)


> There was a discussion this morning about maybe including a jumper
> on the Alpha board controlling whether the CPU can talk to the MKM,
> so that the as-yet-unwritten MKM core doesn't become a blocking item.
> As you describe it, the initial MKM core doesn't sound all that 
> complicated, so maybe this is a non-issue, OTOH one more jumper on a 
> prototype board is (probably) harmless.

A jumper is ok. But adding a simple interface core that provides access
to the MKM for the CPUY via the same FMC interface as other cores should
be a matter of day(s) to fix. So we could start with that and then add
MKM management features to the core.


> We might want to map out just how much new Verilog code we're
> talking about requiring to make this work and how long it is likely
> to take.

Yes. I can do a list of features with guesstimates and some sort of
roadmap. As stated above, the minimal functionality would be our std
core interface connected to something that does data and address serdes
as well as a clock generator.


- -- 
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-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJWcVwdAAoJEF3cfFQkIuyNfjUQAMxRI90Nht42LHpxvvDySKbC
LTtuTtD7PFJ/TVlncZlHNRMJoDlsnus9xzneTYZYrZliLfQniHQKidUGdt8CDWLv
7keH0CdBExRc5pXRE2HDqgXGorbxdeP/xRyb+yW3vWYcMrVS71nNid6LWE6eIEoo
PbcolyRsgJgYc19DN21deDhnB2D2I309OTvAt2wahqwzL3RuWLGk8WFIVqWZajsL
vQ8RhXUqkK2FgCs6qNHe7hgT/QYmi8Umt/0gWzAjwwD8k+g0OMQiC561Y8UjnOBS
19CwxI9Kupvk8KRRt33OSnRIXem8ze8WMVu80qIiNDLgdMKq7p3UrI+GDTMPff+F
OFi++9oB5VI9e/xNZuyF4s6btEPO7Oq3ywCsFJo0qGk1Fia24C73uLw2krnw3g0g
wDK64Tb+0d+l4NTCvzaxz9eOeiLILZ9+yfhNPkMZHX+2Gxdkd3pwkoWZ+2SwLkMU
0dJpTfO0xI6cxHaSN40TSTNPBkSx5LdYGnQqhDTkoAIG32quK46OZkhWkDYDdZpK
Zc9ai9s9wDPe8nAE0FtqHFcL81CHAQbxg/8/JGDb592U7jFo/ZPRRpbzoJM4pAfu
kSkRG1hfp1Ri6YX/gk0s8mNVdr1sXU6iH3xmi/u4SEfU8lU3HLouXe0zptOc0lra
qKKTi0kvX27UScex1kgZ
=BywB
-----END PGP SIGNATURE-----