Keyrings Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH v8 0/4] Introduce TEE based Trusted Keys support
@ 2020-11-03 16:01 Sumit Garg
  2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
                   ` (4 more replies)
  0 siblings, 5 replies; 27+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Add support for TEE based trusted keys where TEE provides the functionality
to seal and unseal trusted keys using hardware unique key. Also, this is
an alternative in case platform doesn't possess a TPM device.

This patch-set has been tested with OP-TEE based early TA which is already
merged in upstream [1].

[1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b

Changes in v8:
1. Added static calls support instead of indirect calls.
2. Documented trusted keys source module parameter.
3. Refined patch #1 commit message discription.
4. Addressed misc. comments on patch #2.
5. Added myself as Trusted Keys co-maintainer instead.
6. Rebased to latest tpmdd master.

Changes in v7:
1. Added a trusted.source module parameter in order to enforce user's
   choice in case a particular platform posses both TPM and TEE.
2. Refine commit description for patch #1.

Changes in v6:
1. Revert back to dynamic detection of trust source.
2. Drop author mention from trusted_core.c and trusted_tpm1.c files.
3. Rebased to latest tpmdd/master.

Changes in v5:
1. Drop dynamic detection of trust source and use compile time flags
   instead.
2. Rename trusted_common.c -> trusted_core.c.
3. Rename callback: cleanup() -> exit().
4. Drop "tk" acronym.
5. Other misc. comments.
6. Added review tags for patch #3 and #4.

Changes in v4:
1. Pushed independent TEE features separately:
  - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062
2. Updated trusted-encrypted doc with TEE as a new trust source.
3. Rebased onto latest tpmdd/master.

Changes in v3:
1. Update patch #2 to support registration of multiple kernel pages.
2. Incoporate dependency patch #4 in this patch-set:
   https://patchwork.kernel.org/patch/11091435/

Changes in v2:
1. Add reviewed-by tags for patch #1 and #2.
2. Incorporate comments from Jens for patch #3.
3. Switch to use generic trusted keys framework.

Sumit Garg (4):
  KEYS: trusted: Add generic trusted keys framework
  KEYS: trusted: Introduce TEE based Trusted Keys
  doc: trusted-encrypted: updates with TEE as a new trust source
  MAINTAINERS: Add myself as Trusted Keys co-maintainer

 Documentation/admin-guide/kernel-parameters.txt   |  12 +
 Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++--
 MAINTAINERS                                       |   2 +
 include/keys/trusted-type.h                       |  47 +++
 include/keys/trusted_tee.h                        |  55 ++++
 include/keys/trusted_tpm.h                        |  17 +-
 security/keys/trusted-keys/Makefile               |   2 +
 security/keys/trusted-keys/trusted_core.c         | 354 ++++++++++++++++++++++
 security/keys/trusted-keys/trusted_tee.c          | 278 +++++++++++++++++
 security/keys/trusted-keys/trusted_tpm1.c         | 336 ++++----------------
 10 files changed, 979 insertions(+), 327 deletions(-)
 create mode 100644 include/keys/trusted_tee.h
 create mode 100644 security/keys/trusted-keys/trusted_core.c
 create mode 100644 security/keys/trusted-keys/trusted_tee.c

-- 
2.7.4


^ permalink raw reply	[flat|nested] 27+ messages in thread

* [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
@ 2020-11-03 16:01 ` Sumit Garg
  2020-11-24  3:42   ` Jarkko Sakkinen
  2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 27+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Current trusted keys framework is tightly coupled to use TPM device as
an underlying implementation which makes it difficult for implementations
like Trusted Execution Environment (TEE) etc. to provide trusted keys
support in case platform doesn't posses a TPM device.

Add a generic trusted keys framework where underlying implementations
can be easily plugged in. Create struct trusted_key_ops to achieve this,
which contains necessary functions of a backend.

Also, define a module parameter in order to select a particular trust
source in case a platform support multiple trust sources. In case its
not specified then implementation itetrates through trust sources list
starting with TPM and assign the first trust source as a backend which
has initiazed successfully during iteration.

Note that current implementation only supports a single trust source at
runtime which is either selectable at compile time or during boot via
aforementioned module parameter.

Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  12 +
 include/keys/trusted-type.h                     |  47 ++++
 include/keys/trusted_tpm.h                      |  17 +-
 security/keys/trusted-keys/Makefile             |   1 +
 security/keys/trusted-keys/trusted_core.c       | 350 ++++++++++++++++++++++++
 security/keys/trusted-keys/trusted_tpm1.c       | 336 ++++-------------------
 6 files changed, 468 insertions(+), 295 deletions(-)
 create mode 100644 security/keys/trusted-keys/trusted_core.c

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d..df9b9fe 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5392,6 +5392,18 @@
 			See Documentation/admin-guide/mm/transhuge.rst
 			for more details.
 
+	trusted.source=	[KEYS]
+			Format: <string>
+			This parameter identifies the trust source as a backend
+			for trusted keys implementation. Supported trust
+			sources:
+			- "tpm"
+			- "tee"
+			If not specified then it defaults to iterating through
+			the trust source list starting with TPM and assigns the
+			first trust source as a backend which is initialized
+			successfully during iteration.
+
 	tsc=		Disable clocksource stability checks for TSC.
 			Format: <string>
 			[x86] reliable: mark tsc clocksource as reliable, this
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index a94c03a..a566451 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -40,6 +40,53 @@ struct trusted_key_options {
 	uint32_t policyhandle;
 };
 
+struct trusted_key_ops {
+	/*
+	 * flag to indicate if trusted key implementation supports migration
+	 * or not.
+	 */
+	unsigned char migratable;
+
+	/* Initialize key interface. */
+	int (*init)(void);
+
+	/* Seal a key. */
+	int (*seal)(struct trusted_key_payload *p, char *datablob);
+
+	/* Unseal a key. */
+	int (*unseal)(struct trusted_key_payload *p, char *datablob);
+
+	/* Get a randomized key. */
+	int (*get_random)(unsigned char *key, size_t key_len);
+
+	/* Exit key interface. */
+	void (*exit)(void);
+};
+
+struct trusted_key_source {
+	char *name;
+	struct trusted_key_ops *ops;
+};
+
 extern struct key_type key_type_trusted;
 
+#define TRUSTED_DEBUG 0
+
+#if TRUSTED_DEBUG
+static inline void dump_payload(struct trusted_key_payload *p)
+{
+	pr_info("trusted_key: key_len %d\n", p->key_len);
+	print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
+		       16, 1, p->key, p->key_len, 0);
+	pr_info("trusted_key: bloblen %d\n", p->blob_len);
+	print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
+		       16, 1, p->blob, p->blob_len, 0);
+	pr_info("trusted_key: migratable %d\n", p->migratable);
+}
+#else
+static inline void dump_payload(struct trusted_key_payload *p)
+{
+}
+#endif
+
 #endif /* _KEYS_TRUSTED_TYPE_H */
diff --git a/include/keys/trusted_tpm.h b/include/keys/trusted_tpm.h
index a56d8e1..fb3280a 100644
--- a/include/keys/trusted_tpm.h
+++ b/include/keys/trusted_tpm.h
@@ -16,6 +16,8 @@
 #define LOAD32N(buffer, offset)	(*(uint32_t *)&buffer[offset])
 #define LOAD16(buffer, offset)	(ntohs(*(uint16_t *)&buffer[offset]))
 
+extern struct trusted_key_ops tpm_trusted_key_ops;
+
 struct osapsess {
 	uint32_t handle;
 	unsigned char secret[SHA1_DIGEST_SIZE];
@@ -60,17 +62,6 @@ static inline void dump_options(struct trusted_key_options *o)
 		       16, 1, o->pcrinfo, o->pcrinfo_len, 0);
 }
 
-static inline void dump_payload(struct trusted_key_payload *p)
-{
-	pr_info("trusted_key: key_len %d\n", p->key_len);
-	print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
-		       16, 1, p->key, p->key_len, 0);
-	pr_info("trusted_key: bloblen %d\n", p->blob_len);
-	print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
-		       16, 1, p->blob, p->blob_len, 0);
-	pr_info("trusted_key: migratable %d\n", p->migratable);
-}
-
 static inline void dump_sess(struct osapsess *s)
 {
 	print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
@@ -96,10 +87,6 @@ static inline void dump_options(struct trusted_key_options *o)
 {
 }
 
-static inline void dump_payload(struct trusted_key_payload *p)
-{
-}
-
 static inline void dump_sess(struct osapsess *s)
 {
 }
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index 7b73ceb..49e3bcf 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -4,5 +4,6 @@
 #
 
 obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
+trusted-y += trusted_core.o
 trusted-y += trusted_tpm1.o
 trusted-y += trusted_tpm2.o
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
new file mode 100644
index 0000000..aa4f2a0
--- /dev/null
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2010 IBM Corporation
+ * Copyright (c) 2019-2020, Linaro Limited
+ *
+ * See Documentation/security/keys/trusted-encrypted.rst
+ */
+
+#include <keys/user-type.h>
+#include <keys/trusted-type.h>
+#include <keys/trusted_tpm.h>
+#include <linux/capability.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/key-type.h>
+#include <linux/module.h>
+#include <linux/parser.h>
+#include <linux/rcupdate.h>
+#include <linux/slab.h>
+#include <linux/static_call.h>
+#include <linux/string.h>
+#include <linux/uaccess.h>
+
+static char *trusted_key_source;
+module_param_named(source, trusted_key_source, charp, 0);
+MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
+
+static const struct trusted_key_source trusted_key_sources[] = {
+#if defined(CONFIG_TCG_TPM)
+	{ "tpm", &tpm_trusted_key_ops },
+#endif
+};
+
+DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
+DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal);
+DEFINE_STATIC_CALL_NULL(trusted_key_unseal,
+			*trusted_key_sources[0].ops->unseal);
+DEFINE_STATIC_CALL_NULL(trusted_key_get_random,
+			*trusted_key_sources[0].ops->get_random);
+DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit);
+static unsigned char migratable;
+
+enum {
+	Opt_err,
+	Opt_new, Opt_load, Opt_update,
+};
+
+static const match_table_t key_tokens = {
+	{Opt_new, "new"},
+	{Opt_load, "load"},
+	{Opt_update, "update"},
+	{Opt_err, NULL}
+};
+
+/*
+ * datablob_parse - parse the keyctl data and fill in the
+ *                  payload structure
+ *
+ * On success returns 0, otherwise -EINVAL.
+ */
+static int datablob_parse(char *datablob, struct trusted_key_payload *p)
+{
+	substring_t args[MAX_OPT_ARGS];
+	long keylen;
+	int ret = -EINVAL;
+	int key_cmd;
+	char *c;
+
+	/* main command */
+	c = strsep(&datablob, " \t");
+	if (!c)
+		return -EINVAL;
+	key_cmd = match_token(c, key_tokens, args);
+	switch (key_cmd) {
+	case Opt_new:
+		/* first argument is key size */
+		c = strsep(&datablob, " \t");
+		if (!c)
+			return -EINVAL;
+		ret = kstrtol(c, 10, &keylen);
+		if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
+			return -EINVAL;
+		p->key_len = keylen;
+		ret = Opt_new;
+		break;
+	case Opt_load:
+		/* first argument is sealed blob */
+		c = strsep(&datablob, " \t");
+		if (!c)
+			return -EINVAL;
+		p->blob_len = strlen(c) / 2;
+		if (p->blob_len > MAX_BLOB_SIZE)
+			return -EINVAL;
+		ret = hex2bin(p->blob, c, p->blob_len);
+		if (ret < 0)
+			return -EINVAL;
+		ret = Opt_load;
+		break;
+	case Opt_update:
+		ret = Opt_update;
+		break;
+	case Opt_err:
+		return -EINVAL;
+	}
+	return ret;
+}
+
+static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
+{
+	struct trusted_key_payload *p = NULL;
+	int ret;
+
+	ret = key_payload_reserve(key, sizeof(*p));
+	if (ret < 0)
+		return p;
+	p = kzalloc(sizeof(*p), GFP_KERNEL);
+
+	p->migratable = migratable;
+
+	return p;
+}
+
+/*
+ * trusted_instantiate - create a new trusted key
+ *
+ * Unseal an existing trusted blob or, for a new key, get a
+ * random key, then seal and create a trusted key-type key,
+ * adding it to the specified keyring.
+ *
+ * On success, return 0. Otherwise return errno.
+ */
+static int trusted_instantiate(struct key *key,
+			       struct key_preparsed_payload *prep)
+{
+	struct trusted_key_payload *payload = NULL;
+	size_t datalen = prep->datalen;
+	char *datablob;
+	int ret = 0;
+	int key_cmd;
+	size_t key_len;
+
+	if (datalen <= 0 || datalen > 32767 || !prep->data)
+		return -EINVAL;
+
+	datablob = kmalloc(datalen + 1, GFP_KERNEL);
+	if (!datablob)
+		return -ENOMEM;
+	memcpy(datablob, prep->data, datalen);
+	datablob[datalen] = '\0';
+
+	payload = trusted_payload_alloc(key);
+	if (!payload) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	key_cmd = datablob_parse(datablob, payload);
+	if (key_cmd < 0) {
+		ret = key_cmd;
+		goto out;
+	}
+
+	dump_payload(payload);
+
+	switch (key_cmd) {
+	case Opt_load:
+		ret = static_call(trusted_key_unseal)(payload, datablob);
+		dump_payload(payload);
+		if (ret < 0)
+			pr_info("trusted_key: key_unseal failed (%d)\n", ret);
+		break;
+	case Opt_new:
+		key_len = payload->key_len;
+		ret = static_call(trusted_key_get_random)(payload->key,
+							  key_len);
+		if (ret != key_len) {
+			pr_info("trusted_key: key_create failed (%d)\n", ret);
+			goto out;
+		}
+
+		ret = static_call(trusted_key_seal)(payload, datablob);
+		if (ret < 0)
+			pr_info("trusted_key: key_seal failed (%d)\n", ret);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+out:
+	kfree_sensitive(datablob);
+	if (!ret)
+		rcu_assign_keypointer(key, payload);
+	else
+		kfree_sensitive(payload);
+	return ret;
+}
+
+static void trusted_rcu_free(struct rcu_head *rcu)
+{
+	struct trusted_key_payload *p;
+
+	p = container_of(rcu, struct trusted_key_payload, rcu);
+	kfree_sensitive(p);
+}
+
+/*
+ * trusted_update - reseal an existing key with new PCR values
+ */
+static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
+{
+	struct trusted_key_payload *p;
+	struct trusted_key_payload *new_p;
+	size_t datalen = prep->datalen;
+	char *datablob;
+	int ret = 0;
+
+	if (key_is_negative(key))
+		return -ENOKEY;
+	p = key->payload.data[0];
+	if (!p->migratable)
+		return -EPERM;
+	if (datalen <= 0 || datalen > 32767 || !prep->data)
+		return -EINVAL;
+
+	datablob = kmalloc(datalen + 1, GFP_KERNEL);
+	if (!datablob)
+		return -ENOMEM;
+
+	new_p = trusted_payload_alloc(key);
+	if (!new_p) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	memcpy(datablob, prep->data, datalen);
+	datablob[datalen] = '\0';
+	ret = datablob_parse(datablob, new_p);
+	if (ret != Opt_update) {
+		ret = -EINVAL;
+		kfree_sensitive(new_p);
+		goto out;
+	}
+
+	/* copy old key values, and reseal with new pcrs */
+	new_p->migratable = p->migratable;
+	new_p->key_len = p->key_len;
+	memcpy(new_p->key, p->key, p->key_len);
+	dump_payload(p);
+	dump_payload(new_p);
+
+	ret = static_call(trusted_key_seal)(new_p, datablob);
+	if (ret < 0) {
+		pr_info("trusted_key: key_seal failed (%d)\n", ret);
+		kfree_sensitive(new_p);
+		goto out;
+	}
+
+	rcu_assign_keypointer(key, new_p);
+	call_rcu(&p->rcu, trusted_rcu_free);
+out:
+	kfree_sensitive(datablob);
+	return ret;
+}
+
+/*
+ * trusted_read - copy the sealed blob data to userspace in hex.
+ * On success, return to userspace the trusted key datablob size.
+ */
+static long trusted_read(const struct key *key, char *buffer,
+			 size_t buflen)
+{
+	const struct trusted_key_payload *p;
+	char *bufp;
+	int i;
+
+	p = dereference_key_locked(key);
+	if (!p)
+		return -EINVAL;
+
+	if (buffer && buflen >= 2 * p->blob_len) {
+		bufp = buffer;
+		for (i = 0; i < p->blob_len; i++)
+			bufp = hex_byte_pack(bufp, p->blob[i]);
+	}
+	return 2 * p->blob_len;
+}
+
+/*
+ * trusted_destroy - clear and free the key's payload
+ */
+static void trusted_destroy(struct key *key)
+{
+	kfree_sensitive(key->payload.data[0]);
+}
+
+struct key_type key_type_trusted = {
+	.name = "trusted",
+	.instantiate = trusted_instantiate,
+	.update = trusted_update,
+	.destroy = trusted_destroy,
+	.describe = user_describe,
+	.read = trusted_read,
+};
+EXPORT_SYMBOL_GPL(key_type_trusted);
+
+static int __init init_trusted(void)
+{
+	int i, ret = 0;
+
+	for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
+		if (trusted_key_source &&
+		    strncmp(trusted_key_source, trusted_key_sources[i].name,
+			    strlen(trusted_key_sources[i].name)))
+			continue;
+
+		static_call_update(trusted_key_init,
+				   trusted_key_sources[i].ops->init);
+		static_call_update(trusted_key_seal,
+				   trusted_key_sources[i].ops->seal);
+		static_call_update(trusted_key_unseal,
+				   trusted_key_sources[i].ops->unseal);
+		static_call_update(trusted_key_get_random,
+				   trusted_key_sources[i].ops->get_random);
+		static_call_update(trusted_key_exit,
+				   trusted_key_sources[i].ops->exit);
+		migratable = trusted_key_sources[i].ops->migratable;
+
+		ret = static_call(trusted_key_init)();
+		if (!ret)
+			break;
+	}
+
+	/*
+	 * encrypted_keys.ko depends on successful load of this module even if
+	 * trusted key implementation is not found.
+	 */
+	if (ret == -ENODEV)
+		return 0;
+
+	return ret;
+}
+
+static void __exit cleanup_trusted(void)
+{
+	static_call(trusted_key_exit)();
+}
+
+late_initcall(init_trusted);
+module_exit(cleanup_trusted);
+
+MODULE_LICENSE("GPL");
diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index b9fe02e..bd03914 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -1,29 +1,22 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
  * Copyright (C) 2010 IBM Corporation
- *
- * Author:
- * David Safford <safford@us.ibm.com>
+ * Copyright (c) 2019-2020, Linaro Limited
  *
  * See Documentation/security/keys/trusted-encrypted.rst
  */
 
 #include <crypto/hash_info.h>
-#include <linux/uaccess.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/slab.h>
 #include <linux/parser.h>
 #include <linux/string.h>
 #include <linux/err.h>
-#include <keys/user-type.h>
 #include <keys/trusted-type.h>
 #include <linux/key-type.h>
-#include <linux/rcupdate.h>
 #include <linux/crypto.h>
 #include <crypto/hash.h>
 #include <crypto/sha.h>
-#include <linux/capability.h>
 #include <linux/tpm.h>
 #include <linux/tpm_command.h>
 
@@ -703,7 +696,6 @@ static int key_unseal(struct trusted_key_payload *p,
 
 enum {
 	Opt_err,
-	Opt_new, Opt_load, Opt_update,
 	Opt_keyhandle, Opt_keyauth, Opt_blobauth,
 	Opt_pcrinfo, Opt_pcrlock, Opt_migratable,
 	Opt_hash,
@@ -712,9 +704,6 @@ enum {
 };
 
 static const match_table_t key_tokens = {
-	{Opt_new, "new"},
-	{Opt_load, "load"},
-	{Opt_update, "update"},
 	{Opt_keyhandle, "keyhandle=%s"},
 	{Opt_keyauth, "keyauth=%s"},
 	{Opt_blobauth, "blobauth=%s"},
@@ -841,71 +830,6 @@ static int getoptions(char *c, struct trusted_key_payload *pay,
 	return 0;
 }
 
-/*
- * datablob_parse - parse the keyctl data and fill in the
- * 		    payload and options structures
- *
- * On success returns 0, otherwise -EINVAL.
- */
-static int datablob_parse(char *datablob, struct trusted_key_payload *p,
-			  struct trusted_key_options *o)
-{
-	substring_t args[MAX_OPT_ARGS];
-	long keylen;
-	int ret = -EINVAL;
-	int key_cmd;
-	char *c;
-
-	/* main command */
-	c = strsep(&datablob, " \t");
-	if (!c)
-		return -EINVAL;
-	key_cmd = match_token(c, key_tokens, args);
-	switch (key_cmd) {
-	case Opt_new:
-		/* first argument is key size */
-		c = strsep(&datablob, " \t");
-		if (!c)
-			return -EINVAL;
-		ret = kstrtol(c, 10, &keylen);
-		if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
-			return -EINVAL;
-		p->key_len = keylen;
-		ret = getoptions(datablob, p, o);
-		if (ret < 0)
-			return ret;
-		ret = Opt_new;
-		break;
-	case Opt_load:
-		/* first argument is sealed blob */
-		c = strsep(&datablob, " \t");
-		if (!c)
-			return -EINVAL;
-		p->blob_len = strlen(c) / 2;
-		if (p->blob_len > MAX_BLOB_SIZE)
-			return -EINVAL;
-		ret = hex2bin(p->blob, c, p->blob_len);
-		if (ret < 0)
-			return -EINVAL;
-		ret = getoptions(datablob, p, o);
-		if (ret < 0)
-			return ret;
-		ret = Opt_load;
-		break;
-	case Opt_update:
-		/* all arguments are options */
-		ret = getoptions(datablob, p, o);
-		if (ret < 0)
-			return ret;
-		ret = Opt_update;
-		break;
-	case Opt_err:
-		return -EINVAL;
-		break;
-	}
-	return ret;
-}
-
 static struct trusted_key_options *trusted_options_alloc(void)
 {
 	struct trusted_key_options *options;
@@ -926,248 +850,99 @@ static struct trusted_key_options *trusted_options_alloc(void)
 	return options;
 }
 
-static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
+static int trusted_tpm_seal(struct trusted_key_payload *p, char *datablob)
 {
-	struct trusted_key_payload *p = NULL;
-	int ret;
-
-	ret = key_payload_reserve(key, sizeof *p);
-	if (ret < 0)
-		return p;
-	p = kzalloc(sizeof *p, GFP_KERNEL);
-	if (p)
-		p->migratable = 1; /* migratable by default */
-	return p;
-}
-
-/*
- * trusted_instantiate - create a new trusted key
- *
- * Unseal an existing trusted blob or, for a new key, get a
- * random key, then seal and create a trusted key-type key,
- * adding it to the specified keyring.
- *
- * On success, return 0. Otherwise return errno.
- */
-static int trusted_instantiate(struct key *key,
-			       struct key_preparsed_payload *prep)
-{
-	struct trusted_key_payload *payload = NULL;
 	struct trusted_key_options *options = NULL;
-	size_t datalen = prep->datalen;
-	char *datablob;
 	int ret = 0;
-	int key_cmd;
-	size_t key_len;
 	int tpm2;
 
 	tpm2 = tpm_is_tpm2(chip);
 	if (tpm2 < 0)
 		return tpm2;
 
-	if (datalen <= 0 || datalen > 32767 || !prep->data)
-		return -EINVAL;
-
-	datablob = kmalloc(datalen + 1, GFP_KERNEL);
-	if (!datablob)
-		return -ENOMEM;
-	memcpy(datablob, prep->data, datalen);
-	datablob[datalen] = '\0';
-
 	options = trusted_options_alloc();
-	if (!options) {
-		ret = -ENOMEM;
-		goto out;
-	}
-	payload = trusted_payload_alloc(key);
-	if (!payload) {
-		ret = -ENOMEM;
-		goto out;
-	}
+	if (!options)
+		return -ENOMEM;
 
-	key_cmd = datablob_parse(datablob, payload, options);
-	if (key_cmd < 0) {
-		ret = key_cmd;
+	ret = getoptions(datablob, p, options);
+	if (ret < 0)
 		goto out;
-	}
+	dump_options(options);
 
 	if (!options->keyhandle) {
 		ret = -EINVAL;
 		goto out;
 	}
 
-	dump_payload(payload);
-	dump_options(options);
+	if (tpm2)
+		ret = tpm2_seal_trusted(chip, p, options);
+	else
+		ret = key_seal(p, options);
+	if (ret < 0) {
+		pr_info("tpm_trusted_key: key_seal failed (%d)\n", ret);
+		goto out;
+	}
 
-	switch (key_cmd) {
-	case Opt_load:
-		if (tpm2)
-			ret = tpm2_unseal_trusted(chip, payload, options);
-		else
-			ret = key_unseal(payload, options);
-		dump_payload(payload);
-		dump_options(options);
-		if (ret < 0)
-			pr_info("trusted_key: key_unseal failed (%d)\n", ret);
-		break;
-	case Opt_new:
-		key_len = payload->key_len;
-		ret = tpm_get_random(chip, payload->key, key_len);
-		if (ret != key_len) {
-			pr_info("trusted_key: key_create failed (%d)\n", ret);
+	if (options->pcrlock) {
+		ret = pcrlock(options->pcrlock);
+		if (ret < 0) {
+			pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
 			goto out;
 		}
-		if (tpm2)
-			ret = tpm2_seal_trusted(chip, payload, options);
-		else
-			ret = key_seal(payload, options);
-		if (ret < 0)
-			pr_info("trusted_key: key_seal failed (%d)\n", ret);
-		break;
-	default:
-		ret = -EINVAL;
-		goto out;
 	}
-	if (!ret && options->pcrlock)
-		ret = pcrlock(options->pcrlock);
 out:
-	kfree_sensitive(datablob);
 	kfree_sensitive(options);
-	if (!ret)
-		rcu_assign_keypointer(key, payload);
-	else
-		kfree_sensitive(payload);
 	return ret;
 }
 
-static void trusted_rcu_free(struct rcu_head *rcu)
-{
-	struct trusted_key_payload *p;
-
-	p = container_of(rcu, struct trusted_key_payload, rcu);
-	kfree_sensitive(p);
-}
-
-/*
- * trusted_update - reseal an existing key with new PCR values
- */
-static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
+static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
 {
-	struct trusted_key_payload *p;
-	struct trusted_key_payload *new_p;
-	struct trusted_key_options *new_o;
-	size_t datalen = prep->datalen;
-	char *datablob;
+	struct trusted_key_options *options = NULL;
 	int ret = 0;
+	int tpm2;
 
-	if (key_is_negative(key))
-		return -ENOKEY;
-	p = key->payload.data[0];
-	if (!p->migratable)
-		return -EPERM;
-	if (datalen <= 0 || datalen > 32767 || !prep->data)
-		return -EINVAL;
+	tpm2 = tpm_is_tpm2(chip);
+	if (tpm2 < 0)
+		return tpm2;
 
-	datablob = kmalloc(datalen + 1, GFP_KERNEL);
-	if (!datablob)
+	options = trusted_options_alloc();
+	if (!options)
 		return -ENOMEM;
-	new_o = trusted_options_alloc();
-	if (!new_o) {
-		ret = -ENOMEM;
-		goto out;
-	}
-	new_p = trusted_payload_alloc(key);
-	if (!new_p) {
-		ret = -ENOMEM;
-		goto out;
-	}
 
-	memcpy(datablob, prep->data, datalen);
-	datablob[datalen] = '\0';
-	ret = datablob_parse(datablob, new_p, new_o);
-	if (ret != Opt_update) {
-		ret = -EINVAL;
-		kfree_sensitive(new_p);
+	ret = getoptions(datablob, p, options);
+	if (ret < 0)
 		goto out;
-	}
+	dump_options(options);
 
-	if (!new_o->keyhandle) {
+	if (!options->keyhandle) {
 		ret = -EINVAL;
-		kfree_sensitive(new_p);
 		goto out;
 	}
 
-	/* copy old key values, and reseal with new pcrs */
-	new_p->migratable = p->migratable;
-	new_p->key_len = p->key_len;
-	memcpy(new_p->key, p->key, p->key_len);
-	dump_payload(p);
-	dump_payload(new_p);
+	if (tpm2)
+		ret = tpm2_unseal_trusted(chip, p, options);
+	else
+		ret = key_unseal(p, options);
+	if (ret < 0)
+		pr_info("tpm_trusted_key: key_unseal failed (%d)\n", ret);
 
-	ret = key_seal(new_p, new_o);
-	if (ret < 0) {
-		pr_info("trusted_key: key_seal failed (%d)\n", ret);
-		kfree_sensitive(new_p);
-		goto out;
-	}
-	if (new_o->pcrlock) {
-		ret = pcrlock(new_o->pcrlock);
+	if (options->pcrlock) {
+		ret = pcrlock(options->pcrlock);
 		if (ret < 0) {
-			pr_info("trusted_key: pcrlock failed (%d)\n", ret);
-			kfree_sensitive(new_p);
+			pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
 			goto out;
 		}
 	}
-	rcu_assign_keypointer(key, new_p);
-	call_rcu(&p->rcu, trusted_rcu_free);
 out:
-	kfree_sensitive(datablob);
-	kfree_sensitive(new_o);
+	kfree_sensitive(options);
 	return ret;
 }
 
-/*
- * trusted_read - copy the sealed blob data to userspace in hex.
- * On success, return to userspace the trusted key datablob size.
- */
-static long trusted_read(const struct key *key, char *buffer,
-			 size_t buflen)
-{
-	const struct trusted_key_payload *p;
-	char *bufp;
-	int i;
-
-	p = dereference_key_locked(key);
-	if (!p)
-		return -EINVAL;
-
-	if (buffer && buflen >= 2 * p->blob_len) {
-		bufp = buffer;
-		for (i = 0; i < p->blob_len; i++)
-			bufp = hex_byte_pack(bufp, p->blob[i]);
-	}
-	return 2 * p->blob_len;
-}
-
-/*
- * trusted_destroy - clear and free the key's payload
- */
-static void trusted_destroy(struct key *key)
+static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
 {
-	kfree_sensitive(key->payload.data[0]);
+	return tpm_get_random(chip, key, key_len);
 }
 
-struct key_type key_type_trusted = {
-	.name = "trusted",
-	.instantiate = trusted_instantiate,
-	.update = trusted_update,
-	.destroy = trusted_destroy,
-	.describe = user_describe,
-	.read = trusted_read,
-};
-
-EXPORT_SYMBOL_GPL(key_type_trusted);
-
 static void trusted_shash_release(void)
 {
 	if (hashalg)
@@ -1182,14 +957,14 @@ static int __init trusted_shash_alloc(void)
 
 	hmacalg = crypto_alloc_shash(hmac_alg, 0, 0);
 	if (IS_ERR(hmacalg)) {
-		pr_info("trusted_key: could not allocate crypto %s\n",
+		pr_info("tpm_trusted_key: could not allocate crypto %s\n",
 			hmac_alg);
 		return PTR_ERR(hmacalg);
 	}
 
 	hashalg = crypto_alloc_shash(hash_alg, 0, 0);
 	if (IS_ERR(hashalg)) {
-		pr_info("trusted_key: could not allocate crypto %s\n",
+		pr_info("tpm_trusted_key: could not allocate crypto %s\n",
 			hash_alg);
 		ret = PTR_ERR(hashalg);
 		goto hashalg_fail;
@@ -1217,16 +992,13 @@ static int __init init_digests(void)
 	return 0;
 }
 
-static int __init init_trusted(void)
+static int trusted_tpm_init(void)
 {
 	int ret;
 
-	/* encrypted_keys.ko depends on successful load of this module even if
-	 * TPM is not used.
-	 */
 	chip = tpm_default_chip();
 	if (!chip)
-		return 0;
+		return -ENODEV;
 
 	ret = init_digests();
 	if (ret < 0)
@@ -1247,7 +1019,7 @@ static int __init init_trusted(void)
 	return ret;
 }
 
-static void __exit cleanup_trusted(void)
+static void trusted_tpm_exit(void)
 {
 	if (chip) {
 		put_device(&chip->dev);
@@ -1257,7 +1029,11 @@ static void __exit cleanup_trusted(void)
 	}
 }
 
-late_initcall(init_trusted);
-module_exit(cleanup_trusted);
-
-MODULE_LICENSE("GPL");
+struct trusted_key_ops tpm_trusted_key_ops = {
+	.migratable = 1, /* migratable by default */
+	.init = trusted_tpm_init,
+	.seal = trusted_tpm_seal,
+	.unseal = trusted_tpm_unseal,
+	.get_random = trusted_tpm_get_random,
+	.exit = trusted_tpm_exit,
+};
-- 
2.7.4


^ permalink raw reply	[flat|nested] 27+ messages in thread

* [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
  2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
@ 2020-11-03 16:01 ` Sumit Garg
  2020-11-24  3:46   ` Jarkko Sakkinen
  2021-01-11 16:35   ` Jarkko Sakkinen
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 27+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Add support for TEE based trusted keys where TEE provides the functionality
to seal and unseal trusted keys using hardware unique key.

