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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALrw=nGhgRrhJ5mWWC6sV2WYWoijvD9WgFzMfOe6mHmqnza-Hw@mail.gmail.com>
Date: Mon, 13 May 2024 18:11:21 +0100
From: Ignat Korchagin <ignat@...udflare.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>, 
	Jarkko Sakkinen <jarkko@...nel.org>, Mimi Zohar <zohar@...ux.ibm.com>, 
	David Howells <dhowells@...hat.com>, Paul Moore <paul@...l-moore.com>, 
	James Morris <jmorris@...ei.org>, serge@...lyn.com, linux-integrity@...r.kernel.org, 
	keyrings@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: kernel-team@...udflare.com
Subject: Re: [RFC PATCH 0/2] TPM derived keys

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