Re: Persistent key protection
by Florian.Schreiner＠infineon.com
Hi Ionut,
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 required.
In order to enable further protection of the authorization secret, the TPM currently supports at least these Authorization policy elements currently:
- PCR State
- Locality
- "Physical Presence"
- Asymmetric signature
- Specific objects
- Symmetric shared secret
- Duplication
- 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 the key:
- 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 TPM Sessions).
- 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
Best,
Florian
From: Ionut Mihalcea <Ionut.Mihalcea(a)arm.com>
Sent: Montag, 27. Juli 2020 13:30
To: tpm2(a)lists.01.org
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 safe<http://iweb.infineon.com/en-US/Support/security/CDC/pse/Pages/pce.aspx>.
Hello all,
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?
Best regards,
Ionut
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.
