| SUIT | B. Moran |
| Internet-Draft | H. Tschofenig |
| Intended status: Standards Track | Arm Limited |
| Expires: December 5, 2018 | H. Birkholz |
| Fraunhofer SIT | |
| J. Jimenez | |
| Ericsson | |
| June 03, 2018 |
Firmware Updates for Internet of Things Devices - An Information Model for Manifests
draft-ietf-suit-information-model-00
Vulnerabilities with Internet of Things (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.
One component of such a firmware update is the meta-data, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes all the information that must be present in the manifest.
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 https://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 December 5, 2018.
Copyright (c) 2018 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 (https://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.
The information model aims to describe all the information that must be present in the manifest that is consumed by an IoT device. Additional information is possible. The fields that are described here are the minimum required to meet the usability and security requirements outlined in Section 3.3.
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].
The following sub-sections describe the threat model, user stories, security requirements, and usability requirements.
The following sub-sections aim to provide information about the threats that were considered, the security requirements that are derived from those threats and the fields that permit implementation of the security requirements. This model uses the S.T.R.I.D.E. [STRIDE] approach. Each threat is classified according to:
This threat model only covers elements related to the transport of firmware updates. It explicitly does not cover threats outside of the transport of firmware updates. For example, threats to an IoT device due to physical access are out of scope.
Classification: Elevation of Privilege
An attacker sends an old, but valid manifest with an old, but valid firmware image to a device. If there is a known vulnerability in the provided firmware image, this may allow an attacker to exploit the vulnerability and gain control of the device.
Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to ALL TYPES.
Mitigated by: MFSR1
Classification: Denial of Service
An attacker sends a valid firmware image, for the wrong type of device, signed by an actor with firmware installation permission on both types of device. The firmware is verified by the device positively because it is signed by an actor with the appropriate permission. This could have wide-ranging consequences. For devices that are similar, it could cause minor breakage, or expose security vulnerabilities. For devices that are very different, it is likely to render devices inoperable.
Mitigated by: MFSR2
Classification: Elevation of Privilege
An attacker targets a device that has been offline for a long time and runs an old firmware version. The attacker sends an old, but valid manifest to a device with an old, but valid firmware image. The attacker-provided firmware is newer than the installed one but older than the most recently available firmware. If there is a known vulnerability in the provided firmware image then this may allow an attacker to gain control of a device. Because the device has been offline for a long time, it is unaware of any new updates. As such it will treat the old manifest as the most current.
Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to ALL TYPES.
Mitigated by: MFSR3
Classification: Denial of Service
If a device misinterprets the type of the firmware image, it may cause a device to install a firmware image incorrectly. An incorrectly installed firmware image would likely cause the device to stop functioning.
Threat Escalation: An attacker that can cause a device to misinterpret the received firmware image may gain elevation of privilege and potentially expand this to all types of threat.
Mitigated by: MFSR4
Classification: Denial of Service
If a device installs a firmware image to the wrong location on the device, then it is likely to break. For example, a firmware image installed as an application could cause a device and/or an application to stop functioning.
Threat Escalation: An attacker that can cause a device to misinterpret the received code may gain elevation of privilege and potentially expand this to all types of threat.
Mitigated by: MFSR4
Classification: Denial of Service
If a device does not know where to obtain the payload for an update, it may be redirected to an attacker’s server. This would allow an attacker to provide broken payloads to devices.
Mitigated by: MFSR4
Classification: Elevation of Privilege
An attacker replaces a newly downloaded firmware after a device finishes verifying a manifest. This could cause the device to execute the attacker’s code. This attack likely requires physical access to the device. However, it is possible that this attack is carried out in combination with another threat that allows remote execution.
Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to ALL TYPES.
Mitigated by: MFSR4
Classification: Elevation of Privilege
If an attacker can install their firmware on a device, by manipulating either payload or metadata, then they have complete control of the device.
Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to ALL TYPES.
Mitigated by: MFSR5
Classification: Denial of Service
An attacker sends a valid, current manifest to a device that has an unexpected precursor image. If a payload format requires a precursor image (for example, delta updates) and that precursor image is not available on the target device, it could cause the update to break.
Threat Escalation: An attacker that can cause a device to install a payload against the wrong precursor image could gain elevation of privilege and potentially expand this to all types of threat.
Mitigated by: MFSR4
Classification: Denial of Service, Elevation of Privilege
This threat can appear in several ways, however it is ultimately about interoperability of devices with other systems. The owner or operator of a network needs to approve firmware for their network in order to ensure interoperability with other devices on the network, or the network itself. If the firmware is not qualified, it may not work. Therefore, if a device installs firmware without the approval of the network owner or operator, this is a threat to devices and the network.
Example 1: We assume that OEMs expect the rights to create firmware, but that Operators expect the rights to qualify firmware as fit-for-purpose on their networks.
An attacker obtains a manifest for a device on Network A. They send that manifest to a device on Network B. Because Network A and Network B are different, and the firmware has not been qualified for Network B, the target device is disabled by this unqualified, but signed firmware.
This is a denial of service because it can render devices inoperable. This is an elevation of privilege because it allows the attacker to make installation decisions that should be made by the Operator.
Example 2: Multiple devices that interoperate are used on the same network. Some devices are manufactured by OEM A and other devices by OEM B. These devices communicate with each other. A new firmware is released by OEM A that breaks compatibility with OEM B devices. An attacker sends the new firmware to the OEM A devices without approval of the network operator. This breaks the behaviour of the larger system causing denial of service and possibly other threats. Where the network is a distributed SCADA system, this could cause misbehaviour of the process that is under control.
Threat Escalation: If the firmware expects configuration that is present in Network A devices, but not Network B devices, then the device may experience degraded security, leading to threats of All Types.
Mitigated by: MFSR6
Classification: All Types
An attacker wants to mount an attack on an IoT device. To prepare the attack he or she retrieves the provided firmware image and performs reverse engineering of the firmware image to analyze it for specific vulnerabilities.
Mitigated by: MFSR7
The security requirements here are a set of policies that mitigate the threats described in Section 3.1.
Only an actor with firmware installation authority is permitted to decide when device firmware can be installed. To enforce this rule, Manifests MUST contain monotonically increasing sequence numbers. Manifests MAY use UTC epoch timestamps to coordinate monotonically increasing sequence numbers across many actors in many locations. Devices MUST reject manifests with sequence numbers smaller than any onboard sequence number.
N.B. This is not a firmware version. It is a manifest sequence number. A firmware version may be rolled back by creating a new manifest for the old firmware version with a later sequence number.
Mitigates: Threat MFT1 Implemented by: Manifest Field: Timestamp
Devices MUST only apply firmware that is intended for them. Devices MUST know with fine granularity that a given update applies to their vendor, model, hardware revision, software revision. Human-readable identifiers are often error-prone in this regard, so unique identifiers SHOULD be used.
Mitigates: Threat MFT2 Implemented by: Manifest Fields: Vendor ID Condition, Class ID Condition
Firmware MAY expire after a given time. Devices MAY provide a secure clock (local or remote). If a secure clock is provided and the Firmware manifest has a best-before timestamp, the device MUST reject the manifest if current time is larger than the best-before time.
Mitigates: Threat MFT3 Implemented by: Manifest Field: Best-Before timestamp condition
All descriptive information about the payload MUST be signed. This MUST include:
Mitigates: Threats MFT4, MFT5, MFT6, MFT7, MFT9 Implemented by: Manifest Fields: Vendor ID Condition, Class ID Condition, Precursor Image Digest Condition, Payload Format, Storage Location, URIs, Digests, Size
The authenticity of an update must be demonstrable. Typically, this means that updates must be digitally signed. Because the manifest contains information about how to install the update, the manifest’s authenticity must also be demonstrable. To reduce the overhead required for validation, the manifest contains the digest of the firmware image, rather than a second digital signature. The authenticity of the manifest can be verified with a digital signature, the authenticity of the firmware image is tied to the manifest by the use of a fingerprint of the firmware image.
Mitigates: Threat MFT8 Implemented by: Signature
If a device grants different rights to different actors, exercising those rights MUST be accompanied by proof of those rights, in the form of proof of authenticity. Authenticity mechanisms such as those required in MFSR5 are acceptable but need to follow the end-to-end security model.
For example, if a device has a policy that requires that firmware have both an Authorship right and a Qualification right and if that device grants Authorship and Qualification rights to different parties, such as an OEM and an Operator, respectively, then the firmware cannot be installed without proof of rights from both the OEM and the Operator.
Mitigates: MFT10 Implemented by: Signature
Firmware images must support encryption. Encryption helps to prevent third parties, including attackers, from reading the content of the firmware image and to reverse engineer the code.
Mitigates: MFT11 Implemented by: Manifest Field: Content Key Distribution Method
User stories provide expected use cases. These are used to feed into usability requirements.
As an OEM for IoT devices, I want to provide my devices with additional installation instructions so that I can keep process details out of my payload data.
Some installation instructions might be:
Satisfied by: MFUR1
As an Operator of IoT devices, I would like to tell my devices to look at my own infrastructure for payloads so that I can manage the traffic generated by firmware updates on my network and my peers’ networks.
Satisfied by: MFUR2, MFUR3
As an OEM of IoT devices, I want to divide my firmware into frequently updated and infrequently updated components, so that I can reduce the size of updates and make different parties responsible for different components.
Satisfied by: MFUR3
As an Operator, I want to ensure the quality of a firmware update before installing it, so that I can ensure a high standard of reliability on my network. The OEM may restrict my ability to create firmware, so I cannot be the only authority on the device.
Satisfied by: MFUR4
As an OEM or Operator of devices, I want to be able to send multiple payload formats to suit the needs of my update, so that I can optimise the bandwidth used by my devices.
Satisfied by: MFUR5
As an OEM or developer for IoT devices, I want to protect the IP contained in the firmware image, such as the utilized algorithms. The need for protecting IP may have also been imposed on me due to the use of some third party code libraries.
Satisfied by: MFSR7
The following usability requirements satisfy the user stories listed above.
It must be possible to write additional installation instructions into the manifest.
Satisfies: Use-Case MFUC1 Implemented by: Manifest Field: Directives
It must be possible to redirect payload fetches. This applies where two manifests are used in conjunction. For example, an OEM manifest specifies a payload and signs it, and provides a URI for that payload. An Operator creates a second manifest, with a dependency on the first. They use this second manifest to override the URIs provided by the OEM, directing them into their own infrastructure instead.
Satisfies: Use-Case MFUC2 Implemented by: Manifest Field: Aliases
It MUST be possible to link multiple manifests together so that a multi-component update can be described. This allows multiple parties with different permissions to collaborate in creating a single update for the IoT device, across multiple components.
Satisfies: Use-Case MFUC2, MFUC3 Implemented by: Manifest Field: Dependencies
It MUST be possible to sign a manifest multiple times so that signatures from multiple parties with different permissions can be required in order to authorise installation of a manifest.
Satisfies: Use-Case MFUC4 Implemented by: COSE Signature (or similar)
The manifest format MUST accommodate any payload format that an operator or OEM wishes to use. Some examples of payload format would be:
Satisfies: Use-Case MFUC5 Implemented by: Manifest Field: Payload Format
Each manifest field is anchored in a security requirement or a usability requirement. The manifest fields are described below and justified by their requirements.
An identifier that describes which iteration of the manifest format is contained in the structure.
A monotonically increasing sequence number. For convenience, the monotonic sequence number MAY be a UTC timestamp. This allows global synchronisation of sequence numbers without any additional management.
Implements: Security Requirement MFSR1.
Vendor IDs MUST be unique. This is to prevent similarly, or identically named entities from different geographic regions from colliding in their customer’s infrastructure. Recommended practice is to use version 5 UUIDs with the vendor’s domain name and the UUID DNS prefix [RFC4122]. Other options include version 1 and type 4 UUIDs.
Implements: Security Requirement MFSR2, MFSR4.
Class Identifiers MUST be unique within a Vendor ID. This is to prevent similarly, or identically named devices colliding in their customer’s infrastructure. Recommended practice is to use type 5 UUIDs with the model, hardware revision, etc. and use the Vendor ID as the UUID prefix. Other options include type 1 and type 4 UUIDs. A device “Class” is defined as any device that can run the same firmware without modification. Classes MAY be implemented in a more granular way. Classes MUST NOT be implemented in a less granular way. Class ID can encompass model name, hardware revision, software revision. Devices MAY have multiple Class IDs.
Implements: Security Requirement MFSR2, MFSR4.
When a precursor image is required by the payload format, a precursor image digest condition MUST be present in the conditions list.
Implements: Security Requirement MFSR4
This field tells a device the last application time. This is only usable in conjunction with a secure clock.
Implements: Security Requirement MFSR3
The format of the payload must be indicated to devices in an unambiguous way. This field provides a mechanism to describe the payload format, within the signed metadata.
Implements: Security Requirement MFSR4, Usability Requirement MFUR5
This field tells the device which component is being updated. The device can use this to establish which permissions are necessary and the physical location to use.
Implements: Security Requirement MFSR4
This field is a list of weighted URIs, which are used to select where to obtain a payload.
Implements: Security Requirement MFSR4
This field is a map of digests, each for a separate stage of installation. This allows the target device to ensure authenticity of the payload at every step of installation.
Implements: Security Requirement MFSR4
The size of the payload in bytes.
Implements: Security Requirement MFSR4
This is not strictly a manifest field. Instead, the manifest is wrapped by a standardised authentication container, such as a COSE or CMS signature object. The authentication container MUST support multiple actors and multiple authentications.
Implements: Security Requirement MFSR5, MFSR6, MFUR4
A list of instructions that the device should execute, in order, when installing the payload.
Implements: Usability Requirement MFUR1
A list of URI/Digest pairs. A device is expected to build an alias table while paring a manifest tree and treat any aliases as top-ranked URIs for the corresponding digest.
Implements: Usability Requirement MFUR2
A list of URI/Digest pairs that refer to other manifests by digest. The manifests that are linked in this way must be acquired and installed simultaneously in order to form a complete update.
Implements: Usability Requirement MFUR3
Efficiently encrypting firmware images requires the use of symmetric key cryptography. Since there are several methods to protect or distribute the symmetric content encryption keys, the manifest contains a field for the Content Key Distribution Method. One example for such a Content Key Distribution Method is the usage of Key Tables, pointing to content encryption keys, which themselves are encrypted using the public keys of devices.
Implements: Security Requirement MFSR7.
Security considerations for this document are covered in Section 3.
This document does not require any actions by IANA.
We would like to thank our working group chairs, Dave Thaler, Russ Housley and David Waltermire, for their review comments and their support.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4122] | Leach, P., Mealling, M. and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005. |
| [STRIDE] | Microsoft, "The STRIDE Threat Model", May 2018. |
The discussion list for this document is located at the e-mail address suit@ietf.org. Information on the group and information on how to subscribe to the list is at https://www1.ietf.org/mailman/listinfo/suit
Archives of the list can be found at: https://www.ietf.org/mail-archive/web/suit/current/index.html