[RFC PATCH 0/2] TPM derived keys

[RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

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

[RFC PATCH 1/2] tpm: add some algorithm and constant definitions from the TPM spec

[Ignat Korchagin]

In preparation for implementing TPM derived keys we need to use some new TPM
functionality in the kernel, so add relevant constant definitions.

Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
---
 include/linux/tpm.h | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index 4ee9d13749ad..5be0808b1b91 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -35,6 +35,7 @@ struct trusted_key_options;
 enum tpm_algorithms {
 	TPM_ALG_ERROR		= 0x0000,
 	TPM_ALG_SHA1		= 0x0004,
+	TPM_ALG_HMAC		= 0x0005,
 	TPM_ALG_KEYEDHASH	= 0x0008,
 	TPM_ALG_SHA256		= 0x000B,
 	TPM_ALG_SHA384		= 0x000C,
@@ -209,6 +210,7 @@ enum tpm2_return_codes {
 	TPM2_RC_DISABLED	= 0x0120,
 	TPM2_RC_UPGRADE		= 0x012D,
 	TPM2_RC_COMMAND_CODE    = 0x0143,
+	TPM2_RC_OBJECT_MEMORY	= 0x0902,
 	TPM2_RC_TESTING		= 0x090A, /* RC_WARN */
 	TPM2_RC_REFERENCE_H0	= 0x0910,
 	TPM2_RC_RETRY		= 0x0922,
@@ -227,6 +229,7 @@ enum tpm2_command_codes {
 	TPM2_CC_CREATE		        = 0x0153,
 	TPM2_CC_LOAD		        = 0x0157,
 	TPM2_CC_SEQUENCE_UPDATE         = 0x015C,
+	TPM2_CC_SIGN		        = 0x015D,
 	TPM2_CC_UNSEAL		        = 0x015E,
 	TPM2_CC_CONTEXT_LOAD	        = 0x0161,
 	TPM2_CC_CONTEXT_SAVE	        = 0x0162,
@@ -234,6 +237,7 @@ enum tpm2_command_codes {
 	TPM2_CC_VERIFY_SIGNATURE        = 0x0177,
 	TPM2_CC_GET_CAPABILITY	        = 0x017A,
 	TPM2_CC_GET_RANDOM	        = 0x017B,
+	TPM2_CC_HASH	        	= 0x017D,
 	TPM2_CC_PCR_READ	        = 0x017E,
 	TPM2_CC_PCR_EXTEND	        = 0x0182,
 	TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,
@@ -243,7 +247,8 @@ enum tpm2_command_codes {
 };
 
 enum tpm2_permanent_handles {
-	TPM2_RS_PW		= 0x40000009,
+	TPM2_RH_OWNER = 0x40000001,
+	TPM2_RS_PW    = 0x40000009,
 };
 
 enum tpm2_capabilities {
@@ -312,9 +317,12 @@ struct tpm_buf {
 };
 
 enum tpm2_object_attributes {
-	TPM2_OA_FIXED_TPM		= BIT(1),
-	TPM2_OA_FIXED_PARENT		= BIT(4),
-	TPM2_OA_USER_WITH_AUTH		= BIT(6),
+	TPM2_OA_FIXED_TPM 		= BIT(1),
+	TPM2_OA_FIXED_PARENT 		= BIT(4),
+	TPM2_OA_SENSITIVE_DATA_ORIGIN	= BIT(5),
+	TPM2_OA_USER_WITH_AUTH 		= BIT(6),
+	TPM2_OA_RESTRICTED 		= BIT(16),
+	TPM2_OA_SIGN 			= BIT(18),
 };
 
 enum tpm2_session_attributes {
-- 
2.39.2

Re: [RFC PATCH 1/2] tpm: add some algorithm and constant definitions from the TPM spec

[Jarkko Sakkinen]

I'll go through the code changes. I've barely skimmed them because I
needed to understand the gist of the cover letter first and was busy
with 6.10 release and asymmetric keys.

On Sat May 4, 2024 at 1:16 AM EEST, Ignat Korchagin wrote:
> In preparation for implementing TPM derived keys we need to use some new TPM
> functionality in the kernel, so add relevant constant definitions.

Define "TPM derived key" what is. It is *undefined* at this point of the
Git history.

>
> Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
> ---
>  include/linux/tpm.h | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index 4ee9d13749ad..5be0808b1b91 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -35,6 +35,7 @@ struct trusted_key_options;
>  enum tpm_algorithms {
>  	TPM_ALG_ERROR		= 0x0000,
>  	TPM_ALG_SHA1		= 0x0004,
> +	TPM_ALG_HMAC		= 0x0005,
>  	TPM_ALG_KEYEDHASH	= 0x0008,
>  	TPM_ALG_SHA256		= 0x000B,
>  	TPM_ALG_SHA384		= 0x000C,

I had a point after all when asking for split and it was about this
patch. This should be a separate comment and with a clear rationale what
for this is required for the new key type.

It is a logically separate change [1].

> @@ -209,6 +210,7 @@ enum tpm2_return_codes {
>  	TPM2_RC_DISABLED	= 0x0120,
>  	TPM2_RC_UPGRADE		= 0x012D,
>  	TPM2_RC_COMMAND_CODE    = 0x0143,
> +	TPM2_RC_OBJECT_MEMORY	= 0x0902,
>  	TPM2_RC_TESTING		= 0x090A, /* RC_WARN */
>  	TPM2_RC_REFERENCE_H0	= 0x0910,
>  	TPM2_RC_RETRY		= 0x0922,

Ditto.

> @@ -227,6 +229,7 @@ enum tpm2_command_codes {
>  	TPM2_CC_CREATE		        = 0x0153,
>  	TPM2_CC_LOAD		        = 0x0157,
>  	TPM2_CC_SEQUENCE_UPDATE         = 0x015C,
> +	TPM2_CC_SIGN		        = 0x015D,
>  	TPM2_CC_UNSEAL		        = 0x015E,
>  	TPM2_CC_CONTEXT_LOAD	        = 0x0161,
>  	TPM2_CC_CONTEXT_SAVE	        = 0x0162,

Ditto.

> @@ -234,6 +237,7 @@ enum tpm2_command_codes {
>  	TPM2_CC_VERIFY_SIGNATURE        = 0x0177,
>  	TPM2_CC_GET_CAPABILITY	        = 0x017A,
>  	TPM2_CC_GET_RANDOM	        = 0x017B,
> +	TPM2_CC_HASH	        	= 0x017D,
>  	TPM2_CC_PCR_READ	        = 0x017E,
>  	TPM2_CC_PCR_EXTEND	        = 0x0182,
>  	TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,


Ditto.

> @@ -243,7 +247,8 @@ enum tpm2_command_codes {
>  };
>  
>  enum tpm2_permanent_handles {
> -	TPM2_RS_PW		= 0x40000009,
> +	TPM2_RH_OWNER = 0x40000001,

Ditto.

> +	TPM2_RS_PW    = 0x40000009,
>  };
>  
>  enum tpm2_capabilities {
> @@ -312,9 +317,12 @@ struct tpm_buf {
>  };
>  
>  enum tpm2_object_attributes {
> -	TPM2_OA_FIXED_TPM		= BIT(1),
> -	TPM2_OA_FIXED_PARENT		= BIT(4),
> -	TPM2_OA_USER_WITH_AUTH		= BIT(6),
> +	TPM2_OA_FIXED_TPM 		= BIT(1),
> +	TPM2_OA_FIXED_PARENT 		= BIT(4),
> +	TPM2_OA_SENSITIVE_DATA_ORIGIN	= BIT(5),
> +	TPM2_OA_USER_WITH_AUTH 		= BIT(6),
> +	TPM2_OA_RESTRICTED 		= BIT(16),
> +	TPM2_OA_SIGN 			= BIT(18),
>  };
>  
>  enum tpm2_session_attributes {

Ditto.

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes

BR, Jarkko

Re: [RFC PATCH 1/2] tpm: add some algorithm and constant definitions from the TPM spec

[Jarkko Sakkinen]

On Wed May 15, 2024 at 1:51 AM EEST, Jarkko Sakkinen wrote:
> > @@ -227,6 +229,7 @@ enum tpm2_command_codes {
> >  	TPM2_CC_CREATE		        = 0x0153,
> >  	TPM2_CC_LOAD		        = 0x0157,
> >  	TPM2_CC_SEQUENCE_UPDATE         = 0x015C,
> > +	TPM2_CC_SIGN		        = 0x015D,
> >  	TPM2_CC_UNSEAL		        = 0x015E,
> >  	TPM2_CC_CONTEXT_LOAD	        = 0x0161,
> >  	TPM2_CC_CONTEXT_SAVE	        = 0x0162,
>
> Ditto.
>
> > @@ -234,6 +237,7 @@ enum tpm2_command_codes {
> >  	TPM2_CC_VERIFY_SIGNATURE        = 0x0177,
> >  	TPM2_CC_GET_CAPABILITY	        = 0x017A,
> >  	TPM2_CC_GET_RANDOM	        = 0x017B,
> > +	TPM2_CC_HASH	        	= 0x017D,
> >  	TPM2_CC_PCR_READ	        = 0x017E,
> >  	TPM2_CC_PCR_EXTEND	        = 0x0182,
> >  	TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,
>
>
> Ditto.

These can be in the same patch but both need a rationale.

BR, Jarkko

[RFC PATCH 2/2] KEYS: implement derived keys

[Ignat Korchagin]

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
application can get a unique secret/key, which is cryptographically bound to
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
the TPM is available, applications can always recover their keys, which may
allow for easier key management on stateless systems.

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)

Key length is used so requests for keys with different sizes result in keys
with different cryptographic material.

User id is mixed, so different users get different keys even when executing the
same binary. Additionally this is useful for derived keys based on path
derivation parameter: without this an unprivileged user can create a user and a
mount namespace, put an executable to a normally privileged location (like
/usr/sbin) and recover the key for some system tool.

If an application chooses to use its path as a key derivation factor, this key
will be implicitly available for any executable located at the path. For
example, a service under /usr/sbin/sshd would always be able to recover its key
regardless of its version or implementation, but if the binary is moved
elsewhere, the key would be different.

If the application chooses to use integrity metadata as a key derivation factor,
the resulting key would be cryptographically bound to this metadata. In practice
this means that a particular binary executable will always have access to its
key regardless where it is executed from. However, if the executable code
changes, the key would change as well.

Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
---
 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 ++++++++++++++++++++++++
 6 files changed, 512 insertions(+)
 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

diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index abb03a1b2a5c..62da9bff5f20 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -112,6 +112,22 @@ config USER_DECRYPTED_DATA
 
 	  If you are unsure as to whether this is required, answer N.
 
+config DERIVED_KEYS
+	tristate "DERIVED KEYS"
+	depends on KEYS
+	depends on TCG_TPM
+	select CRYPTO
+	select CRYPTO_HMAC
+	select CRYPTO_SHA256
+	select CRYPTO_KDF800108_CTR
+	help
+	  This option provides support for deriving keys from a trust source
+	  in the kernel. Derived keys are instantiated using a KDF with a seed
+	  from a trust source, so are unique per system/trust source. These keys
+	  can always be recovered as long as the trust source is available.
+
+	  If you are unsure as to whether this is required, answer N.
+
 config KEY_DH_OPERATIONS
        bool "Diffie-Hellman operations on retained keys"
        depends on KEYS
diff --git a/security/keys/Makefile b/security/keys/Makefile
index 5f40807f05b3..84456cc5cc14 100644
--- a/security/keys/Makefile
+++ b/security/keys/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_ASYMMETRIC_KEY_TYPE) += keyctl_pkey.o
 obj-$(CONFIG_BIG_KEYS) += big_key.o
 obj-$(CONFIG_TRUSTED_KEYS) += trusted-keys/
 obj-$(CONFIG_ENCRYPTED_KEYS) += encrypted-keys/
+obj-$(CONFIG_DERIVED_KEYS) += derived-keys/
diff --git a/security/keys/derived-keys/Makefile b/security/keys/derived-keys/Makefile
new file mode 100644
index 000000000000..5b85c16b6878
--- /dev/null
+++ b/security/keys/derived-keys/Makefile
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for derived keys
+#
+
+obj-$(CONFIG_DERIVED_KEYS) += derived-keys.o
+derived-keys-y += derived.o
+derived-keys-y += tpm2_shash.o
diff --git a/security/keys/derived-keys/derived.c b/security/keys/derived-keys/derived.c
new file mode 100644
index 000000000000..8b28c1dbde2e
--- /dev/null
+++ b/security/keys/derived-keys/derived.c
@@ -0,0 +1,226 @@
+#include <linux/module.h>
+#include <linux/key-type.h>
+#include <linux/file.h>
+#include <linux/mm.h>
+#include <linux/parser.h>
+#include <keys/user-type.h>
+#include <crypto/kdf_sp800108.h>
+#include <keys/request_key_auth-type.h>
+
+#include "derived.h"
+#include "../../integrity/ima/ima.h"
+
+#define MIN_KEY_SIZE 1
+#define MAX_KEY_SIZE 1024
+
+enum { Opt_path, Opt_exe_csum, Opt_err };
+
+static const match_table_t kdf_tokens = {
+	{ Opt_path, "path" },
+	{ Opt_exe_csum, "csum" },
+	{ Opt_err, NULL }
+};
+
+static int get_current_exe_path(char *buf, size_t buf_len, char **path)
+{
+	struct file *exe_file = get_task_exe_file(current);
+	if (!exe_file)
+		return -EFAULT;
+
+	*path = file_path(exe_file, buf, buf_len);
+	fput(exe_file);
+
+	return IS_ERR(*path) ? PTR_ERR(*path) : 0;
+}
+
+#ifdef CONFIG_IMA
+static struct ima_digest_data *get_currect_exe_integrity(void)
+{
+	struct ima_iint_cache *iint;
+	struct file *exe_file = get_task_exe_file(current);
+	if (!exe_file)
+		return NULL;
+
+	iint = ima_iint_find(file_inode(exe_file));
+	fput(exe_file);
+
+	return iint ? iint->ima_hash : NULL;
+}
+#endif
+
+static int tpm2_kdf_generate(int kdf_mix, u8 *out, size_t out_len)
+{
+	int ret;
+	struct kvec kbuf_iov[4];
+	char *path;
+	kuid_t euid = current_euid();
+
+	struct crypto_shash *tpm2_hash = crypto_alloc_shash(
+		TPM2_HASH_IMPL_NAME, CRYPTO_ALG_INTERNAL, CRYPTO_ALG_INTERNAL);
+	if (IS_ERR(tpm2_hash))
+		return PTR_ERR(tpm2_hash);
+
+	kbuf_iov[0].iov_base = &out_len;
+	kbuf_iov[0].iov_len = sizeof(u32);
+
+	kbuf_iov[1].iov_base = &euid;
+	kbuf_iov[1].iov_len = sizeof(euid);
+
+	switch (kdf_mix) {
+	case Opt_path:
+		kbuf_iov[2].iov_base = "path";
+		kbuf_iov[2].iov_len = sizeof("path");
+
+		path = kmalloc(PATH_MAX, GFP_KERNEL);
+		if (!path) {
+			ret = -ENOMEM;
+			goto free_hash;
+		}
+
+		ret = get_current_exe_path(path, PATH_MAX,
+					   (char **)&kbuf_iov[3].iov_base);
+		if (ret) {
+			kfree(path);
+			goto free_hash;
+		}
+
+		kbuf_iov[3].iov_len = strlen(kbuf_iov[3].iov_base);
+		break;
+#ifdef CONFIG_IMA
+	case Opt_exe_csum:
+		kbuf_iov[2].iov_base = "csum";
+		kbuf_iov[2].iov_len = sizeof("csum");
+
+		struct ima_digest_data *digest = get_currect_exe_integrity();
+		if (!digest) {
+			ret = -EOPNOTSUPP;
+			goto free_hash;
+		}
+
+		kbuf_iov[3].iov_base = digest->digest;
+		kbuf_iov[3].iov_len = digest->length;
+		break;
+#endif
+	}
+
+	ret = crypto_kdf108_ctr_generate(tpm2_hash, kbuf_iov,
+					 ARRAY_SIZE(kbuf_iov), out, out_len);
+	switch (kdf_mix) {
+	case Opt_path:
+		kfree(path);
+	}
+
+free_hash:
+	crypto_free_shash(tpm2_hash);
+	return ret;
+}
+
+static int derived_preparse(struct key_preparsed_payload *prep)
+{
+	int ret;
+	char *opts, *cur, *opt;
+	int kdf_mix;
+	unsigned long keylen;
+	substring_t args[MAX_OPT_ARGS];
+	struct user_key_payload *upayload;
+	size_t optslen = prep->datalen;
+
+	if (!prep->data || !prep->datalen)
+		return -EINVAL;
+
+	opts = cur = kmalloc(optslen + 1, GFP_KERNEL);
+	if (!opts)
+		return -ENOMEM;
+	opts[optslen] = 0;
+	memcpy(opts, prep->data, optslen);
+
+	opt = strsep(&cur, " \t");
+	if (!opt) {
+		ret = -EINVAL;
+		goto free_opts;
+	}
+
+	ret = kstrtoul(opts, 10, &keylen);
+	if (ret)
+		goto free_opts;
+
+	if (keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE) {
+		ret = -EINVAL;
+		goto free_opts;
+	}
+
+	if (!cur) {
+		ret = -EINVAL;
+		goto free_opts;
+	}
+
+	kdf_mix = match_token(cur, kdf_tokens, args);
+	switch (kdf_mix) {
+#ifndef CONFIG_IMA
+	case Opt_exe_csum:
+		ret = -EOPNOTSUPP;
+		goto free_opts;
+#endif
+	case Opt_err:
+		ret = -EINVAL;
+		goto free_opts;
+	}
+
+	upayload = kmalloc(sizeof(*upayload) + keylen, GFP_KERNEL);
+	if (!upayload) {
+		ret = -ENOMEM;
+		goto free_opts;
+	}
+
+	ret = tpm2_kdf_generate(kdf_mix, upayload->data, keylen);
+	if (ret)
+		goto free_payload;
+
+	prep->quotalen = keylen;
+	prep->payload.data[0] = upayload;
+	upayload->datalen = keylen;
+	goto free_opts;
+
+free_payload:
+	kfree(upayload);
+free_opts:
+	kfree(opts);
+	return ret;
+}
+
+static struct key_type key_type_derived = {
+	.name = "derived",
+	.preparse = derived_preparse,
+	.free_preparse = user_free_preparse,
+	.instantiate = generic_key_instantiate,
+	.revoke = user_revoke,
+	.destroy = user_destroy,
+	.describe = user_describe,
+	.read = user_read,
+};
+
+static int __init init_derived(void)
+{
+	int ret;
+
+	ret = register_tpm2_shash();
+	if (ret)
+		return ret;
+
+	ret = register_key_type(&key_type_derived);
+	if (ret)
+		unregister_tpm2_shash();
+
+	return ret;
+}
+
+static void __exit cleanup_derived(void)
+{
+	unregister_key_type(&key_type_derived);
+	unregister_tpm2_shash();
+}
+
+late_initcall(init_derived);
+module_exit(cleanup_derived);
+
+MODULE_LICENSE("GPL");
diff --git a/security/keys/derived-keys/derived.h b/security/keys/derived-keys/derived.h
new file mode 100644
index 000000000000..6f2910fb7afa
--- /dev/null
+++ b/security/keys/derived-keys/derived.h
@@ -0,0 +1,4 @@
+#define TPM2_HASH_IMPL_NAME "tpm2-hmac-internal"
+
+int register_tpm2_shash(void);
+void unregister_tpm2_shash(void);
diff --git a/security/keys/derived-keys/tpm2_shash.c b/security/keys/derived-keys/tpm2_shash.c
new file mode 100644
index 000000000000..79b7fecd7753
--- /dev/null
+++ b/security/keys/derived-keys/tpm2_shash.c
@@ -0,0 +1,257 @@
+#include "derived.h"
+#include <linux/tpm.h>
+#include <linux/tpm_command.h>
+
+#include <crypto/internal/hash.h>
+#include <crypto/sha2.h>
+
+/* create hierarchy with a custom unique value */
+#define TPM2_KERNEL_HIERARCHY "kernel"
+
+static struct tpm_chip *chip = NULL;
+
+static int tpm2_hash_init(struct shash_desc *desc)
+{
+	struct tpm_buf *buf = shash_desc_ctx(desc);
+	int ret = tpm_buf_init(buf, TPM2_ST_NO_SESSIONS, TPM2_CC_HASH);
+	if (ret)
+		return ret;
+
+	/* provisional size value for data size to be hashed */
+	tpm_buf_append_u16(buf, 0);
+
+	return 0;
+}
+
+static int tpm2_hash_update(struct shash_desc *desc, const u8 *data,
+			    unsigned int len)
+{
+	struct tpm_buf *buf = shash_desc_ctx(desc);
+
+	tpm_buf_append(buf, data, len);
+
+	if (buf->flags & TPM_BUF_OVERFLOW) {
+		tpm_buf_destroy(buf);
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+static inline void tpm2_buf_append_null_auth(struct tpm_buf *buf)
+{
+	tpm_buf_append_u32(buf, 9);
+	tpm_buf_append_u32(buf, TPM2_RS_PW);
+	tpm_buf_append_u16(buf, 0); /* nonce len */
+	tpm_buf_append_u8(buf, 0); /* attributes */
+	tpm_buf_append_u16(buf, 0); /* hmac len */
+}
+
+static int tpm2_hmac_create_primary(u32 *handle)
+{
+	struct tpm_buf buf;
+
+	int ret = tpm_buf_init(&buf, TPM2_ST_SESSIONS, TPM2_CC_CREATE_PRIMARY);
+	if (ret)
+		return ret;
+
+	/* owner hierarchy */
+	tpm_buf_append_u32(&buf, TPM2_RH_OWNER);
+
+	tpm2_buf_append_null_auth(&buf);
+
+	/* tpm2 sensitive */
+	tpm_buf_append_u16(&buf, 4);
+	tpm_buf_append_u16(&buf, 0);
+	tpm_buf_append_u16(&buf, 0);
+
+	/* tpm2 public */
+	tpm_buf_append_u16(&buf, 16 + sizeof(TPM2_KERNEL_HIERARCHY) - 1);
+	tpm_buf_append_u16(&buf, TPM_ALG_KEYEDHASH);
+	tpm_buf_append_u16(&buf, TPM_ALG_SHA256);
+	tpm_buf_append_u32(&buf, TPM2_OA_FIXED_TPM | TPM2_OA_FIXED_PARENT |
+					 TPM2_OA_SENSITIVE_DATA_ORIGIN |
+					 TPM2_OA_USER_WITH_AUTH |
+					 TPM2_OA_RESTRICTED |
+					 TPM2_OA_SIGN); /* attr */
+	tpm_buf_append_u16(&buf, 0); /* auth policy */
+	tpm_buf_append_u16(&buf, TPM_ALG_HMAC);
+	tpm_buf_append_u16(&buf, TPM_ALG_SHA256);
+	tpm_buf_append_u16(&buf,
+			   sizeof(TPM2_KERNEL_HIERARCHY) - 1); /* unique len */
+	tpm_buf_append(&buf, TPM2_KERNEL_HIERARCHY,
+		       sizeof(TPM2_KERNEL_HIERARCHY) - 1); /* unique */
+
+	/* outside info */
+	tpm_buf_append_u16(&buf, 0);
+
+	/* pcr selection */
+	tpm_buf_append_u32(&buf, 0);
+
+	if (buf.flags & TPM_BUF_OVERFLOW) {
+		ret = -ENOMEM;
+		goto free_buf;
+	}
+
+	ret = tpm_transmit_cmd(chip, &buf, 4,
+			       "create primary kernel hmac hierarchy");
+	if (ret < 0)
+		goto free_buf;
+
+	if (ret > 0) {
+		ret = tpm2_rc_value(ret) == TPM2_RC_OBJECT_MEMORY ? -ENOMEM :
+								    -EPERM;
+		goto free_buf;
+	}
+
+	*handle = be32_to_cpup((__be32 *)&buf.data[TPM_HEADER_SIZE]);
+
+free_buf:
+	tpm_buf_destroy(&buf);
+	return ret;
+}
+
+static int tpm2_sign(u32 handle, const u8 *tpm2b_digest, size_t digest_len,
+		     const u8 *ticket, size_t ticket_len, u8 *out)
+{
+	struct tpm_buf buf;
+
+	int ret = tpm_buf_init(&buf, TPM2_ST_SESSIONS, TPM2_CC_SIGN);
+	if (ret)
+		return ret;
+
+	/* signing key handle */
+	tpm_buf_append_u32(&buf, handle);
+
+	tpm2_buf_append_null_auth(&buf);
+
+	/* digest to sign */
+	tpm_buf_append(&buf, tpm2b_digest, digest_len);
+
+	/* sig scheme */
+	tpm_buf_append_u16(&buf, TPM_ALG_HMAC);
+	tpm_buf_append_u16(&buf, TPM_ALG_SHA256);
+
+	/* validation (needed for restricted keys) */
+	tpm_buf_append(&buf, ticket, ticket_len);
+
+	if (buf.flags & TPM_BUF_OVERFLOW) {
+		ret = -ENOMEM;
+		goto free_buf;
+	}
+
+	ret = tpm_transmit_cmd(chip, &buf, 4 + 2 + 2 + SHA256_DIGEST_SIZE,
+			       "sign data");
+	if (ret < 0)
+		goto free_buf;
+
+	if (ret > 0) {
+		ret = tpm2_rc_value(ret) == TPM2_RC_OBJECT_MEMORY ? -ENOMEM :
+								    -EPERM;
+		goto free_buf;
+	}
+
+	/* check resp len */
+	if (be32_to_cpup((__be32 *)&buf.data[TPM_HEADER_SIZE]) !=
+	    2 + 2 + SHA256_DIGEST_SIZE) {
+		ret = -EFAULT;
+		goto free_buf;
+	}
+
+	memcpy(out, &buf.data[TPM_HEADER_SIZE + 4 + 2 + 2], SHA256_DIGEST_SIZE);
+	memzero_explicit(&buf.data[TPM_HEADER_SIZE + 4 + 2 + 2],
+			 SHA256_DIGEST_SIZE);
+
+free_buf:
+	tpm_buf_destroy(&buf);
+	return ret;
+}
+
+static int tpm2_hash_final(struct shash_desc *desc, u8 *out)
+{
+	u32 handle;
+	int ret;
+	size_t digest_len;
+	struct tpm_buf *buf = shash_desc_ctx(desc);
+
+	/* adjust the input data length */
+	*((__be16 *)&buf->data[TPM_HEADER_SIZE]) =
+		cpu_to_be16(tpm_buf_length(buf) - TPM_HEADER_SIZE - 2);
+
+	tpm_buf_append_u16(buf, TPM_ALG_SHA256);
+	tpm_buf_append_u32(buf, TPM2_RH_OWNER);
+
+	if (buf->flags & TPM_BUF_OVERFLOW) {
+		ret = -ENOMEM;
+		goto free_buf;
+	}
+
+	ret = tpm_try_get_ops(chip);
+	if (ret)
+		goto free_buf;
+
+	ret = tpm_transmit_cmd(chip, buf, 2 + SHA256_DIGEST_SIZE, "hash data");
+	if (ret < 0)
+		goto put_ops;
+
+	if (ret > 0) {
+		ret = -EPERM;
+		goto put_ops;
+	}
+
+	ret = tpm2_hmac_create_primary(&handle);
+	if (ret)
+		goto put_ops;
+
+	digest_len = be16_to_cpup((__be16 *)&buf->data[TPM_HEADER_SIZE]) + 2;
+	ret = tpm2_sign(handle, &buf->data[TPM_HEADER_SIZE], digest_len,
+			&buf->data[TPM_HEADER_SIZE + digest_len],
+			tpm_buf_length(buf) - TPM_HEADER_SIZE - digest_len,
+			out);
+
+	tpm2_flush_context(chip, handle);
+
+put_ops:
+	tpm_put_ops(chip);
+free_buf:
+	tpm_buf_destroy(buf);
+	return ret;
+}
+
+static struct shash_alg alg = {
+	.digestsize = SHA256_DIGEST_SIZE,
+	.init = tpm2_hash_init,
+	.update = tpm2_hash_update,
+	.final = tpm2_hash_final,
+	.descsize = sizeof(struct tpm_buf),
+	.base = {
+		.cra_name = "sha256",
+		.cra_driver_name = TPM2_HASH_IMPL_NAME,
+		.cra_priority = 0,
+		.cra_blocksize = SHA256_BLOCK_SIZE,
+		.cra_flags = CRYPTO_ALG_INTERNAL,
+		.cra_module = THIS_MODULE,
+	}
+};
+
+int register_tpm2_shash(void)
+{
+	int ret;
+
+	chip = tpm_default_chip();
+	if (!chip)
+		return -ENODEV;
+
+	ret = crypto_register_shash(&alg);
+	if (ret)
+		put_device(&chip->dev);
+
+	return ret;
+}
+
+void unregister_tpm2_shash(void)
+{
+	crypto_unregister_shash(&alg);
+	if (chip)
+		put_device(&chip->dev);
+}
-- 
2.39.2

Re: [RFC PATCH 2/2] KEYS: implement derived keys

[Jarkko Sakkinen]

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

Re: [RFC PATCH 2/2] KEYS: implement derived keys

[Jarkko Sakkinen]

On Wed May 15, 2024 at 2:10 AM EEST, Jarkko Sakkinen wrote:
> 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.

Right and neither UIDs and GIDs are applicable for key derivation for
quite obvious reasons. So NAK for that too.

You can make them point out unlimited different identities...

BR, Jarkko

Re: [RFC PATCH 2/2] KEYS: implement derived keys

[Jarkko Sakkinen]

On Wed May 15, 2024 at 2:44 AM EEST, Jarkko Sakkinen wrote:
> >
> > 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.
>
> Right and neither UIDs and GIDs are applicable for key derivation for
> quite obvious reasons. So NAK for that too.
>
> You can make them point out unlimited different identities...

Please drop the whole stateless system argument from the next patch
set version. It looks to me that only it has been considered and we
don't even have definition what it is. I think it only distorts
and confuses and is totally app specific in the end of the day.

This looks more like a tool for identity theft than a key in its
current state. This could never ever exist in a "stateful system"
and this mainline code base so would be quite irresponsible to ever
take this.

There's only one attribute I'm aware that you could ever possibly
use for key derivation: mm_struct->exe_file.

BR, Jarkko

Re: [RFC PATCH 2/2] KEYS: implement derived keys

[Ignat Korchagin]

On Wed, May 15, 2024 at 12:44 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Wed May 15, 2024 at 2:10 AM EEST, Jarkko Sakkinen wrote:
> > 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.
>
> Right and neither UIDs and GIDs are applicable for key derivation for
> quite obvious reasons. So NAK for that too.

Can you, please, clarify a bit here? Not very obvious for me. I added
euid for two reasons:
  * an unprivileged user might run a normally privileged application,
for example /usr/sbin/sshd, and depending on the code could "leak" the
key
  * without it and with unprivileged user namespaces it is possible to
create an unprivileged container with code at the same path as a
privileged application

Why do you think UIDs/GIDs are not applicable as mixins?

Ignat

> You can make them point out unlimited different identities...
>
> BR, Jarkko

Re: [RFC PATCH 2/2] KEYS: implement derived keys

[Jarkko Sakkinen]

On Wed May 15, 2024 at 9:44 AM EEST, Ignat Korchagin wrote:
> On Wed, May 15, 2024 at 12:44 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Wed May 15, 2024 at 2:10 AM EEST, Jarkko Sakkinen wrote:
> > > 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.
> >
> > Right and neither UIDs and GIDs are applicable for key derivation for
> > quite obvious reasons. So NAK for that too.
>
> Can you, please, clarify a bit here? Not very obvious for me. I added
> euid for two reasons:
>   * an unprivileged user might run a normally privileged application,
> for example /usr/sbin/sshd, and depending on the code could "leak" the
> key
>   * without it and with unprivileged user namespaces it is possible to
> create an unprivileged container with code at the same path as a
> privileged application
>
> Why do you think UIDs/GIDs are not applicable as mixins?

I did as much clarification as I possibly can.

Also, if you look at confidential computing platforms there's exactly
two assets that they use lock into machine:

- Binary
- CPU material

Only carved into stone immutable material for key derivation.

You can use mm_struct->exe_file binary if that will work out for you.
I'm done with this version.

BR, Jarkko

Re: [RFC PATCH 2/2] KEYS: implement derived keys

[Jarkko Sakkinen]

On Wed May 15, 2024 at 3:00 PM EEST, Jarkko Sakkinen wrote:
> I did as much clarification as I possibly can.
>
> Also, if you look at confidential computing platforms there's exactly
> two assets that they use lock into machine:
>
> - Binary
> - CPU material
>
> Only carved into stone immutable material for key derivation.
>
> You can use mm_struct->exe_file binary if that will work out for you.
> I'm done with this version.

Pretty good case for having SGX, TDX and SNP in something else than just
Xeon's and EPYC's ;-)

But yeah within time limits I have I've used more quota for this
than I should have.

I look at +1 (if there is one).

BR, Jarkko

Re: [RFC PATCH 2/2] KEYS: implement derived keys

[Ignat Korchagin]

On Wed, May 15, 2024 at 12:10 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> 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.

Can you elaborate here? What kind of a problem you see specifically?
(This is exactly what I want to get from this discussion)

> 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.

With "this implementation" I meant the current RFC patchset because I
do expect there would be more iterations and just wanted to solicit
comments.

> 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.

Understood.

> >
> > 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
>

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Sat May 4, 2024 at 1:16 AM EEST, Ignat Korchagin wrote:
> TPM derived keys get their payload from an HMAC primary key in the owner
> hierarchy mixed with some metadata from the requesting process.

What metadata?
What is "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.

Which use cases?

Two first paragraphs are confusers not motivators with three undefined assets.

> 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.

What are the *existential* issues?

You are start by inconviences with trusted keys without describing for
what the trusted keys are used for.


> Moreover, we need to store the wrapped key blob somewhere, and if we lose it,
> the application cannot recover its data anymore.

I don't frankly understand what you are trying to say here. Somewhere is
not a place. It is an indeterministic entity.

>
> 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.

Does it or does it not make it easier? Please decide.

That said hard fine from mainline perspective unless there is an
existential issue.

>
> 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).

Please describe the implementation with request-key in the context of
the use case where it is used. That is what this should have started.
Then the motivation. Then the proposal for solution. And also focus
only on existential factors.

I have no idea for what the key created with this is even used, which
makes this impossible to review.

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Ben Boeckel]

On Sat, May 04, 2024 at 03:21:11 +0300, Jarkko Sakkinen wrote:
> I have no idea for what the key created with this is even used, which
> makes this impossible to review.

Additionally, there is nothing in Documentation/ for how userspace might
use or create them. This includes things like their description format
and describing available options.

--Ben

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Sat May 4, 2024 at 4:55 PM EEST, Ben Boeckel wrote:
> On Sat, May 04, 2024 at 03:21:11 +0300, Jarkko Sakkinen wrote:
> > I have no idea for what the key created with this is even used, which
> > makes this impossible to review.
>
> Additionally, there is nothing in Documentation/ for how userspace might
> use or create them. This includes things like their description format
> and describing available options.

The whole user story is plain out broken. Documenting a feature that has
no provable use case won't fix that part.

So it is better to start with the cover letter. With the *existing*
knowledge of the *real* issue I don't think we need this tbh.

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Sat May 4, 2024 at 5:51 PM EEST, Jarkko Sakkinen wrote:
> On Sat May 4, 2024 at 4:55 PM EEST, Ben Boeckel wrote:
> > On Sat, May 04, 2024 at 03:21:11 +0300, Jarkko Sakkinen wrote:
> > > I have no idea for what the key created with this is even used, which
> > > makes this impossible to review.
> >
> > Additionally, there is nothing in Documentation/ for how userspace might
> > use or create them. This includes things like their description format
> > and describing available options.
>
> The whole user story is plain out broken. Documenting a feature that has
> no provable use case won't fix that part.
>
> So it is better to start with the cover letter. With the *existing*
> knowledge of the *real* issue I don't think we need this tbh.

As for code I'd suggest the "Describe your changes" part from 

  https://www.kernel.org/doc/html/latest/process/submitting-patches.html

and most essentially how to split them properly.

My best bet could something along the lines that perhaps there is some
issue to be sorted out but I don't honestly believe that this will ever
be a solution for any possible problem that exist in this planet.

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Sat, May 4, 2024 at 5:35 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Sat May 4, 2024 at 5:51 PM EEST, Jarkko Sakkinen wrote:
> > On Sat May 4, 2024 at 4:55 PM EEST, Ben Boeckel wrote:
> > > On Sat, May 04, 2024 at 03:21:11 +0300, Jarkko Sakkinen wrote:
> > > > I have no idea for what the key created with this is even used, which
> > > > makes this impossible to review.
> > >
> > > Additionally, there is nothing in Documentation/ for how userspace might
> > > use or create them. This includes things like their description format
> > > and describing available options.
> >
> > The whole user story is plain out broken. Documenting a feature that has
> > no provable use case won't fix that part.
> >
> > So it is better to start with the cover letter. With the *existing*
> > knowledge of the *real* issue I don't think we need this tbh.
>
> As for code I'd suggest the "Describe your changes" part from
>
>   https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>
> and most essentially how to split them properly.
>
> My best bet could something along the lines that perhaps there is some
> issue to be sorted out but I don't honestly believe that this will ever
> be a solution for any possible problem that exist in this planet.

Sorry, I must admit I wrote the description hastingly and too
high-level (it was pre-travelling, so probably not the right focus and
in a rush). Let me restart from scratch and describe particular
use-cases we're concerned about:

Trusted and encrypted keys are a great way to manage cryptographic
keys inside the kernel, while never exposing plaintext cryptographic
material to userspace: keys can only be read to userspace as encrypted
blobs and with trusted keys - these blobs are created with the TPM, so
only the TPM can unwrap the blobs.

One of the simplest way to create a trusted key is for an application
to request the kernel to generate a new one [1], like below with the
help of keyctl utility from keyutils:
$ keyctl add trusted kmk "new 32 keyhandle=0x81000001" @u

However, after the application generates a trusted key, it is the
responsibility of the application to manage/store it. For example, if
the application wants to reuse the key after a reboot, it needs to
read the key into userspace as an encrypted blob and store it on
persistent storage. This is challenging and sometimes not possible for
stateless/immutable/ephemeral systems, so such systems are effectively
locked out from using hardware-protected cryptographic keys.

Another point: while the fact that the application can't read the
plaintext cryptographic material into userspace is a feature of
trusted keys, it can also be a disadvantage. Since keys in plaintext
exist only in kernel context, they are useful mostly for in-kernel
systems, like dm-crypt, IMA, ecryptfs. Applications cannot easily use
trusted keys for cryptographic purposes for their own workloads: for
example, generating encrypted or MACed configuration files or
encrypting in-transit data. While since commit 7984ceb134bf ("crypto:
af_alg - Support symmetric encryption via keyring keys") it is
possible to use a trusted key via Linux Crypto API userspace interface
[2], it might not always be practical/desirable:
  * due to limitations in the Linux Crypto API implementation it is
not possible to process more than ~64Kb of data using AEAD ciphers [3]
  * needed algorithm implementations might not be enabled in the
kernel configuration file
  * compliance constraints: the utilised cryptographic implementation
must be FIPS-validated
  * performance constraints: passing large blobs of data to the kernel
for encryption is slow even with Crypto API's "zero-copy" interface
[3]

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.

The applications then may either use in-kernel facilities, like [2],
to do crypto operations inside the kernel, so the generated
cryptographic material is never exposed to userspace (similar to
trusted/encrypted keys). Or, if they are subject to
performance/compliance/other constraints mentioned above, they can
read the key material to userspace and use a userspace crypto library.
Even with the latter approach they still get the benefit of using a
key, security of which is rooted in the TPM.

TPM derived keys also address the key storage problem for
stateless/immutable/ephemeral systems: since the derivation process is
deterministic, the same application can always re-create their keys on
the same system and doesn't need to store or back up any wrapped key
blobs. One notable use case (ironically not for a stateless system)
can be setting up proper full-disk encryption (dm-crypt plain mode
without a LUKS header), for example, to provide deniable encryption or
better resiliency to damage of encrypted media [4].

Current implementation provides two options for KDF's input for
application specific info to ensure key uniqueness:

1. A key, which is unique to a filesystem path:
$ keyctl add derived test '32 path'

Above 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. A key, which is cryptographically bound to the code of the
requesting application:
$ keyctl add derived test '32 csum'

Above 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 if and only if 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:
  * should any other modes/derivation parameters be considered as part
of application specific info?
  * 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?

I would like to mention that in Cloudflare we have found large
infrastructure key management based on derived keys from per-device
unique seeds quite convenient and almost infinitely scalable and I
believe TPM derived keys can be the next evolution bringing hardware
security to the table. I understand that folks here are not required
to follow links for additional information, but if someone is
interested in more details for our approach, which has been working
well for almost 9 years, see [5].

Hope it is better this time.

Ignat

[1]: https://www.kernel.org/doc/html/latest/security/keys/trusted-encrypted.html#examples-of-trusted-and-encrypted-key-usage
[2]: https://www.kernel.org/doc/html/latest/crypto/userspace-if.html
[3]: https://blog.cloudflare.com/the-linux-crypto-api-for-user-applications
[4]: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt
[5]: https://youtu.be/2RPcIbP2xsM?si=nKbyY0gss50i04CG

> BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[James Bottomley]

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

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

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. 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).

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.

> James
>

Re: [RFC PATCH 0/2] TPM derived keys

[James Bottomley]

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

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Tue, May 14, 2024 at 3:11 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> 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.

For our current (non-TPM based) derived key hierarchy we do allow
applications to specify a "freeform" mixing value, which in practice
may contain a key version, like "v1"/"v2" etc. This also allows
applications to derive multiple different keys for different purposes.
Perhaps, we can do the same here, for example keyctl add derived test
"<key len> (path|csum) <the rest is used as is as another mixin>". We
can also "just ship" a new version of the code (for the csum case),
which would rotate the key. Another option could be using some
optional xattr as a mixin, which can specify the version of the key or
just be a freeform input.

> James
>

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <ignat@cloudflare.com> wrote:
>
> 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

I would like to point out to myself I was wrong: it is possible to ask
the kernel to generate a trusted key inside the kernel locally with
"keyctl add trusted kmk "new 32" @u"

> 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
>

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Mon May 13, 2024 at 8:11 PM EEST, Ignat Korchagin wrote:
> On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <ignat@cloudflare.com> wrote:
> I would like to point out to myself I was wrong: it is possible to ask
> the kernel to generate a trusted key inside the kernel locally with
> "keyctl add trusted kmk "new 32" @u"

Not in a full-time kernel position ATM as I'm working as contract
researcher up until beginning of Oct (took some industry break after
a startup went down of business), so please, politely asking, write
a bit more compact descriptions ;-) I'm trying to find a new position by
the beginning of Oct but right now I'd appreciate a bit more thought out
text descriptions.

I'm working out a small patch set with James Prestwood to add asymmetric
TPM2 keys based on his old patch set [1] but laid out on top of the
existing baseline.

I did already the key type shenanigans etc. for it and James P is laying
his pre-existing RSA code and new ECDSA on top of that. So this will
give x.509 compatibility [2]. This patch set will be out soon and likely
part of 6.11 (or almost guaranteed as most of it is done).

So by plain guess this might be along the lines what you might want?

[1] https://lore.kernel.org/all/20200518172704.29608-1-prestwoj@gmail.com/
[2] https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Tue, May 14, 2024 at 1:28 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Mon May 13, 2024 at 8:11 PM EEST, Ignat Korchagin wrote:
> > On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <ignat@cloudflare.com> wrote:
> > I would like to point out to myself I was wrong: it is possible to ask
> > the kernel to generate a trusted key inside the kernel locally with
> > "keyctl add trusted kmk "new 32" @u"
>
> Not in a full-time kernel position ATM as I'm working as contract
> researcher up until beginning of Oct (took some industry break after
> a startup went down of business), so please, politely asking, write
> a bit more compact descriptions ;-) I'm trying to find a new position by
> the beginning of Oct but right now I'd appreciate a bit more thought out
> text descriptions.
>
> I'm working out a small patch set with James Prestwood to add asymmetric
> TPM2 keys based on his old patch set [1] but laid out on top of the
> existing baseline.
>
> I did already the key type shenanigans etc. for it and James P is laying
> his pre-existing RSA code and new ECDSA on top of that. So this will

This is great. Perhaps we can finally have ECDSA software signature
support as well, which I have been trying to get in for some time now
[1]

> give x.509 compatibility [2]. This patch set will be out soon and likely
> part of 6.11 (or almost guaranteed as most of it is done).
>
> So by plain guess this might be along the lines what you might want?

I don't think so. I have seen this patchset, but unless the new
version is fundamentally different, it looks to me that the asymmetric
TPM keys are the same as trusted keys except they are asymmetric
instead of being symmetric. That is, they are still of limited use on
stateless systems and are subject to the same restrictions I described
in my revised cover description.

On top of that I'm not sure they would be widely used as "leaf" keys
by applications, maybe more as root/intermediate keys in some kind of
key hierarchy. TPMs are slow and I don't see a high-performance
web-server, for example, using asymmetric TPM keys for TLS operations.
Also, as we learned the hard way operating many TPMs in production,
some TPMs are quite unreliable and fail really fast, if you "spam"
them with a lot of crypto ops. I understand this is a HW/TPM vendor
problem, but in practice we're trying to build systems, where TPM is
used to protect/generate other keys, but most of the "leaf" crypto
operations are done in software, so we don't make the TPM do too much
crypto.

Just to clarify - I'm not arguing about the usefulness of TPM
asymmetric keys in the kernel. I would really want to see this
building block available as well, but I think it just serves a
different purpose/use case from what I'm trying to figure out in this
RFC thread.

> [1] https://lore.kernel.org/all/20200518172704.29608-1-prestwoj@gmail.com/
> [2] https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/
>
> BR, Jarkko

[1] https://lore.kernel.org/lkml/20221014100737.94742-2-ignat@cloudflare.com/T/

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Tue May 14, 2024 at 1:05 PM EEST, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 1:28 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Mon May 13, 2024 at 8:11 PM EEST, Ignat Korchagin wrote:
> > > On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <ignat@cloudflare.com> wrote:
> > > I would like to point out to myself I was wrong: it is possible to ask
> > > the kernel to generate a trusted key inside the kernel locally with
> > > "keyctl add trusted kmk "new 32" @u"
> >
> > Not in a full-time kernel position ATM as I'm working as contract
> > researcher up until beginning of Oct (took some industry break after
> > a startup went down of business), so please, politely asking, write
> > a bit more compact descriptions ;-) I'm trying to find a new position by
> > the beginning of Oct but right now I'd appreciate a bit more thought out
> > text descriptions.
> >
> > I'm working out a small patch set with James Prestwood to add asymmetric
> > TPM2 keys based on his old patch set [1] but laid out on top of the
> > existing baseline.
> >
> > I did already the key type shenanigans etc. for it and James P is laying
> > his pre-existing RSA code and new ECDSA on top of that. So this will
>
> This is great. Perhaps we can finally have ECDSA software signature
> support as well, which I have been trying to get in for some time now
> [1]

Yes exactly both.

>
> > give x.509 compatibility [2]. This patch set will be out soon and likely
> > part of 6.11 (or almost guaranteed as most of it is done).
> >
> > So by plain guess this might be along the lines what you might want?
>
> I don't think so. I have seen this patchset, but unless the new
> version is fundamentally different, it looks to me that the asymmetric
> TPM keys are the same as trusted keys except they are asymmetric
> instead of being symmetric. That is, they are still of limited use on
> stateless systems and are subject to the same restrictions I described
> in my revised cover description.

OK, hmm... can you an "apples and oranges" example what would be
most trivial use case where these don't cut?


> On top of that I'm not sure they would be widely used as "leaf" keys
> by applications, maybe more as root/intermediate keys in some kind of
> key hierarchy. TPMs are slow and I don't see a high-performance
> web-server, for example, using asymmetric TPM keys for TLS operations.
> Also, as we learned the hard way operating many TPMs in production,
> some TPMs are quite unreliable and fail really fast, if you "spam"
> them with a lot of crypto ops. I understand this is a HW/TPM vendor
> problem, but in practice we're trying to build systems, where TPM is
> used to protect/generate other keys, but most of the "leaf" crypto
> operations are done in software, so we don't make the TPM do too much
> crypto.

So what about SGX/SNP/TDX?

TPM is definitely not made for workloads :-)

> Just to clarify - I'm not arguing about the usefulness of TPM
> asymmetric keys in the kernel. I would really want to see this
> building block available as well, but I think it just serves a
> different purpose/use case from what I'm trying to figure out in this
> RFC thread.

Got it :-) NP

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Tue, May 14, 2024 at 1:09 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue May 14, 2024 at 1:05 PM EEST, Ignat Korchagin wrote:
> > On Tue, May 14, 2024 at 1:28 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Mon May 13, 2024 at 8:11 PM EEST, Ignat Korchagin wrote:
> > > > On Fri, May 3, 2024 at 11:16 PM Ignat Korchagin <ignat@cloudflare.com> wrote:
> > > > I would like to point out to myself I was wrong: it is possible to ask
> > > > the kernel to generate a trusted key inside the kernel locally with
> > > > "keyctl add trusted kmk "new 32" @u"
> > >
> > > Not in a full-time kernel position ATM as I'm working as contract
> > > researcher up until beginning of Oct (took some industry break after
> > > a startup went down of business), so please, politely asking, write
> > > a bit more compact descriptions ;-) I'm trying to find a new position by
> > > the beginning of Oct but right now I'd appreciate a bit more thought out
> > > text descriptions.
> > >
> > > I'm working out a small patch set with James Prestwood to add asymmetric
> > > TPM2 keys based on his old patch set [1] but laid out on top of the
> > > existing baseline.
> > >
> > > I did already the key type shenanigans etc. for it and James P is laying
> > > his pre-existing RSA code and new ECDSA on top of that. So this will
> >
> > This is great. Perhaps we can finally have ECDSA software signature
> > support as well, which I have been trying to get in for some time now
> > [1]
>
> Yes exactly both.
>
> >
> > > give x.509 compatibility [2]. This patch set will be out soon and likely
> > > part of 6.11 (or almost guaranteed as most of it is done).
> > >
> > > So by plain guess this might be along the lines what you might want?
> >
> > I don't think so. I have seen this patchset, but unless the new
> > version is fundamentally different, it looks to me that the asymmetric
> > TPM keys are the same as trusted keys except they are asymmetric
> > instead of being symmetric. That is, they are still of limited use on
> > stateless systems and are subject to the same restrictions I described
> > in my revised cover description.
>
> OK, hmm... can you an "apples and oranges" example what would be
> most trivial use case where these don't cut?

For example, a cheap NAS box with no internal storage (disks connected
externally via USB). We want:
  * disks to be encrypted and decryptable only by this NAS box
  * if someone steals one of the disks - we don't want them to see it
has encrypted data (no LUKS header)

Additionally we may want to SSH into the NAS for configuration and we
don't want the SSH server key to change after each boot (regardless if
disks are connected or not).

>
> > On top of that I'm not sure they would be widely used as "leaf" keys
> > by applications, maybe more as root/intermediate keys in some kind of
> > key hierarchy. TPMs are slow and I don't see a high-performance
> > web-server, for example, using asymmetric TPM keys for TLS operations.
> > Also, as we learned the hard way operating many TPMs in production,
> > some TPMs are quite unreliable and fail really fast, if you "spam"
> > them with a lot of crypto ops. I understand this is a HW/TPM vendor
> > problem, but in practice we're trying to build systems, where TPM is
> > used to protect/generate other keys, but most of the "leaf" crypto
> > operations are done in software, so we don't make the TPM do too much
> > crypto.
>
> So what about SGX/SNP/TDX?

In theory yes, but I have chased the tech for a while on commodity HW
and it keeps having problems.

> TPM is definitely not made for workloads :-)
>
> > Just to clarify - I'm not arguing about the usefulness of TPM
> > asymmetric keys in the kernel. I would really want to see this
> > building block available as well, but I think it just serves a
> > different purpose/use case from what I'm trying to figure out in this
> > RFC thread.
>
> Got it :-) NP
>
> BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> For example, a cheap NAS box with no internal storage (disks connected
> externally via USB). We want:
>   * disks to be encrypted and decryptable only by this NAS box

So how this differs from LUKS2 style, which also systemd supports where
the encryption key is anchored to PCR's? If I took hard drive out of my
Linux box, I could not decrypt it in another machine because of this.

>   * if someone steals one of the disks - we don't want them to see it
> has encrypted data (no LUKS header)

So what happens when you reconnect?

> Additionally we may want to SSH into the NAS for configuration and we
> don't want the SSH server key to change after each boot (regardless if
> disks are connected or not).

Right, interesting use case. Begin before any technical jargon exactly
with a great example like this. Then it is easier to start to anchoring
stuff and not be misleaded.

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Tue May 14, 2024 at 5:00 PM EEST, Jarkko Sakkinen wrote:
> On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > For example, a cheap NAS box with no internal storage (disks connected
> > externally via USB). We want:
> >   * disks to be encrypted and decryptable only by this NAS box
>
> So how this differs from LUKS2 style, which also systemd supports where
> the encryption key is anchored to PCR's? If I took hard drive out of my
> Linux box, I could not decrypt it in another machine because of this.

Maybe you could replace the real LUKS2 header with a dummy LUKS2
header, which would need to be able the describe "do not use this" and
e.g. SHA256 of the actual header. And then treat the looked up header as
the header when the drive is mounted.

LUKS2 would also need to be able to have pre-defined (e.g. kernel
command-line or bootconfig) small internal storage, which would be
also encrypted with TPM's PRCs containing an array of LUKS2 header
and then look up that with SHA256 as the key.

Without knowing LUKS2 implementation to me these do not sound reaching
the impossible engineer problems so maybe this would be worth of
investigating...

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Tue May 14, 2024 at 5:30 PM EEST, Jarkko Sakkinen wrote:
> On Tue May 14, 2024 at 5:00 PM EEST, Jarkko Sakkinen wrote:
> > On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > > For example, a cheap NAS box with no internal storage (disks connected
> > > externally via USB). We want:
> > >   * disks to be encrypted and decryptable only by this NAS box
> >
> > So how this differs from LUKS2 style, which also systemd supports where
> > the encryption key is anchored to PCR's? If I took hard drive out of my
> > Linux box, I could not decrypt it in another machine because of this.
>
> Maybe you could replace the real LUKS2 header with a dummy LUKS2
> header, which would need to be able the describe "do not use this" and
> e.g. SHA256 of the actual header. And then treat the looked up header as
> the header when the drive is mounted.
>
> LUKS2 would also need to be able to have pre-defined (e.g. kernel
> command-line or bootconfig) small internal storage, which would be
> also encrypted with TPM's PRCs containing an array of LUKS2 header
> and then look up that with SHA256 as the key.
>
> Without knowing LUKS2 implementation to me these do not sound reaching
> the impossible engineer problems so maybe this would be worth of
> investigating...

Or why you could not just encrypt the whole header with another key
that is only in that device? Then it would appear as random full
length.

I.e. unsealing

1. Decrypt LUKS2 header with TPM2 key
2. Use the new resulting header as it was in the place of encrypted
   stored to the external drive.
3. Decrypt key from the LUK2S header etc.

?

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Tue May 14, 2024 at 6:21 PM EEST, Jarkko Sakkinen wrote:
> On Tue May 14, 2024 at 5:30 PM EEST, Jarkko Sakkinen wrote:
> > On Tue May 14, 2024 at 5:00 PM EEST, Jarkko Sakkinen wrote:
> > > On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > > > For example, a cheap NAS box with no internal storage (disks connected
> > > > externally via USB). We want:
> > > >   * disks to be encrypted and decryptable only by this NAS box
> > >
> > > So how this differs from LUKS2 style, which also systemd supports where
> > > the encryption key is anchored to PCR's? If I took hard drive out of my
> > > Linux box, I could not decrypt it in another machine because of this.
> >
> > Maybe you could replace the real LUKS2 header with a dummy LUKS2
> > header, which would need to be able the describe "do not use this" and
> > e.g. SHA256 of the actual header. And then treat the looked up header as
> > the header when the drive is mounted.
> >
> > LUKS2 would also need to be able to have pre-defined (e.g. kernel
> > command-line or bootconfig) small internal storage, which would be
> > also encrypted with TPM's PRCs containing an array of LUKS2 header
> > and then look up that with SHA256 as the key.
> >
> > Without knowing LUKS2 implementation to me these do not sound reaching
> > the impossible engineer problems so maybe this would be worth of
> > investigating...
>
> Or why you could not just encrypt the whole header with another key
> that is only in that device? Then it would appear as random full
> length.
>
> I.e. unsealing
>
> 1. Decrypt LUKS2 header with TPM2 key
> 2. Use the new resulting header as it was in the place of encrypted
>    stored to the external drive.
> 3. Decrypt key from the LUK2S header etc.

Maybe something like:

1. Asymmetric for LUKS2 (just like it is)
2. Additional symmetric key, which is created as non-migratable and stored
   to the TPM2 chip. This deciphers the header, i.e. takes the random
   away.

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Tue, May 14, 2024 at 4:26 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue May 14, 2024 at 6:21 PM EEST, Jarkko Sakkinen wrote:
> > On Tue May 14, 2024 at 5:30 PM EEST, Jarkko Sakkinen wrote:
> > > On Tue May 14, 2024 at 5:00 PM EEST, Jarkko Sakkinen wrote:
> > > > On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > > > > For example, a cheap NAS box with no internal storage (disks connected
> > > > > externally via USB). We want:
> > > > >   * disks to be encrypted and decryptable only by this NAS box
> > > >
> > > > So how this differs from LUKS2 style, which also systemd supports where
> > > > the encryption key is anchored to PCR's? If I took hard drive out of my
> > > > Linux box, I could not decrypt it in another machine because of this.
> > >
> > > Maybe you could replace the real LUKS2 header with a dummy LUKS2
> > > header, which would need to be able the describe "do not use this" and
> > > e.g. SHA256 of the actual header. And then treat the looked up header as
> > > the header when the drive is mounted.
> > >
> > > LUKS2 would also need to be able to have pre-defined (e.g. kernel
> > > command-line or bootconfig) small internal storage, which would be
> > > also encrypted with TPM's PRCs containing an array of LUKS2 header
> > > and then look up that with SHA256 as the key.
> > >
> > > Without knowing LUKS2 implementation to me these do not sound reaching
> > > the impossible engineer problems so maybe this would be worth of
> > > investigating...
> >
> > Or why you could not just encrypt the whole header with another key
> > that is only in that device? Then it would appear as random full
> > length.
> >
> > I.e. unsealing
> >
> > 1. Decrypt LUKS2 header with TPM2 key
> > 2. Use the new resulting header as it was in the place of encrypted
> >    stored to the external drive.
> > 3. Decrypt key from the LUK2S header etc.
>
> Maybe something like:
>
> 1. Asymmetric for LUKS2 (just like it is)
> 2. Additional symmetric key, which is created as non-migratable and stored
>    to the TPM2 chip. This deciphers the header, i.e. takes the random
>    away.

This could work, but you still have the problem of - if the header
gets wiped, all the data is lost.
As for storing things on the TPM chip - that doesn't scale. Today you
only think about disk encryption, tomorrow there is a new application,
which wants to do the same thing and so on. One of the features of
derived keys - you don't store anything, just recreate/derive when
needed and it scales infinitely.

> BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Tue May 14, 2024 at 6:30 PM EEST, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 4:26 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue May 14, 2024 at 6:21 PM EEST, Jarkko Sakkinen wrote:
> > > On Tue May 14, 2024 at 5:30 PM EEST, Jarkko Sakkinen wrote:
> > > > On Tue May 14, 2024 at 5:00 PM EEST, Jarkko Sakkinen wrote:
> > > > > On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > > > > > For example, a cheap NAS box with no internal storage (disks connected
> > > > > > externally via USB). We want:
> > > > > >   * disks to be encrypted and decryptable only by this NAS box
> > > > >
> > > > > So how this differs from LUKS2 style, which also systemd supports where
> > > > > the encryption key is anchored to PCR's? If I took hard drive out of my
> > > > > Linux box, I could not decrypt it in another machine because of this.
> > > >
> > > > Maybe you could replace the real LUKS2 header with a dummy LUKS2
> > > > header, which would need to be able the describe "do not use this" and
> > > > e.g. SHA256 of the actual header. And then treat the looked up header as
> > > > the header when the drive is mounted.
> > > >
> > > > LUKS2 would also need to be able to have pre-defined (e.g. kernel
> > > > command-line or bootconfig) small internal storage, which would be
> > > > also encrypted with TPM's PRCs containing an array of LUKS2 header
> > > > and then look up that with SHA256 as the key.
> > > >
> > > > Without knowing LUKS2 implementation to me these do not sound reaching
> > > > the impossible engineer problems so maybe this would be worth of
> > > > investigating...
> > >
> > > Or why you could not just encrypt the whole header with another key
> > > that is only in that device? Then it would appear as random full
> > > length.
> > >
> > > I.e. unsealing
> > >
> > > 1. Decrypt LUKS2 header with TPM2 key
> > > 2. Use the new resulting header as it was in the place of encrypted
> > >    stored to the external drive.
> > > 3. Decrypt key from the LUK2S header etc.
> >
> > Maybe something like:
> >
> > 1. Asymmetric for LUKS2 (just like it is)
> > 2. Additional symmetric key, which is created as non-migratable and stored
> >    to the TPM2 chip. This deciphers the header, i.e. takes the random
> >    away.
>
> This could work, but you still have the problem of - if the header
> gets wiped, all the data is lost.
> As for storing things on the TPM chip - that doesn't scale. Today you
> only think about disk encryption, tomorrow there is a new application,
> which wants to do the same thing and so on. One of the features of
> derived keys - you don't store anything, just recreate/derive when
> needed and it scales infinitely.

OK, so now I know the problem at least and that is probably the
most important thing in this discussion, right?

So make a better story, now you also probably have better idea,
also split the patch properly by subsystem, send the patch set,
and I'll promise to revisit.

Fair enough? :-)

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Tue, May 14, 2024 at 4:43 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue May 14, 2024 at 6:30 PM EEST, Ignat Korchagin wrote:
> > On Tue, May 14, 2024 at 4:26 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Tue May 14, 2024 at 6:21 PM EEST, Jarkko Sakkinen wrote:
> > > > On Tue May 14, 2024 at 5:30 PM EEST, Jarkko Sakkinen wrote:
> > > > > On Tue May 14, 2024 at 5:00 PM EEST, Jarkko Sakkinen wrote:
> > > > > > On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > > > > > > For example, a cheap NAS box with no internal storage (disks connected
> > > > > > > externally via USB). We want:
> > > > > > >   * disks to be encrypted and decryptable only by this NAS box
> > > > > >
> > > > > > So how this differs from LUKS2 style, which also systemd supports where
> > > > > > the encryption key is anchored to PCR's? If I took hard drive out of my
> > > > > > Linux box, I could not decrypt it in another machine because of this.
> > > > >
> > > > > Maybe you could replace the real LUKS2 header with a dummy LUKS2
> > > > > header, which would need to be able the describe "do not use this" and
> > > > > e.g. SHA256 of the actual header. And then treat the looked up header as
> > > > > the header when the drive is mounted.
> > > > >
> > > > > LUKS2 would also need to be able to have pre-defined (e.g. kernel
> > > > > command-line or bootconfig) small internal storage, which would be
> > > > > also encrypted with TPM's PRCs containing an array of LUKS2 header
> > > > > and then look up that with SHA256 as the key.
> > > > >
> > > > > Without knowing LUKS2 implementation to me these do not sound reaching
> > > > > the impossible engineer problems so maybe this would be worth of
> > > > > investigating...
> > > >
> > > > Or why you could not just encrypt the whole header with another key
> > > > that is only in that device? Then it would appear as random full
> > > > length.
> > > >
> > > > I.e. unsealing
> > > >
> > > > 1. Decrypt LUKS2 header with TPM2 key
> > > > 2. Use the new resulting header as it was in the place of encrypted
> > > >    stored to the external drive.
> > > > 3. Decrypt key from the LUK2S header etc.
> > >
> > > Maybe something like:
> > >
> > > 1. Asymmetric for LUKS2 (just like it is)
> > > 2. Additional symmetric key, which is created as non-migratable and stored
> > >    to the TPM2 chip. This deciphers the header, i.e. takes the random
> > >    away.
> >
> > This could work, but you still have the problem of - if the header
> > gets wiped, all the data is lost.
> > As for storing things on the TPM chip - that doesn't scale. Today you
> > only think about disk encryption, tomorrow there is a new application,
> > which wants to do the same thing and so on. One of the features of
> > derived keys - you don't store anything, just recreate/derive when
> > needed and it scales infinitely.
>
> OK, so now I know the problem at least and that is probably the
> most important thing in this discussion, right?

Yes, I think so.

> So make a better story, now you also probably have better idea,
> also split the patch properly by subsystem, send the patch set,

I'm actually not super clear on this part - I have two patches: one
for TPM header definitions and another one for the keyring subsystem?
Any other subsystems in play here?

> and I'll promise to revisit.

Thanks. Would probably take some time as I want to think more on the
open questions I raised in the description, try to address some
comments from James B from other replies (key rotation for example)
and rebase on recently merged TPM encrypted sessions. But since this
is an RFC I would like to continue the discussion and gather opinions
from folks here, if there are any more concerns.

> Fair enough? :-)
>
> BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Tue May 14, 2024 at 7:08 PM EEST, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 4:43 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue May 14, 2024 at 6:30 PM EEST, Ignat Korchagin wrote:
> > > On Tue, May 14, 2024 at 4:26 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >
> > > > On Tue May 14, 2024 at 6:21 PM EEST, Jarkko Sakkinen wrote:
> > > > > On Tue May 14, 2024 at 5:30 PM EEST, Jarkko Sakkinen wrote:
> > > > > > On Tue May 14, 2024 at 5:00 PM EEST, Jarkko Sakkinen wrote:
> > > > > > > On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > > > > > > > For example, a cheap NAS box with no internal storage (disks connected
> > > > > > > > externally via USB). We want:
> > > > > > > >   * disks to be encrypted and decryptable only by this NAS box
> > > > > > >
> > > > > > > So how this differs from LUKS2 style, which also systemd supports where
> > > > > > > the encryption key is anchored to PCR's? If I took hard drive out of my
> > > > > > > Linux box, I could not decrypt it in another machine because of this.
> > > > > >
> > > > > > Maybe you could replace the real LUKS2 header with a dummy LUKS2
> > > > > > header, which would need to be able the describe "do not use this" and
> > > > > > e.g. SHA256 of the actual header. And then treat the looked up header as
> > > > > > the header when the drive is mounted.
> > > > > >
> > > > > > LUKS2 would also need to be able to have pre-defined (e.g. kernel
> > > > > > command-line or bootconfig) small internal storage, which would be
> > > > > > also encrypted with TPM's PRCs containing an array of LUKS2 header
> > > > > > and then look up that with SHA256 as the key.
> > > > > >
> > > > > > Without knowing LUKS2 implementation to me these do not sound reaching
> > > > > > the impossible engineer problems so maybe this would be worth of
> > > > > > investigating...
> > > > >
> > > > > Or why you could not just encrypt the whole header with another key
> > > > > that is only in that device? Then it would appear as random full
> > > > > length.
> > > > >
> > > > > I.e. unsealing
> > > > >
> > > > > 1. Decrypt LUKS2 header with TPM2 key
> > > > > 2. Use the new resulting header as it was in the place of encrypted
> > > > >    stored to the external drive.
> > > > > 3. Decrypt key from the LUK2S header etc.
> > > >
> > > > Maybe something like:
> > > >
> > > > 1. Asymmetric for LUKS2 (just like it is)
> > > > 2. Additional symmetric key, which is created as non-migratable and stored
> > > >    to the TPM2 chip. This deciphers the header, i.e. takes the random
> > > >    away.
> > >
> > > This could work, but you still have the problem of - if the header
> > > gets wiped, all the data is lost.
> > > As for storing things on the TPM chip - that doesn't scale. Today you
> > > only think about disk encryption, tomorrow there is a new application,
> > > which wants to do the same thing and so on. One of the features of
> > > derived keys - you don't store anything, just recreate/derive when
> > > needed and it scales infinitely.
> >
> > OK, so now I know the problem at least and that is probably the
> > most important thing in this discussion, right?
>
> Yes, I think so.
>
> > So make a better story, now you also probably have better idea,
> > also split the patch properly by subsystem, send the patch set,
>
> I'm actually not super clear on this part - I have two patches: one
> for TPM header definitions and another one for the keyring subsystem?
> Any other subsystems in play here?

