From: Mimi Zohar <zohar@linux.ibm.com> To: Casey Schaufler <casey@schaufler-ca.com>, Sumit Garg <sumit.garg@linaro.org>, keyrings@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org Cc: jens.wiklander@linaro.org, corbet@lwn.net, dhowells@redhat.com, jejb@linux.ibm.com, jarkko.sakkinen@linux.intel.com, jmorris@namei.org, serge@hallyn.com, ard.biesheuvel@linaro.org, daniel.thompson@linaro.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, tee-dev@lists.linaro.org Subject: Re: [RFC 0/7] Introduce TEE based Trusted Keys support Date: Fri, 14 Jun 2019 00:03:13 +0000 [thread overview] Message-ID: <1560470593.4805.109.camel@linux.ibm.com> (raw) In-Reply-To: <d803283e-5e69-5deb-fe94-3f2e45fb95af@schaufler-ca.com> On Thu, 2019-06-13 at 09:40 -0700, Casey Schaufler wrote: > On 6/13/2019 3:30 AM, 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 series also adds some TEE features like: > > Please expand the acronym TEE on first use. That will > help people who don't work with it on a daily basis > understand what you're going on about. Thanks, Casey. "[6/7] doc: keys: Document usage of TEE based Trusted Keys" refers to the kernel tee documentation, but that documentation is limited to userspace interaction with the tee. A trusted key is a random number generated and sealed(encrypted) by the TPM, so that only the TPM may unseal it. The sealing key never leaves the TPM. The sealed, trusted key may be exported to userspace. In the tee case, can the "sealing" key ever leave the tee? Can the sealed, trusted key, exported to userspace, be unsealed by the tee? Are the tee security protections similar to those of the TPM? How do they compare? Mimi > > > > > Patch #1, #2 enables support for registered kernel shared memory with TEE. > > > > Patch #3 enables support for private kernel login method required for > > cases like trusted keys where we don't wan't user-space to directly access > > TEE service to retrieve trusted key contents. > > > > Rest of the patches from #4 to #7 adds support for TEE based trusted keys. > > > > This patch-set has been tested with OP-TEE based pseudo TA which can be > > found here [1]. > > > > Looking forward to your valuable feedback/suggestions.
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com> To: Casey Schaufler <casey@schaufler-ca.com>, Sumit Garg <sumit.garg@linaro.org>, keyrings@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org Cc: jens.wiklander@linaro.org, corbet@lwn.net, dhowells@redhat.com, jejb@linux.ibm.com, jarkko.sakkinen@linux.intel.com, jmorris@namei.org, serge@hallyn.com, ard.biesheuvel@linaro.org, daniel.thompson@linaro.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, tee-dev@lists.linaro.org Subject: Re: [RFC 0/7] Introduce TEE based Trusted Keys support Date: Thu, 13 Jun 2019 20:03:13 -0400 [thread overview] Message-ID: <1560470593.4805.109.camel@linux.ibm.com> (raw) In-Reply-To: <d803283e-5e69-5deb-fe94-3f2e45fb95af@schaufler-ca.com> On Thu, 2019-06-13 at 09:40 -0700, Casey Schaufler wrote: > On 6/13/2019 3:30 AM, 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 series also adds some TEE features like: > > Please expand the acronym TEE on first use. That will > help people who don't work with it on a daily basis > understand what you're going on about. Thanks, Casey. "[6/7] doc: keys: Document usage of TEE based Trusted Keys" refers to the kernel tee documentation, but that documentation is limited to userspace interaction with the tee. A trusted key is a random number generated and sealed(encrypted) by the TPM, so that only the TPM may unseal it. The sealing key never leaves the TPM. The sealed, trusted key may be exported to userspace. In the tee case, can the "sealing" key ever leave the tee? Can the sealed, trusted key, exported to userspace, be unsealed by the tee? Are the tee security protections similar to those of the TPM? How do they compare? Mimi > > > > > Patch #1, #2 enables support for registered kernel shared memory with TEE. > > > > Patch #3 enables support for private kernel login method required for > > cases like trusted keys where we don't wan't user-space to directly access > > TEE service to retrieve trusted key contents. > > > > Rest of the patches from #4 to #7 adds support for TEE based trusted keys. > > > > This patch-set has been tested with OP-TEE based pseudo TA which can be > > found here [1]. > > > > Looking forward to your valuable feedback/suggestions.
next prev parent reply other threads:[~2019-06-14 0:03 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-13 10:30 [RFC 0/7] Introduce TEE based Trusted Keys support Sumit Garg 2019-06-13 10:42 ` Sumit Garg 2019-06-13 10:30 ` [RFC 1/7] tee: optee: allow kernel pages to register as shm Sumit Garg 2019-06-13 10:42 ` Sumit Garg 2019-06-13 15:12 ` Jarkko Sakkinen 2019-06-13 15:12 ` Jarkko Sakkinen 2019-06-13 15:17 ` Jarkko Sakkinen 2019-06-13 15:17 ` Jarkko Sakkinen 2019-06-13 15:17 ` Jarkko Sakkinen 2019-06-13 15:17 ` Jarkko Sakkinen 2019-06-14 5:12 ` Sumit Garg 2019-06-14 5:24 ` Sumit Garg 2019-06-14 8:15 ` Jens Wiklander 2019-06-14 8:15 ` Jens Wiklander 2019-06-13 10:30 ` [RFC 2/7] tee: enable support to register kernel memory Sumit Garg 2019-06-13 10:42 ` Sumit Garg 2019-06-13 15:20 ` Jarkko Sakkinen 2019-06-13 15:20 ` Jarkko Sakkinen 2019-06-14 5:13 ` Sumit Garg 2019-06-14 5:25 ` Sumit Garg 2019-06-14 8:16 ` Jens Wiklander 2019-06-14 8:16 ` Jens Wiklander 2019-06-13 10:30 ` [RFC 3/7] tee: add private login method for kernel clients Sumit Garg 2019-06-13 10:42 ` Sumit Garg 2019-07-08 15:39 ` Jens Wiklander 2019-07-08 15:39 ` Jens Wiklander 2019-07-09 5:56 ` Sumit Garg 2019-07-09 5:56 ` Sumit Garg 2019-07-09 7:03 ` Jens Wiklander 2019-07-09 7:03 ` Jens Wiklander 2019-07-09 9:36 ` Sumit Garg 2019-07-09 9:48 ` Sumit Garg 2019-07-29 7:08 ` Jens Wiklander 2019-07-29 7:08 ` Jens Wiklander 2019-07-29 13:13 ` Sumit Garg 2019-07-29 13:25 ` Sumit Garg 2019-06-13 10:30 ` [RFC 4/7] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg 2019-06-13 10:42 ` Sumit Garg 2019-06-13 15:32 ` Jarkko Sakkinen 2019-06-13 15:32 ` Jarkko Sakkinen 2019-06-14 5:43 ` Sumit Garg 2019-06-14 5:55 ` Sumit Garg 2019-06-13 10:30 ` [RFC 5/7] KEYS: encrypted: Allow TEE based trusted master keys Sumit Garg 2019-06-13 10:42 ` Sumit Garg 2019-06-13 10:30 ` [RFC 6/7] doc: keys: Document usage of TEE based Trusted Keys Sumit Garg 2019-06-13 10:42 ` Sumit Garg 2019-06-13 15:34 ` Jarkko Sakkinen 2019-06-13 15:34 ` Jarkko Sakkinen 2019-06-14 5:37 ` Sumit Garg 2019-06-14 5:49 ` Sumit Garg 2019-06-14 15:36 ` Jarkko Sakkinen 2019-06-14 15:36 ` Jarkko Sakkinen 2019-06-13 10:30 ` [RFC 7/7] MAINTAINERS: Add entry for " Sumit Garg 2019-06-13 10:42 ` Sumit Garg 2019-06-13 16:40 ` [RFC 0/7] Introduce TEE based Trusted Keys support Casey Schaufler 2019-06-13 16:40 ` Casey Schaufler 2019-06-14 0:03 ` Mimi Zohar [this message] 2019-06-14 0:03 ` Mimi Zohar 2019-06-14 8:17 ` Sumit Garg 2019-06-14 8:29 ` Sumit Garg 2019-06-14 5:58 ` Sumit Garg 2019-06-14 5:58 ` Sumit Garg 2019-07-08 12:41 ` Sumit Garg 2019-07-08 12:53 ` Sumit Garg 2019-07-08 16:31 ` Jens Wiklander 2019-07-08 16:31 ` Jens Wiklander 2019-07-09 5:58 ` Sumit Garg 2019-07-09 5:59 ` Sumit Garg
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1560470593.4805.109.camel@linux.ibm.com \ --to=zohar@linux.ibm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=casey@schaufler-ca.com \ --cc=corbet@lwn.net \ --cc=daniel.thompson@linaro.org \ --cc=dhowells@redhat.com \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=jejb@linux.ibm.com \ --cc=jens.wiklander@linaro.org \ --cc=jmorris@namei.org \ --cc=keyrings@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=serge@hallyn.com \ --cc=sumit.garg@linaro.org \ --cc=tee-dev@lists.linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.