Subject: Re: [Teep] Implementation feedback on draft-ietf-teep-opentrustprotocol-01

From: Mingliang Pei <[email-masked]>
Date: Tue, 17 Jul 2018 03:15:34 +0000

Very good comments, Dave. Please see my comments inline (with [MP]), Ming

From: TEEP <[email-masked]> on behalf of Dave Thaler <dthaler=[email-masked]>
Date: Monday, July 16, 2018 at 11:00 AM
To: Andrew Atyeo <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teep] Implementation feedback on draft-ietf-teep-opentrustprotocol-01

Andrew writes:
…

1)      Section 6.5 explains that the TAM needs to receive a list of one or more

TA’s that are requested to be installed (S6.5.1 point 1A).  However, no

message is defined for doing so, which prevents interoperability.  I
think this message needs to be generated by the TEE (not the rich app),
for reasons I will explain in #3 below.

[AA] I don’t see the need for a message for defining the TAs that need to be installed. The OTrP messages are between the TAM and the TEE, but the desire to install TAs comes from the rich app.  In practice, a rich app will have the identifiers of the TAs it requires built into its own code, since its own code will also be calling those TAs (e.g. once installed, to perform some DRM or payment authentication). Therefore a rich app is aware of the TAs it needs.  I don’t think this info can come from the TEE – since at this point the TA is not installed yet, so which part of the TEE would have the knowledge of which TAs are needed?

As I noted in my arch doc comments, I disagree that there needs to be any communication between the rich app being installed, and the TAM.  A valid implementation model should be that the app store installer reads the metadata (including TA dependencies) about the rich app, and as part of installing the rich app (without ever needing to run it), the installer can communicate with the TEE to express those dependencies, which then triggers the TEE to generate a signed message to the TAM, which can be related by the installer.

[MP] The requested TA by a Rich App can go by itself, or noted by an installer via its metadata. It fundamentally express the need. It may not matter it is the Rich App or an installer that does the job on behalf of the Rich App to make the call.  That was intentionally left out of the scope. We left this choice to the Rich App itself. It can do itself, or leverage an installer or other program to do it.

The main interface for interoperability is what TEE should prepare to accept from a Rich App or an installer in REE. This was the intent of an OTrP agent.

There is one major difference in contacting TEE first vs. contacting TAM first. When a Rich App or an installer being its delegate lets TEE to generate a request, a TEE needs authorize such a request. There is some role relationship to agree on here. A device is managed by a TAM, and TAM’s initiated call can be authorized by a TEE. Now, does the TEE have to authorize both an installer / Rich App intent and also a TAM for a TA installation? Or you mean by “related by the installer” that the first authorization is delegated from TEE to TAM, and TAM will make a decision whether it will honor an installer’s request about a Rich App’s desire to use a TA that it manages, right?

---

In the less efficient model where the rich app has to be run, as the doc implies, the same process can occur where the TEE generates the message in response to the rich app telling the agent it has a dependency.

[MP] true, this is one of the models.

…

Putting my issue #1 and issue #2 together means there’s an extra round

trip that is unnecessary.  6.5 says the TAM receive a list of TAs needed,

and then the TAM just goes back and asks what is installed, just to get
a list of what needs to be installed.  This is unnecessary, the TEE can just

send a list of one or more TAs that need to be installed and aren’t already.

Hopefully this explains why I said in issue #1 above why I think the message
needs to be generated by the TEE.

[AA] but how could the TEE (which doesn’t have its TAs loaded yet) know what TAs should be loaded?

The same piece of code that connects to the TAM tells the TEE what TA’s it desires.

The TEE then generates a message with the list of TAs that aren’t already installed.

[MP] See authorization comment above for how a TEE authorizes a request from a Rich App / installer. Delegated flow would mean that it always accept a request, and generates a request. Would this cause some spam and attack issue to the TEE? On the other hand, TAM is given to handle its clients being Rich App or an installer in a REE etc, which is out of the scope in our design.

…

