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

[Dick Brooks <[e-mail]>]

Thanks, Hannes - I very much appreciate your thoughts and insights; my
responses are shown inline DB2>>

 

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:[e-mail]>
[e-mail]

Tel: [phone]

 

From: Suit <[e-mail]> On Behalf Of Hannes Tschofenig
Sent: Thursday, June 04, 2020 12:45 PM
To: Dick Brooks <[e-mail]>; [e-mail]
Cc: 'Saad EL JAOUHARI' <[e-mail]>
Subject: Re: [Suit] How are firmware and firmware versions expressed in
manifest?

 

Hi Dick, 

 

Thanks for the review comments and for the pointer to NERC CIP-010-3. 

 

Please see my comments below: 

 

~~ snip~~ 

 

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. 

 

[Hannes] Looking at Part 1.6 I see two requirements, namely: 1.6.1. Verify
the identity of the software source; and 1.6.2. Verify the integrity of the
software obtained from the software source.

 

This is certainly met by the digital signature covering the manifest
(provided by the COSE wrapper) and the manifest also includes the digest of
the firmware/software, which ensures the integrity of it. 

 

Part 1.6 then goes on and says: "An example of evidence may include, but is
not limited to a change request record that demonstrates the verification of
identity of the software source and integrity of the software was performed
prior to the baseline change or a process which documents the mechanisms in
place that would automatically ensure the identity of the software source
and integrity of the software."

 

I am not sure about this part and whether it there is something needed in
addition to what we already have in the previously mentioned security
wrapper. 

 

DB2>>You have to look a little deeper to understand what it means to
"verify" identity and authenticity (see page 36 of CIP-010-3 technical
guidelines for software verification for more detail). A digitally signed
object can still carry malware, so it takes more digging to conduct an
effective verification than simply relying on a digitally singed object
(which could contain a contaminated library in the build process - hopefully
not).

 

 

 

* 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.

 

[Hannes] The URL is included in the manifest and, while there is a way to
override it (assuming proper authorization). Since the software/firmware is,
as mentioned above, also integrity protected there is another layer of
defense provided.

 

DB2>>Does the URL include the path+filename of the actual software object
being downloaded? If yes, this would be very useful information.

 

* 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.

 

[Hannes] This is indeed provided and I think we are good there. We should
probably add an example. 

 

DB2>>This is very good to know. Thanks for the insights. An example would be
very helpful.

 

 

* 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. 

 

[Hannes] Thanks, feedback would be highly appreciated. 

 

 

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

 

DB>> I believe so.

 

[Hannes] I will give it a try and post text for a new section to the list. 

 

DB2>> I'm also curious to know if SUIT will work for FPGA bitstreams - do
you know? This one is turning out to be a tough nut to crack - very little
info on FPGA bitstreams metadata (i.e. embedded IP could be concerning). I
welcome any advice you can offer on this point.

 

Thanks for the feedback. 

 

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.