You're absolutely right the split is fine. I look patches every
day so that must have stuck me somewhere else (sometimes does
happen).

Sorry.

> > and I'll promise to revisit.
>
> Thanks. Would probably take some time as I want to think more on the
> open questions I raised in the description, try to address some
> comments from James B from other replies (key rotation for example)
> and rebase on recently merged TPM encrypted sessions. But since this
> is an RFC I would like to continue the discussion and gather opinions
> from folks here, if there are any more concerns.

Yeah, not trying to argue of anything. Just have shoot with
stupid questions until it gets through, and not pretending
of understanding if I actually do not :-)

So I'll be ready once the next version is out.

>
> > Fair enough? :-)
> >
> > BR, Jarkko


BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Tue, May 14, 2024 at 3:00 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > For example, a cheap NAS box with no internal storage (disks connected
> > externally via USB). We want:
> >   * disks to be encrypted and decryptable only by this NAS box
>
> So how this differs from LUKS2 style, which also systemd supports where
> the encryption key is anchored to PCR's? If I took hard drive out of my
> Linux box, I could not decrypt it in another machine because of this.

It differs with the fact that the disk has a clearly identifiable
LUKS2 header, which tells an adversary that this is a disk with some
data that is encrypted. With derived keys and plain dm-crypt mode
there is no LUKS header, so it is not possible to tell if it is an
encrypted disk or a disk with just random data. Additionally, if I
accidentally wipe the sector with the LUKS2 header - all my data is
lost (because the data encryption key from the header is lost). With
derived keys I can always decrypt at least some data, if the disk is
available.

