Received-SPF: pass (google.com: domain of linux-kernel+bounces-178530-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> <D10FIGJ84Q71.2VT5MH1VUDP0R@kernel.org>
 <ZjY-UU8pROnwlTuH@farprobe> <D10Y0V64JXG8.1F6S3OZDACCGF@kernel.org>
 <D10YYQKT9P1S.25CE053K7MQKI@kernel.org> <CALrw=nFLa5=bPbYKijNsEo0Kk77_TEpdPmPe3CJ3VJqGNMmBeg@mail.gmail.com>
 <44cd50b60a0a4e376d01544d25187556b8badf94.camel@HansenPartnership.com>
In-Reply-To: <44cd50b60a0a4e376d01544d25187556b8badf94.camel@HansenPartnership.com>
From: Ignat Korchagin <ignat@cloudflare.com>
Date: Tue, 14 May 2024 10:50:51 +0100
Message-ID: <CALrw=nFOh0=TXGx-z_oTkLWshVU_AfGRQzcC3zxVTzcRbuRqQQ@mail.gmail.com>
Subject: Re: [RFC PATCH 0/2] TPM derived keys
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>, Ben Boeckel <me@benboeckel.net>, 
	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, kernel-team@cloudflare.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 13, 2024 at 11:33=E2=80=AFPM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2024-05-13 at 18:09 +0100, Ignat Korchagin wrote:
> [...]
> > TPM derived keys attempt to address the above use cases by allowing
> > applications to deterministically derive unique cryptographic keys
> > for their own purposes directly from the TPM seed in the owner
> > hierarchy. The idea is that when an application requests a new key,
> > instead of generating a random key and wrapping it with the TPM, the
> > implementation generates a key via KDF(hierarchy seed, application
> > specific info). Therefore, the resulting keys will always be
> > cryptographically bound to the application itself and the device they
> > were generated on.
>
> So I think what confuses me is what the expected cryptographic secrecy
> properties of the derived keys are.  I get they're a KDF of seed and
> deterministic properties, but if those mixing values are well known (as
> the path or binary checksum cases) then anyone with access to the TPM
> can derive the key from user space because they can easily obtain the
> mixing parameters and there's no protection to the TPM keyed hash
> operation.
>
> Consider the use case where two users are using derived keys on the
> same system (so same TPM).  Assuming they use them to protect sensitive
> information, what prevents user1 from simply deriving user2's key and
> getting the information, or am I missing the point of this?

You are correct: it is possible, but in practice it would be limited
only to privileged users/applications. I remember there was a push to
set a 666 mask for the TPM device file, but it is not how it is done
today by default. Also I think the same applies to trusted keys as
well, at least without any additional authorizations or PCR
restrictions on the blob (I remember I could manually unwrap a trusted
key blob in userspace as root).

It would be fixed if we could limit access to some TPM ops only from
the kernel, but I remember from one of your presentations that it is
generally a hard problem and that some solution was in the works (was
it based on limiting access to a resettable PCR?). I'm happy to
consider adopting it here as well somehow.

> James
>