The Open Trust Protocol (OTrP)

The Open Trust Protocol (OTrP) Symantec

350 Ellis St Mountain View CA 94043 USA mpei@yahoo.com

Intercede

St. Mary's Road, Lutterworth Leicestershire LE17 4PS Great Britain nick.cook@intercede.com

Solacia

5F, Daerung Post Tower 2, 306 Digital-ro Seoul 152-790 Korea paromix@sola-cia.com

Intercede

St. Mary's Road, Lutterworth Leicestershire LE17 4PS Great Britain andrew.atyeo@intercede.com

ARM Ltd.

110 Fulbourn Rd Cambridge CB1 9NJ Great Britain Hannes.tschofenig@arm.com

General Internet Engineering Task Force Open Trust This document specifies the Open Trust Protocol (OTrP), a protocol to install, update, and delete applications and to manage security configuration in a Trusted Execution Environment (TEE). TEEs are used in environments where security services should be isolated from a regular operating system (often called rich OS). This form of compartmentlization grants a smaller codebase access to security sensitive services and restricts communication from the rich OS to those security services via mediated access.

The Trusted Execution Environment (TEE) concept has been designed and used to increase security by separating regular operating systems, also referred as Rich Execution Environment (REE), from security-sensitive applications. In an TEE ecosystem, a Trust Service Manager (TSM) is used to authorize manage keys and the Trusted Applications (TA) that run in a device. Different device vendors may use different TEE implementations. Different application providers may use different TSM providers. There arises a need of an open interoperable protocol that allows trustworthy TSM to manage security domains and contents running in different Trusted Execution Environment (TEE) of various devices. The Open Trust Protocol (OTrP) defines a protocol between a TSM 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). This specification assumes that a device that utilizes this specification is equipped with a TEE and is pre-provisioned with a device-unique public/private key pair, which is securely stored. This key pair is referred as the 'root of trust'. A Service Provider (SP) uses such a device to run Trusted Applications (TA). A security domain is defined as the TEE representation of a service provider and is a logical space that contains the service provider's trusted applications. Each security domain requires the management operations of trusted applications (TAs) in the form of installation, update and deletion. The protocol builds on the following properties of the system: The SP needs to determine security-relevant information of a device before provisioning information to a TEE. Examples include the verification of the root of trust, the type of firmware installed, and the type of TEE included in a device. A TEE in a device needs to determine whether a SP or the TSM is authorized to manage applications in the TEE. Secure Boot must be able to ensure a TEE is genuine. This specification defines message payloads exchanged between devices and a TSM but does not mandate a specific transport.

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

The definitions provided below are defined as used in this document. The same terms may be defined differently in other documents. An application running on a rich OS, such as an Android, Windows, or iOS application, provided by a SP. A physical piece of hardware that hosts symmetric key cryptographic modules An application running in the rich OS allowing communication with the TSM and the TEE. Alternative name of "Client Application". In this document we may use these two terms interchangably. An environment that is provided and governed by a rich OS, potentially in conjunction with other supporting operating systems and hypervisors; it is outside of the TEE. This environment and applications running on it are considered un-trusted. A firmware in a device that delivers secure boot functionality. It is also referred as Trusted Firmware (TFW) in this document. An entity that wishes to supply Trusted Applications to remote devices. A Service Provider requires the help of a TSM in order to provision the Trusted Applications to the devices. A root certificate that a module trusts. It is usually embedded in one validating module, and used to validate the trust of a remote entity's certificate. Application that runs in TEE. An execution environment that runs alongside but isolated from an REE. A TEE has security capabilities and meets certain security-related requirements: It protects TEE assets from general software attacks, defines rigid safeguards as to data and functions that a program can access, and resists a set of defined threats. There are multiple technologies that can be used to implement a TEE, and the level of security achieved varies accordingly.

Certificate Authority Open Trust Protocol Rich Execution Environment Security Domain Service Provider Secure Boot Module Trusted Application Trusted Execution Environment Trusted Firmware Trusted Service Manager

There are the following main components in this OTrP system. The TSM is responsible for originating and coordinating lifecycle management activity on a particular TEE. A Trust Service Manager (TSM) is at the core to the protocol that manages device trust check on behalf of service providers for the ecosystem scalability. In addition to its device trust management for a service provider, the TSM provides Security Domain management and TA management in a device, in particularly, over-the-air update to keep Trusted Applications up to date and clean up when a version should be removed. In the context of this specification, the term Trusted Application Manager (TAM) and TSM are synonymous. Mutual trust between a device and a TSM as well as a Service Provider is based on certificates. A device embeds a list of root certificates, called Trust Anchors, from trusted Certificate Authorities that a TSM will be validated against. A TSM will remotely attest a device by checking whether a device comes with a certificate from a trusted CA. The TEE resides in the device chip security zone and is responsible for protecting applications from attack, enabling the application to perform secure operations The REE, usually called device OS such as Android OS in a phone device, is responsible for enabling off device communications to be established between the TEE and TSM. OTrP does not require the device OS to be secure. An application in the REE that can relay messages between a Client Application and TEE. Secure boot (for the purposes of OTrP) must enable authenticity checking of TEEs by the TSM. The OTrP establishes appropriate trust anchors to enable TEE and TSMs to communicate in a trusted way when performing lifecycle management transactions. The main trust relationships between the components are the following. TSM must be able to ensure a TEE is genuine TEE must be able to ensure a TSM is genuine Secure Boot must be able to ensure a TEE is genuine

The TEE in each device comes with a trust store that contains a whitelist of TSM's root CA certificates, which are called Trust Anchors. A TSM will be trusted to manage Security Domains and TAs in a device only if its certificate is chained to one of the root CA certificates in this trust store. Such a list is typically embedded in TEE of a device, and the list update is enabled and handled by device OEM provider.

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

