Re: [Teep] [EXT] Re: My BoF impression

[Jeremy O'Donoghue <[e-mail]>]

The GP definition of a TEE[1] is not tied to Trustzone in any way, and I see nothing to suggest that it precludes the type of hypervisor-based environment you describe.

What GlobalPlatform says ([1], Section 2.2.1), is:

The primary purpose of a TEE is to protect its assets from the REE
and other environments.
- This is achieved through hardware mechanisms that those other
  environments cannot control.

This protection always includes protection against other execution
environments.
[…]
The TEE is instantiated through a secure boot process using assets
bound to the SoC or the Off-SoC Security Processor and isolated
from the REE.
- The integrity and authenticity gained through secure boot:
  - Extends throughout the lifetime of the TEE.
  - Is retained through any state transitions in the system such
    as power transitions or core migration.

It further defines the transition from the non-secure to secure world in a fairly abstract manner which covers the hypervisor use case sufficiently, I think ([1], Section 2.2.3):

The only way for the REE to get access to trusted resources is via
any API entry points or services exposed by the TEE and accessed
through, for example, the TEE Client API. This does not preclude
the capability of the REE passing buffers to the TEE (and vice versa)
in a controlled and protected manner.

In short, I agree with Brian that the GP definition of a TEE is a reasonable starting point for discussion, but I strongly support IETF exploring other use cases and system architectures that GP has not addressed - it seems to me that this is where the greatest value would be generated for the ecosystem.

I am concerned that it will be challenging to move forward effectively when many participants are unfamiliar with the GP standards-base on which the current draft draws heavily unless we are able to take steps to remedy this. Are there any suggestions as to how this could be managed? In short, how do we align the two different groups in Deep more closely?

Best regards
Jeremy

[1] GlobalPlatform TEE System Architecture, Version 1.1, January 2017.

On 20 Apr 2017, at 10:20, Nick Cook <[e-mail]<mailto:[e-mail]>> wrote:

Personally speaking, OTrP is about being able to install security applications into an environment that provides "trusted" hardware backed isolation between the different applications. OTrP does that by establishing it is working against the right device type and right isolation environment type and then proceeds to install the application in a way that provides protection for confidentiality and integrity. The term TEE is probably too often associated with a specific formulation of an isolation environment and therefore this is perhaps the first thing we should move forward.

As an example, I've been working on a hardware backed hypervisor environment that uses OTrP for the installation of the different containers/domains and the virtual machine contents that goes in them. The trust chain from OTrP is met and the isolation of applications and key material to those applications is also provided.

Based on that work and thinking specifically to my original goals for OTrP when we started this work a few years back, I would like to support Dave Wheeler's comment on needing to formulate a more abstract definition for TEE. I also agree with Brian that the GP definition doesn't need to be abandoned to do that - I believe, expressed in the right way, the GP definition of a TEE covers the hardware hypervisor case I described earlier in the email also and I'm sure it can cover the other environments too.


I do however think it is important that we restrict to isolation environments that are hardware backed as this is fundamental to the trust model.

I also support Dave's suggestion that we can be less normative on exact locations of the functional blocks of OTrP. I would like to have a companion document that does provide example deployments but the core protocol itself does not need to be locked down to a specific deployment approach.



Nick Cook
-----Original Message-----
From: Brian Witten [mailto:[e-mail]]
Sent: 05 April 2017 18:02
To: Wheeler, David M <[e-mail]<mailto:[e-mail]>>; 'Jeremy O'Donoghue' <[e-mail]<mailto:[e-mail]>>; Tero Kivinen <[e-mail]<mailto:[e-mail]>>
Cc: Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>; teep <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teep] [EXT] Re: My BoF impression

Thank You Dave!  I'd like to echo & agree with many of your points, but ask for a clarification on one aspect.  "First, I (believe) this is exactly the type of conversation we need to have. Thanks for kicking this off very directly."  Well Said, Thank You Both!  "I am motivated to work jointly on developing OTrP to address a wider set of concerns common to TEEs and their environments, with the purpose of expanding the ease with which the marketplace can utilize TEE mechanisms." Again, I'm motivated by the same purpose.  "Part of this development of OTrP (from my perspective) is being less normative about the exact location and instantiation of certain parties (particularly the TSM) and be specific on the operations and activities at particular 'service access points' of the protocol."  I believe that is a great suggestion, and I'm fully supportive.  Still my clarifying question relates to the desire "to define a more abstract definition of a TEE, and desiring a protocol that is applicable to a wide set of TEEs."  I'm eager to support a wide set of TEE, including both SGX and TZ based TEE.   My question is, "do we need to abandon the Global Platform (GP) definition of a TEE to support both SGX and TZ based TEE?"  I believe that we do Not need to abandon the GP definition of a TEE to support both SGX and TZ based TEE, but I'd be eager to get your view here as you've framed the rest so very well.  Last, either way, "I believe IETF is exactly the place to have this conversation and define a very open and inclusive protocol."  Again, I agree completely.

