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

["faibish, sorin" <[e-mail]>]

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:[e-mail]] 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)'; [e-mail]
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00.txt

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:[e-mail]]
Sent: Friday, July 6, 2018 8:12 AM
To: Dave Thaler <dthaler=[e-mail]>; Hannes Tschofenig <[e-mail]>; Andrew Atyeo <[e-mail]>; Wheeler, David M <[e-mail]>; 'Wiseman, Monty (GE Global Research, US)' <[e-mail]>; [e-mail]
Subject: Re: [Teep] Comments on I-D Action: draft-ietf-teep-architecture-00..txt

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:
> [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 <[e-mail]>
> *Sent:* Friday, July 6, 2018 4:22 AM
> *To:* Andrew Atyeo <[e-mail]>; Dave Thaler 
> <[e-mail]>; Wheeler, David M <[e-mail]>; 
> [e-mail]
> *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:[e-mail]]
> *Sent:* 06 July 2018 10:38
> *To:* Dave Thaler; Wheeler, David M; Hannes Tschofenig; [e-mail] 
> <mailto:[e-mail]>
> *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*
> 
> 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: [phone]
> 
> www.intercede.com <http://www.intercede.com>
> 
> -----Original Message-----
> From: TEEP [mailto:[e-mail]] On Behalf Of Dave Thaler
> Sent: 05 July 2018 21:36
> To: Wheeler, David M <[e-mail] 
> <mailto:[e-mail]>>; Hannes Tschofenig 
> <[e-mail] <mailto:[e-mail]>>;
> [e-mail] <mailto:[e-mail]>
> Subject: Re: [Teep] Comments on I-D Action: 
> draft-ietf-teep-architecture-00...txt
> 
> [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-m
> obile-devices
> <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>
> 
> 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 <[e-mail] <mailto:[e-mail]>> On 
> Behalf Of Wheeler, David M
> 
> Sent: Thursday, July 5, 2018 12:52 PM
> 
> To: Hannes Tschofenig <[e-mail] 
> <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>
> 
> Subject: Re: [Teep] Comments on I-D Action: 
> draft-ietf-teep-architecture-00.txt
> 
> 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: Hannes Tschofenig [mailto:[e-mail] 
> <mailto:[e-mail]>]
> 
> Sent: Thursday, July 5, 2018 12:41 PM
> 
> To: Wheeler, David M <[e-mail] 
> <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>
> 
> Subject: RE: [Teep] Comments on I-D Action: 
> draft-ietf-teep-architecture-00.txt
> 
> 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:[e-mail]] On Behalf Of Wheeler, David 
> M
> 
> Sent: 05 July 2018 21:38
> 
> To: [e-mail] <mailto:[e-mail]>
> 
> Subject: [Teep] Comments on I-D Action: 
> draft-ietf-teep-architecture-00.txt
> 
> 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:[e-mail]] On Behalf Of 
> [e-mail] <mailto:[e-mail]>
> 
> Sent: Wednesday, July 4, 2018 7:49 AM
> 
> To: [e-mail] <mailto:[e-mail]>
> 
> Cc: [e-mail] <mailto:[e-mail]>
> 
> 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://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>
> 
> 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%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>
> 
> 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
> 
> [e-mail] <mailto:[e-mail]>
> 
> 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>
> 
> _______________________________________________
> 
> TEEP mailing list
> 
> [e-mail] <mailto:[e-mail]>
> 
> 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>
> 
> 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
> 
> [e-mail] <mailto:[e-mail]>
> 
> 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>
> 
> _______________________________________________
> 
> TEEP mailing list
> 
> [e-mail] <mailto:[e-mail]>
> 
> 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%40microsof
> t.com%7Ca9986e033e9a4df8bb3608d5e332b1a0%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636664729240750863&sdata=KuTTsAhETZCmCGwo1Y3rmgkhCM8w5
> Mq8JkxxcLL26N8%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.
> 
> 
> 
> _______________________________________________
> TEEP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teep
> 

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