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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 1 Jun 2021 10:40:20 +0000

Dick, I understand your line of argument.

At the same time I want to create awareness for the attacker point of view. They need to get access to plaintext firmware of an embedded device (unless the attacker already knows what the source was used). This is why there are advanced disassemblers available (such as IDA Pro, Binary Ninja, and Ghidra -- to name a few).

As a way forward I am proposing to use the additional data carried in the manifest for doing the SCRM risk assessment step. I believe that this should work.

Ciao
Hannes

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

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

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

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

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

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

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.

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: "Dick Brooks" <[email-masked]>
Date: Tue, 1 Jun 2021 07:31:34 -0400

Hannes,

I definitely see your point, it seems the real problem to solve is:
- How do we (1) prevent the bad guys from discovering SW details (source
code) from binaries while simultaneously (2) providing end use customers the
ability to conduct malware scans, and other risk management functions?

If we encrypt a binary distribution we achieve 1 but not 2
If we do not encrypt we achieve 2, but not 1

Are we really looking at a mutually exclusive choice?

Both of these objectives are trying to achieve the same thing: Keep the bad
guys from causing harm.

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Tuesday, June 1, 2021 6:40 AM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

At the same time I want to create awareness for the attacker point of view.
They need to get access to plaintext firmware of an embedded device (unless
the attacker already knows what the source was used). This is why there are
advanced disassemblers available (such as IDA Pro, Binary Ninja, and Ghidra
-- to name a few).

As a way forward I am proposing to use the additional data carried in the
manifest for doing the SCRM risk assessment step. I believe that this should
work.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Monday, May 31, 2021 10:00 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked]>

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

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

> report a vulnerability and refuse to pass the update along.

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.

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: Hannes Tschofenig <[email-masked]>
Date: Tue, 1 Jun 2021 13:04:37 +0000

It is a challenge.

The SUIT manifest provides the capabilities to give authorized parties extra information (via the manifest meta-data and software description*) while providing less info to adversaries.

(*): I am assuming that the info offered via MUD, COSWID, and the textual description is of any help to you. If it is not, then you need to let us know what other pieces of information will have to be included in the manifest to become valuable to make the risk assessment.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Tuesday, June 1, 2021 1:32 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

Hannes,

I definitely see your point, it seems the real problem to solve is:
- How do we (1) prevent the bad guys from discovering SW details (source
code) from binaries while simultaneously (2) providing end use customers the ability to conduct malware scans, and other risk management functions?

If we encrypt a binary distribution we achieve 1 but not 2 If we do not encrypt we achieve 2, but not 1

Both of these objectives are trying to achieve the same thing: Keep the bad guys from causing harm.

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: Tuesday, June 1, 2021 6:40 AM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

At the same time I want to create awareness for the attacker point of view.
They need to get access to plaintext firmware of an embedded device (unless the attacker already knows what the source was used). This is why there are advanced disassemblers available (such as IDA Pro, Binary Ninja, and Ghidra
-- to name a few).

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Monday, May 31, 2021 10:00 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked]>

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,

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.

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

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 1 Jun 2021 09:19:31 -0400

Hannes,

Will the SUIT manifest contain an attestation of a clean malware scan that
can be verifiably validated for the encrypted software in hand? That would
help, if a malware scan is not an option.

The other issue that needs to be addressed is the ability for a software
consumer to verify that the signing party of a software object has been
given authorization to sign code on behalf of a software source supplier
(VENDOR ID) in the manifest, using a standard method - something similar to
DNS CAA records, but for digital signatures, e.g. maybe DNS DSA records.  

Ref: "Vendor ID is not intended to be a human-readable element.  It is
intended for binary match/mismatch comparison only."

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Tuesday, June 1, 2021 9:05 AM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

It is a challenge.

The SUIT manifest provides the capabilities to give authorized parties extra
information (via the manifest meta-data and software description*) while
providing less info to adversaries.

(*): I am assuming that the info offered via MUD, COSWID, and the textual
description is of any help to you. If it is not, then you need to let us
know what other pieces of information will have to be included in the
manifest to become valuable to make the risk assessment.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Tuesday, June 1, 2021 1:32 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked]>

Hannes,

If we encrypt a binary distribution we achieve 1 but not 2 If we do not
encrypt we achieve 2, but not 1

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: Tuesday, June 1, 2021 6:40 AM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Monday, May 31, 2021 10:00 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked]>

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,

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 1 Jun 2021 16:03:25 +0000

