Re: [Suit] [Teep] ECDH-ES + A128KW vs. ECDH-ES + HKDF-256

["lgl island-resort.com" <[e-mail]>]

On Dec 24, 2023, at 5:19 AM, Hannes Tschofenig <[e-mail]> wrote:


Hi Laurence, Hi all,

In draft-ietf-suit-firmware-encryption we use a two-layer approach, which means that there is

- a content encryption layer, and

- the recipient layer


For the content encryption layer we have included the protected headers in the Enc_structure structure with AEAD ciphers. The protected header may contain the algorithm identifier. In COSE, it is not mandatory to include the algorithm identifier in the protected header. For non-AEAD ciphers, the Enc_structure structure is not used.

Looks to me that all you have to do change the algorithm ID in the protected header from AES-GCM to AES. If the receiver is capable of processing messages with plain AES content encryption it will happily do so not knowing that it was AES-GCM in the original message. Since plain AES provides no data authentication the receiver won’t notice that the algorithm ID was modified. The protected headers aren’t really protected.

I haven’t thought this through deep enough to know how big a hole this is.


The delivery of firmware images is a one-shot message, if we ignore the possibility for conveying errors using SUIT report. The SUIT report, at least in my reading, would not give an adversary the information necessary for performing the attack outlined at https://datatracker.ietf.org/meeting/118/materials/slides-118-lamps-attack-against-aead-in-cms. It does not hurt to add a paragraph to the SUIT report draft saying that the returned information must not include decrypted payloads in case of a failure. In general, however, SUIT reports behaves like an oracle since it will give different responses depending on the success or failure of the SUIT manifest processing. It might be worthwhile to think about how to mitigate such attacks.

Yes, encryption for SUIT may be a use case safe from this attack, but COSE encryption should be safe regardless of the use case.


COSE-HPKE was mentioned in the mails below, although we do not use it in the SUIT firmware encryption draft. In the COSE-HPKE draft we use a one-layer and a two-layer approach. For the two layer approach, the situation is very similiar to my description above. The algorithm identifier is not included in the KDF at the recipient layer but it is instead included in the Enc_structure structure since the current version of the algorithm id is mandatory in the protected header. (See also the request to make it optional https://github.com/cose-wg/HPKE/issues/39).

I realize you can’t use HPKE for SUIT for a few reasons. I mention HPKE, because its design seems intrinsically immune. I think that is partly because of the design and validation process it used. Seems like COSE didn’t use as good a process.


So, what should we do? We could follow the approach Russ presented at IETF#118 and later described in https://datatracker.ietf.org/doc/draft-housley-lamps-cms-cek-hkdf-sha256/

His approach applies a KDF to the CEK and an algorithm id. The result is a new CEK, namely CEK'. CEK' is subsequently used for content encryption. This approach is generic but, on the other hand, a point solution to the specific attack presented to LAMPs. In his presentation Russ mentioned that we should/could include other information into the KDF but his write-up ultimately didn't contain that approach.

Alternatively, we could also include the algorithm id from the content encryption layer into the KDF already used for ES-DH and HPKE. This approach would not work for AES-KW.


Here is the part that worries me a bit: We keep changing the KDFs on a frequent basis and the KDFs used for the different algorithms are not well aligned across the different protocols and "container" formats. I have dropped a mail to Paul Van Oorschot asking him for feedback since he was the first one to come up with the class of attacks we are talking about here.

For me, the next step would be a document that is much more prescriptive on the use of KDF’s in COSE encryption. It probably will need to have something new to say how all algorithm IDs in all the COSE layers are input to the KDF. It might be standards track.

Then we need to review and debate and revise thoroughly to be sure we really got it right.

IMO, it is unfortunate, particularly for SUIT, that COSE encryption published in 9052 and 9053 isn’t quite complete in this area.

LL