[Teep] review on draft-ietf-teep-architecture-08

[Daniel Migault <[e-mail]>]

Hi,

I reviewed the draft-ietf-teep-architecture-08 and please find my comments
below.

Yours,
Daniel



     Trusted Execution Environment Provisioning (TEEP) Architecture
                    draft-ietf-teep-architecture-08

   The Trusted Execution Environment Provisioning (TEEP) protocol
   addresses the following problems:

   -  An installer of an Untrusted Application that depends on a given
      TA wants to request installation of that TA in the device's TEE so
      that the Untrusted Application can complete, but the TEE needs to
      verify whether such a TA is actually authorized to run in the TEE
      and consume potentially scarce TEE resources.

   -  A TA developer providing a TA whose code itself is considered
      confidential wants to determine security-relevant information of a
      device before allowing their TA to be provisioned to the TEE
      within the device.  An example is the verification of the type of
      TEE included in a device and that it is capable of providing the
      security protections required.

   -  A TEE in a device wants to determine whether an entity that wants
      to manage a TA in the device is authorized to manage TAs in the
      TEE, and what TAs the entity is permitted to manage.

   -  A TAM (e.g., operated by a device administrator) wants to
      determine if a TA exists (is installed) on a device (in the TEE),
      and if not, install the TA in the TEE.

   -  A TAM wants to check whether a TA in a device's TEE is the most
      up-to-date version, and if not, update the TA in the TEE.

   -  A TA developer wants to remove a confidential TA from a device's
      TEE if the TA developer is no longer offering such TAs or the TAs

      are being revoked from a particular user (or device).  For
      example, if a subscription or contract for a particular service
      has expired, or a payment by the user has not been completed or
      has been rescinded.

   -  A TA developer wants to define the relationship between
      cooperating TAs under the TA developer's control, and specify
      whether the TAs can communicate, share data, and/or share key
      material.

<mglt>

I believe that the intent of these example was to
provide a high level description of the goals of
the architecture. I think it is necessary to
introduce TA and untrusted Application, but I do
not think TAM needs to be mentioned.

</mglt>

   Note: The TA developer requires the help of a TAM to provision the
   Trusted Applications to remote devices and the TEEP protocol
   exchanges messages between a TAM and a TEEP Agent via a TEEP Broker.

<mglt>

I am incline to think that such clarification
comes too early and mostly because TAM has been
introduced.

</mglt>

2.  Terminology

   The following terms are used:

   -  Device: A physical piece of hardware that hosts one or more TEEs,
      often along with a Rich Execution Environment.  A device contains
      a default list of Trust Anchors that identify entities (e.g.,
      TAMs) that are trusted by the device.  This list is normally set
      by the device manufacturer, and may be governed by the device's
      network carrier when it is a mobile device.  The list of Trust
      Anchors is normally modifiable by the device's owner or Device
      Administrator.  However the device manufacturer or network carrier
      (in the mobile device case) may restrict some modifications, for
      example, by not allowing the manufacturer or carrier's Trust
      Anchor to be removed or disabled.

<mglt>

>From the definition it is unclear to me where the
Trust Anchors are stored. I think the definition
should specify the trust anchors are stored in the
TEEP Agent explicitly.

</mglt>

   -  Trusted Application (TA) Developer: An entity that wishes to
      provide functionality on devices that requires the use of one or
      more Trusted Applications.

<mglt>
It is not clear why we have something more complex
than an entity that publishes, implements TAs. The
way I read the text is that functionalities are
using TAs which might be closer to an untrusted
application.

<mglt>


3.  Use Cases

3.1.  Payment

   A payment application in a mobile device requires high security and
   trust about the hosting device.  Payments initiated from a mobile
   device can use a Trusted Application to provide strong identification
   and proof of transaction.

   For a mobile payment application, some biometric identification
   information could also be stored in a TEE.  The mobile payment
   application can use such information for unlocking the phone and for
   local identification of the user.

   A trusted user interface (UI) may be used in a mobile device to
   prevent malicious software from stealing sensitive user input data.
   Such an implementation often relies on a TEE for providing access to
   peripherals, such as PIN input.

<mglt>

It is unclear to me whether this is a single use
case or many use cases related to the payment. It
believe it would be clarifying to describe a
little bit more what the TA does as well as the
interactions with the untrusted applications.
Typically it seems that the UI is part of the TA,
which guarantee trusted inputs. I am wondering
what mechanism or trust is necessary to actually
trust the output of the TA. In other words why the
"True" from the TA should be more trusted than the
PIN values.  It seems important to consider that
anything coming out to the untrusted world can be
tampered or replayed - even the output of the TA.
Given the example, it seems to me hard to
understand how TA are used.

