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

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

[Mimi Zohar]

From: Elaine Palmer <erpalmer@us.ibm.com>

Update trusted key documentation with additional comparisons between
discrete TPMs and TEE.

Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
---
 .../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.
+
+
+  *  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

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

[Jarkko Sakkinen]

On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
> From: Elaine Palmer <erpalmer@us.ibm.com>
> 
> Update trusted key documentation with additional comparisons between
> discrete TPMs and TEE.
> 
> Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>

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.

> +
> +
> +  *  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

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

[Mimi Zohar]

[Response from Zohargshu Gu <zgu@us.ibm.com>, Elaine Palmer <
erpalmer@us.ibm.com>]

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@us.ibm.com>
> > 
> > Update trusted key documentation with additional comparisons between
> > discrete TPMs and TEE.
> > 
> > Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
> 
> 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

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

[Sumit Garg]

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 <zohar@linux.ibm.com> wrote:
>
> From: Elaine Palmer <erpalmer@us.ibm.com>
>
> 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.

>
> Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
> ---
>  .../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

> +
> +  *  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
>

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

[Sumit Garg]

Hi Jarkko,

On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
> > From: Elaine Palmer <erpalmer@us.ibm.com>
> >
> > Update trusted key documentation with additional comparisons between
> > discrete TPMs and TEE.
> >
> > Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
>
> 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

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

[Jarkko Sakkinen]

On Mon, Jan 04, 2021 at 05:45:55PM +0530, Sumit Garg wrote:
> 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 <zohar@linux.ibm.com> wrote:
> >
> > From: Elaine Palmer <erpalmer@us.ibm.com>
> >
> > 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.

I agree with this point of view.

I'm also finding hard to understand the reason for the thread model
documentation, i.e. how it connects to the implementation.

/Jarkko

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

[Jarkko Sakkinen]

On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:
> Hi Jarkko,
> 
> On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
> > > From: Elaine Palmer <erpalmer@us.ibm.com>
> > >
> > > Update trusted key documentation with additional comparisons between
> > > discrete TPMs and TEE.
> > >
> > > Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
> >
> > 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.

Right, TEE is a protocol standard, just like TPM, and OP-TEE is one
implementation of this interface? I.e. OP-TEE does not define API
that is hard bound to OP-TEE?

Better to ask the very basic questions out and loud to get this
right.

/Jarkko

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

[Sumit Garg]

On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:
> > Hi Jarkko,
> >
> > On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
> > > > From: Elaine Palmer <erpalmer@us.ibm.com>
> > > >
> > > > Update trusted key documentation with additional comparisons between
> > > > discrete TPMs and TEE.
> > > >
> > > > Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
> > >
> > > 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.
>
> Right, TEE is a protocol standard, just like TPM, and OP-TEE is one
> implementation of this interface? I.e. OP-TEE does not define API
> that is hard bound to OP-TEE?
>

Yes, OP-TEE doesn't define a hard bound client interface API. The
client API is based on TEE client API specification [1] from
GlobalPlatform.

[1] http://globalplatform.org/specs-library/tee-client-api-specification/

-Sumit

> Better to ask the very basic questions out and loud to get this
> right.
>
> /Jarkko

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

[Jarkko Sakkinen]

On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote:
> On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:
> > > Hi Jarkko,
> > >
> > > On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >
> > > > On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
> > > > > From: Elaine Palmer <erpalmer@us.ibm.com>
> > > > >
> > > > > Update trusted key documentation with additional comparisons between
> > > > > discrete TPMs and TEE.
> > > > >
> > > > > Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
> > > >
> > > > 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.
> >
> > Right, TEE is a protocol standard, just like TPM, and OP-TEE is one
> > implementation of this interface? I.e. OP-TEE does not define API
> > that is hard bound to OP-TEE?
> >
> 
> Yes, OP-TEE doesn't define a hard bound client interface API. The
> client API is based on TEE client API specification [1] from
> GlobalPlatform.
> 
> [1] http://globalplatform.org/specs-library/tee-client-api-specification/
> 
> -Sumit

Thanks, bookmarked. No need for name change.

/Jarkko

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

[Elaine Palmer]

