[Teep] review on draft-ietf-teep-architecture-08
Daniel Migault <mglt.ietf@gmail.com> Tue, 28 April 2020 02:01 UTC
Return-Path: <mglt.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 E5C2D3A0BE5 for <teep@ietfa.amsl.com>; Mon, 27 Apr 2020 19:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SuxlmaJgzTi for <teep@ietfa.amsl.com>; Mon, 27 Apr 2020 19:01:33 -0700 (PDT)
Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6E73A0BE1 for <teep@ietf.org>; Mon, 27 Apr 2020 19:01:32 -0700 (PDT)
Received: by mail-vk1-xa29.google.com with SMTP id p5so3044172vke.1 for <teep@ietf.org>; Mon, 27 Apr 2020 19:01:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=82/qIxfWrZ0uh7YjcrAb4O0rvW11+jatuMZLRfDomsE=; b=a7BRr6BpbcDaosl6ZCTg9xuaZ5ee9akb0JQ1yfwdi0MBOFTtLTjFNqPxEsI/jGz7Kj mBTwUaQTrXbqPgfuyRpTM4/bvTRxZo8tiFEP3lhmoFWKW9i6CclNi7VVAdvuhB9L7TW1 YF73B0cTj7n4vaB85EyoERt/pfLU0lhKuTfWL9/279+ByT5Cwg6u//KsRdX5yVdacbrT ceeuTiH5uKiDVRSR4fK3+tYotmbz0C4r6OUTHZtK30W2367KiS916Po72PVAyL7C9dra 8E46ao5JxN1FDhRaDiRKPQwNCypb/arZ8vh/8WjP0vf2n+04dncVJnnJ/jLpcc05/2+U oxjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=82/qIxfWrZ0uh7YjcrAb4O0rvW11+jatuMZLRfDomsE=; b=L7j0QM+OtBeVXb37Fp4ZUhQUuHle97oofkQYHgKIzOZl2YGVtdWoPaIe5of/xnRfo8 xPD2yMrE+V377W7VvmWLzVsQkFKEmIIfkoUsRV3WazqAv+4XMbh8XqAfCEDKc1IP1LiU kgoB2G+6ydqtsDeOiskeZxIC2ZY4pIBW6sYr06nPMgF8Hr6GUtxwXNnAH73UvqOzgtOl Zy8j6wYm3pJvZ2uOtpzJPDeX4G6j27VyBD1jw8qmZgwfRNNBfsMCz/9cMLnx7pfS+Evv M+4VNiNA69aVA3ShRL6kecip6geIhcE2d9HSOHpPsiN/601yFbLyimoj5UbmZoTJhuHf xkFQ==
X-Gm-Message-State: AGi0PuZY8EAdAegSYSF7SGsPHJNvvy7n2uwjzMAnPtU+qnl9aA+kbUHN 3Fuz6t2dXmFStkFKT+jcHlgAPqb6z8H69u1bHqrTR5JK
X-Google-Smtp-Source: APiQypJwyfm2IVlZobQUB862u+UQ/nHocfsQOYBxLCMsGWz7Rv6DYaHUNCa2WH+r9JomPtcdxLUW64PF6iMkNxneWCw=
X-Received: by 2002:a1f:7cc7:: with SMTP id x190mr8792032vkc.39.1588039290755; Mon, 27 Apr 2020 19:01:30 -0700 (PDT)
MIME-Version: 1.0
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Mon, 27 Apr 2020 22:01:19 -0400
Message-ID: <CADZyTkmWkXitYSSZG31w06OAc0+9cNEBy9jQvBjrjjuO8R_sXw@mail.gmail.com>
To: teep@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d09eb805a45035f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/U1rTHRW50jZQ6MgY4A4KBJfSyv8>
Subject: [Teep] review on draft-ietf-teep-architecture-08
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 28 Apr 2020 02:01:37 -0000
Hi, I reviewed the draft-ietf-teep-architecture-08 and please find my comments below. Yours, Daniel Trusted Execution Environment Provisioning (TEEP) Architecture draft-ietf-teep-architecture-08 The Trusted Execution Environment Provisioning (TEEP) protocol addresses the following problems: - An installer of an Untrusted Application that depends on a given TA wants to request installation of that TA in the device's TEE so that the Untrusted Application can complete, but the TEE needs to verify whether such a TA is actually authorized to run in the TEE and consume potentially scarce TEE resources. - A TA developer providing a TA whose code itself is considered confidential wants to determine security-relevant information of a device before allowing their TA to be provisioned to the TEE within the device. An example is the verification of the type of TEE included in a device and that it is capable of providing the security protections required. - A TEE in a device wants to determine whether an entity that wants to manage a TA in the device is authorized to manage TAs in the TEE, and what TAs the entity is permitted to manage. - A TAM (e.g., operated by a device administrator) wants to determine if a TA exists (is installed) on a device (in the TEE), and if not, install the TA in the TEE. - A TAM wants to check whether a TA in a device's TEE is the most up-to-date version, and if not, update the TA in the TEE. - A TA developer wants to remove a confidential TA from a device's TEE if the TA developer is no longer offering such TAs or the TAs are being revoked from a particular user (or device). For example, if a subscription or contract for a particular service has expired, or a payment by the user has not been completed or has been rescinded. - A TA developer wants to define the relationship between cooperating TAs under the TA developer's control, and specify whether the TAs can communicate, share data, and/or share key material. <mglt> I believe that the intent of these example was to provide a high level description of the goals of the architecture. I think it is necessary to introduce TA and untrusted Application, but I do not think TAM needs to be mentioned. </mglt> Note: The TA developer requires the help of a TAM to provision the Trusted Applications to remote devices and the TEEP protocol exchanges messages between a TAM and a TEEP Agent via a TEEP Broker. <mglt> I am incline to think that such clarification comes too early and mostly because TAM has been introduced. </mglt> 2. Terminology The following terms are used: - Device: A physical piece of hardware that hosts one or more TEEs, often along with a Rich Execution Environment. A device contains a default list of Trust Anchors that identify entities (e.g., TAMs) that are trusted by the device. This list is normally set by the device manufacturer, and may be governed by the device's network carrier when it is a mobile device. The list of Trust Anchors is normally modifiable by the device's owner or Device Administrator. However the device manufacturer or network carrier (in the mobile device case) may restrict some modifications, for example, by not allowing the manufacturer or carrier's Trust Anchor to be removed or disabled. <mglt> >From the definition it is unclear to me where the Trust Anchors are stored. I think the definition should specify the trust anchors are stored in the TEEP Agent explicitly. </mglt> - Trusted Application (TA) Developer: An entity that wishes to provide functionality on devices that requires the use of one or more Trusted Applications. <mglt> It is not clear why we have something more complex than an entity that publishes, implements TAs. The way I read the text is that functionalities are using TAs which might be closer to an untrusted application. <mglt> 3. Use Cases 3.1. Payment A payment application in a mobile device requires high security and trust about the hosting device. Payments initiated from a mobile device can use a Trusted Application to provide strong identification and proof of transaction. For a mobile payment application, some biometric identification information could also be stored in a TEE. The mobile payment application can use such information for unlocking the phone and for local identification of the user. A trusted user interface (UI) may be used in a mobile device to prevent malicious software from stealing sensitive user input data. Such an implementation often relies on a TEE for providing access to peripherals, such as PIN input. <mglt> It is unclear to me whether this is a single use case or many use cases related to the payment. It believe it would be clarifying to describe a little bit more what the TA does as well as the interactions with the untrusted applications. Typically it seems that the UI is part of the TA, which guarantee trusted inputs. I am wondering what mechanism or trust is necessary to actually trust the output of the TA. In other words why the "True" from the TA should be more trusted than the PIN values. It seems important to consider that anything coming out to the untrusted world can be tampered or replayed - even the output of the TA. Given the example, it seems to me hard to understand how TA are used. </mglt> 3.2. Authentication For better security of authentication, a device may store its keys and cryptographic libraries inside a TEE limiting access to cryptographic functions via a well-defined interface and thereby reducing access to keying material. <mglt> Though I am biaised, draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 are example of this. </mglt> 3.3. Internet of Things The Internet of Things (IoT) has been posing threats to critical infrastructure because of weak security in devices. It is desirable that IoT devices can prevent malware from manipulating actuators (e.g., unlocking a door), or stealing or modifying sensitive data, such as authentication credentials in the device. A TEE can be the best way to implement such IoT security functions. <mglt> quite broad... but ok.;-) </mglt> Pei, et al. Expires October 6, 2020 [Page 7] Internet-Draft TEEP Architecture April 2020 3.4. Confidential Cloud Computing A tenant can store sensitive data in a TEE in a cloud computing server such that only the tenant can access the data, preventing the cloud hosting provider from accessing the data. A tenant can run TAs inside a server TEE for secure operation and enhanced data security. This provides benefits not only to tenants with better data security but also to cloud hosting providers for reduced liability and increased cloud adoption. <mglt> This use case is useful as the document is heavily focused on devices. This use case introduces the notion of tenants that do share the resource of the device - or server. The Device Administrator ( cloud provider) will authorize a tenants' TAM and provision a specific TEE with Trusted Anchors for the tenants. I am also wondering how two concurrent TEEs from different tenants can remain isolated. Isolation is probably something that should be described in the security considerations. </mglt> 4. Architecture 4.1. System Components Figure 1 shows the main components in a typical device with an REE. Full descriptions of components not previously defined are provided below. Interactions of all components are further explained in the following paragraphs. +-------------------------------------------+ | Device | | +--------+ | TA Developer | +-------------+ | |-----------+ | | | TEE-1 | | TEEP |---------+ | | | | +--------+ | +----| Broker | | | | +--------+ | | | | TEEP | | | | |<---+ | | +->| |<-+ | | | Agent |<----+ | | | | | +-| TAM-1 | | | +--------+ | | |<-+ | | +->| | |<-+ | | | +--------+ | | | | +--------+ | | | +---+ +---+ | | | | | TAM-2 | | | +-->|TA1| |TA2| | +-------+ | | | +--------+ | | | | | | | |<---------| App-2 |--+ | | | | | | +---+ +---+ | +-------+ | | | Device Administrator | | +-------------+ | App-1 | | | | | | | | | | | | +--------------------| |---+ | | | | |--------+ | | +-------+ | +-------------------------------------------+ Figure 1: Notional Architecture of TEEP - TA developers and Device Administrators utilize the services of a TAM to manage TAs on devices. TA developers do not directly interact with devices. Device Administators may elect to use a TAM for remote administration of TAs instead of managing each device directly. <mglt> I think before going in to the details of each boxes the architecture should describe the high level goals of the architecture that is enabling the management of an TA developed by a TA Developer on a Device. The messages are exchanged between the TAM and the TEEP Agent. What is not so clear to me is whether a TEEP Agent can validate a TA from a TA developer that is using a different key than the TAM. I am unsure everything is based on session security. Suppose I would like a TEE only running TA from Vendor X independently from the TAM. If such validation occurs it is also unclear to me the validation occurs in the TEE or is performed by the TEEP agent. It also clarifies to explicitly mention that Brokers are not expected to terminate the session between the TAM and the TEEP Agent, but are mostly here to implement networking services in REE that may not be provided by the TEE, i.e. by the TEEP Agent. What I was missing in my first reading was the terminating points of the sessions. In particular, in some cases a broker could be a MiM, so it is better to clarify that it is not the case here. Of course if my understanding is correct. <mglt> Pei, et al. Expires October 6, 2020 [Page 8] Internet-Draft TEEP Architecture April 2020 - Trusted Application Manager (TAM): A TAM is responsible for performing lifecycle management activity on TAs on behalf of TA developers and Device Administrators. This includes creation and <mglt> provisioning might more accurate, but that is just a suggestion. </mglt> deletion of TAs, and may include, for example, over-the-air updates to keep TAs up-to-date and clean up when a version should be removed. TAMs may provide services that make it easier for TA developers or Device Administators to use the TAM's service to manage multiple devices, although that is not required of a TAM. The TAM performs its management of TAs on the device through interactions with a device's TEEP Broker, which relays messages between a TAM and a TEEP Agent running inside the TEE. <mglt> Unless specified before I would suggest to specify the meaning of "relay" and in particular that authentication of the messages are not performed by the broker but by the Agent. </mglt> A TA developer or Device Administrator chooses a particular TAM based on whether the TAM is trusted by a device or set of devices. The TAM is trusted by a device if the TAM's public key is, or chains up to, an authorized Trust Anchor in the device. A TA developer or Device Administrator may run their own TAM, but the devices they wish to manage must include this TAM's public key/ certificate, or a certificate it chains up to, in the Trust Anchor list. <mglt> I have the impression that Trust Anchor Store is the term used in the Terminology. I also think it helps clarifying the trust anchors are part of the Agent... so in a TEE. </mglt> - TEEP Broker: A TEEP Broker is an application component running in a Rich Execution Environment (REE) that enables the message protocol exchange between a TAM and a TEE in a device. A TEEP Broker does not process messages on behalf of a TEE, but merely is responsible for relaying messages from the TAM to the TEE, and for returning the TEE's responses to the TAM. <mglt> Same here "relay" here does not involve some kind of authentication. </mglt> - Certification Authority (CA): Certificate-based credentials used for authenticating a device, a TAM and a TA developer. A device embeds a list of root certificates (Trust Anchors), from trusted CAs that a TAM will be validated against. A TAM will remotely attest a device by checking whether a device comes with a certificate from a CA that the TAM trusts. The CAs do not need to be the same; different CAs can be chosen by each TAM, and different device CAs can be used by different device manufacturers. <mglt> I have the impression that Trust Anchor has been the terminology used. </mgtl> 4.2. Multiple TEEs in a Device Brokers on a particular platform. In addition, since TEEs may be physically separated, with wholly different resources, there may be no need for TEEP Brokers to share information on installed TAs or resource usage. <mglt> I am wondering how multiple TEE could be used as a way to isolate different tenants. As the broker is part of the REE it seems that it does not necessarily need to be set by the Device Administrator, but eventually by the tenant. Would it be possible ? </mglt> 4.3. Multiple TAMs and Relationship to TAs When a TEEP Broker receives a request <mglt> Is such a request a TEEP request or something more abstract ? </mglt> from an Untrusted Application to install a TA, a list of TAM URIs may be provided for that TA, and the request is passed to the TEEP Agent. If the TEEP Agent decides that the TA needs to be installed, the TEEP Agent selects a single TAM URI that is consistent with the list of trusted TAMs provisioned on the device, invokes the HTTP transport for TEEP to connect to the TAM URI, and begins a TEEP protocol exchange. <mglt> """The trusted TAM provisioned on the device""" seems to indicates that a common Trust Anchor Store is shared by all TEEs. I suppose that is provisioned on a per agent base. My understanding is that the Agent may implement the HTTP transport but will not treat networking aspects. These will be instead handled by the Broker. If that is correct, this could maybe clarified. </mglt> 4.4. Untrusted Apps, Trusted Apps, and Personalization Data 1. The Untrusted Application, TA(s), and personalization data are all bundled together in a single package by a TA developer and provided to the TEEP Broker through the TAM. <mglt> Does this scenario corresponds to a push from the TAM ? </mglt> 2. The Untrusted Application and the TA(s) are bundled together in a single package, which a TAM or a publicly accessible app store maintains, and the personalization data is separately provided by the TA developer's TAM. <mglt> The first TAM seems to me related to a push while the app store corresponds to a pull scenario. I also understand the second TAM is requested by the Agent. If that is correct it would be clarifying to specify the initiator of the request. </mglt> 3. All components are independent. The Untrusted Application is installed through some independent or device-specific mechanism, and the TAM provides the TA and personalization data from the TA developer. Delivery of the TA and personalization data may be combined or separate. 4.5. Entity Relations (App Developers) (App Store) (TAM) (Device with TEE) (CAs) | | | | | | | | (Embedded TEE cert) <--| | | | | | | <--- Get an app cert -----------------------------------| | | | | | | | | <-- Get a TAM cert ---------| | | | | | 1. Build two apps: | | | | | | | | (a) Untrusted | | | | App - 2a. Supply --> | --- 3. Install ------> | | | | | | (b) TA -- 2b. Supply ----------> | 4. Messaging-->| | | | | | Figure 3: Developer Experience Note that Figure 3 shows the TA developer as a TA signer. The TA signer is either the same as the TA developer, or is a related entity trusted to sign the developer's TAs. Figure 3 shows an example where the same developer builds two applications: 1) an Untrusted Application; 2) a TA that provides some security functions to be run inside a TEE. <mglt> isn't it a and b in the figure. </mglt> At step 2, the TA developer uploads the Untrusted Application (2a) to an Application Store. The Untrusted Application may optionally bundle the TA binary. Meanwhile, the TA developer may provide its TA to a TAM that will be managing the TA in various devices. At step 3, a user will go to an Application Store to download the Untrusted Application. Since the Untrusted Application depends on the TA, installing the Untrusted Application will trigger TA installation by initiating communication with a TAM. This is step 4. <mglt> Since the broker requests the TAM I would have expected the arrow in the other way. I also have the impression some text is missing around the cert related arrows. </mglt> It should be noted that network communication capability is generally not available in TAs in today's TEE-powered devices. Consequently, Trusted Applications generally rely on broker in the REE to provide access to nnetwork functionality in the REE. A broker does not need to know the actual content of messages to facilitate such access. <mglt> nnetwork </mglt> Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent generally relies on a TEEP Broker in the REE to provide network access, and relay TAM requests to the TEEP Agent and relay the responses back to the TAM. 9.6. Malicious TA Removal It is possible that a rogue developer distributes a malicious Untrusted Application and intends to get a malicious TA installed. It's the responsibility of the TAM to not install malicious trusted apps in the first place. The TEEP architecture allows a TEEP Agent to decide which TAMs it trusts via Trust Anchors, and delegates the TA authenticity check to the TAMs it trusts. It may happen that a TA was previously considered trustworthy but is later found to be buggy or compromised. In this case, the TAM can initiate the removal of the TA by notifying devices to remove the TA (and potentially the REE or device owner to remove any Untrusted Application that depend on the TA). If the TAM does not currently Pei, et al. Expires October 6, 2020 [Page 26] Internet-Draft TEEP Architecture April 2020 have a connection to the TEEP Agent on a device, such a notification would occur the next time connectivity does exist. That is, to recover, the TEEP Agent must be able to reach out to the TAM, for example whenever the RequestPolicyCheck API (Section 6.2.1) is invoked by a timer or other event. <mglt> Given the security assumption of a TEE a rogue TA will not be able to steal data of the other TA - which is not the case for applications running in a REE. I also believe that some additional considerations are needed regarding tenants sharing a given device ( or server). </mglt> -- Daniel Migault Ericsson
- [Teep] review on draft-ietf-teep-architecture-08 Daniel Migault