Re: [Teep] My BoF impression

["Wheeler, David M" <[e-mail]>]

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]>
Cc: Hannes Tschofenig <[e-mail]>; teep <[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:


  1.  A mechanism for managing Trusted Applications and their associated secrets and key material in a GlobalPlatform TEE or something that is conceptually very similar.
  2.  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.
  3.  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