Received-SPF: pass (google.com: domain of linux-kernel+bounces-168341-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
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
Message-Id: <20240503221634.44274-1-ignat@cloudflare.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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