From: Ignat Korchagin <ignat@cloudflare.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
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, Ignat Korchagin <ignat@cloudflare.com>
Subject: [RFC PATCH 0/2] TPM derived keys
Date: Fri, 3 May 2024 23:16:32 +0100 [thread overview]
Message-ID: <20240503221634.44274-1-ignat@cloudflare.com> (raw)
TPM derived keys get their payload from an HMAC primary key in the owner
hierarchy mixed with some metadata from the requesting process.
They are similar to trusted keys in the sense that the key security is rooted
in the TPM, but may provide easier key management for some use-cases.
One inconvenience with trusted keys is that the cryptographic material should
be provided externally. This means either wrapping the key to the TPM on the
executing system (which briefly exposes plaintext cryptographic material to
userspace) or creating the wrapped blob externally, but then we need to gather
and transfer the TPM public key to the remote system, which may be a logistical
problem sometimes.
Moreover, we need to store the wrapped key blob somewhere, and if we lose it,
the application cannot recover its data anymore.
TPM derived keys may make key management for applications easier, especially on
stateless systems as the application can always recreate its keys and the
encrypted data is bound to the device and its TPM. They allow the application
to wrap/unwrap some data to the device without worrying too much about key
management and provisioning. They are similar in a sense to device unique keys
present on many mobile devices and some IoT systems, but even better as every
application has its own unique device key.
It is also easy to quickly "wipe" all the application keys by just resetting
the TPM owner hierarchy.
It is worth mentioning that this functionality can be implemented in userspace
as a /sbin/request-key plugin. However, the advantage of the in-kernel
implementation is that the derived key material never leaves the kernel space
(unless explicitly read into userspace with proper permissions).
Current implementation supports two modes (as demonstrated by the keyctl
userspace tool):
1. keyctl add derived test '32 path' - will derive a 32 byte key based on
the TPM seed and the filesystem path of the requesting application. That
is /usr/bin/keyctl and /opt/bin/keyctl would generate different keys.
2. keyctl add derived test '32 csum' - will derive a 32 byte key based on the
TPM seed and the IMA measurement of the requesting application. That is
/usr/bin/keyctl and /opt/bin/keyctl would generate the same key IFF their
code exactly matches bit for bit. The implementation does not measure the
requesting binary itself, but rather relies on already available
measurement. This means for this mode to work IMA needs to be enabled and
configured for requesting applications. For example:
# echo 'audit func=BPRM_CHECK' > \
/sys/kernel/security/integrity/ima/policy
Open questions (apart from the obvious "is this useful?"):
* should any other modes/derivation parameters be considered?
* apparently in checksum mode, when calling keyring syscalls from scripts,
we mix in the measurement of the interpreter, not the script itself. Is
there any way to improve this?
Ignat Korchagin (2):
tpm: add some algorithm and constant definitions from the TPM spec
KEYS: implement derived keys
include/linux/tpm.h | 16 +-
security/keys/Kconfig | 16 ++
security/keys/Makefile | 1 +
security/keys/derived-keys/Makefile | 8 +
security/keys/derived-keys/derived.c | 226 +++++++++++++++++++++
security/keys/derived-keys/derived.h | 4 +
security/keys/derived-keys/tpm2_shash.c | 257 ++++++++++++++++++++++++
7 files changed, 524 insertions(+), 4 deletions(-)
create mode 100644 security/keys/derived-keys/Makefile
create mode 100644 security/keys/derived-keys/derived.c
create mode 100644 security/keys/derived-keys/derived.h
create mode 100644 security/keys/derived-keys/tpm2_shash.c
--
2.39.2
next reply other threads:[~2024-05-03 22:17 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 22:16 Ignat Korchagin [this message]
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
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=20240503221634.44274-1-ignat@cloudflare.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).