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

[Rob Austein]

Something I know we've discussed, but for which we do not, as far as I
know, have a coherent plan for at the moment, at least not one that
tells me what I should be doing with software for the bridge and alpha
boards.

So we have this nice master key memory where we keep a symmetric key
which we use to encrypt all the private keys; the master key memory is
connected to the tamper circuit, so on any form of tampering, the
master key goes poof, or so goes the theory.  All well and good.

Stable storage of private keys is encrypted with the master key, so it
can be in flash or whatever, no connection to tamper circuitry
required.  Again, all well and good.

But to use those private keys, we have to decrypt them.  Where do we
place the decrypted private key components?  Conventional volatile
memory and hope it goes poof on its own?  Presumably not, since if we
believed that was sufficient we wouldn't need the master key memory.

Maybe we just make the master key memory big enough to hold working
memory for private keys, or add a similar memory-with-poof-circuit for
working memory, or something like that?  But I seem to recall that
power needed to wipe master key memory on tamper is an issue, so the
larger this memory, the more stored power we need to wipe it.  Maybe.

At one point I was hearing muttering about private keys never leaving
the FPGA, 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.  AFAIK this, if not just fevered hallucination
on my part, does not exist in any of the existing designs, so it's
more of an intention than something we can evaluate, much less use.

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?

No blame attached to anybody, of course, except maybe me if we have a
solution and I've just completely spaced on what it is.  I'm bringing
this up now because Paul and I tripped over it a few days ago, and it
may be something we want to think through before declaring victory on
schematics for the Alpha board.