Arm Limited

Brendan.Moran@arm.com

Arm Limited

Milosch.Meriac@arm.com

Arm Limited

hannes.tschofenig@gmx.net

Security SUIT Internet-Draft 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. This document lists requirements and describes an architecture for a firmware update mechanism suitable for IoT devices. The architecture is agnostic to the transport of the firmware images and associated meta-data. This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices.

When developing IoT devices, one of the most difficult problems to solve is how to update the firmware on the device. Once the device is deployed, firmware updates play a critical part in its lifetime, particularly when devices have a long lifetime, are deployed in remote or inaccessible areas or where manual intervention is cost prohibitive or otherwise difficult. The need for a firmware update may be to fix bugs in software, to add new functionality, or to re-configure the device. The firmware update process has to ensure that The firmware image is authenticated and attempts to flash a malicious firmware image are prevented. The firmware image can be confidentiality protected so that attempts by an adversary to recover the plaintext binary can be prevented. Obtaining the plaintext binary is often one of the first steps for an attack to mount an attack.

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 . This document uses the following terms: Manifest: The manifest contains meta-data about the firmware image. The manifest is protected against modification and provides information about the author. Firmware Image: The firmware image is a binary that may contain the complete software of a device or a subset of it. The firmware image may consist of multiple images, if the device contains more than one microcontroller. The image may consist of a differential update for performance reasons. Firmware is the more universal term. Both terms are used in this document and are interchangeable. The following entities are used: Author: The author is the entity that creates the firmware image, signs and/or encrypts it and attaches a manifest to it. The author is most likely a developer using a set of tools. Device: The device is the recipient of the firmware image and the manifest. The goal is to update the firmware of the device. Untrusted Storage: Firmware images and manifests are stored on untrusted fileservers or cloud storage infrastructure. Some deployments may require storage of the firmware images/manifests to be stored on various entities before they reach the device.

The firmware update mechanism described in this specification was designed with the following requirements in mind: Agnostic to how firmware images are distributed Friendly to broadcast delivery Uses state-of-the-art security mechanisms Rollback attacks must be prevented. High reliability Operates with a small bootloader Small Parsers Minimal impact on existing firmware formats Robust permissions

Firmware images can be conveyed to devices in a variety of ways, including USB, UART, WiFi, BLE, low-power WAN technologies, etc and use different protocols (e.g., CoAP, HTTP). The specified mechanism needs to be agnostic to the distribution of the firmware images and manifests.

For an update to be broadcast friendly, it cannot rely on link layer, network layer, or transport layer security. In addition, the same message must be deliverable to many devices; both those to which it applies and those to which it does not without a chance that the wrong device will accept the update. Considerations that apply to network broadcasts apply equally to the use of third-party content distribution networks for payload distribution.

End-to-end security between the author and the device, as shown in , is used to ensure that the device can verify firmware images and manifests produced by authorized authors. The use of post-quantum secure signature mechanisms, such as hash-based signatures, should be explored. A mandatory-to-implement set of algorithms has to be defined offering a key length of 112-bit symmetric key or security or more, as outlined in Section 20 of RFC 7925. This corresponds to a 233 bit ECC key or a 2048 bit RSA key. If the firmware image is to be encrypted, it must be done in such a way that every intended recipient can decrypt it. The information that is encrypted individually for each device must be an absolute minimum.

A device presented with an old, but valid manifest and firmware must not be tricked into installing such firmware since a vulnerability in the old firmware image may allow an attacker gain control of the device.

A power failure at any time must not cause a failure of the device. A failure to validate any part of an update must not cause a failure of the device. One way to achieve this functionality is to provide a minimum of two storage locations for firmware and one bootable location for firmware. An alternative approach is to use a 2nd stage bootloader with build-in full featured firmware update functionality such that it is possible to return to the update process after power down. Note: This is an implementation requirement rather than a requirement on the manifest format.

The bootloader must be minimal, containing only flash support, cryptographic primitives and optionally a recovery mechanism. The recovery mechanism is used in case the update process failed and may include support for firmware updates over serial, USB or even a limited version of Bluetooth Smart. Such a recovery mechanism must provide security at least at the same level as the full featured firmware update functionalities. The bootloader needs to verify the received manifest and to install the bootable firmware image. The bootloader should not require updating since a failed update poses a risk in reliability. If more functionality is required in the bootloader, it must use a two-stage bootloader, with the first stage comprising the functionality defined above. All information necessary for a device to make a decision about the installation of a firmware update must fit into the available RAM of a constrained IoT device. This prevents flash write exhaustion. Note: This is an implementation requirement.

