Subject: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

From: "Wheeler, David M" <[email-masked]>
Date: Thu, 5 Jul 2018 19:37:50 +0000

I have several comments on the new architecture draft.

The first comment has to do with the definition of the "Trust Anchor" (page 4)

The definition states:
Trust Anchor: A root certificate that can be used to validate its
                            certificates. It is usually embedded in a device or
                            configured by a TAM for validating the trust of a remote entity's
                            certificate.

Then later in section 3 (page 6)
This specification assumes that an applicable device is equipped with
 one or more TEEs and each TEE is pre-provisioned with a device-unique
 public/private key pair, which is securely stored. This key pair is
 referred to as the 'root of trust' for remote attestation of the
 associated TEE in a device by an TAM.

It is not clear whether the "Trust Anchor" is the same as the "root-of-trust" key pair, since the "root-of-trust" is not included in the definitions.

If they are intended to be different (which is what I believe), then I suggest we add the "root-of-trust" to the definitions, and explain the difference. Oftentimes, in my experience, these terms are used interchangeably.

Here is my attempt to create definitions for these two types of keys:

Trust Anchor: A trust anchor is public asymmetric key, preferably contained in a certificate 
                            that represents a trusted entity to a device. This public key may be used by 
                            the holder of the corresponding private key to sign other certificates,
                            thereby communicating the signed certificate may also be trusted. 
                            The trust anchor is usually embedded in a device or configured by a TAM 
                             and used by the device to validate the trust of a remote entity by
                            verifying that entity's certificate is signed by a trust anchor.
                             Trust anchors must be stored in a way that prevents or strongly resists
                             modification by unauthorized software and hardware adversaries.
	          An example of a trust anchor is the public key of a TAM or SP which is 
                          "pinned" or securely stored inside the device, and that trust anchor is used 
                            like a CA certificate to validate the trust in other keys/certificates.
                           A trust anchor may be viewed by both trusted and untrusted entities on the device,
                          But may only be modified or deleted by a trusted entity.

Root-of-Trust Key:  A device-unique key generated at device manufacturing or at
                            TEE provisioning, which is securely stored and only accessible to the TEE.
                            The Root-of-Trust Key is used for attestation signing which proves the signed
                            message originated or was approved by the TEE, and may be trusted to the same
                           degree as the TEE.

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 4, 2018 7:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Teep] I-D Action: draft-ietf-teep-architecture-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Trusted Execution Environment Provisioning WG of the IETF.

        Title           : Trusted Execution Environment Provisioning (TEEP) Architecture
        Authors         : Mingliang Pei
                          Hannes Tschofenig
                          Andrew Atyeo
                          Dapeng
	Filename        : draft-ietf-teep-architecture-00.txt
	Pages           : 24
	Date            : 2018-07-02

Abstract:
   A Trusted Execution Environment (TEE) was designed to provide a
   hardware-isolation mechanism to separate a regular operating system
   from security- sensitive applications.

   This architecture document motivates the design and standardization
   of a protocol for managing the lifecyle of trusted applications
   running inside a TEE.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teep-architecture-00
https://datatracker.ietf.org/doc/html/draft-ietf-teep-architecture-00

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
TEEP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teep

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 5 Jul 2018 19:40:53 +0000

Just a quick remark: IMHO root of trust and trust anchor are the same thing. I believe we should update the text to only talk about trust anchors and forget the root of trust terminology.

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Wheeler, David M
Sent: 05 July 2018 21:38
To: [email-masked]
Subject: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

The definition states:

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 4, 2018 7:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Teep] I-D Action: draft-ietf-teep-architecture-00.txt

Abstract:

_______________________________________________
TEEP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teep
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Wheeler, David M" <[email-masked]>
Date: Thu, 5 Jul 2018 19:51:38 +0000

Hannes,
If that is the case (trust root and trust anchors are the same), then I have a concern regarding crypto separation.
In one definition the Trust Anchor signs certificates, in the other definition a Root-of-Trust signs attestations.
If these are in fact the same key, then they are being used for two different functions, which is not recommended for cryptographic keys.

Further, it seems to me (though I may be misunderstanding the intended function), the private key of the Trust Anchor resides outside the device, in a separate entity, like a CA or a TAM.
However, the private key of a Root-of-Trust resides in the TEE (or is accessible only to the TEE).

Can you pick apart my understanding of the two definitions of keys, and help me understand where I got thrown off?

Thanks,
Dave Wheeler 

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Wheeler, David M
Sent: 05 July 2018 21:38
To: [email-masked]
Subject: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

The definition states:

Then later in section 3 (page 6)
This specification assumes that an applicable device is equipped with  one or more TEEs and each TEE is pre-provisioned with a device-unique  public/private key pair, which is securely stored. This key pair is  referred to as the 'root of trust' for remote attestation of the  associated TEE in a device by an TAM.

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 4, 2018 7:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Teep] I-D Action: draft-ietf-teep-architecture-00.txt

Abstract:

---

From: "Wheeler, David M" <[email-masked]>
Date: Thu, 5 Jul 2018 20:34:32 +0000

My comments to this point have been primarily grammatical or elucidatory, in order to improve the clarity of the document. The following comment is (IMHO) a required change to the specification in order to accommodate multiple types of TEEs, not just ARM TrustZone implementations:

Section 5.1 page 9:
Secure Boot: 
      Secure boot must enable authenticity checking of TEEs
      by the TAM. Note that some TEE implementations do not require
      secure boot functionality.

This definition is incomplete, as it does not elucidate how the secure boot checks the authenticity for the TEE, or how the TEE receives something from the SBM to trust the TEE.

Part of the problem, IMHO, is the assumption about how the TEE is booted, and what the TCB of the TEE actually is. I suggest the following paragraphs to replace that definition with a further architectural explanation (as follows):

---

TEE Attestation, Secure Boot, Trusted Firmware, and the TEE TCB
In order for the TAM to trust information received over the TEEP protocol, the Device and TEE must provide sufficient proof that the device and TEE are trust worthy. The TAM must make a trust decision. A trust decision is based on cryptographic proof (a signed attestation) that the subject of the attestation has control of the private portion of a key pair that is registered with a trusted certificate authority. This trusted key pair is the Root-of-Trust key in the TEE. However, the TAM is required to make a further policy decision based upon this attestation proof, namely that the registered key in fact represents a TEE the TAM is willing to trust and that the key has not been revoked. 

The trust the TAM places in the TEE is a combination of the cryptographic verification of the signed attestation and knowledge of the TEE's implementation of its trusted computing base (TCB). The TCB is merely the essential base elements of the TEE that must be trusted for the TEE to operate in a trustworthy fashion. For some TEEs, the TCB is rooted in the secure boot of the device; in this case a proper attestation of the TEE requires an additional attestation of the secure boot of the device, as well as the attestation of the TEE itself. This is the case for the ARM Trust Zone architecture. 

The TCB of other TEEs are independent of the device's boot state, and therefore do not require an attestation for the secure boot of the device. An example  of this type of TEE architecture is a separate physical hardware engine with its own separate secure ROM containing the TEE implementation; examples of such implementations include a Secure Element (SE), a TPM, or the Intel SGX architecture where the TEE is built completely from microcode in the CPU secure ROM. In these instances, the device boot is separate from the TEE; and whether the device is securely booted or not, there is no effect on the secure state of the TEE.

In other cases, the TEE may be composed of multiple secure firmware or hardware elements, and a proper attestation of the TEE could require several signed attestations from different keys. Such a device might use a TPM for a keystore combined with protected FW on a separate co-processor; this combination would require an attestation from the co-processor's Root-of-Trust key and an attestation from the TPM. 

These examples show specific distinctions that are important for the TAM to properly make trust decisions. These decisions are based on knowledge of the TEE implementation, and will be verified by the TAM by looking for the appropriate attestations in the TEE attestation response.