OTrP Protocol leverages the following list of trust anchors and identities in generating signed and encrypted command messages that are exchanged between a device with TEE and a TSM. 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 keypair and Certificate Device secure storage OEM CA A white list of FW root CA trusted by TSMs 1 per device 2. TEE keypair and Certificate Device TEE TEE CA under a root CA A white list of TEE root CA trusted by TSMs 1 per device 3. TSM keypair and Certificate TSM provider TSM CA under a root CA A white list of TSM root CA embedded in TEE 1 or multiple can be used by a TSM 4. SP keypair and Certificate SP SP signer CA TSM manages SP. TA trust is delegated to TSM. TEE trusts TSM to ensure that a TA is trustworthy. 1 or multiple can be used by a TSM A key pair and certificate for evidence of secure boot and trustworthy firmware in a device. Device secure storage RSA and ECC OEM CA A white list of FW root CA trusted by TSMs One per device It is used for device attestation to remote TSM and SP. This key pair is burned into the device at device manufacturer. The key pair and its certificate are valid for the expected lifetime of the device. Device TEE RSA and ECC TEE CA that chains to a root CA A white list of TEE root CA trusted by TSMs One per device A TSM provider acquires a certificate from a CA that a TEE trusts. TSM provider RSA and ECC. RSA 2048-bit, ECC P-256 and P-384. TSM CA that chains to a root CA A white list of TSM root CA embedded in TEE One or multiple can be used by a TSM A SP uses its own key pair and certificate to sign a TA. SP RSA and ECC RSA 2048-bit, ECC P-256 and P-384 SP signer CA that chains to a root CA TSM manages SP. TA trust is delegated to TSM. TEE trusts TSM to ensure that a TA is trustworthy. One or multiple can be used by a SP

This document specifies the minimally required interoperable artifacts to establish mutual trust between a TEE and TSM. The protocol provides specifications for the following three entities: Key and certificate types required for device firmware, TEE, TA, SP, and TSM Data message formats that should be exchanged between a TEE in a device and a TSM An OTrP Agent application in the REE that can relay messages between a Client Application and TEE Figure 1: Protocol Scope and Entity Relationship

Figure 2: OTrP System Diagram

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 key pair such as a FW key pair, TEE key pair or TSM key pair. The main OTrP Protocol component is the set of standard JSON messages created by TSM to deliver device SD and TA management commands to a device, and device attestation and response messages created by TEE to respond to TSM OTrP Messages. The communication method of OTrP Messages between a TSM and TEE in a device is left to TSM providers for maximal interoperability. A TSM can work with its SP and Client Applications how it gets OTrP Messages from a TSM. When a Client Application has had an OTrP Message from its TSM, it is imperative to have an interoperable interface to communicate with various TEE types. This is the OTrP Agent interface that serves this purpose. The OTrP Agent doesn't need to know the actual content of OTrP Messages except for the TEE routing information.

TBD

The protocol generates the following two key pairs in run time to assist message communication and anonymous verification between TSM and TEE. 1. TEE Anonymous Key (TEE AIK): one derived key pair per TEE 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 is generated in the first GetDeviceState query. The public key of the key pair is returned to the caller Client Application for future TEE returned data validation. 2. TEE SP AIK: one derived key per SP in a device The purpose of this key pair is for a TSM to encrypt TA binary data when it sends a TA to a device for installation. This key is generated in the first SD creation for a SP. It is deleted when all SDs are removed for a SP in a device. With the presence of a TEE SP AIK, it isn't necessary to have a shared SP independent TEE AIK. For the initial release, this specification will not use TEE AIK.

The primary job of a TSM is to help a SP to manage its trusted applications. A TA is typically installed in a SD. A SD is commonly created for a SP. When a SP delegates its SD and TA management to a TSM, a SD is created on behalf of a TSM in a TEE and the owner of the SD is assigned to the TSM. A SD may be associated with a SP but the TSM has full privilege to manage the SD for the SP. Each SD for a SP is associated with only one TSM. When a SP changes TSM, a new SP SD must be created to associate with the new TSM. TEE will maintain a registry of TSM ID and SP SD ID mapping. From a SD ownership perspective SD tree is flat and there is only one level. A SD is associated with its owner. It is up to TEE's implementation how it maintains SD binding information for TSM and different SPs under the same TSM. It is an important decision in this protocol specification that a TEE doesn't need to know whether a TSM is authorized to manage SD for a SP. This authorization is implicitly triggered by a SP Client Application, which instructs what TSM it wants to use. A SD is always associated with a TSM in addition to its SP ID. A rogue TSM isn't able to do anything on an unauthorized SP's SD managed by another TSM. Since a TSM may support multiple SPs, sharing the same SD name for different SP creates a dependency in deleting a SD. A SD can be deleted only after all TAs associated with this SD is deleted. A SP cannot delete a Security Domain on its own with a TSM if a TSM decides to introduce such sharing. There are cases where multiple virtual SPs belong to the same organization, and a TSM chooses to use the same SD name for those SPs. This is totally up to the TSM implementation and out of scope of this specification.

There is a need of cryptographically binding proof about the owner of a SD in device. When a SD is created on behalf of a TSM, a future request from the TSM must present itself as a way that the TEE can verify it is the true owner. The certificate itself cannot reliably used as the owner because TSM may change its certificate. To this end, each TSM will be associated with a trusted identifier defined as an attribute in the TSM certificate. This field is kept the same when the TSM renew its certificates. A TSM CA is responsible to vet the requested TSM attribute value. This identifier value must not collide among different TSM providers, and one TSM shouldn't be able to claim the identifier used by another TSM provider. The certificate extension name to carry the identifier can initially use SubjectAltName:registeredID. A dedicated new extension name may be registered later. One common choice of the identifier value is the TSM's service URL. A CA can verify the domain ownership of the URL with the TSM in the certificate enrollment process. TEE can assign this certificate attribute value as the TSM owner ID for the SDs that are created for the TSM. An alternative way to represent a SD ownership by a TSM is to have a unique secret key upon SD creation such that only the creator TSM is able to produce a Proof-of-Possession (POP) data with the secret.

A sample Security Domain hierarchy for the TEE is shown below. [[TBD diagram]] The OTrP assumes that a SP managed by TSM1 cannot be managed by TSM2. Explicit permission grant should happen. SP can authorize TSM.

OTrP Agent is an Rich Application or SDK that facilitates communication between a TSM and TEE. It also provides interfaces for TSM 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. A Client Application interacts with a TSM, and turns around to pass messages received from TSM to OTrP Agent. In all cases, a Client Application needs to be able to identify an OTrP Agent that it can use.

