Subject: [Suit] Valid but partial updates (possible threat)

From: Rønningstad, Øyvind <[email-masked]>
Date: Mon, 8 Jun 2020 11:36:43 +0000

Hi
I have a concern about root manifests. By root manifest I mean the manifest that describes the whole coordinated update (all payloads, dependencies, and conditions). For secure boot, the root manifest serves as the "entry point" for booting the system.

Imagine a device is expecting a new root manifest, and an attacker inserts a different manifest in its stead. The replacement manifest is a valid dependency manifest of a valid new root manifest but not a root manifest itself. When executed as a root manifest this manifest leaves the device in a bad state (e.g. No app or incompatible with existing app/libraries). How to protect against this (without resorting to transport-specific security)? Maybe a dedicated component for the manifest, with a separate class ID? If so, this must be known by the implementer, so it should be made explicit in the manifest document. I think this can also go into the information model as a distinct threat (even if it is very related to 4.2.3.  THREAT.IMG.INCOMPATIBLE: Mismatched Firmware), since it needs specific action from the implementer.  Something like:

"Valid but partial update
An attacker sends a subset of a valid update, that when applied in isolation breaks compatibility with other software on the device, or otherwise leaves the Software in a bad or incomplete state."

Øyvind Rønningstad

---

From: "Dick Brooks" <[email-masked]>
Date: Mon, 8 Jun 2020 10:15:31 -0400

This is precisely the type of attack I'm looking to detect before any
attempt at installation of the software. Good use case, Øyvind. 

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Rønningstad, Øyvind
Sent: Monday, June 08, 2020 7:37 AM
To: [email-masked]
Subject: [Suit] Valid but partial updates (possible threat)

Hi
I have a concern about root manifests. By root manifest I mean the manifest
that describes the whole coordinated update (all payloads, dependencies, and
conditions). For secure boot, the root manifest serves as the "entry point"
for booting the system.

Imagine a device is expecting a new root manifest, and an attacker inserts a
different manifest in its stead. The replacement manifest is a valid
dependency manifest of a valid new root manifest but not a root manifest
itself.. When executed as a root manifest this manifest leaves the device in
a bad state (e.g. No app or incompatible with existing app/libraries). How
to protect against this (without resorting to transport-specific security)?
Maybe a dedicated component for the manifest, with a separate class ID? If
so, this must be known by the implementer, so it should be made explicit in
the manifest document. I think this can also go into the information model
as a distinct threat (even if it is very related to 4.2.3.
THREAT.IMG.INCOMPATIBLE: Mismatched Firmware), since it needs specific
action from the implementer.  Something like:

"Valid but partial update
An attacker sends a subset of a valid update, that when applied in isolation
breaks compatibility with other software on the device, or otherwise leaves
the Software in a bad or incomplete state."

Øyvind Rønningstad

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

---

From: Brendan Moran <[email-masked]>
Date: Mon, 8 Jun 2020 15:24:22 +0000

There are several possible resolutions to this concern. I think that any realistic deployment should address more than one of them. The two most important mitigation are:

1. A key that is used to verify root manifests should be marked as such in the device. Verification of a root manifest should fail if it is signed by a key that is not marked for verifying root manifests.

2. Any valid tree of manifests must contain a specification for every element of an interdependent set of components. Independent groups of components may be specified with separate trees. This can be checked at dependency-resolution and system-validation time.

I’ve had some text about this in the past, but I don’t believe it is in the manifest specification. I think this detail should be in Section 6.2: Required Checks.

Please let me know what you think?

Best Regards,
Brendan

On 8 Jun 2020, at 15:15, Dick Brooks <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Dick Brooks

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Rønningstad, Øyvind
Sent: Monday, June 08, 2020 7:37 AM
To: [email-masked]
Subject: [Suit] Valid but partial updates (possible threat)

Hi

Øyvind Rønningstad

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.

---

From: Rønningstad, Øyvind <[email-masked]>
Date: Tue, 9 Jun 2020 12:52:10 +0000

Thanks.

1. This will fully mitigate the threat, but will require each implementer to be very cognizant, so should be explained carefully.

2. This seems a more fuzzy requirement, and I can envision it being tricky to implement, and will not work in cases where partial updates are sometimes valid (e.g. minor update to network stack).

Both of these will work, but are very use-case dependent. I'm thinking we should take care to formulate them so that they can be implemented generically, with each user configuring the behavior to suit their product. This is to make it easier to implement correctly, or rather, harder to implement incorrectly.

One idea building on your 1st mitigation: A new directive "enable-update" which takes as parameter any or all of: vendor-id, class-id, device-id, and component. The update fails if after the first suit-common block, the update hasn't been "enabled" with the right signing key and parameters. Because of the override mechanics, sub-manifests don't need to include the "enable" call.

We can also formalize the 2nd mitigation to something like: A SUIT implementation MUST keep a list of components that must be updated together. An update must fail if it cannot find all these components in either the dependency-components list or the components list.

What do you think?

BR,
Øyvind

From: Brendan Moran <[email-masked]> 
Sent: Monday, June 8, 2020 17:24
To: Dick Brooks <[email-masked]>
Cc: Rønningstad, Øyvind <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] Valid but partial updates (possible threat)

Best Regards,
Brendan

On 8 Jun 2020, at 15:15, Dick Brooks <mailto:[email-masked]> wrote:

Thanks,

Dick Brooks

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: mailto:[email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <mailto:[email-masked]> On Behalf Of Rønningstad, Øyvind
Sent: Monday, June 08, 2020 7:37 AM
To: mailto:[email-masked]
Subject: [Suit] Valid but partial updates (possible threat)

Hi

Øyvind Rønningstad

mailto:[email-masked]

mailto:[email-masked]