From: Ignat Korchagin <ignat@cloudflare.com>
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
Subject: Re: [RFC PATCH 0/2] TPM derived keys
Date: Tue, 14 May 2024 11:05:59 +0100 [thread overview]
Message-ID: <CALrw=nHGLN=dn3fbyAcXsBufw0tAWUT1PKVHDK5RZkHcdd3CUw@mail.gmail.com> (raw)
In-Reply-To: <D18XXJ373C2V.2M6AOMKD1B89W@kernel.org>
On Tue, May 14, 2024 at 1:28 AM 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 PM Ignat Korchagin <ignat@cloudflare.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]
> 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.
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.
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.
> [1] https://lore.kernel.org/all/20200518172704.29608-1-prestwoj@gmail.com/
> [2] https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/
>
> BR, Jarkko
[1] https://lore.kernel.org/lkml/20221014100737.94742-2-ignat@cloudflare.com/T/
next prev parent reply other threads:[~2024-05-14 10:06 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 22:16 [RFC PATCH 0/2] TPM derived keys Ignat Korchagin
2024-05-03 22:16 ` [RFC PATCH 1/2] tpm: add some algorithm and constant definitions from the TPM spec Ignat Korchagin
2024-05-14 22:51 ` Jarkko Sakkinen
2024-05-14 22:52 ` Jarkko Sakkinen
2024-05-03 22:16 ` [RFC PATCH 2/2] KEYS: implement derived keys Ignat Korchagin
2024-05-14 23:10 ` Jarkko Sakkinen
2024-05-14 23:44 ` Jarkko Sakkinen
2024-05-15 0:00 ` Jarkko Sakkinen
2024-05-15 6:44 ` Ignat Korchagin
2024-05-15 12:00 ` Jarkko Sakkinen
2024-05-15 12:03 ` Jarkko Sakkinen
2024-05-15 7:26 ` Ignat Korchagin
2024-05-04 0:21 ` [RFC PATCH 0/2] TPM " Jarkko Sakkinen
2024-05-04 13:55 ` Ben Boeckel
2024-05-04 14:51 ` Jarkko Sakkinen
2024-05-04 15:35 ` Jarkko Sakkinen
2024-05-13 17:09 ` Ignat Korchagin
2024-05-13 22:33 ` James Bottomley
2024-05-14 9:50 ` Ignat Korchagin
2024-05-14 14:11 ` James Bottomley
2024-05-14 14:54 ` Ignat Korchagin
2024-05-13 17:11 ` Ignat Korchagin
2024-05-14 0:28 ` Jarkko Sakkinen
2024-05-14 10:05 ` Ignat Korchagin [this message]
2024-05-14 12:09 ` Jarkko Sakkinen
2024-05-14 13:11 ` Ignat Korchagin
2024-05-14 14:00 ` Jarkko Sakkinen
2024-05-14 14:30 ` Jarkko Sakkinen
2024-05-14 15:21 ` Jarkko Sakkinen
2024-05-14 15:26 ` Jarkko Sakkinen
2024-05-14 15:30 ` Ignat Korchagin
2024-05-14 15:42 ` Jarkko Sakkinen
2024-05-14 16:08 ` Ignat Korchagin
2024-05-14 16:22 ` Jarkko Sakkinen
2024-05-14 14:41 ` Ignat Korchagin
2024-05-14 14:45 ` Jarkko Sakkinen
2024-05-14 15:30 ` James Bottomley
2024-05-14 15:38 ` Ignat Korchagin
2024-05-14 15:54 ` James Bottomley
2024-05-14 16:01 ` Ignat Korchagin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALrw=nHGLN=dn3fbyAcXsBufw0tAWUT1PKVHDK5RZkHcdd3CUw@mail.gmail.com' \
--to=ignat@cloudflare.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=kernel-team@cloudflare.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).