From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Ignat Korchagin" <ignat@cloudflare.com>,
"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>
Cc: <kernel-team@cloudflare.com>
Subject: Re: [RFC PATCH 2/2] KEYS: implement derived keys
Date: Wed, 15 May 2024 02:10:19 +0300 [thread overview]
Message-ID: <D19QW70177QG.2YC9XL0FT7VME@kernel.org> (raw)
In-Reply-To: <20240503221634.44274-3-ignat@cloudflare.com>
On Sat May 4, 2024 at 1:16 AM EEST, Ignat Korchagin wrote:
> Derived keys are similar to user keys, but their payload is derived from the
> primary TPM seed and some metadata of the requesting process. This way every
What is exactly "some metadata"?
> application can get a unique secret/key, which is cryptographically bound to
What is "cryptographically bound". Please go straight to the point and
cut out *all* white paper'ish phrases. We do not need it and will make
painful to backtrack this commit once in the mainline.
> the TPM without the need to provide the key material externally (unlike trusted
> keys). Also, the whole key derivation process is deterministic, so as long as
Why trusted keys is inside braces. It is not important for the point
you are trying to make here?
> the TPM is available, applications can always recover their keys, which may
> allow for easier key management on stateless systems.
Please drop "stateless system" unless you provide a rigid definition
what it is. I have no idea what you mean by it. Probably not that
important, right?
>
> In this implementation the following factors will be used as a key derivation
> factor:
> * requested key length
> * requesting process effective user id
> * either the application executable path or the application integrity
> metadata (if available)
NAK for path for any possible key derivation. They are racy and
and ambiguous.
This should have been in the beginning instead of "some data". What
other implementations exist. For me "this implementation" implies
that this one competing alternative to multiple implementations
of the same thing.
I do not like this science/white paper style at all. Just express
short, open code everything right at start when you need and cut
extras like "stateless system" unless you can provide exact, sound
and unambiguous definiton of it.
Just want to underline how this really needs a complete rewrite with
clear and concise explanation :-) This won't ever work.
>
> Key length is used so requests for keys with different sizes result in keys
> with different cryptographic material.
What is "key length"? Please refer the exact attribute.
>
> User id is mixed, so different users get different keys even when executing the
First of all it would be more clear to just s/User id/UID/
And make obvious whether we are talking about ruid or euid and how
this interacts with GIDs.
I'll look at the code change next round if the commit message starts
making any sense.
BR, Jarkko
next prev parent reply other threads:[~2024-05-14 23:10 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 [this message]
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
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=D19QW70177QG.2YC9XL0FT7VME@kernel.org \
--to=jarkko@kernel.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dhowells@redhat.com \
--cc=ignat@cloudflare.com \
--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).