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.
The threat I’m trying to work against is simply leaking the persisted key material,
allowing the attacker to load and use the keys (assuming they’re authorized to use the
hierarchy that the keys belong to).
Am I missing something, or is this due to TPM authorization features being aimed more at
lower levels of the stack?
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.
Show replies by date