Re: [Teep] use case document comments

[Dapeng Liu <[e-mail]>]

Hi Jeremy,

Thanks for the clarification and comments.
We will update the draft soon.

Thanks,
Dapeng Liu
On Wed, Mar 15, 2017 at 6:49 PM Jeremy O'Donoghue <[e-mail]>
wrote:

> 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]>
> 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
> _______________________________________________
> TEEP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teep
>