mbox series

[RFC,0/7] Introduce TEE based Trusted Keys support

Message ID 1560421833-27414-1-git-send-email-sumit.garg@linaro.org
Headers show
Series Introduce TEE based Trusted Keys support | expand

Message

Sumit Garg June 13, 2019, 10:30 a.m. UTC
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:

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.

[1] https://github.com/OP-TEE/optee_os/pull/3082

Sumit Garg (7):
  tee: optee: allow kernel pages to register as shm
  tee: enable support to register kernel memory
  tee: add private login method for kernel clients
  KEYS: trusted: Introduce TEE based Trusted Keys
  KEYS: encrypted: Allow TEE based trusted master keys
  doc: keys: Document usage of TEE based Trusted Keys
  MAINTAINERS: Add entry for TEE based Trusted Keys

 Documentation/security/keys/tee-trusted.rst      |  93 +++++
 MAINTAINERS                                      |   9 +
 drivers/tee/optee/call.c                         |   7 +
 drivers/tee/tee_core.c                           |   6 +
 drivers/tee/tee_shm.c                            |  16 +-
 include/keys/tee_trusted.h                       |  84 ++++
 include/keys/trusted-type.h                      |   1 +
 include/linux/tee_drv.h                          |   1 +
 include/uapi/linux/tee.h                         |   2 +
 security/keys/Kconfig                            |   3 +
 security/keys/Makefile                           |   3 +
 security/keys/encrypted-keys/masterkey_trusted.c |  10 +-
 security/keys/tee_trusted.c                      | 506 +++++++++++++++++++++++
 13 files changed, 737 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/security/keys/tee-trusted.rst
 create mode 100644 include/keys/tee_trusted.h
 create mode 100644 security/keys/tee_trusted.c

-- 
2.7.4

Comments

Casey Schaufler June 13, 2019, 4:40 p.m. UTC | #1
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.

>

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

>

> [1] https://github.com/OP-TEE/optee_os/pull/3082

>

> Sumit Garg (7):

>   tee: optee: allow kernel pages to register as shm

>   tee: enable support to register kernel memory

>   tee: add private login method for kernel clients

>   KEYS: trusted: Introduce TEE based Trusted Keys

>   KEYS: encrypted: Allow TEE based trusted master keys

>   doc: keys: Document usage of TEE based Trusted Keys

>   MAINTAINERS: Add entry for TEE based Trusted Keys

>

>  Documentation/security/keys/tee-trusted.rst      |  93 +++++

>  MAINTAINERS                                      |   9 +

>  drivers/tee/optee/call.c                         |   7 +

>  drivers/tee/tee_core.c                           |   6 +

>  drivers/tee/tee_shm.c                            |  16 +-

>  include/keys/tee_trusted.h                       |  84 ++++

>  include/keys/trusted-type.h                      |   1 +

>  include/linux/tee_drv.h                          |   1 +

>  include/uapi/linux/tee.h                         |   2 +

>  security/keys/Kconfig                            |   3 +

>  security/keys/Makefile                           |   3 +

>  security/keys/encrypted-keys/masterkey_trusted.c |  10 +-

>  security/keys/tee_trusted.c                      | 506 +++++++++++++++++++++++

>  13 files changed, 737 insertions(+), 4 deletions(-)

>  create mode 100644 Documentation/security/keys/tee-trusted.rst

>  create mode 100644 include/keys/tee_trusted.h

>  create mode 100644 security/keys/tee_trusted.c

>
Mimi Zohar June 14, 2019, 12:03 a.m. UTC | #2
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.
Sumit Garg June 14, 2019, 5:58 a.m. UTC | #3
On Thu, 13 Jun 2019 at 22:10, Casey Schaufler <casey@schaufler-ca.com> 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.

>


Sure will take care of this. BTW, its Trusted Execution Environment (TEE).

-Sumit

> >

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

> >

> > [1] https://github.com/OP-TEE/optee_os/pull/3082

> >

> > Sumit Garg (7):

> >   tee: optee: allow kernel pages to register as shm

> >   tee: enable support to register kernel memory

> >   tee: add private login method for kernel clients

> >   KEYS: trusted: Introduce TEE based Trusted Keys

> >   KEYS: encrypted: Allow TEE based trusted master keys

> >   doc: keys: Document usage of TEE based Trusted Keys

> >   MAINTAINERS: Add entry for TEE based Trusted Keys

> >

> >  Documentation/security/keys/tee-trusted.rst      |  93 +++++

> >  MAINTAINERS                                      |   9 +

> >  drivers/tee/optee/call.c                         |   7 +

> >  drivers/tee/tee_core.c                           |   6 +

> >  drivers/tee/tee_shm.c                            |  16 +-

> >  include/keys/tee_trusted.h                       |  84 ++++

> >  include/keys/trusted-type.h                      |   1 +

> >  include/linux/tee_drv.h                          |   1 +

> >  include/uapi/linux/tee.h                         |   2 +

> >  security/keys/Kconfig                            |   3 +

> >  security/keys/Makefile                           |   3 +

> >  security/keys/encrypted-keys/masterkey_trusted.c |  10 +-