In order to accommodate these different instances, the TEE attestation must accommodate the consolidation of multiple attestations from potentially different trust roots. In the ARM TrustZone case, an attestation from the SBM is required to ensure the software that booted the TZ environment came from a trusted platform source. Then a further attestation is required for the TZ root-of-trust key to be verified.

In the SGX case, because SGX is completely separate from the REE and the secure boot of the platform, only an attestation of the SGX Root-of-Trust key is required. 

It is easy to see from these examples that Trusted Firmware (TFW) and Secure Boot Modules (SBM) may be required to be included in some TEE attestations, but are not required in others. In fact, it may not even be possible to include an SBM attestation in some SGX implementations because SGX will operate with secure boot turned off, making the secure boot attestation inaccessible.

Secure Boot Module (CBM):
Some TEEs require a secure boot module to verify the software or firmware of the TEE. In these cases, the TEE attestation must include an attestation from the SBM.

Trusted Firmware (TFW):
Some TEEs require software which is loaded over a potentially insecure channel or from an insecure storage device. This software is normally signed by the developer or device manufacturer using a private key corresponding to a device Trust Anchor. When the software is loaded, a TFW verifies the signature on the software using the securely stored Trust Anchor. In these cases, the TEE attestation must include an attestation of the software signed by the TFW Root-of-Trust key.

TEE Attestation:
A TEE attestation is a combination of one or more cryptographically signed attestation records corresponding to the separate TCB elements that compose the TEE. A complete TEE attestation must include attestations from all TCB elements in order for a TAM to properly verify a TEE. The TEE attestation must include at least a TEE Root-of-Trust key attestation, but may also include an SBM attestation and zero or more TFW attestations.

---

Hopefully this provides clarity to the discussion and during the Montreal meeting we can discuss this further if necessary.
Thanks,
Dave Wheeler

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 4, 2018 7:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Teep] I-D Action: draft-ietf-teep-architecture-00.txt

Abstract:

---

From: Dave Thaler <[email-masked]>
Date: Thu, 5 Jul 2018 20:35:50 +0000

[speaking as an individual]

As David says, there's more than one type of "Root-of-Trust" aka "trust anchor". 
There are industry terms of art for the different types.
One example article that gives a decent summary is https://healthitsecurity.com/news/nist-roots-of-trust-for-healthcare-mobile-devices

In particular, the industry terms (from NIST SP 800-164, potentially among others) are:
Roof of Trust for Storage (RTS)
Root of Trust for Verification (RTV)
Root of Trust for Integrity (RTI)
Root of Trust for Reporting (RTR)
Root of Trust for Measurement (RTM)

I would recommend using the above terms and not using "trust anchor" or the unqualified "root of trust" term.

Dave

-----Original Message-----
From: TEEP <[email-masked]> On Behalf Of Wheeler, David M
Sent: Thursday, July 5, 2018 12:52 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Hannes,

Thanks,
Dave Wheeler 

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Wheeler, David M
Sent: 05 July 2018 21:38
To: [email-masked]
Subject: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

The definition states:

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 4, 2018 7:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Teep] I-D Action: draft-ietf-teep-architecture-00.txt

Abstract:

The IETF datatracker status page for this draft is:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teep-architecture%2F&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=XBuTlsiV5OjkxkcqULdsmroTnWRZqApH3fBokJGvkTE%3D&amp;reserved=0

There are also htmlized versions available at:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-00&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=heO1xlxfrVZyyzYziQy8V2P0vxiEbTVSF8sFdNaw8sc%3D&amp;reserved=0
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teep-architecture-00&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=aoKW%2FFnlzzLxpOwEpmKZ6IsOvg8Tji8Gw4YabXAcS54%3D&amp;reserved=0

_______________________________________________
TEEP mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=7x7cgTvWZOsnWEDD9hQuRRvwGvB4TTpl0okIPShXtd0%3D&amp;reserved=0

_______________________________________________
TEEP mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=7x7cgTvWZOsnWEDD9hQuRRvwGvB4TTpl0okIPShXtd0%3D&amp;reserved=0
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
TEEP mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=7x7cgTvWZOsnWEDD9hQuRRvwGvB4TTpl0okIPShXtd0%3D&amp;reserved=0

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 5 Jul 2018 21:19:45 +0000

Hi David,

Thanks so much for your detailed review. We can surely discuss some of these points further in Montreal. I will go through the list to incorporate in the next revision.

Thanks,

Ming

