Re: [Teep] Charter Text

[Robert Broberg <[e-mail]>]

At Nancy's request I've joined and been following this thread. I am not 
completely clear on the need yet for the proposed work but I think 
following paper may be of interest as various vendor specific 
architectures for trusted execution environments come with their own 
specific limiations. The following paper proposes an approach to provide a 
common interface on top of different HW architectures.

Komodo: Using verification to disentangle secure-enclave hardware from software
Andrew Ferraiuolo, Cornell University
Andrew Baumann, Microsoft Research
Chris Hawblitzel, Microsoft Research
Bryan Parno, Carnegie Mellon University

can be found at:

http://delivery.acm.org/10.1145/3140000/3132782/p287-ferraiuolo.pdf?ip=64.104.125.226&id=3132782&acc=OPENTOC&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2EC42B82B87617960C&CFID=823679137&CFTOKEN=20531313&__acm__=1509381326_a95f9975e892c4aa7f42fc5a1be0b1d4

Robert

On Mon, 30 Oct 2017, Dave Thaler wrote:

> 
> Do we know who from GlobalPlatform is participating in IETF, and vice versa?
> 
>  
> 
> Is there a description of the work GlobalPlatform is proposing to do related to OTrP?
> 
>  
> 
> Where can IETF participants find GP?s discussion of OTrP?  Is it an open or closed forum?
> 
>  
> 
> Thanks,
> 
> Dave
> 
>  
> 
> From: TEEP [mailto:[e-mail]] On Behalf Of Jeremy O'Donoghue
> Sent: Friday, September 22, 2017 8:01 AM
> To: Wheeler, David M <[e-mail]>
> Cc: Nancy Cam-Winget (ncamwing) <[e-mail]>; [e-mail]
> Subject: Re: [Teep] Charter Text
> 
>  
> 
> Hi Dave,
> 
>  
>
>       On 22 Sep 2017, at 15:26, Wheeler, David M <[e-mail]> wrote:
> 
>  
> 
> I understand your perspective and concern (I think, but would like to hear more). From Intel?s side, we have some issues with ?too
> close? relationship to GP, because GP?s definition of TEE security ties that security to trusted boot. I understand that TZ, and even
> some of Intel?s TEEs (Android Trusty implementation) require a trusted secure boot in order to themselves be secure, but Intel also
> has TEEs that are *completely separated* from secure boot, and therefore do not require a secure booted platform to retain
> security.
> 
>  
> 
> You are correct on this point. However, the GP notion of ?trusted boot? allows quite a lot of wiggle room - the essential requirement is
> that the mechanism whereby the TEE is instantiated is bound to a secure root of trust on the SoC or on off-SoC security processor. I
> don?t know enough about SGX to be able to say whether it could meet this definition.
> 
>  
> 
> Most actual implementations of GP TEEs are bound to the ARM TZ architecture, so there may well be some bias to that in some of the
> informative material around a GP TEE.
> 
>  
> 
> However, implementations of most of the specifications e.g. the GP Internal Core API, Management Framework, OTrP etc. are not bound to
> that security definition. Both TMF and the GP approach to OTrP are explicitly designed to support management of non-GP TEE.
> 
>  
> 
> I do recognise that being outside the GP Security definition might pose commercial difficulties in such an approach.
> 
> 
>
>       Too close a relationship to GP will create issues around this definition. We need greater discussion around this,
>       otherwise, by definition it rejects certain Intel TEEs (SGX primarily) and then Intel would consider this an implementation
>       specific definition aligned to TrustZone, and not a general TEE protocol.
> 
>  
> 
> My suspicion is that it also rejects ARM Cortex-M Trustzone for similar reasons (which I think has some similarities to SGX in its
> approach)
> 
> 
>
>       I think we need to talk more about this. I agree there is a lot of good stuff in GP that we should leverage.
> 
>  
> 
> Are you open to changing some of these core definitions, and working through the implications of those changes with us? This will
> separate us somewhat form GP standards, I think.
> 
>  
> 
> I think there is a need to have standards supporting TEEs that are not rooted in a secure boot style root of trust, and (ideally) for
> these to behave similarly from a developer and management perspective to TEEs that have such a root.
> 
>  
> 
> I would have thought that the main effort in such a case would be to define a system architecture, security requirements and
> (eventually) a Protection Profile - this looks a long way from the charter as currently proposed.
> 
>  
> 
> I would need to discuss further internally as to whether that is an effort to which I would be able to contribute.
> 
>  
> 
> Best regards
> 
> Jeremy
> 
> 
>
>       Very interested in your thoughts and perspective.
> 
> Thanks,
> 
> Dave Wheeler
> 
>  
> 
> From: TEEP [mailto:[e-mail]] On Behalf Of Jeremy O'Donoghue
> Sent: Friday, September 22, 2017 1:00 AM
> To: Nancy Cam-Winget (ncamwing) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Teep] Charter Text
> 
>  
> 
> Qualcomm would like to ensure that the charter and proposed deliverables are properly differentiated from work occurring in
> GlobalPlatform based on the OTrP contribution which has been accepted as a GlobalPlatform work item. 
> 
>  
> 
> Since the proposed charter for teep includes a close relationship with GlobalPlatform, Qualcomm suggests some alignment between
> the organisations to ensure that there is a single, definitive, set of standards defining OTrP as the best outcome for all
> participants.
> 
>  
> 
> ---
> 
> Jeremy O?Donoghue                            email: [e-mail]
> 
> Engineer, Principal/Manager                  tel:   [phone]
> 
> NFC & Secure Software and Systems
> 
>  
> 
>  
> 
>  
> 
>  
>
>       On 22 Sep 2017, at 05:49, Nancy Cam-Winget (ncamwing) <[e-mail]> wrote:
> 
>  
> 
> Thank you all for responding  and for demonstrating there is good support to move this work along.
> 
>  
> 
> It would be good to get discussions started on the current drafts and milestones as well.
> 
>  
> 
>                 Nancy
> 
>  
> 
> From: TEEP <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
> Date: Thursday, September 21, 2017 at 7:10 PM
> To: Dapeng Liu <[e-mail]>, Lubna Dajani <[e-mail]>, "[e-mail]"
> <[e-mail]>, teep-bounces <[e-mail]>, teep <[e-mail]>, Mingliang Pei
> <[e-mail]>, "Marc.Canel" <[e-mail]>, Richard Parris <[e-mail]>, Rob Coombs
> <[e-mail]>, "qingyang.meng" <[e-mail]>, Brian Witten <[e-mail]>,
> "[e-mail]" <[e-mail]>, Nick Cook <[e-mail]>, "[e-mail]"
> <[e-mail]>, Hannes Tschofenig <[e-mail]>, "zhijian.zhang"
> <[e-mail]>, ???<[e-mail]>, Dominique Bolignano <[e-mail]>,
> "[e-mail]" <[e-mail]>, Mike Hendrick <[e-mail]>, XiaYubin
> <[e-mail]>, "[e-mail]" <[e-mail]>, "Paczkowski, Lyle W [CTO]"
> <[e-mail]>, Pengcheng Zou <[e-mail]>, "[e-mail]" <[e-mail]>,
> "philip.attfield" <[e-mail]>, "Andrew.Atyeo" <[e-mail]>, paromix
> <[e-mail]>, ppeterkaa <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [Teep] Charter Text
> 
>  
> 
> hi,
> 
>  
> 
>  Beijing Laser Tech. support it.thanks.
> 
>  
> 
> _______________________________________________________________________________________________________________________________________
> 
> ??
> 
> CEO
> 
> ????????????
> 
> Beijing Laser Technology Development CO.,LTD
> 
> ??????????43?????7?  ??100044
> 
> ???18910750012/15601105750/13911779990
> 
> ???www.bjleisen.com
>
>        
> 
> From: Dapeng Liu
> 
> Date: 2017-09-13 00:49
> 
> To: Lubna Dajani; ppeterka; teep-bounces; teep; Mingliang Pei; Marc Canel; [e-mail]; Rob
> Coombs; qingyang.meng; brian_witten; [e-mail]; Nick Cook; [e-mail]; HannesTschofenig; zhijian.zhang; zhoup; maojun.wei; dominique.bolignano; [e-mail]; [e-mail]; xiayubin; sangj
> in.park; lyle.w.paczkowski; Pengcheng Zou; fmw; philip.attfield; Andrew.Atyeo; paromix; ppeterkaa; ? ?
> 
> Subject: re: [Teep] Charter Text
> 
> Hello Nancy,
> 
>  
> 
> Thanks!
> 
>  
> 
> Actually, there are lots of companies/experts are very interested in the proposed TEEP work. But they may not
> familiar with IETF process, I hope they would getting more active in the list after the long
> 
> summer vacation:)
> 
>  
> 
> Note: I have copied to all the experts that are interested in TEEP based on offline discussions.
> 
> To all the experts copied in this mail: Please subscribe to TEEP email list first if you want to reply.   Here is how
> to subscribe: https://www.ietf.org/mailman/listinfo/teep
> 
>  
> 
> Thanks,
> 
> Max
> 
> ------------------------------------------------------------------
> 
> From:Nancy Cam-Winget (ncamwing) <[e-mail]>
> 
> Send Time:2017?9?12?(???) 23:50
> 
> To:Lubna Dajani <[e-mail]>; Petr Peterka <[e-mail]>
> 
> Cc:[e-mail] <[e-mail]>
> 
> Subject:Re: [Teep] Charter Text
> 
>  
> 
> Thank you Lubna and Petr!
> 
>  
> 
> Would still like to hear from others and also solicit feedback on the proposed charter text.
> 
>  
> 
> Warm regards,
> 
>                 Nancy
> 
>  
> 
> From: Lubna Dajani <[e-mail]>
> 
> 
> Date: Tuesday, September 12, 2017 at 4:40 AM
> To: Petr Peterka <[e-mail]>
> 
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> 
> Subject: Re: [Teep] Charter Text
> 
>  
> 
> please allow me to echo Petr's responses. 
> 
> 1. Yes
> 
> 2. Yes
> 
> 3. Yes
> 
> 4. Yes 
> 
>  I am personally very excited to see this WG form and I look forward to actively contributing to the evolution of
> this protocol as I have since the ideation stages of this protocol
> 
> ?  
> 
> Thank you Nancy, Petr and everyone here?
> 
>  
> 
> Lubna
> 
> __________________________________________________
> 
> Lubna Dajani  I  Allternet Ltd.
> 
> @lubnadajani
> 
> @futuristasORG
> 
> + 1 201 982 0934
> 
>  
> 
>  
> 
> Confidentiality Notice: The information contained in this email and any attachments is intended only for the
> recipient[s] listed above and may be privileged and confidential. Any dissemination, copying, or use of or reliance
> upon such information by or to anyone other than the recipient[s] listed above is prohibited. If you have received
> this message in error, please notify the sender immediately at the email address above and destroy any and all copies
> of this message.
> 
>  
> 
> Sent with Mixmax
> 
>  
> 
>  
> 
> On Thu, Jul 20, 2017 2:48 AM, Petr Peterka [e-mail] wrote:
> 
> Hi Nancy
> 
> I think we had a very productive meeting yesterday. Here are my answers to your questions:
> 
>  
> 
> 1) Do you understand what TEEP is trying to achieve?
> 
> ANSWER: Yes, I do. I?d like to add that the charter may re-emphasize that the proposed WG is not going to define the
> TEE or the TAM service themselves but just the protocol between them. 
> 
>  
> 
> 2) Is this work that should be done in general?
> 
> ANSWER: Yes, it should since there are going to be more and more trusted execution environments (lower case)
> especially with the proliferation of IoT devices which will need more security than what they have today.
> 
>  
> 
> 3) Is this work that should be done in the IETF, or does it belong to somewhere else?
> 
> ANSWER: Since we are trying to define a protocol that is independent of the different TEE implementations, I believe
> that IETF is the right home for it.
> 
>  
> 
> 4) Should we form a WG with given charter to work on this?
> 
> ANSWER: Yes, that is my recommendation.
> 
>  
> 
> Thanks
> 
>           Petr
> 
>  
> 
> From: TEEP [mailto:[e-mail]] On Behalf Of Nancy Cam-Winget (ncamwing)
> Sent: Thursday, July 20, 2017 11:13 AM
> To: [e-mail]
> Subject: Re: [Teep] Charter Text
> 
>  
> 
> All,
> 
> Please provide feedback on the results of yesterday?s side meeting.  In particular, we?d like to get feedback on whether
> this the right scope and if we have captured it appropriately. If it is not, also please comment and if possible,
> provide suggestions for improvement.
> 
>  
> 
> We would like to continue discussion over email and get consensus around the 2nd week of September so that we can
> have a path forward.  In particular we would like to get answers for:
> 
>  
> 
> 1) Do you understand what TEEP is trying to achieve?
> 
> 2) Is this work that should be done in general?
> 
> 3) Is this work that should be done in the IETF, or does it belong to somewhere else?
> 
> 4) Should we form a WG with given charter to work on this?
> 
>  
> 
> Warm regards, 
> 
>     Nancy & Tero (TEEP BoF Chairs)
> 
>  
> 
> From: TEEP <[e-mail]> on behalf of Hannes Tschofenig <[e-mail]>
> Date: Wednesday, July 19, 2017 at 5:56 AM
> To: "[e-mail]" <[e-mail]>
> Subject: [Teep] Charter Text
> 
>  
> 
> Here is the charter text we came up in the side-meeting today.
> 
>  
> 
> ------
> 
> 
> 
> 
> TEEP -- A Protocol for Dynamic Trusted Execution Environment Enablement Charter
> 
>  
> 
> The Trusted Execution Environment (TEE) is a secure area of a processor. The TEE provides security features, such as
> isolated execution, integrity of Trusted Applications along with confidentiality of their assets. In general terms,
> the TEE offers an execution space that provides a higher level of security than a "rich" operating system and more
> functionality than a secure element. For example, implementations of the TEE concept have been developed by ARM, and
> Intel using the TrustZone and the SGX technology, respectively.
> 
>  
> 
> To programmatically install, update, and delete applications running in the TEE, this protocol runs between a service
> running within the TEE, a relay application or service access point on the device's network stack and a server-side
> infrastructure that interacts with and optionally maintains the applications. Some tasks are security sensitive and
> the server side requires information about the device characteristics in form of attestation and the device-side may
> require information about the server.
> 
>  
> 
> Privacy considerations have to be taken into account with authentication features and attestation.
> 
>  
> 
> This working group aims to develop an application layer protocol providing TEEs with the following functionality,
> 
> * lifecycle management of trusted applications, and
> 
> * security domain management.
> 
>  
> 
> A security domain allows a service provider's applications to be isolated so that one security domain cannot be
> influenced by another, unless it exposes an API to allow it.
> 
>  
> 
> The solution approach must take a wide range of TEE and relevant technologies into account and will focus on the use
> of public key cryptography.
> 
>  
> 
> The group will produce the following deliverables. First, an architecture document describing the involved entities,
> their relationships, assumptions, the keying framework and relevant use cases. Second, a solution document that
> describes the above-described functionality. The choice of encoding format(s) will be decided in the working group.
> The group may document several attestation technologies considering the different hardware capabilities, performance,
> privacy and operational properties.
> 
>  
> 
> The group will maintain a close relationship with the GlobalPlatform, Trusted Computing Group,  and other relevant
> standards to ensure proper use of existing TEE-relevant application layer interfaces.
> 
>  
> 
> Milestones
> 
>  
> 
> Dec 2017     Submit "TEEP Architecture" document as WG item.
> 
>  
> 
> Feb 2018     Submit "TEEP Protocol" document as WG item.
> 
>  
> 
> July 2018     Submit "TEEP Architecture" to the IESG for publication as an Informational RFC.
> 
>  
> 
> Feb 2019     Submit "TEEP Protocol" to the IESG for publication as a Proposed Standard.
> 
>  
> 
> Additional calendar items:
> 
>  
> 
> Nov 2017     IETF #100 Hackathon to work on TEEP protocol prototype implementations.
> 
>  
> 
> Mar 2018     1st interoperability event (at IETF #101).
> 
>  
> 
> Jul 2018       2nd interoperability event (at IETF #102).
> 
>  
> 
> 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.
> 
> [ISbvNmLslWYtdGQp5WYqFGZh5mY1xmI]
> 
>  
> 
> _______________________________________________
> TEEP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teep
> 
>  
> 
> 
>