idnits 2.17.00 (12 Aug 2021) /tmp/idnits47204/draft-ietf-suit-information-model-09.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 (February 22, 2021) is 452 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: August 26, 2021 H. Birkholz 6 Fraunhofer SIT 7 February 22, 2021 9 A Manifest Information Model for Firmware Updates in IoT Devices 10 draft-ietf-suit-information-model-09 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 August 26, 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. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 62 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 63 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 64 3.1. Version ID of the manifest structure . . . . . . . . . . 7 65 3.2. Monotonic Sequence Number . . . . . . . . . . . . . . . . 7 66 3.3. Vendor ID . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 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 . . . . . . . . . . . . . . . 11 75 3.7. Expiration Time . . . . . . . . . . . . . . . . . . . . . 11 76 3.8. Payload Format . . . . . . . . . . . . . . . . . . . . . 11 77 3.9. Processing Steps . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . 13 82 3.11. Component Identifier . . . . . . . . . . . . . . . . . . 13 83 3.12. Payload Indicator . . . . . . . . . . . . . . . . . . . . 13 84 3.13. Payload Digests . . . . . . . . . . . . . . . . . . . . . 13 85 3.14. Size . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 3.15. Manifest Envelope Element: Signature . . . . . . . . . . 14 87 3.16. Additional installation instructions . . . . . . . . . . 15 88 3.17. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 3.18. Dependencies . . . . . . . . . . . . . . . . . . . . . . 15 90 3.19. Encryption Wrapper . . . . . . . . . . . . . . . . . . . 15 91 3.20. XIP Address . . . . . . . . . . . . . . . . . . . . . . . 16 92 3.21. Load-time metadata . . . . . . . . . . . . . . . . . . . 16 93 3.22. Run-time metadata . . . . . . . . . . . . . . . . . . . . 16 94 3.23. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 3.24. Manifest Envelope Element: Delegation Chain . . . . . . . 17 97 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 98 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 99 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 18 100 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 18 101 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old 102 Firmware . . . . . . . . . . . . . . . . . . . . . . 18 103 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 19 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 . . . . . . . . . . . . 20 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 . . . . . . . 21 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 . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . 25 126 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 127 authentication and use . . . . . . . . . . . . . . . 25 128 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 26 129 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 26 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 . . . . 27 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 28 137 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 28 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 . . . 29 144 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 29 145 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 30 146 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 30 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 . . . . . . . . . . . . . . . . . . . . . 31 152 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 153 trusted environment . . . . . . . . . . . . . . . . . 31 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 . . . . . . . 32 160 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 161 Elements . . . . . . . . . . . . . . . . . . . . . . 32 162 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 33 163 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 33 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 . . . . . . . . . . . . . 34 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 . . . . . . 35 177 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . 38 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 . . . . . . . . . 39 193 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 39 194 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 40 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 . . . . . . . . . . . . . . . . . . . . . . . . . 41 200 7.1. Normative References . . . . . . . . . . . . . . . . . . 41 201 7.2. Informative References . . . . . . . . . . . . . . . . . 41 202 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 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. 232 Because this document covers a wide range of user stories and a wide 233 range of threats, not all information elements apply to all 234 scenarios. As a result, various information elements are optional to 235 implement and optional to use, depending on which threats exist in a 236 particular domain of application and which user stories are important 237 for deployments. 239 Elements marked as REQUIRED provide baseline security and usability 240 properties that are expected to be required to be implemented for 241 most applications. Elements marked as RECOMMENDED provide important 242 security or usability properties that are needed on most devices. 243 Elements marked as OPTIONAL enable security or usability properties 244 that are useful in some applications. 246 2. Conventions and Terminology 248 This document uses terms defined in [I-D.ietf-suit-architecture]. 249 The term 'Operator' refers to both Device and Network Operator. 251 Secure time and secure clock refer to a set of requirements on time 252 sources. For local time sources, this primarily means that the clock 253 must be monotonically increasing, including across power cycles, 254 firmware updates, etc. For remote time sources, the provided time 255 must be guaranteed to be correct to within some predetermined bounds, 256 whenever the time source is accessible. 258 The term Envelope is used to describe an encoding that allows the 259 bundling of a manifest with related information elements that are not 260 directly contained within the manifest. 262 The term Payload is used to describe the data that is delivered to a 263 device during an update. This is distinct from a "firmware image", 264 as described in [I-D.ietf-suit-architecture], because the payload is 265 often in an intermediate state, such as being encrypted, compressed 266 and/or encoded as a differential update. The payload, taken in 267 isolation, is often not the final firmware image. 269 2.1. Requirements Notation 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 273 "OPTIONAL" in this document are to be interpreted as described in 274 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 275 capitals, as shown here. 277 Unless otherwise stated these words apply to the design of the 278 manifest format, not its implementation or application. 280 3. Manifest Information Elements 282 Each manifest information element is anchored in a security 283 requirement or a usability requirement. The manifest elements are 284 described below, justified by their requirements. 286 3.1. Version ID of the manifest structure 288 An identifier that describes which iteration of the manifest format 289 is contained in the structure. 291 This element is REQUIRED to be implemented to allow devices to 292 identify the version of the manifest data model that is in use. 294 3.2. Monotonic Sequence Number 296 A monotonically increasing sequence number. For convenience, the 297 monotonic sequence number MAY be a UTC timestamp. This allows global 298 synchronisation of sequence numbers without any additional 299 management. This number MUST be possible to extract with a simple, 300 minimal parser so that code choosing one out of several manifests can 301 choose which is the latest without fully parsing a complex structure. 303 This element is REQUIRED to be implemented and is necessary to 304 prevent malicious actors from reverting a firmware update against the 305 policies of the relevant authority. 307 Implements: REQ.SEC.SEQUENCE (Section 4.3.1) 309 3.3. Vendor ID 311 Vendor IDs must be unique. This is to prevent similarly, or 312 identically named entities from different geographic regions from 313 colliding in their customer's infrastructure. Recommended practice 314 is to use [RFC4122] version 5 UUIDs with the vendor's domain name and 315 the DNS name space ID. Other options include type 1 and type 4 316 UUIDs. 318 Vendor ID is not intended to be a human-readable element. It is 319 intended for binary match/mismatch comparison only. 321 The use of a Vendor ID is RECOMMENDED. It helps to distinguish 322 between identically named products from different vendors. 324 Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), 325 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 327 3.3.1. Example: Domain Name-based UUIDs 329 Vendor A creates a UUID based on a domain name it controls, such as 330 vendorId = UUID5(DNS, "vendor-a.example") 332 Because the DNS infrastructure prevents multiple registrations of the 333 same domain name, this UUID is (with very high probability) 334 guaranteed to be unique. Because the domain name is known, this UUID 335 is reproducible. Type 1 and type 4 UUIDs produce similar guarantees 336 of uniqueness, but not reproducibility. 338 This approach creates a contention when a vendor changes its name or 339 relinquishes control of a domain name. In this scenario, it is 340 possible that another vendor would start using that same domain name. 341 However, this UUID is not proof of identity; a device's trust in a 342 vendor must be anchored in a cryptographic key, not a UUID. 344 3.4. Class ID 346 A device "Class" is a set of different device types that can accept 347 the same firmware update without modification. Class IDs MUST be 348 unique within the scope of a Vendor ID. This is to prevent 349 similarly, or identically named devices colliding in their customer's 350 infrastructure. 352 Recommended practice is to use [RFC4122] version 5 UUIDs with as much 353 information as necessary to define firmware compatibility. Possible 354 information used to derive the class UUID includes: 356 o model name or number 358 o hardware revision 360 o runtime library version 362 o bootloader version 364 o ROM revision 366 o silicon batch number 368 The Class Identifier UUID SHOULD use the Vendor ID as the name space 369 ID. Other options include version 1 and 4 UUIDs. Classes MAY be 370 more fine-grained granular than is required to identify firmware 371 compatibility. Classes MUST NOT be less granular than is required to 372 identify firmware compatibility. Devices MAY have multiple Class 373 IDs. 375 Class ID is not intended to be a human-readable element. It is 376 intended for binary match/mismatch comparison only. 378 The use of Class ID is RECOMMENDED. It allows devices to determine 379 applicability of a firmware in an unambiguous way. 381 If Class ID is not implemented, then each logical device class MUST 382 use a unique trust anchor for authorization. 384 Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), 385 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 387 3.4.1. Example 1: Different Classes 389 Vendor A creates product Z and product Y. The firmware images of 390 products Z and Y are not interchangeable. Vendor A creates UUIDs as 391 follows: 393 o vendorId = UUID5(DNS, "vendor-a.com") 395 o ZclassId = UUID5(vendorId, "Product Z") 397 o YclassId = UUID5(vendorId, "Product Y") 399 This ensures that Vendor A's Product Z cannot install firmware for 400 Product Y and Product Y cannot install firmware for Product Z. 402 3.4.2. Example 2: Upgrading Class ID 404 Vendor A creates product X. Later, Vendor A adds a new feature to 405 product X, creating product X v2. Product X requires a firmware 406 update to work with firmware intended for product X v2. 408 Vendor A creates UUIDs as follows: 410 o vendorId = UUID5(DNS, "vendor-a.com") 412 o XclassId = UUID5(vendorId, "Product X") 414 o Xv2classId = UUID5(vendorId, "Product X v2") 416 When product X receives the firmware update necessary to be 417 compatible with product X v2, part of the firmware update changes the 418 class ID to Xv2classId. 420 3.4.3. Example 3: Shared Functionality 422 Vendor A produces two products, product X and product Y. These 423 components share a common core (such as an operating system), but 424 have different applications. The common core and the applications 425 can be updated independently. To enable X and Y to receive the same 426 common core update, they require the same class ID. To ensure that 427 only product X receives application X and only product Y receives 428 application Y, product X and product Y must have different class IDs. 429 The vendor creates Class IDs as follows: 431 o vendorId = UUID5(DNS, "vendor-a.com") 433 o XclassId = UUID5(vendorId, "Product X") 435 o YclassId = UUID5(vendorId, "Product Y") 437 o CommonClassId = UUID5(vendorId, "common core") 439 Product X matches against both XclassId and CommonClassId. Product Y 440 matches against both YclassId and CommonClassId. 442 3.4.4. Example 4: White-labelling 444 Vendor A creates a product A and its firmware. Vendor B sells the 445 product under its own name as Product B with some customised 446 configuration. The vendors create the Class IDs as follows: 448 o vendorIdA = UUID5(DNS, "vendor-a.com") 450 o classIdA = UUID5(vendorIdA, "Product A-Unlabelled") 452 o vendorIdB = UUID5(DNS, "vendor-b.com") 454 o classIdB = UUID5(vendorIdB, "Product B") 456 The product will match against each of these class IDs. If Vendor A 457 and Vendor B provide different components for the device, the 458 implementor MAY choose to make ID matching scoped to each component. 459 Then, the vendorIdA, classIdA match the component ID supplied by 460 Vendor A, and the vendorIdB, classIdB match the component ID supplied 461 by Vendor B. 463 3.5. Precursor Image Digest Condition 465 When a precursor image is required by the payload format (for 466 example, differential updates), a precursor image digest condition 467 MUST be present. The precursor image MAY be installed or stored as a 468 candidate. 470 This element is OPTIONAL to implement. 472 Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 474 3.6. Required Image Version List 476 Payloads may only be applied to a specific firmware version or 477 firmware versions. For example, a payload containing a differential 478 update may be applied only to a specific firmware version. 480 When a payload applies to multiple versions of a firmware, the 481 required image version list specifies which firmware versions must be 482 present for the update to be applied. This allows the update author 483 to target specific versions of firmware for an update, while 484 excluding those to which it should not or cannot be applied. 486 This element is OPTIONAL to implement. 488 Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) 490 3.7. Expiration Time 492 This element tells a device the time at which the manifest expires 493 and should no longer be used. This element SHOULD be used where a 494 secure source of time is provided and firmware is intended to expire 495 predictably. This element may also be displayed (e.g. via an app) 496 for user confirmation since users typically have a reliable knowledge 497 of the date. 499 Special consideration is required for end-of-life if a firmware will 500 not be updated again, for example if a business stops issuing updates 501 to a device. In this case the last valid firmware should not have an 502 expiration time. 504 This element is OPTIONAL to implement. 506 Implements: REQ.SEC.EXP (Section 4.3.3) 508 3.8. Payload Format 510 The format of the payload MUST be indicated to devices in an 511 unambiguous way. This element provides a mechanism to describe the 512 payload format, within the signed metadata. 514 This element is REQUIRED to be implemented and MUST be used to enable 515 devices to decode payloads correctly. 517 Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT 518 (Section 4.5.5) 520 3.9. Processing Steps 522 A representation of the Processing Steps required to decode a 523 payload, in particular those that are compressed, packed, or 524 encrypted. The representation MUST describe which algorithm(s) is 525 used and any additional parameters required by the algorithm(s). The 526 representation MAY group Processing Steps together in predefined 527 combinations. 529 A Processing Step MAY indicate the expected digest of the payload 530 after the processing is complete. 532 Processing steps are RECOMMENDED to implement. 534 Implements: REQ.USE.IMG.NESTED (Section 4.5.6) 536 3.10. Storage Location 538 This element tells the device where to store a payload within a given 539 component. The device can use this to establish which permissions 540 are necessary and the physical storage location to use. 542 This element is REQUIRED to be implemented and MUST be present to 543 enable devices to store payloads to the correct location. 545 Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 547 3.10.1. Example 1: Two Storage Locations 549 A device supports two components: an OS and an application. These 550 components can be updated independently, expressing dependencies to 551 ensure compatibility between the components. The Author chooses two 552 storage identifiers: 554 o "OS" 556 o "APP" 558 3.10.2. Example 2: File System 560 A device supports a full-featured filesystem. The Author chooses to 561 use the storage identifier as the path at which to install the 562 payload. The payload may be a tarball, in which case, it unpacks the 563 tarball into the specified path. 565 3.10.3. Example 3: Flash Memory 567 A device supports flash memory. The Author chooses to make the 568 storage identifier the offset where the image should be written. 570 3.11. Component Identifier 572 In a device with more than one storage subsystem, a storage 573 identifier is insufficient to identify where and how to store a 574 payload. To resolve this, a component identifier indicates which 575 part of the storage architecture is targeted by the payload. 577 This element is OPTIONAL to implement and only necessary in devices 578 with multiple storage subsystems. 580 N.B. A serialization MAY choose to combine Component Identifier and 581 Storage Location (Section 3.10) 583 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 585 3.12. Payload Indicator 587 This element provides the information required for the device to 588 acquire the payload. This can be encoded in several ways: 590 o One URI 592 o A list of URIs 594 o A prioritised list of URIs 596 o A list of signed URIs 598 This element is OPTIONAL to implement and only needed when the target 599 device does not intrinsically know where to find the payload. 601 N.B. Devices will typically require URIs. 603 Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 605 3.13. Payload Digests 607 This element contains one or more digests of one or more payloads. 608 This allows the target device to ensure authenticity of the 609 payload(s). A manifest format MUST provide a mechanism to select one 610 payload from a list based on system parameters, such as Execute-In- 611 Place Installation Address. 613 This element is REQUIRED to be implemented and necessary to ensure 614 the authenticity and integrity of the payload. Support for more than 615 one digest is OPTIONAL to implement in a recipient device. 617 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT 618 (Section 4.5.8) 620 3.14. Size 622 The size of the payload in bytes. 624 Variable-size storage locations MUST be set to exactly the size 625 listed in this element. 627 This element is REQUIRED to be implemented and informs the target 628 device how big of a payload to expect. Without it, devices are 629 exposed to some classes of denial of service attack. 631 Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) 633 3.15. Manifest Envelope Element: Signature 635 The Signature element MUST contain all the information necessary to 636 cryptographically verify the contents of the manifest against a root 637 of trust. Because the Signature element authenticates the manifest, 638 it cannot be contained within the manifest. Instead, the manifest is 639 either contained within the signature element, or the signature 640 element is a member of the Manifest Envelope and bundled with the 641 manifest. 643 The Signature element MUST support multiple signers and multiple 644 signing algorithms. It is OPTIONAL for a serialization to 645 authenticate multiple manifests with a single Signature element. 647 This element is REQUIRED to be implemented in non-dependency 648 manifests and represents the foundation of all security properties of 649 the manifest. Manifests, which are included as dependencies by 650 another manifests, SHOULD include a signature so that the recipient 651 can distinguish between different actors with different permissions. 653 The design of the manifest security framework MUST NOT rely on 654 channel security. Where public key operations require too many 655 resources, the use of message authentication codes is RECOMMENDED 656 with a per-device symmetric key. 658 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS 659 (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) 661 3.16. Additional installation instructions 663 Machine-readable instructions that the device should execute when 664 processing the manifest. This information is distinct from the 665 information necessary to process a payload. Additional installation 666 instructions include information such as update timing (for example, 667 install only on Sunday, at 0200), procedural considerations (for 668 example, shut down the equipment under control before executing the 669 update), pre- and post-installation steps (for example, run a 670 script). Other installation instructions could include requesting 671 user confirmation before installing. 673 This element is OPTIONAL to implement. 675 Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 677 3.17. Aliases 679 A mechanism for a manifest to augment or replace URIs or URI lists 680 defined by one or more of its dependencies. 682 This element is OPTIONAL to implement and enables some user stories. 684 Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 686 3.18. Dependencies 688 A list of other manifests that are required by the current manifest. 689 Manifests are identified an unambiguous way, such as a cryptographic 690 digest. 692 This element is REQUIRED to use in deployments that include both 693 multiple authorities and multiple payloads. 695 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 697 3.19. Encryption Wrapper 699 Encrypting firmware images requires symmetric content encryption 700 keys. The encryption wrapper provides the information needed for a 701 device to obtain or locate a key that it uses to decrypt the 702 firmware. This MAY be included in a decryption step contained in 703 Processing Steps (Section 3.9). 705 This element is REQUIRED to use for encrypted payloads, 707 Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 709 3.20. XIP Address 711 In order to support execute in place (XIP) systems with multiple 712 possible base addresses, it is necessary to specify which address the 713 payload is linked for. 715 For example a microcontroller may have a simple bootloader that 716 chooses one of two images to boot. That microcontroller then needs 717 to choose one of two firmware images to install, based on which of 718 its two images is older. 720 This element is OPTIONAL to implement. 722 Implements: REQ.USE.IMG.SELECT (Section 4.5.8) 724 3.21. Load-time metadata 726 Load-time metadata provides the device with information that it needs 727 in order to load one or more images. This metadata MAY include any 728 of: 730 o the source 732 o the destination 734 o cryptographic information 736 o decompression information 738 o unpacking information 740 Typically, loading is done by copying an image from its permanent 741 storage location into its active use location. The metadata allows 742 operations such as decryption, decompression, and unpacking to be 743 performed during that copy. 745 This element is OPTIONAL to implement. 747 Implements: REQ.USE.LOAD (Section 4.5.10) 749 3.22. Run-time metadata 751 Run-time metadata provides the device with any extra information 752 needed to boot the device. This may include information such as the 753 entry-point of an XIP image or the kernel command-line of a Linux 754 image. 756 This element is OPTIONAL to implement. 758 Implements: REQ.USE.EXEC (Section 4.5.9) 760 3.23. Payload 762 The Payload element is contained within the manifest or manifest 763 envelope. This enables the manifest and payload to be delivered 764 simultaneously. Typically this is used for delivering small payloads 765 such as cryptographic keys, or configuration data. 767 This element is OPTIONAL to implement. 769 Implements: REQ.USE.PAYLOAD (Section 4.5.11) 771 3.24. Manifest Envelope Element: Delegation Chain 773 It is OPTIONAL for the Signature (Section 3.15) to cover the 774 delegation chain. The delegation chain offers enhanced authorization 775 functionality via authorization tokens. Each token itself is 776 protected and does not require another layer of protection. Because 777 the delegation chain is needed to verify the signature, it must be 778 placed in the Manifest Envelope, rather than the Manifest. 780 This element is OPTIONAL to implement. 782 Implements: REQ.USE.DELEGATION (Section 4.5.13) 784 4. Security Considerations 786 The following sub-sections describe the threat model, user stories, 787 security requirements, and usability requirements. This section also 788 provides the motivations for each of the manifest information 789 elements. 791 4.1. Threat Model 793 The following sub-sections aim to provide information about the 794 threats that were considered, the security requirements that are 795 derived from those threats and the fields that permit implementation 796 of the security requirements. This model uses the S.T.R.I.D.E. 797 [STRIDE] approach. Each threat is classified according to: 799 o Spoofing identity 801 o Tampering with data 803 o Repudiation 805 o Information disclosure 806 o Denial of service 808 o Elevation of privilege 810 This threat model only covers elements related to the transport of 811 firmware updates. It explicitly does not cover threats outside of 812 the transport of firmware updates. For example, threats to an IoT 813 device due to physical access are out of scope. 815 4.2. Threat Descriptions 817 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 819 Classification: Elevation of Privilege 821 An attacker sends an old, but valid manifest with an old, but valid 822 firmware image to a device. If there is a known vulnerability in the 823 provided firmware image, this may allow an attacker to exploit the 824 vulnerability and gain control of the device. 826 Threat Escalation: If the attacker is able to exploit the known 827 vulnerability, then this threat can be escalated to ALL TYPES. 829 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 831 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old Firmware 833 Classification: Elevation of Privilege 835 An attacker targets a device that has been offline for a long time 836 and runs an old firmware version. The attacker sends an old, but 837 valid manifest to a device with an old, but valid firmware image. 838 The attacker-provided firmware is newer than the installed one but 839 older than the most recently available firmware. If there is a known 840 vulnerability in the provided firmware image then this may allow an 841 attacker to gain control of a device. Because the device has been 842 offline for a long time, it is unaware of any new updates. As such 843 it will treat the old manifest as the most current. 845 The exact mitigation for this threat depends on where the threat 846 comes from. This requires careful consideration by the implementor. 847 If the threat is from a network actor, including an on-path attacker, 848 or an intruder into a management system, then a user confirmation can 849 mitigate this attack, simply by displaying an expiration date and 850 requesting confirmation. On the other hand, if the user is the 851 attacker, then an online confirmation system (for example a trusted 852 timestamp server) can be used as a mitigation system. 854 Threat Escalation: If the attacker is able to exploit the known 855 vulnerability, then this threat can be escalated to ALL TYPES. 857 Mitigated by: REQ.SEC.EXP (Section 4.3.3), REQ.USE.MFST.PRE_CHECK 858 (Section 4.5.1), 860 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 862 Classification: Denial of Service 864 An attacker sends a valid firmware image, for the wrong type of 865 device, signed by an actor with firmware installation permission on 866 both types of device. The firmware is verified by the device 867 positively because it is signed by an actor with the appropriate 868 permission. This could have wide-ranging consequences. For devices 869 that are similar, it could cause minor breakage, or expose security 870 vulnerabilities. For devices that are very different, it is likely 871 to render devices inoperable. 873 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 875 4.2.3.1. Example: 877 Suppose that two vendors, Vendor A and Vendor B, adopt the same trade 878 name in different geographic regions, and they both make products 879 with the same names, or product name matching is not used. This 880 causes firmware from Vendor A to match devices from Vendor B. 882 If the vendors are the firmware authorities, then devices from Vendor 883 A will reject images signed by Vendor B since they use different 884 credentials. However, if both devices trust the same Author, then, 885 devices from Vendor A could install firmware intended for devices 886 from Vendor B. 888 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 889 payload 891 Classification: Denial of Service 893 If a device misinterprets the format of the firmware image, it may 894 cause a device to install a firmware image incorrectly. An 895 incorrectly installed firmware image would likely cause the device to 896 stop functioning. 898 Threat Escalation: An attacker that can cause a device to 899 misinterpret the received firmware image may gain elevation of 900 privilege and potentially expand this to all types of threat. 902 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 904 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 905 the wrong location 907 Classification: Denial of Service 909 If a device installs a firmware image to the wrong location on the 910 device, then it is likely to break. For example, a firmware image 911 installed as an application could cause a device and/or an 912 application to stop functioning. 914 Threat Escalation: An attacker that can cause a device to 915 misinterpret the received code may gain elevation of privilege and 916 potentially expand this to all types of threat. 918 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 920 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 922 Classification: Denial of Service 924 If a device does not know where to obtain the payload for an update, 925 it may be redirected to an attacker's server. This would allow an 926 attacker to provide broken payloads to devices. 928 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 930 4.2.7. THREAT.NET.ONPATH: Traffic interception 932 Classification: Spoofing Identity, Tampering with Data 934 An attacker intercepts all traffic to and from a device. The 935 attacker can monitor or modify any data sent to or received from the 936 device. This can take the form of: manifests, payloads, status 937 reports, and capability reports being modified or not delivered to 938 the intended recipient. It can also take the form of analysis of 939 data sent to or from the device, either in content, size, or 940 frequency. 942 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), 943 REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC 944 (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), 945 REQ.SEC.REPORTING (Section 4.3.16) 947 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 949 Classification: Elevation of Privilege 951 An attacker replaces a newly downloaded firmware after a device 952 finishes verifying a manifest. This could cause the device to 953 execute the attacker's code. This attack likely requires physical 954 access to the device. However, it is possible that this attack is 955 carried out in combination with another threat that allows remote 956 execution. This is a typical Time Of Check/Time Of Use threat. 958 Threat Escalation: If the attacker is able to exploit a known 959 vulnerability, or if the attacker can supply their own firmware, then 960 this threat can be escalated to ALL TYPES. 962 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 964 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 966 Classification: Elevation of Privilege / All Types 968 If an attacker can install their firmware on a device, for example by 969 manipulating either payload or metadata, then they have complete 970 control of the device. 972 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 974 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 976 Classification: Denial of Service / All Types 978 An attacker sends a valid, current manifest to a device that has an 979 unexpected precursor image. If a payload format requires a precursor 980 image (for example, delta updates) and that precursor image is not 981 available on the target device, it could cause the update to break. 983 An attacker that can cause a device to install a payload against the 984 wrong precursor image could gain elevation of privilege and 985 potentially expand this to all types of threat. However, it is 986 unlikely that a valid differential update applied to an incorrect 987 precursor would result in a functional, but vulnerable firmware. 989 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 991 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 993 Classification: Denial of Service, Elevation of Privilege 995 This threat can appear in several ways, however it is ultimately 996 about ensuring that devices retain the behaviour required by their 997 owner, or operator. The owner or operator of a device typically 998 requires that the device maintain certain features, functions, 999 capabilities, behaviours, or interoperability constraints (more 1000 generally, behaviour). If these requirements are broken, then a 1001 device will not fulfill its purpose. Therefore, if any party other 1002 than the device's owner or the owner's contracted Device Operator has 1003 the ability to modify device behaviour without approval, then this 1004 constitutes an elevation of privilege. 1006 Similarly, a Network Operator may require that devices behave in a 1007 particular way in order to maintain the integrity of the network. If 1008 devices behaviour on a network can be modified without the approval 1009 of the Network Operator, then this constitutes an elevation of 1010 privilege with respect to the network. 1012 For example, if the owner of a device has purchased that device 1013 because of Features A, B, and C, and a firmware update is issued by 1014 the manufacturer, which removes Feature A, then the device may not 1015 fulfill the owner's requirements any more. In certain circumstances, 1016 this can cause significantly greater threats. Suppose that Feature A 1017 is used to implement a safety-critical system, whether the 1018 manufacturer intended this behaviour or not. When unapproved 1019 firmware is installed, the system may become unsafe. 1021 In a second example, the owner or operator of a system of two or more 1022 interoperating devices needs to approve firmware for their system in 1023 order to ensure interoperability with other devices in the system. 1024 If the firmware is not qualified, the system as a whole may not work. 1025 Therefore, if a device installs firmware without the approval of the 1026 device owner or operator, this is a threat to devices or the system 1027 as a whole. 1029 Similarly, the operator of a network may need to approve firmware for 1030 devices attached to the network in order to ensure favourable 1031 operating conditions within the network. If the firmware is not 1032 qualified, it may degrade the performance of the network. Therefore, 1033 if a device installs firmware without the approval of the Network 1034 Operator, this is a threat to the network itself. 1036 Threat Escalation: If the firmware expects configuration that is 1037 present in devices deployed in Network A, but not in devices deployed 1038 in Network B, then the device may experience degraded security, 1039 leading to threats of All Types. 1041 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 1042 (Section 4.3.13) 1044 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 1045 Operator 1047 In this example, assume that Device Operators expect the rights to 1048 create firmware but that Network Operators expect the rights to 1049 qualify firmware as fit-for-purpose on their networks. Additionally, 1050 assume that Device Operators manage devices that can be deployed on 1051 any network, including Network A and B in our example. 1053 An attacker may obtain a manifest for a device on Network A. Then, 1054 this attacker sends that manifest to a device on Network B. Because 1055 Network A and Network B are under control of different Operators, and 1056 the firmware for a device on Network A has not been qualified to be 1057 deployed on Network B, the target device on Network B is now in 1058 violation of the Operator B's policy and may be disabled by this 1059 unqualified, but signed firmware. 1061 This is a denial of service because it can render devices inoperable. 1062 This is an elevation of privilege because it allows the attacker to 1063 make installation decisions that should be made by the Operator. 1065 4.2.11.2. Example 2: Single Network Operator with Multiple Device 1066 Operators 1068 Multiple devices that interoperate are used on the same network and 1069 communicate with each other. Some devices are manufactured and 1070 managed by Device Operator A and other devices by Device Operator B. 1071 A new firmware is released by Device Operator A that breaks 1072 compatibility with devices from Device Operator B. An attacker sends 1073 the new firmware to the devices managed by Device Operator A without 1074 approval of the Network Operator. This breaks the behaviour of the 1075 larger system causing denial of service and possibly other threats. 1076 Where the network is a distributed SCADA system, this could cause 1077 misbehaviour of the process that is under control. 1079 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 1080 for Vulnerability Analysis 1082 Classification: All Types 1084 An attacker wants to mount an attack on an IoT device. To prepare 1085 the attack he or she retrieves the provided firmware image and 1086 performs reverse engineering of the firmware image to analyze it for 1087 specific vulnerabilities. 1089 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1091 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 1093 Classification: Elevation of Privilege 1095 An authorized actor, but not the Author, uses an override mechanism 1096 (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information 1097 element in a manifest signed by the Author. For example, if the 1098 authorized actor overrides the digest and URI of the payload, the 1099 actor can replace the entire payload with a payload of their choice. 1101 Threat Escalation: By overriding elements such as payload 1102 installation instructions or firmware digest, this threat can be 1103 escalated to all types. 1105 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1107 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 1109 Classification: Information Disclosure 1111 A third party may be able to extract sensitive information from the 1112 manifest. 1114 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 1116 4.2.15. THREAT.IMG.EXTRA: Extra data after image 1118 Classification: All Types 1120 If a third party modifies the image so that it contains extra code 1121 after a valid, authentic image, that third party can then use their 1122 own code in order to make better use of an existing vulnerability. 1124 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 1126 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 1128 Classification: All Types 1130 If a third party obtains a key or even indirect access to a key, for 1131 example in an HSM, then they can perform the same actions as the 1132 legitimate owner of the key. If the key is trusted for firmware 1133 update, then the third party can perform firmware updates as though 1134 they were the legitimate owner of the key. 1136 For example, if manifest signing is performed on a server connected 1137 to the internet, an attacker may compromise the server and then be 1138 able to sign manifests, even if the keys for manifest signing are 1139 held in an HSM that is accessed by the server. 1141 Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17) 1143 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 1144 prior to signing 1146 Classification: All Types 1148 If an attacker can alter a manifest or payload before it is signed, 1149 they can perform all the same actions as the manifest author. This 1150 allows the attacker to deploy firmware updates to any devices that 1151 trust the manifest author. If an attacker can modify the code of a 1152 payload before the corresponding manifest is created, they can insert 1153 their own code. If an attacker can modify the manifest before it is 1154 signed, they can redirect the manifest to their own payload. 1156 For example, the attacker deploys malware to the developer's computer 1157 or signing service that watches manifest creation activities and 1158 inserts code into any binary that is referenced by a manifest. 1160 For example, the attacker deploys malware to the developer's computer 1161 or signing service that replaces the referenced binary (digest) and 1162 URI with the attacker's binary (digest) and URI. 1164 Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18), 1165 REQ.SEC.MFST.TRUSTED (Section 4.3.19) 1167 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 1168 authentication and use 1170 Classification: All Types 1172 If an attacker can modify a manifest after it is authenticated (Time 1173 Of Check) but before it is used (Time Of Use), then the attacker can 1174 place any content whatsoever in the manifest. 1176 Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.20) 1178 4.3. Security Requirements 1180 The security requirements here are a set of policies that mitigate 1181 the threats described in Section 4.1. 1183 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 1185 Only an actor with firmware installation authority is permitted to 1186 decide when device firmware can be installed. To enforce this rule, 1187 manifests MUST contain monotonically increasing sequence numbers. 1188 Manifests MAY use UTC epoch timestamps to coordinate monotonically 1189 increasing sequence numbers across many actors in many locations. If 1190 UTC epoch timestamps are used, they MUST NOT be treated as times, 1191 they MUST be treated only as sequence numbers. Devices MUST reject 1192 manifests with sequence numbers smaller than any onboard sequence 1193 number. 1195 Note: This is not a firmware version. It is a manifest sequence 1196 number. A firmware version may be rolled back by creating a new 1197 manifest for the old firmware version with a later sequence number. 1199 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 1201 Implemented by: Monotonic Sequence Number (Section 3.2) 1203 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1205 Devices MUST only apply firmware that is intended for them. Devices 1206 must know that a given update applies to their vendor, model, 1207 hardware revision, and software revision. Human-readable identifiers 1208 are often error-prone in this regard, so unique identifiers SHOULD be 1209 used instead. 1211 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1213 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1214 (Section 3.4) 1216 4.3.3. REQ.SEC.EXP: Expiration Time 1218 A firmware manifest MAY expire after a given time. Devices MAY 1219 provide a secure clock (local or remote). If a secure clock is 1220 provided and the Firmware manifest has an expiration timestamp, the 1221 device MUST reject the manifest if current time is later than the 1222 expiration time. 1224 Special consideration is required for end-of-life: if a firmware will 1225 not be updated again, for example if a business stops issuing updates 1226 to a device. The last valid firmware should not have an expiration 1227 time. 1229 Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2) 1231 Implemented by: Expiration Time (Section 3.7) 1233 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1235 The authenticity of an update MUST be demonstrable. Typically, this 1236 means that updates must be digitally signed. Because the manifest 1237 contains information about how to install the update, the manifest's 1238 authenticity MUST also be demonstrable. To reduce the overhead 1239 required for validation, the manifest contains the cryptographic 1240 digest of the firmware image, rather than a second digital signature. 1241 The authenticity of the manifest can be verified with a digital 1242 signature or Message Authentication Code. The authenticity of the 1243 firmware image is tied to the manifest by the use of a cryptographic 1244 digest of the firmware image. 1246 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.ONPATH 1247 (Section 4.2.7) 1249 Implemented by: Signature (Section 3.15), Payload Digest 1250 (Section 3.13) 1252 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1254 The type of payload (which may be independent of format) MUST be 1255 authenticated. For example, the target must know whether the payload 1256 is XIP firmware, a loadable module, or configuration data. 1258 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1260 Implemented by: Payload Format (Section 3.8), Signature 1261 (Section 3.15) 1263 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1264 Location 1266 The location on the target where the payload is to be stored MUST be 1267 authenticated. 1269 Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) 1271 Implemented by: Storage Location (Section 3.10) 1273 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 1275 The location where a target should find a payload MUST be 1276 authenticated. 1278 Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.ONPATH 1279 (Section 4.2.7) 1281 Implemented by: Payload Indicator (Section 3.12) 1283 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 1285 The target SHOULD verify firmware at time of boot. This requires 1286 authenticated payload size, and digest. 1288 Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) 1290 Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) 1292 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 1294 If an update uses a differential compression method, it MUST specify 1295 the digest of the precursor image and that digest MUST be 1296 authenticated. 1298 Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10) 1300 Implemented by: Precursor Image Digest (Section 3.5) 1302 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs 1304 The identifiers that specify firmware compatibility MUST be 1305 authenticated to ensure that only compatible firmware is installed on 1306 a target device. 1308 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1310 Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition 1311 (Section 3.4) 1313 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 1315 If a device grants different rights to different actors, exercising 1316 those rights MUST be accompanied by proof of those rights, in the 1317 form of proof of authenticity. Authenticity mechanisms such as those 1318 required in REQ.SEC.AUTHENTIC (Section 4.3.4) can be used to prove 1319 authenticity. 1321 For example, if a device has a policy that requires that firmware 1322 have both an Authorship right and a Qualification right and if that 1323 device grants Authorship and Qualification rights to different 1324 parties, such as a Device Operator and a Network Operator, 1325 respectively, then the firmware cannot be installed without proof of 1326 rights from both the Device Operator and the Network Operator. 1328 Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11) 1330 Implemented by: Signature (Section 3.15) 1332 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 1334 The manifest information model MUST enable encrypted payloads. 1335 Encryption helps to prevent third parties, including attackers, from 1336 reading the content of the firmware image. This can protect against 1337 confidential information disclosures and discovery of vulnerabilities 1338 through reverse engineering. Therefore the manifest must convey the 1339 information required to allow an intended recipient to decrypt an 1340 encrypted payload. 1342 Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.ONPATH 1343 (Section 4.2.7) 1345 Implemented by: Encryption Wrapper (Section 3.19) 1347 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 1349 If a device grants different rights to different actors, then an 1350 exercise of those rights MUST be validated against a list of rights 1351 for the actor. This typically takes the form of an Access Control 1352 List (ACL). ACLs are applied to two scenarios: 1354 1. An ACL decides which elements of the manifest may be overridden 1355 and by which actors. 1357 2. An ACL decides which component identifier/storage identifier 1358 pairs can be written by which actors. 1360 Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), 1361 THREAT.UPD.UNAPPROVED (Section 4.2.11) 1363 Implemented by: Client-side code, not specified in manifest. 1365 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 1367 It MUST be possible to encrypt part or all of the manifest. This may 1368 be accomplished with either transport encryption or with at-rest 1369 encryption. 1371 Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.ONPATH 1372 (Section 4.2.7) 1374 Implemented by: External Encryption Wrapper / Transport Security 1376 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 1378 The digest SHOULD cover all available space in a fixed-size storage 1379 location. Variable-size storage locations MUST be restricted to 1380 exactly the size of deployed payload. This prevents any data from 1381 being distributed without being covered by the digest. For example, 1382 XIP microcontrollers typically have fixed-size storage. These 1383 devices should deploy a digest that covers the deployed firmware 1384 image, concatenated with the default erased value of any remaining 1385 space. 1387 Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) 1389 Implemented by: Payload Digests (Section 3.13) 1391 4.3.16. REQ.SEC.REPORTING: Secure Reporting 1393 Status reports from the device to any remote system MUST be performed 1394 over an authenticated, confidential channel in order to prevent 1395 modification or spoofing of the reports. 1397 Mitigates: THREAT.NET.ONPATH (Section 4.2.7) 1399 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 1401 Cryptographic keys for signing/authenticating manifests SHOULD be 1402 stored in a manner that is inaccessible to networked devices, for 1403 example in an HSM, or an air-gapped computer. This protects against 1404 an attacker obtaining the keys. 1406 Keys SHOULD be stored in a way that limits the risk of a legitimate, 1407 but compromised, entity (such as a server or developer computer) 1408 issuing signing requests. 1410 Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) 1412 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment 1414 Manifests SHOULD be parsed and examined prior to deployment to 1415 validate that their contents have not been modified during creation 1416 and signing. 1418 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1420 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted 1421 environment 1423 For high risk deployments, such as large numbers of devices or 1424 critical function devices, manifests SHOULD be constructed in an 1425 environment that is protected from interference, such as an air- 1426 gapped computer. Note that a networked computer connected to an HSM 1427 does not fulfill this requirement (see THREAT.MFST.MODIFICATION 1428 (Section 4.2.17)). 1430 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1432 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between check and 1433 use 1435 Both the manifest and any data extracted from it MUST be held 1436 immutable between its authenticity verification (time of check) and 1437 its use (time of use). To make this guarantee, the manifest MUST fit 1438 within an internal memory or a secure memory, such as encrypted 1439 memory. The recipient SHOULD defend the manifest from tampering by 1440 code or hardware resident in the recipient, for example other 1441 processes or debuggers. 1443 If an application requires that the manifest is verified before 1444 storing it, then this means the manifest MUST fit in RAM. 1446 Mitigates: THREAT.MFST.TOCTOU (Section 4.2.18) 1448 4.4. User Stories 1450 User stories provide expected use cases. These are used to feed into 1451 usability requirements. 1453 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 1455 As a Device Operator, I want to provide my devices with additional 1456 installation instructions so that I can keep process details out of 1457 my payload data. 1459 Some installation instructions might be: 1461 o Use a table of hashes to ensure that each block of the payload is 1462 validated before writing. 1464 o Do not report progress. 1466 o Pre-cache the update, but do not install. 1468 o Install the pre-cached update matching this manifest. 1470 o Install this update immediately, overriding any long-running 1471 tasks. 1473 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1475 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 1477 As a designer of a resource-constrained IoT device, I want bad 1478 updates to fail as early as possible to preserve battery life and 1479 limit consumed bandwidth. 1481 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1483 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 1485 As a Device Operator, I would like to be able to override the non- 1486 critical information in the manifest so that I can control my devices 1487 more precisely. The authority to override this information is 1488 provided via the installation of a limited trust anchor by another 1489 authority. 1491 Some examples of potentially overridable information: 1493 o URIs (Section 3.12): this allows the Device Operator to direct 1494 devices to their own infrastructure in order to reduce network 1495 load. 1497 o Conditions: this allows the Device Operator to pose additional 1498 constraints on the installation of the manifest. 1500 o Directives (Section 3.16): this allows the Device Operator to add 1501 more instructions such as time of installation. 1503 o Processing Steps (Section 3.9): If an intermediary performs an 1504 action on behalf of a device, it may need to override the 1505 processing steps. It is still possible for a device to verify the 1506 final content and the result of any processing step that specifies 1507 a digest. Some processing steps should be non-overridable. 1509 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1511 4.4.4. USER_STORY.COMPONENT: Component Update 1513 As a Device Operator, I want to divide my firmware into components, 1514 so that I can reduce the size of updates, make different parties 1515 responsible for different components, and divide my firmware into 1516 frequently updated and infrequently updated components. 1518 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1520 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations 1522 As a Device Operator, I want to ensure the quality of a firmware 1523 update before installing it, so that I can ensure interoperability of 1524 all devices in my product family. I want to restrict the ability to 1525 make changes to my devices to require my express approval. 1527 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), 1528 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1530 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1532 As a Device Operator, I want to be able to send multiple payload 1533 formats to suit the needs of my update, so that I can optimise the 1534 bandwidth used by my devices. 1536 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) 1538 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1539 Disclosures 1541 As a firmware author, I want to prevent confidential information in 1542 the manifest from being disclosed when distributing manifests and 1543 firmware images. Confidential information may include information 1544 about the device these updates are being applied to as well as 1545 information in the firmware image itself. 1547 Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1549 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 1550 Unknown Formats 1552 As a Device Operator, I want devices to determine whether they can 1553 process a payload prior to downloading it. 1555 In some cases, it may be desirable for a third party to perform some 1556 processing on behalf of a target. For this to occur, the third party 1557 MUST indicate what processing occurred and how to verify it against 1558 the Trust Provisioning Authority's intent. 1560 This amounts to overriding Processing Steps (Section 3.9) and Payload 1561 Indicator (Section 3.12). 1563 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED 1564 (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 1566 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 1567 Target Firmware 1569 As a Device Operator, I want to be able to target devices for updates 1570 based on their current firmware version, so that I can control which 1571 versions are replaced with a single manifest. 1573 Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7) 1575 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 1577 As a developer, I want to be able to sign two or more versions of my 1578 firmware in a single manifest so that I can use a very simple 1579 bootloader that chooses between two or more images that are executed 1580 in-place. 1582 Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8) 1584 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 1586 As a signer for both secure execution/boot and firmware deployment, I 1587 would like to use the same signed document for both tasks so that my 1588 data size is smaller, I can share common code, and I can reduce 1589 signature verifications. 1591 Satisfied by: REQ.USE.EXEC (Section 4.5.9) 1593 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 1595 As a developer of firmware for a run-from-RAM device, I would like to 1596 use compressed images and to indicate to the bootloader that I am 1597 using a compressed image in the manifest so that it can be used with 1598 secure execution/boot. 1600 Satisfied by: REQ.USE.LOAD (Section 4.5.10) 1602 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 1604 As an operator of devices on a constrained network, I would like the 1605 manifest to be able to include a small payload in the same packet so 1606 that I can reduce network traffic. 1608 Small payloads may include, for example, wrapped encryption keys, 1609 configuration information, public keys, authorization tokens, or 1610 X.509 certificates. 1612 Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) 1614 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 1616 As a developer for constrained devices, I want a low complexity 1617 library for processing updates so that I can fit more application 1618 code on my device. 1620 Satisfied by: REQ.USE.PARSE (Section 4.5.12) 1622 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 1624 As a Device Operator that rotates delegated authority more often than 1625 delivering firmware updates, I would like to delegate a new authority 1626 when I deliver a firmware update so that I can accomplish both tasks 1627 in a single transmission. 1629 Satisfied by: REQ.USE.DELEGATION (Section 4.5.13) 1631 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 1633 As an operator of a constrained network, I would like devices on my 1634 network to be able to evaluate the suitability of an update prior to 1635 initiating any large download so that I can prevent unnecessary 1636 consumption of bandwidth. 1638 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1640 4.5. Usability Requirements 1642 The following usability requirements satisfy the user stories listed 1643 above. 1645 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 1647 It MUST be possible for a manifest author to place ALL information 1648 required to process an update in the manifest. 1650 For example: Information about which precursor image is required for 1651 a differential update MUST be placed in the manifest, not in the 1652 differential compression header. 1654 For example: Information about an installation-time confirmation 1655 system that must be used to allow the installation to proceed. 1657 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1658 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1660 Implemented by: Additional installation instructions (Section 3.16) 1662 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1664 It MUST be possible to redirect payload fetches. This applies where 1665 two manifests are used in conjunction. For example, a Device 1666 Operator creates a manifest specifying a payload and signs it, and 1667 provides a URI for that payload. A Network Operator creates a second 1668 manifest, with a dependency on the first. They use this second 1669 manifest to override the URIs provided by the Device Operator, 1670 directing them into their own infrastructure instead. Some devices 1671 may provide this capability, while others may only look at canonical 1672 sources of firmware. For this to be possible, the device must fetch 1673 the payload, whereas a device that accepts payload pushes will ignore 1674 this feature. 1676 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1678 Implemented by: Aliases (Section 3.17) 1680 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 1682 It MUST be possible to express the requirement to install one or more 1683 payloads from one or more authorities so that a multi-payload update 1684 can be described. This allows multiple parties with different 1685 permissions to collaborate in creating a single update for the IoT 1686 device, across multiple components. 1688 This requirement effectively means that it must be possible to 1689 construct a tree of manifests on a multi-image target. 1691 In order to enable devices with a heterogeneous storage architecture, 1692 the manifest must enable specification of both storage system and the 1693 storage location within that storage system. 1695 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1696 (Section 4.4.4) 1697 Implemented by: Dependencies, StorageIdentifier, ComponentIdentifier 1699 4.5.3.1. Example 1: Multiple Microcontrollers 1701 An IoT device with multiple microcontrollers in the same physical 1702 device will likely require multiple payloads with different component 1703 identifiers. 1705 4.5.3.2. Example 2: Code and Configuration 1707 A firmware image can be divided into two payloads: code and 1708 configuration. These payloads may require authorizations from 1709 different actors in order to install (see REQ.SEC.RIGHTS 1710 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1711 structure means that multiple manifests may be required, with a 1712 dependency structure between them. 1714 4.5.3.3. Example 3: Multiple Software Modules 1716 A firmware image can be divided into multiple functional blocks for 1717 separate testing and distribution. This means that code would need 1718 to be distributed in multiple payloads. For example, this might be 1719 desirable in order to ensure that common code between devices is 1720 identical in order to reduce distribution bandwidth. 1722 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1724 It MUST be possible to authenticate a manifest multiple times so that 1725 authorizations from multiple parties with different permissions can 1726 be required in order to authorize installation of a manifest. 1728 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1730 Implemented by: Signature (Section 3.15) 1732 4.5.5. REQ.USE.IMG.FORMAT: Format Usability 1734 The manifest format MUST accommodate any payload format that an 1735 Operator wishes to use. This enables the recipient to detect which 1736 format the Operator has chosen. Some examples of payload format are: 1738 o Binary 1740 o Executable and Linkable Format (ELF) 1742 o Differential 1744 o Compressed 1745 o Packed configuration 1747 o Intel HEX 1749 o Motorola S-Record 1751 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1752 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1754 Implemented by: Payload Format (Section 3.8) 1756 4.5.6. REQ.USE.IMG.NESTED: Nested Formats 1758 The manifest format MUST accommodate nested formats, announcing to 1759 the target device all the nesting steps and any parameters used by 1760 those steps. 1762 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1764 Implemented by: Processing Steps (Section 3.9) 1766 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 1768 The manifest format MUST provide a method to specify multiple version 1769 numbers of firmware to which the manifest applies, either with a list 1770 or with range matching. 1772 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1774 Implemented by: Required Image Version List (Section 3.6) 1776 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 1778 The manifest format MUST provide a mechanism to list multiple 1779 equivalent payloads by Execute-In-Place Installation Address, 1780 including the payload digest and, optionally, payload URIs. 1782 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1784 Implemented by: XIP Address (Section 3.20) 1786 4.5.9. REQ.USE.EXEC: Executable Manifest 1788 It MUST be possible to describe an executable system with a manifest 1789 on both Execute-In-Place microcontrollers and on complex operating 1790 systems. This requires the manifest to specify the digest of each 1791 statically linked dependency. In addition, the manifest format MUST 1792 be able to express metadata, such as a kernel command-line, used by 1793 any loader or bootloader. 1795 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1797 Implemented by: Run-time metadata (Section 3.22) 1799 4.5.10. REQ.USE.LOAD: Load-Time Information 1801 It MUST be possible to specify additional metadata for load time 1802 processing of a payload, such as cryptographic information, load- 1803 address, and compression algorithm. 1805 N.B. load comes before exec/boot. 1807 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1809 Implemented by: Load-time metadata (Section 3.21) 1811 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope 1813 It MUST be possible to place a payload in the same structure as the 1814 manifest. This may place the payload in the same packet as the 1815 manifest. 1817 Integrated payloads may include, for example, wrapped encryption 1818 keys, configuration information, public keys, authorization tokens, 1819 or X.509 certificates. 1821 When an integrated payload is provided, this increases the size of 1822 the manifest. Manifest size can cause several processing and storage 1823 concerns that require careful consideration. The payload can prevent 1824 the whole manifest from being contained in a single network packet, 1825 which can cause fragmentation and the loss of portions of the 1826 manifest in lossy networks. This causes the need for reassembly and 1827 retransmission logic. The manifest MUST be held immutable between 1828 verification and processing (see REQ.SEC.MFST.CONST 1829 (Section 4.3.20)), so a larger manifest will consume more memory with 1830 immutability guarantees, for example internal RAM or NVRAM, or 1831 external secure memory. If the manifest exceeds the available 1832 immutable memory, then it MUST be processed modularly, evaluating 1833 each of: delegation chains, the security container, and the actual 1834 manifest, which includes verifying the integrated payload. If the 1835 security model calls for downloading the manifest and validating it 1836 before storing to NVRAM in order to prevent wear to NVRAM and energy 1837 expenditure in NVRAM, then either increasing memory allocated to 1838 manifest storage or modular processing of the received manifest may 1839 be required. While the manifest has been organised to enable this 1840 type of processing, it creates additional complexity in the parser. 1841 If the manifest is stored in NVRAM prior to processing, the 1842 integrated payload may cause the manifest to exceed the available 1843 storage. Because the manifest is received prior to validation of 1844 applicability, authority, or correctness, integrated payloads cause 1845 the recipient to expend network bandwidth and energy that may not be 1846 required if the manifest is discarded and these costs vary with the 1847 size of the integrated payload. 1849 See also: REQ.SEC.MFST.CONST (Section 4.3.20). 1851 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1853 Implemented by: Payload (Section 3.23) 1855 4.5.12. REQ.USE.PARSE: Simple Parsing 1857 The structure of the manifest MUST be simple to parse, without need 1858 for a general-purpose parser. 1860 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1862 Implemented by: N/A 1864 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1866 Any manifest format MUST enable the delivery of a key claim with, but 1867 not authenticated by, a manifest. This key claim delivers a new key 1868 with which the recipient can verify the manifest. 1870 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1872 Implemented by: Delegation Chain (Section 3.24) 1874 5. IANA Considerations 1876 This document does not require any actions by IANA. 1878 6. Acknowledgements 1880 We would like to thank our working group chairs, Dave Thaler, Russ 1881 Housley and David Waltermire, for their review comments and their 1882 support. 1884 We would like to thank the participants of the 2018 Berlin SUIT 1885 Hackathon and the June 2018 virtual design team meetings for their 1886 discussion input. In particular, we would like to thank Koen 1887 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1888 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1889 Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias 1890 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1891 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1892 Gharout, and Milen Stoychev. 1894 We would like to thank those who contributed to the development of 1895 this information model. In particular, we would like to thank 1896 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary 1897 Thomson. 1899 Finally, we would like to thank the following IESG members for their 1900 review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa 1901 Cooper, and Benjamin Kaduk. 1903 7. References 1905 7.1. Normative References 1907 [I-D.ietf-suit-architecture] 1908 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 1909 Firmware Update Architecture for Internet of Things", 1910 draft-ietf-suit-architecture-15 (work in progress), 1911 January 2021. 1913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1914 Requirement Levels", BCP 14, RFC 2119, 1915 DOI 10.17487/RFC2119, March 1997, 1916 . 1918 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1919 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1920 DOI 10.17487/RFC4122, July 2005, 1921 . 1923 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1924 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1925 May 2017, . 1927 7.2. Informative References 1929 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1930 . 1933 Authors' Addresses 1935 Brendan Moran 1936 Arm Limited 1938 EMail: Brendan.Moran@arm.com 1940 Hannes Tschofenig 1941 Arm Limited 1943 EMail: hannes.tschofenig@gmx.net 1945 Henk Birkholz 1946 Fraunhofer SIT 1948 EMail: henk.birkholz@sit.fraunhofer.de