OTrP Agent is responsible to communicate with TEE. It takes request messages from an application. The input data is mostly from a TSM that an application communicates. An application may also directly call OTrP Agent for some TA query functions. OTrP Agent may internally process a request from TSM. At least, it needs to know where to route a message, e.g. TEE instance. It doesn't need to process or verify message content. OTrP Agent returns TEE / TFW generated response messages to the caller. OTrP Agent isn't expected to handle any network connection with an application or TSM. OTrP Agent only needs to return an OTrP Agent error message if the TEE is not reachable for some reason. Other errors are represented as response messages returned from the TEE which will then be passed to the TSM.

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

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

OTrP Agent installation is commonly carried out at OEM time. A user can dynamically download and install an OTrP Agent on-demand. It is important to ensure a legitimate OTrP Agent is installed and used. If an OTrP Agent is compromised it may send rogue messages to TSM and TEE and introduce additional risks.

We anticipate only one shared OTrP Agent instance in a device. The device's TEE vendor will most probably supply one OTrP Agent. Potentially we expect some open source. With one shared OTrP Agent, the OTrP Agent provider is responsible to allow multiple TSMs and TEE providers to achieve interoperability. With a standard OTrP Agent interface, TSM can implement its own SDK for its SP Client Applications to work with this OTrP Agent. Multiple independent OTrP Agent providers can be used as long as they have standard interface to a Client Application or TSM SDK. Only one OTrP Agent is expected in a device. OTrP Protocol MUST specify a standard way for applications to lookup the active OTrP Agent instance in a device. TSM providers are generally expected to provide SDK for SP applications to interact with OTrP Agent for the TSM and TEE interaction.

OTrP Agent can be a bound service in Android with a service registration ID that a Client Application can use. This option allows a Client Application not to depend on any OTrP Agent SDK or provider. An OTrP Agent is responsible to detect and work with more than one TEE if a device has more than one. In this version, there is only one active TEE such that an OTrP Agent only needs to handle the active TEE.

The client application shall be responsible for relaying messages between the OTrP agent and the TSM. OTrP Agent APIs are defined below. An OTrP Agent in the form of an Android bound service can take this to be the functionality it provides via service call. The OTrP Agent implements this interface. If a failure is occured during calling API, an error message described in "Common Errors" section (see ) will be returned.

Description A Client Application will use this method of the OTrP Agent in a device to pass OTrP messages from a TSM. The method is responsible for interation with the TEE and for forwarding the input message to the TEE. It also returns TEE generated response message back to the Client Application. Input tsmInMsg - OTrP message generated in a TSM that is passed to this method from a Client Application. Output A TEE generated OTrP response message (which may be a successful response or be a response message containing an error raised within the TEE) for the client application to forward to the TSM. In the event of the OTrP agent not being able to communicate with the TEE, a OTrPAgentException shall be thrown.

Description A Client Application calls this method to query a TA's information. This method is carried out locally by the OTrP Agent without relying on a TSM if it has had the TEE SP AIK. Input spid - SP identifier of the TA taid - the identifier of the TA Output The API returns TA signer and TSM signer certificate along with other metadata information about a TA. The output is a JSON message that is generated by the TEE. It contains the following information: TSMID SP ID TA signer certificate TSM certificate The message is signed with TEE SP AIK private key. The Client Application is expected to consume the response as follows. The Client Application gets signed TA metadata, in particularly, the TA signer certificate. It is able to verify that the result is from device by checking signer against TEE SP AIK public key it gets in some earlier interaction with TSM. If this is a new Client Application in the device that hasn't had TEE SP AIK public key for the response verification, the application can contact TSM first to do GetDeviceState, and TSM will return TEE SP AIK public key to the app for this operation to proceed. JSON Message

", "tsmid": "", "spid": "", "signercert": "", "signercacerts": [ // the full list of CA certificate chain // including the root CA "cacert": "" ], "tsmcert": "", "tsmcacerts": [ // the full list of CA certificate chain // including the root CA "cacert":"" ] } } { "TAInformation": { "payload": "", "protected": "", "header": { "signer": {""} }, "signature": "" } } ]]> A sample JWK public key representation refers to an example in RFC 7517 .

During the Client App installation time, the Client App calls TSM to initialize device preparation The Client Application knows it wants to use a TA1 but the application doesn'tknow whether TA1 has been installed or not. It can use GP TEE Client API to check the existence of TA1 first. If it doesn't exist, it will contact TSM to initiate the TA1 installation. Note that TA1 could have been installed that is triggered by other Client Applications of the same service provider in the same device. The Client Application sends TSM the TA list that it depends on. The TSM will query a device for the Security Domains and TAs that have been installed, and instructs the device to install any dependent TAs that have not been installed. In general, TSM has the latest information of TA list and their status in a device because all operations are instructed by TSM. TSM has such visibility because all Security Domain deletion and TA deletion are managed by TSM; the TSM could have stored the state when a TA is installed, updated and deleted. There is also the possibility that an update command is carried out inside TEE but a response is never received in TSM. There is also possibility that some manual local reset is done in a device that the TSM isn't aware of the changes. TSM generates message: GetDeviceStateRequest The Client Application passes the JSON message GetDeviceStateRequest to OTrP Agent API processMessage. The communication between a Client Application and OTrP Agent is up to the implementation of OTrP Agent. OTrP Agent routes the message to the active TEE. Multiple TEE case: it is up to OTrP Agent to figure this out. This specification limits the support to only one active TEE, which is the typical case today. The target active TEE processes the received OTrP message, returns a JSON message GetDeviceStateResponse The OTrP Agent passes the GetDeviceStateResponse to the Client App The Client Application sends GetDeviceStateResponse to TSM TSM processes GetDeviceStateResponse Extract TEEspaik for the SP, signs TEEspaik with TSM signer key Examine SD list and TA list TSM continues to carry out other actions basing on the need. The next call could be instructing the device to install a dependent TA. Assume a dependent TA isn't in the device yet, the TSM may do the following: Create a SD to install the TA by sending a message CreateSDRequest. The message is sent back to the Client Application, and then OTrP Agent and TEE to process. Install a TA with a message InstallTARequest. If a Client Application depends on multiple TAs, the Client Application should expect multiple round trips of the TA installation message exchanges. At the last TSM and TEE operation, TSM returns the signed TEE SP AIK public key to the application The Client Application shall store the TEEspaik for future loaded TA trust check purpose. If the TSM finds that this is a fresh device that does not have any SD for the SP yet, then the TSM may move on to create a SD for the SP next. The TSM may move on to create a SD for the SP next. During Client Application installation, the application checks whether required Trusted Applications are already installed, which may have been provided by TEE. If needed, it will contact its TSM service to determine whether the device is ready or install TA list that this application needs.

