[Cryptech Core] auto-zeroise vs integrated mkmif

[Paul Selkirk]

On 1/17/19 7:43 AM, Joachim Strömbergson wrote:
> I've now completed the auto-zeroise functionality for the keywrap core.
> The functionality works and does not interfere with long wrap/unwrap
> operations. Basically the functionality allows SW to:
> 
>   1. Set an key expiration time for a loaded key.
>   2. Keep a key alive by either performing wrap/unwrap operations, or
>   3. Checking status of the core (which resets the timeout counter).
>   4. If needed pull zeroise to directly force key zeroisation.

I've finally updated the driver, and tested the auto-zeroise
functionality. It does what it says on the box, but I spent a while
testing the edges.

For testing, I added some stats (how many times the KEK did or didn't
have to be loaded), which we may or may not want to keep if this reaches
production. Testing was done with unit-tests.py, test-rpc_pkey.c, and
(mostly) parallel-signatures.py.

The default timeout is 0x4000000 (67M) FPGA clock cycles, or 1.342 sec.
For any given run, we can see the KEK loaded once, when the signing key
is wrapped and loaded into the keystore, then KEK loading is skipped for
all signing operations. So far, so good.

When we set the timeout below the signing time (about 120ms), we see
that the KEK is loaded for every signing operation. Again, as expected.

When we dial it down to 20000 cycles (400us), we start to see BAD_MAGIC
errors. What this means is the the KEK is loaded and expanded in the
INIT command, but times out and is zeroed before the driver sends the
NEXT command.

When we get down to about 150 cycles (3us), the errors disappear. I
surmise that the KEK times out before either the wrap or unwrap
operations are started, so everything is effectively done with a zero KEK.

It should probably be an error to attempt a key wrap/unwrap (or any AES
operation) with a zero KEK, but that's not something we test for today.
(We test the status word in the MKM, but that's not the same as testing
the value stored in the MKM.)

Also, a tamper event should invalidate the KEK in the keywrap core, but
currently neither the ARM nor the FPGA responds to a tamper interrupt.
(The AVR has 4 GPIO lines to the ARM, and 4 to the FPGA, but a quick
scan of tamper.c doesn't show it using them as outputs, and neither the
ARM nor the FPGA uses them as inputs.)

I didn't do any fine-grained timing tests, but I would expect that
signing would be a little faster with the KEK loaded, by avoiding the
717us to fetch the KEK, but a tiny bit slower with the KEK
unloaded/timed out, because of the extra read of the status register.

> Another thing I have been working on in another keywrap branch is the
> integration of the master key memory interface (mkmif) into keywrap.
> This integration would allow the keywrap to be able to autonomously load
> a stored master key from the MKM and use it for wrap/unwrap operations.
> 
> The changes to keywrap needed to integrate mkmif turned out to be more
> substantial and complex than I anticipated. The changes are basically
> done, but needs substantial verification on real HW before I would start
> to trust that it works. This change would move the responsibility for
> the master key from SW to HW. A single mistake in the HW functionality
> could potentially brick a HSM.

I'll test that next.

> So, considering that the auto-zeroise functionality allows SW control of
> the master key in the FPGA (control of how long it exists, trust that it
> will be wiped when not used and ability to zeroise it when needed), do
> we see a pressing need for the integration of mkmif into keywrap?

Yes. Loading the KEK into the ARM less often is still more than zero. If
we consider this a credible threat (either because the attacker can read
the SDRAM that we use for the task stack, or because he can monitor the
FMC bus that talks to the SDRAM and the FPGA), then we have to consider
that that attacker can trivially cause the ARM to load the KEK, by
either loading a key into the keystore, or initiating a signing or
verification operation with the KEK timed out.

Given this, I'm much less enthusiastic about auto-zeroise than about
integrated mkmif.

> This could be achieved in other ways such as the changes to the FPGA
> architecture with some core-core transfer support using FPGA internal
> data buffers and DMA (which I have previously suggested). In such a
> solution the mkmif would continue to be a separate core, but the key
> material would be transferred to the keywrap core without leaving the
> FPGA. This would basically achieve the same functionality as the
> integrated mkmif would provide, but with less severe core changes.

Let's talk about this next week at the f2f. I like it in theory, but I
got lost in the details the last time I read the proposal.

				paul