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/ |