Refer to Documentation/tee.txt for detailed information about TEE.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 include/keys/trusted_tee.h                |  55 ++++++
 security/keys/trusted-keys/Makefile       |   1 +
 security/keys/trusted-keys/trusted_core.c |   4 +
 security/keys/trusted-keys/trusted_tee.c  | 278 ++++++++++++++++++++++++++++++
 4 files changed, 338 insertions(+)
 create mode 100644 include/keys/trusted_tee.h
 create mode 100644 security/keys/trusted-keys/trusted_tee.c

diff --git a/include/keys/trusted_tee.h b/include/keys/trusted_tee.h
new file mode 100644
index 0000000..2e2bb15
--- /dev/null
+++ b/include/keys/trusted_tee.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019-2020 Linaro Ltd.
+ *
+ * Author:
+ * Sumit Garg <sumit.garg@linaro.org>
+ */
+
+#ifndef __TEE_TRUSTED_KEY_H
+#define __TEE_TRUSTED_KEY_H
+
+#include <linux/tee_drv.h>
+
+#define DRIVER_NAME "tee-trusted-key"
+
+/*
+ * Get random data for symmetric key
+ *
+ * [out]     memref[0]        Random data
+ */
+#define TA_CMD_GET_RANDOM	0x0
+
+/*
+ * Seal trusted key using hardware unique key
+ *
+ * [in]      memref[0]        Plain key
+ * [out]     memref[1]        Sealed key datablob
+ */
+#define TA_CMD_SEAL		0x1
+
+/*
+ * Unseal trusted key using hardware unique key
+ *
+ * [in]      memref[0]        Sealed key datablob
+ * [out]     memref[1]        Plain key
+ */
+#define TA_CMD_UNSEAL		0x2
+
+/**
+ * struct trusted_key_private - TEE Trusted key private data
+ * @dev:		TEE based Trusted key device.
+ * @ctx:		TEE context handler.
+ * @session_id:		Trusted key TA session identifier.
+ * @shm_pool:		Memory pool shared with TEE device.
+ */
+struct trusted_key_private {
+	struct device *dev;
+	struct tee_context *ctx;
+	u32 session_id;
+	struct tee_shm *shm_pool;
+};
+
+extern struct trusted_key_ops tee_trusted_key_ops;
+
+#endif
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index 49e3bcf..012dd78 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
 trusted-y += trusted_core.o
 trusted-y += trusted_tpm1.o
 trusted-y += trusted_tpm2.o
+trusted-y += trusted_tee.o
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index aa4f2a0..15b1b0f3 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -8,6 +8,7 @@
 
 #include <keys/user-type.h>
 #include <keys/trusted-type.h>
+#include <keys/trusted_tee.h>
 #include <keys/trusted_tpm.h>
 #include <linux/capability.h>
 #include <linux/err.h>
@@ -29,6 +30,9 @@ static const struct trusted_key_source trusted_key_sources[] = {
 #if defined(CONFIG_TCG_TPM)
 	{ "tpm", &tpm_trusted_key_ops },
 #endif
+#if defined(CONFIG_TEE)
+	{ "tee", &tee_trusted_key_ops },
+#endif
 };
 
 DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
