Avoid key and IV reuse for AEADs

[charlie-j]

An AEAD scheme is meant to be used only once with a given IV and key,
see e.g. [RFC5116, Sec 3.1].

The standard currently specifies (Appendix E, p. 73) that an "EDHOC implementation MAY keep the protocol state to be able to recreate the previously sent EDHOC message and resend it." For a fixed protocol state before the computation of message_3, the plaintext of message_3 is randomized if the corresponding signature scheme is (like it is the case for ECDSA), but IV_3 and K_3 are not. Allowing to recompute message_3 thus leads to a situation where the same key and IV are used for two (or more) distinct messages.

To solve the issue, there is a couple of possible actions:

• remove the corresponding sentence (Appendix E, p. 73)
• replace the "MAY" with a "MUST NOT"
• explain the situation in more details

[emanjon]

Good point. Clearly a risk that the standard is implemented in an insecure way here. This needs either
additional clarification/considerations or technical changes. In addition to the solutions described above you could also use the plaintext in the key/IV derivation.

I think this needs to be discussed with implementors. Recomputations or storing is an implementation aspect. I don't know what the tradeoffs would be. Storing the random input to ECDSA seems impractical.

I think this issue also affects message_2.

[emanjon]

With deterministic encryption like AES-SIV or deterministic signatures like deterministic ECDSA, EdDSA, RSA, or LMS this is not an issue, but deterministic ECDSA and EdDSA are not to be recommended on IoT devices.

[charlie-j]

In addition to the solutions described above you could also use the plaintext in the key/IV derivation.

It would have been a cool solution, but the recipient needs to be able to compute the key and IV, so inserting the plaintext here would make it impossible for the recipient to compute the needed material for the decryption.

I think this issue also affects message_2.

Oooh, good point For message 2, the consequence of the behaviour is that the attacker can obtain the xor of the two plaintexts. So, it would get a bunch of zeros, and then the xor of the two randomized signatures. What are the concrete consequences of this, I don't know... But probably better to avoid such weird behavior anyway?

To note, for message_3, as the AEAD algorithm is not fixed the consequences of the IV reuse are not specified and we should assume the worst possible case.

[emanjon]

In addition to the solutions described above you could also use the plaintext in the key/IV derivation.

It would have been a cool solution, but the recipient needs to be able to compute the key and IV, so inserting the plaintext here would make it impossible for the recipient to compute the needed material for the decryption.

Yes my mistake :) if you need to use the message in a smart way you need to do it inside the algorithm like in AES-GCM-SIV.

I think this issue also affects message_2.

Oooh, good point For message 2, the consequence of the behaviour is that the attacker can obtain the xor of the two plaintexts. So, it would get a bunch of zeros, and then the xor of the two randomized signatures. What are the concrete consequences of this, I don't know... But probably better to avoid such weird behavior anyway?

Yes, for message_2 and all the currently specified AEAD algorithms the consequences on confidentiality is that the attacker gets as you say "a bunch of zeros, and then the xor of the two randomized signatures". As the signature algorithm is not specified I think we have follow what you say below: In the worst case we have to assume that the attacker gets knowledge of both signatures. And a signature can be used to identity the public key (by testing verification). But with ECDSA this is probable not practically doable).

To note, for message_3, as the AEAD algorithm is not fixed the consequences of the IV reuse are not specified and we should assume the worst possible case.

Yes I agree, in the worst case you have assume that all confidentiality and integrity is gone and the key is revealed.

[charlie-j]

I've put some more thought on that, and I really don't see any practical solution :/

Maybe the best thing is simply to describe the issue, either in the cryptographic considerations or the Appendix E, and say that when such a feature is implemented, deterministic signatures SHOULD be preferred?

[gselander]

My proposal is that we should replace the "MAY" with a "SHOULD NOT", and give an example of a setting when it may anyway be used.