Open Trust Protocol CBOR EncodingAlibaba GroupBeijingBeijing+86-1391788933maxpassion@gmail.comAlibaba GroupBeijingBeijing+86-15210569677qiangwu.fq@alibaba-inc.com
Internet Area
This document specifies the Open Trust Protocol (OTrP) using RFC 7049
Concise Binary Object Representation(CBOR).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.This document uses CBOR to encode the operations in OTrP.
The goal is to improve the efficiency of information transmission in bandwidth-constrained scenarios.
This document will not change the OTrP entity and the trust model. This document will re-use the TA remote security mechanism as defined in .This document uses CBOR to encode the contents of JSON data as defined in .uses JOSE for JSON content encryption, signatures and Message Authentication Code (MAC) operations.
This document uses the CBOR Object Encryption and Signing (COSE) standard which does the similar thing for CBOR encoding format.This document uses CDDL as defined in to describe the CBOR content defined in this document.
In bandwidth constrained scenario, using JSON/JOSE to encode OTrP message may not efficient. Using CBOR as encoding scheme can improve the transmission efficiency.
More use cases can be found in .
If 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.
CBOR Message:' /
{
"reserved":false,
\ crit \ 2:[
"reserved"
]
} / ,
/ unprotected / {},
/ payload / 'the TAInformationTBS CBOR above.',
/ signatures / [
[
/ protected / h'' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h''
]
]
]
)
]]> When using CBOR as encoding method, the OTrP Protocol is composed of a set of standard CBOR messages
created by TSM to deliver SD and TA management commands to a device and the device response messages created by
TEE.
An OTrP Request message uses the following format:(TBD)
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 COSE CBOR Serialization Syntax.
The following example is a general COSE object:
For each message in the following sections all CBOR 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.
The request message consists of the following data elements: ver - version of the message format rid - a unique request ID generated by the TSM tid - a unique transaction ID to trace request and response. This can be from a prior transaction's tid field, and can be used in the subsequent message exchanges in this TSM session. The combination of rid and tid should be made unique.ocspdat - 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. icaocspdat - 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.supportedsigalgs - 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 COSE signed message of the above raw CBOR data with TSM's certificate. Upon receiving a request message GetDeviceStateRequest at a TEE, the TEE must validate the request: 1. Validate CBOR message signing 2. 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.3. Collect Firmware signed data 4. Collect SD information for the SD owned by this TSM The response message shall be encrypted where the encryption key shall be a symmetric key that is wrapped by TSM's public key.
COSE_recipient holds the encrypted keys for recipients to encrypt the respond message .The message has the following structure. The Device State Information (DSI) message consists of the following.TBDTBDThis 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.The request message for CreateSD has the following CBOR format.Following is the OTrP message template, the full request is signed message over the CreateSDTBSRequest as follows. Upon receiving a request message CreateSDRequest at a TEE,the TEE must validate a request.
The process of Validate the CBOR request message,Create action,Construct CreateSDResponse
message,Deliver response message and TSM process are same as described in (8.2.1.2 Request processing requirements at a TEE) The response message for a CreateSDRequest contains the following content. TBDTBDTBDTBDTBDTBDThe following three TA management commands will be supported. o InstallTA - provision a TA by TSM o UpdateTA - update a TA by TSM o DeleteTA - remove TA registration information with a SD, remove TA binary from TEE, remove all TA related data in TEE The request message for InstallTA has the following format.The InstallTAResponse message: TBDTBDTBDTBDTBDThe Open Trust Protocol (OTrP)CBOR data definition language (CDDL): a notational convention to express CBOR data structures Use case of Open Trust Protocol