On 1/13/21 4:23 PM, Jarkko Sakkinen wrote:
> On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote:
>> On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>>> On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:
>>>> Hi Jarkko, On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen 
>>>> <jarkko@kernel.org> wrote:
>>>>> On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
>>>>>> From: Elaine Palmer <erpalmer@us.ibm.com> Update trusted key 
>>>>>> documentation with additional comparisons between discrete TPMs 
>>>>>> and TEE. Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com> 
>>>>> 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. 
>>> Right, TEE is a protocol standard, just like TPM, and OP-TEE is one 
>>> implementation of this interface? I.e. OP-TEE does not define API 
>>> that is hard bound to OP-TEE? 
>> Yes, OP-TEE doesn't define a hard bound client interface API. The 
>> client API is based on TEE client API specification [1] from 
>> GlobalPlatform. [1] 
>> http://globalplatform.org/specs-library/tee-client-api-specification/ 
>> -Sumit 
> Thanks, bookmarked. No need for name change. /Jarkko 
This discussion has illustrated that even those of us who live and
breathe this stuff could use clarification.  Shouldn't we recommend
that the Trust Source have a hardware root of trust?  We could be
even more specific.  For example, the documentation could recommend
that a TPM be evaluated under "TCG Protection Profile for PC Client
Specific TPM 2.0" or later and a TEE be evaluated under GlobalPlatform
"TEE Protection Profile v1.3, GPD_SPE_021" or later.  Of course, our
recommendation would not be a requirement, but it would provide
guidance for deployment as well as precedent for future Trust Sources.

I know where I'm getting stuck is on TEEs as a concept vs
TEEs with specific hardware requirements and interfaces.
The same applies to TPMs.  There are hardware TPMs that meet
the protection profile and there are other implementations
(e.g., vTPMs) that use the same interface, but aren't anchored in
hardware.

I know if I were deploying a server, mobile device, or IoT device, I'd
want to know exactly what is protecting my keys.  A generic TPM or TEE
doesn't tell me enough.

-Elaine

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

[Sumit Garg]

Hi Elaine,

On Sat, 16 Jan 2021 at 04:45, Elaine Palmer <erpalmerny@gmail.com> wrote:
>
>
>
> On 1/13/21 4:23 PM, Jarkko Sakkinen wrote:
> > On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote:
> >> On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>> On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:
> >>>> Hi Jarkko, On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen
> >>>> <jarkko@kernel.org> wrote:
> >>>>> On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
> >>>>>> From: Elaine Palmer <erpalmer@us.ibm.com> Update trusted key
> >>>>>> documentation with additional comparisons between discrete TPMs
> >>>>>> and TEE. Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
> >>>>> 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.
> >>> Right, TEE is a protocol standard, just like TPM, and OP-TEE is one
> >>> implementation of this interface? I.e. OP-TEE does not define API
> >>> that is hard bound to OP-TEE?
> >> Yes, OP-TEE doesn't define a hard bound client interface API. The
> >> client API is based on TEE client API specification [1] from
> >> GlobalPlatform. [1]
> >> http://globalplatform.org/specs-library/tee-client-api-specification/
> >> -Sumit
> > Thanks, bookmarked. No need for name change. /Jarkko
> This discussion has illustrated that even those of us who live and
> breathe this stuff could use clarification.  Shouldn't we recommend
> that the Trust Source have a hardware root of trust?  We could be
> even more specific.  For example, the documentation could recommend
> that a TPM be evaluated under "TCG Protection Profile for PC Client
> Specific TPM 2.0" or later and a TEE be evaluated under GlobalPlatform
> "TEE Protection Profile v1.3, GPD_SPE_021" or later.  Of course, our
> recommendation would not be a requirement, but it would provide
> guidance for deployment as well as precedent for future Trust Sources.
>

Sure, I will update documentation to mention this as a recommendation.

> I know where I'm getting stuck is on TEEs as a concept vs
> TEEs with specific hardware requirements and interfaces.
> The same applies to TPMs.  There are hardware TPMs that meet
> the protection profile and there are other implementations
> (e.g., vTPMs) that use the same interface, but aren't anchored in
> hardware.

Similar is the case with TEEs which can have varying hardware
realizations. Have a look at "Figure 2-3: Example Hardware
Realizations of TEE" from TEE system architecture specification [1].

[1] https://globalplatform.org/specs-library/tee-system-architecture-v1-2/

>
> I know if I were deploying a server, mobile device, or IoT device, I'd
> want to know exactly what is protecting my keys.  A generic TPM or TEE
> doesn't tell me enough.
>

Agree.

-Sumit

> -Elaine
>
>

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

[Jarkko Sakkinen]

