A CBOR-based Manifest Serialisation FormatArm LimitedBrendan.Moran@arm.comArm Limitedhannes.tschofenig@gmx.net
Security
SUITInternet-DraftThis specification describes the serialization 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. 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) is able to install firmware updates on IoT devices
without adequate privileges. This authorization process is ensured
by the use of dedicated credentials and authorization permissions
installed on the IoT device.This document is part of larger document set: the architecture
document can be found in and the
information model of the manifest is described in
. This document focuses on the
serialization format.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 .The following CDDL fragment defines the manifest.Wherever enumerations are used, they are started at 1. This allows
detection of several common software errors that are caused by
uninitialised variables.The processing graph is a mechanism that maps from resources to
installed firmware. On one side of the graph are the resources.
These are the raw content that a device acquires. Resources can be
remote (for example, on a server) or local (for example, an already
installed firmware). On the other side of the graph are targets.
These are the locations that firmware is installed to. In between
these two sides are processors. These are the steps that a device
takes to translate raw content into firmware that is installed. In
the simplest case, this is a direct mapping; the resource is
installed into the target directly. In an example complex case, a
device must use decryption, decompression, and differential patching
to create the final resource. Differential patching requires that
the device refer to an already-installed firmware. In this graph,
there are two resources, three processors, and one target. In some
cases, one resource may be used by multiple processors, such as a
compression table. The nodes of the graph are the resources before
or after transformation by a processor and the edges of the graph
are the processors themselves.Resources, processors and targets are marked with node identifiers.
Resources have an output node. Targets have an input node.
Processors have both.TBD: Several registries will be required for:
* Standard Conditions
* Standard Directives
* Standard Processors
* Standard text valuesThis 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 and in
the information model 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 RosCarsten BormannDavid BrownMarkus GuellerFrank Audun KvamtroOyvind RonningstadKey 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 DevicesVulnerabilities 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.Firmware Updates for Internet of Things Devices - An Information Model for ManifestsVulnerabilities with Internet of Things (IoT) devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. One component of such a firmware update is the meta-data, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes all the information that must be present in the manifest.