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

[Dick Brooks <[e-mail]>]

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

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 9:16 AM
To: Dick Brooks <[e-mail]>
Cc: Hannes Tschofenig <[e-mail]>; Michael Richardson <[e-mail]>; Russ Housley <[e-mail]>; suit <[e-mail]>
Subject: Re: [Suit] suit-firmware-encryption-00

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 <[e-mail]> wrote:
>
> 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
>
> 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 9:04 AM
> To: Hannes Tschofenig <[e-mail]>
> Cc: [e-mail]; Michael Richardson 
> <[e-mail]>; Russ Housley <[e-mail]>; 
> [e-mail]
> Subject: Re: [Suit] suit-firmware-encryption-00
>
> 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 <[e-mail]> wrote:
>>
>> Brendan, IMHO this should be something that could be placed into a manifest -- similarly to a COSWID.
>>
>> -----Original Message-----
>> From: Dick Brooks <[e-mail]>
>> Sent: Wednesday, June 2, 2021 2:44 PM
>> To: Brendan Moran <[e-mail]>
>> Cc: Hannes Tschofenig <[e-mail]>; 'Michael 
>> Richardson' <[e-mail]>; 'Russ Housley'
>> <[e-mail]>; [e-mail]
>> Subject: RE: [Suit] suit-firmware-encryption-00
>>
>> 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.
>>
>
> 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.