From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ignat Korchagin <ignat@cloudflare.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
Ben Boeckel <me@benboeckel.net>,
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 08:11:06 -0600 [thread overview]
Message-ID: <b53f9fa263e65cd6b23677d9f7a385e5eb85cfdd.camel@HansenPartnership.com> (raw)
In-Reply-To: <CALrw=nFOh0=TXGx-z_oTkLWshVU_AfGRQzcC3zxVTzcRbuRqQQ@mail.gmail.com>
On Tue, 2024-05-14 at 10:50 +0100, Ignat Korchagin wrote:
> On Mon, May 13, 2024 at 11:33 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > On Mon, 2024-05-13 at 18:09 +0100, Ignat Korchagin wrote:
> > [...]
> > > TPM derived keys attempt to address the above use cases by
> > > allowing applications to deterministically derive unique
> > > cryptographic keys for their own purposes directly from the TPM
> > > seed in the owner hierarchy. The idea is that when an application
> > > requests a new key, instead of generating a random key and
> > > wrapping it with the TPM, the implementation generates a key via
> > > KDF(hierarchy seed, application specific info). Therefore, the
> > > resulting keys will always be cryptographically bound to the
> > > application itself and the device they were generated on.
> >
> > So I think what confuses me is what the expected cryptographic
> > secrecy properties of the derived keys are. I get they're a KDF of
> > seed and deterministic properties, but if those mixing values are
> > well known (as the path or binary checksum cases) then anyone with
> > access to the TPM can derive the key from user space because they
> > can easily obtain the mixing parameters and there's no protection
> > to the TPM keyed hash operation.
> >
> > Consider the use case where two users are using derived keys on the
> > same system (so same TPM). Assuming they use them to protect
> > sensitive information, what prevents user1 from simply deriving
> > user2's key and getting the information, or am I missing the point
> > of this?
>
> You are correct: it is possible, but in practice it would be limited
> only to privileged users/applications. I remember there was a push to
> set a 666 mask for the TPM device file, but it is not how it is done
> today by default.
No, it's 660, but in consequence of that every user of the TPM is a
member of the tpm group which, since TPM use from userspace is growing,
is everyone, so it might as well have been 666. In other words relying
on access restrictions to the TPM itself is largely useless.
> Also I think the same applies to trusted keys as well, at least
> without any additional authorizations or PCR restrictions on the blob
> (I remember I could manually unwrap a trusted key blob in userspace
> as root).
Well, that's correct, but a TPM key file without policy still has two
protections: the file itself (so the key owner can choose what
permissions and where it is) and the key authority (or password)
although for the mechanical (unsupervised insertion) use case keys tend
not to have an authority.
> It would be fixed if we could limit access to some TPM ops only from
> the kernel, but I remember from one of your presentations that it is
> generally a hard problem and that some solution was in the works (was
> it based on limiting access to a resettable PCR?). I'm happy to
> consider adopting it here as well somehow.
Well, that was based on constructing a policy that meant only the
kernel could access the data (so it requires PCR policy).
In addition to the expected secrecy property question which I don't
think is fully answered I did think of another issue: what if the
application needs to rotate keys because of a suspected compromise?
For sealed keys, we just generate a new one an use that in place of the
old, but for your derived keys we'd have to change one of the mixing
values, which all look to be based on fairly permanent properties of
the system.
James
next prev parent reply other threads:[~2024-05-14 14:11 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 [this message]
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=b53f9fa263e65cd6b23677d9f7a385e5eb85cfdd.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=ignat@cloudflare.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=me@benboeckel.net \
--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).