Draft: draft-ietf-suit-architecture

Commentary: Proposed text based on discussions at the IETF meeting in Montreal . Added extra text about the status tracker , including a new figure describing an example use of the status tracker for firmware updates . Then , text about the TEEP use case .
When developing IoT devices, one of the most difficult problems to
solve is how to update the firmware on the device.  Once the device
is deployed, firmware updates play a critical part in its lifetime,
particularly when devices have a long lifetime, are deployed in
remote or inaccessible areas or where manual intervention is cost
prohibitive or otherwise difficult.  The need for a firmware update
may be to fix bugs in software, to add new functionality, or to re-
configure the device.
The firmware image is authenticated and attempts to flash a
malicious firmware image are prevented.
The firmware image can be confidentiality protected so that
attempts by an adversary to recover the plaintext binary can be
prevented.  Obtaining the plaintext binary is often one of the
first steps for an attack to mount an attack.
When developing IoT devices, one of the most difficult problems to
solve is how to update the firmware on the device.  Once the device
is deployed, firmware updates play a critical part in its lifetime,
particularly when devices have a long lifetime, are deployed in
remote or inaccessible areas where manual intervention is cost
prohibitive or otherwise difficult.  Updates to the firmware of an
IoT device are done to fix bugs in software, to add new
functionality, and to re-configure the device to work in new
environments or to behave differently in an already deployed context.
The firmware image is authenticated and integrity protected.
Attempts to flash a modified firmware image or an image from an
unknown source are prevented.
The firmware image can be confidentiality protected so that
attempts by an adversary to recover the plaintext binary can be
prevented.  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).
More details about the security goals are discussed in architecture
and requirements are described in requirements.
functionality varies throughout different implementations.
functionality varies throughout different implementations.  A more
detailed discussion is provided in bootloader.
Microcontroller (MCU for microcontroller unit): An MCU is a
compact integrated circuit designed for use in embedded systems.
A typical microcontroller includes a processor, memory (RAM and
flash), input/output (I/O) ports and other features connected via
some bus on a single chip.  The term 'system on chip (SoC)' is
often used for these types of devices.
System on Chip (SoC): An SoC is an integrated circuit that
integrates all components of a computer, such as CPU, memory,
input/output ports, secondary storage, etc.
Trusted Execution Environments (TEEs): An execution environment
that runs alongside of, but is isolated from, an REE.
Rich Execution Environment (REE): An environment that is provided
and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
potentially in conjunction with other supporting operating systems
and hypervisors; it is outside of the TEE.  This environment and
applications running on it are considered un-trusted.
Trusted applications (TAs): An application component that runs in
a TEE.
For more information about TEEs see I-D.ietf-teep-architecture.
Device: The device is the recipient of the firmware image and the
manifest.  The goal is to update the firmware of the device.  A
single device may need to obtain more than one firmware image and
manifest to succesfully perform an update.
Communicator: The communicator component of the device interacts
with the firmware update server.  It receives firmware images and
triggers an update, if needed.  The communicator either polls a
firmware update server for the most recent manifest/firmware or
manifests/firmware images are pushed to it.  Note that the
firmware update process may involve multiple stages since one or
multiple manifests may need to be downloaded before the
communicator can fetch one or multiple firmware images/software
components.
Status Tracker: The status tracker offers device management
functionality that includes keep track of the firmware update
process.  This includes fine-grained monitoring of changes at the
device, for example, what state of the firmware update cycle the
device is currently in.
Firmware Server: Entity that stores firmware images and manifests.
Some deployments may require storage of the firmware images/
manifests on more than one entities before they reach the device.
Firmware Consumer: The firmware consumer is the recipient of the
firmware image and the manifest.  It is responsible for parsing
and verifying the received manifest and for storing the obtained
firmware image.  The firmware consumer plays the role of the
update component on the IoT device typically running in the
application firmware.  It interacts with the firmware server and
with the status tracker, if present.
Status Tracker: The status tracker offers device management
functionality to retrieve information about the installed firmware
on a device and other device characteristics (including free
memory and hardware components), to obtain the state of the
firmware update cycle the device is currently in, and to trigger
the update process.  The deployment of status trackers is flexible
and they may be used as cloud-based servers, on-premise servers,
embedded in edge computing device (such as Internet access
gateways or protocol translation gateways), or even in smart
phones and tablets.  While the IoT device itself runs the client-
side of the status tracker it will most likely not run a status
tracker itself unless it acts as a proxy for other IoT devices in
a protocol translation or edge computing device node.  How much
functionality a status tracker includes depends on the selected
configuration of the device management functionality and the
communication environment it is used in.  In a generic networking
environment the protocol used between the client and the server-
side of the status tracker need to deal with Internet
communication challenges involving firewall and NAT traversal.  In
other cases, the communication interaction may be rather simple.
This architecture document does not impose requirements on the
status tracker.
Firmware Server: The firmware server stores firmware images and
manifests and distributes them to IoT devices.  Some deployments
may require a store-and-forward concept, which requires storing
the firmware images/manifests on more than one entity before
they reach the device.  There is typically some interaction
between the firmware server and the status tracker but those
entities are often physically separated on different devices for
scalability reasons.
Microcontroller (MCU for microcontroller unit) is a small computer
on a single integrated circuit, which is often used for mass
volumne IoT devices.
System on Chip (SoC) is an integrated circuit that integrates all
components of a computer, such as CPU, memory, input/output ports,
secondary storage, etc.
"A trust anchor store is a set of one or more trust anchors stored
in a device.  A device may have more than one trust anchor store,
each of which may be used by one or more applications."  A trust
anchor store must resist modification against unauthorized
insertion, deletion, and modification.
This architecture does not specify any specific broadcast protocol
however, given that broadcast may be desirable for some networks,
updates must cause the least disruption possible both in metadata and
payload transmission.
This architecture does not specify any specific broadcast protocol.
However, given that broadcast may be desirable for some networks,
updates must cause the least disruption possible both in metadata and
payload transmission.
The bootloader must be minimal, containing only flash support,
cryptographic primitives and optionally a recovery mechanism.  The
recovery mechanism is used in case the update process failed and may
include support for firmware updates over serial, USB or even a
limited version of wireless connectivity standard like a limited
Bluetooth Smart.  Such a recovery mechanism must provide security at
least at the same level as the full featured firmware update
functionalities.
The bootloader needs to verify the received manifest and to install
the bootable firmware image.  The bootloader should not require
updating since a failed update poses a risk in reliability.  If more
functionality is required in the bootloader, it must use a two-stage
bootloader, with the first stage comprising the functionality defined
above.
All information necessary for a device to make a decision about the
installation of a firmware update must fit into the available RAM of
a constrained IoT device.  This prevents flash write exhaustion.
Throughout this document we assume that the bootloader itself is
distinct from the role of the fw 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.
First, 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).
Second, an IoT device needs a recovery strategy in case the
firmware update / boot process fails.  The recovery strategy may
include storing two or more 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 a limited version of
Bluetooth Smart.  In the latter case the fw consumer functionality
is contained in the second stage bootloader and requires the
necessary functionality for executing the firmware update process,
including manifest parsing.
In general, it is assumed that the bootloader itself, or a minimal
part of it, will not be updated since a failed update of the
bootloader poses a risk in reliability.
All information necessary for a device to make a decision about the
installation of a firmware update must fit into the available RAM of
a constrained IoT device.  This prevents flash write exhaustion.
This is typically not a difficult requirement to accomplish because
there are not other task/processing running while the bootloader is
active (unlike it may be the case when running the application
firmware).
Client-initiated updates take the form of a communicator on a device
proactively checking for new firmware imagines provided by firmware
servers.
Server-initiated updates are important to consider because timing of
updates may need to be tightly controlled in some high- reliability
environments.  In this case the communicator, potentially in
coordination with the status tracker, determines what devices qualify
for a firmware update.  Once those devices have been selected the
firmware server distributes updates to those devices.
Note: This assumes that the firmware server is able to reach the
device, which may require devices to keep reachability information at
the communicator and / or at the firmware server up-to-date.  This
may also require keeping state at NATs and stateful packet filtering
firewalls alive.
Hybrid updates are those that require an interaction between the
device and the firmware server / communicator.  The communicator
pushes notifications of availability of an update to the device, and
the device then downloads the image from the firmware server when it
wants.
Client-initiated updates take the form of a firmware consumer on a
device proactively checking (polling) for new firmware images.
Server-initiated updates are important to consider because timing of
updates may need to be tightly controlled in some high- reliability
environments.  In this case the status tracker determines what
devices qualify for a firmware update.  Once those devices have been
selected the firmware server distributes updates to the firmware
consumers.
Note: This assumes that the status tracker is able to reach the
device, which may require devices to keep reachability information at
the status tracker up-to-date.  This may also require keeping state
at NATs and stateful packet filtering firewalls alive.
Hybrid updates are those that require an interaction between the
firmware consumer and the status tracker.  The status tracker pushes
notifications of availability of an update to the firmware consumer,
and it then downloads the image from a firmware server as soon as
possible.
The notification step consists of the communicator informing the
device that an update is available.  This can be accomplished via
polling (client-initiated), push notifications (server-initiated), or
more complex mechanisms.
The pre-authorisation step involves verifying whether the entity
signing the manifest is indeed authorized to perform an update.  The
device must also determine whether it should fetching and processing
of the firmware image (unless it has been attached already to the
manifest itself).
The notification step consists of the status tracker informing the
firmware consumer that an update is available.  This can be
accomplished via polling (client-initiated), push notifications
(server-initiated), or more complex mechanisms.
The pre-authorisation step involves verifying whether the entity
signing the manifest is indeed authorized to perform an update.  The
firmware consumer must also determine whether it should fetch and
process a firmware image, which is referenced in a manifest.
The download step is the process of acquiring a local copy of the
firmware image.  When the download is client-initiated, this means
that the device chooses when a download occurs and initiates the
download process.  When a download is server-party initiated, this
means that either the communicator / firmware server tells the device
when to download or that it initiates the transfer directly to the
device.  For example, a download from an HTTP-based firmware server
is client-initiated.  A transfer to a LwM2M Firmware Update resource
LwM2M is server-initiated.
If the Device has downloaded a new firmware image and is ready to
install it it may need to wait for a trigger from a Communicator to
install the firmware update, may trigger the update automatically, or
may go through a more complex decision making process to determine
the appropriate timing for an update (such as delaying the update
process to a later time when end users are less impacted by the
update process).
The download step is the process of acquiring a local copy of the
firmware image.  When the download is client-initiated, this means
that the firmware consumer chooses when a download occurs and
initiates the download process.  When a download is server-initiated,
this means that the status tracker tells the device when to download
or that it initiates the transfer directly to the firmware consumer.
For example, a download from an HTTP-based firmware server is client-
initiated.  Pushing a manifest and firmware image to the transfer to
the Package resource of the LwM2M Firmware Update object LwM2M is
server-initiated.
If the firmware consumer has downloaded a new firmware image and is
ready to install it, it may need to wait for a trigger from the
status tracker to initiate the installation, may trigger the update
automatically, or may go through a more complex decision making
process to determine the appropriate timing for an update (such as
delaying the update process to a later time when end users are less
impacted by the update process).
The work on a standardized manifest format initially focused on the
most constrained IoT devices and those devices contain code put
together by a single author (although that author may obtain code
from other developers, some of it only in binary form).
Later it turns out that other use cases may benefit from a
standardized manifest format also for conveying software and even
personalization data alongside software.  Trusted Execution
Environments (TEEs), for example, greatly 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 be conveyed to the TEE.
To support this wider range of use cases the manifest format should
therefore be extensible to convey other forms of payloads as well.
arch-figure shows the communication architecture where a firmware
image is created by an author, and uploaded to a firmware server.
The firmware image/manifest is distributed to the device either in a
push or pull manner using the communicator residing on the device.
The device operator keeps track of the process using the status
tracker.  This allows the device operator to know and control what
devices have received an update and which of them are still pending
an update.
arch-figure shows the communication architecture where a firmware
image is created by an author, and uploaded to a firmware server.
The firmware image/manifest is distributed to the device either in a
push or pull manner using the firmware consumer residing on the
device.  The device operator keeps track of the process using the
status tracker.  This allows the device operator to know and control
what devices have received an update and which of them are still
pending an update.
There is an option for embedding a firmware image into a manifest.
This is a useful approach for deployments where devices are not
connected to the Internet and cannot contact a dedicated server for
download of the firmware.  It is also applicable when the firmware
update happens via a USB stick or via Bluetooth Smart. attached-
firmware-figure shows this delivery mode graphically.
There is an option for embedding a firmware image into a manifest.
This is a useful approach for deployments where devices are not
connected to the Internet and cannot contact a dedicated firmware
server for the firmware download.  It is also applicable when the
firmware update happens via a USB stick or via Bluetooth Smart.
attached-firmware-figure shows this delivery mode graphically.
The following example message flow illustrates the interaction for
distributing a firmware image to a device starting with an author
uploading the new firmware to Firmware Server and creating a
manifest.  The firmware and manifest are stored on the same Firmware
Server.
the Internet protocol stack for (possibly large) firmware
downloads,
the capability to write the received firmware image to persistent
storage (most likely flash memory) prior to performing the update,
the ability to unpack, decompress or otherwise process the
received firmware image,
the features to verify an image and a manifest, including digital
signature verification or checking a message authentication code,
integration of the device into a device management server to
perform automatic firmware updates and to track their progress.
All these features are most likely offered by the application, i.e.
firmware consumer, running on the device (except for basic security
algorithms that may run either on a trusted execution environment or
on a separate hardware security MCU/module) rather than by the
bootloader itself.
Once manifests have been processed and firmware images successfully
downloaded and verified the device 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 takes over control
and determines whether the newly downloaded firmware image should be
executed.
The boot process is security sensitive because the firmware images
may, for example, be stored in off-chip flash memory giving attackers
easy access to the image for reverse engineering and potentially also
for modifying the binary.  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 happened when the firmware image and the
manifest were downloaded.
The manifest may have been stored alongside the firmware image to
allow re-verification of the firmware image during every boot
attempt.  Alternatively, secure boot-specific meta-data may have been
created by the application after a successful firmware download and
verification process.  Whether to re-use the standardized manifest
format that was used during the initial firmware retrieval process or
whether it is better to use a different format for the secure boot-
specific meta-data depends on the system design.  The manifest format
does, however, have the capability to serve also as a building block
for secure boot with its severable elements that allow shrinking the
size of the manifest by stripping elements that are no longer needed.
If the application image contains the firmware consumer
functionality, as described above, then it is necessary that a
working image is left on the device to ensure that the bootloader can
roll back to a working firmware image to re-do the firmware download
since the bootloader itself does not have enough functionality to
fetch a firmware image plus manifest from a firmware server over the
Internet.  A multi-stage bootloader may soften this requirement at
the expense of a more sophisticated boot process.
ability to access security algorithms, such as SHA-256 to compute
a fingerprint over the firmware image and a digital signature
algorithm.
access keying material directly or indirectly to utilize the
digital signature.  The device needs to have a trust anchor store.
ability to expose boot process-related data to the application
firmware (such as to the device management software).  This allows
a device management server to determine whether the firmware
update has been successful and, if not, what errors occurred.
to (optionally) offer attestation information (such as
measurements).
While the software architecture of the bootloader and its security
mechanisms are implementation-specific, the manifest can be used to
control the firmware download from the Internet in addition to
augmenting secure boot process.  These building blocks are highly
relevant for the design of the manifest.
firmware-update illustrates an example message flow for distributing
a firmware image to a device starting with an author uploading the
new firmware to firmware server and creating a manifest.  The
firmware and manifest are stored on the same firmware server.  This
setup does not use a status tracker and the firmware consumer
component is therefore responsible for periodically checking whether
a new firmware image is available for download.
firmware-update2 shows an example follow with the device using a
status tracker.  For editorial reasons the author publishing the
manifest at the status tracker and the firmware image at the firmware
server is not shown.  Also omitted is the secure boot process
following the successful firmware update process.
The exchange starts with the device interacting with the status
tracker; the details of such exchange will vary with the different
device management systems being used.  In any case, the status
tracker learns about the firmware version of the devices it manages.
In our example, the device under management is using firmware version
A.B.C.  At a later point in time the author uploads a new firmware
along with the manifest to the firmware server and the status
tracker, respectively.  While there is no need to store the manifest
and the firmware on different servers this example shows a common
pattern used in the industry.  The status tracker may then
automatically, based on human intervention or based on a more complex
policy decide to inform the device about the newly available firmware
image.  In our example, it does so by pushing the manifest to the FW
consumer.  The firmware consumer downloads the firmware image with
the newer version X.Y.Z after successful validation of the manifest.
Subsequently, a reboot is initiated and the secure boot process
starts.