idnits 2.17.1 draft-ietf-suit-information-model-11.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 (April 06, 2021) is 1110 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-15 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: October 8, 2021 H. Birkholz 6 Fraunhofer SIT 7 April 06, 2021 9 A Manifest Information Model for Firmware Updates in IoT Devices 10 draft-ietf-suit-information-model-11 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 October 8, 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 . . . . . . . . . . . . . . . . . . . 20 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 . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . . 31 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 Note that it is worthwhile to recall that a firmware update is, by 769 definition, remote code execution. Hence, if a device is configured 770 to trust an entity to provide firmware, it trusts this entity to do 771 the "right thing". Many classes of attacks can be mitigated by 772 verifying that a firmware update came from a trusted party and that 773 no rollback is taking place. However, if the trusted entity has been 774 compromised and distributes attacker-provided firmware to devices 775 then the possibilities for deference are limited. 777 4.1. Threat Model 779 The following sub-sections aim to provide information about the 780 threats that were considered, the security requirements that are 781 derived from those threats and the fields that permit implementation 782 of the security requirements. This model uses the S.T.R.I.D.E. 783 [STRIDE] approach. Each threat is classified according to: 785 o Spoofing identity 787 o Tampering with data 789 o Repudiation 791 o Information disclosure 793 o Denial of service 795 o Elevation of privilege 797 This threat model only covers elements related to the transport of 798 firmware updates. It explicitly does not cover threats outside of 799 the transport of firmware updates. For example, threats to an IoT 800 device due to physical access are out of scope. 802 4.2. Threat Descriptions 804 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 806 Classification: Elevation of Privilege 807 An attacker sends an old, but valid manifest with an old, but valid 808 firmware image to a device. If there is a known vulnerability in the 809 provided firmware image, this may allow an attacker to exploit the 810 vulnerability and gain control of the device. 812 Threat Escalation: If the attacker is able to exploit the known 813 vulnerability, then this threat can be escalated to ALL TYPES. 815 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 817 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old Firmware 819 Classification: Elevation of Privilege 821 An attacker targets a device that has been offline for a long time 822 and runs an old firmware version. The attacker sends an old, but 823 valid manifest to a device with an old, but valid firmware image. 824 The attacker-provided firmware is newer than the installed one but 825 older than the most recently available firmware. If there is a known 826 vulnerability in the provided firmware image then this may allow an 827 attacker to gain control of a device. Because the device has been 828 offline for a long time, it is unaware of any new updates. As such 829 it will treat the old manifest as the most current. 831 The exact mitigation for this threat depends on where the threat 832 comes from. This requires careful consideration by the implementor. 833 If the threat is from a network actor, including an on-path attacker, 834 or an intruder into a management system, then a user confirmation can 835 mitigate this attack, simply by displaying an expiration date and 836 requesting confirmation. On the other hand, if the user is the 837 attacker, then an online confirmation system (for example a trusted 838 timestamp server) can be used as a mitigation system. 840 Threat Escalation: If the attacker is able to exploit the known 841 vulnerability, then this threat can be escalated to ALL TYPES. 843 Mitigated by: REQ.SEC.EXP (Section 4.3.3), REQ.USE.MFST.PRE_CHECK 844 (Section 4.5.1), 846 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 848 Classification: Denial of Service 850 An attacker sends a valid firmware image, for the wrong type of 851 device, signed by an actor with firmware installation permission on 852 both types of device. The firmware is verified by the device 853 positively because it is signed by an actor with the appropriate 854 permission. This could have wide-ranging consequences. For devices 855 that are similar, it could cause minor breakage, or expose security 856 vulnerabilities. For devices that are very different, it is likely 857 to render devices inoperable. 859 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 861 For example, suppose that two vendors, Vendor A and Vendor B, adopt 862 the same trade name in different geographic regions, and they both 863 make products with the same names, or product name matching is not 864 used. This causes firmware from Vendor A to match devices from 865 Vendor B. 867 If the vendors are the firmware authorities, then devices from Vendor 868 A will reject images signed by Vendor B since they use different 869 credentials. However, if both devices trust the same Author, then, 870 devices from Vendor A could install firmware intended for devices 871 from Vendor B. 873 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 874 payload 876 Classification: Denial of Service 878 If a device misinterprets the format of the firmware image, it may 879 cause a device to install a firmware image incorrectly. An 880 incorrectly installed firmware image would likely cause the device to 881 stop functioning. 883 Threat Escalation: An attacker that can cause a device to 884 misinterpret the received firmware image may gain elevation of 885 privilege and potentially expand this to all types of threat. 887 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 889 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 890 the wrong location 892 Classification: Denial of Service 894 If a device installs a firmware image to the wrong location on the 895 device, then it is likely to break. For example, a firmware image 896 installed as an application could cause a device and/or an 897 application to stop functioning. 899 Threat Escalation: An attacker that can cause a device to 900 misinterpret the received code may gain elevation of privilege and 901 potentially expand this to all types of threat. 903 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 905 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 907 Classification: Denial of Service 909 If a device is tricked into fetching a payload for an attacker 910 controlled site, the attacker may send corrupted payloads to devices. 912 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 914 4.2.7. THREAT.NET.ONPATH: Traffic interception 916 Classification: Spoofing Identity, Tampering with Data 918 An attacker intercepts all traffic to and from a device. The 919 attacker can monitor or modify any data sent to or received from the 920 device. This can take the form of: manifests, payloads, status 921 reports, and capability reports being modified or not delivered to 922 the intended recipient. It can also take the form of analysis of 923 data sent to or from the device, either in content, size, or 924 frequency. 926 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), 927 REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC 928 (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), 929 REQ.SEC.REPORTING (Section 4.3.16) 931 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 933 Classification: Elevation of Privilege 935 An attacker replaces a newly downloaded firmware after a device 936 finishes verifying a manifest. This could cause the device to 937 execute the attacker's code. This attack likely requires physical 938 access to the device. However, it is possible that this attack is 939 carried out in combination with another threat that allows remote 940 execution. This is a typical Time Of Check/Time Of Use (TICTOC) 941 attack. 943 Threat Escalation: If the attacker is able to exploit a known 944 vulnerability, or if the attacker can supply their own firmware, then 945 this threat can be escalated to ALL TYPES. 947 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 949 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 951 Classification: Elevation of Privilege / All Types 953 If an attacker can install their firmware on a device, for example by 954 manipulating either payload or metadata, then they have complete 955 control of the device. 957 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 959 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 961 Classification: Denial of Service / All Types 963 Modifications of payloads and metadata allow an attacker to introduce 964 a number of denial of service attacks. Below are some examples. 966 An attacker sends a valid, current manifest to a device that has an 967 unexpected precursor image. If a payload format requires a precursor 968 image (for example, delta updates) and that precursor image is not 969 available on the target device, it could cause the update to break. 971 An attacker that can cause a device to install a payload against the 972 wrong precursor image could gain elevation of privilege and 973 potentially expand this to all types of threat. However, it is 974 unlikely that a valid differential update applied to an incorrect 975 precursor would result in a functional, but vulnerable firmware. 977 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 979 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 981 Classification: Denial of Service, Elevation of Privilege 983 This threat can appear in several ways, however it is ultimately 984 about ensuring that devices retain the behaviour required by their 985 owner, or operator. The owner or operator of a device typically 986 requires that the device maintain certain features, functions, 987 capabilities, behaviours, or interoperability constraints (more 988 generally, behaviour). If these requirements are broken, then a 989 device will not fulfill its purpose. Therefore, if any party other 990 than the device's owner or the owner's contracted Device Operator has 991 the ability to modify device behaviour without approval, then this 992 constitutes an elevation of privilege. 994 Similarly, a Network Operator may require that devices behave in a 995 particular way in order to maintain the integrity of the network. If 996 devices behaviour on a network can be modified without the approval 997 of the Network Operator, then this constitutes an elevation of 998 privilege with respect to the network. 1000 For example, if the owner of a device has purchased that device 1001 because of features A, B, and C, and a firmware update is issued by 1002 the manufacturer, which removes feature A, then the device may not 1003 fulfill the owner's requirements any more. In certain circumstances, 1004 this can cause significantly greater threats. Suppose that feature A 1005 is used to implement a safety-critical system, whether the 1006 manufacturer intended this behaviour or not. When unapproved 1007 firmware is installed, the system may become unsafe. 1009 In a second example, the owner or operator of a system of two or more 1010 interoperating devices needs to approve firmware for their system in 1011 order to ensure interoperability with other devices in the system. 1012 If the firmware is not qualified, the system as a whole may not work. 1013 Therefore, if a device installs firmware without the approval of the 1014 device owner or operator, this is a threat to devices or the system 1015 as a whole. 1017 Similarly, the operator of a network may need to approve firmware for 1018 devices attached to the network in order to ensure favourable 1019 operating conditions within the network. If the firmware is not 1020 qualified, it may degrade the performance of the network. Therefore, 1021 if a device installs firmware without the approval of the Network 1022 Operator, this is a threat to the network itself. 1024 Threat Escalation: If the firmware expects configuration that is 1025 present in devices deployed in Network A, but not in devices deployed 1026 in Network B, then the device may experience degraded security, 1027 leading to threats of All Types. 1029 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 1030 (Section 4.3.13) 1032 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 1033 Operator 1035 In this example, assume that Device Operators expect the rights to 1036 create firmware but that Network Operators expect the rights to 1037 qualify firmware as fit-for-purpose on their networks. Additionally, 1038 assume that Device Operators manage devices that can be deployed on 1039 any network, including Network A and B in our example. 1041 An attacker may obtain a manifest for a device on Network A. Then, 1042 this attacker sends that manifest to a device on Network B. Because 1043 Network A and Network B are under control of different Operators, and 1044 the firmware for a device on Network A has not been qualified to be 1045 deployed on Network B, the target device on Network B is now in 1046 violation of the Operator B's policy and may be disabled by this 1047 unqualified, but signed firmware. 1049 This is a denial of service because it can render devices inoperable. 1050 This is an elevation of privilege because it allows the attacker to 1051 make installation decisions that should be made by the Operator. 1053 4.2.11.2. Example 2: Single Network Operator with Multiple Device 1054 Operators 1056 Multiple devices that interoperate are used on the same network and 1057 communicate with each other. Some devices are manufactured and 1058 managed by Device Operator A and other devices by Device Operator B. 1059 A new firmware is released by Device Operator A that breaks 1060 compatibility with devices from Device Operator B. An attacker sends 1061 the new firmware to the devices managed by Device Operator A without 1062 approval of the Network Operator. This breaks the behaviour of the 1063 larger system causing denial of service and possibly other threats. 1064 Where the network is a distributed SCADA system, this could cause 1065 misbehaviour of the process that is under control. 1067 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 1068 for Vulnerability Analysis 1070 Classification: All Types 1072 An attacker wants to mount an attack on an IoT device. To prepare 1073 the attack he or she retrieves the provided firmware image and 1074 performs reverse engineering of the firmware image to analyze it for 1075 specific vulnerabilities. 1077 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1079 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 1081 Classification: Elevation of Privilege 1083 An authorized actor, but not the Author, uses an override mechanism 1084 (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information 1085 element in a manifest signed by the Author. For example, if the 1086 authorized actor overrides the digest and URI of the payload, the 1087 actor can replace the entire payload with a payload of their choice. 1089 Threat Escalation: By overriding elements such as payload 1090 installation instructions or firmware digest, this threat can be 1091 escalated to all types. 1093 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1095 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 1097 Classification: Information Disclosure 1099 A third party may be able to extract sensitive information from the 1100 manifest. 1102 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 1104 4.2.15. THREAT.IMG.EXTRA: Extra data after image 1106 Classification: All Types 1108 If a third party modifies the image so that it contains extra code 1109 after a valid, authentic image, that third party can then use their 1110 own code in order to make better use of an existing vulnerability. 1112 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 1114 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 1116 Classification: All Types 1118 If a third party obtains a key or even indirect access to a key, for 1119 example in an hardware security module (HSM), then they can perform 1120 the same actions as the legitimate owner of the key. If the key is 1121 trusted for firmware update, then the third party can perform 1122 firmware updates as though they were the legitimate owner of the key. 1124 For example, if manifest signing is performed on a server connected 1125 to the internet, an attacker may compromise the server and then be 1126 able to sign manifests, even if the keys for manifest signing are 1127 held in an HSM that is accessed by the server. 1129 Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17) 1131 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 1132 prior to signing 1134 Classification: All Types 1136 If an attacker can alter a manifest or payload before it is signed, 1137 they can perform all the same actions as the manifest author. This 1138 allows the attacker to deploy firmware updates to any devices that 1139 trust the manifest author. If an attacker can modify the code of a 1140 payload before the corresponding manifest is created, they can insert 1141 their own code. If an attacker can modify the manifest before it is 1142 signed, they can redirect the manifest to their own payload. 1144 For example, the attacker deploys malware to the developer's computer 1145 or signing service that watches manifest creation activities and 1146 inserts code into any binary that is referenced by a manifest. 1148 For example, the attacker deploys malware to the developer's computer 1149 or signing service that replaces the referenced binary (digest) and 1150 URI with the attacker's binary (digest) and URI. 1152 Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18), 1153 REQ.SEC.MFST.TRUSTED (Section 4.3.19) 1155 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 1156 authentication and use 1158 Classification: All Types 1160 If an attacker can modify a manifest after it is authenticated (Time 1161 Of Check) but before it is used (Time Of Use), then the attacker can 1162 place any content whatsoever in the manifest. 1164 Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.20) 1166 4.3. Security Requirements 1168 The security requirements here are a set of policies that mitigate 1169 the threats described in Section 4.1. 1171 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 1173 Only an actor with firmware installation authority is permitted to 1174 decide when device firmware can be installed. To enforce this rule, 1175 manifests MUST contain monotonically increasing sequence numbers. 1176 Manifests may use UTC epoch timestamps to coordinate monotonically 1177 increasing sequence numbers across many actors in many locations. If 1178 UTC epoch timestamps are used, they must not be treated as times, 1179 they must be treated only as sequence numbers. Devices must reject 1180 manifests with sequence numbers smaller than any onboard sequence 1181 number, i.e. there is no sequence number roll over. 1183 Note: This is not a firmware version field. It is a manifest 1184 sequence number. A firmware version may be rolled back by creating a 1185 new manifest for the old firmware version with a later sequence 1186 number. 1188 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 1189 Implemented by: Monotonic Sequence Number (Section 3.2) 1191 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1193 Devices MUST only apply firmware that is intended for them. Devices 1194 must know that a given update applies to their vendor, model, 1195 hardware revision, and software revision. Human-readable identifiers 1196 are often error-prone in this regard, so unique identifiers should be 1197 used instead. 1199 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1201 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1202 (Section 3.4) 1204 4.3.3. REQ.SEC.EXP: Expiration Time 1206 A firmware manifest MAY expire after a given time and devices may 1207 have a secure clock (local or remote). If a secure clock is provided 1208 and the Firmware manifest has an expiration timestamp, the device 1209 must reject the manifest if current time is later than the expiration 1210 time. 1212 Special consideration is required for end-of-life in case device will 1213 not be updated again, for example if a business stops issuing updates 1214 for a device. The last valid firmware should not have an expiration 1215 time. 1217 Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2) 1219 Implemented by: Expiration Time (Section 3.7) 1221 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1223 The authenticity of an update MUST be demonstrable. Typically, this 1224 means that updates must be digitally signed. Because the manifest 1225 contains information about how to install the update, the manifest's 1226 authenticity must also be demonstrable. To reduce the overhead 1227 required for validation, the manifest contains the cryptographic 1228 digest of the firmware image, rather than a second digital signature. 1229 The authenticity of the manifest can be verified with a digital 1230 signature or Message Authentication Code. The authenticity of the 1231 firmware image is tied to the manifest by the use of a cryptographic 1232 digest of the firmware image. 1234 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.ONPATH 1235 (Section 4.2.7) 1236 Implemented by: Signature (Section 3.15), Payload Digest 1237 (Section 3.13) 1239 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1241 The type of payload MUST be authenticated. For example, the target 1242 must know whether the payload is XIP firmware, a loadable module, or 1243 configuration data. 1245 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1247 Implemented by: Payload Format (Section 3.8), Signature 1248 (Section 3.15) 1250 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1251 Location 1253 The location on the target where the payload is to be stored MUST be 1254 authenticated. 1256 Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) 1258 Implemented by: Storage Location (Section 3.10) 1260 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 1262 The location where a target should find a payload MUST be 1263 authenticated. Remote resources need to receive an equal amount of 1264 cryptographic protection as the manifest itself, when dereferencing 1265 URIs. The security considerations of Uniform Resource Identifiers 1266 (URIs) are applicable [RFC3986]. 1268 Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.ONPATH 1269 (Section 4.2.7) 1271 Implemented by: Payload Indicator (Section 3.12) 1273 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 1275 The target SHOULD verify firmware at time of boot. This requires 1276 authenticated payload size, and digest. 1278 Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) 1280 Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) 1282 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 1284 If an update uses a differential compression method, it MUST specify 1285 the digest of the precursor image and that digest MUST be 1286 authenticated. 1288 Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10) 1290 Implemented by: Precursor Image Digest (Section 3.5) 1292 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs 1294 The identifiers that specify firmware compatibility MUST be 1295 authenticated to ensure that only compatible firmware is installed on 1296 a target device. 1298 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1300 Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition 1301 (Section 3.4) 1303 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 1305 If a device grants different rights to different actors, exercising 1306 those rights MUST be accompanied by proof of those rights, in the 1307 form of proof of authenticity. Authenticity mechanisms, such as 1308 those required in REQ.SEC.AUTHENTIC (Section 4.3.4), can be used to 1309 prove authenticity. 1311 For example, if a device has a policy that requires that firmware 1312 have both an Authorship right and a Qualification right and if that 1313 device grants Authorship and Qualification rights to different 1314 parties, such as a Device Operator and a Network Operator, 1315 respectively, then the firmware cannot be installed without proof of 1316 rights from both the Device Operator and the Network Operator. 1318 Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11) 1320 Implemented by: Signature (Section 3.15) 1322 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 1324 The manifest information model MUST enable encrypted payloads. 1325 Encryption helps to prevent third parties, including attackers, from 1326 reading the content of the firmware image. This can protect against 1327 confidential information disclosures and discovery of vulnerabilities 1328 through reverse engineering. Therefore the manifest must convey the 1329 information required to allow an intended recipient to decrypt an 1330 encrypted payload. 1332 Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.ONPATH 1333 (Section 4.2.7) 1335 Implemented by: Encryption Wrapper (Section 3.19) 1337 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 1339 If a device grants different rights to different actors, then an 1340 exercise of those rights MUST be validated against a list of rights 1341 for the actor. This typically takes the form of an Access Control 1342 List (ACL). ACLs are applied to two scenarios: 1344 1. An ACL decides which elements of the manifest may be overridden 1345 and by which actors. 1347 2. An ACL decides which component identifier/storage identifier 1348 pairs can be written by which actors. 1350 Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), 1351 THREAT.UPD.UNAPPROVED (Section 4.2.11) 1353 Implemented by: Client-side code, not specified in manifest. 1355 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 1357 A manifest format MUST allow encryption of selected parts of the 1358 manifest or encryption of the entire manifest to prevent sensitive 1359 content of the firmware metadata to be leaked. 1361 Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.ONPATH 1362 (Section 4.2.7) 1364 Implemented by: Manifest Encryption Wrapper / Transport Security 1366 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 1368 The digest SHOULD cover all available space in a fixed-size storage 1369 location. Variable-size storage locations MUST be restricted to 1370 exactly the size of deployed payload. This prevents any data from 1371 being distributed without being covered by the digest. For example, 1372 XIP microcontrollers typically have fixed-size storage. These 1373 devices should deploy a digest that covers the deployed firmware 1374 image, concatenated with the default erased value of any remaining 1375 space. 1377 Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) 1379 Implemented by: Payload Digests (Section 3.13) 1381 4.3.16. REQ.SEC.REPORTING: Secure Reporting 1383 Status reports from the device to any remote system MUST be performed 1384 over an authenticated, confidential channel in order to prevent 1385 modification or spoofing of the reports. 1387 Mitigates: THREAT.NET.ONPATH (Section 4.2.7) 1389 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 1391 Cryptographic keys for signing/authenticating manifests SHOULD be 1392 stored in a manner that is inaccessible to networked devices, for 1393 example in an HSM, or an air-gapped computer. This protects against 1394 an attacker obtaining the keys. 1396 Keys SHOULD be stored in a way that limits the risk of a legitimate, 1397 but compromised, entity (such as a server or developer computer) 1398 issuing signing requests. 1400 Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) 1402 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment 1404 Manifests SHOULD be verified prior to deployment. This reduces 1405 problems that may arise with devices installing firmware images that 1406 damage devices unintentionally. 1408 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1410 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted 1411 environment 1413 For high risk deployments, such as large numbers of devices or 1414 critical function devices, manifests SHOULD be constructed in an 1415 environment that is protected from interference, such as an air- 1416 gapped computer. Note that a networked computer connected to an HSM 1417 does not fulfill this requirement (see THREAT.MFST.MODIFICATION 1418 (Section 4.2.17)). 1420 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1422 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between check and 1423 use 1425 Both the manifest and any data extracted from it MUST be held 1426 immutable between its authenticity verification (time of check) and 1427 its use (time of use). To make this guarantee, the manifest MUST fit 1428 within an internal memory or a secure memory, such as encrypted 1429 memory. The recipient SHOULD defend the manifest from tampering by 1430 code or hardware resident in the recipient, for example other 1431 processes or debuggers. 1433 If an application requires that the manifest is verified before 1434 storing it, then this means the manifest MUST fit in RAM. 1436 Mitigates: THREAT.MFST.TOCTOU (Section 4.2.18) 1438 4.4. User Stories 1440 User stories provide expected use cases. These are used to feed into 1441 usability requirements. 1443 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 1445 As a Device Operator, I want to provide my devices with additional 1446 installation instructions so that I can keep process details out of 1447 my payload data. 1449 Some installation instructions might be: 1451 o Use a table of hashes to ensure that each block of the payload is 1452 validated before writing. 1454 o Do not report progress. 1456 o Pre-cache the update, but do not install. 1458 o Install the pre-cached update matching this manifest. 1460 o Install this update immediately, overriding any long-running 1461 tasks. 1463 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1465 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 1467 As a designer of a resource-constrained IoT device, I want bad 1468 updates to fail as early as possible to preserve battery life and 1469 limit consumed bandwidth. 1471 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1473 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 1475 As a Device Operator, I would like to be able to override the non- 1476 critical information in the manifest so that I can control my devices 1477 more precisely. The authority to override this information is 1478 provided via the installation of a limited trust anchor by another 1479 authority. 1481 Some examples of potentially overridable information: 1483 o URIs (Section 3.12): this allows the Device Operator to direct 1484 devices to their own infrastructure in order to reduce network 1485 load. 1487 o Conditions: this allows the Device Operator to pose additional 1488 constraints on the installation of the manifest. 1490 o Directives (Section 3.16): this allows the Device Operator to add 1491 more instructions such as time of installation. 1493 o Processing Steps (Section 3.9): If an intermediary performs an 1494 action on behalf of a device, it may need to override the 1495 processing steps. It is still possible for a device to verify the 1496 final content and the result of any processing step that specifies 1497 a digest. Some processing steps should be non-overridable. 1499 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1501 4.4.4. USER_STORY.COMPONENT: Component Update 1503 As a Device Operator, I want to divide my firmware into components, 1504 so that I can reduce the size of updates, make different parties 1505 responsible for different components, and divide my firmware into 1506 frequently updated and infrequently updated components. 1508 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1510 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations 1512 As a Device Operator, I want to ensure the quality of a firmware 1513 update before installing it, so that I can ensure interoperability of 1514 all devices in my product family. I want to restrict the ability to 1515 make changes to my devices to require my express approval. 1517 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), 1518 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1520 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1522 As a Device Operator, I want to be able to send multiple payload 1523 formats to suit the needs of my update, so that I can optimise the 1524 bandwidth used by my devices. 1526 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) 1528 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1529 Disclosures 1531 As a firmware author, I want to prevent confidential information in 1532 the manifest from being disclosed when distributing manifests and 1533 firmware images. Confidential information may include information 1534 about the device these updates are being applied to as well as 1535 information in the firmware image itself. 1537 Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1539 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 1540 Unknown Formats 1542 As a Device Operator, I want devices to determine whether they can 1543 process a payload prior to downloading it. 1545 In some cases, it may be desirable for a third party to perform some 1546 processing on behalf of a target. For this to occur, the third party 1547 MUST indicate what processing occurred and how to verify it against 1548 the Trust Provisioning Authority's intent. 1550 This amounts to overriding Processing Steps (Section 3.9) and Payload 1551 Indicator (Section 3.12). 1553 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED 1554 (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 1556 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 1557 Target Firmware 1559 As a Device Operator, I want to be able to target devices for updates 1560 based on their current firmware version, so that I can control which 1561 versions are replaced with a single manifest. 1563 Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7) 1565 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 1567 As a developer, I want to be able to sign two or more versions of my 1568 firmware in a single manifest so that I can use a very simple 1569 bootloader that chooses between two or more images that are executed 1570 in-place. 1572 Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8) 1574 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 1576 As a signer for both secure execution/boot and firmware deployment, I 1577 would like to use the same signed document for both tasks so that my 1578 data size is smaller, I can share common code, and I can reduce 1579 signature verifications. 1581 Satisfied by: REQ.USE.EXEC (Section 4.5.9) 1583 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 1585 As a developer of firmware for a run-from-RAM device, I would like to 1586 use compressed images and to indicate to the bootloader that I am 1587 using a compressed image in the manifest so that it can be used with 1588 secure execution/boot. 1590 Satisfied by: REQ.USE.LOAD (Section 4.5.10) 1592 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 1594 As an operator of devices on a constrained network, I would like the 1595 manifest to be able to include a small payload in the same packet so 1596 that I can reduce network traffic. 1598 Small payloads may include, for example, wrapped content encryption 1599 keys, configuration information, public keys, authorization tokens, 1600 or X.509 certificates. 1602 Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) 1604 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 1606 As a developer for constrained devices, I want a low complexity 1607 library for processing updates so that I can fit more application 1608 code on my device. 1610 Satisfied by: REQ.USE.PARSE (Section 4.5.12) 1612 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 1614 As a Device Operator that rotates delegated authority more often than 1615 delivering firmware updates, I would like to delegate a new authority 1616 when I deliver a firmware update so that I can accomplish both tasks 1617 in a single transmission. 1619 Satisfied by: REQ.USE.DELEGATION (Section 4.5.13) 1621 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 1623 As an operator of a constrained network, I would like devices on my 1624 network to be able to evaluate the suitability of an update prior to 1625 initiating any large download so that I can prevent unnecessary 1626 consumption of bandwidth. 1628 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1630 4.5. Usability Requirements 1632 The following usability requirements satisfy the user stories listed 1633 above. 1635 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 1637 A manifest format MUST be able to carry all information required to 1638 process an update. 1640 For example: Information about which precursor image is required for 1641 a differential update must be placed in the manifest. 1643 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1644 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1646 Implemented by: Additional installation instructions (Section 3.16) 1648 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1650 A manifest format MUST be able to redirect payload fetches. This 1651 applies where two manifests are used in conjunction. For example, a 1652 Device Operator creates a manifest specifying a payload and signs it, 1653 and provides a URI for that payload. A Network Operator creates a 1654 second manifest, with a dependency on the first. They use this 1655 second manifest to override the URIs provided by the Device Operator, 1656 directing them into their own infrastructure instead. Some devices 1657 may provide this capability, while others may only look at canonical 1658 sources of firmware. For this to be possible, the device must fetch 1659 the payload, whereas a device that accepts payload pushes will ignore 1660 this feature. 1662 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1664 Implemented by: Aliases (Section 3.17) 1666 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 1668 A manifest format MUST be able to express the requirement to install 1669 one or more payloads from one or more authorities so that a multi- 1670 payload update can be described. This allows multiple parties with 1671 different permissions to collaborate in creating a single update for 1672 the IoT device, across multiple components. 1674 This requirement implies that it must be possible to construct a tree 1675 of manifests on a multi-image target. 1677 In order to enable devices with a heterogeneous storage architecture, 1678 the manifest must enable specification of both storage system and the 1679 storage location within that storage system. 1681 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1682 (Section 4.4.4) 1684 Implemented by: Dependencies, StorageIdentifier, ComponentIdentifier 1686 4.5.3.1. Example 1: Multiple Microcontrollers 1688 An IoT device with multiple microcontrollers in the same physical 1689 device will likely require multiple payloads with different component 1690 identifiers. 1692 4.5.3.2. Example 2: Code and Configuration 1694 A firmware image can be divided into two payloads: code and 1695 configuration. These payloads may require authorizations from 1696 different actors in order to install (see REQ.SEC.RIGHTS 1697 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1698 structure means that multiple manifests may be required, with a 1699 dependency structure between them. 1701 4.5.3.3. Example 3: Multiple Software Modules 1703 A firmware image can be divided into multiple functional blocks for 1704 separate testing and distribution. This means that code would need 1705 to be distributed in multiple payloads. For example, this might be 1706 desirable in order to ensure that common code between devices is 1707 identical in order to reduce distribution bandwidth. 1709 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1711 A manifest format MUST be able to carry multiple signatures so that 1712 authorizations from multiple parties with different permissions can 1713 be required in order to authorize installation of a manifest. 1715 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1717 Implemented by: Signature (Section 3.15) 1719 4.5.5. REQ.USE.IMG.FORMAT: Format Usability 1721 The manifest format MUST accommodate any payload format that an 1722 Operator wishes to use. This enables the recipient to detect which 1723 format the Operator has chosen. Some examples of payload format are: 1725 o Binary 1727 o Executable and Linkable Format (ELF) 1729 o Differential 1731 o Compressed 1733 o Packed configuration 1735 o Intel HEX 1737 o Motorola S-Record 1739 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1740 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1742 Implemented by: Payload Format (Section 3.8) 1744 4.5.6. REQ.USE.IMG.NESTED: Nested Formats 1746 The manifest format MUST accommodate nested formats, announcing to 1747 the target device all the nesting steps and any parameters used by 1748 those steps. 1750 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1752 Implemented by: Processing Steps (Section 3.9) 1754 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 1756 The manifest format MUST provide a method to specify multiple version 1757 numbers of firmware to which the manifest applies, either with a list 1758 or with range matching. 1760 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1762 Implemented by: Required Image Version List (Section 3.6) 1764 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 1766 The manifest format MUST provide a mechanism to list multiple 1767 equivalent payloads by Execute-In-Place Installation Address, 1768 including the payload digest and, optionally, payload URIs. 1770 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1772 Implemented by: XIP Address (Section 3.20) 1774 4.5.9. REQ.USE.EXEC: Executable Manifest 1776 The manifest format MUST allow to describe an executable system with 1777 a manifest on both Execute-In-Place microcontrollers and on complex 1778 operating systems. In addition, the manifest format MUST be able to 1779 express metadata, such as a kernel command-line, used by any loader 1780 or bootloader. 1782 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1784 Implemented by: Run-time metadata (Section 3.22) 1786 4.5.10. REQ.USE.LOAD: Load-Time Information 1788 The manifest format MUST enable carrying additional metadata for load 1789 time processing of a payload, such as cryptographic information, 1790 load-address, and compression algorithm. Note that load comes before 1791 execution/boot. 1793 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1795 Implemented by: Load-time metadata (Section 3.21) 1797 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope 1799 The manifest format MUST allow placing a payload in the same 1800 structure as the manifest. This may place the payload in the same 1801 packet as the manifest. 1803 Integrated payloads may include, for example, binaries as well as 1804 configuration information, and keying material. 1806 When an integrated payload is provided, this increases the size of 1807 the manifest. Manifest size can cause several processing and storage 1808 concerns that require careful consideration. The payload can prevent 1809 the whole manifest from being contained in a single network packet, 1810 which can cause fragmentation and the loss of portions of the 1811 manifest in lossy networks. This causes the need for reassembly and 1812 retransmission logic. The manifest MUST be held immutable between 1813 verification and processing (see REQ.SEC.MFST.CONST 1814 (Section 4.3.20)), so a larger manifest will consume more memory with 1815 immutability guarantees, for example internal RAM or NVRAM, or 1816 external secure memory. If the manifest exceeds the available 1817 immutable memory, then it MUST be processed modularly, evaluating 1818 each of: delegation chains, the security container, and the actual 1819 manifest, which includes verifying the integrated payload. If the 1820 security model calls for downloading the manifest and validating it 1821 before storing to NVRAM in order to prevent wear to NVRAM and energy 1822 expenditure in NVRAM, then either increasing memory allocated to 1823 manifest storage or modular processing of the received manifest may 1824 be required. While the manifest has been organised to enable this 1825 type of processing, it creates additional complexity in the parser. 1826 If the manifest is stored in NVRAM prior to processing, the 1827 integrated payload may cause the manifest to exceed the available 1828 storage. Because the manifest is received prior to validation of 1829 applicability, authority, or correctness, integrated payloads cause 1830 the recipient to expend network bandwidth and energy that may not be 1831 required if the manifest is discarded and these costs vary with the 1832 size of the integrated payload. 1834 See also: REQ.SEC.MFST.CONST (Section 4.3.20). 1836 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1838 Implemented by: Payload (Section 3.23) 1840 4.5.12. REQ.USE.PARSE: Simple Parsing 1842 The structure of the manifest MUST be simple to parse to reduce the 1843 attack vectors against manifest parsers. 1845 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1847 Implemented by: N/A 1849 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1851 A manifest format MUST enable the delivery of delegation information. 1852 This information delivers a new key with which the recipient can 1853 verify the manifest. 1855 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1857 Implemented by: Delegation Chain (Section 3.24) 1859 5. IANA Considerations 1861 This document does not require any actions by IANA. 1863 6. Acknowledgements 1865 We would like to thank our working group chairs, Dave Thaler, Russ 1866 Housley and David Waltermire, for their review comments and their 1867 support. 1869 We would like to thank the participants of the 2018 Berlin SUIT 1870 Hackathon and the June 2018 virtual design team meetings for their 1871 discussion input. In particular, we would like to thank Koen 1872 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1873 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1874 Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias 1875 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1876 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1877 Gharout, and Milen Stoychev. 1879 We would like to thank those who contributed to the development of 1880 this information model. In particular, we would like to thank 1881 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary 1882 Thomson. 1884 Finally, we would like to thank the following IESG members for their 1885 review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa 1886 Cooper, Stephen Farrell and Benjamin Kaduk. 1888 7. References 1890 7.1. Normative References 1892 [I-D.ietf-suit-architecture] 1893 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 1894 Firmware Update Architecture for Internet of Things", 1895 draft-ietf-suit-architecture-15 (work in progress), 1896 January 2021. 1898 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1899 Requirement Levels", BCP 14, RFC 2119, 1900 DOI 10.17487/RFC2119, March 1997, 1901 . 1903 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1904 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1905 DOI 10.17487/RFC4122, July 2005, 1906 . 1908 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1909 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1910 May 2017, . 1912 7.2. Informative References 1914 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1915 Information Models and Data Models", RFC 3444, 1916 DOI 10.17487/RFC3444, January 2003, 1917 . 1919 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1920 Resource Identifier (URI): Generic Syntax", STD 66, 1921 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1922 . 1924 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1925 . 1928 Authors' Addresses 1930 Brendan Moran 1931 Arm Limited 1933 EMail: Brendan.Moran@arm.com 1935 Hannes Tschofenig 1936 Arm Limited 1938 EMail: hannes.tschofenig@gmx.net 1940 Henk Birkholz 1941 Fraunhofer SIT 1943 EMail: henk.birkholz@sit.fraunhofer.de