< draft-ietf-suit-architecture-13.txt   draft-ietf-suit-architecture-14.txt >
SUIT B. Moran SUIT B. Moran
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Intended status: Informational Arm Limited Intended status: Informational Arm Limited
Expires: April 19, 2021 D. Brown Expires: April 24, 2021 D. Brown
Linaro Linaro
M. Meriac M. Meriac
Consultant Consultant
October 16, 2020 October 21, 2020
A Firmware Update Architecture for Internet of Things A Firmware Update Architecture for Internet of Things
draft-ietf-suit-architecture-13 draft-ietf-suit-architecture-14
Abstract Abstract
Vulnerabilities with Internet of Things (IoT) devices have raised the Vulnerabilities in Internet of Things (IoT) devices have raised the
need for a reliable and secure firmware update mechanism suitable for need for a reliable and secure firmware update mechanism suitable for
devices with resource constraints. Incorporating such an update devices with resource constraints. Incorporating such an update
mechanism is a fundamental requirement for fixing vulnerabilities but mechanism is a fundamental requirement for fixing vulnerabilities but
it also enables other important capabilities such as updating it also enables other important capabilities such as updating
configuration settings as well as adding new functionality. configuration settings as well as adding new functionality.
In addition to the definition of terminology and an architecture this In addition to the definition of terminology and an architecture this
document motivates the standardization of a manifest format as a document motivates the standardization of a manifest format as a
transport-agnostic means for describing and protecting firmware transport-agnostic means for describing and protecting firmware
updates. updates.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2021. This Internet-Draft will expire on April 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
5.3. Symmetric Multiple CPUs . . . . . . . . . . . . . . . . . 16 5.3. Symmetric Multiple CPUs . . . . . . . . . . . . . . . . . 16
5.4. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 16 5.4. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 16
5.5. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 17 5.5. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 17
6. Manifests . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Manifests . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Securing Firmware Updates . . . . . . . . . . . . . . . . . . 19 7. Securing Firmware Updates . . . . . . . . . . . . . . . . . . 19
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
12. Informative References . . . . . . . . . . . . . . . . . . . 26 12. Informative References . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Firmware updates can help to fix security vulnerabilities and are Firmware updates can help to fix security vulnerabilities and are
considered to be an important building block in securing IoT devices. considered to be an important building block in securing IoT devices.
Due to rising concerns about insecure IoT devices the Internet Due to rising concerns about insecure IoT devices the Internet
Architecture Board (IAB) organized a 'Workshop on Internet of Things Architecture Board (IAB) organized a 'Workshop on Internet of Things
(IoT) Software Update (IOTSU)', which took place at Trinity College (IoT) Software Update (IOTSU)', which took place at Trinity College
Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at
the bigger picture. A report about this workshop can be found at the bigger picture. A report about this workshop can be found at
skipping to change at page 3, line 17 skipping to change at page 3, line 17
Internet of Things (SUIT) working group. Internet of Things (SUIT) working group.
Developing secure Internet of Things (IoT) devices is not an easy Developing secure Internet of Things (IoT) devices is not an easy
task and supporting a firmware update solution requires skillful task and supporting a firmware update solution requires skillful
engineers. Once devices are deployed, firmware updates play a engineers. Once devices are deployed, firmware updates play a
critical part in their lifecycle management, particularly when critical part in their lifecycle management, particularly when
devices have a long lifetime, or are deployed in remote or devices have a long lifetime, or are deployed in remote or
inaccessible areas where manual intervention is cost prohibitive or inaccessible areas where manual intervention is cost prohibitive or
otherwise difficult. Firmware updates otherwise difficult. Firmware updates
for IoT devices are expected to work automatically, i.e. without user for IoT devices are expected to work automatically, i.e. without user
involvement. Automatic updates that do not require human involvement. Conversely, IoT devices are expected to account for
intervention are key to a scalable solution for fixing software user preferences and consent when scheduling updates. Automatic
vulnerabilities. updates that do not require human intervention are key to a scalable
solution for fixing software vulnerabilities.
Firmware updates are not only done to fix bugs, but they can also add Firmware updates are not only done to fix bugs, but they can also add
new functionality, and re-configure the device to work in new new functionality, and re-configure the device to work in new
environments or to behave differently in an already deployed context. environments or to behave differently in an already deployed context.
The firmware update process has to ensure that The firmware update process has to ensure that
- The firmware image is authenticated and integrity protected. - The firmware image is authenticated and integrity protected.
Attempts to flash a maliciously modified firmware image or an Attempts to flash a maliciously modified firmware image or an
image from an unknown, untrusted source must be prevented. In image from an unknown, untrusted source must be prevented. In
skipping to change at page 3, line 49 skipping to change at page 3, line 50
the adversary valuable insights into the software libraries used, the adversary valuable insights into the software libraries used,
configuration settings and generic functionality. Even though configuration settings and generic functionality. Even though
reverse engineering the binary can be a tedious process modern reverse engineering the binary can be a tedious process modern
reverse engineering frameworks have made this task a lot easier. reverse engineering frameworks have made this task a lot easier.
While the standardization work has been informed by and optimized for While the standardization work has been informed by and optimized for
firmware update use cases of Class 1 devices (according to the device firmware update use cases of Class 1 devices (according to the device
class definitions in RFC 7228 [RFC7228]) devices, there is nothing in class definitions in RFC 7228 [RFC7228]) devices, there is nothing in
the architecture that restricts its use to only these constrained IoT the architecture that restricts its use to only these constrained IoT
devices. Moreover, this architecture is not limited to managing devices. Moreover, this architecture is not limited to managing
software updates, but can also be applied to managing the delivery of firmware and software updates, but can also be applied to managing
arbitrary data, such as configuration information and keys. Unlike the delivery of arbitrary data, such as configuration information and
higher end devices, like laptops and desktop PCs, many IoT devices do keys. Unlike higher end devices, like laptops and desktop PCs, many
not have user interfaces and support for unattended updates is, IoT devices do not have user interfaces and support for unattended
therefore, essential for the design of a practical solution. updates is, therefore, essential for the design of a practical
Constrained IoT devices often use a software engineering model where solution. Constrained IoT devices often use a software engineering
a developer is responsible for creating and compiling all software model where a developer is responsible for creating and compiling all
running on the device into a single, monolithic firmware image. On software running on the device into a single, monolithic firmware
higher end devices application software is, on the other hand, often image. On higher end devices application software is, on the other
downloaded separately and even obtained from developers different to hand, often downloaded separately and even obtained from developers
the developers of the lower level software. The details for how to different to the developers of the lower level software. The details
obtain those application layer software binaries then depends heavily for how to obtain those application layer software binaries then
on the platform, programming language uses and the sandbox the depends heavily on the platform, programming language used and the
software is executed in. sandbox in which the software is executed.
While the IETF standardization work has been focused on the manifest While the IETF standardization work has been focused on the manifest
format, a fully interoperable solution needs more than a standardized format, a fully interoperable solution needs more than a standardized
manifest. For example, protocols for transferring firmware images manifest. For example, protocols for transferring firmware images
and manifests to the device need to be available as well as the and manifests to the device need to be available as well as the
status tracker functionality. Devices also require a mechanism to status tracker functionality. Devices also require a mechanism to
discover the status tracker(s) and/or firmware servers. These discover the status tracker(s) and/or firmware servers, for example
building blocks have been developed by various organizations under using pre-configured hostnames or [RFC6763] DNS-SD. These building
the umbrella of an IoT device management solution. The LwM2M blocks have been developed by various organizations under the
protocol is one IoT device management protocol. umbrella of an IoT device management solution. The LwM2M protocol is
one IoT device management protocol.
There are, however, several areas that (partially) fall outside the There are, however, several areas that (partially) fall outside the
scope of the IETF and other standards organizations but need to be scope of the IETF and other standards organizations but need to be
considered by firmware authors, as well as device and network considered by firmware authors, as well as device and network
operators. Here are some of them, as highlighted during the IOTSU operators. Here are some of them, as highlighted during the IOTSU
workshop: workshop:
- Installing firmware updates in a robust fashion so that the update - Installing firmware updates in a robust fashion so that the update
does not break the device functionality of the environment this does not break the device functionality of the environment this
device operates in. This requires proper testing and offering device operates in. This requires proper testing and offering
recovery strategies when a firmware update is unsuccessful. recovery strategies when a firmware update is unsuccessful.
- Making firmware updates available in a timely fashion considering - Making firmware updates available in a timely fashion considering
the complexity of the decision making process for updating the complexity of the decision making process for updating
devices, potential re-certification requirements, the length of a devices, potential re-certification requirements, the length of a
supply chain an update needs to go through before it reaches the supply chain an update needs to go through before it reaches the
end customer, and the need for user consent to install updates. end customer, and the need for user consent to install updates.
- Ensuring an energy efficient design of a battery-powered IoT - Ensuring an energy efficient design of a battery-powered IoT
devices because a firmware update, particularly writing the device because a firmware update, particularly radio communication
firmware image to flash, is a heavy task for a device. and writing the firmware image to flash, is an energy-intensive
task for a device.
- Creating incentives for device operators to use a firmware update - Creating incentives for device operators to use a firmware update
mechanism and to demand the integration of it from IoT device mechanism and to demand the integration of it from IoT device
vendors. vendors.
- Ensuring that firmware updates addressing critical flaws can be - Ensuring that firmware updates addressing critical flaws can be
obtained even after a product is discontinued or a vendor goes out obtained even after a product is discontinued or a vendor goes out
of business. of business.
This document starts with a terminology followed by the description This document starts with a terminology followed by the description
skipping to change at page 6, line 8 skipping to change at page 6, line 13
some bus on a single chip. The term 'system on chip (SoC)' is some bus on a single chip. The term 'system on chip (SoC)' is
often used interchangeably with MCU, but MCU tends to imply more often used interchangeably with MCU, but MCU tends to imply more
limited peripheral functions. limited peripheral functions.
- Rich Execution Environment (REE): An environment that is provided - Rich Execution Environment (REE): An environment that is provided
and governed by a typical OS (e.g., Linux, Windows, Android, iOS), and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
potentially in conjunction with other supporting operating systems potentially in conjunction with other supporting operating systems
and hypervisors; it is outside of the TEE. This environment and and hypervisors; it is outside of the TEE. This environment and
applications running on it are considered un-trusted. applications running on it are considered un-trusted.
- Software: Similar to firmware, but typically dynamically loaded by
an Operating System. Used interchangeably with firmware in this
document.
- System on Chip (SoC): An SoC is an integrated circuit that - System on Chip (SoC): An SoC is an integrated circuit that
contains all components of a computer, such as CPU, memory, input/ contains all components of a computer, such as CPU, memory, input/
output ports, secondary storage, a bus to connect the components, output ports, secondary storage, a bus to connect the components,
and other hardware blocks of logic. and other hardware blocks of logic.
- Trust Anchor: A trust anchor, as defined in [RFC6024], represents - Trust Anchor: A trust anchor, as defined in [RFC6024], represents
an authoritative entity via a public key and associated data. The an authoritative entity via a public key and associated data. The
public key is used to verify digital signatures, and the public key is used to verify digital signatures, and the
associated data is used to constrain the types of information for associated data is used to constrain the types of information for
which the trust anchor is authoritative." which the trust anchor is authoritative."
skipping to change at page 7, line 6 skipping to change at page 7, line 15
- Device Operator: The device operator is responsible for the day- - Device Operator: The device operator is responsible for the day-
to-day operation of a fleet of IoT devices. Customers of IoT to-day operation of a fleet of IoT devices. Customers of IoT
devices, as the owners of IoT devices - such as enterprise devices, as the owners of IoT devices - such as enterprise
customers or end users, interact with their IoT devices indirectly customers or end users, interact with their IoT devices indirectly
through the device operator via web or smart phone apps. through the device operator via web or smart phone apps.
- Network Operator: The network operator is responsible for the - Network Operator: The network operator is responsible for the
operation of a network to which IoT devices connect. operation of a network to which IoT devices connect.
- Trust Provisioning Authority (TPA): The TPA distributes trust - Trust Provisioning Authority (TPA): The TPA distributes trust
anchors and authorization policies to various stakeholders. The anchors and authorization policies to devices and various
TPA may also delegate rights to stakeholders. For example, in stakeholders. The TPA may also delegate rights to stakeholders.
some cases, the Original Design Manufacturer (ODM), which is a Typically, the Original Equipment Manufacturer (OEM) or Original
company that designs and manufactures a product, may act as a TPA Design Manufacturer (ODM) will act as a TPA, however complex
and may decide to remain in full control over the firmware update 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. 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.
2.3. Functions 2.3. Functions
- (IoT) Device: A device refers to the entire IoT product, which - (IoT) Device: A device refers to the entire IoT product, which
consists of one or many MCUs, sensors and/or actuators. Many IoT consists of one or many MCUs, sensors and/or actuators. Many IoT
devices sold today contain multiple MCUs and therefore a single devices sold today contain multiple MCUs and therefore a single
device may need to obtain more than one firmware image and device may need to obtain more than one firmware image and
manifest to successfully perform an update. manifest to successfully perform an update.
- Status Tracker: The status tracker has a client and a server - Status Tracker: The status tracker has a client and a server
component and performs three tasks: 1) It communicates the component and performs three tasks: 1) It communicates the
skipping to change at page 7, line 43 skipping to change at page 8, line 9
about available flash memory. Once an update has been triggered, about available flash memory. Once an update has been triggered,
the device operator may want to obtain information about the state the device operator may want to obtain information about the state
of the firmware update. If errors occurred, the device operator of the firmware update. If errors occurred, the device operator
may want to troubleshoot problems by first obtaining diagnostic may want to troubleshoot problems by first obtaining diagnostic
information (typically using a device management protocol). information (typically using a device management protocol).
We make no assumptions about where the server-side component is We make no assumptions about where the server-side component is
deployed. The deployment of status trackers is flexible and may deployed. The deployment of status trackers is flexible and may
be found at be found at
cloud-based servers, on-premise servers, or may be embedded in cloud-based servers, on-premise servers, or may be embedded in
edge computing device. A status tracker server component may even edge computing devices. A status tracker server component may
be deployed on an IoT device. For example, if the IoT device 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 contains multiple MCUs, then the main MCU may act as a status
tracker towards the other MCUs. Such deployment is useful when tracker towards the other MCUs. Such deployment is useful when
updates have to be synchronized across MCUs. updates have to be synchronized across MCUs.
The status tracker may be operated by any suitable stakeholder; The status tracker may be operated by any suitable stakeholder;
typically the Author, Device Operator, or Network Operator. typically the Author, Device Operator, or Network Operator.
- Firmware Consumer: The firmware consumer is the recipient of the - Firmware Consumer: The firmware consumer is the recipient of the
firmware image and the manifest. It is responsible for parsing firmware image and the manifest. It is responsible for parsing
and verifying the received manifest and for storing the obtained and verifying the received manifest and for storing the obtained
skipping to change at page 8, line 31 skipping to change at page 8, line 44
- Bootloader: A bootloader is a piece of software that is executed - Bootloader: A bootloader is a piece of software that is executed
once a microcontroller has been reset. It is responsible for once a microcontroller has been reset. It is responsible for
deciding what code to execute. deciding what code to execute.
3. Architecture 3. Architecture
More devices today than ever before are connected to the Internet, More devices today than ever before are connected to the Internet,
which drives the need for firmware updates to be provided over the which drives the need for firmware updates to be provided over the
Internet rather than through traditional interfaces, such as USB or Internet rather than through traditional interfaces, such as USB or
RS-232. Updating updates over the Internet requires the device to RS-232. Sending updates over the Internet requires the device to
fetch the new firmware image as well as the manifest. fetch the new firmware image as well as the manifest.
Hence, the following components are necessary on a device for a Hence, the following components are necessary on a device for a
firmware update solution: firmware update solution:
- the Internet protocol stack for firmware downloads. Because - the Internet protocol stack for firmware downloads. Because
firmware images are often multiple kilobytes, sometimes exceeding firmware images are often multiple kilobytes, sometimes exceeding
one hundred kilobytes, in size for low end IoT devices and even one hundred kilobytes, in size for low end IoT devices and even
several megabytes large for IoT devices running full-fledged several megabytes large for IoT devices running full-fledged
operating systems like Linux, the protocol mechanism for operating systems like Linux, the protocol mechanism for
skipping to change at page 9, line 8 skipping to change at page 9, line 19
- the capability to write the received firmware image to persistent - the capability to write the received firmware image to persistent
storage (most likely flash memory). storage (most likely flash memory).
- a manifest parser with code to verify a digital signature or a - a manifest parser with code to verify a digital signature or a
message authentication code. message authentication code.
- the ability to unpack, to decompress and/or to decrypt the - the ability to unpack, to decompress and/or to decrypt the
received firmware image. received firmware image.
- (optionally) a status tracker. - a status tracker.
The features listed above are most likely offered by code in the The features listed above are most likely offered by code in the
application firmware image running on the device rather than by the application firmware image running on the device rather than by the
bootloader itself. Note that cryptographic algorithms will likely bootloader itself. Note that cryptographic algorithms will likely
run in a trusted execution environment, on a separate MCU, in a run in a trusted execution environment, on a separate MCU, in a
hardware security module, or in a secure element rather than in the hardware security module, or in a secure element rather than in the
same context with the application code. same context with the application code.
Figure 1 shows the architecture where a firmware image is created by Figure 1 shows the architecture where a firmware image is created by
an author, and made available to a firmware server. For security an author, and made available to a firmware server. For security
reasons, the author will not have the permissions to upload firmware reasons, the author will not have the permissions to upload firmware
images to the firmware server and to initiate an update him- or images to the firmware server and to initiate an update him- or
herself. Instead, authors will make firmware images available to the herself. Instead, authors will make firmware images available to the
device operators. Note that there may be a longer supply chain device operators. Note that there may be a longer supply chain
involved to pass software updates from the author all the way to the involved to pass software updates from the author all the way to the
party that can then finally make a decision to deploy it with IoT party that can then finally make a decision to deploy it with IoT
devices. devices.
As a first step in the firmware update process, the status tracker As a first step in the firmware update process, the status tracker
client need to be made aware of the availability of a new firmware client needs to be made aware of the availability of a new firmware
update by the status tracker server. This can be accomplished via update by the status tracker server. This can be accomplished via
polling (client-initiated), push notifications (server-initiated), or polling (client-initiated), push notifications (server-initiated), or
more complex mechanisms (such as a hybrid approach): more complex mechanisms (such as a hybrid approach):
- Client-initiated updates take the form of a status tracker client - Client-initiated updates take the form of a status tracker client
proactively checking (polling) for updates. proactively checking (polling) for updates.
- With Server-initiated updates the server-side component of the - With Server-initiated updates the server-side component of the
status tracker learns about a new firmware version and determines status tracker learns about a new firmware version and determines
what devices qualify for a firmware update. Once the relevant which devices qualify for a firmware update. Once the relevant
devices have been selected, the status tracker informs these devices have been selected, the status tracker informs these
devices and the firmware consumers obtain those images and devices and the firmware consumers obtain those images and
manifests. Server-initiated updates are important because they manifests. Server-initiated updates are important because they
allow a quick response time. Note that the client-side status allow a quick response time. Note that the client-side status
tracker needs to be reachable by the server-side component. This tracker needs to be reachable by the server-side component. This
may require devices to keep reachability information on the may require devices to keep reachability information on the
server-side up-to-date and state at NATs and stateful packet server-side up-to-date and state at NATs and stateful packet
filtering firewalls alive. filtering firewalls alive.
- Using a hybrid approach the server-side of the status tracker - Using a hybrid approach the server-side of the status tracker
skipping to change at page 14, line 21 skipping to change at page 14, line 21
considerations, particularly when the bootloader implements the considerations, particularly when the bootloader implements the
robustness requirements identified by the IOTSU workshop [RFC8240]. robustness requirements identified by the IOTSU workshop [RFC8240].
4.1. The Bootloader 4.1. The Bootloader
In most cases the MCU must restart in order to hand over control to 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 the bootloader. Once the MCU has initiated a restart, the bootloader
determines whether a newly available firmware image should be determines whether a newly available firmware image should be
executed. If the bootloader concludes that the newly available executed. If the bootloader concludes that the newly available
firmware image is invalid, a recovery strategy is necessary. There firmware image is invalid, a recovery strategy is necessary. There
are only two approaches recovering from an invalid firmware: either are only two approaches for recovering from an invalid firmware:
the bootloader must be able to select a different, valid firmware, or either the bootloader must be able to select a different, valid
it must be able to obtain a new, valid firmware. Both of these firmware, or it must be able to obtain a new, valid firmware. Both
approaches have implications for the architecture of the update of these approaches have implications for the architecture of the
system. update system.
Assuming the first approach, there are (at least) three firmware Assuming the first approach, there are (at least) three firmware
images available on the device: images available on the device:
- First, the bootloader is also firmware. If a bootloader is - First, the bootloader is also firmware. If a bootloader is
updatable then its firmware image is treated like any other updatable then its firmware image is treated like any other
application firmware image. application firmware image.
- Second, the firmware image that has to be replaced is still - Second, the firmware image that has to be replaced is still
available on the device as a backup in case the freshly downloaded available on the device as a backup in case the freshly downloaded
skipping to change at page 14, line 48 skipping to change at page 14, line 48
- Third, there is the newly downloaded firmware image. - Third, there is the newly downloaded firmware image.
Therefore, the firmware consumer must know where to store the new Therefore, the firmware consumer must know where to store the new
firmware. In some cases, this may be implicit, for example replacing firmware. In some cases, this may be implicit, for example replacing
the least-recently-used firmware image. In other cases, the storage the least-recently-used firmware image. In other cases, the storage
location of the new firmware must be explicit, for example when a location of the new firmware must be explicit, for example when a
device has one or more application firmware images and a recovery device has one or more application firmware images and a recovery
image with limited functionality, sufficient only to perform an image with limited functionality, sufficient only to perform an
update. update.
Since many low end IoT devices use non-relocatable code, either the Since many low end IoT devices do not use position-independent code,
bootloader needs to copy the newly downloaded application firmware either the bootloader needs to copy the newly downloaded application
image into the location of the old application firmware image and firmware image into the location of the old application firmware
vice versa or multiple versions of the firmware need to be prepared image and vice versa or multiple versions of the firmware need to be
for different locations. prepared for different locations.
In general, it is assumed that the bootloader itself, or a minimal 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 part of it, will not be updated since a failed update of the
bootloader poses a reliability risk. bootloader poses a reliability risk.
For a bootloader to offer a secure boot functionality it needs to For a bootloader to offer a secure boot functionality it needs to
implement the following functionality: implement the following functionality:
- The bootloader needs to fetch the manifest (or manifest-alike - The bootloader needs to fetch the manifest (or manifest-alike
headers) from nonvolatile storage and parse its contents for headers) from nonvolatile storage and parse its contents for
subsequent cryptographic verification. subsequent cryptographic verification.
- Cryptographic libraries with hash functions, digital signatures - Cryptographic libraries with hash functions, digital signatures
(for asymmetric crypto), keyed message digests (for symmetric (for asymmetric crypto), message authentication codes (for
crypto) need to be accessible. symmetric crypto) need to be accessible.
- The device needs to have a trust anchor store to verify the - The device needs to have a trust anchor store to verify the
digital signature. (Alternatively, access to a key store for use digital signature. (Alternatively, access to a key store for use
with the keyed message digest.) with the message authentication code.)
- Ability to expose boot process-related data to the application - Ability to expose boot process-related data to the application
firmware (such as to the status tracker). This allows to share firmware (such as to the status tracker). This allows to share
information about the current firmware version, and the status of information about the current firmware version, and the status of
the firmware update process and whether errors have occurred. the firmware update process and whether errors have occurred.
- Produce boot measurements as part of an attestation solution. See - Produce boot measurements as part of an attestation solution. See
[I-D.ietf-rats-architecture] for more information. (optional) [I-D.ietf-rats-architecture] for more information. (optional)
- Ability to decrypt firmware images, in case confidentiality - Ability to decrypt firmware images, in case confidentiality
protection was applied). This requires a solution for key protection was applied. This requires a solution for key
management. (optional) management. (optional)
5. Types of IoT Devices 5. Types of IoT Devices
There are billions of MCUs used in devices today produced by a large There are billions of MCUs used in devices today produced by a large
number of silicon manufacturers. While MCUs can vary significantly number of silicon manufacturers. While MCUs can vary significantly
in their characteristics, there are a number of similiaries allowing in their characteristics, there are a number of similiaries allowing
us to categorize in groups. us to categorize in groups.
The firmware update architecture, and the manifest format in The firmware update architecture, and the manifest format in
skipping to change at page 16, line 7 skipping to change at page 16, line 7
5.1. Single MCU 5.1. Single MCU
The simplest, and currently most common, architecture consists of a The simplest, and currently most common, architecture consists of a
single MCU along with its own peripherals. These SoCs generally single MCU along with its own peripherals. These SoCs generally
contain some amount of flash memory for code and fixed data, as well contain some amount of flash memory for code and fixed data, as well
as RAM for working storage. A notable characteristic of these SoCs as RAM for working storage. A notable characteristic of these SoCs
is that the primary code is generally execute in place (XIP). Due to 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 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 be placed in a specific location in flash since the code cannot be
executed from an arbitrary location in flash. Hence, then the executed from an arbitrary location in flash. Hence, when the
firmware image is updated it is necessary to swap the old and the new firmware image is updated it is necessary to swap the old and the new
image. image.
5.2. Single CPU with Secure - Normal Mode Partitioning 5.2. Single CPU with Secure - Normal Mode Partitioning
Another configuration consists of a similar architecture to the Another configuration consists of a similar architecture to the
previous, with a single CPU. However, this CPU supports a security previous, with a single CPU. However, this CPU supports a security
partitioning scheme that allows memory (in addition to other things) partitioning scheme that allows memory (in addition to other things)
to be divided into secure and normal mode. There will generally be to be divided into secure and normal mode. There will generally be
two images, one for secure mode, and one for normal mode. In this two images, one for secure mode, and one for normal mode. In this
skipping to change at page 18, line 51 skipping to change at page 18, line 51
control of the device. control of the device.
Keeping the code size and complexity of a manifest parsers small is Keeping the code size and complexity of a manifest parsers small is
important for constrained IoT devices. Since the manifest parsing important for constrained IoT devices. Since the manifest parsing
code may also be used by the bootloader it is part of the trusted code may also be used by the bootloader it is part of the trusted
computing base. computing base.
A manifest may not only be used to protect firmware images but also A manifest may not only be used to protect firmware images but also
configuration data such as network credentials or personalization configuration data such as network credentials or personalization
data related to firmware or software. Personalization data data related to firmware or software. Personalization data
demonstrates the need for mutually-distrustful delivery of two or demonstrates the need for confidentiality to be maintained between
more images into a device. Personalization data is used with Trusted two or more stakeholders that both deliver images to the same device.
Execution Environments (TEEs), which benefit from a protocol for
managing the lifecycle of trusted applications (TAs) running inside a Personalization data is used with Trusted Execution Environments
TEE. TEEs may obtain TAs from different authors and those TAs may (TEEs), which benefit from a protocol for managing the lifecycle of
require personalization data, such as payment information, to be trusted applications (TAs) running inside a TEE. TEEs may obtain TAs
securely conveyed to the TEE. The TA's author does not want to from different authors and those TAs may require personalization
expose the TA to the user, and the user does not want to expose the data, such as payment information, to be securely conveyed to the
payment information to the TA's author. 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.
7. Securing Firmware Updates 7. Securing Firmware Updates
Using firmware updates to fix vulnerabilities in devices is important Using firmware updates to fix vulnerabilities in devices is important
but securing this update mechanism is equally important since but securing this update mechanism is equally important since
security problems are exacerbated by the update mechanism: update is security problems are exacerbated by the update mechanism: update is
essentially authorized remote code execution, so any security essentially authorized remote code execution, so any security
problems in the update process expose that remote code execution problems in the update process expose that remote code execution
system. Failure to secure the firmware update process will help system. Failure to secure the firmware update process will help
attackers to take control over devices. attackers to take control over devices.
skipping to change at page 26, line 26 skipping to change at page 26, line 26
- Bob Briscoe - Bob Briscoe
- Roman Danyliw - Roman Danyliw
- Brian Carpenter - Brian Carpenter
- Theresa Enghardt - Theresa Enghardt
- Rich Salz - Rich Salz
- Mohit Sethi
We would also like to thank the WG chairs, Russ Housley, David We would also like to thank the WG chairs, Russ Housley, David
Waltermire, Dave Thaler for their support and their reviews. Waltermire, Dave Thaler for their support and their reviews.
12. Informative References 12. Informative References
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-06 (work in progress), draft-ietf-rats-architecture-06 (work in progress),
September 2020. September 2020.
skipping to change at page 27, line 18 skipping to change at page 27, line 18
Architecture", draft-ietf-teep-architecture-12 (work in Architecture", draft-ietf-teep-architecture-12 (work in
progress), July 2020. progress), July 2020.
[LwM2M] OMA, ., "Lightweight Machine to Machine Technical [LwM2M] OMA, ., "Lightweight Machine to Machine Technical
Specification, Version 1.0.2", February 2018, Specification, Version 1.0.2", February 2018,
<http://www.openmobilealliance.org/release/LightweightM2M/ <http://www.openmobilealliance.org/release/LightweightM2M/
V1_0_2-20180209-A/OMA-TS-LightweightM2M- V1_0_2-20180209-A/OMA-TS-LightweightM2M-
V1_0_2-20180209-A.pdf>. V1_0_2-20180209-A.pdf>.
[quantum-factorization] [quantum-factorization]
Department of Computer Science, Purdue University, ., Jiang, S., Britt, K., McCaskey, A., Humble, T., and S.
Quantum Computing Institute, Oak Ridge National Kais, "Quantum Annealing for Prime Factorization",
Laboratory, ., Quantum Computing Institute, Oak Ridge December 2018,
National Laboratory, ., Quantum Computing Institute, Oak
Ridge National Laboratory, ., and . Department of
Chemistry, Physics and Birck Nanotechnology Center, Purdue
University, "Quantum Annealing for Prime Factorization",
n.d.,
<https://www.nature.com/articles/s41598-018-36058-z>. <https://www.nature.com/articles/s41598-018-36058-z>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/info/rfc6024>. 2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet
of Things Software Update (IoTSU) Workshop 2016", of Things Software Update (IoTSU) Workshop 2016",
RFC 8240, DOI 10.17487/RFC8240, September 2017, RFC 8240, DOI 10.17487/RFC8240, September 2017,
<https://www.rfc-editor.org/info/rfc8240>. <https://www.rfc-editor.org/info/rfc8240>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8778] Housley, R., "Use of the HSS/LMS Hash-Based Signature [RFC8778] Housley, R., "Use of the HSS/LMS Hash-Based Signature
Algorithm with CBOR Object Signing and Encryption (COSE)", Algorithm with CBOR Object Signing and Encryption (COSE)",
RFC 8778, DOI 10.17487/RFC8778, April 2020, RFC 8778, DOI 10.17487/RFC8778, April 2020,
<https://www.rfc-editor.org/info/rfc8778>. <https://www.rfc-editor.org/info/rfc8778>.
Authors' Addresses Authors' Addresses
Brendan Moran Brendan Moran
Arm Limited Arm Limited
 End of changes. 30 change blocks. 
80 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/