wdiff draft-pei-opentrustprotocol-05.txt draft-pei-opentrustprotocol-06.txt

Internet Engineering Task Force M. Pei
Internet-Draft Symantec
Intended status: Informational N. Cook
Expires: July 18, September 16, 2018 ARM Ltd.
M. Yoo
Solacia
A. Atyeo
Intercede
H. Tschofenig
ARM Ltd.
January 14,
March 15, 2018

The Open Trust Protocol (OTrP)
draft-pei-opentrustprotocol-05.txt
draft-pei-opentrustprotocol-06.txt

Abstract

This document specifies the Open Trust Protocol (OTrP), a protocol to
install, update, and delete applications and to manage security
configuration in a Trusted Execution
Environment (TEE). (TEE) and to manage their security configuration.

TEEs are used in environments where security services should be
isolated from a regular operating system (often called rich OS).
This form of compartmentlization 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

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 18, September 16, 2018.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 8
4. OTrP Entities and Trust Model . . . . . . . . . . . . . . . . 8
4.1. System Components . . . . . . . . . . . . . . . . . . . . 8
4.2. Trusted Anchors in TEE . . . . . . . . . . . . . . . . . 9
4.3. Trusted Anchors in TSM TAM . . . . . . . . . . . . . . . . . 9 10
4.4. Keys and Cerificate Types . . . . . . . . . . . . . . . . 9 10
5. Protocol Scope and Entity Relations . . . . . . . . . . . . . 12
5.1. A Sample Device Setup Flow . . . . . . . . . . . . . . . 14
5.2. Derived Keys in The Protocol . . . . . . . . . . . . . . 14 15
5.3. Security Domain Hierarchy and Ownership . . . . . . . . . 15
5.4. SD Owner Identification and TSM TAM Certificate Requirements 16
5.5. Service Provider Container . . . . . . . . . . . . . . . 16
6. OTrP Agent . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Role of OTrP Agent . . . . . . . . . . . . . . . . . . . 17 18
6.2. OTrP Agent and Global Platform TEE Client API . . . . . . 18
6.3. OTrP Agent Implementation Consideration . . . . . . . . . 18
6.3.1. OTrP Agent Distribution . . . . . . . . . . . . . . . 18
6.3.2. Number of OTrP Agent . . . . . . . . . . . . . . . . 18
6.3.3. OTrP Android Service Option . . . . . . . . . . . . . 19
6.4. OTrP Agent API Interfaces for Client Applications . . . . . . . . . 19
6.4.1. API processMessage . . ProcessOTrPMessage call . . . . . . . . . . . . . . . 19
6.4.2. API getTAInformation GetTAInformation call . . . . . . . . . . . . . . . . 20
6.5. Sample End-to-End Client Application Flow . . . . . . . . 22 23
6.5.1. Case 1: A New Client Application Uses a TA . . . . . 22 23
6.5.2. Case 2: A Previously Installed Client Application
Calls a TA . . . . . . . . . . . . . . . . . . . . . 24
7. OTrP Messages . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 25
7.2. Message Naming Convention . . . . . . . . . . . . . . . . 25
7.3. Request and Response Message Template . . . . . . . . . . 26
7.4. Signed Request and Response Message Structure . . . . . . 26
7.4.1. Identifying Signing and Encryption Keys for JWS/JWE
Messaging . . . . . . . . . . . . . . . . . . . . . . 28
7.5. JSON Signing and Encryption Algorithms . . . . . . . . . 28
7.5.1. Supported JSON Signing Algorithms . . . . . . . . . . 30
7.5.2. Support JSON Encryption Algorithms . . . . . . . . . 30
7.5.3. Supported JSON Key Management Algorithms . . . . . . 30
7.6. Common Errors . . . . . . . . . . . . . . . . . . . . . . 31
7.7. OTrP Message List . . . . . . . . . . . . . . . . . . . . 31
7.8. OTrP Request Message Routing Rules . . . . . . . . . . . 32
7.8.1. SP Anonymous Attestation Key (SP AIK) . . . . . . . . 32
8. Transport Protocol Support . . . . . . . . . . . . . . . . . 32
9. Detailed Messages Specification . . . . . . . . . . . . . . . 32
8.1. 33
9.1. GetDeviceState . . . . . . . . . . . . . . . . . . . . . 33
8.1.1.
9.1.1. GetDeviceStateRequest message . . . . . . . . . . . . 33
8.1.2.
9.1.2. Request processing requirements at a TEE . . . . . . 34
8.1.3.
9.1.3. Firmware Signed Data . . . . . . . . . . . . . . . . 35
8.1.3.1.
9.1.3.1. Supported Firmware Signature Methods . . . . . . 35
8.1.4. 36
9.1.4. Post Conditions . . . . . . . . . . . . . . . . . . . 36
8.1.5.
9.1.5. GetDeviceStateResponse Message . . . . . . . . . . . 36
8.1.6.
9.1.6. Error Conditions . . . . . . . . . . . . . . . . . . 40
8.1.7. TSM 41
9.1.7. TAM Processing Requirements . . . . . . . . . . . . . 41
8.2. 42
9.2. Security Domain Management . . . . . . . . . . . . . . . 42
8.2.1. 43
9.2.1. CreateSD . . . . . . . . . . . . . . . . . . . . . . 42
8.2.1.1. 43
9.2.1.1. CreateSDRequest Message . . . . . . . . . . . . . 42
8.2.1.2. 43
9.2.1.2. Request Processing Requirements at a TEE . . . . 45
8.2.1.3. 46
9.2.1.3. CreateSDResponse Message . . . . . . . . . . . . 46
8.2.1.4. 47
9.2.1.4. Error Conditions . . . . . . . . . . . . . . . . 47
8.2.2. 49
9.2.2. UpdateSD . . . . . . . . . . . . . . . . . . . . . . 48
8.2.2.1. 49
9.2.2.1. UpdateSDRequest Message . . . . . . . . . . . . . 48
8.2.2.2. 49
9.2.2.2. Request Processing Requirements at a TEE . . . . 51
8.2.2.3. 52
9.2.2.3. UpdateSDResponse Message . . . . . . . . . . . . 53
8.2.2.4. 54
9.2.2.4. Error Conditions . . . . . . . . . . . . . . . . 54
8.2.3. 55
9.2.3. DeleteSD . . . . . . . . . . . . . . . . . . . . . . 55
8.2.3.1. 56
9.2.3.1. DeleteSDRequest Message . . . . . . . . . . . . . 55
8.2.3.2. 56
9.2.3.2. Request Processing Requirements at a TEE . . . . 57
8.2.3.3. 58
9.2.3.3. DeleteSDResponse Message . . . . . . . . . . . . 58
8.2.3.4. 59
9.2.3.4. Error Conditions . . . . . . . . . . . . . . . . 60
8.3. 61
9.3. Trusted Application Management . . . . . . . . . . . . . 60
8.3.1. 61
9.3.1. InstallTA . . . . . . . . . . . . . . . . . . . . . . 60
8.3.1.1. 62
9.3.1.1. InstallTARequest Message . . . . . . . . . . . . 62
8.3.1.2. 63
9.3.1.2. InstallTAResponse Message . . . . . . . . . . . . 64
8.3.1.3. 65
9.3.1.3. Error Conditions . . . . . . . . . . . . . . . . 65
8.3.2. 67
9.3.2. UpdateTA . . . . . . . . . . . . . . . . . . . . . . 65
8.3.2.1. 67
9.3.2.1. UpdateTARequest Message . . . . . . . . . . . . . 67
8.3.2.2. 68
9.3.2.2. UpdateTAResponse Message . . . . . . . . . . . . 68
8.3.2.3. 70
9.3.2.3. Error Conditions . . . . . . . . . . . . . . . . 70
8.3.3. 72
9.3.3. DeleteTA . . . . . . . . . . . . . . . . . . . . . . 70
8.3.3.1. 72
9.3.3.1. DeleteTARequest Message . . . . . . . . . . . . . 70
8.3.3.2. 72
9.3.3.2. Request Processing Requirements at a TEE . . . . 72
8.3.3.3. 74
9.3.3.3. DeleteTAResponse Message . . . . . . . . . . . . 73
8.3.3.4. 75
9.3.3.4. Error Conditions . . . . . . . . . . . . . . . . 74
9. 76
10. Response Messages a TSM TAM May Expect . . . . . . . . . . . . . 74
10. 76
11. Basic Protocol Profile . . . . . . . . . . . . . . . . . . . 75
11. 77
12. Attestation Implementation Consideration . . . . . . . . . . 76
11.1. 78
12.1. OTrP Secure Boot Module . . . . . . . . . . . . . . . . 76
11.1.1. 78
12.1.1. Attestation signer . . . . . . . . . . . . . . . . . 76
11.1.2. 78
12.1.2. SBM Initial Requirements . . . . . . . . . . . . . . 76
11.2. 78
12.2. TEE Loading . . . . . . . . . . . . . . . . . . . . . . 77
11.3. 79
12.3. Attestation Hierarchy . . . . . . . . . . . . . . . . . 77
11.3.1. 79
12.3.1. Attestation Hierarchy Establishment: Manufacture . . 78
11.3.2. 80
12.3.2. Attestation Hierarchy Establishment: Device Boot . . 78
11.3.3. 80
12.3.3. Attestation Hierarchy Establishment: TSM TAM . . . . . . 78
12. 80
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
13. 81
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 79
14. 81
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
14.1. 81
15.1. Error Code List . . . . . . . . . . . . . . . . . . . . 79
15. 81
15.1.1. TEE Signed Error Code List . . . . . . . . . . . . . 81
15.1.2. OTrP Agent Error Code List . . . . . . . . . . . . . 83
16. Security Consideration . . . . . . . . . . . . . . . . . . . 80
15.1. 83
16.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 81
15.2. 83
16.2. Message Security . . . . . . . . . . . . . . . . . . . . 81
15.3. 83
16.3. TEE Attestation . . . . . . . . . . . . . . . . . . . . 81
15.4. 84
16.4. TA Protection . . . . . . . . . . . . . . . . . . . . . 82
15.5. 84
16.5. TA Personalization Data . . . . . . . . . . . . . . . . 82
15.6. 84
16.6. TA Trust Check at TEE . . . . . . . . . . . . . . . . . 82
15.7. 85
16.7. One TA Multiple SP Case . . . . . . . . . . . . . . . . 83
15.8. 85
16.8. OTrP Agent Trust Model . . . . . . . . . . . . . . . . . 83
15.9. 85
16.9. OCSP Stapling Data for TSM TAM Signed Messages . . . . . . . 83
15.10. 86
16.10. Data Protection at TSM TAM and TEE . . . . . . . . . . . . . 84
15.11. 86
16.11. Privacy Consideration . . . . . . . . . . . . . . . . . 84
15.12. 86
16.12. Threat Mitigation . . . . . . . . . . . . . . . . . . . 84
15.13. 86
16.13. Compromised CA . . . . . . . . . . . . . . . . . . . . . 85
15.14. 87
16.14. Compromised TSM TAM . . . . . . . . . . . . . . . . . . . . 85
15.15. 87
16.15. Certificate Renewal . . . . . . . . . . . . . . . . . . 85
16. 88
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 85
16.1. 88
17.1. Normative References . . . . . . . . . . . . . . . . . . 85
16.2. 88
17.2. Informative References . . . . . . . . . . . . . . . . . 86 88
Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . 86 89
A.1. Sample Security Domain Management Messages . . . . . . . 86 89
A.1.1. Sample GetDeviceState . . . . . . . . . . . . . . . . 86 89
A.1.1.1. Sample GetDeviceStateRequest . . . . . . . . . . 86 89
A.1.1.2. Sample GetDeviceStateResponse . . . . . . . . . . 87 89
A.1.2. Sample CreateSD . . . . . . . . . . . . . . . . . . . 90 93
A.1.2.1. Sample CreateSDRequest . . . . . . . . . . . . . 90 93
A.1.2.2. Sample CreateSDResponse . . . . . . . . . . . . . 93 96
A.1.3. Sample UpdateSD . . . . . . . . . . . . . . . . . . . 94 97
A.1.3.1. Sample UpdateSDRequest . . . . . . . . . . . . . 95 98
A.1.3.2. Sample UpdateSDResponse . . . . . . . . . . . . . 96 99
A.1.4. Sample DeleteSD . . . . . . . . . . . . . . . . . . . 96 99
A.1.4.1. Sample DeleteSDRequest . . . . . . . . . . . . . 96 99
A.1.4.2. Sample DeleteSDResponse . . . . . . . . . . . . . 98 101
A.2. Sample TA Management Messages . . . . . . . . . . . . . . 100 103
A.2.1. Sample InstallTA . . . . . . . . . . . . . . . . . . 100 103
A.2.1.1. Sample InstallTARequest . . . . . . . . . . . . . 100 103
A.2.1.2. Sample InstallTAResponse . . . . . . . . . . . . 101 104
A.2.2. Sample UpdateTA . . . . . . . . . . . . . . . . . . . 103 106
A.2.2.1. Sample UpdateTARequest . . . . . . . . . . . . . 103 106
A.2.2.2. Sample UpdateTAResponse . . . . . . . . . . . . . 104 107
A.2.3. Sample DeleteTA . . . . . . . . . . . . . . . . . . . 107 110
A.2.3.1. Sample DeleteTARequest . . . . . . . . . . . . . 107 110
A.2.3.2. Sample DeleteTAResponse . . . . . . . . . . . . . 109 112
A.3. Example OTrP Agent Option . . . . . . . . . . . . . . . . 114
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111 114

1. Introduction

The Trusted Execution Environment (TEE) concept has been designed and
used to increase security by separating a regular operating systems, system,
also referred as a Rich Execution Environment (REE), from security-
sensitive applications. In an TEE ecosystem, a Trust Service Trusted Application
Manager
(TSM) (TAM) is used to authorize 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 TSM TAM providers. There arises a need of an open
interoperable protocol that allows establishes trust between different
devices and TAM providers, and management capability for a
trustworthy TSM TAM to manage Security Domains and contents applications running
in different Trusted Execution
Environment (TEE) TEEs of various devices.

The Open Trust Protocol (OTrP) defines a mutual trust message
protocol between a TSM TAM and a TEE and relies on IETF-defined end-to-end 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 a an applicable device that utilizes this
specification 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'. A Service Provider
(SP) An entity that uses such a device to run Trusted
Applications (TA). (TAs) is known as a Service Provider (SP).

A security domain Security Domain is defined as the TEE representation of a service
provider and Service
Provider, which is a logical space that contains the service provider's
Trusted Applications. SP's TAs. Each security domain
Security Domain requires the management operations of Trusted Applications (TAs) TAs in the form
of installation, update and deletion.

The protocol builds on the following properties of the system:

1. The SP needs to determine security-relevant information of a
device before provisioning information to a TEE. Examples
include the verification of the root device 'root of trust, trust', the type
of firmware installed, and the type of TEE included in a device.

2. A TEE in a device needs to determine whether a an SP or the TSM a TAM is
trustworthy or authorized to manage applications in the TEE.

3. Secure Boot must be able to ensure a TEE is genuine.

This specification defines message payloads exchanged between devices
and a TSM but does not mandate a specific transport. TAM. The messages are designed in anticipation of the use of
the most common transport methods such as HTTPS via a wired or wireless network between a
device HTTPS.

A TA binary and a remote TSM web service. personalization data can be from two sources:

1. A TAM supplies the signed and encrypted TA binary

2. A Client Application supplies the TA binary

This specification considers the first case where TA binary and
personalization data are encrypted by recipient's public key that TAM
has to be involved. The second case will be addressed separately.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

3. Terminology

3.1. Definitions

The definitions provided below are defined as used in this document.
The same terms may be defined differently in other documents.

Client Application: An application running on a rich OS, such as an
Android, Windows, or iOS application, typically provided by a an
SP.

Device: A physical piece of hardware that hosts symmetric key
cryptographic modules a TEE along with a
rich OS.

OTrP Agent: An application running in the rich OS allowing
communication with the TSM TAM and the TEE.

Rich Application: Alternative name of "Client Application". In this
document we may use these two terms interchangably.

Rich Execution Environment (REE) An environment that is provided and
governed by a rich 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 referred as call it a Trusted
Firmware (TFW) in this document. (TFW).

Service Provider (SP): An entity that wishes to supply Trusted
Applications to remote devices. A Service Provider requires the
help of a TSM TAM in order to provision the Trusted Applications to
the devices.

Trust Anchor: A root certificate that a module trusts. can be used to validate its
children certificates. It is usually embedded in one a device or
configured by a TAM for validating module, and used to validate 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
runs alongside of, but is isolated from from, an REE. A TEE has
security capabilities and meets certain security-related requirements:
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) Assuance 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

CA Certificate Authority

OTrP Open Trust Protocol

REE Rich Execution Environment

SD Security Domain

SP Service Provider

SBM Secure Boot Module

TA Trusted Application

TEE Trusted Execution Environment

TFW Trusted Firmware

TSM

TAM Trusted Service Application Manager

4. OTrP Entities and Trust Model

4.1. System Components

There

The following are the following main components in this OTrP system.

TSM:

TAM: The TSM TAM is responsible for originating and coordinating
lifecycle management activity on a particular TEE.

A Trust Service Manager (TSM) is at the core to the protocol that TAM manages device trust check on behalf of service providers for the
ecosystem scalability. In addition to its device trust
management for a service provider, the TSM 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 Trusted Applications up to date TAs up-to-date and
clean up when a version should be removed.

In the context of this specification, the term Trusted
Application Manager (TAM) and TSM are synonymous.

Certificate Authority (CA): Mutual trust between a device and a TSM TAM
as well as a Service Provider an SP is based on certificates. A device embeds a
list of root certificates, called Trust Anchors, from trusted
Certificate Authorities that a TSM TAM will be validated against. A TSM
TAM will remotely attest a device by checking whether a device
comes with a certificate from a trusted CA.

TEE: The TEE resides in the a device chip security zone and is responsible for protecting applications
from attack, enabling the application to perform secure operations
operations.

REE: The REE, usually called device OS such as Android OS in a phone
device, REE is responsible for enabling off device communications
to be established between the TEE and TSM. 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 TSM. TAM.

The OTrP establishes appropriate trust anchors to enable TEE TEEs and TSMs
TAMs to communicate in a trusted way when performing lifecycle
management transactions. The main trust relationships between the components
are the following.

1. TSM must be able to ensure a TEE is genuine

2. TEE must be able to ensure a TSM is genuine

3. Secure Boot must be able to ensure a TEE is genuine

4.2. Trusted Anchors in TEE

The TEE in each device comes with a trust store that contains a
whitelist of TSM's the TAM's root CA certificates, which are called Trust
Anchors. A TSM TAM will be trusted to manage Security Domains and TAs in
a device only if its 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
list update should be generally enabled.

Before a TAM can begin operation in the marketplace to support
devices of a given TEE, it must obtain a TAM certificate from a CA
that is enabled and handled by device OEM provider. registered in the trust store of the TEE.

4.3. Trusted Anchors in TSM TAM

The Trust Anchor set in a TSM TAM consists of a list of Certificate
Authority certificates that signs various device TEE certificates. A
TSM
TAM decides what TEE and optionally TFW it will trust.

4.4. Keys and Cerificate Types

OTrP Protocol leverages the following list of trust anchors and identities in
generating signed and encrypted command messages that are exchanged
between a device with device's TEE and a TSM. TAM. With these security artifacts,
OTrP Messages are able to deliver end-to-end security without relying
on any transport security.

Table 1: Key and Certificate Types

1. TFW keypair key pair and Certificate: certificate: A key pair and certificate for
evidence of secure boot and trustworthy firmware in a device.

Location: Device secure storage

Supported Key Type: RSA and ECC
Issuer: OEM CA

Trust Implication: A white list of FW root CA trusted by TSMs TAMs

Cardinality: One per device

2. TEE keypair key pair and Certificate: certificate: It is used for device attestation
to a remote TSM TAM and SP.

This key pair is burned into the device at device manufacturer.
The key pair and its certificate are valid for the expected
lifetime of the device.

Location: Device TEE

Supported Key Type: RSA and ECC

Issuer: TEE A CA that chains to a TEE root CA

Trust Implication: A white list of TEE root CA trusted by TSMs TAMs

Cardinality: One per device

3. TSM keypair TAM key pair and Certificate: certificate: A TSM TAM provider acquires a
certificate from a CA that a TEE trusts.

Location: TSM TAM provider

Supported Key Type: RSA and ECC.

Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other
sizes should be anticipated in future.

Issuer: TSM TAM CA that chains to a root CA

Trust Implication: A white list of TSM TAM root CA embedded in TEE

Cardinality: One or multiple can be used by a TSM TAM

4. SP keypair key pair and Certificate: A certificate: an SP uses its own key pair and
certificate to sign a TA.

Location: SP

Supported Key Type: RSA and ECC

Supported Key Size: RSA 2048-bit, ECC P-256 and P-384 P-384. Other
sizes should be anticipated in future.

Issuer: an SP signer CA that chains to a root CA

Trust Implication: TSM TAM manages SP. TA trusts an SP by
validating trust is delegated to
TSM. against a TAM that the SP uses. A TEE trusts TSM
TAM to ensure that a TA from the TAM is trustworthy.

Cardinality: One or multiple can be used by a an SP

5. Protocol Scope and Entity Relations

This document specifies the minimally required interoperable
artifacts to messages and key properties that can
establish mutual trust between a TEE and TSM. a TAM. The protocol
provides specifications for the following three entities:

1. Key and certificate types required for device firmware, TEE, TA,
SP, TEEs,
TAs, SPs, and TSM TAMs

2. Data message formats that should be exchanged between a TEE in a
device and a TSM TAM