The Client Application checks the device readiness: (a) whether it has a TEE; (b) whether it has TA that it depends. It may happen that TSM has removed TA this application depends on. The Client App calls OTrP Agent method "GetTAInformation" OTrP Agent queries the TEE to get TA information. If the given TA doesn't exist, an error is returned The Client App parses the TAInformation message. If the TA doesn't exist, the Client App calls its TSM to install the TA. If the TA exists, the Client App proceeds to call the TA.

The main OTrP Protocol component is the set of standard JSON messages created by TSM to deliver device SD and TA management commands to a device, and device attestation and response messages created by TEE to respond to TSM OTrP Messages. An OTrP Message is designed to provide end-to-end security. It is always signed by its creator. In addition, an OTrP Message is typically encrypted such that only the targeted device TEE or TSM provider is able to decrypt and view the actual content.

OTrP Messages use JSON format for JSON's simple readability and moderate data size in comparison with alternative TLV and XML formats. JSON Message security has developed JSON Web Signing and JSON Web Encryption standard in the IETF Workgroup JOSE, see JWS and JWE . The OTrP Messages in this protocol will leverage the basic JWS and JWE to handle JSON signing and encryption.

For each TSM command "xyz"", OTrP Protocol 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: TBSRequest": { } } ]]>

A corresponding OTrP Response message will be as follows. TBSResponse": { } } ]]>

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. ", "protected":"", "header": { , }, "signature":"" } ]]> OTrP signed messages only requires 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. [Request | Response]": { TBS[Request | Response] } } ]]> With the standard JWS message format, a signed OTrP Message looks like the following.

[Request | Response]": { "payload": "TBS[Request | Response]>", "protected":"", "header": , "signature":"" } } ]]> The top element " <name>[Signed][Request | Response]" cannot be fully trusted to match the content because it doesn't participate 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 OTrP Agent for routing purpose. Such information is excluded from JSON encryption. The device's signer certificate itself is encrypted. The overall final message is a standard signed JSON message. As required by JSW/JWE, those JWE and JWS related elements will be BASE64URL encoded. Other binary data elements specific to the OTrP specification are BASE64 encoded. This specification will identify 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. In order to protect privacy, it is important that the device's certificate is released only to a trusted TSM, and that it is encrypted. The TSM will need to know the device certificate, but untrusted parties must not be able to get the device certificate. All OTrP messaging conversations between a TSM and device begin with GetDeviceStateRequest / GetDeviceStateResponse. These messages have elements built into them to exchange signing certificates, described in the "Detailed Message Specification" section. Any subsequent messages in the conversation that follow on from this are implicitly using the same certificates for signing/encryption, and as a result the certificates or references may be ommitted in those subsequent messages. In other words, the signing key identifier in the use of JWS and JWE here may be absent in the subsequent messages after the initial GetDeviceState query. This has implication on the TEE and TSM implementation: they have to cache the signer certificates for the subsequent message signature validation in the session. It may be easier for a TSM service to cache transaction session information but not so for a TEE in a device. A TSM should check a device's capability to decide whether it should include its TSM signer certificate and OCSP data in each subsequent request message. The device's caching capability is reported 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 SHALL be used for RSA with SHA256 and ECDSA with SHA256. If RSA with SHA256 is used, the JSON web algorithm representation is as follows. {"alg":"RS256"} The (BASE64URL encoded) "protected" header property in a signed message looks like the following: "protected":"eyJhbGciOiJSUzI1NiJ9" If ECSDA with P-256 curve and SHA256 are used for signing, the JSON signing algorithm representation is as follows. {"alg":"ES256"} The value for the "protected" field will be the following. eyJhbGciOiJFUzI1NiJ9

Thus a common OTrP signed message with ES256 looks like the following. ", "protected": "eyJhbGciOiJFUzI1NiJ9", "signature":"" } ]]> 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. OTrP recipient typically has an asymmetric key pair. Therefore CEK will be encrypted by the recipient's public key. Symmetric encryption shall use the following algorithm. {"enc":"A128CBC-HS256"} This algorithm represents encryption with AES 128 in CBC mode with HMAC SHA 256 for integrity. The value of the property "protected" in a JWE message will be eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0

An encrypted JSON message looks like the following. " }, "encrypted_key": "" } ], "iv": "", "ciphertext": "", "tag": "" } ]]> 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 are mandatory support in TEE and TSM: RS256 ES256 is optional to support.

The following JSON authenticated encryption algorithm is mandatory support in TEE and TSM. A128CBC-HS256 A256CBC-HS512 is optional to support.

The following JSON key management algorithm is mandatory support in TEE and TSM. RSA1_5 ECDH-ES+A128KW and ECDH-ES+A256KW are optional to support.

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

", "error-message": "" } "ver": "" ]]>

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. A TSM queries a device's current state with a message GetDeviceStateRequest. A device TEE will report its version, its FW version, and list of all SD and TA in the device that is managed by the requesting TSM. TSM may determine whether the device is trustworthy and decide to carry out additional commands according to the response from this query. A TSM instructs a device TEE to create a SD for a SP. The recipient TEE will check whether the requesting TSM is trustworthy. A TSM instructs a device TEE to update an existing SD. A typical update need comes from SP certificate change, TSM certificate change and so on. The recipient TEE will verify whether the TSM is trustworthy and owns the SD. A TSM instructs a device TEE to delete an existing SD. A TEE conditionally deletes TAs loaded in the SD according to a request parameter. A SD cannot be deleted until all TAs in this SD are deleted. If this is the last SD for a SP, TEE can also delete TEE SP AIK key for this SP. A TSM instructs a device to install a TA into a SD for a SP. TEE in a device will check whether the TSM and TA are trustworthy. A TSM instructs a device to update a TA into a SD for a SP. The change may commonly be bug fix for a previously installed TA. A TSM instructs a device to delete a TA. TEE in a device will check whether the TSM and TA are trustworthy.