On Fri, Jan 15, 2021 at 06:15:51PM -0500, Elaine Palmer wrote:
> 
> 
> On 1/13/21 4:23 PM, Jarkko Sakkinen wrote:
> > On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote:
> > > On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:
> > > > > Hi Jarkko, On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen
> > > > > <jarkko@kernel.org> wrote:
> > > > > > On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
> > > > > > > From: Elaine Palmer <erpalmer@us.ibm.com> Update
> > > > > > > trusted key documentation with additional
> > > > > > > comparisons between discrete TPMs and TEE.
> > > > > > > Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
> > > > > > 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.
> > > > Right, TEE is a protocol standard, just like TPM, and OP-TEE is
> > > > one implementation of this interface? I.e. OP-TEE does not
> > > > define API that is hard bound to OP-TEE?
> > > Yes, OP-TEE doesn't define a hard bound client interface API. The
> > > client API is based on TEE client API specification [1] from
> > > GlobalPlatform. [1]
> > > http://globalplatform.org/specs-library/tee-client-api-specification/
> > > -Sumit
> > Thanks, bookmarked. No need for name change. /Jarkko
> This discussion has illustrated that even those of us who live and
> breathe this stuff could use clarification.  Shouldn't we recommend
> that the Trust Source have a hardware root of trust?  We could be
> even more specific.  For example, the documentation could recommend
> that a TPM be evaluated under "TCG Protection Profile for PC Client
> Specific TPM 2.0" or later and a TEE be evaluated under GlobalPlatform
> "TEE Protection Profile v1.3, GPD_SPE_021" or later.  Of course, our
> recommendation would not be a requirement, but it would provide
> guidance for deployment as well as precedent for future Trust Sources.

Recommend what? Not following. I don't undestand what recommending
trust sources means, and why it's written as Trust Sources.

/Jarkko

> I know where I'm getting stuck is on TEEs as a concept vs
> TEEs with specific hardware requirements and interfaces.
> The same applies to TPMs.  There are hardware TPMs that meet
> the protection profile and there are other implementations
> (e.g., vTPMs) that use the same interface, but aren't anchored in
> hardware.
> 
> I know if I were deploying a server, mobile device, or IoT device, I'd
> want to know exactly what is protecting my keys.  A generic TPM or TEE
> doesn't tell me enough.
> 
> -Elaine
> 
> 
> 

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

[Jarkko Sakkinen]

On Wed, Jan 20, 2021 at 04:21:54PM +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 15, 2021 at 06:15:51PM -0500, Elaine Palmer wrote:
> > 
> > 
> > On 1/13/21 4:23 PM, Jarkko Sakkinen wrote:
> > > On Tue, Jan 12, 2021 at 10:55:44AM +0530, Sumit Garg wrote:
> > > > On Sun, 10 Jan 2021 at 08:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > On Mon, Jan 04, 2021 at 06:06:33PM +0530, Sumit Garg wrote:
> > > > > > Hi Jarkko, On Fri, 11 Dec 2020 at 13:44, Jarkko Sakkinen
> > > > > > <jarkko@kernel.org> wrote:
> > > > > > > On Wed, Dec 09, 2020 at 11:42:49AM -0500, Mimi Zohar wrote:
> > > > > > > > From: Elaine Palmer <erpalmer@us.ibm.com> Update
> > > > > > > > trusted key documentation with additional
> > > > > > > > comparisons between discrete TPMs and TEE.
> > > > > > > > Signed-off-by: Elaine Palmer <erpalmer@us.ibm.com>
> > > > > > > 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.
> > > > > Right, TEE is a protocol standard, just like TPM, and OP-TEE is
> > > > > one implementation of this interface? I.e. OP-TEE does not
> > > > > define API that is hard bound to OP-TEE?
> > > > Yes, OP-TEE doesn't define a hard bound client interface API. The
> > > > client API is based on TEE client API specification [1] from
> > > > GlobalPlatform. [1]
> > > > http://globalplatform.org/specs-library/tee-client-api-specification/
> > > > -Sumit
> > > Thanks, bookmarked. No need for name change. /Jarkko
> > This discussion has illustrated that even those of us who live and
> > breathe this stuff could use clarification.  Shouldn't we recommend
> > that the Trust Source have a hardware root of trust?  We could be
> > even more specific.  For example, the documentation could recommend
> > that a TPM be evaluated under "TCG Protection Profile for PC Client
> > Specific TPM 2.0" or later and a TEE be evaluated under GlobalPlatform
> > "TEE Protection Profile v1.3, GPD_SPE_021" or later.  Of course, our
> > recommendation would not be a requirement, but it would provide
> > guidance for deployment as well as precedent for future Trust Sources.
> 
> Recommend what? Not following. I don't undestand what recommending
> trust sources means, and why it's written as Trust Sources.

I don't even understand what "evaluating TPM" means. Does not sound
like anything that belongs to the kernel documentation.

/Jarkko