Draft: draft-ietf-suit-architecture

Commentary: This PR will contain the edits for :    review Roman 's AD review
Vulnerabilities with Internet of Things (IoT) devices have raised the
need for a reliable and secure firmware update mechanism suitable for
devices with resource constraints.  Incorporating such update
mechanism to fix vulnerabilities, to update configuration settings as
well as adding new functionality is recommended by security experts.
Vulnerabilities with Internet of Things (IoT) devices have raised the
need for a reliable and secure firmware update mechanism suitable for
devices with resource constraints.  Incorporating such an update
mechanism is a fundamental requirement for fixing vulnerabilities but
it also enables other important capabilities such as updating
configuration settings as well as adding new functionality.
The firmware image can be confidentiality protected so that
attempts by an adversary to recover the plaintext binary can be
mitigated or at least made more difficult.  Obtaining the firmware
is often one of the first steps to mount an attack since it gives
the adversary valuable insights into used software libraries,
configuration settings and generic functionality.  Even though
reverse engineering the binary can be a tedious process modern
reverse engineering frameworks have made this task a lot easier.
The firmware image can be confidentiality protected so that
attempts by an adversary to recover the plaintext binary can be
mitigated or at least made more difficult.  Obtaining the firmware
is often one of the first steps to mount an attack since it gives
the adversary valuable insights into the software libraries used,
configuration settings and generic functionality.  Even though
reverse engineering the binary can be a tedious process modern
reverse engineering frameworks have made this task a lot easier.
While the IETF standardization work has been focused on the manifest
format, a fully interoperable solution needs more than a standardized
manifest.  For example, protocols for transferring firmware images
and manifests to the device need to be available as well as the
status tracker functionality.  These building blocks have been
developed by various organizations under the umbrella of an IoT
device management solution.  The LwM2M protocol is one IoT device
management protocol.
While the IETF standardization work has been focused on the manifest
format, a fully interoperable solution needs more than a standardized
manifest.  For example, protocols for transferring firmware images
and manifests to the device need to be available as well as the
status tracker functionality.  Devices also require a mechanism to
discover the status tracker(s) and/or firmware servers.  These
building blocks have been developed by various organizations under
the umbrella of an IoT device management solution.  The LwM2M
protocol is one IoT device management protocol.
Ensuring that firmware updates addressing critical flaws can be
obtained even after a product is discontinued or a vendor goes out
of business.
Homogeneous Storage Architecture (HoSA): A device that stores all
firmware components in the same way, for example in a file system
or in flash memory.
Heterogeneous Storage Architecture (HeSA): A device that stores at
least one firmware component differently from the rest, for
example a device with an external, updateable radio, or a device
with internal and external flash memory.
The status tracker may be operated by any suitable stakeholder;
typically the Author, Device Operator, or Network Operator.
In some cases it may be desireable to distribute firmware images
using a multicast or broadcast protocol.  This architecture does not
make recommendations for any such protocol.  However, given that
broadcast may be desirable for some networks, updates must cause the
least disruption possible both in metadata and firmware transmission.
For an update to be broadcast friendly, it cannot rely on link layer,
network layer, or transport layer security.  A solution has to rely
on security protection applied to the manifest and firmware image
instead.  In addition, the same manifest must be deliverable to many
devices, both those to which it applies and those to which it does
not, without a chance that the wrong device will accept the update.
Considerations that apply to network broadcasts apply equally to the
use of third-party content distribution networks for payload
distribution.
In some cases it may be desirable to distribute firmware images using
a multicast or broadcast protocol.  This architecture does not make
recommendations for any such protocol.  However, given that broadcast
may be desirable for some networks, updates must cause the least
disruption possible both in metadata and firmware transmission.  For
an update to be broadcast friendly, it cannot rely on link layer,
network layer, or transport layer security.  A solution has to rely
on security protection applied to the manifest and firmware image
instead.  In addition, the same manifest must be deliverable to many
devices, both those to which it applies and those to which it does
not, without a chance that the wrong device will accept the update.
Considerations that apply to network broadcasts apply equally to the
use of third-party content distribution networks for payload
distribution.
Installation is the act of processing the payload into a format that
the IoT device can recognise and the bootloader is responsible for
then booting from the newly installed firmware image.
architecture describes the steps for getting the firmware image and
the manifest from the author to the firmware consumer on the IoT
device.  Once the firmware consumer has retrieved and successfully
processed the manifest and the firmware image it needs to hand
control over to the bootloader.
In most cases this requires the MCU to restart.  Once the MCU has
initiated a restart, the bootloader determines whether a newly
available firmware image should be executed.
A power failure at any time during a firmware update must not cause a
failure of the device.  Equally, adverse network conditions during an
update must not cause the failure of the device.
One way to achieve this functionality is to provide a minimum of two
storage locations for firmware.  An alternative approach is to use a
second stage bootloader with built-in full featured firmware update
functionality such that it is possible to return to the update
process after power down.
Installation is the act of processing the payload into a format that
the IoT device can recognize and the bootloader is responsible for
then booting from the newly installed firmware image.  This process
is different when a bootloader is not involved.  For example, when an
application is updated in a full-featured operating system, the
updater may halt and restart the application in isolation.  Devices
must not fail when a disruption occurs during the update process.
For example, a power failure or network disruption during the update
process must not cause the device to fail.
architecture describes the steps for getting the firmware image and
the manifest from the author to the firmware consumer on the IoT
device.  Once the firmware consumer has retrieved and successfully
processed the manifest and the firmware image it needs to invoke the
new firmware image.  This is managed in many different ways,
depending on the type of device, but it typically involves halting
the current version of the firmware, handing control over to a
firmware with a higher privilege/trust level (the firmware verifier)
verifying the new firmware's authenticity & integrity, and then
invoking it.
In an execute-in-place microcontroller, this is often done by
rebooting into a bootloader (simultaneously halting the application &
handing over to the higher privilege level) then executing a secure
boot process (verifying and invoking the new image).
In a rich OS, this may be done by halting one or more processes, then
invoking new applications.  In some OSs, this implicitly involves the
kernel verifying the code signatures on the new applications.
The invocation process is security sensitive.  An attacker will
typically try to retrieve a firmware image from the device for
reverse engineering or will try to get the firmware verifier to
execute an attacker-modified firmware image.  The firmware verifier
will therefore have to perform security checks on the firmware image
before it can be invoked.  These security checks by the firmware
verifier happen in addition to the security checks that took place
when the firmware image and the manifest were downloaded by the
firmware consumer.
A firmware verifier must verify the firmware image it boots as
part of the secure boot process.  Doing so requires meta-data to
be stored alongside the firmware image so that the firmware
verifier can cryptographically verify the firmware image before
booting it to ensure it has not been tampered with or replaced.
This meta-data used by the firmware verifier may well be the same
manifest obtained with the firmware image during the update
process.
An IoT device needs a recovery strategy in case the firmware
update / invocation process fails.  The recovery strategy may
include storing two or more application firmware images on the
device or offering the ability to invoke a recovery image to
perform the firmware update process again using firmware updates
over serial, USB or even wireless connectivity like Bluetooth
Smart.  In the latter case the firmware consumer functionality is
contained in the recovery image and requires the necessary
functionality for executing the firmware update process, including
manifest parsing.
While this document assumes that the firmware verifier itself is
distinct from the role of the firmware consumer and therefore does
not manage the firmware update process, this is not a requirement and
these roles may be combined in practice.
Using a bootloader as the firmware verifier requires some special
considerations, particularly when the bootloader implements the
robustness requirements identified by the IOTSU workshop RFC8240.
In most cases the MCU must restart in order to hand over control to
the bootloader.  Once the MCU has initiated a restart, the bootloader
determines whether a newly available firmware image should be
executed.  If the bootloader concludes that the newly available
firmware image is invalid, a recovery strategy is necessary.  There
are only two approaches recovering from an invalid firmware: either
the bootloader must be able to select a different, valid firmware, or
it must be able to obtain a new, valid firmware.  Both of these
approaches have implications for the architecture of the update
system.
Second, the firmware image that has to be replaced is still
available on the device as a backup in case the freshly downloaded
firmware image does not boot correctly.
Since many low end IoT devices use non-relocatable code, the
bootloader needs to copy the newly downloaded application firmware
image into the location of the old application firmware image and
vice versa.
The boot process is security sensitive.  An attacker will typically
try to retrieve a firmware image from the device for reverse
engineering or will try to get the bootloader to excute an attacker-
modified firmware image.  The bootloader will therefore have to
perform security checks on the firmware image before it can be
booted.  These security checks by the bootloader happen in addition
to the security checks that took place when the firmware image and
the manifest were downloaded by the firmware consumer.
Throughout this document we assume that the bootloader itself is
distinct from the role of the firmware consumer and therefore does
not manage the firmware update process.  This may give the impression
that the bootloader itself is a completely separate component, which
is mainly responsible for selecting a firmware image to boot.
A bootloader must verify the firmware image it boots as part of
the secure boot process.  Doing so requires meta-data to be stored
alongside the firmware image so that the bootloader can
cryptographically verify the firmware image before booting it to
ensure it has not been tampered with or replaced.  This meta-data
used by the bootloader may well be the same manifest obtained with
the firmware image during the update process (with the severable
fields stripped off).
An IoT device needs a recovery strategy in case the firmware
update / boot process fails.  As mentioned earlier, the recovery
strategy may include storing two or more application firmware
images on the device or offering the ability to have a second
stage bootloader perform the firmware update process again using
firmware updates over serial, USB or even wireless connectivity
like Bluetooth Smart.  In the latter case the firmware consumer
functionality is contained in the second stage bootloader and
requires the necessary functionality for executing the firmware
update process, including manifest parsing.
Second, the firmware image that has to be replaced is still
available on the device as a backup in case the freshly downloaded
firmware image does not boot or operate correctly.
Therefore, the firmware consumer must know where to store the new
firmware.  In some cases, this may be implicit, for example replacing
the least-recently-used firmware image.  In other cases, the storage
location of the new firmware must be explicit, for example when a
device has one or more application firmware images and a recovery
image with limited functionality, sufficient only to perform an
update.
Since many low end IoT devices use non-relocatable code, either the
bootloader needs to copy the newly downloaded application firmware
image into the location of the old application firmware image and
vice versa or multiple versions of the firmware need to be prepared
for different locations.
The bootloader needs to fetch the manifest (or manifest-alike
headers) stored in flash memory alongside the firmware image and
parse their content for subsequent cryptographic verification.
The bootloader needs to fetch the manifest (or manifest-alike
headers) from nonvolatile storage and parse its contents for
subsequent cryptographic verification.
In order for a firmware consumer to apply an update, it has to make
several decisions using manifest-provided information and data
available on the device itself.  For more detailed information and a
longer list of information elements in the manifest consult the
information model specification I-D.ietf-suit-information-model,
which offers justifications for each element, and the manifest, see
I-D.ietf-suit-manifest}, for details about how this information is
included in the manifest.
In order for a firmware consumer to apply an update, it has to make
several decisions using manifest-provided information and data
available on the device itself.  For more detailed information and a
longer list of information elements in the manifest consult the
information model specification I-D.ietf-suit-information-model,
which offers justifications for each element, and the manifest, see
I-D.ietf-suit-manifest, for details about how this information is
included in the manifest.
A manifest may not only be used to protect firmware images but also
personalization data related to firmware or software.  Trusted
Execution Environments (TEEs), for example, benefit from a protocol
for managing the lifecycle of trusted applications (TAs) running
inside a TEE.  TEEs may obtain TAs from different authors and those
TAs may require personalization data, such as payment information, to
be securely conveyed to the TEE.
A manifest may not only be used to protect firmware images but also
configuration data such as network credentials or personalization
data related to firmware or software.  Personalization data
demonstrates the need for mutually-distrustful delivery of two or
more images into a device.  Personalization data is used with Trusted
Execution Environments (TEEs), which benefit from a protocol for
managing the lifecycle of trusted applications (TAs) running inside a
TEE.  TEEs may obtain TAs from different authors and those TAs may
require personalization data, such as payment information, to be
securely conveyed to the TEE.  The TA's author does not want to
expose the TA to the user, and the user does not want to expose the
payment information to the TA's author.
For confidentiality protection of the firmware image, it must be
done in such a way that the intended firmware consumer(s) can
decrypt it.  The information that is encrypted individually for
each device must maintain friendliness to Content Distribution
Networks, bulk storage, and broadcast protocols.  For
confidentiality protection of firmware images the author needs to
be in possession of the certificate/public key or a pre-shared key
of a device.  The use of confidentiality protection of firmware
images is optional.
For confidentiality protection of the firmware image, it must be
done in such a way that the intended firmware consumer(s), other
authorized parties, and no one else can decrypt it.  The
information that is encrypted individually for each device/
recipient must maintain friendliness to Content Distribution
Networks, bulk storage, and broadcast protocols.  For
confidentiality protection of firmware images the author needs to
be in possession of the certificate/public key or a pre-shared key
of a device.  The use of confidentiality protection of firmware
images is optional.
A manifest specification must support different cryptographic
algorithms and algorithm extensibility.  Due of the nature of
unchangeable code in ROM for bootloaders the use of post-quantum
secure signature mechanisms, such as hash-based signatures RFC8778,
are attractive.  These algorithms maintain security in presence of
quantum computers.
A manifest specification must support different cryptographic
algorithms and algorithm extensibility.  Moreover, since RSA- and
ECC-based signature schemes may become vulnerable to quantum-
accelerated key extraction in the future, unchangeable bootloader
code in ROM is recommended to use post-quantum secure signature
schemes such as hash-based signatures RFC8778.  A bootloader author
must carefully consider the service lifetime of their product and the
time horizon for quantum-accelerated key extraction.  The worst-case
estimate, at time of writing, for the time horizon to key extraction
with quantum acceleration is approximately 2030, based on current
research quantum-factorization.