For each command that a TSM wants to send to a device, the TSM generates a request message. This is typically triggered by a Client Application that uses the TSM. The Client Application initiates contact with the TSM and receives TSM OTrP Request messages according to the TSM's implementation. The Client Application forwards the OTrP message to an OTrP Agent in the device, which in turn sends the message to the active TEE in the device. The current version of specification assumes that each device has only one active TEE, and OTrP Agent is responsible to connect to the active TEE. This is the case today with devices in the market. Upon TEE responding with a request, the OTrP Agent gets OTrP response messages back to the Client Application that sends the request. In case the target TEE fails to respond the request, the OTrP Agent will be responsible to generate an error message to reply the Client Application. The Client Application forwards any data it received to its TSM.

When the first new Security Domain is created in TEE for a 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 device's TEE key pair.

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

This is the first command that a TSM will query a device. This command is triggered when a SP's Client Application contacts its TSM to check whether the underlying device is ready for TA operations. This command queries a device's current TEE state. A device TEE will report its version, its FW version, and list of all SD and TA in the device that is managed by the requesting TSM. TSM may determine whether the device is trustworthy and decide to carry out additional commands according to the response from this query. The request message of this command is signed by TSM. The response message from TEE is encrypted. A random message encryption key (MK) is generated by TEE, and this encrypted key is encrypted by the receiving TSM public key such that only the TSM who sent the request is able to decrypt and view the response message.

", "tid": "", "ocspdat": "", "icaocspdat": "", "supportedsigalgs": "" } } ]]> The request message consists of the following data elements: version of the message format a unique request ID generated by the TSM a unique transaction ID to trace request and response. This can be from a prior transaction's tid field, and can be used in the subsequent message exchanges in this TSM session. The combination of rid and tid should be made unique. OCSP stapling data for the TSM certificate. The TSM provides OCSP data such that a recipient TEE can validate the validity of the TSM certificate without making its own external OCSP service call. This is a mandate field. OCSP stapling data for the intermediate CA certificates of the TSM certificate up to the root. A TEE side can cache CA OCSP data such that this value isn't needed in each call. an optional property to list the signing algorithms that TSM is able to support. A recipient TEE should choose algorithm in this list to sign its response message if this property is present in a request.

The final request message is JSON signed message of the above raw JSON data with TSM's certificate. ", "protected": "", "header": { "x5c": "" }, "signature":"" } } ]]> 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 TSM signer certificate up to the root CA certificate.

Upon receiving a request message GetDeviceStateRequest at a TEE, the TEE must validate a request: Validate JSON message signing Validate that the request TSM certificate is chained to a trusted CA that the TEE embeds as its trust anchor. Cache the CA OCSP stapling data and certificate revocation check status for other subsequent requests. A TEE can use its own clock time for the OCSP stapling data validation. Validate JSON message signing Collect Firmware signed data This is a capability in ARM architecture that allows a TEE to query Firmware to get FW signed data. Collect SD information for the SD owned by this TSM

Firmware isn't expected to process or produce JSON data. It is expected to just sign some raw bytes of data. The data to be signed by TFW key needs be some unique random data each time. The (UTF-8 encoded) "tid" value from the GetDeviceStateTBSRequest shall be signed by the firmware. TSM isn't expected to parse TFW data except the signature validation and signer trust path validation. It is possible that a TEE can get some valid TFW signed data from another device. This is part of the TEE trust assumption where TSM will trust the TFW data supplied by the TEE. The TFW trust is more concerned by TEE than a TSM where a TEE needs to ensure that the underlying device firmware is trustworthy.

", "cert": "", "sigalg": "Signing method", "sig": "" } ]]> It is expected that FW use a standard signature methods for maximal interoperability with TSM providers. The mandatory support list of signing algorithm is RSA with SHA256. The JSON object above is constructed by TEE with data returned from FW. It isn't a standard JSON signed object. The signer information and data to be signed must be specially processed by TSM according to definition given here. The data to be signed is the raw data.

TSM providers shall support the following signature methods. A firmware provider can choose one of the methods in signature generation. RSA with SHA256 ECDSA with SHA 256 The value of "sigalg" in the TfwData JSON message should use one of the following: RS256 ES256

Upon successful request validation, the TEE information is collected. There is no change in the TEE in the device. The response message shall be encrypted where the encryption key shall be a symmetric key that is wrapped by TSM's public key. The JSON Content Encryption Key (CEK) is used for this purpose.

The message has the following structure.

", "tid": "", "signerreq": "true | false about whether TSM needs to send signer data again in subsequent messages", "edsi": "" } } ]]> where true if the TSM should send its signer certificate and OCSP data again in the subsequent messages. The value may be "false" if the TEE caches the TSM's signer certificate and OCSP status. the request ID from the request message the tid from the request message the main data element whose value is JSON encrypted message over the following Device State Information (DSI). The Device State Information (DSI) message consists of the following.

" "cert": "", "sigalg": "Signing method", "sig": "" }, "tee": { "name": "", "ver": "", "cert": "", "cacert": "", "sdlist": { "cnt": "", "sd": [ { "name": "", "spid": "", "talist": [ { "taid": "", "taname": "" // optional } ] } ] }, "teeaiklist": [ { "spaik": "", "spaiktype": "", "spid": "" } ] } } } ]]> The encrypted JSON message looks like the following.

", "recipients": [ { "header": { "alg": "RSA1_5" }, "encrypted_key": "" } ], "iv": "", "ciphertext": "", "tag": "" } ]]> Assume we encrypt plaintext with AES 128 in CBC mode with HMAC SHA 256 for integrity, the encryption algorithm header is: {"enc":"A128CBC-HS256"} The value of the property "protected" in the above JWE message will be eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 In other words, the above message looks like the following:

" } ], "iv": "", "ciphertext": "", "tag": "" } ]]> The full response message looks like the following:

", "tid": "", "signerreq": "true | false", "edsi": { "protected": "", "recipients": [ { "header": { "alg": "RSA1_5" }, "encrypted_key": "" } ], "iv": "", "ciphertext": "", "tag": "" } } } ]]> The CEK will be encrypted by the TSM public key in the device. The TEE signed message has the following structure.

