Received-SPF: pass (google.com: domain of linux-kernel+bounces-168442-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Sat, 04 May 2024 03:21:11 +0300
Message-Id: <D10FIGJ84Q71.2VT5MH1VUDP0R@kernel.org>
To: "Ignat Korchagin" <ignat@cloudflare.com>, "James Bottomley"
 <James.Bottomley@HansenPartnership.com>, "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>
Subject: Re: [RFC PATCH 0/2] TPM derived keys
From: "Jarkko Sakkinen" <jarkko@kernel.org>
References: <20240503221634.44274-1-ignat@cloudflare.com>
In-Reply-To: <20240503221634.44274-1-ignat@cloudflare.com>

On Sat May 4, 2024 at 1:16 AM EEST, Ignat Korchagin wrote:
> TPM derived keys get their payload from an HMAC primary key in the owner
> hierarchy mixed with some metadata from the requesting process.

What metadata?
What is "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.

Which use cases?

Two first paragraphs are confusers not motivators with three undefined asse=
ts.

> 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
> 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.

What are the *existential* issues?

You are start by inconviences with trusted keys without describing for
what the trusted keys are used for.


> Moreover, we need to store the wrapped key blob somewhere, and if we lose=
 it,
> the application cannot recover its data anymore.

I don't frankly understand what you are trying to say here. Somewhere is
not a place. It is an indeterministic entity.

>
> 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.

Does it or does it not make it easier? Please decide.

That said hard fine from mainline perspective unless there is an
existential issue.

>
> 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).

Please describe the implementation with request-key in the context of
the use case where it is used. That is what this should have started.
Then the motivation. Then the proposal for solution. And also focus
only on existential factors.

I have no idea for what the key created with this is even used, which
makes this impossible to review.

BR, Jarkko