Internet DRAFT - draft-liu-opentrustprotocol-cbor
draft-liu-opentrustprotocol-cbor
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'<signing algorithm>' /
{
"reserved":false,
\ crit \ 2:[
"reserved"
]
} / ,
/ unprotected / {},
/ payload / 'the TAInformationTBS CBOR above.',
/ signatures / [
[
/ protected / h'<signing algorithm>' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'<signature contents signed by TEE SP AIK private key >'
]
]
]
)
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
{
"<name>TBSRequest": {
<request message content>
}
}
A corresponding OTrP Response message will be as follows.
{
"<name>TBSResponse": {
<response message content>
}
}
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,
<http://www.rfc-editor.org/info/rfc2119>.
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]