On 7/5/18, 1:34 PM, "TEEP on behalf of Wheeler, David M" <[email-masked] on behalf of [email-masked]> wrote:

    Section 5.1 page 9:
    Secure Boot: 

    
    ---

    

    

    
    
    Trusted Firmware (TFW):
    
    TEE Attestation:
    
    ---

    
    -----Original Message-----
    From: TEEP [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: Wednesday, July 4, 2018 7:49 AM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [Teep] I-D Action: draft-ietf-teep-architecture-00.txt

    
    Abstract:

    The IETF datatracker status page for this draft is:
    https://clicktime.symantec.com/a/1/7XmTTuI4uBLP7j9R_eaZwpn3zdPpl-7nldhfzd0sbAU=?d=Y-xSrL6X6N7P5xllKK6OEi9VGxH8cApwOwormDbGhjliI9CRNACHwNtsQrxYKZl2Q2NEFeiQJyjnWKoc3fTf3DDDwxS2Ur9CYGyYqYe_VDznRLCz4QF6vedaMgHTYC-fTyHD5Z2gMunrFTCTrTRf-KcN3my4IFYOTJwkz8nTSAhR9TfGH4Akw6ZRfeHqo2wuld-R0neZFwtiuWoiFyS4ps2-_j3kjZfPUcZqmQncdWfon4U5D_zp4hUlGE5c-Mq7sWUu24vPEhRzQfW4xW_GRSgtmbVb2qHQC0wltZ0q9tJs0THX6SXvpbAl0et3rWQJlKpFe_FdVU8CF_8JOjOIZEh-4NX4iFiS6buYrmwdlNJX7mVrS7Ak1b2kzNP1g-MmmFjHOxqso2sS7AXroVmxqrhi7j4PUwz6SIdWqGUE8oCnXfGbkqtcYilZqbBCbefsPhuslw%3D%3D&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teep-architecture%2F
    
    There are also htmlized versions available at:
    https://clicktime.symantec.com/a/1/6dMOUFz12CD21tCrwE5wAE0izXRxji2Uhik1_vzy9Us=?d=Y-xSrL6X6N7P5xllKK6OEi9VGxH8cApwOwormDbGhjliI9CRNACHwNtsQrxYKZl2Q2NEFeiQJyjnWKoc3fTf3DDDwxS2Ur9CYGyYqYe_VDznRLCz4QF6vedaMgHTYC-fTyHD5Z2gMunrFTCTrTRf-KcN3my4IFYOTJwkz8nTSAhR9TfGH4Akw6ZRfeHqo2wuld-R0neZFwtiuWoiFyS4ps2-_j3kjZfPUcZqmQncdWfon4U5D_zp4hUlGE5c-Mq7sWUu24vPEhRzQfW4xW_GRSgtmbVb2qHQC0wltZ0q9tJs0THX6SXvpbAl0et3rWQJlKpFe_FdVU8CF_8JOjOIZEh-4NX4iFiS6buYrmwdlNJX7mVrS7Ak1b2kzNP1g-MmmFjHOxqso2sS7AXroVmxqrhi7j4PUwz6SIdWqGUE8oCnXfGbkqtcYilZqbBCbefsPhuslw%3D%3D&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-00
    https://clicktime.symantec.com/a/1/CJjrzTPN6KxdENtJbSXqWUWZtHzvxP6zeDb1PWpCvEU=?d=Y-xSrL6X6N7P5xllKK6OEi9VGxH8cApwOwormDbGhjliI9CRNACHwNtsQrxYKZl2Q2NEFeiQJyjnWKoc3fTf3DDDwxS2Ur9CYGyYqYe_VDznRLCz4QF6vedaMgHTYC-fTyHD5Z2gMunrFTCTrTRf-KcN3my4IFYOTJwkz8nTSAhR9TfGH4Akw6ZRfeHqo2wuld-R0neZFwtiuWoiFyS4ps2-_j3kjZfPUcZqmQncdWfon4U5D_zp4hUlGE5c-Mq7sWUu24vPEhRzQfW4xW_GRSgtmbVb2qHQC0wltZ0q9tJs0THX6SXvpbAl0et3rWQJlKpFe_FdVU8CF_8JOjOIZEh-4NX4iFiS6buYrmwdlNJX7mVrS7Ak1b2kzNP1g-MmmFjHOxqso2sS7AXroVmxqrhi7j4PUwz6SIdWqGUE8oCnXfGbkqtcYilZqbBCbefsPhuslw%3D%3D&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teep-architecture-00

    
    _______________________________________________
    TEEP mailing list
    [email-masked]
    https://clicktime.symantec.com/a/1/-5OlXdYdOrFM4fQuW6p3GFbKv0Kc39eRMhuOf_rsolY=?d=Y-xSrL6X6N7P5xllKK6OEi9VGxH8cApwOwormDbGhjliI9CRNACHwNtsQrxYKZl2Q2NEFeiQJyjnWKoc3fTf3DDDwxS2Ur9CYGyYqYe_VDznRLCz4QF6vedaMgHTYC-fTyHD5Z2gMunrFTCTrTRf-KcN3my4IFYOTJwkz8nTSAhR9TfGH4Akw6ZRfeHqo2wuld-R0neZFwtiuWoiFyS4ps2-_j3kjZfPUcZqmQncdWfon4U5D_zp4hUlGE5c-Mq7sWUu24vPEhRzQfW4xW_GRSgtmbVb2qHQC0wltZ0q9tJs0THX6SXvpbAl0et3rWQJlKpFe_FdVU8CF_8JOjOIZEh-4NX4iFiS6buYrmwdlNJX7mVrS7Ak1b2kzNP1g-MmmFjHOxqso2sS7AXroVmxqrhi7j4PUwz6SIdWqGUE8oCnXfGbkqtcYilZqbBCbefsPhuslw%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
    
    _______________________________________________
    TEEP mailing list
    [email-masked]
    https://clicktime.symantec.com/a/1/-5OlXdYdOrFM4fQuW6p3GFbKv0Kc39eRMhuOf_rsolY=?d=Y-xSrL6X6N7P5xllKK6OEi9VGxH8cApwOwormDbGhjliI9CRNACHwNtsQrxYKZl2Q2NEFeiQJyjnWKoc3fTf3DDDwxS2Ur9CYGyYqYe_VDznRLCz4QF6vedaMgHTYC-fTyHD5Z2gMunrFTCTrTRf-KcN3my4IFYOTJwkz8nTSAhR9TfGH4Akw6ZRfeHqo2wuld-R0neZFwtiuWoiFyS4ps2-_j3kjZfPUcZqmQncdWfon4U5D_zp4hUlGE5c-Mq7sWUu24vPEhRzQfW4xW_GRSgtmbVb2qHQC0wltZ0q9tJs0THX6SXvpbAl0et3rWQJlKpFe_FdVU8CF_8JOjOIZEh-4NX4iFiS6buYrmwdlNJX7mVrS7Ak1b2kzNP1g-MmmFjHOxqso2sS7AXroVmxqrhi7j4PUwz6SIdWqGUE8oCnXfGbkqtcYilZqbBCbefsPhuslw%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
    
    _______________________________________________
    TEEP mailing list
    [email-masked]
    https://clicktime.symantec.com/a/1/-5OlXdYdOrFM4fQuW6p3GFbKv0Kc39eRMhuOf_rsolY=?d=Y-xSrL6X6N7P5xllKK6OEi9VGxH8cApwOwormDbGhjliI9CRNACHwNtsQrxYKZl2Q2NEFeiQJyjnWKoc3fTf3DDDwxS2Ur9CYGyYqYe_VDznRLCz4QF6vedaMgHTYC-fTyHD5Z2gMunrFTCTrTRf-KcN3my4IFYOTJwkz8nTSAhR9TfGH4Akw6ZRfeHqo2wuld-R0neZFwtiuWoiFyS4ps2-_j3kjZfPUcZqmQncdWfon4U5D_zp4hUlGE5c-Mq7sWUu24vPEhRzQfW4xW_GRSgtmbVb2qHQC0wltZ0q9tJs0THX6SXvpbAl0et3rWQJlKpFe_FdVU8CF_8JOjOIZEh-4NX4iFiS6buYrmwdlNJX7mVrS7Ak1b2kzNP1g-MmmFjHOxqso2sS7AXroVmxqrhi7j4PUwz6SIdWqGUE8oCnXfGbkqtcYilZqbBCbefsPhuslw%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep

---

From: "Wheeler, David M" <[email-masked]>
Date: Thu, 5 Jul 2018 21:44:20 +0000

Changes below to use D. Thaler's recommended NIST verbiage for RoT...
Hopefully this clear with the /ADD/.../    and /REMOVE/.../REPLACE/.../ marks   :^)

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Wheeler, David M
Sent: Thursday, July 5, 2018 1:35 PM
To: [email-masked]
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Section 5.1 page 9:
Secure Boot: 

---

In order for the TAM to trust information received over the TEEP protocol, the Device and TEE must provide sufficient proof that the device and TEE are trust worthy. The TAM must make a trust decision. A trust decision is based on cryptographic proof (a signed attestation /ADD/from the Root-of-Trust for Reporting (RTR)/) that the subject of the attestation (the Device/TEE) has control of the private portion of a key pair that is registered with a trusted certificate authority. This trusted key pair is the /REMOVE/Root-of-Trust/REPLACE/Device Identity/ key in the TEE. However, the TAM is required to make a further policy decision based upon this attestation proof, namely that the registered key in fact represents a TEE the TAM is willing to trust and that the key has not been revoked. 

In other cases, the TEE may be composed of multiple secure firmware or hardware elements, and a proper attestation of the TEE could require several signed attestations from different keys. Such a device might use a TPM for a keystore combined with protected FW on a separate co-processor; this combination would require an attestation from the co-processor's Root-of-Trust /ADD/ for Reporting (RTR)/ key and an attestation from the TPM. 

In order to accommodate these different instances, the TEE attestation must accommodate the consolidation of multiple attestations from potentially different trust roots /ADD/ - collectively these are collected together in Root-of-Trust for Integrity (RTI) that manages the assertions on a platform./ In the ARM TrustZone case, an attestation from the SBM is required to ensure the software that booted the TZ environment came from a trusted platform source. Then a further attestation is required for the TZ root-of-trust key to be verified. /ADD/ These attestations or assertions must be provided by the platform in the signed attestation from the RTR./

In the SGX case, because SGX is completely separate from the REE and the secure boot of the platform, only an attestation of the SGX Root-of-Trust /ADD/for Reporting (RTR)/ key is required. 

Secure Boot Module (CBM):
Some TEEs require a secure boot module to verify the software or firmware of the TEE. In these cases, the TEE attestation must include an /REMOVE/attestation/REPLACE/assertion/ from the SBM.

