idnits 2.17.00 (12 Aug 2021) /tmp/idnits45367/draft-ietf-suit-information-model-06.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 : ---------------------------------------------------------------------------- == There are 168 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 01, 2020) is 718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-suit-architecture has been published as RFC 9019 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: Informational Arm Limited 5 Expires: December 3, 2020 H. Birkholz 6 Fraunhofer SIT 7 June 01, 2020 9 An Information Model for Firmware Updates in IoT Devices 10 draft-ietf-suit-information-model-06 12 Abstract 14 Vulnerabilities with Internet of Things (IoT) devices have raised the 15 need for a solid and secure firmware update mechanism that is also 16 suitable for constrained devices. Ensuring that devices function and 17 remain secure over their service life requires such an update 18 mechanism to fix vulnerabilities, to update configuration settings, 19 as well as adding new functionality 21 One component of such a firmware update is a concise and machine- 22 processable meta-data document, or manifest, that describes the 23 firmware image(s) and offers appropriate protection. This document 24 describes the information that must be 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 December 3, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 62 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 63 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 64 3.1. Manifest Element: Version ID of the manifest structure . 6 65 3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6 66 3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 6 67 3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7 68 3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7 69 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8 70 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 8 71 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9 72 3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 9 73 3.5. Manifest Element: Precursor Image Digest Condition . . . 10 74 3.6. Manifest Element: Required Image Version List . . . . . . 10 75 3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10 76 3.8. Manifest Element: Payload Format . . . . . . . . . . . . 10 77 3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11 78 3.10. Manifest Element: Storage Location . . . . . . . . . . . 11 79 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 11 80 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12 81 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12 82 3.11. Manifest Element: Component Identifier . . . . . . . . . 12 83 3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12 84 3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 13 85 3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13 86 3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13 87 3.16. Manifest Element: Additional installation instructions . 14 88 3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14 89 3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 14 90 3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 14 91 3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 15 92 3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15 93 3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 15 94 3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 15 95 3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15 97 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 98 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16 99 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16 100 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16 101 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old 102 Firmware . . . . . . . . . . . . . . . . . . . . . . 17 103 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 17 104 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 105 the type of payload . . . . . . . . . . . . . . . . . 18 106 4.2.5. THREAT.IMG.LOCATION: The target device installs the 107 payload to the wrong location . . . . . . . . . . . . 18 108 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 109 payload hosting . . . . . . . . . . . . . . . . . . . 18 110 4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 18 111 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 19 112 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 19 113 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 114 images . . . . . . . . . . . . . . . . . . . . . . . 19 115 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 20 116 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of 117 Firmware Image for Vulnerability Analysis . . . . . . 22 118 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 119 Elements . . . . . . . . . . . . . . . . . . . . . . 22 120 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 121 Exposure . . . . . . . . . . . . . . . . . . . . . . 22 122 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 22 123 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 23 124 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or 125 payload prior to signing . . . . . . . . . . . . . . 23 126 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 127 authentication and use . . . . . . . . . . . . . . . 23 128 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 24 129 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 24 130 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 24 131 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 25 132 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 25 133 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 25 134 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 135 Authenticated Storage Location . . . . . . . . . . . 25 136 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote 137 Resource Location . . . . . . . . . . . . . . . . . . 26 138 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 26 139 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 140 images . . . . . . . . . . . . . . . . . . . . . . . 26 141 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 142 Class IDs . . . . . . . . . . . . . . . . . . . . . . 26 143 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 26 144 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 27 145 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 27 146 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 28 147 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 28 148 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 28 149 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing 150 keys . . . . . . . . . . . . . . . . . . . . . . . . 28 151 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to 152 deployment . . . . . . . . . . . . . . . . . . . . . 29 153 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 154 trusted environment . . . . . . . . . . . . . . . . . 29 155 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between 156 check and use . . . . . . . . . . . . . . . . . . . . 29 157 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 29 158 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 159 Instructions . . . . . . . . . . . . . . . . . . . . 29 160 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 30 161 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 162 Elements . . . . . . . . . . . . . . . . . . . . . . 30 163 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 31 164 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 31 165 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 31 166 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 167 Information Disclosures . . . . . . . . . . . . . . . 31 168 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from 169 Unpacking Unknown Formats . . . . . . . . . . . . . . 31 170 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 171 Numbers of Target Firmware . . . . . . . . . . . . . 32 172 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 173 Between Images . . . . . . . . . . . . . . . . . . . 32 174 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 175 Manifests . . . . . . . . . . . . . . . . . . . . . . 32 176 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 32 177 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 33 178 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 33 179 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 180 Manifest . . . . . . . . . . . . . . . . . . . . . . 33 181 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 33 182 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 33 183 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 33 184 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 185 Resource Location . . . . . . . . . . . . . . . . . . 34 186 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 34 187 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 35 188 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 35 189 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 36 190 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 36 191 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 36 192 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 36 193 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 37 194 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 37 195 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 38 196 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 197 Manifest . . . . . . . . . . . . . . . . . . . . . . 38 198 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 199 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 200 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 201 7.1. Normative References . . . . . . . . . . . . . . . . . . 39 202 7.2. Informative References . . . . . . . . . . . . . . . . . 39 203 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 205 1. Introduction 207 The information model describes all the information elements required 208 to secure firmware updates of IoT devices from the threats described 209 in Section 4.1 and enables the user stories captured in Section 4.4. 210 These threats and user stories are not intended to be an exhaustive 211 list of the threats against IoT devices, nor of the possible user 212 stories that describe how to conduct a firmware update. Instead they 213 are intended to describe the threats against firmware updates in 214 isolation and provide sufficient motivation to specify the 215 information elements that cover a wide range of user stories. The 216 information model does not define the serialization, encoding, 217 ordering, or structure of information elements, only their semantics. 219 Because the information model covers a wide range of user stories and 220 a wide range of threats, not all information elements apply to all 221 scenarios. As a result, various information elements could be 222 considered optional to implement and optional to use, depending on 223 which threats exist in a particular domain of application and which 224 user stories are required. Elements marked as REQUIRED provide 225 baseline security and usability properties that are expected to be 226 required for most applications. Those elements are REQUIRED to 227 implement and REQUIRED to use. Elements marked as recommended 228 provide important security or usability properties that are needed on 229 most devices. Elements marked as optional enable security or 230 usability properties that are useful in some applications. 232 The definition of some of the information elements include examples 233 that illustrate their semantics and how they are intended to be used. 235 2. Conventions and Terminology 237 This document uses terms defined in [I-D.ietf-suit-architecture]. 238 The term 'Operator' refers to both Device and Network Operator. 240 This document treats devices with a homogeneous storage architecture 241 as devices with a heterogeneous storage architecture, but with a 242 single storage subsystem. 244 2.1. Requirements Notation 246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 248 "OPTIONAL" in this document are to be interpreted as described in 249 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 250 capitals, as shown here. 252 3. Manifest Information Elements 254 Each manifest information element is anchored in a security 255 requirement or a usability requirement. The manifest elements are 256 described below, justified by their requirements. 258 3.1. Manifest Element: Version ID of the manifest structure 260 An identifier that describes which iteration of the manifest format 261 is contained in the structure. 263 This element is REQUIRED and MUST be present in order to allow 264 devices to identify the version of the manifest data model that is in 265 use. 267 3.2. Manifest Element: Monotonic Sequence Number 269 A monotonically increasing sequence number. For convenience, the 270 monotonic sequence number MAY be a UTC timestamp. This allows global 271 synchronisation of sequence numbers without any additional 272 management. This number MUST be easily accessible so that code 273 choosing one out of several manifests can choose which is the latest. 275 This element is REQUIRED and is necessary to prevent malicious actors 276 from reverting a firmware update against the policies of the relevant 277 authority. 279 Implements: REQ.SEC.SEQUENCE (Section 4.3.1) 281 3.3. Manifest Element: Vendor ID 283 Vendor IDs must be unique. This is to prevent similarly, or 284 identically named entities from different geographic regions from 285 colliding in their customer's infrastructure. Recommended practice 286 is to use [RFC4122] version 5 UUIDs with the vendor's domain name and 287 the DNS name space ID. Other options include type 1 and type 4 288 UUIDs. 290 Vendor ID is not intended to be a human-readable element. It is 291 intended for binary match/mismatch comparison only. 293 The use of a Vendor ID is RECOMMENDED. It helps to distinguish 294 between identically named products from different vendors. 296 Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), 297 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 299 3.3.1. Example: Domain Name-based UUIDs 301 Vendor A creates a UUID based on their domain name: 303 vendorId = UUID5(DNS, "vendor-a.com") 305 Because the DNS infrastructure prevents multiple registrations of the 306 same domain name, this UUID is (with very high probability) 307 guaranteed to be unique. Because the domain name is known, this UUID 308 is reproducible. Type 1 and type 4 UUIDs produce similar guarantees 309 of uniqueness, but not reproducibility. 311 This approach creates a contention when a vendor changes its name or 312 relinquishes control of a domain name. In this scenario, it is 313 possible that another vendor would start using that same domain name. 314 However, this UUID is not proof of identity; a device's trust in a 315 vendor must be anchored in a cryptographic key, not a UUID. 317 3.4. Manifest Element: Class ID 319 A device "Class" is a set of different device types that can accept 320 the same firmware update without modification. Class IDs MUST be 321 unique within the scope of a Vendor ID. This is to prevent 322 similarly, or identically named devices colliding in their customer's 323 infrastructure. 325 Recommended practice is to use [RFC4122] version 5 UUIDs with as much 326 information as necessary to define firmware compatibility. Possible 327 information used to derive the class UUID includes: 329 o model name or number 331 o hardware revision 333 o runtime library version 334 o bootloader version 336 o ROM revision 338 o silicon batch number 340 The Class Identifier UUID SHOULD use the Vendor ID as the name space 341 ID. Other options include version 1 and 4 UUIDs. Classes MAY be 342 more granular than is required to identify firmware compatibility. 343 Classes MUST NOT be less granular than is required to identify 344 firmware compatibility. Devices MAY have multiple Class IDs. 346 Class ID is not intended to be a human-readable element. It is 347 intended for binary match/mismatch comparison only. 349 The use of Class ID is RECOMMENDED. It allows devices to determine 350 applicability of a firmware in an unambiguous way. 352 If Class ID is not implemented, then each logical device class MUST 353 use a unique trust anchor for authorisation. 355 Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), 356 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 358 3.4.1. Example 1: Different Classes 360 Vendor A creates product Z and product Y. The firmware images of 361 products Z and Y are not interchangeable. Vendor A creates UUIDs as 362 follows: 364 o vendorId = UUID5(DNS, "vendor-a.com") 366 o ZclassId = UUID5(vendorId, "Product Z") 368 o YclassId = UUID5(vendorId, "Product Y") 370 This ensures that Vendor A's Product Z cannot install firmware for 371 Product Y and Product Y cannot install firmware for Product Z. 373 3.4.2. Example 2: Upgrading Class ID 375 Vendor A creates product X. Later, Vendor A adds a new feature to 376 product X, creating product X v2. Product X requires a firmware 377 update to work with firmware intended for product X v2. 379 Vendor A creates UUIDs as follows: 381 o vendorId = UUID5(DNS, "vendor-a.com") 382 o XclassId = UUID5(vendorId, "Product X") 384 o Xv2classId = UUID5(vendorId, "Product X v2") 386 When product X receives the firmware update necessary to be 387 compatible with product X v2, part of the firmware update changes the 388 class ID to Xv2classId. 390 3.4.3. Example 3: Shared Functionality 392 Vendor A produces two products, product X and product Y. These 393 components share a common core (such as an operating system), but 394 have different applications. The common core and the applications 395 can be updated independently. To enable X and Y to receive the same 396 common core update, they require the same class ID. To ensure that 397 only product X receives application X and only product Y receives 398 application Y, product X and product Y must have different class IDs. 399 The vendor creates Class IDs as follows: 401 o vendorId = UUID5(DNS, "vendor-a.com") 403 o XclassId = UUID5(vendorId, "Product X") 405 o YclassId = UUID5(vendorId, "Product Y") 407 o CommonClassId = UUID5(vendorId, "common core") 409 Product X matches against both XclassId and CommonClassId. Product Y 410 matches against both YclassId and CommonClassId. 412 3.4.4. Example 4: White-labelling 414 Vendor A creates a product A and its firmware. Vendor B sells the 415 product under its own name as Product B with some customised 416 configuration. The vendors create the Class IDs as follows: 418 o vendorIdA = UUID5(DNS, "vendor-a.com") 420 o classIdA = UUID5(vendorIdA, "Product A-Unlabelled") 422 o vendorIdB = UUID5(DNS, "vendor-b.com") 424 o classIdB = UUID5(vendorIdB, "Product B") 426 The product will match against each of these class IDs. If Vendor A 427 and Vendor B provide different components for the device, the 428 implementor MAY choose to make ID matching scoped to each component. 429 Then, the vendorIdA, classIdA match the component ID supplied by 430 Vendor A, and the vendorIdB, classIdB match the component ID supplied 431 by Vendor B. 433 3.5. Manifest Element: Precursor Image Digest Condition 435 When a precursor image is required by the payload format, a precursor 436 image digest condition MUST be present in the conditions list. The 437 precursor image may be installed or stored as a candidate. 439 This element is OPTIONAL to implement. 441 Enables feature: differential updates. 443 Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 445 3.6. Manifest Element: Required Image Version List 447 When a payload applies to multiple versions of a firmware, the 448 required image version list specifies which versions must be present 449 for the update to be applied. This allows the update author to 450 target specific versions of firmware for an update, while excluding 451 those to which it should not be applied. 453 Where an update can only be applied over specific predecessor 454 versions, that version MUST be specified by the Required Image 455 Version List. 457 This element is OPTIONAL. 459 Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) 461 3.7. Manifest Element: Expiration Time 463 This element tells a device the time at which the manifest expires 464 and should no longer be used. This is only usable in conjunction 465 with a secure source of time. 467 This element is OPTIONAL and MAY enable user stories where a secure 468 source of time is provided and firmware is intended to expire 469 predictably. 471 Implements: REQ.SEC.EXP (Section 4.3.3) 473 3.8. Manifest Element: Payload Format 475 The format of the payload MUST be indicated to devices in an 476 unambiguous way. This element provides a mechanism to describe the 477 payload format, within the signed metadata. 479 This element is REQUIRED and MUST be present to enable devices to 480 decode payloads correctly. 482 Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT 483 (Section 4.5.5) 485 3.9. Manifest Element: Processing Steps 487 A representation of the Processing Steps required to decode a 488 payload. The representation MUST describe which algorithm(s) is used 489 and any additional parameters required by the algorithm(s). The 490 representation MAY group Processing Steps together in predefined 491 combinations. 493 A Processing Step MAY indicate the expected digest of the payload 494 after the processing is complete. 496 Processing steps are RECOMMENDED to implement. 498 Enables feature: Encrypted, compressed, packed formats 500 Implements: REQ.USE.IMG.NESTED (Section 4.5.6) 502 3.10. Manifest Element: Storage Location 504 This element tells the device where to store a payload within a given 505 component. The device can use this to establish which permissions 506 are necessary and the physical storage location to use. 508 This element is REQUIRED and MUST be present to enable devices to 509 store payloads to the correct location. 511 Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 513 3.10.1. Example 1: Two Storage Locations 515 A device supports two components: an OS and an application. These 516 components can be updated independently, expressing dependencies to 517 ensure compatibility between the components. The Author chooses two 518 storage identifiers: 520 o "OS" 522 o "APP" 524 3.10.2. Example 2: File System 526 A device supports a full filesystem. The Author chooses to use the 527 storage identifier as the path at which to install the payload. The 528 payload may be a tarball, in which case, it unpacks the tarball into 529 the specified path. 531 3.10.3. Example 3: Flash Memory 533 A device supports flash memory. The Author chooses to make the 534 storage identifier the offset where the image should be written. 536 3.11. Manifest Element: Component Identifier 538 In a heterogeneous storage architecture, a storage identifier is 539 insufficient to identify where and how to store a payload. To 540 resolve this, a component identifier indicates which part of the 541 storage architecture is targeted by the payload. In a homogeneous 542 storage architecture, this element is unnecessary. 544 This element is OPTIONAL and only necessary in heterogeneous storage 545 architecture devices. 547 N.B. A serialisation MAY choose to combine Component Identifier and 548 Storage Location (Section 3.10) 550 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 552 3.12. Manifest Element: Resource Indicator 554 This element provides the information required for the device to 555 acquire the resource. This can be encoded in several ways: 557 o One URI 559 o A list of URIs 561 o A prioritised list of URIs 563 o A list of signed URIs 565 This element is OPTIONAL and only needed when the target device does 566 not intrinsically know where to find the payload. 568 N.B. Devices will typically require URIs. 570 Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 572 3.13. Manifest Element: Payload Digests 574 This element contains one or more digests of one or more payloads. 575 This allows the target device to ensure authenticity of the 576 payload(s). A serialisation MUST provide a mechanism to select one 577 payload from a list based on system parameters, such as Execute-In- 578 Place Installation Address. 580 This element is REQUIRED to implement and fundamentally necessary to 581 ensure the authenticity and integrity of the payload. Support for 582 more than one digest is OPTIONAL to implement in a recipient device. 584 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT 585 (Section 4.5.8) 587 3.14. Manifest Element: Size 589 The size of the payload in bytes. 591 Variable-size storage locations MUST be set to exactly the size 592 listed in this element. 594 This element is REQUIRED and informs the target device how big of a 595 payload to expect. Without it, devices are exposed to some classes 596 of denial of service attack. 598 Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) 600 3.15. Manifest Element: Signature 602 This is not strictly a manifest element. Instead, the manifest is 603 wrapped by a standardised authentication container, such as a COSE 604 ([RFC8152]) or CMS ([RFC5652]) signature object. The authentication 605 container MUST support multiple actors and multiple authentication 606 methods. 608 This element is REQUIRED in non-dependency manifests and represents 609 the foundation of all security properties of the manifest. Manifests 610 which are included as dependencies by another manifest SHOULD include 611 a signature so that the recipient can distinguish between different 612 actors with different permissions. 614 A manifest MUST NOT be considered authenticated by channel security 615 even if it contains only channel information (such as URIs). If the 616 authenticated remote or channel were compromised, the threat actor 617 could induce recipients to query traffic over any accessible network. 618 Lightweight authentication with pre-existing relationships SHOULD be 619 done with MAC. 621 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS 622 (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) 624 3.16. Manifest Element: Additional installation instructions 626 Instructions that the device should execute when processing the 627 manifest. This information is distinct from the information 628 necessary to process a payload. Additional installation instructions 629 include information such as update timing (for example, install only 630 on Sunday, at 0200), procedural considerations (for example, shut 631 down the equipment under control before executing the update), pre- 632 and post-installation steps (for example, run a script). 634 This element is OPTIONAL. 636 Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 638 3.17. Manifest Element: Aliases 640 A mechanism for a manifest to augment or replace URIs or URI lists 641 defined by one or more of its dependencies. 643 This element is OPTIONAL and enables some user stories. 645 Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 647 3.18. Manifest Element: Dependencies 649 A list of other manifests that are required by the current manifest. 650 Manifests are identified an unambiguous way, such as a digest. 652 This element is REQUIRED to use in deployments that include both 653 multiple authorities and multiple payloads. 655 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 657 3.19. Manifest Element: Encryption Wrapper 659 Encrypting firmware images requires symmetric content encryption 660 keys. The encryption wrapper provides the information needed for a 661 device to obtain or locate a key that it uses to decrypt the 662 firmware. Typical choices for an encryption wrapper include CMS 663 ([RFC5652]) or COSE ([RFC8152]). This MAY be included in a 664 decryption step contained in Processing Steps (Section 3.9). 666 This element is REQUIRED to use for encrypted payloads, 668 Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 670 3.20. Manifest Element: XIP Address 672 In order to support XIP systems with multiple possible base 673 addresses, it is necessary to specify which address the payload is 674 linked for. 676 For example a microcontroller may have a simple bootloader that 677 chooses one of two images to boot. That microcontroller then needs 678 to choose one of two firmware images to install, based on which of 679 its two images is older. 681 Implements: REQ.USE.IMG.SELECT (Section 4.5.8) 683 3.21. Manifest Element: Load-time metadata 685 Load-time metadata provides the device with information that it needs 686 in order to load one or more images. This is effectively a copy 687 operation from the permanent storage location of an image into the 688 active use location of that image. The metadata contains the source 689 and destination of the image as well as any operations that are 690 performed on the image. 692 Implements: REQ.USE.LOAD (Section 4.5.10) 694 3.22. Manifest Element: Run-time metadata 696 Run-time metadata provides the device with any extra information 697 needed to boot the device. This may include information such as the 698 entry-point of an XIP image or the kernel command-line of a Linux 699 image. 701 Implements: REQ.USE.EXEC (Section 4.5.9) 703 3.23. Manifest Element: Payload 705 The Payload element provides a recipient device with the whole 706 payload, contained within the manifest superstructure. This enables 707 the manifest and payload to be delivered simultaneously. 709 Implements: REQ.USE.PAYLOAD (Section 4.5.11) 711 3.24. Manifest Element: Key Claims 713 The Key Claims element is not authenticated by the Signature 714 (Section 3.15), instead, it provides a chain of key delegations (or 715 references to them) for the device to follow in order to verify the 716 key that authenticated the manifest using a trusted key. 718 Implements: REQ.USE.DELEGATION (Section 4.5.13) 720 4. Security Considerations 722 The following sub-sections describe the threat model, user stories, 723 security requirements, and usability requirements. This section also 724 provides the motivations for each of the manifest information 725 elements. 727 4.1. Threat Model 729 The following sub-sections aim to provide information about the 730 threats that were considered, the security requirements that are 731 derived from those threats and the fields that permit implementation 732 of the security requirements. This model uses the S.T.R.I.D.E. 733 [STRIDE] approach. Each threat is classified according to: 735 o Spoofing identity 737 o Tampering with data 739 o Repudiation 741 o Information disclosure 743 o Denial of service 745 o Elevation of privilege 747 This threat model only covers elements related to the transport of 748 firmware updates. It explicitly does not cover threats outside of 749 the transport of firmware updates. For example, threats to an IoT 750 device due to physical access are out of scope. 752 4.2. Threat Descriptions 754 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 756 Classification: Elevation of Privilege 758 An attacker sends an old, but valid manifest with an old, but valid 759 firmware image to a device. If there is a known vulnerability in the 760 provided firmware image, this may allow an attacker to exploit the 761 vulnerability and gain control of the device. 763 Threat Escalation: If the attacker is able to exploit the known 764 vulnerability, then this threat can be escalated to ALL TYPES. 766 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 768 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old Firmware 770 Classification: Elevation of Privilege 772 An attacker targets a device that has been offline for a long time 773 and runs an old firmware version. The attacker sends an old, but 774 valid manifest to a device with an old, but valid firmware image. 775 The attacker-provided firmware is newer than the installed one but 776 older than the most recently available firmware. If there is a known 777 vulnerability in the provided firmware image then this may allow an 778 attacker to gain control of a device. Because the device has been 779 offline for a long time, it is unaware of any new updates. As such 780 it will treat the old manifest as the most current. 782 Threat Escalation: If the attacker is able to exploit the known 783 vulnerability, then this threat can be escalated to ALL TYPES. 785 Mitigated by: REQ.SEC.EXP (Section 4.3.3) 787 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 789 Classification: Denial of Service 791 An attacker sends a valid firmware image, for the wrong type of 792 device, signed by an actor with firmware installation permission on 793 both types of device. The firmware is verified by the device 794 positively because it is signed by an actor with the appropriate 795 permission. This could have wide-ranging consequences. For devices 796 that are similar, it could cause minor breakage, or expose security 797 vulnerabilities. For devices that are very different, it is likely 798 to render devices inoperable. 800 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 802 4.2.3.1. Example: 804 Suppose that two vendors, Vendor A and Vendor B, adopt the same trade 805 name in different geographic regions, and they both make products 806 with the same names, or product name matching is not used. This 807 causes firmware from Vendor A to match devices from Vendor B. 809 If the vendors are the firmware authorities, then devices from Vendor 810 A will reject images signed by Vendor B since they use different 811 credentials. However, if both devices trust the same Author, then, 812 devices from Vendor A could install firmware intended for devices 813 from Vendor B. 815 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 816 payload 818 Classification: Denial of Service 820 If a device misinterprets the format of the firmware image, it may 821 cause a device to install a firmware image incorrectly. An 822 incorrectly installed firmware image would likely cause the device to 823 stop functioning. 825 Threat Escalation: An attacker that can cause a device to 826 misinterpret the received firmware image may gain elevation of 827 privilege and potentially expand this to all types of threat. 829 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 831 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 832 the wrong location 834 Classification: Denial of Service 836 If a device installs a firmware image to the wrong location on the 837 device, then it is likely to break. For example, a firmware image 838 installed as an application could cause a device and/or an 839 application to stop functioning. 841 Threat Escalation: An attacker that can cause a device to 842 misinterpret the received code may gain elevation of privilege and 843 potentially expand this to all types of threat. 845 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.5) 847 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 849 Classification: Denial of Service 851 If a device does not know where to obtain the payload for an update, 852 it may be redirected to an attacker's server. This would allow an 853 attacker to provide broken payloads to devices. 855 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 857 4.2.7. THREAT.NET.MITM: Traffic interception 859 Classification: Spoofing Identity, Tampering with Data 861 An attacker intercepts all traffic to and from a device. The 862 attacker can monitor or modify any data sent to or received from the 863 device. This can take the form of: manifests, payloads, status 864 reports, and capability reports being modified or not delivered to 865 the intended recipient. It can also take the form of analysis of 866 data sent to or from the device, either in content, size, or 867 frequency. 869 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), 870 REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC 871 (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), 872 REQ.SEC.REPORTING (Section 4.3.16) 874 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 876 Classification: Elevation of Privilege 878 An attacker replaces a newly downloaded firmware after a device 879 finishes verifying a manifest. This could cause the device to 880 execute the attacker's code. This attack likely requires physical 881 access to the device. However, it is possible that this attack is 882 carried out in combination with another threat that allows remote 883 execution. This is a typical Time Of Check/Time Of Use threat. 885 Threat Escalation: If the attacker is able to exploit a known 886 vulnerability, or if the attacker can supply their own firmware, then 887 this threat can be escalated to ALL TYPES. 889 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 891 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 893 Classification: Elevation of Privilege / All Types 895 If an attacker can install their firmware on a device, by 896 manipulating either payload or metadata, then they have complete 897 control of the device. 899 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 901 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 903 Classification: Denial of Service / All Types 905 An attacker sends a valid, current manifest to a device that has an 906 unexpected precursor image. If a payload format requires a precursor 907 image (for example, delta updates) and that precursor image is not 908 available on the target device, it could cause the update to break. 910 An attacker that can cause a device to install a payload against the 911 wrong precursor image could gain elevation of privilege and 912 potentially expand this to all types of threat. However, it is 913 unlikely that a valid differential update applied to an incorrect 914 precursor would result in a functional, but vulnerable firmware. 916 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 918 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 920 Classification: Denial of Service, Elevation of Privilege 922 This threat can appear in several ways, however it is ultimately 923 about ensuring that devices retain the behaviour required by their 924 Owner, Device Operator, or Network Operator. The owner or operator 925 of a device typically requires that the device maintain certain 926 features, functions, capabilities, behaviours, or interoperability 927 constraints (more generally, behaviour). If these requirements are 928 broken, then a device will not fulfill its purpose. Therefore, if 929 any party other than the device's Owner or the Owner's contracted 930 Device Operator has the ability to modify device behaviour without 931 approval, then this constitutes an elevation of privilege. 933 Similarly, a network operator may require that devices behave in a 934 particular way in order to maintain the integrity of the network. If 935 devices behaviour on a network can be modified without the approval 936 of the network operator, then this constitutes an elevation of 937 privilege with respect to the network. 939 For example, if the owner of a device has purchased that device 940 because of Features A, B, and C, and a firmware update is issued by 941 the manufacturer, which removes Feature A, then the device may not 942 fulfill the owner's requirements any more. In certain circumstances, 943 this can cause significantly greater threats. Suppose that Feature A 944 is used to implement a safety-critical system, whether the 945 manufacturer intended this behaviour or not. When unapproved 946 firmware is installed, the system may become unsafe. 948 In a second example, the owner or operator of a system of two or more 949 interoperating devices needs to approve firmware for their system in 950 order to ensure interoperability with other devices in the system. 951 If the firmware is not qualified, the system as a whole may not work. 952 Therefore, if a device installs firmware without the approval of the 953 device owner or operator, this is a threat to devices or the system 954 as a whole. 956 Similarly, the operator of a network may need to approve firmware for 957 devices attached to the network in order to ensure favourable 958 operating conditions within the network. If the firmware is not 959 qualified, it may degrade the performance of the network. Therefore, 960 if a device installs firmware without the approval of the network 961 operator, this is a threat to the network itself. 963 Threat Escalation: If the firmware expects configuration that is 964 present in devices deployed in Network A, but not in devices deployed 965 in Network B, then the device may experience degraded security, 966 leading to threats of All Types. 968 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 969 (Section 4.3.13) 971 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 972 Operator 974 In this example, assume that Device Operators expect the rights to 975 create firmware but that Network Operators expect the rights to 976 qualify firmware as fit-for-purpose on their networks. Additionally, 977 assume that Device Operators manage devices that can be deployed on 978 any network, including Network A and B in our example. 980 An attacker may obtain a manifest for a device on Network A. Then, 981 this attacker sends that manifest to a device on Network B. Because 982 Network A and Network B are under control of different Operators, and 983 the firmware for a device on Network A has not been qualified to be 984 deployed on Network B, the target device on Network B is now in 985 violation of the Operator B's policy and may be disabled by this 986 unqualified, but signed firmware. 988 This is a denial of service because it can render devices inoperable. 989 This is an elevation of privilege because it allows the attacker to 990 make installation decisions that should be made by the Operator. 992 4.2.11.2. Example 2: Single Network Operator with Multiple Device 993 Operators 995 Multiple devices that interoperate are used on the same network and 996 communicate with each other. Some devices are manufactured and 997 managed by Device Operator A and other devices by Device Operator B. 998 A new firmware is released by Device Operator A that breaks 999 compatibility with devices from Device Operator B. An attacker sends 1000 the new firmware to the devices managed by Device Operator A without 1001 approval of the Network Operator. This breaks the behaviour of the 1002 larger system causing denial of service and possibly other threats. 1003 Where the network is a distributed SCADA system, this could cause 1004 misbehaviour of the process that is under control. 1006 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 1007 for Vulnerability Analysis 1009 Classification: All Types 1011 An attacker wants to mount an attack on an IoT device. To prepare 1012 the attack he or she retrieves the provided firmware image and 1013 performs reverse engineering of the firmware image to analyze it for 1014 specific vulnerabilities. 1016 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1018 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 1020 Classification: Elevation of Privilege 1022 An authorised actor, but not the Author, uses an override mechanism 1023 (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information 1024 element in a manifest signed by the Author. For example, if the 1025 authorised actor overrides the digest and URI of the payload, the 1026 actor can replace the entire payload with a payload of their choice. 1028 Threat Escalation: By overriding elements such as payload 1029 installation instructions or firmware digest, this threat can be 1030 escalated to all types. 1032 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1034 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 1036 Classification: Information Disclosure 1038 A third party may be able to extract sensitive information from the 1039 manifest. 1041 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 1043 4.2.15. THREAT.IMG.EXTRA: Extra data after image 1045 Classification: All Types 1047 If a third party modifies the image so that it contains extra code 1048 after a valid, authentic image, that third party can then use their 1049 own code in order to make better use of an existing vulnerability. 1051 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 1053 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 1055 Classification: All Types 1057 If a third party obtains a key or even indirect access to a key, for 1058 example in an HSM, then they can perform the same actions as the 1059 legitimate owner of the key. If the key is trusted for firmware 1060 update, then the third party can perform firmware updates as though 1061 they were the legitimate owner of the key. 1063 For example, if manifest signing is performed on a server connected 1064 to the internet, an attacker may compromise the server and then be 1065 able to sign manifests, even if the keys for manifest signing are 1066 held in an HSM that is accessed by the server. 1068 Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17) 1070 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 1071 prior to signing 1073 Classification: All Types 1075 If an attacker can alter a manifest or payload before it is signed, 1076 they can perform all the same actions as the manifest author. This 1077 allows the attacker to deploy firmware updates to any devices that 1078 trust the manifest author. If an attacker can modify the code of a 1079 payload before the corresponding manifest is created, they can insert 1080 their own code. If an attacker can modify the manifest before it is 1081 signed, they can redirect the manifest to their own payload. 1083 For example, the attacker deploys malware to the developer's computer 1084 or signing service that watches manifest creation activities and 1085 inserts code into any binary that is referenced by a manifest. 1087 For example, the attacker deploys malware to the developer's computer 1088 or signing service that replaces the referenced binary (digest) and 1089 URI with the attacker's binary (digest) and URI. 1091 Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18), 1092 REQ.SEC.MFST.TRUSTED (Section 4.3.19) 1094 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 1095 authentication and use 1097 Classification: All Types 1098 If an attacker can modify a manifest after it is authenticated (Time 1099 Of Check) but before it is used (Time Of Use), then the attacker can 1100 place any content whatsoever in the manifest. 1102 Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.20) 1104 4.3. Security Requirements 1106 The security requirements here are a set of policies that mitigate 1107 the threats described in Section 4.1. 1109 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 1111 Only an actor with firmware installation authority is permitted to 1112 decide when device firmware can be installed. To enforce this rule, 1113 manifests MUST contain monotonically increasing sequence numbers. 1114 Manifests MAY use UTC epoch timestamps to coordinate monotonically 1115 increasing sequence numbers across many actors in many locations. If 1116 UTC epoch timestamps are used, they MUST NOT be treated as times, 1117 they MUST be treated only as sequence numbers. Devices MUST reject 1118 manifests with sequence numbers smaller than any onboard sequence 1119 number. 1121 Note: This is not a firmware version. It is a manifest sequence 1122 number. A firmware version may be rolled back by creating a new 1123 manifest for the old firmware version with a later sequence number. 1125 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 1127 Implemented by: Monotonic Sequence Number (Section 3.2) 1129 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1131 Devices MUST only apply firmware that is intended for them. Devices 1132 MUST know with fine granularity that a given update applies to their 1133 vendor, model, hardware revision, software revision. Human-readable 1134 identifiers are often error-prone in this regard, so unique 1135 identifiers SHOULD be used. 1137 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1139 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1140 (Section 3.4) 1142 4.3.3. REQ.SEC.EXP: Expiration Time 1144 Firmware MAY expire after a given time. Devices MAY provide a secure 1145 clock (local or remote). If a secure clock is provided and the 1146 Firmware manifest has an expiration timestamp, the device MUST reject 1147 the manifest if current time is later than the expiration time. 1149 Mitigates: THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2) 1151 Implemented by: Expiration Time (Section 3.7) 1153 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1155 The authenticity of an update MUST be demonstrable. Typically, this 1156 means that updates must be digitally authenticated. Because the 1157 manifest contains information about how to install the update, the 1158 manifest's authenticity MUST also be demonstrable. To reduce the 1159 overhead required for validation, the manifest contains the digest of 1160 the firmware image, rather than a second digital signature. The 1161 authenticity of the manifest can be verified with a digital signature 1162 or Message Authentication Code. The authenticity of the firmware 1163 image is tied to the manifest by the use of a digest of the firmware 1164 image. 1166 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.MITM 1167 (Section 4.2.7) 1169 Implemented by: Signature (Section 3.15), Payload Digest 1170 (Section 3.13) 1172 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1174 The type of payload (which may be independent of format) MUST be 1175 authenticated. For example, the target must know whether the payload 1176 is XIP firmware, a loadable module, or serialized configuration data. 1178 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1180 Implemented by: Payload Format (Section 3.8), Storage Location 1181 (Section 3.10) 1183 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1184 Location 1186 The location on the target where the payload is to be stored MUST be 1187 authenticated. 1189 Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) 1190 Implemented by: Storage Location (Section 3.10) 1192 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location 1194 The location where a target should find a payload MUST be 1195 authenticated. 1197 Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.MITM 1198 (Section 4.2.7) 1200 Implemented by: Resource Indicator (Section 3.12) 1202 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 1204 The target SHOULD verify firmware at time of boot. This requires 1205 authenticated payload size, and digest. 1207 Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) 1209 Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) 1211 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 1213 If an update uses a differential compression method, it MUST specify 1214 the digest of the precursor image and that digest MUST be 1215 authenticated. 1217 Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10) 1219 Implemented by: Precursor Image Digest (Section 3.5) 1221 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs 1223 The identifiers that specify firmware compatibility MUST be 1224 authenticated to ensure that only compatible firmware is installed on 1225 a target device. 1227 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1229 Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition 1230 (Section 3.4) 1232 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 1234 If a device grants different rights to different actors, exercising 1235 those rights MUST be accompanied by proof of those rights, in the 1236 form of proof of authenticity. Authenticity mechanisms such as those 1237 required in REQ.SEC.AUTHENTIC (Section 4.3.4) can be used to prove 1238 authenticity. 1240 For example, if a device has a policy that requires that firmware 1241 have both an Authorship right and a Qualification right and if that 1242 device grants Authorship and Qualification rights to different 1243 parties, such as a Device Operator and a Network Operator, 1244 respectively, then the firmware cannot be installed without proof of 1245 rights from both the Device Operator and the Network Operator. 1247 Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11) 1249 Implemented by: Signature (Section 3.15) 1251 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 1253 The manifest information model MUST enable encrypted payloads. 1254 Encryption helps to prevent third parties, including attackers, from 1255 reading the content of the firmware image. This can protect against 1256 confidential information disclosures and discovery of vulnerabilities 1257 through reverse engineering. Therefore the manifest must convey the 1258 information required to allow an intended recipient to decrypt an 1259 encrypted payload. 1261 Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.MITM 1262 (Section 4.2.7) 1264 Implemented by: Encryption Wrapper (Section 3.19) 1266 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 1268 If a device grants different rights to different actors, then an 1269 exercise of those rights MUST be validated against a list of rights 1270 for the actor. This typically takes the form of an Access Control 1271 List (ACL). ACLs are applied to two scenarios: 1273 1. An ACL decides which elements of the manifest may be overridden 1274 and by which actors. 1276 2. An ACL decides which component identifier/storage identifier 1277 pairs can be written by which actors. 1279 Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), 1280 THREAT.UPD.UNAPPROVED (Section 4.2.11) 1282 Implemented by: Client-side code, not specified in manifest. 1284 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 1286 It MUST be possible to encrypt part or all of the manifest. This may 1287 be accomplished with either transport encryption or with at-rest 1288 encryption. 1290 Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.MITM 1291 (Section 4.2.7) 1293 Implemented by: External Encryption Wrapper / Transport Security 1295 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 1297 The digest SHOULD cover all available space in a fixed-size storage 1298 location. Variable-size storage locations MUST be restricted to 1299 exactly the size of deployed payload. This prevents any data from 1300 being distributed without being covered by the digest. For example, 1301 XIP microcontrollers typically have fixed-size storage. These 1302 devices should deploy a digest that covers the deployed firmware 1303 image, concatenated with the default erased value of any remaining 1304 space. 1306 Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) 1308 Implemented by: Payload Digests (Section 3.13) 1310 4.3.16. REQ.SEC.REPORTING: Secure Reporting 1312 Status reports from the device to any remote system SHOULD be 1313 performed over an authenticated, confidential channel in order to 1314 prevent modification or spoofing of the reports. 1316 Mitigates: THREAT.NET.MITM (Section 4.2.7) 1318 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 1320 Cryptographic keys for signing/authenticating manifests SHOULD be 1321 stored in a manner that is inaccessible to networked devices, for 1322 example in an HSM, or an air-gapped computer. This protects against 1323 an attacker obtaining the keys. 1325 Keys SHOULD be stored in a way that limits the risk of a legitimate, 1326 but compromised, entity (such as a server or developer computer) 1327 issuing signing requests. 1329 Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) 1331 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment 1333 Manifests SHOULD be parsed and examined prior to deployment to 1334 validate that their contents have not been modified during creation 1335 and signing. 1337 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1339 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted 1340 environment 1342 For high risk deployments, such as large numbers of devices or 1343 critical function devices, manifests SHOULD be constructed in an 1344 environment that is protected from interference, such as an air- 1345 gapped computer. Note that a networked computer connected to an HSM 1346 does not fulfill this requirement (see THREAT.MFST.MODIFICATION 1347 (Section 4.2.17)). 1349 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1351 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between check and 1352 use 1354 Both the manifest and any data extracted from it MUST be held 1355 immutable between its authenticity verification (time of check) and 1356 its use (time of use). To make this guarantee, the manifest MUST fit 1357 within an internal memory or a secure memory, such as encrypted 1358 memory. The recipient SHOULD defend the manifest from tampering by 1359 code or hardware resident in the recipient, for example other 1360 processes or debuggers. 1362 If an application requires that the manifest is verified before 1363 storing it, then this means the manifest MUST fit in RAM. 1365 Mitigates: THREAT.MFST.TOCTOU (Section 4.2.18) 1367 4.4. User Stories 1369 User stories provide expected use cases. These are used to feed into 1370 usability requirements. 1372 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 1374 As a Device Operator, I want to provide my devices with additional 1375 installation instructions so that I can keep process details out of 1376 my payload data. 1378 Some installation instructions might be: 1380 o Use a table of hashes to ensure that each block of the payload is 1381 validate before writing. 1383 o Do not report progress. 1385 o Pre-cache the update, but do not install. 1387 o Install the pre-cached update matching this manifest. 1389 o Install this update immediately, overriding any long-running 1390 tasks. 1392 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1394 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 1396 As a designer of a resource-constrained IoT device, I want bad 1397 updates to fail as early as possible to preserve battery life and 1398 limit consumed bandwidth. 1400 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1402 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 1404 As a Device Operator, I would like to be able to override the non- 1405 critical information in the manifest so that I can control my devices 1406 more precisely. The authority to override this information is 1407 provided via the installation of a limited trust anchor by another 1408 authority. 1410 Some examples of potentially overridable information: 1412 o URIs (Section 3.12): this allows the Device Operator to direct 1413 devices to their own infrastructure in order to reduce network 1414 load. 1416 o Conditions: this allows the Device Operator to pose additional 1417 constraints on the installation of the manifest. 1419 o Directives (Section 3.16): this allows the Device Operator to add 1420 more instructions such as time of installation. 1422 o Processing Steps (Section 3.9): If an intermediary performs an 1423 action on behalf of a device, it may need to override the 1424 processing steps. It is still possible for a device to verify the 1425 final content and the result of any processing step that specifies 1426 a digest. Some processing steps should be non-overridable. 1428 Satisfied by: USER_STORY.OVERRIDE (Section 4.4.3), 1429 REQ.USE.MFST.COMPONENT (Section 4.5.3) 1431 4.4.4. USER_STORY.COMPONENT: Component Update 1433 As a Device Operator, I want to divide my firmware into components, 1434 so that I can reduce the size of updates, make different parties 1435 responsible for different components, and divide my firmware into 1436 frequently updated and infrequently updated components. 1438 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1440 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations 1442 As a Device Operator, I want to ensure the quality of a firmware 1443 update before installing it, so that I can ensure interoperability of 1444 all devices in my product family. I want to restrict the ability to 1445 make changes to my devices to require my express approval. 1447 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), 1448 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1450 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1452 As a Device Operator, I want to be able to send multiple payload 1453 formats to suit the needs of my update, so that I can optimise the 1454 bandwidth used by my devices. 1456 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) 1458 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1459 Disclosures 1461 As a firmware author, I want to prevent confidential information from 1462 being disclosed during firmware updates. It is assumed that channel 1463 security or at-rest encryption is adequate to protect the manifest 1464 itself against information disclosure. 1466 Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1468 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 1469 Unknown Formats 1471 As a Device Operator, I want devices to determine whether they can 1472 process a payload prior to downloading it. 1474 In some cases, it may be desirable for a third party to perform some 1475 processing on behalf of a target. For this to occur, the third party 1476 MUST indicate what processing occurred and how to verify it against 1477 the Trust Provisioning Authority's intent. 1479 This amounts to overriding Processing Steps (Section 3.9) and 1480 Resource Indicator (Section 3.12). 1482 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED 1483 (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 1485 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 1486 Target Firmware 1488 As a Device Operator, I want to be able to target devices for updates 1489 based on their current firmware version, so that I can control which 1490 versions are replaced with a single manifest. 1492 Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7) 1494 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 1496 As a developer, I want to be able to sign two or more versions of my 1497 firmware in a single manifest so that I can use a very simple 1498 bootloader that chooses between two or more images that are executed 1499 in-place. 1501 Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8) 1503 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 1505 As a signer for both secure execution/boot and firmware deployment, I 1506 would like to use the same signed document for both tasks so that my 1507 data size is smaller, I can share common code, and I can reduce 1508 signature verifications. 1510 Satisfied by: REQ.USE.EXEC (Section 4.5.9) 1512 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 1514 As a developer of firmware for a run-from-RAM device, I would like to 1515 use compressed images and to indicate to the bootloader that I am 1516 using a compressed image in the manifest so that it can be used with 1517 secure execution/boot. 1519 Satisfied by: REQ.USE.LOAD (Section 4.5.10) 1521 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 1523 As an operator of devices on a constrained network, I would like the 1524 manifest to be able to include a small payload in the same packet so 1525 that I can reduce network traffic. 1527 Small payloads may include, for example, wrapped encryption keys, 1528 encoded configuration, public keys, [RFC8392] CBOR Web Tokens, or 1529 X.509 certificates. 1531 Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) 1533 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 1535 As a developer for constrained devices, I want a low complexity 1536 library for processing updates so that I can fit more application 1537 code on my device. 1539 Satisfied by: REQ.USE.PARSE (Section 4.5.12) 1541 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 1543 As a Device Operator that rotates delegated authority more often than 1544 delivering firmware updates, I would like to delegate a new authority 1545 when I deliver a firmware update so that I can accomplish both tasks 1546 in a single transmission. 1548 Satisfied by: REQ.USE.DELEGATION (Section 4.5.13) 1550 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 1552 As an operator of a constrained network, I would like devices on my 1553 network to be able to evaluate the suitability of an update prior to 1554 initiating any large download so that I can prevent unnecessary 1555 consumption of bandwidth. 1557 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1559 4.5. Usability Requirements 1561 The following usability requirements satisfy the user stories listed 1562 above. 1564 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 1566 It MUST be possible for a manifest author to place ALL information 1567 required to process an update in the manifest. 1569 For example: Information about which precursor image is required for 1570 a differential update MUST be placed in the manifest, not in the 1571 differential compression header. 1573 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1574 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1576 Implemented by: Additional installation instructions (Section 3.16) 1578 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1580 It MUST be possible to redirect payload fetches. This applies where 1581 two manifests are used in conjunction. For example, a Device 1582 Operator creates a manifest specifying a payload and signs it, and 1583 provides a URI for that payload. A Network Operator creates a second 1584 manifest, with a dependency on the first. They use this second 1585 manifest to override the URIs provided by the Device Operator, 1586 directing them into their own infrastructure instead. Some devices 1587 may provide this capability, while others may only look at canonical 1588 sources of firmware. For this to be possible, the device must fetch 1589 the payload, whereas a device that accepts payload pushes will ignore 1590 this feature. 1592 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1594 Implemented by: Aliases (Section 3.17) 1596 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 1598 It MUST be possible express the requirement to install one or more 1599 payloads from one or more authorities so that a multi-payload update 1600 can be described. This allows multiple parties with different 1601 permissions to collaborate in creating a single update for the IoT 1602 device, across multiple components. 1604 This requirement effectively means that it must be possible to 1605 construct a tree of manifests on a multi-image target. 1607 In order to enable devices with a heterogeneous storage architecture, 1608 the manifest must enable specification of both storage system and the 1609 storage location within that storage system. 1611 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1612 (Section 4.4.4) 1614 Implemented by Manifest Element: Dependencies, StorageIdentifier, 1615 ComponentIdentifier 1617 4.5.3.1. Example 1: Multiple Microcontrollers 1619 An IoT device with multiple microcontrollers in the same physical 1620 device (HeSA) will likely require multiple payloads with different 1621 component identifiers. 1623 4.5.3.2. Example 2: Code and Configuration 1625 A firmware image can be divided into two payloads: code and 1626 configuration. These payloads may require authorizations from 1627 different actors in order to install (see REQ.SEC.RIGHTS 1628 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1629 structure means that multiple manifests may be required, with a 1630 dependency structure between them. 1632 4.5.3.3. Example 3: Multiple Software Modules 1634 A firmware image can be divided into multiple functional blocks for 1635 separate testing and distribution. This means that code would need 1636 to be distributed in multiple payloads. For example, this might be 1637 desirable in order to ensure that common code between devices is 1638 identical in order to reduce distribution bandwidth. 1640 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1642 It MUST be possible to authenticate a manifest multiple times so that 1643 authorisations from multiple parties with different permissions can 1644 be required in order to authorise installation of a manifest. 1646 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1648 Implemented by: Signature (Section 3.15) 1650 4.5.5. REQ.USE.IMG.FORMAT: Format Usability 1652 The manifest serialisation MUST accommodate any payload format that 1653 an Operator wishes to use. This enables the recipient to detect 1654 which format the Operator has chosen. Some examples of payload 1655 format are: 1657 o Binary 1659 o Executable and Linkable Format (ELF) 1661 o Differential 1663 o Compressed 1664 o Packed configuration 1666 o Intel HEX 1668 o Motorola S-Record 1670 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1671 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1673 Implemented by: Payload Format (Section 3.8) 1675 4.5.6. REQ.USE.IMG.NESTED: Nested Formats 1677 The manifest serialisation MUST accommodate nested formats, 1678 announcing to the target device all the nesting steps and any 1679 parameters used by those steps. 1681 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1683 Implemented by: Processing Steps (Section 3.9) 1685 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 1687 The manifest serialisation MUST provide a method to specify multiple 1688 version numbers of firmware to which the manifest applies, either 1689 with a list or with range matching. 1691 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1693 Implemented by: Required Image Version List (Section 3.6) 1695 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 1697 The manifest serialisation MUST provide a mechanism to list multiple 1698 equivalent payloads by Execute-In-Place Installation Address, 1699 including the payload digest and, optionally, payload URIs. 1701 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1703 Implemented by: XIP Address (Section 3.20) 1705 4.5.9. REQ.USE.EXEC: Executable Manifest 1707 It MUST be possible to describe an executable system with a manifest 1708 on both Execute-In-Place microcontrollers and on complex operating 1709 systems. This requires the manifest to specify the digest of each 1710 statically linked dependency. In addition, the manifest 1711 serialisation MUST be able to express metadata, such as a kernel 1712 command-line, used by any loader or bootloader. 1714 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1716 Implemented by: Run-time metadata (Section 3.22) 1718 4.5.10. REQ.USE.LOAD: Load-Time Information 1720 It MUST be possible to specify additional metadata for load time 1721 processing of a payload, such as cryptographic information, load- 1722 address, and compression algorithm. 1724 N.B. load comes before exec/boot. 1726 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1728 Implemented by: Load-time metadata (Section 3.21) 1730 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure 1732 It MUST be possible to place a payload in the same structure as the 1733 manifest. This MAY place the payload in the same packet as the 1734 manifest. 1736 Integrated payloads may include, for example, wrapped encryption 1737 keys, configuration data, public keys, CBOR Web Tokens [RFC8392], or 1738 X.509 certificates. 1740 When an integrated payload is provided, this increases the size of 1741 the manifest. Manifest size can cause several processing and storage 1742 concerns that require careful consideration. The payload can prevent 1743 the whole manifest from being contained in a single network packet, 1744 which can cause fragmentation and the loss of portions of the 1745 manifest in lossy networks. This causes the need for reassembly and 1746 retransmission logic. The manifest must be held immutable between 1747 verification and processing (see REQ.SEC.MFST.CONST 1748 (Section 4.3.20)), so a larger manifest will consume more memory with 1749 immutability guarantees, for example internal RAM or NVRAM, or 1750 external secure memory. If the manifest exceeds the available 1751 immutable memory, then it must be processed modularly, evaluating 1752 each of: delegation chains, the security container, and the actual 1753 manifest, which includes verifying the integrated payload. If the 1754 security model calls for downloading the manifest and validating it 1755 before storing to NVRAM in order to prevent wear to NVRAM and energy 1756 expenditure in NVRAM, then either increasing memory allocated to 1757 manifest storage or modular processing of the received manifest may 1758 be required. While the manifest has been organised to enable this 1759 type of processing, it creates additional complexity in the parser. 1760 If the manifest is stored in NVRAM prior to processing, the 1761 integrated payload may cause the manifest to exceed the available 1762 storage. Because the manifest is received prior to validation of 1763 applicability, authority, or correctness, integrated payloads cause 1764 the recipient to expend network bandwidth and energy that may not be 1765 required if the manifest is discarded and these costs vary with the 1766 size of the integrated payload. 1768 See also: REQ.SEC.MFST.CONST (Section 4.3.20). 1770 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1772 Implemented by: Payload (Section 3.23) 1774 4.5.12. REQ.USE.PARSE: Simple Parsing 1776 The structure of the manifest MUST be simple to parse, without need 1777 for a general-purpose parser. 1779 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1781 Implemented by: N/A 1783 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1785 Any serialisation MUST enable the delivery of a key claim with, but 1786 not authenticated by, a manifest. This key claim delivers a new key 1787 with which the recipient can verify the manifest. 1789 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1791 Implemented by: Key Claims (Section 3.24) 1793 5. IANA Considerations 1795 This document does not require any actions by IANA. 1797 6. Acknowledgements 1799 We would like to thank our working group chairs, Dave Thaler, Russ 1800 Housley and David Waltermire, for their review comments and their 1801 support. 1803 We would like to thank the participants of the 2018 Berlin SUIT 1804 Hackathon and the June 2018 virtual design team meetings for their 1805 discussion input. In particular, we would like to thank Koen 1806 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1807 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1808 Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias 1809 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1810 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1811 Gharout, and Milen Stoychev. 1813 We would like to thank those who contributed to the development of 1814 this information model. In particular, we would like to thank 1815 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary 1816 Thomson. 1818 7. References 1820 7.1. Normative References 1822 [I-D.ietf-suit-architecture] 1823 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 1824 Firmware Update Architecture for Internet of Things", 1825 draft-ietf-suit-architecture-11 (work in progress), May 1826 2020. 1828 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1829 Requirement Levels", BCP 14, RFC 2119, 1830 DOI 10.17487/RFC2119, March 1997, 1831 . 1833 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1834 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1835 DOI 10.17487/RFC4122, July 2005, 1836 . 1838 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1839 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1840 May 2017, . 1842 7.2. Informative References 1844 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1845 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1846 . 1848 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1849 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1850 . 1852 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1853 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1854 May 2018, . 1856 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1857 . 1860 Authors' Addresses 1862 Brendan Moran 1863 Arm Limited 1865 EMail: Brendan.Moran@arm.com 1867 Hannes Tschofenig 1868 Arm Limited 1870 EMail: hannes.tschofenig@gmx.net 1872 Henk Birkholz 1873 Fraunhofer SIT 1875 EMail: henk.birkholz@sit.fraunhofer.de