> >   * if someone steals one of the disks - we don't want them to see it
> > has encrypted data (no LUKS header)
>
> So what happens when you reconnect?

We recover/derive the encryption key and unlock the disk again.

> > Additionally we may want to SSH into the NAS for configuration and we
> > don't want the SSH server key to change after each boot (regardless if
> > disks are connected or not).
>
> Right, interesting use case. Begin before any technical jargon exactly
> with a great example like this. Then it is easier to start to anchoring
> stuff and not be misleaded.
>
> BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[Jarkko Sakkinen]

On Tue May 14, 2024 at 5:41 PM EEST, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 3:00 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue May 14, 2024 at 4:11 PM EEST, Ignat Korchagin wrote:
> > > For example, a cheap NAS box with no internal storage (disks connected
> > > externally via USB). We want:
> > >   * disks to be encrypted and decryptable only by this NAS box
> >
> > So how this differs from LUKS2 style, which also systemd supports where
> > the encryption key is anchored to PCR's? If I took hard drive out of my
> > Linux box, I could not decrypt it in another machine because of this.
>
> It differs with the fact that the disk has a clearly identifiable
> LUKS2 header, which tells an adversary that this is a disk with some
> data that is encrypted. With derived keys and plain dm-crypt mode
> there is no LUKS header, so it is not possible to tell if it is an
> encrypted disk or a disk with just random data. Additionally, if I
> accidentally wipe the sector with the LUKS2 header - all my data is
> lost (because the data encryption key from the header is lost). With
> derived keys I can always decrypt at least some data, if the disk is
> available.