Hi Dick,

Currently the manifest specification does not contain attestation information. However, as with the MUD information the manifest can be extended to convey such a report.

On the second issue, that's a new topic for me. As you noted, the Vendor ID condition cannot be used for that purpose because it has been designed for a different task.

Thinking out loud here: Would the use of X.509 certificates when signing the manifest (with the Extended Key Usage extension) do the job? If not, would the delegation mechanism defined for the SUIT manifest help? (The delegation mechanism is described in https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#section-3.25 and in https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#section-5.2

(It is not unlikely that the delegation mechanism would benefit from more details...)

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Tuesday, June 1, 2021 3:20 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

Hannes,

Will the SUIT manifest contain an attestation of a clean malware scan that can be verifiably validated for the encrypted software in hand? That would help, if a malware scan is not an option.

The other issue that needs to be addressed is the ability for a software consumer to verify that the signing party of a software object has been given authorization to sign code on behalf of a software source supplier (VENDOR ID) in the manifest, using a standard method - something similar to DNS CAA records, but for digital signatures, e.g. maybe DNS DSA records.

Ref: "Vendor ID is not intended to be a human-readable element.  It is intended for binary match/mismatch comparison only."

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: Tuesday, June 1, 2021 9:05 AM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

It is a challenge.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Tuesday, June 1, 2021 1:32 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked]>

Hannes,

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: Tuesday, June 1, 2021 6:40 AM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Monday, May 31, 2021 10:00 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked]>

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,

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.

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

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 1 Jun 2021 13:25:58 -0400

Hannes, see comments inline DB>>

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Tuesday, June 1, 2021 12:03 PM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

Hi Dick,

Currently the manifest specification does not contain attestation
information. However, as with the MUD information the manifest can be
extended to convey such a report.

DB>> the extension solution seems like a reasonable approach to address the
malware attestation.

On the second issue, that's a new topic for me. As you noted, the Vendor ID
condition cannot be used for that purpose because it has been designed for a
different task.

Thinking out loud here: Would the use of X.509 certificates when signing the
manifest (with the Extended Key Usage extension) do the job? If not, would
the delegation mechanism defined for the SUIT manifest help? (The delegation
mechanism is described in
https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#s
ection-3.25 and in
https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#section-5.
2

DB>> Currently software consumers do not have a standard method to verify
that a signing party has been authorized to sign on behalf of a software
source supplier, when performing digital signature verification on a
software package. Many people "assume" that the signing party is the
software source supplier.  A digital signature alone is insufficient at
identifying the software source supplier because anyone with a code signing
key can sign any software package, as demonstrated in this article:
https://energycentral.com/c/ec/who-ya-gonna-trust 
DB>> I plan to raise the need for a formal method to verify authorized code
signing parties on behalf a software source supplier during digital
signature validation as a topic during NIST's EO workshop in 6/2-3. 

(It is not unlikely that the delegation mechanism would benefit from more
details...)

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Tuesday, June 1, 2021 3:20 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked]>

Hannes,

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: Tuesday, June 1, 2021 9:05 AM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

It is a challenge.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Tuesday, June 1, 2021 1:32 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked]>

Hannes,

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: Tuesday, June 1, 2021 6:40 AM
To: [email-masked]; 'Russ Housley' <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Monday, May 31, 2021 10:00 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked]>

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,

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

---

From: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 12:32:01 +0000

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

In this scenario, I would highly recommend simply adding the SCRM vendor to the COSE_Recipients list. This solves the auditing problem without exposing the firmware to malicious third parties. Remember, ROP compilers are a thing that exists and showing your adversary your binary makes it much easier to craft a ROP attack. I’m not arguing for security through obscurity, I’m just saying that it’s more difficult to build a ROP attack against a target when you don’t know any of its code. That fundamentally delays attacks and it also raises the bar: when you account for attacker capability modelling, what this does is reduce the number of possible adversaries.

Balancing audit and right to repair against strong security is non-trivial. However, I believe that we need to start with strong security, with hooks for audit and right-to-repair.

Best Regards,
Brendan

> 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: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 12:34:29 +0000

Encryption support is not optional. It’s mandatory. Many organisations will not consent to their binaries being publicly available. This is easy to demonstrate: most MCUs support read-out protection. We can’t simply remove encrypted payload support because it changes the audit story. Instead, firmware authors must cooperate with auditors.

Best Regards,
Brendan

> On 31 May 2021, at 20:56, Dick Brooks <[email-masked]> wrote:
>
> I believe encryption would "get in the way of" a malware scan performed
> during a software supply chain risk assessment.
>
>
> Thanks,
>
> Dick Brooks
>
> 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]
> Hi Michael,
> of
>>> the distribution cannot insert any malware.
>
> 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: Wed, 2 Jun 2021 08:44:04 -0400

Thanks for your insights Brendan.

I believe Hannes addressed this concern by suggesting an extension attesting to the results of a malware scan, performed by the original software source supplier prior to encryption, that a SW consumer can trust.
This would provide the end use customer with the information they need to assess trustworthiness for an encrypted object, with regard to the presence of malware, as part of a software supply chain risk assessment.

Do you agree that this is an acceptable compromise?

Thanks,

Dick Brooks

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

-----Original Message-----
From: Brendan Moran <[email-masked]> 
Sent: Wednesday, June 2, 2021 8:34 AM
To: Dick Brooks <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Michael Richardson <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

Best Regards,
Brendan

> I believe encryption would "get in the way of" a malware scan 
> performed during a software supply chain risk assessment.
>
>
> Thanks,
>
> Dick Brooks
>
>> look
> at patches.  Black hats use this to develop exploits in the gap 
> 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
>
> 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: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 12:43:37 +0000

> On 1 Jun 2021, at 14:19, Dick Brooks <[email-masked]> wrote:
>
> Hannes,
>

Please bear in mind what a manifest is. It’s not a declaration of anything at all. It’s a set of instructions to a device to perform certain operations that will result in an installed firmware image. That’s not quite compatible with an attestation of a malware scan. However, what you could do is require multiple signatures: the manifest could be rejected if it is not signed by both the firmware author (and/or any other relevant authorities) and the malware scanning provider. This requires no changes to the manifest specification as it stands.

> DNS CAA records, but for digital signatures, e.g. maybe DNS DSA records.

This concept (without DNS) already incorporated into SUIT. The SUIT Delegation chains allow a trust anchor to delegate authority. The delegation of authority for any given component identifier is left out-of-scope int he SUIT manifest, but can be achieved using a fairly simple ACL.

Key-lookup systems (like DNS CAA) are explicitly avoided because they require interactive operations, which are expensive on constrained networks.

Best Regards,

Brendan

---

From: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 12:43:37 +0000

Best Regards,

Brendan

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Jun 2021 12:46:21 +0000

Brendan, IMHO this should be something that could be placed into a manifest -- similarly to a COSWID.

-----Original Message-----
From: Dick Brooks <[email-masked]>
Sent: Wednesday, June 2, 2021 2:44 PM
To: Brendan Moran <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; 'Michael Richardson' <[email-masked]>; 'Russ Housley' <[email-masked]>; [email-masked]
Subject: RE: [Suit] suit-firmware-encryption-00

Thanks,

Dick Brooks

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

-----Original Message-----
From: Brendan Moran <[email-masked]>
Sent: Wednesday, June 2, 2021 8:34 AM
To: Dick Brooks <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Michael Richardson <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

Best Regards,
Brendan

---

From: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 12:52:57 +0000

> https://energycentral.com/c/ec/who-ya-gonna-trust

This may well be true in the general case, but this is not true for SUIT. SUIT manifests must be verified all the way back to a trust anchor.

https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#section-5.2

>    Delegation Chains allow a Recipient to establish a chain of trust
>    from a Trust Anchor to the signer of a manifest by validating
>    delegation claims.  Each delegation claim is a [RFC8392] CBOR Web
>    Tokens (CWTs).  The first claim in each list is signed by a Trust
>    Anchor.  Each subsequent claim in a list is signed by the public key
>    claimed in the preceding list element.  The last element in each list
>    claims a public key that can be used to verify a signature in the
>    Authentication Block (
> Section 5.3).
See also https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#section-8.3

This is also described in the information model:
https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#section-3.25

See also REQ.SEC.ACCESS_CONTROL: https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#section-4.3.13

>    If a device grants different rights to different actors, then an
>    exercise of those rights MUST be validated against a list of rights
>    for the actor.  This typically takes the form of an Access Control
>    List (ACL).  ACLs are applied to two scenarios:
>
>    1.  An ACL decides which elements of the manifest may be overridden
>        and by which actors.
>
>    2.  An ACL decides which component identifier/storage identifier
>        pairs can be written by which actors.
>
>    Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13),
>    THREAT.UPD.UNAPPROVED (Section 4.2.11)

Best Regards,
Brendan

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 2 Jun 2021 08:54:21 -0400

Brendan,

There are two implementation models, that I'm aware of, for SCRM best practices in use today:
- SW Customer has its own internal process for SCRM risk assessments (customer is the COSE_Recipient)
- SW Customer outsources SCRM to 3rd party (3rd party is the COSE_Recipient)

I totally agree with " I’m just saying that it’s more difficult to build a ROP attack against a target when you don’t know any of its code." 

The optimal solution will impede the bad guys while simultaneously providing the end use customer with some assurance of trustworthiness for a sw package, before installation is performed. 

The days of "just sign it" and it will be trusted are coming to an end. More controls over the software supply chain are coming, i.e. SBOM and verifiable trusted signers.

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]> 
Sent: Wednesday, June 2, 2021 8:32 AM
To: Dick Brooks <[email-masked]>
Cc: Russ Housley <[email-masked]>; Michael Richardson <[email-masked]>; Hannes Tschofenig <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] suit-firmware-encryption-00

Best Regards,
Brendan

---

From: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 12:57:35 +0000

I do not understand the security story of this extension. How is it authenticated? If it is not authenticated, then I, as an adversary, can simply add it myself. So, this means that your malware attestation looks a lot like an endorsement. If it’s an endorsement, then the malware evaluation provider can simply sign the manifest.

Is there some additional benefit that I’m not seeing?

Best Regards,
Brendan

> On 2 Jun 2021, at 13:44, Dick Brooks <[email-masked]> wrote:
>

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 2 Jun 2021 09:03:36 -0400

Brendan,

I agree that a trust anchor is specified in SUIT, however when you look at
the basis for this trust anchor (COSE) you find this information

https://datatracker.ietf.org/doc/html/rfc8152#section-4.4 
COSE's Signing and Verification process contains the following guidance:

  In addition to performing the signature verification, the application
   may also perform the appropriate checks to ensure that the key is
   correctly paired with the signing identity and that the signing
   identity is authorized before performing actions.

The problem seems to be that there is no formal/standard define method for a
SW consumer to verify that a signer has been authorized by the original
source supplier to sign software on their behalf. Anyone can sign anyone's
software package, and it is verified as successful by Microsoft's signtool.
This is a problem for the SCRM community.

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]> 
Sent: Wednesday, June 2, 2021 8:53 AM
To: Dick Brooks <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Russ Housley
<[email-masked]>; Michael Richardson <[email-masked]>;
[email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

> DB>> Currently software consumers do not have a standard method to 
> DB>> verify
> that a signing party has been authorized to sign on behalf of a 
> software source supplier, when performing digital signature 
> verification on a software package. Many people "assume" that the 
> signing party is the software source supplier.  A digital signature 
> alone is insufficient at identifying the software source supplier 
> because anyone with a code signing key can sign any software package, as
> https://energycentral.com/c/ec/who-ya-gonna-trust

This may well be true in the general case, but this is not true for SUIT.
SUIT manifests must be verified all the way back to a trust anchor.

>    claims a public key that can be used to verify a signature in the
See also
https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#section-8.
3

ection-3.25

See also REQ.SEC.ACCESS_CONTROL:
https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#s
ection-4.3.13

Best Regards,
Brendan

> DB>> I plan to raise the need for a formal method to verify authorized 
> DB>> code
> Will the SUIT manifest contain an attestation of a clean malware scan 
> that can be verifiably validated for the encrypted software in hand? 
> That would help, if a malware scan is not an option.
>
> The other issue that needs to be addressed is the ability for a 
> software consumer to verify that the signing party of a software 
> object has been given authorization to sign code on behalf of a 
> software source supplier (VENDOR ID) in the manifest, using a standard 
> method - something similar to DNS CAA records, but for digital signatures,
e.g. maybe DNS DSA records.
> The SUIT manifest provides the capabilities to give authorized parties 
> extra information (via the manifest meta-data and software 
> description*) while providing less info to adversaries.
>
> (*): I am assuming that the info offered via MUD, COSWID, and the 
> textual description is of any help to you. If it is not, then you need 
> to let us know what other pieces of information will have to be 
> included in the manifest to become valuable to make the risk assessment.
>
> Ciao
> Hannes
>
> code) from binaries while simultaneously (2) providing end use 
> customers the ability to conduct malware scans, and other risk management
functions?
> They need to get access to plaintext firmware of an embedded device 
> (unless the attacker already knows what the source was used). This is 
> why there are advanced disassemblers available (such as IDA Pro, 
> Binary Ninja, and Ghidra
> -- to name a few).
>
> As a way forward I am proposing to use the additional data carried in 
> the manifest for doing the SCRM risk assessment step. I believe that 
> this should work.
>
> Ciao
> Hannes
>
> 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
>
> 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
>
> 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
>

---

From: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 13:03:37 +0000

Hi Hannes,

If the anti-malware endorsement is placed within the manifest, then it is authenticated by the author, in which case the author has implicitly authorised the anti-malware endorsement. I don’t think that quite fits within the usage model that Dick is discussing. From what I understand, he wants the anti-malware scan to be done during or just before deployment. This makes sense. Who knows how long ago the author signed the manifest. The latest signatures might not have been available at that time.

Best Regards,
Brendan

> On 2 Jun 2021, at 13:46, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 2 Jun 2021 09:12:25 -0400

Brendan,

	Current SCRM risk assessment practices perform a malware scan, however this would require SW to be distributed without encryption. 

	Hannes suggested a compromise solution where the original software supplier performs the malware scan and inserts an attestation of the malware scan results into the signed manifest. SCRM vendors can use the malware attestation as a replacement for the malware scan step when software is encrypted. 

This appears to be a reasonable compromise to me - what do you think?

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]> 
Sent: Wednesday, June 2, 2021 9:04 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]; Michael Richardson <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

Hi Hannes,

Best Regards,
Brendan

> Cc: Hannes Tschofenig <[email-masked]>; 'Michael 
> Richardson' <[email-masked]>; 'Russ Housley' 
> Cc: Hannes Tschofenig <[email-masked]>; Michael Richardson 
> <[email-masked]>; Russ Housley <[email-masked]>; 
> [email-masked]
>> 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: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 13:13:20 +0000

Hi Dick,

To verify any signature, you have to get a public key from somewhere. If the recipient device doesn’t have the relevant public key, then the signature isn’t valid. The flaw that you describe is based entirely on a system that’s overeager to deliver public keys to devices without applying any ACL.

This is why we explicitly call out ACLs in the information model: https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#section-4.3.13

Constrained devices have access to a constrained set of public keys. They have one trust anchor, sometimes two or three. However those trust anchors have specific duties. For example, one might be the trust anchor for firmware updates, a second might be for the remote management system, and a third might be for data reporting. If you have the ability to dynamically install new trust anchors, then you create a problem. This needs to be carefully considered.

But whatever the case, this is a security consideration. Manifests MUST be signed by known public keys. Public keys MUST have endorsements for specific capabilities on the target device. That mechanism is not in-scope for the manifest itself, but it is certainly in-scope for the manifest security considerations. The manifest security considerations are covered int he information model, which contains the section about ACLs.

Is that adequate coverage?

Best Regards,
Brendan

> On 2 Jun 2021, at 14:03, Dick Brooks <[email-masked]> wrote:
>
> Brendan,
>

---

From: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 13:15:38 +0000

Hi Dick,

I’m not following how this would work. The manifest is a signed document. You can’t insert anything into it without breaking the signature. You could sign it again. Is there a specific problem with signing it again?

Best Regards,
Brendan

> On 2 Jun 2021, at 14:12, Dick Brooks <[email-masked]> wrote:
>
> Brendan,
>

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 2 Jun 2021 09:28:05 -0400

Brendan,

You make an excellent point that the devices themselves have built in trust relationships that the device is capable of verifying. 

The scenario I'm describing goes like this:

A SW vendor announces that a new security patch is available for download.

End use customer downloads the SW per vendor instructions.

Customer wants to perform a SCRM  software supply chain risk assessment before installing the SW patch on a device. 

What standard/formal process is available to the SW customer to verify that the signer of the SW patch was authorized to sign the package by the original software supplier?
I have not found any specific standard or formal practices that prescribe a method to verify the trust relationship between a software supplier and an authorized software code signer. 

