Re: [Teep] TEEP Architecture Last Call Review

[Ben Schwartz <[e-mail]>]

OK, this seems good to me.  Thanks for the adjustments!

On Fri, Oct 21, 2022 at 9:31 PM Mingliang Pei <mingliang.pei=
[e-mail]> wrote:

> Hi Ben,
>
> Could we have your review of the following replies on three issues we
> think remain to confirm our updates to meet your thoughts? Thank you!
>
> *Issue 1: An Trusted UI example (*Section 3.1), Dave had the following
> comments in addition to Brendon's input in the thread:
>
> TEEP is not just for mobile phones, but also POS devices like chip-and-pin
> readers,
> and that facility is present in some of those, not theoretical.
>
> We have changed the the following
>
> A trusted user interface (UI) may be used in a mobile device
>
> to
>
> A trusted user interface (UI) may be used in a payment device
>
> and updated the text in the preceding paragraphs to say "mobile device or
> point-of-sale device".
> *Issue 2: An IoT device example (*Section 3.3), Dave Thaler gave the
> following example:
>
> "The GlobalPlatform architecture discusses this so there are GP compliant
> devices that do.  I demoed one (just a demo, not a product, but it
> actually did so) myself at Hannover-Messe (the largest industrial fair) a
> few years back."
>
> With your last email, we updated the doc (PR #265
> <https://github.com/ietf-teep/architecture/pull/265>) to add a reference
> to [GPTEE] for examples:
>
> "A TEE can be one of the best ways to implement such IoT security
> functions. *See GlobalPlatform {{GPTEE}} for examples of such devices."
> See *
>
> Issue 3: For your first two comments about the use of the word
> "application" and your suggestion to make them "software" and "component"
> respectively.
>
> We authors discussed, and think that the doc already elaborates the
> definition as follows.
>
> >> "An application component ... is referred to as a Trusted
> Application": This is
>
> confusing. A component, explicitly not an entire "application", is
> referred to
> as an "application". "Trusted Component" would be more consistent.
>
> The protocol spec already uses the term "Trusted Component". The
> architecture doc has defined a TA to mean either an "application component"
> or "an application" in the Terminology Section as follows:
>
>    "- Trusted Application (TA): An application (or, in some
> implementations, an application component) that runs in a TEE"
>
> Note that Trusted Application is actually a common terminology for the
> field, for example, Global Platform (GPTEE
> <https://globalplatform.org/specs-library/tee-system-architecture/>) has
> been referring to it this way. The OP-TEE
> <https://optee.readthedocs.io/en/latest/architecture/trusted_applications.html>
> also uses this terminology.
>
> Could you review and let us know if this is OK to leave it as is?
>
> Thanks,
>
> Ming
>
> On Fri, Oct 21, 2022 at 7:03 AM Ben Schwartz <bemasc=
> [e-mail]> wrote:
>
>> Thanks.  I would suggest adding informative references for the examples
>> that exist, and clarifying that the actuator example is hypothetical if
>> there is no worked example.
>>
>> On Thu, Oct 20, 2022 at 9:41 AM Brendan Moran <
>> [e-mail]> wrote:
>>
>>>
>>>
>>> On 19 Oct 2022, at 21:22, Ben Schwartz <bemasc=
>>> [e-mail]> wrote:
>>>
>>> > Section 3.1
>>>> "trusted user interface" ... can you cite an example of a mobile device
>>>> with a
>>>> trusted peripheral that is not accessible to the REE OS? This seems
>>>> theoretical.
>>>> Need help from co-authors here too.
>>>
>>>
>>> There are a few examples in industry. The PCI-SIG has announced some
>>> relevant work:
>>>
>>> TEE Device Interface Security Protocol (TDISP)
>>>> This document defines the TEE Device Interface Security Protocol
>>>> (TDISP) - An architecture for trusted I/O virtualization providing the
>>>> following functions: 1. Establishing a trust relationship between a TVM and
>>>> a device. 2. Securing the interconnect between the host and device. 3.
>>>> Attach and detach a TDI to a TVM in a trusted manner.
>>>
>>> https://pcisig.com/specifications
>>>
>>> Apple’s Platform Security Guide has a few relevant sections on pages
>>> 17-21. For us, I suspect these two excerpts are most relevant:
>>>
>>> Face ID and Touch ID security
>>>> ...
>>>> Apple’s biometric security architecture relies on a strict separation
>>>> of responsibilities between the biometric sensor and the Secure Enclave,
>>>> and a secure connection between the two. The sensor captures the biometric
>>>> image and securely transmits it to the Secure Enclave.
>>>
>>>
>>> Built-in Touch ID channel security
>>>> Communication between the Secure Enclave and the built-in Touch ID
>>>> sensor takes place over a serial peripheral interface bus. The processor
>>>> forwards the data to the Secure Enclave but can’t read it. It’s encrypted
>>>> and authenticated with a session key that’s negotiated using a shared key
>>>> provisioned for each Touch ID sensor and its corresponding Secure Enclave
>>>> at the factory.
>>>
>>>
>>> https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf
>>>
>>> Between the PCI-Sig work and Apple’s platform security guide we have an
>>> example of a specification for trusted I/O and an example of a mobile
>>> device manufacturer implementing trusted I/O. This is not theoretical; it’s
>>> in production.
>>>
>>> > Section 3.3
>>>> Similarly, are there any examples of IoT devices that prevent the REE
>>>> OS from
>>>> operating certain actuators?
>>>> We will follow up on this.
>>>
>>>
>>> While I can’t provide specific examples of where this was done, I can
>>> provide specific examples of where it should have been done. Medical
>>> devices with network or radio connectivity (therefore IoT medical devices)
>>> should place all sensors and actuators under the control of a TEE.
>>>
>>> Best Regards,
>>> Brendan
>>>
>>> On Wed, Oct 19, 2022 at 9:34 PM Mingliang Pei <mingliang.pei=
>>> [e-mail]> wrote:
>>>
>>>> Thanks Ben. Just update you that we have additional comments and fixes
>>>> based on your suggestions, in particular, expanded on "hostile TAM" and
>>>> administrator notification in the Threat Consideration section, and several
>>>> comments Dave's added that were left open in the last email. Please refer
>>>> to the Github Issue 251
>>>> <https://github.com/ietf-teep/architecture/issues/251> for details.
>>>> Thanks,
>>>>
>>>> Ming
>>>>
>>>>
>>>> On Wed, Oct 19, 2022 at 1:23 PM Ben Schwartz <[e-mail]> wrote:
>>>>
>>>>> Thanks for considering this input!  I haven't read the draft recently,
>>>>> so I don't have more to add on how to address these issues.
>>>>>
>>>>> On Wed, Oct 19, 2022 at 5:32 AM Mingliang Pei <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> Hi Ben,
>>>>>>
>>>>>> Thank you very much for your review and suggestions as tracked here
>>>>>> <https://datatracker.ietf.org/doc/review-ietf-teep-architecture-16-secdir-lc-schwartz-2022-04-04/>.
>>>>>> Somehow we didn't notice it until recently and we have tracked it as Issue
>>>>>> #251 <https://github.com/ietf-teep/architecture/issues/251> in
>>>>>> Github TEEP project.
>>>>>>
>>>>>> We have added inputs for each of your suggestions or questions, and
>>>>>> adopted suggestions into the doc revision. There are a few comments that we
>>>>>> would like to follow up with you. Please see full replies below. I am
>>>>>> copying the comments from #251 issue here. It will be great if you can
>>>>>> reply as comments in the github issue above. It is fine too we exchange
>>>>>> here, and we will incorporate our discussions to the issue tracker for
>>>>>> further revision references.
>>>>>>
>>>>>> -----
>>>>>>
>>>>>> > Section 1:
>>>>>> The use of the term "applications" carries an implication of a
>>>>>> client-side
>>>>>> device with installable software, but TEEP seems to extend also to
>>>>>> server
>>>>>> software sharing a kernel, hypervisors sharing a mainboard, etc. A
>>>>>> term like
>>>>>> "software" would be more neutral.
>>>>>>
>>>>>> This would be a major change in the doc. We authors will review for a
>>>>>> consensus.
>>>>>>
>>>>>> > "An application component ... is referred to as a Trusted
>>>>>> Application": This is
>>>>>> confusing. A component, explicitly not an entire "application", is
>>>>>> referred to
>>>>>> as an "application". "Trusted Component" would be more consistent.
>>>>>>
>>>>>> The doc has defined a TA to mean possibly an "application component"
>>>>>> in the Terminology Section as follows:
>>>>>>
>>>>>> "- Trusted Application (TA): An application (or, in some
>>>>>> implementations, an application component) that runs in a TEE"
>>>>>>
>>>>>> The change would be a significant change across the doc, including
>>>>>> APIs to be consistent when "Trusted Application" is replaced with "Trusted
>>>>>> Component" everywhere. Can we continue to use the above definition to cover
>>>>>> both cases?
>>>>>>
>>>>>> > Also, "trusted" seems to be the wrong adjective here, as it is the
>>>>>> environment, and
>>>>>> not the software, that carries an elevated level of trust. "Isolated"
>>>>>> might be
>>>>>> a better descriptor.
>>>>>>
>>>>>> > If this is common terminology for the field, a citation would be
>>>>>> good.
>>>>>>
>>>>>> Not sure that a name "Isolated Component" is more natural than
>>>>>> "Trusted Component".
>>>>>>
>>>>>> > I would appreciate some discussion of whether the Device Owner
>>>>>> needs to trust
>>>>>> the Trusted Application, i.e. interaction between enclaves and
>>>>>> sandboxes.
>>>>>>
>>>>>> Sounds good. A Device Owner may not always have control over TAs that
>>>>>> go to its device regardless of the owner's trust. A Device Administrator
>>>>>> may often decide when the Administrator is different from the owner.
>>>>>> Secondly, the trust to a TA is delegated to the TAMs that may manage the
>>>>>> TAs for installation to devices.
>>>>>>
>>>>>> @dthaler <https://github.com/dthaler> @hannestschofenig
>>>>>> <https://github.com/hannestschofenig> how do you think?
>>>>>>
>>>>>> > "verify the ... rights of TA developers": "rights" is a loaded
>>>>>> term. Rather
>>>>>> than get into constitutional law, consider "permissions".
>>>>>>
>>>>>> Agreed. Fixed.
>>>>>>
>>>>>> > "so that the Untrusted Application can complete" -> "so that
>>>>>> installation of
>>>>>> the Untrusted Application can complete".
>>>>>>
>>>>>> Agreed. Fixed.
>>>>>>
>>>>>> > "is considered confidential" -- By whom? From whom? Consider "A
>>>>>> developer who
>>>>>> wants to provide a TA without revealing its code to the device
>>>>>> owner..."
>>>>>>
>>>>>> Agreed. Just note that the developer may not even want to share the
>>>>>> code with a TAM that distributes the binary. So it isn't only protecting
>>>>>> from a device owner. Proposed fix:
>>>>>>
>>>>>> A Trusted Component might also be encrypted,
>>>>>> if the code is considered confidential, for example, when a developer wants to
>>>>>> provide a TA without revealing its code to others.
>>>>>>
>>>>>> > "A TEE ... wants to determine" ... excessive personification. I
>>>>>> suggest
>>>>>> "needs".
>>>>>>
>>>>>> Agreed. Fixed.
>>>>>>
>>>>>> > Section 2:
>>>>>> "it is more common for the enterprise to own the device, and any
>>>>>> device user
>>>>>> has no or limited administration rights": Grammar issue. Perhaps "and
>>>>>> for any
>>>>>> device user to have ...".
>>>>>>
>>>>>> Agreed. Adopted in fix.
>>>>>>
>>>>>> > Section 3.1
>>>>>> "trusted user interface" ... can you cite an example of a mobile
>>>>>> device with a
>>>>>> trusted peripheral that is not accessible to the REE OS? This seems
>>>>>> theoretical.
>>>>>>
>>>>>> Need help from co-authors here too.
>>>>>>
>>>>>> > Section 3.3
>>>>>> Similarly, are there any examples of IoT devices that prevent the REE
>>>>>> OS from
>>>>>> operating certain actuators?
>>>>>>
>>>>>> We will follow up on this.
>>>>>>
>>>>>> > Section 4.1
>>>>>> the TAM cannot directly contact a TEEP
>>>>>> Agent, but must wait for the TEEP Broker to contact the TAM
>>>>>> requesting a particular service. This architecture is intentional
>>>>>> in order to accommodate network and application firewalls
>>>>>>
>>>>>> > This is true in many use cases, but for Confidential Cloud the
>>>>>> reverse logic
>>>>>> applies. In fact, the TAM could be operating on-site inside an
>>>>>> enterprise,
>>>>>> requiring a firewall exception to be reachable from the TEEP Broker.
>>>>>> This
>>>>>> architecture is also unnatural: it converts an event-driven "update
>>>>>> command"
>>>>>> into a polling loop that adds delay and wastes resources. Why is this
>>>>>> part of
>>>>>> the TEEP architecture? Surely it could be handled by a
>>>>>> reversal-of-control
>>>>>> pattern one layer below TEEP (e.g. Server-sent events)?
>>>>>>
>>>>>> > I think the real motivation here is (1) installation is presumed to
>>>>>> be
>>>>>> triggered locally, by the Untrusted Application, so the TAM must be
>>>>>> reachable
>>>>>> as a "server", and the other side naturally should keep the client
>>>>>> role; (2)
>>>>>> the TAM is intended to have O(1) state while serving N devices.
>>>>>>
>>>>>> Right, that was the main use case and motivation for the architecture.
>>>>>>
>>>>>> > For a TAM to be successful,
>>>>>> it must have its public key or certificate installed in a device's
>>>>>> Trust Anchor Store.
>>>>>> This needs discussion of threat model. What damage can a hostile TAM
>>>>>> do? What
>>>>>> does the device administrator need to know for adding a trust anchor
>>>>>> to be safe?
>>>>>>
>>>>>> This has been addressed in "Section 9.5 Compromised TAM" in a version
>>>>>> after the review was posted.
>>>>>>
>>>>>> > Section 4.4
>>>>>> Implementations must support encryption of
>>>>>> such Personalization Data to preserve the confidentiality of
>>>>>> potentially sensitive data contained within it,
>>>>>>
>>>>>> > Implementations of what?
>>>>>>
>>>>>> Changed to "Implementations of TEEP protocol"
>>>>>>
>>>>>> > and must support
>>>>>> integrity protection of the Personalization Data.
>>>>>>
>>>>>> Lower-case "must" without explanation. Why, and is this a normative
>>>>>> requirement?
>>>>>>
>>>>>> We chose to not use MUST in the doc to differentiate "normative" from
>>>>>> "informal" requirements. To discuss this. @dthaler
>>>>>> <https://github.com/dthaler> @hannestschofenig
>>>>>> <https://github.com/hannestschofenig>
>>>>>>
>>>>>> > Section 4.4.2
>>>>>> "e.g., OP-TEE" -> What is this?
>>>>>>
>>>>>> Changed to "e.g., OP-TEE, an open source TEE"
>>>>>>
>>>>>> > Section 5.4
>>>>>>
>>>>>> > When a PKI is used, many intermediate CA certificates can chain to a
>>>>>> root certificate, each of which can issue many certificates.
>>>>>>
>>>>>> > Intermediate CAs have a troubled history (e.g. [1]), and techniques
>>>>>> that make
>>>>>> them safer (e.g. x.509 name constraints) can't be deployed as a
>>>>>> retrofit. Does
>>>>>> TEEP need some rules about supported x.509 extensions?
>>>>>>
>>>>>> We leave this to the device provider for the constraints on X509
>>>>>> extensions it supports and uses in Trust Anchor validation. They may select
>>>>>> to trust only a selected intermediate CA instead of the root as the Trust
>>>>>> Anchor.
>>>>>>
>>>>>> *Is this fine?*
>>>>>>
>>>>>> > Section 6.2.1
>>>>>>
>>>>>> > If an Untrusted Application is summarily deleted, how do you avoid
>>>>>> leaking the
>>>>>> TA?
>>>>>>
>>>>>> Similar to the removal of a buggy or malicious TA, this is up to a
>>>>>> device to have some scheme to contact TAM or be contacted to initiative a
>>>>>> removal of TAs that are not needed anymore.
>>>>>>
>>>>>> > Section 7
>>>>>>
>>>>>> > TEEP is format-agnostic for attestations, but what about
>>>>>> message-sequence-agnostic? Can it tunnel arbitrary challenge-response
>>>>>> sequences?
>>>>>>
>>>>>> There are some limitations in TEEP about supporting arbitrary
>>>>>> challenge-response sequences. It generally complies with RATS recommended
>>>>>> sequence. A single pass attestation and verifier flow is assumed. A
>>>>>> challenge may be supported by sending it in a request from a TAM to the
>>>>>> device where the device will combine the challenge in its attestation
>>>>>> evidence generation.
>>>>>>
>>>>>> > Section 9.3
>>>>>>
>>>>>> > We have
>>>>>> already seen examples of attacks on the public Internet with billions
>>>>>> of compromised devices being used to mount DDoS attacks.
>>>>>>
>>>>>> > Citation please. Also, are you sure it has reached into billions?
>>>>>>
>>>>>> Changed to "a large number".
>>>>>>
>>>>>> > Section 9:
>>>>>>
>>>>>> > Nothing here seems to discuss attacks on the TEE's properties, and
>>>>>> the
>>>>>> post-compromise implications of those attacks. For example, if all
>>>>>> instances
>>>>>> of a TA share a secret key, used for decrypting the Personalization
>>>>>> Data, then
>>>>>> a single successful attack on a TEE is sufficient to decrypt all
>>>>>> Personalization Data (previous and future). Given the prevalence of
>>>>>> such
>>>>>> attacks (especially via hardware fault injection), it seems likely to
>>>>>> be worth
>>>>>> mentioning.
>>>>>>
>>>>>> In general, we expect that a different secret key is used for
>>>>>> different devices for Personalization Data encryption. Such a secret key is
>>>>>> delivered to a TA using the public key of the TEE in the device. Such a
>>>>>> shared secret key for all TA instances isn't a common case.
>>>>>>
>>>>>> To mitigate this happening, I think we can add a statement to require
>>>>>> that Personalization Data must not be encrypted with the same key for all
>>>>>> devices.
>>>>>>
>>>>>> How do you think? I will also get other co-authors's inputs on this.
>>>>>>
>>>>>> Again, thank you very much for your detailed review and suggestions.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Ming
>>>>>>
>>>>>>
>>>>>>
>>>>>> This electronic communication and the information and any files
>>>>>> transmitted with it, or attached to it, are confidential and are intended
>>>>>> solely for the use of the individual or entity to whom it is addressed and
>>>>>> may contain information that is confidential, legally privileged, protected
>>>>>> by privacy laws, or otherwise restricted from disclosure to anyone else. If
>>>>>> you are not the intended recipient or the person responsible for delivering
>>>>>> the e-mail to the intended recipient, you are hereby notified that any use,
>>>>>> copying, distributing, dissemination, forwarding, printing, or copying of
>>>>>> this e-mail is strictly prohibited. If you received this e-mail in error,
>>>>>> please return the e-mail to the sender, delete it from your computer, and
>>>>>> destroy any printed copy of it.
>>>>>
>>>>>
>>>> This electronic communication and the information and any files
>>>> transmitted with it, or attached to it, are confidential and are intended
>>>> solely for the use of the individual or entity to whom it is addressed and
>>>> may contain information that is confidential, legally privileged, protected
>>>> by privacy laws, or otherwise restricted from disclosure to anyone else. If
>>>> you are not the intended recipient or the person responsible for delivering
>>>> the e-mail to the intended recipient, you are hereby notified that any use,
>>>> copying, distributing, dissemination, forwarding, printing, or copying of
>>>> this e-mail is strictly prohibited. If you received this e-mail in error,
>>>> please return the e-mail to the sender, delete it from your computer, and
>>>> destroy any printed copy of it.
>>>> _______________________________________________
>>>> TEEP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/teep
>>>>
>>>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.