> >  security/keys/tee_trusted.c                      | 506 +++++++++++++++++++++++

> >  13 files changed, 737 insertions(+), 4 deletions(-)

> >  create mode 100644 Documentation/security/keys/tee-trusted.rst

> >  create mode 100644 include/keys/tee_trusted.h

> >  create mode 100644 security/keys/tee_trusted.c

> >
Sumit Garg June 14, 2019, 8:17 a.m. UTC | #4
Thanks Mimi for your comments.

On Fri, 14 Jun 2019 at 05:33, Mimi Zohar <zohar@linux.ibm.com> wrote:
>

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

>


Thanks for pointing this out. I will update documentation to include
TEE bus approach and communication apis for kernel clients.

BTW, the interface is similar as with user-space. Only difference is
instead of IOCTL's from user-space, there are wrapper apis to
communicate with TEE.

Also, in case someone is interested to learn about TEE technology,
this webinar [1] could be one of starting points.

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


Understood.

>  In the tee case, can the "sealing" key ever leave the tee?


No, the "sealing" key never leaves TEE. Its basically a Hardware
Unique Key (HUK) tied to a particular SoC.

>  Can the

> sealed, trusted key, exported to userspace, be unsealed by the tee?


You mean using user-space interface to TEE? If yes, then answer is
"no" as user-space can't communicate with this TEE service as its
accessible to kernel clients only (see patch [2]).

In case you meant loading exported trusted key blob via "keyctl", then
"yes" this driver can unseal the trusted key. Have a look at examples
I have listed in documentation patch [3]. Also, this approach works
well across power cycles too.

>  Are the tee security protections similar to those of the TPM?  How do

> they compare?

>


Let me try to compare both environments. Regarding TEE, I will refer
to OP-TEE [4] as one of its implementation.

TPM:

1. External hardware.
2. Sealing key resides inside TPM.
3. Communicates via SPI, I2C etc.

OP-TEE:

1. On chip, trusted execution environment enforced via ARM TrustZone.
2. Sealing key is unique to a particular SoC provided by secure fuses,
secure crypto engine etc.
3. Communicates via Secure Monitor Calls (SMCs [5]).

[1] https://globalplatform.org/resource-publication/webinar-an-introduction-to-tee-technology/
[2] [RFC 3/7] tee: add private login method for kernel clients
[3] [RFC 6/7] doc: keys: Document usage of TEE based Trusted Keys
[4] https://optee.readthedocs.io/general/about.html
[5] http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf


-Sumit

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

>
Sumit Garg July 8, 2019, 12:41 p.m. UTC | #5
Hi Jens,

On Thu, 13 Jun 2019 at 16:01, Sumit Garg <sumit.garg@linaro.org> 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:

>

> Patch #1, #2 enables support for registered kernel shared memory with TEE.

>


Would you like to pick up Patch #1, #2 separately? I think both these
patches add independent functionality and also got reviewed-by tags
too.


-Sumit

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

>

> [1] https://github.com/OP-TEE/optee_os/pull/3082

>

> Sumit Garg (7):

>   tee: optee: allow kernel pages to register as shm

>   tee: enable support to register kernel memory

>   tee: add private login method for kernel clients

>   KEYS: trusted: Introduce TEE based Trusted Keys

>   KEYS: encrypted: Allow TEE based trusted master keys

>   doc: keys: Document usage of TEE based Trusted Keys

>   MAINTAINERS: Add entry for TEE based Trusted Keys

>

>  Documentation/security/keys/tee-trusted.rst      |  93 +++++

>  MAINTAINERS                                      |   9 +

>  drivers/tee/optee/call.c                         |   7 +

>  drivers/tee/tee_core.c                           |   6 +

>  drivers/tee/tee_shm.c                            |  16 +-

>  include/keys/tee_trusted.h                       |  84 ++++

>  include/keys/trusted-type.h                      |   1 +

>  include/linux/tee_drv.h                          |   1 +

>  include/uapi/linux/tee.h                         |   2 +

>  security/keys/Kconfig                            |   3 +

>  security/keys/Makefile                           |   3 +

>  security/keys/encrypted-keys/masterkey_trusted.c |  10 +-

>  security/keys/tee_trusted.c                      | 506 +++++++++++++++++++++++

>  13 files changed, 737 insertions(+), 4 deletions(-)

>  create mode 100644 Documentation/security/keys/tee-trusted.rst

>  create mode 100644 include/keys/tee_trusted.h

>  create mode 100644 security/keys/tee_trusted.c

>

> --

> 2.7.4

>
Jens Wiklander July 8, 2019, 4:31 p.m. UTC | #6
Hi Sumit,

On Mon, Jul 08, 2019 at 06:11:39PM +0530, Sumit Garg wrote:
> Hi Jens,

> 

> On Thu, 13 Jun 2019 at 16:01, Sumit Garg <sumit.garg@linaro.org> 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:

> >

> > Patch #1, #2 enables support for registered kernel shared memory with TEE.

> >

> 

> Would you like to pick up Patch #1, #2 separately? I think both these

> patches add independent functionality and also got reviewed-by tags