", "protected": "", "signature": "" } } ]]> The signing algorithm shall use SHA256 with respective key type, see Section . The final response message GetDeviceStateResponse consists of array of TEE response. A typical device will have only one active TEE. An OTrP Agent is responsible to collect TEE response for all active TEEs in the future.

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 TEE meets the following conditions with a request message: (1) The request from a TSM has an invalid message structure; mandatory information is absent in the message. undefined member or structure is included. (2) TEE fails to verify signature of the message or fails to decrypt its contents. (3) etc. TEE receives the version of message that TEE can't deal with. TEE receives a request message encoded with cryptographic algorithms that TEE doesn't support. TEE may consider the underlying device firmware be not trustworthy. TEE needs to make sure whether the TSM is trustworthy by checking the validity of TSM certificate and OCSP stapling data and so on. If TEE finds TSM is not reliable, it may return this error code. TEE fails to respond to a TSM request. The OTrP Agent will construct an error message in responding the TSM's request. And also if TEE fails to process a request because of its internal error, it will return this error code. The response message will look like the following if the TEE signing can work to sign the error response message.

", "tid": "", "reason": {"error-code":""} "supportedsigalgs": "" } } ]]> where an optional property to list the JWS signing algorithms that the active TEE supports. When a TSM sends a signed message that the TEE isn't able to validate, it can include signature algorithms that it is able to consume in this status report. A TSM can generate a new request message to retry the management task with a TEE supported signing algorithm. If TEE isn't able to sign an error message, a general error message should be returned.

Upon receiving a message of the type GetDeviceStateResponse at a TSM, the TSM should validate the following. Parse to get list of GetDeviceTEEStateResponse JSON object Parse the JSON "payload" property and decrypt the JSON element "edsi" The decrypted message contains the TEE signer certificate Validate GetDeviceTEEStateResponse JSON signature. The signer certificate is extracted from the decrypted message in the last step. Extract TEE information and check it against its TEE acceptance policy. Extract TFW signed element, and check the signer and data integration against its TFW policy Check the SD list and TA list and prepare for a subsequent command such as "CreateSD" if it needs to have a new SD for a SP.

This command is typically preceded with GetDeviceState command that has acquired the device information of the target device by the TSM. TSM sends such a command to instruct a TEE to create a new Security Domain for a SP. A TSM sends an OTrP Request message CreateSDRequest to a device TEE to create a Security Domain for a SP. Such a request is signed by TSM where the TSM 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: TSM as the owner. The owner identifier is a registered unique TSM ID that is stored in the TSM certificate. SP identified by its TA signer certificate as the authorization. A TSM can add more than one SP certificates to a SD. A Trusted Application that is signed by a matching SP signer certificate for a SD is eligible to be installed into that SD. The TA installation into a SD by a subsequent InstallTARequest message may be instructed from TSM or a Client Application.

The request message for CreateSD has the following JSON format. ", "tid": "", // this may be from prior message "tee": "", "nextdsi": "true | false", "dsihash": "", "content": ENCRYPTED { // this piece of JSON data will be // encrypted "spid": "", "sdname": "", "spcert": "", "tsmid": "", "did": "" } } } ]]> In the message, A unique value to identify this request A unique value to identify this transaction. It can have the same value for the tid in the preceding GetDeviceStateRequest. TEE ID returned from the previous response GetDeviceStateResponse Indicates whether the up to date Device State Information (DSI) should be returned in the response to this request. The BASE64 encoded SHA256 hash value of the DSI data returned in the prior TSM operation with this target TEE. This value is always included such that a receiving TEE can check whether the device state has changed since its last query. It helps enforce SD update order in the right sequence without accidently overwrite an update that was done simultaneously. The "content" is a JSON encrypted message that includes actual input for the SD creation. The encryption key is TSMmk that is encrypted by the target TEE's public key. The entire message is signed by the TSM private key TSMpriv. A separate TSMmk isn't used in the latest specification because JSON encryption will use a content encryption key for exactly the same purpose. A unique id assigned by the TSM for its SP. It should be unique within a TSM namespace. a name unique to the SP. TSM should ensure it is unique for each SP. The SP's TA signer certificate is included in the request. This certificate will be stored by the device TEE and uses it to check against TA installation. Only if a TA is signed by a matching spcert associated with a SD the TA will be installed into the SD. SD owner claim by TSM - A SD owned by a TSM will be associated with a trusted identifier defined as an attribute in the signer TSM certificate. TEE will be responsible to assign this ID to the SD. The TSM certificate attribute for this attribute TSMID must be vetted by the TSM signer issuing CA. With this trusted identifier, SD query at TEE can be fast upon TSM signer verification. The SHA256 hash of the binary encoded device TEE certificate. The encryption key CEK will be encrypted the recipient TEE's public key. This hash value in the "did" property allows the recipient TEE to check whether it is the expected target to receive such a request. If this isn't given, an OTrP message for device 2 could be sent to device 1. It is optional for TEE to check because the successful decryption of the request message with this device's TEE private key already proves it is the target. This explicit hash value makes the protocol not dependent on message encryption method in future.

Following is the OTrP message template, the full request is signed message over the CreateSDTBSRequest as follows. ", "protected":"", "header": , "signature":"" } } ]]> TSM signer certificate is included in the "header" property.

Upon receiving a request message CreateSDRequest at a TEE, the TEE must validate a request: Validate the JSON request message Validate JSON message signing Validate that the request TSM certificate is chained to a trusted CA that the TEE embeds as its trust anchor Compare dsihash with its current state to make sure nothing has changed since this request was sent. Decrypt to get the plaintext of the content: (a) spid, (b) sd name, (c) did Check that a SPID is supplied spcert check: check it is a valid certificate (signature and format verification only) Check "did" is the SHA256 hash of its TEEcert BER raw binary data Check whether the requested SD already exists for the SP Check TSMID in the request matches TSM certificate's TSM ID attribute Create action Create a SD for the SP with the given name Assign the TSMID from the TSMCert to this SD Assign the SPID and SPCert to this SD Check whether a TEE SP AIK keypair already exists for the given SP ID Create TEE SP AIK keypair if it doesn't exist for the given SP ID Generate new DSI data if the request asks for updated DSI Construct CreateSDResponse message Create raw content Operation status "did" or full signer certificate information, TEE SP AIK public key if DSI isn't going to be included Updated DSI data if requested if the request asks for it The response message is encrypted with the same JWE CEK of the request without recreating a new content encryption key. The encrypted message is signed with TEEpriv. The signer information ("did" or TEEcert) is encrypted. Deliver response message. (a) OTrP Agent returns this to the app; (b) The app passes this back to TSM TSM process. (a) TSM processes the response message; (b) TSM can look up signer certificate from device ID "did". If a request is illegitimate or signature doesn't pass, a "status" property in the response will indicate the error code and cause.

