Simplify and improve the session key management

[charlie-j]

As is, the session key PRK_4x3m offers much weaker properties than
the final exported keys.

Reason 1: session keys don't have "contributiveness" or "key control": even if Alice produces good randomness each time, keys may not be unique (if Bob sends low order points or the identity point - see footnote 1). Exported keys fix this by inclusion of transcript, which also gives a better binding to the protocol execution.

Reason 2: PRK_4x3m does not authenticate TH_4 as it is independent of it. If there are ways "to play with" MESSAGE_3 in order to obtain distinct values of TH_4 on both sides (we discuss this further below), any application key derivation not using TH_4 and only PRK_4x3m will break the authentication claim over TH_4.

As an additional remark, the current construction makes it difficult to identify in cryptographic terms what is the session key of the protocol, as the stored key material at the end is both TH_4 and PRK_4x3m.

Our suggestion is to follow a design similar to e.g. TLS, and to have a final key derivation, that combines both TH_4 and PRK_4x3m into a final key. This has multiple advantages:

• solve the issues raise before, ensuring contributivity and no key control over the session key, as well as ensuring that the session key is tied to the execution through PRK_4x3m;
• simplify the final state of the protocol, where instead of managing both TH_4 and PRK_4x3m, only the final key is stored;
• simplify the exporter, as it would only now depend on the session key.

To make this proposal a bit more concrete, we provide a first draft of a commit that could implement this solution here: charlie-j@9f4843a

Breaking TH_4 authentication

We discuss here some subtle ways that may lead to a breach of authentication for TH_4, which could make the authentication very implementation dependent. Those mostly rely on the fact that using ciphertext_3 inside the transcript instead of the underlying payload may allow the attacker some leeway in changing the concrete value of ciphertext_3, thus leading to an initiator and a responder disagreeing on the vlaue of TH_4 after verification of message 3.

1. According to Appendix B, there appear to exist multiple valid encodings of the same bitstring value. Typically, '12cd' can be encoded as '12cd',h'12cd' or << '12cd' >>. If that is the case, by converting between those multiple encodings, an attacker can change the value of the ciphertext_3 that is included inside TH_4 (unless the implementation does a COSE decoding to obtain the actual value of the ciphertext, then does a new COSE encoding to put back the value inside the COSE sequence used for TH_4).

2. The standard specifies a way to interface with the COSE encryption, where after computing a COSE_Encrypt0 object the protected and unprotected fields are dropped to only keep the ciphertext field. This may be error prone on the implementation side: if the full COSE_Encrpyt0 is used inside the implementation instead of the ciphertext field, the message becomes malleable through the unprotected header.

3. An encryption scheme based on the MacThenEncrypt paradigm may only provide integrity of the plaintext, and not integrity of the ciphertext itself. This would lead to two different values of ciphertext_3 each being a valid ciphertext for the same plaintext. This implies in term of a computational analysis that stronger security assumptions are required to prove the security of the key exchange. (Disclaimer: I incorrectly claimed that AES-CCM does not provide ciphertext integrity during the ietf 113 presentation, based on the fact that it is a MacThenEncrypt paradigm, but there is actually a proof of ciphertext integrity for CCM).

4. Related to Issue Avoid key and IV reuse for AEADs #268, where a randomized signature may force a responder to send two distinct MESSAGE_3 (different randomization), we could forward the first copy to I (while R keeps the second one). Both agents would derive the same PRK_4x3m but not the same TH_4.

-> As a side remark, using the plaintext inside of the ciphertext inside TH_4 would resolve points 1,2 and 3).

Footnotes

1. A low order point over the elliptic curve is a point h thus such that h^x=h with high probability. A particular case is the identity of the group, which is such that e^x=e always.

[gselander]

PR #276 looks very good, also as a starting point for other updates.

One comment by the ETH team [0] was

4. KDF Usage in KeyUpdate:

[---]

3) To prevent key reuse across primitives,
KeyUpdate should use Expand, not Extract. (see 3.)

To address this we could replace this:

EDHOC-KeyUpdate( nonce ):
PRK_out = Extract( nonce, PRK_out )

with something like this:

EDHOC-KeyUpdate( nonce ):
PRK_out = EDHOC-KDF( PRK_out, ' ', "EDHOC-KeyUpdate", nonce, hashalg-length)

where hashalg-length is the output length of the EDHOC Hash Algorithm

Another comment in [0]:

3. Key Reuse in KDF:
   The key schedule uses PRK_2e, PRK_3e2m, and PRK-4x3m as inputs in both Extract and Expand (depending on the authentication mode). Such reuse of key material across is generally not secure. Concretely, in HMAC/KMAC-based derivation, one would need to carefully ensure domain separation between such calls.

So, for example, this part:

If the Initiator authenticates with a static Diffie-Hellman key, then PRK_3m = Extract( PRK_3e2m, G_IY ), ...

could be changed into something like this:

If the Initiator authenticates with a static Diffie-Hellman key, then PRK_3m = Extract( Salt_3m, G_IY ), ...
where Salt_3m = EDHOC-KDF( PRK_3e2m, TH_3, "Salt_3m", h'', hashalg_length )

We'll make one of more PRs for this.

[0] https://mailarchive.ietf.org/arch/msg/lake/i2NYxn3vchQ1jUv91frlcqQ4sP0/

[gselander]

@charlie-j For clarity: The four cases of "Breaking TH_4 Authentication" you mention above, they are all mitigated by PR #276, right?

Just a remark about item 1:

Typically, '12cd' can be encoded as '12cd',h'12cd' or << '12cd' >>.

Note that the different representations you list are in the
diagnostic notation (which indeed has multiple ways to notate certain byte strings) but not the encoding used on the wire, so would e.g. not impact the ciphertext.

[charlie-j]

The four cases of "Breaking TH_4 Authentication" you mention above, they are all mitigated by PR #276, right?

Yes. By strongly tying together the session key and the transcript in the session key, we then avoid any of those issues about the transcript authentication.

Note that the different representations you list are in the
diagnostic notation (which indeed has multiple ways to notate certain byte strings) but not the encoding used on the wire, so would e.g. not impact the ciphertext.

Thanks for the explanation!

[charlie-j]

#276