</mglt>

3.2.  Authentication

   For better security of authentication, a device may store its keys
   and cryptographic libraries inside a TEE limiting access to
   cryptographic functions via a well-defined interface and thereby
   reducing access to keying material.

<mglt>

Though I am biaised, draft-mglt-lurk-tls12 and
draft-mglt-lurk-tls13 are example of this.
</mglt>

3.3.  Internet of Things

   The Internet of Things (IoT) has been posing threats to critical
   infrastructure because of weak security in devices.  It is desirable
   that IoT devices can prevent malware from manipulating actuators
   (e.g., unlocking a door), or stealing or modifying sensitive data,
   such as authentication credentials in the device.  A TEE can be the
   best way to implement such IoT security functions.


<mglt> quite broad... but ok.;-) </mglt>




Pei, et al.              Expires October 6, 2020                [Page 7]

Internet-Draft              TEEP Architecture                 April 2020


3.4.  Confidential Cloud Computing

   A tenant can store sensitive data in a TEE in a cloud computing
   server such that only the tenant can access the data, preventing the
   cloud hosting provider from accessing the data.  A tenant can run TAs
   inside a server TEE for secure operation and enhanced data security.
   This provides benefits not only to tenants with better data security
   but also to cloud hosting providers for reduced liability and
   increased cloud adoption.

<mglt>

This use case is useful as the document is heavily
focused on devices. This use case introduces the
notion of tenants that do share the resource of
the device - or server. The Device Administrator (
cloud provider) will authorize a tenants' TAM
and provision a specific TEE with Trusted Anchors
for the tenants.  I am also wondering how two
concurrent TEEs from different tenants can remain
isolated. Isolation is probably something that
should be described in the security
considerations.

</mglt>

4.  Architecture

4.1.  System Components

   Figure 1 shows the main components in a typical device with an REE.
   Full descriptions of components not previously defined are provided
   below.  Interactions of all components are further explained in the
   following paragraphs.

   +-------------------------------------------+
   | Device                                    |
   |                          +--------+       |        TA Developer
   |    +-------------+       |        |-----------+              |
   |    | TEE-1       |       | TEEP   |---------+ |              |
   |    | +--------+  |  +----| Broker |       | | |  +--------+  |
   |    | | TEEP   |  |  |    |        |<---+  | | +->|        |<-+
   |    | | Agent  |<----+    |        |    |  | |  +-|  TAM-1 |
   |    | +--------+  |       |        |<-+ |  | +->| |        |<-+
   |    |             |       +--------+  | |  |    | +--------+  |
   |    | +---+ +---+ |                   | |  |    | TAM-2  |    |
   |  +-->|TA1| |TA2| |        +-------+  | |  |    +--------+    |
   |  | | |   | |   |<---------| App-2 |--+ |  |                  |
   |  | | +---+ +---+ |    +-------+   |    |  |    Device Administrator
   |  | +-------------+    | App-1 |   |    |  |
   |  |                    |       |   |    |  |
   |  +--------------------|       |---+    |  |
   |                       |       |--------+  |
   |                       +-------+           |
   +-------------------------------------------+

                  Figure 1: Notional Architecture of TEEP

   -  TA developers and Device Administrators utilize the services of a
      TAM to manage TAs on devices.  TA developers do not directly
      interact with devices.  Device Administators may elect to use a
      TAM for remote administration of TAs instead of managing each
      device directly.

<mglt>
I think before going in to the details of each
boxes the architecture should describe the high
level goals of the architecture that is enabling
the management of an TA developed by a TA
Developer on a Device. The messages are exchanged
between the TAM and the TEEP Agent.

What is not so clear to me is whether a TEEP Agent
can validate a TA from a TA developer that is
using a different key than the TAM. I am unsure
everything is based on session security. Suppose I
would like a TEE only running TA from Vendor X
independently from the TAM. If such validation
occurs it is also unclear to me the validation
occurs in the TEE or is performed by the TEEP
agent.

It also clarifies to explicitly mention that
Brokers are not expected to terminate the session
between the TAM and the TEEP Agent, but are mostly
here to implement networking services in REE that
may not be provided by the TEE, i.e. by the TEEP
Agent.

