]> Arm Limited

brendan.moran.ietf@gmail.com

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@ietf.contact

Security SUIT Internet-Draft The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. This document specifies a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor.

Introduction This document specifies a logging container, specific to Software Update for the Internet of Things (SUIT) Manifests () that creates a lightweight feedback mechanism for developers in the event that an update or boot fails in the manifest processor. In this way, it provides the necessary link between the Status Tracker Client and the Status Tracker Server as defined in . A SUIT Manifest Processor can fail to install or boot an update for many reasons. Frequently, the error codes generated by such systems fail to provide developers with enough information to find root causes and produce corrective actions, resulting in extra effort to reproduce failures. Logging the results of each SUIT command can simplify this process. While it is possible to report the results of SUIT commands through existing logging or attestation mechanisms, this comes with several drawbacks: data inflation, particularly when designed for text-based logging missing information elements missing support for multiple components The CBOR objects defined in this document allow devices to: report a trace of how an update was performed report expected vs. actual values for critical checks describe the installation of complex multi-component architectures describe the measured properties of a system report the exact reason for a parsing failure

Conventions and Terminology 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 terms "Author", "Recipient", and "Manifest" are defined in . Additionally, this document uses the term Boot: initialization of an executable image. Although this document refers to boot, any boot-specific operations described are equally applicable to starting an executable in an OS context.

The SUIT_Record The SUIT_Record is a record of a decision taken by the Manifest Processor. It contains the information that the Manifest Processor used to make the decision. The decision can be inferred from this information, so it is not included. If the developer has a copy of the manifest, then they need little information to reconstruct what the manifest processor has done. They need any data that influences the control flow of the manifest. The manifest only supports the following control flow primitives: Set Component Set/Override Parameters Try-Each Run Sequence Conditions Of these, only conditions change the behavior of the processor from the default, and then only when the condition fails. To reconstruct the flow of a manifest, a developer needs a list of metadata about failed conditions: the current manifest the current Command Sequence () the offset into the current Command Sequence the current component index the "reason" for failure Most conditions compare a parameter to an actual value, so the "reason" is typically the actual value. Since it is possible that a non-condition command (directive) may fail in an exceptional circumstance, a failure code for a non condition command must be communicated to the developer. However, a failed directive will terminate processing of the manifest. To accommodate for a failed command and for explicit "completion," an additional "result" element is included as well; however, this is included in the SUIT_Report (). In the case of a command failure, the failure reason is typically a numeric error code. However, these error codes need to be standardised in order to be useful. This approach effectively compacts the log of operations taken using the SUIT Manifest as a dictionary. This enables a full reconstruction of the log using a matching decompaction tool. The following CDDL () shows the structure of a SUIT_Record.

suit-record-manifest-id is used to identify which manifest contains the command that caused the record to be generated. The manifest id is a list of integers that form a walk of the manifest tree, starting at the root. An empty list indicates that the command was contained in the root manifest. If the list is not empty, the command was contained in one of the root manifest's dependencies, or nested even further below that. For example, suppose that the root manifest has 3 dependencies and each of those dependencies has 2 dependencies of its own: Root Dependency A (index 0) Dependency AA (index 0,0) Dependency AB (index 0,1) Dependency B (index 1) Dependency BA (index 1,0) Dependency BB (index 1,1) Dependency C (index 2) Dependency CA (index 2,0) Dependency CB (index 2,1) A suit-record-manifest-id of [1,0] would indicate that the current command was contained within Dependency BA. Similarly, a suit-record-manifest-id of [2,1] would indicate Dependency CB suit-record-manifest-section indicates which Command Sequence of the manifest was active. Only the "top level" Command Sequences, with entries in the Manifest are identified by this element. These are: suit-validate = 7 suit-load = 8 suit-invoke = 9 suit-dependency-resolution = 15 suit-payload-fetch = 16 suit-candidate-verification = 18 suit-install = 20 This list may be extended through extensions to the SUIT_Manifest. suit-record-manifest-section is used in addition to an offset so that the developer can index into severable Command Sequences in a predictable way. The value of this element is the value of the key that identified the Command Sequence in the manifest. suit-record-section-offset is the number of bytes into the current Command Sequence at which the current command is located. suit-record-component-index is the index of the component that was specified at the time that the report was generated. This field is necessary due to the availability of set-current-component values of True and a list of components. Both of these values cause the manifest processor to loop over commands using a series of component-ids, so the developer needs to know which was selected when the command executed. suit-record-properties contains any measured properties that led to the command failure. For example, this could be the actual value of a SUIT_Digest or class identifier. This is encoded in a SUIT_Parameters block as defined in .

The SUIT_Report The SUIT_Report is a SUIT-specific logging container. It contains the SUIT_Records needed to reconstruct the decisions made by a Manifest Processor as well as references to the Manifest being processed, the result of processing, and an optional capability report. Some metadata is common to all records, such as the root manifest: the manifest that is the entry-point for the manifest processor. This metadata is aggregated with a list of SUIT_Records as defined in . The SUIT_Report may also contain a list of any System Properties that were measured and reported, and a reason for a failure if one occurred. The following CDDL describes the structure of a SUIT_Report and a SUIT_Reference:

SUIT_Reference, ? suit-report-nonce => bstr, suit-report-records => \ \[ * SUIT_Record / system-property-claims \], suit-report-result => true / { suit-report-result-code => int, suit-report-result-record => SUIT_Record, suit-report-result-reason => SUIT_Report_Reasons, }, ? suit-report-capability-report => SUIT_Capability_Report, $$SUIT_Report_Extensions } system-property-claims = { system-component-id => SUIT_Component_Identifier, + SUIT_Parameters, } SUIT_Reference = [ suit-report-manifest-uri : tstr, suit-report-manifest-digest : SUIT_Digest, ] ]]>

Further details for each element appear in subsequent sections: the encoding of suit-report-records is defined in , the result semantics in , and the optional capability report in . The suit-reference provides a reference URI and digest for a suit manifest. The URI MUST exactly match the suit-reference-uri () that is provided in the manifest. The digest is the digest of the manifest, exactly as reported in SUIT_Authentication, element 0 (). NOTE: The digest is used in preference to other identifiers in the manifest because it allows a manifest to be uniquely identified (collision resistance) whereas other identifiers, such as the sequence number, can collide, particularly in scenarios with multiple trusted signers. suit-report-nonce provides a container for freshness or replay protection information. This field MAY be omitted where the suit-report is authenticated within a container that provides freshness already. For example, attestation evidence typically contains a proof of freshness. suit-report-manifest-digest provides a SUIT_Digest (as defined in ) that is the characteristic digest of the Root manifest. This digest MUST be the same digest as is held in the first element of SUIT_Authentication in the referenced Manifest_Envelope. suit-report-manifest-uri provides the reference URI that was provided in the root manifest.

suit-report-records suit-report-records is a list of 0 or more SUIT_Records or system-property-claims. Because SUIT_Records are only generated on failure, in simple cases this can be an empty list. SUIT_Records and suit-system-property-claims are merged into a single list because this reduces the overhead for a constrained node that generates this report. The use of a single log allows report generators to use simple memory management. Because the system-property-claims are encoded as maps and SUIT_Records are encoded as lists, a recipient need only filter the CBOR Type-5 entries from suit-report-records to obtain all system-property-claims. System Properties can be extracted from suit-report-records by filtering suit-report-records for maps. System Properties are a list of measured or asserted properties of the system that creates the SUIT_Report. These properties are scoped by component identifier. Because this list is expected to be constructed on the fly by a constrained node, component identifiers may appear more than once. A recipient may convert the result to a more conventional structure:

{ + SUIT_Parameters, } } ]]>

