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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/