What I was missing in my first reading was the
terminating points of the sessions. In particular,
in some cases a broker could be a MiM, so it is
better to clarify that it is not the case here. Of
course if my understanding is correct.

<mglt>




Pei, et al.              Expires October 6, 2020                [Page 8]

Internet-Draft              TEEP Architecture                 April 2020


   -  Trusted Application Manager (TAM): A TAM is responsible for
      performing lifecycle management activity on TAs on behalf of TA
      developers and Device Administrators.  This includes creation and
<mglt>
provisioning might more accurate, but that is just
a suggestion.
</mglt>
      deletion of TAs, and may include, for example, over-the-air
      updates to keep TAs up-to-date and clean up when a version should
      be removed.  TAMs may provide services that make it easier for TA
      developers or Device Administators to use the TAM's service to
      manage multiple devices, although that is not required of a TAM.

      The TAM performs its management of TAs on the device through
      interactions with a device's TEEP Broker, which relays messages
      between a TAM and a TEEP Agent running inside the TEE.

<mglt>

Unless specified before I would suggest to
specify the meaning of "relay" and in particular
that authentication of the messages are not
performed by the broker but by the Agent.

</mglt>


      A TA developer or Device Administrator chooses a particular TAM
      based on whether the TAM is trusted by a device or set of devices.
      The TAM is trusted by a device if the TAM's public key is, or
      chains up to, an authorized Trust Anchor in the device.  A TA
      developer or Device Administrator may run their own TAM, but the
      devices they wish to manage must include this TAM's public key/
      certificate, or a certificate it chains up to, in the Trust Anchor
      list.

<mglt>
I have the impression that Trust Anchor Store is
the term used in the Terminology. I also think it
helps clarifying the trust anchors are part of the
Agent... so in a TEE.

</mglt>


   -  TEEP Broker: A TEEP Broker is an application component running in
      a Rich Execution Environment (REE) that enables the message
      protocol exchange between a TAM and a TEE in a device.  A TEEP
      Broker does not process messages on behalf of a TEE, but merely is
      responsible for relaying messages from the TAM to the TEE, and for
      returning the TEE's responses to the TAM.

<mglt>
Same here "relay" here does not involve some kind
of authentication.

</mglt>

   -  Certification Authority (CA): Certificate-based credentials used
      for authenticating a device, a TAM and a TA developer.  A device
      embeds a list of root certificates (Trust Anchors), from trusted
      CAs that a TAM will be validated against.  A TAM will remotely
      attest a device by checking whether a device comes with a
      certificate from a CA that the TAM trusts.  The CAs do not need to
      be the same; different CAs can be chosen by each TAM, and
      different device CAs can be used by different device
      manufacturers.

<mglt>
I have the impression that Trust Anchor has been
the terminology used.

</mgtl>

4.2.  Multiple TEEs in a Device



   Brokers on a particular platform.  In addition, since TEEs may be
   physically separated, with wholly different resources, there may be
   no need for TEEP Brokers to share information on installed TAs or
   resource usage.

<mglt>

I am wondering how multiple TEE could be used as a
way to isolate different tenants. As the broker is
part of the REE it seems that it does not
necessarily need to be set by the Device
Administrator, but eventually by the tenant. Would
it be possible ?

</mglt>

4.3.  Multiple TAMs and Relationship to TAs


   When a TEEP Broker receives a request
<mglt>

Is such a request a TEEP request or
something more abstract ?

</mglt>

from an Untrusted Application
   to install a TA, a list of TAM URIs may be provided for that TA, and
   the request is passed to the TEEP Agent.  If the TEEP Agent decides
   that the TA needs to be installed, the TEEP Agent selects a single
   TAM URI that is consistent with the list of trusted TAMs provisioned
   on the device, invokes the HTTP transport for TEEP to connect to the
   TAM URI, and begins a TEEP protocol exchange.

<mglt>
"""The trusted TAM provisioned on the device"""
seems to indicates that a common Trust Anchor
Store is shared by all TEEs. I suppose that is
provisioned on a per agent base.

My understanding is that the Agent may implement
the HTTP transport but will not treat networking
aspects. These will be instead handled by the
Broker. If that is correct, this could maybe
clarified.

</mglt>

4.4.  Untrusted Apps, Trusted Apps, and Personalization Data


   1.  The Untrusted Application, TA(s), and personalization data are
       all bundled together in a single package by a TA developer and
       provided to the TEEP Broker through the TAM.