SUIT_Report Result suit-report-result provides a mechanism to show that the SUIT procedure completed successfully (value is true) or why it failed (value is a map of an error code and a SUIT_Record). suit-report-result-reason gives a high-level explanation of the failure. These reasons are intended for interoperable implementations. The reasons are divided into a small number of groups: suit-report-reason-cbor-parse: a parsing error was encountered by the CBOR parser. suit-report-reason-cose-unsupported: an unsupported COSE () structure or header was encountered. suit-report-reason-alg-unsupported: an unsupported COSE algorithm was encountered. suit-report-reason-unauthorised: Signature/MAC verification failed. suit-report-reason-command-unsupported: an unsupported command was encountered. suit-report-reason-component-unsupported: The manifest declared a component/prefix that does not exist. suit-report-reason-component-unauthorised: The manifest declared a component that is not accessible by the signer. suit-report-reason-parameter-unsupported: The manifest used a parameter that does not exist. suit-report-reason-severing-unsupported: The manifest used severable fields but the Manifest Processor does not support them. suit-report-reason-condition-failed: A condition failed with soft- failure off. suit-report-reason-operation-failed: A command failed (e.g., download/copy/swap/write) suit-report-reason-invoke-pending: Invocation is about to be attempted and the final outcome is not yet known. The suit-report-result-code reports an internal error code that is provided for debugging reasons. This code is not intended for interoperability. The suit-report-result-record indicates the exact point in the manifest or manifest dependency tree where the error occurred. NOTE: Some deployments use SUIT_Command_Invoke, which can transfer control to invoked code that never returns to the Manifest Processor. When a SUIT_Report is produced for remote attestation, implementations often need to sign the report before attempting the invoke. Signing with an unconditional "success" result would be misleading if the invocation ultimately fails. Implementers can leave the invoke outcome implicit—allowing a verifier to infer that execution was handed off—or, when the result must be reported before invocation, use suit-report-reason-invoke-pending to signal that invocation is about to occur without asserting a final outcome. suit-report-capability-report provides a mechanism to report the capabilities of the Manifest Processor. The SUIT_Capability_Report is described in . The capability report is optional to include in the SUIT_Report, according to an application-specific policy. While the SUIT_Capability_Report is not expected to be very large, applications should ensure that they only report capabilities when necessary in order to conserve bandwidth. A capability report is not necessary except when: A client explicitly requests the capability report, or A manifest attempts to use a capability that the Manifest Processor does not implement.

Attestation Where Remote Attestation (see , the RATS Architecture) is in use, the RATS Verifier (Verifier hereafter) requires a set of Attestation Evidence. Attestation Evidence contains Evidence Claims about the Attester. These Evidence Claims contain measurements about the Attester. Many of these measurements are the same measurements that are generated in SUIT, which means that a SUIT_Report contains most of the Claims and some of the Endorsements that a Verifier requires. Using a SUIT_Manifest and a SUIT_Report improves a Verifier's ability to appraise the trustworthiness of a remote device. Remote attestation is done by using the SUIT_Envelope along with the SUIT_Report in Evidence to reconstruct the state of the device at boot time. Additionally, by including SUIT_Report data as telemetry (i.e., debug/failure information) next to measurements in Evidence, both types of Evidence data can be notarized via verifiable data structure, such as an append-only log () using the same conceptual message. For the SUIT_Report to be usable as Attestation Evidence, the environment that generated the SUIT_Report also needs to be measured. Typically, this means that the software that executes the commands in the Manifest (the Manifest Processor) must be measured; similarly, the piece of software that assembles the measurements, taken by the Manifest Processor, into the SUIT_Report (the Report Generator) must also be measured. Any bootloaders or operating systems that facilitate the running of the Manifest Processor or Report Generator also need to be measured in order to demonstrate the integrity of the measuring environment. Therefore, if a Remote Attestation format that conveys Attestation Evidence, such as an Entity Attestation Token (EAT, see ), contains a SUIT_Report, then it MUST also include an integrity measurement of the Manifest Processor, the Report Generator and any bootloader or OS environment that ran before or during the execution of both. If Reference Values () required by the Verifier are delivered in a SUIT_Envelope, this codifies the delivery of appraisal information to the Verifier: The Firmware Distributor: sends the SUIT_Envelope to the Verifier without payload or text, but with Reference Values sends the SUIT_Envelope to the Recipient without Reference Values, or text, but with payload The Recipient: Installs the firmware as described in the SUIT_Manifest and generates a SUIT_Report, which is encapsulated in an EAT by the installer and sent to the Firmware Distributor. Boots the firmware as described in the SUIT_Manifest and creates a SUIT_Report, which is encapsulated in an EAT by the installer and sent to the Firmware Distributor. The Firmware Distributor sends both reports to the Verifier (separately or together) The Verifier: Reconstructs the state of the device using the manifest Compares this state to the Reference Values Returns an Attestation Report to the Firmware Distributor This approach simplifies the design of the bootloader since it is able to use an append-only log. It allows a Verifier to validate this report against signed Reference Values that is provided by the firmware author, which simplifies the delivery chain of verification information to the Verifier. For a Verifier to consume the SUIT_Report, it requires a copy of the SUIT_Manifest. The Verifier then replays the SUIT_Manifest, using the SUIT_Report to resolve whether each condition is met. It identifies each measurement that is required by attestation policy and records this measurement as a Claim (). It evaluates whether the SUIT_Report correctly matches the SUIT_Manifest as an element of evaluating trustworthiness. For example there are several indicators that would show that a SUIT_Report does not match a SUIT_Manifest. If any of the following (not an exhaustive list) occur, then the Manifest Processor that created the report is not trustworthy: Hash of SUIT_Manifest at suit-report-manifest-uri does not match suit-report-manifest-digest A SUIT_Record is issued for a SUIT_Command_Sequence that does not exist in the SUIT_Manifest at suit-report-manifest-uri. A SUIT_Record is identified at an offset that is not a condition and does not have a reporting policy that would indicate a SUIT_Record is needed. Many architectures require multiple Verifiers, for example where one Verifier handles hardware trust, and another handles software trust, especially the evaluation of software authenticity and freshness. Some Verifiers may not be capable of processing a SUIT_Report and, for separation of roles, it may be preferable to divide that responsibility. In this case, the Verifier of the SUIT_Report should perform an Evidence Transformation and produce general purpose Measurement Results Claims that can be consumed by a downstream Verifier, for example a Verifying Relying Party, that does not understand SUIT_Reports.

