Re: [Teep] use case document comments

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

Hi Michael, Teep group,

I have tried to clarify some of Michael’s questions/comments below. I generally agree with his assertion that the use cases lack detail about:

  *   What assets are involved and who owns them.
  *   What attacks are envisaged.
  *   What are the security assumptions.

I see no use of requirements (RFC2119) language in the document, so it is unclear how requirements derive from this document - perhaps this reflects my unfamiliarity with IETF processes. RFCs 7515, 7516, 7517, 7518 are not referred to in the document - they should be removed from the list of normative references.

On 15 Mar 2017, at 01:06, Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:


Thank you for the use case document.
I think that there is a need in the use case document to explain who owns the
code inside the TEE.  (It seems that a device like a smartphone would need a
multitude of TEEs)

Current generations of Smartphones contain a single TEE (I am unaware of any current deployment of multiple TEE in a single device, although it is theoretically possible).

As a generalisation, OTrP is addressing an execution environment in which there are multiple actors contributing code. Typically

  *   Secured boot loader and firmware (e.g. device drivers). This is typically supplied by the SoC vendor and/or device OEM. The use case document uses two terms for this: SBM (Secure Boot Module) and TFW (Trusted Firmware). Personally I prefer SBM as “Trusted Firmware” may be confused with a specific ARM technology.
  *   The TEE kernel and application level APIs (TEE). This may be supplied by a third party of by an SoC vendor, depending on the device.
  *   Trusted Applications (TAs) - these are supplied by Service Providers.

TAs have to trust the code provided by the TEE and SBM. They must also trust the sandboxing between TAs that is assured by the TEE. This can be assessed by independent security evaluations such as that offered by GlobalPlatform<https://www.globalplatform.org/teecertification.asp> or under the Common Criteria, if the use case requires it.

OTrP organises TAs under Security Domains (SDs). An SD is simply a representative of a Service Provider or (usually) its delegate. It is basically a set of keys and permissions.

3.1. Use Case 1 - Payment

So on the one hand the document suggests that the TEE will contain personal
information relating to payment, so be securely unlocked by the end user via
some kind of SecureAttentionKey interface.   A private key, or perhaps an
anchor for a blockchain signer....
So the end user needs to intimately control what code is inside (i.e: be able
to delegate that trust to a party that they trust).

Then the document says:
    For the development of the relevant TA of SP, the
    use of OTrP can easily send the latest trusted application to the
    device.

I get the impression that the bank is going to send updates to the trust
application.   But, it's the bank that I'm going to dispute a payment with,
so in fact, I can't let them create the audit trail at my end.

The assumption is that the end user trusts their bank. TA updating here should be seen more as a matter of updating for new features and/or security fixes. It is similar to the Smartphone “App Store” model of updates. You do need to trust that your bank will not destroy any audit trail in the device as part of an update.

If the TEE being controlled implements the GlobalPlatform APIs (this is true for many deployed TEE implementations), there is a set of trusted storage APIs which provide mechanisms allowing persistence of secure data across TA updates.

No use case was given for media, yet that was mentioned.
Nor Enterprise.

In each case, I think that the contents of the TEE are controlled by a
different party.  And each party seems to want to control the screen and
keyboard.

There are many use cases which do not require user interactions to be under the control of the TEE - for example if signing and/or encrypting data which was generated in the REE (e.g. Android, Windows, Linux).

GlobalPlatform compliant TEE implementations can implement APIs supporting secured control of display, touchscreen input and biometric authentication if these use cases are required. The GP APIs essentially guarantee that only one TA controls the relevant peripherals using a transaction, and provides mechanisms to indicate this to the user. There are commercial deployments of all of these APIs.

It is probable that components such as secured input and/or display contain significant components in all of the TEE kernel, SBM and REE (due to the need to orchestrate ownership of peripherals).

Since OTrP explicitly manages only TAs, it is not obvious to me that a large class of potential security bugs can be fixed using OTrP alone. A good example is at https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking.pdf. This type of exploit can probably only be fixed with a complete system update. I am uncomfortable with any use case implying that OTrP can be used to patch system level vulnerabilities such as keyboard and display.

3.2.  Use Case 2 - IoT

The only example here given is smart door locks.
I think that this is really confused.   The most important thing the TEE can
do is to provide original bootstrap process, and then yes, storage and update
of session keys.   After putting all that in the TEE, what's actually left?

I believe the intention here is to indicate that the session keys are stored and owned in a TA rather than in the TEE itself. This might allow e.g. a hotel chain to use multiple vendors of door-locks and manage them from a single system (TSM) of its own.

====

Based upon what I have read so far, I can't see a role for the IETF, but I
continue to read with an open mind.

Best regards
Jeremy