Subject: [Suit] Devices with multiple updatable elements

From: Amyas Phillips <[email-masked]>
Date: Wed, 31 Oct 2018 09:20:27 +0000

Hi All

I want to suggest modifications to draft-ietf-suit-information-model-01,
sections:

3.3.1.  Security Requirement MFSR1: Monotonic Sequence Numbers
4.10.  Manifest Element: Storage Location , and
4.11. Manifest Element: Component Identifier

Here are the current texts, to save you looking them up:

3.3.1.  Security Requirement MFSR1: Monotonic Sequence Numbers

   Only an actor with firmware installation authority is permitted to
   decide when device firmware can be installed.  To enforce this rule,
   manifests MUST contain monotonically increasing sequence numbers.
   Manifests MAY use UTC epoch timestamps to coordinate monotonically
   increasing sequence numbers across many actors in many locations.  If
   UTC epoch timestamps are used, they MUST NOT be treated as times,
   they MUST be treated only as sequence numbers.  Devices MUST reject
   manifests with sequence numbers smaller than any onboard sequence
   number.

   Note: This is not a firmware version.  It is a manifest sequence
   number.  A firmware version may be rolled back by creating a new
   manifest for the old firmware version with a later sequence number.

   Mitigates: Threat MFT1

   Implemented by: Manifest Element: Monotonic Sequence Number

4.10.  Manifest Element: Storage Location

   This element tells the device which component is being updated.  The
   device can use this to establish which permissions are necessary and
   the physical location to use.

   This element is MANDATORY and MUST be present to enable devices to
   store payloads to the correct location.

   Implements: Security Requirement MFSR4b

4.10.1.  Example 1: Two Storage Locations

   A device supports two components: an OS and an application.  These
   components can be updated independently, expressing dependencies to
   ensure compatibility between the components.  The firmware authority
   chooses two storage identifiers:
   -  OS
   -  APP

4.10.2.  Example 2: File System

   A device supports a full filesystem.  The firmware authority chooses
   to make the storage identifier the path at which to install the
   payload.  The payload may be a tarball, in which case, it unpacks the
   tarball into the specified path.

4.10.3.  Example 3: Flash Memory

   A device supports flash memory.  The firmware authority chooses to
   make the storage identifier the offset where the image should be
   written.

4.11.  Manifest Element: Component Identifier

   In a heterogeneous storage architecture, a storage identifier is
   insufficient to identify where and how to store a payload.  To
   resolve this, a component identifier indicates which part of the
   storage architecture is targeted by the payload.  In a homogeneous
   storage architecture, this element is unnecessary.

   This element is OPTIONAL and only necessary in heterogeneous storage
   architecture devices.

   Implements: MFUR3

Several examples are given in the documents of scenarios in which a single
device has multiple updatable elements.  draft-moran-suit-architecture
discusses devices with multiple processors, and a device with an external
updatable radio. draft-ietf-suit-information-model-01 in section 3.5.3.
Usability Requirement MFUR3 discusses scenarios where peripheral devices
need updating, and firmware modules are independently updatable.  In
section 4.10.1.  Example 1: Two Storage Locations, the specific scenario of
separately-maintained OS and APP is introduced.  Other scenarios spring to
mind, such as bootloaders and recovery images.

Section 3.3.1 in draft-ietf-suit-information-model-01 introduces the idea
that multiple uncoordinated actors may be creating manifests for the same
device. This might happen if they are maintainers of firmware for different
parts of the device's system.

To prevent one actor's update of element A invalidating another's update of
element B, unnecessarily and quite likely unpredictably, I propose that the
requirement in section 3.3.1 for the manifest sequence number to increase
monotonically be scoped to each updatable element.

This is where I ought to sign off and request your consideration of my
proposal.  However, I have to request that you bear with me a little
further, because draft-ietf-suit-information-model-01 is not completely
clear about how to identify updatable elements.

A device with multiple updatable elements will need to know what element is
targeted by a manifest, so that it can invoke an appropriate handler.
 Section 4.10.  Manifest Element: Storage Location says plainly "This
element tells the device which component is being updated.  The device can
use this to establish which permissions are necessary and the physical
location to use."  This descends from security threat MFT5: The target
device installs the payload to the wrong location.  This parameter (aka
storageIdentifier elsewhere in the document) would also serve very well in
the three example scenarios in usability requirement MFUR3: multiple MCUs,
separate code and configuration, and modular firmware.  Instead of doing
that the document in section 4.11 introduces a new parameter, Component
Identifier.

For the use cases and threats given, I suggest that Storage Location is
sufficient.  It can both identify a handler (e.g. file:) and if necessary
provide a parameter to it (e.g. bin/fw/wifi). Component Identifier is
redundant and should be removed.  If Component Identifier is removed, then
the concepts of HeSA and HoSA are also unnecessary to the specification and
can also be removed.

To recap then, I want to suggest two changes:

1. Scope the requirement in section 3.3.1 (for the manifest sequence number
to increase monotonically) to each updatable element (i.e. to each Storage
Location, if item 2 is also acceptable).  This is to better support use
cases involving multiple independent firmware maintainers.

2. Remove Component Identifier (4.11) from
draft-ietf-suit-information-model-01.  State instead that MFUR3 (3.5.3) is
satisfied by manifest element Storage Location (4.10).   Remove references
to HeSA and HoSA from both documents.  Generalise language and expand
examples around use of Storage Location to clarify usage in use cases
involving devices with multiple separately updatable components.

Many thanks

Amyas Phillips