<mglt>
Does this scenario corresponds to a push from the
TAM ?
</mglt>


   2.  The Untrusted Application and the TA(s) are bundled together in a
       single package, which a TAM or a publicly accessible app store
       maintains, and the personalization data is separately provided by
       the TA developer's TAM.
<mglt>
The first TAM seems to me related to a push while
the app store corresponds to a pull scenario. I
also understand the second TAM is requested by the
Agent. If that is correct it would be clarifying
to specify the initiator of the request.

</mglt>

   3.  All components are independent.  The Untrusted Application is
       installed through some independent or device-specific mechanism,
       and the TAM provides the TA and personalization data from the TA
       developer.  Delivery of the TA and personalization data may be
       combined or separate.

4.5.  Entity Relations

    (App Developers)   (App Store)   (TAM)      (Device with TEE)  (CAs)
           |                   |       |                |            |
           |                   |       |      (Embedded TEE cert) <--|
           |                   |       |                |            |
           | <--- Get an app cert -----------------------------------|
           |                   |       |                |            |
           |                   |       | <-- Get a TAM cert ---------|
           |                   |       |                |            |
   1. Build two apps:          |       |                |            |
                               |       |                |            |
      (a) Untrusted            |       |                |            |
          App - 2a. Supply --> | --- 3. Install ------> |            |
                               |       |                |            |
      (b) TA -- 2b. Supply ----------> | 4. Messaging-->|            |
                               |       |                |            |

                      Figure 3: Developer Experience

   Note that Figure 3 shows the TA developer as a TA signer.  The TA
   signer is either the same as the TA developer, or is a related entity
   trusted to sign the developer's TAs.

   Figure 3 shows an example where the same developer builds two
   applications: 1) an Untrusted Application; 2) a TA that provides some
   security functions to be run inside a TEE.
<mglt>
isn't it a and b in the figure.

</mglt>
At step 2, the TA
   developer uploads the Untrusted Application (2a) to an Application
   Store.  The Untrusted Application may optionally bundle the TA
   binary.  Meanwhile, the TA developer may provide its TA to a TAM that
   will be managing the TA in various devices.  At step 3, a user will
   go to an Application Store to download the Untrusted Application.
   Since the Untrusted Application depends on the TA, installing the
   Untrusted Application will trigger TA installation by initiating
   communication with a TAM.  This is step 4.

<mglt>
Since the broker requests the TAM I would have
expected the arrow in the other way.

I also have the impression some text is missing
around the cert related arrows.

</mglt>

   It should be noted that network communication capability is generally
   not available in TAs in today's TEE-powered devices.  Consequently,
   Trusted Applications generally rely on broker in the REE to provide
   access to nnetwork functionality in the REE.  A broker does not need
   to know the actual content of messages to facilitate such access.

<mglt>
nnetwork
</mglt>

   Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent
   generally relies on a TEEP Broker in the REE to provide network
   access, and relay TAM requests to the TEEP Agent and relay the
   responses back to the TAM.



9.6.  Malicious TA Removal

   It is possible that a rogue developer distributes a malicious
   Untrusted Application and intends to get a malicious TA installed.
   It's the responsibility of the TAM to not install malicious trusted
   apps in the first place.  The TEEP architecture allows a TEEP Agent
   to decide which TAMs it trusts via Trust Anchors, and delegates the
   TA authenticity check to the TAMs it trusts.

   It may happen that a TA was previously considered trustworthy but is
   later found to be buggy or compromised.  In this case, the TAM can
   initiate the removal of the TA by notifying devices to remove the TA
   (and potentially the REE or device owner to remove any Untrusted
   Application that depend on the TA).  If the TAM does not currently



Pei, et al.              Expires October 6, 2020               [Page 26]

Internet-Draft              TEEP Architecture                 April 2020


   have a connection to the TEEP Agent on a device, such a notification
   would occur the next time connectivity does exist.  That is, to
   recover, the TEEP Agent must be able to reach out to the TAM, for
   example whenever the RequestPolicyCheck API (Section 6.2.1) is
   invoked by a timer or other event.

<mglt>

Given the security assumption of a TEE a rogue TA
will not be able to steal data of the other TA -
which is not the case for applications running in
a REE.

I also believe that some additional considerations
are needed regarding tenants sharing a given
device ( or server).

</mglt>
-- 
Daniel Migault
Ericsson