Trusted Firmware (TFW):
Some TEEs require software which is loaded over a potentially insecure channel or from an insecure storage device. This software is normally signed by the developer or device manufacturer using a private key corresponding to a device Trust Anchor. When the software is loaded, a TFW /ADD/(or a Root-of-Trust for Verification (RTV)/ verifies the signature on the software using the securely stored Trust Anchor. In these cases, the TEE attestation must include an /REMOVE/attestation/REPLACE/assertion/ of the software signed by the /REMOVE/TFW Root-of-Trust key/REPALCE/Root of Trust for Reporting (RTR)/.

TEE Attestation:
A TEE attestation is a combination of one or more cryptographically signed /REMOVE/attestation records/REPLACE/assertions/  corresponding to the separate TCB elements that compose the TEE. A complete TEE attestation must include /REMOVE/attestations/REPLACE/assertions/ from all TCB elements in order for a TAM to properly verify a TEE. The TEE attestation must include at least a /ADD/signed assertion from the/ TEE Root-of-Trust /ADD/for Reporting (RTR)/ /REMOVE/key attestation/, but may also include an SBM /REMOVE/attestation/REPLACE/assertion/ and zero or more TFW /REMOVE/attestations/REPLACE/assertions/.

---

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 4, 2018 7:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Teep] I-D Action: draft-ietf-teep-architecture-00.txt

Abstract:

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 6 Jul 2018 06:56:13 +0200

I hope that you guys don't mind a (distantly) related architectural question.

Using trusted hardware and TEEs is indeed cool since they enable security levels comparable to traditional smart cards although provisioned on-line.

A quite popular use case is using a mobile phone as a "security device" together with a PC running a web applications like on-line banking.  Such arrangements usually depend on an OOB channel from the phone.

However, the majority of these applications are in spite of all the great security solutions still susceptible to fairly trivial phishing attacks.  In fact, some of these systems have been exploited numerous times through social engineering over the phone!

What is the problem then?  Please don't take it personally but there are obviously some disconnects in this industry, high-lighted by the fact that QR code has become "the new black" although it is inconvenient and have poor security characteristics.

Summary: for a certain kind of real world applications, trusted hardware offers only marginally better security than traditional passwords.

Cheers,
Anders

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 6 Jul 2018 05:50:06 +0000

Hi Anders,

I agree that there are mobile phone authentication and payment solutions that do not offer much better security than traditional passwords.

We do, however, not propose a single authentication or payment solution but instead want to enable developers to upload and manage code on the TEE. This could, for example, enable improved security for an FIDO-based authentication mechanism.

Ciao
Hannes

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: 06 July 2018 06:56
To: Wheeler, David M; [email-masked]; Hannes Tschofenig
Subject: OOB Issues. Was: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Cheers,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 6 Jul 2018 08:07:05 +0200

> Hi Anders,

Hi Hannes,

> We do, however, not propose a single authentication or payment solution but instead want to enable developers to upload and manage code on the TEE. This could, for example, enable improved security…

What I was trying to explain is that it doesn't matter if you have TEEs or not if the system depends on an OOB channel (which currently is close to a de-facto standard).

As a developer of such systems I find it deeply unsatisfying having to admit that in spite of using "state of the art security solutions", it doesn't really cope with phishing.

What is your recommended solution/workaround to this problem?  Dropping OOB? Replacing OOB with ...?

Cheers,
Anders

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 6 Jul 2018 06:26:04 +0000

Hi Anders,

In this specific example I have to admit that I have a bias towards FIDO. In this setup FIDO wouldn't need an out-of-band channel.
The TEE would helpful and OTrP could be used to distribute the FIDO Authenticator code to phones and tablets.

Ciao
Hannes

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: 06 July 2018 08:07
To: Hannes Tschofenig; Wheeler, David M; [email-masked]
Subject: Re: OOB Issues. Was: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Hi Hannes,

Cheers,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 6 Jul 2018 09:44:40 +0200

Hi Hannes,

> In this specific example I have to admit that I have a bias towards FIDO. In this setup FIDO wouldn't need an out-of-band channel.

I assume you mean that the phone would be equipped with a FIDO authenticator and then connected to the PC though BLE (or worst-case through a cable), right?

This obviously works but is incompatible with client side PKI as well as other schemes that do not have a natural tie to FIDO.

Since this certainly isn't "common knowledge", the most reasonable would be that those who represent the platform vendors (ARM, Intel, MSFT) explained to governments and banks that they should carefully reexamine their design choices for the future.

FWIW, I'm personally interested in creating more "neutral" security technology, including addressing OOB channel authentication beyond what the current standard (QR) offers (=zero).

Cheers,
Anders

---

From: Andrew Atyeo <[email-masked]>
Date: Fri, 6 Jul 2018 08:38:25 +0000

In OTrP, I believe "root of trust" and "trust anchor" are currently referring to 2 different things in the OTrP spec.

*         Root of trust

Excerpt from OTrP: "This specification assumes that an applicable device is equipped with
   a TEE and is pre-provisioned with a device-unique public/private key
   pair, which is securely stored.  This key pair is referred as the
   'root of trust'.  An entity that uses such a device to run Trusted
   Applications (TAs) is known as a Service Provider (SP)."

Here, "Root of Trust" must be talking about either the TEE/TFW private key, so "root of trust" is referring to the process of secure boot that results in a TAM being able to use a signature from this key to know whether to trust the TEE

*         Trust Anchor

There is a problem this refers to 2 completely different concepts:

"Setup trust anchors in devices

   1.  [TFW/TEE] Store the key and certificate encrypted with the eFuse

       key

   2.  [TEE vendor or OEM] Store trusted CA certificate list into

       devices"

Here, "Trust Anchor" is referring to both the TFW private key and the TAM CA root certificate store

BUT later on in the spec:

"The root CA certificates for a TAM, which are

embedded into the trust anchor store in a device, should have long

lifetimes that don't require device trust anchor update."

And

"Trust Anchor: A root certificate that can be used to validate its
children certificates. It is usually embedded in a device or
configured by a TAM for validating the trust of a remote entity's

certificate."

Here, "Trust Anchor" refers to the TAM root CA whitelist that is embedded in the TEE in order to allow the TEE to chain TAM certificates to the root CA certs (to determine what certs to trust)

...So it is best if we can remove the term "trust anchor" wherever it refers to the concept of root CA certs, and refer to "TAM root CA certificate store" (or something like that)

, and for everywhere else that uses "trust anchor" to refer to the concept of secureboot/attestation etc, we need to settle on some other term. In some cases

e.g. "pair, which is securely stored in the TEE. This key pair is referred to as the 'root of trust'."

we can simply refer to the TFW key (since in places 'root of trust' is used to describe the TFW key).

Andrew Atyeo

Security Architect

Intercede

Digital trust    people | devices | apps

Office: +44 (0) 1455 558 111

www.intercede.com

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: 05 July 2018 21:36
To: Wheeler, David M <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Dave

-----Original Message-----

From: TEEP <[email-masked]<mailto:[email-masked]>> On Behalf Of Wheeler, David M

To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hannes,

Thanks,

Dave Wheeler

-----Original Message-----

To: Wheeler, David M <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

-----Original Message-----

Sent: 05 July 2018 21:38

To: [email-masked]<mailto:[email-masked]>

The definition states:

                            certificate.

                           degree as the TEE.

-----Original Message-----

