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

Dick Brooks <dick@reliableenergyanalytics.com> Wed, 02 June 2021 13:12 UTC

Return-Path: <dick@reliableenergyanalytics.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC03A4296 for <suit@ietfa.amsl.com>; Wed, 2 Jun 2021 06:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxyE_RYF7j75 for <suit@ietfa.amsl.com>; Wed, 2 Jun 2021 06:12:33 -0700 (PDT)
Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3813A4295 for <suit@ietf.org>; Wed, 2 Jun 2021 06:12:32 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailforward.nyi.internal (Postfix) with ESMTP id 2D79F1940214; Wed, 2 Jun 2021 09:12:32 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 02 Jun 2021 09:12:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=dtvHat6hjUFmwFDIMUERvf6LjSkGW ubnHk08AYmUrb4=; b=hgFp3PyuyDOfY9ieIQZSIBCtSMsQYpelRQigkRJzSCDHN jukGAXurGVhJ2Rj9d5H3LXQHx1pyk1G8CH6+fbzTdypjQSGJ9sVW+uXgUqhoQdpt Mb4jzlLiZDX4vcEzaMTrzIaulPh8X6D9zjpWdLTEFwy0njCcI0SNwfTzouB6ObAZ L+XrcBjr6WbepNNo2HagS8UvH5XLo5xNQn+tQXx8wNuC7suOfQY+e/9rECyjBn15 FRbxQ6rGQp2g+SQchJrcq5HY8cBvyDJYh/rS2kZMJhpbeObBDf19jMvqoUtoosxw rXaf4aoC9hXGpbb1ANRgGDRLQ2Syog3bBe2S7YHgw==
X-ME-Sender: <xms:voO3YMCwzxWsJs6wEoegA19UIF2LU_iqMN-eQsAem6aqkB5zVor_rA> <xme:voO3YOjdMJsYVZcioJbvj9Dcnj-QAC8oscSUYNP6sN7fOXzsY40jDjNymrlyV2z5_ UX_2hzgK0H5-8WZZQ>
X-ME-Received: <xmr:voO3YPlDbbQUtiWTxkMki2NjqdKC6107YUlXY3M71i6ydEsABOpaQE8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeljedgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheprhfhvfhfjgfuffhokfggtgfgofhtsehtqhhgtddvtdejnecuhfhrohhmpedf ffhitghkuceurhhoohhkshdfuceoughitghksehrvghlihgrsghlvggvnhgvrhhghigrnh grlhihthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpedvueelvdfftddtuedtffev jeeukeettdelgffgkeetgfduteejgfegvdejiefgueenucffohhmrghinheprhgvlhhirg gslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomhenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguihgtkhesrhgvlhhirggslhgvvghnvg hrghihrghnrghlhihtihgtshdrtghomh
X-ME-Proxy: <xmx:voO3YCwTB9qrxpcazUGGsTEFvdqEW2mT1D38n7KUNSzcoE86PQpoaA> <xmx:voO3YBR2EEGcv5dD5r7b2CpEbpcESOHo9ECieM9x539iteWEhTBtaA> <xmx:voO3YNbabjEH3k-YFc8pY1wfxQsbFRQbm3aikygdAmZ6lo3kCTvJqQ> <xmx:wIO3YMexJNamXmTCUCYs9erlvSoo0Iz1EjFIsh2xy9nBHfyUC32hdA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 2 Jun 2021 09:12:29 -0400 (EDT)
Reply-To: dick@reliableenergyanalytics.com
From: Dick Brooks <dick@reliableenergyanalytics.com>
To: 'Brendan Moran' <Brendan.Moran@arm.com>, 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>
Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>, 'Russ Housley' <housley@vigilsec.com>, suit@ietf.org
References: <19586.1622075797@localhost> <DBBPR08MB5915CEC125579D78C108D540FA3F9@DBBPR08MB5915.eurprd08.prod.outlook.com> <F6C86CC2-3AF8-4CC5-BB47-AC6579DAA0C4@vigilsec.com> <13894.1622479289@localhost> <DBBPR08MB59153D31EE75D565A64B4F79FA3F9@DBBPR08MB5915.eurprd08.prod.outlook.com> <186901d75657$0ab645a0$2022d0e0$@reliableenergyanalytics.com> <1B50DDD2-2B47-4044-B812-30BE0D80B31D@arm.com> <021201d757ac$fb26bb90$f17432b0$@reliableenergyanalytics.com> <DBBPR08MB5915A61530B0A26E38B48FB7FA3D9@DBBPR08MB5915.eurprd08.prod.outlook.com> <486F2771-201F-46B6-83F9-7562300F09C1@arm.com>
In-Reply-To: <486F2771-201F-46B6-83F9-7562300F09C1@arm.com>
Date: Wed, 02 Jun 2021 09:12:25 -0400
Organization: Reliable Energy Analytics LLC
Message-ID: <039401d757b0$f0ff4200$d2fdc600$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI/QDB0THmT0m+iwpMcIJ7U5AyVWwGeOG6MAhV23QADMtNZAgFLDFHUAKWKaG4CNkkQVwJzKh2tAzgT0z0B/Q0lmKmbMmUA
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/ga02qGZXCeiRuKwau1TFzXTU3Js>
Subject: Re: [Suit] suit-firmware-encryption-00
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 13:12:38 -0000

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: dick@reliableenergyanalytics.com
Tel: +1 978-696-1788

-----Original Message-----
From: Brendan Moran <Brendan.Moran@arm.com> 
Sent: Wednesday, June 2, 2021 9:04 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: dick@reliableenergyanalytics.com; Michael Richardson <mcr+ietf@sandelman.ca>; Russ Housley <housley@vigilsec.com>; suit@ietf.org
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 <Hannes.Tschofenig@arm.com> wrote:
>
> Brendan, IMHO this should be something that could be placed into a manifest -- similarly to a COSWID.
>
> -----Original Message-----
> From: Dick Brooks <dick@reliableenergyanalytics.com>
> Sent: Wednesday, June 2, 2021 2:44 PM
> To: Brendan Moran <Brendan.Moran@arm.com>
> Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; 'Michael 
> Richardson' <mcr+ietf@sandelman.ca>; 'Russ Housley' 
> <housley@vigilsec.com>; suit@ietf.org
> 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: dick@reliableenergyanalytics.com
> Tel: +1 978-696-1788
>
> -----Original Message-----
> From: Brendan Moran <Brendan.Moran@arm.com>
> Sent: Wednesday, June 2, 2021 8:34 AM
> To: Dick Brooks <dick@reliableenergyanalytics.com>
> Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Michael Richardson 
> <mcr+ietf@sandelman.ca>; Russ Housley <housley@vigilsec.com>; 
> suit@ietf.org
> 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 <dick@reliableenergyanalytics.com> 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: dick@reliableenergyanalytics.com
>> Tel: +1 978-696-1788
>>
>> -----Original Message-----
>> From: Suit <suit-bounces@ietf.org> On Behalf Of Hannes Tschofenig
>> Sent: Monday, May 31, 2021 3:47 PM
>> To: Michael Richardson <mcr+ietf@sandelman.ca>; Russ Housley 
>> <housley@vigilsec.com>; suit@ietf.org
>> 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
>> 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.
>

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.