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

[Hannes Tschofenig <[e-mail]>]

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
>> <[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 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit