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

[Rob Austein]

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...).
Otherwise, approximately what I thought we'd be doing on the bridge
board.

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.

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

At the moment, we don't have an RSA signing core, just a modexp core;
RSA itself (including the CRT logic) is implemented in C, with modexp
as a hardware assist.  Without an RSA signer core, there's little
point in trying to restrict RSA private keys to the FPGA.

> For EC at least the private key could be generated
> totally inside the FPGA (it is after all just a random number). The
> public EC keys could probably also be generated inside the FPGA.

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

> >> implying that we'll have some magic storage core implemented in the
> >> FPGA and that keys will (somehow) be transformed from their 
> >> encrypted form into the forms (sometimes a bit odd) needed by the 
> >> various crypto cores.
> > 
> > Maybe the MKM can take care of all odd transformations?
> 
> No, the MKM is just that, a memory. It is not capable of doing any
> transformations by itself. The FPGA however would be able to do so
> given the correct core.

Yep.

> We will need to have a MKM core anyway that initially provides an
> interface to the memory (an i2c interface). But later also generates a
> master key inside the FPGA, provides key bit rotation and key movement
> to protect against remanence effects. Having key wrap here would be
> possible too.

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.

> >> At the moment, what I have is software and conventional memory,
> >> and unless somebody tells me otherwise, I assume that's what we're
> >> to be using for the bridge board implementation.  Are we expecting
> >> to do better than this on the Alpha board?
> 
> In time, yes. The Alpha board provides the infrastructure in terms of
> components and space inside the FPGA to do key wrapping inside the FPGA.

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.