Ephemeral Diffie-Hellman Over COSE (EDHOC)

Ephemeral Diffie-Hellman Over COSE (EDHOC) Ericsson AB

Farogatan 6 Kista SE-16480 Stockholm Sweden goran.selander@ericsson.com

Ericsson AB

Farogatan 6 Kista SE-16480 Stockholm Sweden john.mattsson@ericsson.com

Ericsson AB

Farogatan 6 Kista SE-16480 Stockholm Sweden francesca.palombini@ericsson.com

Applications ACE Working Group Internet-Draft This document specifies authenticated Diffie-Hellman key exchange with ephemeral keys, embedded in messages encoded with the CBOR Object Signing and Encryption (COSE) format.

Security at the application layer provides an attractive option for protecting Internet of Things (IoT) deployments, for example where transport layer security is not sufficient . IoT devices may be constrained in various ways, including memory, storage, processing capacity, and energy . A method for protecting individual messages at application layer, suitable for constrained devices, is provided by COSE ). In order for a communication session to provide forward secrecy, the communicating parties can run a Diffie-Hellman (DH) key exchange protocol with ephemeral keys, from which shared key material can be derived. This document specifies authenticated DH protocols using COSE objects for integrity protecting the transport of ephemeral public keys. The DH key exchange messages may be authenticated using either pre-shared keys, raw public keys or X.509 certificates. Authentication is based on credentials established out of band, or from a trusted third party, such as an Authorization Server as specified by . This document also specifies the derivation of the shared key material. The DH exchange and the key derivation follow and HKDF , and make use of the data structures of COSE which are aligned with these standards.

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 . These words may also appear in this document in lowercase, absent their normative meanings. The parties exchanging messages are called “party U” and “party V”, and the ECDH ephemeral public keys of U and V are denoted “E_U” and “E_V”, respectively, see . The messages in the authenticated message exchange are called “message_1” and “message_2”, see . The keys used to authenticate the key exchange are either symmetric or asymmetric. In case of symmetric, the pre-shared key is denoted “PSK”. In case of asymmetric, the public keys of U and V are denoted “S_U” and “S_V”, respectively. Most keys used in this document have an associated identifier. The identifiers used in the document are placeholders for values of the identifiers. The following key identifiers/value representations are used in the draft: kid_eu and kid_ev represent the values of the key identifiers of the ephemeral public keys of U and V, respectively. kid_eu is a sequence number used for replay protection of message_1. kid_ev is used to identify the resulting traffic key, as a means for party V to ensure that different U establishing traffic keys using this method have different identifiers. kid_psk represents the value of the key identifier of the pre-shared key between U and V (). kid_su and kid_sv represent the values of the key identifiers of the static public keys of U and V, respectively (). The key notation is summarized in .

EDHOC is a 2-pass message exchange of COSE objects. This section gives an overview of the protocol, together with section , which explains how the messages are processed, while section focuses on the detailed message formats embedded as COSE objects. The underlying scheme is the Elliptic Curve Cofactor Diffie-Hellman with two ephemeral keys as specified in Section 6.1.2.2 of , see . U and V exchange their ephemeral public keys E_U, E_V, computes the shared secret and derives the keying material as described in .

| | | | E_V | |<----------------------+ | | Shared | | Shared Secret Secret | | | Key Derivation | Key Derivation V V Derived Keying Material Derived Keying Material ]]> EDHOC makes the following additions to this scheme (see ): Negotiation of hash function used with HKDF in the key derivation: U proposes one or more hash functions (expressed as HKDF(s) with different hash algorithms). V decides and responds with one function (expressed as HKDF with a particular hash algorithm). Optional nonces (N_U, N_V) contributing to the salt used in the extract phase of HKDF . Negotiation of subsequent traffic crypto algorithm (TCA) to be used between party U and V: U proposes one or more algorithms (TCA(s)). V decides and responds with one algorithm (TCA). Authentication, integrity and replay protection of protocol messages Authentication and integrity protection using the COSE format . The MAC/Signature is calculated over the message as defined by COSE. Information about keys, message protection algorithm and replay parameter is included in the COSE Header, as specified in the sections below. Authentication may be based on pre-shared keys, raw public keys or X.509 certificates. In the latter case the message contains the public key certificate of the sending endpoints (Cert_U, Cert_V). The key exchange messages are called “message_1” and “message_2”, see .