3. An OTrP Agent application in the REE that can relay messages
between a Client Application and TEE

Figure 1: Protocol Scope and Entity Relationship

PKI CA --CA CA-- -- CA CA --
| | |
| | |
| | |
Device | | ----OTrP Agent --- Rich OTrP Agent / Client App --- |
SW | | | | |
| | | | |
| | | | |
OTrP | -- TEE TSM------- TAM-------
|
|
FW

Figure 2: OTrP System Diagram
---OTrP
-------OTrP Message Protocol-- Protocol---
| |
| |
-------------------- --------------- ----------
| REE | TEE | | TSM TAM | | SP |
| --- | --- | | --- | | -- |
| | | | | | |
| Client | SD (TAs)| | SD / TA | | TA |
| Apps | | | Mgmt | | |
| | | | | | | |
| | | | | | | |
| OTrP | Trusted | | Trusted | | |
| Agent | TAM/SP | | FW/TEE | | |
| | CAs | | FW, TEE CAs | | |
| | | | | | |
| |TEE Key/ | | TSM TAM Key/ | |SP Key/ |
| | Cert | | Cert | | Cert |
| | FW Key/ | | | | |
| | Cert | | | | |
------------------
-------------------- --------------- ----------
| | |
| | |
-----------------------------------------
------------- ---------- ---------
| TEE CA | | TAM CA |
-------------- | SP CA |
--------------
------------- ---------- ---------

In the previous diagram, different Certificate Authorities can be
used respectively for different types of certificates. OTrP Messages
are always signed, where the signer keys is the message creator's
private key
pair such as a FW key pair, TEE key pair FW's private key, a TEE's private key, or TSM key pair. a
TAM's private key.

The main OTrP Protocol component is the consists of a set of standard JSON messages
created by TSM a TAM to deliver device SD and TA management commands to a
device, and device attestation and response messages created by a TEE
that responds to respond to TSM a TAM's OTrP Messages. message.

The communication method of OTrP Messages between a TSM TAM and TEE in a
device may vary between TAM and TEE providers. A mandatory transport
protocol is left to TSM providers specified for maximal interoperability. A TSM
can work with its SP a compliant TAM and a device TEE.

It should be noted that network communication capability is generally
not available in today's TEE powered devices. The networking
functionality is handled by a rich Client Application with a remote
internet services; the Client Applications uses a local TEE interface
such as inter-process or a secure shared memory approach to interfact
with TA inside a TEE for message exchanges. Consequenly, a TAM
generally communicates with a Client Application about how it gets
OTrP Messages that originates from TEE inside a TSM. When device. Similarly, a Client Application has had an
TA or TEE generally gets OTrP
Message messages from its TSM, it a TAM via some Client
Application, not direct to the internet.

It is imperative to have an interoperable interface to communicate
with various TEE types. differnet TEEs in differnent devices that a Client Application
needs to run and access a TA inside a TEE. This is the role of an
OTrP
Agent interface that serves this purpose. 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

Step 1: Prepare Images for Devices

1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM

2. [CA] Deliver root CA Whitelist

3. [Soc] Deliver TFW Image

Step 2: Inject Key Pairs and Images to Devices

1. [OEM] Generate Secure Boot Key Pair (May be shared among multiple
devices)

2. [OEM] Flash signed TFW Image and signed TEE Image onto devices
(signed by Secure Boot Key)

Step 3: Setup attestation key pair pairs in devices

1. [OEM] Flash Secure Boot Public Key and eFuse Key (eFuse key is
unique per device)

2. [TFW/TEE] Generate a unique attestation key pair and get a
certificate for the device.

Step 4: Setup trust anchors in devices

1. [TFW/TEE] Store the key and certificate encrypted with the eFuse
key

2. [TEE vendor or OEM] Store trusted CA certificate list into
devices

5.2. Derived Keys in The Protocol

The protocol generates the following two one key pairs pair in run time to assist message
communication and anonymous verification between TSM a TAM and a TEE.

TEE SP Anonymous Key (TEE AIK): (AIK): one derived key pair per TEE SP in a device

The purpose of the key pair is to sign data by a TEE without using
its TEE device key for anonymous attestation to a Client Application.
This key pair is generated in the first GetDeviceState query. SD creation for an SP. It is
deleted when all SDs are removed for a SP in a device. The public
key of the key pair is returned given to the caller Client Application and TAM
for future TEE returned data validation.

2. TEE SP AIK: one derived key per SP in a device The purpose public key of this key pair AIK
is for also used by a TSM TAM to encrypt TA binary data and personalization
data when it sends a TA to a device for installation. This key is
generated in the first SD creation for a SP. It is deleted when all
SDs are removed for a SP in a device.

With the presence of a TEE SP AIK, it isn't necessary to have a
shared SP independent TEE AIK. For the initial release, this
specification will not use TEE AIK.

5.3. Security Domain Hierarchy and Ownership

The primary job of a TSM TAM is to help a an SP to manage its trusted
applications. A TA is typically installed in a an SD. A An SD is
commonly created for a an SP.

When a an SP delegates its SD and TA management to a TSM, a TAM, an SD is
created on behalf of a TSM TAM in a TEE and the owner of the SD is
assigned to the TSM. A TAM. An SD may be associated with a an SP but the TSM TAM
has full privilege to manage the SD for the SP.

Each SD for a an SP is associated with only one TSM. TAM. When a an SP
changes
TSM, TAM, a new SP SD must be created to associate with the new TSM.
TAM. The TEE will maintain a registry of TSM TAM ID and SP SD ID
mapping.

From a an SD ownership perspective perspective, the SD tree is flat and there is
only one level. A An SD is associated with its owner. It is up to TEE's TEE
implementation how it maintains SD binding information for TSM a TAM and
different SPs under the same TSM. TAM.

It is an important decision in this protocol specification that a TEE
doesn't need to know whether a TSM TAM is authorized to manage the SD for a
an SP. This authorization is implicitly triggered by a an SP Client
Application, which instructs what TSM TAM it wants to use. A An SD is
always associated with a TSM TAM in addition to its SP ID. A rogue TSM TAM
isn't able to do anything on an unauthorized SP's SD managed by
another TSM. TAM.

Since a TSM TAM may support multiple SPs, sharing the same SD name for
different SP SPs creates a dependency in deleting a an SD. A An SD can be
deleted only after all TAs associated with this SD is deleted. A An SP
cannot delete a Security Domain on its own with a TSM TAM if a TSM TAM
decides to introduce such sharing. There are cases where multiple
virtual SPs belong to the same organization, and a TSM TAM chooses to use
the same SD name for those SPs. This is totally up to the TSM TAM
implementation and out of scope of this specification.

5.4. SD Owner Identification and TSM TAM Certificate Requirements

There is a need of cryptographically binding proof about the owner of
a
an SD in a device. When a an SD is created on behalf of a TSM, TAM, a
future request from the TSM TAM must present itself as a way that the TEE
can verify it is the true owner. The certificate itself cannot
reliably used as the owner because TSM TAM may change its certificate.

To this end, each TSM TAM will be associated with a trusted identifier
defined as an attribute in the TSM TAM certificate. This field is kept
the same when the TSM TAM renew its certificates. A TSM TAM CA is
responsible to vet the requested TSM TAM attribute value.

This identifier value must not collide among different TSM TAM providers,
and one TSM TAM shouldn't be able to claim the identifier used by another
TSM
TAM provider.

The certificate extension name to carry the identifier can initially
use SubjectAltName:registeredID. A dedicated new extension name may
be registered later.

One common choice of the identifier value is the TSM's TAM's service URL.
A CA can verify the domain ownership of the URL with the TSM TAM in the
certificate enrollment process.

A TEE can assign this certificate attribute value as the TSM TAM owner ID
for the SDs that are created for the TSM. TAM.

An alternative way to represent a an SD ownership by a TSM TAM is to have a
unique secret key upon SD creation such that only the creator TSM TAM is
able to produce a Proof-of-Possession (POP) data with the secret.

5.5. Service Provider Container

A sample Security Domain hierarchy for the TEE is shown below.

----------
| TEE |
----------
|
| ---------------
|----------| SP1 Root SD |
| ---------------
| |
| | --------------
| ----------
|----------| SP1 Sub SD |
| SD1 | --------------
| ----------
| --------------
| ----------
|----------| SP1 Sub SD SD2 |
| -------------- ----------
| --------------- ----------
|----------| SP2 Root SD SD1 |
---------------

The
----------

OTrP assumes segregates SDs and TAs such that a SP managed by TSM1 cannot be managed by TSM2.
Explicit permission grant should happen. SP TAM can authorize TSM. only manage or
retrieve data for SDs and TAs that it previously created for the SPs
it represents.

6. OTrP Agent

A TEE and TAs that run inside the TEE don't generally have capability
to communicate to the outside of the hosting device, for example, the
TEE specified by Global Platform groups [GPTEE]. This calls for a
software module in the REE world to handle the network communication.
Each Client Application in REE may carry this communication
functionality but it must also interact with the TEE for the message
exchange. The TEE interaction will vary according to different TEEs.
In order for a Client Application to transparently support different
TEEs, it is imperative to have a common interface for a Client
Application to invoke for exchanging messages with TEEs.

A shared OTrP Agent comes to meed this need. An OTrP Agent is an a Rich
Application or SDK that facilitates communication between a TSM TAM and
TEE. It also provides interfaces for
TSM TAM SDK or Client Applications
to query and trigger TA installation that the application needs to
use.

This interface for Client Applications may be commonly an Android
service call. call for an Android powered device. A Client Application
interacts with a TSM, TAM, and turns around to pass messages received from TSM
TAM to OTrP Agent.

In all cases, a Client Application needs to be able to identify an
OTrP Agent that it can use.

6.1. Role of OTrP Agent

An OTrP Agent is responsible to communicate abstracts the message exchanges with TEE. It takes request
messages from an application. the TEE in a
device. The input data is mostly originated from a TSM TAM that an application communicates. An application a Client
Application connects. A Client Application may also directly call
OTrP Agent for some TA query functions.

OTrP Agent may internally process a request from TSM. TAM. At least, it
needs to know where to route a message, e.g. TEE instance. It
doesn't need to process or verify message content.

OTrP Agent returns TEE / TFW generated response messages to the
caller. OTrP Agent isn't expected to handle any network connection
with an application or TSM. TAM.

OTrP Agent only needs to return an OTrP Agent error message if the
TEE is not reachable for some reason. Other errors are represented
as response messages returned from the TEE which will then be passed
to the TSM. TAM.

6.2. OTrP Agent and Global Platform TEE Client API

A Client Application may rely on use Global Platform (GP) TEE API for TA
communication. OTrP may use the GP TEE Client API but it is internal
to OTrP implementation that converts given messages from TSM. TAM. More
details can be found at [GPTEE]. [GPTEECLAPI].

6.3. OTrP Agent Implementation Consideration

A Provider should consider methods of distribution, scope and
concurrency on device and runtime options when implementing an OTrP
Agent. Several non-exhaustive options are discussed below.
Providers are encouraged to take advantage of the latest
communication and platform capabilities to offer the best user
experience.

6.3.1. OTrP Agent Distribution

OTrP Agent installation is commonly carried out at OEM time. A user
can dynamically download and install an OTrP Agent on-demand.

It is important to ensure a legitimate OTrP Agent is installed and
used. If an OTrP Agent is compromised it may send rogue messages to
TSM
TAM and TEE and introduce additional risks.

6.3.2. Number of OTrP Agent

We anticipate only one shared OTrP Agent instance in a device. The
device's TEE vendor will most probably supply one OTrP Agent.
Potentially we expect some open source.

With one shared OTrP Agent, the OTrP Agent provider is responsible to
allow multiple TSMs TAMs and TEE providers to achieve interoperability.
With a standard OTrP Agent interface, TSM TAM can implement its own SDK
for its SP Client Applications to work with this OTrP Agent.

Multiple independent OTrP Agent providers can be used as long as they
have standard interface to a Client Application or TSM TAM SDK. Only one
OTrP Agent is expected in a device.

OTrP Protocol MUST specify a standard way for applications to lookup
the active OTrP Agent instance in a device.

TSM

TAM providers are generally expected to provide SDK for SP
applications to interact with an OTrP Agent for the TSM TAM and TEE
interaction.

6.3.3. OTrP Android Service Option

OTrP Agent can be a bound service in Android with a service
registration ID that a Client Application can use. This option
allows a Client Application not to depend on any OTrP Agent SDK or
provider.

An OTrP Agent is responsible to detect and work with more than one
TEE if a device has more than one. In this version, there is only
one active TEE such that an OTrP Agent only needs to handle the
active TEE.

6.4. OTrP Agent API Interfaces for Client Applications

A Client Application shall be responsible for relaying messages
between the OTrP agent and the TSM.

OTrP Agent APIs are defined below. An OTrP Agent in the form of an
Android bound service can take this to be the functionality it
provides via service call. The OTrP Agent implements this interface. TAM.

If a failure is occured during calling API, OTrP Agent, an error message
described in "Common Errors" section (see Section 7.6) will be
returned.

interface IOTrPAgentService {
String processMessage(String tsmInMsg) throws OTrPAgentException;
String getTAInformation(String spid, String taid)
throws OTrPAgentException;
}

public class OTrPAgentException extends Throwable {
private int errCode;
}

6.4.1. API processMessage

String processMessage(String tsmInMsg) throws OTrPAgentException; ProcessOTrPMessage call

Description

A Client Application will use this method of the OTrP Agent in a
device to pass OTrP messages from a TSM. TAM. The method is
responsible for interation interacting with the TEE and for forwarding the
input message to the TEE. It also returns TEE generated response
message back to the Client Application.

Input

tsmInMsg

Inputs:

TAMInMsg - OTrP message generated in a TSM TAM that is passed to this
method from a Client Application.

Output

Outputs:

A TEE generated TEE-generated OTrP response message (which may be a successful
response or be a response message containing an error raised
within the TEE) for the client application to forward to the TSM. TAM.

In the event of the OTrP agent not being able to communicate with
the TEE, a OTrPAgentException shall be thrown.

6.4.2. API getTAInformation

String getTAInformation(String spid, String taid)
throws OTrPAgentException; GetTAInformation call

Description

A Client Application calls this method to may quickly query local TEE about a TA's
information. This method is carried out locally by the OTrP Agent
previously installed TA without relying on a TSM requiring TAM each time if it has
had the TA's identifier and previously saved TEE SP AIK.

Input

spid - SP AIK public key
for TA information integrity verification.

Inputs:

{
"TAQuery": {
"spid": "<SP identifier value of the TA

taid - the TA>",
"taid": "<The identifier value of the TA

Output TA>"
}
}

Outputs:

The API returns OTrP Agent is expected to return TA signer and TSM TAM signer
certificate along with other metadata information about the TA
associated with the given identifier. It follows the underlying
TEE trust model for authoring the local TA query from a TA. Client
Application.

The output is a JSON message that is generated by the TEE. It
contains the following information:

* TSMID tamid

* SP ID

* TA signer certificate

* TSM TAM certificate

The message is signed with TEE SP AIK private key.

The Client Application is expected to consume the response as
follows.

The Client Application gets signed TA metadata, in particularly, particular, the
TA signer certificate. It is able to verify that the result is
from device by checking signer against TEE SP AIK public key it
gets in some earlier interaction with TSM. TAM.

If this is a new Client Application in the device that hasn't had
TEE SP AIK public key for the response verification, the
application can contact TSM the TAM first to do GetDeviceState, and TSM
TAM will return TEE SP AIK public key to the app for this
operation to proceed.

JSON Message

Output Message:

{
"TAInformationTBS": {
"taid": "<TA Identifier from the input>",
"tsmid": "<TSM
"tamid": "<TAM ID for the Security Domain where this TA
resides>",
"spid": "<The service provider identifier of this TA>",
"signercert": "<The BASE64 encoded certificate data of the
TA binary application's signer certificate>",
"signercacerts": [ // the full list of CA certificate chain
// including the root CA
],
"cacert": "<The BASE64 encoded CA certificate data of the TA
binary application's signer certificate>"
],
"tsmcert":
"tamcert": "<The BASE64 encoded certificate data of the TSM TAM
that manages this TA.>",
"tsmcacerts":
"tamcacerts": [ // the full list of CA certificate chain
// including the root CA
],
"cacert":"<The BASE64 encoded CA certificate data of the TSM TAM
that manages this TA>"
]
}
}

