Received-SPF: pass (google.com: domain of linux-kernel+bounces-178705-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240503221634.44274-1-ignat@cloudflare.com> <CALrw=nGhgRrhJ5mWWC6sV2WYWoijvD9WgFzMfOe6mHmqnza-Hw@mail.gmail.com>
 <D18XXJ373C2V.2M6AOMKD1B89W@kernel.org> <CALrw=nHGLN=dn3fbyAcXsBufw0tAWUT1PKVHDK5RZkHcdd3CUw@mail.gmail.com>
 <D19CUF0H9Q3S.3L5Y5S9553S5@kernel.org>
In-Reply-To: <D19CUF0H9Q3S.3L5Y5S9553S5@kernel.org>
From: Ignat Korchagin <ignat@cloudflare.com>
Date: Tue, 14 May 2024 14:11:44 +0100
Message-ID: <CALrw=nEZ07U9VhbGsnpchOYw1icUZCnuoHHXkJLzhFqSPe9_fQ@mail.gmail.com>
Subject: Re: [RFC PATCH 0/2] TPM derived keys
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: 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, 
	kernel-team@cloudflare.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 14, 2024 at 1:09=E2=80=AFPM Jarkko Sakkinen <jarkko@kernel.org>=
 wrote:
>
> On Tue May 14, 2024 at 1:05 PM EEST, Ignat Korchagin wrote:
> > On Tue, May 14, 2024 at 1:28=E2=80=AFAM Jarkko Sakkinen <jarkko@kernel.=
org> wrote:
> > >
> > > On Mon May 13, 2024 at 8:11 PM EEST, Ignat Korchagin wrote:
> > > > On Fri, May 3, 2024 at 11:16=E2=80=AFPM Ignat Korchagin <ignat@clou=
dflare.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 asymmet=
ric
> > > 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 lay=
ing
> > > 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 lik=
ely
> > > 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?

For example, a cheap NAS box with no internal storage (disks connected
externally via USB). We want:
  * disks to be encrypted and decryptable only by this NAS box
  * if someone steals one of the disks - we don't want them to see it
has encrypted data (no LUKS header)

Additionally we may want to SSH into the NAS for configuration and we
don't want the SSH server key to change after each boot (regardless if
disks are connected or not).

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

In theory yes, but I have chased the tech for a while on commodity HW
and it keeps having problems.

> 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