]>
Traces of Ephemeral DiffieHellman Over COSE (EDHOC)
Ericsson
Sweden
goran.selander@ericsson.com
Ericsson
Sweden
john.mattsson@ericsson.com
ASSA ABLOY
Poland
marek.serafin@assaabloy.com
RISE AB
Isafjordsgatan 22
164 40
Kista
Sweden
marco.tiloca@ri.se
Inria
France
malisa.vucinic@inria.fr
sec
lake
test vector
lightweight
authenticated key exchange
LAKE
AKE
This document contains example traces of Ephemeral DiffieHellman Over COSE (EDHOC).
Introduction
EDHOC is a lightweight authenticated key exchange protocol designed for highly constrained settings. This document contains annotated traces of EDHOC sessions with input, output, and intermediate processing results to simplify testing of implementations. The traces have been verified by two independent implementations.
Setup
EDHOC is run between an Initiator (I) and a Responder (R). The private/public key pairs and credentials of the Initiator and the Responder required to produce the protocol messages are shown in the traces when needed for the calculations.
EDHOC messages and intermediate results are encoded in Concise Binary Object Representation (CBOR) and can therefore be displayed in CBOR diagnostic notation using, e.g., the CBOR playground , which makes them easy to parse for humans. Credentials can also be encoded in CBOR, e.g., CBOR Web Tokens (CWTs) .
The document contains two traces:

 Authentication with signature keys identified by the hash value of the X.509 certificates (provided in ). The endpoints use Edwardscurve Digital Signature Algorithm (EdDSA) for authentication and X25519 for ephemeralephemeral DiffieHellman (DH) key exchange.

 Authentication with static DiffieHellman keys identified by short key identifiers labeling CWT Claims Sets (CCSs) . The endpoints use NIST P256 for both ephemeralephemeral and ephemeralstatic DH key exchange. This trace also illustrates the cipher suite negotiation and provides an example of low protocol overhead with messages sizes of 39, 45, and 19 bytes.
Examples of invalid EDHOC messages are found in .
 The same name is used for hexadecimal byte strings and their CBOR encodings. The traces contain both the raw byte strings and the corresponding CBORencoded data items.
 If not clear from the context, remember that CBOR sequences and CBOR arrays assume CBORencoded data items as elements.
 When the protocol transporting EDHOC messages does not inherently provide correlation across all messages, then some messages are typically prepended with connection identifiers and potentially a message_1 indicator (see Section and Appendix of ). Those bytes are not included in the traces in this document.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Authentication with Signatures, X.509 Identified by 'x5t'
In this example, the Initiator (I) and Responder (R) are authenticated with digital signatures (METHOD = 0). Both the Initiator and the Responder support cipher suite 0, which determines the algorithms:
 EDHOC AEAD algorithm = AESCCM1664128
 EDHOC hash algorithm = SHA256
 EDHOC Message Authentication Code (MAC) length in bytes (Static DH) = 8
 EDHOC key exchange algorithm (ECDH curve) = X25519
 EDHOC signature algorithm = EdDSA
 application AEAD algorithm = AESCCM1664128
 application hash algorithm = SHA256
