On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <ignat@xxxxxxxxxxxxxx> 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 >
