Add support for TEE based trusted keys where TEE provides the functionality
to seal and unseal trusted keys using hardware unique key. Also, this is
an alternative in case platform doesn't possess a TPM device.
This patch-set has been tested with OP-TEE based early TA which can be
found here .
Changes in v4:
1. Pushed independent TEE features separately:
- Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062
2. Updated trusted-encrypted doc with TEE as a new trust source.
3. Rebased onto latest tpmdd/master.
Changes in v3:
1. Update patch #2 to support registration of multiple kernel pages.
2. Incoporate dependency patch #4 in this patch-set:
Changes in v2:
1. Add reviewed-by tags for patch #1 and #2.
2. Incorporate comments from Jens for patch #3.
3. Switch to use generic trusted keys framework.
Sumit Garg (4):
KEYS: trusted: Add generic trusted keys framework
KEYS: trusted: Introduce TEE based Trusted Keys
doc: trusted-encrypted: updates with TEE as a new trust source
MAINTAINERS: Add entry for TEE based Trusted Keys
Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++---
MAINTAINERS | 8 +
include/keys/trusted-type.h | 48 ++++
include/keys/trusted_tee.h | 66 +++++
include/keys/trusted_tpm.h | 15 -
security/keys/Kconfig | 3 +
security/keys/trusted-keys/Makefile | 2 +
security/keys/trusted-keys/trusted_common.c | 336 ++++++++++++++++++++++
security/keys/trusted-keys/trusted_tee.c | 282 ++++++++++++++++++
security/keys/trusted-keys/trusted_tpm1.c | 335 ++++-----------------
10 files changed, 974 insertions(+), 324 deletions(-)
create mode 100644 include/keys/trusted_tee.h
create mode 100644 security/keys/trusted-keys/trusted_common.c
create mode 100644 security/keys/trusted-keys/trusted_tee.c
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
We're about to make another OP-TEE release, namely: 3.9.0. Target is
Friday, May 22th which leaves us almost 3 weeks to finalize the
Please start testing your favorite platform(s) and report any issue in
this pull request . I will create a release candidate tag one week
before the release date, at which point we will do some more testing and
I will collect Tested-by tags in the same pull request.
TEE Client API defines that from user space only information needed for
specified login operations is group identifier for group based logins.
REE kernel is expected to formulate trustworthy client UUID and pass that
to TEE environment. REE kernel is required to verify that provided group
identifier for group based logins matches calling processes group
TEE specification only defines that the information passed from REE
environment to TEE environment is encoded into on UUID.
In order to guarantee trustworthiness of client UUID user space is not
allowed to freely pass client UUID.
Vesa Jääskeläinen (3):
tee: add support for session's client UUID generation
tee: optee: Add support for session login client UUID generation
[RFC] tee: add support for app id for client UUID generation
drivers/tee/Kconfig | 1 +
drivers/tee/optee/call.c | 6 +-
drivers/tee/tee_core.c | 211 +++++++++++++++++++++++++++++++++++++++
include/linux/tee_drv.h | 16 +++
4 files changed, 233 insertions(+), 1 deletion(-)
* Changed goto labels to be more logical
* Capture error if formatted string for UUIDv5 does not fit into buffer
This patcheset has been designed so that it can be iteratively intergrated
meaning that the application ID (RFC patch) part can be left for later when
there is agreed solution for that.
TEE specification leaves Linux behavior undefined. It does not define any
UUID value for name space. UUID in here is randomly generated with uuidgen
I have also include amdtee people as this method probably should also be
applied in there.
Using op-tee(a)lists.trustedfirmware.org instead of tee-dev(a)lists.linaro.org as
latter is deprecated old list.
Original issue in OP-TEE OS tracker:
Related reviews and demonstration for the concept: