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

[Hannes Tschofenig <[e-mail]>]

Hi Laurence, Hi all,


given the start of the holidays I have managed to watch the recording
from the LAMPS IETF#118 session. Below are my reflections about this topic.


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.

The recipient layer carries the CEK. In the draft the CEK is produced
randomly. For the AES-KW, no KDF used. For ES-DH we use a KDF and pass
in the parameters discussed at
https://datatracker.ietf.org/meeting/117/materials/slides-117-suit-encrypted-payloads-in-suit-manifests.
In earlier versions of the draft we passed in the algorithm used at the
content encryption layer and identity information of the sender and the
recipient. Did did, however, change our mind because this approach was
more complex to use in practice. See discussion earlier this year
(around IETF#117).


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.


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).


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.


Ciao

Hannes


PS: Merry Christmas Everyone


Am 17.12.2023 um 18:36 schrieb lgl island-resort.com:
> I think both algorithm IDs should be protected. Both the AES-KW and the AES-GCM identifier.
>
> The main reason is to provide very thorough protection. Protecting both algorithm IDs may prevent attacks we don’t even know about today. This is the level of security and quality that IETF/COSE should work too.
>
> Seems like HPKE used this kind of thinking (but didn’t support multiple recipients).
>
> I haven’t thought it through completely, but I think HPKE is probably not vulnerable to the AEAD downgrade attack described in Prague, because it used that kind of approach.
>
> I don’t think the COSE work did for ECDH plus KDF is as thorough as HPKE’s work, but CMS is worse than COSE.
>
> It’s not a matter of trying to figure out what 9053 intended. It’s a matter that it didn’t go as far as it should.
>
> Seems like there’s many different approaches to fixing this ranging from trying for as little work as possible like having all the alg IDs in the KDF input to something very major like adding multiple recipient support to HPKE.
>
> This is an incomplete message as I am not proposing anything and that I’m not providing analysis to properly link up to the AEAD downgrade attack. This stuff is hard for me to think about...
>
> LL
>
>
>
> Also, the COSE documents are sort of incomplete, in that they leaves some very difficult security analysis for the implementor in the area of KDF input  in contrast that to the extensive warnings about AES-CTR mode in RFC 9459 that expect the reader knows very little. Personally, I learned about AES-CTR mode issues twenty-thirty years ago and think it is common knowledge.
>
>
>> On Dec 17, 2023, at 8:20 AM, Hannes Tschofenig<[e-mail]>  wrote:
>>
>> Hi Laurence,
>>
>>
>> I believe these are two different aspects but it is, of course, worth
>> checking it again.
>>
>>
>> The algorithm input to the KDF context structure is something Ken and I
>> coincidently discussed last week.
>>
>>
>> Initially, we used the algorithm id used for encrypting the firmware
>> image in the KDF context. Then, we changed it to the algorithm id used
>> in the recipient structure to encrypt the CEK, which is A128KW in our
>> example below. This reflected our reading of the COSE specification*.
>> When Ken explored the use of ECDH-ES + HKDF-256, it was not clear
>> anymore what algorithm id to include in the KDF context.
>>
>>
>> *: The relevant paragraph from Section 5.2 of RFC 9053 is when Jim
>> talked about the AlgorithmID and said:
>>
>> "This field indicates the algorithm for which the key material will be
>> used. This normally is either a key wrap algorithm identifier or a
>> content encryption algorithm identifier."
>>
>>
>> Of course, this leaves room for interpretation because the keying
>> material derived by ESDH is used twice, first to encrypt the random CEK.
>> Then, the CEK is used to encrypt the firmware image. So, which usage of
>> the key is meant here?
>>
>>
>> Ciao
>>
>> Hannes
>>
>>
>> Am 15.12.2023 um 04:14 schrieb lgl island-resort.com:
>>> Maybe I’m wrong here (hope so), but AES-GCM is used with ECDH-ES + A128KW for the bulk payload encryption and the algorithm ID identifying it is not mixed in with the KDF context so the alg ID is not really protected.
>>>
>>> Will look at the referenced paper some more.
>>>
>>> LL
>>>
>>>
>>>> On Dec 14, 2023, at 10:34 AM, Russ Housley<[e-mail]>  wrote:
>>>>
>>>> Laurence:
>>>>
>>>> I am aware of a presentation about an attack against AES-GCM and AES-CCM:
>>>>
>>>> 	Roth, J. and F. Strenzke,
>>>> 	"AEAD-to-CBC Downgrade Attacks on CMS",
>>>> 	8 November 2023,
>>>> 	<https://datatracker.ietf.org/meeting/118/materials/slides-118-lamps-attack-against-aead-in-cms>.
>>>>
>>>> I am not aware of any attacks that involve AES-KW.
>>>>
>>>> Where can I find information about the attack you are talking about?
>>>>
>>>> Russ
>>>>
>>>>> On Dec 14, 2023, at 12:19 PM, lgl island-resort.com<[e-mail]>  wrote:
>>>>>
>>>>> Note that there is a vulnerability in ECDH-ES + A128KW — the one that was presented in Prague. I think there are fixes, and it’s on my list to dig into it (IETF/COSE needs a full, proper and secure multi-recipient modern encryption format), but don’t have bandwidth right now.
>>>>>
>>>>> LL
>>>>>
>>>>>> On Dec 14, 2023, at 2:18 AM,hannes.tschofenig=[e-mail]  wrote:
>>>>>>
>>>>>> Thank you all for your quick response. From the feedback it seems clear to go for ECDH-ES + A128KW
>>>>>> We will update the documents accordingly.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Suit<[e-mail]>  On Behalf Of Akira Tsukamoto
>>>>>> Sent: Donnerstag, 14. Dezember 2023 06:29
>>>>>> To: Brendan Moran<[e-mail]>; Russ Housley<[e-mail]>; Hannes Tschofenig<[e-mail]>
>>>>>> Cc:[e-mail];[e-mail]; Ken Takayama<[e-mail]>
>>>>>> Subject: Re: [Suit] [Teep] ECDH-ES + A128KW vs. ECDH-ES + HKDF-256
>>>>>>
>>>>>> Hi Brendan,
>>>>>>
>>>>>> I am fine changing the MTI with ECDH-ES + A128KW.
>>>>>>
>>>>>> Akira
>>>>>>
>>>>>> On 12/14/2023 12:08 AM, Russ Housley wrote:
>>>>>>> I think ECDH-ES + A128KW covers more use cases.  It can be used with on recipient or many recipients.  So, I'd like to see that be the MTI.
>>>>>>>
>>>>>>> Russ
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 13, 2023, at 3:38 AM,hannes.tschofenig=[e-mail]  wrote:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> In the SUIT firmware encryption draft we have so far used ECDH-ES + A128KW, which is also what we implemented in t_cose to generate the examples.
>>>>>>>>
>>>>>>>> In a discussion with Ken today we realized that the SUIT-MTI draft has always used ECDH-ES + HKDF-256 instead.
>>>>>>>>
>>>>>>>> Now, the question is: Should we support both, ECDH-ES + A128KW and ECDH-ES + HKDF-256?
>>>>>>>>
>>>>>>>> IHMO we definitely need AES-KW for scenarios where we encrypt a firmware with a CEK once and then distribute that encrypted firmware image to many recipients. In this case, we
>>>>>>>>
>>>>>>>> * randomly generate a CEK,
>>>>>>>> * encrypt the firmware using this CEK,
>>>>>>>> * encrypt this CEK with a KEY unique per recipient with a KEK. The KEK is the result of using ECDH-ES with an KDF, as described in Section 6.4 of RFC 9053.
>>>>>>>>
>>>>>>>>
>>>>>>>> For scenarios where we send one firmware image to one recipient we could use ECDH-ES + HKDF-256 and currently we have a little bit of overhead here by using ECDH-ES + A128KW.
>>>>>>>>
>>>>>>>> My preference is to leave the SUIT firmware encryption draft as is and to change the SUIT MTI draft to reference ECDH-ES + A128KW instead of ECDH-ES + HKDF-256.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> Ciao
>>>>>>>> Hannes
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> TEEP mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/teep
>>>>>> _______________________________________________
>>>>>> Suit mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/suit
>>>>>>
>>>>>> _______________________________________________
>>>>>> Suit mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/suit
>>> _______________________________________________
>>> Suit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/suit