Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

Security SUIT Working Group Internet-Draft This document defines a resource extension for Concise Software Identifiers (CoSWID) that represents a SUIT firmware manifest. This extension combines the information elements of the SUIT information model with the semantic expressiveness of Software Identifiers. In consequence, this composite enables the integration of Firmware Updates for the Internet of Things (SUIT) in existing work-flows for updates of software components in general.

Firmware updates are quite similar to software update of applications – composites of software components – for example, servers or user-devices. Attributes and semantic dependencies as defined by Concise Software Identifies are equivalent. In contrast, location and target definitions as well as the characteristics that are specific to an update campaign of a SUIT require a specific set of addiction information elements. The semantics regarding SUIT specific information elements are defined by the SUIT Information Model . Correspondingly, the CoSWID extension defined in this document uses CDDL extension points to add SUIT information elements to the standard Concise Software Identifiers. 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 BCP 14 when, and only when, they appear in all capitals, as shown here.

The following CDDL data definition is intended to be used as an extension to the CoSWID CDDL data definition. Corresponding terms, such as Resources, Processors and Targets of input nodes and output nodes are covered by the SUIT Information Model and Architecture .

The following CDDL data definition MUST be added to Payload or Evidence Resources via CDDL extension points in order to express SUIT Manifests in Concise Software Identifiers.

bytes } ) suit.resources = (70: [ + [ suit.resource-type, suit.uri-list, suit.digest, suit.onode, ? suit.size, ] ] ) suit.resource-type = suit.payload / suit.dependency / suit.key / suit.alias suit.payload = 0 suit.dependency = 1 suit.key = 2 suit.alias = 3 suit.uri-list = { + int => text } suit.size = uint suit.onode = bytes suit.processors = (71: [ + [ suit.decrypt / suit.decompress / suit.undiff / suit.relocate / suit.unrelocate, suit.parameters, suit.inode, suit.onode, ] ] ) suit.decrypt = 0 suit.decompress = 1 suit.undiff = 2 suit.relocate = 3 suit.unrelocate = 4 suit.parameters = bytes suit.inode = bytes suit.targets = (72: [ + [ suit.component-id, suit.storage-identifier, suit.inode, ? suit.encoding, ] ] ) suit.component-id = [ + bytes ] suit.encoding = bytes suit.extensions = (73: { + int => bytes } ) ]]>

This draft is intended to incorporate the extension registry that will be defined by Concise Software Identifiers. Until then, a consecutive numbering system in alignment to the labels used in Concise Software Identifiers is applied.

TBD

TBD

Initial Contribution

TBD

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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a concise representation of ISO/IEC 19770-2:2015 Software Identification (SWID) tags that are interoperable with the XML schema definition of ISO/IEC 19770-2:2015 and augmented for application in Constrained-Node Networks. Next to the inherent capability of SWID tags to express arbitrary context information, Concise SWID (CoSWID) tags support the definition of additional semantics via well-defined data definitions incorporated by extension points. Vulnerabilities with Internet of Things (IoT) devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. One component of such a firmware update is the meta-data, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes all the information that must be present in the manifest. 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.