[TrouSerS-users] Ways to store keys persistently and permanently in hardware

[Tadd Seiff]

Hi List,

In my situation I have to tolerate CATASTROPHIC hardware events. Not
failures, but the owners of my platforms can, and routinely do, swap
hard-drives with newly pre-imaged ones. This is the "upgrade" procedure.
This is done remotely and we have no way to touch the system. We cannot
"pre-provision" these imaged drives before they ship.

Per my understanding, and please correct me if I'm wrong, this would
obliterate any keys that Trousers has stored. What WOULD persist is:
1. EK
2. SRK
3. Ownership state and auth data

So to deal with this, I can either ensure keys (or something) is stored
persistently in the chip across reboots and catastrophic events, or develop
a process that tolerates these events (rely on ownership to recover and
create keys at run time if they have been obliterated, no need to
re-provision).

I researched OWNER_EVICT keys but was not convinced that this is a
permanent solution, only that the owner can control when a key is swapped
out of the TPM.

Is there a proven method for on-chip storage and what does it buy me? Or
if there isn't, that's valuable to know too.

Thanks for you time,
-Tadd

[Ken Goldman]

1 - I wonder why owner evict keys are not the solution. You only get a
few of them, but their purpose is to persist and travel with the TPM.

2 - You could also store a few key blobs in NV indexes. Again, you only
get a few of them.

3 - I'd try to solve this at the system layer. Swapping a disk is no
different from a disk failure, or even a TPM failure. Whatever you're
enterprise is doing for key backup (or general data backup) should work
for key blobs.

4 - In TPM 2.0, primary keys are repeatable. It's slow, so you may not
want to do it routinely, but it's a way to recover in case you lose your
disk copy.