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: <D10FIGJ84Q71.2VT5MH1VUDP0R@kernel.org>
Date: Sat, 04 May 2024 03:21:11 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Ignat Korchagin" <ignat@...udflare.com>, "James Bottomley"
 <James.Bottomley@...senPartnership.com>, "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 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 rooted
> 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 assets.

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

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

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

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