The public keys are represented with X.509 certificates identified by the CBOR Object Signing and Encryption (COSE) header parameter 'x5t'.
message_1
Both endpoints are authenticated with signatures, i.e., METHOD = 0:
The Initiator selects cipher suite 0. A single cipher suite is encoded as an int:
The Initiator creates an ephemeral key pair for use with the EDHOC key exchange algorithm:
The Initiator selects its connection identifier C_I to be the byte string 0x2d, which is encoded as 0x2d since it is represented by the 1byte CBOR int 14:
No external authorization data:
The Initiator constructs message_1:
message_2
The Responder supports the most preferred and selected cipher suite 0, so SUITES_I is acceptable.
The Responder creates an ephemeral key pair for use with the EDHOC key exchange algorithm:
The Responder selects its connection identifier C_R to be the byte string 0x18, which is encoded as h'18' = 0x4118 since it is not represented by a 1byte CBOR int:
The transcript hash TH_2 is calculated using the EDHOC hash algorithm:
TH_2 = H( G_Y, H(message_1) )
The input to calculate TH_2 is the CBOR sequence:
G_Y, H(message_1)
PRK_2e is specified in .
First, the Elliptic Curve DiffieHellman (ECDH) shared secret G_XY is computed from G_X and Y or G_Y and X:
Then, PRK_2e is calculated using EDHOC_Extract(), which is determined by the EDHOC hash algorithm:
where salt is TH_2:
Since METHOD = 0, the Responder authenticates using signatures. Since the selected cipher suite is 0, the EDHOC signature algorithm is EdDSA.
The Responder's signature key pair uses EdDSA:
PRK_3e2m is specified in .
Since the Responder authenticates with signatures, PRK_3e2m = PRK_2e.
The Responder constructs the remaining input needed to calculate MAC_2:
MAC_2 = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 )
context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>
CRED_R is identified by a 64bit hash:
where the COSE header value 34 ('x5t') indicates a hash of an X.509 certificate,
and the COSE algorithm 15 indicates the hash algorithm SHA256 truncated to 64 bits.
CRED_R is a CBOR byte string of the DER encoding of the X.509 certificate in :
No external authorization data:
context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>
MAC_2 is computed through EDHOC_Expand() using the EDHOC hash algorithm (see ):
where
Since METHOD = 0, mac_length_2 is given by the EDHOC hash algorithm.
info for MAC_2 is:
where the last value is the output size of the EDHOC hash algorithm in bytes.
Since METHOD = 0, Signature_or_MAC_2 is the 'signature' of the COSE_Sign1 object.
The Responder constructs the message to be signed:
>,
<< TH_2, CRED_R, ? EAD_2 >>,
MAC_2
] =
[
"Signature1",
h'a11822822e4879f2a41b510c1f9b',
h'5820c6405c154c567466ab1df20369500e540e9f14bd3a79
6a0652cae66c9061688d58f13081ee3081a1a00302010202
0462319ec4300506032b6570301d311b301906035504030c
124544484f4320526f6f742045643235353139301e170d32
32303331363038323433365a170d32393132333132333030
30305a30223120301e06035504030c174544484f43205265
73706f6e6465722045643235353139302a300506032b6570
032100a1db47b95184854ad12a0c1a354e418aace33aa0f2
c662c00b3ac55de92f9359300506032b6570034100b723bc
01eab0928e8b2b6c98de19cc3823d46e7d6987b032478fec
faf14537a1af14cc8be829c6b73044101837eb4abc949565
d86dce51cfae52ab82c152cb02',
h'862a7e5ef147f9a5f4c512e1b6623cd66cd17a7272072bfe
5b602ffe307ee0e9'
]
]]>
The Responder signs using the private authentication key SK_R.
The Responder constructs PLAINTEXT_2:
The input needed to calculate KEYSTREAM_2 is defined in , using EDHOC_Expand() with the EDHOC hash algorithm:
where plaintext_length is the length in bytes of PLAINTEXT_2 in bytes and info for KEYSTREAM_2 is:
where the last value is the length in bytes of PLAINTEXT_2.
The Responder calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and KEYSTREAM_2:
The Responder constructs message_2:
where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of
the raw values of G_Y and CIPHERTEXT_2.
message_3
Since METHOD = 0, the Initiator authenticates using signatures. Since the selected cipher suite is 0, the EDHOC signature algorithm is EdDSA.
The Initiator's signature key pair uses EdDSA:
PRK_4e3m is specified in .
Since the Initiator authenticates with signatures, PRK_4e3m = PRK_3e2m.
The transcript hash TH_3 is calculated using the EDHOC hash algorithm:
TH_3 = H( TH_2, PLAINTEXT_2, CRED_R )
The Initiator constructs the remaining input needed to calculate MAC_3:
where
>
]]>
CRED_I is identified by a 64bit hash:
where the COSE header value 34 ('x5t') indicates a hash of an X.509 certificate,
and the COSE algorithm 15 indicates the hash algorithm SHA256 truncated to 64 bits.
CRED_I is a CBOR byte string of the DER encoding of the X.509 certificate in :
No external authorization data:
context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>
MAC_3 is computed through EDHOC_Expand() using the EDHOC hash algorithm (see ):
where
where
>
]]>
Since METHOD = 0, mac_length_3 is given by the EDHOC hash algorithm.
info for MAC_3 is:
where the last value is the output size of the EDHOC hash algorithm in bytes.
Since METHOD = 0, Signature_or_MAC_3 is the 'signature' of the
COSE_Sign1 object.
The Initiator constructs the message to be signed:
>,
<< TH_3, CRED_I, ? EAD_3 >>,
MAC_3
] =
[
"Signature1",
h'a11822822e48c24ab2fd7643c79f',
h'58205b7df9b4f58f240ce0418e48191b5fff3a22b5ca57f6
69b16777996592e928bc58f13081ee3081a1a00302010202
0462319ea0300506032b6570301d311b301906035504030c
124544484f4320526f6f742045643235353139301e170d32
32303331363038323430305a170d32393132333132333030
30305a30223120301e06035504030c174544484f4320496e
69746961746f722045643235353139302a300506032b6570
032100ed06a8ae61a829ba5fa54525c9d07f48dd44a302f4
3e0f23d8cc20b73085141e300506032b6570034100521241
d8b3a770996bcfc9b9ead4e7e0a1c0db353a3bdf2910b392
75ae48b756015981850d27db6734e37f67212267dd05eeff
27b9e7a813fa574b72a00b430b',
h'39b127c130129afa30618c751329e637cc3734270d4b0125
8445a8ee02daa3bd'
]
]]>
The Initiator signs using the private authentication key SK_I:
The Initiator constructs PLAINTEXT_3:
The Initiator constructs the associated data for message_3:
The Initiator constructs the input needed to derive the key K_3 (see ) using the EDHOC hash algorithm:
where key_length is the key length in bytes for the EDHOC Authenticated Encryption with Associated Data (AEAD) algorithm, and info for K_3 is:
where the last value is the key length in bytes for the EDHOC AEAD algorithm.
The Initiator constructs the input needed to derive the nonce IV_3 (see ) using the EDHOC hash algorithm:
where iv_length is the nonce length in bytes for the EDHOC AEAD algorithm, and info for IV_3 is:
where the last value is the nonce length in bytes for the EDHOC AEAD algorithm.
The Initiator calculates CIPHERTEXT_3 as 'ciphertext' of COSE_Encrypt0 applied
using the EDHOC AEAD algorithm with plaintext PLAINTEXT_3, additional data
A_3, key K_3, and nonce IV_3.
message_3 is the CBOR bstr encoding of CIPHERTEXT_3:
The transcript hash TH_4 is calculated using the EDHOC hash algorithm:
TH_4 = H( TH_3, PLAINTEXT_3, CRED_I )
message_4
No external authorization data:
The Responder constructs PLAINTEXT_4:
The Responder constructs the associated data for message_4:
The Responder constructs the input needed to derive the EDHOC message_4 key (see ) using the EDHOC hash algorithm:
where key_length is the key length in bytes for the EDHOC AEAD algorithm,
and info for K_4 is:
where the last value is the key length in bytes for the EDHOC AEAD algorithm.
The Responder constructs the input needed to derive the EDHOC message_4 nonce (see ) using the EDHOC hash algorithm:
where length is the nonce length in bytes for the EDHOC AEAD algorithm,
and info for IV_4 is:
where the last value is the nonce length in bytes for the EDHOC AEAD algorithm.
The Responder calculates CIPHERTEXT_4 as 'ciphertext' of COSE_Encrypt0 applied
using the EDHOC AEAD algorithm with plaintext PLAINTEXT_4, additional data
A_4, key K_4, and nonce IV_4.
message_4 is the CBOR bstr encoding of CIPHERTEXT_4:
PRK_out and PRK_exporter
PRK_out is specified in .
where hash_length is the length in bytes of the output of the EDHOC hash algorithm, and info for PRK_out is:
where the last value is the length in bytes of the output of the EDHOC hash algorithm.
The Object Security for Constrained RESTful Environments (OSCORE) Master Secret and OSCORE Master Salt are derived with the EDHOC_Exporter as specified in .
where PRK_exporter is derived from PRK_out:
where hash_length is the length in bytes of the output of the EDHOC hash algorithm, and info for the PRK_exporter is:
where the last value is the length in bytes of the output of the EDHOC hash algorithm.
OSCORE Parameters
The derivation of OSCORE parameters is specified in .
The AEAD and hash algorithms to use in OSCORE are given by the selected cipher suite:
The mapping from EDHOC connection identifiers to OSCORE Sender/Recipient IDs is defined in .
C_R is mapped to the Recipient ID of the server, i.e., the Sender ID of the client. The byte string 0x18, which as C_R is encoded as the CBOR byte string 0x4118, is converted to the server Recipient ID 0x18.
C_I is mapped to the Recipient ID of the client, i.e., the Sender ID of the server. The byte string 0x2d, which as C_I is encoded as the CBOR integer 0x2d, is converted to the client Recipient ID 0x2d.
The OSCORE Master Secret is computed through EDHOC_Expand() using the
application hash algorithm (see ):
where oscore_key_length is the key length in bytes for the application AEAD
algorithm by default, and info for the OSCORE Master Secret is:
where the last value is the key length in bytes for the application AEAD algorithm.
The OSCORE Master Salt is computed through EDHOC_Expand() using the application hash algorithm (see ):
where oscore_salt_length is the length in bytes of the OSCORE Master Salt, and info for the OSCORE Master Salt is:
where the last value is the length in bytes of the OSCORE Master Salt.
Key Update
Key update is defined in .
where hash_length is the length in bytes of the output of the EDHOC hash function, and the context for KeyUpdate is:
where info for KeyUpdate is:
After the key update, the PRK_exporter needs to be derived anew:
where info and hash_length are unchanged as in .
The OSCORE Master Secret is derived with the updated PRK_exporter:
where info and oscore_key_length are unchanged as in .
The OSCORE Master Salt is derived with the updated PRK_exporter:
where info and oscore_salt_length are unchanged as in .
Authentication with Static DH, CCS Identified by 'kid'
In this example, the Initiator and the Responder are authenticated with ephemeralstatic DiffieHellman (METHOD = 3). The Initiator supports cipher suites 6 and 2 (in order of preference), and the Responder only supports cipher suite 2. After an initial negotiation message exchange, cipher suite 2 is used, which determines the algorithms:
 EDHOC AEAD algorithm = AESCCM1664128
 EDHOC hash algorithm = SHA256
 EDHOC MAC length in bytes (Static DH) = 8
 EDHOC key exchange algorithm (ECDH curve) = P256
 EDHOC signature algorithm = ES256
 application AEAD algorithm = AESCCM1664128
 application hash algorithm = SHA256