The response message for a CreateSDRequest contains the following content.

", "rid": "", "tid": "", "content": ENCRYPTED { "reason":"", // optional "did": "", "sdname": "", "teespaik": "", "dsi": "" } } } ]]> In the response message, the following fields MUST be supplied. The SHA256 hash of the device TEE certificate. This shows the device ID explicitly to the receiving TSM. The newly generated SP AIK public key for the given SP. This is an optional value if the device has had another domain for the SP that has triggered TEE SP AIK keypair for this specific SP. There is possible extreme error case where TEE isn't reachable or the TEE final response generation itself fails. In this case, TSM should still receive a response from the OTrP Agent. OTrP Agent is able to detect such error from TEE. In this case, a general error response message should be returned, assuming OTrP Agent even doesn't know any content and information about the request message. In other words, TSM should expect receive a TEE successfully signed JSON message, or a general "status" message.

", "protected": { "" }, "signature": "" } } ]]> A response message type "status" will be returned when TEE totally fails to respond. OTrP Agent is responsible to create this message.

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

This TSM initiated command can update a SP's SD that it manages for the following need. (a) Update SP signer certificate; (b) Add SP signer certificate when a SP uses multiple to sign TA binary; (c) Update SP ID. The TSM presents the proof of the SD ownership to TEE, and includes related information in its signed message. The entire request is also encrypted for the end-to-end confidentiality.

The request message for UpdateSD has the following JSON format. ", "tid": "", // this may be from prior message "tee": "", "nextdsi": "true | false", "dsihash": "", "content": ENCRYPTED { // this piece of JSON will be encrypted "tsmid": "", "spid": "", "sdname": "", "changes": { "newsdname": "", // Optional "newspid": "", // Optional "spcert": [""], // Optional "deloldspcert": [""], // Optional "renewteespaik": "true | false" } } } } ]]> In the message, A unique value to identify this request A unique value to identify this transaction. It can have the same value for the tid in the preceding GetDeviceStateRequest. TEE ID returned from the previous response GetDeviceStateResponse Indicates whether the up to date Device State Information (DSI) should be returned in the response to this request. The BASE64 encoded SHA256 hash value of the DSI data returned in the prior TSM operation with this target TEE. This value is always included such that a receiving TEE can check whether the device state has changed since its last query. It helps enforce SD update order in the right sequence without accidently overwrite an update that was done simultaneously. The "content" is a JSON encrypted message that includes actual input for the SD update. The standard JSON content encryption key (CEK) is used, and the CEK is encrypted by the target TEE's public key. SD owner claim by TSM - A SD owned by a TSM will be associated with a trusted identifier defined as an attribute in the signer TSM certificate. the identifier of the SP whose SD will be updated. This value is still needed because SD name is considered unique within a SP only. the name of the target SD to be updated. its content consists of changes that should be updated in the given SD. the new name of the target SD to be assigned if this value is present. the new SP ID of the target SD to be assigned if this value is present. a new TA signer certificate of this SP to be added to the SD if this is present. a SP certificate assigned into the SD should be deleted if this is present. The value is the SHA256 fingerprint of the old SP certificate. the value should be 'true' or 'false'. If it is present and the value is 'true', TEE should regenerate TEE SP AIK for this SD's owner SP. The newly generated TEE SP AIK for the SP must be returned in the response message of this request. If there are more than one SD for the SP, a new SPID for one of the domain will always trigger a new teespaik generation as if a new SP is introduced to the TEE.

Following the OTrP message template, the full request is signed message over the UpdateSDTBSRequest as follows. ", "protected":"", "header": , "signature":"" } } ]]> TSM signer certificate is included in the "header" property.

Upon receiving a request message UpdateSDRequest at a TEE, the TEE must validate a request: Validate the JSON request message Validate JSON message signing Validate that the request TSM certificate is chained to a trusted CA that the TEE embeds as its trust anchor. TSM certificate status check is generally not needed anymore in this request. The prior request should have validated the TSM certificate's revocation status Compare dsihash with TEE cached last response DSI data to this TSM Decrypt to get the plaintext of the content Check that the target SD name is supplied Check whether the requested SD exists Check that the TSM owns this TSM by verifying TSMID in the SD matches TSM certificate's TSM ID attribute Now the TEE is ready to carry out update listed in the "content" message Update action If "newsdname" is given, replace the SD name for the SD to the new value If "newspid" is given, replace the SP ID assigned to this SD with the given new value If "spcert" is given, add this new SP certificate to the SD. If "deloldspcert" is present in the content, check previously assigned SP certificates to this SD, and delete the one that matches the given certificate hash value. If "renewteespaik" is given and has a value as "true", generate a new TEE SP AIK keypair, and replace the old one with this. Generate new DSI data if the request asks for updated DSI Now the TEE is ready to construct the response message Construct UpdateSDResponse message Create raw content Operation status "did" or full signer certificate information, TEE SP AIK public key if DSI isn't going to be included Updated DSI data if requested if the request asks for it The response message is encrypted with the same JWE CEK of the request without recreating a new content encryption key. The encrypted message is signed with TEEpriv. The signer information ("did" or TEEcert) is encrypted. Deliver response message. (a) OTrP Agent returns this to the app; (b) The app passes this back to TSM TSM process. (a) TSM processes the response message; (b) TSM can look up signer certificate from device ID "did". If a request is illegitimate or signature doesn't pass, a "status" property in the response will indicate the error code and cause.

The response message for a UpdateSDRequest contains the following content.

