Thread (13 messages) 13 messages, 4 authors, 2021-01-20

Re: [PATCH] doc: trusted-encrypted: updates with TEE as a new trust source (update)

From: Sumit Garg <hidden>
Date: 2021-01-04 12:16:56

Hi Mimi and Elaine,

Apologies for my delayed reply as I was busy with other high priority work.

On Wed, 9 Dec 2020 at 22:14, Mimi Zohar [off-list ref] wrote:
From: Elaine Palmer <redacted>

Update trusted key documentation with additional comparisons between
discrete TPMs and TEE.
Isn't this additional comparison limited to a particular type of TPM
(discrete TPMs) and ignored other TPM implementations (virtual TPM,
firmware TPM etc.)? I think your later comment about on-chip versus
off-chip points at these missing pieces as well.

I would rather suggest comparing TPM and TEE on the basis of
interfaces and implementation guidelines provided by corresponding
standards as I think this is the most relevant part to the kernel.
quoted hunk ↗ jump to hunk
Signed-off-by: Elaine Palmer <redacted>
---
 .../security/keys/trusted-encrypted.rst       | 73 +++++++++++++++++--
 1 file changed, 65 insertions(+), 8 deletions(-)
diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 16042c8ff8ae..90c02105ab89 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -14,12 +14,14 @@ convenience, and are integrity verified.
 Trust Source
 ============

-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:
+A trust source provides the source of security for Trusted Keys.  This
+section lists currently supported trust sources, along with their security
+considerations.  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.

   *  Root of trust for storage
@@ -116,6 +118,59 @@ guarantees:
          Provides no protection by itself, relies on the underlying platform for
          features such as tamper resistance.

+  *  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"
+
+     (2) TEE
+
+         A protection profile for TEEs does not yet exist.
Really? Have a look here [1].

[1] https://globalplatform.org/specs-library/tee-protection-profile-v1-3/#
 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.
+
Kernel interface to TEE is based on the standardized TEE client API
specification from GlobalPlatform [2].

[2] https://globalplatform.org/specs-library/tee-client-api-specification/

-Sumit
quoted hunk ↗ jump to hunk
+
+  *  Threat model
+
+     The strength and appropriateness of a particular TPM or TEE for a given
+     purpose must be assessed when using them to protect security-relevant data.
+

 Key Generation
 ==============
@@ -123,8 +178,10 @@ 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.

   *  TPM (hardware device) based RNG

--
2.18.4
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help