I figured most of this out myself and sent a follow-up but yeah thnaks
for confirming my toughts. I get this part now.

Follow-ups to my follow-up...

BR, Jarkko

Re: [RFC PATCH 0/2] TPM derived keys

[James Bottomley]

On Tue, 2024-05-14 at 14:11 +0100, Ignat Korchagin wrote:
>   * if someone steals one of the disks - we don't want them to see it
> has encrypted data (no LUKS header)

What is the use case that makes this important?  In usual operation
over the network, the fact that we're setting up encryption is easily
identifiable to any packet sniffer (DHE key exchanges are fairly easy
to fingerprint), but security relies on the fact that even knowing that
we're setting up encryption, the attacker can't gain access to it.  The
fact that we are setting up encryption isn't seen as a useful thing to
conceal, so why is it important for your encrypted disk use case?

James

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Tue, May 14, 2024 at 4:30 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2024-05-14 at 14:11 +0100, Ignat Korchagin wrote:
> >   * if someone steals one of the disks - we don't want them to see it
> > has encrypted data (no LUKS header)
>
> What is the use case that makes this important?  In usual operation
> over the network, the fact that we're setting up encryption is easily
> identifiable to any packet sniffer (DHE key exchanges are fairly easy
> to fingerprint), but security relies on the fact that even knowing that
> we're setting up encryption, the attacker can't gain access to it.  The
> fact that we are setting up encryption isn't seen as a useful thing to
> conceal, so why is it important for your encrypted disk use case?

In some "jurisdictions" authorities can demand that you decrypt the
data for them for "reasons". On the other hand if they can't prove
there is a ciphertext in the first place - it makes their case harder.

> James
>

Re: [RFC PATCH 0/2] TPM derived keys

[James Bottomley]

On Tue, 2024-05-14 at 16:38 +0100, Ignat Korchagin wrote:
> On Tue, May 14, 2024 at 4:30 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > On Tue, 2024-05-14 at 14:11 +0100, Ignat Korchagin wrote:
> > >   * if someone steals one of the disks - we don't want them to
> > > see it has encrypted data (no LUKS header)
> > 
> > What is the use case that makes this important?  In usual operation
> > over the network, the fact that we're setting up encryption is
> > easily identifiable to any packet sniffer (DHE key exchanges are
> > fairly easy to fingerprint), but security relies on the fact that
> > even knowing that we're setting up encryption, the attacker can't
> > gain access to it.  The fact that we are setting up encryption
> > isn't seen as a useful thing to conceal, so why is it important for
> > your encrypted disk use case?
> 
> In some "jurisdictions" authorities can demand that you decrypt the
> data for them for "reasons". On the other hand if they can't prove
> there is a ciphertext in the first place - it makes their case
> harder.

Well, this isn't necessarily a good assumption: the way to detect an
encrypted disk is to look at the entropy of the device blocks.  If the
disk is encrypted, the entropy will be pretty much maximal unlike every
other use case.  The other thing is that if the authorities have your
TPM, they already have access to the disk in this derived key scenario.
If *you* still have access to your TPM, you can update the storage seed
to shred the data.