From: TEEP [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

        Authors         : Mingliang Pei

                          Hannes Tschofenig

                          Andrew Atyeo

                          Dapeng

Pages           : 24

Date            : 2018-07-02

Abstract:

   running inside a TEE.

TEEP mailing list

[email-masked]<mailto:[email-masked]>

TEEP mailing list

[email-masked]<mailto:[email-masked]>

TEEP mailing list

[email-masked]<mailto:[email-masked]>

TEEP mailing list

[email-masked]<mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 6 Jul 2018 11:21:32 +0000

The problem is only that "root of trust" is not a well defined term in the IETF, at least as far as I know. Trust anchor, on the other hand, is well defined.
The definition currently in the document for root of trust seems to be similar to trust anchor. However, I agree with both Andy and with David that we need to find out whether we want to point out certain usages of the key (such as for the purpose of the attestation). Whether this justifies the introduction of another term is yet another discussion

Ciao
Hannes

From: Andrew Atyeo [mailto:[email-masked]]
Sent: 06 July 2018 10:38
To: Dave Thaler; Wheeler, David M; Hannes Tschofenig; [email-masked]
Subject: RE: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

*         Root of trust

*         Trust Anchor

       key

       devices"

And

certificate."

Andrew Atyeo

Security Architect

Intercede

www.intercede.com

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: 05 July 2018 21:36
To: Wheeler, David M <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Dave

-----Original Message-----

Hannes,

Thanks,

Dave Wheeler

-----Original Message-----

Sent: 05 July 2018 21:38

The definition states:

                            certificate.

                           degree as the TEE.

-----Original Message-----

        Authors         : Mingliang Pei

                          Hannes Tschofenig

                          Andrew Atyeo

                          Dapeng

Pages           : 24

Date            : 2018-07-02

Abstract:

   running inside a TEE.

TEEP mailing list

TEEP mailing list

TEEP mailing list

TEEP mailing list

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 6 Jul 2018 11:35:34 +0000

Hi Anders,

Most likely it would make more sense to use the FIDO Authenticator in the TEE of the phone rather than connected to an external device. Using another device, such as a watch via BLE, may be possible but it is probably not the most common approach. (In fact I have actually contributed to the FIDO specification that offers that functionality.)

There is a lot of "educating" going on as part of the FIDO public policy and privacy program, which I had the pleasure to co-chair for some time.

You are correct that FIDO has not been designed with the classical client-side PKI in mind. IMHO that's a good thing.

For what matters with regards to TEEP is whether we can get a standardized mechanism defined that allows us to enable easier deployments like the once described above. Today, this is rather challenging since it is tough to get the necessary FIDO Authenticator code on phones and tablets.

Ciao
Hannes

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: 06 July 2018 09:45
To: Hannes Tschofenig; Wheeler, David M; [email-masked]
Subject: Re: OOB Issues. Was: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Hi Hannes,

Cheers,
Anders

---

From: Dave Thaler <[email-masked]>
Date: Fri, 6 Jul 2018 14:37:05 +0000

[speaking as an individual participant]

The WG charter says "The group will maintain a close relationship with the ... Trusted Computing Group, and other relevant standards groups..." and I think part of that is to use consistent terminology.  Hence my recommendation that David Wheeler already incorporated into his proposed text.  (Thanks David)

Dave

From: Hannes Tschofenig <[email-masked]>
Sent: Friday, July 6, 2018 4:22 AM
To: Andrew Atyeo <[email-masked]>; Dave Thaler <[email-masked]>; Wheeler, David M <[email-masked]>; [email-masked]
Subject: RE: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Ciao
Hannes

From: Andrew Atyeo [mailto:[email-masked]]
Sent: 06 July 2018 10:38
To: Dave Thaler; Wheeler, David M; Hannes Tschofenig; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

*         Root of trust

*         Trust Anchor

       key

       devices"

And

certificate."

Andrew Atyeo

Security Architect

Intercede

www.intercede.com<http://www.intercede.com>

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: 05 July 2018 21:36
To: Wheeler, David M <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00..txt

One example article that gives a decent summary is https://healthitsecurity.com/news/nist-roots-of-trust-for-healthcare-mobile-devices<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhealthitsecurity.com%2Fnews%2Fnist-roots-of-trust-for-healthcare-mobile-devices&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240700830&sdata=nWEwUiwplWo%2F2ikoHBR6mg6s3vI7vKr0YywPjl8Nuz4%3D&reserved=0>

Dave

-----Original Message-----

Hannes,

Thanks,

Dave Wheeler

-----Original Message-----

From: Hannes Tschofenig [mailto:[email-masked]<mailto:[email-masked]>]

-----Original Message-----

Sent: 05 July 2018 21:38

The definition states:

                            certificate.

                           degree as the TEE.

-----Original Message-----

        Authors         : Mingliang Pei

                          Hannes Tschofenig

                          Andrew Atyeo

                          Dapeng

Pages           : 24

Date            : 2018-07-02

Abstract:

   running inside a TEE.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teep-architecture%2F&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=XBuTlsiV5OjkxkcqULdsmroTnWRZqApH3fBokJGvkTE%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teep-architecture%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240700830&sdata=QgHpEQ6cqPzjNSNAXlOBVJfmbHzpDogVNJNpWI6uPzg%3D&reserved=0>

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-00&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=heO1xlxfrVZyyzYziQy8V2P0vxiEbTVSF8sFdNaw8sc%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240710835&sdata=yLbkguKNpWobGSQbfCI3XTLaLJPHO5pX7y0uzM5aQpI%3D&reserved=0>

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teep-architecture-00&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=aoKW%2FFnlzzLxpOwEpmKZ6IsOvg8Tji8Gw4YabXAcS54%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teep-architecture-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240720840&sdata=izEKpdtjJPah2dorUbEc7ZdJZJAvPITE9iop%2BtuFrms%3D&reserved=0>

TEEP mailing list

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=7x7cgTvWZOsnWEDD9hQuRRvwGvB4TTpl0okIPShXtd0%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240730849&sdata=vxedecEwOXML1kDDEvCVOmZWyVp7JF6jky%2BnGgZeU5w%3D&reserved=0>

TEEP mailing list

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=7x7cgTvWZOsnWEDD9hQuRRvwGvB4TTpl0okIPShXtd0%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240730849&sdata=vxedecEwOXML1kDDEvCVOmZWyVp7JF6jky%2BnGgZeU5w%3D&reserved=0>

TEEP mailing list

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=7x7cgTvWZOsnWEDD9hQuRRvwGvB4TTpl0okIPShXtd0%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240740862&sdata=BM3CGgYe99eqU3Cr9j8CZ3R9LIxD0ycKnT8%2FEMwUqjU%3D&reserved=0>

TEEP mailing list

https://www.ietf.org/mailman/listinfo/teep<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240750863&sdata=KuTTsAhETZCmCGwo1Y3rmgkhCM8w5Mq8JkxxcLL26N8%3D&reserved=0>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Fri, 6 Jul 2018 15:17:09 +0000

Use of the NIST terminology would also maintain alignment with GlobalPlatform - both TCG and GlobalPlatform expand somewhat on NIST definitions due to differences in use-case and architecture, but NIST is a common root which is well understood in both the GlobalPlatform and TCG specifications - there is an entire document covering this at GlobalPlatform (https://globalplatform.org/wp-content/uploads/2018/06/GP_RoT_Definitions_and_Requirements_v1.0.1_PublicRelease_CC.pdf - note that this will shortly be updated)

Jeremy

On 6 Jul 2018, at 15:37, Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>> wrote:

The WG charter says “The group will maintain a close relationship with the … Trusted Computing Group, and other relevant standards groups...” and I think part of that is to use consistent terminology.  Hence my recommendation that David Wheeler already incorporated into his proposed text.  (Thanks David)

Dave

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 6, 2018 4:22 AM
To: Andrew Atyeo <[email-masked]<mailto:[email-masked]>>; Dave Thaler <[email-masked]<mailto:[email-masked]>>; Wheeler, David M <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

The problem is only that “root of trust” is not a well defined term in the IETF, at least as far as I know. Trust anchor, on the other hand, is well defined.
The definition currently in the document for root of trust seems to be similar to trust anchor. However, I agree with both Andy and with David that we need to find out whether we want to point out certain usages of the key (such as for the purpose of the attestation). Whether this justifies the introduction of another term is yet another discussion

Ciao
Hannes

•         Root of trust

Excerpt from OTrP: “This specification assumes that an applicable device is equipped with

   a TEE and is pre-provisioned with a device-unique public/private key
   pair, which is securely stored.  This key pair is referred as the
   'root of trust'.  An entity that uses such a device to run Trusted
   Applications (TAs) is known as a Service Provider (SP).”
Here, “Root of Trust” must be talking about either the TEE/TFW private key, so “root of trust” is referring to the process of secure boot that results in a TAM being able to use a signature from this key to know whether to trust the TEE

•         Trust Anchor

“Setup trust anchors in devices

       key

       devices”

Here, “Trust Anchor” is referring to both the TFW private key and the TAM CA root certificate store

BUT later on in the spec:
“The root CA certificates for a TAM, which are
embedded into the trust anchor store in a device, should have long
lifetimes that don't require device trust anchor update.”
And
“Trust Anchor: A root certificate that can be used to validate its
children certificates. It is usually embedded in a device or
configured by a TAM for validating the trust of a remote entity's
certificate.”
Here, “Trust Anchor” refers to the TAM root CA whitelist that is embedded in the TEE in order to allow the TEE to chain TAM certificates to the root CA certs (to determine what certs to trust)

…So it is best if we can remove the term “trust anchor” wherever it refers to the concept of root CA certs, and refer to “TAM root CA certificate store” (or something like that)
, and for everywhere else that uses “trust anchor” to refer to the concept of secureboot/attestation etc, we need to settle on some other term. In some cases
e.g. “pair, which is securely stored in the TEE. This key pair is referred to as the 'root of trust'.”
we can simply refer to the TFW key (since in places ‘root of trust’ is used to describe the TFW key).

Andrew Atyeo
Security Architect

Intercede

Office: +44 (0) 1455 558 111
www.intercede.com<http://www.intercede.com/>
-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: 05 July 2018 21:36
To: Wheeler, David M <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00...txt

Dave

-----Original Message-----
From: TEEP <[email-masked]<mailto:[email-masked]>> On Behalf Of Wheeler, David M
Sent: Thursday, July 5, 2018 12:52 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Hannes,

Thanks,
Dave Wheeler

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Wheeler, David M
Sent: 05 July 2018 21:38
To: [email-masked]<mailto:[email-masked]>
Subject: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

The definition states:

It is not clear whether the "Trust Anchor" is the same as the "root-of-trust" key pair, since the "root-of-trust" is not included in the definitions..

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, July 4, 2018 7:49 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Teep] I-D Action: draft-ietf-teep-architecture-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged.. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 6 Jul 2018 17:11:57 +0200

Hi all,

the TCG's definition of RoT is:

> A component that performs one or more security specific functions, such as measurement, storage, reporting, verification, and/or update. It is trusted always to behave in the expected manner, because its misbehavior cannot be detected (such as by measurement) under normal operation.

This term is disconnected from the quality of being "securely stored". 
The TCG defines Shielded Location:

> A place (memory, register, etc.) where it is safe to operate on sensitive data; data locations that can be accessed only by Protected Capabilities.

Trust Anchor is defined by RFC494 already (and therefore difficult to 
redefine, I think):

> An established point of trust (usually based on the authority of some person, office, or organization) from which a certificate user begins the validation of a certification path.

Corresponding to the definition above, in the TCG context it is also 
common to define these "favors" of RoT:

> RTC - Root of Trust for Confidentiality
> RTI - Root of Trust for Integrity
> RTM - Root of Trust for Measurement
> RTR - Root of Trust for Reporting
> RTS - Root of Trust for Storage
> RTV - Root of Trust for Verification

Maybe it can be of use to define a "flavor" here also? Arbitrary use of 
one single shielded secret for multiple uses might enable a variety of 
attack vectors.

Viele Grüße,

Henk

On 07/06/2018 04:37 PM, Dave Thaler wrote:
> The WG charter says “The group will maintain a close relationship with 
> the … Trusted Computing Group, and other relevant standards groups...” 
> and I think part of that is to use consistent terminology.  Hence my 
> recommendation that David Wheeler already incorporated into his proposed 
> text.  (Thanks David)
> 
> Dave
> 
> *From:* Hannes Tschofenig <[email-masked]>
> *Sent:* Friday, July 6, 2018 4:22 AM
> *To:* Andrew Atyeo <[email-masked]>; Dave Thaler 
> <[email-masked]>; Wheeler, David M <[email-masked]>; 
> [email-masked]
> *Subject:* RE: [Teep] Comments on I-D Action: 
> draft-ietf-teep-architecture-00.txt
> 
> The problem is only that “root of trust” is not a well defined term in 
> the IETF, at least as far as I know. Trust anchor, on the other hand, is 
> well defined.
> 
> The definition currently in the document for root of trust seems to be 
> similar to trust anchor. However, I agree with both Andy and with David 
> that we need to find out whether we want to point out certain usages of 
> the key (such as for the purpose of the attestation). Whether this 
> justifies the introduction of another term is yet another discussion
> 
> Ciao
> 
> Hannes
> 
> *From:*Andrew Atyeo [mailto:[email-masked]]
> *Sent:* 06 July 2018 10:38
> *To:* Dave Thaler; Wheeler, David M; Hannes Tschofenig; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* RE: [Teep] Comments on I-D Action: 
> draft-ietf-teep-architecture-00.txt
> 
> In OTrP, I believe "root of trust" and "trust anchor" are currently 
> referring to 2 different things in the OTrP spec.
> 
> ·*Root of trust*
> 
> Here, “Root of Trust” must be talking about either the TEE/TFW private 
> key, so “root of trust” is referring to the process of secure boot that 
> results in a TAM being able to use a signature from this key to know 
> whether to trust the TEE
> 
> ·*Trust Anchor*
> 
> Here, “Trust Anchor” refers to the TAM root CA whitelist that is 
> embedded in the TEE in order to allow the TEE to chain TAM certificates 
> to the root CA certs (to determine what certs to trust)
> 
> …So it is best if we can remove the term “trust anchor” wherever it 
> refers to the concept of root CA certs, and refer to “TAM root CA 
> certificate store” (or something like that)
> 
> , and for everywhere else that uses “trust anchor” to refer to the 
> concept of secureboot/attestation etc, we need to settle on some other 
> term. In some cases
> 
> www.intercede.com <http://www.intercede.com>
> 
> To: Wheeler, David M <[email-masked] 
> <mailto:[email-masked]>>; Hannes Tschofenig 
> <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> One example article that gives a decent summary is 
> https://healthitsecurity.com/news/nist-roots-of-trust-for-healthcare-mobile-devices 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhealthitsecurity.com%2Fnews%2Fnist-roots-of-trust-for-healthcare-mobile-devices&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240700830&sdata=nWEwUiwplWo%2F2ikoHBR6mg6s3vI7vKr0YywPjl8Nuz4%3D&reserved=0>
> 
> From: TEEP <[email-masked] <mailto:[email-masked]>> On 
> Behalf Of Wheeler, David M
> 
> To: Hannes Tschofenig <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> 
> If that is the case (trust root and trust anchors are the same), then I 
> have a concern regarding crypto separation.
> 
> In one definition the Trust Anchor signs certificates, in the other 
> definition a Root-of-Trust signs attestations.
> 
> If these are in fact the same key, then they are being used for two 
> different functions, which is not recommended for cryptographic keys.
> 
> Further, it seems to me (though I may be misunderstanding the intended 
> function), the private key of the Trust Anchor resides outside the 
> device, in a separate entity, like a CA or a TAM.
> 
> Can you pick apart my understanding of the two definitions of keys, and 
> help me understand where I got thrown off?
> 
> Thanks,
> 
> Dave Wheeler
> 
> To: Wheeler, David M <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> 
> Just a quick remark: IMHO root of trust and trust anchor are the same 
> thing. I believe we should update the text to only talk about trust 
> anchors and forget the root of trust terminology.
> 
> To: [email-masked] <mailto:[email-masked]>
> 
> It is not clear whether the "Trust Anchor" is the same as the 
> "root-of-trust" key pair, since the "root-of-trust" is not included in 
> the definitions..
> 
> If they are intended to be different (which is what I believe), then I 
> suggest we add the "root-of-trust" to the definitions, and explain the 
> difference. Oftentimes, in my experience, these terms are used 
> interchangeably.
> 
>                              The Root-of-Trust Key is used for 
> attestation signing which proves the signed
> 
> From: TEEP [mailto:[email-masked]] On Behalf Of 
> [email-masked] <mailto:[email-masked]>
> 
> To: [email-masked] <mailto:[email-masked]>
> 
> Cc: [email-masked] <mailto:[email-masked]>
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teep-architecture%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240700830&sdata=QgHpEQ6cqPzjNSNAXlOBVJfmbHzpDogVNJNpWI6uPzg%3D&reserved=0>
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240710835&sdata=yLbkguKNpWobGSQbfCI3XTLaLJPHO5pX7y0uzM5aQpI%3D&reserved=0>
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teep-architecture-00&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240720840&sdata=izEKpdtjJPah2dorUbEc7ZdJZJAvPITE9iop%2BtuFrms%3D&reserved=0>
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
> 
> [email-masked] <mailto:[email-masked]>
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240730849&sdata=vxedecEwOXML1kDDEvCVOmZWyVp7JF6jky%2BnGgZeU5w%3D&reserved=0>
> 
> [email-masked] <mailto:[email-masked]>
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240730849&sdata=vxedecEwOXML1kDDEvCVOmZWyVp7JF6jky%2BnGgZeU5w%3D&reserved=0>
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you.
> 
> [email-masked] <mailto:[email-masked]>
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240740862&sdata=BM3CGgYe99eqU3Cr9j8CZ3R9LIxD0ycKnT8%2FEMwUqjU%3D&reserved=0>
> 
> [email-masked] <mailto:[email-masked]>
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240750863&sdata=KuTTsAhETZCmCGwo1Y3rmgkhCM8w5Mq8JkxxcLL26N8%3D&reserved=0>
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged.. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you.
> 
> 
>

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 6 Jul 2018 17:43:27 +0200

> Hi Anders,

Hi Hannes,
I think you misunderstood what I meant.
> Most likely it would make more sense to use the FIDO Authenticator in the TEE of the phone rather than connected to an external device. Using another device, such as a watch via BLE, may be possibl…

The scenario I tried to depict was a Phone used as security token together with a PC running a Web application.

Using FIDO this can be done in a secure ("non-phishable") way through standardized (but specific) FIDO interfaces using BLE (or cable).

For non-FIDO solutions like PKI and payments, there is nothing similar available leaving us with security broken OOB schemes like QR.

Question: What's the value of OTrP if it in reality limits you to FIDO? This question becomes even more relevant given that FIDO (in contrast to OTrP...) already supports a perfectly working Web provisioning [1] system.  Personally I would be extremely surprised [2] if a not so distant release of Win10 running on recent Intel HW doesn't come with WebAuth/FIDO support built-in.  The same goes for Android/ARM.

Having had two generations of TPMs with no use whatsoever, I was hoping for something more flexible this time :-|

Anders

1] Web provisioning is as ugly as it was way back during the KEYPROV days.  I would say it has actually gotten worse, due to new constraints introduced by the browser vendors.