Thank You Again!
Brian


From: TEEP <[e-mail]<mailto:[e-mail]>> on behalf of Wheeler, David M <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 5, 2017 9:34 AM
To: 'Jeremy O'Donoghue'; Tero Kivinen
Cc: Hannes Tschofenig; teep
Subject: [EXT] Re: [Teep] My BoF impression


I'm a bit behind on the thread, but want to respond to Jeremy's original comment.

First, I this is exactly the type of conversation we need to have. Thanks for kicking this off very directly.
I agree with your perception of the two groups, though I think it is important to understand the motivations in the second group, since they may be varied.

I will put myself voluntarily in the second bucket. I will present my personal perspective, which may be different from others in the "second group".

For myself, I am looking to define a more abstract definition of a TEE, and desiring a protocol that is applicable to a wide set of TEEs. From my perspective,  looking at TEEs that Intel has in the marketplace, and also having worked for several years on Intel's XScale processors (and am thus familiar with TZ), the current OTrP draft addresses Trust Zone concerns without really considering other TEEs. This is my  perception, of course.

It is also my opinion that an IETF protocol should do more than address implementation specific concerns.
I am motivated to work jointly on developing OTrP to address a wider set of concerns common to TEEs and their environments, with the purpose of expanding the  ease with which the marketplace can utilize TEE mechanisms.

Part of this development of OTrP (from my perspective) is being less normative about the exact location and instantiation of certain parties (particularly the  TSM) and be specific on the operations and activities at particular "service access points" of the protocol. My point here is that OTrP in its current rendition is <emphasis> too </emphasis> implementation specific and too normative in its description of the  marketplace. I believe this is fine as an example, but not as part of the protocol.

I believe IETF is exactly the place to have this conversation and define a very open and inclusive protocol. I realize that takes some time. I look forward  to having this conversation in more detail.

Thanks,
Dave Wheeler



From: TEEP [mailto:[e-mail]] On Behalf Of Jeremy O'Donoghue
Sent: Tuesday, April 4, 2017 7:13 AM
To: Tero Kivinen <[e-mail]<mailto:[e-mail]>>
Cc: Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>; teep <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teep] My BoF impression




On 4 Apr 2017, at 12:21, Tero Kivinen <[e-mail]<mailto:[e-mail]>> wrote:



My feeling that the main question what people did not understand was:

What is the real difference between TEEP and just normal application download. I.e., why separate protocol is needed.
How is this different from just having perhaps encrypted signed application blob from the marketplace and installing that.

At least that was my main question when we discussed this before the BoF.

Of course it does not help, that when you ask that question from different people you get different answer, as the idea of what TEEP is different for different people.



I think there is a degree of talking at cross-purposes.



There is one group - essentially those sponsoring the creation of this group - which has a very clear understanding of what it would like TEEP to be, which is essentially three things:



A mechanism for managing Trusted Applications and their associated secrets and key material in a GlobalPlatform TEE or something that is conceptually very similar.
A mechanism for establishing a chain of trust rooted in firmware and covering the TEE and possibly other system components up to and including the executing Task in a Security Domain.
A mechanism - targeted at phone and tablet type devices - which operates independently of the "App Store" mechanism, and is based on a PKI infrastructure allowing Service Providers to manage the Trusted Applications they control  without the need for user intervention.



The draft specification very clearly addresses such a system. Understanding it fully requires considerable familiarity with the GlobalPlatform TEE specifications, since much of the terminology and architectural assumptions are derived from  these.



There is a second group which is starting from a more abstract position of what a TEE should look like and what security services it might then provide to a system and how the control of these could be structured. This is a completely different  problem, and likely a much broader one which is difficult to encapsulate in a small scope.




Trying to make the architecture too generic also confuses things. It might be better to have more concrete example with more limited scope, that would explain things what TEEP should provide.

For example:

1) TEEP provides a way to install software from the Secure trusted application marketplace to the TEE running inside device.

2) The Secure trusted appliation marketplace needs to be able to verify that the TEE wanting to install an application is actual TEE, and not some fake device, for example using signature from the key installed by the manufacturer which is used to sign the installation request.

3) The Secure trusted application marketplace can then encrypt the trusted application with TEE specific key, so that nobody else than TEE can decrypt and install it. This will prevent leaking out confidential material inside the application.
Trusted application instlal package might also be personalized for the specific TEE. Secure trusted application marketplace will also sign the trusted application install package, so TEE can verify it is authentic.

4) TEE will verify the signature of the trusted application install package, and check that signer is trusted, and then it will decrypt the package, and install it.

5) The application running on the REE side might need to verify that the trusted application part of it has been properly installed to real TEE, so it can trust it doing its job. I am not sure if this will be part of the TEEP or not...

Is my understanding of TEEP correct? I do not know, and I assume other people have different ideas what should or should not be part of it.



I think this is a pretty good explanation of what the first group would like to see.


Best regards

Jeremy