Capability Reporting Because SUIT is extensible, a manifest author must know what capabilities a device has available. To enable this, a capability report is a set of lists that define which commands, parameters, algorithms, and component IDs are supported by a manifest processor. The CDDL for a SUIT_Capability_Report follows:

[+ SUIT_Component_Capability ] suit-command-capabilities => [+ int], suit-parameters-capabilities => [+ int], suit-crypt-algo-capabilities => [+ int], ? suit-envelope-capabilities => [+ int], ? suit-manifest-capabilities => [+ int], ? suit-common-capabilities => [+ int], ? suit-text-capabilities => [+ int], ? suit-text-component-capabilities => [+ int], ? suit-dependency-capabilities => [+ int], * [+int] => [+ int], $$SUIT_Capability_Report_Extensions } SUIT_Component_Capability = [*bstr,?true] ]]>

A SUIT_Component_Capability is similar to a SUIT_Component_ID, with one difference: it may optionally be terminated by a CBOR 'true' which acts as a wild-card match for any component with a prefix matching the SUIT_Component_Capability leading up to the 'true.' This feature is for use with filesystem storage, key value stores, or any other arbitrary-component-id storage systems. When reporting capabilities, it is OPTIONAL to report capabilities that are declared mandatory by the SUIT Manifest . Capabilities defined by extensions MUST be reported. Additional capability reporting can be added as follows: if a manifest element does not exist in this map, it can be added by specifying the CBOR path to the manifest element in an array and using this as the key. For example SUIT_Dependencies, as described in , could have an extension added, which was key 3 in the SUIT_Dependencies map. This capability would be reported as: [3, 3, 1] => [3], where the key consists of the key for SUIT_Manifest (3), the key for SUIT_Common (3), and the key for SUIT_Dependencies (1). Then the value indicates that this manifest processor supports the extension (3).

EAT Claim The Entity Attestation Token (EAT, see ) is a secure container for conveying Attestation Evidence, such as measurements, and Attestation Results. The SUIT_Report is a form of measurement done by the SUIT Manifest Processor as it attempts to invoke a manifest or install a manifest. As a result, the SUIT_Report can be captured in an EAT measurements type. The log-based structure of the SUIT_Report is not conducive to processing by a typical Relying Party: it contains only a list of waypoints through the SUIT Manifest--unless system parameter records are included--and requires additional information (the SUIT_Manifest) to reconstruct the values that must have been present at each test. A Verifier in posession of the SUIT_Manifest can reconstruct the measurements that would produce the waypoints in the SUIT_Report. The Verifier SHOULD convert a SUIT_Report into a more consumable version of the EAT claim by, for example, constructing a measurement results claim that contains the digest of a component, the Vendor ID and Class ID of a component, etc.

