draft-ietf-suit-architecture-05.txt   draft-ietf-suit-architecture-06.txt 
SUIT B. Moran SUIT B. Moran
Internet-Draft Arm Limited Internet-Draft Arm Limited
Intended status: Informational M. Meriac Intended status: Informational M. Meriac
Expires: October 11, 2019 Consultant Expires: March 16, 2020 Consultant
H. Tschofenig H. Tschofenig
Arm Limited Arm Limited
D. Brown D. Brown
Linaro Linaro
April 09, 2019 September 13, 2019
A Firmware Update Architecture for Internet of Things Devices A Firmware Update Architecture for Internet of Things Devices
draft-ietf-suit-architecture-05 draft-ietf-suit-architecture-06
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 41 skipping to change at page 1, line 41
symmetric key approach for very constrained devices. symmetric key approach for very constrained devices.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 October 11, 2019. This Internet-Draft will expire on March 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 36 skipping to change at page 2, line 36
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . 7 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 . . . . . . . . . . . 8
3.5. High reliability . . . . . . . . . . . . . . . . . . . . 8 3.5. High reliability . . . . . . . . . . . . . . . . . . . . 9
3.6. Operate with a small bootloader . . . . . . . . . . . . . 8 3.6. Operate with a small bootloader . . . . . . . . . . . . . 9
3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 10
3.8. Minimal impact on existing firmware formats . . . . . . . 9 3.8. Minimal impact on existing firmware formats . . . . . . . 10
3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 9 3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 10
3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 9 3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 10
4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.11. Suitability to software and personalization data . . . . 12
5. Communication Architecture . . . . . . . . . . . . . . . . . 12 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Communication Architecture . . . . . . . . . . . . . . . . . 13
7. Device Firmware Update Examples . . . . . . . . . . . . . . . 17 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 17 7. Device Firmware Update Examples . . . . . . . . . . . . . . . 18
7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 17 7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 18
7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 17 7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 18
7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 17 7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 18
8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 18
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Mailing List Information . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12. Mailing List Information . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
When developing IoT devices, one of the most difficult problems to When developing IoT devices, one of the most difficult problems to
solve is how to update the firmware on the device. Once the device solve is how to update the firmware on the device. Once the device
is deployed, firmware updates play a critical part in its lifetime, is deployed, firmware updates play a critical part in its lifetime,
particularly when devices have a long lifetime, are deployed in particularly when devices have a long lifetime, are deployed in
remote or inaccessible areas where manual intervention is cost remote or inaccessible areas where manual intervention is cost
prohibitive or otherwise difficult. Updates to the firmware of an prohibitive or otherwise difficult. Updates to the firmware of an
IoT device are done to fix bugs in software, to add new IoT device are done to fix bugs in software, to add new
skipping to change at page 5, line 10 skipping to change at page 5, line 10
- Homogeneous Storage Architecture (HoSA): A device that stores all - Homogeneous Storage Architecture (HoSA): A device that stores all
firmware components in the same way, for example in a file system firmware components in the same way, for example in a file system
or in flash memory. or in flash memory.
- Heterogeneous Storage Architecture (HeSA): A device that stores at - Heterogeneous Storage Architecture (HeSA): A device that stores at
least one firmware component differently from the rest, for least one firmware component differently from the rest, for
example a device with an external, updatable radio, or a device example a device with an external, updatable radio, or a device
with internal and external flash memory. with internal and external flash memory.
- 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].
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
firmware image and the manifest. 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.
- Device: A device refers to the entire IoT product, which consists - (IoT) Device: A device refers to the entire IoT product, which
of one or many MCUs, sensors and/or actuators. Many IoT devices consists of one or many MCUs, sensors and/or actuators. Many IoT
sold today contain multiple MCUs and therefore a single device may devices sold today contain multiple MCUs and therefore a single
need to obtain more than one firmware image and manifest to device may need to obtain more than one firmware image and
succesfully perform an update. The terms device and firmware manifest to succesfully perform an update. The terms device and
consumer are used interchangably since the firmware consumer is firmware consumer are used interchangably since the firmware
one software component running on an MCU on the device. consumer is one software component running on an MCU on the
device.
- Status Tracker: The status tracker offers device management - Status Tracker: The status tracker offers device management
functionality to monitor the firmware update process. A status functionality to retrieve information about the installed firmware
tracker may, for example, want to know what state of the firmware on a device and other device characteristics (including free
update cycle the device is currently in. 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 - 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. 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.
- 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.
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
skipping to change at page 7, line 5 skipping to change at page 7, line 44
- Operate with a small bootloader - Operate with a small bootloader
- Small Parsers - Small Parsers
- Minimal impact on existing firmware formats - Minimal impact on existing firmware formats
- Robust permissions - Robust permissions
- Diverse modes of operation - Diverse modes of operation
- 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
skipping to change at page 8, line 28 skipping to change at page 9, line 21
location for firmware. An alternative approach is to use a 2nd stage location for firmware. An alternative approach is to use a 2nd stage
bootloader with build-in full featured firmware update functionality bootloader with build-in full featured firmware update functionality
such that it is possible to return to the update process after power such that it is possible to return to the update process after power
down. 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
The bootloader must be minimal, containing only flash support, Throughout this document we assume that the bootloader itself is
cryptographic primitives and optionally a recovery mechanism. The distinct from the role of the fw consumer and therefore does not
recovery mechanism is used in case the update process failed and may manage the firmware update process. This may give the impression
include support for firmware updates over serial, USB or even a that the bootloader itself is a completely separate component, which
limited version of wireless connectivity standard like a limited is mainly responsible for selecting a firmware image to boot.
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 overlap between the firmware update process and the bootloader
the bootable firmware image. The bootloader should not require functionality comes in two forms, namely
updating since a failed update poses a risk in reliability. If more
functionality is required in the bootloader, it must use a two-stage - First, a bootloader must verify the firmware image it boots as
bootloader, with the first stage comprising the functionality defined part of the secure boot process. Doing so requires meta-data to
above. 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 All information necessary for a device to make a decision about the
installation of a firmware update must fit into the available RAM of installation of a firmware update must fit into the available RAM of
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
there are not other task/processing running while the bootloader is
active (unlike it may be the case when running the application
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 they must be minimal.
Additionally, it must be easy to parse only those fields that are Additionally, it must be easy to parse only those fields that are
required to validate at least one signature or MAC with minimal required to validate at least one signature or MAC with minimal
exposure. exposure.
skipping to change at page 11, line 24 skipping to change at page 12, line 34
process to determine the appropriate timing for an update (such as process to determine the appropriate timing for an update (such as
delaying the update process to a later time when end users are less delaying the update process to a later time when end users are less
impacted by the update process). impacted by the update process).
Installation is the act of processing the payload into a format that Installation is the act of processing the payload into a format that
the IoT device can recognise and the bootloader is responsible for the IoT device can recognise and the bootloader is responsible for
then booting from the newly installed firmware image. then booting from the newly installed firmware image.
Each of these steps may require different permissions. Each of these steps may require different permissions.
3.11. Suitability to software and personalization data
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.
4. Claims 4. Claims
Claims in the manifest offer a way to convey instructions to a device Claims in the manifest offer a way to convey instructions to a device
that impact the firmware update process. To have any value the that impact the firmware update process. To have any value the
manifest containing those claims must be authenticated and integrity manifest containing those claims must be authenticated and integrity
protected. The credential used to must be directly or indirectly protected. The credential used to must be directly or indirectly
related to the trust anchor installed at the device by the Trust related to the trust anchor installed at the device by the Trust
Provisioning Authority. Provisioning Authority.
The baseline claims for all manifests are described in The baseline claims for all manifests are described in
skipping to change at page 15, line 25 skipping to change at page 16, line 25
| | | | | | | | | | | |
+--------+ +-----------+ +--------+ +--------+ +-----------+ +--------+
Figure 3: Manifest with attached firmware. Figure 3: Manifest with attached firmware.
Figure 4 shows an option for remotely updating a device where the Figure 4 shows an option for remotely updating a device where the
device fetches the firmware image from some file server. The device fetches the firmware image from some file server. The
manifest itself is delivered independently and provides information manifest itself is delivered independently and provides information
about the firmware image(s) to download. about the firmware image(s) to download.
/------------\ /--------\ /--------\
/ \ / \ / \
| Manifest | | Manifest | | Manifest |
\ / \ / \ /
+--------+ \------------/ +--------+ \--------/ \--------/
| |<..............................................>| | +-----------+
| Device | -- | Author | +--------+ | | +--------+
| |<- --- | | | |<.................| Status |................>| |
+--------+ -- --- +--------+ | Device | | Tracker | -- | Author |
-- --- | |<- | | --- | |
--- --- +--------+ -- +-----------+ --- +--------+
-- +-----------+ -- -- ---
-- | | -- --- ---
/------------\ -- | Firmware |<- /------------\ -- +-----------+ --
/ \ -- | Server | / \ -- | | --
| Firmware | | | | Firmware | /------------\ -- | Firmware |<- /------------\
\ / +-----------+ \ / / \ -- | Server | / \
\------------/ \------------/ | Firmware | | | | Firmware |
\ / +-----------+ \ /
\------------/ \------------/
Figure 4: Independent retrieval of the firmware image. Figure 4: Independent retrieval of the firmware image.
This architecture does not mandate a specific delivery mode but a This architecture does not mandate a specific delivery mode but a
solution must support both types. solution must support both types.
6. Manifest 6. Manifest
In order for a device to apply an update, it has to make several In order for a device to apply an update, it has to make several
decisions about the update: decisions about the update:
skipping to change at page 20, line 9 skipping to change at page 21, line 9
measurements). measurements).
While the software architecture of the bootloader and its security While the software architecture of the bootloader and its security
mechanisms are implementation-specific, the manifest can be used to mechanisms are implementation-specific, the manifest can be used to
control the firmware download from the Internet in addition to control the firmware download from the Internet in addition to
augmenting secure boot process. These building blocks are highly augmenting secure boot process. These building blocks are highly
relevant for the design of the manifest. relevant for the design of the manifest.
9. Example 9. Example
The following example message flow illustrates a possible interaction Figure 5 illustrates an example message flow for distributing a
for distributing a firmware image to a device starting with an author firmware image to a device starting with an author uploading the new
uploading the new firmware to firmware server and creating a firmware to firmware server and creating a manifest. The firmware
manifest. The firmware and manifest are stored on the same firmware and manifest are stored on the same firmware server. This setup does
server. 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.
+--------+ +-----------------+ +------------+ +----------+ +--------+ +-----------------+ +------------+ +----------+
| Author | | Firmware Server | |FW Consumer | |Bootloader| | Author | | Firmware Server | |FW Consumer | |Bootloader|
+--------+ +-----------------+ +------------+ +----------+ +--------+ +-----------------+ +------------+ +----------+
| | | + | | | +
| Create Firmware | | | | Create Firmware | | |
|--------------- | | | |--------------+ | | |
| | | | | | | | | |
|<-------------- | | | |<-------------+ | | |
| | | | | | | |
| Upload Firmware | | | | Upload Firmware | | |
|------------------>| | | |------------------>| | |
| | | | | | | |
| Create Manifest | | | | Create Manifest | | |
|---------------- | | | |---------------+ | | |
| | | | | | | | | |
|<--------------- | | | |<--------------+ | | |
| | | | | | | |
| Sign Manifest | | | | Sign Manifest | | |
|-------------- | | | |-------------+ | | |
| | | | | | | | | |
|<------------- | | | |<------------+ | | |
| | | | | | | |
| Upload Manifest | | | | Upload Manifest | | |
|------------------>| | | |------------------>| | |
| | | | | | | |
| | Query Manifest | | | | Query Manifest | |
| |<--------------------| | | |<--------------------| |
| | | | | | | |
| | Send Manifest | | | | Send Manifest | |
| |-------------------->| | | |-------------------->| |
| | | Validate | | | | Validate |
skipping to change at page 21, line 10 skipping to change at page 22, line 12
| | | | | | | | | |
| | |<--------+ | | | |<--------+ |
| | | | | | | |
| | Request Firmware | | | | Request Firmware | |
| |<--------------------| | | |<--------------------| |
| | | | | | | |
| | Send Firmware | | | | Send Firmware | |
| |-------------------->| | | |-------------------->| |
| | | Verify | | | | Verify |
| | | Firmware | | | | Firmware |
| | |--------------- | | | |--------------+ |
| | | | | | | | | |
| | |<-------------- | | | |<-------------+ |
| | | | | | | |
| | | Store | | | | Store |
| | | Firmware | | | | Firmware |
| | |-------------- | | | |-------------+ |
| | | | | | | | | |
| | |<------------- | | | |<------------+ |
| | | | | | | |
| | | | | | | |
| | | Reboot | | | | Trigger Reboot |
| | |--------------->| | | |--------------->|
| | | | | | | |
| | | Verify |
| | | Firmware |
| | | ---------------|
| | | | |
| | | -------------->|
| | | |
| | | Activate new |
| | | Firmware |
| | | ---------------|
| | | | |
| | | -------------->|
| | | | | | | |
| | | Boot new | | | +---+----------------+--+
| | | Firmware | | | S| | | |
| | | ---------------| | | E| | Verify | |
| | | | | | | C| | Firmware | |
| | | -------------->| | | U| | +--------------| |
| | R| | | | |
| | E| | +------------->| |
| | | | | |
| | B| | Activate new | |
| | O| | Firmware | |
| | O| | +--------------| |
| | T| | | | |
| | | | +------------->| |
| | P| | | |
| | R| | Boot new | |
| | O| | Firmware | |
| | C| | +--------------| |
| | E| | | | |
| | S| | +------------->| |
| | S| | | |
| | +---+----------------+--+
| | | | | | | |
Figure 5: Example Flow for a Firmware Upate. Figure 5: First Example Flow for a Firmware Upate.
Figure 6 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.
+---------+ +-----------------+ |-----------------------------.
| Status | | Firmware Server | | +------------+ +----------+ |
| Tracker | | | | |FW Consumer | |Bootloader| |
+---------+ +-----------------+ | +------------+ +----------+ |
| | | | IoT Device | |
| | `''''''''''''''''''''''''''''
| | | |
| Query Firmware Version | |
|------------------------------------->| |
| Firmware Version A.B.C | |
|<-------------------------------------| |
| | | |
| <<some time later>> | |
| | | |
_,...._ _,...._ | |
,' `. ,' `. | |
| New | | New | | |
\ Manifest / \ Firmware / | |
`.._ _,,' `.._ _,,' | |
`'' `'' | |
| Push manifest | |
|----------------+-------------------->| |
| | | |
| ' | '
| | | Validate |
| | | Manifest |
| | |---------+ |
| | | | |
| | |<--------+ |
| | Request firmware | |
| | X.Y.Z | |
| |<--------------------| |
| | | |
| | Firmware X.Y.Z | |
| |-------------------->| |
| | | |
| | | Verify |
| | | Firmware |
| | |--------------+ |
| | | | |
| | |<-------------+ |
| | | |
| | | Store |
| | | Firmware |
| | |-------------+ |
| | | | |
| | |<------------+ |
| | | |
| | | |
| | | Trigger Reboot |
| | |--------------->|
| | | |
| | | |
| | | __..-------..._'
| | ,-' `-.
| | | Secure Boot |
| | `-. _/
| | |`--..._____,,.,-'
| | | |
Figure 6: Second Example Flow for a Firmware Upate.
10. IANA Considerations 10. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
11. Security Considerations 11. Security Considerations
Firmware updates fix security vulnerabilities and are considered to Firmware updates fix security vulnerabilities and are considered to
be an important building block in securing IoT devices. Due to the be an important building block in securing IoT devices. Due to the
importance of firmware updates for IoT devices the Internet importance of firmware updates for IoT devices the Internet
skipping to change at page 22, line 50 skipping to change at page 25, line 43
protecting the manifest. protecting the manifest.
- incentives for manufacturers to offer a firmware update mechanism - incentives for manufacturers to offer a firmware update mechanism
as part of their IoT products. as part of their IoT products.
12. Mailing List Information 12. Mailing List Information
The discussion list for this document is located at the e-mail The discussion list for this document is located at the e-mail
address suit@ietf.org [1]. Information on the group and information address suit@ietf.org [1]. Information on the group and information
on how to subscribe to the list is at on how to subscribe to the list is at
https://www1.ietf.org/mailman/listinfo/suit [2] https://www1.ietf.org/mailman/listinfo/suit
Archives of the list can be found at: https://www.ietf.org/mail- Archives of the list can be found at: https://www.ietf.org/mail-
archive/web/suit/current/index.html [3] archive/web/suit/current/index.html
13. Acknowledgements 13. Acknowledgements
We would like to thank the following persons for their feedback: We would like to thank the following persons for their feedback:
- Geraint Luff - Geraint Luff
- Amyas Phillips - Amyas Phillips
- Dan Ros - Dan Ros
skipping to change at page 24, line 4 skipping to change at page 26, line 48
- Markus Gueller - Markus Gueller
- Henk Birkholz - Henk Birkholz
- Jintao Zhu - Jintao Zhu
- Takeshi Takahashi - Takeshi Takahashi
- Jacob Beningo - Jacob Beningo
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.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, March 1997.
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925, DOI
DOI 10.17487/RFC7925, July 2016, 10.17487/RFC7925, July 2016, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7925>. editor.org/info/rfc7925>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-suit-information-model] [I-D.ietf-suit-information-model]
Moran, B., Tschofenig, H., and H. Birkholz, "Firmware Moran, B., Tschofenig, H., and H. Birkholz, "Firmware
Updates for Internet of Things Devices - An Information Updates for Internet of Things Devices - An Information
Model for Manifests", draft-ietf-suit-information-model-02 Model for Manifests", draft-ietf-suit-information-model-03
(work in progress), January 2019. (work in progress), July 2019.
[I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.
Liu, "Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-03 (work in
progress), July 2019.
[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/ V1_0_2-20180209-A/
OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf>. OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI
DOI 10.17487/RFC5649, September 2009, 10.17487/RFC5649, September 2009, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5649>. editor.org/info/rfc5649>.
[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>.
[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
RFC 8240, DOI 10.17487/RFC8240, September 2017, 8240, DOI 10.17487/RFC8240, September 2017,
<https://www.rfc-editor.org/info/rfc8240>. <https://www.rfc-editor.org/info/rfc8240>.
14.3. URIs 14.3. URIs
[1] mailto:suit@ietf.org [1] mailto:suit@ietf.org
[2] https://www1.ietf.org/mailman/listinfo/suit
[3] https://www.ietf.org/mail-archive/web/suit/current/index.html
Authors' Addresses Authors' Addresses
Brendan Moran Brendan Moran
Arm Limited Arm Limited
EMail: Brendan.Moran@arm.com EMail: Brendan.Moran@arm.com
Milosch Meriac Milosch Meriac
Consultant Consultant
 End of changes. 44 change blocks. 
130 lines changed or deleted 310 lines changed or added

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