Network Working Group D. Liu Internet-Draft Q. Fang Intended status: Standards Track Alibaba Group Expires: September 14, 2017 March 13, 2017 Open Trust Protocol CBOR Encoding draft-liu-opentrustprotocol-cbor-00.txt Abstract This document specifies the Open Trust Protocol (OTrP) using RFC 7049 Concise Binary Object Representation(CBOR). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 14, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Liu & Fang Expires September 14, 2017 [Page 1] Internet-Draft opentrustprotocol-CBOR March 2017 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Scenario of using CBOR . . . . . . . . . . . . . . . . . . . 3 3. OTrP Agent . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. API getTAInformation . . . . . . . . . . . . . . . . . . 3 3.2. OTrP Messages using CBOR Encoding . . . . . . . . . . . . 4 3.2.1. Request and Response Message Template . . . . . . . . 4 3.2.2. Signed Request and Response Message Structure . . . . 5 3.3. Detailed Messages Specification-8 . . . . . . . . . . . . 6 3.3.1. GetDeviceState-8.1 . . . . . . . . . . . . . . . . . 6 3.3.2. Security Domain Management-8.2 . . . . . . . . . . . 10 3.3.3. Trusted Application Management-8.3 . . . . . . . . . 13 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Normative References . . . . . . . . . . . . . . . . . . 15 4.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction 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 [draft-pei-opentrustprotocol]. This document uses CBOR to encode the contents of JSON data as defined in [draft-pei-opentrustprotocol]. [draft-pei-opentrustprotocol]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 [draft-greevenbosch-appsawg-cbor-cddl]to describe the CBOR content defined in this document. Liu & Fang Expires September 14, 2017 [Page 2] Internet-Draft opentrustprotocol-CBOR March 2017 2. Scenario of using CBOR 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 [draft-liu-opentrustprotocol-usecase]. 3. OTrP Agent 3.1. API getTAInformation 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: TAInformationTBS={ taid : tstr, ;TA Identifier from the input tsmid : tstr, ;TSM ID for the Security Domain where this TA resides signercert : tstr, ;certificate data of the TA binary application's signer certificate signercacerts : [*cacert], ;CA certificate data of the TA binary application's signer certificate tsmcert : bstr, ;certificate data of the TSM that manages this TA tsmcacerts : [*cacert] ;CA certificate data of the TSM that manages this TA } cacert=( cacert : bstr ) Liu & Fang Expires September 14, 2017 [Page 3] Internet-Draft opentrustprotocol-CBOR March 2017 98( [ / protected / h'' / { "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'' ] ] ] ) 3.2. OTrP Messages using CBOR Encoding 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. 3.2.1. Request and Response Message Template An OTrP Request message uses the following format:(TBD) Liu & Fang Expires September 14, 2017 [Page 4] Internet-Draft opentrustprotocol-CBOR March 2017 { "TBSRequest": { } } A corresponding OTrP Response message will be as follows. { "TBSResponse": { } } 3.2.2. Signed Request and Response Message Structure 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: COSE_Sign = [ Headers, payload : bstr / nil, signatures : [+ COSE_Signature] ] COSE_Signature = [ Headers, signature : bstr ] COSE_Encrypt = [ Headers, ciphertext : bstr / nil, recipients : [+COSE_recipient] ] COSE_recipient = [ Headers, ciphertext : bstr / nil, ? recipients : [+COSE_recipient] ] Liu & Fang Expires September 14, 2017 [Page 5] Internet-Draft opentrustprotocol-CBOR March 2017 3.3. Detailed Messages Specification-8 For each message in the following sections all CBOR elements are mandatory if it isn't explicitly indicated as optional. 3.3.1. GetDeviceState-8.1 3.3.1.1. GetDeviceStateRequest message-8.1.1 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. GetDeviceStateTBSRequest={ ver : tstr, ;1.0 rid : tstr, ;Unique request ID tid : tstr, ;transaction ID ocspdat : bstr, ;OCSP stapling data of TSM certificate icaocspdat : bstr, ;OCSP stapling data for TSM CA certificates supportedsigalgs : bstr, ;comma separated signing algorithms } The request message consists of the following data elements: ver - version of the message format rid - a unique request ID generated by the TSM 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. Liu & Fang Expires September 14, 2017 [Page 6] Internet-Draft opentrustprotocol-CBOR March 2017 The final request message is COSE signed message of the above raw CBOR data with TSM's certificate. 98( [ / protected / h'', / unprotected / {}, / payload / 'GetDeviceStateTBSRequest CBOR above.', / signatures / [ [ / protected / h'' / { \ alg \ 1:-7 \ ECDSA 256 \ } / , / unprotected / { / kid / 4:'11' }, / signature / h'signature contents signed by TSM private key' ] ] ] ) 3.3.1.2. Request processing requirements at a TEE-8.1.2 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 3.3.1.3. Post Conditions-8.1.4 The response message shall be encrypted where the encryption key shall be a symmetric key that is wrapped by TSM's public key. Liu & Fang Expires September 14, 2017 [Page 7] Internet-Draft opentrustprotocol-CBOR March 2017 COSE_recipient holds the encrypted keys for recipients to encrypt the respond message . 3.3.1.4. GetDeviceStateResponse message-8.1.5 The message has the following structure. GetDeviceTEEStateTBSResponse={ ver : 1.0, status : pass/fail, rid : tstr, ;the request ID from the request message tid : tstr, ;transaction ID signerreq : true/false ;whether TSM needs to send signer data again in subsequent messages edsi : bstr ;Encrypted CBOR dsi information } The Device State Information (DSI) message consists of the following. Liu & Fang Expires September 14, 2017 [Page 8] Internet-Draft opentrustprotocol-CBOR March 2017 dsi={ tfwdata : tfwdata, tee : tee, } tfwdata={ tbs : tstr, ;TFW to be signed data is the tid cert : bstr, ;TFW certificate sigalg : tstr, ;Signing method sig : Tfw ;signed data } tee ={ name : tstr, ; TEE name ver : tstr, ; TEE version cert : bstr, ;encoded TEE cert cacert : bstr, ;array value of CA certificates up to the root CA sdlist : sdlist, teeaiklist: teeaiklist, } sdlist ={ cnt: uint, ;Number of SD owned by this TSM sd : sd } sd=[ name : tstr, ; SD name spid : tstr, ;SP owner ID of this SD talist : talist, ] talist=[ taid : tstr, ;TA application taname : tstr, ;TA application friendly name optional ] teeaiklist=[*teeaiklist] teeaiklist=[ spaik : bstr, ; SP AIK public key, BASE64 encoded spaiktype : tstr, ; RSA/ECC spid : tstr, ; sp id ] TBD Liu & Fang Expires September 14, 2017 [Page 9] Internet-Draft opentrustprotocol-CBOR March 2017 3.3.1.5. TSM Processing Requirements-8.1.7 TBD 3.3.2. Security Domain Management-8.2 3.3.2.1. CreateSD-8.2.1 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. 3.3.2.1.1. CreateSDRequest Message-8.2.1.1 The request message for CreateSD has the following CBOR format. CreateSDRequest={ ver : 1.0, rid : tstr, ;Unique request ID tid : tstr, ;Transaction ID tee : tstr, ; OCSP stapling data of TSM certificate nextdsi : true/false, dsihash : bstr, ;hash of DSI returned in the prior query content : content, ;his piece of data will beencrypted } content ={ spid : tstr, ;SP ID value sdname : tstr, ;SD name for the domain to be created spcert : tstr, ;SP certificate tsmid : tstr, ;An identifiable attribute of the TSM certificate did : bstr, ;SHA256 hash of the TEE cert } Following is the OTrP message template, the full request is signed message over the CreateSDTBSRequest as follows. Liu & Fang Expires September 14, 2017 [Page 10] Internet-Draft opentrustprotocol-CBOR March 2017 98( [ / protected / h'', / unprotected / {}, / payload / 'CreateSDTBSRequest CBOR above.', / signatures / [ [ / protected / h'a10126' / { \ alg \ 1:-7 \ ECDSA 256 \ } / , / unprotected / { / kid / 4:'11' }, / signature / 'signature contents signed by TSM private key' ] ] ] ) 3.3.2.1.2. Request processing requirements at a TEE-8.2.1.2 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 [draft-pei-opentrustprotocol] (8.2.1.2 Request processing requirements at a TEE) 3.3.2.1.3. CreateSDResponse Message-8.2.1.3 The response message for a CreateSDRequest contains the following content. Liu & Fang Expires September 14, 2017 [Page 11] Internet-Draft opentrustprotocol-CBOR March 2017 CreateSDTBSResponse={ ver : 1.0, ;version status : bstr, ;operation result rid : tstr, ;Unique request ID tid : tstr, ;Transaction ID content : content, ;this piece of data will beencrypted } content ={ reason : bstr, ;failure reason detail did : bstr, ;the device id received from the request sdname : tstr, ;SD name for the domain to be created teespaik : bstr, ;SP certificate dsi : bstr, ;Updated TEE state, including all SD owned by this TSM } 3.3.2.2. UpdateSD-8.2.2 3.3.2.2.1. UpdateSDRequest Message-8.2.2.1 TBD 3.3.2.2.2. Request processing requirements at a TEE-8.2.2.1 TBD 3.3.2.2.3. UpdateSDResponse Message-8.2.2.3 TBD 3.3.2.3. DeleteSD--8.2.3 3.3.2.3.1. DeleteSDRequest Message-8.2.3.1 TBD 3.3.2.3.2. Request processing requirements at a TEE-8.2.3.2 TBD 3.3.2.3.3. DeleteSDResponse Message-8.2.3.3 TBD Liu & Fang Expires September 14, 2017 [Page 12] Internet-Draft opentrustprotocol-CBOR March 2017 3.3.3. Trusted Application Management-8.3 The 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 3.3.3.1. InstallTA--8.3.1 3.3.3.1.1. InstallTARequest Message-8.3.1.1 The request message for InstallTA has the following format. InstallTATBSRequest={ ver : 1.0, rid : tstr, ;Unique request ID tid : tstr, ;Transaction ID tee : tstr, ; OCSP stapling data of TSM certificate nextdsi : true/false, dsihash : bstr, ;hash of DSI returned in the prior query content : content, ;this piece of data will beencrypted encrypted_ta : encrypted_ta ;encrypted_ta } content ={ tsmid : tstr, ;TSM ID previously assigned to the SD spid : tstr, ;SPID value sdname : tstr, ;SD name for the domain to install the TA spcert : bstr, ;SP certificate taid : tstr, ;TA identifier } encrypted_ta={ key : bstr, ;A 256-bit symmetric key encrypted by TEEspaik public key iv : bstr, ;hex of 16 random bytes alg : tstr, ;encryption algoritm. AESCBC by default. ciphertadata : bstr, ;encrypted TA binary data cipherpdata : bstr, ;encrypted TA personalization data } Liu & Fang Expires September 14, 2017 [Page 13] Internet-Draft opentrustprotocol-CBOR March 2017 3.3.3.1.2. InstallTAResponse Message-8.3.1.2 InstallTATBSResponse={ ver : 1.0, status : bstr, ;operation result rid : tstr, ;Unique request ID tid : tstr, ;Transaction ID content : content, ;this piece of data will be encrypted } content ={ reason : bstr, ;failure reason detail did : bstr, ;the device id received from the request dsi : tstr, ;the device id hash } The InstallTAResponse message: TBD 3.3.3.2. UpdateTA--8.3.2 3.3.3.2.1. UpdateTARequest Message-8.3.2.1 TBD 3.3.3.2.2. UpdateTAResponse Message-8.3.2.2 TBD 3.3.3.3. DeleteTA--8.3.3 3.3.3.3.1. DeleteTARequest Message-8.3.3.1 TBD 3.3.3.3.2. Request processing requirements at a TEE-8.3.3.2 TBD 3.3.3.3.3. DeleteTAResponse Message-8.3.3.3 TBD Liu & Fang Expires September 14, 2017 [Page 14] Internet-Draft opentrustprotocol-CBOR March 2017 3.3.3.4. UpdateTA--8.3.2 4. References 4.1. Normative References [draft-pei-opentrustprotocol] "The Open Trust Protocol (OTrP)", January 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 4.2. Informative References [draft-greevenbosch-appsawg-cbor-cddl] "CBOR data definition language (CDDL): a notational convention to express CBOR data structures", September 2016. [draft-liu-opentrustprotocol-usecase] "Use case of Open Trust Protocol", March 2016. Authors' Addresses Dapeng Liu Alibaba Group Beijing Beijing Phone: +86-1391788933 Email: maxpassion@gmail.com Qiang Fang Alibaba Group Beijing Beijing Phone: +86-15210569677 Email: qiangwu.fq@alibaba-inc.com Liu & Fang Expires September 14, 2017 [Page 15]