< draft-ietf-suit-architecture-04.txt   draft-ietf-suit-architecture-05.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: September 28, 2019 Consultant Expires: October 11, 2019 Consultant
H. Tschofenig H. Tschofenig
Arm Limited Arm Limited
D. Brown D. Brown
Linaro Linaro
March 27, 2019 April 09, 2019
A Firmware Update Architecture for Internet of Things Devices A Firmware Update Architecture for Internet of Things Devices
draft-ietf-suit-architecture-04 draft-ietf-suit-architecture-05
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 48 skipping to change at page 1, line 48
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 September 28, 2019. This Internet-Draft will expire on October 11, 2019.
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 (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 3, line 7 skipping to change at page 3, line 7
3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 9 3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 9
4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Communication Architecture . . . . . . . . . . . . . . . . . 12 5. Communication Architecture . . . . . . . . . . . . . . . . . 12
6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Device Firmware Update Examples . . . . . . . . . . . . . . . 17 7. Device Firmware Update Examples . . . . . . . . . . . . . . . 17
7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 17 7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 17
7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 17 7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 17
7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 17 7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 17
7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 17 7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 17
8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. Mailing List Information . . . . . . . . . . . . . . . . . . 22 12. Mailing List Information . . . . . . . . . . . . . . . . . . 22
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 24
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 18, line 11 skipping to change at page 18, line 11
It is likely that one of the CPUs will be considered a master, and It is likely that one of the CPUs will be considered a master, and
will direct the other CPU to do the upgrade. This configuration is will direct the other CPU to do the upgrade. This configuration is
commonly used to offload specific work to other CPUs. Firmware commonly used to offload specific work to other CPUs. Firmware
dependencies are similar to the other solutions above, sometimes dependencies are similar to the other solutions above, sometimes
allowing only one image to be upgraded, other times requiring several allowing only one image to be upgraded, other times requiring several
to be upgraded atomically. Because the updates are happening on to be upgraded atomically. Because the updates are happening on
multiple CPUs, upgrading the two images atomically is challenging. multiple CPUs, upgrading the two images atomically is challenging.
8. Bootloader 8. Bootloader
Today, firmware updates for an Internet-connected device are expected More devices today than ever before are being connected to the
to be delivered over the Internet. Firmware updates over serial Internet, which drives the need for firmware updates to be provided
interfaces, such as USB or RS232, are most likely the exception over the Internet rather than through traditional interfaces, such as
rather than the norm. In order to fetch a manifest plus the firmware USB or RS232. Updating a device over the Internet requires the
image a fair amount of code is required since the firmware consumer device to fetch not only the firmware image but also the manifest.
needs to implement Hence, the following building blocks are necessary for a firmware
update solution:
- the Internet protocol stack for large file downloads, - the Internet protocol stack for (possibly large) firmware
downloads,
- the capability to write the received firmware image to some - the capability to write the received firmware image to persistent
persistent storage (most likely flash memory). It may even be storage (most likely flash memory) prior to performing the update,
necessary to unpack, decompress or otherwise process the received
firmware image.
- security protocol features for communication security, - the ability to unpack, decompress or otherwise process the
received firmware image,
- manifest parsing, - the features to verify an image and a manifest, including digital
signature verification or checking a message authentication code,
- security functionality for manifest verification, and - a manifest parsing library, and
- functionality for remote management by a device management server. - integration of the device into a device management server to
perform automatic firmware updates and to track their progress.
All these features are most likely offered by the application running All these features are most likely offered by the application, i.e.
on the device (except for basic security algorithms that may run firmware consumer, running on the device (except for basic security
either on a trusted execution environment or on a separate hardware algorithms that may run either on a trusted execution environment or
security MCU/module). on a separate hardware security MCU/module) rather than by the
bootloader itself.
Once manifests have been processed and firmware images successfully Once manifests have been processed and firmware images successfully
downloaded and verified the device needs to hand control over to the downloaded and verified the device needs to hand control over to the
bootloader. In most cases this requires the MCU to restart. The bootloader. In most cases this requires the MCU to restart. Once
bootloader then determines whether the newly downloaded firmware the MCU has initiated a restart, the bootloader takes over control
image should be started. The boot process is security sensitive and determines whether the newly downloaded firmware image should be
since the firmware images may, for example, be stored in off-chip executed.
flash memory given attackers easy access to the firmware image. The
bootloader will have to perform additional security checks on the The boot process is security sensitive because the firmware images
firmware image before it can be booted. may, for example, be stored in off-chip flash memory giving attackers
easy access to the image for reverse engineering and potentially also
for modifying the binary. The bootloader will therefore have to
perform security checks on the firmware image before it can be
booted. These security checks by the bootloader happen in addition
to the security checks that happened when the firmware image and the
manifest were downloaded.
The manifest may have been stored alongside the firmware image to The manifest may have been stored alongside the firmware image to
allow re-verification of the firmware image during every boot allow re-verification of the firmware image during every boot
attempt. Alternatively, secure boot-specific meta-data may have been attempt. Alternatively, secure boot-specific meta-data may have been
created by the firmware consumer after a successful firmware download created by the application after a successful firmware download and
and verification process. Whether to re-use the standardized verification process. Whether to re-use the standardized manifest
manifest format that was used during the initial firmware retrieval format that was used during the initial firmware retrieval process or
process or whether it is better to use a different format for the whether it is better to use a different format for the secure boot-
secure boot-specific meta-data depends on the system design. The specific meta-data depends on the system design. The manifest format
manifest format does, however, have the capability to serve also as a does, however, have the capability to serve also as a building block
building block for secure boot with its severable elements that allow for secure boot with its severable elements that allow shrinking the
shrinking the size of the manifest by stripping elements that are no size of the manifest by stripping elements that are no longer needed.
longer needed.
If the application image contains the firmware consumer If the application image contains the firmware consumer
functionality, as described above, then it is necessary that a functionality, as described above, then it is necessary that a
working image is left on the device to ensure that the bootloader can working image is left on the device to ensure that the bootloader can
roll back to a working firmware image to re-do the firmware download roll back to a working firmware image to re-do the firmware download
since the bootloader itself does not have enough functionality to since the bootloader itself does not have enough functionality to
fetch a firmware image plus manifest from a firmware server over the fetch a firmware image plus manifest from a firmware server over the
Internet. A multi-stage bootloader may soften this requirement at Internet. A multi-stage bootloader may soften this requirement at
the expense of a more sophisticated boot process. the expense of a more sophisticated boot process.
skipping to change at page 19, line 40 skipping to change at page 19, line 49
digital signature. The device needs to have a trust anchor store. digital signature. The device needs to have a trust anchor store.
- 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 device management software). This allows firmware (such as to the device management software). This allows
a device management server to determine whether the firmware a device management server to determine whether the firmware
update has been successful and, if not, what errors occurred. update has been successful and, if not, what errors occurred.
- to (optionally) offer attestation information (such as - to (optionally) offer attestation information (such as
measurements). measurements).
While the software architecture of the bootloader and also its While the software architecture of the bootloader and its security
security mechanism are implemention-specific the use of the manifest mechanisms are implementation-specific, the manifest can be used to
for controlling the download of the firmware over the Internet as control the firmware download from the Internet in addition to
well as for the secure boot process is relevant for the design of the augmenting secure boot process. These building blocks are highly
manifest. relevant for the design of the manifest.
9. Example 9. Example
The following example message flow illustrates a possible interaction The following example message flow illustrates a possible interaction
for distributing a firmware image to a device starting with an author for distributing a firmware image to a device starting with an author
uploading the new firmware to firmware server and creating a uploading the new firmware to firmware server and creating a
manifest. The firmware and manifest are stored on the same firmware manifest. The firmware and manifest are stored on the same firmware
server. server.
+--------+ +-----------------+ +------------+ +----------+ +--------+ +-----------------+ +------------+ +----------+
skipping to change at page 23, line 38 skipping to change at page 23, line 49
- Andrzej Puzdrowski - Andrzej Puzdrowski
- Markus Gueller - Markus Gueller
- Henk Birkholz - Henk Birkholz
- Jintao Zhu - Jintao Zhu
- Takeshi Takahashi - Takeshi Takahashi
- 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.
Kathleen Moriarty was the responsible security area director when
this work was started.
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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 21 change blocks. 
53 lines changed or deleted 61 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/