Message-Id: <D19CUF0H9Q3S.3L5Y5S9553S5@kernel.org>
Date: Tue, 14 May 2024 15:09:44 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Ignat Korchagin" <ignat@...udflare.com>
Cc: "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>,
 <kernel-team@...udflare.com>
Subject: Re: [RFC PATCH 0/2] TPM derived keys

On Tue May 14, 2024 at 1:05 PM EEST, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 1:28 AM Jarkko Sakkinen <jarkko@...nel.org> wrote:
> >
> > On Mon May 13, 2024 at 8:11 PM EEST, Ignat Korchagin wrote:
> > > On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <ignat@...udflare.com> wrote:
> > > 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"
> >
> > Not in a full-time kernel position ATM as I'm working as contract
> > researcher up until beginning of Oct (took some industry break after
> > a startup went down of business), so please, politely asking, write
> > a bit more compact descriptions ;-) I'm trying to find a new position by
> > the beginning of Oct but right now I'd appreciate a bit more thought out
> > text descriptions.
> >
> > I'm working out a small patch set with James Prestwood to add asymmetric
> > TPM2 keys based on his old patch set [1] but laid out on top of the
> > existing baseline.
> >
> > I did already the key type shenanigans etc. for it and James P is laying
> > his pre-existing RSA code and new ECDSA on top of that. So this will
>
> This is great. Perhaps we can finally have ECDSA software signature
> support as well, which I have been trying to get in for some time now
> [1]

Yes exactly both.

>
> > give x.509 compatibility [2]. This patch set will be out soon and likely
> > part of 6.11 (or almost guaranteed as most of it is done).
> >
> > So by plain guess this might be along the lines what you might want?
>
> I don't think so. I have seen this patchset, but unless the new
> version is fundamentally different, it looks to me that the asymmetric
> TPM keys are the same as trusted keys except they are asymmetric
> instead of being symmetric. That is, they are still of limited use on
> stateless systems and are subject to the same restrictions I described
> in my revised cover description.

OK, hmm... can you an "apples and oranges" example what would be
most trivial use case where these don't cut?


> On top of that I'm not sure they would be widely used as "leaf" keys
> by applications, maybe more as root/intermediate keys in some kind of
> key hierarchy. TPMs are slow and I don't see a high-performance
> web-server, for example, using asymmetric TPM keys for TLS operations.
> Also, as we learned the hard way operating many TPMs in production,
> some TPMs are quite unreliable and fail really fast, if you "spam"
> them with a lot of crypto ops. I understand this is a HW/TPM vendor
> problem, but in practice we're trying to build systems, where TPM is
> used to protect/generate other keys, but most of the "leaf" crypto
> operations are done in software, so we don't make the TPM do too much
> crypto.

So what about SGX/SNP/TDX?

TPM is definitely not made for workloads :-)

> Just to clarify - I'm not arguing about the usefulness of TPM
> asymmetric keys in the kernel. I would really want to see this
> building block available as well, but I think it just serves a
> different purpose/use case from what I'm trying to figure out in this
> RFC thread.

Got it :-) NP

BR, Jarkko

Powered by blists - more mailing lists