2] Since I as early as 2007 together with a bunch of Nokia gurus brought the first(?) integrated TEE "secure key" solution to the market, I know there's no magic here.

---

From: "Wheeler, David M" <[email-masked]>
Date: Fri, 6 Jul 2018 15:47:56 +0000

Henk,
I quickly reviewed the NIST document, and did not find a
	RTC - Root of Trust for Confidentiality

Can you provide a reference and a short definition?
Thanks,
Dave Wheeler

-----Original Message-----
From: Henk Birkholz [mailto:[email-masked]] 
Sent: Friday, July 6, 2018 8:12 AM
To: Dave Thaler <dthaler=[email-masked]>; Hannes Tschofenig <[email-masked]>; Andrew Atyeo <[email-masked]>; Wheeler, David M <[email-masked]>; 'Wiseman, Monty (GE Global Research, US)' <[email-masked]>; [email-masked]
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Hi all,

Corresponding to the definition above, in the TCG context it is also common to define these "favors" of RoT:

> RTC - Root of Trust for Confidentiality RTI - Root of Trust for 
> Integrity RTM - Root of Trust for Measurement RTR - Root of Trust for 
> Reporting RTS - Root of Trust for Storage RTV - Root of Trust for 
> Verification

Maybe it can be of use to define a "flavor" here also? Arbitrary use of one single shielded secret for multiple uses might enable a variety of attack vectors.

