Draft: draft-ietf-suit-architecture

Commentary: Address IoT Dir review and add comments on firmware server discovery . Editorial fixes Add DNS - SD reference Clarify difference between software & firmware Clarify that SUIT treats software and firmware as equal Note that energy for receiving an update is also substantial in some cases . Clarify TPA , OEM , ODM roles . Replace keyed message digest with the more generic " message authentication code " Clarify the confidentiality requirement between users & TA authors .
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.
Vulnerabilities in 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.
Developing secure Internet of Things (IoT) devices is not an easy
task and supporting a firmware update solution requires skillful
engineers.  Once devices are deployed, firmware updates play a
critical part in their lifecycle management, particularly when
devices have a long lifetime, or are deployed in remote or
inaccessible areas where manual intervention is cost prohibitive or
otherwise difficult.  Firmware updates
for IoT devices are expected to work automatically, i.e. without user
involvement.  Automatic updates that do not require human
intervention are key to a scalable solution for fixing software
vulnerabilities.
Developing secure Internet of Things (IoT) devices is not an easy
task and supporting a firmware update solution requires skillful
engineers.  Once devices are deployed, firmware updates play a
critical part in their lifecycle management, particularly when
devices have a long lifetime, or are deployed in remote or
inaccessible areas where manual intervention is cost prohibitive or
otherwise difficult.  Firmware updates
for IoT devices are expected to work automatically, i.e. without user
involvement.  Conversely, IoT devices are expected to account for
user preferences and consent when scheduling updates.  Automatic
updates that do not require human intervention are key to a scalable
solution for fixing software vulnerabilities.
While the standardization work has been informed by and optimized for
firmware update use cases of Class 1 devices (according to the device
class definitions in RFC 7228 RFC7228) devices, there is nothing in
the architecture that restricts its use to only these constrained IoT
devices.  Moreover, this architecture is not limited to managing
software updates, but can also be applied to managing the delivery of
arbitrary data, such as configuration information and keys.  Unlike
higher end devices, like laptops and desktop PCs, many IoT devices do
not have user interfaces and support for unattended updates is,
therefore, essential for the design of a practical solution.
Constrained IoT devices often use a software engineering model where
a developer is responsible for creating and compiling all software
running on the device into a single, monolithic firmware image.  On
higher end devices application software is, on the other hand, often
downloaded separately and even obtained from developers different to
the developers of the lower level software.  The details for how to
obtain those application layer software binaries then depends heavily
on the platform, programming language uses and the sandbox the
software is executed in.
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.
While the standardization work has been informed by and optimized for
firmware update use cases of Class 1 devices (according to the device
class definitions in RFC 7228 RFC7228) devices, there is nothing in
the architecture that restricts its use to only these constrained IoT
devices.  Moreover, this architecture is not limited to managing
firmware and software updates, but can also be applied to managing
the delivery of arbitrary data, such as configuration information and
keys.  Unlike higher end devices, like laptops and desktop PCs, many
IoT devices do not have user interfaces and support for unattended
updates is, therefore, essential for the design of a practical
solution.  Constrained IoT devices often use a software engineering
model where a developer is responsible for creating and compiling all
software running on the device into a single, monolithic firmware
image.  On higher end devices application software is, on the other
hand, often downloaded separately and even obtained from developers
different to the developers of the lower level software.  The details
for how to obtain those application layer software binaries then
depends heavily on the platform, programming language used and the
sandbox in which the software is executed.
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, for example
using pre-configured hostnames or RFC6763 DNS-SD.  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 an energy efficient design of a battery-powered IoT
devices because a firmware update, particularly writing the
firmware image to flash, is a heavy task for a device.
Ensuring an energy efficient design of a battery-powered IoT
device because a firmware update, particularly radio communication
and writing the firmware image to flash, is an energy-intensive
task for a device.
Software: Similar to firmware, but typically dynamically loaded by
an Operating System.  Used interchangeably with firmware in this
document.
Trust Provisioning Authority (TPA): The TPA distributes trust
anchors and authorization policies to various stakeholders.  The
TPA may also delegate rights to stakeholders.  For example, in
some cases, the Original Design Manufacturer (ODM), which is a
company that designs and manufactures a product, may act as a TPA
and may decide to remain in full control over the firmware update
process of their products.
Trust Provisioning Authority (TPA): The TPA distributes trust
anchors and authorization policies to devices and various
stakeholders.  The TPA may also delegate rights to stakeholders.
Typically, the Original Equipment Manufacturer (OEM) or Original
Design Manufacturer (ODM) will act as a TPA, however complex
supply chains may require a different design.  In some cases, the
TPA may decide to remain in full control over the firmware update
process of their products.
User: The end-user of a device.  The user may interact with
devices via web or smart phone apps, as well as through direct
user interfaces.
We make no assumptions about where the server-side component is
deployed.  The deployment of status trackers is flexible and may
be found at
cloud-based servers, on-premise servers, or may be embedded in
edge computing device.  A status tracker server component may even
be deployed on an IoT device.  For example, if the IoT device
contains multiple MCUs, then the main MCU may act as a status
tracker towards the other MCUs.  Such deployment is useful when
updates have to be synchronized across MCUs.
We make no assumptions about where the server-side component is
deployed.  The deployment of status trackers is flexible and may
be found at
cloud-based servers, on-premise servers, or may be embedded in
edge computing devices.  A status tracker server component may
even be deployed on an IoT device.  For example, if the IoT device
contains multiple MCUs, then the main MCU may act as a status
tracker towards the other MCUs.  Such deployment is useful when
updates have to be synchronized across MCUs.
More devices today than ever before are connected to the Internet,
which drives the need for firmware updates to be provided over the
Internet rather than through traditional interfaces, such as USB or
RS-232.  Updating updates over the Internet requires the device to
fetch the new firmware image as well as the manifest.
More devices today than ever before are connected to the Internet,
which drives the need for firmware updates to be provided over the
Internet rather than through traditional interfaces, such as USB or
RS-232.  Sending updates over the Internet requires the device to
fetch the new firmware image as well as the manifest.
a status tracker.
With Server-initiated updates the server-side component of the
status tracker learns about a new firmware version and determines
what devices qualify for a firmware update.  Once the relevant
devices have been selected, the status tracker informs these
devices and the firmware consumers obtain those images and
manifests.  Server-initiated updates are important because they
allow a quick response time.  Note that the client-side status
tracker needs to be reachable by the server-side component.  This
may require devices to keep reachability information on the
server-side up-to-date and state at NATs and stateful packet
filtering firewalls alive.
With Server-initiated updates the server-side component of the
status tracker learns about a new firmware version and determines
which devices qualify for a firmware update.  Once the relevant
devices have been selected, the status tracker informs these
devices and the firmware consumers obtain those images and
manifests.  Server-initiated updates are important because they
allow a quick response time.  Note that the client-side status
tracker needs to be reachable by the server-side component.  This
may require devices to keep reachability information on the
server-side up-to-date and state at NATs and stateful packet
filtering firewalls alive.
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.
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 for 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.
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.
Since many low end IoT devices do not use position-independent 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.
Cryptographic libraries with hash functions, digital signatures
(for asymmetric crypto), keyed message digests (for symmetric
crypto) need to be accessible.
Cryptographic libraries with hash functions, digital signatures
(for asymmetric crypto), message authentication codes (for
symmetric crypto) need to be accessible.
The simplest, and currently most common, architecture consists of a
single MCU along with its own peripherals.  These SoCs generally
contain some amount of flash memory for code and fixed data, as well
as RAM for working storage.  A notable characteristic of these SoCs
is that the primary code is generally execute in place (XIP).  Due to
the non-relocatable nature of the code, the firmware image needs to
be placed in a specific location in flash since the code cannot be
executed from an arbitrary location in flash.  Hence, then the
firmware image is updated it is necessary to swap the old and the new
image.
The simplest, and currently most common, architecture consists of a
single MCU along with its own peripherals.  These SoCs generally
contain some amount of flash memory for code and fixed data, as well
as RAM for working storage.  A notable characteristic of these SoCs
is that the primary code is generally execute in place (XIP).  Due to
the non-relocatable nature of the code, the firmware image needs to
be placed in a specific location in flash since the code cannot be
executed from an arbitrary location in flash.  Hence, when the
firmware image is updated it is necessary to swap the old and the new
image.
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.
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 confidentiality to be maintained between
two or more stakeholders that both deliver images to the same 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's code to any
other stakeholder or third party.  The user does not want to expose
the payment information to any other stakeholder or third party.