[Response from Zohargshu Gu <zgu@xxxxxxxxxx>, Elaine Palmer < erpalmer@xxxxxxxxxx>] On Fri, 2020-12-11 at 10:14 +0200, Jarkko Sakkinen 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 essentially means that the backend needs to be renamed as "op_tee". > > 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. Thanks Jarkko for the response. The other suggestion we have is with regard to the "on-chip versus off-chip" section. TPM can have different implementations. That section only covers the traditional discrete TPMs. However, TPM can also be an independent chip packaged with processor, e.g., Microsoft Pluton. TPM can also be implemented in system firmware, e.g., Intel Platform Trust Technology (PTT). We suggest renaming this section "Packaging and integration" to cover multiple chips, removable daughter cards, multi-chip modules, discrete TPMs, fTPMs, exposed buses, etc. Thank you. Zhongshu, Elaine
