Firmware Updates for Internet of Things Devices - An Information Model for Manifests
draft-ietf-suit-information-model-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9124.
|
|
|---|---|---|---|
| Authors | Brendan Moran , Hannes Tschofenig , Henk Birkholz , Jaime Jimenez | ||
| Last updated | 2018-06-04 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
IOTDIR Telechat review
(of
-08)
by Stephen Farrell
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 9124 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-suit-information-model-00
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
Abstract
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.
Status of This Memo
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 December 5, 2018.
Moran, et al. Expires December 5, 2018 [Page 1]
Internet-Draft A Firmware Manifest Information Model June 2018
Copyright Notice
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
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Motivation for Manifest Fields . . . . . . . . . . . . . . . 4
3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 5
3.2.1. Threat MFT1: Old Firmware . . . . . . . . . . . . . . 5
3.2.2. Threat MFT2: Mismatched Firmware . . . . . . . . . . 5
3.2.3. Threat MFT3: Offline device + Old Firmware . . . . . 5
3.2.4. Threat MFT4: The target device misinterprets the type
of payload . . . . . . . . . . . . . . . . . . . . . 6
3.2.5. Threat MFT5: The target device installs the payload
to the wrong location . . . . . . . . . . . . . . . . 6
3.2.6. Threat MFT6: Redirection . . . . . . . . . . . . . . 6
3.2.7. Threat MFT7: Payload Verification on Boot . . . . . . 6
3.2.8. Threat MFT8: Unauthenticated Updates . . . . . . . . 7
3.2.9. Threat MFT9: Unexpected Precursor images . . . . . . 7
3.2.10. Threat MFT10: Unqualified Firmware . . . . . . . . . 7
3.2.11. Threat MFT11: Reverse Engineering Of Firmware Image
for Vulnerability Analysis . . . . . . . . . . . . . 8
Moran, et al. Expires December 5, 2018 [Page 2]
Internet-Draft A Firmware Manifest Information Model June 2018
3.3. Security Requirements . . . . . . . . . . . . . . . . . . 9
3.3.1. Security Requirement MFSR1: Monotonic Sequence
Numbers . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Security Requirement MFSR2: Vendor, Device-type
Identifiers . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Security Requirement MFSR3: Best-Before Timestamps . 9
3.3.4. Security Requirement MFSR4: Signed Payload Descriptor 9
3.3.5. Security Requirement MFSR5: Cryptographic
Authenticity . . . . . . . . . . . . . . . . . . . . 10
3.3.6. Security Requirement MFSR6: Rights Require
Authenticity . . . . . . . . . . . . . . . . . . . . 10
3.3.7. Security Requirement MFSR7: Firmware encryption . . . 11
3.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1. Use Case MFUC1: Installation Instructions . . . . . . 11
3.4.2. Use Case MFUC2: Reuse Local Infrastructure . . . . . 12
3.4.3. Use Case MFUC3: Modular Update . . . . . . . . . . . 12
3.4.4. Use Case MFUC4: Multiple Authorisations . . . . . . . 12
3.4.5. Use Case MFUC5: Multiple Payload Formats . . . . . . 12
3.4.6. Use Case MFUC6: IP Protection . . . . . . . . . . . . 12
3.5. Usability Requirements . . . . . . . . . . . . . . . . . 13
3.5.1. Usability Requirement MFUR1 . . . . . . . . . . . . . 13
3.5.2. Usability Requirement MFUR2 . . . . . . . . . . . . . 13
3.5.3. Usability Requirement MFUR3 . . . . . . . . . . . . . 13
3.5.4. Usability Requirement MFUR4 . . . . . . . . . . . . . 13
3.5.5. Usability Requirement MFUR5 . . . . . . . . . . . . . 13
4. Manifest Fields . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Manifest Version Field: version identifier of the
manifest structure . . . . . . . . . . . . . . . . . . . 14
4.2. Manifest Field: Monotonic Sequence Number . . . . . . . . 14
4.3. Manifest Field: Vendor ID Condition . . . . . . . . . . . 14
4.4. Manifest Field: Class ID Condition . . . . . . . . . . . 15
4.5. Manifest Field: Precursor Image Digest Condition . . . . 15
4.6. Manifest Field: Best-Before timestamp condition . . . . . 15
4.7. Manifest Field: Payload Format . . . . . . . . . . . . . 15
4.8. Manifest Field: Storage Location . . . . . . . . . . . . 15
4.9. Manifest Field: URIs . . . . . . . . . . . . . . . . . . 16
4.10. Manifest Field: Digests . . . . . . . . . . . . . . . . . 16
4.11. Manifest Field: Size . . . . . . . . . . . . . . . . . . 16
4.12. Manifest Field: Signature . . . . . . . . . . . . . . . . 16
4.13. Manifest Field: Directives . . . . . . . . . . . . . . . 16
4.14. Manifest Field: Aliases . . . . . . . . . . . . . . . . . 16
4.15. Manifest Field: Dependencies . . . . . . . . . . . . . . 17
4.16. Manifest Field: Content Key Distribution Method . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
Moran, et al. Expires December 5, 2018 [Page 3]
Internet-Draft A Firmware Manifest Information Model June 2018
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Mailing List Information . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
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.
2. Conventions and Terminology
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].
3. Motivation for Manifest Fields
The following sub-sections describe the threat model, user stories,
security requirements, and usability requirements.
3.1. Threat Model
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:
- Spoofing Identity
- Tampering with data
- Repudiation
- Information disclosure
- Denial of service
- Elevation of privilege
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.
Moran, et al. Expires December 5, 2018 [Page 4]
Internet-Draft A Firmware Manifest Information Model June 2018
3.2. Threat Descriptions
3.2.1. Threat MFT1: Old Firmware
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
3.2.2. Threat MFT2: Mismatched Firmware
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
3.2.3. Threat MFT3: Offline device + Old Firmware
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.
Moran, et al. Expires December 5, 2018 [Page 5]
Internet-Draft A Firmware Manifest Information Model June 2018
Mitigated by: MFSR3
3.2.4. Threat MFT4: The target device misinterprets the type of payload
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
3.2.5. Threat MFT5: The target device installs the payload to the wrong
location
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
3.2.6. Threat MFT6: Redirection
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
3.2.7. Threat MFT7: Payload Verification on Boot
Classification: Elevation of Privilege
Moran, et al. Expires December 5, 2018 [Page 6]
Internet-Draft A Firmware Manifest Information Model June 2018
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
3.2.8. Threat MFT8: Unauthenticated Updates
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
3.2.9. Threat MFT9: Unexpected Precursor images
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
3.2.10. Threat MFT10: Unqualified Firmware
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,
Moran, et al. Expires December 5, 2018 [Page 7]
Internet-Draft A Firmware Manifest Information Model June 2018
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
3.2.11. Threat MFT11: Reverse Engineering Of Firmware Image for
Vulnerability Analysis
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
Moran, et al. Expires December 5, 2018 [Page 8]
Internet-Draft A Firmware Manifest Information Model June 2018
3.3. Security Requirements
The security requirements here are a set of policies that mitigate
the threats described in Section 3.1.
3.3.1. Security Requirement MFSR1: Monotonic Sequence Numbers
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
3.3.2. Security Requirement MFSR2: Vendor, Device-type Identifiers
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
3.3.3. Security Requirement MFSR3: Best-Before Timestamps
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
3.3.4. Security Requirement MFSR4: Signed Payload Descriptor
All descriptive information about the payload MUST be signed. This
MUST include:
- The type of payload (which may be independent of format)
Moran, et al. Expires December 5, 2018 [Page 9]
Internet-Draft A Firmware Manifest Information Model June 2018
- The location to store the payload
- The payload digest, in each state of installation (encrypted,
plaintext, installed, etc.)
- The payload size
- The payload format
- Where to obtain the payload
- All instructions or parameters for applying the payload
- Any rules that identify whether or not the payload can be used on
this device
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
3.3.5. Security Requirement MFSR5: Cryptographic Authenticity
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
3.3.6. Security Requirement MFSR6: Rights Require Authenticity
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
Moran, et al. Expires December 5, 2018 [Page 10]
Internet-Draft A Firmware Manifest Information Model June 2018
firmware cannot be installed without proof of rights from both the
OEM and the Operator.
Mitigates: MFT10 Implemented by: Signature
3.3.7. Security Requirement MFSR7: Firmware encryption
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
3.4. User Stories
User stories provide expected use cases. These are used to feed into
usability requirements.
3.4.1. Use Case MFUC1: Installation Instructions
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:
- Specify a package handler
- Use a table of hashes to ensure that each block of the payload is
validated before writing.
- Run post-processing script after the update is installed
- Do not report progress
- Pre-cache the update, but do not install
- Install the pre-cached update matching this manifest
- Install this update immediately, overriding any long-running
tasks.
Satisfied by: MFUR1
Moran, et al. Expires December 5, 2018 [Page 11]
Internet-Draft A Firmware Manifest Information Model June 2018
3.4.2. Use Case MFUC2: Reuse Local Infrastructure
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
3.4.3. Use Case MFUC3: Modular Update
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
3.4.4. Use Case MFUC4: Multiple Authorisations
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
3.4.5. Use Case MFUC5: Multiple Payload Formats
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
3.4.6. Use Case MFUC6: IP Protection
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
Moran, et al. Expires December 5, 2018 [Page 12]
Internet-Draft A Firmware Manifest Information Model June 2018
3.5. Usability Requirements
The following usability requirements satisfy the user stories listed
above.
3.5.1. Usability Requirement MFUR1
It must be possible to write additional installation instructions
into the manifest.
Satisfies: Use-Case MFUC1 Implemented by: Manifest Field: Directives
3.5.2. Usability Requirement MFUR2
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
3.5.3. Usability Requirement MFUR3
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
3.5.4. Usability Requirement MFUR4
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)
3.5.5. Usability Requirement MFUR5
The manifest format MUST accommodate any payload format that an
operator or OEM wishes to use. Some examples of payload format would
be:
Moran, et al. Expires December 5, 2018 [Page 13]
Internet-Draft A Firmware Manifest Information Model June 2018
- Binary
- Elf
- Differential
- Compressed
- Packed configuration
Satisfies: Use-Case MFUC5 Implemented by: Manifest Field: Payload
Format
4. Manifest Fields
Each manifest field is anchored in a security requirement or a
usability requirement. The manifest fields are described below and
justified by their requirements.
4.1. Manifest Version Field: version identifier of the manifest
structure
An identifier that describes which iteration of the manifest format
is contained in the structure.
4.2. Manifest Field: Monotonic Sequence Number
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.
4.3. Manifest Field: Vendor ID Condition
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.
Moran, et al. Expires December 5, 2018 [Page 14]
Internet-Draft A Firmware Manifest Information Model June 2018
4.4. Manifest Field: Class ID Condition
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.
4.5. Manifest Field: Precursor Image Digest Condition
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
4.6. Manifest Field: Best-Before timestamp condition
This field tells a device the last application time. This is only
usable in conjunction with a secure clock.
Implements: Security Requirement MFSR3
4.7. Manifest Field: Payload Format
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
4.8. Manifest Field: Storage Location
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
Moran, et al. Expires December 5, 2018 [Page 15]
Internet-Draft A Firmware Manifest Information Model June 2018
4.9. Manifest Field: URIs
This field is a list of weighted URIs, which are used to select where
to obtain a payload.
Implements: Security Requirement MFSR4
4.10. Manifest Field: Digests
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
4.11. Manifest Field: Size
The size of the payload in bytes.
Implements: Security Requirement MFSR4
4.12. Manifest Field: Signature
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
4.13. Manifest Field: Directives
A list of instructions that the device should execute, in order, when
installing the payload.
Implements: Usability Requirement MFUR1
4.14. Manifest Field: Aliases
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
Moran, et al. Expires December 5, 2018 [Page 16]
Internet-Draft A Firmware Manifest Information Model June 2018
4.15. Manifest Field: Dependencies
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
4.16. Manifest Field: Content Key Distribution Method
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.
5. Security Considerations
Security considerations for this document are covered in Section 3.
6. IANA Considerations
This document does not require any actions by IANA.
7. Acknowledgements
We would like to thank our working group chairs, Dave Thaler, Russ
Housley and David Waltermire, for their review comments and their
support.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
8.2. Informative References
Moran, et al. Expires December 5, 2018 [Page 17]
Internet-Draft A Firmware Manifest Information Model June 2018
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, <https://www.rfc-
editor.org/info/rfc4122>.
[STRIDE] Microsoft, "The STRIDE Threat Model", May 2018,
<https://msdn.microsoft.com/en-us/library/
ee823878(v=cs.20).aspx>.
8.3. URIs
[1] mailto:suit@ietf.org
Moran, et al. Expires December 5, 2018 [Page 18]
Internet-Draft A Firmware Manifest Information Model June 2018
Appendix A. Mailing List Information
The discussion list for this document is located at the e-mail
address suit@ietf.org [1]. 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
Authors' Addresses
Brendan Moran
Arm Limited
EMail: Brendan.Moran@arm.com
Hannes Tschofenig
Arm Limited
EMail: hannes.tschofenig@gmx.net
Henk Birkholz
Fraunhofer SIT
EMail: henk.birkholz@sit.fraunhofer.de
Jaime Jimenez
Ericsson
EMail: jaime.jimenez@ericsson.com
Moran, et al. Expires December 5, 2018 [Page 19]