Minutes IETF98: teep
minutes-98-teep-00

TEEP BoF

Chairs introduced themselves.

Hannes began an overview.


Background covered various form of isolation.
Software environments would receive additional code reviews.

TEs that sit along rich execution environments

10,000 foot view includes Rich OS/Linux in the REE and trusted apps
and oses in the TEE all sitting atop a hardware platform.

The terminology comes from other organizations (The Global Platform)

Example: a banking application would want to have access to certain
certificates. Maybe there is a "trusted UI".

This is in home routers and even in the Raspberri Pi

This is a bit more than just a smart card function

The concept extends to the bus and peripherals.

There is a defined message passing interface as an API to transition
internally within the CPU and software stacks to get between different
environments 

It is this transition that is particularly important for this BoF

The concepts have been worked out, and hardware manufacturers have
developed chips that support this architecture. 
But provisioning software in this environment is done today using
proprietary techniques.  There is some fragmentation in the market. 
The uptake of this technology that could be used for different use
cases has been somewhat limited. 

Wouldn't it be great if we had a standard way to install, update, and
delete software? 
We might just need a bit of security around such a process.

And so the specification has a number of security aspects

Mohit: applications have to be provisioned into the TEE.  I'm a
developer sitting in a basement.  Is it only trusted applications that
can have access and what makes an application trusted? 

Hannes: defer to later, but it depends on the hardware.  Raspberri pi
is completely open.  Other environments can be locked down, 

IETF work TBD: A protocol

on the sreen is a slide containing the various entities that are
reflected in the Open Trust Protocol (OTrP) using JSON/JOSE  

there is a bit of back and forth because the TEE needs to authenticate
that it is talking to the right trust application manager. 

The grey arrow in the strawman uses a JSON-based encoding and that is
what we are trying to define here. 

Kent Watson: typically an application might bundle a firmware image.
Would that work here? 

Hannes: target market is mobile phones and tablets, because there is a
lot of hardware in the field.  

Kent Watson: why couldn't use existing mechanisms?

Chair: defer to conversation later, please.

Dapeng Liu: only portions of an application are trusted, and so
sometimes it is useful to update each component separately. 

Hannes: we'll discuss this more later

Envisioned User Experience

App developer uploads the app to the Google store and the trusted app
to the "TAM" (trusted application manager?) 

The system only updates from the TAM when the hardware is there.  And
there is authorization involved in step 3 and 4. 

Hannes then moved on to the ARM TrustZone

Different profiles for different use case.
The BoF is mainly for high power processors, not for light weight stuff
ARM then has its own terminology for some of the terms

David M Wheeler (Intel) next presented remotely

TEE Variations

TEEs are there to provide some form of protection that is not
available in the rich o/s side. 
As the TCB grows there's less and less trust
Otherwise we would use other protections.
There are reasons to want to separate particularly sensitive
operations into a separate container 
He then ran through the list on the slides
How do you prove to other parties that your code is trusted?

type and capability of root of trust
does it attest to just firmware or also code?
Can the TEE be used to derive keying materials?

Anonymity
There are different types of anonymous protocols and algorithms

And then David provided a list of environments they support.

SGX
Instead of having a secure world, you have the ability to set aside
some memory, and then you have the ability through CPU instructions to
establish a TEE.  And it's in the same process space as the process
that launched it. 
Intel supports the concept of delivering app along with the trusted piece.

DaL  Dynamic Application Loader uses a cryptoprocessor that's on the
same dye as the CPU.  If your code is signed by the proper key you can
load applets to that environments, but unlike SGX the apps are not
tied to a single application environments. 

Then on to the obligatory picture diagram
But he nicely summarized this page without delving into detail

Differences between SGX and TrustZone
 - load on demand via special instructions
 - launching process is verified by the launcher.  And the launcher
 operates, in effect, as the "TSM". 
Current architecture has an external TSM.

In SGX we use the root of trust to derive keys for an enclave.  This
creates the ability to bind secrets to both the platform and the
trusted app, 
Sometimes one needs a small O/S to arbitrate between apps.  SGX
provides that separation by default.  Certain protocols are required
in order enable sharing between  
enclaves.

The point is that there are very different models that we might wish
to acccomodate with this work 

Attestation can provide complete anonymity to the application being
attested. 

Then what of the charter?
Supporting different types of TEES as well as multiple both
cooperating and non-cooperating TEEs. 
Privacy is important
Must support validation of TEE trust by cryptographic means
There may not be a need to have an outside manager.
  
Eliot Lear asks David: there may or may not be a need for external
services, can you expand on that?

David: in the case of SGX, trusted app can be embedded in the
untrusted application and delivered as one group to a platform,
current infrastructure and protocols from today can be used 
  
For certain other TEEs a trust protocol may be helpful.  Even though
we can point out cases where a protocol ISN'T necessary, having the
uniform protocol is still a benefit. 

Dapeng Liu

Use cases

Use case 1: Payment

