idnits 2.17.00 (12 Aug 2021) /tmp/idnits49903/draft-ietf-suit-information-model-10.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 (March 19, 2021) is 427 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: September 20, 2021 H. Birkholz 6 Fraunhofer SIT 7 March 19, 2021 9 A Manifest Information Model for Firmware Updates in IoT Devices 10 draft-ietf-suit-information-model-10 12 Abstract 14 Vulnerabilities with Internet of Things (IoT) devices have raised the 15 need for a reliable 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 September 20, 2021. 43 Copyright Notice 45 Copyright (c) 2021 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. Requirements and Terminology . . . . . . . . . . . . . . . . 6 62 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 65 3.1. Version ID of the Manifest Structure . . . . . . . . . . 7 66 3.2. Monotonic Sequence Number . . . . . . . . . . . . . . . . 7 67 3.3. Vendor ID . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Class ID . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 9 70 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 9 71 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9 72 3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 10 73 3.5. Precursor Image Digest Condition . . . . . . . . . . . . 10 74 3.6. Required Image Version List . . . . . . . . . . . . . . . 10 75 3.7. Expiration Time . . . . . . . . . . . . . . . . . . . . . 11 76 3.8. Payload Format . . . . . . . . . . . . . . . . . . . . . 11 77 3.9. Processing Steps . . . . . . . . . . . . . . . . . . . . 11 78 3.10. Storage Location . . . . . . . . . . . . . . . . . . . . 12 79 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 12 80 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12 81 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12 82 3.11. Component Identifier . . . . . . . . . . . . . . . . . . 12 83 3.12. Payload Indicator . . . . . . . . . . . . . . . . . . . . 13 84 3.13. Payload Digests . . . . . . . . . . . . . . . . . . . . . 13 85 3.14. Size . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 3.15. Manifest Envelope Element: Signature . . . . . . . . . . 14 87 3.16. Additional Installation Instructions . . . . . . . . . . 14 88 3.17. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 3.18. Dependencies . . . . . . . . . . . . . . . . . . . . . . 15 90 3.19. Encryption Wrapper . . . . . . . . . . . . . . . . . . . 15 91 3.20. XIP Address . . . . . . . . . . . . . . . . . . . . . . . 15 92 3.21. Load-time Metadata . . . . . . . . . . . . . . . . . . . 15 93 3.22. Run-time metadata . . . . . . . . . . . . . . . . . . . . 16 94 3.23. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 3.24. Manifest Envelope Element: Delegation Chain . . . . . . . 16 97 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 98 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 99 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17 100 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 17 101 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old 102 Firmware . . . . . . . . . . . . . . . . . . . . . . 18 103 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 18 104 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 105 the type of payload . . . . . . . . . . . . . . . . . 19 106 4.2.5. THREAT.IMG.LOCATION: The target device installs the 107 payload to the wrong location . . . . . . . . . . . . 19 108 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 109 payload hosting . . . . . . . . . . . . . . . . . . . 19 110 4.2.7. THREAT.NET.ONPATH: Traffic interception . . . . . . . 20 111 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 20 112 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 20 113 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 114 images . . . . . . . . . . . . . . . . . . . . . . . 21 115 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 21 116 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of 117 Firmware Image for Vulnerability Analysis . . . . . . 23 118 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 119 Elements . . . . . . . . . . . . . . . . . . . . . . 23 120 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 121 Exposure . . . . . . . . . . . . . . . . . . . . . . 23 122 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 24 123 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 24 124 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or 125 payload prior to signing . . . . . . . . . . . . . . 24 126 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 127 authentication and use . . . . . . . . . . . . . . . 25 128 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 25 129 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 25 130 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 26 131 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 26 132 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 26 133 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 27 134 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 135 Authenticated Storage Location . . . . . . . . . . . 27 136 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 27 137 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 27 138 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 139 images . . . . . . . . . . . . . . . . . . . . . . . 27 140 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 141 Class IDs . . . . . . . . . . . . . . . . . . . . . . 28 142 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 28 143 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 28 144 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 29 145 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 29 146 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 29 147 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 30 148 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing 149 keys . . . . . . . . . . . . . . . . . . . . . . . . 30 150 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to 151 deployment . . . . . . . . . . . . . . . . . . . . . 30 152 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 153 trusted environment . . . . . . . . . . . . . . . . . 30 154 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between 155 check and use . . . . . . . . . . . . . . . . . . . . 30 156 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 31 157 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 158 Instructions . . . . . . . . . . . . . . . . . . . . 31 159 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 31 160 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 161 Elements . . . . . . . . . . . . . . . . . . . . . . 32 162 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 32 163 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 32 164 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 33 165 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 166 Information Disclosures . . . . . . . . . . . . . . . 33 167 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from 168 Unpacking Unknown Formats . . . . . . . . . . . . . . 33 169 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 170 Numbers of Target Firmware . . . . . . . . . . . . . 33 171 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 172 Between Images . . . . . . . . . . . . . . . . . . . 34 173 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 174 Manifests . . . . . . . . . . . . . . . . . . . . . . 34 175 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 34 176 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 34 177 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 34 178 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 179 Manifest . . . . . . . . . . . . . . . . . . . . . . 35 180 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 35 181 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 35 182 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 35 183 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 184 Resource Location . . . . . . . . . . . . . . . . . . 35 185 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 36 186 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 37 187 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 37 188 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 37 189 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 38 190 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 38 191 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 38 192 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 38 193 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 38 194 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 39 195 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 196 Manifest . . . . . . . . . . . . . . . . . . . . . . 40 197 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 198 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 199 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 200 7.1. Normative References . . . . . . . . . . . . . . . . . . 40 201 7.2. Informative References . . . . . . . . . . . . . . . . . 41 202 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 204 1. Introduction 206 Vulnerabilities with Internet of Things (IoT) devices have raised the 207 need for a reliable and secure firmware update mechanism that is also 208 suitable for constrained devices. Ensuring that devices function and 209 remain secure over their service life requires such an update 210 mechanism to fix vulnerabilities, to update configuration settings, 211 as well as adding new functionality. 213 One component of such a firmware update is a concise and machine- 214 processable meta-data document, or manifest, that describes the 215 firmware image(s) and offers appropriate protection. This document 216 describes the information that must be present in the manifest. 218 This document describes all the information elements required in a 219 manifest to secure firmware updates of IoT devices. Each information 220 element is motiviated by user stories and threats it aims to 221 mitigate. These threats and user stories are not intended to be an 222 exhaustive list of the threats against IoT devices, nor of the 223 possible user stories that describe how to conduct a firmware update. 224 Instead they are intended to describe the threats against firmware 225 updates in isolation and provide sufficient motivation to specify the 226 information elements that cover a wide range of user stories. 228 To distinguish information elements from their encoding and 229 serialization over the wire this document presents an information 230 model. RFC 3444 [RFC3444] describes the differences between 231 information and data models. 233 Because this document covers a wide range of user stories and a wide 234 range of threats, not all information elements apply to all 235 scenarios. As a result, various information elements are optional to 236 implement and optional to use, depending on which threats exist in a 237 particular domain of application and which user stories are important 238 for deployments. 240 2. Requirements and Terminology 242 2.1. Requirements Notation 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 246 "OPTIONAL" in this document are to be interpreted as described in 247 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 248 capitals, as shown here. 250 Unless otherwise stated these words apply to the design of the 251 manifest format, not its implementation or application. Hence, 252 whenever an information is declared as "REQUIRED" this implies that 253 the manifest format document has to include support for it. 255 2.2. Terminology 257 This document uses terms defined in [I-D.ietf-suit-architecture]. 258 The term 'Operator' refers to both Device and Network Operator. 260 Secure time and secure clock refer to a set of requirements on time 261 sources. For local time sources, this primarily means that the clock 262 must be monotonically increasing, including across power cycles, 263 firmware updates, etc. For remote time sources, the provided time 264 must be guaranteed to be correct to within some predetermined bounds, 265 whenever the time source is accessible. 267 The term Envelope is used to describe an encoding that allows the 268 bundling of a manifest with related information elements that are not 269 directly contained within the manifest. 271 The term Payload is used to describe the data that is delivered to a 272 device during an update. This is distinct from a "firmware image", 273 as described in [I-D.ietf-suit-architecture], because the payload is 274 often in an intermediate state, such as being encrypted, compressed 275 and/or encoded as a differential update. The payload, taken in 276 isolation, is often not the final firmware image. 278 3. Manifest Information Elements 280 Each manifest information element is anchored in a security 281 requirement or a usability requirement. The manifest elements are 282 described below, justified by their requirements. 284 3.1. Version ID of the Manifest Structure 286 An identifier that describes which iteration of the manifest format 287 is contained in the structure. This allows devices to identify the 288 version of the manifest data model that is in use. 290 This element is REQUIRED. 292 3.2. Monotonic Sequence Number 294 A monotonically increasing sequence number to prevent malicious 295 actors from reverting a firmware update against the policies of the 296 relevant authority. 298 For convenience, the monotonic sequence number may be a UTC 299 timestamp. This allows global synchronisation of sequence numbers 300 without any additional management. 302 This element is REQUIRED. 304 Implements: REQ.SEC.SEQUENCE (Section 4.3.1) 306 3.3. Vendor ID 308 The Vendor ID element helps to distinguish between identically named 309 products from different vendors. Vendor ID is not intended to be a 310 human-readable element. It is intended for binary match/mismatch 311 comparison only. 313 Recommended practice is to use [RFC4122] version 5 UUIDs with the 314 vendor's domain name and the DNS name space ID. Other options 315 include type 1 and type 4 UUIDs. 317 This element is RECOMMENDED. 319 Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), 320 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 322 Here is an example for a domain name-based UUID. Vendor A creates a 323 UUID based on a domain name it controls, such as vendorId = 324 UUID5(DNS, "vendor-a.example") 326 Because the DNS infrastructure prevents multiple registrations of the 327 same domain name, this UUID is (with very high probability) 328 guaranteed to be unique. Because the domain name is known, this UUID 329 is reproducible. Type 1 and type 4 UUIDs produce similar guarantees 330 of uniqueness, but not reproducibility. 332 This approach creates a contention when a vendor changes its name or 333 relinquishes control of a domain name. In this scenario, it is 334 possible that another vendor would start using that same domain name. 335 However, this UUID is not proof of identity; a device's trust in a 336 vendor must be anchored in a cryptographic key, not a UUID. 338 3.4. Class ID 340 A device "Class" is a set of different device types that can accept 341 the same firmware update without modification. It thereby allows 342 devices to determine applicability of a firmware in an unambiguous 343 way. Class IDs must be unique within the scope of a Vendor ID. This 344 is to prevent similarly, or identically named devices colliding in 345 their customer's infrastructure. 347 Recommended practice is to use [RFC4122] version 5 UUIDs with as much 348 information as necessary to define firmware compatibility. Possible 349 information used to derive the class UUID includes: 351 o model name or number 353 o hardware revision 355 o runtime library version 357 o bootloader version 359 o ROM revision 361 o silicon batch number 363 The Class ID UUID should use the Vendor ID as the name space 364 identifier. Other options include version 1 and 4 UUIDs. Classes 365 may be more fine-grained granular than is required to identify 366 firmware compatibility. Classes must not be less granular than is 367 required to identify firmware compatibility. Devices may have 368 multiple Class IDs. 370 Class ID is not intended to be a human-readable element. It is 371 intended for binary match/mismatch comparison only. 373 If Class ID is not implemented, then each logical device class must 374 use a unique trust anchor for authorization. 376 This element is RECOMMENDED. 378 Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), 379 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 381 3.4.1. Example 1: Different Classes 383 Vendor A creates product Z and product Y. The firmware images of 384 products Z and Y are not interchangeable. Vendor A creates UUIDs as 385 follows: 387 o vendorId = UUID5(DNS, "vendor-a.com") 389 o ZclassId = UUID5(vendorId, "Product Z") 391 o YclassId = UUID5(vendorId, "Product Y") 393 This ensures that Vendor A's Product Z cannot install firmware for 394 Product Y and Product Y cannot install firmware for Product Z. 396 3.4.2. Example 2: Upgrading Class ID 398 Vendor A creates product X. Later, Vendor A adds a new feature to 399 product X, creating product X v2. Product X requires a firmware 400 update to work with firmware intended for product X v2. 402 Vendor A creates UUIDs as follows: 404 o vendorId = UUID5(DNS, "vendor-a.com") 406 o XclassId = UUID5(vendorId, "Product X") 408 o Xv2classId = UUID5(vendorId, "Product X v2") 410 When product X receives the firmware update necessary to be 411 compatible with product X v2, part of the firmware update changes the 412 class ID to Xv2classId. 414 3.4.3. Example 3: Shared Functionality 416 Vendor A produces two products, product X and product Y. These 417 components share a common core (such as an operating system), but 418 have different applications. The common core and the applications 419 can be updated independently. To enable X and Y to receive the same 420 common core update, they require the same class ID. To ensure that 421 only product X receives application X and only product Y receives 422 application Y, product X and product Y must have different class IDs. 423 The vendor creates Class IDs as follows: 425 o vendorId = UUID5(DNS, "vendor-a.com") 427 o XclassId = UUID5(vendorId, "Product X") 428 o YclassId = UUID5(vendorId, "Product Y") 430 o CommonClassId = UUID5(vendorId, "common core") 432 Product X matches against both XclassId and CommonClassId. Product Y 433 matches against both YclassId and CommonClassId. 435 3.4.4. Example 4: White-labelling 437 Vendor A creates a product A and its firmware. Vendor B sells the 438 product under its own name as Product B with some customised 439 configuration. The vendors create the Class IDs as follows: 441 o vendorIdA = UUID5(DNS, "vendor-a.com") 443 o classIdA = UUID5(vendorIdA, "Product A-Unlabelled") 445 o vendorIdB = UUID5(DNS, "vendor-b.com") 447 o classIdB = UUID5(vendorIdB, "Product B") 449 The product will match against each of these class IDs. If Vendor A 450 and Vendor B provide different components for the device, the 451 implementor may choose to make ID matching scoped to each component. 452 Then, the vendorIdA, classIdA match the component ID supplied by 453 Vendor A, and the vendorIdB, classIdB match the component ID supplied 454 by Vendor B. 456 3.5. Precursor Image Digest Condition 458 This element provides information about the payload that needs to be 459 present on the device for an update to apply. This may, for example, 460 be the case with differential updates. 462 This element is OPTIONAL. 464 Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 466 3.6. Required Image Version List 468 Payloads may only be applied to a specific firmware version or 469 firmware versions. For example, a payload containing a differential 470 update may be applied only to a specific firmware version. 472 When a payload applies to multiple versions of a firmware, the 473 required image version list specifies which firmware versions must be 474 present for the update to be applied. This allows the update author 475 to target specific versions of firmware for an update, while 476 excluding those to which it should not or cannot be applied. 478 This element is OPTIONAL. 480 Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) 482 3.7. Expiration Time 484 This element tells a device the time at which the manifest expires 485 and should no longer be used. This element should be used where a 486 secure source of time is provided and firmware is intended to expire 487 predictably. This element may also be displayed (e.g. via an app) 488 for user confirmation since users typically have a reliable knowledge 489 of the date. 491 Special consideration is required for end-of-life if a firmware will 492 not be updated again, for example if a business stops issuing updates 493 to a device. In this case the last valid firmware should not have an 494 expiration time. 496 This element is OPTIONAL. 498 Implements: REQ.SEC.EXP (Section 4.3.3) 500 3.8. Payload Format 502 This element describes the payload format within the signed metadata. 503 It is used to enable devices to decode payloads correctly. 505 This element is REQUIRED. 507 Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT 508 (Section 4.5.5) 510 3.9. Processing Steps 512 A representation of the Processing Steps required to decode a 513 payload, in particular those that are compressed, packed, or 514 encrypted. The representation must describe which algorithms are 515 used and must convey any additional parameters required by those 516 algorithms. 518 A Processing Step may indicate the expected digest of the payload 519 after the processing is complete. 521 This element is RECOMMENDED. 523 Implements: REQ.USE.IMG.NESTED (Section 4.5.6) 525 3.10. Storage Location 527 This element tells the device where to store a payload within a given 528 component. The device can use this to establish which permissions 529 are necessary and the physical storage location to use. 531 This element is REQUIRED. 533 Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 535 3.10.1. Example 1: Two Storage Locations 537 A device supports two components: an OS and an application. These 538 components can be updated independently, expressing dependencies to 539 ensure compatibility between the components. The Author chooses two 540 storage identifiers: 542 o "OS" 544 o "APP" 546 3.10.2. Example 2: File System 548 A device supports a full-featured filesystem. The Author chooses to 549 use the storage identifier as the path at which to install the 550 payload. The payload may be a tarball, in which case, it unpacks the 551 tarball into the specified path. 553 3.10.3. Example 3: Flash Memory 555 A device supports flash memory. The Author chooses to make the 556 storage identifier the offset where the image should be written. 558 3.11. Component Identifier 560 In a device with more than one storage subsystem, a storage 561 identifier is insufficient to identify where and how to store a 562 payload. To resolve this, a component identifier indicates to which 563 part of the storage subsystem the payload shall be placed. 565 A serialization may choose to combine Component Identifier and 566 Storage Location (Section 3.10). 568 This element is OPTIONAL. 570 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 572 3.12. Payload Indicator 574 This element provides the information required for the device to 575 acquire the payload. This functionality is only needed when the 576 target device does not intrinsically know where to find the payload. 578 This can be encoded in several ways: 580 o One URI 582 o A list of URIs 584 o A prioritised list of URIs 586 o A list of signed URIs 588 This element is OPTIONAL. 590 Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 592 3.13. Payload Digests 594 This element contains one or more digests of one or more payloads. 595 This allows the target device to ensure authenticity of the 596 payload(s) when combined with the Signature (Section 3.15) element. 597 A manifest format must provide a mechanism to select one payload from 598 a list based on system parameters, such as Execute-In-Place 599 Installation Address. 601 This element is REQUIRED. Support for more than one digest is 602 OPTIONAL. 604 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT 605 (Section 4.5.8) 607 3.14. Size 609 The size of the payload in bytes, which informs the target device how 610 big of a payload to expect. Without it, devices are exposed to some 611 classes of denial of service attack. 613 This element is REQUIRED. 615 Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) 617 3.15. Manifest Envelope Element: Signature 619 The Signature element contains all the information necessary to 620 protect the contents of the manifest against modification and to 621 offer authentication of the signer. Because the Signature element 622 authenticates the manifest, it cannot be contained within the 623 manifest. Instead, the manifest is either contained within the 624 signature element, or the signature element is a member of the 625 Manifest Envelope and bundled with the manifest. 627 The Signature element represents the foundation of all security 628 properties of the manifest. Manifests, which are included as 629 dependencies by another manifests, should include a signature so that 630 the recipient can distinguish between different actors with different 631 permissions. 633 The Signature element must support multiple signers and multiple 634 signing algorithms. A manifest format may allow multiple manifests 635 to be covered by a single Signature element. 637 This element is REQUIRED in non-dependency manifests. 639 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS 640 (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) 642 3.16. Additional Installation Instructions 644 Additional installation instructions are machine-readable commands 645 the device should execute when processing the manifest. This 646 information is distinct from the information necessary to process a 647 payload. Additional installation instructions include information 648 such as update timing (for example, install only on Sunday, at 0200), 649 procedural considerations (for example, shut down the equipment under 650 control before executing the update), pre- and post-installation 651 steps (for example, run a script). Other installation instructions 652 could include requesting user confirmation before installing. 654 This element is OPTIONAL. 656 Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 658 3.17. Aliases 660 A mechanism for a manifest to augment or replace URIs or URI lists 661 defined by one or more of its dependencies. 663 This element is OPTIONAL. 665 Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 667 3.18. Dependencies 669 A list of other manifests that are required by the current manifest. 670 Manifests are identified an unambiguous way, such as a cryptographic 671 digest. 673 This element is REQUIRED to support deployments that include both 674 multiple authorities and multiple payloads. 676 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 678 3.19. Encryption Wrapper 680 Encrypting firmware images requires symmetric content encryption 681 keys. The encryption wrapper provides the information needed for a 682 device to obtain or locate a key that it uses to decrypt the 683 firmware. 685 This element is REQUIRED for encrypted payloads. 687 Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 689 3.20. XIP Address 691 In order to support execute in place (XIP) systems with multiple 692 possible base addresses, it is necessary to specify which address the 693 payload is linked for. 695 For example a microcontroller may have a simple bootloader that 696 chooses one of two images to boot. That microcontroller then needs 697 to choose one of two firmware images to install, based on which of 698 its two images is older. 700 This element is OPTIONAL. 702 Implements: REQ.USE.IMG.SELECT (Section 4.5.8) 704 3.21. Load-time Metadata 706 Load-time metadata provides the device with information that it needs 707 in order to load one or more images. This metadata may include any 708 of: 710 o the source 712 o the destination 713 o cryptographic information 715 o decompression information 717 o unpacking information 719 Typically, loading is done by copying an image from its permanent 720 storage location into its active use location. The metadata allows 721 operations such as decryption, decompression, and unpacking to be 722 performed during that copy. 724 This element is OPTIONAL. 726 Implements: REQ.USE.LOAD (Section 4.5.10) 728 3.22. Run-time metadata 730 Run-time metadata provides the device with any extra information 731 needed to boot the device. This may include the entry-point of an 732 XIP image or the kernel command-line to boot a Linux image. 734 This element is OPTIONAL. 736 Implements: REQ.USE.EXEC (Section 4.5.9) 738 3.23. Payload 740 The Payload element is contained within the manifest or manifest 741 envelope and enables the manifest and payload to be delivered 742 simultaneously. This is used for delivering small payloads, such as 743 cryptographic keys or configuration data. 745 This element is OPTIONAL. 747 Implements: REQ.USE.PAYLOAD (Section 4.5.11) 749 3.24. Manifest Envelope Element: Delegation Chain 751 The delegation chain offers enhanced authorization functionality via 752 authorization tokens. Each token itself is protected and does not 753 require another layer of protection. Because the delegation chain is 754 needed to verify the signature, it must be placed in the Manifest 755 Envelope, rather than the Manifest. 757 This element is OPTIONAL. 759 Implements: REQ.USE.DELEGATION (Section 4.5.13) 761 4. Security Considerations 763 The following sub-sections describe the threat model, user stories, 764 security requirements, and usability requirements. This section also 765 provides the motivations for each of the manifest information 766 elements. 768 4.1. Threat Model 770 The following sub-sections aim to provide information about the 771 threats that were considered, the security requirements that are 772 derived from those threats and the fields that permit implementation 773 of the security requirements. This model uses the S.T.R.I.D.E. 774 [STRIDE] approach. Each threat is classified according to: 776 o Spoofing identity 778 o Tampering with data 780 o Repudiation 782 o Information disclosure 784 o Denial of service 786 o Elevation of privilege 788 This threat model only covers elements related to the transport of 789 firmware updates. It explicitly does not cover threats outside of 790 the transport of firmware updates. For example, threats to an IoT 791 device due to physical access are out of scope. 793 4.2. Threat Descriptions 795 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 797 Classification: Elevation of Privilege 799 An attacker sends an old, but valid manifest with an old, but valid 800 firmware image to a device. If there is a known vulnerability in the 801 provided firmware image, this may allow an attacker to exploit the 802 vulnerability and gain control of the device. 804 Threat Escalation: If the attacker is able to exploit the known 805 vulnerability, then this threat can be escalated to ALL TYPES. 807 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 809 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old Firmware 811 Classification: Elevation of Privilege 813 An attacker targets a device that has been offline for a long time 814 and runs an old firmware version. The attacker sends an old, but 815 valid manifest to a device with an old, but valid firmware image. 816 The attacker-provided firmware is newer than the installed one but 817 older than the most recently available firmware. If there is a known 818 vulnerability in the provided firmware image then this may allow an 819 attacker to gain control of a device. Because the device has been 820 offline for a long time, it is unaware of any new updates. As such 821 it will treat the old manifest as the most current. 823 The exact mitigation for this threat depends on where the threat 824 comes from. This requires careful consideration by the implementor. 825 If the threat is from a network actor, including an on-path attacker, 826 or an intruder into a management system, then a user confirmation can 827 mitigate this attack, simply by displaying an expiration date and 828 requesting confirmation. On the other hand, if the user is the 829 attacker, then an online confirmation system (for example a trusted 830 timestamp server) can be used as a mitigation system. 832 Threat Escalation: If the attacker is able to exploit the known 833 vulnerability, then this threat can be escalated to ALL TYPES. 835 Mitigated by: REQ.SEC.EXP (Section 4.3.3), REQ.USE.MFST.PRE_CHECK 836 (Section 4.5.1), 838 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 840 Classification: Denial of Service 842 An attacker sends a valid firmware image, for the wrong type of 843 device, signed by an actor with firmware installation permission on 844 both types of device. The firmware is verified by the device 845 positively because it is signed by an actor with the appropriate 846 permission. This could have wide-ranging consequences. For devices 847 that are similar, it could cause minor breakage, or expose security 848 vulnerabilities. For devices that are very different, it is likely 849 to render devices inoperable. 851 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 853 For example, suppose that two vendors, Vendor A and Vendor B, adopt 854 the same trade name in different geographic regions, and they both 855 make products with the same names, or product name matching is not 856 used. This causes firmware from Vendor A to match devices from 857 Vendor B. 859 If the vendors are the firmware authorities, then devices from Vendor 860 A will reject images signed by Vendor B since they use different 861 credentials. However, if both devices trust the same Author, then, 862 devices from Vendor A could install firmware intended for devices 863 from Vendor B. 865 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 866 payload 868 Classification: Denial of Service 870 If a device misinterprets the format of the firmware image, it may 871 cause a device to install a firmware image incorrectly. An 872 incorrectly installed firmware image would likely cause the device to 873 stop functioning. 875 Threat Escalation: An attacker that can cause a device to 876 misinterpret the received firmware image may gain elevation of 877 privilege and potentially expand this to all types of threat. 879 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 881 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 882 the wrong location 884 Classification: Denial of Service 886 If a device installs a firmware image to the wrong location on the 887 device, then it is likely to break. For example, a firmware image 888 installed as an application could cause a device and/or an 889 application to stop functioning. 891 Threat Escalation: An attacker that can cause a device to 892 misinterpret the received code may gain elevation of privilege and 893 potentially expand this to all types of threat. 895 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 897 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 899 Classification: Denial of Service 901 If a device is tricked into fetching a payload for an attacker 902 controlled site, the attacker may send corrupted payloads to devices. 904 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 906 4.2.7. THREAT.NET.ONPATH: Traffic interception 908 Classification: Spoofing Identity, Tampering with Data 910 An attacker intercepts all traffic to and from a device. The 911 attacker can monitor or modify any data sent to or received from the 912 device. This can take the form of: manifests, payloads, status 913 reports, and capability reports being modified or not delivered to 914 the intended recipient. It can also take the form of analysis of 915 data sent to or from the device, either in content, size, or 916 frequency. 918 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), 919 REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC 920 (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), 921 REQ.SEC.REPORTING (Section 4.3.16) 923 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 925 Classification: Elevation of Privilege 927 An attacker replaces a newly downloaded firmware after a device 928 finishes verifying a manifest. This could cause the device to 929 execute the attacker's code. This attack likely requires physical 930 access to the device. However, it is possible that this attack is 931 carried out in combination with another threat that allows remote 932 execution. This is a typical Time Of Check/Time Of Use (TICTOC) 933 attack. 935 Threat Escalation: If the attacker is able to exploit a known 936 vulnerability, or if the attacker can supply their own firmware, then 937 this threat can be escalated to ALL TYPES. 939 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 941 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 943 Classification: Elevation of Privilege / All Types 945 If an attacker can install their firmware on a device, for example by 946 manipulating either payload or metadata, then they have complete 947 control of the device. 949 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 951 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 953 Classification: Denial of Service / All Types 955 Modifications of payloads and metadata allow an attacker to introduce 956 a number of denial of service attacks. Below are some examples. 958 An attacker sends a valid, current manifest to a device that has an 959 unexpected precursor image. If a payload format requires a precursor 960 image (for example, delta updates) and that precursor image is not 961 available on the target device, it could cause the update to break. 963 An attacker that can cause a device to install a payload against the 964 wrong precursor image could gain elevation of privilege and 965 potentially expand this to all types of threat. However, it is 966 unlikely that a valid differential update applied to an incorrect 967 precursor would result in a functional, but vulnerable firmware. 969 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 971 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 973 Classification: Denial of Service, Elevation of Privilege 975 This threat can appear in several ways, however it is ultimately 976 about ensuring that devices retain the behaviour required by their 977 owner, or operator. The owner or operator of a device typically 978 requires that the device maintain certain features, functions, 979 capabilities, behaviours, or interoperability constraints (more 980 generally, behaviour). If these requirements are broken, then a 981 device will not fulfill its purpose. Therefore, if any party other 982 than the device's owner or the owner's contracted Device Operator has 983 the ability to modify device behaviour without approval, then this 984 constitutes an elevation of privilege. 986 Similarly, a Network Operator may require that devices behave in a 987 particular way in order to maintain the integrity of the network. If 988 devices behaviour on a network can be modified without the approval 989 of the Network Operator, then this constitutes an elevation of 990 privilege with respect to the network. 992 For example, if the owner of a device has purchased that device 993 because of features A, B, and C, and a firmware update is issued by 994 the manufacturer, which removes feature A, then the device may not 995 fulfill the owner's requirements any more. In certain circumstances, 996 this can cause significantly greater threats. Suppose that feature A 997 is used to implement a safety-critical system, whether the 998 manufacturer intended this behaviour or not. When unapproved 999 firmware is installed, the system may become unsafe. 1001 In a second example, the owner or operator of a system of two or more 1002 interoperating devices needs to approve firmware for their system in 1003 order to ensure interoperability with other devices in the system. 1004 If the firmware is not qualified, the system as a whole may not work. 1005 Therefore, if a device installs firmware without the approval of the 1006 device owner or operator, this is a threat to devices or the system 1007 as a whole. 1009 Similarly, the operator of a network may need to approve firmware for 1010 devices attached to the network in order to ensure favourable 1011 operating conditions within the network. If the firmware is not 1012 qualified, it may degrade the performance of the network. Therefore, 1013 if a device installs firmware without the approval of the Network 1014 Operator, this is a threat to the network itself. 1016 Threat Escalation: If the firmware expects configuration that is 1017 present in devices deployed in Network A, but not in devices deployed 1018 in Network B, then the device may experience degraded security, 1019 leading to threats of All Types. 1021 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 1022 (Section 4.3.13) 1024 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 1025 Operator 1027 In this example, assume that Device Operators expect the rights to 1028 create firmware but that Network Operators expect the rights to 1029 qualify firmware as fit-for-purpose on their networks. Additionally, 1030 assume that Device Operators manage devices that can be deployed on 1031 any network, including Network A and B in our example. 1033 An attacker may obtain a manifest for a device on Network A. Then, 1034 this attacker sends that manifest to a device on Network B. Because 1035 Network A and Network B are under control of different Operators, and 1036 the firmware for a device on Network A has not been qualified to be 1037 deployed on Network B, the target device on Network B is now in 1038 violation of the Operator B's policy and may be disabled by this 1039 unqualified, but signed firmware. 1041 This is a denial of service because it can render devices inoperable. 1042 This is an elevation of privilege because it allows the attacker to 1043 make installation decisions that should be made by the Operator. 1045 4.2.11.2. Example 2: Single Network Operator with Multiple Device 1046 Operators 1048 Multiple devices that interoperate are used on the same network and 1049 communicate with each other. Some devices are manufactured and 1050 managed by Device Operator A and other devices by Device Operator B. 1051 A new firmware is released by Device Operator A that breaks 1052 compatibility with devices from Device Operator B. An attacker sends 1053 the new firmware to the devices managed by Device Operator A without 1054 approval of the Network Operator. This breaks the behaviour of the 1055 larger system causing denial of service and possibly other threats. 1056 Where the network is a distributed SCADA system, this could cause 1057 misbehaviour of the process that is under control. 1059 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 1060 for Vulnerability Analysis 1062 Classification: All Types 1064 An attacker wants to mount an attack on an IoT device. To prepare 1065 the attack he or she retrieves the provided firmware image and 1066 performs reverse engineering of the firmware image to analyze it for 1067 specific vulnerabilities. 1069 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1071 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 1073 Classification: Elevation of Privilege 1075 An authorized actor, but not the Author, uses an override mechanism 1076 (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information 1077 element in a manifest signed by the Author. For example, if the 1078 authorized actor overrides the digest and URI of the payload, the 1079 actor can replace the entire payload with a payload of their choice. 1081 Threat Escalation: By overriding elements such as payload 1082 installation instructions or firmware digest, this threat can be 1083 escalated to all types. 1085 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1087 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 1089 Classification: Information Disclosure 1091 A third party may be able to extract sensitive information from the 1092 manifest. 1094 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 1096 4.2.15. THREAT.IMG.EXTRA: Extra data after image 1098 Classification: All Types 1100 If a third party modifies the image so that it contains extra code 1101 after a valid, authentic image, that third party can then use their 1102 own code in order to make better use of an existing vulnerability. 1104 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 1106 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 1108 Classification: All Types 1110 If a third party obtains a key or even indirect access to a key, for 1111 example in an hardware security module (HSM), then they can perform 1112 the same actions as the legitimate owner of the key. If the key is 1113 trusted for firmware update, then the third party can perform 1114 firmware updates as though they were the legitimate owner of the key. 1116 For example, if manifest signing is performed on a server connected 1117 to the internet, an attacker may compromise the server and then be 1118 able to sign manifests, even if the keys for manifest signing are 1119 held in an HSM that is accessed by the server. 1121 Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17) 1123 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 1124 prior to signing 1126 Classification: All Types 1128 If an attacker can alter a manifest or payload before it is signed, 1129 they can perform all the same actions as the manifest author. This 1130 allows the attacker to deploy firmware updates to any devices that 1131 trust the manifest author. If an attacker can modify the code of a 1132 payload before the corresponding manifest is created, they can insert 1133 their own code. If an attacker can modify the manifest before it is 1134 signed, they can redirect the manifest to their own payload. 1136 For example, the attacker deploys malware to the developer's computer 1137 or signing service that watches manifest creation activities and 1138 inserts code into any binary that is referenced by a manifest. 1140 For example, the attacker deploys malware to the developer's computer 1141 or signing service that replaces the referenced binary (digest) and 1142 URI with the attacker's binary (digest) and URI. 1144 Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18), 1145 REQ.SEC.MFST.TRUSTED (Section 4.3.19) 1147 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 1148 authentication and use 1150 Classification: All Types 1152 If an attacker can modify a manifest after it is authenticated (Time 1153 Of Check) but before it is used (Time Of Use), then the attacker can 1154 place any content whatsoever in the manifest. 1156 Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.20) 1158 4.3. Security Requirements 1160 The security requirements here are a set of policies that mitigate 1161 the threats described in Section 4.1. 1163 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 1165 Only an actor with firmware installation authority is permitted to 1166 decide when device firmware can be installed. To enforce this rule, 1167 manifests MUST contain monotonically increasing sequence numbers. 1168 Manifests may use UTC epoch timestamps to coordinate monotonically 1169 increasing sequence numbers across many actors in many locations. If 1170 UTC epoch timestamps are used, they must not be treated as times, 1171 they must be treated only as sequence numbers. Devices must reject 1172 manifests with sequence numbers smaller than any onboard sequence 1173 number, i.e. there is no sequence number roll over. 1175 Note: This is not a firmware version field. It is a manifest 1176 sequence number. A firmware version may be rolled back by creating a 1177 new manifest for the old firmware version with a later sequence 1178 number. 1180 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 1182 Implemented by: Monotonic Sequence Number (Section 3.2) 1184 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1186 Devices MUST only apply firmware that is intended for them. Devices 1187 must know that a given update applies to their vendor, model, 1188 hardware revision, and software revision. Human-readable identifiers 1189 are often error-prone in this regard, so unique identifiers should be 1190 used instead. 1192 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1194 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1195 (Section 3.4) 1197 4.3.3. REQ.SEC.EXP: Expiration Time 1199 A firmware manifest MAY expire after a given time and devices may 1200 have a secure clock (local or remote). If a secure clock is provided 1201 and the Firmware manifest has an expiration timestamp, the device 1202 must reject the manifest if current time is later than the expiration 1203 time. 1205 Special consideration is required for end-of-life in case device will 1206 not be updated again, for example if a business stops issuing updates 1207 for a device. The last valid firmware should not have an expiration 1208 time. 1210 Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2) 1212 Implemented by: Expiration Time (Section 3.7) 1214 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1216 The authenticity of an update MUST be demonstrable. Typically, this 1217 means that updates must be digitally signed. Because the manifest 1218 contains information about how to install the update, the manifest's 1219 authenticity must also be demonstrable. To reduce the overhead 1220 required for validation, the manifest contains the cryptographic 1221 digest of the firmware image, rather than a second digital signature. 1222 The authenticity of the manifest can be verified with a digital 1223 signature or Message Authentication Code. The authenticity of the 1224 firmware image is tied to the manifest by the use of a cryptographic 1225 digest of the firmware image. 1227 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.ONPATH 1228 (Section 4.2.7) 1230 Implemented by: Signature (Section 3.15), Payload Digest 1231 (Section 3.13) 1233 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1235 The type of payload MUST be authenticated. For example, the target 1236 must know whether the payload is XIP firmware, a loadable module, or 1237 configuration data. 1239 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1241 Implemented by: Payload Format (Section 3.8), Signature 1242 (Section 3.15) 1244 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1245 Location 1247 The location on the target where the payload is to be stored MUST be 1248 authenticated. 1250 Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) 1252 Implemented by: Storage Location (Section 3.10) 1254 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 1256 The location where a target should find a payload MUST be 1257 authenticated. 1259 Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.ONPATH 1260 (Section 4.2.7) 1262 Implemented by: Payload Indicator (Section 3.12) 1264 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 1266 The target SHOULD verify firmware at time of boot. This requires 1267 authenticated payload size, and digest. 1269 Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) 1271 Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) 1273 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 1275 If an update uses a differential compression method, it MUST specify 1276 the digest of the precursor image and that digest MUST be 1277 authenticated. 1279 Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10) 1280 Implemented by: Precursor Image Digest (Section 3.5) 1282 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs 1284 The identifiers that specify firmware compatibility MUST be 1285 authenticated to ensure that only compatible firmware is installed on 1286 a target device. 1288 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1290 Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition 1291 (Section 3.4) 1293 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 1295 If a device grants different rights to different actors, exercising 1296 those rights MUST be accompanied by proof of those rights, in the 1297 form of proof of authenticity. Authenticity mechanisms, such as 1298 those required in REQ.SEC.AUTHENTIC (Section 4.3.4), can be used to 1299 prove authenticity. 1301 For example, if a device has a policy that requires that firmware 1302 have both an Authorship right and a Qualification right and if that 1303 device grants Authorship and Qualification rights to different 1304 parties, such as a Device Operator and a Network Operator, 1305 respectively, then the firmware cannot be installed without proof of 1306 rights from both the Device Operator and the Network Operator. 1308 Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11) 1310 Implemented by: Signature (Section 3.15) 1312 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 1314 The manifest information model MUST enable encrypted payloads. 1315 Encryption helps to prevent third parties, including attackers, from 1316 reading the content of the firmware image. This can protect against 1317 confidential information disclosures and discovery of vulnerabilities 1318 through reverse engineering. Therefore the manifest must convey the 1319 information required to allow an intended recipient to decrypt an 1320 encrypted payload. 1322 Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.ONPATH 1323 (Section 4.2.7) 1325 Implemented by: Encryption Wrapper (Section 3.19) 1327 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 1329 If a device grants different rights to different actors, then an 1330 exercise of those rights MUST be validated against a list of rights 1331 for the actor. This typically takes the form of an Access Control 1332 List (ACL). ACLs are applied to two scenarios: 1334 1. An ACL decides which elements of the manifest may be overridden 1335 and by which actors. 1337 2. An ACL decides which component identifier/storage identifier 1338 pairs can be written by which actors. 1340 Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), 1341 THREAT.UPD.UNAPPROVED (Section 4.2.11) 1343 Implemented by: Client-side code, not specified in manifest. 1345 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 1347 A manifest format MUST allow encryption of selected parts of the 1348 manifest or encryption of the entire manifest to prevent sensitive 1349 content of the firmware metadata to be leaked. 1351 Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.ONPATH 1352 (Section 4.2.7) 1354 Implemented by: Manifest Encryption Wrapper / Transport Security 1356 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 1358 The digest SHOULD cover all available space in a fixed-size storage 1359 location. Variable-size storage locations MUST be restricted to 1360 exactly the size of deployed payload. This prevents any data from 1361 being distributed without being covered by the digest. For example, 1362 XIP microcontrollers typically have fixed-size storage. These 1363 devices should deploy a digest that covers the deployed firmware 1364 image, concatenated with the default erased value of any remaining 1365 space. 1367 Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) 1369 Implemented by: Payload Digests (Section 3.13) 1371 4.3.16. REQ.SEC.REPORTING: Secure Reporting 1373 Status reports from the device to any remote system MUST be performed 1374 over an authenticated, confidential channel in order to prevent 1375 modification or spoofing of the reports. 1377 Mitigates: THREAT.NET.ONPATH (Section 4.2.7) 1379 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 1381 Cryptographic keys for signing/authenticating manifests SHOULD be 1382 stored in a manner that is inaccessible to networked devices, for 1383 example in an HSM, or an air-gapped computer. This protects against 1384 an attacker obtaining the keys. 1386 Keys SHOULD be stored in a way that limits the risk of a legitimate, 1387 but compromised, entity (such as a server or developer computer) 1388 issuing signing requests. 1390 Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) 1392 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment 1394 Manifests SHOULD be verified prior to deployment. This reduces 1395 problems that may arise with devices installing firmware images that 1396 damage devices unintentionally. 1398 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1400 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted 1401 environment 1403 For high risk deployments, such as large numbers of devices or 1404 critical function devices, manifests SHOULD be constructed in an 1405 environment that is protected from interference, such as an air- 1406 gapped computer. Note that a networked computer connected to an HSM 1407 does not fulfill this requirement (see THREAT.MFST.MODIFICATION 1408 (Section 4.2.17)). 1410 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1412 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between check and 1413 use 1415 Both the manifest and any data extracted from it MUST be held 1416 immutable between its authenticity verification (time of check) and 1417 its use (time of use). To make this guarantee, the manifest MUST fit 1418 within an internal memory or a secure memory, such as encrypted 1419 memory. The recipient SHOULD defend the manifest from tampering by 1420 code or hardware resident in the recipient, for example other 1421 processes or debuggers. 1423 If an application requires that the manifest is verified before 1424 storing it, then this means the manifest MUST fit in RAM. 1426 Mitigates: THREAT.MFST.TOCTOU (Section 4.2.18) 1428 4.4. User Stories 1430 User stories provide expected use cases. These are used to feed into 1431 usability requirements. 1433 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 1435 As a Device Operator, I want to provide my devices with additional 1436 installation instructions so that I can keep process details out of 1437 my payload data. 1439 Some installation instructions might be: 1441 o Use a table of hashes to ensure that each block of the payload is 1442 validated before writing. 1444 o Do not report progress. 1446 o Pre-cache the update, but do not install. 1448 o Install the pre-cached update matching this manifest. 1450 o Install this update immediately, overriding any long-running 1451 tasks. 1453 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1455 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 1457 As a designer of a resource-constrained IoT device, I want bad 1458 updates to fail as early as possible to preserve battery life and 1459 limit consumed bandwidth. 1461 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1463 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 1465 As a Device Operator, I would like to be able to override the non- 1466 critical information in the manifest so that I can control my devices 1467 more precisely. The authority to override this information is 1468 provided via the installation of a limited trust anchor by another 1469 authority. 1471 Some examples of potentially overridable information: 1473 o URIs (Section 3.12): this allows the Device Operator to direct 1474 devices to their own infrastructure in order to reduce network 1475 load. 1477 o Conditions: this allows the Device Operator to pose additional 1478 constraints on the installation of the manifest. 1480 o Directives (Section 3.16): this allows the Device Operator to add 1481 more instructions such as time of installation. 1483 o Processing Steps (Section 3.9): If an intermediary performs an 1484 action on behalf of a device, it may need to override the 1485 processing steps. It is still possible for a device to verify the 1486 final content and the result of any processing step that specifies 1487 a digest. Some processing steps should be non-overridable. 1489 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1491 4.4.4. USER_STORY.COMPONENT: Component Update 1493 As a Device Operator, I want to divide my firmware into components, 1494 so that I can reduce the size of updates, make different parties 1495 responsible for different components, and divide my firmware into 1496 frequently updated and infrequently updated components. 1498 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1500 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations 1502 As a Device Operator, I want to ensure the quality of a firmware 1503 update before installing it, so that I can ensure interoperability of 1504 all devices in my product family. I want to restrict the ability to 1505 make changes to my devices to require my express approval. 1507 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), 1508 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1510 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1512 As a Device Operator, I want to be able to send multiple payload 1513 formats to suit the needs of my update, so that I can optimise the 1514 bandwidth used by my devices. 1516 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) 1518 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1519 Disclosures 1521 As a firmware author, I want to prevent confidential information in 1522 the manifest from being disclosed when distributing manifests and 1523 firmware images. Confidential information may include information 1524 about the device these updates are being applied to as well as 1525 information in the firmware image itself. 1527 Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1529 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 1530 Unknown Formats 1532 As a Device Operator, I want devices to determine whether they can 1533 process a payload prior to downloading it. 1535 In some cases, it may be desirable for a third party to perform some 1536 processing on behalf of a target. For this to occur, the third party 1537 MUST indicate what processing occurred and how to verify it against 1538 the Trust Provisioning Authority's intent. 1540 This amounts to overriding Processing Steps (Section 3.9) and Payload 1541 Indicator (Section 3.12). 1543 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED 1544 (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 1546 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 1547 Target Firmware 1549 As a Device Operator, I want to be able to target devices for updates 1550 based on their current firmware version, so that I can control which 1551 versions are replaced with a single manifest. 1553 Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7) 1555 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 1557 As a developer, I want to be able to sign two or more versions of my 1558 firmware in a single manifest so that I can use a very simple 1559 bootloader that chooses between two or more images that are executed 1560 in-place. 1562 Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8) 1564 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 1566 As a signer for both secure execution/boot and firmware deployment, I 1567 would like to use the same signed document for both tasks so that my 1568 data size is smaller, I can share common code, and I can reduce 1569 signature verifications. 1571 Satisfied by: REQ.USE.EXEC (Section 4.5.9) 1573 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 1575 As a developer of firmware for a run-from-RAM device, I would like to 1576 use compressed images and to indicate to the bootloader that I am 1577 using a compressed image in the manifest so that it can be used with 1578 secure execution/boot. 1580 Satisfied by: REQ.USE.LOAD (Section 4.5.10) 1582 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 1584 As an operator of devices on a constrained network, I would like the 1585 manifest to be able to include a small payload in the same packet so 1586 that I can reduce network traffic. 1588 Small payloads may include, for example, wrapped content encryption 1589 keys, configuration information, public keys, authorization tokens, 1590 or X.509 certificates. 1592 Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) 1594 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 1596 As a developer for constrained devices, I want a low complexity 1597 library for processing updates so that I can fit more application 1598 code on my device. 1600 Satisfied by: REQ.USE.PARSE (Section 4.5.12) 1602 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 1604 As a Device Operator that rotates delegated authority more often than 1605 delivering firmware updates, I would like to delegate a new authority 1606 when I deliver a firmware update so that I can accomplish both tasks 1607 in a single transmission. 1609 Satisfied by: REQ.USE.DELEGATION (Section 4.5.13) 1611 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 1613 As an operator of a constrained network, I would like devices on my 1614 network to be able to evaluate the suitability of an update prior to 1615 initiating any large download so that I can prevent unnecessary 1616 consumption of bandwidth. 1618 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1620 4.5. Usability Requirements 1622 The following usability requirements satisfy the user stories listed 1623 above. 1625 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 1627 A manifest format MUST be able to carry all information required to 1628 process an update. 1630 For example: Information about which precursor image is required for 1631 a differential update must be placed in the manifest. 1633 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1634 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1636 Implemented by: Additional installation instructions (Section 3.16) 1638 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1640 A manifest format MUST be able to redirect payload fetches. This 1641 applies where two manifests are used in conjunction. For example, a 1642 Device Operator creates a manifest specifying a payload and signs it, 1643 and provides a URI for that payload. A Network Operator creates a 1644 second manifest, with a dependency on the first. They use this 1645 second manifest to override the URIs provided by the Device Operator, 1646 directing them into their own infrastructure instead. Some devices 1647 may provide this capability, while others may only look at canonical 1648 sources of firmware. For this to be possible, the device must fetch 1649 the payload, whereas a device that accepts payload pushes will ignore 1650 this feature. 1652 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1654 Implemented by: Aliases (Section 3.17) 1656 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 1658 A manifest format MUST be able to express the requirement to install 1659 one or more payloads from one or more authorities so that a multi- 1660 payload update can be described. This allows multiple parties with 1661 different permissions to collaborate in creating a single update for 1662 the IoT device, across multiple components. 1664 This requirement implies that it must be possible to construct a tree 1665 of manifests on a multi-image target. 1667 In order to enable devices with a heterogeneous storage architecture, 1668 the manifest must enable specification of both storage system and the 1669 storage location within that storage system. 1671 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1672 (Section 4.4.4) 1674 Implemented by: Dependencies, StorageIdentifier, ComponentIdentifier 1676 4.5.3.1. Example 1: Multiple Microcontrollers 1678 An IoT device with multiple microcontrollers in the same physical 1679 device will likely require multiple payloads with different component 1680 identifiers. 1682 4.5.3.2. Example 2: Code and Configuration 1684 A firmware image can be divided into two payloads: code and 1685 configuration. These payloads may require authorizations from 1686 different actors in order to install (see REQ.SEC.RIGHTS 1687 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1688 structure means that multiple manifests may be required, with a 1689 dependency structure between them. 1691 4.5.3.3. Example 3: Multiple Software Modules 1693 A firmware image can be divided into multiple functional blocks for 1694 separate testing and distribution. This means that code would need 1695 to be distributed in multiple payloads. For example, this might be 1696 desirable in order to ensure that common code between devices is 1697 identical in order to reduce distribution bandwidth. 1699 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1701 A manifest format MUST be able to carry multiple signatures so that 1702 authorizations from multiple parties with different permissions can 1703 be required in order to authorize installation of a manifest. 1705 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1707 Implemented by: Signature (Section 3.15) 1709 4.5.5. REQ.USE.IMG.FORMAT: Format Usability 1711 The manifest format MUST accommodate any payload format that an 1712 Operator wishes to use. This enables the recipient to detect which 1713 format the Operator has chosen. Some examples of payload format are: 1715 o Binary 1717 o Executable and Linkable Format (ELF) 1719 o Differential 1721 o Compressed 1723 o Packed configuration 1725 o Intel HEX 1727 o Motorola S-Record 1729 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1730 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1732 Implemented by: Payload Format (Section 3.8) 1734 4.5.6. REQ.USE.IMG.NESTED: Nested Formats 1736 The manifest format MUST accommodate nested formats, announcing to 1737 the target device all the nesting steps and any parameters used by 1738 those steps. 1740 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1742 Implemented by: Processing Steps (Section 3.9) 1744 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 1746 The manifest format MUST provide a method to specify multiple version 1747 numbers of firmware to which the manifest applies, either with a list 1748 or with range matching. 1750 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1752 Implemented by: Required Image Version List (Section 3.6) 1754 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 1756 The manifest format MUST provide a mechanism to list multiple 1757 equivalent payloads by Execute-In-Place Installation Address, 1758 including the payload digest and, optionally, payload URIs. 1760 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1762 Implemented by: XIP Address (Section 3.20) 1764 4.5.9. REQ.USE.EXEC: Executable Manifest 1766 The manifest format MUST allow to describe an executable system with 1767 a manifest on both Execute-In-Place microcontrollers and on complex 1768 operating systems. In addition, the manifest format MUST be able to 1769 express metadata, such as a kernel command-line, used by any loader 1770 or bootloader. 1772 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1774 Implemented by: Run-time metadata (Section 3.22) 1776 4.5.10. REQ.USE.LOAD: Load-Time Information 1778 The manifest format MUST enable carrying additional metadata for load 1779 time processing of a payload, such as cryptographic information, 1780 load-address, and compression algorithm. Note that load comes before 1781 execution/boot. 1783 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1785 Implemented by: Load-time metadata (Section 3.21) 1787 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope 1789 The manifest format MUST allow placing a payload in the same 1790 structure as the manifest. This may place the payload in the same 1791 packet as the manifest. 1793 Integrated payloads may include, for example, binaries as well as 1794 configuration information, and keying material. 1796 When an integrated payload is provided, this increases the size of 1797 the manifest. Manifest size can cause several processing and storage 1798 concerns that require careful consideration. The payload can prevent 1799 the whole manifest from being contained in a single network packet, 1800 which can cause fragmentation and the loss of portions of the 1801 manifest in lossy networks. This causes the need for reassembly and 1802 retransmission logic. The manifest MUST be held immutable between 1803 verification and processing (see REQ.SEC.MFST.CONST 1804 (Section 4.3.20)), so a larger manifest will consume more memory with 1805 immutability guarantees, for example internal RAM or NVRAM, or 1806 external secure memory. If the manifest exceeds the available 1807 immutable memory, then it MUST be processed modularly, evaluating 1808 each of: delegation chains, the security container, and the actual 1809 manifest, which includes verifying the integrated payload. If the 1810 security model calls for downloading the manifest and validating it 1811 before storing to NVRAM in order to prevent wear to NVRAM and energy 1812 expenditure in NVRAM, then either increasing memory allocated to 1813 manifest storage or modular processing of the received manifest may 1814 be required. While the manifest has been organised to enable this 1815 type of processing, it creates additional complexity in the parser. 1816 If the manifest is stored in NVRAM prior to processing, the 1817 integrated payload may cause the manifest to exceed the available 1818 storage. Because the manifest is received prior to validation of 1819 applicability, authority, or correctness, integrated payloads cause 1820 the recipient to expend network bandwidth and energy that may not be 1821 required if the manifest is discarded and these costs vary with the 1822 size of the integrated payload. 1824 See also: REQ.SEC.MFST.CONST (Section 4.3.20). 1826 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1828 Implemented by: Payload (Section 3.23) 1830 4.5.12. REQ.USE.PARSE: Simple Parsing 1832 The structure of the manifest MUST be simple to parse to reduce the 1833 attack vectors against manifest parsers. 1835 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1837 Implemented by: N/A 1839 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1841 A manifest format MUST enable the delivery of delegation information. 1842 This information delivers a new key with which the recipient can 1843 verify the manifest. 1845 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1847 Implemented by: Delegation Chain (Section 3.24) 1849 5. IANA Considerations 1851 This document does not require any actions by IANA. 1853 6. Acknowledgements 1855 We would like to thank our working group chairs, Dave Thaler, Russ 1856 Housley and David Waltermire, for their review comments and their 1857 support. 1859 We would like to thank the participants of the 2018 Berlin SUIT 1860 Hackathon and the June 2018 virtual design team meetings for their 1861 discussion input. In particular, we would like to thank Koen 1862 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1863 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1864 Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias 1865 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1866 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1867 Gharout, and Milen Stoychev. 1869 We would like to thank those who contributed to the development of 1870 this information model. In particular, we would like to thank 1871 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary 1872 Thomson. 1874 Finally, we would like to thank the following IESG members for their 1875 review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa 1876 Cooper, Stephen Farrell and Benjamin Kaduk. 1878 7. References 1880 7.1. Normative References 1882 [I-D.ietf-suit-architecture] 1883 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 1884 Firmware Update Architecture for Internet of Things", 1885 draft-ietf-suit-architecture-15 (work in progress), 1886 January 2021. 1888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1889 Requirement Levels", BCP 14, RFC 2119, 1890 DOI 10.17487/RFC2119, March 1997, 1891 . 1893 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1894 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1895 DOI 10.17487/RFC4122, July 2005, 1896 . 1898 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1899 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1900 May 2017, . 1902 7.2. Informative References 1904 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1905 Information Models and Data Models", RFC 3444, 1906 DOI 10.17487/RFC3444, January 2003, 1907 . 1909 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1910 . 1913 Authors' Addresses 1915 Brendan Moran 1916 Arm Limited 1918 EMail: Brendan.Moran@arm.com 1920 Hannes Tschofenig 1921 Arm Limited 1923 EMail: hannes.tschofenig@gmx.net 1925 Henk Birkholz 1926 Fraunhofer SIT 1928 EMail: henk.birkholz@sit.fraunhofer.de