| Network Working Group | B. Moran |
| Internet-Draft | M. Meriac |
| Intended status: Informational | H. Tschofenig |
| Expires: January 19, 2018 | ARM Limited |
| July 18, 2017 |
A Firmware Update Architecture for Internet of Things Devices
draft-moran-fud-architecture-00
Vulnerabilities with IoT devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts.
This document specifies requires and an architecture for a firmware update mechanism aimed for Internet of Things (IoT) devices. The architecture is agnostic to the transport of the firmware images and associated meta-data.
This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 19, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
When developing IoT devices, one of the most difficult problems to solve is how to update the firmware on the device. Once the device is deployed, firmware updates play a critical part in its lifetime, particularly when devices have a long lifetime, are deployed in remote or inaccessible areas or where manual intervention is cost prohibitive or otherwise difficult: - Fixes to bugs in software can be applied to the device with a firmware update. - New functionality can be added to the device with a firmware update.
The firmware update process has to ensure that - The firmware is authenticated (attempts to flash a malicious firmware are prevented). - The firmware can be confidentiality protected (attempts by an adversary to recover the plaintext binary can be prevented).
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the following entities:
Additionally, the following terms are defined:
The firmware update mechanism described in this specification was designed with the following requirements in mind:
Firmware images can be conveyed to devices in a variety of ways, including USB, UART, WiFi, BLE, low-power WAN technologies, etc and use different protocol mechanisms (e.g., CoAP, HTTP). The specified mechanism needs to be agnostic to the distribution of the firmware images/manifests.
For an update to be broadcast friendly, it must not rely on any transport security. In addition, the same message must be deliverable to many devices; both those to which it applies and those to which it does not without a chance that the wrong device will accept the update. Considerations that apply to network broadcasts apply equally to the use of third-party content distribution networks for payload distribution.
End-to-end security between the author and the device, as shown in Section 4, is used to ensure that the device can verify firmware images and manifests produced by authorized authors.
If the update payload is to be encrypted, it must be done in such a way that every intended recipient can decrypt it. The information that is encrypted individually for each device must be an absolute minimum.
Rollback attacks must be prevented.
All information necessary for a device to make a decision about the installation of an update must fit into the available RAM of a constrained IoT device. This prevents flash write exhaustion.
Since parsers are known sources of bugs it must be easy to parse only those fields which are required to validate at least one signature with minimal exposure.
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 of the device. To achieve this, the device is required to provide a minimum of two storage locations for firmware and one bootable location for firmware. Note: This is an implementation requirement rather than a requirement on the manifest format.
The bootloader must be minimal, containing only the flash and cryptographic primitives necessary to read the stored firmware, validate the received firmware, and write the bootable firmware. The bootloader should not require updating, since a failed update poses a risk in reliability. If more functionality is required in the bootloader, it must use a two-stage bootloader, with the first stage comprising the functionality defined above.
The firmware update must not require changes to existing firmware formats.
A device may have many modules that require updating individually. It may also need to trust several different actors in order to authorize an update. For example, a firmware author may not have the authority to install firmware on a device in critical infrastructure without the authorization of a device operator. In this case, the device should reject firmware updates unless they are signed both by the firmware author and by the device operator.
To facilitate complex use-cases such as this, updates require several permissions:
The architecture graphically shown below illustrates that an author creates a firmware image and a manifest. The firmware image may be encrypted and will be integrity protected. The meta-data is integrity protected. When the author is ready to distribute the firmware image it conveys it using his or her favorite communication channel to the device, which will typically involve the use of untrusted storage, like a file server. Whether the firmware image and the manifest is pushed to the device or fetched by the device is outside the scope of this work and existing device management protocols can be used for efficiently distributing this information.
The following assumptions are made to allow the device to verify the received firmware image and manifest before updating software:
+-----------+
+--------+ Firmware Image | | Firmware Image +--------+
| | + Manifest | Untrusted | + Manifest | |
| Device |<-----------------| Storage |<------------------| Author |
| | | | | |
+--------+ +-----------+ +--------+
^ *
* *
************************************************************
End-to-End Security
In order for a device to apply an update, it has to make several decisions about the update:
The manifest format encodes the information that devices need in order to make these decisions.
The manifest is a data structure that contains the following information:
The manifest structure is described in a companion document.
The following example message flow illustrates the interaction for distributing a firmware image to a device starting with an author uploading the new firmware to untrusted storage and creating a manifest.
+--------+ +-----------------+ +------+ | Author | |Untrusted Storage| |Device| +--------+ +-----------------+ +------+ | | | | Create Firmware | | |--------------- | | | | | | |<-------------- | | | | | | Upload Firmware | | |------------------>| | | | | | Create Manifest | | |---------------- | | | | | | |<--------------- | | | | | | Sign Manifest | | |-------------- | | | | | | |<------------- | | | | | | Upload Manifest | | |------------------>| | | | | | | Query Manifest | | |<--------------------| | | | | | Send Manifest | | |-------------------->| | | | | | | Validate Manifest | | |------------------ | | | | | | |<----------------- | | | | | Request Firmware | | |<--------------------| | | | | | Send Firmware | | |-------------------->| | | | | | | Verify Firmware | | |--------------- | | | | | | |<-------------- | | | | | | Store Firmware | | |-------------- | | | | | | |<------------- | | | | | | Reboot | | |------- | | | | | | |<------ | | | | | | Bootloader validates | | | Firmware | | |---------------------- | | | | | | |<--------------------- | | | | | | Bootloader activates | | | Firmware | | |---------------------- | | | | | | |<--------------------- | | | | | | Bootloader transfers | | | control to new Firmware | | |---------------------- | | | | | | |<--------------------- | | |
This document does not require any actions by IANA.
Firmware updates fix security vulnerabilities and are considered to be an important building block in securing IoT devices. Due to the importance of firmware updates for IoT devices the Internet Architecture Board (IAB) organized a ‘Workshop on Internet of Things (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 the big picture. A report about this workshop can be found at [I-D.iab-iotsu-workshop]. This document (and associated specifications) offer a standardized firmware manifest format and an approach for offering end-to-end security from the author to the device.
There are, however, many other considerations raised during the workshop. Many of them are outside the scope of standardization organizations since they fall into the realm of product engineering, regulatory frameworks, and business models. The following considerations are outside the scope of this document, namely
The discussion list for this document is located at the e-mail address fud@ietf.org. Information on the group and information on how to subscribe to the list is at https://www1.ietf.org/mailman/listinfo/fud
Archives of the list can be found at: https://www.ietf.org/mail-archive/web/fud/current/index.html
We would like the following persons for their support in designing this mechanism
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.iab-iotsu-workshop] | Tschofenig, H. and S. Farrell, "Report from the Internet of Things (IoT) Software Update (IoTSU) Workshop 2016", Internet-Draft draft-iab-iotsu-workshop-01, February 2017. |