SUIT_Report Container Transmission of the SUIT_Report MUST satisfy the requirements of : REQ.SEC.REPORTING. Status reports from the device to any remote system MUST be performed over an authenticated, confidential channel in order to prevent modification or spoofing of the reports. As a result, the SUIT_Report MUST be transported using one of the following methods: As part of a larger document that provides authenticity guarantees, such as within a measurements claim in an Entity Attestation Token (EAT, ). As the payload of a message transmitted over a communication security protocol, such as DTLS . Encapsulated within a secure container, such as a COSE structure. In the case of COSE, the container MUST be either a COSE_Encrypt0 or COSE_Sign1 structure. The SUIT_Report MUST be the sole payload, as illustrated by the CDDL fragment below.

any}, payload : bstr .cbor SUIT_Report_Unprotected, signature : bstr ] SUIT_Report_COSE_MAC0_Tagged = #6.17(SUIT_Report_COSE_MAC0) SUIT_Report_COSE_MAC0 = [ protected : bstr, unprotected : {* int => any}, payload : bstr .cbor SUIT_Report_Unprotected, tag : bstr ] SUIT_Report_Unprotected = SUIT_Report / SUIT_Report_COSE_Encrypt0 SUIT_Report_COSE_Encrypt0 = COSE_Encrypt0 ]]>

Note that SUIT_Report_COSE_Sign1 and SUIT_Report_COSE_MAC0 MUST be combined with a SUIT_COSE_Profiles from using the CDDL .and directive. The SUIT_Report_COSE_Encrypt0 carries a ciphertext payload that MUST contain just the ciphertext obtained by encrypting the following CDDL:

SUIT_COSE_Profiles, which use AES-CTR encryption, are not integrity protected and authenticated. For this purpose, SUIT_Report_Protected defines authenticated containers with an encrypted payload.