The EDHOC protocol messages are authenticated based on credentials pre-established between U and V. The parties may have acquired such a credential from the other party out of band or from a trusted third party, such as an Authorization Server as specified in . The pre-established credentials are either symmetric secret keys or public keys. The public keys may be raw public keys (RPK), or public keys of a Certificate Authority (CA) used as trust anchor for verification of received certificates. Pre-shared symmetric key (PSK). Each message contains a MAC over the message generated by the sending party using PSK. Raw Public Keys (RPK). The pre-established credentials may be static raw public keys of the other party (S_U and S_V, of party U and V, respectively). Each message contain a signature over the message generated by the sending party. X.509 Certificates (Cert). The pre-established credentials may also be CA public keys, used to verify received public key certificates. Each message contain the signature over the message, excluding the certificate, generated by the sending party.

This section details the format for the objects used. Examples are provided for each object in .

This section defines the formatting of the ephemeral public keys E_U and E_V. The ECDH ephemeral public key SHALL be formatted as a COSE_Key with the following fields and values (see ): kty: The value SHALL be 2 (Elliptic Curve Keys) kid: crv: The value of the Curve used. The value 1 SHALL be supported by party V (NIST P-256 a.k.a. secp256r1 ) x: y: The value SHOULD be boolean. TODO: Consider replacing P-256 with Curve25519 as mandatory

This section defines the formatting of the payload in message_1. payload_1 is a CBOR array object containing: HKDFs: the set of proposed algorithms to indicate the key derivation N_U: optional nonce for use in salt with HKDF TCAs: the set of proposed algorithms to use with the derived secret E_U: the ephemeral public key (with ‘kid’ = kid_eu, which is a sequence number)

This section defines the formatting of the payload in message_2. payload_2 is a CBOR array object containing: HKDF: the agreed key derivation algorithm N_V: optional nonce for use in salt with HKDF TCA: the agreed traffic crypto algorithm E_V: the ephemeral public key (with ‘kid’ = kid_ev)

Parties U and V are assumed to have a pre-shared key, PSK. The value of the key identifier kid_psk SHALL be unique for U and V.

In case of PSK, message_1 SHALL have the COSE_Mac0_Tagged structure with the following fields and values: Header Protected Alg: 4 (HMAC 256/64) Kid: kid_psk Unprotected: Empty Payload: payload_1 as defined in MAC: As in section 6.3 of

In case of PSK, message_2 SHALL have the COSE_Mac0_Tagged structure with the following fields and values: Header Protected Alg: 4 (HMAC 256/64) Kid: kid_psk Unprotected: empty Payload: payload_2 as defined in Tag: As in section 6.3 of , including the external_aad in the MAC_structure. The external authenticated data to use in the MAC_structure of Section 6.3 of is the MAC of message_1. external_aad: MAC

The key derivation is specified in using the following context information COSE_KDF_Context for symmetric keys:

Parties U and V are assumed to have access to each other’s public key. Party U’s public key, S_U, SHALL be uniquely identified at V by kid_su. Party V’s public key, S_V, SHALL be uniquely identified at U by kid_sv.

In case of RPK message_1 SHALL have the COSE_Sign1_Tagged structure , with the following fields and values: Header protected: alg: -7 (ECDSA 256) kid: kid_su unprotected: empty payload: payload_1 as defined in signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg}

In case of RPK, message_2 SHALL have the COSE_Sign1_Tagged structure with the following fields and values: Header Protected Alg: -7 (ECDSA 256) Kid: kid_sv Unprotected: empty payload: payload_2 as defined in signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg}, including the external_aad in the Sig_structure. The external authenticated data to use in the Sig_structure of Section 4.4 of is the signature in message_1. external_aad: signature

The case of Certificates is similar to RPK. message_1 SHALL have the COSE_Sign1_Tagged structure , with the same fields and values as with the addition of the unprotected header field “x5c” containing the X.509 certificate of S_U as a byte string. Header protected: alg: -7 (ECDSA 256) kid: kid_su unprotected: x5c: bstr payload: payload_1 as defined in signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg}

