Firmware Manifest FormatArm LimitedBrendan.Moran@arm.comArm LimitedMilosch.Meriac@arm.comArm Limitedhannes.tschofenig@gmx.net
Security
SUITInternet-DraftThis specification describes the format of a manifest. A manifest is a bundle of metadata about the firmware for an IoT device, where to find the firmware, the devices to which it applies, and cryptographic information protecting the manifest.A firmware update mechanism is an essential security feature for IoT devices to deal with vulnerabilities. While the transport of firmware images to the devices themselves is important there are already various techniques available, such as the Lightweight Machine-to-Machine (LwM2M) protocol offering device management of IoT devices. Equally important is the inclusion of meta-data about the conveyed firmware image (in the form of a manifest) and the use of end-to-end security protection to detect modifications and (optionally) to make reverse engineering more difficult. End-to-end security allows the author, who builds the firmware image, to be sure that no other party (including potential adversaries) installs firmware updates on IoT devices without adequate privileges. This authorization process is ensured by the use of dedicated symmetric or asymmetric keys installed on the IoT device: for use cases where only integrity protection is required it is sufficient to install a trust anchor on the IoT device. For confidentiality protected firmware images it is additionally required to install either one or multiple symmetric or asymmetric keys on the IoT device. Starting security protection at the author is a risk mitigation technique so that firmware images and manifests can be stored on untrusted respositories.It is assumed that the reader is familiar with the high-level firmware update architecture .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 .To describe the components of the manifest we use the terms structures and attributes. The manifest has a hierarchical structure and top level components are called structures and the attributes are the components within them.The key components of a manifest are shown in and are explained in the sub-sections below.The Manifest structure is the top-level construct that ties all other structures together. In addition to the structures explained in subsections below it containsa version number (in the ‘manifestVersion’ attribute)a textual description about the update, including the version / vendor / model of the device (in the ‘text’ attribute). This information is optional.a timestamp indicating when the manifest was created (in the ‘timestamp’ attribute).The following CDDL fragment defines the manifest.In the text section, positive integers define standard text fields, described in this draft. Negative integers define application-specific text fields.Text fields are never used by the target. They are for informational purposes only.The PayloadInfo structure contains information about the firmware image:format: contains the firmware image type (such as rawBinary, hexLocationLengthData, ELF). Format is an array of: an integer (positive for standard types, negative for application-specific types) and a bstr that encapsulates any information needed by the format processor, that is not included in the firmware image itself.size: offers information about the size of the firmware image in bytes. If the size of the obtained firmware image differs from the size stated in the manifest then the obtained image MUST be consider corrupted.nonce: contains a (short) random value to ensure that a given manifest is unique. This separates the function of the timestamp, which is provided for rollback protection, from the function of the nonce, which is for uniqueness. Keeping these functions separate ensures that a number of edge cases are catered for, for example: the creation of manifests quickly enough that they have the same timestamp.storageIdentifier: indicates where the image should be placed on the device. This value is useful, for example, when an IoT device contains multiple microcontrollers (MCUs) and the decision needs to be made to which MCU to send which firmware image. Another example is when an IoT device contains both firmware and configuration and the configuration must be updated while the firmware remains the same.uris: a set of ranked references for where to find the payload. By using a ranking, the device can select which the preferred URIs are. If several URIs have the same preference, then devices SHOULD select randomly from the available URIs of the same rank. URIs need not be a URL, a URN is acceptable if the target understands it. The uri can allow a device to use a ranked search pattern to choose the best location to look for the payload in complex distribution scenarios, such as attempting to find the payload on a gateway device prior to looking on a fileserver.digestAlgorithm: This defines the type of digest used for all entries in the digests list. The type must be a standard COSE MAC algorithm or a message digest algorithm (these are not yet defined in COSE). An optional ‘parameters’ bstr is provided in case one of these algorithms requires additional configuration that would normally be present in the ‘protected’ or ‘unprotected’ fields of the COSE_Mac object.digests: This is a map of possible digests. It is indexed by integer: positive for standardized digests and negative for application-specific digests.payload: a COSE_Encrypt object, a bstr, or nil. Note that a COSE_Mac could be used instead of a bstr / nil, but this would be redundant since the whole structure is already authenticated.NOTE: digests needs some form of key derivation to prevent the need for multiple keys. It is expected that the same key be used, with a KDF of some kind, to derive a key from the key used to sign the manifest in the case of COSE_Mac manifests. Where manifests use COSE_Sign at the top level, it is expected that digests will use standard message digest algorithms instead of MAC algorithms.The following CDDL fragment defines the payload info:Digests can contain several kinds of digest:There are several ways that this format can reference a payload:The payload can be contained by the COSE_Encrypt object. In this case, no URIs are expected, since the payload is contained in COSE_Encrypt.The COSE_Encrypt object is present, but its ‘ciphertext’ is nil. This means that the ciphertext payload is delivered separately. In this case, at least one URI is expected in uris.The payload is a bstr. This encapsulates a plaintext payload. A raw payload digest is redundant. No URIs are expected.The payload is a nil. This means that the plaintext payload is delivered separately. In this case, at least one URI is expected in uris. At least one digest is expected in digests.Most importantly, however, the PayloadInfo structure contains a reference to the firmware image (in the ‘reference’ attribute) or the image is embedded inside the PayloadInfo structure (within the ‘integrated’ attribute). A referenced image first needs to be fetched by the device before the update can be applied. The ‘reference’ attribute contains a ‘hash’ and a ‘uri’ attribute: the value in the ‘hash’ attribute allows the device to determine whether it has already obtained this firmware image and, since it is included in the digitally signed manifest, it protects the firmware image against modifications. The ‘uri’ attribute references the image.Encryption is handled by the COSE_Encrypt structure. Most encryption modes are already supported via the COSE_Encrypt structure, only per-device pre-shared keys (or per-device ECDH derivation of pre-shared keys) needs to be described. When using an encrypted image key, shared between many devices, the COSE_Encrypt recipients structure should be filled out as follows:This allows a manifest to direct a device to fetch keys from a particular location, identify them by name, or perform another fetch/lookup operation. The exact method for key distribution is out of scope. (However, an array of COSE_Encrypt objects, each containing a single key object, with a simple recipient object seems appropriate.)This mode is tailored to use cases where a single encrypted firmware image is transmitted to many IoT devices.The Condition and the Directive structures together allow “If <…> Then <…>” rules to be expressed.It offers the following functionality:Apply an update immediately (Directive.applyImmediately)Apply an update only to devices that match the vendorId, classId, deviceId attributesApply an update only if the device system time is before the time indicated in the Condition.lastApplicationTime.Wait to apply an update until the device system time is after an indicated time.The following CDDL fragment defines the structure of a condition:Some condition types are predefined:Some directive types are predefined:Application-specific conditions and directives MUST use negative identifiers.In some situations an IoT device may require more than a single firmware image. To express the requirement that more than one image has to be installed on a device the dependencies structure is used, which is of type ResourceReference.The following CDDL fragment defines the ResourceReference:Aliases are used to refer to alternative locations of firmware images. This is useful in environments where organizations cache firmware images (and their corresponding manifests) on premise to avoid the need to fetch images from repositories maintained by the developer’s organizations (such a device manufacturer or an OEM).A device is identified by a combination of three identifiers:A vendor identifierA device class identifierA device identifierThe vendor ID is a 128-bit number that conforms to RFC 4122, type 5. This number is used by the device to verify manifests.The Vendor ID should be derived from the manufacturer’s domain name using the algorithm defined in Section 4.3 of RFC 4122.A vendor ID is typically compiled into a firmware image since it is static for the lifetime of the firmware.The device class is a 128-bit number that conforms to RFC 4122, type 5. This number is used by the client to verify manifests. The Device Class ID SHOULD use the Vendor ID as the namespace, but the ID within the namespace can be arbitrary.A class ID is also typically compiled into a firmware image since it is static for the lifetime of the firmware.The device ID is also a 128-bit number that conforms to RFC 4122. The device ID can come from a variety of sources. For example, a device may obtain this identifier during the manufacturing phase (together with other configuration information and manufacturer-provided credentials). In this case, we recommend using RFC 4122, type 1, where the node ID is the factory tool ID, which provides traceability of a device back to the origin of manufacture. A device ID can also come from on-device resources, such as device unique-ID registers or device identifiers in CPUs. Our recommendation is to provide unique CPU resources to a generator function similar to the one used for the class_id. In this example, the device_info may be a combination of several components, such as:MAC addressDevice unique identifierWhere multiple sources of unique identity are available, they should all be provided to the UUID function, since it combines them to create a single, unique identifier.At the top level, manifests are authenticated using either the COSE_Mac or COSE_Sign structures, depending on application. The considerations that apply to encryption keys in PayloadInfo apply equally to the use of Mac keys in COSE_Mac.Not all devices will support the full feature set described in this specification. If features become complex enough, it may be necessary to report the features used by a manifest. Since this is redundant information, it is excluded from this draft.At minimum, targets MUST support the following manifest fields:manifestVersion, so that the target can tell which version of manifest is in use.text (this is ignored by the target)nonce (this is ignored by the target)timestampconditionspayloadInfoA target attempting to parse a manifest that contains non-nil fields that it does not support SHALL report an error in validation.At minimum, targets MUST support the ONE of the following payload modes:digestAlgorithm, digests, bstrdigestAlgorithm, digests, uris, nil payloadCOSE_Encrypt, inline ciphertextCOSE_Encrypt, nil ciphertextThe following CDDL code describes the entire manifest format.The manifest itself is encapsulated in either a COSE_Mac or a COSE_Sign block.Editor’s Note: A few registries would be good to allow easier allocation of new features.This document is about a manifest format describing and protecting firmware images and as such it is part of a larger solution for offering a standardized way of delivering firmware updates to IoT devices. A more detailed discussion about security can be found in the architecture document .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/suitArchives of the list can be found at:
https://www.ietf.org/mail-archive/web/suit/current/index.htmlWe would like the following persons for their support in designing this mechanismGeraint LuffAmyas PhillipsDan RosThomas EichingerMichael RichardsonEmmanuel BaccelliNed SmithDavid BrownJim SchaadCarsten BormannCullen JenningsOlaf BergmannSuhas NandakumarPhillip Hallam-BakerWe 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.Key words for use in RFCs to Indicate Requirement LevelsIn 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.A Firmware Update Architecture for Internet of Things DevicesArm Limited