| TEEP | M. Pei |
| Internet-Draft | Symantec |
| Intended status: Informational | A. Atyeo |
| Expires: November 16, 2019 | Intercede |
| N. Cook | |
| ARM Ltd. | |
| M. Yoo | |
| IoTrust | |
| H. Tschofenig | |
| ARM Ltd. | |
| May 15, 2019 |
The Open Trust Protocol (OTrP)
draft-ietf-teep-opentrustprotocol-03.txt
This document specifies the Open Trust Protocol (OTrP), a protocol that follows the Trust Execution Environment Provisioning (TEEP) architecture and provides a message protocol that provisions and manages Trusted Applications into a device with a Trusted Execution Environment (TEE).
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 https://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 November 16, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
The Trusted Execution Environment (TEE) concept has been designed to separate a regular operating system, also referred as a Rich Execution Environment (REE), from security-sensitive applications. In an TEE ecosystem, different device vendors may use different TEE implementations. Different application providers or device administrators may choose to use different TAM providers. There calls for an interoperable protocol for managing TAs running in different TEEs of various devices is needed.
The Trusted Execution Environment Provisioning (TEEP) architecture document [TEEPArch] has set to provide a design guidance for such an interoperable protocol. This document specifies an Open Trust Protocol (OTrP) that follows the architecture guidance.
OTrP defines a mutual trust message protocol between a TAM and a TEE and relies on IETF-defined end-to-end security mechanisms, namely JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Key (JWK). Other message encoding methods may be supported.
This specification defines message payloads exchanged between devices and a TAM. The messages are designed in anticipation of the use of the most common transport methods such as HTTPS.
Each TA binary and configuration data can be from either of two sources:
This specification considers the first case where TA binary and configuration data are encrypted by recipient's public key that TAM has to be involved. The second case will also be addressed separately.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The definitions provided below are defined as used in this document. All the terms defined in the TEEP Architecture document [TEEPArch] will be used, which are not repeated in this document.
The same system components as defined in the TEEP Architecture document [TEEPArch] are used in OTrP, including TAM, CA, TEE, REE, and OTrP Broker (a.k.a Broker).
Secure boot (for the purposes of OTrP) is optional in enabling authenticity checking of TEEs by the TAM. A TAM provider can choose it policy whether it trusts a TEE if the underlying firmware attestation information is not included.
OTrP uses trust anchors to establish trust between TEEs and TAMs and verifies that they communicate in a trusted way when performing lifecycle management transactions.
This assumes the Trust Anchor specification defined in the TEEP Architecture document [TEEPArch].
Each TEE comes with a trust store that contains a whitelist of root CA certificates that are used to validate a TAM's certificate. A TEE will accept a TAM to create new Security Domains and install new TAs on behalf of a SP only if the TAM's certificate is chained to one of the root CA certificates in the TEE's trust store.
The Trust Anchor set in a TAM consists of a list of Certificate Authority certificates that signs various device TEE certificates. A TAM decides what TEE and optionally TFW it will trust when TFW signature data is present in an attestation.
OTrP leverages the following list of trust anchors and identities in generating signed and encrypted command messages that are exchanged between a device's TEE and a TAM. With these security artifacts, OTrP Messages are able to deliver end-to-end security without relying on any transport security.
| Key Entity Name | Location | Issuer | Trust Implication | Cardinality |
|---|---|---|---|---|
| 1. TFW key pair and certificate | Device secure storage | FW CA | A whitelist of FW root CA trusted by TAMs | 1 per device |
| 2. TEE key pair and certificate | Device TEE | TEE CA under a root CA | A whitelist of TEE root CA trusted by TAMs | 1 per device |
| 3. TAM key pair and certificate | TAM provider | TAM CA under a root CA | A whitelist of TAM root CA embedded in TEE | 1 or multiple can be used by a TAM |
| 4. SP key pair and certificate | SP | SP signer CA | TAM manages SP. TA trust is delegated to TAM. TEE trusts TAM to ensure that a TA is trustworthy. | 1 or multiple can be used by a TAM |
This document specifies messages and key properties that can establish mutual trust between a TEE and a TAM. The protocol provides specifications for the following three entities:
Figure 1: Protocol Scope and Entity Relationship
PKI CA -- CA CA --
| | |
| | |
| | |
Device | | --- OTrP Broker / Client App --- |
SW | | | | |
| | | | |
| | | | |
OTrP | -- TEE TAM-------
|
|
FW
Figure 2: OTrP System Diagram
-------OTrP Message Protocol---
| |
| |
-------------------- --------------- ----------
| REE | TEE | | TAM | | SP |
| --- | --- | | --- | | -- |
| | | | | | |
| Client | SD (TAs)| | SD / TA | | TA |
| Apps | | | Mgmt | | |
| | | | | | | |
| | | List of | | List of | | |
| OTrP | Trusted | | Trusted | | |
| Broker | TAM/SP | | FW/TEE | | |
| | CAs | | CAs | | |
| | | | | | |
| |TEE Key/ | | 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 such as a FW's private key, a TEE's private key, or a TAM's private key.
The main OTrP component consists of a set of standard JSON messages created by a TAM to deliver device SD and TA management commands to a device, and device attestation and response messages created by a TEE that responds to a TAM's OTrP message.
The communication method of OTrP Messages between a TAM and TEE in a device may vary between TAM and TEE providers. A mandatory transport protocol is specified for a compliant TAM and a device TEE.
An OTrP Broker is used to bridge communication between a TAM and a TEE. The OTrP Broker doesn't need to know the actual content of OTrP Messages except for the TEE routing information.
Step 1: Prepare Images for Devices
Step 2: Inject Key Pairs and Images to Devices
Step 3: Setup attestation key pairs in devices
Step 4: Setup trust anchors in devices
The protocol generates one key pair in run time to assist message communication and anonymous verification between a TAM and a TEE.
TEE SP Anonymous Key (AIK): one derived key pair per 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 SD creation for an SP. It is deleted when all SDs are removed for a SP in a device. The public key of the key pair is given to the caller Client Application and TAM for future TEE returned data validation. The public key of this AIK is also used by a TAM to encrypt TA binary data and personalization data when it sends a TA to a device for installation.
The primary job of a TAM is to help an SP to manage its trusted application components. A TA is typically installed in an SD. An SD is commonly created for an SP.
When an SP delegates its SD and TA management to a TAM, an SD is created on behalf of a TAM in a TEE and the owner of the SD is assigned to the TAM. An SD may be associated with an SP but the TAM has full privilege to manage the SD for the SP.
Each SD for an SP is associated with only one TAM. When an SP changes TAM, a new SP SD must be created to associate with the new TAM. The TEE will maintain a registry of TAM ID and SP SD ID mapping.
From an SD ownership perspective, the SD tree is flat and there is only one level. An SD is associated with its owner. It is up to TEE implementation how it maintains SD binding information for a TAM and different SPs under the same TAM.
It is an important decision in this protocol specification that a TEE doesn't need to know whether a TAM is authorized to manage the SD for an SP. This authorization is implicitly triggered by an SP Client Application, which instructs what TAM it wants to use. An SD is always associated with a TAM in addition to its SP ID. A rogue TAM isn't able to do anything on an unauthorized SP's SD managed by another TAM.
Since a TAM may support multiple SPs, sharing the same SD name for different SPs creates a dependency in deleting an SD. An SD can be deleted only after all TAs associated with this SD is deleted. An SP cannot delete a Security Domain on its own with a TAM if a TAM decides to introduce such sharing. There are cases where multiple virtual SPs belong to the same organization, and a TAM chooses to use the same SD name for those SPs. This is totally up to the TAM implementation and out of scope of this specification.
There is a need of cryptographically binding proof about the owner of an SD in a device. When an SD is created on behalf of a TAM, a future request from the 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 TAM may change its certificate.
To this end, each TAM will be associated with a trusted identifier defined as an attribute in the TAM certificate. This field is kept the same when the TAM renew its certificates. A TAM CA is responsible to vet the requested TAM attribute value.
This identifier value must not collide among different TAM providers, and one TAM shouldn't be able to claim the identifier used by another 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 TAM's service URL. A CA can verify the domain ownership of the URL with the TAM in the certificate enrollment process.
A TEE can assign this certificate attribute value as the TAM owner ID for the SDs that are created for the TAM.
An alternative way to represent an SD ownership by a TAM is to have a unique secret key upon SD creation such that only the creator TAM is able to produce a Proof-of-Possession (POP) data with the secret.
A sample Security Domain hierarchy for the TEE is shown below.
----------
| TEE |
----------
|
| ----------
|----------| SP1 SD1 |
| ----------
| ----------
|----------| SP1 SD2 |
| ----------
| ----------
|----------| SP2 SD1 |
----------
OTrP segregates SDs and TAs such that a TAM can only manage or retrieve data for SDs and TAs that it previously created for the SPs it represents.
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 Broker comes to meed this need. An OTrP Broker is a Rich Application or SDK that facilitates communication between a TAM and TEE. It also provides interfaces for TAM SDK or Client Applications to query and trigger TA installation that the application needs to use.
This interface for Client Applications may be commonly an Android service call for an Android powered device. A Client Application interacts with a TAM, and turns around to pass messages received from TAM to OTrP Broker.
In all cases, a Client Application needs to be able to identify an OTrP Broker that it can use.
An OTrP Broker abstracts the message exchanges with the TEE in a device. The input data is originated from a TAM that a Client Application connects. A Client Application may also directly call OTrP Broker for some TA query functions.
OTrP Broker may internally process a request from TAM. At least, it needs to know where to route a message, e.g. TEE instance. It doesn't need to process or verify message content.
OTrP Broker returns TEE / TFW generated response messages to the caller. OTrP Broker isn't expected to handle any network connection with an application or TAM.
OTrP Broker only needs to return an OTrP Broker error message if the TEE is not reachable for some reason. Other errors are represented as response messages returned from the TEE which will then be passed to the TAM.
A Client Application may use Global Platform (GP) TEE API for TA communication. OTrP may use the GP TEE Client API but it is internal to OTrP implementation that converts given messages from TAM. More details can be found at [GPTEECLAPI].
A Provider should consider methods of distribution, scope and concurrency on device and runtime options when implementing an OTrP Broker. Several non-exhaustive options are discussed below. Providers are encouraged to take advantage of the latest communication and platform capabilities to offer the best user experience.
OTrP Broker installation is commonly carried out at OEM time. A user can dynamically download and install an OTrP Broker on-demand.
It is important to ensure a legitimate OTrP Broker is installed and used. If an OTrP Broker is compromised it may send rogue messages to TAM and TEE and introduce additional risks.
We anticipate only one shared OTrP Broker instance in a device. The device's TEE vendor will most probably supply one OTrP Broker. Potentially we expect some open source.
With one shared OTrP Broker, the OTrP Broker provider is responsible to allow multiple TAMs and TEE providers to achieve interoperability. With a standard OTrP Broker interface, TAM can implement its own SDK for its SP Client Applications to work with this OTrP Broker.
Multiple independent OTrP Broker providers can be used as long as they have standard interface to a Client Application or TAM SDK. Only one OTrP Broker is expected in a device.
TAM providers are generally expected to provide SDK for SP applications to interact with an OTrP Broker for the TAM and TEE interaction.
A Client Application shall be responsible for relaying messages between the OTrP Broker and the TAM.
If a failure occurs during calling OTrP Broker, an error message described in "Common Errors" section (see Section 7.6) will be returned.
Description
Inputs:
Outputs:
Description
{
"TAQuery": {
"spid": "<SP identifier value of the TA>",
"taid": "<The identifier value of the TA>"
}
}
Inputs:
{
"TAInformationTBS": {
"taid": "<TA Identifier from the input>",
"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>"
],
"tamcert": "<The BASE64 encoded certificate data of the TAM
that manages this TA.>",
"tamcacerts": [ < The full list of CA certificate chain
including the root CA>
],
"cacert":"<The BASE64 encoded CA certificate data of the TAM
that manages this TA>"
]
}
}
{
"TAInformation": {
"payload": "<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>"
}
}
Outputs:
The message is signed with TEE SP AIK private key.
The main OTrP component is the set of standard JSON messages created by a TAM to deliver device SD and TA management commands to a device, and device attestation and response messages created by TEE to respond to 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 TAM is able to decrypt and view the actual content.
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.
For each TAM command "xyz"", OTrP use the following naming convention to represent its raw message content and complete request and response messages:
| Purpose | Message Name | Example |
|---|---|---|
| Request to be signed | xyzTBSRequest | CreateSDTBSRequest |
| Request message | xyzRequest | CreateSDRequest |
| Response to be signed | xyzTBSResponse | CreateSDTBSResponse |
| Response message | xyzResponse | CreateSDResponse |
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>
}
}
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].
A general JWS object looks like the following.
{
"payload": "<payload contents>",
"protected": "<integrity-protected header contents>",
"header": {
<non-integrity-protected header contents>,
},
"signature": "<signature contents>"
}
OTrP signed messages only 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 header contents>",
"header": <non-integrity-protected header contents>,
"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 Broker 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. This specification indicates elements that should be BASE64 and those elements that are to be BASE64URL encoded.
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.
To protect privacy, it is important that the device's certificate is released only to a trusted TAM, and that it is encrypted. The 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 TAM and device begin with GetDeviceStateRequest / GetDeviceStateResponse. These messages have elements built into them to exchange signing certificates, described in the section Section 9. Any subsequent messages in the conversation that follow on from this implicitly use the same certificates for signing/encryption, and as a result the certificates or references may be omitted 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 TAM implementation: they have to cache the signer certificates for the subsequent message signature validation in the session. It may be easier for a TAM service to cache transaction session information but not so for a TEE in a device. A TAM can get a device's capability by checking the response message from a TEE to decide whether it should include its TAM signer certificate and OCSP data in each subsequent request message. The device's caching capability is reported in GetDeviceStateResponse signerreq parameter.
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.
The (BASE64URL encoded) "protected" header property in a signed message looks like the following:
If ECSDA with P-256 curve and SHA256 are used for signing, the JSON signing algorithm representation is as follows.
The value for the "protected" field will be the following.
Thus, a common OTrP signed message with ES256 looks like the following.
{
"payload": "<payload contents>",
"protected": "eyJhbGciOiJFUzI1NiJ9",
"signature": "<signature contents>"
}
The OTrP JSON message encryption algorithm 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, the CEK will be encrypted by the recipient's public key.
A compliant implementation shall support the following symmetric encryption algorithm and anticipate future new algorithms.
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
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.
The following JSON signature algorithm is mandatory support in the TEE and TAM:
ES256 is optional to support.
The following JSON authenticated encryption algorithm is mandatory support in TEE and TAM.
A256CBC-HS512 is optional to support.
The following JSON key management algorithm is mandatory support in TEE and TAM.
ECDH-ES+A128KW and ECDH-ES+A256KW are optional to support.
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>"
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.
For each command that a TAM wants to send to a device, the TAM generates a request message. This is typically triggered by a Client Application that uses the TAM. The Client Application initiates contact with the TAM and receives TAM OTrP Request messages according to the TAM's implementation. The Client Application forwards the OTrP message to an OTrP Broker 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 Broker is responsible to connect to the active TEE. This is the case today with devices in the market.
When the TEE responds to a request, the OTrP Broker gets the OTrP response messages back to the Client Application that sent the request. In case the target TEE fails to respond to the request, the OTrP Broker will be responsible to generate an error message to reply the Client Application. The Client Application forwards any data it received to its TAM.
When the first new Security Domain is created in a TEE for an SP, a new key pair is generated and associated with this SP. This key pair is used for future device attestation to the service provider instead of using the device's TEE key pair.
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.
For each message in the following sections all JSON elements are mandatory if not explicitly indicated as optional.
This is the first command that a TAM will send to a device. This command is triggered when an SP's Client Application contacts its 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 SDs and TAs in the device that is managed by the requesting 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 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 TAM's public key such that only the TAM that sent the request is able to decrypt and view the response message.
{
"GetDeviceStateTBSRequest": {
"ver": "1.0",
"rid": "<Unique request ID>",
"tid": "<transaction ID>",
"ocspdat": [<a list of OCSP stapling data>"],
"supportedsigalgs": [<array of supported signing algorithms>]
}
}
The request message consists of the following data elements:
The final request message is JSON signed message of the above raw JSON data with TAM's certificate.
{
"GetDeviceStateRequest": {
"payload": "<BASE64URL encoding of the GetDeviceStateTBSRequest
JSON above>",
"protected": "<BASE64URL encoded signing algorithm>",
"header": {
"x5c": "<BASE64 encoded TAM certificate chain up to the
root CA certificate>"
},
"signature":"<signature contents signed by TAM private key>"
}
}
The signing algorithm 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 TAM signer certificate up to the root CA certificate.
Upon receiving a request message GetDeviceStateRequest at a TEE, the TEE MUST validate a request:
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. 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. The TEE is responsible to validate TFW integrity to ensure that the underlying device firmware is trustworthy. In some cases, a TEE isn't able to get a TFW signed data, in which case the TEE trust validation is up to a TAM to decide. A TAM may opt to trust a TEE basing on the TEE signer and additional information about a TEE out-of-band.
When TFW signed data is available, a TAM validates the TEE and trusts that a trusted TEE has carried out appropriate trust check about a TFW.
TfwData: {
"tbs": "<TFW to be signed data, BASE64 encoded>",
"cert": "<BASE64 encoded TFW certificate>",
"sigalg": "Signing method",
"sig": "<TFW signed data, BASE64 encoded>"
}
It is expected that a FW uses standard signature methods for maximal interoperability with 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 a TAM according to the definition given here. The data to be signed is the raw data.
TAM providers shall support the following signature methods. A firmware provider can choose one of the methods in signature generation.
The value of "sigalg" in the TfwData JSON message SHOULD use one of the following:
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 TAM's public key. The JSON Content Encryption Key (CEK) is used for this purpose.
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 | false // about whether TAM needs to send
signer data again in subsequent messages,
"edsi": "<Encrypted JSON DSI information>"
}
}
where
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 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 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:
The value of the property "protected" in the above JWE message will be
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 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 7.5.1.
The final GetDeviceStateResponse response message consists of an array of TEE responses.
{
"GetDeviceStateResponse": [ // JSON array
{"GetDeviceTEEStateResponse": ...},
...
{"GetDeviceTEEStateResponse": ...}
]
}
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.
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": [<an array of signature algorithms that
the TEE supports>]
}
}
where
If the TEE isn't able to sign an error message due to an internal device error, a general error message should be returned by the OTrP Broker.
Upon receiving a GetDeviceStateResponse message at a TAM, the TAM MUST validate the following.
This command is typically preceded with a GetDeviceState command that has acquired the device information of the target device by the TAM. The TAM sends such a command to instruct a TEE to create a new Security Domain for an SP.
A TAM sends an OTrP CreateSDRequest Request message to a device TEE to create a Security Domain for an SP. Such a request is signed by the TAM where the 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:
A Trusted Application that is signed by a matching SP signer certificate for an SD is eligible to be installed into that SD. The TA installation into an SD by a subsequent InstallTARequest message may be instructed from a TAM.
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 | 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>",
"tamid": "<An identifiable attribute of the TAM
certificate>",
"did": "<SHA256 hash of the TEE cert>"
}
}
}
In the message,
A CreateSDTBSRequest message is signed to generate a final CreateSDRequest message as follows.
{
"CreateSDRequest": {
"payload": "<CreateSDTBSRequest JSON above>",
"protected": "<integrity-protected header contents>",
"header": "<non-integrity-protected header contents>",
"signature": "<signature contents signed by TAM private key>"
}
}
The TAM signer certificate is included in the "header" property.
Upon receiving a CreateSDRequest request message at a TEE, the TEE MUST do the following:
If a request is illegitimate or signature doesn't pass, a "status" property in the response will indicate the error code and cause.
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 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 SDs owned by
this TAM>"
}
}
}
In the response message, the following fields MUST be supplied.
There is a possible extreme error case where the TEE isn't reachable or the TEE final response generation itself fails. In this case, the TAM might still receive a response from the OTrP Broker if the OTrP Broker is able to detect such error from TEE. In this case, a general error response message should be returned by the OTrP Broker, assuming OTrP Broker even doesn't know any content and information about the request message.
In other words, the TAM should expect to receive a TEE successfully signed JSON message, a general "status" message, or none when a client experiences a network error.
{
"CreateSDResponse": {
"payload": "<CreateSDTBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by the TEE device private
key (BASE64URL)>"
}
}
When the TEE fails to respond, the OTrP Broker will not provide a subsequent response to the TAM. The TAM should treat this as if the device has gone offline where a response is never delivered back.
An error might occur if a request isn't valid or the TEE runs into some error. The list of possible errors are as follows. Refer to the Error Code List for detailed causes and actions.
This TAM initiated command can update an SP's SD that it manages for any of the following needs: (a) Update an SP signer certificate; (b) Add an SP signer certificate when an SP uses multiple to sign TA binaries; (c) Update an SP ID.
The 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 end-to-end confidentiality.
The UpdateSD request message 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 | false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED { // this piece of JSON will be encrypted
"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 | false
}
}
}
}
In the message,
The UpdateSDTBSRequest message is signed to generate the final UpdateSDRequest message.
{
"UpdateSDRequest": {
"payload": "<UpdateSDTBSRequest JSON above>",
"protected": "<integrity-protected header contents>",
"header": "<non-integrity-protected header contents>",
"signature":"<signature contents signed by TAM private key>"
}
}
TAM signer certificate is included in the "header" property.
Upon receiving a request message UpdateSDRequest at a TEE, the TEE must validate a request:
If a request is illegitimate or the signature doesn't pass, a "status" property in the response will indicate the error code and cause.
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 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 TAM>"
}
}
}
In the response message, the following fields MUST be supplied.
Similar to the template for the creation of the encrypted and signed CreateSDResponse, the final UpdateSDResponse looks like the following.
{
"UpdateSDResponse": {
"payload": "<UpdateSDTBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by TEE device private
key (BASE64URL)>"
}
}
When the TEE fails to respond, the OTrP Broker will not provide a subsequent response to the TAM. The TAM should treat this as if the device has gone offline where a response is never delivered back.
An error may occur if a request isn't valid or the TEE runs into some error. The list of possible errors are as follows. Refer to the Error Code List for detailed causes and actions.
A TAM sends a DeleteSDRequest message to a TEE to delete a specified SD that it owns. 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 an SD and then delete the SD.
The target TEE will operate with the following logic.
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 | false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED { // this piece of JSON will be encrypted
"tamid": "<tamid associated with this SD>",
"sdname": "<SD name for the domain to be updated>",
"deleteta": true | false
}
}
}
In the message,
According to the OTrP message template, the full request DeleteSDRequest is a signed message over the DeleteSDTBSRequest as follows.
{
"DeleteSDRequest": {
"payload": "<DeleteSDTBSRequest JSON above>",
"protected": "<integrity-protected header contents>",
"header": "<non-integrity-protected header contents>",
"signature": "<signature contents signed by TAM private key>"
}
}
TAM signer certificate is included in the "header" property.
Upon receiving a request message DeleteSDRequest at a TEE, the TEE must validate a request:
If a request is illegitimate or the signature doesn't pass, a "status" property in the response will indicate the error code and cause.
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 detail>", // optional
"did": "<the device id hash>",
"dsi": "<Updated TEE state, including all SD owned by
this TAM>"
}
}
}
In the response message, the following fields MUST be supplied.
The final DeleteSDResponse looks like the following.
{
"DeleteSDResponse": {
"payload": "<DeleteSDTBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by TEE device
private key (BASE64URL)>"
}
}
When the TEE fails to respond, the OTrP Broker will not provide a subsequent response to the TAM. The TAM should treat this as if the device has gone offline where a response is never delivered back.
An error may occur if a request isn't valid or the TEE runs into some error. The list of possible errors is as follows. Refer to the Error Code List for detailed causes and actions.
This protocol doesn't introduce a TA container concept. All TA authorization and management will be up to the TEE implementation.
The following three TA management commands are supported.
TA binary data and related personalization data if there is any can be from two sources:
This specification primarily considers the first case where a TAM supplies a TA binary. This is to ensure that a TEE can properly validate whether a TA is trustworthy. Further, TA 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 TAM sends the following information in a InstallTARequest message to a target TEE:
The TEE processes the command given by the TAM to install a TA into an SP's SD. It does the following:
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 | false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED {
"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": "<JWE enveloped data of a 256-bit symmetric key 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,
According to the OTrP message template, the full request InstallTARequest is a signed message over the InstallTATBSRequest as follows.
{
"InstallTARequest": {
"payload": "<InstallTATBSRequest JSON above>",
"protected": "<integrity-protected header contents>",
"header": "<non-integrity-protected header contents>",
"signature": "<signature contents signed by TAM private key>"
}
}
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 TAM>"
}
}
}
In the response message, the following fields MUST be supplied.
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)>"
}
}
When the TEE fails to respond, the OTrP Broker will not provide a subsequent response to the TAM. The TAM should treat this as if the device has gone offline where a response is never delivered back.
An error may occur if a request isn't valid or the TEE runs into some error. The list of possible errors are as follows. Refer to the Error Code List for detailed causes and actions.
This TAM-initiated command can update a TA and its data in an SP's SD that it manages for the following purposes.
The 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 end-to-end confidentiality.
The TEE processes the command from the TAM to update the TA of an SP SD. It does the following:
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 | false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED {
"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": "<JWE enveloped data of a 256-bit symmetric key 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,
According to the OTrP message template, the full request UpdateTARequest is a signed message over the UpdateTATBSRequest as follows.
{
"UpdateTARequest": {
"payload": "<UpdateTATBSRequest JSON above>",
"protected": "<integrity-protected header contents>",
"header": "<non-integrity-protected header contents>",
"signature": "<signature contents signed by TAM private key>"
}
}
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 detail>", // optional
"did": "<the device id hash>",
"dsi": "<Updated TEE state, including all SD owned by
this TAM>"
}
}
}
In the response message, the following fields MUST be supplied.
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)>"
}
}
When the TEE fails to respond, the OTrP Broker will not provide a subsequent response to the TAM. The TAM should treat this as if the device has gone offline where a response is never delivered back.
An error may occur if a request isn't valid or the TEE runs into some error. The list of possible errors are as follows. Refer to the Error Code List for detailed causes and actions.
This operation defines OTrP messages that allow a TAM to instruct a TEE to delete a TA for an SP in a given SD. A TEE will delete a TA from an SD and also TA data in the TEE. A Client Application cannot directly access TEE or OTrP Broker to delete a TA.
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 | false,
"dsihash": "<hash of DSI returned in the prior query>",
"content": ENCRYPTED {
"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,
According to the OTrP message template, the full request DeleteTARequest is a signed message over the DeleteTATBSRequest as follows.
{
"DeleteTARequest": {
"payload": "<DeleteTATBSRequest JSON above>",
"protected": "<integrity-protected header contents>",
"header": "<non-integrity-protected header contents>",
"signature": "<signature contents signed by TAM
private key>"
}
}
A TEE processes a command from a TAM to delete a TA of an SP SD. It does the following:
If a request is illegitimate or the signature doesn't pass, a "status" property in the response will indicate the error code and cause.
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 detail>", // optional
"did": "<the device id hash>",
"dsi": "<Updated TEE state, including all SD owned by
this TAM>"
}
}
}
In the response message, the following fields MUST be supplied.
The final message DeleteTAResponse looks like the following.
{
"DeleteTAResponse": {
"payload": "<DeleteTATBSResponse JSON above>",
"protected": {
"<BASE64URL of signing algorithm>"
},
"signature": "<signature contents signed by TEE device
private key (BASE64URL)>"
}
}
When the TEE fails to respond, the OTrP Broker will not provide a subsequent response to the TAM. The TAM should treat this as if the device has gone offline where a response is never delivered back.
An error may occur if a request isn't valid or the TEE runs into some error. The list of possible errors are as follows. Refer to the Error Code List for detailed causes and actions.
A 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.
{
"OTrPBrokerError": {
"ver": "1.0",
"rid": "",
"tid": "",
"errcode": "ERR_AGENT_TEE_UNKNOWN | ERR_AGENT_TEE_BUSY"
}
}
This section describes a baseline for interoperability among the protocol entities, mainly, the TAM and TEE.
A TEE MUST support RSA algorithms. It is optional to support ECC algorithms. A TAM SHOULD use a RSA certificate for TAM message signing. It may use an ECC certificate if it detects that the TEE supports ECC according to the field "supportedsigalgs" in a TEE response.
A 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
JSON asymmetric encryption algorithms (describes key-exchange or key-agreement algorithm for sharing symmetric key with TEE):
JSON symmetric encryption algorithms (describes symmetric algorithm for encrypting body of data, using symmetric key transferred to TEE using asymmetric encryption):
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 how the TAM and the device implement the trust hierarchy verification. However, it is helpful to understand what each system provider should do in order to properly implement an OTrP trust hierarchy.
In this section, we provide some implementation reference consideration.
It is proposed that attestation for OTrP is based on the TFW layer, and that further attestation is not performed within the TEE itself during Security Domain operations. The rationale is that the device boot process will be defined to start with a secure bootloader protected with a harden key in eFUSE. The process releases attestation signing capabilities into the TFW once a trust boot has been established. In this way the release of the attestation signer can be considered the first "platform configuration metric", using Trust Computing Group (TCG) terminology.
During boot, the TFW is required to start all of the root TEEs. Before loading them, the TFW must first determine whether the code sign signature of the TEE is valid. If TEE integrity is confirmed, the TEE may be started. The TFW must then be able to receive the identity certificate from the TEE (if that TEE is OTrP compliant). The identity certificate and keys will need to be baked into the TEE image, and therefore also covered by the code signer hash during the manufacturing process. The private key for the identity certificate must be securely protected. The private key for a TEE identity must never be released no matter how the public key and certificate are released to the TFW.
Once the TFW has successfully booted a TEE and retrieved the identity certificate, the TFW will commit this to the platform configuration register (PCR) set, for later use during attestation. At minimum, the following data must be committed to the PCR for each TEE:
The attestation hierarchy and seed required for TAM protocol operation must be built into the device at manufacture. Additional TEEs can be added post-manufacture using the scheme proposed, but it is outside of the current scope of this document to detail that.
It should be noted that the attestation scheme described is based on signatures. The only decryption that may take place is through the use of a bootloader key.
During manufacture the following steps are required:
During device boot the following steps are required:
Before a TAM can begin operation in the marketplace to support devices of a given TEE, it must obtain a TAM certificate from a CA that is registered in the trust store of devices with that TEE. In this way, the TEE can check the intermediate and root CA and verify that it trusts this TAM to perform operations on the TEE.
There are two IANA requests: a media type and list of error codes.
This section first requests that IANA assign a media type: application/otrp+json.
The error code listed in the next section will be registered.
This section lists error codes that could be reported by a TA or TEE in a device in responding to a TAM request, and a separate list that OTrP Broker may return when the TEE fails to respond.
The strength of the cryptographic algorithms, using the measure of 'bits of security' defined in NIST SP800-57 allowed for OTrP is:
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 allows for crypto-agility. In this specification, TAM and TEE can negotiate an agreed upon algorithm where both include their supported algorithm in OTrP message.
OTrP messages between the 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 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 TAM, and to ensure that the TAM will only communicate with a trusted TEE.
It is important that the 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 TAM. This allows the 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 manufacture, which allows the TEE to check that that the TFW is trusted.
The GetDeviceState message therefore allows the TAM to check that it trusts the TEE, and the TEE at this point will check whether it trusts the TFW.
A TA will be delivered in an encrypted form. This encryption is an additional layer within the message encryption described in the Section 11 of this document. The TA binary is encrypted for each target device with the device's TEE SP AIK public key. A TAM can either do this encryption itself or provide the TEE SP AIK public key to an SP such that the SP encrypts the encrypted TA for distribution to the TEE.
The encryption algorithm can use a 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": "<JWE enveloped data of a 256-bit symmetric key by
the recipient's TEEspaik public key>",
"iv": <hex of 16 random bytes>",
"alg": "AESCBC",
"cipherdata": "<BASE64 encoded encrypted TA binary data>"
}
An SP or TAM can supply personalization data for a TA to initialize for a device. Such data is passed through an InstallTA command from a TAM. The personalization data itself is (or can be) opaque to the TAM. The data can be from the SP without being revealed to the 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 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": "<JWE enveloped data of a 256-bit symmetric key by
the recipient's TEEspaik public key>",
"iv": "<hex of 16 random bytes>",
"alg": "AESCBC",
"cipherdata": "<BASE64 encoded encrypted TA personalization
data>"
}
A TA binary is signed by a TA signer certificate. This TA signing certificate/private key belongs to the SP, and may be self-signed (i.e., it need not participate in a trust hierarchy). It is the responsibility of the TAM to only allow verified TAs from trusted SPs into the system. Delivery of that TA to the TEE is then the responsibility of the TEE, using the security mechanisms provided by the OTrP.
We allow a way for an (untrusted) application to check the trustworthiness of a TA. OTrP Broker has a function to allow a Client Application to query the information about a TA.
An application in the Rich O/S may perform verification of the TA by verifying the signature of the TA. The GetTAInformation function is available to return the TEE supplied TA signer and TAM signer information to the application. An application can do additional trust checks on the certificate returned for this TA. It might trust the TAM, or require additional SP signer trust chaining.
A TA for multiple SPs must have a different identifier per SP. A TA will be installed in a different SD for each respective SP.
An OTrP Broker could be malware in the vulnerable REE. A Client Application will connect its TAM provider for required TA installation. It gets command messages from the TAM, and passes the message to the OTrP Broker.
The OTrP is a conduit for enabling the TAM to communicate with the device's TEE to manage SDs and TAs. All TAM messages are signed and sensitive data is encrypted such that the OTrP Broker cannot modify or capture sensitive data.
The GetDeviceStateRequest message from a TAM to a TEE shall include OCSP stapling data for the TAM's signer certificate and for intermediate CA certificates up to the root certificate so that the TEE can verify the signer certificate's revocation status.
A certificate revocation status check on a TA signer certificate is OPTIONAL by a TEE. A TAM is responsible for vetting a TA and the SP before it distributes them to devices. A TEE will trust a TA signer certificate's validation status done by a TAM when it trusts the TAM.
The TEE implementation provides protection of data on the device. It is the responsibility of the TAM to protect data on its servers.
Devices are issued with a unique TEE certificate to attest 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 TAM (it must verify the TAM certificate before proceeding). OTrP is designed such that only a TAM can obtain the TEE device certificate and firmware certificate - the GetDeviceState message requires signature checks to validate the TAM is trusted, and OTrP delivers the device's certificate(s) encrypted such that only that TAM can decrypt the response. A Client Application will never see the device certificate.
An SP-specific TEE SP AIK (TEE SP Anonymous Key) is generated by the protocol for Client Applications. This provides a way for the Client Application to validate some data that the TEE may send without requiring the TEE device certificate to be released to the client device rich O/S , and to optionally allow an SP to encrypt a TA for a target device without the SP needing to be supplied with the TEE device certificate.
A rogue application may perform excessive TA loading. An OTrP Broker implementation should protect against excessive calls.
Rogue applications might request excessive SD creation. The TAM is responsible to ensure this is properly guarded against.
Rogue OTrP Broker could replay or send TAM messages out of sequence: e.g., a TAM sends update1 and update2. The OTrP Broker replays update2 and update1 again, creating an unexpected result that a client wants. "dsihash" is used to mitigate this. The TEE MUST store DSI state and check that the DSI state matches before it does another update.
Concurrent calls from a TAM to a TEE MUST be handled properly by a TEE. If multiple concurrent TAM operations take place, these could fail due to the "dsihash" being modified by another concurrent operation. The TEE is responsible for resolve any locking such that one application cannot lock other applications from using the TEE, except for a short term duration of the TAM operation taking place. For example, an OTrP operation that starts but never completes (e.g. loss of connectivity) must not prevent subsequent OTrP messages from being executed.
A root CA for TAM certificates might get compromised. Some TEE trust anchor update mechanism is expected from device OEMs. A compromised intermediate CA is covered by OCSP stapling and OCSP validation check in the protocol. A TEE should validate certificate revocation about a TAM certificate chain.
If the root CA of some TEE device certificates is compromised, these devices might be rejected by a TAM, which is a decision of the TAM implementation and policy choice. Any intermediate CA for TEE device certificates SHOULD be validated by TAM with a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) method.
The TEE SHOULD use validation of the supplied TAM certificates and OCSP stapled data to validate that the 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 TAM certificate, or revoked TAM certificate. Since OCSP stapling includes signature generation time, certificate validity dates are compared to the current time.
TFW and TEE device certificates are expected to be long lived, longer than the lifetime of a device. A TAM certificate usually has a moderate lifetime of 2 to 5 years. A TAM should get renewed or rekeyed certificates. The root CA certificates for a TAM, which are embedded into the trust anchor store in a device, should have long lifetimes that don't require device trust anchor update. On the other hand, it is imperative that OEMs or device providers plan for support of trust anchor update in their shipped devices.
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 (in alphabetical order) for their input and review: Sangsu Baek, Rob Coombs, Dapeng Liu, Dave Thaler, and Pengfei Zhao.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4648] | Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006. |
| [RFC7159] | Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014. |
| [RFC7515] | Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. |
| [RFC7516] | Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015. |
| [RFC7517] | Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015. |
| [RFC7518] | Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015. |
| [TEEPArch] | Pei, M., Tschofenig, H., Atyeo, A. and D. Liu, "Trusted Execution Environment Provisioning (TEEP) Architecture", 2018. |
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"
}
}
The TAM signs "GetDeviceStateTBSRequest", creating "GetDeviceStateRequest"
{
"GetDeviceStateRequest": {
"payload":"
ewoJIkdldERldmljZVN0YXRlVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJ
InJpZCI6IHs4QzZGOURCQi1GQzM5LTQzNWMtQkM4OS00RDM2MTREQTJGMEJ9LAoJCSJ0
aWQiOiAiezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0iLAoJCSJv
Y3NwZGF0IjogImMyRnRjR3hsSUc5amMzQmtZWFFnUWpZMElHVnVZMjlrWldRZ1FWTk9N
UT09IiwKCQkiaWNhb2NzcGRhdCI6ICJjMkZ0Y0d4bElHbGpZVzlqYzNCa1lYUWdRalkw
SUdWdVkyOWtaV1FnUVZOT01RPT0iLAoJCSJzdXBwb3J0ZWRzaWdhbGdzIjogIlJTMjU2
IgoJfQp9",
"protected": "eyJhbGciOiJSUzI1NiJ9",
"header": {
"x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==",
"ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"]
},
"signature":"c2FtcGxlIHNpZ25hdHVyZQ"
}
}
The TAM sends "GetDeviceStateRequest" to the OTrP Broker
The OTrP Broker obtains "dsi" from each TEE. (In this example there is a single TEE.)
The TEE obtains signed "fwdata" from firmware.
The TEE builds "dsi" - summarizing device state of the TEE.
{
"dsi": {
"tfwdata": {
"tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=",
"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.
{
"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 Broker. The OTrP Broker encodes "GetDeviceTEEStateResponse" into an array to form "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 Broker, which returns message back to the TAM.
{
"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-
gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4wD
AYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2xhY2l
hMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhcNMTUwN
zAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAwGA1UECAw
FU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNpYTEQMA4GA
1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0GCSqGSIb3DQE
BAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0hCWJRaFzt5mU-
lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE--
3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_dca
d2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUjEOMA
wGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNp
YTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tggkAiTRNq3
S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BAwwCgYIKwYB
BQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ-
LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa-
GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1QV
THILI6afLCRWXXclc1L5KGY290OwIdQ",
"tamid":"TAM_x.acme.com",
"did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM"
}
}
}
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"
}
}
{
"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",
}
}
}
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"
}
}
{
"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
"tamid": "id1.TAMxyz.com",
"spid": "com.acmebank.spid1",
"sdname": "com.acmebank.sdname1",
"changes": {
"newsdname": "com.acmebank.sdname2",
"newspid": "com.acquirer.spid1",
"spcert":
"MIIDFjCCAn-
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"
}
}
}
}
{
"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"
}
}
}
The TAM builds message - including data to be encrypted.
{
"DeleteSDTBSRequest": {
"ver": "1.0",
"rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}",
"tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
"tee": "Primary TEE",
"nextdsi": "false",
"dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=",
"content": ENCRYPTED {
"tamid": "TAM1.com",
"sdname": "default.acmebank.com",
"deleteta": "1"
}
}
}
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"
}
}
}
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"
}
}
The TEE creates a "DeleteSDTBSResponse" to respond to the "DeleteSDRequest" message from the TAM, including data to be encrypted.
{
"DeleteSDTBSResponse": {
"ver": "1.0",
"status": "pass",
"rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}",
"tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}",
"content": ENCRYPTED {
"did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=",
}
}
}
The TEE encrypts the "content" for the 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 Broker, which returns the message back to the TAM.
{
"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": {
"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 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"
}
]
}
}
}
}
}
{
"UpdateTATBSRequest": {
"ver": "1.0",
"rid": "req-2",
"tid": "tran-01",
"tee": "SecuriTEE",
"nextdsi": " false",
"dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U",
"content": {
"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"
}
}
{
"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"
}
}
{
"DeleteTATBSRequest": {
"ver": "1.0",
"rid": "req-2",
"tid": "tran-01",
"tee": "SecuriTEE",
"nextdsi": "false",
"dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U",
"content": {
"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"
}
}
{
"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
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"
}
}
The most popular TEE devices today are Android powered devices. In an Android device, an OTrP Broker can be a bound service with a service registration ID that a Client Application can use. This option allows a Client Application not to depend on any OTrP Broker SDK or provider.
An OTrP Broker is responsible to detect and work with more than one TEE if a device has more than one. In this version, there is only one active TEE such that an OTrP Broker only needs to handle the active TEE.
- Brian Witten
Symantec
brian_witten@symantec.com
- Tyler Kim
Solacia
tylerkim@iotrust.kr