{
"TAInformation": {
"payload": "<BASE64URL "<The BASE64URL encoding of the TAInformationTBS
JSON above>",
"protected": "<BASE64URL encoded signing algorithm>",
"header": {
"signer": {"<JWK definition of the TEE SP AIK public
key>"}
},
"signature": "<signature contents signed by TEE SP AIK
private key BASE64URL encoded>"
}
}

where the definitions of BASE64 and BASE64URL refer to [RFC4648].

A sample JWK public key representation refers to an example in RFC
7517 [RFC7517] .
[RFC7517].

6.5. Sample End-to-End Client Application Flow

6.5.1. Case 1: A New Client Application Uses a TA

1. During the Client Application installation time, the Client
Application calls TSM TAM to initialize the device preparation step.

A. The Client Application knows it wants to use a Trusted
Application TA1 but the application doesn'tknow whether TA1
has been installed or not. It can use GP TEE Client API
[GPTEECLAPI] to check the existence of TA1 first. If it
detects that TA1 doesn't exist, it will contact TSM TAM to
initiate the installation of TA1. Note that TA1 could have
been previously installed by other Client Applications from
the same service provider in the device.

B. The Client Application sends TSM the TAM the TA list that it
depends on. The TSM TAM will query a device for the Security
Domains and TAs that have been installed, and instructs the
device to install any dependent TAs that have not been
installed.

C. In general, TSM the TAM has the latest information of TA list and their status
in a device because all operations are instructed by TSM. TSM TAM.
TAM has such visibility because all Security Domain deletion
and TA deletion are managed by TSM; the TSM TAM; the TAM could have
stored the state when a TA is installed, updated and
deleted. There is also the possibility that an update
command is carried out inside TEE but a response is never
received in TSM. TAM. There is also possibility that some manual
local reset is done in a device that the TSM TAM isn't aware of
the changes.

2. TSM The TAM generates message: GetDeviceStateRequest

3. The Client Application passes the JSON message
GetDeviceStateRequest to OTrP Agent API processMessage. call ProcessOTrPMessage.
The communication between a Client Application and an OTrP Agent
is up to the implementation of the OTrP Agent.

4. The OTrP Agent routes the message to the active TEE. Multiple
TEE case: it is up to OTrP Agent to figure this out. This
specification limits the support to only one active TEE, which
is the typical case today.

5. The target active TEE processes the received OTrP message, and
returns a JSON message GetDeviceStateResponse GetDeviceStateResponse.

6. The OTrP Agent passes the GetDeviceStateResponse to the Client
App
Application.

7. The Client Application sends GetDeviceStateResponse to TSM the TAM.

8. TSM The TAM processes GetDeviceStateResponse the GetDeviceStateResponse.

A. Extract TEEspaik for the SP, signs TEEspaik with TSM TAM signer
key

B. Examine SD list and TA list

9. TSM The TAM continues to carry out other actions basing based on the need.
The next call could be instructing the device to install a
dependent TA.

A. Assume a dependent TA isn't in the device yet, the TSM TAM may
do the following:

Create a (1) create an SD in which to install the
TA by sending a message
CreateSDRequest. CreateSDRequest message. The message is
sent back to the Client Application, and then the OTrP Agent
and TEE to process.

Install process; (2) install a TA with a message InstallTARequest.

C. an
InstallTARequest message.

B. If a Client Application depends on multiple TAs, the Client
Application should expect multiple round trips of the TA
installation message exchanges.

10. At the last TSM TAM and TEE operation, TSM the TAM returns the signed
TEE SP AIK public key to the application application.

11. The Client Application shall store stores the TEEspaik for future loaded TA
trust check purpose. check.

12. If the TSM TAM finds that this is a fresh device that does not have
any SD for the SP yet, then the TSM TAM may move on to next create a an SD for
the SP next. SP.

13. During Client Application installation, the application checks
whether required Trusted Applications are already installed,
which may have been provided by the TEE. If needed, it will
contact its TSM TAM service to determine whether the device is ready
or install TA list that this application needs.

6.5.2. Case 2: A Previously Installed Client Application Calls a TA

1. The Client Application checks the device readiness: (a) whether
it has a TEE; (b) whether it has TA that it depends. It may
happen that TSM TAM has removed the TA this application depends on.

2. The Client Application calls the OTrP Agent method "GetTAInformation" to query the TA.

3. The OTrP Agent queries the TEE to get TA information. If the
given TA doesn't exist, an error is returned.

4. The Client Application parses the TAInformation message.

5. If the TA doesn't exist, the Client Application calls its TSM TAM to
install the TA. If the TA exists, the Client Application
proceeds to call the TA.

7. OTrP Messages

The main OTrP Protocol component is the set of standard JSON messages created
by TSM a TAM to deliver device SD and TA management commands to a device,
and device attestation and response messages created by TEE to
respond to TSM TAM OTrP Messages.

An OTrP Message is designed to provide end-to-end security. It is
always signed by its creator. In addition, an OTrP Message is
typically encrypted such that only the targeted device TEE or TSM
provider TAM is
able to decrypt and view the actual content.

7.1. Message Format

OTrP Messages use the JSON format for JSON's simple readability and
moderate data size in comparison with alternative TLV and XML
formats. More compact CBOR format may be used as an alternative
choice.

JSON Message security has developed JSON Web Signing and JSON Web
Encryption standard in the IETF Workgroup JOSE, see JWS [RFC7515] and
JWE [RFC7516]. The OTrP Messages in this protocol will leverage the
basic JWS and JWE to handle JSON signing and encryption.

7.2. Message Naming Convention

For each TSM TAM command "xyz"", OTrP Protocol use the following naming convention
to represent its raw message content and complete request and
response messages:

7.3. Request and Response Message Template

An OTrP Request message uses the following format:

{
"<name>TBSRequest": {
<request message content>
}
}

A corresponding OTrP Response message will be as follows.

{
"<name>TBSResponse": {
<response message content>
}
}

7.4. Signed Request and Response Message Structure

A signed request message will generally include only one signature,
and uses the flattened JWS JSON Serialization Syntax, see
Section 7.2.2 in RFC7515 [RFC7515] . [RFC7515].

A general JWS object looks like the following.

{
"payload": "<payload contents>",
"protected":"<integrity-protected
"protected": "<integrity-protected header contents>",
"header": {
<non-integrity-protected header contents>,
},
"signature":"<signature
"signature": "<signature contents>"
}
OTrP signed messages only requires require the signing algorithm as the
mandate header in the property "protected". The "non-integrity-
protected header contents" is optional.

OTrP signed message will be given an explicit Request or Response
property name. In other words, a signed Request or Response uses the
following template.

A general JWS object looks like the following.

{
"<name>[Request | Response]": {
<JWS Message of <name>TBS[Request | Response]
}
}

With the standard JWS message format, a signed OTrP Message looks
like the following.

{
"<name>[Request | Response]": {
"payload": "<payload contents of <name>TBS[Request | Response]>",
"protected":"<integrity-protected
"protected": "<integrity-protected header contents>",
"header": <non-integrity-protected header contents>,
"signature":"<signature
"signature": "<signature contents>"
}
}

The top element " <name>[Signed][Request | Response]" cannot be fully
trusted to match the content because it doesn't participate in the
signature generation. However, a recipient can always match it with
the value associated with the property "payload". It purely serves
to provide a quick reference for reading and method invocation.

Furthermore, most properties in an unsigned OTrP messages are
encrypted to provide end-to-end confidentiality. The only OTrP
message that isn't encrypted is the initial device query message that
asks for the device state information.

Thus a typical OTrP Message consists of an encrypted and then signed
JSON message. Some transaction data such as transaction ID and TEE
information may need to be exposed to the OTrP Agent for routing
purpose. Such information is excluded from JSON encryption. The
device's signer certificate itself is encrypted. The overall final
message is a standard signed JSON message.

As required by JSW/JWE, those JWE and JWS related elements will be
BASE64URL encoded. Other binary data elements specific to the OTrP
specification are BASE64 encoded. BASE64-encoded. This specification will identify indicates
elements that should be BASE64 and those elements that are to be
BASE64URL encoded.

7.4.1. Identifying Signing and Encryption Keys for JWS/JWE Messaging

JWS and JWE messaging allow various options for identifying the
signing and encryption keys, for example, it allows optional elements
including "x5c", "x5t" and "kid" in the header to cover various
possibilities.

In order to

To protect privacy, it is important that the device's certificate is
released only to a trusted TSM, TAM, and that it is encrypted. The TSM TAM
will need to know the device certificate, but untrusted parties must
not be able to get the device certificate. All OTrP messaging
conversations between a TSM TAM and device begin with
GetDeviceStateRequest / GetDeviceStateResponse. These messages have
elements built into them to exchange signing certificates, described
in the "Detailed Message Specification" section. section Section 9. Any subsequent messages in the
conversation that follow on from this are implicitly
using use the same
certificates for signing/encryption, and as a result the certificates
or references may be ommitted in those subsequent messages.

In other words, the signing key identifier in the use of JWS and JWE
here may be absent in the subsequent messages after the initial
GetDeviceState query.

This has an implication on the TEE and TSM TAM implementation: they have
to cache the signer certificates for the subsequent message signature
validation in the session. It may be easier for a TSM TAM service to
cache transaction session information but not so for a TEE in a
device. A TSM should check TAM can get a device's capability by checking the response
message from a TEE to decide whether it should include its TSM TAM signer
certificate and OCSP data in each subsequent request message. The
device's caching capability is reported in GetDeviceStateResponse
signerreq parameter.

7.5. JSON Signing and Encryption Algorithms

The OTrP JSON signing algorithm shall use SHA256 or a stronger hash
method with respective key type. JSON Web Algorithm RS256 or ES256
[RFC7518] SHALL be used for RSA with SHA256 and ECDSA with SHA256.
If RSA with SHA256 is used, the JSON web algorithm representation is
as follows.

{"alg":"RS256"}

The (BASE64URL encoded) "protected" header property in a signed
message looks like the following:

"protected":"eyJhbGciOiJSUzI1NiJ9"

If ECSDA with P-256 curve and SHA256 are used for signing, the JSON
signing algorithm representation is as follows.

{"alg":"ES256"}

The value for the "protected" field will be the following.

eyJhbGciOiJFUzI1NiJ9

Thus

Thus, a common OTrP signed message with ES256 looks like the
following.

{
"payload": "<payload contents>",
"protected": "eyJhbGciOiJFUzI1NiJ9",
"signature":"<signature
"signature": "<signature contents>"
}

The OTrP JSON message encryption algorithm should SHOULD use one of the
supported algorithms defined in the later chapter of this document.
JSON encryption uses a symmetric key as its "Content Encryption Key
(CEK)". This CEK is encrypted or wrapped by a recipient's key. The
OTrP recipient typically has an asymmetric key pair. Therefore Therefore, the
CEK will be encrypted by the recipient's public key.

Symmetric encryption

A compliant implementation shall use support the following algorithm. symmetric
encryption algorithm and anticipate future new algorithms.

{"enc":"A128CBC-HS256"}

This algorithm represents encryption with AES 128 in CBC mode with
HMAC SHA 256 for integrity. The value of the property "protected" in
a JWE message will be

eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0

An encrypted JSON message looks like the following.

{
"protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"recipients": [
{
"header": {
"alg": "<RSA1_5 etc.>"
},
"encrypted_key": "<encrypted value of CEK>"
}
],
"iv": "<BASE64URL encoded IV data>",
"ciphertext": "<Encrypted data over the JSON plaintext
(BASE64URL)>",
"tag": "<JWE authentication tag (BASE64URL)>"
}

OTrP doesn't use JWE AAD (Additional Authenticated Data) because each
message is always signed after the message is encrypted.

7.5.1. Supported JSON Signing Algorithms

The following JSON signature algorithm are is mandatory support in the
TEE and TSM: TAM:

o RS256

ES256 is optional to support.

7.5.2. Support JSON Encryption Algorithms

The following JSON authenticated encryption algorithm is mandatory
support in TEE and TSM. TAM.

o A128CBC-HS256

A256CBC-HS512 is optional to support.

7.5.3. Supported JSON Key Management Algorithms

The following JSON key management algorithm is mandatory support in
TEE and TSM. TAM.

o RSA1_5

ECDH-ES+A128KW and ECDH-ES+A256KW are optional to support.

7.6. Common Errors

An OTrP Response message typically needs to report the operation
status and error causes if an operation fails. The following JSON
message elements should be used across all OTrP Messages.

"status": "pass | fail"

"reason": {
"error-code": "<error code if there is any>",
"error-message": "<error message>"
}

"ver": "<version string>"

7.7. OTrP Message List

The following table lists the OTrP commands and therefore
corresponding Request and Response messages defined in this
specification. Additional messages may be added in the future when
new task messages are needed.

GetDeviceState -
A TSM TAM queries a device's current state with a message
GetDeviceStateRequest. A device TEE will report its version, its
FW version, and list of all SD SDs and TA TAs in the device that is
managed by the requesting TSM. TSM TAM. TAM may determine whether the
device is trustworthy and decide to carry out additional commands
according to the response from this query.

CreateSD -
A TSM TAM instructs a device TEE to create a an SD for a an SP. The
recipient TEE will check whether the requesting TSM TAM is
trustworthy.

UpdateSD -
A TSM TAM instructs a device TEE to update an existing SD. A typical
update need comes from SP certificate change, TSM TAM certificate
change and so on. The recipient TEE will verify whether the TSM TAM
is trustworthy and owns the SD.

DeleteSD -
A TSM TAM instructs a device TEE to delete an existing SD. A TEE
conditionally deletes TAs loaded in the SD according to a request
parameter. A An SD cannot be deleted until all TAs in this SD are
deleted. If this is the last SD for a an SP, TEE can MAY also delete
TEE SP AIK key for this SP.

InstallTA -
A TSM TAM instructs a device to install a TA into a an SD for a SP.
The TEE in a device will check whether the TSM TAM and TA are
trustworthy.

UpdateTA -
A TSM TAM instructs a device to update a TA into a an SD for a an SP.
The change may commonly be bug fix for a previously installed TA.

DeleteTA -
A TSM TAM instructs a device to delete a TA. The TEE in a device
will check whether the TSM TAM and TA are trustworthy.

7.8. OTrP Request Message Routing Rules

For each command that a TSM TAM wants to send to a device, the TSM TAM
generates a request message. This is typically triggered by a Client
Application that uses the TSM. TAM. The Client Application initiates
contact with the TSM TAM and receives TSM TAM OTrP Request messages according
to the TSM's TAM's implementation. The Client Application forwards the
OTrP message to an OTrP Agent in the device, which in turn sends the
message to the active TEE in the device.

The current version of this specification assumes that each device
has only one active TEE, and the OTrP Agent is responsible to connect
to the active TEE. This is the case today with devices in the
market.

Upon

When the TEE responding with responds to a request, the OTrP Agent gets the OTrP
response messages back to the Client Application that sends sent 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
the Client Application. The Client Application forwards any data it
received to its TSM. TAM.

7.8.1. SP Anonymous Attestation Key (SP AIK)

When the first new Security Domain is created in a TEE for a an SP, a
new key pair is generated and associated with this SP. This key pair
is used for future device attestation to the service provider instead
of using the device's TEE key pair.

8. Transport Protocol Support

The OTrP message exchange between a TEE device and TAM generally
takes place between a Client Application in REE and TAM. A device
that is capable to run a TEE and PKI based cryptographic attestation
isn't generally resource constraint to carry out standard HTTPS
connections. A compliant device and TAM SHOULD support HTTPs.

9. Detailed Messages Specification

For each message in the following sections all JSON elements are
mandatory if it isn't not explicitly indicated as optional.

8.1.

9.1. GetDeviceState

This is the first command that a TSM TAM will query send to a device. This
command is triggered when a an SP's Client Application contacts its TSM TAM
to check whether the underlying device is ready for TA operations.

This command queries a device's current TEE state. A device TEE will
report its version, its FW version, and list of all SD SDs and TA TAs in
the device that is managed by the requesting TSM. TSM TAM. TAM may determine
whether the device is trustworthy and decide to carry out additional
commands according to the response from this query.

The request message of this command is signed by TSM. the TAM. The
response message from the TEE is encrypted. A random message
encryption key (MK) is generated by TEE, and this encrypted key is
encrypted by the
receiving TSM TAM's public key such that only the TSM who TAM that sent
the request is able to decrypt and view the response message.

8.1.1.

9.1.1. GetDeviceStateRequest message

{
"GetDeviceStateTBSRequest": {
"ver": "1.0",
"rid": "<Unique request ID>",
"tid": "<transaction ID>",
"ocspdat": "<OCSP stapling data [<a list of TSM certificate>",
"icaocspdat": "<OCSP OCSP stapling data for TSM CA certificates>", data>"],
"supportedsigalgs": "<comma separated [<array of supported signing algorithms>" algorithms>]
}
}

The request message consists of the following data elements:

ver - version of the message format

rid - a unique request ID generated by the TSM TAM

tid - a unique transaction ID to trace request and response. This
can be from a prior transaction's tid field, and can be used in
the
subsequent message exchanges in this TSM TAM session. The
combination of rid and tid should MUST be made unique.

ocspdat - A list of OCSP stapling data respectively for the TSM TAM
certificate and each of the CA certificates up to the root
certificate. The TSM TAM provides OCSP data such that a recipient
TEE can validate the
validity of the TSM TAM certificate chain revocaton status
without making its own external OCSP service call. This is a mandate field.

icaocspdat - OCSP stapling data for the intermediate CA
certificates of the TSM certificate up to the root. A TEE side
can MAY
cache the CA OCSP data such that this value isn't needed the array may contain only the
OCSP stapling data for the TAM certificate in each
call. subsequent
exchanges. This is a mandatory field.

supportedsigalgs - an optional property to list the signing
algorithms that TSM the TAM is able to support. A recipient TEE should MUST
choose an algorithm in this list to sign its response message if
this property is present in a request. If it is absent, the TEE
may use any compliant signing algorithm that is listed as
mandatory support in this specification.

The final request message is JSON signed message of the above raw
JSON data with TSM's TAM's certificate.

{
"GetDeviceStateRequest": {
"payload":"<BASE64URL
"payload": "<BASE64URL encoding of the GetDeviceStateTBSRequest
JSON above>",
"protected": "<BASE64URL encoded signing algorithm>",
"header": {
"x5c": "<BASE64 encoded TSM TAM certificate chain up to the
root CA certificate>"
},
"signature":"<signature contents signed by TSM TAM private key>"
}
}

The signing algorithm should SHOULD use SHA256 with respective key type.
The mandatory algorithm support is the RSA signing algorithm. The
signer header "x5c" is used to include the TSM TAM signer certificate up
to the root CA certificate.

8.1.2.

9.1.2. Request processing requirements at a TEE

Upon receiving a request message GetDeviceStateRequest at a TEE, the
TEE must MUST validate a request:

1. Validate JSON message signing signing. If it doesn't pass, an error
message is returned.

2. Validate that the request TSM TAM certificate is chained to a trusted
CA that the TEE embeds as its trust anchor.

* Cache the CA OCSP stapling data and certificate revocation
check status for other subsequent requests.

* A TEE can use its own clock time for the OCSP stapling data
validation.

3. Collect Firmware signed data

* This is a capability in ARM architecture that allows a TEE to
query Firmware to get FW signed data.

4. Collect SD information for the SD owned by this TSM

8.1.3. TAM

9.1.3. Firmware Signed Data

Firmware isn't expected to process or produce JSON data. It is
expected to just sign some raw bytes of 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
GetDeviceStateTBSRequest shall be signed by the firmware. TSM TAM isn't
expected to parse TFW data except the signature validation and signer
trust path validation.

It is possible that a TEE can get some valid TFW signed data from
another device. This is part of the TEE trust assumption where TSM
will trust the TFW data supplied by the TEE. The TFW trust is more
concerned by TEE than a TSM where a TEE needs is responsible to validate TFW integrity to
ensure that the underlying device firmware is trustworthy. A TAM
trusts the TEE and the TFW trust status check carried out by the TEE.

TfwData: {
"tbs": "<TFW to be signed data, BASE64 encoded>",
"cert": "<BASE64 encoded TFW certificate>",
"sigalg": "Signing method",
"sig": "<Tfw "<TFW signed data, BASE64 encoded>"
}

It is expected that FW use a FW uses standard signature methods for maximal
interoperability with TSM TAM providers. The mandatory support list of
signing algorithm is RSA with SHA256.

The JSON object above is constructed by a TEE with data returned from
the FW. It isn't a standard JSON signed object. The signer
information and data to be signed must be specially processed by TSM a
TAM according to the definition given here. The data to be signed is
the raw data.

8.1.3.1.

9.1.3.1. Supported Firmware Signature Methods

TSM

TAM providers shall support the following signature methods. A
firmware provider can choose one of the methods in signature
generation.

o RSA with SHA256

o ECDSA with SHA 256

The value of "sigalg" in the TfwData JSON message should SHOULD use one of
the following:

o RS256

o ES256

8.1.4.

9.1.4. Post Conditions

Upon successful request validation, the TEE information is collected.
There is no change in the TEE in the device.

The response message shall be encrypted where the encryption key
shall be a symmetric key that is wrapped by TSM's TAM's public key. The
JSON Content Encryption Key (CEK) is used for this purpose.

8.1.5.

9.1.5. GetDeviceStateResponse Message

The message has the following structure.

{
"GetDeviceTEEStateTBSResponse": {
"ver": "1.0",
"status": "pass | fail",
"rid": "<the request ID from the request message>",
"tid": "<the transaction ID from the request message>",
"signerreq": "true true | false // about whether TSM TAM needs to send
signer data again in subsequent messages", messages,
"edsi": "<Encrypted JSON dsi DSI information>"
}
}

where

signerreq - true if the TSM TAM should send its signer certificate and
OCSP data again in the subsequent messages. The value may be
"false" if the TEE caches the TSM's TAM's signer certificate and OCSP
status.

rid - the request ID from the request message

tid - the tid from the request message

edsi - the main data element whose value is JSON encrypted message
over the following Device State Information (DSI).

The Device State Information (DSI) message consists of the following.

{
"dsi": {
"tfwdata": {
"tbs": "<TFW to be signed data is the tid>"
"cert": "<BASE64 encoded TFW certificate>",
"sigalg": "Signing method",
"sig": "<Tfw "<TFW signed data, BASE64 encoded>"
},
"tee": {
"name": "<TEE name>",
"ver": "<TEE version>",
"cert": "<BASE64 encoded TEE cert>",
"cacert": "<JSON array value of CA certificates up to
the root CA>",
"sdlist": {
"cnt": "<Number of SD owned by this TSM>", TAM>",
"sd": [
{
"name": "<SD name>",
"spid": "<SP owner ID of this SD>",
"talist": [
{
"taid": "<TA application identifier>",
"taname": "<TA application friendly
name>" // optional
}
]
}
]
},
"teeaiklist": [
{
"spaik": "<SP AIK public key, BASE64 encoded>",
"spaiktype": "<RSA | ECC>",
"spid": "<sp id>"
}
]
}
}
}

The encrypted JSON message looks like the following.

{
"protected": "<BASE64URL encoding of encryption algorithm header
JSON data>",
"recipients": [
{
"header": {
"alg": "RSA1_5"
},
"encrypted_key": "<encrypted value of CEK>"
}
],
"iv": "<BASE64URL encoded IV data>",
"ciphertext": "<Encrypted data over the JSON object of dsi
(BASE64URL)>",
"tag": "<JWE authentication tag (BASE64URL)>"
}

Assume we encrypt plaintext with AES 128 in CBC mode with HMAC SHA
256 for integrity, the encryption algorithm header is:

{"enc":"A128CBC-HS256"}

The value of the property "protected" in the above JWE message will
be

eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0

In other words, the above message looks like the following:

{
"protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"recipients": [
{
"header": {
"alg": "RSA1_5"
},
"encrypted_key": "<encrypted value of CEK>"
}
],
"iv": "<BASE64URL encoded IV data>",
"ciphertext": "<Encrypted data over the JSON object of dsi
(BASE64URL)>",
"tag": "<JWE authentication tag (BASE64URL)>"
}

The full response message looks like the following:

{
"GetDeviceTEEStateTBSResponse": {
"ver": "1.0",
"status": "pass | fail",
"rid": "<the request ID from the request message>",
"tid": "<the transaction ID from the request message>",
"signerreq": "true | false",
"edsi": {
"protected": "<BASE64URL encoding of encryption algorithm
header JSON data>",
"recipients": [
{
"header": {
"alg": "RSA1_5"
},
"encrypted_key": "<encrypted value of CEK>"
}
],
"iv": "<BASE64URL encoded IV data>",
"ciphertext": "<Encrypted data over the JSON object of dsi
(BASE64URL)>",
"tag": "<JWE authentication tag (BASE64URL)>"
}
}
}

The CEK will be encrypted by the TSM TAM public key in the device. The
TEE signed message has the following structure.

{
"GetDeviceTEEStateResponse": {
"payload": "<BASE64URL encoding of the JSON message
GetDeviceTEEStateTBSResponse>",
"protected": "<BASE64URL encoding of signing algorithm>",
"signature": "<BASE64URL encoding of the signature value>"
}
}

The signing algorithm shall use SHA256 with respective key type, see
Section Section 7.5.1.

The final GetDeviceStateResponse response message GetDeviceStateResponse consists of an
array of TEE response. A typical device will have only one active TEE. An
OTrP Agent is responsible to collect TEE response for all active TEEs
in the future. responses.

{
"GetDeviceStateResponse": [ // JSON array
{"GetDeviceTEEStateResponse": ...},
...
{"GetDeviceTEEStateResponse": ...}
]
}

8.1.6.

9.1.6. Error Conditions

An error may occur if a request isn't valid or the TEE runs into some
error. The list of possible error conditions is the following.

ERR_REQUEST_INVALID The TEE meets the following conditions with a
request message: (1) The request from a TSM TAM has an invalid message
structure; mandatory information is absent in the message. message; or an
undefined member or structure is included. (2) TEE fails to verify
the signature of the message or fails to decrypt its contents. (3) etc.

ERR_UNSUPPORTED_MSG_VERSION The TEE receives the a version of message
that the TEE can't deal with.

ERR_UNSUPPORTED_CRYPTO_ALG The TEE receives a request message
encoded with a cryptographic algorithms algorithm that the TEE doesn't
support.

ERR_TFW_NOT_TRUSTED The TEE may consider considers the underlying device firmware
be not trustworthy.

ERR_TSM_NOT_TRUSTED

ERR_TAM_NOT_TRUSTED The TEE needs to make sure whether the TSM TAM is
trustworthy by checking the validity of TSM the TAM certificate and
OCSP stapling data and so on. If the TEE finds TSM the TAM is not
reliable, it may
return returns this error code.

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
will return this error code.

