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

On 04/20/2017 02:20 AM, Nick Cook 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.

Nick,

By "hardware backed hypervisor" do you mean running e.g. OKL4 or Xen 
hypervisor on e.g. an Intel or ARM system with hardware virtualization 
support?
Or something else with a different coupling between the hardware and the 
hypervisor?

Just want to make sure I understand.

I think it would be useful to see how the isolation provided by 
hypervisors fit with the TEE/REE split.

Thanks,
    Erik

>
> 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:brian_witten@symantec.com]
> Sent: 05 April 2017 18:02
> To: Wheeler, David M <david.m.wheeler@intel.com>; 'Jeremy O'Donoghue' <jodonogh@qti.qualcomm.com>; Tero Kivinen <kivinen@iki.fi>
> Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; teep <teep@ietf.org>
> 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 <teep-bounces@ietf.org> on behalf of Wheeler, David M <david.m.wheeler@intel.com>
> 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:teep-bounces@ietf.org] On Behalf Of Jeremy O'Donoghue
> Sent: Tuesday, April 4, 2017 7:13 AM
> To: Tero Kivinen <kivinen@iki.fi>
> Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; teep <teep@ietf.org>
> Subject: Re: [Teep] My BoF impression
>
>
>
>
> On 4 Apr 2017, at 12:21, Tero Kivinen <kivinen@iki.fi> 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
>
>
>
> _______________________________________________
> TEEP mailing list
> TEEP@ietf.org
> https://www.ietf.org/mailman/listinfo/teep
>