Current code signing and verification practices allow any party to sign software and an "unauthorized signature" will be reported as verified by tools such as Microsoft's signtool. This is the security gap that needs to be plugged. 

A SW customer MUST be able to perform a SCRM risk assessment to ascertain some level of assurance that a SW package is trustworthy before any attempt to install. This is a current requirement of NERC CIP-010-3 software verification requirements. 

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]> 
Sent: Wednesday, June 2, 2021 9:13 AM
To: Dick Brooks <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Russ Housley <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

Hi Dick,

Best Regards,
Brendan

> I agree that a trust anchor is specified in SUIT, however when you 
> look at the basis for this trust anchor (COSE) you find this 
> information
>
> The problem seems to be that there is no formal/standard define method 
> for a SW consumer to verify that a signer has been authorized by the 
> original source supplier to sign software on their behalf. Anyone can 
> sign anyone's software package, and it is verified as successful by Microsoft's signtool.
>> DB>> I plan to raise the need for a formal method to verify 
>> DB>> authorized code
>> software source supplier (VENDOR ID) in the manifest, using a 
>> standard method - something similar to DNS CAA records, but for 
>> digital signatures,
>> Ref: "Vendor ID is not intended to be a human-readable element.  It 
>> is intended for binary match/mismatch comparison only."
>>
>> Thanks,
>>
>> Dick Brooks
>>
>> The SUIT manifest provides the capabilities to give authorized 
>> parties extra information (via the manifest meta-data and software
>> textual description is of any help to you. If it is not, then you 
>> need to let us know what other pieces of information will have to be 
>> encryption creates for malware scanning, which is one of the SCRM 
>> risk assessment steps, performed before installation
>>
>> Thanks,
>>
>> Dick Brooks
>>
>> 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.)
>>
>> 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
>>
>> (https://www.whitehouse.gov/briefing-room/presidential-actions/2021/0
>> 5
>> /12/ex
>>>>> 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!
>>> If a trustworthy party in the middle of the distribution path is 
>>> can report a vulnerability and refuse to pass the update along.
>>>
>>> Russ

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 2 Jun 2021 09:30:53 -0400

Maybe I'm confused, Brendan.

I'm thinking it's possible for a sw vendor to perform a malware scan and then insert the malware attestation into the manifest before signing the manifest and sw package. 

Is my assumption invalid? 

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]> 
Sent: Wednesday, June 2, 2021 9:16 AM
To: Dick Brooks <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Michael Richardson <[email-masked]>; Russ Housley <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] suit-firmware-encryption-00

Hi Dick,

Best Regards,
Brendan

> Cc: [email-masked]; Michael Richardson 
>>>>> middle
>>>> to look
>>> the contents to any other person, use it for any purpose, or store 
>>> or copy the information in any medium. Thank you.

---

From: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 13:54:03 +0000

Hi Dick

Brendan,

Really, this is just an extension of the device use-case. If the device reports to its management system (the SW Customer) what public keys it trusts, then the SW customer can verify a manifest prior to distribution. Regardless, if the device receives a manifest signed by an untrusted source, it can identify that when it checks the `kid` header in the signature. That means it can reject the manifest before even validating the signature. This means the device only pays the cost of receiving the manifest.

In any case, device operators (SW Customers) should have access to the public keys of any trust anchors so that they can do pre-distribution checks. (https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#section-4.3.19)

I don’t think we should take the policies used by signtool as an indication of how IoT devices built with SUIT will work. I think it’s more important to consider the SUIT threat model and security requirements.

Best Regards,
Brendan

Thanks,

Dick Brooks

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

-----Original Message-----
From: Brendan Moran <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 2, 2021 9:13 AM
To: Dick Brooks <[email-masked]<mailto:[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Russ Housley <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] suit-firmware-encryption-00

Hi Dick,

Best Regards,
Brendan

On 2 Jun 2021, at 14:03, Dick Brooks <[email-masked]<mailto:[email-masked]>> wrote:

Brendan,

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]>
Sent: Wednesday, June 2, 2021 8:53 AM
To: Dick Brooks <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Russ Housley

because anyone with a code signing key can sign any software package,
as

This is also described in the information model:
https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-mode
l-12#s
ection-3.25

See also REQ.SEC.ACCESS_CONTROL:
https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-mode
l-12#s
ection-4.3.13

Best Regards,
Brendan

