Received-SPF: pass (google.com: domain of linux-kernel+bounces-177880-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240503221634.44274-1-ignat@cloudflare.com>
In-Reply-To: <20240503221634.44274-1-ignat@cloudflare.com>
From: Ignat Korchagin <ignat@cloudflare.com>
Date: Mon, 13 May 2024 18:11:21 +0100
Message-ID: <CALrw=nGhgRrhJ5mWWC6sV2WYWoijvD9WgFzMfOe6mHmqnza-Hw@mail.gmail.com>
Subject: Re: [RFC PATCH 0/2] TPM derived keys
To: James Bottomley <James.Bottomley@hansenpartnership.com>, 
	Jarkko Sakkinen <jarkko@kernel.org>, Mimi Zohar <zohar@linux.ibm.com>, 
	David Howells <dhowells@redhat.com>, Paul Moore <paul@paul-moore.com>, 
	James Morris <jmorris@namei.org>, serge@hallyn.com, linux-integrity@vger.kernel.org, 
	keyrings@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: kernel-team@cloudflare.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 3, 2024 at 11:16=E2=80=AFPM Ignat Korchagin <ignat@cloudflare.c=
om> 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 ro=
oted
> in the TPM, but may provide easier key management for some use-cases.
>
> One inconvenience with trusted keys is that the cryptographic material sh=
ould
> 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 g=
ather
> and transfer the TPM public key to the remote system, which may be a logi=
stical
> 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, especia=
lly 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 applica=
tion
> to wrap/unwrap some data to the device without worrying too much about ke=
y
> 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 e=
very
> application has its own unique device key.
>
> It is also easy to quickly "wipe" all the application keys by just resett=
ing
> the TPM owner hierarchy.
>
> It is worth mentioning that this functionality can be implemented in user=
space
> as a /sbin/request-key plugin. However, the advantage of the in-kernel
> implementation is that the derived key material never leaves the kernel s=
pace
> (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 measur=
e the
>      requesting binary itself, but rather relies on already available
>      measurement. This means for this mode to work IMA needs to be enable=
d and
>      configured for requesting applications. For example:
>        # echo 'audit func=3DBPRM_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 scrip=
ts,
>     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
>