ERR_AGENT_TEE_FAIL The TEE failed to respond to a TSM TAM request. The
OTrP Agent will construct an error message in responding to the TSM's
TAM's request.
And also if TEE fails to process a request because of its internal
error, it will return this The error code. message will not be signed.

The response message will look like the following if the TEE signing
can work to sign the error response message.

{
"GetDeviceTEEStateTBSResponse": {
"ver": "1.0",
"status": "fail",
"rid": "<the request ID from the request message>",
"tid": "<the transaction ID from the request message>",
"reason": {"error-code":"<error code>"}
"supportedsigalgs": "<signature [<an array of signature algorithms that
the TEE supports>" supports>]
}
}

where

supportedsigalgs - an optional property to list the JWS signing
algorithms that the active TEE supports. When a TSM TAM sends a
signed message that the TEE isn't able to validate, it can
include signature algorithms that it is able to consume in this
status report. A TSM TAM can generate a new request message to retry
the management task with a TEE supported TEE-supported signing algorithm.

If the TEE isn't able to sign an error message, message due to an internal
device error, a general error message should be returned.

8.1.7. TSM returned by the OTrP
Agent.

9.1.7. TAM Processing Requirements

Upon receiving a message of the type GetDeviceStateResponse message at a TSM, TAM, the TSM should TAM
MUST validate the following.

o Parse to get list of GetDeviceTEEStateResponse JSON object objects

o Parse the JSON "payload" property and decrypt the JSON element
"edsi"

o
"edsi". The decrypted message contains the TEE signer certificate
certificate.

o Validate the GetDeviceTEEStateResponse JSON signature. The signer
certificate is extracted from the decrypted message in the last
step.

o Extract TEE information and check it against its TEE acceptance
policy.

o Extract the TFW signed element, and check the signer and data
integration against its TFW policy policy.

o Check the SD list and TA list and prepare for a subsequent command
such as "CreateSD" if it needs to have a new SD for a an SP.

8.2.

9.2. Security Domain Management

8.2.1.

9.2.1. CreateSD

This command is typically preceded with a GetDeviceState command that
has acquired the device information of the target device by the TSM.
TSM TAM.
The TAM sends such a command to instruct a TEE to create a new
Security Domain for a an SP.

A TSM TAM sends an OTrP CreateSDRequest Request message CreateSDRequest to a device TEE
to create a Security Domain for a an SP. Such a request is signed by
TSM
the TAM where the TSM TAM signer may or may not be the same as the SP's
TA signer certificate. The resulting SD is associated with two
identifiers for future management:

o TSM TAM as the owner. The owner identifier is a registered unique TSM TAM
ID that is stored in the TSM TAM certificate.

o SP identified by its TA signer certificate as the authorization.
A TSM TAM can add more than one SP certificates certificate to a an SD.

A Trusted Application that is signed by a matching SP signer
certificate for a an SD is eligible to be installed into that SD. The
TA installation into a an SD by a subsequent InstallTARequest message
may be instructed from TSM or a Client Application.

8.2.1.1. TAM.

9.2.1.1. CreateSDRequest Message
The request message for CreateSD has the following JSON format.

{
"CreateSDTBSRequest": {
"ver": "1.0",
"rid": "<unique request ID>",
"tid": "<transaction ID>", // this may be from prior message
"tee": "<TEE routing name from the DSI for the SD's target>",
"nextdsi": "true true | false", false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED { // this piece of JSON data will be
// encrypted
"spid": "<SP ID value>",
"sdname": "<SD name for the domain to be created>",
"spcert": "<BASE64 encoded SP certificate>",
"tsmid":
"tamid": "<An identifiable attribute of the TSM TAM
certificate>",
"did": "<SHA256 hash of the TEE cert>"
}
}
}

In the message,

rid - A unique value to identify this request

tid - A unique value to identify this transaction. It can have the
same value for the tid in the preceding GetDeviceStateRequest.

tee - TEE ID returned from the previous response
GetDeviceStateResponse GetDeviceStateResponse.

nextdsi - Indicates whether the up to date up-to-date Device State Information
(DSI) should be returned is expected in the response from the TEE to this request.

dsihash - The BASE64 encoded BASE64-encoded SHA256 hash value of the DSI data
returned in the prior TSM TAM operation with this target TEE. This
value is always included such that a receiving TEE can check
whether the device state has changed since its last query. It
helps enforce SD update order in the right sequence without
accidently overwrite overwriting an update that was done simultaneously.

content - The "content" is a JSON encrypted message that includes
actual input for the SD creation. The encryption key is TSMmk TAMmk that
is encrypted by the target TEE's public key. The entire message is
signed by the TSM TAM private key TSMpriv. TAMpriv. A separate TSMmk TAMmk isn't used
in the latest specification because JSON encryption will use a
content encryption key for exactly the same purpose.

spid - A unique id assigned by the TSM TAM for its SP. It should be
unique within a TSM TAM namespace.

sdname - a name unique to the SP. TSM TAM should ensure it is unique
for each SP.

spcert - The SP's TA signer certificate is included in the request.
This certificate will be stored by the device TEE and which uses it to
check against TA installation. Only if a TA is signed by a
matching spcert associated with a an SD will the TA will be installed into
the SD.

tsmid

tamid - SD owner claim by TSM TAM - A an SD owned by a TSM TAM will be
associated with a trusted identifier defined as an attribute in the
signer TSM TAM certificate. TEE will be responsible to assign this ID
to the SD. The TSM TAM certificate attribute for this attribute TSMID
must tamid
MUST be vetted by the TSM TAM signer issuing CA. With this trusted
identifier, the SD query at TEE can be fast upon TSM TAM signer
verification.

did - The SHA256 hash of the binary encoded binary-encoded device TEE certificate.
The encryption key CEK will be encrypted the recipient TEE's public
key. This hash value in the "did" property allows the recipient
TEE to check whether it is the expected target to receive such a
request. If this isn't given, an OTrP message for device 2 could
be sent to device 1. It is optional for the TEE to check because
the successful decryption of the request message with this device's
TEE private key already proves it is the target. This explicit
hash value makes the protocol not dependent on message encryption
method in future.

Following is the OTrP

A CreateSDTBSRequest message template, the full request is signed to generate a final
CreateSDRequest message over the CreateSDTBSRequest as follows.

{
"CreateSDRequest": {
"payload":"<CreateSDTBSRequest
"payload": "<CreateSDTBSRequest JSON above>",
"protected":"<integrity-protected
"protected": "<integrity-protected header contents>",
"header": <non-integrity-protected "<non-integrity-protected header contents>,
"signature":"<signature contents>",
"signature": "<signature contents signed by TSM TAM private key>"
}
}

TSM

The TAM signer certificate is included in the "header" property.

8.2.1.2.

9.2.1.2. Request Processing Requirements at a TEE

Upon receiving a CreateSDRequest request message CreateSDRequest at a TEE, the TEE
must validate a request:
MUST do the following:

1. Validate the JSON request message as follows

* Validate JSON message signing signing.

* Validate that the request TSM TAM certificate is chained to a
trusted CA that the TEE embeds as its trust anchor anchor.

* Compare dsihash with its current state to make sure nothing
has changed since this request was sent.

* Decrypt to get the plaintext of the content: (a) spid, (b) sd
name, (c) did did.

* Check that a an SPID is supplied supplied.

* spcert check: check it is a valid certificate (signature and
format verification only) only).

* Check "did" is the SHA256 hash of its TEEcert BER raw binary
data
data.

* Check whether the requested SD already exists for the SP SP.

* Check TSMID that the tamid in the request matches TSM the TAM
certificate's TSM TAM ID
attribute attribute.

2. Create If the request was valid, create action

* Create a an SD for the SP with the given name name.

* Assign the TSMID tamid from the TSMCert TAMCert to this SD SD.

* Assign the SPID and SPCert to this SD SD.

* Check whether a TEE SP AIK keypair key pair already exists for the
given SP ID ID.

* Create TEE SP AIK keypair key pair if it doesn't exist for the given
SP
ID ID.

* Generate new DSI data if the request asks for updated DSI DSI.

3. Construct a CreateSDResponse message
* Create raw content

+ Operation status

+ "did" or full signer certificate information,

+ TEE SP AIK public key if DSI isn't going to be included

+ Updated DSI data if requested if the request asks for it

* The response message is encrypted with the same JWE CEK of the
request without recreating a new content encryption key.

* The encrypted message is signed with TEEpriv. The signer
information ("did" or TEEcert) is encrypted.

4. Deliver the response message. (a) The OTrP Agent returns this to
the app; Client Application; (b) The app Client App passes this back to TSM
the TAM.

5. TSM process. TAM processing. (a) TSM The TAM processes the response message; (b) TSM
the TAM can look up signer certificate from the device ID "did".

If a request is illegitimate or signature doesn't pass, a "status"
property in the response will indicate the error code and cause.

8.2.1.3.

9.2.1.3. CreateSDResponse Message

The response message for a CreateSDRequest contains the following
content.

{
"CreateSDTBSResponse": {
"ver": "1.0",
"status": "<operation result>",
"rid": "<the request ID received>",
"tid": "<the transaction ID received>",
"content": ENCRYPTED {
"reason":"<failure
"reason": "<failure reason detail>", // optional
"did": "<the device id received from the request>",
"sdname": "<SD name for the domain created>",
"teespaik": "<TEE SP AIK public key, BASE64 encoded>",
"dsi": "<Updated TEE state, including all SD SDs owned by
this TSM>" TAM>"
}
}
}
In the response message, the following fields MUST be supplied.

did - The SHA256 hash of the device TEE certificate. This shows
the device ID explicitly to the receiving TSM. TAM.

teespaik - The newly generated SP AIK public key for the given SP.
This is an optional value if the device has had another domain for
the SP that has triggered TEE SP AIK keypair key pair for this specific SP.

There is a possible extreme error case where the TEE isn't reachable
or the TEE final response generation itself fails. In this case, TSM should the
TAM might still receive a response from the OTrP Agent. Agent if the OTrP
Agent is able to detect such error from TEE. In this case, a general
error response message should be returned, returned by the OTrP Agent, assuming
OTrP Agent even doesn't know any content and information about the
request message.

In other words, TSM the TAM should expect to receive a TEE successfully
signed JSON message, or a general "status" message. message, or none when a
client experiences a network error.

{
"CreateSDResponse": {
"payload":"<CreateSDTBSResponse
"payload": "<CreateSDTBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by the TEE device private
key (BASE64URL)>"
}
}

A response message type "status" will be returned when the TEE totally fails
to respond. The OTrP Agent is responsible to create this message.

{
"status": {
"result": "fail",
"error-code": "ERR_TEE_UNKNOWN", "ERR_AGENT_TEE_FAIL",
"error-message": "TEE fails to respond"
}
}

8.2.1.4.

9.2.1.4. Error Conditions

An error may might occur if a request isn't valid or the TEE runs into
some error. The list of possible errors are the following. as follows. Refer to
section
the Error Code List (Section 14.1) 15.1) for detail detailed causes and actions.

ERR_AGENT_TEE_BUSY

ERR_AGENT_TEE_FAIL

ERR_AGENT_TEE_UNKNOWN

ERR_REQUEST_INVALID

ERR_UNSUPPORTED_MSG_VERSION

ERR_UNSUPPORTED_CRYPTO_ALG

ERR_DEV_STATE_MISMATCH

ERR_SD_ALREADY_EXIST

ERR_SD_NOT_FOUND

ERR_SPCERT_INVALID

ERR_TEE_FAIL

ERR_TEE_UNKNOWN

ERR_TSM_NOT_AUTHORIZED

ERR_TSM_NOT_TRUSTED

8.2.2.

ERR_TAM_NOT_AUTHORIZED

ERR_TAM_NOT_TRUSTED

9.2.2. UpdateSD

This TSM TAM initiated command can update a an SP's SD that it manages for
any of the following need. needs: (a) Update an SP signer certificate; (b)
Add an SP signer certificate when a an SP uses multiple to sign TA binary;
binaries; (c) Update an SP ID.

The TSM TAM presents the proof of the SD ownership to the TEE, and
includes related information in its signed message. The entire
request is also encrypted for the end-to-end confidentiality.

8.2.2.1.

9.2.2.1. UpdateSDRequest Message
The UpdateSD request message for UpdateSD has the following JSON format.

{
"UpdateSDTBSRequest": {
"ver": "1.0",
"rid": "<unique request ID>",
"tid": "<transaction ID>", // this may be from prior message
"tee": "<TEE routing name from the DSI for the SD's target>",
"nextdsi": "true true | false", false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED { // this piece of JSON will be encrypted
"tsmid": "<TSMID
"tamid": "<tamid associated with this SD>",
"spid": "<SP ID>",
"sdname": "<SD name for the domain to be updated>",
"changes": {
"newsdname": "<Change the SD name to this new name>",
// Optional
"newspid": "<Change SP ID of the domain to this new value>",
// Optional
"spcert": ["<BASE64 encoded new SP signer cert to be added>"],
// Optional
"deloldspcert": ["<The SHA256 hex value of an old SP cert
assigned into this SD that should be deleted >"],
// Optional
"renewteespaik": "true true | false" false
}
}
}
}

In the message,

rid - A unique value to identify this request

tid - A unique value to identify this transaction. It can have the
same value for as the tid in the preceding GetDeviceStateRequest.

tee - TEE ID returned from the previous response GetDeviceStateResponse

nextdsi - Indicates whether the up to date up-to-date Device State Information
(DSI) should is expected to be returned in the response from the TEE to
this request.

content - The "content" is a JSON encrypted message that includes
actual input for the SD update. The standard JSON content
encryption key (CEK) is used, and the CEK is encrypted by the
target TEE's public key.

tsmid

tamid - SD owner claim by TSM TAM - A an SD owned by a TSM TAM will be
associated with a trusted identifier defined as an attribute in the
signer TSM TAM certificate.

spid - the identifier of the SP whose SD will be updated. This
value is still needed because the SD name is considered unique only
within a
SP only. an SP.

sdname - the name of the target SD to be updated.

changes - its content consists of changes that should are to be updated in the
given SD.

newsdname - the new name of the target SD to be assigned if this
value is present.

newspid - the new SP ID of the target SD to be assigned if this
value is present.

spcert - a new TA signer certificate of this SP to be added to the
SD if this is present.

deloldspcert - a an SP certificate assigned into the SD should is to be
deleted if this is present. The value is the SHA256 fingerprint of
the old SP certificate.

renewteespaik - the value should be 'true' true or 'false'. false. If it is present
and the value is 'true', true, the TEE should MUST regenerate TEE SP AIK for this
SD's owner SP. The newly generated TEE SP AIK for the SP must be
returned in the response message of this request. If there
are is more
than one SD for the SP, a new SPID for one of the domain domains will
always trigger a new teespaik generation as if a new SP is were
introduced to the TEE.

Following the OTrP

The UpdateSDTBSRequest message template, the full request is signed
message over to generate the UpdateSDTBSRequest as follows. final
UpdateSDRequest message.

{
"UpdateSDRequest": {
"payload":"<UpdateSDTBSRequest
"payload": "<UpdateSDTBSRequest JSON above>",
"protected":"<integrity-protected
"protected": "<integrity-protected header contents>",
"header": <non-integrity-protected "<non-integrity-protected header contents>, contents>",
"signature":"<signature contents signed by TSM TAM private key>"
}
}

TSM

TAM signer certificate is included in the "header" property.

8.2.2.2.

9.2.2.2. Request Processing Requirements at a TEE

Upon receiving a request message UpdateSDRequest at a TEE, the TEE
must validate a request:

1. Validate the JSON request message

* Validate JSON message signing

* Validate that the request TSM TAM certificate is chained to a
trusted CA that the TEE embeds as its trust anchor. TSM anchor.The TAM
certificate status check is generally not needed anymore in
this request. The prior request should have validated the TSM TAM
certificate's revocation status status.

* Compare dsihash with the TEE cached last response DSI data to
this
TSM TAM.

* Decrypt to get the plaintext of the content content.

* Check that the target SD name is supplied supplied.

* Check whether the requested SD exists exists.

* Check that the TSM TAM owns this TSM TAM by verifying TSMID tamid in the SD
matches TSM TAM certificate's TSM TAM ID attribute attribute.

* Now the TEE is ready to carry out update listed in the
"content" message message.

2. Update If the request is valid, update action

* If "newsdname" is given, replace the SD name for the SD to the
new value

* If "newspid" is given, replace the SP ID assigned to this SD
with the given new value

* If "spcert" is given, add this new SP certificate to the SD.

* If "deloldspcert" is present in the content, check previously
assigned SP certificates to this SD, and delete the one that
matches the given certificate hash value.

* If "renewteespaik" is given and has a value as "true", of 'true',
generate a new TEE SP AIK keypair, key pair, and replace the old one
with this.

* Generate new DSI data if the request asks for updated DSI

* Now the TEE is ready to construct the response message

3. Construct UpdateSDResponse message

* Create raw content

+ Operation status

+ "did" or full signer certificate information,

+ TEE SP AIK public key if DSI isn't going to be included

+ Updated DSI data if requested if the request asks for it

* The response message is encrypted with the same JWE CEK of the
request without recreating a new content encryption key.

* The encrypted message is signed with TEEpriv. The signer
information ("did" or TEEcert) is encrypted.

4. Deliver response message. (a) The OTrP Agent returns this to the
app; (b) The app passes this back to TSM the TAM.

5. TSM process. TAM processing. (a) TSM The TAM processes the response message; (b) TSM
The TAM can look up the signer certificate from the device ID
"did".

If a request is illegitimate or the signature doesn't pass, a
"status" property in the response will indicate the error code and
cause.

8.2.2.3.

9.2.2.3. UpdateSDResponse Message

The response message for a UpdateSDRequest contains the following
content.

{
"UpdateSDTBSResponse": {
"ver": "1.0",
"status": "<operation result>",
"rid": "<the request ID received>",
"tid": "<the transaction ID received>",
"content": ENCRYPTED {
"reason":"<failure
"reason": "<failure reason detail>", // optional
"did": "<the device id hash>",
"cert": "<TEE certificate>", // optional
"teespaik": "<TEE SP AIK public key, BASE64 encoded>",
"teespaiktype": "<TEE SP AIK key type: RSA or ECC>",
"dsi": "<Updated TEE state, including all SD owned by
this TSM>" TAM>"
}
}
}

In the response message, the following fields MUST be supplied.

did - The request should have known the signer certificate of this
device from a prior request. This hash value of the device TEE
certificate serves as a quick identifier only. Full A full device
certificate isn't necessary.

teespaik - the newly generated SP AIK public key for the given SP
if the TEE SP AIK for the SP is asked to be renewed in the request.
This is an optional value if "dsi" is included in the response,
which will contain all up to date up-to-date TEE SP AIK key pairs.

Similar to the template for the creation of the encrypted and signed
CreateSDResponse, the final UpdateSDResponse looks like the
following.

{
"UpdateSDResponse": {
"payload":"<UpdateSDTBSResponse
"payload": "<UpdateSDTBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by TEE device private
key (BASE64URL)>"
}
}

A response message type "status" will be returned when the TEE totally fails
to respond. The OTrP Agent is responsible to create this message.

{
"status": {
"result": "fail",
"error-code": "ERR_TEE_UNKNOWN", "ERR_AGENT_TEE_FAIL",
"error-message": "TEE "<TEE fails to respond" respond message>"
}
}

8.2.2.4.

9.2.2.4. Error Conditions

An error may occur if a request isn't valid or the TEE runs into some
error. The list of possible errors are the following. as follows. Refer to
section the
Error Code List (Section 14.1) 15.1) for detail detailed causes and actions.

ERR_AGENT_TEE_BUSY

ERR_AGENT_TEE_FAIL

ERR_AGENT_TEE_UNKNOWN

ERR_REQUEST_INVALID

ERR_UNSUPPORTED_MSG_VERSION

ERR_UNSUPPORTED_CRYPTO_ALG

ERR_DEV_STATE_MISMATCH

ERR_SD_NOT_FOUND

ERR_SDNAME_ALREADY_USED

ERR_SPCERT_INVALID
ERR_TEE_FAIL

ERR_TEE_UNKNOWN

ERR_TSM_NOT_AUTHORIZED
ERR_TSM_NOT_TRUSTED

8.2.3.

ERR_TAM_NOT_AUTHORIZED

ERR_TAM_NOT_TRUSTED

9.2.3. DeleteSD

A TSM TAM sends a DeleteSDRequest message to a TEE to delete a specified
SD that it owns. A An SD can be deleted only if there is no TA
associated with this SD in the device. The request message can
contain a flag to instruct the TEE to delete all related TAs in a an SD
and then delete the SD.

The target TEE will operate with the following logic.

1. Lookup Look up the given SD specified in the request message

2. Check that the TSM TAM owns the SD

3. Check that the device state hasn't changed since the last
operation

4. Check whether there are TAs in this SD

5. If TA exists in a an SD, check whether the request instructs
whether the TA should be deleted. If the request instructs the
TEE to delete TAs, delete all TAs in this SD. If the request
doesn't instruct the TEE to delete TAs, return an error
"ERR_SD_NOT_EMPTY".

6. Delete the SD

7. If this is the last SD of this SP, delete the TEE SP AIK key

8.2.3.1. key.

9.2.3.1. DeleteSDRequest Message
The request message for DeleteSD has the following JSON format.

{
"DeleteSDTBSRequest": {
"ver": "1.0",
"rid": "<unique request ID>",
"tid": "<transaction ID>", // this may be from prior message
"tee": "<TEE routing name from the DSI for the SD's target>",
"nextdsi": "true true | false", false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED { // this piece of JSON will be encrypted
"tsmid": "<TSMID
"tamid": "<tamid associated with this SD>",
"sdname": "<SD name for the domain to be updated>",
"deleteta": "true true | false" false
}
}
}

