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

[Brendan Moran <[e-mail]>]

>
> " 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: [e-mail]
> Tel: [phone]
>
> -----Original Message-----
> From: Suit <[e-mail]> On Behalf Of Russ Housley
> Sent: Monday, May 31, 2021 12:49 PM
> To: Michael Richardson <[e-mail]>
> Cc: Hannes Tschofenig <[e-mail]>; [e-mail]
> 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
> [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.