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: <CALrw=nEZ07U9VhbGsnpchOYw1icUZCnuoHHXkJLzhFqSPe9_fQ@mail.gmail.com>
Date: Tue, 14 May 2024 14:11:44 +0100
From: Ignat Korchagin <ignat@...udflare.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
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:09 PM Jarkko Sakkinen <jarkko@...nel.org> wrote:
>
> 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?

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