< draft-moran-suit-architecture-02.txt   draft-moran-suit-architecture-03.txt >
SUIT B. Moran SUIT B. Moran
Internet-Draft M. Meriac Internet-Draft M. Meriac
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: September 3, 2018 Arm Limited Expires: September 6, 2018 Arm Limited
March 02, 2018 March 05, 2018
A Firmware Update Architecture for Internet of Things Devices A Firmware Update Architecture for Internet of Things Devices
draft-moran-suit-architecture-02 draft-moran-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 44 skipping to change at page 1, line 44
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 16
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Threat Model, User Stories, Security Requirements, Appendix A. Threat Model, User Stories, Security Requirements,
and Usability Requirements . . . . . . . . . . . . . 17 and Usability Requirements . . . . . . . . . . . . . 17
A.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 A.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17
A.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17 A.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17
A.2.1. Threat MFT1: Old Firmware . . . . . . . . . . . . . . 17 A.2.1. Threat MFT1: Old Firmware . . . . . . . . . . . . . . 17
A.2.2. Threat MFT2: Mismatched Firmware . . . . . . . . . . 17 A.2.2. Threat MFT2: Mismatched Firmware . . . . . . . . . . 18
A.2.3. Threat MFT3: Offline device + Old Firmware . . . . . 18 A.2.3. Threat MFT3: Offline device + Old Firmware . . . . . 18
A.2.4. Threat MFT4: The target device misinterprets the type A.2.4. Threat MFT4: The target device misinterprets the type
of payload . . . . . . . . . . . . . . . . . . . . . 18 of payload . . . . . . . . . . . . . . . . . . . . . 18
A.2.5. Threat MFT5: The target device installs the payload A.2.5. Threat MFT5: The target device installs the payload
to the wrong location . . . . . . . . . . . . . . . . 18 to the wrong location . . . . . . . . . . . . . . . . 19
A.2.6. Threat MFT6: Redirection . . . . . . . . . . . . . . 19 A.2.6. Threat MFT6: Redirection . . . . . . . . . . . . . . 19
A.2.7. Threat MFT7: Payload Verification on Boot . . . . . . 19 A.2.7. Threat MFT7: Payload Verification on Boot . . . . . . 19
A.2.8. Threat MFT8: Unauthenticated Updates . . . . . . . . 19 A.2.8. Threat MFT8: Unauthenticated Updates . . . . . . . . 19
A.2.9. Threat MFT9: Unexpected Precursor images . . . . . . 19 A.2.9. Threat MFT9: Unexpected Precursor images . . . . . . 20
A.2.10. Threat MFT10: Unqualified Firmware . . . . . . . . . 19 A.2.10. Threat MFT10: Unqualified Firmware . . . . . . . . . 20
A.2.11. Threat MFT11: Reverse Engineering Of Firmware Image A.2.11. Threat MFT11: Reverse Engineering Of Firmware Image
for Vulnerability Analysis . . . . . . . . . . . . . 20 for Vulnerability Analysis . . . . . . . . . . . . . 21
A.3. Security Requirements . . . . . . . . . . . . . . . . . . 21 A.3. Security Requirements . . . . . . . . . . . . . . . . . . 21
A.3.1. Security Requirement MFSR1: Monotonic Sequence A.3.1. Security Requirement MFSR1: Monotonic Sequence
Numbers . . . . . . . . . . . . . . . . . . . . . . . 21 Numbers . . . . . . . . . . . . . . . . . . . . . . . 21
A.3.2. Security Requirement MFSR2: Vendor, Device-type A.3.2. Security Requirement MFSR2: Vendor, Device-type
Identifiers . . . . . . . . . . . . . . . . . . . . . 21 Identifiers . . . . . . . . . . . . . . . . . . . . . 22
A.3.3. Security Requirement MFSR3: Best-Before Timestamps . 21 A.3.3. Security Requirement MFSR3: Best-Before Timestamps . 22
A.3.4. Security Requirement MFSR4: Signed Payload Descriptor 21 A.3.4. Security Requirement MFSR4: Signed Payload Descriptor 22
A.3.5. Security Requirement MFSR5: Cryptographic A.3.5. Security Requirement MFSR5: Cryptographic
Authenticity . . . . . . . . . . . . . . . . . . . . 22 Authenticity . . . . . . . . . . . . . . . . . . . . 23
A.3.6. Security Requirement MFSR6: Rights Require A.3.6. Security Requirement MFSR6: Rights Require
Authenticity . . . . . . . . . . . . . . . . . . . . 22 Authenticity . . . . . . . . . . . . . . . . . . . . 23
A.3.7. Security Requirement MFSR7: Firmware encryption . . . 23 A.3.7. Security Requirement MFSR7: Firmware encryption . . . 23
A.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 23 A.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 23
A.4.1. Use Case MFUC1: Installation Instructions . . . . . . 23 A.4.1. Use Case MFUC1: Installation Instructions . . . . . . 24
A.4.2. Use Case MFUC2: Reuse Local Infrastructure . . . . . 23 A.4.2. Use Case MFUC2: Reuse Local Infrastructure . . . . . 24
A.4.3. Use Case MFUC3: Modular Update . . . . . . . . . . . 24 A.4.3. Use Case MFUC3: Modular Update . . . . . . . . . . . 24
A.4.4. Use Case MFUC4: Multiple Authorisations . . . . . . . 24 A.4.4. Use Case MFUC4: Multiple Authorisations . . . . . . . 25
A.4.5. Use Case MFUC5: Multiple Payload Formats . . . . . . 24 A.4.5. Use Case MFUC5: Multiple Payload Formats . . . . . . 25
A.4.6. Use Case MFUC6: IP Protection . . . . . . . . . . . . 24 A.4.6. Use Case MFUC6: IP Protection . . . . . . . . . . . . 25
A.5. Usability Requirements . . . . . . . . . . . . . . . . . 24 A.5. Usability Requirements . . . . . . . . . . . . . . . . . 25
A.5.1. Usability Requirement MFUR1 . . . . . . . . . . . . . 24 A.5.1. Usability Requirement MFUR1 . . . . . . . . . . . . . 25
A.5.2. Usability Requirement MFUR2 . . . . . . . . . . . . . 24 A.5.2. Usability Requirement MFUR2 . . . . . . . . . . . . . 25
A.5.3. Usability Requirement MFUR3 . . . . . . . . . . . . . 25 A.5.3. Usability Requirement MFUR3 . . . . . . . . . . . . . 26
A.5.4. Usability Requirement MFUR4 . . . . . . . . . . . . . 25 A.5.4. Usability Requirement MFUR4 . . . . . . . . . . . . . 26
A.5.5. Usability Requirement MFUR5 . . . . . . . . . . . . . 25 A.5.5. Usability Requirement MFUR5 . . . . . . . . . . . . . 26
A.6. Manifest Fields . . . . . . . . . . . . . . . . . . . . . 25 A.6. Manifest Fields . . . . . . . . . . . . . . . . . . . . . 26
A.6.1. Manifest Field: Timestamp . . . . . . . . . . . . . . 25 A.6.1. Manifest Field: Timestamp . . . . . . . . . . . . . . 27
A.6.2. Manifest Field: Vendor ID Condition . . . . . . . . . 26 A.6.2. Manifest Field: Vendor ID Condition . . . . . . . . . 27
A.6.3. Manifest Field: Class ID Condition . . . . . . . . . 26 A.6.3. Manifest Field: Class ID Condition . . . . . . . . . 27
A.6.4. Manifest Field: Precursor Image Digest Condition . . 26 A.6.4. Manifest Field: Precursor Image Digest Condition . . 27
A.6.5. Manifest Field: Best-Before timestamp . . . . . . . . 26 A.6.5. Manifest Field: Best-Before timestamp condition . . . 27
A.6.6. Manifest Field: Payload Format . . . . . . . . . . . 26 A.6.6. Manifest Field: Payload Format . . . . . . . . . . . 28
A.6.7. Manifest Field: Storage Location . . . . . . . . . . 27 A.6.7. Manifest Field: Storage Location . . . . . . . . . . 28
A.6.8. Manifest Field: URIs . . . . . . . . . . . . . . . . 27 A.6.8. Manifest Field: URIs . . . . . . . . . . . . . . . . 28
A.6.9. Manifest Field: Digests . . . . . . . . . . . . . . . 27 A.6.9. Manifest Field: Digests . . . . . . . . . . . . . . . 28
A.6.10. Manifest Field: Size . . . . . . . . . . . . . . . . 27 A.6.10. Manifest Field: Size . . . . . . . . . . . . . . . . 28
A.6.11. Manifest Field: Signature . . . . . . . . . . . . . . 27 A.6.11. Manifest Field: Signature . . . . . . . . . . . . . . 28
A.6.12. Manifest Field: Directives . . . . . . . . . . . . . 27 A.6.12. Manifest Field: Directives . . . . . . . . . . . . . 29
A.6.13. Manifest Field: Aliases . . . . . . . . . . . . . . . 28 A.6.13. Manifest Field: Aliases . . . . . . . . . . . . . . . 29
A.6.14. Manifest Field: Dependencies . . . . . . . . . . . . 28 A.6.14. Manifest Field: Dependencies . . . . . . . . . . . . 29
A.6.15. Manifest Field: Content Key Distribution Method . . . 28 A.6.15. Manifest Field: Content Key Distribution Method . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 or where manual intervention is cost remote or inaccessible areas or where manual intervention is cost
prohibitive or otherwise difficult. The need for a firmware update prohibitive or otherwise difficult. The need for a firmware update
may be to fix bugs in software, to add new functionality, or to re- may be to fix bugs in software, to add new functionality, or to re-
skipping to change at page 7, line 18 skipping to change at page 7, line 18
Note: This is an implementation requirement rather than a requirement Note: This is an implementation requirement rather than a requirement
on the manifest format. on the manifest format.
3.6. Operates with a small bootloader 3.6. Operates with a small bootloader
The bootloader must be minimal, containing only flash support, The bootloader must be minimal, containing only flash support,
cryptographic primitives and optionally a recovery mechanism. The cryptographic primitives and optionally a recovery mechanism. The
recovery mechanism is used in case the update process failed and may recovery mechanism is used in case the update process failed and may
include support for firmware updates over serial, USB or even a include support for firmware updates over serial, USB or even a
limited version of Bluetooth Smart. Such a recovery mechanism must limited version of wireless connectivity standard like a limited
provide security at least at the same level as the full featured Bluetooth Smart. Such a recovery mechanism must provide security at
firmware update functionalities. least at the same level as the full featured firmware update
functionalities.
The bootloader needs to verify the received manifest and to install The bootloader needs to verify the received manifest and to install
the bootable firmware image. The bootloader should not require the bootable firmware image. The bootloader should not require
updating since a failed update poses a risk in reliability. If more updating since a failed update poses a risk in reliability. If more
functionality is required in the bootloader, it must use a two-stage functionality is required in the bootloader, it must use a two-stage
bootloader, with the first stage comprising the functionality defined bootloader, with the first stage comprising the functionality defined
above. above.
All information necessary for a device to make a decision about the All information necessary for a device to make a decision about the
installation of a firmware update must fit into the available RAM of installation of a firmware update must fit into the available RAM of
skipping to change at page 17, line 28 skipping to change at page 17, line 28
- Tampering with data - Tampering with data
- Repudiation - Repudiation
- Information disclosure - Information disclosure
- Denial of service - Denial of service
- Elevation of privilege - 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.
A.2. Threat Descriptions A.2. Threat Descriptions
A.2.1. Threat MFT1: Old Firmware A.2.1. Threat MFT1: Old Firmware
Classification: Escalation of Privilege Classification: Escalation of Privilege
An attacker sends an old, but valid manifest with an old, but valid 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 firmware image to a device. If there is a known vulnerability in the
provided firmware image, this may allow an attacker to exploit the provided firmware image, this may allow an attacker to exploit the
vulnerability and gain control of the device. vulnerability and gain control of the device.
Threat Escalation: If the attacker is able to exploit the known Threat Escalation: If the attacker is able to exploit the known
vulnerability, then this threat can be escalated to ALL TYPES. vulnerability, then this threat can be escalated to ALL TYPES.
Mitigated by: MFSR1
A.2.2. Threat MFT2: Mismatched Firmware A.2.2. Threat MFT2: Mismatched Firmware
Classification: Denial of Service Classification: Denial of Service
An attacker sends a valid firmware image, for the wrong type of An attacker sends a valid firmware image, for the wrong type of
device, signed by an actor with firmware installation permission on device, signed by an actor with firmware installation permission on
both types of device. The firmware is verified by the device both types of device. The firmware is verified by the device
positively because it is signed by an actor with the appropriate positively because it is signed by an actor with the appropriate
permission. This could have wide-ranging consequences. For devices permission. This could have wide-ranging consequences. For devices
that are similar, it could cause minor breakage, or expose security that are similar, it could cause minor breakage, or expose security
vulnerabilities. For devices that are very different, it is likely vulnerabilities. For devices that are very different, it is likely
to render devices inoperable. to render devices inoperable.
Mitigated by: MFSR2
A.2.3. Threat MFT3: Offline device + Old Firmware A.2.3. Threat MFT3: Offline device + Old Firmware
Classification: Escalation of Privilege Classification: Escalation of Privilege
An attacker targets a device that has been offline for a long time 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 and runs an old firmware version. The attacker sends an old, but
valid manifest to a device with an old, but valid firmware image. valid manifest to a device with an old, but valid firmware image.
The attacker-provided firmware is newer than the installed one but The attacker-provided firmware is newer than the installed one but
older than the most recently available firmware. If there is a known older than the most recently available firmware. If there is a known
vulnerability in the provided firmware image then this may allow an vulnerability in the provided firmware image then this may allow an
attacker to gain control of a device. Because the device has been 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 offline for a long time, it is unaware of any new updates. As such
it will treat the old manifest as the most current. it will treat the old manifest as the most current.
Threat Escalation: If the attacker is able to exploit the known Threat Escalation: If the attacker is able to exploit the known
vulnerability, then this threat can be escalated to ALL TYPES. vulnerability, then this threat can be escalated to ALL TYPES.
Mitigated by: MFSR3
A.2.4. Threat MFT4: The target device misinterprets the type of payload A.2.4. Threat MFT4: The target device misinterprets the type of payload
Classification: Denial of Service Classification: Denial of Service
If a device misinterprets the type of the firmware image, it may If a device misinterprets the type of the firmware image, it may
cause a device to install a firmware image incorrectly. An cause a device to install a firmware image incorrectly. An
incorrectly installed firmware image would likely cause the device to incorrectly installed firmware image would likely cause the device to
stop functioning. stop functioning.
Threat Escalation: An attacker that can cause a device to Threat Escalation: An attacker that can cause a device to
misinterpret the received firmware image may gain escalation of misinterpret the received firmware image may gain escalation of
privilege and potentially expand this to all types of threat. privilege and potentially expand this to all types of threat.
Mitigated by: MFSR4
A.2.5. Threat MFT5: The target device installs the payload to the wrong A.2.5. Threat MFT5: The target device installs the payload to the wrong
location location
Classification: Denial of Service Classification: Denial of Service
If a device installs a firmware image to the wrong location on the 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 device, then it is likely to break. For example, a firmware image
installed as an application could cause a device and/or an installed as an application could cause a device and/or an
application to stop functioning. application to stop functioning.
Threat Escalation: An attacker that can cause a device to Threat Escalation: An attacker that can cause a device to
misinterpret the received code may gain escalation of privilege and misinterpret the received code may gain escalation of privilege and
potentially expand this to all types of threat. potentially expand this to all types of threat.
Mitigated by: MFSR4
A.2.6. Threat MFT6: Redirection A.2.6. Threat MFT6: Redirection
Classification: Denial of Service Classification: Denial of Service
If a device does not know where to obtain the payload for an update, 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 it may be redirected to an attacker's server. This would allow an
attacker to provide broken payloads to devices. attacker to provide broken payloads to devices.
Mitigated by: MFSR4
A.2.7. Threat MFT7: Payload Verification on Boot A.2.7. Threat MFT7: Payload Verification on Boot
Classification: All Types Classification: All Types
An attacker replaces a newly downloaded firmware after a device An attacker replaces a newly downloaded firmware after a device
finishes verifying a manifest. This could cause the device to finishes verifying a manifest. This could cause the device to
execute the attacker's code. This attack likely requires physical execute the attacker's code. This attack likely requires physical
access to the device. However, it is possible that this attack is access to the device. However, it is possible that this attack is
carried out in combination with another threat that allows remote carried out in combination with another threat that allows remote
execution. execution.
Mitigated by: MFSR4
A.2.8. Threat MFT8: Unauthenticated Updates A.2.8. Threat MFT8: Unauthenticated Updates
Classification: All Types Classification: All Types
If an attacker can install their firmware on a device, by If an attacker can install their firmware on a device, by
manipulating either payload or metadata, then they have complete manipulating either payload or metadata, then they have complete
control of the device. control of the device.
Mitigated by: MFSR5
A.2.9. Threat MFT9: Unexpected Precursor images A.2.9. Threat MFT9: Unexpected Precursor images
Classification: Denial of Service Classification: Denial of Service
An attacker sends a valid, current manifest to a device that has an An attacker sends a valid, current manifest to a device that has an
unexpected precursor image. If a payload format requires a precursor unexpected precursor image. If a payload format requires a precursor
image (for example, delta updates) and that precursor image is not image (for example, delta updates) and that precursor image is not
available on the target device, it could cause the update to break. available on the target device, it could cause the update to break.
Threat Escalation: An attacker that can cause a device to install a Threat Escalation: An attacker that can cause a device to install a
payload against the wrong precursor image could gain escalation of payload against the wrong precursor image could gain escalation of
privilege and potentially expand this to all types of threat. privilege and potentially expand this to all types of threat.
Mitigated by: MFSR4
A.2.10. Threat MFT10: Unqualified Firmware A.2.10. Threat MFT10: Unqualified Firmware
Classification: Denial of Service, Escalation of Privilege Classification: Denial of Service, Escalation of Privilege
This threat can appear in several ways, however it is ultimately This threat can appear in several ways, however it is ultimately
about interoperability of devices with other systems. The owner or about interoperability of devices with other systems. The owner or
operator of a network needs to approve firmware for their network in operator of a network needs to approve firmware for their network in
order to ensure interoperability with other devices on the network, order to ensure interoperability with other devices on the network,
or the network itself. If the firmware is not qualified, it may not or the network itself. If the firmware is not qualified, it may not
work. Therefore, if a device installs firmware without the approval work. Therefore, if a device installs firmware without the approval
skipping to change at page 20, line 38 skipping to change at page 21, line 13
of the network operator. This breaks the behaviour of the larger of the network operator. This breaks the behaviour of the larger
system causing denial of service and possibly other threats. Where system causing denial of service and possibly other threats. Where
the network is a distributed SCADA system, this could cause the network is a distributed SCADA system, this could cause
misbehaviour of the process that is under control. misbehaviour of the process that is under control.
Threat Escalation: If the firmware expects configuration that is Threat Escalation: If the firmware expects configuration that is
present in Network A devices, but not Network B devices, then the present in Network A devices, but not Network B devices, then the
device may experience degraded security, leading to threats of All device may experience degraded security, leading to threats of All
Types. Types.
Mitigated by: MFSR6
A.2.11. Threat MFT11: Reverse Engineering Of Firmware Image for A.2.11. Threat MFT11: Reverse Engineering Of Firmware Image for
Vulnerability Analysis Vulnerability Analysis
Classification: All Types Classification: All Types
An attacker wants to mount an attack on an IoT device. To prepare An attacker wants to mount an attack on an IoT device. To prepare
the attack he or she retrieves the provided firmware image and the attack he or she retrieves the provided firmware image and
performs reverse engineering of the firmware image to analyze it for performs reverse engineering of the firmware image to analyze it for
specific vulnerabilities. specific vulnerabilities.
Mitigated by: MFSR7
A.3. Security Requirements A.3. Security Requirements
The security requirements here are a set of policies that mitigate The security requirements here are a set of policies that mitigate
the threats described in the previous section. the threats described in the previous section.
A.3.1. Security Requirement MFSR1: Monotonic Sequence Numbers A.3.1. Security Requirement MFSR1: Monotonic Sequence Numbers
Only an actor with firmware installation authority is permitted to Only an actor with firmware installation authority is permitted to
decide when device firmware can be installed. To enforce this rule, decide when device firmware can be installed. To enforce this rule,
Manifests MUST contain monotonically increasting sequence numbers. Manifests MUST contain monotonically increasting sequence numbers.
Manifests MAY use UTC epoch timestamps to coordinate monotonically Manifests MAY use UTC epoch timestamps to coordinate monotonically
increasting sequence numbers across many actors in many locations. increasting sequence numbers across many actors in many locations.
Devices MUST reject manifests with sequence numbers smaller than any Devices MUST reject manifests with sequence numbers smaller than any
onboard sequence number. onboard sequence number.
N.B. This is not a firmware version. It is a manifest sequence 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 number. A firmware version may be rolled back by creating a new
manifest for the old firmware version with a later sequence number. manifest for the old firmware version with a later sequence number.
Mitigates: Threat MFT1 Mitigates: Threat MFT1 Implemented by: Manifest Field: Timestamp
A.3.2. Security Requirement MFSR2: Vendor, Device-type Identifiers A.3.2. Security Requirement MFSR2: Vendor, Device-type Identifiers
Devices MUST only apply firmware that is intended for them. Devices Devices MUST only apply firmware that is intended for them. Devices
MUST know with fine granularity that a given update applies to their MUST know with fine granularity that a given update applies to their
vendor, model, hardware revision, software revision. Human-readable vendor, model, hardware revision, software revision. Human-readable
identifiers are often error-prone in this regard, so unique identifiers are often error-prone in this regard, so unique
identifiers SHOULD be used. identifiers SHOULD be used.
Mitigates: Threat MFT2 Mitigates: Threat MFT2 Implemented by: Manifest Fields: Vendor ID
Condition, Class ID Condition
A.3.3. Security Requirement MFSR3: Best-Before Timestamps A.3.3. Security Requirement MFSR3: Best-Before Timestamps
Firmware MAY expire after a given time. Devices MAY provide a secure Firmware MAY expire after a given time. Devices MAY provide a secure
clock (local or remote). If a secure clock is provided and the clock (local or remote). If a secure clock is provided and the
Firmware manifest has a best-before timestamp, the device MUST reject Firmware manifest has a best-before timestamp, the device MUST reject
the manifest if current time is larger than the best-before time. the manifest if current time is larger than the best-before time.
Mitigates: Threat MFT3 Mitigates: Threat MFT3 Implemented by: Manifest Field: Best-Before
timestamp condition
A.3.4. Security Requirement MFSR4: Signed Payload Descriptor A.3.4. Security Requirement MFSR4: Signed Payload Descriptor
All descriptive information about the payload MUST be signed. This All descriptive information about the payload MUST be signed. This
MUST include: MUST include:
- The type of payload (which may be independent of format)
- The location to store the payload - The location to store the payload
- The payload digest, in each state of installation (encrypted, - The payload digest, in each state of installation (encrypted,
plaintext, installed, etc.) plaintext, installed, etc.)
- The payload size - The payload size
- The payload format - The payload format
- Where to obtain the payload - Where to obtain the payload
- All instructions or parameters for applying the payload - All instructions or parameters for applying the payload
- Any rules that identify whether or not the payload can be used on - Any rules that identify whether or not the payload can be used on
this device this device
Mitigates: Threats MFT5, MFT6, MFT7, MFT9 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
A.3.5. Security Requirement MFSR5: Cryptographic Authenticity A.3.5. Security Requirement MFSR5: Cryptographic Authenticity
The authenticity of an update must be demonstrable. Typically, this The authenticity of an update must be demonstrable. Typically, this
means that updates must be digitally signed. Because the manifest means that updates must be digitally signed. Because the manifest
contains information about how to install the update, the manifest's contains information about how to install the update, the manifest's
authenticity must also be demonstrable. To reduce the overhead authenticity must also be demonstrable. To reduce the overhead
required for validation, the manifest contains the digest of the required for validation, the manifest contains the digest of the
firmware image, rather than a second digitial signature. The firmware image, rather than a second digitial signature. The
authenticity of the manifest can be verified with a digital authenticity of the manifest can be verified with a digital
signature, the authenticity of the firmware image is tied to the signature, the authenticity of the firmware image is tied to the
manifest by the use of a fingerprint of the firmware image. manifest by the use of a fingerprint of the firmware image.
Mitigates: Threat MFT8 Mitigates: Threat MFT8 Implemented by: Signature
A.3.6. Security Requirement MFSR6: Rights Require Authenticity A.3.6. Security Requirement MFSR6: Rights Require Authenticity
If a device grants different rights to different actors, exercising If a device grants different rights to different actors, exercising
those rights MUST be accompanied by proof of those rights, in the those rights MUST be accompanied by proof of those rights, in the
form of proof of authenticity. Authenticity mechanisms such as those form of proof of authenticity. Authenticity mechanisms such as those
required in MFSR5 are acceptable but need to follow the end-to-end required in MFSR5 are acceptable but need to follow the end-to-end
security model. security model.
For example, if a device has a policy that requires that firmware For example, if a device has a policy that requires that firmware
have both an Authorship right and a Qualification right and if that have both an Authorship right and a Qualification right and if that
device grants Authorship and Qualification rights to different device grants Authorship and Qualification rights to different
parties, such as an OEM and an Operator, respectively, then the parties, such as an OEM and an Operator, respectively, then the
firmware cannot be installed without proof of rights from both the firmware cannot be installed without proof of rights from both the
OEM and the Operator. OEM and the Operator.
Mitigates: MFT10 Mitigates: MFT10 Implemented by: Signature
A.3.7. Security Requirement MFSR7: Firmware encryption A.3.7. Security Requirement MFSR7: Firmware encryption
Firmware images must be encrypted to prevent third parties, including Firmware images must be encrypted to prevent third parties, including
attackers, from reading the content of the firmware image and to attackers, from reading the content of the firmware image and to
reverse engineer the code. reverse engineer the code.
Mitigates: MFT11 Mitigates: MFT11 Implemented by: Manifest Field: Content Key
Distribution Method
A.4. User Stories A.4. User Stories
User stories provide expected use cases. These are used to feed into User stories provide expected use cases. These are used to feed into
usability requirements. usability requirements.
A.4.1. Use Case MFUC1: Installation Instructions A.4.1. Use Case MFUC1: Installation Instructions
As an OEM for IoT devices, I want to provide my devices with As an OEM for IoT devices, I want to provide my devices with
additional installation instructions so that I can keep process additional installation instructions so that I can keep process
skipping to change at page 23, line 42 skipping to change at page 24, line 29
- Do not report progress - Do not report progress
- Pre-cache the update, but do not install - Pre-cache the update, but do not install
- Install the pre-cached update matching this manifest - Install the pre-cached update matching this manifest
- Install this update immediately, overriding any long-running - Install this update immediately, overriding any long-running
tasks. tasks.
Satisfied by: MFUR1
A.4.2. Use Case MFUC2: Reuse Local Infrastructure A.4.2. Use Case MFUC2: Reuse Local Infrastructure
As an Operator of IoT devices, I would like to tell my devices to 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 look at my own infrastructure for payloads so that I can manage the
traffic generated by firmware updates on my network and my peers' traffic generated by firmware updates on my network and my peers'
networks. networks.
Satisfied by: MFUR2, MFUR3
A.4.3. Use Case MFUC3: Modular Update A.4.3. Use Case MFUC3: Modular Update
As an OEM of IoT devices, I want to divide my firmware into As an OEM of IoT devices, I want to divide my firmware into
frequently updated and infrequently updated components, so that I can frequently updated and infrequently updated components, so that I can
reduce the size of updates and make different parties responsible for reduce the size of updates and make different parties responsible for
different components. different components.
Satisfied by: MFUR3
A.4.4. Use Case MFUC4: Multiple Authorisations A.4.4. Use Case MFUC4: Multiple Authorisations
As an Operator, I want to ensure the quality of a firmware update 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 before installing it, so that I can ensure a high standard of
reliability on my network. The OEM may restrict my ability to create reliability on my network. The OEM may restrict my ability to create
firmware, so I cannot be the only authority on the device. firmware, so I cannot be the only authority on the device.
Satisfied by: MFUR4
A.4.5. Use Case MFUC5: Multiple Payload Formats A.4.5. Use Case MFUC5: Multiple Payload Formats
As a OEM or Operator of devices, I want to be able to send multiple As a 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 payload formats to suit the needs of my update, so that I can
optimise the bandwidth used by my devices. optimise the bandwidth used by my devices.
Satisfied by: MFUR5
A.4.6. Use Case MFUC6: IP Protection A.4.6. Use Case MFUC6: IP Protection
As an OEM or developer for IoT devices, I want to protect the IP As an OEM or developer for IoT devices, I want to protect the IP
contained in the firmware image, such as the utilized algorithms. contained in the firmware image, such as the utilized algorithms.
The need for protecting IP may have also been imposed on my due to The need for protecting IP may have also been imposed on my due to
the use of some third party code libraries. the use of some third party code libraries.
Satisfied by: MFSR7
A.5. Usability Requirements A.5. Usability Requirements
The following usability requirements satisfy the user stories listed The following usability requirements satisfy the user stories listed
above. above.
A.5.1. Usability Requirement MFUR1 A.5.1. Usability Requirement MFUR1
It must be possible to write additional installation instructions It must be possible to write additional installation instructions
into the manifest. into the manifest.
Satisfies Use-Case MFUC1 Satisfies: Use-Case MFUC1 Implemented by: Manifest Field: Directives
A.5.2. Usability Requirement MFUR2 A.5.2. Usability Requirement MFUR2
It must be possible to redirect payload fetches. This applies where It must be possible to redirect payload fetches. This applies where
two manifests are used in conjunction. For example, an OEM manifest two manifests are used in conjunction. For example, an OEM manifest
specifies a payload and signs it, and provides a URI for that specifies a payload and signs it, and provides a URI for that
payload. An Operator creates a second manifest, with a dependency on payload. An Operator creates a second manifest, with a dependency on
the first. They use this second manifest to override the URIs the first. They use this second manifest to override the URIs
provided by the OEM, directing them into their own infrastructure provided by the OEM, directing them into their own infrastructure
instead. instead.
Satisfies Use-Case MFUC2 Satisfies: Use-Case MFUC2 Implemented by: Manifest Field: Aliases
A.5.3. Usability Requirement MFUR3 A.5.3. Usability Requirement MFUR3
It MUST be possible to link multiple manifests together so that a It MUST be possible to link multiple manifests together so that a
multi-component update can be described. This allows multiple multi-component update can be described. This allows multiple
parties with different permissions to collaborate in creating a parties with different permissions to collaborate in creating a
single update for the IoT device, across multiple components. single update for the IoT device, across multiple components.
Satisfies Use-Case MFUC2, MFUC3 Satisfies: Use-Case MFUC2, MFUC3 Implemented by: Manifest Field:
Dependencies
A.5.4. Usability Requirement MFUR4 A.5.4. Usability Requirement MFUR4
It MUST be possible to sign a manifest multiple times so that It MUST be possible to sign a manifest multiple times so that
signatures from multiple parties with different permissions can be signatures from multiple parties with different permissions can be
required in order to authorise installation of a manifest. required in order to authorise installation of a manifest.
Satisfies Use-Case MFUC4 Satisfies: Use-Case MFUC4 Implemented by: COSE Signature (or similar)
A.5.5. Usability Requirement MFUR5 A.5.5. Usability Requirement MFUR5
The manifest format MUST accommodate any payload format that an The manifest format MUST accommodate any payload format that an
operator or OEM wishes to use. Some examples of payload format would operator or OEM wishes to use. Some examples of payload format would
be: be:
- Binary - Binary
- Elf - Elf
- Differential - Differential
- Compressed - Compressed
- Packed configuration - Packed configuration
Satisfies Use-Case MFUC5 Satisfies: Use-Case MFUC5 Implemented by: Manifest Field: Payload
Format
A.6. Manifest Fields A.6. Manifest Fields
Each manifest field is anchored in a security requirement or a Each manifest field is anchored in a security requirement or a
usability requirement. The manifest fields are described below and usability requirement. The manifest fields are described below and
justified by their requirements. justified by their requirements.
A.6.1. Manifest Field: Timestamp A.6.1. Manifest Field: Timestamp
A monotonically increasing sequence number A monotonically increasing sequence number. For convenience, a
timestamp implements the requirement of a monotonically increasing
sequence number. This allows global synchronisation of sequence
numbers without any additional management.
Implements: Security Requirement MFSR1. Implements: Security Requirement MFSR1.
A.6.2. Manifest Field: Vendor ID Condition A.6.2. Manifest Field: Vendor ID Condition
Vendor IDs MUST be unique. This is to prevent similarly, or Vendor IDs MUST be unique. This is to prevent similarly, or
identically named entities from different geographic regions from identically named entities from different geographic regions from
colliding in their customer's infrastructure. Recommended practice colliding in their customer's infrastructure. Recommended practice
is to use type 5 UUIDs with the vendor's domain name and the UUID DNS is to use type 5 UUIDs with the vendor's domain name and the UUID DNS
prefix. Other options include type 1 and type 4 UUIDs. prefix. Other options include type 1 and type 4 UUIDs.
skipping to change at page 26, line 37 skipping to change at page 27, line 46
Implements: Security Requirement MFSR2, MFSR4. Implements: Security Requirement MFSR2, MFSR4.
A.6.4. Manifest Field: Precursor Image Digest Condition A.6.4. Manifest Field: Precursor Image Digest Condition
When a precursor image is required by the payload format, a precursor When a precursor image is required by the payload format, a precursor
image digest condition MUST be present in the conditions list. image digest condition MUST be present in the conditions list.
Implements: Security Requirement MFSR4 Implements: Security Requirement MFSR4
A.6.5. Manifest Field: Best-Before timestamp A.6.5. Manifest Field: Best-Before timestamp condition
This field tells a device the last application time. This is only This field tells a device the last application time. This is only
usable in conjunction with a secure clock. usable in conjunction with a secure clock.
Implements Security Requirement MFSR3 Implements: Security Requirement MFSR3
A.6.6. Manifest Field: Payload Format A.6.6. Manifest Field: Payload Format
The format of the payload must be indicated to devices is in an The format of the payload must be indicated to devices is in an
unambiguous way. This field provides a mechanism to describe the unambiguous way. This field provides a mechanism to describe the
payload format, within the signed metadata. payload format, within the signed metadata.
Implements Security Requirement MFSR4, Usability Requirement MFUR5 Implements: Security Requirement MFSR4, Usability Requirement MFUR5
A.6.7. Manifest Field: Storage Location A.6.7. Manifest Field: Storage Location
This field tells the device which component is being updated. The This field tells the device which component is being updated. The
device can use this to establish which permissions are necessary and device can use this to establish which permissions are necessary and
the physical location to use. the physical location to use.
Implements Security Requirement MFSR4 Implements: Security Requirement MFSR4
A.6.8. Manifest Field: URIs A.6.8. Manifest Field: URIs
This field is a list of weighted URIs that the device uses to select This field is a list of weighted URIs that the device uses to select
where to obtain a payload. where to obtain a payload.
Implements Security Requirement MFSR4 Implements: Security Requirement MFSR4
A.6.9. Manifest Field: Digests A.6.9. Manifest Field: Digests
This field is a map of digests, each for a separate stage of This field is a map of digests, each for a separate stage of
installation. This allows the target device to ensure authenticity installation. This allows the target device to ensure authenticity
of the payload at every step of installation. of the payload at every step of installation.
Implements Security Requirement MFSR4 Implements: Security Requirement MFSR4
A.6.10. Manifest Field: Size A.6.10. Manifest Field: Size
The size of the payload in bytes. The size of the payload in bytes.
Implements Security Requirement MFSR4 Implements: Security Requirement MFSR4
A.6.11. Manifest Field: Signature A.6.11. Manifest Field: Signature
This is not strictly a manifest field. Instead, the manifest is This is not strictly a manifest field. Instead, the manifest is
wrapped by a standardised authentication container, such as a COSE or wrapped by a standardised authentication container, such as a COSE or
CMS signature object. The authentication container MUST support CMS signature object. The authentication container MUST support
multiple actors and multiple authentications. multiple actors and multiple authentications.
Implements Security Requirement MFSR5, MFSR6, MFUR4 Implements: Security Requirement MFSR5, MFSR6, MFUR4
A.6.12. Manifest Field: Directives A.6.12. Manifest Field: Directives
A list of instructions that the device should execute, in order, when A list of instructions that the device should execute, in order, when
installing the payload. installing the payload.
Implements Usability Requirement MFUR1 Implements: Usability Requirement MFUR1
A.6.13. Manifest Field: Aliases A.6.13. Manifest Field: Aliases
A list of URI/Digest pairs. A device should build an alias table A list of URI/Digest pairs. A device should build an alias table
while paring a manifest tree and treat any aliases as top-ranked URIs while paring a manifest tree and treat any aliases as top-ranked URIs
for the corresponding digest. for the corresponding digest.
Implements Usability Requirement MFUR2 Implements: Usability Requirement MFUR2
A.6.14. Manifest Field: Dependencies A.6.14. Manifest Field: Dependencies
A list of URI/Digest pairs that refer to other manifests by digest. 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 The manifests that are linked in this way must be acquired and
installed simultaneously in order to form a complete update. installed simultaneously in order to form a complete update.
Implements Usability Requirement MFUR3 Implements: Usability Requirement MFUR3
A.6.15. Manifest Field: Content Key Distribution Method A.6.15. Manifest Field: Content Key Distribution Method
Encrypting firmware images requires symmetric content encryption Encrypting firmware images requires symmetric content encryption
keys. Since there are several methods to protect or distribute the keys. Since there are several methods to protect or distribute the
symmetric content encryption keys, the manifest contains a field for symmetric content encryption keys, the manifest contains a field for
the Content Key Distribution Method. One examples for such a Content the Content Key Distribution Method. One examples for such a Content
Key Distribution Method is the usage of Key Tables, pointing to Key Distribution Method is the usage of Key Tables, pointing to
content encryption keys, which themselves are encrypted using the content encryption keys, which themselves are encrypted using the
public keys of devices. public keys of devices.
 End of changes. 58 change blocks. 
69 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/