< draft-ietf-suit-architecture-11.txt   draft-ietf-suit-architecture-12.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: November 28, 2020 D. Brown Expires: March 21, 2021 D. Brown
Linaro Linaro
M. Meriac M. Meriac
Consultant Consultant
May 27, 2020 September 17, 2020
A Firmware Update Architecture for Internet of Things A Firmware Update Architecture for Internet of Things
draft-ietf-suit-architecture-11 draft-ietf-suit-architecture-12
Abstract Abstract
Vulnerabilities with Internet of Things (IoT) devices have raised the Vulnerabilities with Internet of Things (IoT) devices have raised the
need for a solid and secure firmware update mechanism that is also need for a solid and secure firmware update mechanism that is also
suitable for constrained devices. Incorporating such update suitable for constrained devices. Incorporating such update
mechanism to fix vulnerabilities, to update configuration settings as mechanism to fix vulnerabilities, to update configuration settings as
well as adding new functionality is recommended by security experts. well as adding new functionality is recommended by security experts.
This document lists requirements and describes an architecture for a This document lists requirements and describes an architecture for a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 November 28, 2020. This Internet-Draft will expire on March 21, 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 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Agnostic to how firmware images are distributed . . . . . 7 3.1. Agnostic to how firmware images are distributed . . . . . 7
3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 7 3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 8
3.3. Use state-of-the-art security mechanisms . . . . . . . . 8 3.3. Use state-of-the-art security mechanisms . . . . . . . . 8
3.4. Rollback attacks must be prevented . . . . . . . . . . . 8 3.4. Rollback attacks must be prevented . . . . . . . . . . . 9
3.5. High reliability . . . . . . . . . . . . . . . . . . . . 8 3.5. High reliability . . . . . . . . . . . . . . . . . . . . 9
3.6. Operate with a small bootloader . . . . . . . . . . . . . 9 3.6. Operate with a small bootloader . . . . . . . . . . . . . 9
3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 10
3.8. Minimal impact on existing firmware formats . . . . . . . 10 3.8. Minimal impact on existing firmware formats . . . . . . . 10
3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 10 3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 10
3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 10 3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 11
3.11. Suitability to software and personalization data . . . . 12 3.11. Suitability to software and personalization data . . . . 13
4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Communication Architecture . . . . . . . . . . . . . . . . . 13 5. Communication Architecture . . . . . . . . . . . . . . . . . 14
6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Device Firmware Update Examples . . . . . . . . . . . . . . . 18 7. Device Firmware Update Examples . . . . . . . . . . . . . . . 19
7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 18 7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 19
7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 18 7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 19
7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 18 7.3. Symmetric Multiple CPUs . . . . . . . . . . . . . . . . . 19
7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 18 7.4. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 20
8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.5. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 20
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13. Informative References . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 13. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
When developing Internet of Things (IoT) devices, one of the most When developing Internet of Things (IoT) devices, one of the most
difficult problems to solve is how to update firmware on the device. difficult problems to solve is how to update firmware on the device.
Once the device is deployed, firmware updates play a critical part in Once the device is deployed, firmware updates play a critical part in
its lifetime, particularly when devices have a long lifetime, are its lifetime, particularly when devices have a long lifetime, are
deployed in remote or inaccessible areas where manual intervention is deployed in remote or inaccessible areas where manual intervention is
cost prohibitive or otherwise difficult. Updates to the firmware of cost prohibitive or otherwise difficult. Updates to the firmware of
an IoT device are done to fix bugs in software, to add new an IoT device are done to fix bugs in software, to add new
skipping to change at page 3, line 30 skipping to change at page 3, line 31
into used software libraries, configuration settings and generic into used software libraries, configuration settings and generic
functionality (even though reverse engineering the binary can be a functionality (even though reverse engineering the binary can be a
tedious process). tedious process).
This version of the document assumes asymmetric cryptography and a This version of the document assumes asymmetric cryptography and a
public key infrastructure. Future versions may also describe a public key infrastructure. Future versions may also describe a
symmetric key approach for very constrained devices. symmetric key approach for very constrained devices.
While the standardization work has been informed by and optimised for While the standardization work has been informed by and optimised 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]), there is nothing in the class definitions in RFC 7228 [RFC7228]) devices, there is nothing in
architecture that restricts its use to only these constrained IoT the architecture that restricts its use to only these constrained IoT
devices. Software update and delivery of arbitrary data, such as devices. Moreover, this architecture is not limited to managing
configuration information and keys, can equally be managed by software updates, but can also be applied to managing the delivery of
manifests. arbitrary data, such as configuration information and keys.
More details about the security goals are discussed in Section 5 and More details about the security goals are discussed in Section 5 and
requirements are described in Section 3. requirements are described in Section 3.
2. Conventions and Terminology 2. Conventions and Terminology
This document uses the following terms: This document uses the following terms:
- Manifest: The manifest contains meta-data about the firmware - Manifest: The manifest contains meta-data about the firmware
image. The manifest is protected against modification and image. The manifest is protected against modification and
skipping to change at page 5, line 12 skipping to change at page 5, line 15
- 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.
- Trusted applications (TAs): An application component that runs in - Trusted applications (TAs): An application component that runs in
a TEE. a TEE.
For more information about TEEs see [I-D.ietf-teep-architecture]. For more information about TEEs see [I-D.ietf-teep-architecture].
TEEP requires the use of SUIT for delivering TAs.
The following entities are used: The following entities are used:
- Author: The author is the entity that creates the firmware image. - Author: The author is the entity that creates the firmware image.
There may be multiple authors in a system either when a device There may be multiple authors in a system either when a device
consists of multiple micro-controllers or when the the final consists of multiple micro-controllers or when the the final
firmware image consists of software components from multiple firmware image consists of software components from multiple
companies. companies.
- Firmware Consumer: The firmware consumer is the recipient of the - Firmware Consumer: The firmware consumer is the recipient of the
skipping to change at page 5, line 47 skipping to change at page 5, line 51
- Status Tracker: The status tracker offers device management - Status Tracker: The status tracker offers device management
functionality to retrieve information about the installed firmware functionality to retrieve information about the installed firmware
on a device and other device characteristics (including free on a device and other device characteristics (including free
memory and hardware components), to obtain the state of the memory and hardware components), to obtain the state of the
firmware update cycle the device is currently in, and to trigger firmware update cycle the device is currently in, and to trigger
the update process. The deployment of status trackers is flexible the update process. The deployment of status trackers is flexible
and they may be used as cloud-based servers, on-premise servers, and they may be used as cloud-based servers, on-premise servers,
embedded in edge computing device (such as Internet access embedded in edge computing device (such as Internet access
gateways or protocol translation gateways), or even in smart gateways or protocol translation gateways), or even in smart
phones and tablets. While the IoT device itself runs the client- phones and tablets. IoT devices that self-initiate updates may
side of the status tracker it will most likely not run a status run a status tracker. Similarly, IoT devices that act as a proxy
tracker itself unless it acts as a proxy for other IoT devices in for other IoT devices in a protocol translation or edge computing
a protocol translation or edge computing device node. How much device node may also run a status tracker. However, if the device
functionality a status tracker includes depends on the selected contains multiple MCUs, the main MCU may act as a limited status
configuration of the device management functionality and the tracker towards the other MCUs if updates are to be synchronized
communication environment it is used in. In a generic networking across MCUs. How much functionality a status tracker includes
environment the protocol used between the client and the server- depends on the selected configuration of the device management
side of the status tracker need to deal with Internet functionality and the communication environment it is used in. In
communication challenges involving firewall and NAT traversal. In a generic networking environment the protocol used between the
other cases, the communication interaction may be rather simple. client and the server-side of the status tracker need to deal with
This architecture document does not impose requirements on the Internet communication challenges involving firewall and NAT
status tracker. 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 - Firmware Server: The firmware server stores firmware images and
manifests and distributes them to IoT devices. Some deployments manifests and distributes them to IoT devices. Some deployments
may require a store-and-forward concept, which requires storing may require a store-and-forward concept, which requires storing
the firmware images/manifests on more than one entity before the firmware images/manifests on more than one entity before
they reach the device. There is typically some interaction they reach the device. There is typically some interaction
between the firmware server and the status tracker but those between the firmware server and the status tracker but those
entities are often physically separated on different devices for entities are often physically separated on different devices for
scalability reasons. scalability reasons.
- Device Operator: The actor responsible for the day-to-day - Device Operator: The actor responsible for the day-to-day
operation of a fleet of IoT devices. operation of a fleet of IoT devices.
- Network Operator: The actor responsible for the operation of a - Network Operator: The actor responsible for the operation of a
network to which IoT devices connect. network to which IoT devices connect.
- Claim: A piece of information asserted about a recipient or
payload.
In addition to the entities in the list above there is an orthogonal In addition to the entities in the list above there is an orthogonal
infrastructure with a Trust Provisioning Authority (TPA) distributing infrastructure with a Trust Provisioning Authority (TPA) distributing
trust anchors and authorization permissions to various entities in trust anchors and authorization permissions to various entities in
the system. The TPA may also delegate rights to install, update, the system. The TPA may also delegate rights to install, update,
enhance, or delete trust anchors and authorization permissions to enhance, or delete trust anchors and authorization permissions to
other parties in the system. This infrastructure overlaps the other parties in the system. This infrastructure overlaps the
communication architecture and different deployments may empower communication architecture and different deployments may empower
certain entities while other deployments may not. For example, in certain entities while other deployments may not. For example, in
some cases, the Original Design Manufacturer (ODM), which is a some cases, the Original Design Manufacturer (ODM), which is a
company that designs and manufactures a product, may act as a TPA and company that designs and manufactures a product, may act as a TPA and
skipping to change at page 7, line 37 skipping to change at page 7, line 46
- Robust permissions - Robust permissions
- Diverse modes of operation - Diverse modes of operation
- Suitability to software and personalization data - Suitability to software and personalization data
3.1. Agnostic to how firmware images are distributed 3.1. Agnostic to how firmware images are distributed
Firmware images can be conveyed to devices in a variety of ways, Firmware images can be conveyed to devices in a variety of ways,
including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and
use different protocols (e.g., CoAP, HTTP). The specified mechanism use different protocols (e.g., CoAP, HTTP). The specified mechanism
needs to be agnostic to the distribution of the firmware images and needs to be agnostic to the distribution of the firmware images and
manifests. manifests.
3.2. Friendly to broadcast delivery 3.2. Friendly to broadcast delivery
This architecture does not specify any specific broadcast protocol. This architecture does not specify any specific broadcast protocol.
However, given that broadcast may be desirable for some networks, However, given that broadcast may be desirable for some networks,
updates must cause the least disruption possible both in metadata and updates must cause the least disruption possible both in metadata and
firmware transmission. firmware transmission.
skipping to change at page 8, line 49 skipping to change at page 9, line 15
3.4. Rollback attacks must be prevented 3.4. Rollback attacks must be prevented
A device presented with an old, but valid manifest and firmware must A device presented with an old, but valid manifest and firmware must
not be tricked into installing such firmware since a vulnerability in not be tricked into installing such firmware since a vulnerability in
the old firmware image may allow an attacker to gain control of the the old firmware image may allow an attacker to gain control of the
device. device.
3.5. High reliability 3.5. High reliability
A power failure at any time must not cause a failure of the device. A power failure at any time must not cause a failure of the device.
A failure to validate any part of an update must not cause a failure Equally, adverse network conditions during an update must not cause
of the device. One way to achieve this functionality is to provide a the failure of the device. A failure to validate any part of an
minimum of two storage locations for firmware and one bootable update must not cause a failure of the device. One way to achieve
location for firmware. An alternative approach is to use a 2nd stage this functionality is to provide a minimum of two storage locations
bootloader with build-in full featured firmware update functionality for firmware and one bootable location for firmware. An alternative
such that it is possible to return to the update process after power approach is to use a 2nd stage bootloader with build-in full featured
down. firmware update functionality such that it is possible to return to
the update process after power down.
Note: This is an implementation requirement rather than a requirement Note: This is an implementation requirement rather than a requirement
on the manifest format. on the manifest format.
3.6. Operate with a small bootloader 3.6. Operate with a small bootloader
Throughout this document we assume that the bootloader itself is Throughout this document we assume that the bootloader itself is
distinct from the role of the firmware consumer and therefore does distinct from the role of the firmware consumer and therefore does
not manage the firmware update process. This may give the impression not manage the firmware update process. This may give the impression
that the bootloader itself is a completely separate component, which that the bootloader itself is a completely separate component, which
skipping to change at page 10, line 11 skipping to change at page 10, line 25
a constrained IoT device. This prevents flash write exhaustion. a constrained IoT device. This prevents flash write exhaustion.
This is typically not a difficult requirement to accomplish because This is typically not a difficult requirement to accomplish because
there are not other task/processing running while the bootloader is there are not other task/processing running while the bootloader is
active (unlike it may be the case when running the application active (unlike it may be the case when running the application
firmware). firmware).
Note: This is an implementation requirement. Note: This is an implementation requirement.
3.7. Small Parsers 3.7. Small Parsers
Since parsers are known sources of bugs they must be minimal. Since parsers are known sources of bugs, any parsers used to process
Additionally, it must be easy to parse only those fields that are the manifest must be minimal. Additionally, it must be easy to parse
required to validate at least one signature or MAC with minimal only those fields that are required to validate at least one
exposure. signature or MAC with minimal exposure.
3.8. Minimal impact on existing firmware formats 3.8. Minimal impact on existing firmware formats
The design of the firmware update mechanism must not require changes The design of the firmware update mechanism must not require changes
to existing firmware formats. to existing firmware formats.
3.9. Robust permissions 3.9. Robust permissions
When a device obtains a monolithic firmware image from a single When a device obtains a monolithic firmware image from a single
author without any additional approval steps then the authorization author without any additional approval steps then the authorization
skipping to change at page 11, line 25 skipping to change at page 11, line 40
device, which may require devices to keep reachability information at device, which may require devices to keep reachability information at
the status tracker up-to-date. This may also require keeping state the status tracker up-to-date. This may also require keeping state
at NATs and stateful packet filtering firewalls alive. at NATs and stateful packet filtering firewalls alive.
Hybrid updates are those that require an interaction between the Hybrid updates are those that require an interaction between the
firmware consumer and the status tracker. The status tracker pushes firmware consumer and the status tracker. The status tracker pushes
notifications of availability of an update to the firmware consumer, notifications of availability of an update to the firmware consumer,
and it then downloads the image from a firmware server as soon as and it then downloads the image from a firmware server as soon as
possible. possible.
An alternative view to the operating modes is to consider the steps a While these broad classifications encompass the majority of operating
device has to go through in the course of an update: modes, some may not be covered in these classifications. By
reinterpreting these modes as a set of operations performed by the
system as a whole, all operating modes can be represented.
The steps performed in the course of an update by the system
containing an updatable device are:
- Notification - Notification
- Pre-authorisation - Pre-authorisation
- Dependency resolution - Dependency resolution
- Download - Download
- Installation - Installation
This is a coarse-grained high level view of steps required to install
a new firmware. By considering where in the system each of these
steps is performed, each operating mode can be represented. Each of
these steps is broken down into smaller constituent parts. Section 5
defines the steps taken from the perspective of the communication
between actors in the system. Section 8 describes some additional
steps that a bootloader takes in addition to those described here.
Section 9 shows an example of the steps undertaken by each party in
the course of an update.
The notification step consists of the status tracker informing the The notification step consists of the status tracker informing the
firmware consumer that an update is available. This can be firmware consumer that an update is available. This can be
accomplished via polling (client-initiated), push notifications accomplished via polling (client-initiated), push notifications
(server-initiated), or more complex mechanisms. (server-initiated), or more complex mechanisms.
The pre-authorisation step involves verifying whether the entity The pre-authorisation step involves verifying whether the entity
signing the manifest is indeed authorized to perform an update. The signing the manifest is indeed authorized to perform an update. The
firmware consumer must also determine whether it should fetch and firmware consumer must also determine whether it should fetch and
process a firmware image, which is referenced in a manifest. process a firmware image, which is referenced in a manifest.
skipping to change at page 13, line 7 skipping to change at page 13, line 32
managing the lifecycle of trusted applications (TAs) running inside a managing the lifecycle of trusted applications (TAs) running inside a
TEE. TEEs may obtain TAs from different authors and those TAs may TEE. TEEs may obtain TAs from different authors and those TAs may
require personalization data, such as payment information, to be require personalization data, such as payment information, to be
securely conveyed to the TEE. securely conveyed to the TEE.
To support this wider range of use cases the manifest format should To support this wider range of use cases the manifest format should
therefore be extensible to convey other forms of payloads as well. therefore be extensible to convey other forms of payloads as well.
4. Claims 4. Claims
Claims in the manifest offer a way to convey instructions to a device The information conveyed from an Author to a Firmware Consumer can be
that impact the firmware update process. To have any value the considered to be Claims as described in [RFC7519] and [RFC8392]. The
manifest containing those claims must be authenticated and integrity same security considerations apply to the Claims expressed in the
protected. The credential used must be directly or indirectly manifest. The chief difference between manifest Claims and CWT or
related to the trust anchor installed at the device by the Trust JWT claims is that a manifest has multiple subjects. The manifest
Provisioning Authority. contains:
The baseline claims for all manifests are described in
[I-D.ietf-suit-information-model]. For example, there are:
- Do not install firmware with earlier metadata than the current 1. Claims about the Firmware, including its dependencies
metadata.
- Only install firmware with a matching vendor, model, hardware 2. Claims about the Firmware Consumer's physical or software
revision, software version, etc. properties
- Only install firmware that is before its best-before timestamp. 3. Claims about the Author, or the Author's delegate
- Only allow a firmware installation if dependencies have been met. The credential used to authenticate these Claims must be directly or
indirectly related to the trust anchor installed at the device by the
Trust Provisioning Authority.
- Choose the mechanism to install the firmware, based on the type of The baseline claims for all manifests are described in
firmware it is. [I-D.ietf-suit-information-model].
5. Communication Architecture 5. Communication Architecture
Figure 1 shows the communication architecture where a firmware image Figure 1 shows the communication architecture where a firmware image
is created by an author, and uploaded to a firmware server. The is created by an author, and uploaded to a firmware server. The
firmware image/manifest is distributed to the device either in a push firmware image/manifest is distributed to the device either in a push
or pull manner using the firmware consumer residing on the device. or pull manner using the firmware consumer residing on the device.
The device operator keeps track of the process using the status The device operator keeps track of the process using the status
tracker. This allows the device operator to know and control what tracker. This allows the device operator to know and control what
devices have received an update and which of them are still pending devices have received an update and which of them are still pending
skipping to change at page 18, line 36 skipping to change at page 19, line 36
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
configuration, firmware upgrades will generally be done by the CPU in configuration, firmware upgrades will generally be done by the CPU in
secure mode, which is able to write to both areas of the flash secure mode, which is able to write to both areas of the flash
device. In addition, there are requirements to be able to update device. In addition, there are requirements to be able to update
either image independently, as well as to update them together either image independently, as well as to update them together
atomically, as specified in the associated manifests. atomically, as specified in the associated manifests.
7.3. Dual CPU, shared memory 7.3. Symmetric Multiple CPUs
This configuration has two or more CPUs in a single SoC that share In more complex SoCs with symmetric multi-processing support,
memory (flash and RAM). Generally, they will be a protection advanced operating systems, such as Linux, are often used. These
mechanism to prevent one CPU from accessing the other's memory. SoCs frequently use an external storage medium such as raw NAND flash
Upgrades in this case will typically be done by one of the CPUs, and or eMMC. Due to the higher quantity of resources, these devices are
is similar to the single CPU with secure mode. often capable of storing multiple copies of their firmware images and
selecting the most appropriate one to boot. Many SoCs also support
bootloaders that are capable of updating the firmware image, however
this is typically a last resort because it requires the device to be
held in the bootloader while the new firmware is downloaded and
installed, which results in down-time for the device. Firmware
updates in this class of device are typically not done in-place.
7.4. Dual CPU, other bus 7.4. Dual CPU, shared memory
This configuration has two or more CPUs, each having their own This configuration has two or more heterogeneous CPUs in a single SoC
memory. There will be a communication channel between them, but it that share memory (flash and RAM). Generally, they will be a
will be used as a peripheral, not via shared memory. In this case, protection mechanism to prevent one CPU from accessing the other's
each CPU will have to be responsible for its own firmware upgrade. memory. Upgrades in this case will typically be done by one of the
It is likely that one of the CPUs will be considered a master, and CPUs, and is similar to the single CPU with secure mode.
will direct the other CPU to do the upgrade. This configuration is
commonly used to offload specific work to other CPUs. Firmware 7.5. Dual CPU, other bus
dependencies are similar to the other solutions above, sometimes
allowing only one image to be upgraded, other times requiring several This configuration has two or more heterogeneous CPUs, each having
to be upgraded atomically. Because the updates are happening on their own memory. There will be a communication channel between
multiple CPUs, upgrading the two images atomically is challenging. them, but it will be used as a peripheral, not via shared memory. In
this case, each CPU will have to be responsible for its own firmware
upgrade. It is likely that one of the CPUs will be considered the
primary CPU, and will direct the other CPU to do the upgrade. This
configuration is commonly used to offload specific work to other
CPUs. Firmware dependencies are similar to the other solutions
above, sometimes allowing only one image to be upgraded, other times
requiring several to be upgraded atomically. Because the updates are
happening on multiple CPUs, upgrading the two images atomically is
challenging.
8. Bootloader 8. Bootloader
More devices today than ever before are being connected to the More devices today than ever before are being connected to the
Internet, which drives the need for firmware updates to be provided Internet, which drives the need for firmware updates to be provided
over the Internet rather than through traditional interfaces, such as over the Internet rather than through traditional interfaces, such as
USB or RS232. Updating a device over the Internet requires the USB or RS232. Updating a device over the Internet requires the
device to fetch not only the firmware image but also the manifest. device to fetch not only the firmware image but also the manifest.
Hence, the following building blocks are necessary for a firmware Hence, the following building blocks are necessary for a firmware
update solution: update solution:
skipping to change at page 20, line 29 skipping to change at page 21, line 47
attempt. Alternatively, secure boot-specific meta-data may have been attempt. Alternatively, secure boot-specific meta-data may have been
created by the application after a successful firmware download and created by the application after a successful firmware download and
verification process. Whether to re-use the standardized manifest verification process. Whether to re-use the standardized manifest
format that was used during the initial firmware retrieval process or format that was used during the initial firmware retrieval process or
whether it is better to use a different format for the secure boot- whether it is better to use a different format for the secure boot-
specific meta-data depends on the system design. The manifest format specific meta-data depends on the system design. The manifest format
does, however, have the capability to serve also as a building block does, however, have the capability to serve also as a building block
for secure boot with its severable elements that allow shrinking the for secure boot with its severable elements that allow shrinking the
size of the manifest by stripping elements that are no longer needed. size of the manifest by stripping elements that are no longer needed.
If the application image contains the firmware consumer In order to satisfy the reliability requirements defined in
functionality, as described above, then it is necessary that a Section 3.5, devices must always be able to return to a working
working image is left on the device. This allows the bootloader to firmware image. This has implications for the design of the
roll back to a working firmware image to execute a firmware download bootloader: If the firmware image contains the firmware consumer
if the bootloader itself does not have enough functionality to fetch functionality, as described above, then the bootloader must be able
a firmware image plus manifest from a firmware server over the to roll back to a working firmware image. Alternatively, the
Internet. A multi-stage bootloader may soften this requirement at bootloader may have enough functionality to fetch a firmware image
the expense of a more sophisticated boot process. 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.
For a bootloader to offer a secure boot mechanism it needs to provide For a bootloader to offer a secure boot mechanism it needs to provide
the following features: the following features:
- ability to access security algorithms, such as SHA-256 to compute - ability to access security algorithms, such as SHA-256 to compute
a fingerprint over the firmware image and a digital signature a fingerprint over the firmware image and a digital signature
algorithm. algorithm.
- access keying material directly or indirectly to utilize the - access keying material directly or indirectly to utilize the
digital signature. The device needs to have a trust anchor store. digital signature. The device needs to have a trust anchor store.
skipping to change at page 26, line 38 skipping to change at page 28, line 4
- Olaf Bergmann - Olaf Bergmann
- Suhas Nandakumar - Suhas Nandakumar
- Phillip Hallam-Baker - Phillip Hallam-Baker
- Marti Bolivar - Marti Bolivar
- Andrzej Puzdrowski - Andrzej Puzdrowski
- Markus Gueller - Markus Gueller
- Henk Birkholz - Henk Birkholz
- Jintao Zhu - Jintao Zhu
- Takeshi Takahashi - Takeshi Takahashi
- Jacob Beningo - Jacob Beningo
- Kathleen Moriarty - Kathleen Moriarty
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.
13. Informative References 13. Informative References
[I-D.ietf-suit-information-model] [I-D.ietf-suit-information-model]
Moran, B., Tschofenig, H., and H. Birkholz, "An Moran, B., Tschofenig, H., and H. Birkholz, "An
Information Model for Firmware Updates in IoT Devices", Information Model for Firmware Updates in IoT Devices",
draft-ietf-suit-information-model-05 (work in progress), draft-ietf-suit-information-model-07 (work in progress),
January 2020. June 2020.
[I-D.ietf-suit-manifest] [I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
"A Concise Binary Object Representation (CBOR)-based "A Concise Binary Object Representation (CBOR)-based
Serialization Format for the Software Updates for Internet Serialization Format for the Software Updates for Internet
of Things (SUIT) Manifest", draft-ietf-suit-manifest-05 of Things (SUIT) Manifest", draft-ietf-suit-manifest-09
(work in progress), May 2020. (work in progress), July 2020.
[I-D.ietf-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-08 (work in Architecture", draft-ietf-teep-architecture-12 (work in
progress), April 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>.
[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>.
[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. 35 change blocks. 
106 lines changed or deleted 150 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/