All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ignat Korchagin <ignat@cloudflare.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	 Ben Boeckel <me@benboeckel.net>
Cc: 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: Mon, 13 May 2024 16:33:40 -0600	[thread overview]
Message-ID: <44cd50b60a0a4e376d01544d25187556b8badf94.camel@HansenPartnership.com> (raw)
In-Reply-To: <CALrw=nFLa5=bPbYKijNsEo0Kk77_TEpdPmPe3CJ3VJqGNMmBeg@mail.gmail.com>

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?

James


  reply	other threads:[~2024-05-13 22:33 UTC|newest]

Thread overview: 41+ 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-06  4:11   ` kernel test robot
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 [this message]
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=44cd50b60a0a4e376d01544d25187556b8badf94.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.