Re: [Suit] suit-firmware-encryption-00

[Hannes Tschofenig <[e-mail]>]

Hi Michael,

Thanks for your quick feedback!

A few responses below.

-----Original Message-----
From: Suit <[e-mail]> On Behalf Of Michael Richardson
Sent: Thursday, May 27, 2021 2:37 AM
To: [e-mail]
Subject: [Suit] suit-firmware-encryption-00


I have read draft-tschofenig-suit-firmware-encryption-00 and I think that the WG should adopt it.  It fits within the charter as it is within what would have been done in the manifest document.

Some comments:

1) I found this sentence really awkward:
     In addition to offering protection against modification, which is
     provided by a digital signature or a message authentication code, the
     firmware image may also be confidentiality protected using
     encryption.

Maybe:
     the
     firmware image may also be afforded confidentiality using
     encryption.

[Hannes] Fixed.


2) "This might be done to protect
   confidential information or prevent discovery of vulnerabilities
   through reverse engineering."

   this screams security through obscurity.   I know that some people still
   think that this is important, so I guess I would just drop the claim.
   There are also some significant public policy issues around declining
   access to review and audit code, including defending against insertion
   of malware at the source, or by National Security Letter.
   (consider SolarWind situation)
   I would like some text in the Security Considerations about this.

[Hannes] There may be many reasons why encryption is useful but in the referenced sentence we have been thinking about ROP. I changed the text.

The issues you mention are also important but are probably unrelated to encryption itself. If you manage to compromise a company that is responsible for distributing software/firmware updates then there will be a problem.

I agree that there are also challenges with certification schemes that prevent developers from seeing the source code (or from publishing the source code). That's yet another issue.

3) Are the terms CEK and KEK from RFC3394?  I didn't find it there.
   I wonder how they play out as acronyms in languages without a soft-C
   sound... where both come out as "kay eh kay" (CEK) and "kay eh kay" (KEK)...
   It's bad enough in DNSSEC with Zee Ess Kay vs Zed Ess Kay...

[Hannes] Russ responded to this point and I added references.

4) "However, the COSE_recipient structure can contain the same CEK
   encrypted with many different KEKs if needed to reach all of the
   authorized recipients."

   This is exactly like how DVDCSS works, and how the dvdcss breach occured
   when a KEK was all zeros.  Something to think about.
   It seems that the HPKE version would not suffer from this mishap?

[Hannes] With HPKE this is not possible because the KEK is the DHE-derived key. With AES-KW you could still pick a KEY that consists of all zeros. You could also pick a CEK that consists of all zeros. I will add text to the security consideration section.


5) We had a discussion about how to have a complete CDDL during the meeting
   yesterday.   I think that this version has the complete CDDL shown?
   There isn't that much copy and pasted from 8152(bis), and I think it's
   clearer like it is.  It just needs to be noted what is coming from 8152.
   If 8152bis-bis *CHANGED* COSE_Encrypt in an incompatible way, then we'd
   still be pointing at 8152bis until we updated this document.

[Hannes] I have followed the suggestion Henk provided at the last IETF meeting and copied the CDDL from COSE and then removed the parts that are not needed by this specification. When Russ reviewed the CDDL he made further suggestions on how to improve the structure because the nested structure (whereby the same names are used for the structures) made it difficult to refer to the relevant elements.

6) should the pseudo-code in section 4, starting with "CEK = random()", be a
   figure?

[Hannes] Fixed.

7) irtf-cfrg-hpke says it is in state awaiting IRSG reviews.   Does that mean
   it is close to being published?

[Hannes] I thought so. In any case, the spec is being used by MLS and TLS ESNI for which running code already exists.

8) The new HPKE methods defines here might be generally useful outside of
   firmware-encryption.   I don't propose to change the document in a way to
   make it generic, but are there any applicability that we need to import?

[Hannes] Yes, that's true. Maybe we should extract the HPKE-part. Need to think about it a bit more...

9) Given that:
   "Both cases require some upfront communication interaction, which is
   not part of the SUIT manifest."

   do we need to say anything about this communication?

[Hannes] We say something about it in the architecture document. I have added a reference.

   Can an ECDH be part of an IDevID?

[Hannes] You should be able to answer that question...

   Would manufacturers be tempted to use the same ECDH in every device?
   In all devices made on a particular day?

[Hannes] No, I don't think so. I would assume that manufacturers are going to provision these keys in the factory to the device (like they would do with other keys as well).

Ciao
Hannes

PS: Here is the updated draft:
Htmlized:       https://datatracker.ietf.org/doc/html/draft-tschofenig-suit-firmware-encryption
Diff:           https://www.ietf.org/rfcdiff?url2=draft-tschofenig-suit-firmware-encryption-01


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [











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




IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.