idnits 2.17.1 draft-ietf-suit-information-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2019) is 1925 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1448 -- Looks like a reference, but probably isn't: '2' on line 1450 -- Looks like a reference, but probably isn't: '3' on line 1453 == Unused Reference: 'RFC4122' is defined on line 1428, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-02 ** Downref: Normative reference to an Informational draft: draft-ietf-suit-architecture (ref. 'I-D.ietf-suit-architecture') Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft H. Tschofenig 4 Intended status: Standards Track Arm Limited 5 Expires: July 22, 2019 H. Birkholz 6 Fraunhofer SIT 7 January 18, 2019 9 Firmware Updates for Internet of Things Devices - An Information Model 10 for Manifests 11 draft-ietf-suit-information-model-02 13 Abstract 15 Vulnerabilities with Internet of Things (IoT) devices have raised the 16 need for a solid and secure firmware update mechanism that is also 17 suitable for constrained devices. Incorporating such update 18 mechanism to fix vulnerabilities, to update configuration settings as 19 well as adding new functionality is recommended by security experts. 21 One component of such a firmware update is the meta-data, or 22 manifest, that describes the firmware image(s) and offers appropriate 23 protection. This document describes all the information that must be 24 present in the manifest. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 22, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 74 3. Manifest Information Elements . . . . . . . . . . . . . . . . 5 75 3.1. Manifest Element: version identifier of the manifest 76 structure . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6 78 3.3. Manifest Element: Vendor ID Condition . . . . . . . . . . 6 79 3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 6 80 3.4. Manifest Element: Class ID Condition . . . . . . . . . . 6 81 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 7 82 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 7 83 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 8 84 3.5. Manifest Element: Precursor Image Digest Condition . . . 8 85 3.6. Manifest Element: Required Image Version List . . . . . . 8 86 3.7. Manifest Element: Best-Before timestamp condition . . . . 9 87 3.8. Manifest Element: Payload Format . . . . . . . . . . . . 9 88 3.9. Manifest Element: Processing Steps . . . . . . . . . . . 9 89 3.10. Manifest Element: Storage Location . . . . . . . . . . . 9 90 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 10 91 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 10 92 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 10 93 3.11. Manifest Element: Component Identifier . . . . . . . . . 10 94 3.12. Manifest Element: URIs . . . . . . . . . . . . . . . . . 10 95 3.13. Manifest Element: Payload Digest . . . . . . . . . . . . 11 96 3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 11 97 3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 11 98 3.16. Manifest Element: Directives . . . . . . . . . . . . . . 11 99 3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 12 100 3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 12 101 3.19. Manifest Element: Content Key Distribution Method . . . . 12 102 3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 12 103 3.21. Manifest Element: Load-time metadata . . . . . . . . . . 13 104 4. Motivation for Manifest Fields . . . . . . . . . . . . . . . 13 105 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 13 106 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 13 107 4.2.1. Threat MFT1: Old Firmware . . . . . . . . . . . . . . 13 108 4.2.2. Threat MFT2: Mismatched Firmware . . . . . . . . . . 14 109 4.2.3. Threat MFT3: Offline device + Old Firmware . . . . . 14 110 4.2.4. Threat MFT4: The target device misinterprets the type 111 of payload . . . . . . . . . . . . . . . . . . . . . 15 112 4.2.5. Threat MFT5: The target device installs the payload 113 to the wrong location . . . . . . . . . . . . . . . . 15 114 4.2.6. Threat MFT6: Redirection . . . . . . . . . . . . . . 15 115 4.2.7. Threat MFT7: Payload Verification on Boot . . . . . . 16 116 4.2.8. Threat MFT8: Unauthenticated Updates . . . . . . . . 16 117 4.2.9. Threat MFT9: Unexpected Precursor images . . . . . . 16 118 4.2.10. Threat MFT10: Unqualified Firmware . . . . . . . . . 17 119 4.2.11. Threat MFT11: Reverse Engineering Of Firmware Image 120 for Vulnerability Analysis . . . . . . . . . . . . . 18 121 4.2.12. Threat MFT12: Overriding Critical Manifest Elements . 18 122 4.2.13. Threat MFT13: Manifest Element Exposure . . . . . . . 18 123 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 19 124 4.3.1. Security Requirement MFSR1: Monotonic Sequence 125 Numbers . . . . . . . . . . . . . . . . . . . . . . . 19 126 4.3.2. Security Requirement MFSR2: Vendor, Device-type 127 Identifiers . . . . . . . . . . . . . . . . . . . . . 19 128 4.3.3. Security Requirement MFSR3: Best-Before Timestamps . 19 129 4.3.4. Security Requirement MFSR5: Cryptographic 130 Authenticity . . . . . . . . . . . . . . . . . . . . 20 131 4.3.5. Security Requirement MFSR4a: Authenticated Payload 132 Type . . . . . . . . . . . . . . . . . . . . . . . . 20 133 4.3.6. Security Requirement MFSR4b: Authenticated Storage 134 Location . . . . . . . . . . . . . . . . . . . . . . 20 135 4.3.7. Security Requirement MFSR4c: Authenticated Remote 136 Resource Location . . . . . . . . . . . . . . . . . . 20 137 4.3.8. Security Requirement MFSR4d: Secure Boot . . . . . . 21 138 4.3.9. Security Requirement MFSR4e: Authenticated precursor 139 images . . . . . . . . . . . . . . . . . . . . . . . 21 140 4.3.10. Security Requirement MFSR4f: Authenticated Vendor and 141 Class IDs . . . . . . . . . . . . . . . . . . . . . . 21 142 4.3.11. Security Requirement MFSR4f: Authenticated Vendor and 143 Class IDs . . . . . . . . . . . . . . . . . . . . . . 21 145 4.3.12. Security Requirement MFSR6: Rights Require 146 Authenticity . . . . . . . . . . . . . . . . . . . . 21 147 4.3.13. Security Requirement MFSR7: Firmware encryption . . . 22 148 4.3.14. Security Requirement MFSR8: Access Control Lists . . 22 149 4.3.15. Security Requirement MFSR9: Encrypted Manifests . . . 22 150 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 23 151 4.4.1. Use Case MFUS1: Installation Instructions . . . . . . 23 152 4.4.2. Use Case MFUS2: Override Non-Critical Manifest 153 Elements . . . . . . . . . . . . . . . . . . . . . . 23 154 4.4.3. Use Case MFUS3: Modular Update . . . . . . . . . . . 24 155 4.4.4. Use Case MFUS4: Multiple Authorisations . . . . . . . 24 156 4.4.5. Use Case MFUS5: Multiple Payload Formats . . . . . . 24 157 4.4.6. Use Case MFUS6: Prevent Confidential Information 158 Disclosures . . . . . . . . . . . . . . . . . . . . . 24 159 4.4.7. Use Case MFUS7: Prevent Devices from Unpacking 160 Unknown Formats . . . . . . . . . . . . . . . . . . . 24 161 4.4.8. Use Case MFUS8: Specify Version Numbers of Target 162 Firmware . . . . . . . . . . . . . . . . . . . . . . 25 163 4.4.9. Use Case MFUS9: Enable Devices to Choose Between 164 Images . . . . . . . . . . . . . . . . . . . . . . . 25 165 4.4.10. Use Case MFUS10: Secure Boot Using Manifests . . . . 25 166 4.4.11. Use Case MFUS11: Decompress on Load . . . . . . . . . 25 167 4.4.12. Use Case MFUS12: Payload in Manifest . . . . . . . . 26 168 4.4.13. Use Case MFUS13: Simple Parsing . . . . . . . . . . . 26 169 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 26 170 4.5.1. Usability Requirement MFUR1 . . . . . . . . . . . . . 26 171 4.5.2. Usability Requirement MFUR2 . . . . . . . . . . . . . 26 172 4.5.3. Usability Requirement MFUR3 . . . . . . . . . . . . . 27 173 4.5.4. Usability Requirement MFUR4 . . . . . . . . . . . . . 28 174 4.5.5. Usability Requirement MFUR5 . . . . . . . . . . . . . 28 175 4.5.6. Usability Requirement MFUR6 . . . . . . . . . . . . . 28 176 4.5.7. Usability Requirement MFUR7 . . . . . . . . . . . . . 28 177 4.5.8. Usability Requirement MFUR8 . . . . . . . . . . . . . 29 178 4.5.9. Usability Requirement MFUR9: Bootable Manifest . . . 29 179 4.5.10. Usability Requirement MFUR10: Load-Time Information . 29 180 4.5.11. Usability Requirement MFUR11: Payload in Manifest 181 Superstructure . . . . . . . . . . . . . . . . . . . 29 182 4.5.12. Usability Requirement MFUR12: Simple Parsing . . . . 30 183 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 184 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 185 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 186 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 187 8.1. Normative References . . . . . . . . . . . . . . . . . . 30 188 8.2. Informative References . . . . . . . . . . . . . . . . . 31 189 Appendix A. Mailing List Information . . . . . . . . . . . . . . 32 190 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 192 1. Introduction 194 The information model describes all the information elements required 195 to secure firmware updates of IoT devices from the threats described 196 in Section 4.1 and enable the user stories captured in Section 4.4. 197 These threats and user stories are not intended to be an exhaustive 198 list of the threats against IoT devices, nor of the possible use 199 cases of firmware update; instead they are intended to describe the 200 threats against firmware update in isolation and provide sufficient 201 motivation to provide information elements that cover a wide range of 202 use cases. The information model does not define the encoding, 203 ordering, or structure of information elements, only their semantics. 205 Because the information model covers a wide range of user stories and 206 a wide range of threats, not all information elements apply to all 207 scenarios. As a result, many information elements could be 208 considered optional to implement and optional to use, depending on 209 which threats exist in a particular system and which use cases are 210 required. Elements marked as mandatory provide baseline security and 211 usability properties that are expected to be required for most 212 applications. Those elements are mandatory to implement and 213 mandatory to use. Elements marked as recommended provide important 214 security or usability properties that are needed on most devices. 215 Elements marked as optional enable security or usability properties 216 that are useful in some applications. 218 2. Conventions and Terminology 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 222 "OPTIONAL" in this document are to be interpreted as described in RFC 223 2119 [RFC2119]. 225 This document uses terms defined in [I-D.ietf-suit-architecture]. 226 The term 'Operator' refers to both, Device and Network Operator. 228 3. Manifest Information Elements 230 Each manifest element is anchored in a security requirement or a 231 usability requirement. The manifest elements are described below and 232 justified by their requirements. 234 3.1. Manifest Element: version identifier of the manifest structure 236 An identifier that describes which iteration of the manifest format 237 is contained in the structure. 239 This element is MANDATORY and must be present in order to allow 240 devices to identify the version of the manifest data model that is in 241 use. 243 3.2. Manifest Element: Monotonic Sequence Number 245 A monotonically increasing sequence number. For convenience, the 246 monotonic sequence number MAY be a UTC timestamp. This allows global 247 synchronisation of sequence numbers without any additional 248 management. 250 This element is MANDATORY and is necessary to prevent malicious 251 actors from reverting a firmware update against the wishes of the 252 relevant authority. 254 Implements: Security Requirement MFSR1. 256 3.3. Manifest Element: Vendor ID Condition 258 Vendor IDs MUST be unique. This is to prevent similarly, or 259 identically named entities from different geographic regions from 260 colliding in their customer's infrastructure. Recommended practice 261 is to use type 5 UUIDs with the vendor's domain name and the UUID DNS 262 prefix. Other options include type 1 and type 4 UUIDs. 264 This ID is RECOMMENDED and helps to distinguish between identically 265 named products from different vendors. 267 Implements: Security Requirement MFSR2, MFSR4f. 269 3.3.1. Example: Domain Name-based UUIDs 271 Vendor A creates a UUID based on their domain name: 273 vendorId = UUID5(DNS, "vendor-a.com") 275 Because the DNS infrastructure prevents multiple registrations of the 276 same domain name, this UUID is guaranteed to be unique. Because the 277 domain name is known, this UUID is reproducible. Type 1 and type 4 278 UUIDs produce similar guarantees of uniqueness, but not 279 reproducibility. 281 3.4. Manifest Element: Class ID Condition 283 A device "Class" is defined as any device that can accept the same 284 firmware update without modification. Class Identifiers MUST be 285 unique within a Vendor ID. This is to prevent similarly, or 286 identically named devices colliding in their customer's 287 infrastructure. Recommended practice is to use type 5 UUIDs with the 288 model, hardware revision, etc. and use the Vendor ID as the UUID 289 prefix. Other options include type 1 and type 4 UUIDs. Classes MAY 290 be implemented in a more granular way. Classes MUST NOT be 291 implemented in a less granular way. Class ID can encompass model 292 name, hardware revision, software revision. Devices MAY have 293 multiple Class IDs. 295 Note Well: Class ID is not a human-readable element. It is intended 296 for match/mismatch use only. 298 This ID is RECOMMENDED and allows devices to determine applicability 299 of a firmware in an unambiguous way. 301 Implements: Security Requirement MFSR2, MFSR4f. 303 3.4.1. Example 1: Different Classes 305 Vendor A creates product Z and product Y. The firmware images of 306 products Z and Y are not interchangeable. Vendor A creates UUIDs as 307 follows: 309 - vendorId = UUID5(DNS, "vendor-a.com") 311 - ZclassId = UUID5(vendorId, "Product Z") 313 - YclassId = UUID5(vendorId, "Product Y") 315 This ensures that Vendor A's Product Z cannot install firmware for 316 Product Y and Product Y cannot install firmware for Product Z. 318 3.4.2. Example 2: Upgrading Class ID 320 Vendor A creates product X. Later, Vendor A adds a new feature to 321 product X, creating product X v2. Product X requires a firmware 322 update to work with firmware intended for product X v2. 324 Vendor A creates UUIDs as follows: 326 - vendorId = UUID5(DNS, "vendor-a.com") 328 - XclassId = UUID5(vendorId, "Product X") 330 - Xv2classId = UUID5(vendorId, "Product X v2") 332 When product X receives the firmware update necessary to be 333 compatible with product X v2, part of the firmware update changes the 334 class ID to Xv2classId. 336 3.4.3. Example 3: Shared Functionality 338 Vendor A produces two products, product X and product Y. These 339 components share a common core (such as an operating system), but 340 have different applications. The common core and the applications 341 can be updated independently. To enable X and Y to receive the same 342 common core update, they require the same class ID. To ensure that 343 only product X receives application X and only product Y receives 344 application Y, product X and product Y must have different class IDs. 345 The vendor creates Class IDs as follows: 347 - vendorId = UUID5(DNS, "vendor-a.com") 349 - XclassId = UUID5(vendorId, "Product X") 351 - YclassId = UUID5(vendorId, "Product Y") 353 - CommonClassId = UUID5(vendorId, "common core") 355 Product X matches against both XclassId and CommonClassId. Product Y 356 matches against both YclassId and CommonClassId. 358 3.5. Manifest Element: Precursor Image Digest Condition 360 When a precursor image is required by the payload format, a precursor 361 image digest condition MUST be present in the conditions list. The 362 precursor image may be installed or stored as a candidate. 364 This element is MANDATORY for differential updates. Otherwise, it is 365 not needed. 367 Implements: Security Requirement MFSR4e 369 3.6. Manifest Element: Required Image Version List 371 When a payload applies to multiple versions of a firmware, the 372 required image version list specifies which versions must be present 373 for the update to be applied. This allows the update author to 374 target specific versions of firmware for an update, while excluding 375 those to which it should not be applied. 377 Where an update can only be applied over specific predecessor 378 versions, that version MUST be specified by the Required Image 379 Version List. 381 This element is OPTIONAL. 383 Implements: MFUR7 385 3.7. Manifest Element: Best-Before timestamp condition 387 This element tells a device the last application time. This is only 388 usable in conjunction with a secure clock. 390 This element is OPTIONAL and MAY enable use cases where a secure 391 clock is provided and firmware is intended to expire regularly. 393 Implements: Security Requirement MFSR3 395 3.8. Manifest Element: Payload Format 397 The format of the payload must be indicated to devices is in an 398 unambiguous way. This element provides a mechanism to describe the 399 payload format, within the signed metadata. 401 This element is MANDATORY and MUST be present to enable devices to 402 decode payloads correctly. 404 Implements: Security Requirement MFSR4a, Usability Requirement MFUR5 406 3.9. Manifest Element: Processing Steps 408 A list of all payload processors necessary to process a nested format 409 and any parameters needed by those payload processors. Each 410 Processing Step SHOULD indicate the expected digest of the payload 411 after the processing is complete. Processing steps are distinct from 412 Directives in that Directives apply to the manifest as a whole, 413 whereas Processing Steps apply to an individual payload and provide 414 instructions on how to unpack it. 416 Implements: Usability Requirement MFUR6 418 3.10. Manifest Element: Storage Location 420 This element tells the device which component is being updated. The 421 device can use this to establish which permissions are necessary and 422 the physical location to use. 424 This element is MANDATORY and MUST be present to enable devices to 425 store payloads to the correct location. 427 Implements: Security Requirement MFSR4b 429 3.10.1. Example 1: Two Storage Locations 431 A device supports two components: an OS and an application. These 432 components can be updated independently, expressing dependencies to 433 ensure compatibility between the components. The firmware authority 434 chooses two storage identifiers: 436 - OS 438 - APP 440 3.10.2. Example 2: File System 442 A device supports a full filesystem. The firmware authority chooses 443 to make the storage identifier the path at which to install the 444 payload. The payload may be a tarball, in which case, it unpacks the 445 tarball into the specified path. 447 3.10.3. Example 3: Flash Memory 449 A device supports flash memory. The firmware authority chooses to 450 make the storage identifier the offset where the image should be 451 written. 453 3.11. Manifest Element: Component Identifier 455 In a heterogeneous storage architecture, a storage identifier is 456 insufficient to identify where and how to store a payload. To 457 resolve this, a component identifier indicates which part of the 458 storage architecture is targeted by the payload. In a homogeneous 459 storage architecture, this element is unnecessary. 461 This element is OPTIONAL and only necessary in heterogeneous storage 462 architecture devices. 464 Implements: MFUR3 466 3.12. Manifest Element: URIs 468 This element is a list of weighted URIs that the device uses to 469 select where to obtain a payload. 471 This element is OPTIONAL and only needed when the target device does 472 not intrinsically know where to find the payload. 474 Note: Devices will typically require URIs. 476 Implements: Security Requirement MFSR4c 478 3.13. Manifest Element: Payload Digest 480 This element contains the digest of the payload. This allows the 481 target device to ensure authenticity of the payload. It MUST be 482 possible to specify more than one payload digest, indexed by Manifest 483 Element: XIP Address. 485 This element is MANDATORY and fundamentally necessary to ensure the 486 authenticity and integrity of the payload. 488 Implements: Security Requirement MFSR4d, Usability Requirement MFUR8 490 3.14. Manifest Element: Size 492 The size of the payload in bytes. 494 This element is MANDATORY and informs the target device how big of a 495 payload to expect. Without it, devices are exposed to some classes 496 of denial of service attack. 498 Implements: Security Requirement MFSR4d 500 3.15. Manifest Element: Signature 502 This is not strictly a manifest element. Instead, the manifest is 503 wrapped by a standardised authentication container, such as a COSE or 504 CMS signature object. The authentication container MUST support 505 multiple actors and multiple authentications. 507 This element is MANDATORY and represents the foundation of all 508 security properties of the manifest. 510 Implements: Security Requirement MFSR5, MFSR6, MFUR4 512 3.16. Manifest Element: Directives 514 A list of instructions that the device should execute, in order, when 515 processing the manifest. This information is distinct from the 516 information necessary to process a payload (Processing Steps) and 517 applies to the whole manifest including all payloads that it 518 references. Directives include information such as update timing 519 (For example, install only on Sunday, at 0200), procedural 520 considerations (for example, shut down the equipment under control 521 before executing the update), pre and post-installation steps (for 522 example, run a script). 524 This element is OPTIONAL and enables some use cases. 526 Implements: Usability Requirement MFUR1 528 3.17. Manifest Element: Aliases 530 A list of Digest/URI pairs. A device should build an alias table 531 while paring a manifest tree and treat any aliases as top-ranked URIs 532 for the corresponding digest. 534 This element is OPTIONAL and enables some use cases. 536 Implements: Usability Requirement MFUR2 538 3.18. Manifest Element: Dependencies 540 A list of Digest/URI pairs that refer to other manifests by digest. 541 The manifests that are linked in this way must be acquired and 542 installed simultaneously in order to form a complete update. 544 This element is MANDATORY to use in deployments that include both 545 multiple authorities and multiple payloads. 547 Implements: Usability Requirement MFUR3 549 3.19. Manifest Element: Content Key Distribution Method 551 Encrypting firmware images requires symmetric content encryption 552 keys. Since there are several methods to protect or distribute the 553 symmetric content encryption keys, the manifest contains a element 554 for the Content Key Distribution Method. One examples for such a 555 Content Key Distribution Method is the usage of Key Tables, pointing 556 to content encryption keys, which themselves are encrypted using the 557 public keys of devices. This MAY be included in a decryption step 558 contained in Processing Steps. 560 This element is MANDATORY to use for encrypted payloads, 562 Implements: Security Requirement MFSR7. 564 3.20. Manifest Element: XIP Address 566 In order to support XIP systems with multiple possible base 567 addresses, it is necessary to specify which address the payload is 568 linked for. 570 For example a microcontroller may have a simple bootloader that 571 chooses one of two images to boot. That microcontroller then needs 572 to choose one of two firmware images to install, based on which of 573 its two images is older. 575 Implements: MFUR8 577 3.21. Manifest Element: Load-time metadata 579 ## Manifest Element: Boot-time metadata ## Manifest Element: Payload 581 4. Motivation for Manifest Fields 583 The following sub-sections describe the threat model, user stories, 584 security requirements, and usability requirements. 586 4.1. Threat Model 588 The following sub-sections aim to provide information about the 589 threats that were considered, the security requirements that are 590 derived from those threats and the fields that permit implementation 591 of the security requirements. This model uses the S.T.R.I.D.E. 592 [STRIDE] approach. Each threat is classified according to: 594 - Spoofing Identity 596 - Tampering with data 598 - Repudiation 600 - Information disclosure 602 - Denial of service 604 - Elevation of privilege 606 This threat model only covers elements related to the transport of 607 firmware updates. It explicitly does not cover threats outside of 608 the transport of firmware updates. For example, threats to an IoT 609 device due to physical access are out of scope. 611 4.2. Threat Descriptions 613 4.2.1. Threat MFT1: Old Firmware 615 Classification: Elevation of Privilege 617 An attacker sends an old, but valid manifest with an old, but valid 618 firmware image to a device. If there is a known vulnerability in the 619 provided firmware image, this may allow an attacker to exploit the 620 vulnerability and gain control of the device. 622 Threat Escalation: If the attacker is able to exploit the known 623 vulnerability, then this threat can be escalated to ALL TYPES. 625 Mitigated by: MFSR1 627 4.2.2. Threat MFT2: Mismatched Firmware 629 Classification: Denial of Service 631 An attacker sends a valid firmware image, for the wrong type of 632 device, signed by an actor with firmware installation permission on 633 both types of device. The firmware is verified by the device 634 positively because it is signed by an actor with the appropriate 635 permission. This could have wide-ranging consequences. For devices 636 that are similar, it could cause minor breakage, or expose security 637 vulnerabilities. For devices that are very different, it is likely 638 to render devices inoperable. 640 Mitigated by: MFSR2 642 Example: 644 Suppose that two vendors, Vendor A and Vendor B, adopt the same trade 645 name in different geographic regions, and they both make products 646 with the same names, or product name matching is not used. This 647 causes firmware from Vendor A to match devices from Vendor B. 649 If the vendors are the firmware authorities, then devices from Vendor 650 A will reject images signed by Vendor B since they use different 651 credentials. However, if both devices trust the same firmware 652 authority, then, devices from Vendor A could install firmware 653 intended for devices from Vendor B. 655 4.2.3. Threat MFT3: Offline device + Old Firmware 657 Classification: Elevation of Privilege 659 An attacker targets a device that has been offline for a long time 660 and runs an old firmware version. The attacker sends an old, but 661 valid manifest to a device with an old, but valid firmware image. 662 The attacker-provided firmware is newer than the installed one but 663 older than the most recently available firmware. If there is a known 664 vulnerability in the provided firmware image then this may allow an 665 attacker to gain control of a device. Because the device has been 666 offline for a long time, it is unaware of any new updates. As such 667 it will treat the old manifest as the most current. 669 Threat Escalation: If the attacker is able to exploit the known 670 vulnerability, then this threat can be escalated to ALL TYPES. 672 Mitigated by: MFSR3 674 4.2.4. Threat MFT4: The target device misinterprets the type of payload 676 Classification: Denial of Service 678 If a device misinterprets the type of the firmware image, it may 679 cause a device to install a firmware image incorrectly. An 680 incorrectly installed firmware image would likely cause the device to 681 stop functioning. 683 Threat Escalation: An attacker that can cause a device to 684 misinterpret the received firmware image may gain elevation of 685 privilege and potentially expand this to all types of threat. 687 Mitigated by: MFSR4a 689 4.2.5. Threat MFT5: The target device installs the payload to the wrong 690 location 692 Classification: Denial of Service 694 If a device installs a firmware image to the wrong location on the 695 device, then it is likely to break. For example, a firmware image 696 installed as an application could cause a device and/or an 697 application to stop functioning. 699 Threat Escalation: An attacker that can cause a device to 700 misinterpret the received code may gain elevation of privilege and 701 potentially expand this to all types of threat. 703 Mitigated by: MFSR4b 705 4.2.6. Threat MFT6: Redirection 707 Classification: Denial of Service 709 If a device does not know where to obtain the payload for an update, 710 it may be redirected to an attacker's server. This would allow an 711 attacker to provide broken payloads to devices. 713 Mitigated by: MFSR4c 715 4.2.7. Threat MFT7: Payload Verification on Boot 717 Classification: Elevation of Privilege 719 An attacker replaces a newly downloaded firmware after a device 720 finishes verifying a manifest. This could cause the device to 721 execute the attacker's code. This attack likely requires physical 722 access to the device. However, it is possible that this attack is 723 carried out in combination with another threat that allows remote 724 execution. 726 Threat Escalation: If the attacker is able to exploit a known 727 vulnerability, or if the attacker can supply their own firmware, then 728 this threat can be escalated to ALL TYPES. 730 Mitigated by: MFSR4d 732 4.2.8. Threat MFT8: Unauthenticated Updates 734 Classification: Elevation of Privilege 736 If an attacker can install their firmware on a device, by 737 manipulating either payload or metadata, then they have complete 738 control of the device. 740 Threat Escalation: If the attacker is able to exploit a known 741 vulnerability, or if the attacker can supply their own firmware, then 742 this threat can be escalated to ALL TYPES. 744 Mitigated by: MFSR5 746 4.2.9. Threat MFT9: Unexpected Precursor images 748 Classification: Denial of Service 750 An attacker sends a valid, current manifest to a device that has an 751 unexpected precursor image. If a payload format requires a precursor 752 image (for example, delta updates) and that precursor image is not 753 available on the target device, it could cause the update to break. 755 Threat Escalation: An attacker that can cause a device to install a 756 payload against the wrong precursor image could gain elevation of 757 privilege and potentially expand this to all types of threat. 759 Mitigated by: MFSR4e 761 4.2.10. Threat MFT10: Unqualified Firmware 763 Classification: Denial of Service, Elevation of Privilege 765 This threat can appear in several ways, however it is ultimately 766 about interoperability of devices with other systems. The owner or 767 operator of a network needs to approve firmware for their network in 768 order to ensure interoperability with other devices on the network, 769 or the network itself. If the firmware is not qualified, it may not 770 work. Therefore, if a device installs firmware without the approval 771 of the network owner or operator, this is a threat to devices and the 772 network. 774 Threat Escalation: If the firmware expects configuration that is 775 present in devices deployed in Network A, but not in devices deployed 776 in Network B, then the device may experience degraded security, 777 leading to threats of All Types. 779 Mitigated by: MFSR6, MFSR8 781 4.2.10.1. Example 1: Multiple Network Operators with a Single Device 782 Operator 784 In this example let us assume that Device Operators expect the rights 785 to create firmware but that Network Operators expect the rights to 786 qualify firmware as fit-for-purpose on their networks. Additionally 787 assume that an Device Operators manage devices that can be deployed 788 on any network, including Network A and B in our example. 790 An attacker may obtain a manifest for a device on Network A. Then, 791 this attacker sends that manifest to a device on Network B. Because 792 Network A and Network B are under control of different Operators, and 793 the firmware for a device on Network A has not been qualified to be 794 deployed on Network B, the target device on Network B is now in 795 violation of the Operator B's policy and may get disabled by this 796 unqualified, but signed firmware. 798 This is a denial of service because it can render devices inoperable. 799 This is an elevation of privilege because it allows the attacker to 800 make installation decisions that should be made by the Operator. 802 4.2.10.2. Example 2: Single Network Operator with Multiple Device 803 Operators 805 Multiple devices that interoperate are used on the same network and 806 communicate with each other. Some devices are manufactured and 807 managed by Device Operator A and other devices by Device Operator B. 808 A new firmware is released by Device Operator A that breaks 809 compatibility with devices from Device Operator B. An attacker sends 810 the new firmware to the devices managed by Device Operator A without 811 approval of the Network Operator. This breaks the behaviour of the 812 larger system causing denial of service and possibly other threats. 813 Where the network is a distributed SCADA system, this could cause 814 misbehaviour of the process that is under control. 816 4.2.11. Threat MFT11: Reverse Engineering Of Firmware Image for 817 Vulnerability Analysis 819 Classification: All Types 821 An attacker wants to mount an attack on an IoT device. To prepare 822 the attack he or she retrieves the provided firmware image and 823 performs reverse engineering of the firmware image to analyze it for 824 specific vulnerabilities. 826 Mitigated by: MFSR7 828 4.2.12. Threat MFT12: Overriding Critical Manifest Elements 830 Classification: Elevation of Privilege 832 An authorised actor, but not the firmware authority, uses an override 833 mechanism (MFUS2) to change an information element in a manifest 834 signed by the firmware authority. For example, if the authorised 835 actor overrides the digest and URI of the payload, the actor can 836 replace the entire payload with a payload of their choice. 838 Threat Escalation: By overriding elements such as payload 839 installation instructions or firmware digest, this threat can be 840 escalated to all types. 842 Mitigated by: MFSR8 844 4.2.13. Threat MFT13: Manifest Element Exposure 846 Classification: Information Disclosure 848 A third party may be able to extract sensitive information from the 849 manifest. 851 Mitigated by: MFSR9 853 4.3. Security Requirements 855 The security requirements here are a set of policies that mitigate 856 the threats described in Section 4.1. 858 4.3.1. Security Requirement MFSR1: Monotonic Sequence Numbers 860 Only an actor with firmware installation authority is permitted to 861 decide when device firmware can be installed. To enforce this rule, 862 manifests MUST contain monotonically increasing sequence numbers. 863 Manifests MAY use UTC epoch timestamps to coordinate monotonically 864 increasing sequence numbers across many actors in many locations. If 865 UTC epoch timestamps are used, they MUST NOT be treated as times, 866 they MUST be treated only as sequence numbers. Devices MUST reject 867 manifests with sequence numbers smaller than any onboard sequence 868 number. 870 Note: This is not a firmware version. It is a manifest sequence 871 number. A firmware version may be rolled back by creating a new 872 manifest for the old firmware version with a later sequence number. 874 Mitigates: Threat MFT1 876 Implemented by: Manifest Element: Monotonic Sequence Number 878 4.3.2. Security Requirement MFSR2: Vendor, Device-type Identifiers 880 Devices MUST only apply firmware that is intended for them. Devices 881 MUST know with fine granularity that a given update applies to their 882 vendor, model, hardware revision, software revision. Human-readable 883 identifiers are often error-prone in this regard, so unique 884 identifiers SHOULD be used. 886 Mitigates: Threat MFT2 888 Implemented by: Manifest Elements: Vendor ID Condition, Class ID 889 Condition 891 4.3.3. Security Requirement MFSR3: Best-Before Timestamps 893 Firmware MAY expire after a given time. Devices MAY provide a secure 894 clock (local or remote). If a secure clock is provided and the 895 Firmware manifest has a best-before timestamp, the device MUST reject 896 the manifest if current time is larger than the best-before time. 898 Mitigates: Threat MFT3 900 Implemented by: Manifest Element: Best-Before timestamp condition 902 4.3.4. Security Requirement MFSR5: Cryptographic Authenticity 904 The authenticity of an update must be demonstrable. Typically, this 905 means that updates must be digitally authenticated. Because the 906 manifest contains information about how to install the update, the 907 manifest's authenticity must also be demonstrable. To reduce the 908 overhead required for validation, the manifest contains the digest of 909 the firmware image, rather than a second digital signature. The 910 authenticity of the manifest can be verified with a digital signature 911 or Message Authentication Code, the authenticity of the firmware 912 image is tied to the manifest by the use of a digest of the firmware 913 image. 915 Mitigates: Threat MFT8 917 Implemented by: Signature, Payload Digest 919 4.3.5. Security Requirement MFSR4a: Authenticated Payload Type 921 The type of payload (which may be independent of format) MUST be 922 authenticated. For example, the target must know whether the payload 923 is XIP firmware, a loadable module, or serialized configuration data. 925 Mitigates: MFT4 927 Implemented by: Manifest Elements: Payload Format, Storage Location 929 4.3.6. Security Requirement MFSR4b: Authenticated Storage Location 931 The location on the target where the payload is to be stored MUST be 932 authenticated. 934 Mitigates: MFT5 936 Implemented by: Manifest Elements: Storage Location 938 4.3.7. Security Requirement MFSR4c: Authenticated Remote Resource 939 Location 941 The location where a target should find a payload MUST be 942 authenticated. 944 Mitigates: MFT6 946 Implemented by: Manifest Elements: URIs 948 4.3.8. Security Requirement MFSR4d: Secure Boot 950 The target SHOULD verify firmware at time of boot. This requires 951 authenticated payload size, and digest. 953 Mitigates: MFT7 955 Implemented by: Manifest Elements: Payload Digest, Size 957 4.3.9. Security Requirement MFSR4e: Authenticated precursor images 959 If an update uses a differential compression method, it MUST specify 960 the digest of the precursor image and that digest MUST be 961 authenticated. 963 Mitigates: MFT9 965 Implemented by: Manifest Elements: Precursor Image Digest Condition 967 4.3.10. Security Requirement MFSR4f: Authenticated Vendor and Class IDs 969 The identifiers that specify firmware compatibility MUST be 970 authenticated to ensure that only compatible firmware is installed on 971 a target device. 973 Mitigates: MFT2 975 Implemented By: Manifest Elements: Vendor ID Condition, Class ID 976 Condition 978 4.3.11. Security Requirement MFSR4f: Authenticated Vendor and Class IDs 980 The identifiers that specify firmware compatibility MUST be 981 authenticated to ensure that only compatible firmware is installed on 982 a target device. 984 Mitigates: MFT2 986 Implemented By: Manifest Elements: Vendor ID Condition, Class ID 987 Condition 989 4.3.12. Security Requirement MFSR6: Rights Require Authenticity 991 If a device grants different rights to different actors, exercising 992 those rights MUST be accompanied by proof of those rights, in the 993 form of proof of authenticity. Authenticity mechanisms such as those 994 required in MFSR5 are acceptable but need to follow the end-to-end 995 security model. 997 For example, if a device has a policy that requires that firmware 998 have both an Authorship right and a Qualification right and if that 999 device grants Authorship and Qualification rights to different 1000 parties, such as a Device Operator and a Network Operator, 1001 respectively, then the firmware cannot be installed without proof of 1002 rights from both the Device and the Network Operator. 1004 Mitigates: MFT10 1006 Implemented by: Signature 1008 4.3.13. Security Requirement MFSR7: Firmware encryption 1010 The manifest information model must enable encrypted payloads. 1011 Encryption helps to prevent third parties, including attackers, from 1012 reading the content of the firmware image. This can protect against 1013 confidential information disclosures and discovery of vulnerabilities 1014 through reverse engineering. Therefore the manifest must convey the 1015 information required to allow an intended recipient to decrypt an 1016 encrypted payload. 1018 Mitigates: MFT11 1020 Implemented by: Manifest Element: Content Key Distribution Method 1022 4.3.14. Security Requirement MFSR8: Access Control Lists 1024 If a device grants different rights to different actors, then an 1025 exercise of those rights must be validated against a list of rights 1026 for the actor. This typically takes the form of an Access Control 1027 List (ACL). ACLs are applied to two scenarios: 1029 1. An ACL decides which elements of the manifest may be overridden 1030 and by which actors. 1032 2. An ACL decides which component identifier/storage identifier 1033 pairs can be written by which actors. 1035 Mitigates: MFT12, MFT10 1037 Implemented by: Client-side code, not specified in manifest. 1039 4.3.15. Security Requirement MFSR9: Encrypted Manifests 1041 It must be possible to encrypt part or all of the manifest. This may 1042 be accomplished with either transport encryption or with at-rest 1043 encryption, for example COSE_Encrypt. 1045 Mitigates: MFT13 1047 Implemented by: TLS/COSE 1049 4.4. User Stories 1051 User stories provide expected use cases. These are used to feed into 1052 usability requirements. 1054 4.4.1. Use Case MFUS1: Installation Instructions 1056 As an Device Operator, I want to provide my devices with additional 1057 installation instructions so that I can keep process details out of 1058 my payload data. 1060 Some installation instructions might be: 1062 - Use a table of hashes to ensure that each block of the payload is 1063 validate before writing. 1065 - Do not report progress. 1067 - Pre-cache the update, but do not install. 1069 - Install the pre-cached update matching this manifest. 1071 - Install this update immediately, overriding any long-running 1072 tasks. 1074 Satisfied by: MFUR1 1076 4.4.2. Use Case MFUS2: Override Non-Critical Manifest Elements 1078 As a Network Operator, I would like to be able to override the non- 1079 critical information in the manifest so that I can control my devices 1080 more precisely. This assumes that the Device Operator delegated 1081 rights about the device to the Network Operator. 1083 Some examples of potentially overridable information: 1085 - URIs: this allows the Network Operator to direct devices to their 1086 own infrastructure in order to reduce network load. 1088 - Conditions: this allows the Network Operator to pose additional 1089 constraints on the installation of the manifest. 1091 - Directives: this allows the Network Operator to add more 1092 instructions such as time of installation. 1094 - Processing Steps: If an intermediary performs an action on behalf 1095 of a device, it may need to override the processing steps. It is 1096 still possible for a device to verify the final content and the 1097 result of any processing step that specifies a digest. Some 1098 processing steps should be non-overridable. 1100 Satisfied by: MFUR2, MFUR3 1102 4.4.3. Use Case MFUS3: Modular Update 1104 As an Operator, I want to divide my firmware into frequently updated 1105 and infrequently updated components, so that I can reduce the size of 1106 updates and make different parties responsible for different 1107 components. 1109 Satisfied by: MFUR3 1111 4.4.4. Use Case MFUS4: Multiple Authorisations 1113 As a Device Operator, I want to ensure the quality of a firmware 1114 update before installing it, so that I can ensure interoperability of 1115 all devices in my product family. I want to restrict the ability to 1116 make changes to my devices to require my express approval. 1118 Satisfied by: MFUR4, MFSR8 1120 4.4.5. Use Case MFUS5: Multiple Payload Formats 1122 As an Operator, I want to be able to send multiple payload formats to 1123 suit the needs of my update, so that I can optimise the bandwidth 1124 used by my devices. 1126 Satisfied by: MFUR5 1128 4.4.6. Use Case MFUS6: Prevent Confidential Information Disclosures 1130 As an firmware author, I want to prevent confidential information 1131 from being disclosed during firmware updates. It is assumed that 1132 channel security is adequate to protect the manifest itself against 1133 information disclosure. 1135 Satisfied by: MFSR7 1137 4.4.7. Use Case MFUS7: Prevent Devices from Unpacking Unknown Formats 1139 As a Device Operator, I want devices to determine whether they can 1140 process a payload prior to downloading it. 1142 In some cases, it may be desirable for a third party to perform some 1143 processing on behalf of a target. For this to occur, the third party 1144 MUST indicate what processing occurred and how to verify it against 1145 the Trust Provisioning Authority's intent. 1147 This amounts to overriding Processing Steps and URIs. 1149 Satisfied by: MFUR6, MFUR2 1151 4.4.8. Use Case MFUS8: Specify Version Numbers of Target Firmware 1153 As a Device Operator, I want to be able to target devices for updates 1154 based on their current firmware version, so that I can control which 1155 versions are replaced with a single manifest. 1157 Satisfied by: MFUR7 1159 4.4.9. Use Case MFUS9: Enable Devices to Choose Between Images 1161 As a developer, I want to be able to sign two or more versions of my 1162 firmware in a single manifest so that I can use a very simple 1163 bootloader that chooses between two or more images that are executed 1164 in-place. 1166 Satisfied by: MFUR8 1168 4.4.10. Use Case MFUS10: Secure Boot Using Manifests 1170 As a signer for both secure boot and firmware deployment, I would 1171 like to use the same signed document for both tasks so that my data 1172 size is smaller, I can share common code, and I can reduce signature 1173 verifications. 1175 Satisfied by: MFUR9 1177 4.4.11. Use Case MFUS11: Decompress on Load 1179 As a developer of firmware for a run-from-RAM device, I would like to 1180 use compressed images and to indicate to the bootloader that I am 1181 using a compressed image in the manifest so that it can be used with 1182 secure boot. 1184 Satisfied by: MFUR10 1186 4.4.12. Use Case MFUS12: Payload in Manifest 1188 As an operator of a constrained network, I would like to be able to 1189 send a small payload in the same packet as the manifest so that I can 1190 reduce network traffic. 1192 Satisfied by: MFUR11 1194 4.4.13. Use Case MFUS13: Simple Parsing 1196 As a developer for constrained devices, I want a low complexity 1197 library for processing updates so that I can fit more application 1198 code on my device. 1200 Satisfied by: MFUR12 1202 4.5. Usability Requirements 1204 The following usability requirements satisfy the user stories listed 1205 above. 1207 4.5.1. Usability Requirement MFUR1 1209 It must be possible to provide all information necessary for the 1210 processing of a manifest into the manifest. 1212 Satisfies: User story MFUS1 1214 Implemented by: Manifest Element: Directives 1216 4.5.2. Usability Requirement MFUR2 1218 It must be possible to redirect payload fetches. This applies where 1219 two manifests are used in conjunction. For example, a Device 1220 Operator creates a manifest specifying a payload and signs it, and 1221 provides a URI for that payload. A Network Operator creates a second 1222 manifest, with a dependency on the first. They use this second 1223 manifest to override the URIs provided by the Device Operator, 1224 directing them into their own infrastructure instead. Some devices 1225 may provide this capability, while others may only look at canonical 1226 sources of firmware. For this to be possible, the device must fetch 1227 the payload, whereas a device that accpets payload pushes will ignore 1228 this feature. 1230 Satisfies: User story MFUS2 1232 Implemented by: Manifest Element: Aliases 1234 4.5.3. Usability Requirement MFUR3 1236 It must be possible express the requirement to install one or more 1237 payloads from one or more authorities so that a multi-payload update 1238 can be described. This allows multiple parties with different 1239 permissions to collaborate in creating a single update for the IoT 1240 device, across multiple components. 1242 This requirement effectively means that it must be possible to 1243 construct a tree of manifests on a multi-image target. 1245 Because devices can be either HeSA or HoSA both the storage system 1246 and the storage location within that storage system must be possible 1247 to specify. In a HoSA device, the payload location may be as simple 1248 as an address, or a file path. In a HeSA device, the payload 1249 location may be scoped by a component identifier. It is expedient to 1250 consider that all HoSA devices are HeSA devices with a single 1251 component. 1253 4.5.3.1. Example 1: Multiple Microcontrollers 1255 An IoT device with multiple microcontrollers in the same physical 1256 device (HeSA) will likely require multiple payloads with different 1257 component identifiers. 1259 4.5.3.2. Example 2: Code and Configuration 1261 A firmware image can be divided into two payloads: code and 1262 configuration. These payloads may require authorizations from 1263 different actors in order to install (see MFSR6 and MFSR8). This 1264 structure means that multiple manifests may be required, with a 1265 dependency structure between them. 1267 4.5.3.3. Example 3: Multiple Chunks 1269 A firmware image can be divided into multiple functional blocks for 1270 separate testing and distribution. This means that code would need 1271 to be distributed in multiple payloads. For example, this might be 1272 desirable in order to ensure that common code between devices is 1273 identical in order to reduce distribution bandwidth. 1275 Satisfies: User story MFUS2, MFUS3 1277 Implemented by Manifest Element: Dependencies, StorageIdentifier, 1278 ComponentIdentifier 1280 4.5.4. Usability Requirement MFUR4 1282 It MUST be possible to sign a manifest multiple times so that 1283 signatures from multiple parties with different permissions can be 1284 required in order to authorise installation of a manifest. 1286 Satisfies: User story MFUS4 1288 Implemented by: COSE Signature (or similar) 1290 4.5.5. Usability Requirement MFUR5 1292 The manifest format MUST accommodate any payload format that an 1293 Operator wishes to use. Some examples of payload format would be: 1295 - Binary 1297 - Elf 1299 - Differential 1301 - Compressed 1303 - Packed configuration 1305 - Intel HEX 1307 - S-Record 1309 Satisfies: User story MFUS5 1311 Implemented by: Manifest Element: Payload Format 1313 4.5.6. Usability Requirement MFUR6 1315 The manifest format must accommodate nested formats, announcing to 1316 the target device all the nesting steps and any parameters used by 1317 those steps. 1319 Satisfies: User story MFUS6 1321 Implemented by: Manifest Element: Processing Steps 1323 4.5.7. Usability Requirement MFUR7 1325 The manifest format must provide a method to specify multiple version 1326 numbers of firmware to which the manifest applies, either with a list 1327 or with range matching. 1329 Satisfies: User story MFUS8 1331 Implemented by: Manifest Element: Required Image Version List 1333 4.5.8. Usability Requirement MFUR8 1335 The manifest format must provide a mechanism to list multiple 1336 equivalent payloads by Execute-In-Place Installation Address, 1337 including the payload digest and, optionally, payload URIs. 1339 Satisfies: User story MFUS9 1341 Implemented by: Manifest Element: XIP Address 1343 4.5.9. Usability Requirement MFUR9: Bootable Manifest 1345 It must be possible to describe a bootable system with a manifest on 1346 both Execute-In-Place microcontrollers and on complex operating 1347 systems. This requires the manifest to specify the digest of each 1348 statically linked storage location. In addition, the manifest must 1349 be able to express metadata used by the bootloader, such as a kernel 1350 command-line. 1352 Satisfies: User story MFUS10 1354 Implemented by: Manifest Element: Boot-time Metadata 1356 4.5.10. Usability Requirement MFUR10: Load-Time Information 1358 It must be possible to specify additional metadata for load time 1359 processing of a payload, such as load-address, and compression 1360 algorithm. 1362 N.B. load comes before boot. 1364 Satisfies: User Story MFUS11 1366 Implemented by: Manifest Element: Load-time Metadata 1368 4.5.11. Usability Requirement MFUR11: Payload in Manifest 1369 Superstructure 1371 It must be possible to place a payload in the same structure as the 1372 manifest. This typically places the payload in the same packet as 1373 the manifest. 1375 Satisfies: User Story MFUS12 1376 Implemented by: Manifest Element: Payload 1378 4.5.12. Usability Requirement MFUR12: Simple Parsing 1380 The structure of the manifest must be simple to parse, without need 1381 for a general-purpose parser. 1383 Satisfies: User Story MFUS13 1385 Implemented by: N/A 1387 5. Security Considerations 1389 Security considerations for this document are covered in Section 4. 1391 6. IANA Considerations 1393 This document does not require any actions by IANA. 1395 7. Acknowledgements 1397 We would like to thank our working group chairs, Dave Thaler, Russ 1398 Housley and David Waltermire, for their review comments and their 1399 support. 1401 We would like to thank the participants of the 2018 Berlin SUIT 1402 Hackathon and the June 2018 virtual design team meetings for their 1403 discussion input. In particular, we would like to thank Koen 1404 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1405 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1406 Jan-Frederik Rieckers Francisco Acosta, Anton Gerasimov, Matthias 1407 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1408 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1409 Gharout, and Milen Stoychev. 1411 8. References 1413 8.1. Normative References 1415 [I-D.ietf-suit-architecture] 1416 Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A 1417 Firmware Update Architecture for Internet of Things 1418 Devices", draft-ietf-suit-architecture-02 (work in 1419 progress), January 2019. 1421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1422 Requirement Levels", BCP 14, RFC 2119, 1423 DOI 10.17487/RFC2119, March 1997, 1424 . 1426 8.2. Informative References 1428 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1429 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1430 DOI 10.17487/RFC4122, July 2005, 1431 . 1433 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1434 . 1437 8.3. URIs 1439 [1] mailto:suit@ietf.org 1441 [2] https://www1.ietf.org/mailman/listinfo/suit 1443 [3] https://www.ietf.org/mail-archive/web/suit/current/index.html 1445 Appendix A. Mailing List Information 1447 The discussion list for this document is located at the e-mail 1448 address suit@ietf.org [1]. Information on the group and information 1449 on how to subscribe to the list is at 1450 https://www1.ietf.org/mailman/listinfo/suit [2] 1452 Archives of the list can be found at: https://www.ietf.org/mail- 1453 archive/web/suit/current/index.html [3] 1455 Authors' Addresses 1457 Brendan Moran 1458 Arm Limited 1460 EMail: Brendan.Moran@arm.com 1462 Hannes Tschofenig 1463 Arm Limited 1465 EMail: hannes.tschofenig@gmx.net 1467 Henk Birkholz 1468 Fraunhofer SIT 1470 EMail: henk.birkholz@sit.fraunhofer.de