IANA Considerations IANA is requested to rename the overall SUIT registry group (https://www.iana.org/assignments/suit/suit.xhtml) "Software Update for the Internet of Things (SUIT)". IANA is requested to allocate a CBOR tag for each of the following items. Please see for further details. SUIT_Report_Protected SUIT_Reference SUIT_Capability_Report IANA is requested to allocate a CoAP content-format and a media-type for SUIT_Report . Please see and for further details. IANA is also requested to add the following registries to the SUIT registry group (https://www.iana.org/assignments/suit/suit.xhtml). SUIT_Report Elements SUIT_Record Elements SUIT_Report Reasons SUIT_Capability_Report Elements For each of these registries, registration policy is: -256 to 255: Standards Action -65536 to 257, 256 to 65535: Specification Required -4294967296 to -65537, 65536 to 4294967295: First Come First Served Requests in the Standards Action and Specification Required ranges MUST also undergo designated expert review as described below; this guidance supplements the normal IANA processing for those policies.

Expert Review Instructions The IANA registries established in this document allow values to be added based on expert review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude. Expert reviewers should take into consideration the following points: Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered, and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing. Specifications are required for the standards track range of point assignment. Specifications should exist for all other ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.

Media Type Registration

application/suit-report+cose IANA is requested to register application/suit-report+cose as a media type for the SUIT_Report.

Type name:

application

Subtype name:

suit-report+cose

Required parameters:

n/a

Encoding considerations:

binary (CBOR)

Security considerations:

of &SELF;

Interoperability considerations:

n/a

Published specification:

&SELF;

Applications that use this media type:

SUIT Manifest Processor, SUIT Manifest Distributor, SUIT Manifest Author, RATS Attesters, RATS Verifiers

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/cose".

Person & email address to contact for further information:

SUIT WG mailing list (suit@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

CoAP Content-Format Registration IANA is requested to assign a CoAP Content-Format ID for the SUIT_Report media type in the "CoAP Content-Formats" registry, from the "IETF Review with Expert Review or IESG Approval with Expert Review" space (256..9999), within the "CoRE Parameters" registry group : Content Type Content Coding ID Reference application/suit-report+cose   TBA &SELF;

CBOR Tag Registration IANA is requested to allocate a tag in the "CBOR Tags" registry , preferably in the Specification Required range: Tag Data Item Semantics TBA array SUIT_Report_Protected TBA array SUIT_Reference TBA map SUIT_Capability_Report

SUIT_Report Elements IANA is requested to create a new registry for SUIT_Report Elements. Label Name CDDL Label Reference 2 Nonce suit-report-nonce of &SELF; 3 Records suit-report-records of &SELF; 4 Result suit-report-result of &SELF; 5 Result Code suit-report-result-code of &SELF; 6 Result Record suit-report-result-record of &SELF; 7 Result Reason suit-report-result-reason of &SELF; 8 Capability Report suit-report-capability-report of &SELF; 99 Reference suit-reference of &SELF;

SUIT_Record Elements IANA is requested to create a new registry for SUIT_Record Elements. Label Name CDDL Label Reference 0 Manifest ID suit-record-manifest-id of &SELF; 1 Manifest Section suit-record-manifest-section of &SELF; 2 Section Offset suit-record-section-offset of &SELF; 3 Component Index suit-record-component-index of &SELF; 4 Record Properties suit-record-properties of &SELF;

SUIT_Report Reasons IANA is requested to create a new registry for SUIT_Report Reasons. Label Name CDDL Label Reference 0 Result OK suit-report-reason-ok of &SELF; 1 CBOR Parse Failure suit-report-reason-cbor-parse of &SELF; 2 Unsupported COSE Structure or Header suit-report-reason-cose-unsupported of &SELF; 3 Unsupported COSE Algorithm suit-report-reason-alg-unsupported of &SELF; 4 Signature / MAC verification failed suit-report-reason-unauthorised of &SELF; 5 Unsupported SUIT Command suit-report-reason-command-unsupported of &SELF; 6 Unsupported SUIT Component suit-report-reason-component-unsupported of &SELF; 7 Unauthorized SUIT Component suit-report-reason-component-unauthorised of &SELF; 8 Unsupported SUIT Parameter suit-report-reason-parameter-unsupported of &SELF; 9 Severing Unsupported suit-report-reason-severing-unsupported of &SELF; 10 Condition Failed suit-report-reason-condition-failed of &SELF; 11 Operation Failed suit-report-reason-operation-failed of &SELF; 12 Invocation Pending suit-report-reason-invoke-pending of &SELF;

 SUIT Capability Report Elements IANA is requested to create a new registry for SUIT Capability Report Elements. Label Name Reference   1 Components suit-component-capabilities of &SELF; 2 Commands suit-command-capabilities of &SELF; 3 Parameters suit-parameters-capabilities of &SELF; 4 Cryptographic Algorithms suit-crypt-algo-capabilities of &SELF; 5 Envelope Elements suit-envelope-capabilities of &SELF; 6 Manifest Elements suit-manifest-capabilities of &SELF; 7 Common Elements suit-common-capabilities of &SELF; 8 Text Elements suit-text-capabilities of &SELF; 9 Component Text Elements suit-text-component-capabilities of &SELF; 10 Dependency Capabilities suit-dependency-capabilities of &SELF;

Security Considerations The SUIT_Report serves four primary security objectives: Validated Identity Integrity Replay protection Confidentiality The mechanisms for achieving these protections are outlined in . Ideally, a SUIT_Report SHOULD be conveyed as part of a remote attestation procedure, such as embeding it in EAT tokens that represent RATS conceptual messages. This approach ensures that the SUIT_Report is cryptographically bound to the environment (hardware, software, or both) in which it was generated, thereby strengthening its authenticity. A SUIT_Report may disclose sensitive information about the device on which it were produced. In such cases, the SUIT_Report MUST be encrypted, as specified in . Furthermore, failure reports, particularly those involving cryptographic operations, can unintentionally reveal insights into system weaknesses or vulnerabilities. As such, SUIT_Reports SHOULD be encrypted whenever possible, to minimize the risk of information leakage. In addition to these core security requirements, operational considerations must be taken into account. When a SUIT_Report is included within another protocol message (e.g., inside an encrypted EAT), care must be taken to avoid inadvertently leaking information and to uphold the principle of least privilege. For example, in many EAT-based remote attestation flows, the Verifier may not require the full SUIT_Report. Similarly, the Relying Party might not need access to it either. To support least-privilege access, the SUIT_Report should be independently encrypted, even when the transport or enclosing token is also encrypted. This layered encryption ensures that only authorized entities can access the contents of the SUIT_Report. In other scenarios, the EAT Verifier might require full access to a SUIT_Report. For example, the SUIT_Report must be accessible in its entirety for the EAT Verifier to extract or convert the SUIT_Report content into specific EAT claims, such as measres (Measurement Results). A typical case involves translating a successful suit-condition-image check into a digest-based claim within the EAT. When applying cryptographic protection to the SUIT_Report, the same algorithm profile used for the corresponding SUIT manifest SHOULD be reused. The available algorithm profiles are detailed in . If using the same profile is not feasible (e.g., due to constraints imposed by suit-sha256-hsslms-a256kw-a256ctr), then a profile offering comparable security strength SHOULD be selected—for instance, suit-sha256-esp256-ecdh-a128ctr. In exceptional cases, if no suitable profile can be applied, the necessity of disabling a SUIT_Report functionality altogether might arise. SUIT_Reports may expose information about the user to the Verifier, Firmware Distributor, or Manifest Author. Implementors MUST carefully consider user consent in the reporting system.

Acknowledgements The authors would like to thank Dave Thaler for his feedback.

Arm Limited University of Applied Sciences Bonn-Rhein-Sieg Fraunhofer SIT Inria Nordic Semiconductor 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 Internet of Things (IoT) device), where to find the 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. Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. 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. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Arm Limited Nordic Semiconductor Openchip & Software Technologies, S.L. The SUIT manifest, as defined in "A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices" (RFC 9124), provides a flexible and extensible format for describing how firmware and software updates are to be fetched, verified, decrypted, and installed on resource-constrained devices. To ensure the security of these update processes, the manifest relies on cryptographic algorithms for functions such as digital signature verification, integrity checking, and confidentiality. This document defines cryptographic algorithm profiles for use with the Software Updates for Internet of Things (SUIT) manifest. These profiles specify sets of algorithms to promote interoperability across implementations. Given the diversity of IoT deployments and the evolving cryptographic landscape, algorithm agility is essential. This document groups algorithms into named profiles to accommodate varying levels of device capabilities and security requirements. These profiles support the use cases laid out in the SUIT architecture, published in "A Firmware Update Architecture for Internet of Things" (RFC 9019). IANA IANA 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. Arm Limited SECOM CO., LTD. A device has more than one trust domain when it enables delegation of different rights to mutually distrusting entities for use for different purposes or Components in the context of firmware or software update. This specification describes extensions to the Software Update for the Internet of Things (SUIT) Manifest format for use in deployments with multiple trust domains. Fraunhofer SIT Microsoft Research Microsoft Research ARM Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. AMD Independent Independent Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester to decide if continued interaction is warrented. Evidence structures can vary making appraisals challenging for Verifiers. Verifiers need to understand Evidence encoding formats and some of the Evidence semantics to appraise it. Consequently, Evidence may require format transformation to an internal representation that preserves original semantics. This document specifies Evidence transformation methods for DiceTcbInfo, concise evidence, and SPDM measurements block structures. These Evidence structures are converted to the CoRIM internal representation and follow CoRIM defined appraisal procedures. Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality. One component of such a firmware update is a concise and machine-processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.

Full CDDL In order to create a valid SUIT_Report document the structure of the corresponding CBOR message MUST adhere to the following CDDL () data definition. To be valid, the following CDDL MUST have the COSE CDDL appended to it. The COSE CDDL can be obtained by following the directions in . It must also have the CDDL from appended to it. This CDDL is line-wrapped per .

any}, payload : bstr .cbor SUIT_Report_Unprotected, signature : bstr ] SUIT_Report_COSE_MAC0_Tagged = #6.17(SUIT_Report_COSE_MAC0) SUIT_Report_COSE_MAC0 = [ protected : bstr, unprotected : {* int => any}, payload : bstr .cbor SUIT_Report_Unprotected, tag : bstr ] SUIT_Report_Unprotected = SUIT_Report / SUIT_Report_COSE_Encrypt0 SUIT_Report_COSE_Encrypt0 = COSE_Encrypt0 SUIT_Report = { suit-reference => SUIT_Reference, ? suit-report-nonce => bstr, suit-report-records => [ * SUIT_Record / system-property-claims ], suit-report-result => true / { suit-report-result-code => int, suit-report-result-record => SUIT_Record, suit-report-result-reason => SUIT_Report_Reasons, }, ? suit-report-capability-report => SUIT_Capability_Report, $$SUIT_Report_Extensions } SUIT_Reference = [ suit-report-manifest-uri : tstr, suit-report-manifest-digest : SUIT_Digest ] SUIT_Record = [ suit-record-manifest-id : [* uint ], suit-record-manifest-section : int, suit-record-section-offset : uint, suit-record-component-index : uint, suit-record-properties : {*$$SUIT_Parameters}, $$SUIT_Record_Extensions ] system-property-claims = { system-component-id => SUIT_Component_Identifier, + $$SUIT_Parameters, } SUIT_Capability_Report = { suit-component-capabilities => [+ SUIT_Component_Capability] suit-command-capabilities => [+ int], suit-parameters-capabilities => [+ int], suit-crypt-algo-capabilities => [+ int], ? suit-envelope-capabilities => [+ int], ? suit-manifest-capabilities => [+ int], ? suit-common-capabilities => [+ int], ? suit-text-capabilities => [+ int], ? suit-text-component-capabilities => [+ int], ? suit-dependency-capabilities => [+ int], * [+int] => [+ int], $$SUIT_Capability_Report_Extensions } SUIT_Component_Capability = [*bstr,?true] suit-report-nonce = 2 suit-report-records = 3 suit-report-result = 4 suit-report-result-code = 5 suit-report-result-record = 6 suit-report-result-reason = 7 suit-report-capability-report = 8 suit-reference = 99 system-component-id = 0 suit-record-manifest-id = 0 suit-record-manifest-section = 1 suit-record-section-offset = 2 suit-record-component-index = 3 suit-record-properties = 4 SUIT_Report_Reasons /= suit-report-reason-ok SUIT_Report_Reasons /= suit-report-reason-cbor-parse SUIT_Report_Reasons /= suit-report-reason-cose-unsupported SUIT_Report_Reasons /= suit-report-reason-alg-unsupported SUIT_Report_Reasons /= suit-report-reason-unauthorised SUIT_Report_Reasons /= suit-report-reason-command-unsupported SUIT_Report_Reasons /= suit-report-reason-component-unsupported SUIT_Report_Reasons /= suit-report-reason-component-unauthorised SUIT_Report_Reasons /= suit-report-reason-parameter-unsupported SUIT_Report_Reasons /= suit-report-reason-severing-unsupported SUIT_Report_Reasons /= suit-report-reason-condition-failed SUIT_Report_Reasons /= suit-report-reason-operation-failed SUIT_Report_Reasons /= suit-report-reason-invoke-pending suit-report-reason-ok = 0 suit-report-reason-cbor-parse = 1 suit-report-reason-cose-unsupported = 2 suit-report-reason-alg-unsupported = 3 suit-report-reason-unauthorised = 4 suit-report-reason-command-unsupported = 5 suit-report-reason-component-unsupported = 6 suit-report-reason-component-unauthorised = 7 suit-report-reason-parameter-unsupported = 8 suit-report-reason-severing-unsupported = 9 suit-report-reason-condition-failed = 10 suit-report-reason-operation-failed = 11 suit-report-reason-invoke-pending = 12 suit-component-capabilities = 1 suit-command-capabilities = 2 suit-parameters-capabilities = 3 suit-crypt-algo-capabilities = 4 suit-envelope-capabilities = 5 suit-manifest-capabilities = 6 suit-common-capabilities = 7 suit-text-capabilities = 8 suit-text-component-capabilities = 9 suit-dependency-capabilities = 10 ]]>