", "rid": "", "tid": "", "content": ENCRYPTED { "reason":"", // optional "did": "", "cert": "", // optional "teespaik": "", "teespaiktype": "", "dsi": "" } } } ]]> In the response message, the following fields MUST be supplied. The request should have known the signer certificate of this device from a prior request. This hash value of the device TEE certificate serves as a quick identifier only. Full device certificate isn't necessary. the newly generated SP AIK public key for the given SP if TEE SP AIK for the SP is asked to be renewed in the request. This is an optional value if "dsi" is included in the response, which will contain all up to date TEE SP AIK key pairs. Similar to the template for the creation of the encrypted and signed CreateSDResponse, the final UpdateSDResponse looks like the following.

", "protected": { "" }, "signature": "" } } ]]> A response message type "status" will be returned when TEE totally fails to respond. OTrP Agent is responsible to create this message.

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

A TSM sends a DeleteSDRequest message to TEE to delete a specified SD that it owns. A 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 TEE to delete all related TAs in a SD and then delete the SD. The target TEE will operate with the following logic. Lookup given SD specified in the request message Check that the TSM owns the SD Check that the device state hasn't changed since the last operation Check whether there are TAs in this SD If TA exists in a SD, check whether the request instructs whether TA should be deleted. If the request instructs TEE to delete TAs, delete all TAs in this SD. If the request doesn't instruct the TEE to delete TAs, return an error "ERR_SD_NOT_EMPTY". Delete SD If this is the last SD of this SP, delete TEE SP AIK key

The request message for DeleteSD has the following JSON format. ", "tid": "", // this may be from prior message "tee": "", "nextdsi": "true | false", "dsihash": "", "content": ENCRYPTED { // this piece of JSON will be encrypted "tsmid": "", "sdname": "", "deleteta": "true | false" } } } ]]> In the message, A unique value to identify this request A unique value to identify this transaction. It can have the same value for the tid in the preceding GetDeviceStateRequest. TEE ID returned from the previous response GetDeviceStateResponse Indicates whether the up to date Device State Information (DSI) should be returned in the response to this request. The BASE64 encoded SHA256 hash value of the DSI data returned in the prior TSM operation with this target TEE. This value is always included such that a receiving TEE can check whether the device state has changed since its last query. It helps enforce SD update order in the right sequence without accidently overwrite an update that was done simultaneously. The "content" is a JSON encrypted message that includes actual input for the SD update. The standard JSON content encryption key (CEK) is used, and the CEK is encrypted by the target TEE's public key. SD owner claim by TSM - A SD owned by a TSM will be associated with a trusted identifier defined as an attribute in the signer TSM certificate. the name of the target SD to be updated. the value should be 'true' or 'false'. If it is present and the value is 'true', TEE should delete all TAs associated with the SD in the device.

Following the OTrP message template, the full request is signed message over the DeleteSDTBSRequest as follows. ", "protected":"", "header": , "signature":"" } } ]]> TSM signer certificate is included in the "header" property.

Upon receiving a request message DeleteSDRequest at a TEE, the TEE must validate a request: Validate the JSON request message Validate JSON message signing Validate that the request TSM certificate is chained to a trusted CA that the TEE embeds as its trust anchor. TSM certificate status check is generally not needed anymore in this request. The prior request should have validated the TSM certificate's revocation status Compare dsihash with TEE cached last response DSI data to this TSM Decrypt to get the plaintext of the content Check that the target SD name is supplied Check whether the requested SD exists Check that the TSM owns this TSM by verifying TSMID in the SD matches TSM certificate's TSM ID attribute Now the TEE is ready to carry out update listed in the "content" message Deletion action Check TA existence in this SD If "deleteta" is "true", delete all TAs in this SD. If the value of "deleteta" is "false" and some TA exists, return an error "ERR_SD_NOT_EMPTY" Delete the SD Delete TEE SP AIK key pair if this SD is the last one for the SP Now the TEE is ready to construct the response message Construct DeleteSDResponse message Create response content Operation status "did" or full signer certificate information, Updated DSI data if requested if the request asks for it The response message is encrypted with the same JWE CEK of the request without recreating a new content encryption key. The encrypted message is signed with TEEpriv. The signer information ("did" or TEEcert) is encrypted. Deliver response message. (a) OTrP Agent returns this to the app; (b) The app passes this back to TSM TSM process. (a) TSM processes the response message; (b) TSM can look up signer certificate from device ID "did". If a request is illegitimate or signature doesn't pass, a "status" property in the response will indicate the error code and cause.

The response message for a DeleteSDRequest contains the following content.

", "rid": "", "tid": "", "content": ENCRYPTED { "reason":"", // optional "did": "", "dsi": "" } } } ]]> In the response message, the following fields MUST be supplied. The request should have known the signer certificate of this device from a prior request. This hash value of the device TEE certificate serves as a quick identifier only. Full device certificate isn't necessary. The final DeleteSDResponse looks like the following.

", "protected": { "" }, "signature": "" } }]]> A response message type "status" will be returned when TEE totally fails to respond. OTrP Agent is responsible to create this message.

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

This protocol doesn't introduce a TA container concept. All the TA authorization and management will be up to TEE implementation. The following three TA management commands will be supported. InstallTA - provision a TA by TSM UpdateTA - update a TA by TSM DeleteTA - remove TA registration information with a SD, remove TA binary from TEE, remove all TA related data in TEE

TA binary data can be from two sources: TSM supplies the signed TA binary Client Application supplies the TA binary This specification considers only the first case where TSM supplies TA binary. When such a request is received by TEE, a SD is already created and is ready to take TA installation. A TSM sends the following information in message InstallTARequest to a target TEE: The target SD information: SP ID and SD name Encrypted TA binary data. TA data is encrypted with TEE SP AIK. TA metadata. It is optional to include SP signer certificate for the SD to add if the SP has changed signer since the SD was created. TEE processes command given by TSM to install TA into a SP's SD. It does the following: Validation TEE validates TSM message authenticity Decrypt to get request content Lookup SD with SD name Checks that the TSM owns the SD Checks DSI hash matches that the device state hasn't changed TA validation Decrypt to get TA binary and any personalization data with "TEE SP AIK private key" Check that SP ID is the one that is registered with the SP SD TA signer is either the newly given SP certificate or the one in SD. The TA signing method is specific to TEE. This specification doesn't define how a TA should be signed. If a TA signer is given in the request, add this signer into the SD. TA installation TEE re-encrypts TA binary and its personalization data with its own method TEE enrolls and stores the TA onto TEE secure storage area. Construct a response message. This involves signing a encrypted status information for the requesting TSM.