Since parsers are known sources of bugs they must be minimal. Additionally, it must be easy to parse only those fields which are required to validate at least one signature with minimal exposure.

The design of the firmware update mechanism must not require changes to existing firmware formats.

A device may have many modules that require updating individually. It may also need to trust several actors in order to authorize an update. For example, a firmware author may not have the authority to install firmware on a device in critical infrastructure without the authorization of a device operator. In this case, the device should reject firmware updates unless they are signed both by the firmware author and by the device operator. To facilitate complex use-cases such as this, updates require several permissions.

When a simple set of permissions fails to encapsulate the rules required for a device make decisions about firmware, claims can be used instead. Claims represent a form of policy. Several claims can be used together, when multiple actors should have the rights to set policies. Some example claims are: Trust the actor identified by the referenced public key. Three actors are trusted identified by their public keys. Signatures from at least two of these actors are required to trust a manifest. The actor identified by the referenced public key is authorized to create secondary policies The baseline claims for all manifests are described in Appendix A. In summary, they are: Do not install firmware with earlier metadata than the current metadata. Only install firmware with a matching vendor, model, hardware revision, software version, etc. Only install firmware that is before its best-before timestamp. Only install firmware with metadata signed by a trusted actor. Only allow an actor to exercise rights on the device via a manifest if that actor has signed the manifest. Only allow a firmware installation if all required rights have been met through signatures (one or more) or manifest dependencies (one or more). Use the instructions provided by the manifest to install the firmware. Any authorized actor may redirect any URI. Install any and all firmware images that are linked together with manifest dependencies. Choose the mechanism to install the firmware, based on the type of firmware it is.

We start the architectural description with the security model. It is based on end-to-end security. illustrates the security model where a firmware image and the corresponding manifest are created by an author and verified by the device. The firmware image is integrity protected and may be encrypted. The manifest is integrity protected and authenticated. When the author is ready to distribute the firmware image it is conveyed using some communication channel to the device, which will typically involve the use of untrusted storage. Examples of untrusted storage are FTP servers, Web servers or USB sticks.

Whether the firmware image and the manifest is pushed to the device or fetched by the device is outside the scope of this work and existing device management protocols can be used for efficiently distributing this information. The following assumptions are made to allow the device to verify the received firmware image and manifest before updating software: To accept an update, a device needs to decide whether the author signing the firmware image and the manifest is authorized to make the updates. We use public key cryptography to accomplish this. The device verifies the signature covering the manifest using a digital signature algorithm. The device is provisioned with a trust anchor that is used to validate the digital signature produced by the author. This trust anchor is potentially different from the trust anchor used to validate the digital signature produced for other protocols (such as device management protocols). This trust anchor may be provisioned to the device during manufacturing or during commissioning. For confidentiality protection of firmware images the author needs to be in possession of the certificate/public key or a pre-shared key of a device. There are different types of delivery modes, which are illustrates based on examples below. There is an option for embedding a firmware image into a manifest. This is a useful approach for deployments where devices are not connected to the Internet and cannot contact a dedicated server for download of the firmware. It is also applicable when the firmware update happens via a USB stick or via Bluetooth Smart. shows this delivery mode graphically.

shows an option for remotely updating a device where the device fetches the firmware image from some file server. The manifest itself is delivery independently and provides information about the firmware image(s) to download.

| | | Device | -- | Author | | |<- --- | | +--------+ -- --- +--------+ -- --- --- --- -- +-----------+ -- -- | | -- /------------\ -- | Untrusted |<- /------------\ / \ -- | Storage | / \ | Firmware | | | | Firmware | \ / +-----------+ \ / \------------/ \------------/ ]]>

This architecture does not mandate a specific delivery mode but a solution must support both types.

In order for a device to apply an update, it has to make several decisions about the update: Does it trust the author of the update? Has the firmware been corrupted? Does the firmware update apply to this device? Is the update older than the active firmware? When should the device apply the update? How should the device apply the update? What kind of firmware binary is it? Where should the update be obtained? Where should the firmware be stored? The manifest encodes the information that devices need in order to make these decisions. It is a data structure that contains the following information: information about the device(s) the firmware image is intented to be applied to, information about when the firmware update has to be applied, information about when the manifest was created, dependencies to other manifests, pointers to the firmware image and information about the format, information about where to store the firmware image, cryptographic information, such as digital signatures. The manifest format is described in a companion document.

The following example message flow illustrates the interaction for distributing a firmware image to a device starting with an author uploading the new firmware to untrusted storage and creating a manifest.

