draft-ietf-teep-opentrustprotocol-00.txt   draft-ietf-teep-opentrustprotocol-01.txt 
Internet Engineering Task Force M. Pei TEEP M. Pei
Internet-Draft Symantec Internet-Draft Symantec
Intended status: Informational A. Atyeo Intended status: Informational A. Atyeo
Expires: November 2, 2018 Intercede Expires: January 3, 2019 Intercede
N. Cook N. Cook
ARM Ltd. ARM Ltd.
M. Yoo M. Yoo
Solacia Solacia
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
May 1, 2018 July 2, 2018
The Open Trust Protocol (OTrP) The Open Trust Protocol (OTrP)
draft-ietf-teep-opentrustprotocol-00.txt draft-ietf-teep-opentrustprotocol-01.txt
Abstract Abstract
This document specifies the Open Trust Protocol (OTrP), a protocol to This document specifies the Open Trust Protocol (OTrP), a protocol
install, update, and delete applications in a Trusted Execution that follows the Trust Execution Environment Provisioning (TEEP)
Environment (TEE) and to manage their security configuration. architecture and provides a message protocol that provisions and
manages Trusted Applications into a device with a Trusted Execution
TEEs are used in environments where security services should be Environment (TEE).
isolated from a regular operating system (often called rich OS).
This form of compartmentalization grants a smaller codebase access to
security sensitive services and restricts communication from the rich
OS to those security services via mediated access.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 2, 2018. This Internet-Draft will expire on January 3, 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 26 skipping to change at page 2, line 18
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
4. OTrP Entities and Trust Model . . . . . . . . . . . . . . . . 8 4. OTrP Entities and Trust Model . . . . . . . . . . . . . . . . 6
4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 4.1. System Components . . . . . . . . . . . . . . . . . . . . 6
4.2. Trusted Anchors in TEE . . . . . . . . . . . . . . . . . 9 4.2. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 7
4.3. Trusted Anchors in TAM . . . . . . . . . . . . . . . . . 10 4.3. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 7
4.4. Keys and Certificate Types . . . . . . . . . . . . . . . 10 4.4. Keys and Certificate Types . . . . . . . . . . . . . . . 7
5. Protocol Scope and Entity Relations . . . . . . . . . . . . . 12 5. Protocol Scope and Entity Relations . . . . . . . . . . . . . 10
5.1. A Sample Device Setup Flow . . . . . . . . . . . . . . . 14 5.1. A Sample Device Setup Flow . . . . . . . . . . . . . . . 12
5.2. Derived Keys in The Protocol . . . . . . . . . . . . . . 15 5.2. Derived Keys in The Protocol . . . . . . . . . . . . . . 12
5.3. Security Domain Hierarchy and Ownership . . . . . . . . . 15 5.3. Security Domain Hierarchy and Ownership . . . . . . . . . 13
5.4. SD Owner Identification and TAM Certificate Requirements 16 5.4. SD Owner Identification and TAM Certificate Requirements 13
5.5. Service Provider Container . . . . . . . . . . . . . . . 16 5.5. Service Provider Container . . . . . . . . . . . . . . . 14
6. OTrP Agent . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. OTrP Agent . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Role of OTrP Agent . . . . . . . . . . . . . . . . . . . 18 6.1. Role of OTrP Agent . . . . . . . . . . . . . . . . . . . 15
6.2. OTrP Agent and Global Platform TEE Client API . . . . . . 18 6.2. OTrP Agent and Global Platform TEE Client API . . . . . . 16
6.3. OTrP Agent Implementation Consideration . . . . . . . . . 18 6.3. OTrP Agent Implementation Consideration . . . . . . . . . 16
6.3.1. OTrP Agent Distribution . . . . . . . . . . . . . . . 18 6.3.1. OTrP Agent Distribution . . . . . . . . . . . . . . . 16
6.3.2. Number of OTrP Agent . . . . . . . . . . . . . . . . 19 6.3.2. Number of OTrP Agent . . . . . . . . . . . . . . . . 16
6.4. OTrP Agent Interfaces for Client Applications . . . . . . 19 6.4. OTrP Agent Interfaces for Client Applications . . . . . . 17
6.4.1. ProcessOTrPMessage call . . . . . . . . . . . . . . . 19 6.4.1. ProcessOTrPMessage call . . . . . . . . . . . . . . . 17
6.4.2. GetTAInformation call . . . . . . . . . . . . . . . . 20 6.4.2. GetTAInformation call . . . . . . . . . . . . . . . . 17
6.5. Sample End-to-End Client Application Flow . . . . . . . . 23 6.5. Sample End-to-End Client Application Flow . . . . . . . . 20
6.5.1. Case 1: A New Client Application Uses a TA . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . 24 Calls a TA . . . . . . . . . . . . . . . . . . . . . 21
7. OTrP Messages . . . . . . . . . . . . . . . . . . . . . . . . 25 7. OTrP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 25 7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 22
7.2. Message Naming Convention . . . . . . . . . . . . . . . . 25 7.2. Message Naming Convention . . . . . . . . . . . . . . . . 22
7.3. Request and Response Message Template . . . . . . . . . . 26 7.3. Request and Response Message Template . . . . . . . . . . 23
7.4. Signed Request and Response Message Structure . . . . . . 26 7.4. Signed Request and Response Message Structure . . . . . . 23
7.4.1. Identifying Signing and Encryption Keys for JWS/JWE 7.4.1. Identifying Signing and Encryption Keys for JWS/JWE
Messaging . . . . . . . . . . . . . . . . . . . . . . 28 Messaging . . . . . . . . . . . . . . . . . . . . . . 25
7.5. JSON Signing and Encryption Algorithms . . . . . . . . . 28 7.5. JSON Signing and Encryption Algorithms . . . . . . . . . 25
7.5.1. Supported JSON Signing Algorithms . . . . . . . . . . 30 7.5.1. Supported JSON Signing Algorithms . . . . . . . . . . 27
7.5.2. Support JSON Encryption Algorithms . . . . . . . . . 30 7.5.2. Support JSON Encryption Algorithms . . . . . . . . . 27
7.5.3. Supported JSON Key Management Algorithms . . . . . . 30 7.5.3. Supported JSON Key Management Algorithms . . . . . . 27
7.6. Common Errors . . . . . . . . . . . . . . . . . . . . . . 31 7.6. Common Errors . . . . . . . . . . . . . . . . . . . . . . 28
7.7. OTrP Message List . . . . . . . . . . . . . . . . . . . . 31 7.7. OTrP Message List . . . . . . . . . . . . . . . . . . . . 28
7.8. OTrP Request Message Routing Rules . . . . . . . . . . . 32 7.8. OTrP Request Message Routing Rules . . . . . . . . . . . 29
7.8.1. SP Anonymous Attestation Key (SP AIK) . . . . . . . . 32 7.8.1. SP Anonymous Attestation Key (SP AIK) . . . . . . . . 29
8. Transport Protocol Support . . . . . . . . . . . . . . . . . 32 8. Transport Protocol Support . . . . . . . . . . . . . . . . . 29
9. Detailed Messages Specification . . . . . . . . . . . . . . . 33 9. Detailed Messages Specification . . . . . . . . . . . . . . . 30
9.1. GetDeviceState . . . . . . . . . . . . . . . . . . . . . 33 9.1. GetDeviceState . . . . . . . . . . . . . . . . . . . . . 30
9.1.1. GetDeviceStateRequest message . . . . . . . . . . . . 33 9.1.1. GetDeviceStateRequest message . . . . . . . . . . . . 30
9.1.2. Request processing requirements at a TEE . . . . . . 34 9.1.2. Request processing requirements at a TEE . . . . . . 31
9.1.3. Firmware Signed Data . . . . . . . . . . . . . . . . 35 9.1.3. Firmware Signed Data . . . . . . . . . . . . . . . . 32
9.1.3.1. Supported Firmware Signature Methods . . . . . . 36 9.1.3.1. Supported Firmware Signature Methods . . . . . . 33
9.1.4. Post Conditions . . . . . . . . . . . . . . . . . . . 36 9.1.4. Post Conditions . . . . . . . . . . . . . . . . . . . 33
9.1.5. GetDeviceStateResponse Message . . . . . . . . . . . 36 9.1.5. GetDeviceStateResponse Message . . . . . . . . . . . 33
9.1.6. Error Conditions . . . . . . . . . . . . . . . . . . 41 9.1.6. Error Conditions . . . . . . . . . . . . . . . . . . 38
9.1.7. TAM Processing Requirements . . . . . . . . . . . . . 42 9.1.7. TAM Processing Requirements . . . . . . . . . . . . . 39
9.2. Security Domain Management . . . . . . . . . . . . . . . 43 9.2. Security Domain Management . . . . . . . . . . . . . . . 40
9.2.1. CreateSD . . . . . . . . . . . . . . . . . . . . . . 43 9.2.1. CreateSD . . . . . . . . . . . . . . . . . . . . . . 40
9.2.1.1. CreateSDRequest Message . . . . . . . . . . . . . 43 9.2.1.1. CreateSDRequest Message . . . . . . . . . . . . . 40
9.2.1.2. Request Processing Requirements at a TEE . . . . 46 9.2.1.2. Request Processing Requirements at a TEE . . . . 43
9.2.1.3. CreateSDResponse Message . . . . . . . . . . . . 47 9.2.1.3. CreateSDResponse Message . . . . . . . . . . . . 44
9.2.1.4. Error Conditions . . . . . . . . . . . . . . . . 49 9.2.1.4. Error Conditions . . . . . . . . . . . . . . . . 46
9.2.2. UpdateSD . . . . . . . . . . . . . . . . . . . . . . 49 9.2.2. UpdateSD . . . . . . . . . . . . . . . . . . . . . . 46
9.2.2.1. UpdateSDRequest Message . . . . . . . . . . . . . 49 9.2.2.1. UpdateSDRequest Message . . . . . . . . . . . . . 46
9.2.2.2. Request Processing Requirements at a TEE . . . . 52 9.2.2.2. Request Processing Requirements at a TEE . . . . 49
9.2.2.3. UpdateSDResponse Message . . . . . . . . . . . . 54 9.2.2.3. UpdateSDResponse Message . . . . . . . . . . . . 51
9.2.2.4. Error Conditions . . . . . . . . . . . . . . . . 55 9.2.2.4. Error Conditions . . . . . . . . . . . . . . . . 52
9.2.3. DeleteSD . . . . . . . . . . . . . . . . . . . . . . 56 9.2.3. DeleteSD . . . . . . . . . . . . . . . . . . . . . . 53
9.2.3.1. DeleteSDRequest Message . . . . . . . . . . . . . 56 9.2.3.1. DeleteSDRequest Message . . . . . . . . . . . . . 53
9.2.3.2. Request Processing Requirements at a TEE . . . . 58 9.2.3.2. Request Processing Requirements at a TEE . . . . 55
9.2.3.3. DeleteSDResponse Message . . . . . . . . . . . . 59 9.2.3.3. DeleteSDResponse Message . . . . . . . . . . . . 56
9.2.3.4. Error Conditions . . . . . . . . . . . . . . . . 61 9.2.3.4. Error Conditions . . . . . . . . . . . . . . . . 58
9.3. Trusted Application Management . . . . . . . . . . . . . 61 9.3. Trusted Application Management . . . . . . . . . . . . . 58
9.3.1. InstallTA . . . . . . . . . . . . . . . . . . . . . . 62 9.3.1. InstallTA . . . . . . . . . . . . . . . . . . . . . . 59
9.3.1.1. InstallTARequest Message . . . . . . . . . . . . 63 9.3.1.1. InstallTARequest Message . . . . . . . . . . . . 60
9.3.1.2. InstallTAResponse Message . . . . . . . . . . . . 65 9.3.1.2. InstallTAResponse Message . . . . . . . . . . . . 62
9.3.1.3. Error Conditions . . . . . . . . . . . . . . . . 67 9.3.1.3. Error Conditions . . . . . . . . . . . . . . . . 64
9.3.2. UpdateTA . . . . . . . . . . . . . . . . . . . . . . 67 9.3.2. UpdateTA . . . . . . . . . . . . . . . . . . . . . . 64
9.3.2.1. UpdateTARequest Message . . . . . . . . . . . . . 68 9.3.2.1. UpdateTARequest Message . . . . . . . . . . . . . 65
9.3.2.2. UpdateTAResponse Message . . . . . . . . . . . . 70 9.3.2.2. UpdateTAResponse Message . . . . . . . . . . . . 67
9.3.2.3. Error Conditions . . . . . . . . . . . . . . . . 72 9.3.2.3. Error Conditions . . . . . . . . . . . . . . . . 69
9.3.3. DeleteTA . . . . . . . . . . . . . . . . . . . . . . 72 9.3.3. DeleteTA . . . . . . . . . . . . . . . . . . . . . . 69
9.3.3.1. DeleteTARequest Message . . . . . . . . . . . . . 72 9.3.3.1. DeleteTARequest Message . . . . . . . . . . . . . 69
9.3.3.2. Request Processing Requirements at a TEE . . . . 74 9.3.3.2. Request Processing Requirements at a TEE . . . . 71
9.3.3.3. DeleteTAResponse Message . . . . . . . . . . . . 75 9.3.3.3. DeleteTAResponse Message . . . . . . . . . . . . 72
9.3.3.4. Error Conditions . . . . . . . . . . . . . . . . 76 9.3.3.4. Error Conditions . . . . . . . . . . . . . . . . 73
10. Response Messages a TAM May Expect . . . . . . . . . . . . . 76 10. Response Messages a TAM May Expect . . . . . . . . . . . . . 73
11. Basic Protocol Profile . . . . . . . . . . . . . . . . . . . 77 11. Basic Protocol Profile . . . . . . . . . . . . . . . . . . . 74
12. Attestation Implementation Consideration . . . . . . . . . . 78 12. Attestation Implementation Consideration . . . . . . . . . . 75
12.1. OTrP Secure Boot Module . . . . . . . . . . . . . . . . 78 12.1. OTrP Secure Boot Module . . . . . . . . . . . . . . . . 75
12.1.1. Attestation signer . . . . . . . . . . . . . . . . . 78 12.1.1. Attestation signer . . . . . . . . . . . . . . . . . 75
12.1.2. SBM Initial Requirements . . . . . . . . . . . . . . 78 12.1.2. SBM Initial Requirements . . . . . . . . . . . . . . 75
12.2. TEE Loading . . . . . . . . . . . . . . . . . . . . . . 79 12.2. TEE Loading . . . . . . . . . . . . . . . . . . . . . . 76
12.3. Attestation Hierarchy . . . . . . . . . . . . . . . . . 79 12.3. Attestation Hierarchy . . . . . . . . . . . . . . . . . 76
12.3.1. Attestation Hierarchy Establishment: Manufacture . . 80 12.3.1. Attestation Hierarchy Establishment: Manufacture . . 77
12.3.2. Attestation Hierarchy Establishment: Device Boot . . 80 12.3.2. Attestation Hierarchy Establishment: Device Boot . . 77
12.3.3. Attestation Hierarchy Establishment: TAM . . . . . . 80 12.3.3. Attestation Hierarchy Establishment: TAM . . . . . . 77
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
13.1. Error Code List . . . . . . . . . . . . . . . . . . . . 81 13.1. Error Code List . . . . . . . . . . . . . . . . . . . . 78
13.1.1. TEE Signed Error Code List . . . . . . . . . . . . . 81 13.1.1. TEE Signed Error Code List . . . . . . . . . . . . . 78
13.1.2. OTrP Agent Error Code List . . . . . . . . . . . . . 82 13.1.2. OTrP Agent Error Code List . . . . . . . . . . . . . 79
14. Security Consideration . . . . . . . . . . . . . . . . . . . 82 14. Security Consideration . . . . . . . . . . . . . . . . . . . 79
14.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 82 14.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 79
14.2. Message Security . . . . . . . . . . . . . . . . . . . . 83 14.2. Message Security . . . . . . . . . . . . . . . . . . . . 80
14.3. TEE Attestation . . . . . . . . . . . . . . . . . . . . 83 14.3. TEE Attestation . . . . . . . . . . . . . . . . . . . . 80
14.4. TA Protection . . . . . . . . . . . . . . . . . . . . . 83 14.4. TA Protection . . . . . . . . . . . . . . . . . . . . . 80
14.5. TA Personalization Data . . . . . . . . . . . . . . . . 84 14.5. TA Personalization Data . . . . . . . . . . . . . . . . 81
14.6. TA Trust Check at TEE . . . . . . . . . . . . . . . . . 84 14.6. TA Trust Check at TEE . . . . . . . . . . . . . . . . . 81
14.7. One TA Multiple SP Case . . . . . . . . . . . . . . . . 85 14.7. One TA Multiple SP Case . . . . . . . . . . . . . . . . 82
14.8. OTrP Agent Trust Model . . . . . . . . . . . . . . . . . 85 14.8. OTrP Agent Trust Model . . . . . . . . . . . . . . . . . 82
14.9. OCSP Stapling Data for TAM Signed Messages . . . . . . . 85 14.9. OCSP Stapling Data for TAM Signed Messages . . . . . . . 82
14.10. Data Protection at TAM and TEE . . . . . . . . . . . . . 85 14.10. Data Protection at TAM and TEE . . . . . . . . . . . . . 82
14.11. Privacy Consideration . . . . . . . . . . . . . . . . . 85 14.11. Privacy Consideration . . . . . . . . . . . . . . . . . 82
14.12. Threat Mitigation . . . . . . . . . . . . . . . . . . . 86 14.12. Threat Mitigation . . . . . . . . . . . . . . . . . . . 83
14.13. Compromised CA . . . . . . . . . . . . . . . . . . . . . 86 14.13. Compromised CA . . . . . . . . . . . . . . . . . . . . . 83
14.14. Compromised TAM . . . . . . . . . . . . . . . . . . . . 87 14.14. Compromised TAM . . . . . . . . . . . . . . . . . . . . 84
14.15. Certificate Renewal . . . . . . . . . . . . . . . . . . 87 14.15. Certificate Renewal . . . . . . . . . . . . . . . . . . 84
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 87 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 87 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
16.1. Normative References . . . . . . . . . . . . . . . . . . 87 16.1. Normative References . . . . . . . . . . . . . . . . . . 84
16.2. Informative References . . . . . . . . . . . . . . . . . 88 16.2. Informative References . . . . . . . . . . . . . . . . . 85
Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . 88 Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . 85
A.1. Sample Security Domain Management Messages . . . . . . . 88 A.1. Sample Security Domain Management Messages . . . . . . . 85
A.1.1. Sample GetDeviceState . . . . . . . . . . . . . . . . 88 A.1.1. Sample GetDeviceState . . . . . . . . . . . . . . . . 85
A.1.1.1. Sample GetDeviceStateRequest . . . . . . . . . . 88 A.1.1.1. Sample GetDeviceStateRequest . . . . . . . . . . 85
A.1.1.2. Sample GetDeviceStateResponse . . . . . . . . . . 89 A.1.1.2. Sample GetDeviceStateResponse . . . . . . . . . . 86
A.1.2. Sample CreateSD . . . . . . . . . . . . . . . . . . . 92 A.1.2. Sample CreateSD . . . . . . . . . . . . . . . . . . . 89
A.1.2.1. Sample CreateSDRequest . . . . . . . . . . . . . 92 A.1.2.1. Sample CreateSDRequest . . . . . . . . . . . . . 89
A.1.2.2. Sample CreateSDResponse . . . . . . . . . . . . . 95 A.1.2.2. Sample CreateSDResponse . . . . . . . . . . . . . 92
A.1.3. Sample UpdateSD . . . . . . . . . . . . . . . . . . . 96 A.1.3. Sample UpdateSD . . . . . . . . . . . . . . . . . . . 93
A.1.3.1. Sample UpdateSDRequest . . . . . . . . . . . . . 97 A.1.3.1. Sample UpdateSDRequest . . . . . . . . . . . . . 94
A.1.3.2. Sample UpdateSDResponse . . . . . . . . . . . . . 98 A.1.3.2. Sample UpdateSDResponse . . . . . . . . . . . . . 95
A.1.4. Sample DeleteSD . . . . . . . . . . . . . . . . . . . 98 A.1.4. Sample DeleteSD . . . . . . . . . . . . . . . . . . . 95
A.1.4.1. Sample DeleteSDRequest . . . . . . . . . . . . . 98 A.1.4.1. Sample DeleteSDRequest . . . . . . . . . . . . . 95
A.1.4.2. Sample DeleteSDResponse . . . . . . . . . . . . . 100 A.1.4.2. Sample DeleteSDResponse . . . . . . . . . . . . . 97
A.2. Sample TA Management Messages . . . . . . . . . . . . . . 102
A.2.1. Sample InstallTA . . . . . . . . . . . . . . . . . . 102
A.2.1.1. Sample InstallTARequest . . . . . . . . . . . . . 102
A.2.1.2. Sample InstallTAResponse . . . . . . . . . . . . 103
A.2.2. Sample UpdateTA . . . . . . . . . . . . . . . . . . . 105
A.2.2.1. Sample UpdateTARequest . . . . . . . . . . . . . 105
A.2.2.2. Sample UpdateTAResponse . . . . . . . . . . . . . 106
A.2.3. Sample DeleteTA . . . . . . . . . . . . . . . . . . . 109
A.2.3.1. Sample DeleteTARequest . . . . . . . . . . . . . 109
A.2.3.2. Sample DeleteTAResponse . . . . . . . . . . . . . 111
A.3. Example OTrP Agent Option . . . . . . . . . . . . . . . . 113
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113
1. Introduction
The Trusted Execution Environment (TEE) concept has been designed and
used to increase security by separating a regular operating system,
also referred as a Rich Execution Environment (REE), from security-
sensitive applications. In an TEE ecosystem, a Trusted Application
Manager (TAM) is used to manage keys and the Trusted Applications
(TA) that run in a device. Different device vendors may use
different TEE implementations. Different application providers may
use different TAM providers. There arises a need of an open
interoperable protocol that establishes trust between different
devices and TAM providers, and management capability for a
trustworthy TAM to manage Security Domains and applications running
in different TEEs of various devices.
The Open Trust Protocol (OTrP) defines a mutual trust message
protocol between a TAM and a TEE and relies on IETF-defined end-to-
end security mechanisms, namely JSON Web Encryption (JWE), JSON Web
Signature (JWS), and JSON Web Key (JWK). Other message encoding
methods may be supported.
This specification assumes that an applicable device is equipped with
a TEE and is pre-provisioned with a device-unique public/private key
pair, which is securely stored. This key pair is referred as the
'root of trust'. An entity that uses such a device to run Trusted
Applications (TAs) is known as a Service Provider (SP).
A Security Domain is defined as the TEE representation of a Service A.2. Sample TA Management Messages . . . . . . . . . . . . . . 99
Provider, which is a logical space that contains the SP's TAs. Each A.2.1. Sample InstallTA . . . . . . . . . . . . . . . . . . 99
Security Domain requires the management operations of TAs in the form A.2.1.1. Sample InstallTARequest . . . . . . . . . . . . . 99
of installation, update and deletion. A.2.1.2. Sample InstallTAResponse . . . . . . . . . . . . 100
A.2.2. Sample UpdateTA . . . . . . . . . . . . . . . . . . . 102
A.2.2.1. Sample UpdateTARequest . . . . . . . . . . . . . 102
A.2.2.2. Sample UpdateTAResponse . . . . . . . . . . . . . 103
A.2.3. Sample DeleteTA . . . . . . . . . . . . . . . . . . . 106
A.2.3.1. Sample DeleteTARequest . . . . . . . . . . . . . 106
A.2.3.2. Sample DeleteTAResponse . . . . . . . . . . . . . 108
A.3. Example OTrP Agent Option . . . . . . . . . . . . . . . . 110
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 110
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110
The protocol builds on the following properties of the system: 1. Introduction
1. The SP needs to determine security-relevant information of a The Trusted Execution Environment (TEE) concept has been designed to
device before provisioning information to a TEE. Examples separate a regular operating system, also referred as a Rich
include the verification of the device 'root of trust', the type Execution Environment (REE), from security-sensitive applications.
of firmware installed, and the type of TEE included in a device. In an TEE ecosystem, different device vendors may use different TEE
implementations. Different application providers or device
administrators may choose to use different TAM providers. There
calls for an interoperable protocol for managing TAs running in
different TEEs of various devices is needed.
2. A TEE in a device needs to determine whether an SP or a TAM is The Trusted Execution Environment Provisioning (TEEP) architecture
trustworthy or authorized to manage applications in the TEE. document [TEEPArch] has set to provide a design guidance for such an
interoperable protocol. This document specifies an Open Trust
Protocol (OTrP) that follows the architecture guidance.
3. Secure Boot must be able to ensure a TEE is genuine. OTrP defines a mutual trust message protocol between a TAM and a TEE
and relies on IETF-defined end-to-end security mechanisms, namely
JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Key
(JWK). Other message encoding methods may be supported.
This specification defines message payloads exchanged between devices 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: A TA binary and personalization data can be from two sources:
1. A TAM supplies the signed and encrypted TA binary 1. A TAM supplies the signed and encrypted TA binary
2. A Client Application supplies the TA binary 2. A Client Application supplies the TA binary
skipping to change at page 6, line 47 skipping to change at page 6, line 16
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.
The same terms may be defined differently in other documents. All the terms defined in the TEEP Architecture document [TEEPArch]
will be used, which are not repeated in this document.
Client Application: An application running on a rich OS, such as an
Android, Windows, or iOS application, typically provided by an
SP.
Device: A physical piece of hardware that hosts a TEE along with a
rich OS.
OTrP Agent: An application running in the rich OS allowing
communication with the TAM and the TEE.
Rich Application: Alternative name of "Client Application". In this
document we may use these two terms interchangeably.
Rich Execution Environment (REE) An environment that is provided and
governed by a standard OS, potentially in conjunction with other
supporting operating systems and hypervisors; it is outside of
the TEE. This environment and applications running on it are
considered un-trusted.
Secure Boot Module (SBM): A firmware in a device that delivers
secure boot functionality. It is generally signed and can be
verified whether it can be trusted. We also call it a Trusted
Firmware (TFW).
Service Provider (SP): An entity that wishes to supply Trusted
Applications to remote devices. A Service Provider requires the
help of a TAM in order to provision the Trusted Applications to
the devices.
Trust Anchor: A root certificate that can be used to validate its
children certificates. It is usually embedded in a device or
configured by a TAM for validating the trust of a remote entity's
certificate.
Trusted Application (TA): An Application that runs in a TEE.
Trusted Execution Environment (TEE): An execution environment that OTrP Agent: It is the Agent as defined in the TEEP Architecture
runs alongside of, but is isolated from, an REE. A TEE has document [TEEPArch].
security capabilities and meets certain security-related
requirements. It protects TEE assets from general software
attacks, defines rigid safeguards as to data and functions that a
program can access, and resists a set of defined threats. It
should have at least the following three properties: (a) A unique
security identity that cannot be cloned; (b) Assurance that only
authorized code can run in the TEE; (c) Memory that cannot be
read by code outside of TEE. There are multiple technologies
that can be used to implement a TEE, and the level of security
achieved varies accordingly.
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
skipping to change at page 8, line 44 skipping to change at page 6, line 48
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 following are the main components in this OTrP system. The same system components as defined in the TEEP Architecture
document [TEEPArch] are used in OTrP, including TAM, CA, TEE, REE,
TAM: The TAM is responsible for originating and coordinating and OTrP Agent (a.k.a Agent).
lifecycle management activity on a particular TEE.
A TAM manages device trust check on behalf of Service Providers.
A TAM may be used by one SP or many SPs. A TAM also provides
Security Domain management and TA management in a device, in
particularly, over-the-air update to keep TAs up-to-date and
clean up when a version should be removed.
Certificate Authority (CA): Mutual trust between a device and a TAM
as well as an SP is based on certificates. A device embeds a
list of root certificates, called Trust Anchors, from trusted
Certificate Authorities that a TAM will be validated against. A
TAM will remotely attest a device by checking whether a device
comes with a certificate from a trusted CA.
TEE: The TEE in a device is responsible for protecting applications
from attack, enabling the application to perform secure
operations.
REE: The REE is responsible for enabling off device communications
to be established between the TEE and TAM. OTrP does not require
the device OS to be secure.
OTrP Agent: An application in the REE that can relay messages
between a Client Application and TEE. Its implementation can be
TEE specific as to how it can interact with a TEE in a device.
Secure Boot: Secure boot (for the purposes of OTrP) must enable
authenticity checking of TEEs by the TAM.
The OTrP establishes appropriate trust anchors to enable TEEs and Secure boot (for the purposes of OTrP) is optional in enabling
TAMs to communicate in a trusted way when performing lifecycle authenticity checking of TEEs by the TAM. A TAM provider can choose
management transactions. it policy whether it trusts a TEE if the underlying firmware
attestation information isn't included.
4.2. Trusted Anchors in TEE OTrP uses trust anchors to establish trust between TEEs and TAMs and
verifies that they communicate in a trusted way when performing
lifecycle management transactions.
The TEE in each device comes with a trust store that contains a 4.2. Trust Anchors in TEE
whitelist of the TAM's root CA certificates, which are called Trust
Anchors. A TAM will be trusted to manage Security Domains and TAs in
a device only if the TAM's certificate is chained to one of the root
CA certificates in this trust store.
Such a list is typically embedded in the TEE of a device, and the This assumes the Trust Anchor specification defined in the TEEP
list update should be generally enabled. Architecture document [TEEPArch].
Before a TAM can begin operation in the marketplace to support Each TEE comes with a trust store that contains a whitelist of root
devices of a given TEE, it must obtain a TAM certificate from a CA CA certificates that are used to validate a TAM's certificate. A TEE
that is registered in the trust store of the TEE. will accept a TAM to create new Security Domains and install new TAs
on behalf of a SP only if the TAM's certificate is chained to one of
the root CA certificates in the TEE's trust store.
4.3. Trusted Anchors in TAM 4.3. Trust Anchors in TAM
The Trust Anchor set in a TAM consists of a list of Certificate The Trust Anchor set in a TAM consists of a list of Certificate
Authority certificates that signs various device TEE certificates. A Authority certificates that signs various device TEE certificates. A
TAM decides what TEE and optionally TFW it will trust. TAM decides what TEE and optionally TFW it will trust when TFW
signature data is present in an attestation.
4.4. Keys and Certificate Types 4.4. Keys and Certificate Types
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.
+-------------+----------+--------+-------------------+-------------+ +-------------+----------+--------+-------------------+-------------+
skipping to change at page 13, 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.
It should be noted that network communication capability is generally An OTrP Agent is used to bridge communication between a TAM and a
not available in today's TEE powered devices. The networking TEE. The OTrP Agent doesn't need to know the actual content of OTrP
functionality is handled by a rich Client Application with a remote Messages except for the TEE routing information.
internet services; the Client Applications uses a local TEE interface
such as inter-process or a secure shared memory approach to interact
with TA inside a TEE for message exchanges. Consequently, a TAM
generally communicates with a Client Application about how it gets
OTrP Messages that originates from TEE inside a device. Similarly, a
TA or TEE generally gets OTrP messages from a TAM via some Client
Application, not direct to the internet.
It is imperative to have an interoperable interface to communicate
with different TEEs in different devices that a Client Application
needs to run and access a TA inside a TEE. This is the role of an
OTrP Agent, which is a software component to bridge communication
between a TAM and a TEE. The OTrP Agent doesn't need to know the
actual content of OTrP 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
3. [Soc] Deliver TFW Image 3. [Soc] Deliver TFW Image
skipping to change at page 35, line 11 skipping to change at page 32, line 11
2. Validate that the request TAM certificate is chained to a trusted 2. Validate that the request TAM certificate is chained to a trusted
CA that the TEE embeds as its trust anchor. CA that the TEE embeds as its trust anchor.
* Cache the CA OCSP stapling data and certificate revocation * Cache the CA OCSP stapling data and certificate revocation
check status for other subsequent requests. check status for other subsequent requests.
* A TEE can use its own clock time for the OCSP stapling data * A TEE can use its own clock time for the OCSP stapling data
validation. validation.
3. Collect Firmware signed data 3. Optionally collect Firmware signed data
* This is a capability in ARM architecture that allows a TEE to * This is a capability in ARM architecture that allows a TEE to
query Firmware to get FW signed data. query Firmware to get FW signed data. It isn't required for
all TEE implementations. When TFW signed data is absent, it
is up to a TAM's policy how it will trust a TEE.
4. Collect SD information for the SD owned by this TAM 4. Collect SD information for the SD owned by this TAM
9.1.3. Firmware Signed Data 9.1.3. Firmware Signed Data
Firmware isn't expected to process or produce JSON data. It is Firmware isn't expected to process or produce JSON data. It is
expected to just sign some raw bytes of data. expected to just sign some raw bytes of data.
The data to be signed by TFW key needs be some unique random data The data to be signed by TFW key needs be some unique random data
each time. The (UTF-8 encoded) "tid" value from the each time. The (UTF-8 encoded) "tid" value from the
GetDeviceStateTBSRequest shall be signed by the firmware. TAM isn't GetDeviceStateTBSRequest shall be signed by the firmware. TAM isn't
expected to parse TFW data except the signature validation and signer expected to parse TFW data except the signature validation and signer
trust path validation. trust path validation.
It is possible that a TEE can get some valid TFW signed data from It is possible that a TEE can get some valid TFW signed data from
another device. The TEE is responsible to validate TFW integrity to another device. The TEE is responsible to validate TFW integrity to
ensure that the underlying device firmware is trustworthy. A TAM ensure that the underlying device firmware is trustworthy. In some
trusts the TEE and the TFW trust status check carried out by the TEE. cases, a TEE isn't able to get a TFW signed data, in which case the
TEE trust validation is up to a TAM to decide. A TAM may opt to
trust a TEE basing on the TEE signer and additional information about
a TEE out-of-band.
When TFW signed data is available, a TAM validates the TEE and trusts
that a trusted TEE has carried out appropriate trust check about a
TFW.
TfwData: { TfwData: {
"tbs": "<TFW to be signed data, BASE64 encoded>", "tbs": "<TFW to be signed data, BASE64 encoded>",
"cert": "<BASE64 encoded TFW certificate>", "cert": "<BASE64 encoded TFW certificate>",
"sigalg": "Signing method", "sigalg": "Signing method",
"sig": "<TFW signed data, BASE64 encoded>" "sig": "<TFW signed data, BASE64 encoded>"
} }
It is expected that a FW uses standard signature methods for maximal It is expected that a FW uses standard signature methods for maximal
interoperability with TAM providers. The mandatory support list of interoperability with TAM providers. The mandatory support list of
skipping to change at page 88, line 25 skipping to change at page 85, line 25
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
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]
Pei, M., Tschofenig, H., Atyeo, A., and D. Liu, "Trusted
Execution Environment Provisioning (TEEP) Architecture",
2018.
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.
Appendix A. Sample Messages Appendix A. Sample Messages
skipping to change at page 114, line 26 skipping to change at page 111, line 26
Korea Korea
Email: paromix@gmail.com Email: paromix@gmail.com
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. 30 change blocks. 
313 lines changed or deleted 214 lines changed or added

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