In China there are a lot of mobile payment applications.  The banks
provide the apps and the users can just use their phones.  3rd party
payment providers  may also have autopay services that run on the
user's phone.  We need better and more secure ways.  We're looking for
ways to use the user's fingerprint in a secure way. 

Why not use phone applet?  We need a standard protocol that can
operating between different layers of the ecosystem and can address
different types of the TEE technology. 

Part of this use case involves a secure keyboard application.

Enterprise Authentication

BYOD is very popular, but some enterprise applications may be
sensitive, that include credentials.  How to provide isolation in this
case?  Enterprises need a simple way to install/update/delete the
trusted applications without the help of OEMs. 

TEEP Architecture
Mingliang Pei (Symantec)

Starts off by asking who has seen the draft.  A few hands
Then a nice marketing slide intended to describe the ecosystem.

There are a few high level decisions:
     - Use a PKI (manufacturer-provided kesys and trust anchors)
     - Start with JSON because it is "light weight" and standardized.
     - We introduce an OTrP Agent in REE to relay messages through a standard API.

Device has a single TEE only

Then an architectural overview diagram

Who gets to update the trusted environment?  User gets to decide or ...

Next slide

Messages are signed and encrypted end-to-end

We only need to define trust establishment information; how messages
are delivered via a network between rich and TAM is not necessary to
standardize. 

Next a slide on keys
What keys and certs are needed in which part of the solution.

Different regions may use different CAs for for different SPs

The protocol specifically defines trusted messages

Relationship diagram

Protocol flow with a swimming lane diagram
3 phase diagram
Flows allow for signing and encrypting of applications.
Creates a secured domain for a given service provider
Device decrypts, verifies images,  and installs the app.

++++++++

Ben Kaouk:  TE and TSMs have private applications where the user can't
see what's going on.  That leaves open the possibility for a privacy
risk. 

Mingliang: Trusted Application Manager has the scheme to deal with
this and privacy was an important part in the protocol design.

PHB: All I want is the ability to do a private key operation.  Going
beyond that doesn't get me much?  Doesn't want a full Turing machine 

Mingliang: Good point [on no need of Turing machine and lightweight
trusted application types].
there needs trust apps, and types of trust apps doesn't need to be a
complete heavy application as Dapeng mentioned earlier in the use cases.

Hannes, responding to Ben: these privacy concerns show up at different
levels.  Attestation releases information by design.  There are
mechanisms to avoid linkability, but there are some pros and cons for
each mechanism.  We should discuss more on the list. 

To PHB's point: we have come up with these technologies because there
is a demand for features more powerful than a SIM card.  For example:
trusted display, trusted input.  These were specific hardware
components that people have demanded.  In the IETF we don't work on
hardware, but having an understanding of the purpose and limitations
of the hardware is useful. 

Yaron Schaffer: how viable is this?  Google and others want to have
very tight control on your device.

Mingliang: there are multiple app stores, and there are some trusted
applications. There are already existing practice by some TAM vendors
who distribute trusted apps outside of Google app store.

Hannes:  we are working with some companies to prove that this is not
just a research exercise.  There may also be some networking use
cases, maybe with (for example) I2NSF.

Erik Nordmark: the various documents should be openly available.

Mingliang: protocol is a draft.

Erik: are there other things that people would need to have access to
to implement this?

Hannes: for specific hardware you might want some additional code and
documents, and he pointed to some of the documents.  One would
probably use a [device specific] SDK.

Erik: but we might need the information in order to properly design
the protocol.

Erik: what is unique about this protocol that could be used to
updating TEEs versus other enviroments?  Would it be capable of
updating other environments?

Hannes:  could be used for IoT firmware update, and we need an
application layer security mechanism.  Attestation doesn't quite match
with some of the other cases.

Hannes: we replace the whole image.

Hannes: looked at linux distribution mechanisms, but no attestation
concepts.

Chris Nasio, CMU: a lot of shared concepts from TPM.  I've never seen
a CA that validated my TPM chip?  Who's going to do that?

Mingliang: that's a provider question.  This defines a scheme, not who
plays the roles.


Lots of talk about Qualcomm

Chris Nasio: you are asking for a substantial financial commitment
associated with CA management.  Has anyone signed up to write the
check?


Hannes: we are recommending even to our IoT vendors to use secure
credentials that we recommend in general

Mingliang: this is a best practice.  You need a root of trust.

Markus from NCSA: question around the mobile use case: might overlap
with FIDO alliance that is addressing a similar problem.  This is
somewhat wider.

Hannes: folk from FIDO should speak up

???: From the developer perspective it makes sense to lower the
threshold to develop such applications.  From the smartphone vendors'
perspectives will it increase security strength to the users?


AND the Mics are closed

Tero, as chair:
    
Does the group understand the work to be done?
More people hummed yes than no but it was only by a bit.  Not convincing.
How many people are interested in working on this?
about 14-15 people.

Kathleen:
    We'll continue on the list.