In the message,

rid - A unique value to identify this request

tid - A unique value to identify this transaction. It can have the
same value for the tid in the preceding GetDeviceStateRequest.

tee - TEE ID returned from the previous response
GetDeviceStateResponse

nextdsi - Indicates whether the up to date up-to-date Device State Information
(DSI) should is to be returned in the response to this request.

tsmid

tamid - SD owner claim by TSM TAM - A an SD owned by a TSM TAM will be
associated with a trusted identifier defined as an attribute in the
signer TSM TAM certificate.

sdname - the name of the target SD to be updated.

deleteta - the value should be boolean 'true' or 'false'. If it is
present and the value is 'true', the TEE should delete all TAs
associated with the SD in the device.

Following

According to the OTrP message template, the full request
DeleteSDRequest is a signed message over the DeleteSDTBSRequest as
follows.

{
"DeleteSDRequest": {
"payload":"<DeleteSDTBSRequest
"payload": "<DeleteSDTBSRequest JSON above>",
"protected":"<integrity-protected
"protected": "<integrity-protected header contents>",
"header": <non-integrity-protected "<non-integrity-protected header contents>,
"signature":"<signature contents>",
"signature": "<signature contents signed by TSM TAM private key>"
}
}

TSM

TAM signer certificate is included in the "header" property.

8.2.3.2.

9.2.3.2. Request Processing Requirements at a TEE

Upon receiving a request message DeleteSDRequest at a TEE, the TEE
must validate a request:

1. Validate the JSON request message

* Validate JSON message signing

* Validate that the request TSM TAM certificate is chained to a
trusted CA that the TEE embeds as its trust anchor. TSM The TAM
certificate status check is generally not needed anymore in
this request. The prior request should have validated the TSM TAM
certificate's revocation status status.

* Compare dsihash with the TEE cached last response DSI data to
this
TSM TAM

* Decrypt to get the plaintext of the content

* Check that the target SD name is supplied

* Check whether the requested SD exists

* Check that the TSM TAM owns this TSM TAM by verifying TSMID that the tamid
in the SD matches TSM the TAM certificate's TSM TAM ID attribute

* Now the TEE is ready to carry out the update listed in the
"content" message

2. Deletion If the request is valid, deletion action

* Check TA existence in this SD

* If "deleteta" is "true", delete all TAs in this SD. If the
value of "deleteta" is "false" false and some TA exists, return an
error "ERR_SD_NOT_EMPTY"

* Delete the SD

* Delete the TEE SP AIK key pair if this SD is the last one for
the SP

* Now the TEE is ready to construct the response message

3. Construct a DeleteSDResponse message

* Create response content

+ Operation status

+ "did" or full signer certificate information,

+ Updated DSI data if requested if the request asks for it

* The response message is encrypted with the same JWE CEK of the
request without recreating a new content encryption key.

* The encrypted message is signed with TEEpriv. The signer
information ("did" or TEEcert) is encrypted.

4. Deliver response message. (a) The OTrP Agent returns this to the
app; (b) The app passes this back to TSM the TAM

5. TSM process. TAM processing. (a) TSM The TAM processes the response message; (b) TSM
The TAM can look up signer certificate from the device ID "did".

If a request is illegitimate or the signature doesn't pass, a
"status" property in the response will indicate the error code and
cause.

8.2.3.3.

9.2.3.3. DeleteSDResponse Message

The response message for a DeleteSDRequest contains the following
content.

{
"DeleteSDTBSResponse": {
"ver": "1.0",
"status": "<operation result>",
"rid": "<the request ID received>",
"tid": "<the transaction ID received>",
"content": ENCRYPTED {
"reason":"<failure
"reason": "<failure reason detail>", // optional
"did": "<the device id hash>",
"dsi": "<Updated TEE state, including all SD owned by
this TSM>" TAM>"
}
}
}

In the response message, the following fields MUST be supplied.

The final DeleteSDResponse looks like the following.

{
"DeleteSDResponse": {
"payload":"<DeleteSDTBSResponse
"payload": "<DeleteSDTBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by TEE device
private key (BASE64URL)>"
}
}

A response message type "status" will be returned when the TEE totally fails
to respond. The OTrP Agent is responsible to create this message.

{
"status": {
"result": "fail",
"error-code": "ERR_TEE_UNKNOWN", "ERR_AGENT_TEE_FAIL",
"error-message": "TEE fails to respond"
}
}

8.2.3.4.

9.2.3.4. Error Conditions

An error may occur if a request isn't valid or the TEE runs into some
error. The list of possible errors are the following. is as follows. Refer to
section the
Error Code List (Section 14.1) 15.1) for detail detailed causes and actions.

ERR_AGENT_TEE_BUSY

ERR_AGENT_TEE_FAIL

ERR_AGENT_TEE_UNKNOWN

ERR_REQUEST_INVALID

ERR_UNSUPPORTED_MSG_VERSION

ERR_UNSUPPORTED_CRYPTO_ALG

ERR_DEV_STATE_MISMATCH

ERR_SD_NOT_EMPTY

ERR_SD_NOT_FOUND

ERR_TEE_FAIL

ERR_TEE_UNKNOWN

ERR_TSM_NOT_AUTHORIZED

ERR_TSM_NOT_TRUSTED

8.3.

ERR_TAM_NOT_AUTHORIZED

ERR_TAM_NOT_TRUSTED

9.3. Trusted Application Management

This protocol doesn't introduce a TA container concept. All the TA
authorization and management will be up to the TEE implementation.

The following three TA management commands will be are supported.

o InstallTA - provision a TA by TSM TAM

o UpdateTA - update a TA by TSM TAM

o DeleteTA - remove TA registration information with a an SD, remove
the TA binary from TEE, remove and all TA related TA-related data in a TEE

8.3.1.

9.3.1. InstallTA

TA binary data and related personalization data if there is any can
be from two sources:

1. TSM A TAM supplies the signed and encrypted TA binary

2. A Client Application supplies the TA binary

This specification primarily considers only the first case where TSM a TAM
supplies a TA binary. When such a request This is received by TEE, to ensure that a SD is already
created and TEE can properly
validate whether a TA is ready to take trustworthy. Further, TA installation. personalization
data will be encrypted by the TEE device's SP public key for end-to-
end protection. A Client Application bundled TA case will be
addressed separately later.

A TSM TAM sends the following information in message a InstallTARequest message
to a target TEE:

o The target SD information: SP ID and SD name

o Encrypted TA binary data. TA data is encrypted with the TEE SP
AIK.

o TA metadata. It is optional to include the SP signer certificate
for the SD to add if the SP has changed signer since the SD was
created.

The TEE processes the command given by TSM the TAM to install a TA into a
an SP's SD. It does the following:

o Validation

* The TEE validates TSM the TAM message authenticity

* Decrypt to get request content

* Lookup Look up the SD with the SD name

* Checks that the TSM TAM owns the SD

* Checks that the DSI hash matches which shows that the device
state hasn't changed

o If the request is valid, continue to do the TA validation

* Decrypt to get the TA binary data and any personalization data
with the "TEE SP AIK private key"

* Check that SP ID is the one that is registered with the SP SD

* Check that the TA signer is either the a newly given SP certificate
or the one
in SD. that is already trusted by the SD from the previous
TA installation. The TA signing method is specific to a TEE.
This specification doesn't define how a TA should be signed. signed; a
TAM should support TEE specific TA signing when it supports
that TEE.

* If a TA signer is given in the request, add this signer into
the SD.

o If the above validation passed, continue to do TA installation

* The TEE re-encrypts the TA binary and its personalization data
with its own method method.

* The TEE enrolls and stores the TA onto TEE in a secure storage area. storage.

o Construct a response message. This involves signing a encrypted
status information for the requesting TSM.

8.3.1.1. TAM.

9.3.1.1. InstallTARequest Message
The request message for InstallTA has the following JSON format.

{
"InstallTATBSRequest": {
"ver": "1.0",
"rid": "<unique request ID>",
"tid": "<transaction ID>",
"tee": "<TEE routing name from the DSI for the SD's target>",
"nextdsi": "true true | false", false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED {
"tsmid": "<TSM
"tamid": "<TAM ID previously assigned to the SD>",
"spid": "<SPID value>",
"sdname": "<SD name for the domain to install the TA>",
"spcert": "<BASE64 encoded SP certificate >", // optional
"taid": "<TA identifier>"
},
"encrypted_ta": {
"key": "<A "<JWE enveloped data of a 256-bit symmetric key encrypted by
the recipient's TEEspaik public key>",
"iv": "<hex of 16 random bytes>",
"alg": "<encryption algoritm. AESCBC by default.",
"ciphertadata": "<BASE64 encoded encrypted TA binary data>",
"cipherpdata": "<BASE64 encoded encrypted TA personalization
data>"
}
}
}

In the message,

rid - A unique value to identify this request

tid - A unique value to identify this transaction. It can have the
same value for the tid in the preceding GetDeviceStateRequest.

tee - TEE ID returned from the previous response GetDeviceStateResponse

nextdsi - Indicates whether the up to date up-to-date Device State Information
(DSI) should is to be returned in the response to this request.

tsmid

tamid - SD owner claim by TSM TAM - A An SD owned by a TSM TAM will be
associated with a trusted identifier defined as an attribute in the
signer TSM TAM certificate.

spid - SP identifier of the TA owner SP

sdname - the name of the target SD where the TA should is to be installed

spcert - an optional field to specify the SP certificate that signed
the TA. This is sent if the SP has a new certificate that hasn't
been previously registered with the target SD where the TA should
be installed.

taid - the identifier of the TA application to be installed

encrypted_ta - the message portion contains encrypted TA binary data
and personalization data. The TA data encryption key is placed in
"key", which is encrypted by the recipient's public key. key, using JWE
enveloped structure. The TA data encryption uses symmetric key
based encryption such as AESCBC.

Following

According to the OTrP message template, the full request
InstallTARequest is a signed message over the InstallTATBSRequest as
follows.

{
"InstallTARequest": {
"payload":"<InstallTATBSRequest
"payload": "<InstallTATBSRequest JSON above>",
"protected":"<integrity-protected
"protected": "<integrity-protected header contents>",
"header": <non-integrity-protected "<non-integrity-protected header contents>,
"signature":"<signature contents>",
"signature": "<signature contents signed by TSM TAM private key>"
}
}

8.3.1.2.

9.3.1.2. InstallTAResponse Message

The response message for a InstallTARequest contains the following
content.

{
"InstallTATBSResponse": {
"ver": "1.0",
"status": "<operation result>",
"rid": "<the request ID received>",
"tid": "<the transaction ID received>",
"content": ENCRYPTED {
"reason":"<failure reason detail>", // optional
"did": "<the device id hash>",
"dsi": "<Updated TEE state, including all SD owned by
this TSM>" TAM>"
}
}
}

In the response message, the following fields MUST be supplied.

did - the SHA256 hash of the device TEE certificate. This shows
the device ID explicitly to the receiving TSM. TAM.

The final message InstallTAResponse looks like the following.

{
"InstallTAResponse": {
"payload":"<InstallTATBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by TEE device
private key (BASE64URL)>"
}
}

A response message type "status" will be returned when the TEE totally fails
to respond. The OTrP Agent is responsible to create this message.

{
"status": {
"result": "fail",
"error-code": "ERR_TEE_UNKNOWN", "ERR_AGENT_TEE_FAIL",
"error-message": "TEE fails to respond"
}
}

8.3.1.3.

9.3.1.3. Error Conditions

ERR_AGENT_TEE_BUSY

ERR_AGENT_TEE_FAIL

ERR_AGENT_TEE_UNKNOWN

ERR_REQUEST_INVALID

ERR_UNSUPPORTED_MSG_VERSION

ERR_UNSUPPORTED_CRYPTO_ALG

ERR_DEV_STATE_MISMATCH

ERR_SD_NOT_FOUND

ERR_TA_INVALID

ERR_TA_ALREADY_INSTALLED

ERR_TEE_FAIL

ERR_TEE_UNKNOWN

ERR_TEE_RESOURCE_FULL

ERR_TSM_NOT_AUTHORIZED

ERR_TSM_NOT_TRUSTED

8.3.2.

ERR_TAM_NOT_AUTHORIZED

ERR_TAM_NOT_TRUSTED

9.3.2. UpdateTA

This TSM initiated TAM-initiated command can update a TA and its data in a an SP's SD
that it manages for the following purposes.

1. Update TA binary

2. Update TA's personalization data

The TSM TAM presents the proof of the SD ownership to a TEE, and includes
related information in its signed message. The entire request is
also encrypted for the end-to-end confidentiality.

The TEE processes the command given by TSM from the TAM to update the TA of a an SP
SD. It does the following:

o Validation

* The TEE validates TSM the TAM message authenticity

* Decrypt to get request content

* Lookup Look up the SD with the SD name

* Checks that the TSM TAM owns the SD

* Checks DSI hash matches that the device state hasn't changed

o TA validation

* Both TA binary and personalization data are optional, but at
least one of them shall be present in the message

* Decrypt to get the TA binary and any personalization data with
the "TEE SP AIK private key"

* Check that SP ID is the one that is registered with the SP SD

* Check that the TA signer is either the a newly given SP certificate
or the one in SD. The TA signing method is specific to TEE. This
specification doesn't define how a TA should be signed.

* If a TA signer is given in the request, add this signer into
the SD SD.

o If the above validation passes, continue to do TA update

* The TEE re-encrypts the TA binary and its personalization data
with its own method

* The TEE replaces the existing TA binary and its personalization
data with the new binary and data.

o Construct a response message. This involves signing a encrypted
status information for the requesting TSM.

8.3.2.1. TAM.

9.3.2.1. UpdateTARequest Message
The request message for UpdateTA has the following JSON format.

{
"UpdateTATBSRequest": {
"ver": "1.0",
"rid": "<unique request ID>",
"tid": "<transaction ID>",
"tee": "<TEE routing name from the DSI for the SD's target>",
"nextdsi": "true true | false", false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED {
"tsmid": "<TSM
"tamid": "<TAM ID previously assigned to the SD>",
"spid": "<SPID value>",
"sdname": "<SD name for the domain to be created>",
"spcert": "<BASE64 encoded SP certificate >", // optional
"taid": "<TA identifier>"
},
"encrypted_ta": {
"key": "<A "<JWE enveloped data of a 256-bit symmetric key encrypted by
the recipient's TEEspaik public key>",
"iv": "<hex of 16 random bytes>",
"alg": "<encryption algoritm. AESCBC by default.",
"ciphernewtadata": "<Change existing TA binary to this new TA
binary data(BASE64 encoded and encrypted)>",
"ciphernewpdata": "<Change the existing data to this new TA
personalization data(BASE64 encoded and encrypted)>"
// optional
}
}
}

In the message,

rid - A unique value to identify this request

tid - A unique value to identify this transaction. It can have the
same value for the tid in the preceding GetDeviceStateRequest.

tee - TEE ID returned from the previous response GetDeviceStateResponse

nextdsi - Indicates whether the up to date up-to-date Device State Information
(DSI) should is to be returned in the response to this request.

tsmid

tamid - SD owner claim by TSM TAM - A an SD owned by a TSM TAM will be
associated with a trusted identifier defined as an attribute in the
signer TSM TAM certificate.

spid - SP identifier of the TA owner SP

sdname - the name of the target SD where the TA should be updated

taid - an identifier for the TA application to be updated

encrypted_ta - the message portion contains new newly encrypted TA
binary data and personalization data.

Following

According to the OTrP message template, the full request
UpdateTARequest is a signed message over the UpdateTATBSRequest as
follows.

{
"UpdateTARequest": {
"payload":"<UpdateTATBSRequest
"payload": "<UpdateTATBSRequest JSON above>",
"protected":"<integrity-protected
"protected": "<integrity-protected header contents>",
"header": <non-integrity-protected "<non-integrity-protected header contents>,
"signature":"<signature contents>",
"signature": "<signature contents signed by TSM TAM private key>"
}
}

8.3.2.2.

9.3.2.2. UpdateTAResponse Message

The response message for a UpdateTARequest contains the following
content.

{
"UpdateTATBSResponse": {
"ver": "1.0",
"status": "<operation result>",
"rid": "<the request ID received>",
"tid": "<the transaction ID received>",
"content": ENCRYPTED {
"reason":"<failure
"reason": "<failure reason detail>", // optional
"did": "<the device id hash>",
"dsi": "<Updated TEE state, including all SD owned by
this TSM>" TAM>"
}
}
}

In the response message, the following fields MUST be supplied.

did - the SHA256 hash of the device TEE certificate. This shows
the device ID explicitly to the receiving TSM. TAM.

The final message UpdateTAResponse looks like the following.

{
"UpdateTAResponse": {
"payload":"<UpdateTATBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by TEE device
private key (BASE64URL)>"
}
}

A response message type "status" will be returned when the TEE totally fails
to respond. The OTrP Agent is responsible to create this message.

{
"status": {
"result": "fail",
"error-code": "ERR_TEE_UNKNOWN", "ERR_AGENT_TEE_FAIL",
"error-message": "TEE fails to respond"
}
}

8.3.2.3.

9.3.2.3. Error Conditions

ERR_AGENT_TEE_BUSY

ERR_AGENT_TEE_FAIL

ERR_AGENT_TEE_UNKNOWN

ERR_REQUEST_INVALID

ERR_UNSUPPORTED_MSG_VERSION

ERR_UNSUPPORTED_CRYPTO_ALG

ERR_DEV_STATE_MISMATCH

ERR_SD_NOT_FOUND

ERR_TA_INVALID

ERR_TA_NOT_FOUND

ERR_TEE_FAIL

ERR_TEE_UNKNOWN

ERR_TSM_NOT_AUTHORIZED

ERR_TSM_NOT_TRUSTED

8.3.3.

ERR_TAM_NOT_AUTHORIZED

ERR_TAM_NOT_TRUSTED

9.3.3. DeleteTA

This operation defines OTrP messages that allow a TSM TAM to instruct a
TEE to delete a TA for a an SP in a given SD. A TEE will delete a TA
from a an SD and also TA data in the TEE. A Client Application cannot
directly access TEE or OTrP Agent to delete a TA.

8.3.3.1.

9.3.3.1. DeleteTARequest Message
The request message for DeleteTA has the following JSON format.

{
"DeleteTATBSRequest": {
"ver": "1.0",
"rid": "<unique request ID>",
"tid": "<transaction ID>",
"tee": "<TEE routing name from the DSI for the SD's target>",
"nextdsi": "true true | false", false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED {
"tsmid": "<TSM
"tamid": "<TAM ID previously assigned to the SD>",
"sdname": "<SD name of the TA>",
"taid": "<the identifier of the TA to be deleted from the
specified SD>"
}
}
}

In the message,

rid - A unique value to identify this request

tid - A unique value to identify this transaction. It can have the
same value for the tid in the preceding GetDeviceStateRequest.

tee - The TEE ID returned from the previous response GetDeviceStateResponse

nextdsi - Indicates whether the up to date up-to-date Device State Information
(DSI) should is to be returned in the response to this request.

tsmid

tamid - SD owner claim by TSM TAM - A an SD owned by a TSM TAM will be
associated with a trusted identifier defined as an attribute in the
signer TSM TAM certificate.

sdname - the name of the target SD where the TA is installed
taid - an identifier for the TA application to be deleted

Following

According to the OTrP message template, the full request
DeleteTARequest is a signed message over the DeleteTATBSRequest as
follows.

{
"DeleteTARequest": {
"payload":"<DeleteTATBSRequest
"payload": "<DeleteTATBSRequest JSON above>",
"protected":"<integrity-protected
"protected": "<integrity-protected header contents>",
"header": <non-integrity-protected "<non-integrity-protected header contents>,
"signature":"<signature contents>",
"signature": "<signature contents signed by TSM TAM
private key>"
}
}

8.3.3.2.

9.3.3.2. Request Processing Requirements at a TEE

A TEE processes a command given by TSM from a TAM to delete a TA of a an SP SD. It
does the following:

1. Validate the JSON request message

* The TEE validates TSM TAM message authenticity

* Decrypt to get request content

* Lookup Look up the SD and the TA with the given SD name and TA ID

* Checks that the TSM TAM owns the SD, and TA is installed in the SD

* Checks that the DSI hash matches that and the the device state
hasn't changed

2. Deletion action

* If all the above validation points pass, the TEE deletes the
TA from the SD

* The TEE may SHOULD also delete all personalization data for the TA

3. Construct DeleteTAResponse message.

If a request is illegitimate or the signature doesn't pass, a
"status" property in the response will indicate the error code and
cause.

8.3.3.3.

9.3.3.3. DeleteTAResponse Message

The response message for a DeleteTARequest contains the following
content.

{
"DeleteTATBSResponse": {
"ver": "1.0",
"status": "<operation result>",
"rid": "<the request ID received>",
"tid": "<the transaction ID received>",
"content": ENCRYPTED {
"reason":"<failure
"reason": "<failure reason detail>", // optional
"did": "<the device id hash>",
"dsi": "<Updated TEE state, including all SD owned by
this TSM>" TAM>"
}
}
}

In the response message, the following fields MUST be supplied.

did - the SHA256 hash of the device TEE certificate. This shows
the device ID explicitly to the receiving TSM. TAM.

The final message DeleteTAResponse looks like the following.

{
"DeleteTAResponse": {
"payload":"<DeleteTATBSResponse
"payload": "<DeleteTATBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by TEE device
private key (BASE64URL)>"
}
}

A response message type "status" will be returned when the TEE totally fails
to respond. The OTrP Agent is responsible to create this message.