James

Re: [RFC PATCH 0/2] TPM derived keys

[Ignat Korchagin]

On Tue, May 14, 2024 at 4:54 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2024-05-14 at 16:38 +0100, Ignat Korchagin wrote:
> > On Tue, May 14, 2024 at 4:30 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > >
> > > On Tue, 2024-05-14 at 14:11 +0100, Ignat Korchagin wrote:
> > > >   * if someone steals one of the disks - we don't want them to
> > > > see it has encrypted data (no LUKS header)
> > >
> > > What is the use case that makes this important?  In usual operation
> > > over the network, the fact that we're setting up encryption is
> > > easily identifiable to any packet sniffer (DHE key exchanges are
> > > fairly easy to fingerprint), but security relies on the fact that
> > > even knowing that we're setting up encryption, the attacker can't
> > > gain access to it.  The fact that we are setting up encryption
> > > isn't seen as a useful thing to conceal, so why is it important for
> > > your encrypted disk use case?
> >
> > In some "jurisdictions" authorities can demand that you decrypt the
> > data for them for "reasons". On the other hand if they can't prove
> > there is a ciphertext in the first place - it makes their case
> > harder.
>
> Well, this isn't necessarily a good assumption: the way to detect an
> encrypted disk is to look at the entropy of the device blocks.  If the
> disk is encrypted, the entropy will be pretty much maximal unlike every
> other use case.  The other thing is that if the authorities have your

What if the disk is filled with random data? Would it not be at maximal entropy?

> TPM, they already have access to the disk in this derived key scenario.

I'm thinking more of a datacenter scenario here - it is much easier to
"steal" a disk rather than a server from a datacenter. So it is
possible that someone has the disk but no access to the TPM.

> If *you* still have access to your TPM, you can update the storage seed
> to shred the data.

The point here is not if I was able to shred the data or not, but the
fact I have something encrypted. Even if I shred the key I would be
considered "uncooperative and refusing to provide the key" vs "I don't
have anything encrypted in the first place".

> James
>