+ Imran, he might have some additional suggestions.
From: Ionut Mihalcea <Ionut.Mihalcea(a)arm.com>
Sent: Monday, July 27, 2020 6:30 AM
Subject: [tpm2] Persistent key protection
I've been trying to identify any TPM authorization features that could be used in
a user-space persistent key store with hardware backing, but it appears that
simply storing the key context, preferably on an encrypted filesystem, is the best
solution I could come up with. Keys could have an auth value of their own, but
that value must then be stored as well, and any other authorization mechanism
ends up reducing to an (indirect) "auth" value that has to be persisted.
Yes and no. Depends on how you set up the key. You would probably want to lock it to a
Policy, or something like policy signed. Where you can sign a policy with a key on your
And send down a PCR policy. This way if PCR's change, you just update your policy.
This would be fixed to measured system state.
The threat I'm trying to work against is simply leaking the persisted key material,
You can set up attributes on the key so that it cannot be exported from the TPM. You
want fixedtpm and fixedparent in your attribute set.
allowing the attacker to load and use the keys (assuming they're
use the hierarchy that the keys belong to).
You could lock It to PCR state. Hopefully a mis measure would occur causing the key not
to be available. You could even store an auth value secret on the server, and require the
client to perform an attestation before sending the secret to unlock it.
> Am I missing something, or is this due to TPM authorization features being aimed
> more at lower levels of the stack?
> Best regards,
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.