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

[Dave Thaler <[e-mail]>]

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.
> Also remember that the TA binary need not come from the TAM.
>
> [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.

... 
> 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?

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