Re: [Teep] My BoF impression

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

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