(It is not unlikely that the delegation mechanism would benefit from
more
details...)

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 1, 2021 3:20 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; 'Russ Housley'
<[email-masked]<mailto:[email-masked]>>
Cc: 'Michael Richardson' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] suit-firmware-encryption-00

Hannes,

Thanks,

Dick Brooks

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

-----Original Message-----
From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 1, 2021 9:05 AM
To: [email-masked]<mailto:[email-masked]>; 'Russ Housley'
<[email-masked]<mailto:[email-masked]>>
Cc: 'Michael Richardson' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] suit-firmware-encryption-00

It is a challenge.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 1, 2021 1:32 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; 'Russ Housley'
<[email-masked]<mailto:[email-masked]>>
Cc: 'Michael Richardson' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] suit-firmware-encryption-00

Hannes,

I definitely see your point, it seems the real problem to solve is:
- How do we (1) prevent the bad guys from discovering SW details
(source
code) from binaries while simultaneously (2) providing end use
customers the ability to conduct malware scans, and other risk
management
functions?

If we encrypt a binary distribution we achieve 1 but not 2 If we do
not encrypt we achieve 2, but not 1

Both of these objectives are trying to achieve the same thing: Keep
the bad guys from causing harm.

Thanks,

Dick Brooks

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

-----Original Message-----
From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 1, 2021 6:40 AM
To: [email-masked]<mailto:[email-masked]>; 'Russ Housley'
<[email-masked]<mailto:[email-masked]>>
Cc: 'Michael Richardson' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] suit-firmware-encryption-00

At the same time I want to create awareness for the attacker point of
view.
They need to get access to plaintext firmware of an embedded device
(unless the attacker already knows what the source was used). This is
why there are advanced disassemblers available (such as IDA Pro,
Binary Ninja, and Ghidra
-- to name a few).

Ciao
Hannes

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

Thanks,

Dick Brooks

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

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

Hi Dick,

Ciao
Hannes

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

I agree, Russ.

Thanks,

Dick Brooks

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

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

Dick:

Russ

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

Thanks,

Dick Brooks

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

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

Michael:

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

---

From: Brendan Moran <[email-masked]>
Date: Wed, 2 Jun 2021 14:04:46 +0000

Should we trust anything the SW vendor has to say if we’re scanning their SW for malware? Isn’t that a little like a company supplying its own safety compliance auditor?

The explicit threat here is: An adversary compromises SW Vendor (SWV). They modify SWV’s software to include malware. But, SWV is including a malware scan report. The adversary forges the malware scan report.

It would be better if they were isolated entities with isolated security infrastructure.

I’m not sure that specifics about how to encapsulate an anti-malware report belong in the SUIT Manifest specification. The SUIT Manifest is a mechanism for a variety of authorities, trusted by a device for specific operations, to tell a device *how* to obtain, install, and authenticate a software/firmware image. The malware report is an endorsement about that image, that is consumed by the device operator. This sounds to me like something that should never be delivered to the device. A signature over the manifest is an option, but that would require a mechanism to provision the device with a public key for the anti-malware vendor.

I can see an option to reserve a element identifier (key) in the manifest envelope (these are unauthenticated elements) for it to contain that report. The report itself would need to be signed by the anti-malware vendor and to reference the manifest in an unambiguous way (e.g. by digest). However, I don’t think that specification belongs in the core SUIT manifest specification. We could add an extension that just provides a container for this document if you think that’s helpful. The device operator would need to strip this document out of the manifest envelope prior to distribution.

Best Regards,
Brendan

> On 2 Jun 2021, at 14:30, Dick Brooks <[email-masked]> wrote:
>

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 2 Jun 2021 10:08:36 -0400

Brendan,

               I understand your position.

               I have my doubts that the approach you describe will pass a NERC audit for CIP-010-3 software verification requirements R1, part 1.6 requirement 1.6.1, because it requires sending the SW to the device, essentially changing the baseline, in violation of the NERC CIP standard, before performing the necessary identity verification; https://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-010-3 <https://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-010-3&title=Cyber%20Security%20%E2%80%94%20Configuration%20Change%20Management%20and%20Vulnerability%20Assessments&Jurisdiction=United%20States> &title=Cyber%20Security%20%E2%80%94%20Configuration%20Change%20Management%20and%20Vulnerability%20Assessments&Jurisdiction=United%20States 

Thanks,

Dick Brooks

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[email-masked]> [email-masked]

Tel: +1 978-696-1788