> too.


I think it makes more sense to keep them together in the same patch
series or could end up with dependencies between trees.

If you don't think dependencies will be an issue then I don't mind
picking them up, in that case they'd likely sit in an arm-soc branch
until next merge window. However, I think that #3 (support for private
kernel login method) should be included too and that one isn't ready
yet.

Thanks,
Jens

> 

> 

> -Sumit

> 

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

> >

> > [1] https://github.com/OP-TEE/optee_os/pull/3082

> >

> > Sumit Garg (7):

> >   tee: optee: allow kernel pages to register as shm

> >   tee: enable support to register kernel memory

> >   tee: add private login method for kernel clients

> >   KEYS: trusted: Introduce TEE based Trusted Keys

> >   KEYS: encrypted: Allow TEE based trusted master keys

> >   doc: keys: Document usage of TEE based Trusted Keys

> >   MAINTAINERS: Add entry for TEE based Trusted Keys

> >

> >  Documentation/security/keys/tee-trusted.rst      |  93 +++++

> >  MAINTAINERS                                      |   9 +

> >  drivers/tee/optee/call.c                         |   7 +

> >  drivers/tee/tee_core.c                           |   6 +

> >  drivers/tee/tee_shm.c                            |  16 +-

> >  include/keys/tee_trusted.h                       |  84 ++++

> >  include/keys/trusted-type.h                      |   1 +

> >  include/linux/tee_drv.h                          |   1 +

> >  include/uapi/linux/tee.h                         |   2 +

> >  security/keys/Kconfig                            |   3 +

> >  security/keys/Makefile                           |   3 +

> >  security/keys/encrypted-keys/masterkey_trusted.c |  10 +-

> >  security/keys/tee_trusted.c                      | 506 +++++++++++++++++++++++

> >  13 files changed, 737 insertions(+), 4 deletions(-)

> >  create mode 100644 Documentation/security/keys/tee-trusted.rst

> >  create mode 100644 include/keys/tee_trusted.h

> >  create mode 100644 security/keys/tee_trusted.c

> >

> > --

> > 2.7.4

> >
Sumit Garg July 9, 2019, 5:58 a.m. UTC | #7
On Mon, 8 Jul 2019 at 22:01, Jens Wiklander <jens.wiklander@linaro.org> wrote:
>

> Hi Sumit,

>

> On Mon, Jul 08, 2019 at 06:11:39PM +0530, Sumit Garg wrote:

> > Hi Jens,

> >

> > On Thu, 13 Jun 2019 at 16:01, Sumit Garg <sumit.garg@linaro.org> 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:

> > >

> > > Patch #1, #2 enables support for registered kernel shared memory with TEE.

> > >

> >

> > Would you like to pick up Patch #1, #2 separately? I think both these

> > patches add independent functionality and also got reviewed-by tags

> > too.

>

> I think it makes more sense to keep them together in the same patch

> series or could end up with dependencies between trees.

>


I understand your point. Let me keep this patch-set together to avoid
any dependencies.

-Sumit

> If you don't think dependencies will be an issue then I don't mind

> picking them up, in that case they'd likely sit in an arm-soc branch

> until next merge window. However, I think that #3 (support for private

> kernel login method) should be included too and that one isn't ready

> yet.

>

> Thanks,

> Jens

>

> >

> >

> > -Sumit

> >

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

> > >

> > > [1] https://github.com/OP-TEE/optee_os/pull/3082

> > >

> > > Sumit Garg (7):

> > >   tee: optee: allow kernel pages to register as shm

> > >   tee: enable support to register kernel memory

> > >   tee: add private login method for kernel clients

> > >   KEYS: trusted: Introduce TEE based Trusted Keys

> > >   KEYS: encrypted: Allow TEE based trusted master keys

> > >   doc: keys: Document usage of TEE based Trusted Keys

> > >   MAINTAINERS: Add entry for TEE based Trusted Keys

> > >

> > >  Documentation/security/keys/tee-trusted.rst      |  93 +++++

> > >  MAINTAINERS                                      |   9 +

> > >  drivers/tee/optee/call.c                         |   7 +

> > >  drivers/tee/tee_core.c                           |   6 +

> > >  drivers/tee/tee_shm.c                            |  16 +-

> > >  include/keys/tee_trusted.h                       |  84 ++++

> > >  include/keys/trusted-type.h                      |   1 +

> > >  include/linux/tee_drv.h                          |   1 +

> > >  include/uapi/linux/tee.h                         |   2 +

> > >  security/keys/Kconfig                            |   3 +

> > >  security/keys/Makefile                           |   3 +

> > >  security/keys/encrypted-keys/masterkey_trusted.c |  10 +-

> > >  security/keys/tee_trusted.c                      | 506 +++++++++++++++++++++++

> > >  13 files changed, 737 insertions(+), 4 deletions(-)

> > >  create mode 100644 Documentation/security/keys/tee-trusted.rst

> > >  create mode 100644 include/keys/tee_trusted.h

> > >  create mode 100644 security/keys/tee_trusted.c

> > >

> > > --

> > > 2.7.4

> > >