new file mode 100644
index 0000000..da8785a
--- /dev/null
+++ b/security/keys/trusted-keys/trusted_tee.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019-2020 Linaro Ltd.
+ *
+ * Author:
+ * Sumit Garg <sumit.garg@linaro.org>
+ */
+
+#include <linux/err.h>
+#include <linux/key-type.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/uuid.h>
+
+#include <keys/trusted-type.h>
+#include <keys/trusted_tee.h>
+
+static struct trusted_key_private pvt_data;
+
+/*
+ * Have the TEE seal(encrypt) the symmetric key
+ */
+static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob)
+{
+	int ret;
+	struct tee_ioctl_invoke_arg inv_arg;
+	struct tee_param param[4];
+	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
+
+	memset(&inv_arg, 0, sizeof(inv_arg));
+	memset(&param, 0, sizeof(param));
+
+	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
+				      p->key_len, TEE_SHM_DMA_BUF |
+				      TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm_in)) {
+		dev_err(pvt_data.dev, "key shm register failed\n");
+		return PTR_ERR(reg_shm_in);
+	}
+
+	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
+				       sizeof(p->blob), TEE_SHM_DMA_BUF |
+				       TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm_out)) {
+		dev_err(pvt_data.dev, "blob shm register failed\n");
+		ret = PTR_ERR(reg_shm_out);
+		goto out;
+	}
+
+	inv_arg.func = TA_CMD_SEAL;
+	inv_arg.session = pvt_data.session_id;
+	inv_arg.num_params = 4;
+
+	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
+	param[0].u.memref.shm = reg_shm_in;
+	param[0].u.memref.size = p->key_len;
+	param[0].u.memref.shm_offs = 0;
+	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+	param[1].u.memref.shm = reg_shm_out;
+	param[1].u.memref.size = sizeof(p->blob);
+	param[1].u.memref.shm_offs = 0;
+
+	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
+	if ((ret < 0) || (inv_arg.ret != 0)) {
+		dev_err(pvt_data.dev, "TA_CMD_SEAL invoke err: %x\n",
+			inv_arg.ret);
+		ret = -EFAULT;
+	} else {
+		p->blob_len = param[1].u.memref.size;
+	}
+
+out:
+	if (reg_shm_out)
+		tee_shm_free(reg_shm_out);
+	if (reg_shm_in)
+		tee_shm_free(reg_shm_in);
+
+	return ret;
+}
+
+/*
+ * Have the TEE unseal(decrypt) the symmetric key
+ */
+static int trusted_tee_unseal(struct trusted_key_payload *p, char *datablob)
+{
+	int ret;
+	struct tee_ioctl_invoke_arg inv_arg;
+	struct tee_param param[4];
+	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
+
+	memset(&inv_arg, 0, sizeof(inv_arg));
+	memset(&param, 0, sizeof(param));
+
+	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
+				      p->blob_len, TEE_SHM_DMA_BUF |
+				      TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm_in)) {
+		dev_err(pvt_data.dev, "blob shm register failed\n");
+		return PTR_ERR(reg_shm_in);
+	}
+
+	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
+				       sizeof(p->key), TEE_SHM_DMA_BUF |
+				       TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm_out)) {
+		dev_err(pvt_data.dev, "key shm register failed\n");
+		ret = PTR_ERR(reg_shm_out);
+		goto out;
+	}
+
+	inv_arg.func = TA_CMD_UNSEAL;
+	inv_arg.session = pvt_data.session_id;
+	inv_arg.num_params = 4;
+
+	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
+	param[0].u.memref.shm = reg_shm_in;
+	param[0].u.memref.size = p->blob_len;
+	param[0].u.memref.shm_offs = 0;
+	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+	param[1].u.memref.shm = reg_shm_out;
+	param[1].u.memref.size = sizeof(p->key);
+	param[1].u.memref.shm_offs = 0;
+
+	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
+	if ((ret < 0) || (inv_arg.ret != 0)) {
+		dev_err(pvt_data.dev, "TA_CMD_UNSEAL invoke err: %x\n",
+			inv_arg.ret);
+		ret = -EFAULT;
+	} else {
+		p->key_len = param[1].u.memref.size;
+	}
+
+out:
+	if (reg_shm_out)
+		tee_shm_free(reg_shm_out);
+	if (reg_shm_in)
+		tee_shm_free(reg_shm_in);
+
+	return ret;
+}
+
+/*
+ * Have the TEE generate random symmetric key
+ */
+static int trusted_tee_get_random(unsigned char *key, size_t key_len)
+{
+	int ret;
+	struct tee_ioctl_invoke_arg inv_arg;
+	struct tee_param param[4];
+	struct tee_shm *reg_shm = NULL;
+
+	memset(&inv_arg, 0, sizeof(inv_arg));
+	memset(&param, 0, sizeof(param));
+
+	reg_shm = tee_shm_register(pvt_data.ctx, (unsigned long)key, key_len,
+				   TEE_SHM_DMA_BUF | TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm)) {
+		dev_err(pvt_data.dev, "key shm register failed\n");
+		return PTR_ERR(reg_shm);
+	}
+
+	inv_arg.func = TA_CMD_GET_RANDOM;
+	inv_arg.session = pvt_data.session_id;
+	inv_arg.num_params = 4;
+
+	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+	param[0].u.memref.shm = reg_shm;
+	param[0].u.memref.size = key_len;
+	param[0].u.memref.shm_offs = 0;
+
+	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
+	if ((ret < 0) || (inv_arg.ret != 0)) {
+		dev_err(pvt_data.dev, "TA_CMD_GET_RANDOM invoke err: %x\n",
+			inv_arg.ret);
+		ret = -EFAULT;
+	} else {
+		ret = param[0].u.memref.size;
+	}
+
+	tee_shm_free(reg_shm);
+
+	return ret;
+}
+
+static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
+{
+	if (ver->impl_id == TEE_IMPL_ID_OPTEE)
+		return 1;
+	else
+		return 0;
+}
+
+static int trusted_key_probe(struct device *dev)
+{
+	struct tee_client_device *rng_device = to_tee_client_device(dev);
+	int ret;
+	struct tee_ioctl_open_session_arg sess_arg;
+
+	memset(&sess_arg, 0, sizeof(sess_arg));
+
+	pvt_data.ctx = tee_client_open_context(NULL, optee_ctx_match, NULL,
+					       NULL);
+	if (IS_ERR(pvt_data.ctx))
+		return -ENODEV;
+
+	memcpy(sess_arg.uuid, rng_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
+	sess_arg.clnt_login = TEE_IOCTL_LOGIN_REE_KERNEL;
+	sess_arg.num_params = 0;
+
+	ret = tee_client_open_session(pvt_data.ctx, &sess_arg, NULL);
+	if ((ret < 0) || (sess_arg.ret != 0)) {
+		dev_err(dev, "tee_client_open_session failed, err: %x\n",
+			sess_arg.ret);
+		ret = -EINVAL;
+		goto out_ctx;
+	}
+	pvt_data.session_id = sess_arg.session;
+
+	ret = register_key_type(&key_type_trusted);
+	if (ret < 0)
+		goto out_sess;
+
+	pvt_data.dev = dev;
+
+	return 0;
+
+out_sess:
+	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
+out_ctx:
+	tee_client_close_context(pvt_data.ctx);
+
+	return ret;
+}
+
+static int trusted_key_remove(struct device *dev)
+{
+	unregister_key_type(&key_type_trusted);
+	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
+	tee_client_close_context(pvt_data.ctx);
+
+	return 0;
+}
+
+static const struct tee_client_device_id trusted_key_id_table[] = {
+	{UUID_INIT(0xf04a0fe7, 0x1f5d, 0x4b9b,
+		   0xab, 0xf7, 0x61, 0x9b, 0x85, 0xb4, 0xce, 0x8c)},
+	{}
+};
+MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
+
+static struct tee_client_driver trusted_key_driver = {
+	.id_table	= trusted_key_id_table,
+	.driver		= {
+		.name		= DRIVER_NAME,
+		.bus		= &tee_bus_type,
+		.probe		= trusted_key_probe,
+		.remove		= trusted_key_remove,
+	},
+};
+
+static int trusted_tee_init(void)
+{
+	return driver_register(&trusted_key_driver.driver);
+}
+
+static void trusted_tee_exit(void)
+{
+	driver_unregister(&trusted_key_driver.driver);
+}
+
+struct trusted_key_ops tee_trusted_key_ops = {
+	.migratable = 0, /* non-migratable */
+	.init = trusted_tee_init,
+	.seal = trusted_tee_seal,
+	.unseal = trusted_tee_unseal,
+	.get_random = trusted_tee_get_random,
+	.exit = trusted_tee_exit,
+};
-- 
2.7.4


^ permalink raw reply	[flat|nested] 27+ messages in thread

* [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
  2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
  2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
@ 2020-11-03 16:01 ` Sumit Garg
  2020-12-02 19:34   ` gmail Elaine Palmer
                     ` (2 more replies)
  2020-11-03 16:01 ` [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer Sumit Garg
  2020-11-05  5:07 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen
  4 siblings, 3 replies; 27+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Update documentation for Trusted and Encrypted Keys with TEE as a new
trust source. Following is brief description of updates:

- Add a section to demostrate a list of supported devices along with
  their security properties/guarantees.
- Add a key generation section.
- Updates for usage section including differences specific to a trust
  source.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++++++++++----
 1 file changed, 171 insertions(+), 32 deletions(-)

diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 1da879a..16042c8 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -6,30 +6,161 @@ Trusted and Encrypted Keys are two new key types added to the existing kernel
 key ring service.  Both of these new types are variable length symmetric keys,
 and in both cases all keys are created in the kernel, and user space sees,
 stores, and loads only encrypted blobs.  Trusted Keys require the availability
-of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
-Keys can be used on any system.  All user level blobs, are displayed and loaded
-in hex ascii for convenience, and are integrity verified.
+of a Trust Source for greater security, while Encrypted Keys can be used on any
+system. All user level blobs, are displayed and loaded in hex ascii for
+convenience, and are integrity verified.
 
-Trusted Keys use a TPM both to generate and to seal the keys.  Keys are sealed
-under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR
-(integrity measurement) values, and only unsealed by the TPM, if PCRs and blob
-integrity verifications match.  A loaded Trusted Key can be updated with new
-(future) PCR values, so keys are easily migrated to new pcr values, such as
-when the kernel and initramfs are updated.  The same key can have many saved
-blobs under different PCR values, so multiple boots are easily supported.
 
-TPM 1.2
--------
+Trust Source
+============
 
-By default, trusted keys are sealed under the SRK, which has the default
-authorization value (20 zeros).  This can be set at takeownership time with the
-trouser's utility: "tpm_takeownership -u -z".
+Trust Source provides the source of security for the Trusted Keys, on which
+basis Trusted Keys establishes a Trust model with its user. A Trust Source could
+differ from one system to another depending on its security requirements. It
+could be either an off-chip device or an on-chip device. Following section
+demostrates a list of supported devices along with their security properties/
+guarantees:
 
-TPM 2.0
--------
+  *  Root of trust for storage
 
-The user must first create a storage key and make it persistent, so the key is
-available after reboot. This can be done using the following commands.
+     (1) TPM (Trusted Platform Module: hardware device)
+
+         Rooted to Storage Root Key (SRK) which never leaves the TPM that
+         provides crypto operation to establish root of trust for storage.
+
+     (2) TEE (Trusted Execution Environment: OP-TEE based on Arm TrustZone)
+
+         Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
+         fuses and is accessible to TEE only.
+
+  *  Execution isolation
+
+     (1) TPM
+
+         Fixed set of operations running in isolated execution environment.
+
+     (2) TEE
+
+         Customizable set of operations running in isolated execution
+         environment verified via Secure/Trusted boot process.
+
+  * Optional binding to platform integrity state
+
+     (1) TPM
+
+         Keys can be optionally sealed to specified PCR (integrity measurement)
+         values, and only unsealed by the TPM, if PCRs and blob integrity
+         verifications match. A loaded Trusted Key can be updated with new
+         (future) PCR values, so keys are easily migrated to new PCR values,
+         such as when the kernel and initramfs are updated. The same key can
+         have many saved blobs under different PCR values, so multiple boots are
+         easily supported.
+
+     (2) TEE
+
+         Relies on Secure/Trusted boot process for platform integrity. It can
+         be extended with TEE based measured boot process.
+
+  *  On-chip versus off-chip
+
+     (1) TPM
+
+         Off-chip device connected via serial bus (like I2C, SPI etc.) exposing
+         physical access which represents an attack surface that can be
+         mitigated via tamper detection.
+
+     (2) TEE
+
+         On-chip functionality, immune to this attack surface.
+
+  *  Memory attacks (DRAM based like attaching a bus monitor etc.)
+
+     (1) TPM
+
+         Immune to these attacks as it doesn’t make use of system DRAM.
+
+     (2) TEE
+
+         An implementation based on TrustZone protected DRAM is susceptible to
+         such attacks. In order to mitigate these attacks one needs to rely on
+         on-chip secure RAM to store secrets or have the entire TEE
+         implementation based on on-chip secure RAM. An alternative mitigation
+         would be to use encrypted DRAM.
+
+  *  Side-channel attacks (cache, memory, CPU or time based)
+
+     (1) TPM
+
+         Immune to side-channel attacks as its resources are isolated from the
+         main OS.
+
+     (2) TEE
+
+         A careful implementation is required to mitigate against these attacks
+         for resources which are shared (eg. shared memory) with the main OS.
+         Cache and CPU based side-channel attacks can be mitigated via
+         invalidating caches and CPU registers during context switch to and from
+         the secure world.
+         To mitigate against time based attacks, one needs to have time
+         invariant implementations (like crypto algorithms etc.).
+
+  *  Resistance to physical attacks (power analysis, electromagnetic emanation,
+     probes etc.)
+
+     (1) TPM
+
+         Provides limited protection utilizing tamper resistance.
+
+     (2) TEE
+
+         Provides no protection by itself, relies on the underlying platform for
+         features such as tamper resistance.
+
+
+Key Generation
+==============
+
+Trusted Keys
+------------
+
+New keys are created from trust source generated random numbers, and are
+encrypted/decrypted using trust source storage root key.
+
+  *  TPM (hardware device) based RNG
+
+     Strength of random numbers may vary from one device manufacturer to
+     another.
+
+  *  TEE (OP-TEE based on Arm TrustZone) based RNG
+
+     RNG is customizable as per platform needs. It can either be direct output
+     from platform specific hardware RNG or a software based Fortuna CSPRNG
+     which can be seeded via multiple entropy sources.
+
+Encrypted Keys
+--------------
+
+Encrypted keys do not depend on a trust source, and are faster, as they use AES
+for encryption/decryption. New keys are created from kernel generated random
+numbers, and are encrypted/decrypted using a specified ‘master’ key. The
+‘master’ key can either be a trusted-key or user-key type. The main disadvantage
+of encrypted keys is that if they are not rooted in a trusted key, they are only
+as secure as the user key encrypting them. The master user key should therefore
+be loaded in as secure a way as possible, preferably early in boot.
+
+
+Usage
+=====
+
+Trusted Keys usage: TPM
+-----------------------
+
+TPM 1.2: By default, trusted keys are sealed under the SRK, which has the
+default authorization value (20 zeros).  This can be set at takeownership time
+with the TrouSerS utility: "tpm_takeownership -u -z".
+
+TPM 2.0: The user must first create a storage key and make it persistent, so the
+key is available after reboot. This can be done using the following commands.
 
 With the IBM TSS 2 stack::
 
@@ -78,14 +209,21 @@ TPM_STORED_DATA format.  The key length for new keys are always in bytes.
 Trusted Keys can be 32 - 128 bytes (256 - 1024 bits), the upper limit is to fit
 within the 2048 bit SRK (RSA) keylength, with all necessary structure/padding.
 
-Encrypted keys do not depend on a TPM, and are faster, as they use AES for
-encryption/decryption.  New keys are created from kernel generated random
-numbers, and are encrypted/decrypted using a specified 'master' key.  The
-'master' key can either be a trusted-key or user-key type.  The main
-disadvantage of encrypted keys is that if they are not rooted in a trusted key,
-they are only as secure as the user key encrypting them.  The master user key
-should therefore be loaded in as secure a way as possible, preferably early in
-boot.
+Trusted Keys usage: TEE
+-----------------------
+
+Usage::
+
+    keyctl add trusted name "new keylen" ring
+    keyctl add trusted name "load hex_blob" ring
+    keyctl print keyid
+
+"keyctl print" returns an ascii hex copy of the sealed key, which is in format
+specific to TEE device implementation.  The key length for new keys are always
+in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
+
+Encrypted Keys usage
+--------------------
 
 The decrypted portion of encrypted keys can contain either a simple symmetric
 key or a more complex structure. The format of the more complex structure is
@@ -103,8 +241,8 @@ Where::
 	format:= 'default | ecryptfs | enc32'
 	key-type:= 'trusted' | 'user'
 
-
 Examples of trusted and encrypted key usage:
+--------------------------------------------
 
 Create and save a trusted key named "kmk" of length 32 bytes.
 
@@ -150,7 +288,7 @@ Load a trusted key from the saved blob::
     f1f8fff03ad0acb083725535636addb08d73dedb9832da198081e5deae84bfaf0409c22b
     e4a8aea2b607ec96931e6f4d4fe563ba
 
-Reseal a trusted key under new pcr values::
+Reseal (TPM specific) a trusted key under new PCR values::
 
     $ keyctl update 268728824 "update pcrinfo=`cat pcr.blob`"
     $ keyctl print 268728824
@@ -164,11 +302,12 @@ Reseal a trusted key under new pcr values::
     7ef6a24defe4846104209bf0c3eced7fa1a672ed5b125fc9d8cd88b476a658a4434644ef
     df8ae9a178e9f83ba9f08d10fa47e4226b98b0702f06b3b8
 
+
 The initial consumer of trusted keys is EVM, which at boot time needs a high
-quality symmetric key for HMAC protection of file metadata.  The use of a
+quality symmetric key for HMAC protection of file metadata. The use of a
 trusted key provides strong guarantees that the EVM key has not been
-compromised by a user level problem, and when sealed to specific boot PCR
-values, protects against boot and offline attacks.  Create and save an
+compromised by a user level problem, and when sealed to a platform integrity
+state, protects against boot and offline attacks. Create and save an
 encrypted key "evm" using the above trusted key "kmk":
 
 option 1: omitting 'format'::
-- 
2.7.4


^ permalink raw reply	[flat|nested] 27+ messages in thread

* [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
                   ` (2 preceding siblings ...)
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
@ 2020-11-03 16:01 ` Sumit Garg
  2020-11-24  3:46   ` Jarkko Sakkinen
  2020-11-05  5:07 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen
  4 siblings, 1 reply; 27+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Add a Trusted Keys co-maintainer entry in order to support TEE based
Trusted Keys framework.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e73636b..52687bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9732,11 +9732,13 @@ KEYS-TRUSTED
 M:	James Bottomley <jejb@linux.ibm.com>
 M:	Jarkko Sakkinen <jarkko@kernel.org>
 M:	Mimi Zohar <zohar@linux.ibm.com>
+M:	Sumit Garg <sumit.garg@linaro.org>
 L:	linux-integrity@vger.kernel.org
 L:	keyrings@vger.kernel.org
 S:	Supported
 F:	Documentation/security/keys/trusted-encrypted.rst
 F:	include/keys/trusted-type.h
+F:	include/keys/trusted_tee.h
 F:	include/keys/trusted_tpm.h
 F:	security/keys/trusted-keys/
 
-- 
2.7.4


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
                   ` (3 preceding siblings ...)
  2020-11-03 16:01 ` [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer Sumit Garg
@ 2020-11-05  5:07 ` Jarkko Sakkinen
  2020-11-06  9:32   ` Sumit Garg
  4 siblings, 1 reply; 27+ messages in thread
From: Jarkko Sakkinen @ 2020-11-05  5:07 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key. Also, this is
> an alternative in case platform doesn't possess a TPM device.
> 
> This patch-set has been tested with OP-TEE based early TA which is already
> merged in upstream [1].

Is the new RPI400 computer a platform that can be used for testing
patch sets like this? I've been looking for a while something ARM64
based with similar convenience as Intel NUC's, and on the surface
this new RPI product looks great for kernel testing purposes.

/Jarkko

> 
> [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b
> 
> Changes in v8:
> 1. Added static calls support instead of indirect calls.
> 2. Documented trusted keys source module parameter.
> 3. Refined patch #1 commit message discription.
> 4. Addressed misc. comments on patch #2.
> 5. Added myself as Trusted Keys co-maintainer instead.
> 6. Rebased to latest tpmdd master.
> 
> Changes in v7:
> 1. Added a trusted.source module parameter in order to enforce user's
>    choice in case a particular platform posses both TPM and TEE.
> 2. Refine commit description for patch #1.
> 
> Changes in v6:
> 1. Revert back to dynamic detection of trust source.
> 2. Drop author mention from trusted_core.c and trusted_tpm1.c files.
> 3. Rebased to latest tpmdd/master.
> 
> Changes in v5:
> 1. Drop dynamic detection of trust source and use compile time flags
>    instead.
> 2. Rename trusted_common.c -> trusted_core.c.
> 3. Rename callback: cleanup() -> exit().
> 4. Drop "tk" acronym.
> 5. Other misc. comments.
> 6. Added review tags for patch #3 and #4.
> 
> Changes in v4:
> 1. Pushed independent TEE features separately:
>   - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062
> 2. Updated trusted-encrypted doc with TEE as a new trust source.
> 3. Rebased onto latest tpmdd/master.
> 
> Changes in v3:
> 1. Update patch #2 to support registration of multiple kernel pages.
> 2. Incoporate dependency patch #4 in this patch-set:
>    https://patchwork.kernel.org/patch/11091435/
> 
> Changes in v2:
> 1. Add reviewed-by tags for patch #1 and #2.
> 2. Incorporate comments from Jens for patch #3.
> 3. Switch to use generic trusted keys framework.
> 
> Sumit Garg (4):
>   KEYS: trusted: Add generic trusted keys framework
>   KEYS: trusted: Introduce TEE based Trusted Keys
>   doc: trusted-encrypted: updates with TEE as a new trust source
>   MAINTAINERS: Add myself as Trusted Keys co-maintainer
> 
>  Documentation/admin-guide/kernel-parameters.txt   |  12 +
>  Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++--
>  MAINTAINERS                                       |   2 +
>  include/keys/trusted-type.h                       |  47 +++
>  include/keys/trusted_tee.h                        |  55 ++++
>  include/keys/trusted_tpm.h                        |  17 +-
>  security/keys/trusted-keys/Makefile               |   2 +
>  security/keys/trusted-keys/trusted_core.c         | 354 ++++++++++++++++++++++
>  security/keys/trusted-keys/trusted_tee.c          | 278 +++++++++++++++++
>  security/keys/trusted-keys/trusted_tpm1.c         | 336 ++++----------------
>  10 files changed, 979 insertions(+), 327 deletions(-)
>  create mode 100644 include/keys/trusted_tee.h
>  create mode 100644 security/keys/trusted-keys/trusted_core.c
>  create mode 100644 security/keys/trusted-keys/trusted_tee.c
> 
> -- 
> 2.7.4
> 
> 

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-11-05  5:07 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen
@ 2020-11-06  9:32   ` Sumit Garg
  2020-11-06 14:52     ` Jarkko Sakkinen
  0 siblings, 1 reply; 27+ messages in thread
From: Sumit Garg @ 2020-11-06  9:32 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> > Add support for TEE based trusted keys where TEE provides the functionality
> > to seal and unseal trusted keys using hardware unique key. Also, this is
> > an alternative in case platform doesn't possess a TPM device.
> >
> > This patch-set has been tested with OP-TEE based early TA which is already
> > merged in upstream [1].
>
> Is the new RPI400 computer a platform that can be used for testing
> patch sets like this? I've been looking for a while something ARM64
> based with similar convenience as Intel NUC's, and on the surface
> this new RPI product looks great for kernel testing purposes.

Here [1] is the list of supported versions of Raspberry Pi in OP-TEE.
The easiest approach would be to pick up a supported version or else
do an OP-TEE port for an unsupported one (which should involve minimal
effort).

[1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work

-Sumit

>
> /Jarkko
>
> >
> > [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b
> >
> > Changes in v8:
> > 1. Added static calls support instead of indirect calls.
> > 2. Documented trusted keys source module parameter.
> > 3. Refined patch #1 commit message discription.
> > 4. Addressed misc. comments on patch #2.
> > 5. Added myself as Trusted Keys co-maintainer instead.
> > 6. Rebased to latest tpmdd master.
> >
> > Changes in v7:
> > 1. Added a trusted.source module parameter in order to enforce user's
> >    choice in case a particular platform posses both TPM and TEE.
> > 2. Refine commit description for patch #1.
> >
> > Changes in v6:
> > 1. Revert back to dynamic detection of trust source.
> > 2. Drop author mention from trusted_core.c and trusted_tpm1.c files.
> > 3. Rebased to latest tpmdd/master.
> >
> > Changes in v5:
> > 1. Drop dynamic detection of trust source and use compile time flags
> >    instead.
> > 2. Rename trusted_common.c -> trusted_core.c.
> > 3. Rename callback: cleanup() -> exit().
> > 4. Drop "tk" acronym.
> > 5. Other misc. comments.
> > 6. Added review tags for patch #3 and #4.
> >
> > Changes in v4:
> > 1. Pushed independent TEE features separately:
> >   - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062
> > 2. Updated trusted-encrypted doc with TEE as a new trust source.
> > 3. Rebased onto latest tpmdd/master.
> >
> > Changes in v3:
> > 1. Update patch #2 to support registration of multiple kernel pages.
> > 2. Incoporate dependency patch #4 in this patch-set:
> >    https://patchwork.kernel.org/patch/11091435/
> >
> > Changes in v2:
> > 1. Add reviewed-by tags for patch #1 and #2.
> > 2. Incorporate comments from Jens for patch #3.
> > 3. Switch to use generic trusted keys framework.
> >
> > Sumit Garg (4):
> >   KEYS: trusted: Add generic trusted keys framework
> >   KEYS: trusted: Introduce TEE based Trusted Keys
> >   doc: trusted-encrypted: updates with TEE as a new trust source
> >   MAINTAINERS: Add myself as Trusted Keys co-maintainer
> >
> >  Documentation/admin-guide/kernel-parameters.txt   |  12 +
> >  Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++--
> >  MAINTAINERS                                       |   2 +
> >  include/keys/trusted-type.h                       |  47 +++
> >  include/keys/trusted_tee.h                        |  55 ++++
> >  include/keys/trusted_tpm.h                        |  17 +-
> >  security/keys/trusted-keys/Makefile               |   2 +
> >  security/keys/trusted-keys/trusted_core.c         | 354 ++++++++++++++++++++++
> >  security/keys/trusted-keys/trusted_tee.c          | 278 +++++++++++++++++
> >  security/keys/trusted-keys/trusted_tpm1.c         | 336 ++++----------------
> >  10 files changed, 979 insertions(+), 327 deletions(-)
> >  create mode 100644 include/keys/trusted_tee.h
> >  create mode 100644 security/keys/trusted-keys/trusted_core.c
> >  create mode 100644 security/keys/trusted-keys/trusted_tee.c
> >
> > --
> > 2.7.4
> >
> >

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-11-06  9:32   ` Sumit Garg
@ 2020-11-06 14:52     ` Jarkko Sakkinen
  2020-12-04  5:16       ` Jarkko Sakkinen
  0 siblings, 1 reply; 27+ messages in thread
From: Jarkko Sakkinen @ 2020-11-06 14:52 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Fri, Nov 06, 2020 at 03:02:41PM +0530, Sumit Garg wrote:
> On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> > > Add support for TEE based trusted keys where TEE provides the functionality
> > > to seal and unseal trusted keys using hardware unique key. Also, this is
> > > an alternative in case platform doesn't possess a TPM device.
> > >
> > > This patch-set has been tested with OP-TEE based early TA which is already
> > > merged in upstream [1].
> >
> > Is the new RPI400 computer a platform that can be used for testing
> > patch sets like this? I've been looking for a while something ARM64
> > based with similar convenience as Intel NUC's, and on the surface
> > this new RPI product looks great for kernel testing purposes.
> 
> Here [1] is the list of supported versions of Raspberry Pi in OP-TEE.
> The easiest approach would be to pick up a supported version or else
> do an OP-TEE port for an unsupported one (which should involve minimal
> effort).
> 
> [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work
> 
> -Sumit

If porting is doable, then I'll just order RPI 400, and test with QEMU
up until either I port OP-TEE myself or someone else does it.

For seldom ARM testing, RPI 400 is really convenient device with its
boxed form factor.

/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
  2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
@ 2020-11-24  3:42   ` Jarkko Sakkinen
  0 siblings, 0 replies; 27+ messages in thread
From: Jarkko Sakkinen @ 2020-11-24  3:42 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:43PM +0530, Sumit Garg wrote:
> Current trusted keys framework is tightly coupled to use TPM device as
> an underlying implementation which makes it difficult for implementations
> like Trusted Execution Environment (TEE) etc. to provide trusted keys
> support in case platform doesn't posses a TPM device.
> 
> Add a generic trusted keys framework where underlying implementations
> can be easily plugged in. Create struct trusted_key_ops to achieve this,
> which contains necessary functions of a backend.
> 
> Also, define a module parameter in order to select a particular trust
> source in case a platform support multiple trust sources. In case its
> not specified then implementation itetrates through trust sources list
> starting with TPM and assign the first trust source as a backend which
> has initiazed successfully during iteration.
> 
> Note that current implementation only supports a single trust source at
> runtime which is either selectable at compile time or during boot via
> aforementioned module parameter.
> 
> Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  Documentation/admin-guide/kernel-parameters.txt |  12 +
>  include/keys/trusted-type.h                     |  47 ++++



>  include/keys/trusted_tpm.h                      |  17 +-
>  security/keys/trusted-keys/Makefile             |   1 +
>  security/keys/trusted-keys/trusted_core.c       | 350 ++++++++++++++++++++++++
>  security/keys/trusted-keys/trusted_tpm1.c       | 336 ++++-------------------
>  6 files changed, 468 insertions(+), 295 deletions(-)
>  create mode 100644 security/keys/trusted-keys/trusted_core.c
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 526d65d..df9b9fe 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5392,6 +5392,18 @@
>  			See Documentation/admin-guide/mm/transhuge.rst
>  			for more details.
>  
> +	trusted.source=	[KEYS]
> +			Format: <string>
> +			This parameter identifies the trust source as a backend
> +			for trusted keys implementation. Supported trust
> +			sources:
> +			- "tpm"
> +			- "tee"
> +			If not specified then it defaults to iterating through
> +			the trust source list starting with TPM and assigns the
> +			first trust source as a backend which is initialized
> +			successfully during iteration.
> +
>  	tsc=		Disable clocksource stability checks for TSC.
>  			Format: <string>
>  			[x86] reliable: mark tsc clocksource as reliable, this
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index a94c03a..a566451 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -40,6 +40,53 @@ struct trusted_key_options {
>  	uint32_t policyhandle;
>  };
>  
> +struct trusted_key_ops {
> +	/*
> +	 * flag to indicate if trusted key implementation supports migration
> +	 * or not.
> +	 */
> +	unsigned char migratable;
> +
> +	/* Initialize key interface. */
> +	int (*init)(void);
> +
> +	/* Seal a key. */
> +	int (*seal)(struct trusted_key_payload *p, char *datablob);
> +
> +	/* Unseal a key. */
> +	int (*unseal)(struct trusted_key_payload *p, char *datablob);
> +
> +	/* Get a randomized key. */
> +	int (*get_random)(unsigned char *key, size_t key_len);
> +
> +	/* Exit key interface. */
> +	void (*exit)(void);
> +};
> +
> +struct trusted_key_source {
> +	char *name;
> +	struct trusted_key_ops *ops;
> +};
> +
>  extern struct key_type key_type_trusted;
>  
> +#define TRUSTED_DEBUG 0
> +
> +#if TRUSTED_DEBUG
> +static inline void dump_payload(struct trusted_key_payload *p)
> +{
> +	pr_info("trusted_key: key_len %d\n", p->key_len);
> +	print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> +		       16, 1, p->key, p->key_len, 0);
> +	pr_info("trusted_key: bloblen %d\n", p->blob_len);
> +	print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> +		       16, 1, p->blob, p->blob_len, 0);
> +	pr_info("trusted_key: migratable %d\n", p->migratable);
> +}
> +#else
> +static inline void dump_payload(struct trusted_key_payload *p)
> +{
> +}
> +#endif
> +
>  #endif /* _KEYS_TRUSTED_TYPE_H */
> diff --git a/include/keys/trusted_tpm.h b/include/keys/trusted_tpm.h
> index a56d8e1..fb3280a 100644
> --- a/include/keys/trusted_tpm.h
> +++ b/include/keys/trusted_tpm.h
> @@ -16,6 +16,8 @@
>  #define LOAD32N(buffer, offset)	(*(uint32_t *)&buffer[offset])
>  #define LOAD16(buffer, offset)	(ntohs(*(uint16_t *)&buffer[offset]))
>  
> +extern struct trusted_key_ops tpm_trusted_key_ops;
> +
>  struct osapsess {
>  	uint32_t handle;
>  	unsigned char secret[SHA1_DIGEST_SIZE];
> @@ -60,17 +62,6 @@ static inline void dump_options(struct trusted_key_options *o)
>  		       16, 1, o->pcrinfo, o->pcrinfo_len, 0);
>  }
>  
> -static inline void dump_payload(struct trusted_key_payload *p)
> -{
> -	pr_info("trusted_key: key_len %d\n", p->key_len);
> -	print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> -		       16, 1, p->key, p->key_len, 0);
> -	pr_info("trusted_key: bloblen %d\n", p->blob_len);
> -	print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> -		       16, 1, p->blob, p->blob_len, 0);
> -	pr_info("trusted_key: migratable %d\n", p->migratable);
> -}
> -
>  static inline void dump_sess(struct osapsess *s)
>  {
>  	print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> @@ -96,10 +87,6 @@ static inline void dump_options(struct trusted_key_options *o)
>  {
>  }
>  
> -static inline void dump_payload(struct trusted_key_payload *p)
> -{
> -}
> -
>  static inline void dump_sess(struct osapsess *s)
>  {
>  }
> diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
> index 7b73ceb..49e3bcf 100644
> --- a/security/keys/trusted-keys/Makefile
> +++ b/security/keys/trusted-keys/Makefile
> @@ -4,5 +4,6 @@
>  #
>  
>  obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
> +trusted-y += trusted_core.o
>  trusted-y += trusted_tpm1.o
>  trusted-y += trusted_tpm2.o
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> new file mode 100644
> index 0000000..aa4f2a0
> --- /dev/null
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -0,0 +1,350 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2010 IBM Corporation
> + * Copyright (c) 2019-2020, Linaro Limited
> + *
> + * See Documentation/security/keys/trusted-encrypted.rst
> + */
> +
> +#include <keys/user-type.h>
> +#include <keys/trusted-type.h>
> +#include <keys/trusted_tpm.h>
> +#include <linux/capability.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/key-type.h>
> +#include <linux/module.h>
> +#include <linux/parser.h>
> +#include <linux/rcupdate.h>
> +#include <linux/slab.h>
> +#include <linux/static_call.h>
> +#include <linux/string.h>
> +#include <linux/uaccess.h>
> +
> +static char *trusted_key_source;
> +module_param_named(source, trusted_key_source, charp, 0);
> +MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
> +
> +static const struct trusted_key_source trusted_key_sources[] = {
> +#if defined(CONFIG_TCG_TPM)
> +	{ "tpm", &tpm_trusted_key_ops },
> +#endif
> +};
> +
> +DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
> +DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal);
> +DEFINE_STATIC_CALL_NULL(trusted_key_unseal,
> +			*trusted_key_sources[0].ops->unseal);
> +DEFINE_STATIC_CALL_NULL(trusted_key_get_random,
> +			*trusted_key_sources[0].ops->get_random);
> +DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit);
> +static unsigned char migratable;
> +
> +enum {
> +	Opt_err,
> +	Opt_new, Opt_load, Opt_update,
> +};
> +
> +static const match_table_t key_tokens = {
> +	{Opt_new, "new"},
> +	{Opt_load, "load"},
> +	{Opt_update, "update"},
> +	{Opt_err, NULL}
> +};
> +
> +/*
> + * datablob_parse - parse the keyctl data and fill in the
> + *                  payload structure
> + *
> + * On success returns 0, otherwise -EINVAL.
> + */
> +static int datablob_parse(char *datablob, struct trusted_key_payload *p)
> +{
> +	substring_t args[MAX_OPT_ARGS];
> +	long keylen;
> +	int ret = -EINVAL;
> +	int key_cmd;
> +	char *c;
> +
> +	/* main command */
> +	c = strsep(&datablob, " \t");
> +	if (!c)
> +		return -EINVAL;
> +	key_cmd = match_token(c, key_tokens, args);
> +	switch (key_cmd) {
> +	case Opt_new:
> +		/* first argument is key size */
> +		c = strsep(&datablob, " \t");
> +		if (!c)
> +			return -EINVAL;
> +		ret = kstrtol(c, 10, &keylen);
> +		if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
> +			return -EINVAL;
> +		p->key_len = keylen;
> +		ret = Opt_new;
> +		break;
> +	case Opt_load:
> +		/* first argument is sealed blob */
> +		c = strsep(&datablob, " \t");
> +		if (!c)
> +			return -EINVAL;
> +		p->blob_len = strlen(c) / 2;
> +		if (p->blob_len > MAX_BLOB_SIZE)
> +			return -EINVAL;
> +		ret = hex2bin(p->blob, c, p->blob_len);
> +		if (ret < 0)
> +			return -EINVAL;
> +		ret = Opt_load;
> +		break;
> +	case Opt_update:
> +		ret = Opt_update;
> +		break;
> +	case Opt_err:
> +		return -EINVAL;
> +	}
> +	return ret;
> +}
> +
> +static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
> +{
> +	struct trusted_key_payload *p = NULL;
> +	int ret;
> +
> +	ret = key_payload_reserve(key, sizeof(*p));
> +	if (ret < 0)
> +		return p;
> +	p = kzalloc(sizeof(*p), GFP_KERNEL);
> +
> +	p->migratable = migratable;
> +
> +	return p;
> +}
> +
> +/*
> + * trusted_instantiate - create a new trusted key
> + *
> + * Unseal an existing trusted blob or, for a new key, get a
> + * random key, then seal and create a trusted key-type key,
> + * adding it to the specified keyring.
> + *
> + * On success, return 0. Otherwise return errno.
> + */
> +static int trusted_instantiate(struct key *key,
> +			       struct key_preparsed_payload *prep)
> +{
> +	struct trusted_key_payload *payload = NULL;
> +	size_t datalen = prep->datalen;
> +	char *datablob;
> +	int ret = 0;
> +	int key_cmd;
> +	size_t key_len;
> +
> +	if (datalen <= 0 || datalen > 32767 || !prep->data)
> +		return -EINVAL;
> +
> +	datablob = kmalloc(datalen + 1, GFP_KERNEL);
> +	if (!datablob)
> +		return -ENOMEM;
> +	memcpy(datablob, prep->data, datalen);
> +	datablob[datalen] = '\0';
> +
> +	payload = trusted_payload_alloc(key);
> +	if (!payload) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	key_cmd = datablob_parse(datablob, payload);
> +	if (key_cmd < 0) {
> +		ret = key_cmd;
> +		goto out;
> +	}
> +
> +	dump_payload(payload);
> +
> +	switch (key_cmd) {
> +	case Opt_load:
> +		ret = static_call(trusted_key_unseal)(payload, datablob);
> +		dump_payload(payload);
> +		if (ret < 0)
> +			pr_info("trusted_key: key_unseal failed (%d)\n", ret);
> +		break;
> +	case Opt_new:
> +		key_len = payload->key_len;
> +		ret = static_call(trusted_key_get_random)(payload->key,
> +							  key_len);
> +		if (ret != key_len) {
> +			pr_info("trusted_key: key_create failed (%d)\n", ret);
> +			goto out;
> +		}
> +
> +		ret = static_call(trusted_key_seal)(payload, datablob);
> +		if (ret < 0)
> +			pr_info("trusted_key: key_seal failed (%d)\n", ret);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +out:
> +	kfree_sensitive(datablob);
> +	if (!ret)
> +		rcu_assign_keypointer(key, payload);
> +	else
> +		kfree_sensitive(payload);
> +	return ret;
> +}
> +
> +static void trusted_rcu_free(struct rcu_head *rcu)
> +{
> +	struct trusted_key_payload *p;
> +
> +	p = container_of(rcu, struct trusted_key_payload, rcu);
> +	kfree_sensitive(p);
> +}
> +
> +/*
> + * trusted_update - reseal an existing key with new PCR values
> + */
> +static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
> +{
> +	struct trusted_key_payload *p;
> +	struct trusted_key_payload *new_p;
> +	size_t datalen = prep->datalen;
> +	char *datablob;
> +	int ret = 0;
> +
> +	if (key_is_negative(key))
> +		return -ENOKEY;
> +	p = key->payload.data[0];
> +	if (!p->migratable)
> +		return -EPERM;
> +	if (datalen <= 0 || datalen > 32767 || !prep->data)
> +		return -EINVAL;
> +
> +	datablob = kmalloc(datalen + 1, GFP_KERNEL);
> +	if (!datablob)
> +		return -ENOMEM;
> +
> +	new_p = trusted_payload_alloc(key);
> +	if (!new_p) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	memcpy(datablob, prep->data, datalen);
> +	datablob[datalen] = '\0';
> +	ret = datablob_parse(datablob, new_p);
> +	if (ret != Opt_update) {
> +		ret = -EINVAL;
> +		kfree_sensitive(new_p);
> +		goto out;
> +	}
> +
> +	/* copy old key values, and reseal with new pcrs */
> +	new_p->migratable = p->migratable;
> +	new_p->key_len = p->key_len;
> +	memcpy(new_p->key, p->key, p->key_len);
> +	dump_payload(p);
> +	dump_payload(new_p);
> +
> +	ret = static_call(trusted_key_seal)(new_p, datablob);
> +	if (ret < 0) {
> +		pr_info("trusted_key: key_seal failed (%d)\n", ret);
> +		kfree_sensitive(new_p);
> +		goto out;
> +	}
> +
> +	rcu_assign_keypointer(key, new_p);
> +	call_rcu(&p->rcu, trusted_rcu_free);
> +out:
> +	kfree_sensitive(datablob);
> +	return ret;
> +}
> +
> +/*
> + * trusted_read - copy the sealed blob data to userspace in hex.
> + * On success, return to userspace the trusted key datablob size.
> + */
> +static long trusted_read(const struct key *key, char *buffer,
> +			 size_t buflen)
> +{
> +	const struct trusted_key_payload *p;
> +	char *bufp;
> +	int i;
> +
> +	p = dereference_key_locked(key);
> +	if (!p)
> +		return -EINVAL;
> +
> +	if (buffer && buflen >= 2 * p->blob_len) {
> +		bufp = buffer;
> +		for (i = 0; i < p->blob_len; i++)
> +			bufp = hex_byte_pack(bufp, p->blob[i]);
> +	}
> +	return 2 * p->blob_len;
> +}
> +
> +/*
> + * trusted_destroy - clear and free the key's payload
> + */
> +static void trusted_destroy(struct key *key)
> +{
> +	kfree_sensitive(key->payload.data[0]);
> +}
> +
> +struct key_type key_type_trusted = {
> +	.name = "trusted",
> +	.instantiate = trusted_instantiate,
> +	.update = trusted_update,
> +	.destroy = trusted_destroy,
> +	.describe = user_describe,
> +	.read = trusted_read,
> +};
> +EXPORT_SYMBOL_GPL(key_type_trusted);
> +
> +static int __init init_trusted(void)
> +{
> +	int i, ret = 0;
> +
> +	for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
> +		if (trusted_key_source &&
> +		    strncmp(trusted_key_source, trusted_key_sources[i].name,
> +			    strlen(trusted_key_sources[i].name)))
> +			continue;
> +
> +		static_call_update(trusted_key_init,
> +				   trusted_key_sources[i].ops->init);
> +		static_call_update(trusted_key_seal,
> +				   trusted_key_sources[i].ops->seal);
> +		static_call_update(trusted_key_unseal,
> +				   trusted_key_sources[i].ops->unseal);
> +		static_call_update(trusted_key_get_random,
> +				   trusted_key_sources[i].ops->get_random);
> +		static_call_update(trusted_key_exit,
> +				   trusted_key_sources[i].ops->exit);
> +		migratable = trusted_key_sources[i].ops->migratable;
> +
> +		ret = static_call(trusted_key_init)();
> +		if (!ret)
> +			break;
> +	}
> +
> +	/*
> +	 * encrypted_keys.ko depends on successful load of this module even if
> +	 * trusted key implementation is not found.
> +	 */
> +	if (ret == -ENODEV)
> +		return 0;
> +
> +	return ret;
> +}
> +
> +static void __exit cleanup_trusted(void)
> +{
> +	static_call(trusted_key_exit)();
> +}
> +
> +late_initcall(init_trusted);
> +module_exit(cleanup_trusted);
> +
> +MODULE_LICENSE("GPL");
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index b9fe02e..bd03914 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -1,29 +1,22 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (C) 2010 IBM Corporation
> - *
> - * Author:
> - * David Safford <safford@us.ibm.com>
> + * Copyright (c) 2019-2020, Linaro Limited
>   *
>   * See Documentation/security/keys/trusted-encrypted.rst
>   */
>  
>  #include <crypto/hash_info.h>
> -#include <linux/uaccess.h>
> -#include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/slab.h>
>  #include <linux/parser.h>
>  #include <linux/string.h>
>  #include <linux/err.h>
> -#include <keys/user-type.h>
>  #include <keys/trusted-type.h>
>  #include <linux/key-type.h>
> -#include <linux/rcupdate.h>
>  #include <linux/crypto.h>
>  #include <crypto/hash.h>
>  #include <crypto/sha.h>
> -#include <linux/capability.h>
>  #include <linux/tpm.h>
>  #include <linux/tpm_command.h>
>  
> @@ -703,7 +696,6 @@ static int key_unseal(struct trusted_key_payload *p,
>  
>  enum {
>  	Opt_err,
> -	Opt_new, Opt_load, Opt_update,
>  	Opt_keyhandle, Opt_keyauth, Opt_blobauth,
>  	Opt_pcrinfo, Opt_pcrlock, Opt_migratable,
>  	Opt_hash,
> @@ -712,9 +704,6 @@ enum {
>  };
>  
>  static const match_table_t key_tokens = {
> -	{Opt_new, "new"},
> -	{Opt_load, "load"},
> -	{Opt_update, "update"},
>  	{Opt_keyhandle, "keyhandle=%s"},
>  	{Opt_keyauth, "keyauth=%s"},
>  	{Opt_blobauth, "blobauth=%s"},
> @@ -841,71 +830,6 @@ static int getoptions(char *c, struct trusted_key_payload *pay,
>  	return 0;
>  }
>  
> -/*
> - * datablob_parse - parse the keyctl data and fill in the
> - * 		    payload and options structures
> - *
> - * On success returns 0, otherwise -EINVAL.
> - */
> -static int datablob_parse(char *datablob, struct trusted_key_payload *p,
> -			  struct trusted_key_options *o)
> -{
> -	substring_t args[MAX_OPT_ARGS];
> -	long keylen;
> -	int ret = -EINVAL;
> -	int key_cmd;
> -	char *c;
> -
> -	/* main command */
> -	c = strsep(&datablob, " \t");
> -	if (!c)
> -		return -EINVAL;
> -	key_cmd = match_token(c, key_tokens, args);
> -	switch (key_cmd) {
> -	case Opt_new:
> -		/* first argument is key size */
> -		c = strsep(&datablob, " \t");
> -		if (!c)
> -			return -EINVAL;
> -		ret = kstrtol(c, 10, &keylen);
> -		if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
> -			return -EINVAL;
> -		p->key_len = keylen;
> -		ret = getoptions(datablob, p, o);
> -		if (ret < 0)
> -			return ret;
> -		ret = Opt_new;
> -		break;
> -	case Opt_load:
> -		/* first argument is sealed blob */
> -		c = strsep(&datablob, " \t");
> -		if (!c)
> -			return -EINVAL;
> -		p->blob_len = strlen(c) / 2;
> -		if (p->blob_len > MAX_BLOB_SIZE)
> -			return -EINVAL;
> -		ret = hex2bin(p->blob, c, p->blob_len);
> -		if (ret < 0)
> -			return -EINVAL;
> -		ret = getoptions(datablob, p, o);
> -		if (ret < 0)
> -			return ret;
> -		ret = Opt_load;
> -		break;
> -	case Opt_update:
> -		/* all arguments are options */
> -		ret = getoptions(datablob, p, o);
> -		if (ret < 0)
> -			return ret;
> -		ret = Opt_update;
> -		break;
> -	case Opt_err:
> -		return -EINVAL;
> -		break;
> -	}
> -	return ret;
> -}
> -
>  static struct trusted_key_options *trusted_options_alloc(void)
>  {
>  	struct trusted_key_options *options;
> @@ -926,248 +850,99 @@ static struct trusted_key_options *trusted_options_alloc(void)
>  	return options;
>  }
>  
> -static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
> +static int trusted_tpm_seal(struct trusted_key_payload *p, char *datablob)
>  {
> -	struct trusted_key_payload *p = NULL;
> -	int ret;
> -
> -	ret = key_payload_reserve(key, sizeof *p);
> -	if (ret < 0)
> -		return p;
> -	p = kzalloc(sizeof *p, GFP_KERNEL);
> -	if (p)
> -		p->migratable = 1; /* migratable by default */
> -	return p;
> -}
> -
> -/*
> - * trusted_instantiate - create a new trusted key
> - *
> - * Unseal an existing trusted blob or, for a new key, get a
> - * random key, then seal and create a trusted key-type key,
> - * adding it to the specified keyring.
> - *
> - * On success, return 0. Otherwise return errno.
> - */
> -static int trusted_instantiate(struct key *key,
> -			       struct key_preparsed_payload *prep)
> -{
> -	struct trusted_key_payload *payload = NULL;
>  	struct trusted_key_options *options = NULL;
> -	size_t datalen = prep->datalen;
> -	char *datablob;
>  	int ret = 0;
> -	int key_cmd;
> -	size_t key_len;
>  	int tpm2;
>  
>  	tpm2 = tpm_is_tpm2(chip);
>  	if (tpm2 < 0)
>  		return tpm2;
>  
> -	if (datalen <= 0 || datalen > 32767 || !prep->data)
> -		return -EINVAL;
> -
> -	datablob = kmalloc(datalen + 1, GFP_KERNEL);
> -	if (!datablob)
> -		return -ENOMEM;
> -	memcpy(datablob, prep->data, datalen);
> -	datablob[datalen] = '\0';
> -
>  	options = trusted_options_alloc();
> -	if (!options) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> -	payload = trusted_payload_alloc(key);
> -	if (!payload) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> +	if (!options)
> +		return -ENOMEM;
>  
> -	key_cmd = datablob_parse(datablob, payload, options);
> -	if (key_cmd < 0) {
> -		ret = key_cmd;
> +	ret = getoptions(datablob, p, options);
> +	if (ret < 0)
>  		goto out;
> -	}
> +	dump_options(options);
>  
>  	if (!options->keyhandle) {
>  		ret = -EINVAL;
>  		goto out;
>  	}
>  
> -	dump_payload(payload);
> -	dump_options(options);
> +	if (tpm2)
> +		ret = tpm2_seal_trusted(chip, p, options);
> +	else
> +		ret = key_seal(p, options);
> +	if (ret < 0) {
> +		pr_info("tpm_trusted_key: key_seal failed (%d)\n", ret);
> +		goto out;
> +	}
>  
> -	switch (key_cmd) {
> -	case Opt_load:
> -		if (tpm2)
> -			ret = tpm2_unseal_trusted(chip, payload, options);
> -		else
> -			ret = key_unseal(payload, options);
> -		dump_payload(payload);
> -		dump_options(options);
> -		if (ret < 0)
> -			pr_info("trusted_key: key_unseal failed (%d)\n", ret);
> -		break;
> -	case Opt_new:
> -		key_len = payload->key_len;
> -		ret = tpm_get_random(chip, payload->key, key_len);
> -		if (ret != key_len) {
> -			pr_info("trusted_key: key_create failed (%d)\n", ret);
> +	if (options->pcrlock) {
> +		ret = pcrlock(options->pcrlock);
> +		if (ret < 0) {
> +			pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
>  			goto out;
>  		}
> -		if (tpm2)
> -			ret = tpm2_seal_trusted(chip, payload, options);
> -		else
> -			ret = key_seal(payload, options);
> -		if (ret < 0)
> -			pr_info("trusted_key: key_seal failed (%d)\n", ret);
> -		break;
> -	default:
> -		ret = -EINVAL;
> -		goto out;
>  	}
> -	if (!ret && options->pcrlock)
> -		ret = pcrlock(options->pcrlock);
>  out:
> -	kfree_sensitive(datablob);
>  	kfree_sensitive(options);
> -	if (!ret)
> -		rcu_assign_keypointer(key, payload);
> -	else
> -		kfree_sensitive(payload);
>  	return ret;
>  }
>  
> -static void trusted_rcu_free(struct rcu_head *rcu)
> -{
> -	struct trusted_key_payload *p;
> -
> -	p = container_of(rcu, struct trusted_key_payload, rcu);
> -	kfree_sensitive(p);
> -}
> -
> -/*
> - * trusted_update - reseal an existing key with new PCR values
> - */
> -static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
> +static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
>  {
> -	struct trusted_key_payload *p;
> -	struct trusted_key_payload *new_p;
> -	struct trusted_key_options *new_o;
> -	size_t datalen = prep->datalen;
> -	char *datablob;
> +	struct trusted_key_options *options = NULL;
>  	int ret = 0;
> +	int tpm2;
>  
> -	if (key_is_negative(key))
> -		return -ENOKEY;
> -	p = key->payload.data[0];
> -	if (!p->migratable)
> -		return -EPERM;
> -	if (datalen <= 0 || datalen > 32767 || !prep->data)
> -		return -EINVAL;
> +	tpm2 = tpm_is_tpm2(chip);
> +	if (tpm2 < 0)
> +		return tpm2;
>  
> -	datablob = kmalloc(datalen + 1, GFP_KERNEL);
> -	if (!datablob)
> +	options = trusted_options_alloc();
> +	if (!options)
>  		return -ENOMEM;
> -	new_o = trusted_options_alloc();
> -	if (!new_o) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> -	new_p = trusted_payload_alloc(key);
> -	if (!new_p) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
>  
> -	memcpy(datablob, prep->data, datalen);
> -	datablob[datalen] = '\0';
> -	ret = datablob_parse(datablob, new_p, new_o);
> -	if (ret != Opt_update) {
> -		ret = -EINVAL;
> -		kfree_sensitive(new_p);
> +	ret = getoptions(datablob, p, options);
> +	if (ret < 0)
>  		goto out;
> -	}
> +	dump_options(options);
>  
> -	if (!new_o->keyhandle) {
> +	if (!options->keyhandle) {
>  		ret = -EINVAL;
> -		kfree_sensitive(new_p);
>  		goto out;
>  	}
>  
> -	/* copy old key values, and reseal with new pcrs */
> -	new_p->migratable = p->migratable;
> -	new_p->key_len = p->key_len;
> -	memcpy(new_p->key, p->key, p->key_len);
> -	dump_payload(p);
> -	dump_payload(new_p);
> +	if (tpm2)
> +		ret = tpm2_unseal_trusted(chip, p, options);
> +	else
> +		ret = key_unseal(p, options);
> +	if (ret < 0)
> +		pr_info("tpm_trusted_key: key_unseal failed (%d)\n", ret);
>  
> -	ret = key_seal(new_p, new_o);
> -	if (ret < 0) {
> -		pr_info("trusted_key: key_seal failed (%d)\n", ret);
> -		kfree_sensitive(new_p);
> -		goto out;
> -	}
> -	if (new_o->pcrlock) {
> -		ret = pcrlock(new_o->pcrlock);
> +	if (options->pcrlock) {
> +		ret = pcrlock(options->pcrlock);
>  		if (ret < 0) {
> -			pr_info("trusted_key: pcrlock failed (%d)\n", ret);
> -			kfree_sensitive(new_p);
> +			pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
>  			goto out;
>  		}
>  	}
> -	rcu_assign_keypointer(key, new_p);
> -	call_rcu(&p->rcu, trusted_rcu_free);
>  out:
> -	kfree_sensitive(datablob);
> -	kfree_sensitive(new_o);
> +	kfree_sensitive(options);
>  	return ret;
>  }
>  
> -/*
> - * trusted_read - copy the sealed blob data to userspace in hex.
> - * On success, return to userspace the trusted key datablob size.
> - */
> -static long trusted_read(const struct key *key, char *buffer,
> -			 size_t buflen)
> -{
> -	const struct trusted_key_payload *p;
> -	char *bufp;
> -	int i;
> -
> -	p = dereference_key_locked(key);
> -	if (!p)
> -		return -EINVAL;
> -
> -	if (buffer && buflen >= 2 * p->blob_len) {
> -		bufp = buffer;
> -		for (i = 0; i < p->blob_len; i++)
> -			bufp = hex_byte_pack(bufp, p->blob[i]);
> -	}
> -	return 2 * p->blob_len;
> -}
> -
> -/*
> - * trusted_destroy - clear and free the key's payload
> - */
> -static void trusted_destroy(struct key *key)
> +static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
>  {
> -	kfree_sensitive(key->payload.data[0]);
> +	return tpm_get_random(chip, key, key_len);
>  }
>  
> -struct key_type key_type_trusted = {
> -	.name = "trusted",
> -	.instantiate = trusted_instantiate,
> -	.update = trusted_update,
> -	.destroy = trusted_destroy,
> -	.describe = user_describe,
> -	.read = trusted_read,
> -};
> -
> -EXPORT_SYMBOL_GPL(key_type_trusted);
> -
>  static void trusted_shash_release(void)
>  {
>  	if (hashalg)
> @@ -1182,14 +957,14 @@ static int __init trusted_shash_alloc(void)
>  
>  	hmacalg = crypto_alloc_shash(hmac_alg, 0, 0);
>  	if (IS_ERR(hmacalg)) {
> -		pr_info("trusted_key: could not allocate crypto %s\n",
> +		pr_info("tpm_trusted_key: could not allocate crypto %s\n",
>  			hmac_alg);
>  		return PTR_ERR(hmacalg);
>  	}
>  
>  	hashalg = crypto_alloc_shash(hash_alg, 0, 0);
>  	if (IS_ERR(hashalg)) {
> -		pr_info("trusted_key: could not allocate crypto %s\n",
> +		pr_info("tpm_trusted_key: could not allocate crypto %s\n",

Let's just add interal trusted.h file with:

#undef pr_fmt
#define pr_fmt(fmt) "trusted_key: " fmt

and remove tags from these. Does not add value to have separate tags
for backends. Makes the klog only a bit messier I think.


>  			hash_alg);
>  		ret = PTR_ERR(hashalg);
>  		goto hashalg_fail;
> @@ -1217,16 +992,13 @@ static int __init init_digests(void)
>  	return 0;
>  }
>  
> -static int __init init_trusted(void)
> +static int trusted_tpm_init(void)
>  {
>  	int ret;
>  
> -	/* encrypted_keys.ko depends on successful load of this module even if
> -	 * TPM is not used.
> -	 */
>  	chip = tpm_default_chip();
>  	if (!chip)
> -		return 0;
> +		return -ENODEV;
>  
>  	ret = init_digests();
>  	if (ret < 0)
> @@ -1247,7 +1019,7 @@ static int __init init_trusted(void)
>  	return ret;
>  }
>  
> -static void __exit cleanup_trusted(void)
> +static void trusted_tpm_exit(void)
>  {
>  	if (chip) {
>  		put_device(&chip->dev);
> @@ -1257,7 +1029,11 @@ static void __exit cleanup_trusted(void)
>  	}
>  }
>  
> -late_initcall(init_trusted);
> -module_exit(cleanup_trusted);
> -
> -MODULE_LICENSE("GPL");
> +struct trusted_key_ops tpm_trusted_key_ops = {
> +	.migratable = 1, /* migratable by default */
> +	.init = trusted_tpm_init,
> +	.seal = trusted_tpm_seal,
> +	.unseal = trusted_tpm_unseal,
> +	.get_random = trusted_tpm_get_random,
> +	.exit = trusted_tpm_exit,
> +};
> -- 
> 2.7.4
> 
> 

/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
@ 2020-11-24  3:46   ` Jarkko Sakkinen
  2021-01-11 16:35   ` Jarkko Sakkinen
  1 sibling, 0 replies; 27+ messages in thread
From: Jarkko Sakkinen @ 2020-11-24  3:46 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key.
> 
> Refer to Documentation/tee.txt for detailed information about TEE.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  include/keys/trusted_tee.h                |  55 ++++++
>  security/keys/trusted-keys/Makefile       |   1 +
>  security/keys/trusted-keys/trusted_core.c |   4 +
>  security/keys/trusted-keys/trusted_tee.c  | 278 ++++++++++++++++++++++++++++++
>  4 files changed, 338 insertions(+)
>  create mode 100644 include/keys/trusted_tee.h
>  create mode 100644 security/keys/trusted-keys/trusted_tee.c
> 
> diff --git a/include/keys/trusted_tee.h b/include/keys/trusted_tee.h
> new file mode 100644
> index 0000000..2e2bb15
> --- /dev/null
> +++ b/include/keys/trusted_tee.h
> @@ -0,0 +1,55 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019-2020 Linaro Ltd.
> + *
> + * Author:
> + * Sumit Garg <sumit.garg@linaro.org>
> + */
> +
> +#ifndef __TEE_TRUSTED_KEY_H
> +#define __TEE_TRUSTED_KEY_H
> +
> +#include <linux/tee_drv.h>
> +
> +#define DRIVER_NAME "tee-trusted-key"
> +
> +/*
> + * Get random data for symmetric key
> + *
> + * [out]     memref[0]        Random data
> + */
> +#define TA_CMD_GET_RANDOM	0x0
> +
> +/*
> + * Seal trusted key using hardware unique key
> + *
> + * [in]      memref[0]        Plain key
> + * [out]     memref[1]        Sealed key datablob
> + */
> +#define TA_CMD_SEAL		0x1
> +
> +/*
> + * Unseal trusted key using hardware unique key
> + *
> + * [in]      memref[0]        Sealed key datablob
> + * [out]     memref[1]        Plain key
> + */
> +#define TA_CMD_UNSEAL		0x2
> +
> +/**
> + * struct trusted_key_private - TEE Trusted key private data
> + * @dev:		TEE based Trusted key device.
> + * @ctx:		TEE context handler.
> + * @session_id:		Trusted key TA session identifier.
> + * @shm_pool:		Memory pool shared with TEE device.
> + */
> +struct trusted_key_private {
> +	struct device *dev;
> +	struct tee_context *ctx;
> +	u32 session_id;
> +	struct tee_shm *shm_pool;
> +};
> +
> +extern struct trusted_key_ops tee_trusted_key_ops;
> +
> +#endif
> diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
> index 49e3bcf..012dd78 100644
> --- a/security/keys/trusted-keys/Makefile
> +++ b/security/keys/trusted-keys/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
>  trusted-y += trusted_core.o
>  trusted-y += trusted_tpm1.o
>  trusted-y += trusted_tpm2.o
> +trusted-y += trusted_tee.o
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index aa4f2a0..15b1b0f3 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -8,6 +8,7 @@
>  
>  #include <keys/user-type.h>
>  #include <keys/trusted-type.h>
> +#include <keys/trusted_tee.h>
>  #include <keys/trusted_tpm.h>
>  #include <linux/capability.h>
>  #include <linux/err.h>
> @@ -29,6 +30,9 @@ static const struct trusted_key_source trusted_key_sources[] = {
>  #if defined(CONFIG_TCG_TPM)
>  	{ "tpm", &tpm_trusted_key_ops },
>  #endif
> +#if defined(CONFIG_TEE)
> +	{ "tee", &tee_trusted_key_ops },
> +#endif
>  };
>  
>  DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
> diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
> new file mode 100644
> index 0000000..da8785a
> --- /dev/null
> +++ b/security/keys/trusted-keys/trusted_tee.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019-2020 Linaro Ltd.
> + *
> + * Author:
> + * Sumit Garg <sumit.garg@linaro.org>
> + */
> +
> +#include <linux/err.h>
> +#include <linux/key-type.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/uuid.h>
> +
> +#include <keys/trusted-type.h>
> +#include <keys/trusted_tee.h>
> +
> +static struct trusted_key_private pvt_data;
> +
> +/*
> + * Have the TEE seal(encrypt) the symmetric key
> + */
> +static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob)
> +{
> +	int ret;
> +	struct tee_ioctl_invoke_arg inv_arg;
> +	struct tee_param param[4];
> +	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
> +
> +	memset(&inv_arg, 0, sizeof(inv_arg));
> +	memset(&param, 0, sizeof(param));
> +
> +	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
> +				      p->key_len, TEE_SHM_DMA_BUF |
> +				      TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_in)) {
> +		dev_err(pvt_data.dev, "key shm register failed\n");
> +		return PTR_ERR(reg_shm_in);
> +	}
> +
> +	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
> +				       sizeof(p->blob), TEE_SHM_DMA_BUF |
> +				       TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_out)) {
> +		dev_err(pvt_data.dev, "blob shm register failed\n");
> +		ret = PTR_ERR(reg_shm_out);
> +		goto out;
> +	}
> +
> +	inv_arg.func = TA_CMD_SEAL;
> +	inv_arg.session = pvt_data.session_id;
> +	inv_arg.num_params = 4;
> +
> +	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
> +	param[0].u.memref.shm = reg_shm_in;
> +	param[0].u.memref.size = p->key_len;
> +	param[0].u.memref.shm_offs = 0;
> +	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> +	param[1].u.memref.shm = reg_shm_out;
> +	param[1].u.memref.size = sizeof(p->blob);
> +	param[1].u.memref.shm_offs = 0;
> +
> +	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
> +	if ((ret < 0) || (inv_arg.ret != 0)) {
> +		dev_err(pvt_data.dev, "TA_CMD_SEAL invoke err: %x\n",
> +			inv_arg.ret);
> +		ret = -EFAULT;
> +	} else {
> +		p->blob_len = param[1].u.memref.size;
> +	}
> +
> +out:
> +	if (reg_shm_out)
> +		tee_shm_free(reg_shm_out);
> +	if (reg_shm_in)
> +		tee_shm_free(reg_shm_in);
> +
> +	return ret;
> +}
> +
> +/*
> + * Have the TEE unseal(decrypt) the symmetric key
> + */
> +static int trusted_tee_unseal(struct trusted_key_payload *p, char *datablob)
> +{
> +	int ret;
> +	struct tee_ioctl_invoke_arg inv_arg;
> +	struct tee_param param[4];
> +	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
> +
> +	memset(&inv_arg, 0, sizeof(inv_arg));
> +	memset(&param, 0, sizeof(param));
> +
> +	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
> +				      p->blob_len, TEE_SHM_DMA_BUF |
> +				      TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_in)) {
> +		dev_err(pvt_data.dev, "blob shm register failed\n");
> +		return PTR_ERR(reg_shm_in);
> +	}
> +
> +	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
> +				       sizeof(p->key), TEE_SHM_DMA_BUF |
> +				       TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_out)) {
> +		dev_err(pvt_data.dev, "key shm register failed\n");
> +		ret = PTR_ERR(reg_shm_out);
> +		goto out;
> +	}
> +
> +	inv_arg.func = TA_CMD_UNSEAL;
> +	inv_arg.session = pvt_data.session_id;
> +	inv_arg.num_params = 4;
> +
> +	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
> +	param[0].u.memref.shm = reg_shm_in;
> +	param[0].u.memref.size = p->blob_len;
> +	param[0].u.memref.shm_offs = 0;
> +	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> +	param[1].u.memref.shm = reg_shm_out;
> +	param[1].u.memref.size = sizeof(p->key);
> +	param[1].u.memref.shm_offs = 0;
> +
> +	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
> +	if ((ret < 0) || (inv_arg.ret != 0)) {
> +		dev_err(pvt_data.dev, "TA_CMD_UNSEAL invoke err: %x\n",
> +			inv_arg.ret);
> +		ret = -EFAULT;
> +	} else {
> +		p->key_len = param[1].u.memref.size;
> +	}
> +
> +out:
> +	if (reg_shm_out)
> +		tee_shm_free(reg_shm_out);
> +	if (reg_shm_in)
> +		tee_shm_free(reg_shm_in);
> +
> +	return ret;
> +}
> +
> +/*
> + * Have the TEE generate random symmetric key
> + */
> +static int trusted_tee_get_random(unsigned char *key, size_t key_len)
> +{
> +	int ret;
> +	struct tee_ioctl_invoke_arg inv_arg;
> +	struct tee_param param[4];
> +	struct tee_shm *reg_shm = NULL;
> +
> +	memset(&inv_arg, 0, sizeof(inv_arg));
> +	memset(&param, 0, sizeof(param));
> +
> +	reg_shm = tee_shm_register(pvt_data.ctx, (unsigned long)key, key_len,
> +				   TEE_SHM_DMA_BUF | TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm)) {
> +		dev_err(pvt_data.dev, "key shm register failed\n");
> +		return PTR_ERR(reg_shm);
> +	}
> +
> +	inv_arg.func = TA_CMD_GET_RANDOM;
> +	inv_arg.session = pvt_data.session_id;
> +	inv_arg.num_params = 4;
> +
> +	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> +	param[0].u.memref.shm = reg_shm;
> +	param[0].u.memref.size = key_len;
> +	param[0].u.memref.shm_offs = 0;
> +
> +	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
> +	if ((ret < 0) || (inv_arg.ret != 0)) {
> +		dev_err(pvt_data.dev, "TA_CMD_GET_RANDOM invoke err: %x\n",
> +			inv_arg.ret);
> +		ret = -EFAULT;
> +	} else {
> +		ret = param[0].u.memref.size;
> +	}
> +
> +	tee_shm_free(reg_shm);
> +
> +	return ret;
> +}
> +
> +static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> +{
> +	if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> +		return 1;
> +	else
> +		return 0;
> +}
> +
> +static int trusted_key_probe(struct device *dev)
> +{
> +	struct tee_client_device *rng_device = to_tee_client_device(dev);
> +	int ret;
> +	struct tee_ioctl_open_session_arg sess_arg;
> +
> +	memset(&sess_arg, 0, sizeof(sess_arg));
> +
> +	pvt_data.ctx = tee_client_open_context(NULL, optee_ctx_match, NULL,
> +					       NULL);
> +	if (IS_ERR(pvt_data.ctx))
> +		return -ENODEV;
> +
> +	memcpy(sess_arg.uuid, rng_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
> +	sess_arg.clnt_login = TEE_IOCTL_LOGIN_REE_KERNEL;
> +	sess_arg.num_params = 0;
> +
> +	ret = tee_client_open_session(pvt_data.ctx, &sess_arg, NULL);
> +	if ((ret < 0) || (sess_arg.ret != 0)) {
> +		dev_err(dev, "tee_client_open_session failed, err: %x\n",
> +			sess_arg.ret);
> +		ret = -EINVAL;
> +		goto out_ctx;
> +	}
> +	pvt_data.session_id = sess_arg.session;
> +
> +	ret = register_key_type(&key_type_trusted);
> +	if (ret < 0)
> +		goto out_sess;
> +
> +	pvt_data.dev = dev;
> +
> +	return 0;
> +
> +out_sess:
> +	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
> +out_ctx:
> +	tee_client_close_context(pvt_data.ctx);
> +
> +	return ret;
> +}
> +
> +static int trusted_key_remove(struct device *dev)
> +{
> +	unregister_key_type(&key_type_trusted);
> +	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
> +	tee_client_close_context(pvt_data.ctx);
> +
> +	return 0;
> +}
> +
> +static const struct tee_client_device_id trusted_key_id_table[] = {
> +	{UUID_INIT(0xf04a0fe7, 0x1f5d, 0x4b9b,
> +		   0xab, 0xf7, 0x61, 0x9b, 0x85, 0xb4, 0xce, 0x8c)},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
> +
> +static struct tee_client_driver trusted_key_driver = {
> +	.id_table	= trusted_key_id_table,
> +	.driver		= {
> +		.name		= DRIVER_NAME,
> +		.bus		= &tee_bus_type,
> +		.probe		= trusted_key_probe,
> +		.remove		= trusted_key_remove,
> +	},
> +};
> +
> +static int trusted_tee_init(void)
> +{
> +	return driver_register(&trusted_key_driver.driver);
> +}
> +
> +static void trusted_tee_exit(void)
> +{
> +	driver_unregister(&trusted_key_driver.driver);
> +}
> +
> +struct trusted_key_ops tee_trusted_key_ops = {


Nit: trusted_key_tee_ops

> +	.migratable = 0, /* non-migratable */
> +	.init = trusted_tee_init,
> +	.seal = trusted_tee_seal,
> +	.unseal = trusted_tee_unseal,
> +	.get_random = trusted_tee_get_random,
> +	.exit = trusted_tee_exit,
> +};
> -- 
> 2.7.4
> 
> 
/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer
  2020-11-03 16:01 ` [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer Sumit Garg
@ 2020-11-24  3:46   ` Jarkko Sakkinen
  0 siblings, 0 replies; 27+ messages in thread
From: Jarkko Sakkinen @ 2020-11-24  3:46 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:46PM +0530, Sumit Garg wrote:
> Add a Trusted Keys co-maintainer entry in order to support TEE based
> Trusted Keys framework.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>

Acked-by: Jarkko Sakkinen <jarkko@kernel.org>

> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e73636b..52687bb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9732,11 +9732,13 @@ KEYS-TRUSTED
>  M:	James Bottomley <jejb@linux.ibm.com>
>  M:	Jarkko Sakkinen <jarkko@kernel.org>
>  M:	Mimi Zohar <zohar@linux.ibm.com>
> +M:	Sumit Garg <sumit.garg@linaro.org>
>  L:	linux-integrity@vger.kernel.org
>  L:	keyrings@vger.kernel.org
>  S:	Supported
>  F:	Documentation/security/keys/trusted-encrypted.rst
>  F:	include/keys/trusted-type.h
> +F:	include/keys/trusted_tee.h
>  F:	include/keys/trusted_tpm.h
>  F:	security/keys/trusted-keys/
>  
> -- 
> 2.7.4
> 
> 

/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
@ 2020-12-02 19:34   ` gmail Elaine Palmer
  2020-12-04 15:30     ` Jarkko Sakkinen
  2020-12-06 18:51   ` Randy Dunlap
  2020-12-08 15:55   ` Mimi Zohar
  2 siblings, 1 reply; 27+ messages in thread
From: gmail Elaine Palmer @ 2020-12-02 19:34 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee, Kenneth Goldman, gcwilson, zgu, stefanb, NAYNA JAIN1


Hi Sumit,  

Thank you for the detailed descriptions and examples of trust sources for Trusted Keys.   A group of us in IBM (Stefan Berger, Ken Goldman, Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar) have been doing related work for quite some time, and we have one primary concern and some suggested changes to the document. 

Our primary concern is that describing a TEE as a Trust Source needs to be more specific.   For example, "ARM TrustZone" is not sufficient, but "wolfSSL embedded SSL/TLS library with ARM TrustZone CryptoCell-310" is.  Just because a key is protected by software running in a TEE is not enough to establish trust.  Just like cryptographic modules, a Trust Source should be defined as a specific implementation on specific hardware with well-documented environmental assumptions, dependencies, and threats.

In addition to the above concern, our suggested changes are inline below.

> Begin forwarded message:
> 
> From: Sumit Garg <sumit.garg@linaro.org>
> Subject: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
> Date: November 3, 2020 at 11:01:45 AM EST
> To: jarkko.sakkinen@linux.intel.com, zohar@linux.ibm.com, jejb@linux.ibm.com
> Cc: dhowells@redhat.com, jens.wiklander@linaro.org, corbet@lwn.net, jmorris@namei.org, serge@hallyn.com, casey@schaufler-ca.com, janne.karhunen@gmail.com, daniel.thompson@linaro.org, Markus.Wamser@mixed-mode.de, lhinds@redhat.com, keyrings@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, op-tee@lists.trustedfirmware.org, Sumit Garg <sumit.garg@linaro.org>
> 
> Update documentation for Trusted and Encrypted Keys with TEE as a new
> trust source. Following is brief description of updates:
> 
> - Add a section to demostrate a list of supported devices along with
> their security properties/guarantees.
> - Add a key generation section.
> - Updates for usage section including differences specific to a trust
> source.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
> Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++++++++++----
> 1 file changed, 171 insertions(+), 32 deletions(-)
> 
> diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
> index 1da879a..16042c8 100644
> --- a/Documentation/security/keys/trusted-encrypted.rst
> +++ b/Documentation/security/keys/trusted-encrypted.rst
> @@ -6,30 +6,161 @@ Trusted and Encrypted Keys are two new key types added to the existing kernel
> key ring service.  Both of these new types are variable length symmetric keys,
> and in both cases all keys are created in the kernel, and user space sees,
> stores, and loads only encrypted blobs.  Trusted Keys require the availability
> -of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
> -Keys can be used on any system.  All user level blobs, are displayed and loaded
> -in hex ascii for convenience, and are integrity verified.
> +of a Trust Source for greater security, while Encrypted Keys can be used on any
> +system. All user level blobs, are displayed and loaded in hex ascii for
> +convenience, and are integrity verified.
> 
> -Trusted Keys use a TPM both to generate and to seal the keys.  Keys are sealed
> -under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR
> -(integrity measurement) values, and only unsealed by the TPM, if PCRs and blob
> -integrity verifications match.  A loaded Trusted Key can be updated with new
> -(future) PCR values, so keys are easily migrated to new pcr values, such as
> -when the kernel and initramfs are updated.  The same key can have many saved
> -blobs under different PCR values, so multiple boots are easily supported.
> 
> -TPM 1.2
> --------
> +Trust Source
> +============
> 
> -By default, trusted keys are sealed under the SRK, which has the default
> -authorization value (20 zeros).  This can be set at takeownership time with the
> -trouser's utility: "tpm_takeownership -u -z".
> +Trust Source provides the source of security for the Trusted Keys, on which
> +basis Trusted Keys establishes a Trust model with its user. A Trust Source could
> +differ from one system to another depending on its security requirements. It
> +could be either an off-chip device or an on-chip device. Following section
> +demostrates a list of supported devices along with their security properties/
> +guarantees:
Please change the following 
"Trust Source provides the source of security for the Trusted Keys, on which basis Trusted Keys establishes a Trust model with its user." 
to 
"A trust source provides the source of security for the Trusted Keys.  Whether or not a trust source is sufficiently safe depends on the strength and correctness of its implementation, as well as the threat environment for a specific use case.  Since the kernel doesn't know what the environment is, and there is no metric of trust, it is dependent on the consumer of the Trusted Keys to determine if the trust source is sufficiently safe."
> 
> -TPM 2.0
> --------
> +  *  Root of trust for storage
> 
> -The user must first create a storage key and make it persistent, so the key is
> -available after reboot. This can be done using the following commands.
> +     (1) TPM (Trusted Platform Module: hardware device)
> +
> +         Rooted to Storage Root Key (SRK) which never leaves the TPM that
> +         provides crypto operation to establish root of trust for storage.
> +
> +     (2) TEE (Trusted Execution Environment: OP-TEE based on Arm TrustZone)
> +
> +         Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
> +         fuses and is accessible to TEE only.
> +
> +  *  Execution isolation
> +
> +     (1) TPM
> +
> +         Fixed set of operations running in isolated execution environment.
> +
> +     (2) TEE
> +
> +         Customizable set of operations running in isolated execution
> +         environment verified via Secure/Trusted boot process.
> +
> +  * Optional binding to platform integrity state
> +
> +     (1) TPM
> +
> +         Keys can be optionally sealed to specified PCR (integrity measurement)
> +         values, and only unsealed by the TPM, if PCRs and blob integrity
> +         verifications match. A loaded Trusted Key can be updated with new
> +         (future) PCR values, so keys are easily migrated to new PCR values,
> +         such as when the kernel and initramfs are updated. The same key can
> +         have many saved blobs under different PCR values, so multiple boots are
> +         easily supported.
> +
> +     (2) TEE
> +
> +         Relies on Secure/Trusted boot process for platform integrity. It can
> +         be extended with TEE based measured boot process.
> +
> +  *  On-chip versus off-chip
> +
> +     (1) TPM
> +
> +         Off-chip device connected via serial bus (like I2C, SPI etc.) exposing
> +         physical access which represents an attack surface that can be
> +         mitigated via tamper detection.
> +
> +     (2) TEE
> +
> +         On-chip functionality, immune to this attack surface.
> +
> +  *  Memory attacks (DRAM based like attaching a bus monitor etc.)
> +
> +     (1) TPM
> +
> +         Immune to these attacks as it doesn’t make use of system DRAM.
> +
> +     (2) TEE
> +
> +         An implementation based on TrustZone protected DRAM is susceptible to
> +         such attacks. In order to mitigate these attacks one needs to rely on
> +         on-chip secure RAM to store secrets or have the entire TEE
> +         implementation based on on-chip secure RAM. An alternative mitigation
> +         would be to use encrypted DRAM.
> +
> +  *  Side-channel attacks (cache, memory, CPU or time based)
> +
> +     (1) TPM
> +
> +         Immune to side-channel attacks as its resources are isolated from the
> +         main OS.
> +
> +     (2) TEE
> +
> +         A careful implementation is required to mitigate against these attacks
> +         for resources which are shared (eg. shared memory) with the main OS.
> +         Cache and CPU based side-channel attacks can be mitigated via
> +         invalidating caches and CPU registers during context switch to and from
> +         the secure world.
> +         To mitigate against time based attacks, one needs to have time
> +         invariant implementations (like crypto algorithms etc.).
> +
> +  *  Resistance to physical attacks (power analysis, electromagnetic emanation,
> +     probes etc.)
> +
> +     (1) TPM
> +
> +         Provides limited protection utilizing tamper resistance.
> +
> +     (2) TEE
> +
> +         Provides no protection by itself, relies on the underlying platform for
> +         features such as tamper resistance.
> +
> +
please add the following:

* Provisioning - the trust source's unique and verifiable cryptographic identity is provisioned during manufacturing

(1) TPM
The unique and verifiable cryptographic identity is the endorsement key (EK) or its primary seed.  A review of the generation of the EK and its accompanying certificate is part of the Common Criteria evaluation of the product's lifecycle processes (ALC_*).  See "TCG Protection Profile for PC Client Specific TPM 2" (https://trustedcomputinggroup.org/resource/pc-client-protection-profile-for-tpm-2-0/).

(2) TEE
A protection profile for TEEs does not yet exist.  Therefore, the provisioning process that generates the Hardware Unique Key is not evaluated by an independent third party and is highly dependent on the manufacturing environment.  


* Cryptography
(1) TPM
As part of the TPM's mandatory Common Criteria evaluation, the correctness of the TPM's implementation of cryptographic algorithms, the protection of keys, and the generation of random numbers, and other security-relevant functions must be documented, reviewed, and tested by an independent third party evaluation agency.  It must meet the requirements of FIPS 140-2, FIPS 140-3, or ISO/IEC 19790:2012. 

(2) TEE
Evaluations of cryptographic modules within TEEs are not required, but some are available for specific implementations within TEEs.



* Interfaces and APIs
(1) TPMs have well-documented, standardized interfaces and APIs.
(2) Unless they implement functionality such as a virtual TPM, TEEs have custom interfaces and APIs. 



* Threat model
The strength and appropriateness of  TPMs and TEEs for a given purpose must be assessed when using them to protect security-relevant data.    

We suggest documenting environmental assumptions and dependencies in a high-level threat model for each additional trust source.  Just as each new LSM needs to comply with Documentation/security/lsm-development.rst, each new Trusted Key source should provide a high-level threat model.   An example of a high-level threat model is "Common Security Threats v1.0” (https://www.opencompute.org/documents/common-security-threats-notes-1-pdf ). 

The original Trusted Keys implementation assumed discrete physical TPMs for key protection.  However, even physical TPMs themselves vary based on the manufacturer and systems in which they are placed.  The embedded chipset, firmware load, algorithms, packaging, pins, and countermeasures vary.  (Threats and mitigations on physical TPMs are well documented, e.g., "Threat Model of a Scenario Based on Trusted Platform Module 2.0 Specification” (http://ceur-ws.org/Vol-1011/6.pdf).

Specific to Trusted Keys and TPMs, there is some discussion of threats and mitigations in the Integrity_overview.pdf on the IMA wiki:

	• The trusted key component does two things to help with secure key management on Linux. First, it provides a kernel key ring service in which the symmetric encryption keys are never visible in plain text to userspace. The keys are created in the kernel, and sealed by a hardware device such as a TPM, with userspace seeing only the sealed blobs. Malicious or compromised applications cannot steal a trusted key, since only the kernel can see the unsealed blobs. Secondly, the trusted keys can tie key unsealing to the integrity measurements, so that keys cannot be stolen in an offline attack, such as by booting an unlocked Linux image from CD or USB.  As the measurements will be different, the TPM chip will refuse to unseal the keys, even for the kernel.

Consumers of Trusted Keys in different environments need enough information so that they can create their own threat models tailored to their use cases.  For the present submission, a high-level security model of ARM TrustZone and how Trusted Keys key protection is implemented along with an enumeration of security considerations for end-use threat models would be appropriate.  

An excellent and related paper describes the strengths, weaknesses, and countermeasures of a firmware TPM implemented within a TEE.  See "fTPM: A Software-only Implementation of a TPM Chip” (https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/raj)


> +Key Generation
> +==============
> +
> +Trusted Keys
> +------------
> +
> +New keys are created from trust source generated random numbers, and are
> +encrypted/decrypted using trust source storage root key.
Please change the following
"New keys are created from trust source generated random numbers, and are encrypted/decrypted using trust source storage root key."
to
"New keys are created from random numbers generated in the trust source. They are encrypted/decrypted using a child key in the storage key hierarchy.  Encryption and decryption of the child key must be protected by a strong access control policy within the trust source. “

Thank you. 
Elaine
_____________________________________
Elaine R. Palmer, Senior Technical Staff Member
Secure Systems and Academy of Technology
IBM T.J. Watson Research Center

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-11-06 14:52     ` Jarkko Sakkinen
@ 2020-12-04  5:16       ` Jarkko Sakkinen
  2020-12-08 11:51         ` Sumit Garg
  0 siblings, 1 reply; 27+ messages in thread
From: Jarkko Sakkinen @ 2020-12-04  5:16 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Fri, Nov 06, 2020 at 04:52:52PM +0200, Jarkko Sakkinen wrote:
> On Fri, Nov 06, 2020 at 03:02:41PM +0530, Sumit Garg wrote:
> > On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > to seal and unseal trusted keys using hardware unique key. Also, this is
> > > > an alternative in case platform doesn't possess a TPM device.
> > > >
> > > > This patch-set has been tested with OP-TEE based early TA which is already
> > > > merged in upstream [1].
> > >
> > > Is the new RPI400 computer a platform that can be used for testing
> > > patch sets like this? I've been looking for a while something ARM64
> > > based with similar convenience as Intel NUC's, and on the surface
> > > this new RPI product looks great for kernel testing purposes.
> > 
> > Here [1] is the list of supported versions of Raspberry Pi in OP-TEE.
> > The easiest approach would be to pick up a supported version or else
> > do an OP-TEE port for an unsupported one (which should involve minimal
> > effort).
> > 
> > [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work
> > 
> > -Sumit
> 
> If porting is doable, then I'll just order RPI 400, and test with QEMU
> up until either I port OP-TEE myself or someone else does it.
> 
> For seldom ARM testing, RPI 400 is really convenient device with its
> boxed form factor.

I'm now a proud owner of Raspberry Pi 400 home computer :-)

I also found instructions on how to boot a custom OS from a USB stick:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

Also, my favorite build system BuildRoot has bunch of of the shelf
configs:

➜  buildroot-sgx (master) ✔ ls -1 configs | grep raspberry
raspberrypi0_defconfig
raspberrypi0w_defconfig
raspberrypi2_defconfig
raspberrypi3_64_defconfig
raspberrypi3_defconfig
raspberrypi3_qt5we_defconfig
raspberrypi4_64_defconfig
raspberrypi4_defconfig
raspberrypi_defconfig

I.e. I'm capable of compiling kernel and user space and boot it up
with it.

Further, I can select this compilation option:

BR2_TARGET_OPTEE_OS:                                                                                                                                              │  
                                                                                                                                                                     │  
   OP-TEE OS provides the secure world boot image and the trust                                                                                                      │  
   application development kit of the OP-TEE project. OP-TEE OS                                                                                                      │  
   also provides generic trusted application one can embedded                                                                                                        │  
   into its system.                                                                                                                                                  │  
                                                                                                                                                                     │  
   http://github.com/OP-TEE/optee_os       

Is that what I want? If I put this all together and apply your patches,
should the expectation be that I can use trusted keys?

Please note that I had a few remarks about your patches (minor but need
to be fixed), but this version is already solid enough for testing.

/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-02 19:34   ` gmail Elaine Palmer
@ 2020-12-04 15:30     ` Jarkko Sakkinen
  2020-12-08 15:02       ` Mimi Zohar
  0 siblings, 1 reply; 27+ messages in thread
From: Jarkko Sakkinen @ 2020-12-04 15:30 UTC (permalink / raw)
  To: gmail Elaine Palmer
  Cc: Sumit Garg, jarkko.sakkinen, zohar, jejb, dhowells,
	jens.wiklander, corbet, jmorris, serge, casey, janne.karhunen,
	daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Kenneth Goldman, gcwilson, zgu,
	stefanb, NAYNA JAIN1

On Wed, Dec 02, 2020 at 02:34:07PM -0500, gmail Elaine Palmer wrote:
> Hi Sumit,  
> 
> Thank you for the detailed descriptions and examples of trust sources
> for Trusted Keys.   A group of us in IBM (Stefan Berger, Ken Goldman,
> Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar)
> have been doing related work for quite some time, and we have one
> primary concern and some suggested changes to the document. 
> 
> Our primary concern is that describing a TEE as a Trust Source needs
> to be more specific.   For example, "ARM TrustZone" is not sufficient,
> but "wolfSSL embedded SSL/TLS library with ARM TrustZone
> CryptoCell-310" is.  Just because a key is protected by software
> running in a TEE is not enough to establish trust.  Just like
> cryptographic modules, a Trust Source should be defined as a specific
> implementation on specific hardware with well-documented environmental
> assumptions, dependencies, and threats.
> 
> In addition to the above concern, our suggested changes are inline
> below.

In order to give a decent review comment it should have two ingredients:

- Where the existing line of code / text / whatever goes wrong.
- How it should modified and why that makes sense. And use as plain
  English and non-academic terms as possible, if it is documentation.
  Further, scope is only the kernel implementation, no more or no
  less.

"do this" is not unfortunately an argument. Feedback is welcome when
it is supported by something common sensse.

Some meta suggestion of related to email:

Please also use a proper email client and split your paragraphs into
at most 80 character lines with new line characters when writing email.
I prefer to use 72 character line length so that there's some space
for longer email threads.

/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
  2020-12-02 19:34   ` gmail Elaine Palmer
@ 2020-12-06 18:51   ` Randy Dunlap
  2020-12-08 15:55   ` Mimi Zohar
  2 siblings, 0 replies; 27+ messages in thread
From: Randy Dunlap @ 2020-12-06 18:51 UTC (permalink / raw)
  To: Sumit Garg, jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee

Hi--

Please see doc. comments below.


On 11/3/20 8:01 AM, Sumit Garg wrote:
> Update documentation for Trusted and Encrypted Keys with TEE as a new
> trust source. Following is brief description of updates:
> 
> - Add a section to demostrate a list of supported devices along with

                     demonstrate

>   their security properties/guarantees.
> - Add a key generation section.
> - Updates for usage section including differences specific to a trust
>   source.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++++++++++----
>  1 file changed, 171 insertions(+), 32 deletions(-)
> 
> diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
> index 1da879a..16042c8 100644
> --- a/Documentation/security/keys/trusted-encrypted.rst
> +++ b/Documentation/security/keys/trusted-encrypted.rst
> @@ -6,30 +6,161 @@ Trusted and Encrypted Keys are two new key types added to the existing kernel
>  key ring service.  Both of these new types are variable length symmetric keys,
>  and in both cases all keys are created in the kernel, and user space sees,
>  stores, and loads only encrypted blobs.  Trusted Keys require the availability
> -of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
> -Keys can be used on any system.  All user level blobs, are displayed and loaded
> -in hex ascii for convenience, and are integrity verified.
> +of a Trust Source for greater security, while Encrypted Keys can be used on any
> +system. All user level blobs, are displayed and loaded in hex ascii for

s/ascii/ASCII/ please. Yes, I know that it was already there in lower case.

> +convenience, and are integrity verified.
>  
> -Trusted Keys use a TPM both to generate and to seal the keys.  Keys are sealed
> -under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR
> -(integrity measurement) values, and only unsealed by the TPM, if PCRs and blob
> -integrity verifications match.  A loaded Trusted Key can be updated with new
> -(future) PCR values, so keys are easily migrated to new pcr values, such as
> -when the kernel and initramfs are updated.  The same key can have many saved
> -blobs under different PCR values, so multiple boots are easily supported.
>  
> -TPM 1.2
> --------
> +Trust Source
> +============
>  
> -By default, trusted keys are sealed under the SRK, which has the default
> -authorization value (20 zeros).  This can be set at takeownership time with the
> -trouser's utility: "tpm_takeownership -u -z".
> +Trust Source provides the source of security for the Trusted Keys, on which
> +basis Trusted Keys establishes a Trust model with its user. A Trust Source could
> +differ from one system to another depending on its security requirements. It
> +could be either an off-chip device or an on-chip device. Following section
> +demostrates a list of supported devices along with their security properties/

   demonstrates

> +guarantees:
>  
> -TPM 2.0
> --------
> +  *  Root of trust for storage
>  
> -The user must first create a storage key and make it persistent, so the key is
> -available after reboot. This can be done using the following commands.
> +     (1) TPM (Trusted Platform Module: hardware device)
> +
> +         Rooted to Storage Root Key (SRK) which never leaves the TPM that
> +         provides crypto operation to establish root of trust for storage.
> +
> +     (2) TEE (Trusted Execution Environment: OP-TEE based on Arm TrustZone)
> +
> +         Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
> +         fuses and is accessible to TEE only.
> +
> +  *  Execution isolation
> +
> +     (1) TPM
> +
> +         Fixed set of operations running in isolated execution environment.
> +
> +     (2) TEE
> +
> +         Customizable set of operations running in isolated execution
> +         environment verified via Secure/Trusted boot process.
> +
> +  * Optional binding to platform integrity state
> +
> +     (1) TPM
> +
> +         Keys can be optionally sealed to specified PCR (integrity measurement)
> +         values, and only unsealed by the TPM, if PCRs and blob integrity
> +         verifications match. A loaded Trusted Key can be updated with new
> +         (future) PCR values, so keys are easily migrated to new PCR values,
> +         such as when the kernel and initramfs are updated. The same key can
> +         have many saved blobs under different PCR values, so multiple boots are
> +         easily supported.
> +
> +     (2) TEE
> +
> +         Relies on Secure/Trusted boot process for platform integrity. It can
> +         be extended with TEE based measured boot process.
> +
> +  *  On-chip versus off-chip
> +
> +     (1) TPM
> +
> +         Off-chip device connected via serial bus (like I2C, SPI etc.) exposing
> +         physical access which represents an attack surface that can be
> +         mitigated via tamper detection.
> +
> +     (2) TEE
> +
> +         On-chip functionality, immune to this attack surface.
> +
> +  *  Memory attacks (DRAM based like attaching a bus monitor etc.)

                        DRAM-based

> +
> +     (1) TPM
> +
> +         Immune to these attacks as it doesn’t make use of system DRAM.
> +
> +     (2) TEE
> +
> +         An implementation based on TrustZone protected DRAM is susceptible to
> +         such attacks. In order to mitigate these attacks one needs to rely on
> +         on-chip secure RAM to store secrets or have the entire TEE
> +         implementation based on on-chip secure RAM. An alternative mitigation
> +         would be to use encrypted DRAM.
> +
> +  *  Side-channel attacks (cache, memory, CPU or time based)
> +
> +     (1) TPM
> +
> +         Immune to side-channel attacks as its resources are isolated from the
> +         main OS.
> +
> +     (2) TEE
> +
> +         A careful implementation is required to mitigate against these attacks
> +         for resources which are shared (eg. shared memory) with the main OS.

	                                    e.g.

> +         Cache and CPU based side-channel attacks can be mitigated via
> +         invalidating caches and CPU registers during context switch to and from
> +         the secure world.
> +         To mitigate against time based attacks, one needs to have time
> +         invariant implementations (like crypto algorithms etc.).
> +
> +  *  Resistance to physical attacks (power analysis, electromagnetic emanation,
> +     probes etc.)
> +
> +     (1) TPM
> +
> +         Provides limited protection utilizing tamper resistance.
> +
> +     (2) TEE
> +
> +         Provides no protection by itself, relies on the underlying platform for
> +         features such as tamper resistance.
> +
> +
> +Key Generation
> +==============
> +
> +Trusted Keys
> +------------
> +
> +New keys are created from trust source generated random numbers, and are
> +encrypted/decrypted using trust source storage root key.
> +
> +  *  TPM (hardware device) based RNG
> +
> +     Strength of random numbers may vary from one device manufacturer to
> +     another.
> +
> +  *  TEE (OP-TEE based on Arm TrustZone) based RNG
> +
> +     RNG is customizable as per platform needs. It can either be direct output
> +     from platform specific hardware RNG or a software based Fortuna CSPRNG
> +     which can be seeded via multiple entropy sources.
> +
> +Encrypted Keys
> +--------------
> +
> +Encrypted keys do not depend on a trust source, and are faster, as they use AES
> +for encryption/decryption. New keys are created from kernel generated random

                                                        kernel-generated

> +numbers, and are encrypted/decrypted using a specified ‘master’ key. The
> +‘master’ key can either be a trusted-key or user-key type. The main disadvantage
> +of encrypted keys is that if they are not rooted in a trusted key, they are only
> +as secure as the user key encrypting them. The master user key should therefore
> +be loaded in as secure a way as possible, preferably early in boot.
> +
> +
> +Usage
> +=====
> +
> +Trusted Keys usage: TPM
> +-----------------------
> +
> +TPM 1.2: By default, trusted keys are sealed under the SRK, which has the
> +default authorization value (20 zeros).  This can be set at takeownership time

Does "20 zeros" mean 20 bytes of 0s or 20 bits of 0s or something else?

> +with the TrouSerS utility: "tpm_takeownership -u -z".
> +
> +TPM 2.0: The user must first create a storage key and make it persistent, so the
> +key is available after reboot. This can be done using the following commands.
>  
>  With the IBM TSS 2 stack::
>  
> @@ -78,14 +209,21 @@ TPM_STORED_DATA format.  The key length for new keys are always in bytes.
>  Trusted Keys can be 32 - 128 bytes (256 - 1024 bits), the upper limit is to fit
>  within the 2048 bit SRK (RSA) keylength, with all necessary structure/padding.
>  
> -Encrypted keys do not depend on a TPM, and are faster, as they use AES for
> -encryption/decryption.  New keys are created from kernel generated random
> -numbers, and are encrypted/decrypted using a specified 'master' key.  The
> -'master' key can either be a trusted-key or user-key type.  The main
> -disadvantage of encrypted keys is that if they are not rooted in a trusted key,
> -they are only as secure as the user key encrypting them.  The master user key
> -should therefore be loaded in as secure a way as possible, preferably early in
> -boot.
> +Trusted Keys usage: TEE
> +-----------------------
> +
> +Usage::
> +
> +    keyctl add trusted name "new keylen" ring
> +    keyctl add trusted name "load hex_blob" ring
> +    keyctl print keyid
> +
> +"keyctl print" returns an ascii hex copy of the sealed key, which is in format

                             ASCII

> +specific to TEE device implementation.  The key length for new keys are always

                                                                       is always

> +in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
> +
> +Encrypted Keys usage
> +--------------------
>  
>  The decrypted portion of encrypted keys can contain either a simple symmetric
>  key or a more complex structure. The format of the more complex structure is
> @@ -103,8 +241,8 @@ Where::
>  	format:= 'default | ecryptfs | enc32'
>  	key-type:= 'trusted' | 'user'
>  
> -
>  Examples of trusted and encrypted key usage:
> +--------------------------------------------

No colon at end of heading, please.

>  
>  Create and save a trusted key named "kmk" of length 32 bytes.
>  
> @@ -150,7 +288,7 @@ Load a trusted key from the saved blob::
>      f1f8fff03ad0acb083725535636addb08d73dedb9832da198081e5deae84bfaf0409c22b
>      e4a8aea2b607ec96931e6f4d4fe563ba
>  
> -Reseal a trusted key under new pcr values::
> +Reseal (TPM specific) a trusted key under new PCR values::
>  
>      $ keyctl update 268728824 "update pcrinfo=`cat pcr.blob`"
>      $ keyctl print 268728824
> @@ -164,11 +302,12 @@ Reseal a trusted key under new pcr values::
>      7ef6a24defe4846104209bf0c3eced7fa1a672ed5b125fc9d8cd88b476a658a4434644ef
>      df8ae9a178e9f83ba9f08d10fa47e4226b98b0702f06b3b8
>  
> +
>  The initial consumer of trusted keys is EVM, which at boot time needs a high
> -quality symmetric key for HMAC protection of file metadata.  The use of a
> +quality symmetric key for HMAC protection of file metadata. The use of a
>  trusted key provides strong guarantees that the EVM key has not been
> -compromised by a user level problem, and when sealed to specific boot PCR
> -values, protects against boot and offline attacks.  Create and save an
> +compromised by a user level problem, and when sealed to a platform integrity
> +state, protects against boot and offline attacks. Create and save an
>  encrypted key "evm" using the above trusted key "kmk":
>  
>  option 1: omitting 'format'::
> 


thanks.
-- 
~Randy


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-12-04  5:16       ` Jarkko Sakkinen
@ 2020-12-08 11:51         ` Sumit Garg
  0 siblings, 0 replies; 27+ messages in thread
From: Sumit Garg @ 2020-12-08 11:51 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

Hi Jarkko,

Apologies for the delay in my response as I was busy with other high
priority work.

On Fri, 4 Dec 2020 at 10:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Fri, Nov 06, 2020 at 04:52:52PM +0200, Jarkko Sakkinen wrote:
> > On Fri, Nov 06, 2020 at 03:02:41PM +0530, Sumit Garg wrote:
> > > On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >
> > > > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> > > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > > to seal and unseal trusted keys using hardware unique key. Also, this is
> > > > > an alternative in case platform doesn't possess a TPM device.
> > > > >
> > > > > This patch-set has been tested with OP-TEE based early TA which is already
> > > > > merged in upstream [1].
> > > >
> > > > Is the new RPI400 computer a platform that can be used for testing
> > > > patch sets like this? I've been looking for a while something ARM64
> > > > based with similar convenience as Intel NUC's, and on the surface
> > > > this new RPI product looks great for kernel testing purposes.
> > >
> > > Here [1] is the list of supported versions of Raspberry Pi in OP-TEE.
> > > The easiest approach would be to pick up a supported version or else
> > > do an OP-TEE port for an unsupported one (which should involve minimal
> > > effort).
> > >
> > > [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work
> > >
> > > -Sumit
> >
> > If porting is doable, then I'll just order RPI 400, and test with QEMU
> > up until either I port OP-TEE myself or someone else does it.
> >
> > For seldom ARM testing, RPI 400 is really convenient device with its
> > boxed form factor.
>
> I'm now a proud owner of Raspberry Pi 400 home computer :-)
>
> I also found instructions on how to boot a custom OS from a USB stick:
>
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
>
> Also, my favorite build system BuildRoot has bunch of of the shelf
> configs:
>
> ➜  buildroot-sgx (master) ✔ ls -1 configs | grep raspberry
> raspberrypi0_defconfig
> raspberrypi0w_defconfig
> raspberrypi2_defconfig
> raspberrypi3_64_defconfig
> raspberrypi3_defconfig
> raspberrypi3_qt5we_defconfig
> raspberrypi4_64_defconfig
> raspberrypi4_defconfig
> raspberrypi_defconfig
>
> I.e. I'm capable of compiling kernel and user space and boot it up
> with it.
>
> Further, I can select this compilation option:
>
> BR2_TARGET_OPTEE_OS:                                                                                                                                              │
>                                                                                                                                                                      │
>    OP-TEE OS provides the secure world boot image and the trust                                                                                                      │
>    application development kit of the OP-TEE project. OP-TEE OS                                                                                                      │
>    also provides generic trusted application one can embedded                                                                                                        │
>    into its system.                                                                                                                                                  │
>                                                                                                                                                                      │
>    http://github.com/OP-TEE/optee_os
>
> Is that what I want? If I put this all together and apply your patches,
> should the expectation be that I can use trusted keys?
>

Firstly you need to do an OP-TEE port for RPI 400 (refer here [1] for
guidelines). And then in order to boot up OP-TEE on RPI 400, you can
refer to Raspberry Pi 3 build instructions [2].

[1] https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
[2] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#build-instructions

> Please note that I had a few remarks about your patches (minor but need
> to be fixed), but this version is already solid enough for testing.
>

Sure, I will incorporate your remarks and Randy's documentation
comments in the next version.

-Sumit

> /Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-04 15:30     ` Jarkko Sakkinen
@ 2020-12-08 15:02       ` Mimi Zohar
  2020-12-08 17:49         ` Jarkko Sakkinen
  0 siblings, 1 reply; 27+ messages in thread
From: Mimi Zohar @ 2020-12-08 15:02 UTC (permalink / raw)
  To: Jarkko Sakkinen, Elaine Palmer
  Cc: Sumit Garg, jarkko.sakkinen, jejb, dhowells, jens.wiklander,
	corbet, jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee, Kenneth Goldman, gcwilson, zgu, stefanb, NAYNA JAIN1

Hi Jarkko,

On Fri, 2020-12-04 at 17:30 +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 02, 2020 at 02:34:07PM -0500, gmail Elaine Palmer wrote:
> > Hi Sumit,  
> > 
> > Thank you for the detailed descriptions and examples of trust sources
> > for Trusted Keys.   A group of us in IBM (Stefan Berger, Ken Goldman,
> > Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar)
> > have been doing related work for quite some time, and we have one
> > primary concern and some suggested changes to the document. 
> > 
> > Our primary concern is that describing a TEE as a Trust Source needs
> > to be more specific.   For example, "ARM TrustZone" is not sufficient,
> > but "wolfSSL embedded SSL/TLS library with ARM TrustZone
> > CryptoCell-310" is.  Just because a key is protected by software
> > running in a TEE is not enough to establish trust.  Just like
> > cryptographic modules, a Trust Source should be defined as a specific
> > implementation on specific hardware with well-documented environmental
> > assumptions, dependencies, and threats.
> > 
> > In addition to the above concern, our suggested changes are inline
> > below.
> 
> In order to give a decent review comment it should have two ingredients:
> 
> - Where the existing line of code / text / whatever goes wrong.
> - How it should modified and why that makes sense. And use as plain
>   English and non-academic terms as possible, if it is documentation.
>   Further, scope is only the kernel implementation, no more or no
>   less.
> 
> "do this" is not unfortunately an argument. Feedback is welcome when
> it is supported by something common sensse.

Even after the code is fully debugged, reviewed and tested, our concern
is that people will assume the security guarantees of TEE based trusted
keys to be equivalent to that of a discrete TPM.

> 
> Some meta suggestion of related to email:
> 
> Please also use a proper email client and split your paragraphs into
> at most 80 character lines with new line characters when writing email.
> I prefer to use 72 character line length so that there's some space
> for longer email threads.

Sure, we'll re-post the suggested documentation changes/additions.

Mimi


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
  2020-12-02 19:34   ` gmail Elaine Palmer
  2020-12-06 18:51   ` Randy Dunlap
@ 2020-12-08 15:55   ` Mimi Zohar
  2020-12-08 17:07     ` Mimi Zohar
  2 siblings, 1 reply; 27+ messages in thread
From: Mimi Zohar @ 2020-12-08 15:55 UTC (permalink / raw)
  To: Sumit Garg, jarkko.sakkinen, jejb, Elaine Palmer
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, George Wilson

Hi Sumit, Jarkko,

Re-posting Elaine Palmer's comments, inline below, trimmed and properly
formatted.

On Tue, 2020-11-03 at 21:31 +0530, Sumit Garg wrote:
> Update documentation for Trusted and Encrypted Keys with TEE as a new
> trust source. Following is brief description of updates:
> 
> - Add a section to demostrate a list of supported devices along with
>   their security properties/guarantees.
> - Add a key generation section.
> - Updates for usage section including differences specific to a trust
>   source.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++++++++++----
>  1 file changed, 171 insertions(+), 32 deletions(-)
> 
> diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
> index 1da879a..16042c8 100644
> --- a/Documentation/security/keys/trusted-encrypted.rst
> +++ b/Documentation/security/keys/trusted-encrypted.rst
> @@ -6,30 +6,161 @@ Trusted and Encrypted Keys are two new key types added to the existing kernel
>  key ring service.  Both of these new types are variable length symmetric keys,
>  and in both cases all keys are created in the kernel, and user space sees,
>  stores, and loads only encrypted blobs.  Trusted Keys require the availability
> -of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
> -Keys can be used on any system.  All user level blobs, are displayed and loaded
> -in hex ascii for convenience, and are integrity verified.
> +of a Trust Source for greater security, while Encrypted Keys can be used on any
> +system. All user level blobs, are displayed and loaded in hex ascii for
> +convenience, and are integrity verified.
>  
> -Trusted Keys use a TPM both to generate and to seal the keys.  Keys are sealed
> -under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR
> -(integrity measurement) values, and only unsealed by the TPM, if PCRs and blob
> -integrity verifications match.  A loaded Trusted Key can be updated with new
> -(future) PCR values, so keys are easily migrated to new pcr values, such as
> -when the kernel and initramfs are updated.  The same key can have many saved
> -blobs under different PCR values, so multiple boots are easily supported.
>  
> -TPM 1.2
> --------
> +Trust Source
> +============
>  
> -By default, trusted keys are sealed under the SRK, which has the default
> -authorization value (20 zeros).  This can be set at takeownership time with the
> -trouser's utility: "tpm_takeownership -u -z".
> +Trust Source provides the source of security for the Trusted Keys, on which
> +basis Trusted Keys establishes a Trust model with its user.

A trust source provides the source of security for the Trusted
Keys.  Whether or not a trust source is sufficiently safe depends on
the strength and correctness of its implementation, as well as the
threat environment for a specific use case.  Since the kernel doesn't
know what the environment is, and there is no metric of trust, it is
dependent on the consumer of the Trusted Keys to determine if the trust
source is sufficiently safe.

>  A Trust Source could
> +differ from one system to another depending on its security requirements. It
> +could be either an off-chip device or an on-chip device. Following section
> +demostrates a list of supported devices along with their security properties/
> +guarantees:
>  
> -TPM 2.0
> --------
> +  *  Root of trust for storage
>  
> -The user must first create a storage key and make it persistent, so the key is
> -available after reboot. This can be done using the following commands.
> +     (1) TPM (Trusted Platform Module: hardware device)
> +
> +         Rooted to Storage Root Key (SRK) which never leaves the TPM that
> +         provides crypto operation to establish root of trust for storage.
> +
> +     (2) TEE (Trusted Execution Environment: OP-TEE based on Arm TrustZone)
> +
> +         Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
> +         fuses and is accessible to TEE only.
> +
> +  *  Execution isolation
> +
> +     (1) TPM
> +
> +         Fixed set of operations running in isolated execution environment.
> +
> +     (2) TEE
> +
> +         Customizable set of operations running in isolated execution
> +         environment verified via Secure/Trusted boot process.
> +
> +  * Optional binding to platform integrity state
> +
> +     (1) TPM
> +
> +         Keys can be optionally sealed to specified PCR (integrity measurement)
> +         values, and only unsealed by the TPM, if PCRs and blob integrity
> +         verifications match. A loaded Trusted Key can be updated with new
> +         (future) PCR values, so keys are easily migrated to new PCR values,
> +         such as when the kernel and initramfs are updated. The same key can
> +         have many saved blobs under different PCR values, so multiple boots are
> +         easily supported.
> +
> +     (2) TEE
> +
> +         Relies on Secure/Trusted boot process for platform integrity. It can
> +         be extended with TEE based measured boot process.
> +
> +  *  On-chip versus off-chip
> +
> +     (1) TPM
> +
> +         Off-chip device connected via serial bus (like I2C, SPI etc.) exposing
> +         physical access which represents an attack surface that can be
> +         mitigated via tamper detection.
> +
> +     (2) TEE
> +
> +         On-chip functionality, immune to this attack surface.
> +
> +  *  Memory attacks (DRAM based like attaching a bus monitor etc.)
> +
> +     (1) TPM
> +
> +         Immune to these attacks as it doesn’t make use of system DRAM.
> +
> +     (2) TEE
> +
> +         An implementation based on TrustZone protected DRAM is susceptible to
> +         such attacks. In order to mitigate these attacks one needs to rely on
> +         on-chip secure RAM to store secrets or have the entire TEE
> +         implementation based on on-chip secure RAM. An alternative mitigation
> +         would be to use encrypted DRAM.
> +
> +  *  Side-channel attacks (cache, memory, CPU or time based)
> +
> +     (1) TPM
> +
> +         Immune to side-channel attacks as its resources are isolated from the
> +         main OS.
> +
> +     (2) TEE
> +
> +         A careful implementation is required to mitigate against these attacks
> +         for resources which are shared (eg. shared memory) with the main OS.
> +         Cache and CPU based side-channel attacks can be mitigated via
> +         invalidating caches and CPU registers during context switch to and from
> +         the secure world.
> +         To mitigate against time based attacks, one needs to have time
> +         invariant implementations (like crypto algorithms etc.).
> +
> +  *  Resistance to physical attacks (power analysis, electromagnetic emanation,
> +     probes etc.)
> +
> +     (1) TPM
> +
> +         Provides limited protection utilizing tamper resistance.
> +
> +     (2) TEE
> +
> +         Provides no protection by itself, relies on the underlying platform for
> +         features such as tamper resistance.
> +

Please add the following topics:

* Provisioning - the trust source's unique and verifiable cryptographic
identity is provisioned during manufacturing

(1) TPM

The unique and verifiable cryptographic identity is the endorsement key
(EK) or its primary seed.  A review of the generation of the EK and its
accompanying certificate is part of the Common Criteria evaluation of
the product's lifecycle processes (ALC_*).  See "TCG Protection Profile
for PC Client Specific TPM 2" (
https://trustedcomputinggroup.org/resource/pc-client-protection-profile-for-tpm-2-0/
).

(2) TEE

A protection profile for TEEs does not yet exist.  Therefore, the
provisioning process that generates the Hardware Unique Key is not
evaluated by an independent third party and is highly dependent on the
manufacturing environment.


* Cryptography

(1) TPM

As part of the TPM's mandatory Common Criteria evaluation, the
correctness of the TPM's implementation of cryptographic algorithms,
the protection of keys, and the generation of random numbers, and other
security-relevant functions must be documented, reviewed, and tested by
an independent third party evaluation agency.  It must meet the
requirements of FIPS 140-2, FIPS 140-3, or ISO/IEC 19790:2012. 

(2) TEE

Evaluations of cryptographic modules within TEEs are not required, but
some are available for specific implementations within TEEs.


* Interfaces and APIs

(1) TPM

 TPMs have well-documented, standardized interfaces and APIs.

(2) TEE

Unless TEEs implement functionality such as a virtual TPM, they have
custom interfaces and APIs. 


* Threat model

The strength and appropriateness of TPMs and TEEs for a given purpose
must be assessed when using them to protect security-relevant data.

> +
> +Key Generation
> +==============
> +
> +Trusted Keys
> +------------
> +
> +New keys are created from trust source generated random numbers, and are
> +encrypted/decrypted using trust source storage root key.

New keys are created from random numbers generated in the trust source.
They are encrypted/decrypted using a child key in the storage key
hierarchy.  Encryption and decryption of the child key must be
protected by a strong access control policy within the trust source.

Thank you,

Elaine (and Mimi)


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-08 15:55   ` Mimi Zohar
@ 2020-12-08 17:07     ` Mimi Zohar
  0 siblings, 0 replies; 27+ messages in thread
From: Mimi Zohar @ 2020-12-08 17:07 UTC (permalink / raw)
  To: Sumit Garg, jarkko.sakkinen, jejb, Elaine Palmer
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, George Wilson

Hi Sumit, Jarkko,

On Tue, 2020-12-08 at 10:55 -0500, Mimi Zohar wrote:
> Re-posting Elaine Palmer's comments, inline below, trimmed and properly
> formatted.

Continued ...

Thank you for the detailed descriptions and examples of trust sources
for Trusted Keys.  A group of us in IBM (Stefan Berger, Ken Goldman,
Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar) have
some concerns with extending trusted keys to new sources without
providing a threat model.   The following is based on our internal
discussions.

> * Threat model
> 
> The strength and appropriateness of TPMs and TEEs for a given purpose
> must be assessed when using them to protect security-relevant data.

The original Trusted Keys implementation assumed discrete physical TPMs
for key protection[1].  However, even physical TPMs themselves vary
based on the manufacturer and systems in which they are placed.  The
embedded chipset, firmware load, algorithms, packaging, pins, and
countermeasures vary.  (Threats and mitigations on physical TPMs are
well documented, e.g., "Threat Model of a Scenario Based on Trusted
Platform Module 2.0 Specification” (http://ceur-ws.org/Vol-1011/6.pdf).

Extending Trusted Keys to support new trust sources needs to provide
consumers of these new sources enough information so that they can
create their own threat models tailored to their use cases.

Just as each new LSM needs to comply with Documentation/security/lsm-
development.rst, we recommend each new source should provide a high-
level threat model.  We suggest documenting environmental assumptions
and dependencies in a high-level threat model for each additional trust
source.  An example of a high-level threat model is "Common Security
Threats v1.0” (
https://www.opencompute.org/documents/common-security-threats-notes-1-pdf
 ).

Thank you,

Elaine (and Mimi)


[1] Specific to Trusted Keys and TPMs, there is some discussion of
threats and mitigations in the Integrity_overview.pdf on the IMA wiki:

"The trusted key component does two things to help with secure key management on Linux. First, it provides a kernel key ring service in which the symmetric encryption keys are never visible in plain text to userspace. The keys are created in the kernel, and sealed by a hardware device such as a TPM, with userspace seeing only the sealed blobs. Malicious or compromised applications cannot steal a trusted key, since only the kernel can see the unsealed blobs. Secondly, the trusted keys can tie key unsealing to the integrity measurements, so that keys cannot be stolen in an offline attack, such as by booting an unlocked Linux image from CD or USB.  As the measurements will be different, the TPM chip will refuse to unseal the keys, even for the kernel."


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-08 15:02       ` Mimi Zohar
@ 2020-12-08 17:49         ` Jarkko Sakkinen
  2020-12-09 16:50           ` Mimi Zohar
  0 siblings, 1 reply; 27+ messages in thread
From: Jarkko Sakkinen @ 2020-12-08 17:49 UTC (permalink / raw)
  To: Mimi Zohar, sumit.garg
  Cc: Elaine Palmer, jarkko.sakkinen, jejb, dhowells, jens.wiklander,
	corbet, jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee, Kenneth Goldman, gcwilson, zgu, stefanb, NAYNA JAIN1

On Tue, Dec 08, 2020 at 10:02:57AM -0500, Mimi Zohar wrote:
> Hi Jarkko,
> 
> On Fri, 2020-12-04 at 17:30 +0200, Jarkko Sakkinen wrote:
> > On Wed, Dec 02, 2020 at 02:34:07PM -0500, gmail Elaine Palmer wrote:
> > > Hi Sumit,  
> > > 
> > > Thank you for the detailed descriptions and examples of trust sources
> > > for Trusted Keys.   A group of us in IBM (Stefan Berger, Ken Goldman,
> > > Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar)
> > > have been doing related work for quite some time, and we have one
> > > primary concern and some suggested changes to the document. 
> > > 
> > > Our primary concern is that describing a TEE as a Trust Source needs
> > > to be more specific.   For example, "ARM TrustZone" is not sufficient,
> > > but "wolfSSL embedded SSL/TLS library with ARM TrustZone
> > > CryptoCell-310" is.  Just because a key is protected by software
> > > running in a TEE is not enough to establish trust.  Just like
> > > cryptographic modules, a Trust Source should be defined as a specific
> > > implementation on specific hardware with well-documented environmental
> > > assumptions, dependencies, and threats.
> > > 
> > > In addition to the above concern, our suggested changes are inline
> > > below.
> > 
> > In order to give a decent review comment it should have two ingredients:
> > 
> > - Where the existing line of code / text / whatever goes wrong.
> > - How it should modified and why that makes sense. And use as plain
> >   English and non-academic terms as possible, if it is documentation.
> >   Further, scope is only the kernel implementation, no more or no
> >   less.
> > 
> > "do this" is not unfortunately an argument. Feedback is welcome when
> > it is supported by something common sensse.
> 
> Even after the code is fully debugged, reviewed and tested, our concern
> is that people will assume the security guarantees of TEE based trusted
> keys to be equivalent to that of a discrete TPM.
> 
> > 
> > Some meta suggestion of related to email:
> > 
> > Please also use a proper email client and split your paragraphs into
> > at most 80 character lines with new line characters when writing email.
> > I prefer to use 72 character line length so that there's some space
> > for longer email threads.
> 
> Sure, we'll re-post the suggested documentation changes/additions.
> 
> Mimi

So. Wouldn't it be a better idea to post a patch that Sumit could
squash to his (and add co-developed-by tag)?

/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-08 17:49         ` Jarkko Sakkinen
@ 2020-12-09 16:50           ` Mimi Zohar
  2020-12-11 10:36             ` Jarkko Sakkinen
  0 siblings, 1 reply; 27+ messages in thread
From: Mimi Zohar @ 2020-12-09 16:50 UTC (permalink / raw)
  To: Jarkko Sakkinen, sumit.garg
  Cc: Elaine Palmer, jarkko.sakkinen, jejb, dhowells, jens.wiklander,
	corbet, jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee, Kenneth Goldman, gcwilson, zgu, stefanb, NAYNA JAIN1

On Tue, 2020-12-08 at 19:49 +0200, Jarkko Sakkinen wrote:
> On Tue, Dec 08, 2020 at 10:02:57AM -0500, Mimi Zohar wrote:

> > > Please also use a proper email client and split your paragraphs into
> > > at most 80 character lines with new line characters when writing email.
> > > I prefer to use 72 character line length so that there's some space
> > > for longer email threads.
> > 
> > Sure, we'll re-post the suggested documentation changes/additions.
> > 
> > Mimi
> 
> So. Wouldn't it be a better idea to post a patch that Sumit could
> squash to his (and add co-developed-by tag)?

I just posted it on Elaine's behalf.
  
Mimi


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-09 16:50           ` Mimi Zohar
@ 2020-12-11 10:36             ` Jarkko Sakkinen
  2020-12-11 15:29               ` Mimi Zohar
  0 siblings, 1 reply; 27+ messages in thread
From: Jarkko Sakkinen @ 2020-12-11 10:36 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: sumit.garg, Elaine Palmer, jarkko.sakkinen, jejb, dhowells,
	jens.wiklander, corbet, jmorris, serge, casey, janne.karhunen,
	daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Kenneth Goldman, gcwilson, zgu,
	stefanb, NAYNA JAIN1

On Wed, Dec 09, 2020 at 11:50:19AM -0500, Mimi Zohar wrote:
> On Tue, 2020-12-08 at 19:49 +0200, Jarkko Sakkinen wrote:
> > On Tue, Dec 08, 2020 at 10:02:57AM -0500, Mimi Zohar wrote:
> 
> > > > Please also use a proper email client and split your paragraphs into
> > > > at most 80 character lines with new line characters when writing email.
> > > > I prefer to use 72 character line length so that there's some space
> > > > for longer email threads.
> > > 
> > > Sure, we'll re-post the suggested documentation changes/additions.
> > > 
> > > Mimi
> > 
> > So. Wouldn't it be a better idea to post a patch that Sumit could
> > squash to his (and add co-developed-by tag)?
> 
> I just posted it on Elaine's behalf.
>   
> Mimi

I responded. It's good that this feedback came as I think the whole
thing does not have the correct label for it.

/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-11 10:36             ` Jarkko Sakkinen
@ 2020-12-11 15:29               ` Mimi Zohar
  0 siblings, 0 replies; 27+ messages in thread
From: Mimi Zohar @ 2020-12-11 15:29 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: sumit.garg, Elaine Palmer, jarkko.sakkinen, jejb, dhowells,
	jens.wiklander, corbet, jmorris, serge, casey, janne.karhunen,
	daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Kenneth Goldman, gcwilson, zgu,
	stefanb, NAYNA JAIN1, Zohargshu Gu

On Fri, 2020-12-11 at 12:36 +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 09, 2020 at 11:50:19AM -0500, Mimi Zohar wrote:
> > On Tue, 2020-12-08 at 19:49 +0200, Jarkko Sakkinen wrote:
> > > On Tue, Dec 08, 2020 at 10:02:57AM -0500, Mimi Zohar wrote:
> > 
> > > > > Please also use a proper email client and split your paragraphs into
> > > > > at most 80 character lines with new line characters when writing email.
> > > > > I prefer to use 72 character line length so that there's some space
> > > > > for longer email threads.
> > > > 
> > > > Sure, we'll re-post the suggested documentation changes/additions.
> > > > 
> > > 
> > > So. Wouldn't it be a better idea to post a patch that Sumit could
> > > squash to his (and add co-developed-by tag)?
> > 
> > I just posted it on Elaine's behalf.
> >   
> 
> I responded. It's good that this feedback came as I think the whole
> thing does not have the correct label for it.

Every HW is going to want to add "trusted keys" support.   We've seen
this with Udit Agarwal's "secure keys" proposal for NXP CAAM crypto HW
accelerator.  If we go down this route to extend "trusted keys" to
support specific implementations like this one, I strongly recommend
requiring an accompaying high-level threat model.  This is similar to
how new LSMs need to comply with Documentation/security/lsm-
development.rst.

Based on Elaine's work with OCP, an example of a high-level threat
model is "Common Security Threats v1.0” (
https://www.opencompute.org/documents/common-security-threats-notes-1-pdf
 ).

thanks,

Mimi


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
  2020-11-24  3:46   ` Jarkko Sakkinen
@ 2021-01-11 16:35   ` Jarkko Sakkinen
  2021-01-13 11:17     ` Sumit Garg
  1 sibling, 1 reply; 27+ messages in thread
From: Jarkko Sakkinen @ 2021-01-11 16:35 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key.
> 
> Refer to Documentation/tee.txt for detailed information about TEE.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>

I haven't yet got QEMU environment working with aarch64, this produces
just a blank screen:

./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio

My BuildRoot fork for TPM and keyring testing is located over here:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/

The "ARM version" is at this point in aarch64 branch. Over time I will
define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
in the master branch.

To create identical images you just need to

$ make tpmdd_defconfig && make

Can you check if you see anything obviously wrong? I'm eager to test this
patch set, and in bigger picture I really need to have ready to run
aarch64 environment available.

/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-11 16:35   ` Jarkko Sakkinen
@ 2021-01-13 11:17     ` Sumit Garg
  2021-01-14  2:05       ` Jarkko Sakkinen
  0 siblings, 1 reply; 27+ messages in thread
From: Sumit Garg @ 2021-01-13 11:17 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

Hi Jarkko,

On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > Add support for TEE based trusted keys where TEE provides the functionality
> > to seal and unseal trusted keys using hardware unique key.
> >
> > Refer to Documentation/tee.txt for detailed information about TEE.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
>
> I haven't yet got QEMU environment working with aarch64, this produces
> just a blank screen:
>
> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
>
> My BuildRoot fork for TPM and keyring testing is located over here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
>
> The "ARM version" is at this point in aarch64 branch. Over time I will
> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> in the master branch.
>
> To create identical images you just need to
>
> $ make tpmdd_defconfig && make
>
> Can you check if you see anything obviously wrong? I'm eager to test this
> patch set, and in bigger picture I really need to have ready to run
> aarch64 environment available.

I would rather suggest you to follow steps listed here [1] as to test
this feature on Qemu aarch64 we need to build firmwares such as TF-A,
OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
system [2]. And then it would be easier to migrate them to your
buildroot environment as well.

[1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
[2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8

-Sumit

>
> /Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-13 11:17     ` Sumit Garg
@ 2021-01-14  2:05       ` Jarkko Sakkinen
  2021-01-15  6:02         ` Sumit Garg
  0 siblings, 1 reply; 27+ messages in thread
From: Jarkko Sakkinen @ 2021-01-14  2:05 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> Hi Jarkko,
> 
> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > Add support for TEE based trusted keys where TEE provides the functionality
> > > to seal and unseal trusted keys using hardware unique key.
> > >
> > > Refer to Documentation/tee.txt for detailed information about TEE.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > I haven't yet got QEMU environment working with aarch64, this produces
> > just a blank screen:
> >
> > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> >
> > My BuildRoot fork for TPM and keyring testing is located over here:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> >
> > The "ARM version" is at this point in aarch64 branch. Over time I will
> > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > in the master branch.
> >
> > To create identical images you just need to
> >
> > $ make tpmdd_defconfig && make
> >
> > Can you check if you see anything obviously wrong? I'm eager to test this
> > patch set, and in bigger picture I really need to have ready to run
> > aarch64 environment available.
> 
> I would rather suggest you to follow steps listed here [1] as to test
> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> system [2]. And then it would be easier to migrate them to your
> buildroot environment as well.
> 
> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> 
> -Sumit

Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.

After I've successfully tested 2/4, I'd suggest that you roll out one more
version and CC the documentation patch to Elaine and Mini, and clearly
remark in the commit message that TEE is a standard, with a link to the
specification.

/Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-14  2:05       ` Jarkko Sakkinen
@ 2021-01-15  6:02         ` Sumit Garg
  0 siblings, 0 replies; 27+ messages in thread
From: Sumit Garg @ 2021-01-15  6:02 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > Hi Jarkko,
> >
> > On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > to seal and unseal trusted keys using hardware unique key.
> > > >
> > > > Refer to Documentation/tee.txt for detailed information about TEE.
> > > >
> > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > >
> > > I haven't yet got QEMU environment working with aarch64, this produces
> > > just a blank screen:
> > >
> > > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > >
> > > My BuildRoot fork for TPM and keyring testing is located over here:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > >
> > > The "ARM version" is at this point in aarch64 branch. Over time I will
> > > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > in the master branch.
> > >
> > > To create identical images you just need to
> > >
> > > $ make tpmdd_defconfig && make
> > >
> > > Can you check if you see anything obviously wrong? I'm eager to test this
> > > patch set, and in bigger picture I really need to have ready to run
> > > aarch64 environment available.
> >
> > I would rather suggest you to follow steps listed here [1] as to test
> > this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > system [2]. And then it would be easier to migrate them to your
> > buildroot environment as well.
> >
> > [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> >
> > -Sumit
>
> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
>

$ cat keyctl_change
diff --git a/common.mk b/common.mk
index aeb7b41..663e528 100644
--- a/common.mk
+++ b/common.mk
@@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
 BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
 BR2_PACKAGE_STRACE ?= y
 BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
$(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
+BR2_PACKAGE_KEYUTILS := y

 # All BR2_* variables from the makefile or the environment are appended to
 # ../out-br/extra.conf. All values are quoted "..." except y and n.
diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
index 368c18a..832ab74 100644
--- a/kconfigs/qemu.conf
+++ b/kconfigs/qemu.conf
@@ -20,3 +20,5 @@ CONFIG_9P_FS=y
 CONFIG_9P_FS_POSIX_ACL=y
 CONFIG_HW_RANDOM=y
 CONFIG_HW_RANDOM_VIRTIO=y
+CONFIG_TRUSTED_KEYS=y
+CONFIG_ENCRYPTED_KEYS=y

> After I've successfully tested 2/4, I'd suggest that you roll out one more
> version and CC the documentation patch to Elaine and Mini, and clearly
> remark in the commit message that TEE is a standard, with a link to the
> specification.
>

Sure, I will roll out the next version after your testing.

-Sumit

> /Jarkko

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, back to index

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
2020-11-24  3:42   ` Jarkko Sakkinen
2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
2020-11-24  3:46   ` Jarkko Sakkinen
2021-01-11 16:35   ` Jarkko Sakkinen
2021-01-13 11:17     ` Sumit Garg
2021-01-14  2:05       ` Jarkko Sakkinen
2021-01-15  6:02         ` Sumit Garg
2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
2020-12-02 19:34   ` gmail Elaine Palmer
2020-12-04 15:30     ` Jarkko Sakkinen
2020-12-08 15:02       ` Mimi Zohar
2020-12-08 17:49         ` Jarkko Sakkinen
2020-12-09 16:50           ` Mimi Zohar
2020-12-11 10:36             ` Jarkko Sakkinen
2020-12-11 15:29               ` Mimi Zohar
2020-12-06 18:51   ` Randy Dunlap
2020-12-08 15:55   ` Mimi Zohar
2020-12-08 17:07     ` Mimi Zohar
2020-11-03 16:01 ` [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer Sumit Garg
2020-11-24  3:46   ` Jarkko Sakkinen
2020-11-05  5:07 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen
2020-11-06  9:32   ` Sumit Garg
2020-11-06 14:52     ` Jarkko Sakkinen
2020-12-04  5:16       ` Jarkko Sakkinen
2020-12-08 11:51         ` Sumit Garg

Keyrings Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/keyrings/0 keyrings/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 keyrings keyrings/ https://lore.kernel.org/keyrings \
		keyrings@vger.kernel.org
	public-inbox-index keyrings

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.keyrings


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git