--- 1/draft-ietf-teep-opentrustprotocol-01.txt 2018-10-23 14:14:34.793026064 -0700 +++ 2/draft-ietf-teep-opentrustprotocol-02.txt 2018-10-23 14:14:34.969030320 -0700 @@ -1,25 +1,25 @@ TEEP M. Pei Internet-Draft Symantec Intended status: Informational A. Atyeo -Expires: January 3, 2019 Intercede +Expires: April 26, 2019 Intercede N. Cook ARM Ltd. M. Yoo - Solacia + IoTrust H. Tschofenig ARM Ltd. - July 2, 2018 + October 23, 2018 The Open Trust Protocol (OTrP) - draft-ietf-teep-opentrustprotocol-01.txt + draft-ietf-teep-opentrustprotocol-02.txt Abstract This document specifies the Open Trust Protocol (OTrP), a protocol that follows the Trust Execution Environment Provisioning (TEEP) architecture and provides a message protocol that provisions and manages Trusted Applications into a device with a Trusted Execution Environment (TEE). Status of This Memo @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 3, 2019. + This Internet-Draft will expire on April 26, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,37 +55,37 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 4. OTrP Entities and Trust Model . . . . . . . . . . . . . . . . 6 - 4.1. System Components . . . . . . . . . . . . . . . . . . . . 6 + 4.1. System Components . . . . . . . . . . . . . . . . . . . . 7 4.2. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 7 4.3. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 7 4.4. Keys and Certificate Types . . . . . . . . . . . . . . . 7 5. Protocol Scope and Entity Relations . . . . . . . . . . . . . 10 5.1. A Sample Device Setup Flow . . . . . . . . . . . . . . . 12 5.2. Derived Keys in The Protocol . . . . . . . . . . . . . . 12 5.3. Security Domain Hierarchy and Ownership . . . . . . . . . 13 5.4. SD Owner Identification and TAM Certificate Requirements 13 5.5. Service Provider Container . . . . . . . . . . . . . . . 14 - 6. OTrP Agent . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 6.1. Role of OTrP Agent . . . . . . . . . . . . . . . . . . . 15 - 6.2. OTrP Agent and Global Platform TEE Client API . . . . . . 16 - 6.3. OTrP Agent Implementation Consideration . . . . . . . . . 16 - 6.3.1. OTrP Agent Distribution . . . . . . . . . . . . . . . 16 - 6.3.2. Number of OTrP Agent . . . . . . . . . . . . . . . . 16 - 6.4. OTrP Agent Interfaces for Client Applications . . . . . . 17 + 6. OTrP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.1. Role of OTrP Broker . . . . . . . . . . . . . . . . . . . 15 + 6.2. OTrP Broker and Global Platform TEE Client API . . . . . 16 + 6.3. OTrP Broker Implementation Consideration . . . . . . . . 16 + 6.3.1. OTrP Broker Distribution . . . . . . . . . . . . . . 16 + 6.3.2. Number of OTrP Broker . . . . . . . . . . . . . . . . 16 + 6.4. OTrP Broker Interfaces for Client Applications . . . . . 17 6.4.1. ProcessOTrPMessage call . . . . . . . . . . . . . . . 17 6.4.2. GetTAInformation call . . . . . . . . . . . . . . . . 17 6.5. Sample End-to-End Client Application Flow . . . . . . . . 20 6.5.1. Case 1: A New Client Application Uses a TA . . . . . 20 6.5.2. Case 2: A Previously Installed Client Application Calls a TA . . . . . . . . . . . . . . . . . . . . . 21 7. OTrP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 22 7.2. Message Naming Convention . . . . . . . . . . . . . . . . 22 7.3. Request and Response Message Template . . . . . . . . . . 23 @@ -137,41 +137,41 @@ 9.3.2.2. UpdateTAResponse Message . . . . . . . . . . . . 67 9.3.2.3. Error Conditions . . . . . . . . . . . . . . . . 69 9.3.3. DeleteTA . . . . . . . . . . . . . . . . . . . . . . 69 9.3.3.1. DeleteTARequest Message . . . . . . . . . . . . . 69 9.3.3.2. Request Processing Requirements at a TEE . . . . 71 9.3.3.3. DeleteTAResponse Message . . . . . . . . . . . . 72 9.3.3.4. Error Conditions . . . . . . . . . . . . . . . . 73 10. Response Messages a TAM May Expect . . . . . . . . . . . . . 73 11. Basic Protocol Profile . . . . . . . . . . . . . . . . . . . 74 12. Attestation Implementation Consideration . . . . . . . . . . 75 - 12.1. OTrP Secure Boot Module . . . . . . . . . . . . . . . . 75 + 12.1. OTrP Trusted Firmware . . . . . . . . . . . . . . . . . 75 12.1.1. Attestation signer . . . . . . . . . . . . . . . . . 75 - 12.1.2. SBM Initial Requirements . . . . . . . . . . . . . . 75 + 12.1.2. TFW Initial Requirements . . . . . . . . . . . . . . 75 12.2. TEE Loading . . . . . . . . . . . . . . . . . . . . . . 76 12.3. Attestation Hierarchy . . . . . . . . . . . . . . . . . 76 12.3.1. Attestation Hierarchy Establishment: Manufacture . . 77 12.3.2. Attestation Hierarchy Establishment: Device Boot . . 77 12.3.3. Attestation Hierarchy Establishment: TAM . . . . . . 77 - 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 13.1. Error Code List . . . . . . . . . . . . . . . . . . . . 78 13.1.1. TEE Signed Error Code List . . . . . . . . . . . . . 78 - 13.1.2. OTrP Agent Error Code List . . . . . . . . . . . . . 79 + 13.1.2. OTrP Broker Error Code List . . . . . . . . . . . . 79 14. Security Consideration . . . . . . . . . . . . . . . . . . . 79 14.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 79 14.2. Message Security . . . . . . . . . . . . . . . . . . . . 80 14.3. TEE Attestation . . . . . . . . . . . . . . . . . . . . 80 14.4. TA Protection . . . . . . . . . . . . . . . . . . . . . 80 14.5. TA Personalization Data . . . . . . . . . . . . . . . . 81 14.6. TA Trust Check at TEE . . . . . . . . . . . . . . . . . 81 14.7. One TA Multiple SP Case . . . . . . . . . . . . . . . . 82 - 14.8. OTrP Agent Trust Model . . . . . . . . . . . . . . . . . 82 + 14.8. OTrP Broker Trust Model . . . . . . . . . . . . . . . . 82 14.9. OCSP Stapling Data for TAM Signed Messages . . . . . . . 82 14.10. Data Protection at TAM and TEE . . . . . . . . . . . . . 82 14.11. Privacy Consideration . . . . . . . . . . . . . . . . . 82 14.12. Threat Mitigation . . . . . . . . . . . . . . . . . . . 83 14.13. Compromised CA . . . . . . . . . . . . . . . . . . . . . 83 14.14. Compromised TAM . . . . . . . . . . . . . . . . . . . . 84 14.15. Certificate Renewal . . . . . . . . . . . . . . . . . . 84 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 16.1. Normative References . . . . . . . . . . . . . . . . . . 84 @@ -194,21 +194,21 @@ A.2. Sample TA Management Messages . . . . . . . . . . . . . . 99 A.2.1. Sample InstallTA . . . . . . . . . . . . . . . . . . 99 A.2.1.1. Sample InstallTARequest . . . . . . . . . . . . . 99 A.2.1.2. Sample InstallTAResponse . . . . . . . . . . . . 100 A.2.2. Sample UpdateTA . . . . . . . . . . . . . . . . . . . 102 A.2.2.1. Sample UpdateTARequest . . . . . . . . . . . . . 102 A.2.2.2. Sample UpdateTAResponse . . . . . . . . . . . . . 103 A.2.3. Sample DeleteTA . . . . . . . . . . . . . . . . . . . 106 A.2.3.1. Sample DeleteTARequest . . . . . . . . . . . . . 106 A.2.3.2. Sample DeleteTAResponse . . . . . . . . . . . . . 108 - A.3. Example OTrP Agent Option . . . . . . . . . . . . . . . . 110 + A.3. Example OTrP Broker Option . . . . . . . . . . . . . . . 110 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110 1. Introduction The Trusted Execution Environment (TEE) concept has been designed to separate a regular operating system, also referred as a Rich Execution Environment (REE), from security-sensitive applications. In an TEE ecosystem, different device vendors may use different TEE implementations. Different application providers or device @@ -223,81 +223,80 @@ OTrP defines a mutual trust message protocol between a TAM and a TEE and relies on IETF-defined end-to-end security mechanisms, namely JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Key (JWK). Other message encoding methods may be supported. This specification defines message payloads exchanged between devices and a TAM. The messages are designed in anticipation of the use of the most common transport methods such as HTTPS. - A TA binary and personalization data can be from two sources: + Each TA binary and configuration data can be from either of two + sources: - 1. A TAM supplies the signed and encrypted TA binary + 1. A TAM supplies the signed and encrypted TA binary and any + required configuration data 2. A Client Application supplies the TA binary - This specification considers the first case where TA binary and - personalization data are encrypted by recipient's public key that TAM - has to be involved. The second case will be addressed separately. + configuration data are encrypted by recipient's public key that TAM + has to be involved. The second case will also be addressed + separately. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology 3.1. Definitions The definitions provided below are defined as used in this document. All the terms defined in the TEEP Architecture document [TEEPArch] will be used, which are not repeated in this document. - OTrP Agent: It is the Agent as defined in the TEEP Architecture + OTrP Broker: It is the Broker as defined in the TEEP Architecture document [TEEPArch]. 3.2. Abbreviations CA Certificate Authority OTrP Open Trust Protocol REE Rich Execution Environment SD Security Domain SP Service Provider - SBM Secure Boot Module - TA Trusted Application TEE Trusted Execution Environment TFW Trusted Firmware TAM Trusted Application Manager 4. OTrP Entities and Trust Model - 4.1. System Components The same system components as defined in the TEEP Architecture document [TEEPArch] are used in OTrP, including TAM, CA, TEE, REE, - and OTrP Agent (a.k.a Agent). + and OTrP Broker (a.k.a Broker). Secure boot (for the purposes of OTrP) is optional in enabling authenticity checking of TEEs by the TAM. A TAM provider can choose it policy whether it trusts a TEE if the underlying firmware - attestation information isn't included. + attestation information is not included. OTrP uses trust anchors to establish trust between TEEs and TAMs and verifies that they communicate in a trusted way when performing lifecycle management transactions. 4.2. Trust Anchors in TEE This assumes the Trust Anchor specification defined in the TEEP Architecture document [TEEPArch]. @@ -319,23 +318,23 @@ OTrP leverages the following list of trust anchors and identities in generating signed and encrypted command messages that are exchanged between a device's TEE and a TAM. With these security artifacts, OTrP Messages are able to deliver end-to-end security without relying on any transport security. +-------------+----------+--------+-------------------+-------------+ | Key Entity | Location | Issuer | Trust Implication | Cardinality | | Name | | | | | +-------------+----------+--------+-------------------+-------------+ - | 1. TFW key | Device | FW CA | A white list of | 1 per | - | pair and | secure | | FW root CA | device | - | certificate | storage | | trusted by TAMs | | + | 1. TFW key | Device | FW CA | A whitelist of FW | 1 per | + | pair and | secure | | root CA trusted | device | + | certificate | storage | | by TAMs | | | | | | | | | 2. TEE key | Device | TEE CA | A white list of | 1 per | | pair and | TEE | under | TEE root CA | device | | certificate | | a root | trusted by TAMs | | | | | CA | | | | | | | | | | 3. TAM key | TAM | TAM CA | A white list of | 1 or | | pair and | provider | under | TAM root CA | multiple | | certificate | | a root | embedded in TEE | can be used | | | | CA | | by a TAM | @@ -344,21 +343,25 @@ | pair and | | signer | TA trust is | multiple | | certificate | | CA | delegated to TAM. | can be used | | | | | TEE trusts TAM to | by a TAM | | | | | ensure that a TA | | | | | | is trustworthy. | | +-------------+----------+--------+-------------------+-------------+ Table 1: Key and Certificate Types 1. TFW key pair and certificate: A key pair and certificate for - evidence of secure boot and trustworthy firmware in a device. + evidence of trustworthy firmware in a device. This key pair is + optional. Some TEE may present its trusted attributes to a TAM + using signed attestation with a TFW key. For example, a platform + that uses a hardware based TEE can have attestation data signed + by a hardware protected TFW key. Location: Device secure storage Supported Key Type: RSA and ECC Issuer: OEM CA Trust Implication: A white list of FW root CA trusted by TAMs Cardinality: One per device @@ -419,52 +422,52 @@ This document specifies messages and key properties that can establish mutual trust between a TEE and a TAM. The protocol provides specifications for the following three entities: 1. Key and certificate types required for device firmware, TEEs, TAs, SPs, and TAMs 2. Data message formats that should be exchanged between a TEE in a device and a TAM - 3. An OTrP Agent application in the REE that can relay messages - between a Client Application and TEE + 3. An OTrP Broker in the REE that can relay messages between a + Client Application and TEE Figure 1: Protocol Scope and Entity Relationship PKI CA -- CA CA -- | | | | | | | | | - Device | | --- OTrP Agent / Client App --- | + Device | | --- OTrP Broker / Client App --- | SW | | | | | | | | | | | | | | | OTrP | -- TEE TAM------- | | FW Figure 2: OTrP System Diagram -------OTrP Message Protocol--- | | | | -------------------- --------------- ---------- | REE | TEE | | TAM | | SP | | --- | --- | | --- | | -- | | | | | | | | | Client | SD (TAs)| | SD / TA | | TA | | Apps | | | Mgmt | | | | | | | | | | | - | | | | | | | | + | | | List of | | List of | | | | OTrP | Trusted | | Trusted | | | - | Agent | TAM/SP | | FW/TEE | | | + | Broker | TAM/SP | | FW/TEE | | | | | CAs | | CAs | | | | | | | | | | | |TEE Key/ | | TAM Key/ | |SP Key/ | | | Cert | | Cert | | Cert | | | FW Key/ | | | | | | | Cert | | | | | -------------------- --------------- ---------- | | | | | | ------------- ---------- --------- @@ -479,22 +482,22 @@ The main OTrP component consists of a set of standard JSON messages created by a TAM to deliver device SD and TA management commands to a device, and device attestation and response messages created by a TEE that responds to a TAM's OTrP message. The communication method of OTrP Messages between a TAM and TEE in a device may vary between TAM and TEE providers. A mandatory transport protocol is specified for a compliant TAM and a device TEE. - An OTrP Agent is used to bridge communication between a TAM and a - TEE. The OTrP Agent doesn't need to know the actual content of OTrP + An OTrP Broker is used to bridge communication between a TAM and a + TEE. The OTrP Broker doesn't need to know the actual content of OTrP Messages except for the TEE routing information. 5.1. A Sample Device Setup Flow Step 1: Prepare Images for Devices 1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM 2. [CA] Deliver root CA Whitelist @@ -503,22 +506,21 @@ Step 2: Inject Key Pairs and Images to Devices 1. [OEM] Generate Secure Boot Key Pair (May be shared among multiple devices) 2. [OEM] Flash signed TFW Image and signed TEE Image onto devices (signed by Secure Boot Key) Step 3: Setup attestation key pairs in devices - 1. [OEM] Flash Secure Boot Public Key and eFuse Key (eFuse key is - unique per device) + 1. [OEM] Flash TFW Public Key and a bootloader key. 2. [TFW/TEE] Generate a unique attestation key pair and get a certificate for the device. Step 4: Setup trust anchors in devices 1. [TFW/TEE] Store the key and certificate encrypted with the eFuse key 2. [TEE vendor or OEM] Store trusted CA certificate list into @@ -536,22 +538,22 @@ This key pair is generated in the first SD creation for an SP. It is deleted when all SDs are removed for a SP in a device. The public key of the key pair is given to the caller Client Application and TAM for future TEE returned data validation. The public key of this AIK is also used by a TAM to encrypt TA binary data and personalization data when it sends a TA to a device for installation. 5.3. Security Domain Hierarchy and Ownership The primary job of a TAM is to help an SP to manage its trusted - applications. A TA is typically installed in an SD. An SD is - commonly created for an SP. + application components. A TA is typically installed in an SD. An SD + is commonly created for an SP. When an SP delegates its SD and TA management to a TAM, an SD is created on behalf of a TAM in a TEE and the owner of the SD is assigned to the TAM. An SD may be associated with an SP but the TAM has full privilege to manage the SD for the SP. Each SD for an SP is associated with only one TAM. When an SP changes TAM, a new SP SD must be created to associate with the new TAM. The TEE will maintain a registry of TAM ID and SP SD ID mapping. @@ -625,142 +627,142 @@ |----------| SP1 SD2 | | ---------- | ---------- |----------| SP2 SD1 | ---------- OTrP segregates SDs and TAs such that a TAM can only manage or retrieve data for SDs and TAs that it previously created for the SPs it represents. -6. OTrP Agent +6. OTrP Broker A TEE and TAs that run inside the TEE don't generally have capability to communicate to the outside of the hosting device, for example, the TEE specified by Global Platform groups [GPTEE]. This calls for a software module in the REE world to handle the network communication. Each Client Application in REE may carry this communication functionality but it must also interact with the TEE for the message exchange. The TEE interaction will vary according to different TEEs. In order for a Client Application to transparently support different TEEs, it is imperative to have a common interface for a Client Application to invoke for exchanging messages with TEEs. - A shared OTrP Agent comes to meed this need. An OTrP Agent is a Rich - Application or SDK that facilitates communication between a TAM and - TEE. It also provides interfaces for TAM SDK or Client Applications - to query and trigger TA installation that the application needs to - use. + A shared OTrP Broker comes to meed this need. An OTrP Broker is a + Rich Application or SDK that facilitates communication between a TAM + and TEE. It also provides interfaces for TAM SDK or Client + Applications to query and trigger TA installation that the + application needs to use. This interface for Client Applications may be commonly an Android service call for an Android powered device. A Client Application interacts with a TAM, and turns around to pass messages received from - TAM to OTrP Agent. + TAM to OTrP Broker. In all cases, a Client Application needs to be able to identify an - OTrP Agent that it can use. + OTrP Broker that it can use. -6.1. Role of OTrP Agent +6.1. Role of OTrP Broker - An OTrP Agent abstracts the message exchanges with the TEE in a + An OTrP Broker abstracts the message exchanges with the TEE in a device. The input data is originated from a TAM that a Client Application connects. A Client Application may also directly call - OTrP Agent for some TA query functions. + OTrP Broker for some TA query functions. - OTrP Agent may internally process a request from TAM. At least, it + OTrP Broker may internally process a request from TAM. At least, it needs to know where to route a message, e.g. TEE instance. It doesn't need to process or verify message content. - OTrP Agent returns TEE / TFW generated response messages to the - caller. OTrP Agent isn't expected to handle any network connection + OTrP Broker returns TEE / TFW generated response messages to the + caller. OTrP Broker isn't expected to handle any network connection with an application or TAM. - OTrP Agent only needs to return an OTrP Agent error message if the + OTrP Broker only needs to return an OTrP Broker error message if the TEE is not reachable for some reason. Other errors are represented as response messages returned from the TEE which will then be passed to the TAM. -6.2. OTrP Agent and Global Platform TEE Client API +6.2. OTrP Broker and Global Platform TEE Client API A Client Application may use Global Platform (GP) TEE API for TA communication. OTrP may use the GP TEE Client API but it is internal to OTrP implementation that converts given messages from TAM. More details can be found at [GPTEECLAPI]. -6.3. OTrP Agent Implementation Consideration +6.3. OTrP Broker Implementation Consideration A Provider should consider methods of distribution, scope and concurrency on device and runtime options when implementing an OTrP - Agent. Several non-exhaustive options are discussed below. + Broker. Several non-exhaustive options are discussed below. Providers are encouraged to take advantage of the latest communication and platform capabilities to offer the best user experience. -6.3.1. OTrP Agent Distribution +6.3.1. OTrP Broker Distribution - OTrP Agent installation is commonly carried out at OEM time. A user - can dynamically download and install an OTrP Agent on-demand. + OTrP Broker installation is commonly carried out at OEM time. A user + can dynamically download and install an OTrP Broker on-demand. - It is important to ensure a legitimate OTrP Agent is installed and - used. If an OTrP Agent is compromised it may send rogue messages to + It is important to ensure a legitimate OTrP Broker is installed and + used. If an OTrP Broker is compromised it may send rogue messages to TAM and TEE and introduce additional risks. -6.3.2. Number of OTrP Agent +6.3.2. Number of OTrP Broker - We anticipate only one shared OTrP Agent instance in a device. The - device's TEE vendor will most probably supply one OTrP Agent. + We anticipate only one shared OTrP Broker instance in a device. The + device's TEE vendor will most probably supply one OTrP Broker. Potentially we expect some open source. - With one shared OTrP Agent, the OTrP Agent provider is responsible to - allow multiple TAMs and TEE providers to achieve interoperability. - With a standard OTrP Agent interface, TAM can implement its own SDK - for its SP Client Applications to work with this OTrP Agent. + With one shared OTrP Broker, the OTrP Broker provider is responsible + to allow multiple TAMs and TEE providers to achieve interoperability. + With a standard OTrP Broker interface, TAM can implement its own SDK + for its SP Client Applications to work with this OTrP Broker. - Multiple independent OTrP Agent providers can be used as long as they - have standard interface to a Client Application or TAM SDK. Only one - OTrP Agent is expected in a device. + Multiple independent OTrP Broker providers can be used as long as + they have standard interface to a Client Application or TAM SDK. + Only one OTrP Broker is expected in a device. TAM providers are generally expected to provide SDK for SP - applications to interact with an OTrP Agent for the TAM and TEE + applications to interact with an OTrP Broker for the TAM and TEE interaction. -6.4. OTrP Agent Interfaces for Client Applications +6.4. OTrP Broker Interfaces for Client Applications A Client Application shall be responsible for relaying messages - between the OTrP agent and the TAM. + between the OTrP Broker and the TAM. - If a failure occurs during calling OTrP Agent, an error message + If a failure occurs during calling OTrP Broker, an error message described in "Common Errors" section (see Section 7.6) will be returned. 6.4.1. ProcessOTrPMessage call Description - A Client Application will use this method of the OTrP Agent in a + A Client Application will use this method of the OTrP Broker in a device to pass OTrP messages from a TAM. The method is responsible for interacting with the TEE and for forwarding the input message to the TEE. It also returns TEE generated response message back to the Client Application. Inputs: TAMInMsg - OTrP message generated in a TAM that is passed to this method from a Client Application. Outputs: A TEE-generated OTrP response message (which may be a successful response or be a response message containing an error raised within the TEE) for the client application to forward to the TAM. - In the event of the OTrP agent not being able to communicate with - the TEE, a OTrPAgentException shall be thrown. + In the event of the OTrP Broker not being able to communicate with + the TEE, a OTrPBrokerException shall be thrown. 6.4.2. GetTAInformation call Description A Client Application may quickly query local TEE about a previously installed TA without requiring TAM each time if it has had the TA's identifier and previously saved TEE SP AIK public key for TA information integrity verification. @@ -768,21 +770,21 @@ { "TAQuery": { "spid": "", "taid": "" } } Outputs: - The OTrP Agent is expected to return TA signer and TAM signer + The OTrP Broker is expected to return TA signer and TAM signer certificate along with other metadata information about the TA associated with the given identifier. It follows the underlying TEE trust model for authoring the local TA query from a Client Application. The output is a JSON message that is generated by the TEE. It contains the following information: * tamid @@ -811,30 +813,30 @@ Output Message: { "TAInformationTBS": { "taid": "", "tamid": "", "spid": "", "signercert": "", - "signercacerts": [ // the full list of CA certificate chain - // including the root CA + "signercacerts": [ < The full list of CA certificate chain + including the root CA> ], "cacert": "" ], "tamcert": "", - "tamcacerts": [ // the full list of CA certificate chain - // including the root CA + "tamcacerts": [ < The full list of CA certificate chain + including the root CA> ], "cacert":"" ] } } { "TAInformation": { "payload": "", @@ -1722,21 +1724,21 @@ supportedsigalgs - an optional property to list the JWS signing algorithms that the active TEE supports. When a TAM sends a signed message that the TEE isn't able to validate, it can include signature algorithms that it is able to consume in this status report. A TAM can generate a new request message to retry the management task with a TEE-supported signing algorithm. If the TEE isn't able to sign an error message due to an internal device error, a general error message should be returned by the OTrP - Agent. + Broker. 9.1.7. TAM Processing Requirements Upon receiving a GetDeviceStateResponse message at a TAM, the TAM MUST validate the following. o Parse to get list of GetDeviceTEEStateResponse JSON objects o Parse the JSON "payload" property and decrypt the JSON element "edsi". The decrypted message contains the TEE signer @@ -1932,21 +1934,21 @@ + TEE SP AIK public key if DSI isn't going to be included + Updated DSI data if requested * The response message is encrypted with the same JWE CEK of the request without recreating a new content encryption key. * The encrypted message is signed with TEEpriv. The signer information ("did" or TEEcert) is encrypted. - 4. Deliver the response message. (a) The OTrP Agent returns this to + 4. Deliver the response message. (a) The OTrP Broker returns this to the Client Application; (b) The Client App passes this back to the TAM. 5. TAM processing. (a) The TAM processes the response message; (b) the TAM can look up signer certificate from the device ID "did". If a request is illegitimate or signature doesn't pass, a "status" property in the response will indicate the error code and cause. 9.2.1.3. CreateSDResponse Message @@ -1974,43 +1976,43 @@ did - The SHA256 hash of the device TEE certificate. This shows the device ID explicitly to the receiving TAM. teespaik - The newly generated SP AIK public key for the given SP. This is an optional value if the device has had another domain for the SP that has triggered TEE SP AIK key pair for this specific SP. There is a possible extreme error case where the TEE isn't reachable or the TEE final response generation itself fails. In this case, the - TAM might still receive a response from the OTrP Agent if the OTrP - Agent is able to detect such error from TEE. In this case, a general - error response message should be returned by the OTrP Agent, assuming - OTrP Agent even doesn't know any content and information about the - request message. + TAM might still receive a response from the OTrP Broker if the OTrP + Broker is able to detect such error from TEE. In this case, a + general error response message should be returned by the OTrP Broker, + assuming OTrP Broker even doesn't know any content and information + about the request message. In other words, the TAM should expect to receive a TEE successfully signed JSON message, a general "status" message, or none when a client experiences a network error. { "CreateSDResponse": { "payload": "", "protected": { "" }, "signature": "" } } A response message type "status" will be returned when the TEE fails - to respond. The OTrP Agent is responsible to create this message. + to respond. The OTrP Broker is responsible to create this message. { "status": { "result": "fail", "error-code": "ERR_AGENT_TEE_FAIL", "error-message": "TEE fails to respond" } } 9.2.1.4. Error Conditions @@ -2223,21 +2225,21 @@ + TEE SP AIK public key if DSI isn't going to be included + Updated DSI data if requested * The response message is encrypted with the same JWE CEK of the request without recreating a new content encryption key. * The encrypted message is signed with TEEpriv. The signer information ("did" or TEEcert) is encrypted. - 4. Deliver response message. (a) The OTrP Agent returns this to the + 4. Deliver response message. (a) The OTrP Broker returns this to the app; (b) The app passes this back to the TAM. 5. TAM processing. (a) The TAM processes the response message; (b) The TAM can look up the signer certificate from the device ID "did". If a request is illegitimate or the signature doesn't pass, a "status" property in the response will indicate the error code and cause. @@ -2285,21 +2287,21 @@ "payload": "", "protected": { "" }, "signature": "" } } A response message type "status" will be returned when the TEE fails - to respond. The OTrP Agent is responsible to create this message. + to respond. The OTrP Broker is responsible to create this message. { "status": { "result": "fail", "error-code": "ERR_AGENT_TEE_FAIL", "error-message": "" } } 9.2.2.4. Error Conditions @@ -2485,21 +2487,21 @@ + "did" or full signer certificate information, + Updated DSI data if requested * The response message is encrypted with the same JWE CEK of the request without recreating a new content encryption key. * The encrypted message is signed with TEEpriv. The signer information ("did" or TEEcert) is encrypted. - 4. Deliver response message. (a) The OTrP Agent returns this to the + 4. Deliver response message. (a) The OTrP Broker returns this to the app; (b) The app passes this back to the TAM 5. TAM processing. (a) The TAM processes the response message; (b) The TAM can look up signer certificate from the device ID "did". If a request is illegitimate or the signature doesn't pass, a "status" property in the response will indicate the error code and cause. 9.2.3.3. DeleteSDResponse Message @@ -2536,21 +2538,21 @@ "payload": "", "protected": { "" }, "signature": "" } } A response message type "status" will be returned when the TEE fails - to respond. The OTrP Agent is responsible to create this message. + to respond. The OTrP Broker is responsible to create this message. { "status": { "result": "fail", "error-code": "ERR_AGENT_TEE_FAIL", "error-message": "TEE fails to respond" } } 9.2.3.4. Error Conditions @@ -2788,21 +2790,21 @@ "payload":"", "protected": { "" }, "signature": "" } } A response message type "status" will be returned when the TEE fails - to respond. The OTrP Agent is responsible to create this message. + to respond. The OTrP Broker is responsible to create this message. { "status": { "result": "fail", "error-code": "ERR_AGENT_TEE_FAIL", "error-message": "TEE fails to respond" } } 9.3.1.3. Error Conditions @@ -3013,21 +3015,21 @@ "payload":"", "protected": { "" }, "signature": "" } } A response message type "status" will be returned when the TEE fails - to respond. The OTrP Agent is responsible to create this message. + to respond. The OTrP Broker is responsible to create this message. { "status": { "result": "fail", "error-code": "ERR_AGENT_TEE_FAIL", "error-message": "TEE fails to respond" } } 9.3.2.3. Error Conditions @@ -3060,21 +3062,21 @@ ERR_TAM_NOT_AUTHORIZED ERR_TAM_NOT_TRUSTED 9.3.3. DeleteTA This operation defines OTrP messages that allow a TAM to instruct a TEE to delete a TA for an SP in a given SD. A TEE will delete a TA from an SD and also TA data in the TEE. A Client Application cannot - directly access TEE or OTrP Agent to delete a TA. + directly access TEE or OTrP Broker to delete a TA. 9.3.3.1. DeleteTARequest Message The request message for DeleteTA has the following JSON format. { "DeleteTATBSRequest": { "ver": "1.0", "rid": "", "tid": "", "tee": "", @@ -3197,21 +3199,21 @@ "payload": "", "protected": { "" }, "signature": "" } } A response message type "status" will be returned when the TEE fails - to respond. The OTrP Agent is responsible to create this message. + to respond. The OTrP Broker is responsible to create this message. { "status": { "result": "fail", "error-code": "ERR_AGENT_TEE_FAIL", "error-message": "TEE fails to respond" } } 9.3.3.4. Error Conditions @@ -3251,38 +3253,38 @@ responses SHOULD be supplied. Type 1: Expect a valid TEE-generated response message A valid TEE signed response may contain errors detected by a TEE, e.g. a TAM is trusted but some TAM-supplied data is missing, for example, SP ID doesn't exist. TEE MUST be able to sign and encrypt. If a TEE isn't able to sign a response, the TEE returns an error - to the OTrP Agent without giving any other internal information. - The OTrP Agent will be generating the response. + to the OTrP Broker without giving any other internal information. + The OTrP Broker will be generating the response. - Type 2: The OTrP Agent generated error message when TEE fails. - OTrP Agent errors will be defined in this document. + Type 2: The OTrP Broker generated error message when TEE fails. + OTrP Broker errors will be defined in this document. A Type 2 message has the following format. { - "OTrPAgentError": { + "OTrPBrokerError": { "ver": "1.0", "rid": "", "tid": "", "errcode": "ERR_AGENT_TEE_UNKNOWN | ERR_AGENT_TEE_BUSY" } } - Type 3: OTrP Agent itself isn't reachable or fails. A Client + Type 3: OTrP Broker itself isn't reachable or fails. A Client Application is responsible to handle error and respond the TAM in its own way. This is out of scope for this specification. 11. Basic Protocol Profile This section describes a baseline for interoperability among the protocol entities, mainly, the TAM and TEE. A TEE MUST support RSA algorithms. It is optional to support ECC algorithms. A TAM SHOULD use a RSA certificate for TAM message @@ -3324,142 +3326,140 @@ mechanism. In the initial version, only one active TEE is assumed. It is out of scope how the TAM and the device implement the trust hierarchy verification. However, it is helpful to understand what each system provider should do in order to properly implement an OTrP trust hierarchy. In this section, we provide some implementation reference consideration. -12.1. OTrP Secure Boot Module +12.1. OTrP Trusted Firmware 12.1.1. Attestation signer - It is proposed that attestation for OTrP is based on the SBM secure - boot layer, and that further attestation is not performed within the - TEE itself during Security Domain operations. The rationale is that - the device boot process will be defined to start with a secure boot - approach that, using eFuse, only releases attestation signing - capabilities into the SBM once a secure boot has been established. - In this way the release of the attestation signer can be considered - the first "platform configuration metric", using Trust Computing - Group (TCG) terminology. + It is proposed that attestation for OTrP is based on the TFW layer, + and that further attestation is not performed within the TEE itself + during Security Domain operations. The rationale is that the device + boot process will be defined to start with a secure bootloader + protected with a harden key in eFUSE. The process releases + attestation signing capabilities into the TFW once a trust boot has + been established. In this way the release of the attestation signer + can be considered the first "platform configuration metric", using + Trust Computing Group (TCG) terminology. -12.1.2. SBM Initial Requirements +12.1.2. TFW Initial Requirements - R1 The SBM must be possible to load securely into the secure boot - flow + R1 The TFW must be possible for verification during boot - R2 The SBM must allow a public / private key pair to be generated + R2 The TFW must allow a public / private key pair to be generated during device manufacture R3 The public key and certificate must be possible to store securely R4 The private key must be possible to store encrypted at rest - R5 The private key must only be visible to the SBM when it is + R5 The private key must only be visible to the TFW when it is decrypted - R6 The SBM must be able to read a list of root and intermediate + R6 The TFW must be able to read a list of root and intermediate certificates that it can use to check certificate chains with. The list must be stored such that it cannot be tampered with R7 Need to allow a TEE to access its unique TEE specific private key 12.2. TEE Loading - During boot, the SBM is required to start all of the root TEEs. - Before loading them, the SBM must first determine whether the code + During boot, the TFW is required to start all of the root TEEs. + Before loading them, the TFW must first determine whether the code sign signature of the TEE is valid. If TEE integrity is confirmed, - the TEE may be started. The SBM must then be able to receive the + the TEE may be started. The TFW must then be able to receive the identity certificate from the TEE (if that TEE is OTrP compliant). The identity certificate and keys will need to be baked into the TEE image, and therefore also covered by the code signer hash during the manufacturing process. The private key for the identity certificate must be securely protected. The private key for a TEE identity must never be released no matter how the public key and certificate are - released to the SBM. + released to the TFW. - Once the SBM has successfully booted a TEE and retrieved the identity - certificate, the SBM will commit this to the platform configuration + Once the TFW has successfully booted a TEE and retrieved the identity + certificate, the TFW will commit this to the platform configuration register (PCR) set, for later use during attestation. At minimum, the following data must be committed to the PCR for each TEE: 1. Public key and certificate for the TEE 2. TEE identifier that can be used later by a TAM to identify this TEE 12.3. Attestation Hierarchy The attestation hierarchy and seed required for TAM protocol operation must be built into the device at manufacture. Additional TEEs can be added post-manufacture using the scheme proposed, but it is outside of the current scope of this document to detail that. It should be noted that the attestation scheme described is based on - signatures. The only encryption that takes place is with eFuse to - release the SBM signing key and later during the protocol lifecycle - management interchange with the TAM. + signatures. The only decryption that may take place is through the + use of a bootloader key. 12.3.1. Attestation Hierarchy Establishment: Manufacture During manufacture the following steps are required: 1. A device-specific TFW key pair and certificate are burnt into the - device, encrypted by eFuse. This key pair will be used for - signing operations performed by the SBM. + device. This key pair will be used for signing operations + performed by the TFW. 2. TEE images are loaded and include a TEE instance-specific key pair and certificate. The key pair and certificate are included in the image and covered by the code signing hash. 3. The process for TEE images is repeated for any subordinate TEEs, which are additional TEEs after the root TEE that some devices have. 12.3.2. Attestation Hierarchy Establishment: Device Boot During device boot the following steps are required: - 1. Secure boot releases the TFW private key by decrypting it with - eFuse + 1. The boot module releases the TFW private key by decrypting it + with the bootloader key. - 2. The SBM verifies the code-signing signature of the active TEE and + 2. The TFW verifies the code-signing signature of the active TEE and places its TEE public key into a signing buffer, along with its - identifier for later access. For a non-OTrP TEE, the SBM leaves + identifier for later access. For a non-OTrP TEE, the TFW leaves the TEE public key field blank. - 3. The SBM signs the signing buffer with the TFW private key. + 3. The TFW signs the signing buffer with the TFW private key. - 4. Each active TEE performs the same operation as the SBM, building + 4. Each active TEE performs the same operation as the TFW, building up their own signed buffer containing subordinate TEE information. 12.3.3. Attestation Hierarchy Establishment: TAM Before a TAM can begin operation in the marketplace to support devices of a given TEE, it must obtain a TAM certificate from a CA that is registered in the trust store of devices with that TEE. In this way, the TEE can check the intermediate and root CA and verify that it trusts this TAM to perform operations on the TEE. 13. IANA Considerations The error code listed in the next section will be registered. 13.1. Error Code List This section lists error codes that could be reported by a TA or TEE in a device in responding to a TAM request, and a separate list that - OTrP Agent may return when the TEE fails to respond. + OTrP Broker may return when the TEE fails to respond. 13.1.1. TEE Signed Error Code List ERR_DEV_STATE_MISMATCH - A TEE will return this error code if the DSI hash value from TAM doesn't match the has value of the device's current DSI. ERR_SD_ALREADY_EXISTS - This error will occur if an SD to be created already exists in the TEE. @@ -3506,31 +3506,31 @@ validity of the TAM certificate, etc. If the TEE finds that the TAM is not trustworthy, then it will return this error code. ERR_UNSUPPORTED_CRYPTO_ALG - This error will occur if a TEE receives a request message encoded with cryptographic algorithms that the TEE doesn't support. ERR_UNSUPPORTED_MSG_VERSION - This error will occur if a TEE receives a message version that the TEE can't deal with. -13.1.2. OTrP Agent Error Code List +13.1.2. OTrP Broker Error Code List ERR_AGENT_TEE_UNKNOWN - This error will occur if the receiver TEE is not supposed to receive the request. That will be determined by checking the TEE name or device id in the request message. ERR_AGENT_TEE_BUSY - The device TEE is busy. The request can be generally sent again to retry. ERR_AGENT_TEE_FAIL - The TEE fails to respond to a TAM request. The - OTrP Agent will construct an error message in responding to the + OTrP Broker will construct an error message in responding to the TAM's request. 14. Security Consideration 14.1. Cryptographic Strength The strength of the cryptographic algorithms, using the measure of 'bits of security' defined in NIST SP800-57 allowed for OTrP is: o At a minimum, 112 bits of security. The limiting factor for this @@ -3625,46 +3625,46 @@ A TA binary is signed by a TA signer certificate. This TA signing certificate/private key belongs to the SP, and may be self-signed (i.e., it need not participate in a trust hierarchy). It is the responsibility of the TAM to only allow verified TAs from trusted SPs into the system. Delivery of that TA to the TEE is then the responsibility of the TEE, using the security mechanisms provided by the OTrP. We allow a way for an (untrusted) application to check the - trustworthiness of a TA. OTrP Agent has a function to allow an - application to query the information about a TA. + trustworthiness of a TA. OTrP Broker has a function to allow a + Client Application to query the information about a TA. An application in the Rich O/S may perform verification of the TA by verifying the signature of the TA. The GetTAInformation function is available to return the TEE supplied TA signer and TAM signer information to the application. An application can do additional trust checks on the certificate returned for this TA. It might trust the TAM, or require additional SP signer trust chaining. 14.7. One TA Multiple SP Case A TA for multiple SPs must have a different identifier per SP. A TA will be installed in a different SD for each respective SP. -14.8. OTrP Agent Trust Model +14.8. OTrP Broker Trust Model - An OTrP Agent could be malware in the vulnerable Rich OS. A Client + An OTrP Broker could be malware in the vulnerable REE. A Client Application will connect its TAM provider for required TA installation. It gets command messages from the TAM, and passes the - message to the OTrP Agent. + message to the OTrP Broker. The OTrP is a conduit for enabling the TAM to communicate with the device's TEE to manage SDs and TAs. All TAM messages are signed and - sensitive data is encrypted such that the OTrP Agent cannot modify or - capture sensitive data. + sensitive data is encrypted such that the OTrP Broker cannot modify + or capture sensitive data. 14.9. OCSP Stapling Data for TAM Signed Messages The GetDeviceStateRequest message from a TAM to a TEE shall include OCSP stapling data for the TAM's signer certificate and for intermediate CA certificates up to the root certificate so that the TEE can verify the signer certificate's revocation status. A certificate revocation status check on a TA signer certificate is OPTIONAL by a TEE. A TAM is responsible for vetting a TA and the SP @@ -3694,47 +3694,47 @@ An SP-specific TEE SP AIK (TEE SP Anonymous Key) is generated by the protocol for Client Applications. This provides a way for the Client Application to validate some data that the TEE may send without requiring the TEE device certificate to be released to the client device rich O/S , and to optionally allow an SP to encrypt a TA for a target device without the SP needing to be supplied with the TEE device certificate. 14.12. Threat Mitigation - A rogue application may perform excessive TA loading. An OTrP Agent + A rogue application may perform excessive TA loading. An OTrP Broker implementation should protect against excessive calls. Rogue applications might request excessive SD creation. The TAM is responsible to ensure this is properly guarded against. - Rogue OTrP Agent could replay or send TAM messages out of sequence: - e.g., a TAM sends update1 and update2. The OTrP Agent replays + Rogue OTrP Broker could replay or send TAM messages out of sequence: + e.g., a TAM sends update1 and update2. The OTrP Broker replays update2 and update1 again, creating an unexpected result that a client wants. "dsihash" is used to mitigate this. The TEE MUST store DSI state and check that the DSI state matches before it does another update. Concurrent calls from a TAM to a TEE MUST be handled properly by a TEE. If multiple concurrent TAM operations take place, these could fail due to the "dsihash" being modified by another concurrent operation. The TEE is responsible for resolve any locking such that one application cannot lock other applications from using the TEE, except for a short term duration of the TAM operation taking place. For example, an OTrP operation that starts but never completes (e.g. loss of connectivity) must not prevent subsequent OTrP messages from being executed. 14.13. Compromised CA A root CA for TAM certificates might get compromised. Some TEE trust - anchor update mechanism is expected from device OEM. A compromised + anchor update mechanism is expected from device OEMs. A compromised intermediate CA is covered by OCSP stapling and OCSP validation check in the protocol. A TEE should validate certificate revocation about a TAM certificate chain. If the root CA of some TEE device certificates is compromised, these devices might be rejected by a TAM, which is a decision of the TAM implementation and policy choice. Any intermediate CA for TEE device certificates SHOULD be validated by TAM with a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) method. @@ -3793,21 +3793,22 @@ DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [TEEPArch] Pei, M., Tschofenig, H., Atyeo, A., and D. Liu, "Trusted Execution Environment Provisioning (TEEP) Architecture", - 2018. + 2018, . 16.2. Informative References [GPTEE] Global Platform, "Global Platform, GlobalPlatform Device Technology: TEE System Architecture, v1.0", 2013. [GPTEECLAPI] Global Platform, "Global Platform, GlobalPlatform Device Technology: TEE Client API Specification, v1.0", 2013. @@ -3849,23 +3850,23 @@ "header": { "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] }, "signature":"c2FtcGxlIHNpZ25hdHVyZQ" } } A.1.1.2. Sample GetDeviceStateResponse - The TAM sends "GetDeviceStateRequest" to the OTrP Agent + The TAM sends "GetDeviceStateRequest" to the OTrP Broker - The OTrP Agent obtains "dsi" from each TEE. (In this example there + The OTrP Broker obtains "dsi" from each TEE. (In this example there is a single TEE.) The TEE obtains signed "fwdata" from firmware. The TEE builds "dsi" - summarizing device state of the TEE. { "dsi": { "tfwdata": { "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=", @@ -3938,22 +3939,22 @@ "ciphertext": " c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW NpcGllbnRzLmVuY3J5cHRlZF9rZXk", "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" } } } The TEE signs "GetDeviceTEEStateTBSResponse" and returns it to the - OTrP Agent. The OTrP Agent encodes "GetDeviceTEEStateResponse" into - an array to form "GetDeviceStateResponse". + OTrP Broker. The OTrP Broker encodes "GetDeviceTEEStateResponse" + into an array to form "GetDeviceStateResponse". { "GetDeviceStateResponse": [ { "GetDeviceTEEStateResponse": { "payload": " ewogICJHZXREZXZpY2VURUVTdGF0ZVRCU1Jlc3BvbnNlIjogewogICAgInZlciI6 ICIxLjAiLAogICAgInN0YXR1cyI6ICJwYXNzIiwKICAgICJyaWQiOiAiezhDNkY5 REJCLUZDMzktNDM1Yy1CQzg5LTREMzYxNERBMkYwQn0iLAogICAgInRpZCI6ICJ7 @@ -3971,21 +3972,21 @@ eVpXCiAgICAgIE5wY0dsbGJuUnpMbVZ1WTNKNWNIUmxaRjlyWlhrIiwKICAgICAg InRhZyI6ICJjMkZ0Y0d4bElHRjFkR2hsYm5ScFkyRjBhVzl1SUhSaFp3IgogICAg fQogIH0KfQ", "protected": "eyJhbGciOiJSUzI1NiJ9", "signature": "c2FtcGxlIHNpZ25hdHVyZQ" } } ] } - The TEE returns "GetDeviceStateResponse" back to the OTrP Agent, + The TEE returns "GetDeviceStateResponse" back to the OTrP Broker, which returns message back to the TAM. A.1.2. Sample CreateSD A.1.2.1. Sample CreateSDRequest { "CreateSDTBSRequest": { "ver":"1.0", "rid":"req-01", "tid":"tran-01", @@ -4385,21 +4386,21 @@ IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAoJCQkiY2lwaGVydGV4dCI6ICJj MkZ0Y0d4bElHUnphU0JrWVhSaElHVnVZM0o1Y0hSbFpDQjNhWFJvSUVGRlV6RXlP Q0JyWlhrZ1puSnZiU0J5WldOcGNHbGxiblJ6TG1WdVkzSjVjSFJsWkY5clpYayIs CgkJCSJ0YWciOiAiYzJGdGNHeGxJR0YxZEdobGJuUnBZMkYwYVc5dUlIUmhadyIK CQl9Cgl9Cn0", "protected":"eyJhbGciOiJSUzI1NiJ9", "signature":"c2FtcGxlIHNpZ25hdHVyZQ" } } - The TEE returns "DeleteSDResponse" back to the OTrP Agent, which + The TEE returns "DeleteSDResponse" back to the OTrP Broker, which returns the message back to the TAM. A.2. Sample TA Management Messages A.2.1. Sample InstallTA A.2.1.1. Sample InstallTARequest { "InstallTATBSRequest": { "ver": "1.0", @@ -4756,31 +4757,31 @@ em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" }, "signature":" DfoBOetNelKsnAe_m4Z9K5UbihgWNYZsp5jVybiI05sOagDzv6R4do9npaAlAvpNK8HJ CxD6D22J8GDUExlIhSR1aDuDCQm6QzmjdkFdxAz5TRYl6zpPCZqgSToN_g1TZxqxEv6V Ob5fies4g6MHvCH-Il_-KbHq5YpwGxEEFdg" } } -A.3. Example OTrP Agent Option +A.3. Example OTrP Broker Option The most popular TEE devices today are Android powered devices. In - an Android device, an OTrP Agent can be a bound service with a + an Android device, an OTrP Broker can be a bound service with a service registration ID that a Client Application can use. This - option allows a Client Application not to depend on any OTrP Agent + option allows a Client Application not to depend on any OTrP Broker SDK or provider. - An OTrP Agent is responsible to detect and work with more than one + An OTrP Broker is responsible to detect and work with more than one TEE if a device has more than one. In this version, there is only - one active TEE such that an OTrP Agent only needs to handle the + one active TEE such that an OTrP Broker only needs to handle the active TEE. Appendix B. Contributors - Brian Witten Symantec brian_witten@symantec.com - Tyler Kim Solacia @@ -4805,24 +4806,24 @@ Email: andrew.atyeo@intercede.com Nick Cook ARM Ltd. 110 Fulbourn Rd Cambridge, CB1 9NJ Great Britain Email: nicholas.cook@arm.com Minho Yoo - Solacia - 5F, Daerung Post Tower 2, 306 Digital-ro - Seoul 152-790 + IoTrust + Suite 501, Gasanbusiness Center,165, Gasan digital1-ro + Seoul 08503 Korea - Email: paromix@gmail.com + Email: minho.yoo@iotrust.kr Hannes Tschofenig ARM Ltd. 110 Fulbourn Rd Cambridge, CB1 9NJ Great Britain - Email: Hannes.Tschofenig@arm.com + Email: hannes.tschofenig@arm.com