this is an interesting request and I hope I understand it correctly. I think the question
should be better asked in the TCG because it refers to TPM functional capabilities and not
so much related to the TSS stack. The TSS stack provides the TPM authorization
functionalities to the host software. The architecture of the host software (e.g.
execution separation, privileges) and hardware (virtualization, TEE) can then be combined
to be validated in the TPM authorization.
I think an important point is that the authorization secret requires anyway only a lower
security level, because it allows an attacker only to use a key, but not to extract the
private key. The extraction of a private key is more critical, because it would be then
entirely be compromised as any further misuse can't be blocked anymore. The loss of an
authorization secret still makes it possible to reconfigure the authorization of the key
in the TPM so that after that the misuse of the key is not possible anymore. It therefore
depends on the use case if an additional protection of the authorization secret is
In order to enable further protection of the authorization secret, the TPM currently
supports at least these Authorization policy elements currently:
- PCR State
- "Physical Presence"
- Asymmetric signature
- Specific objects
- Symmetric shared secret
- Time Limited
- NV Written
- Specific Command
- Contents of NV
Furthermore there is the ACT concept (Authenticated Countdown Timer).
For example the authorizations for Locality and PCR state might provide the authorization
features that you are looking for (e.g. sealing). They can be combined with Secure Boot.
For both there are concepts and implementations available for x86 platforms. However for
non-x86 systems it would be an interesting topic to define a proposal or concept, how this
can be integrated.
Another (simpler) solution depending on your overall system might be to store the
authorization secret (e.g. a password) on another partner device nearby. In this case the
local system with the TPM doesn't store the authorization password anymore and
therefore an attacker can't extract it. There are then for example 2 options to use
- Only the partner device can load and use the key in the TPM of the local
system. Results of the TPM commands are securely transferred to the partner device (Remote
- Only when the local system was booted up correctly (e.g. using authentication,
hardware validation, attestation), the partner device transfers the authorization secret
the local device. The local device would have stored the key only in volatile memory, so
that an attacker could
From: Ionut Mihalcea <Ionut.Mihalcea(a)arm.com>
Sent: Montag, 27. Juli 2020 13:30
Subject: [tpm2] Persistent key protection
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or
open attachments unless you validate it is
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.