+COSE WG (didn’t notice it wasn’t in discussion until now) Yes, exclusively considering the COSE for SUIT use case, it seems safe enough from what you describe below.
But, from a general COSE view, I still see risk and/or and open issue. - Privacy provided by COSE shouldn’t be at risk if there is no signing - The safety of one algorithm shouldn’t be continent on the receiver not implementing other algorithms I suppose we could write these things in errata security considerations and be done with COSE. A large part of my comment here is about process and generality. Hannes, you’re (understandably) just focusing on SUIT. That’s understandable, but not enough in the long run. For example, I’m bring up HPKE to to say it should be used for SUIT, but because it is an example of another more thorough standard (except it didn’t support multiple recipients). My interest is more in encryption of EAT tokens. Often the EAT signing will be before the encryption so it won’t protect the COSE algorithm ID. When I was managing a team at Qualcomm, I would have responded to an issue like this by redirecting some the people that worked for me to work on this until it was solved. IETF is kind of a volunteer organization, so we can’t do that. Personally, I plan to work on this later 2024 after I’ve paid attention to some of my other projects for a while. I also understand how frustrating this is. Around 2017 I chose to use COSE signing with CMS encryption for a Qualcomm EAT precursor product because COSE encryption wasn’t ready and was hard to understand. LL On Dec 31, 2023, at 1:48 AM, Hannes Tschofenig <[email protected]> wrote: Hi Laurence, comments below. Am 28.12.2023 um 18:58 schrieb lgl island-resort.com: On Dec 24, 2023, at 5:19 AM, Hannes Tschofenig <[email protected]><mailto:[email protected]> 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 attack you are describing is to change the algorithm id from AES-GCM to AES-CBC. If you do so, this change would be detected by the signature covering the entire SUIT manifest. Furthermore, the recipient will check whether the use of AES-CBC is an allowed algorithm. Finally, for the attack to work as presented in LAMPS the recipient then has to try to decrypt the payload and return the result back to the sender. None of this is realistic but nevertheless worth describing in the draft. 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. I agree but the use of AES-CBC is limited to special use cases and the use case envisioned was firmware encryption. For other use cases, a receipient receiving a payload encrypted with AES-CBC has to fail because there is no use for algorithms other than AEAD ciphers. In general, one has to store algorithm information alongside the key and not let attackers switch algorithms. 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. You can use HPKE for SUIT but we haven't specified it. In the above paragraph I am observing that HPKE in the two layer approach is not necessarily immune to the attack. 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. In SUIT we luckilly have a dedicated document that explains how to use encryption properly. At the start, we thought we just have to reference COSE_Encrypt from the COSE specification and to be done with it. As we know, it turned out to be quite different. Ciao Hannes LL _______________________________________________ Suit mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/suit
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
