Re: [Teep] TEEP Architecture Last Call Review

Brendan Moran <brendan.moran.ietf@gmail.com> Thu, 20 October 2022 13:41 UTC

Return-Path: <brendan.moran.ietf@gmail.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4254BC14CE3D; Thu, 20 Oct 2022 06:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhdGSPrHZqys; Thu, 20 Oct 2022 06:41:09 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC91EC14CE2E; Thu, 20 Oct 2022 06:41:08 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id z97so29937254ede.8; Thu, 20 Oct 2022 06:41:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kv+VMKFTGXOV0+LgnurMN2T9aYDRZ9LL3JvQWT/7U6A=; b=Xna60dtKSe7Pq1i6MCX78FLO1nujITR0KNk5XjJaiv8XytaKJR3+GtykM/4zFZNKuo Hf5F/vrrOxxUUiKfyEI/u2HAVxAzLzaKURCBLHz/vk6leCN5KbtQwV5TBdxsiL1eVvvw Us3npDf2oBgUIgY6z9NCXfyXMHZj6CtqJBlFGbQUP3UcKRsebk8uEL41WtcUo/eN6Ieu qF4hfpZiMHzMwt9/09bb9qT931ReByJQtXgCykyuJMRcKNlCVn18nMg7N71GpiNX24EI 1ibQ/oxeZiUqIo/Jz71eh1tvX2DxdQ4NyTD6oU8Xwqfko3V7+rIamTG6aPWUcQdcXE7c J3aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kv+VMKFTGXOV0+LgnurMN2T9aYDRZ9LL3JvQWT/7U6A=; b=xbiYOGUx7sjVlFVjGgfUOzZx/Kj/l9BM2X00c0P0ZmsfKGQMMC8wnIJo/HIBx+isV3 TkJVHcK2kZzPgV+hH/Z4a+IjPOH/GHbkhBt83q6YOZaCsug4wvgRof9DryR6ReQyjPeU 2StQoqmaQ6qSiBXZVGkKBOzosYSu8Be914FykS8XsvQ6HgaQhJXz7ytTPbTeI7G7i0lh fKfsgPztwbRG/ZFpKEmGVHqMWRl14few9eBo8AcEEloAGEcgYF6vjmhg1d+F3ik4fqYO Hi6G7XX54fhpetoBsQW8rKG43cifmstAySn/bceV1Ey2GscmHseGjY8Uf/Rg8pbSxeEV jrjQ==
X-Gm-Message-State: ACrzQf3lVnAYeht1R4kP7LJbmo8hw3IcvmE65Nyznry3xwMtx6FLNtFl +NI9RRHSsmWGVcd8p82ydwy2h71VVouAEQkXz4mUHka/Qtc=
X-Google-Smtp-Source: AMsMyM6Tj24tTw0aE1W++xmSajXCFbEn8A4DXPIt/XHEQ3h/qNjHCH00rpo9tfTy95SRhSQD6V1K76Xf8WjWiiEgKe4=
X-Received: by 2002:aa7:df16:0:b0:45b:f51f:ab73 with SMTP id c22-20020aa7df16000000b0045bf51fab73mr12282221edy.366.1666273266565; Thu, 20 Oct 2022 06:41:06 -0700 (PDT)
MIME-Version: 1.0
References: <CABDGos5jh-DUr4Tmv=yp7S+5tVMAUuvrrxq85TZBbt+REf=c1Q@mail.gmail.com> <CAHbrMsDinGqS36YiGQYROpbUjw2BSJVkrT5zsMQfpNGHEg8wuw@mail.gmail.com> <CABDGos5y8a7eW+jDJjevrXNqhNz5ipUrZV5F87WmmJ3V4=5H0w@mail.gmail.com>
In-Reply-To: <CABDGos5y8a7eW+jDJjevrXNqhNz5ipUrZV5F87WmmJ3V4=5H0w@mail.gmail.com>
From: Brendan Moran <brendan.moran.ietf@gmail.com>
Date: Thu, 20 Oct 2022 14:40:52 +0100
Message-ID: <CAPmVn1PWJ1zQ3Ome-XLjYqpPJQgVVhC+ybAQjvk8FLDCZQo1Hg@mail.gmail.com>
To: Mingliang Pei <mingliang.pei=40broadcom.com@dmarc.ietf.org>
Cc: Ben Schwartz <bemasc@google.com>, teep <teep@ietf.org>, teep-chairs@ietf.org, Paul Wouters <paul.wouters@aiven.io>
Content-Type: multipart/alternative; boundary="00000000000027055d05eb777a43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/t8l96pKTwOaEu5iHf12s4eOQ7tc>
Subject: Re: [Teep] TEEP Architecture Last Call Review
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2022 13:41:13 -0000

On 19 Oct 2022, at 21:22, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
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=
40broadcom.com@dmarc.ietf.org> 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 <bemasc@google.com> 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 <mingliang.pei@broadcom.com>
>> 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
> TEEP@ietf.org
> https://www.ietf.org/mailman/listinfo/teep
>