Skip to content

Latest commit

 

History

History
121 lines (78 loc) · 12.8 KB

REQUIREMENTS.md

File metadata and controls

121 lines (78 loc) · 12.8 KB
Raw

This document gathers requirements related to the suit-manifest-processor (suit-mp) implementation. Some requirements are fulfilled by the suit-mp itself, while others are fulfilled indirectly, or must be attended to by the user of suit-mp.

The rest of the document is divided into sections according to who will fulfill the requirements.

Any text in italics is quoted from the provided link.

Requirements covered by zcbor-generated code

Requirements from manifest211:

  • no custom commands are permitted in the shared sequence. (6.2)
  • The suit-authentication-wrapper MUST come before the suit-manifest element, regardless of canonical encoding of CBOR. A SUIT_Envelope that has not had authentication information added MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest. (8.3)
  • Full CDDL (Appendix A)

Requirements from information model2:

Implemented via the CDDL

Requirements covered by device code in suit-manifest-processor

Requirements from manifest211:

  • Compatibility must be checked before any other operation is performed. (4.2)
  • All payloads must be validated prior to loading. (4.2)
  • All loaded images must be validated prior to execution. (4.2)
  • Whenever the manifest processor can choose between several manifests, it MUST select the latest valid, authentic manifest. If the latest valid, authentic manifest fails, it MAY select the next latest valid, authentic manifest, according to application-specific policy. (6.1)
  • The RECOMMENDED process is to verify the signature of the manifest prior to parsing/executing any section of the manifest. This guards the parser against arbitrary input by unauthenticated third parties, but it costs extra energy when a Recipient receives an incompatible manifest. (6.2)
  • Once a valid, authentic manifest has been selected, the manifest processor MUST examine the component list and verify that its maximum number of components is not exceeded and that each listed component is supported. (6.2)
  • For each listed component, the manifest processor MUST provide storage for the supported parameters. (6.2)
  • The manifest processor SHOULD check that the shared sequence contains at least Check Vendor Identifier command and at least one Check Class Identifier command. (6.2)
  • If the manifest contains more than one component, each command sequence MUST begin with a Set Component Index. (6.2)
  • If a Recipient supports groups of interdependent components (a Component Set), then it SHOULD verify that all Components in the Component Set are specified by one update, that is the manifest: 1) has sufficient permissions imparted by its signatures, 2) specifies a digest and a payload for every Component in the Component Set. (6.2)
  • The manifest parser MUST NOT execute any command with side-effects outside the parser (for example, Invoke, Copy, Swap, or Fetch commands) prior to authentication [or at any time in the shared sequence] and any such command MUST Abort (6.2.1)
  • Executing an update MUST either result in an error, or a verifiably correct system state. (6.3)
  • Executing a Trusted Invocation MUST either result in an error, or an invoked image. (6.3)
  • Executing the same manifest on multiple Recipients MUST result in the same system state. (6.3)
  • Where a command is not repeatable because of the way in which it alters system state (e.g. swapping images or in-place delta) it MUST be resumable or revertible. This applies to commands that modify at least one source component as well as the destination component. (6.3.1)
  • Conditions MUST NOT have any side-effects other than informing the interpreter of success or failure. (6.4)
  • The Interpreter MUST Abort if a Directive reports failure regardless of the Soft Failure flag. (6.4)
  • A digest MUST always be set using Override Parameters. (7)
  • The suit-authentication-wrapper MUST come before the suit-manifest element, regardless of canonical encoding of CBOR. A SUIT_Envelope that has not had authentication information added MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest. (8.3)

Requirements from information model2:

Requirements covered by platform code

Requirements from manifest181:

  • Where a command is not repeatable because of the way in which it alters system state (e.g. swapping images or in-place delta) it MUST be resumable or revertible. This applies to commands that modify at least one source component as well as the destination component. (6.3.1)
  • Conditions MUST NOT have any side-effects other than informing the interpreter of success or failure. (6.4)

Requirements from information model2:

Requirements covered by the suit-manifest-processor build system

Own requirements

  • Regardless of the modifications to the CDDL used to build the suit-mp, or to generate the manifest, the build system should contain a step where the manifest is validated against a (largely) unmodified version of the Full CDDL.

Requirements from manifest181:

  • All payloads must be validated prior to loading. (4.2)
  • All loaded images must be validated prior to execution. (4.2)
  • The suit-authentication-wrapper MUST come before the suit-manifest element, regardless of canonical encoding of CBOR. (8.3)
  • A SUIT_Envelope that has not had authentication information added MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest. (8.3)

Requirements from information model2:

Requirements covered by user

Requirements from manifest181:

  • Whenever the manifest processor can choose between several manifests, it MUST select the latest valid, authentic manifest. If the latest valid, authentic manifest fails, it MAY select the next latest valid, authentic manifest, according to application-specific policy. (6.1)
  • Manifests are constructed so that repeated partial invocations of any manifest sequence always results in a correct system configuration. (6.3.1)
  • The author MUST ensure that all parameters consumed by a command are set prior to invoking that command. Where Component Index = True, this means that the parameters consumed by each command MUST have been set for each Component. (7)
  • A signing application MUST verify the suit-manifest element against the SUIT_Digest prior to signing. (8.3)
  • Each SUIT_Component_Identifier => map entry contains a map of integer => text values. All SUIT_Component_Identifiers present in suit-text MUST also be present in suit-common (8.4.4)

Requirements from information model2:

References

Footnotes

  1. IETF draft-ietf-suit-manifest-21 - A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest - https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-21 ↩ ↩2 ↩3 ↩4 ↩5

  2. IETF RFC 9124 - A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices - https://datatracker.ietf.org/doc/rfc9124/ ↩ ↩2 ↩3 ↩4 ↩5