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

[Michael Richardson <[e-mail]>]

Hannes Tschofenig <hannes.tschofenig=[e-mail]> wrote:
    > 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

Yeah, but my understanding of the attack is that it requires that:
1) the key be used in CMS and non-CMS things
2) that it's enabled because CMS' key derivation process does not have any
   CMS-specific things in it. (And all of our stuff from that era suffer from this)

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

I don't think we need to, since in general COSE has usage specific content as part of
the key derivation process.  But, I guess in constructing our two-layer
approach, we have broken that.

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

I think we should do that if it is not too late.

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

Hmm.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide