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

From: Michael Richardson <[email-masked]>
Date: Wed, 26 May 2021 20:36:37 -0400

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.

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.

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

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?

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.

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

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

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?

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?
   Can an ECDH be part of an IDevID?
   Would manufacturers be tempted to use the same ECDH in every device?
   In all devices made on a particular day?

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

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 May 2021 15:40:46 -0400

Michael:

Just responding th one of your comments.

>   It's bad enough in DNSSEC with Zee Ess Kay vs Zed Ess Kay...

CEK = content-encryption key, which is defined in PKCS#7 and CMS.  I think the first uses are in RFC 2630 and RFC 2631.

KEK - key-encryption key, which is used in thoses same RFCs, but it was also used as early as RFC 1949.

Russ

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 May 2021 21:57:13 +0200

> KEK - key-encryption key, which is used in thoses same RFCs, but it was also used as early as RFC 1949.

FYI: RFC 4949, which should still be the goto resource here, has KEK, but not CEK (which is called a DEK there, if I get the analogy right — I certainly have heard CEK much more than DEK).

Grüße, Carsten

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 May 2021 16:00:38 -0400

> FYI: RFC 4949, which should still be the goto resource here, has KEK, but not CEK (which is called a DEK there, if I get the analogy right — I certainly have heard CEK much more than DEK).

Data Encrypting Key (DEK) comes from Privacy Enhance Mail, which was first published as RFC 989.

Russ

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 27 May 2021 13:01:58 -0700

> On May 27, 2021, at 12:57 PM, Carsten Bormann <[email-masked]> wrote:
> 

COSE RFC 8152 uses CEK and KEK.  I’ve heard them in other contexts and I find them clear and useful myself.

LL

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 May 2021 15:15:19 +0000

Hi Michael,

Thanks for your quick feedback!

A few responses below.

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Michael Richardson
Sent: Thursday, May 27, 2021 2:37 AM
To: [email-masked]
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:

Maybe:
     the

[Hannes] Fixed.

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

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

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

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

[Hannes] Fixed.

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

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

9) Given that:

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

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

