Re: [RFC PATCH 0/2] TPM derived keys

Ignat Korchagin
2024-05-13T17:11:33Z

On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <ignat@cloudflare.com> wrote:
>
> TPM derived keys get their payload from an HMAC primary key in the owner
> hierarchy mixed with some metadata from the requesting process.
>
> They are similar to trusted keys in the sense that the key security is rooted
> in the TPM, but may provide easier key management for some use-cases.
>
> One inconvenience with trusted keys is that the cryptographic material should
> be provided externally. This means either wrapping the key to the TPM on the

I would like to point out to myself I was wrong: it is possible to ask
the kernel to generate a trusted key inside the kernel locally with
"keyctl add trusted kmk "new 32" @u"

> executing system (which briefly exposes plaintext cryptographic material to
> userspace) or creating the wrapped blob externally, but then we need to gather
> and transfer the TPM public key to the remote system, which may be a logistical
> problem sometimes.
>
> Moreover, we need to store the wrapped key blob somewhere, and if we lose it,
> the application cannot recover its data anymore.
>
> TPM derived keys may make key management for applications easier, especially on
> stateless systems as the application can always recreate its keys and the
> encrypted data is bound to the device and its TPM. They allow the application
> to wrap/unwrap some data to the device without worrying too much about key
> management and provisioning. They are similar in a sense to device unique keys
> present on many mobile devices and some IoT systems, but even better as every
> application has its own unique device key.
>
> It is also easy to quickly "wipe" all the application keys by just resetting
> the TPM owner hierarchy.
>
> It is worth mentioning that this functionality can be implemented in userspace
> as a /sbin/request-key plugin. However, the advantage of the in-kernel
> implementation is that the derived key material never leaves the kernel space
> (unless explicitly read into userspace with proper permissions).
>
> Current implementation supports two modes (as demonstrated by the keyctl
> userspace tool):
> 1. keyctl add derived test '32 path' - will derive a 32 byte key based on
> the TPM seed and the filesystem path of the requesting application. That
> is /usr/bin/keyctl and /opt/bin/keyctl would generate different keys.
>
> 2. keyctl add derived test '32 csum' - will derive a 32 byte key based on the
> TPM seed and the IMA measurement of the requesting application. That is
> /usr/bin/keyctl and /opt/bin/keyctl would generate the same key IFF their
> code exactly matches bit for bit. The implementation does not measure the
> requesting binary itself, but rather relies on already available
> measurement. This means for this mode to work IMA needs to be enabled and
> configured for requesting applications. For example:
> # echo 'audit func=BPRM_CHECK' > \
> /sys/kernel/security/integrity/ima/policy
>
> Open questions (apart from the obvious "is this useful?"):
> * should any other modes/derivation parameters be considered?
> * apparently in checksum mode, when calling keyring syscalls from scripts,
> we mix in the measurement of the interpreter, not the script itself. Is
> there any way to improve this?
>
>
> Ignat Korchagin (2):
> tpm: add some algorithm and constant definitions from the TPM spec
> KEYS: implement derived keys
>
> include/linux/tpm.h | 16 +-
> security/keys/Kconfig | 16 ++
> security/keys/Makefile | 1 +
> security/keys/derived-keys/Makefile | 8 +
> security/keys/derived-keys/derived.c | 226 +++++++++++++++++++++
> security/keys/derived-keys/derived.h | 4 +
> security/keys/derived-keys/tpm2_shash.c | 257 ++++++++++++++++++++++++
> 7 files changed, 524 insertions(+), 4 deletions(-)
> create mode 100644 security/keys/derived-keys/Makefile
> create mode 100644 security/keys/derived-keys/derived.c
> create mode 100644 security/keys/derived-keys/derived.h
> create mode 100644 security/keys/derived-keys/tpm2_shash.c
>
> --
> 2.39.2
>