| < draft-ietf-suit-manifest-16.txt | draft-ietf-suit-manifest-17.txt > | |||
|---|---|---|---|---|
| SUIT B. Moran | SUIT B. Moran | |||
| Internet-Draft H. Tschofenig | Internet-Draft H. Tschofenig | |||
| Intended status: Standards Track Arm Limited | Intended status: Standards Track Arm Limited | |||
| Expires: 29 April 2022 H. Birkholz | Expires: 30 October 2022 H. Birkholz | |||
| Fraunhofer SIT | Fraunhofer SIT | |||
| K. Zandberg | K. Zandberg | |||
| Inria | Inria | |||
| 26 October 2021 | 28 April 2022 | |||
| A Concise Binary Object Representation (CBOR)-based Serialization Format | A Concise Binary Object Representation (CBOR)-based Serialization Format | |||
| for the Software Updates for Internet of Things (SUIT) Manifest | for the Software Updates for Internet of Things (SUIT) Manifest | |||
| draft-ietf-suit-manifest-16 | draft-ietf-suit-manifest-17 | |||
| Abstract | Abstract | |||
| This specification describes the format of a manifest. A manifest is | This specification describes the format of a manifest. A manifest is | |||
| a bundle of metadata about code/data obtained by a recipient (chiefly | 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 firmware for an IoT device), where to find the that code/data, | |||
| the devices to which it applies, and cryptographic information | the devices to which it applies, and cryptographic information | |||
| protecting the manifest. Software updates and Trusted Invocation | protecting the manifest. Software updates and Trusted Invocation | |||
| both tend to use sequences of common operations, so the manifest | both tend to use sequences of common operations, so the manifest | |||
| encodes those sequences of operations, rather than declaring the | encodes those sequences of operations, rather than declaring the | |||
| skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 29 April 2022. | This Internet-Draft will expire on 30 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Simplified BSD License text | extracted from this document must include Revised BSD License text as | |||
| as described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 | 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 | |||
| 3. How to use this Document . . . . . . . . . . . . . . . . . . 8 | 3. How to use this Document . . . . . . . . . . . . . . . . . . 8 | |||
| 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 4.1. IoT Firmware Update Constraints . . . . . . . . . . . . . 9 | 4.1. IoT Firmware Update Constraints . . . . . . . . . . . . . 9 | |||
| 4.2. SUIT Workflow Model . . . . . . . . . . . . . . . . . . . 10 | 4.2. SUIT Workflow Model . . . . . . . . . . . . . . . . . . . 10 | |||
| 5. Metadata Structure Overview . . . . . . . . . . . . . . . . . 11 | 5. Metadata Structure Overview . . . . . . . . . . . . . . . . . 11 | |||
| 5.1. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.1. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5.2. Authentication Block . . . . . . . . . . . . . . . . . . 12 | 5.2. Authentication Block . . . . . . . . . . . . . . . . . . 13 | |||
| 5.3. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 13 | 5.3. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.3.1. Critical Metadata . . . . . . . . . . . . . . . . . . 13 | 5.3.1. Critical Metadata . . . . . . . . . . . . . . . . . . 13 | |||
| 5.3.2. Common . . . . . . . . . . . . . . . . . . . . . . . 13 | 5.3.2. Common . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.3.3. Command Sequences . . . . . . . . . . . . . . . . . . 14 | 5.3.3. Command Sequences . . . . . . . . . . . . . . . . . . 14 | |||
| 5.3.4. Integrity Check Values . . . . . . . . . . . . . . . 14 | 5.3.4. Integrity Check Values . . . . . . . . . . . . . . . 14 | |||
| 5.3.5. Human-Readable Text . . . . . . . . . . . . . . . . . 14 | 5.3.5. Human-Readable Text . . . . . . . . . . . . . . . . . 14 | |||
| 5.4. Severable Elements . . . . . . . . . . . . . . . . . . . 15 | 5.4. Severable Elements . . . . . . . . . . . . . . . . . . . 15 | |||
| 5.5. Integrated Payloads . . . . . . . . . . . . . . . . . . . 15 | 5.5. Integrated Payloads . . . . . . . . . . . . . . . . . . . 15 | |||
| 6. Manifest Processor Behavior . . . . . . . . . . . . . . . . . 15 | 6. Manifest Processor Behavior . . . . . . . . . . . . . . . . . 15 | |||
| 6.1. Manifest Processor Setup . . . . . . . . . . . . . . . . 16 | 6.1. Manifest Processor Setup . . . . . . . . . . . . . . . . 16 | |||
| skipping to change at page 3, line 9 ¶ | skipping to change at page 3, line 9 ¶ | |||
| 7.6. Load from Nonvolatile Storage Template . . . . . . . . . 26 | 7.6. Load from Nonvolatile Storage Template . . . . . . . . . 26 | |||
| 7.7. A/B Image Template . . . . . . . . . . . . . . . . . . . 26 | 7.7. A/B Image Template . . . . . . . . . . . . . . . . . . . 26 | |||
| 8. Metadata Structure . . . . . . . . . . . . . . . . . . . . . 28 | 8. Metadata Structure . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 8.1. Encoding Considerations . . . . . . . . . . . . . . . . . 28 | 8.1. Encoding Considerations . . . . . . . . . . . . . . . . . 28 | |||
| 8.2. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 28 | 8.2. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 8.3. Authenticated Manifests . . . . . . . . . . . . . . . . . 29 | 8.3. Authenticated Manifests . . . . . . . . . . . . . . . . . 29 | |||
| 8.4. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 29 | 8.4. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 8.4.1. suit-manifest-version . . . . . . . . . . . . . . . . 30 | 8.4.1. suit-manifest-version . . . . . . . . . . . . . . . . 30 | |||
| 8.4.2. suit-manifest-sequence-number . . . . . . . . . . . . 30 | 8.4.2. suit-manifest-sequence-number . . . . . . . . . . . . 30 | |||
| 8.4.3. suit-reference-uri . . . . . . . . . . . . . . . . . 30 | 8.4.3. suit-reference-uri . . . . . . . . . . . . . . . . . 30 | |||
| 8.4.4. suit-text . . . . . . . . . . . . . . . . . . . . . . 30 | 8.4.4. suit-text . . . . . . . . . . . . . . . . . . . . . . 31 | |||
| 8.4.5. suit-common . . . . . . . . . . . . . . . . . . . . . 32 | 8.4.5. suit-common . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 8.4.6. SUIT_Command_Sequence . . . . . . . . . . . . . . . . 33 | 8.4.6. SUIT_Command_Sequence . . . . . . . . . . . . . . . . 33 | |||
| 8.4.7. Reporting Policy . . . . . . . . . . . . . . . . . . 35 | 8.4.7. Reporting Policy . . . . . . . . . . . . . . . . . . 35 | |||
| 8.4.8. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 36 | 8.4.8. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 36 | |||
| 8.4.9. SUIT_Condition . . . . . . . . . . . . . . . . . . . 42 | 8.4.9. SUIT_Condition . . . . . . . . . . . . . . . . . . . 42 | |||
| 8.4.10. SUIT_Directive . . . . . . . . . . . . . . . . . . . 45 | 8.4.10. SUIT_Directive . . . . . . . . . . . . . . . . . . . 45 | |||
| 8.4.11. Integrity Check Values . . . . . . . . . . . . . . . 50 | 8.4.11. Integrity Check Values . . . . . . . . . . . . . . . 50 | |||
| 8.5. Severable Elements . . . . . . . . . . . . . . . . . . . 50 | 8.5. Severable Elements . . . . . . . . . . . . . . . . . . . 50 | |||
| 9. Access Control Lists . . . . . . . . . . . . . . . . . . . . 50 | 9. Access Control Lists . . . . . . . . . . . . . . . . . . . . 50 | |||
| 10. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 51 | 10. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 51 | |||
| skipping to change at page 3, line 43 ¶ | skipping to change at page 3, line 43 ¶ | |||
| B.2. Example 1: Simultaneous Download and Installation of | B.2. Example 1: Simultaneous Download and Installation of | |||
| Payload . . . . . . . . . . . . . . . . . . . . . . . . . 67 | Payload . . . . . . . . . . . . . . . . . . . . . . . . . 67 | |||
| B.3. Example 2: Simultaneous Download, Installation, Secure | B.3. Example 2: Simultaneous Download, Installation, Secure | |||
| Boot, Severed Fields . . . . . . . . . . . . . . . . . . 69 | Boot, Severed Fields . . . . . . . . . . . . . . . . . . 69 | |||
| B.4. Example 3: A/B images . . . . . . . . . . . . . . . . . . 73 | B.4. Example 3: A/B images . . . . . . . . . . . . . . . . . . 73 | |||
| B.5. Example 4: Load from External Storage . . . . . . . . . . 76 | B.5. Example 4: Load from External Storage . . . . . . . . . . 76 | |||
| B.6. Example 5: Two Images . . . . . . . . . . . . . . . . . . 79 | B.6. Example 5: Two Images . . . . . . . . . . . . . . . . . . 79 | |||
| Appendix C. C. Design Rational . . . . . . . . . . . . . . . . 82 | Appendix C. C. Design Rational . . . . . . . . . . . . . . . . 82 | |||
| C.1. C.1 Design Rationale: Envelope . . . . . . . . . . . . . 83 | C.1. C.1 Design Rationale: Envelope . . . . . . . . . . . . . 83 | |||
| C.2. C.2 Byte String Wrappers . . . . . . . . . . . . . . . . 84 | C.2. C.2 Byte String Wrappers . . . . . . . . . . . . . . . . 84 | |||
| Appendix D. D. Implementation Conformance Matrix . . . . . . . 84 | Appendix D. D. Implementation Conformance Matrix . . . . . . . 85 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87 | |||
| 1. Introduction | 1. Introduction | |||
| A firmware update mechanism is an essential security feature for IoT | A firmware update mechanism is an essential security feature for IoT | |||
| devices to deal with vulnerabilities. While the transport of | devices to deal with vulnerabilities. While the transport of | |||
| firmware images to the devices themselves is important there are | firmware images to the devices themselves is important there are | |||
| already various techniques available. Equally important is the | already various techniques available. Equally important is the | |||
| inclusion of metadata about the conveyed firmware image (in the form | inclusion of metadata about the conveyed firmware image (in the form | |||
| of a manifest) and the use of a security wrapper to provide end-to- | of a manifest) and the use of a security wrapper to provide end-to- | |||
| end security protection to detect modifications and (optionally) to | end security protection to detect modifications and (optionally) to | |||
| skipping to change at page 4, line 43 ¶ | skipping to change at page 4, line 43 ¶ | |||
| * Verify them | * Verify them | |||
| * Load them into memory | * Load them into memory | |||
| * Invoke them | * Invoke them | |||
| This specification defines the SUIT manifest format and it is | This specification defines the SUIT manifest format and it is | |||
| intended to meet several goals: | intended to meet several goals: | |||
| * Meet the requirements defined in | * Meet the requirements defined in [RFC9124]. | |||
| [I-D.ietf-suit-information-model]. | ||||
| * Simple to parse on a constrained node | * Simple to parse on a constrained node | |||
| * Simple to process on a constrained node | * Simple to process on a constrained node | |||
| * Compact encoding | * Compact encoding | |||
| * Comprehensible by an intermediate system | * Comprehensible by an intermediate system | |||
| * Expressive enough to enable advanced use cases on advanced nodes | * Expressive enough to enable advanced use cases on advanced nodes | |||
| skipping to change at page 5, line 37 ¶ | skipping to change at page 5, line 37 ¶ | |||
| * a device to reason about the installation of a firmware. | * a device to reason about the installation of a firmware. | |||
| * a device to reason about the authenticity & encoding of a firmware | * a device to reason about the authenticity & encoding of a firmware | |||
| at boot. | at boot. | |||
| Each of these uses happens at a different stage of the manifest | Each of these uses happens at a different stage of the manifest | |||
| lifecycle, so each has different requirements. | lifecycle, so each has different requirements. | |||
| It is assumed that the reader is familiar with the high-level | It is assumed that the reader is familiar with the high-level | |||
| firmware update architecture [RFC9019] and the threats, requirements, | firmware update architecture [RFC9019] and the threats, requirements, | |||
| and user stories in [I-D.ietf-suit-information-model]. | and user stories in [RFC9124]. | |||
| The design of this specification is based on an observation that the | The design of this specification is based on an observation that the | |||
| vast majority of operations that a device can perform during an | vast majority of operations that a device can perform during an | |||
| update or Trusted Invocation are composed of a small group of | update or Trusted Invocation are composed of a small group of | |||
| operations: | operations: | |||
| * Copy some data from one place to another | * Copy some data from one place to another | |||
| * Transform some data | * Transform some data | |||
| skipping to change at page 6, line 23 ¶ | skipping to change at page 6, line 23 ¶ | |||
| firmware image from one place to another, checking that a firmware | firmware image from one place to another, checking that a firmware | |||
| image is correct, verifying that the specified firmware is the | image is correct, verifying that the specified firmware is the | |||
| correct firmware for the device, or unpacking a firmware. By using | correct firmware for the device, or unpacking a firmware. By using | |||
| these steps in different orders and changing the parameters they use, | these steps in different orders and changing the parameters they use, | |||
| a broad range of use cases can be supported. The SUIT manifest uses | a broad range of use cases can be supported. The SUIT manifest uses | |||
| this observation to optimize metadata for consumption by constrained | this observation to optimize metadata for consumption by constrained | |||
| devices. | devices. | |||
| While the SUIT manifest is informed by and optimized for firmware | While the SUIT manifest is informed by and optimized for firmware | |||
| update and Trusted Invocation use cases, there is nothing in the SUIT | update and Trusted Invocation use cases, there is nothing in the SUIT | |||
| Information Model ([I-D.ietf-suit-information-model]) that restricts | Information Model ([RFC9124]) that restricts its use to only those | |||
| its use to only those use cases. Other use cases include the | use cases. Other use cases include the management of trusted | |||
| management of trusted applications (TAs) in a Trusted Execution | applications (TAs) in a Trusted Execution Environment (TEE), as | |||
| Environment (TEE), as discussed in [I-D.ietf-teep-architecture]. | discussed in [I-D.ietf-teep-architecture]. | |||
| 2. Conventions and Terminology | 2. Conventions and Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| Additionally, the following terminology is used throughout this | Additionally, the following terminology is used throughout this | |||
| skipping to change at page 7, line 7 ¶ | skipping to change at page 7, line 7 ¶ | |||
| * Resource: A piece of information that is used to construct a | * Resource: A piece of information that is used to construct a | |||
| payload. | payload. | |||
| * Manifest: A manifest is a bundle of metadata about the firmware | * Manifest: A manifest is a bundle of metadata about the firmware | |||
| for an IoT device, where to find the firmware, and the devices to | for an IoT device, where to find the firmware, and the devices to | |||
| which it applies. | which it applies. | |||
| * Envelope: A container with the manifest, an authentication wrapper | * Envelope: A container with the manifest, an authentication wrapper | |||
| with cryptographic information protecting the manifest, | with cryptographic information protecting the manifest, | |||
| authorization information, and severable elements (see: TBD). | authorization information, and severable elements. | |||
| * Update: One or more manifests that describe one or more payloads. | * Update: One or more manifests that describe one or more payloads. | |||
| * Update Authority: The owner of a cryptographic key used to sign | * Update Authority: The owner of a cryptographic key used to sign | |||
| updates, trusted by Recipients. | updates, trusted by Recipients. | |||
| * Recipient: The system, typically an IoT device, that receives and | * Recipient: The system, typically an IoT device, that receives and | |||
| processes a manifest. | processes a manifest. | |||
| * Manifest Processor: A component of the Recipient that consumes | * Manifest Processor: A component of the Recipient that consumes | |||
| skipping to change at page 9, line 11 ¶ | skipping to change at page 9, line 11 ¶ | |||
| The IANA consideration section, see Section 11, provides instructions | The IANA consideration section, see Section 11, provides instructions | |||
| to IANA to create several registries. This section also provides the | to IANA to create several registries. This section also provides the | |||
| CBOR labels for the structures defined in this document. | CBOR labels for the structures defined in this document. | |||
| The complete CDDL description is provided in Appendix A, examples are | The complete CDDL description is provided in Appendix A, examples are | |||
| given in Appendix B and a design rational is offered in Appendix C. | given in Appendix B and a design rational is offered in Appendix C. | |||
| Finally, Appendix D gives a summarize of the mandatory-to-implement | Finally, Appendix D gives a summarize of the mandatory-to-implement | |||
| features of this specification. | features of this specification. | |||
| This specification covers the core features of SUIT. Additional | This specification covers the core features of SUIT. Additional | |||
| specifications will cover advanced use cases and update management | specifications describe functionality of advanced use cases, such as: | |||
| needs: | ||||
| * Firmware Encryption is covered in | * Firmware Encryption is covered in | |||
| [I-D.ietf-suit-firmware-encryption] | [I-D.ietf-suit-firmware-encryption] | |||
| * Update Management is covered in (TBD) | * Update Management is covered in [I-D.ietf-suit-update-management] | |||
| * Multiple Trust Domains (dependencies, key delegation, multiple | * Features, such as dependencies, key delegation, multiple | |||
| processors, TEEs, etc.) are covered in (TBD) | processors, required by the use of multiple trust domains are | |||
| covered in [I-D.ietf-suit-trust-domains] | ||||
| * Update Compression is covered in (TBD) | * Secure reporting of the update status is covered in | |||
| [I-D.ietf-suit-report] | ||||
| * Compression of firmware images | ||||
| 4. Background | 4. Background | |||
| Distributing software updates to diverse devices with diverse trust | Distributing software updates to diverse devices with diverse trust | |||
| anchors in a coordinated system presents unique challenges. Devices | anchors in a coordinated system presents unique challenges. Devices | |||
| have a broad set of constraints, requiring different metadata to make | have a broad set of constraints, requiring different metadata to make | |||
| appropriate decisions. There may be many actors in production IoT | appropriate decisions. There may be many actors in production IoT | |||
| systems, each of whom has some authority. Distributing firmware in | systems, each of whom has some authority. Distributing firmware in | |||
| such a multi-party environment presents additional challenges. Each | such a multi-party environment presents additional challenges. Each | |||
| party requires a different subset of data. Some data may not be | party requires a different subset of data. Some data may not be | |||
| accessible to all parties. Multiple signatures may be required from | accessible to all parties. Multiple signatures may be required from | |||
| parties with different authorities. This topic is covered in more | parties with different authorities. This topic is covered in more | |||
| depth in [RFC9019]. The security aspects are described in | depth in [RFC9019]. The security aspects are described in [RFC9124]. | |||
| [I-D.ietf-suit-information-model]. | ||||
| 4.1. IoT Firmware Update Constraints | 4.1. IoT Firmware Update Constraints | |||
| The various constraints of IoT devices and the range of use cases | The various constraints of IoT devices and the range of use cases | |||
| that need to be supported create a broad set of requirements. For | that need to be supported create a broad set of requirements. For | |||
| example, devices with: | example, devices with: | |||
| * limited processing power and storage may require a simple | * limited processing power and storage may require a simple | |||
| representation of metadata. | representation of metadata. | |||
| skipping to change at page 17, line 6 ¶ | skipping to change at page 17, line 6 ¶ | |||
| * Required parameter not supplied. | * Required parameter not supplied. | |||
| These failure reasons MAY be combined with retry mechanisms prior to | These failure reasons MAY be combined with retry mechanisms prior to | |||
| marking a manifest as invalid. | marking a manifest as invalid. | |||
| Selecting an older manifest in the event of failure of the latest | Selecting an older manifest in the event of failure of the latest | |||
| valid manifest is a robustness mechanism that is necessary for | valid manifest is a robustness mechanism that is necessary for | |||
| supporting the requirements in [RFC9019], section 3.5. It may not be | supporting the requirements in [RFC9019], section 3.5. It may not be | |||
| appropriate for all applications. In particular Trusted Execution | appropriate for all applications. In particular Trusted Execution | |||
| Environments MAY require a failure to invoke a new installation, | Environments MAY require a failure to invoke a new installation, | |||
| rather than a rollback approach. See | rather than a rollback approach. See [RFC9124], Section 4.2.1 for | |||
| [I-D.ietf-suit-information-model], Section 4.2.1 for more discussion | more discussion on the security considerations that apply to | |||
| on the security considerations that apply to rollback. | rollback. | |||
| Following these initial tests, the manifest processor clears all | Following these initial tests, the manifest processor clears all | |||
| parameter storage. This ensures that the manifest processor begins | parameter storage. This ensures that the manifest processor begins | |||
| without any leaked data. | without any leaked data. | |||
| 6.2. Required Checks | 6.2. Required Checks | |||
| The RECOMMENDED process is to verify the signature of the manifest | The RECOMMENDED process is to verify the signature of the manifest | |||
| prior to parsing/executing any section of the manifest. This guards | prior to parsing/executing any section of the manifest. This guards | |||
| the parser against arbitrary input by unauthenticated third parties, | the parser against arbitrary input by unauthenticated third parties, | |||
| skipping to change at page 29, line 11 ¶ | skipping to change at page 29, line 11 ¶ | |||
| The Envelope contains each of the other primary constituent parts of | The Envelope contains each of the other primary constituent parts of | |||
| the SUIT metadata. It allows for modular processing of the manifest | the SUIT metadata. It allows for modular processing of the manifest | |||
| by ordering components in the expected order of processing. | by ordering components in the expected order of processing. | |||
| The Envelope is encoded as a CBOR Map. Each element of the Envelope | The Envelope is encoded as a CBOR Map. Each element of the Envelope | |||
| is enclosed in a bstr, which allows computation of a message digest | is enclosed in a bstr, which allows computation of a message digest | |||
| against known bounds. | against known bounds. | |||
| 8.3. Authenticated Manifests | 8.3. Authenticated Manifests | |||
| The suit-authentication-wrapper contains a list containing a SUIT | The suit-authentication-wrapper contains a SUIT Digest Container (see | |||
| Digest Container (see Section 10) and one or more cryptographic | Section 10) and one or more SUIT Authentication Blocks. The | |||
| authentication wrappers for the Manifest. These blocks are | SUIT_Digest carries the result of computing the indicated hash | |||
| implemented as COSE_Mac_Tagged or COSE_Sign_Tagged structures with | algorithm over the suit-manifest element. A signing application MUST | |||
| null payloads, indicating that the payload to be used is the SUIT | verify the suit-manifest element against the SUIT_Digest prior to | |||
| Digest Container. This enables modular processing of the manifest. | signing. A SUIT Authentication Block is implemented as | |||
| The COSE_Mac_Tagged and COSE_Sign_Tagged blocks are described in RFC | COSE_Mac_Tagged, COSE_Mac0_Tagged, COSE_Sign_Tagged or | |||
| 8152 [RFC8152]. The suit-authentication-wrapper MUST come before any | COSE_Sign1_Tagged structures with detached payloads, as described in | |||
| element in the SUIT_Envelope, regardless of canonical encoding of | RFC 8152 [RFC8152]. | |||
| CBOR. All validators MUST reject any SUIT_Envelope that begins with | ||||
| any element other than a suit-authentication-wrapper (NOTE: key | For COSE_Sign and COSE_Sign1 a special signature structure (called | |||
| delegation MAY relax this requirement to include a delegation | Sig_structure) has to be created onto which the selected digital | |||
| structure as well). | signature algorithm is applied to, see Section 4.4 of [RFC8152] for | |||
| details. This specification requires Sig_structure to be populated | ||||
| as follows: * The external_aad field MUST be set to a zero-length | ||||
| binary string (i.e. there is no external additional authenticated | ||||
| data). * The payload field contains the SUIT_Digest wrapped in a | ||||
| bstr, as per the requirements in Section 4.4 of RFC 8152. All other | ||||
| fields in the Sig_structure are populated as described in Section 4.4 | ||||
| of [RFC8152]. | ||||
| Likewise, Section 6.3 of [RFC8152] describes the details for | ||||
| computing a MAC and the fields of the MAC_structure need to be | ||||
| populated. The rules for external_aad and the payload fields | ||||
| described in the paragraph above also apply to this structure. | ||||
| 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 | A SUIT_Envelope that has not had authentication information added | |||
| MUST still contain the suit-authentication-wrapper element, but the | MUST still contain the suit-authentication-wrapper element, but the | |||
| content MUST be a list containing only the SUIT_Digest. | content MUST be a list containing only the SUIT_Digest. | |||
| A signing application MUST verify the suit-manifest element against | ||||
| the SUIT_Digest prior to signing. | ||||
| 8.4. Manifest | 8.4. Manifest | |||
| The manifest contains: | The manifest contains: | |||
| * a version number (see Section 8.4.1) | * a version number (see Section 8.4.1) | |||
| * a sequence number (see Section 8.4.2) | * a sequence number (see Section 8.4.2) | |||
| * a reference URI (see Section 8.4.3) | * a reference URI (see Section 8.4.3) | |||
| * a common structure with information that is shared between command | * a common structure with information that is shared between command | |||
| sequences (see Section 8.4.5) | sequences (see Section 8.4.5) | |||
| * one or more lists of commands that the Recipient should perform | * one or more lists of commands that the Recipient should perform | |||
| (see Section 8.4.6) | (see Section 8.4.6) | |||
| * a reference to the full manifest (see Section 8.4.3) | * a reference to the full manifest (see Section 8.4.3) | |||
| * human-readable text describing the manifest found in the | * human-readable text describing the manifest found in the | |||
| SUIT_Envelope (see Section 8.4.4) | SUIT_Envelope (see Section 8.4.4) | |||
| skipping to change at page 38, line 9 ¶ | skipping to change at page 38, line 9 ¶ | |||
| reference the object with a single pointer and traverse it without | reference the object with a single pointer and traverse it without | |||
| understanding the contents. This is important for modularization and | understanding the contents. This is important for modularization and | |||
| division of responsibility within a pull parser. The same | division of responsibility within a pull parser. The same | |||
| consideration does not apply to Directives because those elements are | consideration does not apply to Directives because those elements are | |||
| invoked with their arguments immediately. | invoked with their arguments immediately. | |||
| 8.4.8.1. CBOR PEN UUID Namespace Identifier | 8.4.8.1. CBOR PEN UUID Namespace Identifier | |||
| The CBOR PEN UUID Namespace Identifier is constructed as follows: | The CBOR PEN UUID Namespace Identifier is constructed as follows: | |||
| It uses the OID Namespace as a starting point, then uses the CBOR OID | It uses the OID Namespace as a starting point, then uses the CBOR | |||
| encoding for the IANA PEN OID (1.3.6.1.4.1): | absolute OID encoding for the IANA PEN OID (1.3.6.1.4.1): | |||
| D8 6F # tag(111) | D8 6F # tag(111) | |||
| 45 # bytes(5) | 45 # bytes(5) | |||
| # Absolute OID encoding of IANA Private Enterprise Number: | # Absolute OID encoding of IANA Private Enterprise Number: | |||
| # 1.3. 6. 1. 4. 1 | # 1.3. 6. 1. 4. 1 | |||
| 2B 06 01 04 01 # X.690 Clause 8.19 | 2B 06 01 04 01 # X.690 Clause 8.19 | |||
| Computing a type 5 UUID from these produces: | Computing a type 5 UUID from these produces: | |||
| NAMESPACE_CBOR_PEN = UUID5(NAMESPACE_OID, h'D86F452B06010401') | NAMESPACE_CBOR_PEN = UUID5(NAMESPACE_OID, h'D86F452B06010401') | |||
| skipping to change at page 55, line 43 ¶ | skipping to change at page 55, line 43 ¶ | |||
| +-------+----------------------------+---------------+ | +-------+----------------------------+---------------+ | |||
| Table 11 | Table 11 | |||
| 12. Security Considerations | 12. Security Considerations | |||
| This document is about a manifest format protecting and describing | This document is about a manifest format protecting and describing | |||
| how to retrieve, install, and invoke firmware images and as such it | how to retrieve, install, and invoke firmware images and as such it | |||
| is part of a larger solution for delivering firmware updates to IoT | is part of a larger solution for delivering firmware updates to IoT | |||
| devices. A detailed security treatment can be found in the | devices. A detailed security treatment can be found in the | |||
| architecture [RFC9019] and in the information model | architecture [RFC9019] and in the information model [RFC9124] | |||
| [I-D.ietf-suit-information-model] documents. | documents. | |||
| 13. Acknowledgements | 13. Acknowledgements | |||
| We would like to thank the following persons for their support in | We would like to thank the following persons for their support in | |||
| designing this mechanism: | designing this mechanism: | |||
| * Milosch Meriac | * Milosch Meriac | |||
| * Geraint Luff | * Geraint Luff | |||
| * Dan Ros | * Dan Ros | |||
| skipping to change at page 56, line 32 ¶ | skipping to change at page 56, line 32 ¶ | |||
| * Michael Richardson | * Michael Richardson | |||
| * David Brown | * David Brown | |||
| * Emmanuel Baccelli | * Emmanuel Baccelli | |||
| 14. References | 14. References | |||
| 14.1. Normative References | 14.1. Normative References | |||
| [I-D.ietf-suit-information-model] | ||||
| Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest | ||||
| Information Model for Firmware Updates in IoT Devices", | ||||
| Work in Progress, Internet-Draft, draft-ietf-suit- | ||||
| information-model-13, 8 July 2021, | ||||
| <https://www.ietf.org/archive/id/draft-ietf-suit- | ||||
| information-model-13.txt>. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
| Resource Identifier (URI): Generic Syntax", STD 66, | Resource Identifier (URI): Generic Syntax", STD 66, | |||
| RFC 3986, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
| <https://www.rfc-editor.org/info/rfc3986>. | <https://www.rfc-editor.org/info/rfc3986>. | |||
| skipping to change at page 57, line 23 ¶ | skipping to change at page 57, line 14 ¶ | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A | [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A | |||
| Firmware Update Architecture for Internet of Things", | Firmware Update Architecture for Internet of Things", | |||
| RFC 9019, DOI 10.17487/RFC9019, April 2021, | RFC 9019, DOI 10.17487/RFC9019, April 2021, | |||
| <https://www.rfc-editor.org/info/rfc9019>. | <https://www.rfc-editor.org/info/rfc9019>. | |||
| [RFC9124] Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest | ||||
| Information Model for Firmware Updates in Internet of | ||||
| Things (IoT) Devices", RFC 9124, DOI 10.17487/RFC9124, | ||||
| January 2022, <https://www.rfc-editor.org/info/rfc9124>. | ||||
| 14.2. Informative References | 14.2. Informative References | |||
| [I-D.ietf-cbor-tags-oid] | [I-D.ietf-cbor-tags-oid] | |||
| Bormann, C., "Concise Binary Object Representation (CBOR) | Bormann, C., "Concise Binary Object Representation (CBOR) | |||
| Tags for Object Identifiers", Work in Progress, Internet- | Tags for Object Identifiers", Work in Progress, Internet- | |||
| Draft, draft-ietf-cbor-tags-oid-08, 21 May 2021, | Draft, draft-ietf-cbor-tags-oid-08, 21 May 2021, | |||
| <https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid- | <https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid- | |||
| 08.txt>. | 08.txt>. | |||
| [I-D.ietf-cose-hash-algs] | [I-D.ietf-cose-hash-algs] | |||
| Schaad, J., "CBOR Object Signing and Encryption (COSE): | Schaad, J., "CBOR Object Signing and Encryption (COSE): | |||
| Hash Algorithms", Work in Progress, Internet-Draft, draft- | Hash Algorithms", Work in Progress, Internet-Draft, draft- | |||
| ietf-cose-hash-algs-09, 14 September 2020, | ietf-cose-hash-algs-09, 14 September 2020, | |||
| <https://www.ietf.org/archive/id/draft-ietf-cose-hash- | <https://www.ietf.org/archive/id/draft-ietf-cose-hash- | |||
| algs-09.txt>. | algs-09.txt>. | |||
| [I-D.ietf-suit-firmware-encryption] | [I-D.ietf-suit-firmware-encryption] | |||
| Tschofenig, H., Housley, R., and B. Moran, "Firmware | Tschofenig, H., Housley, R., and B. Moran, "Firmware | |||
| Encryption with SUIT Manifests", Work in Progress, | Encryption with SUIT Manifests", Work in Progress, | |||
| Internet-Draft, draft-ietf-suit-firmware-encryption-02, 25 | Internet-Draft, draft-ietf-suit-firmware-encryption-04, 20 | |||
| October 2021, <https://www.ietf.org/archive/id/draft-ietf- | April 2022, <https://www.ietf.org/archive/id/draft-ietf- | |||
| suit-firmware-encryption-02.txt>. | suit-firmware-encryption-04.txt>. | |||
| [I-D.ietf-suit-report] | ||||
| Moran, B. and H. Birkholz, "Secure Reporting of Update | ||||
| Status", Work in Progress, Internet-Draft, draft-ietf- | ||||
| suit-report-01, 12 January 2022, | ||||
| <https://www.ietf.org/archive/id/draft-ietf-suit-report- | ||||
| 01.txt>. | ||||
| [I-D.ietf-suit-trust-domains] | ||||
| Moran, B., "SUIT Manifest Extensions for Multiple Trust | ||||
| Domains", Work in Progress, Internet-Draft, draft-ietf- | ||||
| suit-trust-domains-00, 7 March 2022, | ||||
| <https://www.ietf.org/archive/id/draft-ietf-suit-trust- | ||||
| domains-00.txt>. | ||||
| [I-D.ietf-suit-update-management] | ||||
| Moran, B., "Update Management Extensions for Software | ||||
| Updates for Internet of Things (SUIT) Manifests", Work in | ||||
| Progress, Internet-Draft, draft-ietf-suit-update- | ||||
| management-00, 7 March 2022, | ||||
| <https://www.ietf.org/archive/id/draft-ietf-suit-update- | ||||
| management-00.txt>. | ||||
| [I-D.ietf-teep-architecture] | [I-D.ietf-teep-architecture] | |||
| Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, | Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, | |||
| "Trusted Execution Environment Provisioning (TEEP) | "Trusted Execution Environment Provisioning (TEEP) | |||
| Architecture", Work in Progress, Internet-Draft, draft- | Architecture", Work in Progress, Internet-Draft, draft- | |||
| ietf-teep-architecture-15, 12 July 2021, | ietf-teep-architecture-17, 19 April 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-teep- | <https://www.ietf.org/archive/id/draft-ietf-teep- | |||
| architecture-15.txt>. | architecture-17.txt>. | |||
| [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | |||
| Constrained-Node Networks", RFC 7228, | Constrained-Node Networks", RFC 7228, | |||
| DOI 10.17487/RFC7228, May 2014, | DOI 10.17487/RFC7228, May 2014, | |||
| <https://www.rfc-editor.org/info/rfc7228>. | <https://www.rfc-editor.org/info/rfc7228>. | |||
| [YAML] "YAML Ain't Markup Language", 2020, <https://yaml.org/>. | [YAML] "YAML Ain't Markup Language", 2020, <https://yaml.org/>. | |||
| Appendix A. A. Full CDDL | Appendix A. A. Full CDDL | |||
| In order to create a valid SUIT Manifest document the structure of | In order to create a valid SUIT Manifest document the structure of | |||
| the corresponding CBOR message MUST adhere to the following CDDL data | the corresponding CBOR message MUST adhere to the following CDDL data | |||
| definition. | definition. | |||
| To be valid, the following CDDL MUST have the COSE CDDL appended to | 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. The COSE CDDL can be obtained by following the directions in | |||
| [RFC8152], section 1.4. | [RFC8152], Section 1.3. | |||
| SUIT_Envelope_Tagged = #6.107(SUIT_Envelope) | SUIT_Envelope_Tagged = #6.107(SUIT_Envelope) | |||
| SUIT_Envelope = { | SUIT_Envelope = { | |||
| ? suit-delegation => bstr .cbor SUIT_Delegation, | ||||
| suit-authentication-wrapper => bstr .cbor SUIT_Authentication, | suit-authentication-wrapper => bstr .cbor SUIT_Authentication, | |||
| suit-manifest => bstr .cbor SUIT_Manifest, | suit-manifest => bstr .cbor SUIT_Manifest, | |||
| SUIT_Severable_Manifest_Members, | SUIT_Severable_Manifest_Members, | |||
| * SUIT_Integrated_Payload, | * SUIT_Integrated_Payload, | |||
| * $$SUIT_Envelope_Extensions, | * $$SUIT_Envelope_Extensions, | |||
| * (int => bstr) | * (int => bstr) | |||
| } | } | |||
| SUIT_Authentication = [ | SUIT_Authentication = [ | |||
| bstr .cbor SUIT_Digest, | bstr .cbor SUIT_Digest, | |||
| * bstr .cbor SUIT_Authentication_Block | * bstr .cbor SUIT_Authentication_Block | |||
| ] | ] | |||
| SUIT_Digest = [ | SUIT_Digest = [ | |||
| suit-digest-algorithm-id : suit-cose-hash-algs, | suit-digest-algorithm-id : suit-cose-hash-algs, | |||
| suit-digest-bytes : bstr, | suit-digest-bytes : bstr, | |||
| skipping to change at page 59, line 30 ¶ | skipping to change at page 60, line 4 ¶ | |||
| } | } | |||
| SUIT_Unseverable_Members = ( | SUIT_Unseverable_Members = ( | |||
| ? suit-validate => bstr .cbor SUIT_Command_Sequence, | ? suit-validate => bstr .cbor SUIT_Command_Sequence, | |||
| ? suit-load => bstr .cbor SUIT_Command_Sequence, | ? suit-load => bstr .cbor SUIT_Command_Sequence, | |||
| ? suit-run => bstr .cbor SUIT_Command_Sequence, | ? suit-run => bstr .cbor SUIT_Command_Sequence, | |||
| * $$unseverable-manifest-member-extensions, | * $$unseverable-manifest-member-extensions, | |||
| ) | ) | |||
| SUIT_Severable_Members_Choice = ( | SUIT_Severable_Members_Choice = ( | |||
| ? suit-payload-fetch => \ | ? suit-payload-fetch => | |||
| bstr .cbor SUIT_Command_Sequence / SUIT_Digest, | bstr .cbor SUIT_Command_Sequence / SUIT_Digest, | |||
| ? suit-install => bstr .cbor SUIT_Command_Sequence / SUIT_Digest, | ? suit-install => bstr .cbor SUIT_Command_Sequence / SUIT_Digest, | |||
| ? suit-text => bstr .cbor SUIT_Command_Sequence / SUIT_Digest, | ? suit-text => bstr .cbor SUIT_Command_Sequence / SUIT_Digest, | |||
| * $$severable-manifest-members-choice-extensions | * $$severable-manifest-members-choice-extensions | |||
| ) | ) | |||
| SUIT_Common = { | SUIT_Common = { | |||
| ? suit-components => SUIT_Components, | ? suit-components => SUIT_Components, | |||
| ? suit-common-sequence => bstr .cbor SUIT_Common_Sequence, | ? suit-common-sequence => bstr .cbor SUIT_Common_Sequence, | |||
| * $$SUIT_Common-extensions, | * $$SUIT_Common-extensions, | |||
| End of changes. 33 change blocks. | ||||
| 68 lines changed or deleted | 99 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||