Hi Jarkko, On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote: > > From: Elaine Palmer <erpalmer@xxxxxxxxxx> > > > > Update trusted key documentation with additional comparisons between > > discrete TPMs and TEE. > > > > Signed-off-by: Elaine Palmer <erpalmer@xxxxxxxxxx> > > Right, so OP-TEE is not the same as TEE. I did not know this and the > patch set does not underline this. > > I re-checked the patches and none of them say explicitly that OP-TEE > is an application living inside TEE. This patch-set provides a trust source based on generic TEE interface where underlying TEE implementations like OP-TEE (drivers/tee/optee/), AMD TEE (drivers/tee/amdtee/) etc. can easily be hooked up. And this is similar to the TPM interface where underlying TPM implementations like discrete TPM, virtual TPM, firmware TPM etc. can be easily hooked up. > > This essentially means that the backend needs to be renamed as "op_tee". > I don't see any need for this, see above. > All patches need to be rewritten according to this. > > > > --- > > .../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. 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. > > Comparing TPM and TEE does not make logically any sense given that TPM > is application and TEE a platfrom. > I think comparing them on the basis of standardized interfaces to trust source and common platform security features does make sense. -Sumit > > + > > + > > + * 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 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 > > > > > > /Jarkko
