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

[Dick Brooks <[e-mail]>]

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: [e-mail]
Tel: [phone]

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

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 <[e-mail]> wrote:
>
> I believe encryption would "get in the way of" a malware scan 
> performed during a software supply chain risk assessment.
>
>
> Thanks,
>
> Dick Brooks
>
> Never trust software, always verify and report! T 
> http://www.reliableenergyanalytics.com
> Email: [e-mail]
> Tel: [phone]
>
> -----Original Message-----
> From: Suit <[e-mail]> On Behalf Of Hannes Tschofenig
> Sent: Monday, May 31, 2021 3:47 PM
> To: Michael Richardson <[e-mail]>; Russ Housley 
> <[e-mail]>; [e-mail]
> Subject: Re: [Suit] suit-firmware-encryption-00
>
> Hi Michael,
>
>>> 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"
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit
>
> _______________________________________________
> Suit mailing list
> [e-mail]
> 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.