draft-ietf-suit-architecture-02.txt   draft-ietf-suit-architecture-03.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: July 20, 2019 Consultant Expires: September 12, 2019 Consultant
H. Tschofenig H. Tschofenig
Arm Limited Arm Limited
D. Brown D. Brown
Linaro Linaro
January 16, 2019 March 11, 2019
A Firmware Update Architecture for Internet of Things Devices A Firmware Update Architecture for Internet of Things Devices
draft-ietf-suit-architecture-02 draft-ietf-suit-architecture-03
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 July 20, 2019. This Internet-Draft will expire on September 12, 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 2, line 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Agnostic to how firmware images are distributed . . . . . 6 3.1. Agnostic to how firmware images are distributed . . . . . 7
3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 7 3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 7
3.3. Use state-of-the-art security mechanisms . . . . . . . . 7 3.3. Use state-of-the-art security mechanisms . . . . . . . . 7
3.4. Rollback attacks must be prevented . . . . . . . . . . . 7 3.4. Rollback attacks must be prevented . . . . . . . . . . . 8
3.5. High reliability . . . . . . . . . . . . . . . . . . . . 8 3.5. High reliability . . . . . . . . . . . . . . . . . . . . 8
3.6. Operate with a small bootloader . . . . . . . . . . . . . 8 3.6. Operate with a small bootloader . . . . . . . . . . . . . 8
3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 9
3.8. Minimal impact on existing firmware formats . . . . . . . 9 3.8. Minimal impact on existing firmware formats . . . . . . . 9
3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 9 3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 9
3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 9 3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 9
4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Communication Architecture . . . . . . . . . . . . . . . . . 11 5. Communication Architecture . . . . . . . . . . . . . . . . . 12
6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Device Firmware Update Examples . . . . . . . . . . . . . . . 16 7. Device Firmware Update Examples . . . . . . . . . . . . . . . 17
7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 16 7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 17
7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 16 7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 17
7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 16 7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 17
7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 16 7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 17
8. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Mailing List Information . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 12. Mailing List Information . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 4, line 31 skipping to change at page 4, line 33
deciding whether to boot a firmware image that is present or deciding whether to boot a firmware image that is present or
whether to obtain and verify a new firmware image. Since the whether to obtain and verify a new firmware image. Since the
bootloader is a security critical component its functionality may bootloader is a security critical component its functionality may
be split into separate stages. Such a multi-stage bootloader may be split into separate stages. Such a multi-stage bootloader may
offer very basic functionality in the first stage and resides in offer very basic functionality in the first stage and resides in
ROM whereas the second stage may implement more complex ROM whereas the second stage may implement more complex
functionality and resides in flash memory so that it can be functionality and resides in flash memory so that it can be
updated in the future (in case bugs have been found). The exact updated in the future (in case bugs have been found). The exact
split of components into the different stages, the number of split of components into the different stages, the number of
firmware images stored by an IoT device, and the detailed firmware images stored by an IoT device, and the detailed
functionality varies throughout different implementations. functionality varies throughout different implementations. A more
detailed discussion is provided in Section 8.
- Microcontroller (MCU for microcontroller unit): An MCU is a - Microcontroller (MCU for microcontroller unit): An MCU is a
compact integrated circuit designed for use in embedded systems. compact integrated circuit designed for use in embedded systems.
A typical microcontroller includes a processor, memory (RAM and A typical microcontroller includes a processor, memory (RAM and
flash), input/output (I/O) ports and other features connected via flash), input/output (I/O) ports and other features connected via
some bus on a single chip. The term 'system on chip (SoC)' is some bus on a single chip. The term 'system on chip (SoC)' is
often used for these types of devices. often used for these types of devices.
- System on Chip (SoC): An SoC is an integrated circuit that - System on Chip (SoC): An SoC is an integrated circuit that
integrates all components of a computer, such as CPU, memory, integrates all components of a computer, such as CPU, memory,
skipping to change at page 17, line 9 skipping to change at page 18, line 9
will be used as a peripheral, not via shared memory. In this case, 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. each CPU will have to be responsible for its own firmware upgrade.
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. Example Flow 8. Bootloader
The following example message flow illustrates the interaction for Today, firmware updates for an Internet-connected device are expected
distributing a firmware image to a device starting with an author to be delivered over the Internet. Firmware updates over serial
interfaces, such as USB or RS232, are most likely the exception
rather than the norm. In order to fetch a manifest plus the firmware
image a fair amount of code is required since the firmware consumer
needs to implement
- the Internet protocol stack for large file downloads,
- the capability to write the received firmware image to some
persistent storage (most likely flash memory). It may even be
necessary to unpack, decompress or otherwise process the received
firmware image.
- security protocol features for communication security,
- manifest parsing,
- security functionality for manifest verification, and
- functionality for remote management by a device management server.
All these features are most likely offered by the application running
on the device (except for basic security algorithms that may run
either on a trusted execution environment or on a separate hardware
security MCU/module).
Once manifests have been processed and firmware images successfully
downloaded and verified the device needs to hand control over to the
bootloader. In most cases this requires the MCU to restart. The
bootloader then determines whether the newly downloaded firmware
image should be started. The boot process is security sensitive
since the firmware images may, for example, be stored in off-chip
flash memory given attackers easy access to the firmware image. The
bootloader will have to perform additional security checks on the
firmware image before it can be booted.
The manifest may have been stored alongside the firmware image to
allow re-verification of the firmware image during every boot
attempt. Alternatively, secure boot-specific meta-data may have been
created by the firmware consumer after a successful firmware download
and verification process. Whether to re-use the standardized
manifest format that was used during the initial firmware retrieval
process or whether it is better to use a different format for the
secure boot-specific meta-data depends on the system design. The
manifest format does, however, have the capability to serve also as a
building block for secure boot with its severable elements that allow
shrinking the size of the manifest by stripping elements that are no
longer needed.
If the application image contains the firmware consumer
functionality, as described above, then it is necessary that a
working image is left on the device to ensure that the bootloader can
roll back to a working firmware image to re-do the firmware download
since the bootloader itself does not have enough functionality to
fetch a firmware image plus manifest from a firmware server over the
Internet. A multi-stage bootloader may soften this requirement at
the expense of a more sophisticated boot process.
For a bootloader to offer a secure boot mechanism it needs to provide
the following features:
- ability to access security algorithms, such as SHA-256 to compute
a fingerprint over the firmware image and a digital signature
algorithm.
- access keying material directly or indirectly to utilize the
digital signature. The device needs to have a trust anchor store.
- ability to expose boot process-related data to the application
firmware (such as to the device management software). This allows
a device management server to determine whether the firmware
update has been successful and, if not, what errors occurred.
- to (optionally) offer attestation information (such as
measurements).
While the software architecture of the bootloader and also its
security mechanism are implemention-specific the use of the manifest
for controlling the download of the firmware over the Internet as
well as for the secure boot process is relevant for the design of the
manifest.
9. Example
The following example message flow illustrates a possible interaction
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.
+--------+ +-----------------+ +------------+ +----------+ +--------+ +-----------------+ +------------+ +----------+
| Author | | Firmware Server | |FW Consuumer| |Bootloader| | Author | | Firmware Server | |FW Consumer | |Bootloader|
+--------+ +-----------------+ +------------+ +----------+ +--------+ +-----------------+ +------------+ +----------+
| | | + | | | +
| Create Firmware | | | | Create Firmware | | |
|--------------- | | | |--------------- | | |
| | | | | | | | | |
|<-------------- | | | |<-------------- | | |
| | | | | | | |
| Upload Firmware | | | | Upload Firmware | | |
|------------------>| | | |------------------>| | |
| | | | | | | |
skipping to change at page 18, line 26 skipping to change at page 21, line 16
| | | Store | | | | Store |
| | | Firmware | | | | Firmware |
| | |-------------- | | | |-------------- |
| | | | | | | | | |
| | |<------------- | | | |<------------- |
| | | | | | | |
| | | | | | | |
| | | Reboot | | | | Reboot |
| | |--------------->| | | |--------------->|
| | | | | | | |
| | | Validate | | | | Verify |
| | | Firmware | | | | Firmware |
| | | ---------------| | | | ---------------|
| | | | | | | | | |
| | | -------------->| | | | -------------->|
| | | | | | | |
| | | Activate new | | | | Activate new |
| | | Firmware | | | | Firmware |
| | | ---------------| | | | ---------------|
| | | | | | | | | |
| | | -------------->| | | | -------------->|
| | | | | | | |
| | | Boot new | | | | Boot new |
| | | Firmware | | | | Firmware |
| | | ---------------| | | | ---------------|
| | | | | | | | | |
| | | -------------->| | | | -------------->|
| | | | | | | |
Figure 5: Example Flow for a Firmware Upate. Figure 5: Example Flow for a Firmware Upate.
9. IANA Considerations 10. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
10. 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
Architecture Board (IAB) organized a 'Workshop on Internet of Things Architecture Board (IAB) organized a 'Workshop on Internet of Things
(IoT) Software Update (IOTSU)', which took place at Trinity College (IoT) Software Update (IOTSU)', which took place at Trinity College
Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at
the big picture. A report about this workshop can be found at the big picture. A report about this workshop can be found at
[RFC8240]. A standardized firmware manifest format providing end-to- [RFC8240]. A standardized firmware manifest format providing end-to-
end security from the author to the device will be specified in a end security from the author to the device will be specified in a
skipping to change at page 19, line 45 skipping to change at page 22, line 34
involvement. involvement.
- energy efficiency and battery lifetime considerations. - energy efficiency and battery lifetime considerations.
- key management required for verifying the digital signature - key management required for verifying the digital signature
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.
11. 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 [2]
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 [3]
12. 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
- Thomas Eichinger - Thomas Eichinger
- Michael Richardson - Michael Richardson
- Emmanuel Baccelli - Emmanuel Baccelli
- Ned Smith - Ned Smith
skipping to change at page 21, line 4 skipping to change at page 23, line 40
- Markus Gueller - Markus Gueller
- Henk Birkholz - Henk Birkholz
- Jintao Zhu - Jintao Zhu
- Takeshi Takahashi - Takeshi Takahashi
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 Kathleen Moriarty was the responsible security area director when
this work was started. this work was started.
13. References 14. References
13.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>.
[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 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
13.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-01 Model for Manifests", draft-ietf-suit-information-model-02
(work in progress), July 2018. (work in progress), January 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 10.17487/RFC5649, September 2009, DOI 10.17487/RFC5649, September 2009,
skipping to change at page 22, line 5 skipping to change at page 24, line 39
[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 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>.
13.3. URIs 14.3. URIs
[1] mailto:suit@ietf.org [1] mailto:suit@ietf.org
[2] https://www1.ietf.org/mailman/listinfo/suit [2] https://www1.ietf.org/mailman/listinfo/suit
[3] https://www.ietf.org/mail-archive/web/suit/current/index.html [3] https://www.ietf.org/mail-archive/web/suit/current/index.html
Authors' Addresses Authors' Addresses
Brendan Moran Brendan Moran
 End of changes. 25 change blocks. 
42 lines changed or deleted 128 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/