From: Brendan Moran <[email-masked]> 
Sent: Wednesday, June 2, 2021 9:54 AM
To: Dick Brooks <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Russ Housley <[email-masked]>; Michael Richardson <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] suit-firmware-encryption-00

Hi Dick

Brendan,

Best Regards,

Brendan

Thanks,

Dick Brooks

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

-----Original Message-----
From: Brendan Moran < <mailto:[email-masked]> [email-masked]> 
Sent: Wednesday, June 2, 2021 9:13 AM
To: Dick Brooks < <mailto:[email-masked]> [email-masked]>
Cc: Hannes Tschofenig < <mailto:[email-masked]> [email-masked]>; Russ Housley < <mailto:[email-masked]> [email-masked]>; Michael Richardson < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: Re: [Suit] suit-firmware-encryption-00

Hi Dick,

Best Regards,
Brendan

On 2 Jun 2021, at 14:03, Dick Brooks <[email-masked] <mailto:[email-masked]> > wrote:

Brendan,

Thanks,

Dick Brooks

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

-----Original Message-----
From: Brendan Moran <[email-masked] <mailto:[email-masked]> >
Sent: Wednesday, June 2, 2021 8:53 AM
To: Dick Brooks <[email-masked] <mailto:[email-masked]> >
Cc: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >; Russ Housley 
<[email-masked] <mailto:[email-masked]> >; Michael Richardson <[email-masked] <mailto:[email-masked]> >; 
[email-masked] <mailto:[email-masked]> 
Subject: Re: [Suit] suit-firmware-encryption-00

See also

Best Regards,
Brendan

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked] <mailto:[email-masked]> >
Sent: Tuesday, June 1, 2021 3:20 PM
To: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >; 'Russ Housley'
<[email-masked] <mailto:[email-masked]> >
Cc: 'Michael Richardson' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Suit] suit-firmware-encryption-00

Hannes,

Thanks,

Dick Brooks

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

-----Original Message-----
From: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >
Sent: Tuesday, June 1, 2021 9:05 AM
To: [email-masked] <mailto:[email-masked]> ; 'Russ Housley'
<[email-masked] <mailto:[email-masked]> >
Cc: 'Michael Richardson' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Suit] suit-firmware-encryption-00

It is a challenge.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[email-masked] <mailto:[email-masked]> >
Sent: Tuesday, June 1, 2021 1:32 PM
To: Hannes Tschofenig <[email-masked]>; 'Russ Housley'
<[email-masked] <mailto:[email-masked]> >
Cc: 'Michael Richardson' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Suit] suit-firmware-encryption-00

Hannes,

functions?

Thanks,

Dick Brooks

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

-----Original Message-----
From: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >
Sent: Tuesday, June 1, 2021 6:40 AM
To: [email-masked] <mailto:[email-masked]> ; 'Russ Housley'
<[email-masked] <mailto:[email-masked]> >
Cc: 'Michael Richardson' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Suit] suit-firmware-encryption-00

view.

Ciao
Hannes

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

Thanks,

Dick Brooks

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

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

Hi Dick,

Ciao
Hannes

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

I agree, Russ.

Thanks,

Dick Brooks

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

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

Dick:

Russ

<[email-masked] <mailto:[email-masked]> > wrote:

Thanks,

Dick Brooks

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

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

Michael:

"factory"

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

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

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 2 Jun 2021 10:11:11 -0400

I'll offer the profound advice offered by Ken Thompson to answer this question:
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf 

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]> 
Sent: Wednesday, June 2, 2021 10:05 AM
To: Dick Brooks <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Michael Richardson <[email-masked]>; Russ Housley <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] suit-firmware-encryption-00

Best Regards,
Brendan

> <[email-masked]>; Russ Housley <[email-masked]>; suit 
> <[email-masked]>
>> If the anti-malware endorsement is placed within the manifest, then it is authenticated by the author, in which case the author has implicitly authorised the anti-malware endorsement. I don’t think that quite fits within the usage model that Dick is discussing. >From what I understand, he wants the anti-malware scan to be done during or just before deployment. This makes sense. Who knows how long ago the author signed the manifest. The latest signatures might not have been available at that time.
>>
>> Best Regards,
>> Brendan
>>
>>> Cc: Hannes Tschofenig <[email-masked]>; Michael 
>>> Richardson <[email-masked]>; Russ Housley 
>>>> 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.