3)      Section 6.5.1 point 9.A implies that to install a TA, one must have an extra
round trip first to create an SD if one isn’t already there.  I would expect one
common case to be where there is one TA per SD, so that all TAs are isolated
from each other.  As such, requiring the extra delay is inefficient in time,
bandwidth, and processing.   All the fields in CreateSD are already present
in an InstallTA message (except the “did” field mentioned above in issue #5),
so it could be done automatically by the first InstallTA message itself.
[AA] when the SD is created, an asymmetric keypair is generated (spaik), and the public part of this is returned. When a TA is installed, it is encrypted with this key. This enables some use cases where a TAM could interface to a SP and enable an SP to provide the TA encrypted such that the TA binary is not known by the TAM.
The spaik is also used to encrypt the personalization data (that is also sent in InstallTA), and there is also a use case for a TAM interfacing to an SP in order that the SP encrypts perso data for that TEE such that it travels via the TAM to the TEE, but without the TAM having access to that data
Since InstallTA requires knowledge of the public key returned from CreateSD, it is true that the extra round trip is required.
So the question is whether there is a case for installing TA (and their accompanying perso data) without the ability to provide confidentiality between an SP and the TEE by making that layer of encryption optional, and by allowing the TA (and perso data?) to be bundled into CreateSD

My main point is that it should be possible to combine CreateSD into the first InstallTA and be more efficient.
Also remember that the TA binary need not come from the TAM.

[MP] This could be an option, I think, when a TA binary encryption isn’t needed. However, we did elaborate this in the very beginning of protocol design whether we give such an option. We (OTrP Alliance at the time) agreed that the protection of TA binary itself is very valuable. You don’t want someone to reverse engineer your TA code that makes exploit finding easier. In the current design, a TA binary code is never given clear to any Rich App or MITM. It is only known by the developer and then the running device TEE itself. This was a very important design goal in this protocol.

4)      The scope of uniqueness of the “rid” and “tid” fields is underspecified.

They just say “unique”.  I think “rid” is just supposed to be unique within

a given {session,”tid”} but I can’t tell for sure.  And I think “tid” is just supposed
to be unique within a given session (not globally across all sessions, all TAMs,

all devices), but I can’t tell.   They’re also formatted as strings, but I’m not sure
why they can’t be integers which I think would be much more efficient..

[AA] although it is not mandated, random guids can be a viable implementation choice for these (as it takes away the requirement to manage incremental counters) – so I would not want to see these become integers. By making them strings, a TAM can choose the mechanism it wants.

I take your point about “rid” and “tid” being underspecified. The truth is that values contained in these fields don’t matter to the protocol much. (they are mostly for the convenience of the TAM in order to match up request and response messages (rid), and (tid) to understand which messages belong in a ‘conversation’)

Unless there is a reason a guid is actually needed (e.g., global uniqueness), I would argue against that additional complexity.

If all you need is uniqueness within a session, a simple sequence number would suffice.

[MP] Open suggestion for this to be more normalized. It is used as an internal linking by the TAM itself, as Andy commented.

5)      I found it confusing that the names of the messages don’t match the name values
in the messages themselves (“GetDeviceStateResponse” vs

“GetDeviceTEEStateTBSResponse”, etc.)   Having these not match is bug-prone.

[AA] I agree. Instead of having a mixture of GetDeviceStateXXX and GetDeviceTEEStateXXX they should all standardize on GetDeviceTEEStateXXX.

Node that there are intentional differences at the end of those words (e.g. GetDeviceTEEStateTBSResponse vs GetDeviceTEEStateResponse is intentional as one of these is the ‘to be signed’ data and the other is the signed data.

I don’t understand, and the terms seem to be interchangeable in the doc, so if there is a distinction, it’s not explained clearly in the doc.

[MP] There is a difference there. The document says:

“The final GetDeviceStateResponse response message consists of an array of TEE responses.”

6)      It’s unclear whether a rich app can depend on two TA’s from different TAMs,

and whether a TA can depend on a TA from a different TAM.  In the use case

where the device admin runs the TAM and controls all TAs on their devices the

answer would be no.  But in other use cases I’m not sure.   If so, then the question
arises about how dependencies are expressed and whether a dependency needs
to express which TAM is used.  This then begs the questions of whether a TA might
be via more than one TAM, or might change TAMs over time.   The answers here
probably belong in the arch doc.
[AA] TA inter-dependency is completely out of the scope of the OTrP protocol. (so the rich app vendor needs to know all the TA IDs they need installing, and which TAM(s) to get them from).

TAs inherently can depend on other TA’s.  I don’t think it should be out of scope for the WG.

[MP] Let us discuss this more. In theory, there could be all chaining dependencies. It isn’t common today. When TA1 uses TA2, would TA1 installation by TAM and TEE will need to check existing of TA2?

[MP] Overall, thanks for your great questions and suggestions of some alternative models.

Dave

---

From: "Wheeler, David M" <[email-masked]>
Date: Tue, 17 Jul 2018 13:30:42 +0000

I think this conversation about the communication of the installation of the Application and dependent TAs is going to be a very interesting one.

As I will discuss in my talk today, the model that Ming has does not work with SGX, because there is no TEE resident component to talk with that “knows” all the TAs installed. The model that Ming outlines is architecture specific to TZ, and is based on an all-knowing, omni-potent TEE (like a Trust Zone kernel), but this does not exist in other TEEs – specifically SGX.

We need to work to extract the most important elements, and leave the rest to implementation details.
I completely understand the need (form TZ perspective) to have the dependency message.

Look forward to an exhilarating conversation today!

Dave Wheeler