The public keys are represented as raw public keys (RPKs), encoded in a CWT Claims Set (CCS) and identified by the COSE header parameter 'kid'.
message_1 (First Time)
Both endpoints are authenticated with static DH, i.e., METHOD = 3:
The Initiator selects its preferred cipher suite 6. A single cipher suite is encoded as an int:
The Initiator creates an ephemeral key pair for use with the EDHOC key exchange algorithm:
The Initiator selects its connection identifier C_I to be the byte string 0x0e, which is encoded as 0x0e since it is represented by the 1byte CBOR int 14:
No external authorization data:
The Initiator constructs message_1:
error
The Responder does not support cipher suite 6 and sends an error with ERR_CODE 2 containing SUITES_R as ERR_INFO. The Responder proposes cipher suite 2, a single cipher suite thus encoded as an int.
message_1 (Second Time)
Same steps are performed as for message_1 the first time () but with SUITES_I updated.
Both endpoints are authenticated with static DH, i.e., METHOD = 3:
The Initiator selects cipher suite 2 and indicates the more preferred cipher suite(s), in this case 6, all encoded as the array [6, 2]:
The Initiator creates an ephemeral key pair for use with the EDHOC key exchange algorithm:
The Initiator selects its connection identifier C_I to be the byte string 0x37, which is encoded as 0x37 since it is represented by the 1byte CBOR int 24:
No external authorization data:
The Initiator constructs message_1:
message_2
The Responder supports the selected cipher suite 2 and not the Initiator's more preferred cipher suite(s) 6, so SUITES_I is acceptable.
The Responder creates an ephemeral key pair for use with the EDHOC key exchange algorithm:
The Responder selects its connection identifier C_R to be the byte string 0x27, which is encoded as 0x27 since it is represented by the 1byte CBOR int 8:
The transcript hash TH_2 is calculated using the EDHOC hash algorithm:
TH_2 = H( G_Y, H(message_1) )
The input to calculate TH_2 is the CBOR sequence:
G_Y, H(message_1)
PRK_2e is specified in .
First, the ECDH shared secret G_XY is computed from G_X and Y or G_Y and X:
Then, PRK_2e is calculated using EDHOC_Extract(), which is determined by the EDHOC hash algorithm:
where salt is TH_2:
Since METHOD = 3, the Responder authenticates using static DH. The EDHOC key exchange algorithm is based on the same curve as for the ephemeral keys, which is P256, since the selected cipher suite is 2.
The Responder's static DiffieHellman P256 key pair consists of a private key and a public key.
Since the Responder authenticates with static DH (METHOD = 3), PRK_3e2m is derived
from SALT_3e2m and G_RX.
The input needed to calculate SALT_3e2m is defined in , using EDHOC_Expand() with the EDHOC hash algorithm:
where hash_length is the length in bytes of the output of the EDHOC hash algorithm, and info for SALT_3e2m is:
PRK_3e2m is specified in .
PRK_3e2m is derived from G_RX using EDHOC_Extract() with the EDHOC hash algorithm:
where G_RX is the ECDH shared secret calculated from G_X and R, or G_R and X.
The Responder constructs the remaining input needed to calculate MAC_2:
MAC_2 = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 )
context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>
CRED_R is identified by a 'kid' with byte string value 0x32:
CRED_R is an RPK encoded as a CCS:
No external authorization data:
context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>
MAC_2 is computed through EDHOC_Expand() using the EDHOC hash algorithm (see ):
where
Since METHOD = 3, mac_length_2 is given by the EDHOC MAC length.
info for MAC_2 is:
where the last value is the EDHOC MAC length in bytes.
Since METHOD = 3, Signature_or_MAC_2 is MAC_2:
The Responder constructs PLAINTEXT_2:
Since ID_CRED_R contains a single 'kid' parameter, only the byte string value is included in the plaintext, represented as described in . The CBOR map { 4 : h'32' } is thus replaced, not by the CBOR byte string 0x4132, but by the CBOR int 0x32, since that is a onebyte encoding of a CBOR integer (19).
The input needed to calculate KEYSTREAM_2 is defined in , using EDHOC_Expand() with the EDHOC hash algorithm:
where plaintext_length is the length in bytes of PLAINTEXT_2, and info for KEYSTREAM_2 is:
where the last value is the length in bytes of PLAINTEXT_2.
The Responder calculates CIPHERTEXT_2 as XOR between PLAINTEXT_2 and KEYSTREAM_2:
The Responder constructs message_2:
where G_Y_CIPHERTEXT_2 is the bstr encoding of the concatenation of
the raw values of G_Y and CIPHERTEXT_2.
message_3
The transcript hash TH_3 is calculated using the EDHOC hash algorithm:
TH_3 = H( TH_2, PLAINTEXT_2, CRED_R )
Since METHOD = 3, the Initiator authenticates using static DH. The EDHOC key exchange algorithm is based on the same curve as for the ephemeral keys, which is P256, since the selected cipher suite is 2.
The Initiator's static DiffieHellman P256 key pair consists of a private key and a public key:
Since I authenticates with static DH (METHOD = 3), PRK_4e3m is derived
from SALT_4e3m and G_IY.
The input needed to calculate SALT_4e3m is defined in , using EDHOC_Expand() with the EDHOC hash algorithm:
where hash_length is the length in bytes of the output of the EDHOC hash algorithm, and info for SALT_4e3m is:
PRK_4e3m is specified in .
Since I authenticates with static DH (METHOD = 3), PRK_4e3m is derived
from G_IY using EDHOC_Extract() with the EDHOC hash algorithm:
where G_IY is the ECDH shared secret calculated from G_I and Y, or G_Y and I.
The Initiator constructs the remaining input needed to calculate MAC_3:
MAC_3 = EDHOC_KDF( PRK_4e3m, 6, context_3, mac_length_3 )
context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>
CRED_I is identified by a 'kid' with byte string value 0x2b:
CRED_I is an RPK encoded as a CCS:
No external authorization data:
context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>
MAC_3 is computed through EDHOC_Expand() using the EDHOC hash algorithm (see ):
where
Since METHOD = 3, mac_length_3 is given by the EDHOC MAC length.
info for MAC_3 is:
where the last value is the EDHOC MAC length in bytes.
Since METHOD = 3, Signature_or_MAC_3 is MAC_3:
The Initiator constructs PLAINTEXT_3:
Since ID_CRED_I contains a single 'kid' parameter, only the byte string value is included in the plaintext, represented as described in . The CBOR map { 4 : h'2b' } is thus replaced, not by the CBOR byte string 0x412b, but by the CBOR int 0x2b, since that is a onebyte encoding of a CBOR integer (12).
The Initiator constructs the associated data for message_3:
The Initiator constructs the input needed to derive the key K_3 (see ) using the EDHOC hash algorithm:
where key_length is the key length in bytes for the EDHOC AEAD algorithm, and info for K_3 is:
where the last value is the key length in bytes for the EDHOC AEAD algorithm.
The Initiator constructs the input needed to derive the nonce IV_3 (see ) using the EDHOC hash algorithm:
where iv_length is the nonce length in bytes for the EDHOC AEAD algorithm, and info for IV_3 is:
where the last value is the nonce length in bytes for the EDHOC AEAD algorithm.
The Initiator calculates CIPHERTEXT_3 as 'ciphertext' of COSE_Encrypt0 applied
using the EDHOC AEAD algorithm with plaintext PLAINTEXT_3, additional data
A_3, key K_3, and nonce IV_3.
message_3 is the CBOR bstr encoding of CIPHERTEXT_3:
The transcript hash TH_4 is calculated using the EDHOC hash algorithm:
TH_4 = H( TH_3, PLAINTEXT_3, CRED_I )
message_4
No external authorization data:
The Responder constructs PLAINTEXT_4:
The Responder constructs the associated data for message_4:
The Responder constructs the input needed to derive the EDHOC message_4 key (see ) using the EDHOC hash algorithm:
where key_length is the key length in bytes for the EDHOC AEAD algorithm,
and info for K_4 is:
where the last value is the key length in bytes for the EDHOC AEAD algorithm.
The Responder constructs the input needed to derive the EDHOC message_4 nonce (see ) using the EDHOC hash algorithm:
where iv_length is the nonce length in bytes for the EDHOC AEAD algorithm,
and info for IV_4 is:
where the last value is the nonce length in bytes for the EDHOC AEAD algorithm.
The Responder calculates CIPHERTEXT_4 as 'ciphertext' of COSE_Encrypt0 applied
using the EDHOC AEAD algorithm with plaintext PLAINTEXT_4, additional data
A_4, key K_4, and nonce IV_4.
message_4 is the CBOR bstr encoding of CIPHERTEXT_4:
PRK_out and PRK_exporter
PRK_out is specified in .
where hash_length is the length in bytes of the output of the EDHOC hash algorithm, and info for PRK_out is:
where the last value is the length in bytes of the output of the EDHOC hash algorithm.
The OSCORE Master Secret and OSCORE Master Salt are derived with the EDHOC_Exporter as specified in .
where PRK_exporter is derived from PRK_out:
where hash_length is the length in bytes of the output of the EDHOC hash algorithm, and info for the PRK_exporter is:
where the last value is the length in bytes of the output of the EDHOC hash algorithm.
OSCORE Parameters
The derivation of OSCORE parameters is specified in .
The AEAD and hash algorithms to use in OSCORE are given by the selected cipher suite:
The mapping from EDHOC connection identifiers to OSCORE Sender/Recipient IDs
is defined in .
C_R is mapped to the Recipient ID of the server, i.e., the Sender ID of the client. The byte string 0x27, which as C_R is encoded as the CBOR integer 0x27, is converted to the server Recipient ID 0x27.
C_I is mapped to the Recipient ID of the client, i.e., the Sender ID of the server. The byte string 0x37, which as C_I is encoded as the CBOR integer 0x0e, is converted to the client Recipient ID 0x37.
The OSCORE Master Secret is computed through EDHOC_Expand() using the
application hash algorithm (see ):
where oscore_key_length is by default the key length in bytes for the application AEAD
algorithm, and info for the OSCORE Master Secret is:
where the last value is the key length in bytes for the application AEAD algorithm.
The OSCORE Master Salt is computed through EDHOC_Expand() using the application hash algorithm (see ):
where oscore_salt_length is the length in bytes of the OSCORE Master Salt, and info for the OSCORE Master Salt is:
where the last value is the length in bytes of the OSCORE Master Salt.
Key Update
The key update is defined in .
where hash_length is the length in bytes of the output of the EDHOC hash function, and the context for KeyUpdate is:
and where info for the key update is:
After the key update, the PRK_exporter needs to be derived anew:
where info and hash_length are unchanged as in .
The OSCORE Master Secret is derived with the updated PRK_exporter:
where info and oscore_key_length are unchanged as in .
The OSCORE Master Salt is derived with the updated PRK_exporter:
where info and oscore_salt_length are unchanged as in .
Invalid Traces
This section contains examples of invalid messages, which a compliant implementation will not compose and must or may reject according to , , , and . This is just a small set of examples of different reasons for which a message might be invalid. The same types of invalidities apply to other fields and messages as well. Implementations should make sure to check for similar types of invalidities in all EDHOC fields and messages.
Encoding Errors
Surplus Array Encoding of a Message
message_1 is incorrectly encoded as a CBOR array. The correct encoding is a CBOR sequence according to .
Surplus bstr Encoding of the Connection Identifier
The connection identifier C_I = 0x0e is incorrectly encoded as the CBOR byte string 41 0e. The correct encoding is the integer 0e according to .
Surplus Array Encoding of the Ciphersuite
The element SUITES_I = 2 is incorrectly encoded as the CBOR array 81 02. The correct encoding is the integer 02 according to .
Text String Encoding of the Ephemeral Key
The third element of message_1 (G_X) is incorrectly encoded as a text string. The correct encoding is a byte string according to .
Wrong Number of CBOR Sequence Elements
The CBOR sequence in message_2 has an incorrect number of elements. The correct number of elements in the CBOR sequence is 1 according to .
Surplus Map Encoding of the ID_CRED Field
The element ID_CRED_R in PLAINTEXT_2 is incorrectly encoded as the map a1 04 42 32 10. The correct encoding is 42 32 10 according to .
Surplus bstr Encoding of the ID_CRED Field
The element ID_CRED_R in PLAINTEXT_2 is incorrectly encoded as the byte string 41 32. The correct encoding is 32 according to .
CryptographyRelated Errors
Error in the Length of the Ephemeral Key
The third element (G_X) has an invalid length. The selected cipher suite is cipher suite 24 with curve P384 according to Sections and of . The correct length of the xcoordinate is 48 bytes according to and .
Error in Elliptic Curve Representation
The xcoordinate in G_X is invalid as x ≥ p. It is required that x < p according to Section 5.6.2.3 of , which is referenced in .
Error in the Elliptic Curve Point
The xcoordinate in G_X is invalid as it does not correspond to a point on the P256 curve. It is required that y^{2} ≡ x^{3} + a ⋅ x + b (mod p) according to Section 5.6.2.3 of , which is referenced in .
Curve Point of the Low Order
The Curve25519 point is invalid as it is of low order and fails the check for allzero output according to .
Error in the Length of the MAC
The third element (Signature_or_MAC_2) has an invalid length. The length of Signature_or_MAC_2 is given by the cipher suite, and the MAC length is at least 8 bytes according to .
Error in the Elliptic Curve Encoding
The third element (G_X) is incorrectly encoded. The correct encoding is with leadingzero octets according to , which is referenced in .
Nondeterministic CBOR
Unnecessary Long Encoding
The element METHOD = 3 is incorrectly encoded as a 16bit integer. The deterministic encoding 03 is correct according to and , which states that the arguments for integers, lengths in major types 2 through 5, and tags are required to be as short as possible.
IndefiniteLength Array Encoding
The element SUITES_I = [6, 2] is incorrectly encoded as an indefinitelength array. The correct encoding is the definitelength array 82 06 02 according to , which is referenced in .
Security Considerations
This document contains examples of EDHOC . The security considerations described in apply. The keys printed in these examples cannot be considered secret and MUST NOT be used.
IANA Considerations
This document has no IANA actions.
References
Normative References
Ephemeral DiffieHellman Over COSE (EDHOC)
Informative References
CBOR playground
Recommendation for PairWise KeyEstablishment Schemes Using Discrete Logarithm Cryptography
Recommendations for Discrete Logarithmbased Cryptography: Elliptic Curve Domain Parameters
Acknowledgments
The authors want to thank all people verifying EDHOC test vectors and/or contributing to the interoperability testing, including: , , , , , , , , and .