Viele Grüße,

Henk

On 07/06/2018 04:37 PM, Dave Thaler wrote:
> The WG charter says "The group will maintain a close relationship with 
> the . Trusted Computing Group, and other relevant standards groups..."
> recommendation that David Wheeler already incorporated into his 
> proposed text.  (Thanks David)
> 
> Dave
> 
> The problem is only that "root of trust" is not a well defined term in 
> the IETF, at least as far as I know. Trust anchor, on the other hand, 
> is well defined.
> 
> similar to trust anchor. However, I agree with both Andy and with 
> David that we need to find out whether we want to point out certain 
> usages of the key (such as for the purpose of the attestation). 
> Whether this justifies the introduction of another term is yet another 
> discussion
> 
> Ciao
> 
> Hannes
> 
> Here, "Root of Trust" must be talking about either the TEE/TFW private 
> key, so "root of trust" is referring to the process of secure boot 
> that results in a TAM being able to use a signature from this key to 
> know whether to trust the TEE
> 
> ·*Trust Anchor*
> 
> Here, "Trust Anchor" refers to the TAM root CA whitelist that is 
> embedded in the TEE in order to allow the TEE to chain TAM 
> certificates to the root CA certs (to determine what certs to trust)
> 
> .So it is best if we can remove the term "trust anchor" wherever it 
> refers to the concept of root CA certs, and refer to "TAM root CA 
> certificate store" (or something like that)
> 
> , and for everywhere else that uses "trust anchor" to refer to the 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fheal
> thitsecurity.com%2Fnews%2Fnist-roots-of-trust-for-healthcare-mobile-de
> vices&data=02%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d
> 5e332b1a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240700
> 830&sdata=nWEwUiwplWo%2F2ikoHBR6mg6s3vI7vKr0YywPjl8Nuz4%3D&reserved=0>
> 
> If that is the case (trust root and trust anchors are the same), then 
> I have a concern regarding crypto separation.
> 
> Can you pick apart my understanding of the two definitions of keys, 
> and help me understand where I got thrown off?
> 
> Thanks,
> 
> Dave Wheeler
> 
>                             A trust anchor may be viewed by both 
> trusted and untrusted entities on the device,
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-teep-architecture%2F&amp;data=02%7C
> 01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f9
> 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=XB
> uTlsiV5OjkxkcqULdsmroTnWRZqApH3fBokJGvkTE%3D&amp;reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-teep-architecture%2F&data=02%7C01%
> 7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988b
> f86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240700830&sdata=QgHpEQ6cq
> PzjNSNAXlOBVJfmbHzpDogVNJNpWI6uPzg%3D&reserved=0>
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools
> .ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-00&amp;data=02%7C01%7C
> dthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf8
> 6f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;sdata=heO1xlx
> frVZyyzYziQy8V2P0vxiEbTVSF8sFdNaw8sc%3D&amp;reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-00&data=02%7C01%7Cdth
> aler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C636664729240710835&sdata=yLbkguKNpWobGS
> QbfCI3XTLaLJPHO5pX7y0uzM5aQpI%3D&reserved=0>
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teep-architecture-00&amp;dat
> a=02%7C01%7Cdthaler%40microsoft.com%7C96a47856ba6549e9926f08d5e2b0c5fc
> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664171223541902&amp;s
> data=aoKW%2FFnlzzLxpOwEpmKZ6IsOvg8Tji8Gw4YabXAcS54%3D&amp;reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teep-architecture-00&data=0
> 2%7C01%7Cdthaler%40microsoft.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C
> 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636664729240720840&sdata=iz
> EKpdtjJPah2dorUbEc7ZdJZJAvPITE9iop%2BtuFrms%3D&reserved=0>
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40micro
> soft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C636664171223541902&amp;sdata=7x7cgTvWZOsnWEDD9hQuRR
> vwGvB4TTpl0okIPShXtd0%3D&amp;reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsof
> t.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636664729240730849&sdata=vxedecEwOXML1kDDEvCVOmZWyVp7J
> F6jky%2BnGgZeU5w%3D&reserved=0>
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40micro
> soft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C636664171223541902&amp;sdata=7x7cgTvWZOsnWEDD9hQuRR
> vwGvB4TTpl0okIPShXtd0%3D&amp;reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsof
> t.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636664729240730849&sdata=vxedecEwOXML1kDDEvCVOmZWyVp7J
> F6jky%2BnGgZeU5w%3D&reserved=0>
> 
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cdthaler%40micro
> soft.com%7C96a47856ba6549e9926f08d5e2b0c5fc%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C636664171223541902&amp;sdata=7x7cgTvWZOsnWEDD9hQuRR
> vwGvB4TTpl0okIPShXtd0%3D&amp;reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsof
> t.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636664729240740862&sdata=BM3CGgYe99eqU3Cr9j8CZ3R9LIxD0
> ycKnT8%2FEMwUqjU%3D&reserved=0>
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsof
> t.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636664729240750863&sdata=KuTTsAhETZCmCGwo1Y3rmgkhCM8w5
> Mq8JkxxcLL26N8%3D&reserved=0>
> 
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.
> 
> 
>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 6 Jul 2018 17:45:28 +0200