| | | | | | Create Manifest | | |---------------- | | | | | | |<--------------- | | | | | | Sign Manifest | | |-------------- | | | | | | |<------------- | | | | | | Upload Manifest | | |------------------>| | | | | | | Query Manifest | | |<--------------------| | | | | | Send Manifest | | |-------------------->| | | | | | | Validate Manifest | | |------------------ | | | | | | |<----------------- | | | | | Request Firmware | | |<--------------------| | | | | | Send Firmware | | |-------------------->| | | | | | | Verify Firmware | | |--------------- | | | | | | |<-------------- | | | | | | Store Firmware | | |-------------- | | | | | | |<------------- | | | | | | Reboot | | |------- | | | | | | |<------ | | | | | | Bootloader validates | | | Firmware | | |---------------------- | | | | | | |<--------------------- | | | | | | Bootloader activates | | | Firmware | | |---------------------- | | | | | | |<--------------------- | | | | | | Bootloader transfers | | | control to new Firmware | | |---------------------- | | | | | | |<--------------------- | | | ]]>

This document does not require any actions by IANA.

Firmware updates fix security vulnerabilities and are considered to be an important building block in securing IoT devices. Due to the importance of firmware updates for IoT devices the Internet Architecture Board (IAB) organized a ‘Workshop on Internet of Things (IoT) Software Update (IOTSU)’, which took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at the big picture. A report about this workshop can be found at . This document (and associated specifications) offer a standardized firmware manifest format providing end-to-end security from the author to the device. There are, however, many other considerations raised during the workshop. Many of them are outside the scope of standardization organizations since they fall into the realm of product engineering, regulatory frameworks, and business models. The following considerations are outside the scope of this document, namely installing firmware updates in a robust fashion so that the update does not break the device functionality of the environment this device operates in. installing firmware updates in a timely fashion considering the complexity of the decision making process of updating devices, potential re-certification requirements, and the need for user’s consent to install updates. the distribution of the actual firmware update, potentially in an efficient manner to a large number of devices without human involvement. energy efficiency and battery lifetime considerations. key management required for verifying the digitial signature protecting the manifest. incentives for manufacturers to offer a firmware update mechanism as part of their IoT products.

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

We would like to thank the following persons for their feedback: Geraint Luff Amyas Phillips Dan Ros Thomas Eichinger Michael Richardson Emmanuel Baccelli Ned Smith David Brown Jim Schaad Carsten Bormann Cullen Jennings Olaf Bergmann Suhas Nandakumar Phillip Hallam-Baker Marti Bolivar Andrzej Puzdrowski Markus Gueller We would also like to thank the WG chairs, Russ Housley, David Waltermire, Dave Thaler and the responsible security area director, Kathleen Moriarty, for their support and their reviews.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community.Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. Microsoft

This appendix aims 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. approach. Each threat is classified according to: Spoofing Identity Tampering with data Repudiation Information disclosure Denial of service Elevation of privilege

Classification: Escalation 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.

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.

Classification: Escalation 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.

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 escalation of privilege and potentially expand this to all types of threat.

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 escalation of privilege and potentially expand this to all types of threat.

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.

Classification: All Types 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.

Classification: All Types If an attacker can install their firmware on a device, by manipulating either payload or metadata, then they have complete control of the device.

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 escalation of privilege and potentially expand this to all types of threat.

Classification: Denial of Service, Escalation 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 escalation 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.

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.

The security requirements here are a set of policies that mitigate the threats described in the previous section.

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 increasting sequence numbers. Manifests MAY use UTC epoch timestamps to coordinate monotonically increasting 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

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

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

All descriptive information about the payload MUST be signed. This MUST include: 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 MFT5, MFT6, MFT7, MFT9

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 digitial 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

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

Firmware images must be encrypted to prevent third parties, including attackers, from reading the content of the firmware image and to reverse engineer the code. Mitigates: MFT11

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: Specify a package handler Use a table of hashes to ensure that each block of the payload is validate 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.

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.

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.

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.

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 optimise the bandwidth used by my devices.

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 my due to the use of some third party code libraries.

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

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

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

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

The manifest format MUST accommodate any payload format that an operator or OEM wishes to use. Some examples of payload format would be: Binary Elf Differential Compressed Packed configuration Satisfies Use-Case MFUC5

Each manifest field is anchored in a security requirement or a usability requirement. The manifest fields are described below and justified by their requirements.

A monotonically increasing sequence number 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 type 5 UUIDs with the vendor’s domain name and the UUID DNS prefix. Other options include type 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 is 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 that the device uses 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 should 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

Encrypting firmware images requires symmetric content encryption keys. 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 examples 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.