Re: [Suit] How are firmware and firmware versions expressed in manifest?

Dick Brooks <dick@reliableenergyanalytics.com> Wed, 03 June 2020 17:57 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 D03E63A0C9A for <suit@ietfa.amsl.com>; Wed, 3 Jun 2020 10:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 T-v0v-ylhhov for <suit@ietfa.amsl.com>; Wed, 3 Jun 2020 10:57:04 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEB03A0C85 for <suit@ietf.org>; Wed, 3 Jun 2020 10:57:04 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0387B5C011C; Wed, 3 Jun 2020 13:57:03 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 03 Jun 2020 13:57:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=2lEFa9 JnhfSjUsQ+KsUyUTqwfartuxhpW+wgeW+DI6c=; b=kG4b1p93xffV25RBL6W3VA UmQtR6AR4R7bT13x7q+u9nKYjAkysVVDPvAL+yfSSzXtRNN47DZkVhLltVnpKK3g wUSfz5Lg/7t/6UQ8nJwTaDDb3Eaks3XkfX9A3LxYKtfR9foSUw09U9Eej7ofAwEq s5gdHpKd8Ppb/Z56xmpfWyHhcynyEsz4WQLjhqc2JClq6mUEFVtlAFuLos7LNnm1 hS2T9rKRtW49M9+zAI+m0DeW07MaCKufPpRHeahaV+IAAWMjIQjb0PbqaCQNBCc9 4Idp89TS3VfENckBZo5+0RNXVHl5Py7S90bWVrU6kWQ7GC+XZQzHkhG669f5YxpQ ==
X-ME-Sender: <xms:buTXXlj_BiO7wNOS_Z3roRQx3aV8ikqOn6KP8bcQX2EyryyHmcpOyg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefledgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvfhgjufffohfkgggtofhtsehrtdhgpedvtddvnecuhfhrohhmpedfffhi tghkuceurhhoohhkshdfuceoughitghksehrvghlihgrsghlvggvnhgvrhhghigrnhgrlh ihthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpefgjeehueefveethfeiffelteev hfekkefhheelgfetffefjefhueeigeeuffeivdenucffohhmrghinheprhgvlhhirggslh gvvghnvghrghihrghnrghlhihtihgtshdrtghomhenucfkphepjeefrddvfeegrddvgedv rdduvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe guihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomh
X-ME-Proxy: <xmx:buTXXqDkeTD1VLycOarvfkK75CRdCZ3_WpaL_Y-5RldoCk4zrYeC_A> <xmx:buTXXlFwLqJE0LhV8p2bC5MBKWJ7lVy_xeiTnMtIiuICOFC8uVisDQ> <xmx:buTXXqQEPtTmuAlgpkFIwWpOr_RnC-_Bysp_g_vL85paIh3c17OPUg> <xmx:buTXXh_9hvg_nnCpCfJSYqYWpjVikJ2k-ljRzSSYe2PyB1q5aOba9w>
Received: from farpoint (c-73-234-242-12.hsd1.ma.comcast.net [73.234.242.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 63A6F3061CB6; Wed, 3 Jun 2020 13:57:02 -0400 (EDT)
From: "Dick Brooks" <dick@reliableenergyanalytics.com>
To: "'Hannes Tschofenig'" <Hannes.Tschofenig@arm.com>, <suit@ietf.org>
Cc: "'Saad EL JAOUHARI'" <saadeljaou@gmail.com>
References: <AM0PR08MB371631B7C1E6B50DCA29049AFA880@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB371631B7C1E6B50DCA29049AFA880@AM0PR08MB3716.eurprd08.prod.outlook.com>
Date: Wed, 3 Jun 2020 13:57:01 -0400
Organization: Reliable Energy Analytics
Message-ID: <8b6d01d639d0$62614150$2723c3f0$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_8B6E_01D639AE.DB5127F0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEpJGg3Q76y3b59AZfDOO6eGr7fRKohU+gA
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/kJNL3S0L_zCAuPLfjRSA5jWkde4>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?
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, 03 Jun 2020 17:57:06 -0000

My Company provides Risk Assessment software to the US Electric Industry to
meet NERC CIP-010-3 R1, Part 1.6 software integrity and authenticity and
verification standards across the software supply chain; my comments pertain
specifically to this use case.

 

See responses inline: DB>>

 

Thanks,

 

Dick Brooks



 <https://reliableenergyanalytics.com/products> Never trust software, always
verify and report! T

 <http://www.reliableenergyanalytics.com/>
http://www.reliableenergyanalytics.com

Email:  <mailto:dick@reliableenergyanalytics.com>
dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: Suit <suit-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Wednesday, June 03, 2020 5:23 AM
To: suit@ietf.org
Cc: Saad EL JAOUHARI <saadeljaou@gmail.com>
Subject: [Suit] How are firmware and firmware versions expressed in
manifest?

 

Hi all, 

 

in his review of the recent manifest draft Saad (on CC) pointed out that it
is not clear how the firmware version is identified in the manifest. This is
a good question and I thought I bring up to the group. It turns out that
there are different use cases that require identification of different
pieces of software and here is a list of what I consider relevant: 

 

 

DB>> Risk assessments for NERC CIP-010-3 R1, Part 1.6 require corroborating
evidence to establish trust in a software object. It's important that the
identification marks within a software object be consistent across domains.
The data in the installation file must match data in the digital signature
and metadata within vulnerability databases so that we can get accurate risk
assessments. 

 

* The manifest needs to point to a location where to obtain the firmware.
This is accomplished with a URL. Section 7.3 describes an example (look for
the uri parameters directive).

 

 

DB>> The "Trusted Source Location URL" where the "real/trusted" software
object is available is vitally important for an effective NERC CIP-010-3
risk assessment. This is part of the corroborating evidence that's needed.

 

 

* There is the digest of the firmware, which is used for security purposes,
and there is an example in Section 7.3 (look for the image digest parameters
directive). 

 

* Then, there is also the component id, which indicates where to store the
software / image. We discussed this recently in the context of TEEP where
the binaries of trusted applications are protected with the manifest and
those binaries will typically end up on a file system. In the OP-TEE secure
world OS those binaries are stored with the UUIDs in their file name. In a
low end IoT device, like a Cortex M class processor, there is typically no
file system and hence the firmware image ends up in a flash memory slot. 

 

* There is also the case with a differential update where the manifest needs
to indicate to what firmware images the differential update can be applied
to. This is accomplished with the image match condition.

 

DB>>Patches/Updates must contain clear metadata that can be correlated with
a specific software object that represents the original installation, and
other patch dependencies that must be in place for a successful deployment.
A  "Trusted Source Location URL" is also required, for CIP-010-3 software
integrity and authenticity risk assessments.

 

* Finally, there is also a version condition. This allows to express that a
manifest is applicable to one or multiple versions of the firmware. As
described in the information model draft, this situation occurs when you
upload an application that relies on existing software to be present on the
device. (Think of it as an API version.)

 

It is important to note that the manifest is not meant to be used to
describe the software running on the device. This is the job of other tools,
such as COSWID. The manifest instead provides instructions on how to update
firmware and to accomplish secure boot. 

 

DB>> I'm hoping to use the manifest as a virtual SBOM. Will let you know if
I'm successful in this regard. 

 

Is this a topic that needs to be better described in the draft? 

 

DB>> I believe so.

 

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.