Hi Dave,

sure :)

Root of Trust for Confidentiality is defined as:

> An RoT providing confidentiality for data stored in TPM Shielded Locations.

in

> https://trustedcomputinggroup.org/wp-content/uploads/TCG-Glossary-V1.1-Rev-1.0.pdf

Viele Grüße,

Henk

---

From: Mingliang Pei <[email-masked]>
Date: Fri, 6 Jul 2018 23:22:32 +0000

Hi Anders,

I would like to separate the authentication solution from the general TA management value that OTrP provides while authentication is one of the application case to add value. There are many apps that need security protection that can leverage a TEE, say, banking apps today in phones, which needs to store confidential data, and some gaming apps to run some confidential logic. Such a logic and confidential data can better utilize a TEE, and use a TA to run inside the TEE. There is also the TEE use case "cloud provider" where a cloud provider doesn't want to have capability to inspect a customer's app running in its hosted; a TA running in a TEE (in a server machine) would offer such a position as the host provider isn't able to inspect code and data running in the TEE.

There is a gap today how these TAs are trusted, distributed and updated across different TEE devices and app providers. We believe that TEEP will provide greater realization of security value that TEE and TA can offer. Happy to discuss more.

Thanks,

Ming

On 7/6/18, 8:44 AM, "TEEP on behalf of Anders Rundgren" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Hannes,

    

    
    Anders

    > https://clicktime.symantec.com/a/1/AGsEUPvckMmXoUgJYtRiKZ14Kdo4TW_22t1Zmqx9gag=?d=Jl7UdGDeZoSKgM8phWJNJoDoD5lKk-ptf8HBgsvdCVMjBilGVqcMQ6fkuUAt71PW6OK9JNe1K_REet49jGXIGtRTqJli9lJUb6ygGZyDbzrM2zw1p29ZnZ1vC7QdCdnX-n4lIsNfiOj5gkUCrH07lOADvkFtxR8Bce8bL4hjmj4YoO4cKaqXCIsde8a0CiIvp5Qf4ieUPcA6h6F5J2sDaH9fD5RyoN9kmU38O3nCDJ-fpw8zDtp_oE0nwpNzqlscP_3G5wF34iA02qeIwUbrFvd8Np1RcyfOnxK02sZng1CWXX6juhS3hkmcFb5YI1wC-h5INa6Jv1S4MWjtptOyvn84L3yVgp9NpgHcbnYhryiuKHSXRaaAUQNBwfTNoI6Sf5c3ouL3T7Cil2KzVzw5BYmhUyEUEUoGwjZWLt7AtrLAqGW1u9XQJ9qgTLFt&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
    > 
    
    _______________________________________________
    TEEP mailing list
    [email-masked]
    https://clicktime.symantec.com/a/1/AGsEUPvckMmXoUgJYtRiKZ14Kdo4TW_22t1Zmqx9gag=?d=Jl7UdGDeZoSKgM8phWJNJoDoD5lKk-ptf8HBgsvdCVMjBilGVqcMQ6fkuUAt71PW6OK9JNe1K_REet49jGXIGtRTqJli9lJUb6ygGZyDbzrM2zw1p29ZnZ1vC7QdCdnX-n4lIsNfiOj5gkUCrH07lOADvkFtxR8Bce8bL4hjmj4YoO4cKaqXCIsde8a0CiIvp5Qf4ieUPcA6h6F5J2sDaH9fD5RyoN9kmU38O3nCDJ-fpw8zDtp_oE0nwpNzqlscP_3G5wF34iA02qeIwUbrFvd8Np1RcyfOnxK02sZng1CWXX6juhS3hkmcFb5YI1wC-h5INa6Jv1S4MWjtptOyvn84L3yVgp9NpgHcbnYhryiuKHSXRaaAUQNBwfTNoI6Sf5c3ouL3T7Cil2KzVzw5BYmhUyEUEUoGwjZWLt7AtrLAqGW1u9XQJ9qgTLFt&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 7 Jul 2018 05:37:27 +0200

Hi Ming,

Now things became pretty confusing since my question was about applications like depicted in this one-page PDF: https://1drv.ms/b/s!AmhUDQ0Od0GTgWGG91dStYl166y5

According to Hannes, FIDO is the only recommendable solution since it can use an in-line connection, rather than relying on a "phishable" OOB connection using QR or similar.  That is, this market has to give up on PKI.

However, according to me, FIDO support doesn't need OTrP.

In my younger days as an Electronics Engineer, I would have called this an "impedance mismatch" :-)

BTW, since OTrP doesn't come with a Web interface it will not be particularly attractive to use for banks etc.

The "cloud provider" use case OTOH, seems like a cool target!

Thanx,
Anders

---

From: "faibish, sorin" <[email-masked]>
Date: Sat, 7 Jul 2018 14:54:19 +0000

Hannes,

After reviewing the definitions again I realized that the 2 definitions of RTC and TA - trust anchors are representing to different functions. Same as Dave I would like to see what definition and usage were intented by the draft as well as the specific use in the protocol of each definition in order to clarify the similarities/differences between the 2 definitions.

On another note, while reviewing the draft, I was wondering if it shouldn't also define the minimum OS requirements for IoT devices which will allow the implementation of the trusted protocols. I was looking at several types of IoT used in the industry and I came up to this list including:
      No-OS, RT-OS, language-runtime OS, full-OS, application-OS, server OS and container OS.  

According to some publications the minimum OS requirements to support the security of IoT devices is Language-runtime OS that according to the sources is capable of TFW upgrades and implementation of full security of TEE. My recommendation is to add such a definition/requirements for IoT TA. 

./Sorin

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Wheeler, David M
Sent: Friday, July 6, 2018 11:48 AM
To: Henk Birkholz; Dave Thaler; Hannes Tschofenig; Andrew Atyeo; 'Wiseman, Monty (GE Global Research, US)'; [email-masked]
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

Henk,

-----Original Message-----
From: Henk Birkholz [mailto:[email-masked]]
Sent: Friday, July 6, 2018 8:12 AM
To: Dave Thaler <dthaler=[email-masked]>; Hannes Tschofenig <[email-masked]>; Andrew Atyeo <[email-masked]>; Wheeler, David M <[email-masked]>; 'Wiseman, Monty (GE Global Research, US)' <[email-masked]>; [email-masked]
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00..txt

Hi all,

Viele Grüße,

Henk