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

On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:

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.

Thanks, I'll try this at instant, and give my feedback.

/Jarkko

On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen jarkko@kernel.org wrote:

On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:

...

On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:

...

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.

Thanks, I'll try this at instant, and give my feedback.

I bump into this:

$ make run-only ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/ ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory make: *** [Makefile:194: run-only] Error 1

Could you check if the following directory tree is built after executing the below command?

$ make -j`nproc` CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c

$ tree out/bin/ out/bin/ ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin ├── bl31.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin ├── bl32.bin -> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin ├── bl32_extra1.bin -> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin ├── bl32_extra2.bin -> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin ├── bl33.bin -> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image └── rootfs.cpio.gz -> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz

0 directories, 9 files

-Sumit

/Jarkko

Hello Sumit,

On 03.11.20 17:01, 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"

Looks unusual to define this in a header, especially when it's included in trusted_core.c as well. Could you move it?

+/*

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

These also look like implementation-specific stuff that should go into trusted_tee.c?

+/**

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

This is name is a bit too generic. Either move it to trusted_tee or put a caam_ prefix in front?

• struct device *dev;
• struct tee_context *ctx;
• u32 session_id;
• struct tee_shm *shm_pool;

+};

+extern struct trusted_key_ops tee_trusted_key_ops;

This looks like the only thing that must be in this header.

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

Shouldn't this depend on CONFIG_TEE or similar? Otherwise without LTO, you'd run into linker errors.

[Apologies if these points were raised in previous review cycles, I just recently subscribed]

Cheers, Ahmad

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,

+};

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

(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/presen...)

+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

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

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