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

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

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

-----Original Message-----
From: Brendan Moran <Brendan.Moran@arm.com> 
Sent: Wednesday, June 2, 2021 8:32 AM
To: Dick Brooks <dick@reliableenergyanalytics.com>
Cc: Russ Housley <housley@vigilsec.com>; Michael Richardson <mcr+ietf@sandelman.ca>; Hannes Tschofenig <Hannes.Tschofenig@arm.com>; suit <suit@ietf.org>
Subject: Re: [Suit] suit-firmware-encryption-00

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

> Thanks,
>
> Dick Brooks
>
> Never trust software, always verify and report! T 
> http://www.reliableenergyanalytics.com
> Email: dick@reliableenergyanalytics.com
> Tel: +1 978-696-1788
>
> -----Original Message-----
> From: Suit <suit-bounces@ietf.org> On Behalf Of Russ Housley
> Sent: Monday, May 31, 2021 12:49 PM
> To: Michael Richardson <mcr+ietf@sandelman.ca>
> Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; suit@ietf.org
> 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
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit
>
> _______________________________________________
> Suit mailing list
> Suit@ietf.org
> 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.