Secure Reporting of Update StatusArm LimitedBrendan.Moran@arm.com
Security
SUITInternet-DraftThe 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. However, this does not
provide a feedback mechanism for developers in the event that an update
or boot fails.This specification describes 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.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 loggingmissing information elementsmissing support for multiple componentsThe CBOR objects defined in this document allow devices to:report a trace of how an update was performedreport expected vs. actual values for critical checksdescribe the installation of complex multi-component architecturesThis document provides a definition of a SUIT-specific logging container
that may be used in a variety of scenarios.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.Terms used in this specification include:Boot: initialization of an executable image. Although this
specification refers to boot, any boot-specific operations described
are equally applicable to starting an executable in an OS context.If the developer can be assumed to have a copy of the
manifest, then they need little information to reconstruct what the
manifest processor has done. They simply need any data that influences
the control flow of the manifest. The manifest only supports the
following control flow primitives:Set Component/Dependency IndexSet/Override ParametersTry-EachRun SequenceConditions.Of these, only conditions change the behavior of the processor from the
default, and then only when the condition fails.Then, to reconstruct the flow of a manifest, all a developer needs is
a list of metadata about failed conditions:the current manifestthe current sectionthe offset into the current sectionthe current component indexthe “reason” for failureMost conditions compare a parameter to an actual value, so the “reason”
is typically simply the actual value.Since it is possible that a non-condition command may fail in an
exceptional circumstance, this must be included as well. To accommodate
for a failed command, the list of failed conditions is expanded to be a
list of failed commands instead. In the case of a command failure,
the failure reason is typically a numeric error code.Reconstructing what a device has done in this way is compact,
however it requires some reconstruction effort. This is an issue that
can be solved by tooling.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 Dependency A0Dependency A1Dependency B Dependency B0Dependency B1Dependency C Dependency C0Dependency C1A manifest-id of [1,0] would indicate that the current command was
contained within Dependency B0. Similarly, a manifest-id of [2,1]
would indicate Dependency C1suit-record-manifest-section indicates which section of the manifest was
active. This is used in addition to an offset so that the developer can
index into severable sections in a predictable way. The value of this
element is the value of the key that identified the section in the
manifest.suit-record-section-offset is the number of bytes into the current
section 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-dependency-index is similar to suit-record-component-index
but is used to identify the dependency that was active.suit-record-failure-reason contains the reason for 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 .
If it is not a condition that has failed, but a
directive, then the value of this element is an integer that represents
an implementation-defined failure code.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.suit-report-manifest-digest provides a SUIT_Digest (as defined in ) that is the
characteristic digest of the Root manifest.suit-report-manifest-uri provides the reference URI that was provided in
the root manifest.suit-report-records is a list of 0 or more SUIT Records. Because SUIT
Records are only generated on failure, in simple cases this can be an
empty list.IANA is requested to allocate a CBOR tag for the SUIT Report.The SUIT Report should either be carried over a secure transport, or
signed, or both. Ideally, attestation should be used to prove that the
report was generated by legitimate hardware.A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) ManifestThis 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. Firmware updates and secure boot both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. The manifest also serves as a building block for secure boot.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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.