{
"status": {
"result": "fail",
"error-code": "ERR_TEE_UNKNOWN", "ERR_AGENT_TEE_FAIL",
"error-message": "TEE fails to respond"
}
}

8.3.3.4.

9.3.3.4. Error Conditions

ERR_AGENT_TEE_BUSY

ERR_AGENT_TEE_FAIL

ERR_AGENT_TEE_UNKNOWN

ERR_REQUEST_INVALID

ERR_UNSUPPORTED_MSG_VERSION

ERR_UNSUPPORTED_CRYPTO_ALG

ERR_DEV_STATE_MISMATCH

ERR_SD_NOT_FOUND

ERR_TA_NOT_FOUND

ERR_TEE_FAIL

ERR_TEE_UNKNOWN

ERR_TSM_NOT_AUTHORIZED

ERR_TSM_NOT_TRUSTED

ERR_TAM_NOT_AUTHORIZED

ERR_TAM_NOT_TRUSTED

10. Response Messages a TSM TAM May Expect

A TSM TAM expects some feedback from a remote device when a request
message is delivered to a device. The following three types of
responses SHOULD be supplied.

Type 1: Expect a valid TEE generated TEE-generated response message

A valid TEE signed response may contain errors detected by a TEE,
e.g. TSM a TAM is trusted but TSM supplied some TAM-supplied data is missing, for
example, SP ID doesn't exist. TEE MUST be able to sign and
encrypt.

If a TEE isn't able to sign a response, the TEE should returns an error
to the OTrP Agent without giving any other internal information.
The OTrP Agent will be generating the response.

Type 2: The OTrP Agent generated error message when TEE fails.
OTrP Agent errors will be defined in this document.

A Type 2 message has the following format.

{
"OTrPAgentError": {
"ver": "1.0",
"rid": "",
"tid": "",
"errcode": "ERR_TEE_FAIL "ERR_AGENT_TEE_UNKNOWN | ERR_TEE_BUSY" ERR_AGENT_TEE_BUSY"
}
}

Type 3: OTrP Agent itself isn't reachable or fails. A Client
Application is responsible to handle error and response TSM respond the TAM in
its own way. This is out of scope for this specification.

10.

11. Basic Protocol Profile

This section describes a baseline for interoperability among the
protocol entities, mainly, the TSM TAM and TEE.

A TEE MUST support RSA algorithms. It is optional to support ECC
algorithms. A TSM should TAM SHOULD use a RSA certificate for TSM TAM message
signing. It may use an ECC certificate if it detects that the TEE
supports ECC. ECC according to the field "supportedsigalgs" in a TEE
response.

A TSM TAM MUST support both RSA 2048-bit algorithm and ECC P-256
algorithms. With this, a TEE and TFW certificate can be either RSA
or ECC type.

JSON signing algorithms

o RSA PKCS#1 with SHA256 signing : "RS256"

o ECDSA with SHA256 signing : "ES256"

JSON asymmetric encryption algorithms (describes key-exchange or key-
agreement algorithm for sharing symmetric key with TEE):

o RSA PKCS#1 : "RSA1_5"

o ECDH using TEE ECC P-256 key and ephemeral ECC key generated by
TSM
TAM : "ECDH-ES+A128W"

JSON symmetric encryption algorithms (describes symmetric algorithm
for encrypting body of data, using symmetric key transferred to TEE
using asymmetric encryption):

o Authenticated encryption AES 128 CBC with SHA256 :
{"enc":"A128CBC-HS256"}

11.

12. Attestation Implementation Consideration

It is important to know that the state of a device is appropriate
before trusting that a device is what it says it is. The attestation
scheme for OTrP must also be able to cope with different TEEs,
including those that are OTrP compliant and those that use another
mechanism. In the initial version, only one active TEE is assumed.

It is out of scope about how TSM the TAM and the device implement the trust
hierarchy verification. However, it is helpful to understand what
each system provider should do in order to properly implement an OTrP
trust hierarchy.

In this section, we provide some implementation reference
consideration.

11.1.

12.1. OTrP Secure Boot Module

11.1.1.

12.1.1. Attestation signer

It is proposed that attestation for OTrP is based on the SBM secure
boot layer, and that further attestation is not performed within the
TEE itself during security domain Security Domain operations. The rationale is that
the device boot process will be defined to start with a secure boot
approach that, using eFuse, only releases attestation signing
capabilities into the SBM once a secure boot has been established.
In this way the release of the attestation signer can be considered
the first "platform configuration metric", using TCG Trust Computing
Group (TCG) terminology.

11.1.2.

12.1.2. SBM Initial Requirements

R1 The SBM must be possible to load securely into the secure boot
flow

R2 The SBM must allow a public / private key pair to be generated
during device manufacture

R3 The public key and certificate must be possible to store securely
from tamper

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
decrypted

R6 The SBM must be able to read a list of root and intermediate
certificates that it can use to check certificate chains with.
The list must be stored such that it cannot be tampered with

R7 Possible need Need to allow a TEE to access its unique TEE specific private key

11.2.

12.2. TEE Loading

During boot boot, the SBM is required to start all of the ROOT root TEEs.
Before loading them them, the SBM must first determine whether the code
sign signature of the TEE is valid. If TEE integrity is confirmed it confirmed,
the TEE may be started. The SBM must then be able to receive the
identity certificate from the TEE (if that TEE is OTrP compliant).
The identity certificate and keys will need to be baked into the TEE
image, and therefore also covered by the code signer hash during the
manufacture
manufacturing process. The private key for the identity certificate
must be securely protected. The private key for a TEE identity must
never be released no matter how the public key and certificate are
released to the SBM.

Once the SBM has successfully booted a TEE and retrieved the identity
certificate it
certificate, the SBM will commit this to the platform configuration
register (PCR) set, for later use during attestation. As a minimum At minimum,
the following data must be committed to the PCR for each TEE:

1. Public key and certificate for the TEE

2. TEE reference identifier that can be used later by a TSM TAM to identify this
TEE

11.3.

12.3. Attestation Hierarchy

The attestation hierarchy and seed required for TSM TAM protocol
operation must be built into the device at manufacture. Additional
TEEs can be added post manufacture post-manufacture using the scheme proposed however proposed, but it
is outside of the current scope of this document to detail that.

It should be noted that the attestation scheme described is based on
signatures. The only encryption that takes place is with eFuse to
release the SBM signing key and later during the protocol lifecycle
management interchange with the TSM.

11.3.1. TAM.

12.3.1. Attestation Hierarchy Establishment: Manufacture

During manufacture the following steps are required:

1. Device specific A device-specific TFW key pair and certificate are burnt into the
device, encrypted by eFuse. This key pair will be used for
signing operations performed by the SBM.

2. TEE images are loaded and include a TEE instance specific instance-specific key
pair and certificate. The key pair and certificate are included
in the image and covered by the code signing hash.

3. The process for TEE images is repeated for any subordinate TEEs,
which are additional TEEs

11.3.2. after the root TEE that some devices
have.

12.3.2. Attestation Hierarchy Establishment: Device Boot

During device boot the following steps are required:

1. Secure boot releases the TFW private key by decrypting it with
eFuse

2. The SBM verifies the code-signing signature of the active TEE and
places its TEE public key into a signing buffer, along with their
reference its
identifier for later access. For a non-OTrP TEE, the SBM leaves
the TEE public key field blank.

3. The SBM signs the signing buffer with the TFW private key key.

4. Each active TEE performs the same operation as the SBM, building
up their own signed buffer containing subordinate TEE
information.

11.3.3.

12.3.3. Attestation Hierarchy Establishment: TSM TAM

Before a TSM TAM can begin operation in the marketplace to support
devices of a given TEE, it must obtain a
TSM key pair and TAM certificate (TSMpub, TSMpriv) from a CA
that is registered in the trust store of the devices with that TEE. In
this way, the TEE can check the intermediate and root CA and verify
that it trusts this TSM TAM to perform operations on the TEE.

12.

13. Acknowledgements

