Re: [Suit] suit-firmware-encryption-00
Dick Brooks <dick@reliableenergyanalytics.com> Tue, 01 June 2021 17:26 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 623BB3A20F1 for <suit@ietfa.amsl.com>; Tue, 1 Jun 2021 10:26:10 -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 D_QRvZF0KW2e for <suit@ietfa.amsl.com>; Tue, 1 Jun 2021 10:26:05 -0700 (PDT)
Received: from forward1-smtp.messagingengine.com (forward1-smtp.messagingengine.com [66.111.4.223]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C643A20EF for <suit@ietf.org>; Tue, 1 Jun 2021 10:26:04 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 10C801940CC1; Tue, 1 Jun 2021 13:26:02 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 01 Jun 2021 13:26:02 -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=QiTkSw/G7aTXqKTif6+FiP5TdMiA2 00G4Tn5nJAlDUU=; b=VD8sIh3IPw2LOwYYdsFH3QuCNrnyxdDOw+ZuqDwi+5481 wKmkm6tUr2IsAkTyneA3ITM8RwA/K5PyZxl8QPvkUeTZMmzMOlftKRYyvPNuyWch NvUCWW2Qkj6ewT4XmObqcTs+q7jfzMeJ5A21mgyO/wP1w/0mk/NlbfzC3nTPPcTs cAHgHJeBfncNnfKI0h/x7+ke3d7rVuJooiTd8Ef2GGXoM50VI/E2z1k5E37b64Am CP/TpfySElqSQye4SBuC+tsG2XWlSfdyO+hPCTCbn9bvg9eGNSTwKnm4+bes/3nl yM16Hl3xrRb3eVl0iKNMa67+2gu2L2zcsYMUTl7OQ==
X-ME-Sender: <xms:qW22YFjQPCkethQNBGvRSumAAJfQA4kjxySkt6zTd8IcQF-6TfV6mw> <xme:qW22YKDhKduEpVbumqhjp4Ne6MX6gi9_YwP18gLx9ul-dIgfa3Ehk0h2ceAR6zHs2 RroPpiAEnWV4-gb3A>
X-ME-Received: <xmr:qW22YFEpa6h1ueBXh1ZamexG02s-cjTlsppZ0L_4gmnwvh-YQowZWbM>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelhedgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehrhffvfhgjufffohfkgggtgffothesthejghdtvddtvdenucfhrhhomhep fdffihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrg hnrghlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepjeeuteegveefueffveet iefhuedvffejteefteetfffgtdevlefhfedvgfffffejnecuffhomhgrihhnpehrvghlih grsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmpdhivghtfhdrohhrghdpvghn vghrghihtggvnhhtrhgrlhdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrghl hihtihgtshdrtghomh
X-ME-Proxy: <xmx:qW22YKTJTpaQccH2TaiEz1B6xjG8yC_ogfaSY7roBmaXfNIZ486J0w> <xmx:qW22YCz3KCAxmHs8KPa44drkJstgOINgbp1985GIvU92e5i17H18sw> <xmx:qW22YA5i-QQqubj-2lCG_nAYKMQ1eB34H75lgWPd_I3GsAGxM0-HCQ> <xmx:qm22YHrlb2t9kta6x2npHeKpTuwwdFmyDuOXUbN32XMQRg5xQtqvwA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 1 Jun 2021 13:26:00 -0400 (EDT)
Reply-To: dick@reliableenergyanalytics.com
From: Dick Brooks <dick@reliableenergyanalytics.com>
To: 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>, 'Russ Housley' <housley@vigilsec.com>
Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>, suit@ietf.org
References: <19586.1622075797@localhost> <DBBPR08MB5915CEC125579D78C108D540FA3F9@DBBPR08MB5915.eurprd08.prod.outlook.com> <F6C86CC2-3AF8-4CC5-BB47-AC6579DAA0C4@vigilsec.com> <13894.1622479289@localhost> <64BDF7A0-4B70-4EB3-A764-2BD6CAA3921A@vigilsec.com> <132601d7563d$7097f680$51c7e380$@reliableenergyanalytics.com> <E2D893E5-8462-4F69-88D0-29167B6DB1B3@vigilsec.com> <140a01d7563f$65d2a130$3177e390$@reliableenergyanalytics.com> <DBBPR08MB591549CB964EA7E18C8640C2FA3F9@DBBPR08MB5915.eurprd08.prod.outlook.com> <18b401d75657$880bfef0$9823fcd0$@reliableenergyanalytics.com> <DBBPR08MB59158723623695EB0473637FFA3E9@DBBPR08MB5915.eurprd08.prod.outlook.com> <223201d756d9$af8bddb0$0ea39910$@reliableenergyanalytics.com> <DBBPR08MB5915C1F5529E8801DF5AFD09FA3E9@DBBPR08MB5915.eurprd08.prod.outlook.com> <272401d756e8$c446ba90$4cd42fb0$@reliableenergyanalytics.com> <DBBPR08MB59159E70B7ED1575EF82A745FA3E9@DBBPR08MB5915.eurprd08.prod.outlook.com>
In-Reply-To: <DBBPR08MB59159E70B7ED1575EF82A745FA3E9@DBBPR08MB5915.eurprd08.prod.outlook.com>
Date: Tue, 01 Jun 2021 13:25:58 -0400
Organization: Reliable Energy Analytics LLC
Message-ID: <32f301d7570b$316490d0$942db270$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI/QDB0THmT0m+iwpMcIJ7U5AyVWwGeOG6MAhV23QADMtNZAgELPwAdAnBC4M8B5S+ZkQG9GBtkAvvy+dYCdoomoQLkXmLkAmxgmzgCFyi88ACA9OzHAiJ3M0GpQ4Ex0A==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/fFb0on0nCK60fEpCEP6NtNyxRls>
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: Tue, 01 Jun 2021 17:26:10 -0000
Hannes, see comments inline DB>> 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: Hannes Tschofenig <Hannes.Tschofenig@arm.com> Sent: Tuesday, June 1, 2021 12:03 PM To: dick@reliableenergyanalytics.com; 'Russ Housley' <housley@vigilsec.com> Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>; suit@ietf.org Subject: RE: [Suit] suit-firmware-encryption-00 Hi Dick, Currently the manifest specification does not contain attestation information. However, as with the MUD information the manifest can be extended to convey such a report. DB>> the extension solution seems like a reasonable approach to address the malware attestation. On the second issue, that's a new topic for me. As you noted, the Vendor ID condition cannot be used for that purpose because it has been designed for a different task. Thinking out loud here: Would the use of X.509 certificates when signing the manifest (with the Extended Key Usage extension) do the job? If not, would the delegation mechanism defined for the SUIT manifest help? (The delegation mechanism is described in https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#s ection-3.25 and in https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#section-5. 2 DB>> Currently software consumers do not have a standard method to verify that a signing party has been authorized to sign on behalf of a software source supplier, when performing digital signature verification on a software package. Many people "assume" that the signing party is the software source supplier. A digital signature alone is insufficient at identifying the software source supplier because anyone with a code signing key can sign any software package, as demonstrated in this article: https://energycentral.com/c/ec/who-ya-gonna-trust DB>> I plan to raise the need for a formal method to verify authorized code signing parties on behalf a software source supplier during digital signature validation as a topic during NIST's EO workshop in 6/2-3. (It is not unlikely that the delegation mechanism would benefit from more details...) Ciao Hannes -----Original Message----- From: Dick Brooks <dick@reliableenergyanalytics.com> Sent: Tuesday, June 1, 2021 3:20 PM To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; 'Russ Housley' <housley@vigilsec.com> Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>; suit@ietf.org Subject: RE: [Suit] suit-firmware-encryption-00 Hannes, Will the SUIT manifest contain an attestation of a clean malware scan that can be verifiably validated for the encrypted software in hand? That would help, if a malware scan is not an option. The other issue that needs to be addressed is the ability for a software consumer to verify that the signing party of a software object has been given authorization to sign code on behalf of a software source supplier (VENDOR ID) in the manifest, using a standard method - something similar to DNS CAA records, but for digital signatures, e.g. maybe DNS DSA records. Ref: "Vendor ID is not intended to be a human-readable element. It is intended for binary match/mismatch comparison only." 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: Hannes Tschofenig <Hannes.Tschofenig@arm.com> Sent: Tuesday, June 1, 2021 9:05 AM To: dick@reliableenergyanalytics.com; 'Russ Housley' <housley@vigilsec.com> Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>; suit@ietf.org Subject: RE: [Suit] suit-firmware-encryption-00 It is a challenge. The SUIT manifest provides the capabilities to give authorized parties extra information (via the manifest meta-data and software description*) while providing less info to adversaries. (*): I am assuming that the info offered via MUD, COSWID, and the textual description is of any help to you. If it is not, then you need to let us know what other pieces of information will have to be included in the manifest to become valuable to make the risk assessment. Ciao Hannes -----Original Message----- From: Dick Brooks <dick@reliableenergyanalytics.com> Sent: Tuesday, June 1, 2021 1:32 PM To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; 'Russ Housley' <housley@vigilsec.com> Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>; suit@ietf.org Subject: RE: [Suit] suit-firmware-encryption-00 Hannes, I definitely see your point, it seems the real problem to solve is: - How do we (1) prevent the bad guys from discovering SW details (source code) from binaries while simultaneously (2) providing end use customers the ability to conduct malware scans, and other risk management functions? If we encrypt a binary distribution we achieve 1 but not 2 If we do not encrypt we achieve 2, but not 1 Are we really looking at a mutually exclusive choice? Both of these objectives are trying to achieve the same thing: Keep the bad guys from causing harm. 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: Hannes Tschofenig <Hannes.Tschofenig@arm.com> Sent: Tuesday, June 1, 2021 6:40 AM To: dick@reliableenergyanalytics.com; 'Russ Housley' <housley@vigilsec.com> Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>; suit@ietf.org Subject: RE: [Suit] suit-firmware-encryption-00 Dick, I understand your line of argument. At the same time I want to create awareness for the attacker point of view. They need to get access to plaintext firmware of an embedded device (unless the attacker already knows what the source was used). This is why there are advanced disassemblers available (such as IDA Pro, Binary Ninja, and Ghidra -- to name a few). As a way forward I am proposing to use the additional data carried in the manifest for doing the SCRM risk assessment step. I believe that this should work. Ciao Hannes -----Original Message----- From: Dick Brooks <dick@reliableenergyanalytics.com> Sent: Monday, May 31, 2021 10:00 PM To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; 'Russ Housley' <housley@vigilsec.com> Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>; suit@ietf.org Subject: RE: [Suit] suit-firmware-encryption-00 Thanks, Hannes. I just submitted a concern regarding the problem encryption creates for malware scanning, which is one of the SCRM risk assessment steps, performed before installation 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: Hannes Tschofenig <Hannes.Tschofenig@arm.com> Sent: Monday, May 31, 2021 3:57 PM To: dick@reliableenergyanalytics.com; 'Russ Housley' <housley@vigilsec.com> Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>; suit@ietf.org Subject: RE: [Suit] suit-firmware-encryption-00 Hi Dick, with the SUIT manifest format I hope we can make information available to trusted third parties (MUD, COSWID and alike) and at the same time use encrypted binaries. Having access to the plaintext binary is essential for adversaries to mount attacks. (Happy to give a tutorial about how this works.) Like-wise differential updates may make it difficult for SCRM vendors to make their analysis but the information in the manifest can help them. Severable fields allows to remove information from the manifest before it is sent to the device. This reduces overhead and prevents untrusted parties from gathering information from the manifest. Ciao Hannes -----Original Message----- From: Dick Brooks <dick@reliableenergyanalytics.com> Sent: Monday, May 31, 2021 7:07 PM To: 'Russ Housley' <housley@vigilsec.com> Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca>; Hannes Tschofenig <Hannes.Tschofenig@arm.com>; suit@ietf.org Subject: RE: [Suit] suit-firmware-encryption-00 I agree, Russ. Parties subject to the 5/12 Executive Order (https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/ex ecutive-order-on-improving-the-nations-cybersecurity/) will likely want to perform a proactive SCRM risk assessment prior to installation, if my interpretation of the EO is accurate. 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: Russ Housley <housley@vigilsec.com> Sent: Monday, May 31, 2021 12:56 PM To: Dick Brooks <dick@reliableenergyanalytics.com> Cc: Michael Richardson <mcr+ietf@sandelman.ca>; Hannes Tschofenig <Hannes.Tschofenig@arm.com>; suit@ietf.org Subject: Re: [Suit] suit-firmware-encryption-00 Dick: Yes, and there are other use cases that require encryption. Russ > On May 31, 2021, at 12:53 PM, Dick Brooks <dick@reliableenergyanalytics.com> wrote: > > " 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. > > 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 > 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. 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.
- Re: [Suit] suit-firmware-encryption-00 Russ Housley
- [Suit] suit-firmware-encryption-00 Michael Richardson
- Re: [Suit] suit-firmware-encryption-00 Carsten Bormann
- Re: [Suit] suit-firmware-encryption-00 Russ Housley
- Re: [Suit] suit-firmware-encryption-00 Laurence Lundblade
- Re: [Suit] suit-firmware-encryption-00 Hannes Tschofenig
- Re: [Suit] suit-firmware-encryption-00 Russ Housley
- Re: [Suit] suit-firmware-encryption-00 Michael Richardson
- Re: [Suit] suit-firmware-encryption-00 Russ Housley
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Russ Housley
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Hannes Tschofenig
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Hannes Tschofenig
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Hannes Tschofenig
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Hannes Tschofenig
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Hannes Tschofenig
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Hannes Tschofenig
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Brendan Moran
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks
- Re: [Suit] suit-firmware-encryption-00 Dick Brooks