Trustworthiness Vectors for the Software Updates of Internet of Things (SUIT) Workflow Model
Fraunhofer SIT
henk.birkholz@sit.fraunhofer.de
Arm Limited
Brendan.Moran@arm.com
Security
RATS
Internet-Draft
The IETF Remote Attestation Procedures (RATS) architecture defines Conceptual Messages as input and output of the appraisal process that assesses the trustworthiness of remote peers: Evidence and Attestation Results.
Based on the Trustworthiness Vectors defined in Trusted Path Routing, this document defines a core set of Claims to be used in Evidence and Attestation Results for the Software Update for the Internet of Things (SUIT) Workflow Model.
Consecutively, this document is in support of the Trusted Execution Environment Provisioning (TEEP) architecture, which defines the assessment of remote peers via RATS and uses SUIT for evidence generation as well as a remediation measure to improve trustworthiness of given remote peers.
Introduction
Attestation Results are an essential output of Verifiers as defined in the Remote ATtestation procedureS (RATS) architecture .
They are consumed by Relying Parties: the entities that intend to build future decisions on trustworthiness assessments of remote peers.
Attestation Results must be easily appraised by Relying Parties -- in contrast to the rather complex or domain-specific Evidence appraised by Verifiers.
In order to create Attestation Results, a Verifier must consume Evidence generated by a given Attester (amongst other Conceptual Messages, such as Endorsements and Attestation Policies).
Both Evidence and Attestation Results are composed of Claims.
This document highlights and defines a set of Claims to be used in Evidence and Attestation Results that are based on the SUIT Workflow Model .
In the scope of this document, an Attester takes on the role of a SUIT Recipient: the system that receives a SUIT Manifest.
SUIT Workflow Model and Procedures
This document focuses on Evidence and Attestation Results that can be generated based on the output of SUIT Procedures.
The SUIT Workflow Model allows for two types of SUIT Procedures generating Reports on the Attester as defined in the SUIT Manifest specification :
-
Update Procedures:
-
A procedure that updates a device by fetching dependencies, software images, and installing them.
-
An Update Procedure creates a Report about mutable software components that are installed or updated on hardware components.
-
Boot Procedures:
-
A procedure that boots a device by checking dependencies and images, loading images, and invoking one or more image.
-
A Boot Procedure creates a Report on measured boot events (e.g. during Secure Boot).
The Records contained in each type of Report can be used as Claims in Evidence generation on the Attester for Remote Attestation Procedures as described in this document.
Analogously, a corresponding Verifier appraising that Evidence can generate Attestation Results using the Claims defined in this document.
Both types of SUIT Procedures pass several stages (e.g. dependency-checking is one stage).
The type and sequence of stages are defined by the Command Sequences included in a SUIT Manifest.
For each stage in which a Command from the Command Sequence is executed a Record is created. All Records of a SUIT procedure contain binary results limited to "fail" or "pass".
The aggregated sequence of all Records is composed into a Report.
This document specifies new Claims derived from Command Sequence Reports and highlights existing Claims as defined in Trusted Path Routing that are applicable to the operational state of installed and updated software.
The Claims defined in this document are in support of the Trusted Execution Environment Provisioning (TEEP) architecture.
During TEEP, the current operational state of an Attester is assessed via RATS. If the corresponding Attestation Results -- as covered in this document -- indicate insufficient Trustworthiness Levels with respect to installed software, the SUIT Workflow Model is used for remediation.
Terminology
This document uses the terms and concepts defined in , , and .
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.
Trustworthiness Vectors
While there are usage scenarios where Attestation Results can be binary decisions, more often than not the assessment of trustworthiness is represented by a more fine-grained spectrum or based on multiple factors.
These shades of Attestation Results are captured by the definition of Trustworthiness Vectors in Trusted Path Routing .
Trustworthiness Vectors are sets of Claims representing appraisal outputs created by a Verifier. Each of these Claims is called a Trustworthiness Level.
Multiple Trustworthiness Levels are composed into a vector.
An Attester processing SUIT Manifests can create three types of Claims about its Target Environments.
This includes Claims about:
- installed manifests including initial state (e.g. factory default),
- hardware component identifiers that represent the targets of updates, and
- SUIT Interpreter results (e.g. test-failed) created during updates.
Every SUIT Manifest maps to a certain intended state of a device.
Every intended device composition of software components associated with hardware components can therefore be expressed based on a SUIT Manifest.
The current operational state of a device can be represented in the same form, including the initial state.
As a result, the Claims defined in this document are bundled by the scope of the information represented in SUIT Manifests, i.e., dedicated blobs of software that are the payload of a SUIT Manifest.
All Claims associated with an identifiable SUIT Manifest must always be bundled together in a Claims set that is limited to the Claims defined in this document.
SUIT Claims
The Claim description in this document uses CDDL as the formal modeling language for Claims.
This approach is derived from .
All Claims are based on information elements as used in the SUIT Manifest specification .
For instance, a SUIT Vendor ID is represented as an UUID.
Analogously, the corresponding vendor-identifier Claim found below is based on a UUID.
SUIT Claims are differentiated in:
- software and hardware characteristics (System Properties), and
- reports about updates their SUIT Commands (SUIT Records).
Both types of Claims are always bundled in dedicated Claim Sets.
Implementations can encode this information in various different ways (data models), e.g., sets, sequences, or nested structures.
The following subsections define the SUIT Report Claims for RATS and are structured according to the following CDDL expression.
suit-report = {
suit-system-properties => [ + system-property-claims ],
suit-records => [ + interpreter-record-claims ],
}
system-property-claims => { + $$system-property-claim }
interpreter-record-claims => { + $$interpreter-record-claim }
System Properties Claims
System Properties Claims are composed of:
- Hardware Component Claims and
- Software Component Claims.
Correspondingly, the Claim definitions below highlight if a Claim is generic or hw/sw-component specific.
vendor-identifier
A RFC 4122 UUID representing the vendor of the Attester or one of its hardware and/or software components.
$$system-property-claim //= ( vendor-identifier => RFC4122_UUID )
class-identifier
A RFC 4122 UUID representing the class of the Attester or one of its hardware and/or software components.
$$system-property-claim //= ( class-identifier => RFC4122_UUID )
device-identifier
A RFC 4122 UUID representing the Attester.
$$system-property-claim //= ( device-identifier => RFC4122_UUID )
component-identifier
A sequence of binary identifiers that is intended to identify a software-component of an Attester uniquely. A binary identifier can represent a CoSWID tag-id.
$$system-property-claim //= ( class-identifier => [ + identifier ] )
image-digest
A fingerprint computed over a software component image on the Attester.
This Claim is always bundled with a component-identifier or component-index.
$$system-property-claim //= ( image-digest => digest )
image-size
The size of a firmware image on the Attester.
$$system-property-claim //= ( image-size => size )
minimum-battery
The configured minimum battery level of the Attester in mWh.
$$system-property-claim //= ( minimum-battery => charge )
version
The Version of a hardware or software component of the Attester.
$$system-property-claim //= ( version => version-value )
Interpreter Record Claims
This class of Claims represents the content of SUIT Records generated by Interpreters running on Recipients. They are always bundled into Claim Sets representing SUIT Reports and are intended to be included in Evidence generated by an Attester. The Interpreter Record Claims appraised by a Verifier can steer a corresponding a Firmware Appraisal procedures that consumes this Evidence. Analogously, these Claims can be re-used in generated Attestation Results as Trustworthiness Vectors .
record-success
The result of a Command that was executed by the Interpreter on an Attester.
$$interpreter-record-claim //= ( record-success => bool )
component-index
A positive integer representing an entry in a flat list of indices mapped to software component identifiers to be updated.
$$system-property-claim //= ( component-index => uint )
dependency-index
A thumbprint of a software component that an update depends on.
$$interpreter-record-claim //= ( dependency-index => digest )
command-index
A positive integer representing an entry in a SUIT_Command_Sequence identifying a Command encoded as a SUIT Manifest Directive or SUIT Manifest Condition.
$$interpreter-record-claim //= ( command-index => uint )
nominal-parameters
A list of SUIT_Parameters associated with a specific Command encoded as a SUIT Manifest Directive.
$$interpreter-record-claim //= ( nominal-parameters => parameter-list )
nominal-parameters
A list of SUIT_Parameters associated with a specific Command that was executed by the Interpreter on an Attester.
$$interpreter-record-claim //= ( actual-parameters => parameter-list )
Generic Record Conditions (TBD)
- test-failed
- unsupported-command
- unsupported-parameter
- unsupported-component-id
- payload-unavailable
- dependency-unavailable
- critical-application-failure
- watchdog-timeout
List of Commands (TBD)
- Check Vendor Identifier
- Check Class Identifier
- Verify Image
- Set Component Index
- Override Parameters
- Set Dependency Index
- Set Parameters
- Process Dependency
- Run
- Fetch
- Use Before
- Check Component Offset
- Check Device Identifier
- Check Image Not Match
- Check Minimum Battery
- Check Update Authorized
- Check Version
- Abort
- Try Each
- Copy
- Swap
- Wait For Event
- Run Sequence
- Run with Arguments
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
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.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
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.
Informative References
Remote Attestation Procedures Architecture
Fraunhofer SIT
Microsoft
Sandelman Software Works
Intel Corporation
Huawei Technologies
In network protocol exchanges it is often useful for one end of a
communication to know whether the other end is in an intended
operating state. This document provides an architectural overview of
the entities involved that make such tests possible through the
process of generating, conveying, and evaluating evidentiary claims.
An attempt is made to provide for a model that is neutral toward
processor architectures, the content of claims, and protocols.
A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest
Arm Limited
Arm Limited
Fraunhofer SIT
Inria
This specification describes the format of a manifest. A manifest is
a bundle of metadata about code/data obtained by a recipient (chiefly
the firmware for an IoT device), where to find the that code/data,
the devices to which it applies, and cryptographic information
protecting the manifest. Software updates and Trusted Invocation
both tend to use sequences of common operations, so the manifest
encodes those sequences of operations, rather than declaring the
metadata.
Trusted Execution Environment Provisioning (TEEP) Architecture
Broadcom
Arm Limited
Microsoft
Intel
A Trusted Execution Environment (TEE) is an environment that enforces
that any code within that environment cannot be tampered with, and
that any data used by such code cannot be read or tampered with by
any code outside that environment. This architecture document
motivates the design and standardization of a protocol for managing
the lifecycle of trusted applications running inside such a TEE.
Trusted Path Routing
Cisco Systems, Inc.
There are end-users who believe encryption technologies like IPSec
alone are insufficient to protect the confidentiality of their highly
sensitive traffic flows. These end-users want their flows to
traverse devices which have been freshly appraised and verified.
This specification describes Trusted Path Routing. Trusted Path
Routing protects sensitive flows as they transit a network by
forwarding traffic to/from sensitive subnets across network devices
recently appraised as trustworthy.
The Entity Attestation Token (EAT)
Qualcomm Technologies Inc.
Security Theory LLC
Qualcomm Technologies Inc.
Qualcomm Technologies Inc.
An Entity Attestation Token (EAT) provides a signed (attested) set of
claims that describe state and characteristics of an entity,
typically a device like a phone or an IoT device. These claims are
used by a relying party to determine how much it wishes to trust the
entity.
An EAT is either a CWT or JWT with some attestation-oriented claims.
To a large degree, all this document does is extend CWT and JWT.
Contributing
TBD
Concise Software Identification Tags
Fraunhofer SIT
National Security Agency
The MITRE Corporation
National Institute of Standards and Technology
ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
extensible XML-based structure to identify and describe individual
software components, patches, and installation bundles. SWID tag
representations can be too large for devices with network and storage
constraints. This document defines a concise representation of SWID
tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of
semantics and features as SWID tags, as well as new semantics that
allow CoSWIDs to describe additional types of information, all in a
more memory efficient format.