idnits 2.17.1 draft-ietf-suit-information-model-07.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 02, 2020) is 1423 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-11 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 4, 2020 H. Birkholz 6 Fraunhofer SIT 7 June 02, 2020 9 An Information Model for Firmware Updates in IoT Devices 10 draft-ietf-suit-information-model-07 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 4, 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 . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . 12 85 3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13 86 3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13 87 3.16. Manifest Element: Additional installation instructions . 13 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 . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . 17 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 . . . . . . 21 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 . . . . 22 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 . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . 25 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 . . 27 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 . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . 32 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 . . . . . . . . . . . . . . . . . . . . . . . 39 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 be 227 implemented and used. Elements marked as RECOMMENDED provide 228 important security or usability properties that are needed on most 229 devices. Elements marked as OPTIONAL enable security or usability 230 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 in order to allow devices to identify the 264 version of the manifest data model that is in use. 266 3.2. Manifest Element: Monotonic Sequence Number 268 A monotonically increasing sequence number. For convenience, the 269 monotonic sequence number MAY be a UTC timestamp. This allows global 270 synchronisation of sequence numbers without any additional 271 management. This number MUST be easily accessible so that code 272 choosing one out of several manifests can choose which is the latest. 274 This element is REQUIRED and is necessary to prevent malicious actors 275 from reverting a firmware update against the policies of the relevant 276 authority. 278 Implements: REQ.SEC.SEQUENCE (Section 4.3.1) 280 3.3. Manifest Element: Vendor ID 282 Vendor IDs must be unique. This is to prevent similarly, or 283 identically named entities from different geographic regions from 284 colliding in their customer's infrastructure. Recommended practice 285 is to use [RFC4122] version 5 UUIDs with the vendor's domain name and 286 the DNS name space ID. Other options include type 1 and type 4 287 UUIDs. 289 Vendor ID is not intended to be a human-readable element. It is 290 intended for binary match/mismatch comparison only. 292 The use of a Vendor ID is RECOMMENDED. It helps to distinguish 293 between identically named products from different vendors. 295 Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), 296 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 298 3.3.1. Example: Domain Name-based UUIDs 300 Vendor A creates a UUID based on their domain name: 302 vendorId = UUID5(DNS, "vendor-a.com") 304 Because the DNS infrastructure prevents multiple registrations of the 305 same domain name, this UUID is (with very high probability) 306 guaranteed to be unique. Because the domain name is known, this UUID 307 is reproducible. Type 1 and type 4 UUIDs produce similar guarantees 308 of uniqueness, but not reproducibility. 310 This approach creates a contention when a vendor changes its name or 311 relinquishes control of a domain name. In this scenario, it is 312 possible that another vendor would start using that same domain name. 313 However, this UUID is not proof of identity; a device's trust in a 314 vendor must be anchored in a cryptographic key, not a UUID. 316 3.4. Manifest Element: Class ID 318 A device "Class" is a set of different device types that can accept 319 the same firmware update without modification. Class IDs MUST be 320 unique within the scope of a Vendor ID. This is to prevent 321 similarly, or identically named devices colliding in their customer's 322 infrastructure. 324 Recommended practice is to use [RFC4122] version 5 UUIDs with as much 325 information as necessary to define firmware compatibility. Possible 326 information used to derive the class UUID includes: 328 o model name or number 330 o hardware revision 332 o runtime library version 334 o bootloader version 336 o ROM revision 337 o silicon batch number 339 The Class Identifier UUID SHOULD use the Vendor ID as the name space 340 ID. Other options include version 1 and 4 UUIDs. Classes MAY be 341 more granular than is required to identify firmware compatibility. 342 Classes MUST NOT be less granular than is required to identify 343 firmware compatibility. Devices MAY have multiple Class IDs. 345 Class ID is not intended to be a human-readable element. It is 346 intended for binary match/mismatch comparison only. 348 The use of Class ID is RECOMMENDED. It allows devices to determine 349 applicability of a firmware in an unambiguous way. 351 If Class ID is not implemented, then each logical device class MUST 352 use a unique trust anchor for authorisation. 354 Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), 355 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 357 3.4.1. Example 1: Different Classes 359 Vendor A creates product Z and product Y. The firmware images of 360 products Z and Y are not interchangeable. Vendor A creates UUIDs as 361 follows: 363 o vendorId = UUID5(DNS, "vendor-a.com") 365 o ZclassId = UUID5(vendorId, "Product Z") 367 o YclassId = UUID5(vendorId, "Product Y") 369 This ensures that Vendor A's Product Z cannot install firmware for 370 Product Y and Product Y cannot install firmware for Product Z. 372 3.4.2. Example 2: Upgrading Class ID 374 Vendor A creates product X. Later, Vendor A adds a new feature to 375 product X, creating product X v2. Product X requires a firmware 376 update to work with firmware intended for product X v2. 378 Vendor A creates UUIDs as follows: 380 o vendorId = UUID5(DNS, "vendor-a.com") 382 o XclassId = UUID5(vendorId, "Product X") 384 o Xv2classId = UUID5(vendorId, "Product X v2") 385 When product X receives the firmware update necessary to be 386 compatible with product X v2, part of the firmware update changes the 387 class ID to Xv2classId. 389 3.4.3. Example 3: Shared Functionality 391 Vendor A produces two products, product X and product Y. These 392 components share a common core (such as an operating system), but 393 have different applications. The common core and the applications 394 can be updated independently. To enable X and Y to receive the same 395 common core update, they require the same class ID. To ensure that 396 only product X receives application X and only product Y receives 397 application Y, product X and product Y must have different class IDs. 398 The vendor creates Class IDs as follows: 400 o vendorId = UUID5(DNS, "vendor-a.com") 402 o XclassId = UUID5(vendorId, "Product X") 404 o YclassId = UUID5(vendorId, "Product Y") 406 o CommonClassId = UUID5(vendorId, "common core") 408 Product X matches against both XclassId and CommonClassId. Product Y 409 matches against both YclassId and CommonClassId. 411 3.4.4. Example 4: White-labelling 413 Vendor A creates a product A and its firmware. Vendor B sells the 414 product under its own name as Product B with some customised 415 configuration. The vendors create the Class IDs as follows: 417 o vendorIdA = UUID5(DNS, "vendor-a.com") 419 o classIdA = UUID5(vendorIdA, "Product A-Unlabelled") 421 o vendorIdB = UUID5(DNS, "vendor-b.com") 423 o classIdB = UUID5(vendorIdB, "Product B") 425 The product will match against each of these class IDs. If Vendor A 426 and Vendor B provide different components for the device, the 427 implementor MAY choose to make ID matching scoped to each component. 428 Then, the vendorIdA, classIdA match the component ID supplied by 429 Vendor A, and the vendorIdB, classIdB match the component ID supplied 430 by Vendor B. 432 3.5. Manifest Element: Precursor Image Digest Condition 434 When a precursor image is required by the payload format, a precursor 435 image digest condition MUST be present in the conditions list. The 436 precursor image may be installed or stored as a candidate. 438 This element is OPTIONAL to implement. 440 Enables feature: differential updates. 442 Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 444 3.6. Manifest Element: Required Image Version List 446 When a payload applies to multiple versions of a firmware, the 447 required image version list specifies which versions must be present 448 for the update to be applied. This allows the update author to 449 target specific versions of firmware for an update, while excluding 450 those to which it should not be applied. 452 Where an update can only be applied over specific predecessor 453 versions, that version MUST be specified by the Required Image 454 Version List. 456 This element is OPTIONAL. 458 Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) 460 3.7. Manifest Element: Expiration Time 462 This element tells a device the time at which the manifest expires 463 and should no longer be used. This is only usable in conjunction 464 with a secure source of time. 466 This element is OPTIONAL and may enable user stories where a secure 467 source of time is provided and firmware is intended to expire 468 predictably. 470 Implements: REQ.SEC.EXP (Section 4.3.3) 472 3.8. Manifest Element: Payload Format 474 The format of the payload MUST be indicated to devices in an 475 unambiguous way. This element provides a mechanism to describe the 476 payload format, within the signed metadata. 478 This element is REQUIRED and MUST be present to enable devices to 479 decode payloads correctly. 481 Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT 482 (Section 4.5.5) 484 3.9. Manifest Element: Processing Steps 486 A representation of the Processing Steps required to decode a 487 payload. The representation MUST describe which algorithm(s) is used 488 and any additional parameters required by the algorithm(s). The 489 representation MAY group Processing Steps together in predefined 490 combinations. 492 A Processing Step MAY indicate the expected digest of the payload 493 after the processing is complete. 495 Processing steps are RECOMMENDED to implement. 497 Enables feature: Encrypted, compressed, packed formats 499 Implements: REQ.USE.IMG.NESTED (Section 4.5.6) 501 3.10. Manifest Element: Storage Location 503 This element tells the device where to store a payload within a given 504 component. The device can use this to establish which permissions 505 are necessary and the physical storage location to use. 507 This element is REQUIRED and MUST be present to enable devices to 508 store payloads to the correct location. 510 Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 512 3.10.1. Example 1: Two Storage Locations 514 A device supports two components: an OS and an application. These 515 components can be updated independently, expressing dependencies to 516 ensure compatibility between the components. The Author chooses two 517 storage identifiers: 519 o "OS" 521 o "APP" 523 3.10.2. Example 2: File System 525 A device supports a full filesystem. The Author chooses to use the 526 storage identifier as the path at which to install the payload. The 527 payload may be a tarball, in which case, it unpacks the tarball into 528 the specified path. 530 3.10.3. Example 3: Flash Memory 532 A device supports flash memory. The Author chooses to make the 533 storage identifier the offset where the image should be written. 535 3.11. Manifest Element: Component Identifier 537 In a heterogeneous storage architecture, a storage identifier is 538 insufficient to identify where and how to store a payload. To 539 resolve this, a component identifier indicates which part of the 540 storage architecture is targeted by the payload. In a homogeneous 541 storage architecture, this element is unnecessary. 543 This element is OPTIONAL and only necessary in heterogeneous storage 544 architecture devices. 546 N.B. A manifest format MAY choose to combine Component Identifier 547 and Storage Location (Section 3.10) 549 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 551 3.12. Manifest Element: Resource Indicator 553 This element provides the information required for the device to 554 acquire the resource. This can be encoded in several ways: 556 o One URI 558 o A list of URIs 560 o A prioritised list of URIs 562 o A list of signed URIs 564 This element is OPTIONAL and only needed when the target device does 565 not intrinsically know where to find the payload. 567 N.B. Devices will typically require URIs. 569 Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 571 3.13. Manifest Element: Payload Digests 573 This element contains one or more digests of one or more payloads. 574 This allows the target device to ensure authenticity of the 575 payload(s). A manifest format MUST provide a mechanism to select one 576 payload from a list based on system parameters, such as Execute-In- 577 Place Installation Address. 579 This element is REQUIRED to implement and fundamentally necessary to 580 ensure the authenticity and integrity of the payload. Support for 581 more than one digest is OPTIONAL to implement in a recipient device. 583 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT 584 (Section 4.5.8) 586 3.14. Manifest Element: Size 588 The size of the payload in bytes. 590 Variable-size storage locations MUST be set to exactly the size 591 listed in this element. 593 This element is REQUIRED and informs the target device how big of a 594 payload to expect. Without it, devices are exposed to some classes 595 of denial of service attack. 597 Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) 599 3.15. Manifest Element: Signature 601 This is not strictly a manifest element. Instead, the manifest is 602 wrapped by a standardised authentication container. The 603 authentication container MUST support multiple signers and multiple 604 signature algorithms. 606 This element is REQUIRED in non-dependency manifests and represents 607 the foundation of all security properties of the manifest. Manifests 608 which are included as dependencies by another manifest SHOULD include 609 a signature so that the recipient can distinguish between different 610 actors with different permissions. 612 A manifest MUST NOT be considered authenticated by channel security 613 even if it contains only channel information (such as URIs). If the 614 authenticated remote or channel were compromised, the threat actor 615 could induce recipients to query traffic over any accessible network. 616 Lightweight authentication with pre-existing relationships SHOULD be 617 done with MAC. 619 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS 620 (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) 622 3.16. Manifest Element: Additional installation instructions 624 Instructions that the device should execute when processing the 625 manifest. This information is distinct from the information 626 necessary to process a payload. Additional installation instructions 627 include information such as update timing (for example, install only 628 on Sunday, at 0200), procedural considerations (for example, shut 629 down the equipment under control before executing the update), pre- 630 and post-installation steps (for example, run a script). 632 This element is OPTIONAL. 634 Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 636 3.17. Manifest Element: Aliases 638 A mechanism for a manifest to augment or replace URIs or URI lists 639 defined by one or more of its dependencies. 641 This element is OPTIONAL and enables some user stories. 643 Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 645 3.18. Manifest Element: Dependencies 647 A list of other manifests that are required by the current manifest. 648 Manifests are identified an unambiguous way, such as a digest. 650 This element is REQUIRED to use in deployments that include both 651 multiple authorities and multiple payloads. 653 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 655 3.19. Manifest Element: Encryption Wrapper 657 Encrypting firmware images requires symmetric content encryption 658 keys. The encryption wrapper provides the information needed for a 659 device to obtain or locate a key that it uses to decrypt the 660 firmware. This MAY be included in a decryption step contained in 661 Processing Steps (Section 3.9). 663 This element is REQUIRED to use for encrypted payloads, 665 Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 667 3.20. Manifest Element: XIP Address 669 In order to support XIP systems with multiple possible base 670 addresses, it is necessary to specify which address the payload is 671 linked for. 673 For example a microcontroller may have a simple bootloader that 674 chooses one of two images to boot. That microcontroller then needs 675 to choose one of two firmware images to install, based on which of 676 its two images is older. 678 Implements: REQ.USE.IMG.SELECT (Section 4.5.8) 680 3.21. Manifest Element: Load-time metadata 682 Load-time metadata provides the device with information that it needs 683 in order to load one or more images. This is effectively a copy 684 operation from the permanent storage location of an image into the 685 active use location of that image. The metadata contains the source 686 and destination of the image as well as any operations that are 687 performed on the image. 689 Implements: REQ.USE.LOAD (Section 4.5.10) 691 3.22. Manifest Element: Run-time metadata 693 Run-time metadata provides the device with any extra information 694 needed to boot the device. This may include information such as the 695 entry-point of an XIP image or the kernel command-line of a Linux 696 image. 698 Implements: REQ.USE.EXEC (Section 4.5.9) 700 3.23. Manifest Element: Payload 702 The Payload element provides a recipient device with the whole 703 payload, contained within the manifest superstructure. This enables 704 the manifest and payload to be delivered simultaneously. 706 Implements: REQ.USE.PAYLOAD (Section 4.5.11) 708 3.24. Manifest Element: Key Claims 710 The Key Claims element is not authenticated by the Signature 711 (Section 3.15), instead, it provides a chain of key delegations (or 712 references to them) for the device to follow in order to verify the 713 key that authenticated the manifest using a trusted key. 715 Implements: REQ.USE.DELEGATION (Section 4.5.13) 717 4. Security Considerations 719 The following sub-sections describe the threat model, user stories, 720 security requirements, and usability requirements. This section also 721 provides the motivations for each of the manifest information 722 elements. 724 4.1. Threat Model 726 The following sub-sections aim to provide information about the 727 threats that were considered, the security requirements that are 728 derived from those threats and the fields that permit implementation 729 of the security requirements. This model uses the S.T.R.I.D.E. 730 [STRIDE] approach. Each threat is classified according to: 732 o Spoofing identity 734 o Tampering with data 736 o Repudiation 738 o Information disclosure 740 o Denial of service 742 o Elevation of privilege 744 This threat model only covers elements related to the transport of 745 firmware updates. It explicitly does not cover threats outside of 746 the transport of firmware updates. For example, threats to an IoT 747 device due to physical access are out of scope. 749 4.2. Threat Descriptions 751 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 753 Classification: Elevation of Privilege 755 An attacker sends an old, but valid manifest with an old, but valid 756 firmware image to a device. If there is a known vulnerability in the 757 provided firmware image, this may allow an attacker to exploit the 758 vulnerability and gain control of the device. 760 Threat Escalation: If the attacker is able to exploit the known 761 vulnerability, then this threat can be escalated to ALL TYPES. 763 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 765 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old Firmware 767 Classification: Elevation of Privilege 769 An attacker targets a device that has been offline for a long time 770 and runs an old firmware version. The attacker sends an old, but 771 valid manifest to a device with an old, but valid firmware image. 773 The attacker-provided firmware is newer than the installed one but 774 older than the most recently available firmware. If there is a known 775 vulnerability in the provided firmware image then this may allow an 776 attacker to gain control of a device. Because the device has been 777 offline for a long time, it is unaware of any new updates. As such 778 it will treat the old manifest as the most current. 780 Threat Escalation: If the attacker is able to exploit the known 781 vulnerability, then this threat can be escalated to ALL TYPES. 783 Mitigated by: REQ.SEC.EXP (Section 4.3.3) 785 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 787 Classification: Denial of Service 789 An attacker sends a valid firmware image, for the wrong type of 790 device, signed by an actor with firmware installation permission on 791 both types of device. The firmware is verified by the device 792 positively because it is signed by an actor with the appropriate 793 permission. This could have wide-ranging consequences. For devices 794 that are similar, it could cause minor breakage, or expose security 795 vulnerabilities. For devices that are very different, it is likely 796 to render devices inoperable. 798 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 800 4.2.3.1. Example: 802 Suppose that two vendors, Vendor A and Vendor B, adopt the same trade 803 name in different geographic regions, and they both make products 804 with the same names, or product name matching is not used. This 805 causes firmware from Vendor A to match devices from Vendor B. 807 If the vendors are the firmware authorities, then devices from Vendor 808 A will reject images signed by Vendor B since they use different 809 credentials. However, if both devices trust the same Author, then, 810 devices from Vendor A could install firmware intended for devices 811 from Vendor B. 813 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 814 payload 816 Classification: Denial of Service 818 If a device misinterprets the format of the firmware image, it may 819 cause a device to install a firmware image incorrectly. An 820 incorrectly installed firmware image would likely cause the device to 821 stop functioning. 823 Threat Escalation: An attacker that can cause a device to 824 misinterpret the received firmware image may gain elevation of 825 privilege and potentially expand this to all types of threat. 827 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 829 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 830 the wrong location 832 Classification: Denial of Service 834 If a device installs a firmware image to the wrong location on the 835 device, then it is likely to break. For example, a firmware image 836 installed as an application could cause a device and/or an 837 application to stop functioning. 839 Threat Escalation: An attacker that can cause a device to 840 misinterpret the received code may gain elevation of privilege and 841 potentially expand this to all types of threat. 843 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.5) 845 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 847 Classification: Denial of Service 849 If a device does not know where to obtain the payload for an update, 850 it may be redirected to an attacker's server. This would allow an 851 attacker to provide broken payloads to devices. 853 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 855 4.2.7. THREAT.NET.MITM: Traffic interception 857 Classification: Spoofing Identity, Tampering with Data 859 An attacker intercepts all traffic to and from a device. The 860 attacker can monitor or modify any data sent to or received from the 861 device. This can take the form of: manifests, payloads, status 862 reports, and capability reports being modified or not delivered to 863 the intended recipient. It can also take the form of analysis of 864 data sent to or from the device, either in content, size, or 865 frequency. 867 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), 868 REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC 869 (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), 870 REQ.SEC.REPORTING (Section 4.3.16) 872 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 874 Classification: Elevation of Privilege 876 An attacker replaces a newly downloaded firmware after a device 877 finishes verifying a manifest. This could cause the device to 878 execute the attacker's code. This attack likely requires physical 879 access to the device. However, it is possible that this attack is 880 carried out in combination with another threat that allows remote 881 execution. This is a typical Time Of Check/Time Of Use threat. 883 Threat Escalation: If the attacker is able to exploit a known 884 vulnerability, or if the attacker can supply their own firmware, then 885 this threat can be escalated to ALL TYPES. 887 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 889 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 891 Classification: Elevation of Privilege / All Types 893 If an attacker can install their firmware on a device, by 894 manipulating either payload or metadata, then they have complete 895 control of the device. 897 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 899 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 901 Classification: Denial of Service / All Types 903 An attacker sends a valid, current manifest to a device that has an 904 unexpected precursor image. If a payload format requires a precursor 905 image (for example, delta updates) and that precursor image is not 906 available on the target device, it could cause the update to break. 908 An attacker that can cause a device to install a payload against the 909 wrong precursor image could gain elevation of privilege and 910 potentially expand this to all types of threat. However, it is 911 unlikely that a valid differential update applied to an incorrect 912 precursor would result in a functional, but vulnerable firmware. 914 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 916 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 918 Classification: Denial of Service, Elevation of Privilege 920 This threat can appear in several ways, however it is ultimately 921 about ensuring that devices retain the behaviour required by their 922 Owner, Device Operator, or Network Operator. The owner or operator 923 of a device typically requires that the device maintain certain 924 features, functions, capabilities, behaviours, or interoperability 925 constraints (more generally, behaviour). If these requirements are 926 broken, then a device will not fulfill its purpose. Therefore, if 927 any party other than the device's Owner or the Owner's contracted 928 Device Operator has the ability to modify device behaviour without 929 approval, then this constitutes an elevation of privilege. 931 Similarly, a network operator may require that devices behave in a 932 particular way in order to maintain the integrity of the network. If 933 devices behaviour on a network can be modified without the approval 934 of the network operator, then this constitutes an elevation of 935 privilege with respect to the network. 937 For example, if the owner of a device has purchased that device 938 because of Features A, B, and C, and a firmware update is issued by 939 the manufacturer, which removes Feature A, then the device may not 940 fulfill the owner's requirements any more. In certain circumstances, 941 this can cause significantly greater threats. Suppose that Feature A 942 is used to implement a safety-critical system, whether the 943 manufacturer intended this behaviour or not. When unapproved 944 firmware is installed, the system may become unsafe. 946 In a second example, the owner or operator of a system of two or more 947 interoperating devices needs to approve firmware for their system in 948 order to ensure interoperability with other devices in the system. 949 If the firmware is not qualified, the system as a whole may not work. 950 Therefore, if a device installs firmware without the approval of the 951 device owner or operator, this is a threat to devices or the system 952 as a whole. 954 Similarly, the operator of a network may need to approve firmware for 955 devices attached to the network in order to ensure favourable 956 operating conditions within the network. If the firmware is not 957 qualified, it may degrade the performance of the network. Therefore, 958 if a device installs firmware without the approval of the network 959 operator, this is a threat to the network itself. 961 Threat Escalation: If the firmware expects configuration that is 962 present in devices deployed in Network A, but not in devices deployed 963 in Network B, then the device may experience degraded security, 964 leading to threats of All Types. 966 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 967 (Section 4.3.13) 969 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 970 Operator 972 In this example, assume that Device Operators expect the rights to 973 create firmware but that Network Operators expect the rights to 974 qualify firmware as fit-for-purpose on their networks. Additionally, 975 assume that Device Operators manage devices that can be deployed on 976 any network, including Network A and B in our example. 978 An attacker may obtain a manifest for a device on Network A. Then, 979 this attacker sends that manifest to a device on Network B. Because 980 Network A and Network B are under control of different Operators, and 981 the firmware for a device on Network A has not been qualified to be 982 deployed on Network B, the target device on Network B is now in 983 violation of the Operator B's policy and may be disabled by this 984 unqualified, but signed firmware. 986 This is a denial of service because it can render devices inoperable. 987 This is an elevation of privilege because it allows the attacker to 988 make installation decisions that should be made by the Operator. 990 4.2.11.2. Example 2: Single Network Operator with Multiple Device 991 Operators 993 Multiple devices that interoperate are used on the same network and 994 communicate with each other. Some devices are manufactured and 995 managed by Device Operator A and other devices by Device Operator B. 996 A new firmware is released by Device Operator A that breaks 997 compatibility with devices from Device Operator B. An attacker sends 998 the new firmware to the devices managed by Device Operator A without 999 approval of the Network Operator. This breaks the behaviour of the 1000 larger system causing denial of service and possibly other threats. 1001 Where the network is a distributed SCADA system, this could cause 1002 misbehaviour of the process that is under control. 1004 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 1005 for Vulnerability Analysis 1007 Classification: All Types 1009 An attacker wants to mount an attack on an IoT device. To prepare 1010 the attack he or she retrieves the provided firmware image and 1011 performs reverse engineering of the firmware image to analyze it for 1012 specific vulnerabilities. 1014 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1016 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 1018 Classification: Elevation of Privilege 1020 An authorised actor, but not the Author, uses an override mechanism 1021 (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information 1022 element in a manifest signed by the Author. For example, if the 1023 authorised actor overrides the digest and URI of the payload, the 1024 actor can replace the entire payload with a payload of their choice. 1026 Threat Escalation: By overriding elements such as payload 1027 installation instructions or firmware digest, this threat can be 1028 escalated to all types. 1030 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1032 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 1034 Classification: Information Disclosure 1036 A third party may be able to extract sensitive information from the 1037 manifest. 1039 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 1041 4.2.15. THREAT.IMG.EXTRA: Extra data after image 1043 Classification: All Types 1045 If a third party modifies the image so that it contains extra code 1046 after a valid, authentic image, that third party can then use their 1047 own code in order to make better use of an existing vulnerability. 1049 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 1051 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 1053 Classification: All Types 1055 If a third party obtains a key or even indirect access to a key, for 1056 example in an HSM, then they can perform the same actions as the 1057 legitimate owner of the key. If the key is trusted for firmware 1058 update, then the third party can perform firmware updates as though 1059 they were the legitimate owner of the key. 1061 For example, if manifest signing is performed on a server connected 1062 to the internet, an attacker may compromise the server and then be 1063 able to sign manifests, even if the keys for manifest signing are 1064 held in an HSM that is accessed by the server. 1066 Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17) 1068 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 1069 prior to signing 1071 Classification: All Types 1073 If an attacker can alter a manifest or payload before it is signed, 1074 they can perform all the same actions as the manifest author. This 1075 allows the attacker to deploy firmware updates to any devices that 1076 trust the manifest author. If an attacker can modify the code of a 1077 payload before the corresponding manifest is created, they can insert 1078 their own code. If an attacker can modify the manifest before it is 1079 signed, they can redirect the manifest to their own payload. 1081 For example, the attacker deploys malware to the developer's computer 1082 or signing service that watches manifest creation activities and 1083 inserts code into any binary that is referenced by a manifest. 1085 For example, the attacker deploys malware to the developer's computer 1086 or signing service that replaces the referenced binary (digest) and 1087 URI with the attacker's binary (digest) and URI. 1089 Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18), 1090 REQ.SEC.MFST.TRUSTED (Section 4.3.19) 1092 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 1093 authentication and use 1095 Classification: All Types 1097 If an attacker can modify a manifest after it is authenticated (Time 1098 Of Check) but before it is used (Time Of Use), then the attacker can 1099 place any content whatsoever in the manifest. 1101 Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.20) 1103 4.3. Security Requirements 1105 The security requirements here are a set of policies that mitigate 1106 the threats described in Section 4.1. 1108 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 1110 Only an actor with firmware installation authority is permitted to 1111 decide when device firmware can be installed. To enforce this rule, 1112 manifests MUST contain monotonically increasing sequence numbers. 1113 Manifests MAY use UTC epoch timestamps to coordinate monotonically 1114 increasing sequence numbers across many actors in many locations. If 1115 UTC epoch timestamps are used, they MUST NOT be treated as times, 1116 they MUST be treated only as sequence numbers. Devices MUST reject 1117 manifests with sequence numbers smaller than any onboard sequence 1118 number. 1120 Note: This is not a firmware version. It is a manifest sequence 1121 number. A firmware version may be rolled back by creating a new 1122 manifest for the old firmware version with a later sequence number. 1124 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 1126 Implemented by: Monotonic Sequence Number (Section 3.2) 1128 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1130 Devices MUST only apply firmware that is intended for them. Devices 1131 MUST know with fine granularity that a given update applies to their 1132 vendor, model, hardware revision, software revision. Human-readable 1133 identifiers are often error-prone in this regard, so unique 1134 identifiers SHOULD be used. 1136 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1138 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1139 (Section 3.4) 1141 4.3.3. REQ.SEC.EXP: Expiration Time 1143 A firmware manifest MAY expire after a given time. Devices MAY 1144 provide a secure clock (local or remote). If a secure clock is 1145 provided and the Firmware manifest has an expiration timestamp, the 1146 device MUST reject the manifest if current time is later than the 1147 expiration time. 1149 Mitigates: THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2) 1150 Implemented by: Expiration Time (Section 3.7) 1152 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1154 The authenticity of an update MUST be demonstrable. Typically, this 1155 means that updates must be digitally authenticated. Because the 1156 manifest contains information about how to install the update, the 1157 manifest's authenticity MUST also be demonstrable. To reduce the 1158 overhead required for validation, the manifest contains the digest of 1159 the firmware image, rather than a second digital signature. The 1160 authenticity of the manifest can be verified with a digital signature 1161 or Message Authentication Code. The authenticity of the firmware 1162 image is tied to the manifest by the use of a digest of the firmware 1163 image. 1165 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.MITM 1166 (Section 4.2.7) 1168 Implemented by: Signature (Section 3.15), Payload Digest 1169 (Section 3.13) 1171 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1173 The type of payload (which may be independent of format) MUST be 1174 authenticated. For example, the target must know whether the payload 1175 is XIP firmware, a loadable module, or configuration data. 1177 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1179 Implemented by: Payload Format (Section 3.8), Storage Location 1180 (Section 3.10) 1182 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1183 Location 1185 The location on the target where the payload is to be stored MUST be 1186 authenticated. 1188 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) 1292 Implemented by: External Encryption Wrapper / Transport Security 1294 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 1296 The digest SHOULD cover all available space in a fixed-size storage 1297 location. Variable-size storage locations MUST be restricted to 1298 exactly the size of deployed payload. This prevents any data from 1299 being distributed without being covered by the digest. For example, 1300 XIP microcontrollers typically have fixed-size storage. These 1301 devices should deploy a digest that covers the deployed firmware 1302 image, concatenated with the default erased value of any remaining 1303 space. 1305 Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) 1307 Implemented by: Payload Digests (Section 3.13) 1309 4.3.16. REQ.SEC.REPORTING: Secure Reporting 1311 Status reports from the device to any remote system SHOULD be 1312 performed over an authenticated, confidential channel in order to 1313 prevent modification or spoofing of the reports. 1315 Mitigates: THREAT.NET.MITM (Section 4.2.7) 1317 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 1319 Cryptographic keys for signing/authenticating manifests SHOULD be 1320 stored in a manner that is inaccessible to networked devices, for 1321 example in an HSM, or an air-gapped computer. This protects against 1322 an attacker obtaining the keys. 1324 Keys SHOULD be stored in a way that limits the risk of a legitimate, 1325 but compromised, entity (such as a server or developer computer) 1326 issuing signing requests. 1328 Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) 1330 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment 1332 Manifests SHOULD be parsed and examined prior to deployment to 1333 validate that their contents have not been modified during creation 1334 and signing. 1336 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1338 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted 1339 environment 1341 For high risk deployments, such as large numbers of devices or 1342 critical function devices, manifests SHOULD be constructed in an 1343 environment that is protected from interference, such as an air- 1344 gapped computer. Note that a networked computer connected to an HSM 1345 does not fulfill this requirement (see THREAT.MFST.MODIFICATION 1346 (Section 4.2.17)). 1348 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1350 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between check and 1351 use 1353 Both the manifest and any data extracted from it MUST be held 1354 immutable between its authenticity verification (time of check) and 1355 its use (time of use). To make this guarantee, the manifest MUST fit 1356 within an internal memory or a secure memory, such as encrypted 1357 memory. The recipient SHOULD defend the manifest from tampering by 1358 code or hardware resident in the recipient, for example other 1359 processes or debuggers. 1361 If an application requires that the manifest is verified before 1362 storing it, then this means the manifest MUST fit in RAM. 1364 Mitigates: THREAT.MFST.TOCTOU (Section 4.2.18) 1366 4.4. User Stories 1368 User stories provide expected use cases. These are used to feed into 1369 usability requirements. 1371 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 1373 As a Device Operator, I want to provide my devices with additional 1374 installation instructions so that I can keep process details out of 1375 my payload data. 1377 Some installation instructions might be: 1379 o Use a table of hashes to ensure that each block of the payload is 1380 validate before writing. 1382 o Do not report progress. 1384 o Pre-cache the update, but do not install. 1386 o Install the pre-cached update matching this manifest. 1388 o Install this update immediately, overriding any long-running 1389 tasks. 1391 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1393 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 1395 As a designer of a resource-constrained IoT device, I want bad 1396 updates to fail as early as possible to preserve battery life and 1397 limit consumed bandwidth. 1399 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1401 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 1403 As a Device Operator, I would like to be able to override the non- 1404 critical information in the manifest so that I can control my devices 1405 more precisely. The authority to override this information is 1406 provided via the installation of a limited trust anchor by another 1407 authority. 1409 Some examples of potentially overridable information: 1411 o URIs (Section 3.12): this allows the Device Operator to direct 1412 devices to their own infrastructure in order to reduce network 1413 load. 1415 o Conditions: this allows the Device Operator to pose additional 1416 constraints on the installation of the manifest. 1418 o Directives (Section 3.16): this allows the Device Operator to add 1419 more instructions such as time of installation. 1421 o Processing Steps (Section 3.9): If an intermediary performs an 1422 action on behalf of a device, it may need to override the 1423 processing steps. It is still possible for a device to verify the 1424 final content and the result of any processing step that specifies 1425 a digest. Some processing steps should be non-overridable. 1427 Satisfied by: USER_STORY.OVERRIDE (Section 4.4.3), 1428 REQ.USE.MFST.COMPONENT (Section 4.5.3) 1430 4.4.4. USER_STORY.COMPONENT: Component Update 1432 As a Device Operator, I want to divide my firmware into components, 1433 so that I can reduce the size of updates, make different parties 1434 responsible for different components, and divide my firmware into 1435 frequently updated and infrequently updated components. 1437 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1439 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations 1441 As a Device Operator, I want to ensure the quality of a firmware 1442 update before installing it, so that I can ensure interoperability of 1443 all devices in my product family. I want to restrict the ability to 1444 make changes to my devices to require my express approval. 1446 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), 1447 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1449 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1451 As a Device Operator, I want to be able to send multiple payload 1452 formats to suit the needs of my update, so that I can optimise the 1453 bandwidth used by my devices. 1455 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) 1457 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1458 Disclosures 1460 As a firmware author, I want to prevent confidential information from 1461 being disclosed during firmware updates. It is assumed that channel 1462 security or at-rest encryption is adequate to protect the manifest 1463 itself against information disclosure. 1465 Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1467 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 1468 Unknown Formats 1470 As a Device Operator, I want devices to determine whether they can 1471 process a payload prior to downloading it. 1473 In some cases, it may be desirable for a third party to perform some 1474 processing on behalf of a target. For this to occur, the third party 1475 MUST indicate what processing occurred and how to verify it against 1476 the Trust Provisioning Authority's intent. 1478 This amounts to overriding Processing Steps (Section 3.9) and 1479 Resource Indicator (Section 3.12). 1481 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED 1482 (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 1484 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 1485 Target Firmware 1487 As a Device Operator, I want to be able to target devices for updates 1488 based on their current firmware version, so that I can control which 1489 versions are replaced with a single manifest. 1491 Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7) 1493 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 1495 As a developer, I want to be able to sign two or more versions of my 1496 firmware in a single manifest so that I can use a very simple 1497 bootloader that chooses between two or more images that are executed 1498 in-place. 1500 Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8) 1502 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 1504 As a signer for both secure execution/boot and firmware deployment, I 1505 would like to use the same signed document for both tasks so that my 1506 data size is smaller, I can share common code, and I can reduce 1507 signature verifications. 1509 Satisfied by: REQ.USE.EXEC (Section 4.5.9) 1511 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 1513 As a developer of firmware for a run-from-RAM device, I would like to 1514 use compressed images and to indicate to the bootloader that I am 1515 using a compressed image in the manifest so that it can be used with 1516 secure execution/boot. 1518 Satisfied by: REQ.USE.LOAD (Section 4.5.10) 1520 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 1522 As an operator of devices on a constrained network, I would like the 1523 manifest to be able to include a small payload in the same packet so 1524 that I can reduce network traffic. 1526 Small payloads may include, for example, wrapped encryption keys, 1527 configuration information, public keys, authorization tokens, or 1528 X.509 certificates. 1530 Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) 1532 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 1534 As a developer for constrained devices, I want a low complexity 1535 library for processing updates so that I can fit more application 1536 code on my device. 1538 Satisfied by: REQ.USE.PARSE (Section 4.5.12) 1540 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 1542 As a Device Operator that rotates delegated authority more often than 1543 delivering firmware updates, I would like to delegate a new authority 1544 when I deliver a firmware update so that I can accomplish both tasks 1545 in a single transmission. 1547 Satisfied by: REQ.USE.DELEGATION (Section 4.5.13) 1549 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 1551 As an operator of a constrained network, I would like devices on my 1552 network to be able to evaluate the suitability of an update prior to 1553 initiating any large download so that I can prevent unnecessary 1554 consumption of bandwidth. 1556 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1558 4.5. Usability Requirements 1560 The following usability requirements satisfy the user stories listed 1561 above. 1563 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 1565 It MUST be possible for a manifest author to place ALL information 1566 required to process an update in the manifest. 1568 For example: Information about which precursor image is required for 1569 a differential update MUST be placed in the manifest, not in the 1570 differential compression header. 1572 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1573 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1574 Implemented by: Additional installation instructions (Section 3.16) 1576 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1578 It MUST be possible to redirect payload fetches. This applies where 1579 two manifests are used in conjunction. For example, a Device 1580 Operator creates a manifest specifying a payload and signs it, and 1581 provides a URI for that payload. A Network Operator creates a second 1582 manifest, with a dependency on the first. They use this second 1583 manifest to override the URIs provided by the Device Operator, 1584 directing them into their own infrastructure instead. Some devices 1585 may provide this capability, while others may only look at canonical 1586 sources of firmware. For this to be possible, the device must fetch 1587 the payload, whereas a device that accepts payload pushes will ignore 1588 this feature. 1590 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1592 Implemented by: Aliases (Section 3.17) 1594 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 1596 It MUST be possible to express the requirement to install one or more 1597 payloads from one or more authorities so that a multi-payload update 1598 can be described. This allows multiple parties with different 1599 permissions to collaborate in creating a single update for the IoT 1600 device, across multiple components. 1602 This requirement effectively means that it must be possible to 1603 construct a tree of manifests on a multi-image target. 1605 In order to enable devices with a heterogeneous storage architecture, 1606 the manifest must enable specification of both storage system and the 1607 storage location within that storage system. 1609 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1610 (Section 4.4.4) 1612 Implemented by Manifest Element: Dependencies, StorageIdentifier, 1613 ComponentIdentifier 1615 4.5.3.1. Example 1: Multiple Microcontrollers 1617 An IoT device with multiple microcontrollers in the same physical 1618 device (HeSA) will likely require multiple payloads with different 1619 component identifiers. 1621 4.5.3.2. Example 2: Code and Configuration 1623 A firmware image can be divided into two payloads: code and 1624 configuration. These payloads may require authorizations from 1625 different actors in order to install (see REQ.SEC.RIGHTS 1626 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1627 structure means that multiple manifests may be required, with a 1628 dependency structure between them. 1630 4.5.3.3. Example 3: Multiple Software Modules 1632 A firmware image can be divided into multiple functional blocks for 1633 separate testing and distribution. This means that code would need 1634 to be distributed in multiple payloads. For example, this might be 1635 desirable in order to ensure that common code between devices is 1636 identical in order to reduce distribution bandwidth. 1638 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1640 It MUST be possible to authenticate a manifest multiple times so that 1641 authorisations from multiple parties with different permissions can 1642 be required in order to authorise installation of a manifest. 1644 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1646 Implemented by: Signature (Section 3.15) 1648 4.5.5. REQ.USE.IMG.FORMAT: Format Usability 1650 The manifest format MUST accommodate any payload format that an 1651 Operator wishes to use. This enables the recipient to detect which 1652 format the Operator has chosen. Some examples of payload format are: 1654 o Binary 1656 o Executable and Linkable Format (ELF) 1658 o Differential 1660 o Compressed 1662 o Packed configuration 1664 o Intel HEX 1666 o Motorola S-Record 1667 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1668 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1670 Implemented by: Payload Format (Section 3.8) 1672 4.5.6. REQ.USE.IMG.NESTED: Nested Formats 1674 The manifest format MUST accommodate nested formats, announcing to 1675 the target device all the nesting steps and any parameters used by 1676 those steps. 1678 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1680 Implemented by: Processing Steps (Section 3.9) 1682 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 1684 The manifest format MUST provide a method to specify multiple version 1685 numbers of firmware to which the manifest applies, either with a list 1686 or with range matching. 1688 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1690 Implemented by: Required Image Version List (Section 3.6) 1692 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 1694 The manifest format MUST provide a mechanism to list multiple 1695 equivalent payloads by Execute-In-Place Installation Address, 1696 including the payload digest and, optionally, payload URIs. 1698 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1700 Implemented by: XIP Address (Section 3.20) 1702 4.5.9. REQ.USE.EXEC: Executable Manifest 1704 It MUST be possible to describe an executable system with a manifest 1705 on both Execute-In-Place microcontrollers and on complex operating 1706 systems. This requires the manifest to specify the digest of each 1707 statically linked dependency. In addition, the manifest format MUST 1708 be able to express metadata, such as a kernel command-line, used by 1709 any loader or bootloader. 1711 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1713 Implemented by: Run-time metadata (Section 3.22) 1715 4.5.10. REQ.USE.LOAD: Load-Time Information 1717 It MUST be possible to specify additional metadata for load time 1718 processing of a payload, such as cryptographic information, load- 1719 address, and compression algorithm. 1721 N.B. load comes before exec/boot. 1723 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1725 Implemented by: Load-time metadata (Section 3.21) 1727 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure 1729 It MUST be possible to place a payload in the same structure as the 1730 manifest. This MAY place the payload in the same packet as the 1731 manifest. 1733 Integrated payloads may include, for example, wrapped encryption 1734 keys, configuration information, public keys, authorization tokens, 1735 or X.509 certificates. 1737 When an integrated payload is provided, this increases the size of 1738 the manifest. Manifest size can cause several processing and storage 1739 concerns that require careful consideration. The payload can prevent 1740 the whole manifest from being contained in a single network packet, 1741 which can cause fragmentation and the loss of portions of the 1742 manifest in lossy networks. This causes the need for reassembly and 1743 retransmission logic. The manifest MUST be held immutable between 1744 verification and processing (see REQ.SEC.MFST.CONST 1745 (Section 4.3.20)), so a larger manifest will consume more memory with 1746 immutability guarantees, for example internal RAM or NVRAM, or 1747 external secure memory. If the manifest exceeds the available 1748 immutable memory, then it MUST be processed modularly, evaluating 1749 each of: delegation chains, the security container, and the actual 1750 manifest, which includes verifying the integrated payload. If the 1751 security model calls for downloading the manifest and validating it 1752 before storing to NVRAM in order to prevent wear to NVRAM and energy 1753 expenditure in NVRAM, then either increasing memory allocated to 1754 manifest storage or modular processing of the received manifest may 1755 be required. While the manifest has been organised to enable this 1756 type of processing, it creates additional complexity in the parser. 1757 If the manifest is stored in NVRAM prior to processing, the 1758 integrated payload may cause the manifest to exceed the available 1759 storage. Because the manifest is received prior to validation of 1760 applicability, authority, or correctness, integrated payloads cause 1761 the recipient to expend network bandwidth and energy that may not be 1762 required if the manifest is discarded and these costs vary with the 1763 size of the integrated payload. 1765 See also: REQ.SEC.MFST.CONST (Section 4.3.20). 1767 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1769 Implemented by: Payload (Section 3.23) 1771 4.5.12. REQ.USE.PARSE: Simple Parsing 1773 The structure of the manifest MUST be simple to parse, without need 1774 for a general-purpose parser. 1776 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1778 Implemented by: N/A 1780 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1782 Any manifest format MUST enable the delivery of a key claim with, but 1783 not authenticated by, a manifest. This key claim delivers a new key 1784 with which the recipient can verify the manifest. 1786 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1788 Implemented by: Key Claims (Section 3.24) 1790 5. IANA Considerations 1792 This document does not require any actions by IANA. 1794 6. Acknowledgements 1796 We would like to thank our working group chairs, Dave Thaler, Russ 1797 Housley and David Waltermire, for their review comments and their 1798 support. 1800 We would like to thank the participants of the 2018 Berlin SUIT 1801 Hackathon and the June 2018 virtual design team meetings for their 1802 discussion input. In particular, we would like to thank Koen 1803 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1804 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1805 Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias 1806 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1807 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1808 Gharout, and Milen Stoychev. 1810 We would like to thank those who contributed to the development of 1811 this information model. In particular, we would like to thank 1812 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary 1813 Thomson. 1815 7. References 1817 7.1. Normative References 1819 [I-D.ietf-suit-architecture] 1820 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 1821 Firmware Update Architecture for Internet of Things", 1822 draft-ietf-suit-architecture-11 (work in progress), May 1823 2020. 1825 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1826 Requirement Levels", BCP 14, RFC 2119, 1827 DOI 10.17487/RFC2119, March 1997, 1828 . 1830 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1831 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1832 DOI 10.17487/RFC4122, July 2005, 1833 . 1835 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1836 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1837 May 2017, . 1839 7.2. Informative References 1841 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1842 . 1845 Authors' Addresses 1847 Brendan Moran 1848 Arm Limited 1850 EMail: Brendan.Moran@arm.com 1852 Hannes Tschofenig 1853 Arm Limited 1855 EMail: hannes.tschofenig@gmx.net 1856 Henk Birkholz 1857 Fraunhofer SIT 1859 EMail: henk.birkholz@sit.fraunhofer.de