From: TEEP [mailto:[email-masked]] On Behalf Of Mingliang Pei
Sent: Monday, July 16, 2018 8:16 PM
To: Dave Thaler <dthaler=[email-masked]>; Andrew Atyeo <[email-masked]>; [email-masked]
Subject: Re: [Teep] Implementation feedback on draft-ietf-teep-opentrustprotocol-01

From: TEEP <[email-masked]<mailto:[email-masked]>> on behalf of Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>>
Date: Monday, July 16, 2018 at 11:00 AM
To: Andrew Atyeo <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teep] Implementation feedback on draft-ietf-teep-opentrustprotocol-01

Andrew writes:
…

---

…

…

Dave

---

From: Dave Thaler <[email-masked]>
Date: Tue, 17 Jul 2018 14:35:46 +0000

Mingliang Pei writes:
...
> There is one major difference in contacting TEE first vs. contacting TAM first. 
> When a Rich App or an installer being its delegate lets TEE to generate a request,
> a TEE needs authorize such a request. There is some role relationship to agree
> on here. A device is managed by a TAM, and TAM’s initiated call can be authorized
> by a TEE. Now, does the TEE have to authorize both an installer / Rich App intent
> and also a TAM for a TA installation? Or you mean by “related by the installer”
> that the first authorization is delegated from TEE to TAM, and TAM will make a
> decision whether it will honor an installer’s request about a Rich App’s desire to
> use a TA that it manages, right?

The installer's request is just a request, regardless of whether it's sent to the TAM
or the TEE.  It can only be authorized by communication between the TAM and the
TEE, regardless of which side initiated it.   It's simply far more efficient to contact
the TEE first, since that does not require a network message.

I have a diagram that I will present in the meeting (which Ming has already seen).

…
> Delegated flow would mean that it always accept a request, and generates a
> request. Would this cause some spam and attack issue to the TEE? On the other
> hand, TAM is given to handle its clients being Rich App or an installer in a REE
> etc, which is out of the scope in our design.

There's a potential spam attack issue on whoever the installer/rich app
contacts first.   In the document's model, it's a spam/attack issue against the
TAM.   I claim it's slightly more efficient to defend against it when talking to
the TEE first, since it does not involve network messages and so is a less severe issue
to deal with.   E.g., a rich app sending 10000 messages to a TAM consumes
more resources than a rich app sending 10000 requests to its own TEE,
and a TAM has to scale to far more rich apps (many per device) than a TEE does
(just the ones on the local device) so the problem is more severe at a TAM.
 
...
> My main point is that it should be possible to combine CreateSD into
> the first InstallTA and be more efficient.
> [AA] when the SD is created, an asymmetric keypair is generated (spaik),
> and the public part of this is returned. When a TA is installed, it is encrypted
> with this key. This enables some use cases where a TAM could interface to
> a SP and enable an SP to provide the TA encrypted such that the TA binary
> is not known by the TAM.
>
> The spaik is also used to encrypt the personalization data (that is also sent
> in InstallTA), and there is also a use case for a TAM interfacing to an SP in
> order that the SP encrypts perso data for that TEE such that it travels via
> the TAM to the TEE, but without the TAM having access to that data
> Since InstallTA requires knowledge of the public key returned from CreateSD,
> it is true that the extra round trip is required.
> So the question is whether there is a case for installing TA (and their
> accompanying perso data) without the ability to provide confidentiality
> between an SP and the TEE by making that layer of encryption optional,
> and by allowing the TA (and perso data?) to be bundled into CreateSD
> 
> [MP] This could be an option, I think, when a TA binary encryption isn’t
> needed. However, we did elaborate this in the very beginning of protocol
> design whether we give such an option. We (OTrP Alliance at the time) agreed
> that the protection of TA binary itself is very valuable. You don’t want
> someone to reverse engineer your TA code that makes exploit finding easier.
> In the current design, a TA binary code is never given clear to any Rich App
> or MITM. It is only known by the developer and then the running device TEE
> itself. This was a very important design goal in this protocol.

I think we're convoluting two separate things here:
1) The notion of an isolation boundary around one or more TAs.  An SP
can have multiple such instances within a TEE, e.g., one per TA is a common
case.
2) The notion of a cryptographic context (spaik) between an SP and a TEE,
to allow for use cases where the TAM should not have access to certain
information (e.g., decrypted TA binary, etc.)

In my view, for scalability these need to be kept as separate things, since
the granularity is different.  If an SP has 100 TAs per device, I think it should
need only 1 key, not 100 of them.

... 
> [MP] Let us discuss this more. In theory, there could be all chaining dependencies.
> It isn’t common today. When TA1 uses TA2, would TA1 installation by TAM and
> TEE will need to check existing of TA2?

Yes.

In general apps can depend on other things being installed
that themselves depend on other things, this is not new.  All I'm saying is that the
same dependency models people use for apps today will happen for TAs too.

Dave