message_2 is analogous to message_1. message_2 SHALL have the COSE_Sign1_Tagged structure , with the same fields and values as and with the addition of the unprotected header field “x5c” containing the X.509 certificate of S_V as a byte string. Header Protected Alg: -7 (ECDSA 256) Kid: kid_sv Unprotected: x5c: bstr payload: payload_2 as defined in signature: computed as in Section 4.4 of {{I-D.ietf-cose-msg}, including the external_aad in the Sig_structure. The external authenticated data to use in the Sig_structure of Section 4.4 of is the signature in message_1. external_aad: signature

The key derivation is specified in using the following context information COSE_KDF_Context for asymmetric keys:

Party U and V are assumed to have pre-established credentials as described in .

Party U processes message_1 for party V as follows: Party U SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of using ECC domain parameters of a curve complying with security policies for communicating with party V. The ephemeral public key, E_U, SHALL be formatted as a COSE_key as specified in . The key identifier kid_eu of the ephemeral public key E_U SHALL be a sequence number initiated to 1 and increased by 1 for each message_1 associated to a particular party V. Party U SHALL define the parameters and format payload_1 as specified in complying with the security policies for communicating with party V. message_1 SHALL be formatted as a COSE message according to with parameters specified in (PSK) , (RPK) or (Cert). Party U SHALL cache the MAC/Signature value of the request. Party U sends message_1 to party V.

Party V processes the received message_1 as follows: If the message contains a certificate, party V SHALL verify the certificate using the pre-established trust anchor and the revocation verification policies relevant for party U. If the verification fails the message is discarded. Party V SHALL verify that kid_eu is greater than a counter tracking latest message associated with party U, identified with the sending party key. (The counter is initialized to 0 at first contact with party U.) If kid_eu is less than or equal than the counter, the message is discarded. Party V SHALL verify the COSE message as specified in using the key associated to party U, identified by the key identifier kid_psk/kid_su in the message header, or in the verified received certificate. If the MAC/Signature of the received request can be verified, then the counter associated to party U is updated with kid-eu, else the message is discarded. Party V SHALL verify that the ECDH curve is compliant with its security policy for communicating with U, or else respond with an error. V SHALL select a preferred pair of (HKDF, TCA) out of those proposed by U, compliant with the security policy relevant for party U. If such a pair does not exist, V SHALL stop processing the message and MAY respond with an error, indicating that no common algorithm could be found.

Party V composes message_2 for party U as follows: Party V SHALL generate a fresh ephemeral ECDH key pair as specified in Section 5 of using same curve/ECC domain parameters as used by party U. The ephemeral public key, E_V, SHALL be formatted as a COSE_key as specified in . The key identifier kid_ev SHALL be unique among key identifiers used for traffic keys by party V. Party SHALL define the parameters and format payload_2 as specified in complying with the security policies for communicating with party V. message_2 SHALL be formatted as a COSE message according to with parameters specified in (PSK) , (RPK) or (Cert) using the same authentication scheme as in message_1. Note that the MAC/Signature value of the request is included as additional authenticated data of the response. Party V sends message_2 to party U. Then party V derives the traffic_secret_0 key as specified , and labels it with kid_ev.

Party U processes the received message_2 as follows: If the message contains a certificate, party V SHALL verify the certificate using the pre-established trust anchor and the revocation verification policies relevant for party U. If the verification fails the message is discarded. Party U SHALL verify the received COSE message as defined in using the key associated to the key identifier (kid_psk/kid_su) in the message header, or in the verified received certificate. Note the use of the cached MAC/Signature of the request. If the COSE message cannot be verified, the message is discarded. U SHALL verify that the received pair (HKDF, TCA) is one element of those proposed in the request, else stop processing the message. If the response is verified, U derives the traffic_secret_0 as specified .

The key derivation is identical to Section 11 of , using HKDF agreed during the message exchange. the secret SHALL be the ECDH shared secret as defined in Section 12.4.1 of , where the computed secret is specified in section 5.7.1.2 of the salt SHALL be B1 XOR B2, where B1 = N_U || 00 .. 0, i.e. the nonce N_U, if present, appended with padded zeros to the size of the hash function; or else just an octet string of zeros B2 = 00… 0 || N_V, i.e. the nonce N_V, if present, prepended with padded zeros to the size of the hash function; or else just an octet string of zeros This corresponds to salt = N_U || N_V in the case of each party contributing a nonce of half the size of the salt, but also accommodates for nonces of different sizes. the length SHALL be the length of the key in TCA. the context information SHALL be the serialized COSE_KDF_Context defined in the next paragraph. the PRF SHALL be the one indicated in HKDF using the Table 18 of (in our examples, -27 corresponds to HMAC with SHA-256) The context information COSE_KDF_Context is defined as follows: AlgorithmID SHALL be the algorithm for which the key material will be derived. It’s value is AlgID PartyUInfo SHALL be empty PartyVInfo SHALL be empty SuppPubInfo SHALL contain: KeyDataLength SHALL be equal to ‘length’ protected SHALL be a zero length bstr other SHALL be the concatenation of the MAC/Signature of message_1 and the MAC/Signature of message_2 SuppPrivInfo SHALL be empty The tags are either MACs (PSK) or the Signatures (RPK, Cert) of the COSE messages.

The output from the key derivation is denoted “traffic_secret_0”.

For unauthenticated Diffie-Hellman it is recommended that public information about parties U and V, such as their identifiers, is included in the context information used in the key derivation. In the present case the assumption is that the parties authenticate each other with pre-established credentials, and the tag (MAC/Signature) created with the pre-established credentials is included in the key derivation context. The referenced processing instructions in must be complied with, including deleting the intermediate computed values along with any ephemeral ECDH secrets after the key derivation is completed. The choice of key length used in the different algorithms needs to be harmonized, so that right security level is maintained throughout the calculations. The identifier of the ephemeral key of party U is used for replay protection of U’s requests. With the current protocol, key confirmation of the Diffie-Hellman shared secret/traffic keys is performed when the keys are successfully used. The addition of key confirmation to the protocol is for further study. TODO: Expand on the security considerations in a future version of the draft

TODO

The authors wants to thank Ilari Liusvaara, Jim Schaad and Ludwig Seitz for timely review and helpful comments.

&I-D.ietf-cose-msg; &RFC2119; Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography &I-D.hartke-core-e2e-security-reqs; &I-D.ietf-ace-oauth-authz; &RFC4492; &RFC7228; &RFC7252; &RFC5869;

An example of COSE_Key structure, representing an ECDH public key, is given in , using CBOR’s diagnostic notation. In this example, the ephemeral key is identified by a 4 bytes ‘kid’.

The equivalent CBOR encoding is: h’a120a50102024478f67901200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5’, which has a size of 51 bytes.

An example of COSE encoding for payload_1 is given in , using CBOR’s diagnostic notation. In this example, the size of the identifier of U’s ephemeral key, kid_eu, is 1 byte. The payload_1 is:

The equivalent CBOR encoding of the payload is: h’84381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f5’, which has a size of 54 bytes.

An example of COSE encoding for message_2 is given in using CBOR’s diagnostic notation. In this example, kid_ev, the identifier of V’s ephemeral public key, is 4 bytes. The payload is:

The equivalent CBOR encoding of the payload is: h’84381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5’, which has a size of 57 bytes.

An example of COSE encoding for message_1 is given in using CBOR’s diagnostic notation. In this example, kid_psk, the identifier of PSK is 4 bytes, and the payload is as in . The message_1 is:

The equivalent CBOR encoding is: h’d903e48449a201040444e19648b5a0583684381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f548e77fe81c66c3b5c0’, which has a size of 80 bytes.

An example of COSE encoding for message_2 is given in using CBOR’s diagnostic notation. In this example, kid_psk, the identifier of PSK, is 4 bytes, and the payload is as in . The message_2 is:

The equivalent CBOR encoding is: h’d903e48449a201040444e19648b5a0583984381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f5486113268ad246f2c9’, which has a size of 83 bytes.

An example of COSE encoding for message_1 is given in , using CBOR’s diagnostic notation. In this example, the size of the identifier of the static public key of U, kid_su, is 4 bytes, and the payload is as in . The message_1 is:

The equivalent CBOR encoding is: h’d903e58449a201260444c150d41ca0583684381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f55840eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327be470355c9657ce0’, which has a size of 137 bytes.

An example of COSE encoding for Message 2 is given in , using CBOR’s diagnostic notation. In this example, the size of the identifier of the public key of V, kid_sv, is 4 bytes, and the payload is as in . The external_aad is the signature of message_1:

The message_2 is:

The equivalent CBOR encoding is: h’d903e58449a2012604447a2af164a0583984381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f558402374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327be470355c9657ce0’, which has a size of 140 bytes.

The equivalent CBOR encoding is: h’d903e58449a201260444c150d41ca163783563 40… 583684381af60c582fa120a50102024103200121582098f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91d628022f55840eae868ecc1276883766c5dc5ba5b8dca25dab3c2e56a51ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327be470355c9657ce0’, which has a size of 142 bytes plus the size of the certificate.

An example of COSE encoding for message_2 is given in , using CBOR’s diagnostic notation. In this example, the size of the identifier of the static public key of U, kid_su, is 4 bytes, and the payload is as in . The message_2 is:

The equivalent CBOR encoding is: h’d903e58449a2012604447a2af164a163783563 40… 583984381af60c5832a120a5010202442edb61f92001215820acbee6672a28340affce41c721901ebd7868231bd1d86e41888a07822214050022f558402374e27a3d9eeb4f66c5dc5ba5b8dca25dab3c2e56a551ce5705b793914348e14eea4aee6e0c9f09db4ef3ddeca8f3506cd1a98a8fb64327be470355c9657ce0’, which has a size of 145 bytes plus the size of the certificate.

The DH key exchange specified in this document can be implemented as a CoAP message exchange with the CoAP client as party U and the CoAP server as party V. A strawman is sketched here. The CoAP client makes the following request: The request method is POST Content-Format is “application/cose+cbor” The Uri-Path is “edhoc” The Payload is message_1 The CoAP server performs the verifications of the COSE object as specified in . If successful, then the server provides the following response: The response Code is 2.04 (Changed) The Payload is message_2