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

[Dick Brooks <[e-mail]>]

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

-----Original Message-----
From: Suit <[e-mail]> On Behalf Of Rønningstad, Øyvind
Sent: Monday, June 08, 2020 7:37 AM
To: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/suit