Re: [Teep] TEEP Architecture Last Call Review

[Ben Schwartz <[e-mail]>]

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