We thank Alin Mutu for his contribution to many discussion that
helped to design the trust flow mechanisms, and the creation of the
flow diagrams. We also thank the following people (by (in alphabetical
order) for their input and review: Sangsu Baek, Marc Canel, Roger
Casals, Rob Coombs, Lubna Dajani, Richard Parris, Dave Thaler, and
Pengfei Zhao.

13.

14. Contributors

Brian Witten
Symantec
900 Corporate Pointe
Culver City, CA 90230
USA

Email: brian_witten@symantec.com

Tyler Kim
Solacia
5F, Daerung Post Tower 2, 306 Digital-ro
Seoul 152-790
Korea

Email: tkkim@sola-cia.com

14.

15. IANA Considerations

The error code listed in the next section will be registered.

14.1.

15.1. Error Code List

This section lists error codes that could be reported by a TA or TEE
in a device in responding to a TSM request. TAM request, and a separate list that
OTrP Agent may return when the TEE fails to respond.

15.1.1. TEE Signed Error Code List

ERR_DEV_STATE_MISMATCH - A TEE will return this error code if the
DSI hash value from TSM TAM doesn't match with that the has value of the device's
current DSI.

ERR_SD_ALREADY_EXIST

ERR_SD_ALREADY_EXISTS - This error will occur if an SD to be created
already exist exists in the TEE.

ERR_SD_NOT_EMPTY - This is reported if a target SD isn't empty.

ERR_SDNAME_ALREADY_USED A TEE will return this error code if the new
SD name already exists in the namespace of TSM in the TEE.

ERR_REQUEST_INVALID - This error will occur if the TEE meets any of
the following conditions with a request message: (1) The request
from a
TSM TAM has an invalid message structure; mandatory information
is absent in the message. undefined member or structure is
included. (2) TEE fails to verify signature of the message or
fails to decrypt its contents. (3) etc.

ERR_SPCERT_INVALID - If a new SP certificate for the SD to be
updated is not valid, then the TEE will return this error code.

ERR_TA_ALREADY_INSTALLED - while While installing a TA, a TEE will return
this error if the TA already has already been installed in the SD.

ERR_TA_INVALID - This error will occur when a TEE meets any of
following conditions while checking validity of TA: (1) The TA
binary has a format that the TEE can't recognize. (2) The TEE fails
to decrypt the encoding of the TA binary and personalization data.
(3) If an SP isn't registered with the SP SD where the TA will be
installed. (4) etc.

ERR_TA_NOT_FOUND - This error will occurs occur when the target TA doesn't
exist in the SD.

ERR_TEE_BUSY - The device TEE is busy. The request should be
generally sent later to retry.

ERR_TEE_FAIL - TEE fails to respond to a TSM request. The OTrP
Agent will construct an error message in responding If the TSM's
request. And also if TEE fails to process a request because of its an
internal error, it will return this error code.

ERR_TEE_RESOURCE_FULL - This error is reported when a device
resource isn't available anymore such as storage space is full.

ERR_TEE_UNKNOWN - This error will occur if the receiver TEE is not
supposed to receive the request. That will be determined by
checking TEE name or device id in the request message.

ERR_TFW_NOT_TRUSTED - A TEE may concern is responsible for determining that the
underlying device firmware is trustworthy. If the TEE determines
the TFW is not trustworthy, then this error will occur.

ERR_TSM_NOT_TRUSTED

ERR_TAM_NOT_TRUSTED - Before processing a request, a TEE needs to
make sure whether the sender TSM TAM is trustworthy by checking the
validity of TSM certificate the TAM certificate, etc. If the TEE finds TSM that the
TAM is not reliable, trustworthy, then it will return this error code.

ERR_UNSUPPORTED_CRYPTO_ALG - This error will occur if a TEE receives
a request message encoded with cryptographic algorithms that the
TEE doesn't support.

ERR_UNSUPPORTED_MSG_VERSION - This error will occur if a TEE
receives
the version of a message version that the TEE can't deal with.

15.

15.1.2. OTrP Agent Error Code List

ERR_AGENT_TEE_UNKNOWN - This error will occur if the receiver TEE is
not supposed to receive the request. That will be determined by
checking the TEE name or device id in the request message.

ERR_AGENT_TEE_BUSY - The device TEE is busy. The request can be
generally sent again to retry.

ERR_AGENT_TEE_FAIL - The TEE fails to respond to a TAM request. The
OTrP Agent will construct an error message in responding to the
TAM's request.

16. Security Consideration
15.1.

16.1. Cryptographic Strength

The strength of the cryptographic algorithms, using the measure of
'bits of security' defined in NIST SP800-57 allowed for the OTrP
protocol is:

o At a minimum, 112 bits of security. The limiting factor for this
is the RSA-2048 algorithm, which is indicated as providing 112
bits of symmetric key strength in SP800-57. It is important that
RSA is supported in order to enhance the interoperability of the
protocol.

o The option exists to choose algorithms providing 128 bits of
security. This requires using TEE devices that support ECC P256.

The available algorithms and key sizes specified in this document are
based on industry standards. Over time the recommended or allowed
cryptographic algorithms may change. It is important that the OTrP
protocol
allows for crypto-agility.

15.2. In this specification, TAM and TEE can
negotiate an agreed upon algorithm where both include their supported
algorithm in OTrP message.

16.2. Message Security

OTrP messages between the TSM TAM and TEE are protected by message
security using JWS and JWE. The 'Basic protocol profile' section of
this document describes the algorithms used for this. All OTrP TEE
devices and OTrP TSMs TAMs must meet the requirements of the basic
profile. In the future additional 'profiles' can be added.

PKI is used to ensure that the TEE will only communicate with a
trusted TSM, TAM, and to ensure that the TSM TAM will only communicate with a
trusted TEE.

15.3.

16.3. TEE Attestation

It is important that the TSM TAM can trust that it is talking to a
trusted TEE. This is achieved through attestation. The TEE has a
private key and certificate built into it at manufacture, which is
used to sign data supplied by the TSM. TAM. This allows the TSM TAM to verify
that the TEE is trusted.

It is also important that the TFW (trusted firmware) can be checked.
The TFW has a private key and certificate built into it at
manufacturer,
manufacture, which allows the TEE to check that that the TFW is
trusted.

The GetDeviceState message therefore allows the TSM TAM to check that it
trusts the TEE, and the TEE at this point will check whether it
trusts the TFW.

15.4.

16.4. TA Protection

A TA will be delivered in an encrypted form. This encryption is an
additional layer within the message encryption described in the
'Basic protocol profile' section
Section 11 of this document. The TA binary is encrypted for each
target device with the device's TEE SP AIK public key. A TSM may TAM can
either do this encryption itself or provides provide the TEE SP AIK public key
to a an SP such that the SP encrypts the encrypted TA to TSM for distribution
to the TEE.

The encryption algorithm can use a randomly random AES 256 key "taek" with a
16 byte random IV, and the "taek" is encrypted by the "TEE SP AIK
public key". The following encrypted TA data structure is expected
by a TEE:

"encrypted_ta_bin": {
"key": "<A "<JWE enveloped data of a 256-bit symmetric key encrypted by TEE SP AIK
the recipient's TEEspaik public key>",
"iv": <hex of 16 random bytes>",
"alg": "AESCBC",
"cipherdata": "<BASE64 encoded encrypted TA binary data>"
}

15.5.

16.5. TA Personalization Data

An SP or TSM TAM can supply personalization data for a TA to initialize
for a device. Such data is passed through an InstallTA command from
TSM.
a TAM. The personalization data itself is (or can be) opaque to the
TSM.
TAM. The data can be from the SP without being revealed to the TSM. TAM.
The data is sent in an encrypted manner in a request to a device such
that only the device can decrypt. A device's TEE SP AIK public key
for a an SP is used to encrypt the data. Here JWE enveloping is used
to carry all encryption key parameters along with encrypted data.

"encrypted_ta_data": { // "TA personalization data"
"key": "<A "<JWE enveloped data of a 256-bit symmetric key encrypted by TEE SP AIK
the recipient's TEEspaik public key>",
"iv": "<hex of 16 random bytes>",
"alg": "AESCBC",
"cipherdata": "<BASE64 encoded encrypted TA personalization
data>"
}

15.6.

16.6. TA Trust Check at TEE

A TA binary is signed by a TA signer certificate. This TA signing
certificate/private key belongs to the SP, and may be self-signed
(i.e.
(i.e., it need not participate in a trust hierarchy). It is the
responsibility of the TSM TAM to only allow verified TAs from trusted SPs
into the system. Delivery of that TA to the TEE is then the
responsibility of the TEE, using the security mechanisms provided by
the OTrP protocol. OTrP.

We allow a way for an (untrusted) application to check trustworthy the
trustworthiness of a TA. OTrP Agent will have has a function to allow an
application to query the metadata
of information about a TA.

An application in the Rich O/S may perform verification of the TA by
verifying the signature of the TA. The
OTRPService.getTAInformation() GetTAInformation function is
available to return the TEE supplied TA signer and TSM TAM signer
information to the application. An application can do additional
trust check checks on the certificate returned for this TA. It may might trust TSM,
the TAM, or require additional SP signer trust chaining.

15.7.

16.7. One TA Multiple SP Case

A TA for different SP multiple SPs must have a different identifier. identifier per SP. A TA
will be installed in a different SD for the each respective SP.

15.8.

16.8. OTrP Agent Trust Model

An OTrP Agent could be malware in the vulnerable Android Rich OS. A Client
Application will connect its TSM TAM provider for required TA
installation. It gets command messages from TSM, the TAM, and passes the
message to the OTrP Agent.

The OTrP protocol is a conduit for enabling the TSM TAM to communicate with the
device's TEE to manage SDs and TAs. All TSM TAM messages are signed and
sensitive data is encrypted such that the OTrP Agent cannot modify or
capture sensitive data.

15.9.

16.9. OCSP Stapling Data for TSM TAM Signed Messages

The GetDeviceStateRequest message from TSM a TAM to a TEE shall include
OCSP stapling data for the TSM's TAM's signer certificate and that for
intermediate CA certificates up to the root certificate so that the
TEE side can verify the signer certificate's revocation status.

Certificate

A certificate revocation status check on a TA signer certificate is
optional
OPTIONAL by a TEE. A TSM TAM is generally expected to do proper TA
application responsible for vetting a TA and its the SP signer trust validation.
before it distributes them to devices. A TEE will trust a TA signer
certificate's validation status done by a TSM TAM when it trusts the TSM.

15.10. TAM.

16.10. Data Protection at TSM TAM and TEE

The TEE implementation provides protection of data on the device. It
is the responsibility of the TSM TAM to protect data on its servers.

15.11.

16.11. Privacy Consideration

Devices are issued with a unique TEE certificate to attest a device the
device's validity. This uniqueness also creates a privacy and
tracking risk that must be mitigated.

The TEE will only release the TEE certificate to a trusted TSM TAM (it
must verify the TSM TAM certificate before proceeding). The OTrP
protocol is designed
such that only the TSM a TAM can obtain the TEE device certificate and
firmware certificate - the GetDeviceState message requires signature
checks to validate the TSM TAM is trusted, and then OTrP delivers the device's
certificate(s) encrypted such that only that
TSM may TAM can decrypt the
response. A Client Application will never see the device
certificate.

A SP specific

An SP-specific TEE SP AIK (TEE SP Anonymous Key) is generated by the
protocol for Client Applications. This provides a way for the Client
Application to validate some data sent from that the TEE may send without
requiring the TEE device certificate to be released to the client
device rich O/S , and to optionally allow an SP to encrypt a TA for a
target device without the SP needing to be supplied with the TEE
device certificate.

15.12.

16.12. Threat Mitigation

A rogue application may perform excessive TA loading. An OTrP Agent
implementation should protect against excessive calls.

Rogue applications may might request excessive SD creation request. creation. The
TSM TAM is
responsible to ensure this is properly guarded against.

Rogue OTrP Agent could replay or send TSM TAM messages out of
sequence:e.g. TSM sequence:
e.g., a TAM sends update1 and update2. The OTrP Agent replays
update2 and update1 again, create creating an unexpected result that a
client wants. "dsihash" is used to mitigate this. The TEE MUST make sure
it stores store
DSI state and checks check that the DSI state matches before it does another
update.

Concurrent calls from TSM a TAM to a TEE should MUST be handled properly by a
TEE.
It is up to the device to manage concurrency to the TEE. If multiple concurrent TSM TAM operations take place place, these could
fail due to the "dsihash" being modified by another concurrent
operation. If locking The TEE is
implemented on the client, this must be done in responsible for resolve any locking such a way that
one application cannot lock other applications from using the TEE,
except for a short term duration of the TSM TAM operation taking place.
For example, an OTrP operation that starts but never completes (e.g.
loss of connectivity) must not prevent subsequent OTrP messages from
being executed.

15.13.

16.13. Compromised CA

If a

A root CA for TSM TAM certificates is found compromised, some might get compromised. Some TEE trust
anchor update mechanism should be devised. is expected from device OEM. A compromised
intermediate CA is covered by OCSP stapling and OCSP validation check
in the protocol. A TEE should validate certificate revocation about
a TSM TAM certificate chain.

If the root CA of some TEE device certificates is compromised, these
devices might be rejected by TSM, a TAM, which is a decision of TSM the TAM
implementation and policy choice. Any intermediate CA for TEE device
certificates should SHOULD be validated by TSM TAM with common CRL a Certificate Revocation
List (CRL) or OCSP Online Certificate Status Protocol (OCSP) method.

15.14.

16.14. Compromised TSM TAM

The TEE should SHOULD use validation of the supplied TSM TAM certificates and
OCSP stapled data to validate that the TSM TAM is trustworthy.

Since PKI is used, the integrity of the clock within the TEE
determines the ability of the TEE to reject an expired TSM TAM
certificate, or revoked TSM TAM certificate. Since OCSP stapling
includes signature generation time, certificate validity dates are
compared to the current time.

15.15.

16.15. Certificate Renewal

TFW and TEE device certificates are expected to be long lived, longer
than the lifetime of a device. A TSM TAM certificate usually has a
moderate lifetime of 2 to 5 years. TSM A TAM should get renewed or
rekeyed
certificates.The certificates. The root CA certificates for TSM, a TAM, which is are
embedded into the trust anchor store in a device, should have long lifetime
lifetimes that don't require device trust anchor update. On the
other hand, it is imperative that OEM OEMs or device providers plan for
support of trust anchor update in their shipped devices.

16.

17. References

16.1.

17.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.

[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.

[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, <https://www.rfc-
editor.org/info/rfc7517>.

[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, <https://www.rfc-
editor.org/info/rfc7518>.

16.2.

17.2. Informative References

[GPTEE] Global Platform, "Global Platform, GlobalPlatform Device
Technology: TEE System Architecture, v1.0", 2013.

[GPTEECLAPI]
Global Platform, "Global Platform, GlobalPlatform Device
Technology: TEE Client API Specification, v1.0", 2013.

Appendix A. Sample Messages

A.1. Sample Security Domain Management Messages

A.1.1. Sample GetDeviceState

A.1.1.1. Sample GetDeviceStateRequest

TSM

The TAM builds a "GetDeviceStateTBSRequest" message.

{
"GetDeviceStateTBSRequest": {
"ver": "1.0",
"rid": "8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B",
"tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
"ocspdat": "c2FtcGxlIG9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==",
"icaocspdat": "c2FtcGxlIGljYW9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==",
"supportedsigalgs": "RS256"
}
}
TSM

The TAM signs "GetDeviceStateTBSRequest", creating
"GetDeviceStateRequest"

{
"GetDeviceStateRequest": {
"payload":"
ewoJIkdldERldmljZVN0YXRlVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJ
InJpZCI6IHs4QzZGOURCQi1GQzM5LTQzNWMtQkM4OS00RDM2MTREQTJGMEJ9LAoJCSJ0
aWQiOiAiezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0iLAoJCSJv
Y3NwZGF0IjogImMyRnRjR3hsSUc5amMzQmtZWFFnUWpZMElHVnVZMjlrWldRZ1FWTk9N
UT09IiwKCQkiaWNhb2NzcGRhdCI6ICJjMkZ0Y0d4bElHbGpZVzlqYzNCa1lYUWdRalkw
SUdWdVkyOWtaV1FnUVZOT01RPT0iLAoJCSJzdXBwb3J0ZWRzaWdhbGdzIjogIlJTMjU2
IgoJfQp9",
"protected": "eyJhbGciOiJSUzI1NiJ9",
"header": {
"x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==",
"ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"]
},
"signature":"c2FtcGxlIHNpZ25hdHVyZQ"
}
}

A.1.1.2. Sample GetDeviceStateResponse

TSM

The TAM sends "GetDeviceStateRequest" to the OTrP Agent
The OTrP Agent obtains "dsi" from each TEE. (in (In this example there
is a single TEE). TEE.)

The TEE obtains signed "fwdata" from firmware firmware.

The TEE builds "dsi" - summarizing device state of TEE the TEE.

{
"dsi": {
"tfwdata": {
"tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=",
"cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==",
"sigalg": "RS256",
"sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ=="
},
"tee": {
"name": "Primary TEE",
"ver": "1.0",
"cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==",
"cacert": [
"c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=",
"c2FtcGxlIENBIGNlcnRpZmljYXRlIDI="
],
"sdlist": {
"cnt": "1",
"sd": [
{
"name": "default.acmebank.com",
"spid": "acmebank.com",
"talist": [
{
"taid": "acmebank.secure.banking",
"taname": "Acme secure banking app"
},
{
"taid": "acmebank.loyalty.rewards",
"taname": "Acme loyalty rewards app"
}
]
}
]
},
"teeaiklist": [
{
"spaik": "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=",
"spaiktype": "RSA",
"spid": "acmebank.com"
}
]
}
}
}

The TEE encrypts "dsi", and embeds it into a
"GetDeviceTEEStateTBSResponse"
message message.

{
"GetDeviceTEEStateTBSResponse": {
"ver": "1.0",
"status": "pass",
"rid": "{8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B}",
"tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
"signerreq":"false",
"edsi": {
"protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K",
"recipients": [
{
"header": {
"alg": "RSA1_5"
},
"encrypted_key":
"
QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg
a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw"
}
],
"iv": "ySGmfZ69YlcEilNr5_SGbA",
"ciphertext":
"
c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW
NpcGllbnRzLmVuY3J5cHRlZF9rZXk",
"tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw"
}
}
}

The TEE signs "GetDeviceTEEStateTBSResponse" and returns it to the
OTrP Agent. The OTrP Agent encodes "GetDeviceTEEStateResponse" into
an array to form
"GetDeviceStateResponse" "GetDeviceStateResponse".

{
"GetDeviceStateResponse": [
{
"GetDeviceTEEStateResponse": {
"payload":
"
ewogICJHZXREZXZpY2VURUVTdGF0ZVRCU1Jlc3BvbnNlIjogewogICAgInZlciI6
ICIxLjAiLAogICAgInN0YXR1cyI6ICJwYXNzIiwKICAgICJyaWQiOiAiezhDNkY5
REJCLUZDMzktNDM1Yy1CQzg5LTREMzYxNERBMkYwQn0iLAogICAgInRpZCI6ICJ7
NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkic2lnbmVy
cmVxIjoiZmFsc2UiLAogICAgImVkc2kiOiB7CiAgICAgICJwcm90ZWN0ZWQiOiAi
ZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAogICAgICAicmVjaXBp
ZW50cyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaGVhZGVyIjogewogICAgICAg
ICAgImFsZyI6ICJSU0ExXzUiCiAgICAgICAgfSwKICAgICAgICAiZW5jcnlwdGVk
X2tleSI6CiAgICAgICAgIgogICAgICAgIFFVVlRNVEk0SUNoRFJVc3BJR3RsZVN3
Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWcKICAgICAg
ICBhMlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgogICAgICAgIH0K
ICAgICAgXSwKICAgICAgIml2IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAog
ICAgICAiY2lwaGVydGV4dCI6CiAgICAgICIKICAgICAgYzJGdGNHeGxJR1J6YVNC
a1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2YlNC
eVpXCiAgICAgIE5wY0dsbGJuUnpMbVZ1WTNKNWNIUmxaRjlyWlhrIiwKICAgICAg
InRhZyI6ICJjMkZ0Y0d4bElHRjFkR2hsYm5ScFkyRjBhVzl1SUhSaFp3IgogICAg
fQogIH0KfQ",
"protected": "eyJhbGciOiJSUzI1NiJ9",
"signature": "c2FtcGxlIHNpZ25hdHVyZQ"
}
}
]
}

The TEE returns "GetDeviceStateResponse" back to the OTrP Agent,
which returns message back to TSM. the TAM.

A.1.2. Sample CreateSD

A.1.2.1. Sample CreateSDRequest
{
"CreateSDTBSRequest": {
"ver":"1.0",
"rid":"req-01",
"tid":"tran-01",
"tee":"SecuriTEE",
"nextdsi":"false",
"dsihash":"Iu-c0-fGrpMmzbbtiWI1U8u7wMJE7IK8wkJpsVuf2js",
"content":{
"spid":"bank.com",
"sdname":"sd.bank.com",
"spcert":"MIIDFjCCAn-
gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAktSMQ4wD
gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4wD
AYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2xhY2l
hMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhcNMTUwN
zAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAwGA1UECAw
FU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNpYTEQMA4GA
1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0GCSqGSIb3DQE
BAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0hCWJRaFzt5mU-
lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE--
3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_dca
d2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUjEOMA
wGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNp
YTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tggkAiTRNq3
S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BAwwCgYIKwYB
BQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ-
LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa-
GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1QV
THILI6afLCRWXXclc1L5KGY290OwIdQ",
"tsmid":"tsm_x.acme.com",
"tamid":"TAM_x.acme.com",
"did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM"
}
}
}

Here

Below is a sample message after the content is encrypted and encoded

{
"CreateSDRequest": {
"payload":"
eyJDcmVhdGVTRFRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTAxIiwidG
lkIjoidHJhbi0wMSIsInRlZSI6IlNlY3VyaVRFRSIsIm5leHRkc2kiOiJmYWxzZSIsImRz
aWhhc2giOiIyMmVmOWNkM2U3YzZhZTkzMjZjZGI2ZWQ4OTYyMzU1M2NiYmJjMGMyNDRlYz
gyYmNjMjQyNjliMTViOWZkYTNiIiwiY29udGVudCI6eyJwcm90ZWN0ZWQiOiJlLUtBbkdW
dVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJyZWNpcGllbnRzIjpbey
JoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJTUzE2NTl4Q2FJ
c1dUeUlsVTZPLUVsZzU4UUhvT1pCekxVRGptVG9vanBaWE54TVpBakRMcWtaSTdEUzhOVG
FIWHcxczFvZjgydVhsM0d6NlVWMkRoZDJ3R2l6Y2VEdGtXc1RwZDg4QVYwaWpEYTNXa3lk
dEpSVmlPOGdkSlEtV29NSUVJRUxzVGthblZCb25wQkF4ZHE0ckVMbl9TZlliaFg4Zm9ub2
gxUVUifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiI1
bmVWZXdndm55UXprR3hZeWw5QlFrZTJVNjVaOHp4NDdlb3NzM3FETy0xY2FfNEpFY3NLcj
ZhNjF5QzBUb0doYnJOQWJXbVRSemMwSXB5bTF0ZjdGemp4UlhBaTZBYnVSM2gzSUpRS1Bj
UUVvRUlkZ2tWX0NaZTM2eTBkVDBpRFBMclg0QzFkb0dmMEdvaWViRC1yVUg1VUtEY3BsTW
9lTjZvUnFyd0dnNUhxLTJXM3B4MUlzY0h4SktRZm11dkYxMTJ4ajBmZFNZX0N2WFE1NTJr
TVRDUW1ZbzRPaGF2R0ZvaG9TZVVnaGZSVG1LYWp3OThkTzdhREdrUEpRUlBtYVVHWllEMW
JXd01nMXFRV3RPd19EZlIyZDNzTzVUN0pQMDJDUFprVXBiQ3dZYVcybW9HN1c2Zlc2U3V5
Q2lpd2pQWmZSQmIzSktTVTFTd1kxYXZvdW02OWctaDB6by12TGZvbHRrWFV2LVdPTXZTY0
JzR25NRzZYZnMzbXlTWnJ1WTNRR09wVVRzdjFCQ0JqSTJpdjkwb2U2aXFCcVpxQVBxbzdi
ajYwVlJGQzZPTlNLZExGQTIyU3pqRHo1dmtnTXNEaHkwSzlDeVhYN1Z6MkNLTXJvQjNiUE
xFZF9abTZuVWlkTFN5cVJ5cXJxTmVnN1lmQng3aV93X0dzRW9rX1VYZXd6RGtneHp6RjZj
XzZ6S0s3UFktVnVmYUo0Z2dHZmlpOHEwMm9RZ1VEZTB2Vm1FWDc0c2VQX2RxakVpZVVOYm
xBZE9sS2dBWlFGdEs4dy1xVUMzSzVGTjRoUG9yeDc2b3lPVUpOQTVFZVV2Qy1jR2tMcTNQ
UG1GRmQyaUtOTElCTEJzVWl6c1h3RERvZVA5SmktWGt5ZEQtREN1SHdpcno0OEdNNWVLSj
Q5WVdqRUtFQko2T01NNUNmZHZ4cDNmVG1uUTdfTXcwZ3FZVDRiOUJJSnBfWjA3TTctNUpE
emg0czhyU3dsQzFXU3V2RmhRWlJCcXJtX2RaUlRIb0VaZldXc1VCSWVNWWdxNG1zb0JqTj
NXSzhnRWYwZGI5a3Z6UG9LYmpJRy10UUE2R2l1X3pHaFVfLXFBV1lLemVKMDZ6djRIWlBO
dHktQXRyTGF0WGhtUTdOQlVrX0hvbjdOUWxhU1g1ZHVNVmN4bGs1ZHVrWFZNMDgxa09wYV
kzbDliQVFfYVhTM0FNaFFTTVVsT3dnTDZJazFPYVpaTGFMLUE3ejlITnlESmFEWTVhakZK
TWFDV1lfOG94YlNoQUktNXA2MmNuT0xzV0dNWWNKTlBGVTZpcWlMR19oc3JfNlNKMURhbD
VtQ0YycnBJLUItMlhuckxZR01ZS0NEZ2V2dGFnbi1DVUV6RURwR3ozQ2VLcWdQU0Vqd3BK
N0M3NXduYTlCSmtTUkpOdDNla3hoWElrcnNEazRHVVpMSDdQYzFYZHdRTXhxdWpzNmxJSV
EycjM1NWEtVkotWHdPcFpfY3RPdW96LTA4WHdYQ3RkTEliSFFVTG40RjlMRTRtanU0dUxS
bjNSc043WWZ1S3dCVmVEZDJ6R3NBY0s5SVlDa3hOaDk3dDluYW1iMDZqSXVoWXF5QkhWRU
9nTkhici1rMDY1bW9OVk5lVVUyMm5OdVNKS0ZxVnIxT0dKNGVfNXkzYkNwTmxTeEFPV1Bn
RnJzU0Flc2JJOWw4eVJtVTAwenJYdGc4OWt5SjlCcXN2eXA1RE8wX2FtS1JyMXB1MVJVWF
lFZzB2ampKS1FSdDVZbXRUNFJzaWpqdGRDWDg3UUxJaUdSY0hDdlJzUzZSdDJESmNYR1ht
UGQyc0ZmNUZyNnJnMkFzX3BmUHN3cnF1WlAxbVFLc3RPMFVkTXpqMTlyb2N1NHVxVXlHUD
lWWU54cHVnWVdNSjRYb1dRelJtWGNTUEJ4VEtnenFPS2s3UnRzWWVMNXl4LVM4NjV0cHVz
dTA0bXpzYUJRZ21od1ZFVXBRdWNrcG1YWkNLNHlJUXktaHNFQUlJSmVxdFB3dVAySXF0X2
I5dlk0bzExeXdzeXhzdmp2RnNKN0VVZU1MaGE2R2dSanBSbnU5RWIzRnlJZ0U5M0VVNEEw
T0lUMWlOSGNRYWc0eWtOc3dPdkxQbjZIZ21zQ05ESlgwekc2RlFDMTZRdjBSQ25SVTdfV2
VvblhSTUZwUzZRZ1JiSk45R1NMckN5bklJSWxUcDBxNHBaS05zM0tqQ2tMUzJrb3Bhd2Y0
WF9BUllmTko3a0s5eW5BR0dCcktnUWJNRWVxUEFmMDBKMlYtVXpuU1JMZmQ4SGs3Y2JEdk
5RQlhHQW9BR0ViaGRwVUc0RXFwMlVyQko3dEtyUUVSRlh4RTVsOFNHY2czQ1RmN2Zoazdx
VEFBVjVsWEFnOUtOUDF1c1ZRZk1fUlBleHFNTG9WQVVKV2syQkF6WF9uSEhkVVhaSVBIOG
hLeDctdEFRV0dTWUd0R2FmanZJZzI2c082TzloQWZVd3BpSV90MzF6SkZORDU0OTZURHBz
QmNnd2dMLU1UcVhCRUJ2NEhvQld5SG1DVjVFMUwiLCJ0YWciOiJkbXlEeWZJVlNJUi1Ren
ExOEgybFRIeEMxbl9HZEtrdnZNMDJUcHdsYzQwIn19fQ",
"protected":"e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", //RSAwithSHA256
"header": {
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
"signer":"
MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA
YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh
cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p
YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy
BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3
c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA
YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR
MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq
hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G
SZ1MdyIZV8fwdEmD90IvtMHgtzK-
9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA
UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
},
"signature":"nuQUsCTEBLeaRzuwd7q1iPIYEJ2eJfurO5sT5Y-
N03zFRcv1jvrqMHtx_pw0Y9YWjmpoWfpfelhwGEko9SgeeBnznmkZbp7kjS6MmX4CKz
9OApe3-VI7yL9Yp0WNdRh3425eYfuapCy3lcXFln5JBAUnU_OzUg3RWxcU_yGnFsw"
}
}

A.1.2.2. Sample CreateSDResponse

{
"CreateSDTBSResponse": {
"ver":"1.0",
"status":"pass",
"rid":"req-01",
"tid":"tran-01",
"content":{
"did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM",
"sdname":"sd.bank.com",
"teespaik":"AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h-
X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9
GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE",
}
}
}

Here

Below is the response message after the content is encrypted and
encoded.

{
"CreateSDResponse": {
"payload":"
eyJDcmVhdGVTRFRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi
LCJyaWQiOiJyZXEtMDEiLCJ0aWQiOiJ0cmFuLTAxIiwiY29udGVudCI6eyJwcm90ZWN0
ZWQiOiJlLUtBbkdWdVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJy
ZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9r
ZXkiOiJOX0I4R3pldUlfN2hwd0wwTFpHSTkxVWVBbmxJRkJfcndmZU1yZERrWnFGak1s
VVhjdlI0XzhhOGhyeFI4SXR3aEtFZnVfRWVLRDBQb0dqQ2pCSHcxdG1ULUN6eWhsbW5v
Slk3LXllWnZzRkRpc2VNTkd0eGE0OGZJYUs2VWx5NUZMYXBCZVc5T1I5bmktOU9GQV9j
aFVuWWl3b2Q4ZTJFa0Vpd0JEZ1EzMk0ifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIz
Um9aUSIsImNpcGhlcnRleHQiOiJsalh6Wk5JTmR1WjFaMXJHVElkTjBiVUp1RDRVV2xT
QVptLWd6YnJINFVDYy1jMEFQenMtMWdWSFk4NTRUR3VMYkdyRmVHcDFqM2Fsb1lacWZp
ZnE4aEt3Ty16RFlBN2tmVFhBZHp6czM4em9xeG4zbHoyM2w1RUlGUWhrOHBRWTRYTHRW
M3ZBQWlNYnlrQ1Q3VS1CWDdWcjBacVNhYWZTQVZ4OFBLQ1RIU3hHN3hHVko0NkxxRzJS
RE54WXQ4RC1SQ3lZUi1zRTM0MUFKZldEc2FLaGRRbzJXcjNVN1hTOWFqaXJtWjdqTlJ4
cVRodHJBRWlIY1ctOEJMdVFHWEZ1YUhLMTZrenJKUGl4d0VXbzJ4cmw4cmkwc3ZRcHpl
Z2M3MEt2Z0I0NUVaNHZiNXR0YlUya25hN185QU1Wcm4wLUJaQ1Bnb280MWlFblhuNVJn
TXY2c2V2Y1JPQ2xHMnpWSjFoRkVLYjk2akEiLCJ0YWciOiIzOTZISTk4Uk1NQnR0eDlo
ZUtsODROaVZLd0lJSzI0UEt2Z1RGYzFrbEJzIn19fQ",
"protected": "e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0",
"header": {
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
"signer":"
MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp
Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN
MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET
MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G
A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA
6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp
Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX
9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E
DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv
em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK-
9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV
rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
},
"signature":"jnJtaB0vFFwrE-qKOR3Pu9pf2gNoI1s67GgPCTq0U-
qrz97svKpuh32WgCP2MWCoQPEswsEX-nxhIx_siTe4zIPO1nBYn-
R7b25rQaF87O8uAOOnBN5Yl2Jk3laIbs-
hGE32aRZDhrVoyEdSvIFrT6AQqD20bIAZGqTR-zA-900"
}
}

A.1.3. Sample UpdateSD
A.1.3.1. Sample UpdateSDRequest

{
"UpdateSDTBSRequest": {
"ver": "1.0",
"rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A",
"tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
"tee": "Primary TEE ABC",
"nextdsi": "false",
"dsihash":
"
IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf
w5o7",
"content": { // NEEDS to BE ENCRYPTED
"tsmid": "id1.tsmxyz.com",
"tamid": "id1.TAMxyz.com",
"spid": "com.acmebank.spid1",
"sdname": "com.acmebank.sdname1",
"changes": {
"newsdname": "com.acmebank.sdname2",
"newspid": "com.acquirer.spid1",
"spcert":
"MIIDFjCCAn-
gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAktSMQ4
gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4
wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2x
hY2lhMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhc
NMTUwNzAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAw
GA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWN
pYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0
GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0
hCWJRaFzt5mU-
lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE--
3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_d
cad2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUj
EOMAwGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU2
9sYWNpYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tgg
kAiTRNq3S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BA
wwCgYIKwYBBQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ-
LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa
-
GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1
QVTHILI6afLCRWXXclc1L5KGY290OwIdQ",
"renewteespaik": "0"
}
}
}
}
A.1.3.2. Sample UpdateSDResponse

{
"UpdateSDTBSResponse": {
"ver": "1.0",
"status": "pass",
"rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A",
"tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
"content": {
"did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=",
"teespaik":
"AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h-
X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9
GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE",
"teespaiktype": "RSA"
}
}
}

A.1.4. Sample DeleteSD

A.1.4.1. Sample DeleteSDRequest

TSM

The TAM builds message - including data to be encrypted.

TSM

The TAM encrypts the "content".

{
"DeleteSDTBSRequest": {
"ver": "1.0",
"rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}",
"tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
"tee": "Primary TEE",
"nextdsi": "false",
"dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=",
"content": {
"protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"recipients": [
{
"header": {
"alg": "RSA1_5"
},
"encrypted_key":
"
QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMga2
V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw"
}
],
"iv": "rWO5DVmQX9ogelMLBIogIA",
"ciphertext":
"
c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZWNp
cGllbnRzLmVuY3J5cHRlZF9rZXk",
"tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw"
}
}
}

TSM

The TAM signs the "DeleteSDTBSRequest" to form a "DeleteSDRequest"
{
"DeleteSDRequest": {
"payload":"
ewoJIkRlbGV0ZVNEVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJInJp
ZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlBNjMtNjYzNDQwQjkxRDQ5fSIsCgkJ
InRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIs
CgkJInRlZSI6ICJQcmltYXJ5IFRFRSIsCgkJIm5leHRkc2kiOiAiZmFsc2UiLAoJ
CSJkc2loYXNoIjogIkFBRUNBd1FGQmdjSUNRb0xEQTBPRHdBQkFnTUVCUVlIQ0Fr
S0N3d05EZzg9IiwKCQkiY29udGVudCI6IHsKCQkJInByb3RlY3RlZCI6ICJleUps
Ym1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wIiwKCQkJInJlY2lwaWVudHMiOiBb
ewoJCQkJImhlYWRlciI6IHsKCQkJCQkiYWxnIjogIlJTQTFfNSIKCQkJCX0sCgkJ
CQkiZW5jcnlwdGVkX2tleSI6ICJRVVZUTVRJNElDaERSVXNwSUd0bGVTd2daVzVq
Y25sd2RHVmtJSGRwZEdnZ1ZGTk5JRkpUUVNCd2RXSnNhV01nYTJWNUxDQjFjMmx1
WnlCU1UwRXhYelVnY0dGa1pHbHVadyIKCQkJfV0sCgkJCSJpdiI6ICJyV081RFZt
UVg5b2dlbE1MQklvZ0lBIiwKCQkJImNpcGhlcnRleHQiOiAiYzJGdGNHeGxJR1J6
YVNCa1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2
YlNCeVpXTnBjR2xsYm5SekxtVnVZM0o1Y0hSbFpGOXJaWGsiLAoJCQkidGFnIjog
ImMyRnRjR3hsSUdGMWRHaGxiblJwWTJGMGFXOXVJSFJoWnciCgkJfQoJfQp9",
"protected":"eyJhbGciOiJSUzI1NiJ9",
"header": {
"x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==",
"ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"]
},
"signature":"c2FtcGxlIHNpZ25hdHVyZQ"
}
}

A.1.4.2. Sample DeleteSDResponse

The TEE creates a "DeleteSDTBSResponse" to respond to the
"DeleteSDRequest" message from the TSM, TAM, including data to be
encrypted.

The TEE encrypts the "content" for the TSM. TAM.

{
"DeleteSDTBSResponse": {
"ver": "1.0",
"status": "pass",
"rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}",
"tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
"content": {
"protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K",
"recipients": [
{
"header": {
"alg": "RSA1_5"
},
"encrypted_key":
"
QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg
a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw"
}
],
"iv": "ySGmfZ69YlcEilNr5_SGbA",
"ciphertext":
"
c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW
NpcGllbnRzLmVuY3J5cHRlZF9rZXk",
"tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw"
}
}
}

The TEE signs "DeleteSDTBSResponse" to form a "DeleteSDResponse"
{
"DeleteSDResponse": {
"payload":"
ewoJIkRlbGV0ZVNEVEJTUmVzcG9uc2UiOiB7CgkJInZlciI6ICIxLjAiLAoJCSJz
dGF0dXMiOiAicGFzcyIsCgkJInJpZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlB
NjMtNjYzNDQwQjkxRDQ5fSIsCgkJInRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3
LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkJImNvbnRlbnQiOiB7CgkJCSJwcm90ZWN0
ZWQiOiAiZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAoJCQkicmVj
aXBpZW50cyI6IFt7CgkJCQkiaGVhZGVyIjogewoJCQkJCSJhbGciOiAiUlNBMV81
IgoJCQkJfSwKCQkJCSJlbmNyeXB0ZWRfa2V5IjogIlFVVlRNVEk0SUNoRFJVc3BJ
R3RsZVN3Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWdh
MlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgoJCQl9XSwKCQkJIml2
IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAoJCQkiY2lwaGVydGV4dCI6ICJj
MkZ0Y0d4bElHUnphU0JrWVhSaElHVnVZM0o1Y0hSbFpDQjNhWFJvSUVGRlV6RXlP
Q0JyWlhrZ1puSnZiU0J5WldOcGNHbGxiblJ6TG1WdVkzSjVjSFJsWkY5clpYayIs
CgkJCSJ0YWciOiAiYzJGdGNHeGxJR0YxZEdobGJuUnBZMkYwYVc5dUlIUmhadyIK
CQl9Cgl9Cn0",
"protected":"eyJhbGciOiJSUzI1NiJ9",
"signature":"c2FtcGxlIHNpZ25hdHVyZQ"
}
}

The TEE returns "DeleteSDResponse" back to the OTrP Agent, which
returns the message back to TSM. the TAM.

A.2. Sample TA Management Messages

A.2.1. Sample InstallTA

A.2.1.1. Sample InstallTARequest
{
"InstallTATBSRequest": {
"ver": "1.0",
"rid": "24BEB059-0AED-42A6-A381-817DFB7A1207",
"tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
"tee": "Primary TEE ABC",
"nextdsi": "true",
"dsihash":
"
IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf
w5o7",
"content": {
"tsmid": "id1.tsmxyz.com",
"tamid": "id1.TAMxyz.com",
"spid": "com.acmebank.spid1",
"sdname": "com.acmebank.sdname1",
"taid": "com.acmebank.taid.banking"
},
"encrypted_ta": {
"key":
"mLBjodcE4j36y64nC/nEs694P3XrLAOokjisXIGfs0H7lOEmT5FtaNDYEMcg9RnE
ftlJGHO7N0lgcNcjoXBmeuY9VI8xzrsZM9gzH6VBKtVONSx0aw5IAFkNcyPZwDdZ
MLwhvrzPJ9Fg+bZtrCoJz18PUz+5aNl/dj8+NM85LCXXcBlZF74btJer1Mw6ffzT
/grPiEQTeJ1nEm9F3tyRsvcTInsnPJ3dEXv7sJXMrhRKAeZsqKzGX4eiZ3rEY+FQ
6nXULC8cAj5XTKpQ/EkZ/iGgS0zcXR7KUJv3wFEmtBtPD/+ze08NILLmxM8olQFj
//Lq0gGtq8vPC8r0oOfmbQ==",
"iv": "4F5472504973426F726E496E32303135",
"alg": "AESCBC",
"ciphertadata":
"......0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk......=",
"cipherpdata": "0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk="
}
}
}

A.2.1.2. Sample InstallTAResponse

A sample to-be-signed response of InstallTA looks as follows.

{
"InstallTATBSResponse": {
"ver": "1.0",
"status": "pass",
"rid": "24BEB059-0AED-42A6-A381-817DFB7A1207",
"tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE",
"content": {
"did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=",
"dsi": {
"tfwdata": {
"tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0="
"cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==",
"sigalg": "UlMyNTY=",
"sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ=="
},
"tee": {
"name": "Primary TEE",
"ver": "1.0",
"cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==",
"cacert": [
"c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=",
"c2FtcGxlIENBIGNlcnRpZmljYXRlIDI="
],
"sdlist": {
"cnt": "1",
"sd": [
{
"name": "com.acmebank.sdname1",
"spid": "com.acmebank.spid1",
"talist": [
{
"taid": "com.acmebank.taid.banking",
"taname": "Acme secure banking app"
},
{
"taid": "acom.acmebank.taid.loyalty.rewards",
"taname": "Acme loyalty rewards app"
}
]
}
]
},
"teeaiklist": [
{
"spaik":
"c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=",
"spaiktype": "RSA"
"spid": "acmebank.com"
}
]
}
}
}
}
}

A.2.2. Sample UpdateTA

A.2.2.1. Sample UpdateTARequest

{
"UpdateTATBSRequest": {
"ver": "1.0",
"rid": "req-2",
"tid": "tran-01",
"tee": "SecuriTEE",
"nextdsi": " false",
"dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U",
"content": {
"tsmid": "tsm1.acme.com",
"tamid": "TAM1.acme.com",
"spid": "bank.com",
"sdname": "sd.bank.com",
"taid": "sd.bank.com.ta"
},
"encrypted_ta": {
"key":
"
XzmAn_RDVk3IozMwNWhiB6fmZlIs1YUvMKlQAv_UDoZ1fvGGsRGo9bT0A440aYMgLt
GilKypoJjCgijdaHgamaJgRSc4Je2otpnEEagsahvDNoarMCC5nGQdkRxW7Vo2NKgL
A892HGeHkJVshYm1cUlFQ-BhiJ4NAykFwlqC_oc",
"iv": "AxY8DCtDaGlsbGljb3RoZQ",
"alg": "AESCBC",
"ciphernewtadata":
"KHqOxGn7ib1F_14PG4_UX9DBjOcWkiAZhVE-U-
67NsKryHGokeWr2spRWfdU2KWaaNncHoYGwEtbCH7XyNbOFh28nzwUmstep4nHWbAl
XZYTNkENcABPpuw_G3I3HADo"
}
}
}

{
"UpdateTARequest": {
"payload" :
"
eyJVcGRhdGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0
aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi
ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu
NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVo
VE1qVTJJbjAiLCJyZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0s
ImVuY3J5cHRlZF9rZXkiOiJYem1Bbl9SRFZrM0lvek13TldoaUI2Zm1abElzMVlVdk1L
bFFBdl9VRG9aMWZ2R0dzUkdvOWJUMEE0NDBhWU1nTHRHaWxLeXBvSmpDZ2lqZGFIZ2Ft
YUpnUlNjNEplMm90cG5FRWFnc2FodkROb2FyTUNDNW5HUWRrUnhXN1ZvMk5LZ0xBODky
SEdlSGtKVnNoWW0xY1VsRlEtQmhpSjROQXlrRndscUNfb2MifV0sIml2IjoiQXhZOERD
dERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiJIYTcwVXRZVEtWQmtXRFJuMi0w
SF9IdkZtazl5SGtoVV91bk1OLWc1T3BqLWF1NGFUb2lxWklMYzVzYTdENnZZSjF6eW04
QW1JOEJIVXFqc2l5Z0tOcC1HdURJUjFzRXc0a2NhMVQ5ZENuU0RydHhSUFhESVdrZmt3
azZlR1NQWiIsInRhZyI6Im9UN01UTE41eWtBTFBoTDR0aUh6T1pPTGVFeU9xZ0NWaEM5
MXpkcldMU0UifSwiZW5jcnlwdGVkX3RhIjp7ImtleSI6Ilh6bUFuX1JEVmszSW96TXdO
V2hpQjZmbVpsSXMxWVV2TUtsUUF2X1VEb1oxZnZHR3NSR285YlQwQTQ0MGFZTWdMdEdp
bEt5cG9KakNnaWpkYUhnYW1hSmdSU2M0SmUyb3RwbkVFYWdzYWh2RE5vYXJNQ0M1bkdR
ZGtSeFc3Vm8yTktnTEE4OTJIR2VIa0pWc2hZbTFjVWxGUS1CaGlKNE5BeWtGd2xxQ19v
YyIsIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImFsZyI6IkFFU0NCQyIsImNp
cGhlcm5ld3RhZGF0YSI6IktIcU94R243aWIxRl8xNFBHNF9VWDlEQmpPY1draUFaaFZF
LVUtNjdOc0tyeUhHb2tlV3Iyc3BSV2ZkVTJLV2FhTm5jSG9ZR3dFdGJDSDdYeU5iT0Zo
MjhuendVbXN0ZXA0bkhXYkFsWFpZVE5rRU5jQUJQcHV3X0czSTNIQURvIn19fQ",
"protected": " eyJhbGciOiJSUzI1NiJ9",
"header": {
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
"signer":"
MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA
YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh
cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p
YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy
BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3
c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA
YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR
MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq
hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G
SZ1MdyIZV8fwdEmD90IvtMHgtzK-
9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA
UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
},
"signature":"inB1K6G3EAhF-
FbID83UI25R5Ao8MI4qfrbrmf0UQhjM3O7_g3l6XxN_JkHrGQaZr-
myOkGPVM8BzbUZW5GqxNZwFXwMeaoCjDKc4Apv4WZkD1qKJxkg1k5jaUCfJz1Jmw_XtX
6MHhrLh9ov03S9PtuT1VAQ0FVUB3qFIvjSnNU"
}
}

A.2.2.2. Sample UpdateTAResponse
{
"UpdateTATBSResponse": {
"ver": "1.0",
"status": "pass",
"rid": "req-2",
"tid": "tran-01",
"content": {
"did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM"
}
}
}

{
"UpdateTAResponse":{
"payload":"
eyJVcGRhdGVUQVRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi
LCJyaWQiOiJyZXEtMiIsInRpZCI6InRyYW4tMDEiLCJjb250ZW50Ijp7InByb3RlY3Rl
ZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVoVE1qVTJJbjAiLCJyZWNpcGllbnRzIjpb
eyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJFaGUxLUJB
UUdJLTNEMFNHdXFGY01MZDJtd0gxQm1uRndYQWx1M1FxUFVXZ1RRVm55SUowNFc2MnBK
YWVSREFkeTU0R0FSVjBrVzQ0RGw0MkdUUlhqbE1EZ3BYdXdFLWloc1JVV0tNNldCZ2N3
VXVGQTRUR3gwU0I1NTZCdl92dnBNaFdfMXh2c2FHdFBaQmwxTnZjbXNibzBhY3FobXlu
bzBDTmF5SVAtX1UifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhl
cnRleHQiOiJwc2o2dGtyaGJXM0lmVElMeE9GMU5HdFUtcTFmeVBidV9KWk9jbklycWIw
eTNPOHN6OTItaWpWR1ZyRW5WbG1sY1FYeWFNZTNyX1JGdEkwV3B4UmRodyIsInRhZyI6
Ik0zb2dNNk11MVJYMUMybEZvaG5rTkN5b25qNjd2TDNqd2RrZXhFdUlpaTgifX19",
"protected":"eyJhbGciOiJSUzI1NiJ9",
"header": {
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
"signer":"
MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA
YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh
cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p
YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy
BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3
c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA
YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR
MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq
hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G
SZ1MdyIZV8fwdEmD90IvtMHgtzK-
9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA
UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
},
"signature":"
Twajmt_BBLIMcNrDsjqr8lI7O7lEQxXZNhlUOtFkOMMqf37wOPKtp_99LoS82CVmdpCo
PLaws8zzh-SNIQ42-
9GYO8_9BaEGCiCwyl8YgWP9fWNfNv2gR2fl2DK4uknkYu1EMBW4YfP81n_pGpb4Gm-
nMk14grVZygwAPej3ZZk"
}
}
A.2.3. Sample DeleteTA

A.2.3.1. Sample DeleteTARequest

{
"DeleteTATBSRequest": {
"ver": "1.0",
"rid": "req-2",
"tid": "tran-01",
"tee": "SecuriTEE",
"nextdsi": "false",
"dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U",
"content": {
"tsmid": "tsm1.acme.com",
"tamid": "TAM1.acme.com",
"sdname": "sd.bank.com",
"taid": "sd.bank.com.ta"
}
}
}

{
"DeleteTARequest": {
"payload":
"
eyJEZWxldGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0
aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi
ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu
NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0s
InJlY2lwaWVudHMiOlt7ImhlYWRlciI6eyJhbGciOiJSU0ExXzUifSwiZW5jcnlwdGVk
X2tleSI6ImtyaGs0d2dpY0RlX3d0VXQyTW4tSUJsdUtvX0JkeXpNY2p1cVlBenBPYnRS
TG9MZzQ0QkFLN2tRVWE1YTg0TEVJRGEzaHNtWDIxdldNZFJLczN4MTJsOUh5VFdfLUNS
WmZtcUx2bEh1LV9MSVdvc1ZyRTZVMlJqUnRndllVOWliUkVLczkzRDRHWm4xVHFuZG9n
d0tXRF9jdG1nWG1sbzZZVXpCWDZhR1dZMCJ9XSwiaXYiOiJBeFk4REN0RGFHbHNiR2xq
YjNSb1pRIiwiY2lwaGVydGV4dCI6IkhhNzBVdFlUS1ZCa1dEUm4yLTBIX1BGa19yQnpQ
dGJHdzhSNktlMXotdklNeFBSY0Nxa1puZmwyTjRjUTZPSTZCSHZJUUFoM2Jic0l0dHlR
bXhDTE5Nbm8wejBrYm9TdkIyVXlxWExpeGVZIiwidGFnIjoidEtUbFRLdlR2LTRtVVlG
Y1dYWnZMMVlhQnRGNloxVlNxOTMzVmI2UEpmcyJ9fX0",
"protected" : "eyJhbGciOiJSUzI1NiJ9",
"header": {
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
"signer":"
MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA
YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh
cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p
YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy
BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3
c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA
YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw
HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR
MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq
hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G
SZ1MdyIZV8fwdEmD90IvtMHgtzK-
9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA
UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
},
"signature" :
"
BZS0_Ab6pqvGNXe5lqT4Sc3jakyWQeiK9KlVSnimwWnjCCyMtyB9bwvlbILZba3IJiFe
_3F9bIQpSytGS0f2TQrPTKC7pSjwDw-3kH7HkHcPPJd-
PpMMfQvRx7AIV8vBqO9MijIC62iN0V2se5z2v8VFjGSoRGgq225w7FvrnWE"
}
}
A.2.3.2. Sample DeleteTAResponse

{
"DeleteTATBSResponse": {
"ver": "1.0",
"status": "pass",
"rid": "req-2",
"tid": "tran-01",
"content": {
"did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM"
}
}
}

{
"DeleteTAResponse":{
"payload":"
ew0KCSJEZWxldGVUQVRCU1Jlc3BvbnNlIjogew0KCQkidmVyIjogIjEuMCIsDQoJCSJz
dGF0dXMiOiAicGFzcyIsDQoJCSJyaWQiOiAicmVxLTIiLA0KCQkidGlkIjogInRyYW4t
MDEiLA0KCQkiY29udGVudCI6IHsNCgkJCSJwcm90ZWN0ZWQiOnsiZW5jIjoiQTEyOENC
Qy1IUzI1NiJ9LA0KCQkJInJlY2lwaWVudHMiOlsNCgkJCQl7DQoJCQkJCSJoZWFkZXIi
OnsiYWxnIjoiUlNBMV81In0sDQoJCQkJCSJlbmNyeXB0ZWRfa2V5IjoiTXdtU1ZHaWU2
eHpfQmxTaFlmTFRKRHhKT3oyNWhvYy1HZ2NEM2o5OWFyM2E4X2lYY182ZE44bFRTb1dD
X19wZEFhaEMyWk5SakdIcTBCZ2JDYTRKalk0eXRkMVBVWDB6M1psbXl1YnRXM291eEpY
el9PMzg1WGM4S3hySndjbElyZGx2WUY2OVZmeERLQkVzUHJCdzlVenVIa1VmSU4xWlFU
bWZ0QmVaSlJnIg0KCQkJCX0NCgkJCV0sDQoJCQkiaXYiOiJBeFk4REN0RGFHbHNiR2xq
YjNSb1pRIiwNCgkJCSJjaXBoZXJ0ZXh0IjoiamhQTlV5ZkFTel9rVV9GbEM2LUtCME01
WDBHNE5MbHc0LWt0bERyajZTWlUteUp6eUFUbC1oY0ZBWWMwLXJMVEF4cF93N1d1WER0
Y3N3SzJSSzRjcWciLA0KCQkJInRhZyI6IlBBeGo5N25oT29qVTNIREhxSll4MGZMNWpt
b0xkTlJkTHRtSmIzUTdrYXciDQoJCX0NCgl9DQp9",
b0xkTlJkTHRTAMIzUTdrYXciDQoJCX0NCgl9DQp9",
"protected": "eyJhbGciOiJSUzI1NiJ9",
"header": {
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
"signer":"
MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp
Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN
MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET
MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G
A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG-
meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu-
AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA
6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj-
ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp
Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX
9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E
DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv
em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK-
9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV
rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg"
},
"signature":"
DfoBOetNelKsnAe_m4Z9K5UbihgWNYZsp5jVybiI05sOagDzv6R4do9npaAlAvpNK8HJ
CxD6D22J8GDUExlIhSR1aDuDCQm6QzmjdkFdxAz5TRYl6zpPCZqgSToN_g1TZxqxEv6V
Ob5fies4g6MHvCH-Il_-KbHq5YpwGxEEFdg"
}
}
A.3. Example OTrP Agent Option

The most popular TEE devices today are Android powered devices. In
an Android device, an OTrP Agent can be a bound service with a
service registration ID that a Client Application can use. This
option allows a Client Application not to depend on any OTrP Agent
SDK or provider.

Authors' Addresses

Mingliang Pei
Symantec
350 Ellis St
Mountain View, CA 94043
USA

Email: mingliang_pei@symantec.com

Nick Cook
ARM Ltd.
110 Fulbourn Rd
Cambridge, CB1 9NJ
Great Britain

Email: nicholas.cook@arm.com

Minho Yoo
Solacia
5F, Daerung Post Tower 2, 306 Digital-ro
Seoul 152-790
Korea

Email: paromix@sola-cia.com
Andrew Atyeo
Intercede
St. Mary's Road, Lutterworth
Leicestershire, LE17 4PS
Great Britain

Email: andrew.atyeo@intercede.com

Hannes Tschofenig
ARM Ltd.
110 Fulbourn Rd
Cambridge, CB1 9NJ
Great Britain

Email: Hannes.tschofenig@arm.com