[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

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.

---

From: Russ Housley <[email-masked]>
Date: Mon, 31 May 2021 12:23:04 -0400

Michael:

Building on Hannes' response to three of your questions.

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

SUIT is using signature for the authentication and integrity of the firmware.  If the signature remains in place, a party in the middle of the distribution cannot insert any malware.

> [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…

Please let us know if you see ways to add further clarity.

> 9) [snip]

Are you aware of anyone that is putting key agreement public keys in the IDevID?  I thought everyone was using signature keys.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 May 2021 12:41:29 -0400

Russ Housley <[email-masked]> wrote:
    >> 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.

    > SUIT is using signature for the authentication and integrity of the
    > firmware.  If the signature remains in place, a party in the middle of
    > the distribution cannot insert any malware.

The encryption of the firmware keeps third parties from auditing the software
updates to determine if malware has been inserted at the "factory"
Both white and black hats are currently using binary diff systems to look at
patches.  Black hats use this to develop exploits in the gap between 9am EST
and 9am PST!
I am suggesting that this is a "Security Consideration"

    > Are you aware of anyone that is putting key agreement public keys in
    > the IDevID?  I thought everyone was using signature keys.

Yes, that was the point of my question.

---

From: Russ Housley <[email-masked]>
Date: Mon, 31 May 2021 12:48:34 -0400

> I am suggesting that this is a "Security Consideration"

Yes, this is a reasonable thing to add to the Security Considerations.

If a trustworthy party in the middle of the distribution path is able to detect a problem with cleartext (but signed) firmware, they can report a vulnerability and refuse to pass the update along.

Russ

---

From: "Dick Brooks" <[email-masked]>
Date: Mon, 31 May 2021 12:53:06 -0400

" If a trustworthy party in the middle of the distribution path is able to
detect a problem with cleartext (but signed) firmware, they can report a
vulnerability and refuse to pass the update along."

This is precisely the function SCRM vendors are performing today. Encrypting
a binary object would be an impediment to software supply chain risk
assessment functions in place today.

Thanks,

Dick Brooks

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Russ Housley
Sent: Monday, May 31, 2021 12:49 PM
To: Michael Richardson <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

Michael:

>>> 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.
> 
>> firmware.  If the signature remains in place, a party in the middle 
>> of the distribution cannot insert any malware.
> 
> The encryption of the firmware keeps third parties from auditing the 
> software updates to determine if malware has been inserted at the
"factory"
> Both white and black hats are currently using binary diff systems to 
> look at patches.  Black hats use this to develop exploits in the gap 
> between 9am EST and 9am PST!

If a trustworthy party in the middle of the distribution path is able to
detect a problem with cleartext (but signed) firmware, they can report a
vulnerability and refuse to pass the update along.

Russ
_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

---

From: Russ Housley <[email-masked]>
Date: Mon, 31 May 2021 12:56:04 -0400

Dick:

Yes, and there are other use cases that require encryption.

Russ

> On May 31, 2021, at 12:53 PM, Dick Brooks <[email-masked]> wrote:
>

---

From: "Dick Brooks" <[email-masked]>
Date: Mon, 31 May 2021 13:07:07 -0400

I agree, Russ. 

Parties subject to the 5/12 Executive Order
(https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/ex
ecutive-order-on-improving-the-nations-cybersecurity/) will likely want to
perform a proactive SCRM risk assessment prior to installation, if my
interpretation of the EO is accurate.

Thanks,

Dick Brooks

-----Original Message-----
From: Russ Housley <[email-masked]> 
Sent: Monday, May 31, 2021 12:56 PM
To: Dick Brooks <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Hannes Tschofenig
<[email-masked]>; [email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

Dick:

Russ

> On May 31, 2021, at 12:53 PM, Dick Brooks
<[email-masked]> wrote:
> 
> " If a trustworthy party in the middle of the distribution path is 
> able to detect a problem with cleartext (but signed) firmware, they 
> can report a vulnerability and refuse to pass the update along."
> 
> This is precisely the function SCRM vendors are performing today. 
> Encrypting a binary object would be an impediment to software supply 
> chain risk assessment functions in place today.
> 
> Thanks,
> 
> Dick Brooks
> 
> If a trustworthy party in the middle of the distribution path is able 
> to detect a problem with cleartext (but signed) firmware, they can 
> report a vulnerability and refuse to pass the update along.
> 
> Russ

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 May 2021 19:47:20 +0000

Hi Michael,

> The encryption of the firmware keeps third parties from auditing the software updates to determine if malware has been inserted at the "factory"
> Both white and black hats are currently using binary diff systems to look at patches.  Black hats use this to develop exploits in the gap between 9am EST and 9am PST!

A description of the software is contained in the COSWID and, as Brendan suggests, in a MUD file that is included with the manifest (see https://datatracker.ietf.org/doc/html/draft-moran-suit-mud).
Furthermore, I can imagine that those authorized to audit the software can do so either based on the source code or by giving them access to the binary.

Ciao
Hannes

---

From: "Dick Brooks" <[email-masked]>
Date: Mon, 31 May 2021 15:56:23 -0400

I believe encryption would "get in the way of" a malware scan performed
during a software supply chain risk assessment. 

Thanks,

Dick Brooks

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, May 31, 2021 3:47 PM
To: Michael Richardson <[email-masked]>; Russ Housley
<[email-masked]>; [email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

Hi Michael,

   > > firmware.  If the signature remains in place, a party in the middle
of

> The encryption of the firmware keeps third parties from auditing the
software updates to determine if malware has been inserted at the "factory"
> Both white and black hats are currently using binary diff systems to look
at patches.  Black hats use this to develop exploits in the gap between 9am
EST and 9am PST!
> I am suggesting that this is a "Security Consideration"

A description of the software is contained in the COSWID and, as Brendan
suggests, in a MUD file that is included with the manifest (see
https://datatracker.ietf.org/doc/html/draft-moran-suit-mud).
Furthermore, I can imagine that those authorized to audit the software can
do so either based on the source code or by giving them access to the
binary.

Ciao
Hannes

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.
_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 May 2021 19:57:00 +0000

Hi Dick,

with the SUIT manifest format I hope we can make information available to trusted third parties (MUD, COSWID and alike) and at the same time use encrypted binaries. Having access to the plaintext binary is essential for adversaries to mount attacks. (Happy to give a tutorial about how this works.)

Like-wise differential updates may make it difficult for SCRM vendors to make their analysis but the information in the manifest can help them.

Severable fields allows to remove information from the manifest before it is sent to the device. This reduces overhead and prevents untrusted parties from gathering information from the manifest.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Monday, May 31, 2021 7:07 PM
To: 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

I agree, Russ.

Parties subject to the 5/12 Executive Order (https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/ex
ecutive-order-on-improving-the-nations-cybersecurity/) will likely want to perform a proactive SCRM risk assessment prior to installation, if my interpretation of the EO is accurate.

Thanks,

Dick Brooks

Never trust software, always verify and report! T http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Russ Housley <[email-masked]>
Sent: Monday, May 31, 2021 12:56 PM
To: Dick Brooks <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

Dick:

Russ

---

From: "Dick Brooks" <[email-masked]>
Date: Mon, 31 May 2021 15:59:53 -0400

Thanks, Hannes. I just submitted a concern regarding the problem encryption
creates for malware scanning, which is one of the SCRM risk assessment
steps, performed before installation

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Monday, May 31, 2021 3:57 PM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

Hi Dick,

with the SUIT manifest format I hope we can make information available to
trusted third parties (MUD, COSWID and alike) and at the same time use
encrypted binaries. Having access to the plaintext binary is essential for
adversaries to mount attacks. (Happy to give a tutorial about how this
works.)

Like-wise differential updates may make it difficult for SCRM vendors to
make their analysis but the information in the manifest can help them.

Severable fields allows to remove information from the manifest before it is
sent to the device. This reduces overhead and prevents untrusted parties
from gathering information from the manifest.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Monday, May 31, 2021 7:07 PM
To: 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; Hannes Tschofenig

I agree, Russ.

Thanks,

Dick Brooks

-----Original Message-----
From: Russ Housley <[email-masked]>
Sent: Monday, May 31, 2021 12:56 PM
To: Dick Brooks <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Hannes Tschofenig

Dick:

Russ