idnits 2.17.00 (12 Aug 2021) /tmp/idnits50374/draft-ietf-suit-information-model-08.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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (October 28, 2020) is 569 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 (==), 2 comments (--). 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: May 1, 2021 H. Birkholz 6 Fraunhofer SIT 7 October 28, 2020 9 An Information Model for Firmware Updates in IoT Devices 10 draft-ietf-suit-information-model-08 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 May 1, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 62 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 63 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 64 3.1. Manifest Element: Version ID of the manifest structure . 6 65 3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6 66 3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 7 67 3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7 68 3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7 69 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8 70 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 9 71 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9 72 3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 9 73 3.5. Manifest Element: Precursor Image Digest Condition . . . 10 74 3.6. Manifest Element: Required Image Version List . . . . . . 10 75 3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10 76 3.8. Manifest Element: Payload Format . . . . . . . . . . . . 11 77 3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11 78 3.10. Manifest Element: Storage Location . . . . . . . . . . . 11 79 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 12 80 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12 81 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12 82 3.11. Manifest Element: Component Identifier . . . . . . . . . 12 83 3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12 84 3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 13 85 3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13 86 3.15. Manifest Envelope Element: Signature . . . . . . . . . . 13 87 3.16. Manifest Element: Additional installation instructions . 14 88 3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14 89 3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 15 90 3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 15 91 3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 15 92 3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15 93 3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 16 94 3.23. Manifest Element: 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 137 Resource Location . . . . . . . . . . . . . . . . . . 27 138 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 27 139 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 140 images . . . . . . . . . . . . . . . . . . . . . . . 27 141 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 142 Class IDs . . . . . . . . . . . . . . . . . . . . . . 28 143 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 28 144 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 28 145 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 29 146 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 29 147 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 29 148 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 30 149 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing 150 keys . . . . . . . . . . . . . . . . . . . . . . . . 30 151 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to 152 deployment . . . . . . . . . . . . . . . . . . . . . 30 153 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 154 trusted environment . . . . . . . . . . . . . . . . . 30 155 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between 156 check and use . . . . . . . . . . . . . . . . . . . . 30 157 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 31 158 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 159 Instructions . . . . . . . . . . . . . . . . . . . . 31 160 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 31 161 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 162 Elements . . . . . . . . . . . . . . . . . . . . . . 32 163 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 32 164 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 32 165 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 33 166 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 167 Information Disclosures . . . . . . . . . . . . . . . 33 168 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from 169 Unpacking Unknown Formats . . . . . . . . . . . . . . 33 170 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 171 Numbers of Target Firmware . . . . . . . . . . . . . 33 172 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 173 Between Images . . . . . . . . . . . . . . . . . . . 34 174 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 175 Manifests . . . . . . . . . . . . . . . . . . . . . . 34 176 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 34 177 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 34 178 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 34 179 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 180 Manifest . . . . . . . . . . . . . . . . . . . . . . 35 181 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 35 182 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 35 183 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 35 184 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 185 Resource Location . . . . . . . . . . . . . . . . . . 35 186 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 36 187 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 37 188 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 37 189 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 37 190 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 38 191 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 38 192 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 38 193 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 38 194 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 39 195 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 40 196 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 197 Manifest . . . . . . . . . . . . . . . . . . . . . . 40 198 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 199 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 200 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 201 7.1. Normative References . . . . . . . . . . . . . . . . . . 41 202 7.2. Informative References . . . . . . . . . . . . . . . . . 41 203 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 205 1. Introduction 207 The information model describes all the information elements required 208 to secure firmware updates of IoT devices from the threats described 209 in Section 4.1 and enables the user stories captured in Section 4.4. 210 These threats and user stories are not intended to be an exhaustive 211 list of the threats against IoT devices, nor of the possible user 212 stories that describe how to conduct a firmware update. Instead they 213 are intended to describe the threats against firmware updates in 214 isolation and provide sufficient motivation to specify the 215 information elements that cover a wide range of user stories. The 216 information model does not define the serialization, encoding, 217 ordering, or structure of information elements, only their semantics. 219 Because the information model covers a wide range of user stories and 220 a wide range of threats, not all information elements apply to all 221 scenarios. As a result, various information elements could be 222 considered optional to implement and optional to use, depending on 223 which threats exist in a particular domain of application and which 224 user stories are required. Elements marked as REQUIRED provide 225 baseline security and usability properties that are expected to be 226 required for most applications. Those elements are required to be 227 implemented and used. Elements marked as RECOMMENDED provide 228 important security or usability properties that are needed on most 229 devices. Elements marked as OPTIONAL enable security or usability 230 properties that are useful in some applications. 232 The definition of some of the information elements include examples 233 that illustrate their semantics and how they are intended to be used. 235 2. Conventions and Terminology 237 This document uses terms defined in [I-D.ietf-suit-architecture]. 238 The term 'Operator' refers to both Device and Network Operator. 240 Secure time and secure clock refer to a set of requirements on time 241 sources. For local time sources, this primarily means that the clock 242 must be monotonically increasing, including across power cycles, 243 firmware updates, etc. For remote time sources, the provided time 244 must be guaranteed to be correct to within some predetermined bounds, 245 whenever the time source is accessible. 247 The term Envelope is used to describe an encoding that allows the 248 bundling of a manifest with related information elements that are not 249 directly contained within the manifest. 251 The term Payload is used to describe the data that is delivered to a 252 device during an update. This is distinct from a "firmware image" as 253 described in [I-D.ietf-suit-architecture] because the payload is 254 often in an intermediate state, such as being encrypted, compressed 255 and/or encoded as a differential update. The payload, taken in 256 isolation, is often not the final firmware image. 258 2.1. Requirements Notation 260 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 261 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 262 "OPTIONAL" in this document are to be interpreted as described in 263 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 264 capitals, as shown here. 266 3. Manifest Information Elements 268 Each manifest information element is anchored in a security 269 requirement or a usability requirement. The manifest elements are 270 described below, justified by their requirements. 272 3.1. Manifest Element: Version ID of the manifest structure 274 An identifier that describes which iteration of the manifest format 275 is contained in the structure. 277 This element is REQUIRED in order to allow devices to identify the 278 version of the manifest data model that is in use. 280 3.2. Manifest Element: Monotonic Sequence Number 282 A monotonically increasing sequence number. For convenience, the 283 monotonic sequence number MAY be a UTC timestamp. This allows global 284 synchronisation of sequence numbers without any additional 285 management. This number MUST be possible to extract with a simple, 286 minimal parser so that code choosing one out of several manifests can 287 choose which is the latest without fully parsing a complex structure. 289 This element is REQUIRED and is necessary to prevent malicious actors 290 from reverting a firmware update against the policies of the relevant 291 authority. 293 Implements: REQ.SEC.SEQUENCE (Section 4.3.1) 295 3.3. Manifest Element: Vendor ID 297 Vendor IDs must be unique. This is to prevent similarly, or 298 identically named entities from different geographic regions from 299 colliding in their customer's infrastructure. Recommended practice 300 is to use [RFC4122] version 5 UUIDs with the vendor's domain name and 301 the DNS name space ID. Other options include type 1 and type 4 302 UUIDs. 304 Vendor ID is not intended to be a human-readable element. It is 305 intended for binary match/mismatch comparison only. 307 The use of a Vendor ID is RECOMMENDED. It helps to distinguish 308 between identically named products from different vendors. 310 Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), 311 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 313 3.3.1. Example: Domain Name-based UUIDs 315 Vendor A creates a UUID based on their domain name: 317 vendorId = UUID5(DNS, "vendor-a.com") 319 Because the DNS infrastructure prevents multiple registrations of the 320 same domain name, this UUID is (with very high probability) 321 guaranteed to be unique. Because the domain name is known, this UUID 322 is reproducible. Type 1 and type 4 UUIDs produce similar guarantees 323 of uniqueness, but not reproducibility. 325 This approach creates a contention when a vendor changes its name or 326 relinquishes control of a domain name. In this scenario, it is 327 possible that another vendor would start using that same domain name. 328 However, this UUID is not proof of identity; a device's trust in a 329 vendor must be anchored in a cryptographic key, not a UUID. 331 3.4. Manifest Element: Class ID 333 A device "Class" is a set of different device types that can accept 334 the same firmware update without modification. Class IDs MUST be 335 unique within the scope of a Vendor ID. This is to prevent 336 similarly, or identically named devices colliding in their customer's 337 infrastructure. 339 Recommended practice is to use [RFC4122] version 5 UUIDs with as much 340 information as necessary to define firmware compatibility. Possible 341 information used to derive the class UUID includes: 343 o model name or number 345 o hardware revision 347 o runtime library version 349 o bootloader version 351 o ROM revision 353 o silicon batch number 355 The Class Identifier UUID SHOULD use the Vendor ID as the name space 356 ID. Other options include version 1 and 4 UUIDs. Classes MAY be 357 more granular than is required to identify firmware compatibility. 358 Classes MUST NOT be less granular than is required to identify 359 firmware compatibility. Devices MAY have multiple Class IDs. 361 Class ID is not intended to be a human-readable element. It is 362 intended for binary match/mismatch comparison only. 364 The use of Class ID is RECOMMENDED. It allows devices to determine 365 applicability of a firmware in an unambiguous way. 367 If Class ID is not implemented, then each logical device class MUST 368 use a unique trust anchor for authorization. 370 Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), 371 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 373 3.4.1. Example 1: Different Classes 375 Vendor A creates product Z and product Y. The firmware images of 376 products Z and Y are not interchangeable. Vendor A creates UUIDs as 377 follows: 379 o vendorId = UUID5(DNS, "vendor-a.com") 381 o ZclassId = UUID5(vendorId, "Product Z") 383 o YclassId = UUID5(vendorId, "Product Y") 384 This ensures that Vendor A's Product Z cannot install firmware for 385 Product Y and Product Y cannot install firmware for Product Z. 387 3.4.2. Example 2: Upgrading Class ID 389 Vendor A creates product X. Later, Vendor A adds a new feature to 390 product X, creating product X v2. Product X requires a firmware 391 update to work with firmware intended for product X v2. 393 Vendor A creates UUIDs as follows: 395 o vendorId = UUID5(DNS, "vendor-a.com") 397 o XclassId = UUID5(vendorId, "Product X") 399 o Xv2classId = UUID5(vendorId, "Product X v2") 401 When product X receives the firmware update necessary to be 402 compatible with product X v2, part of the firmware update changes the 403 class ID to Xv2classId. 405 3.4.3. Example 3: Shared Functionality 407 Vendor A produces two products, product X and product Y. These 408 components share a common core (such as an operating system), but 409 have different applications. The common core and the applications 410 can be updated independently. To enable X and Y to receive the same 411 common core update, they require the same class ID. To ensure that 412 only product X receives application X and only product Y receives 413 application Y, product X and product Y must have different class IDs. 414 The vendor creates Class IDs as follows: 416 o vendorId = UUID5(DNS, "vendor-a.com") 418 o XclassId = UUID5(vendorId, "Product X") 420 o YclassId = UUID5(vendorId, "Product Y") 422 o CommonClassId = UUID5(vendorId, "common core") 424 Product X matches against both XclassId and CommonClassId. Product Y 425 matches against both YclassId and CommonClassId. 427 3.4.4. Example 4: White-labelling 429 Vendor A creates a product A and its firmware. Vendor B sells the 430 product under its own name as Product B with some customised 431 configuration. The vendors create the Class IDs as follows: 433 o vendorIdA = UUID5(DNS, "vendor-a.com") 435 o classIdA = UUID5(vendorIdA, "Product A-Unlabelled") 437 o vendorIdB = UUID5(DNS, "vendor-b.com") 439 o classIdB = UUID5(vendorIdB, "Product B") 441 The product will match against each of these class IDs. If Vendor A 442 and Vendor B provide different components for the device, the 443 implementor MAY choose to make ID matching scoped to each component. 444 Then, the vendorIdA, classIdA match the component ID supplied by 445 Vendor A, and the vendorIdB, classIdB match the component ID supplied 446 by Vendor B. 448 3.5. Manifest Element: Precursor Image Digest Condition 450 When a precursor image is required by the payload format (for 451 example, differential updates), a precursor image digest condition 452 MUST be present. The precursor image MAY be installed or stored as a 453 candidate. 455 This element is OPTIONAL to implement. 457 Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 459 3.6. Manifest Element: Required Image Version List 461 When a payload applies to multiple versions of a firmware, the 462 required image version list specifies which versions must be present 463 for the update to be applied. This allows the update author to 464 target specific versions of firmware for an update, while excluding 465 those to which it should not be applied. 467 Where an update can only be applied over specific predecessor 468 versions, that version MUST be specified by the Required Image 469 Version List. 471 This element is OPTIONAL to implement. 473 Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) 475 3.7. Manifest Element: Expiration Time 477 This element tells a device the time at which the manifest expires 478 and should no longer be used. This element SHOULD be used where a 479 secure source of time is provided and firmware is intended to expire 480 predictably. This element may also be displayed (e.g. via an app) 481 for user confirmation since users typically have a reliable knowledge 482 of the date. 484 Special consideration is required for end-of-life: if a firmware will 485 not be updated again, for example if a business stops issuing updates 486 to a device. The last valid firmware should not have an expiration 487 time. 489 This element is OPTIONAL to implement. 491 Implements: REQ.SEC.EXP (Section 4.3.3) 493 3.8. Manifest Element: Payload Format 495 The format of the payload MUST be indicated to devices in an 496 unambiguous way. This element provides a mechanism to describe the 497 payload format, within the signed metadata. 499 This element is REQUIRED and MUST be present to enable devices to 500 decode payloads correctly. 502 Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT 503 (Section 4.5.5) 505 3.9. Manifest Element: Processing Steps 507 A representation of the Processing Steps required to decode a 508 payload, in particular those that are compressed, packed, or 509 encrypted. The representation MUST describe which algorithm(s) is 510 used and any additional parameters required by the algorithm(s). The 511 representation MAY group Processing Steps together in predefined 512 combinations. 514 A Processing Step MAY indicate the expected digest of the payload 515 after the processing is complete. 517 Processing steps are RECOMMENDED to implement. 519 Implements: REQ.USE.IMG.NESTED (Section 4.5.6) 521 3.10. Manifest Element: Storage Location 523 This element tells the device where to store a payload within a given 524 component. The device can use this to establish which permissions 525 are necessary and the physical storage location to use. 527 This element is REQUIRED and MUST be present to enable devices to 528 store payloads to the correct location. 530 Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 532 3.10.1. Example 1: Two Storage Locations 534 A device supports two components: an OS and an application. These 535 components can be updated independently, expressing dependencies to 536 ensure compatibility between the components. The Author chooses two 537 storage identifiers: 539 o "OS" 541 o "APP" 543 3.10.2. Example 2: File System 545 A device supports a full filesystem. The Author chooses to use the 546 storage identifier as the path at which to install the payload. The 547 payload may be a tarball, in which case, it unpacks the tarball into 548 the specified path. 550 3.10.3. Example 3: Flash Memory 552 A device supports flash memory. The Author chooses to make the 553 storage identifier the offset where the image should be written. 555 3.11. Manifest Element: Component Identifier 557 In a device with more than one storage subsystem, a storage 558 identifier is insufficient to identify where and how to store a 559 payload. To resolve this, a component identifier indicates which 560 part of the storage architecture is targeted by the payload. 562 This element is OPTIONAL and only necessary in devices with multiple 563 storage subsystems. 565 N.B. A serialization MAY choose to combine Component Identifier and 566 Storage Location (Section 3.10) 568 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 570 3.12. Manifest Element: Resource Indicator 572 This element provides the information required for the device to 573 acquire the resource. This can be encoded in several ways: 575 o One URI 577 o A list of URIs 578 o A prioritised list of URIs 580 o A list of signed URIs 582 This element is OPTIONAL and only needed when the target device does 583 not intrinsically know where to find the payload. 585 N.B. Devices will typically require URIs. 587 Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 589 3.13. Manifest Element: Payload Digests 591 This element contains one or more digests of one or more payloads. 592 This allows the target device to ensure authenticity of the 593 payload(s). A manifest format MUST provide a mechanism to select one 594 payload from a list based on system parameters, such as Execute-In- 595 Place Installation Address. 597 This element is REQUIRED to implement and fundamentally necessary to 598 ensure the authenticity and integrity of the payload. Support for 599 more than one digest is OPTIONAL to implement in a recipient device. 601 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT 602 (Section 4.5.8) 604 3.14. Manifest Element: Size 606 The size of the payload in bytes. 608 Variable-size storage locations MUST be set to exactly the size 609 listed in this element. 611 This element is REQUIRED and informs the target device how big of a 612 payload to expect. Without it, devices are exposed to some classes 613 of denial of service attack. 615 Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) 617 3.15. Manifest Envelope Element: Signature 619 The Signature element MUST contain all the information necessary to 620 cryptographically verify the contents of the manifest against a root 621 of trust. Because the Signature element authenticates the manifest, 622 it cannot be contained within the manifest. Instead, the manifest is 623 either contained within the signature element, or the signature 624 element is a member of the Manifest Envelope and bundled with the 625 manifest. 627 This element MAY be provided either by the manifest envelope 628 serialization or by another serialization of authentication objects, 629 such as a COSE ([RFC8152]) or CMS ([RFC5652]) signature object. The 630 Signature element MUST support multiple actors and multiple 631 authentication methods. It is NOT REQUIRED for a serialization to 632 authenticate multiple manifests with a single Signature element. 634 This element is REQUIRED in non-dependency manifests and represents 635 the foundation of all security properties of the manifest. Manifests 636 which are included as dependencies by another manifest SHOULD include 637 a signature so that the recipient can distinguish between different 638 actors with different permissions. 640 A manifest MUST NOT be considered authenticated by channel security 641 even if it contains only channel information (such as URIs). If the 642 authenticated remote or channel were compromised, the threat actor 643 could induce recipients to execute queries over any accessible 644 network. Where public key operations require too many resources, the 645 recommended authentication mechanism is MAC with a per-device pre- 646 shared key. 648 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS 649 (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) 651 3.16. Manifest Element: Additional installation instructions 653 Instructions that the device should execute when processing the 654 manifest. This information is distinct from the information 655 necessary to process a payload. Additional installation instructions 656 include information such as update timing (for example, install only 657 on Sunday, at 0200), procedural considerations (for example, shut 658 down the equipment under control before executing the update), pre- 659 and post-installation steps (for example, run a script). Other 660 installation instructions could include requesting user confirmation 661 before installing. 663 This element is OPTIONAL. 665 Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 667 3.17. Manifest Element: Aliases 669 A mechanism for a manifest to augment or replace URIs or URI lists 670 defined by one or more of its dependencies. 672 This element is OPTIONAL and enables some user stories. 674 Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 676 3.18. Manifest Element: Dependencies 678 A list of other manifests that are required by the current manifest. 679 Manifests are identified an unambiguous way, such as a digest. 681 This element is REQUIRED to use in deployments that include both 682 multiple authorities and multiple payloads. 684 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 686 3.19. Manifest Element: Encryption Wrapper 688 Encrypting firmware images requires symmetric content encryption 689 keys. The encryption wrapper provides the information needed for a 690 device to obtain or locate a key that it uses to decrypt the 691 firmware. This MAY be included in a decryption step contained in 692 Processing Steps (Section 3.9). 694 This element is REQUIRED to use for encrypted payloads, 696 Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 698 3.20. Manifest Element: XIP Address 700 In order to support XIP systems with multiple possible base 701 addresses, it is necessary to specify which address the payload is 702 linked for. 704 For example a microcontroller may have a simple bootloader that 705 chooses one of two images to boot. That microcontroller then needs 706 to choose one of two firmware images to install, based on which of 707 its two images is older. 709 This element is OPTIONAL to implement. 711 Implements: REQ.USE.IMG.SELECT (Section 4.5.8) 713 3.21. Manifest Element: Load-time metadata 715 Load-time metadata provides the device with information that it needs 716 in order to load one or more images. This metadata MAY include any 717 of: 719 o the source 721 o the destination 723 o the destination address 724 o cryptographic information 726 o decompression information 728 o unpacking information 730 Typically, loading is done by copying an image from its permanent 731 storage location into its active use location. The metadata allows 732 operations such as decryption, decompression, and unpacking to be 733 performed during that copy. 735 This element is OPTIONAL to implement. 737 Implements: REQ.USE.LOAD (Section 4.5.10) 739 3.22. Manifest Element: Run-time metadata 741 Run-time metadata provides the device with any extra information 742 needed to boot the device. This may include information such as the 743 entry-point of an XIP image or the kernel command-line of a Linux 744 image. 746 This element is OPTIONAL to implement. 748 Implements: REQ.USE.EXEC (Section 4.5.9) 750 3.23. Manifest Element: Payload 752 The Payload element is contained within the manifest or manifest 753 envelope. This enables the manifest and payload to be delivered 754 simultaneously. Typically this is used for delivering small payloads 755 such as cryptographic keys, or configuration data. 757 This element is OPTIONAL to implement. 759 Implements: REQ.USE.PAYLOAD (Section 4.5.11) 761 3.24. Manifest Envelope Element: Delegation Chain 763 The Signature (Section 3.15) is NOT REQUIRED to cover the delegation 764 chain. The delegation chain offers enhanced authorization 765 functionality via authorization tokens. Each token itself is 766 protected and does not require another layer of protection and 767 because the delegation chain is needed to verify the signature, it 768 must be placed in the Manifest Envelope, rather than the Manifest. 770 This element is OPTIONAL to implement. 772 Implements: REQ.USE.DELEGATION (Section 4.5.13) 774 4. Security Considerations 776 The following sub-sections describe the threat model, user stories, 777 security requirements, and usability requirements. This section also 778 provides the motivations for each of the manifest information 779 elements. 781 4.1. Threat Model 783 The following sub-sections aim to provide information about the 784 threats that were considered, the security requirements that are 785 derived from those threats and the fields that permit implementation 786 of the security requirements. This model uses the S.T.R.I.D.E. 787 [STRIDE] approach. Each threat is classified according to: 789 o Spoofing identity 791 o Tampering with data 793 o Repudiation 795 o Information disclosure 797 o Denial of service 799 o Elevation of privilege 801 This threat model only covers elements related to the transport of 802 firmware updates. It explicitly does not cover threats outside of 803 the transport of firmware updates. For example, threats to an IoT 804 device due to physical access are out of scope. 806 4.2. Threat Descriptions 808 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 810 Classification: Elevation of Privilege 812 An attacker sends an old, but valid manifest with an old, but valid 813 firmware image to a device. If there is a known vulnerability in the 814 provided firmware image, this may allow an attacker to exploit the 815 vulnerability and gain control of the device. 817 Threat Escalation: If the attacker is able to exploit the known 818 vulnerability, then this threat can be escalated to ALL TYPES. 820 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 822 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old Firmware 824 Classification: Elevation of Privilege 826 An attacker targets a device that has been offline for a long time 827 and runs an old firmware version. The attacker sends an old, but 828 valid manifest to a device with an old, but valid firmware image. 829 The attacker-provided firmware is newer than the installed one but 830 older than the most recently available firmware. If there is a known 831 vulnerability in the provided firmware image then this may allow an 832 attacker to gain control of a device. Because the device has been 833 offline for a long time, it is unaware of any new updates. As such 834 it will treat the old manifest as the most current. 836 The exact mitigation for this threat depends on where the threat 837 comes from. This requires careful consideration by the implementor. 838 If the threat is from a network actor, including an on-path attacker, 839 or an intruder into a management system, then a user confirmation can 840 mitigate this attack, simply by displaying an expiration date and 841 requesting confirmation. On the other hand, if the user is the 842 attacker, then an online confirmation system (for example a trusted 843 timestamp server) can be used as a mitigation system. 845 Threat Escalation: If the attacker is able to exploit the known 846 vulnerability, then this threat can be escalated to ALL TYPES. 848 Mitigated by: REQ.SEC.EXP (Section 4.3.3), REQ.USE.MFST.PRE_CHECK 849 (Section 4.5.1), 851 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 853 Classification: Denial of Service 855 An attacker sends a valid firmware image, for the wrong type of 856 device, signed by an actor with firmware installation permission on 857 both types of device. The firmware is verified by the device 858 positively because it is signed by an actor with the appropriate 859 permission. This could have wide-ranging consequences. For devices 860 that are similar, it could cause minor breakage, or expose security 861 vulnerabilities. For devices that are very different, it is likely 862 to render devices inoperable. 864 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 866 4.2.3.1. Example: 868 Suppose that two vendors, Vendor A and Vendor B, adopt the same trade 869 name in different geographic regions, and they both make products 870 with the same names, or product name matching is not used. This 871 causes firmware from Vendor A to match devices from Vendor B. 873 If the vendors are the firmware authorities, then devices from Vendor 874 A will reject images signed by Vendor B since they use different 875 credentials. However, if both devices trust the same Author, then, 876 devices from Vendor A could install firmware intended for devices 877 from Vendor B. 879 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 880 payload 882 Classification: Denial of Service 884 If a device misinterprets the format of the firmware image, it may 885 cause a device to install a firmware image incorrectly. An 886 incorrectly installed firmware image would likely cause the device to 887 stop functioning. 889 Threat Escalation: An attacker that can cause a device to 890 misinterpret the received firmware image may gain elevation of 891 privilege and potentially expand this to all types of threat. 893 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 895 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 896 the wrong location 898 Classification: Denial of Service 900 If a device installs a firmware image to the wrong location on the 901 device, then it is likely to break. For example, a firmware image 902 installed as an application could cause a device and/or an 903 application to stop functioning. 905 Threat Escalation: An attacker that can cause a device to 906 misinterpret the received code may gain elevation of privilege and 907 potentially expand this to all types of threat. 909 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 911 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 913 Classification: Denial of Service 915 If a device does not know where to obtain the payload for an update, 916 it may be redirected to an attacker's server. This would allow an 917 attacker to provide broken payloads to devices. 919 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 921 4.2.7. THREAT.NET.ONPATH: Traffic interception 923 Classification: Spoofing Identity, Tampering with Data 925 An attacker intercepts all traffic to and from a device. The 926 attacker can monitor or modify any data sent to or received from the 927 device. This can take the form of: manifests, payloads, status 928 reports, and capability reports being modified or not delivered to 929 the intended recipient. It can also take the form of analysis of 930 data sent to or from the device, either in content, size, or 931 frequency. 933 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), 934 REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC 935 (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), 936 REQ.SEC.REPORTING (Section 4.3.16) 938 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 940 Classification: Elevation of Privilege 942 An attacker replaces a newly downloaded firmware after a device 943 finishes verifying a manifest. This could cause the device to 944 execute the attacker's code. This attack likely requires physical 945 access to the device. However, it is possible that this attack is 946 carried out in combination with another threat that allows remote 947 execution. This is a typical Time Of Check/Time Of Use threat. 949 Threat Escalation: If the attacker is able to exploit a known 950 vulnerability, or if the attacker can supply their own firmware, then 951 this threat can be escalated to ALL TYPES. 953 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 955 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 957 Classification: Elevation of Privilege / All Types 959 If an attacker can install their firmware on a device, by 960 manipulating either payload or metadata, then they have complete 961 control of the device. 963 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 965 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 967 Classification: Denial of Service / All Types 969 An attacker sends a valid, current manifest to a device that has an 970 unexpected precursor image. If a payload format requires a precursor 971 image (for example, delta updates) and that precursor image is not 972 available on the target device, it could cause the update to break. 974 An attacker that can cause a device to install a payload against the 975 wrong precursor image could gain elevation of privilege and 976 potentially expand this to all types of threat. However, it is 977 unlikely that a valid differential update applied to an incorrect 978 precursor would result in a functional, but vulnerable firmware. 980 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 982 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 984 Classification: Denial of Service, Elevation of Privilege 986 This threat can appear in several ways, however it is ultimately 987 about ensuring that devices retain the behaviour required by their 988 Owner, Device Operator, or Network Operator. The owner or operator 989 of a device typically requires that the device maintain certain 990 features, functions, capabilities, behaviours, or interoperability 991 constraints (more generally, behaviour). If these requirements are 992 broken, then a device will not fulfill its purpose. Therefore, if 993 any party other than the device's Owner or the Owner's contracted 994 Device Operator has the ability to modify device behaviour without 995 approval, then this constitutes an elevation of privilege. 997 Similarly, a network operator may require that devices behave in a 998 particular way in order to maintain the integrity of the network. If 999 devices behaviour on a network can be modified without the approval 1000 of the network operator, then this constitutes an elevation of 1001 privilege with respect to the network. 1003 For example, if the owner of a device has purchased that device 1004 because of Features A, B, and C, and a firmware update is issued by 1005 the manufacturer, which removes Feature A, then the device may not 1006 fulfill the owner's requirements any more. In certain circumstances, 1007 this can cause significantly greater threats. Suppose that Feature A 1008 is used to implement a safety-critical system, whether the 1009 manufacturer intended this behaviour or not. When unapproved 1010 firmware is installed, the system may become unsafe. 1012 In a second example, the owner or operator of a system of two or more 1013 interoperating devices needs to approve firmware for their system in 1014 order to ensure interoperability with other devices in the system. 1015 If the firmware is not qualified, the system as a whole may not work. 1016 Therefore, if a device installs firmware without the approval of the 1017 device owner or operator, this is a threat to devices or the system 1018 as a whole. 1020 Similarly, the operator of a network may need to approve firmware for 1021 devices attached to the network in order to ensure favourable 1022 operating conditions within the network. If the firmware is not 1023 qualified, it may degrade the performance of the network. Therefore, 1024 if a device installs firmware without the approval of the network 1025 operator, this is a threat to the network itself. 1027 Threat Escalation: If the firmware expects configuration that is 1028 present in devices deployed in Network A, but not in devices deployed 1029 in Network B, then the device may experience degraded security, 1030 leading to threats of All Types. 1032 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 1033 (Section 4.3.13) 1035 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 1036 Operator 1038 In this example, assume that Device Operators expect the rights to 1039 create firmware but that Network Operators expect the rights to 1040 qualify firmware as fit-for-purpose on their networks. Additionally, 1041 assume that Device Operators manage devices that can be deployed on 1042 any network, including Network A and B in our example. 1044 An attacker may obtain a manifest for a device on Network A. Then, 1045 this attacker sends that manifest to a device on Network B. Because 1046 Network A and Network B are under control of different Operators, and 1047 the firmware for a device on Network A has not been qualified to be 1048 deployed on Network B, the target device on Network B is now in 1049 violation of the Operator B's policy and may be disabled by this 1050 unqualified, but signed firmware. 1052 This is a denial of service because it can render devices inoperable. 1053 This is an elevation of privilege because it allows the attacker to 1054 make installation decisions that should be made by the Operator. 1056 4.2.11.2. Example 2: Single Network Operator with Multiple Device 1057 Operators 1059 Multiple devices that interoperate are used on the same network and 1060 communicate with each other. Some devices are manufactured and 1061 managed by Device Operator A and other devices by Device Operator B. 1062 A new firmware is released by Device Operator A that breaks 1063 compatibility with devices from Device Operator B. An attacker sends 1064 the new firmware to the devices managed by Device Operator A without 1065 approval of the Network Operator. This breaks the behaviour of the 1066 larger system causing denial of service and possibly other threats. 1067 Where the network is a distributed SCADA system, this could cause 1068 misbehaviour of the process that is under control. 1070 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 1071 for Vulnerability Analysis 1073 Classification: All Types 1075 An attacker wants to mount an attack on an IoT device. To prepare 1076 the attack he or she retrieves the provided firmware image and 1077 performs reverse engineering of the firmware image to analyze it for 1078 specific vulnerabilities. 1080 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1082 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 1084 Classification: Elevation of Privilege 1086 An authorized actor, but not the Author, uses an override mechanism 1087 (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information 1088 element in a manifest signed by the Author. For example, if the 1089 authorized actor overrides the digest and URI of the payload, the 1090 actor can replace the entire payload with a payload of their choice. 1092 Threat Escalation: By overriding elements such as payload 1093 installation instructions or firmware digest, this threat can be 1094 escalated to all types. 1096 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1098 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 1100 Classification: Information Disclosure 1102 A third party may be able to extract sensitive information from the 1103 manifest. 1105 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 1107 4.2.15. THREAT.IMG.EXTRA: Extra data after image 1109 Classification: All Types 1111 If a third party modifies the image so that it contains extra code 1112 after a valid, authentic image, that third party can then use their 1113 own code in order to make better use of an existing vulnerability. 1115 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 1117 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 1119 Classification: All Types 1121 If a third party obtains a key or even indirect access to a key, for 1122 example in an HSM, then they can perform the same actions as the 1123 legitimate owner of the key. If the key is trusted for firmware 1124 update, then the third party can perform firmware updates as though 1125 they were the legitimate owner of the key. 1127 For example, if manifest signing is performed on a server connected 1128 to the internet, an attacker may compromise the server and then be 1129 able to sign manifests, even if the keys for manifest signing are 1130 held in an HSM that is accessed by the server. 1132 Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17) 1134 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 1135 prior to signing 1137 Classification: All Types 1139 If an attacker can alter a manifest or payload before it is signed, 1140 they can perform all the same actions as the manifest author. This 1141 allows the attacker to deploy firmware updates to any devices that 1142 trust the manifest author. If an attacker can modify the code of a 1143 payload before the corresponding manifest is created, they can insert 1144 their own code. If an attacker can modify the manifest before it is 1145 signed, they can redirect the manifest to their own payload. 1147 For example, the attacker deploys malware to the developer's computer 1148 or signing service that watches manifest creation activities and 1149 inserts code into any binary that is referenced by a manifest. 1151 For example, the attacker deploys malware to the developer's computer 1152 or signing service that replaces the referenced binary (digest) and 1153 URI with the attacker's binary (digest) and URI. 1155 Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18), 1156 REQ.SEC.MFST.TRUSTED (Section 4.3.19) 1158 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 1159 authentication and use 1161 Classification: All Types 1163 If an attacker can modify a manifest after it is authenticated (Time 1164 Of Check) but before it is used (Time Of Use), then the attacker can 1165 place any content whatsoever in the manifest. 1167 Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.20) 1169 4.3. Security Requirements 1171 The security requirements here are a set of policies that mitigate 1172 the threats described in Section 4.1. 1174 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 1176 Only an actor with firmware installation authority is permitted to 1177 decide when device firmware can be installed. To enforce this rule, 1178 manifests MUST contain monotonically increasing sequence numbers. 1179 Manifests MAY use UTC epoch timestamps to coordinate monotonically 1180 increasing sequence numbers across many actors in many locations. If 1181 UTC epoch timestamps are used, they MUST NOT be treated as times, 1182 they MUST be treated only as sequence numbers. Devices MUST reject 1183 manifests with sequence numbers smaller than any onboard sequence 1184 number. 1186 Note: This is not a firmware version. It is a manifest sequence 1187 number. A firmware version may be rolled back by creating a new 1188 manifest for the old firmware version with a later sequence number. 1190 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 1192 Implemented by: Monotonic Sequence Number (Section 3.2) 1194 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1196 Devices MUST only apply firmware that is intended for them. Devices 1197 MUST know with fine granularity that a given update applies to their 1198 vendor, model, hardware revision, software revision. Human-readable 1199 identifiers are often error-prone in this regard, so unique 1200 identifiers SHOULD be used. 1202 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1204 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1205 (Section 3.4) 1207 4.3.3. REQ.SEC.EXP: Expiration Time 1209 A firmware manifest MAY expire after a given time. Devices MAY 1210 provide a secure clock (local or remote). If a secure clock is 1211 provided and the Firmware manifest has an expiration timestamp, the 1212 device MUST reject the manifest if current time is later than the 1213 expiration time. 1215 Special consideration is required for end-of-life: if a firmware will 1216 not be updated again, for example if a business stops issuing updates 1217 to a device. The last valid firmware should not have an expiration 1218 time. 1220 Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2) 1222 Implemented by: Expiration Time (Section 3.7) 1224 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1226 The authenticity of an update MUST be demonstrable. Typically, this 1227 means that updates must be digitally authenticated. Because the 1228 manifest contains information about how to install the update, the 1229 manifest's authenticity MUST also be demonstrable. To reduce the 1230 overhead required for validation, the manifest contains the digest of 1231 the firmware image, rather than a second digital signature. The 1232 authenticity of the manifest can be verified with a digital signature 1233 or Message Authentication Code. The authenticity of the firmware 1234 image is tied to the manifest by the use of a digest of the firmware 1235 image. 1237 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.ONPATH 1238 (Section 4.2.7) 1240 Implemented by: Signature (Section 3.15), Payload Digest 1241 (Section 3.13) 1243 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1245 The type of payload (which may be independent of format) MUST be 1246 authenticated. For example, the target must know whether the payload 1247 is XIP firmware, a loadable module, or configuration data. 1249 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1251 Implemented by: Payload Format (Section 3.8), Storage Location 1252 (Section 3.10) 1254 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1255 Location 1257 The location on the target where the payload is to be stored MUST be 1258 authenticated. 1260 Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) 1262 Implemented by: Storage Location (Section 3.10) 1264 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location 1266 The location where a target should find a payload MUST be 1267 authenticated. 1269 Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.ONPATH 1270 (Section 4.2.7) 1272 Implemented by: Resource Indicator (Section 3.12) 1274 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 1276 The target SHOULD verify firmware at time of boot. This requires 1277 authenticated payload size, and digest. 1279 Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) 1281 Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) 1283 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 1285 If an update uses a differential compression method, it MUST specify 1286 the digest of the precursor image and that digest MUST be 1287 authenticated. 1289 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 those 1308 required in REQ.SEC.AUTHENTIC (Section 4.3.4) can be used to prove 1309 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 It MUST be possible to encrypt part or all of the manifest. This may 1358 be accomplished with either transport encryption or with at-rest 1359 encryption. 1361 Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.ONPATH 1362 (Section 4.2.7) 1364 Implemented by: External 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 SHOULD be 1384 performed over an authenticated, confidential channel in order to 1385 prevent 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 parsed and examined prior to deployment to 1405 validate that their contents have not been modified during creation 1406 and signing. 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 validate 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: USER_STORY.OVERRIDE (Section 4.4.3), 1500 REQ.USE.MFST.COMPONENT (Section 4.5.3) 1502 4.4.4. USER_STORY.COMPONENT: Component Update 1504 As a Device Operator, I want to divide my firmware into components, 1505 so that I can reduce the size of updates, make different parties 1506 responsible for different components, and divide my firmware into 1507 frequently updated and infrequently updated components. 1509 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1511 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations 1513 As a Device Operator, I want to ensure the quality of a firmware 1514 update before installing it, so that I can ensure interoperability of 1515 all devices in my product family. I want to restrict the ability to 1516 make changes to my devices to require my express approval. 1518 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), 1519 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1521 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1523 As a Device Operator, I want to be able to send multiple payload 1524 formats to suit the needs of my update, so that I can optimise the 1525 bandwidth used by my devices. 1527 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) 1529 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1530 Disclosures 1532 As a firmware author, I want to prevent confidential information from 1533 being disclosed during firmware updates. It is assumed that channel 1534 security or at-rest encryption is adequate to protect the manifest 1535 itself against information disclosure. 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 1551 Resource 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 encryption keys, 1599 configuration information, public keys, authorization tokens, or 1600 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 It MUST be possible for a manifest author to place ALL information 1638 required to process an update in the manifest. 1640 For example: Information about which precursor image is required for 1641 a differential update MUST be placed in the manifest, not in the 1642 differential compression header. 1644 For example: Information about an installation-time confirmation 1645 system that must be used to allow the installation to proceed. 1647 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1648 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1650 Implemented by: Additional installation instructions (Section 3.16) 1652 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1654 It MUST be possible to redirect payload fetches. This applies where 1655 two manifests are used in conjunction. For example, a Device 1656 Operator creates a manifest specifying a payload and signs it, and 1657 provides a URI for that payload. A Network Operator creates a second 1658 manifest, with a dependency on the first. They use this second 1659 manifest to override the URIs provided by the Device Operator, 1660 directing them into their own infrastructure instead. Some devices 1661 may provide this capability, while others may only look at canonical 1662 sources of firmware. For this to be possible, the device must fetch 1663 the payload, whereas a device that accepts payload pushes will ignore 1664 this feature. 1666 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1668 Implemented by: Aliases (Section 3.17) 1670 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 1672 It MUST be possible to express the requirement to install one or more 1673 payloads from one or more authorities so that a multi-payload update 1674 can be described. This allows multiple parties with different 1675 permissions to collaborate in creating a single update for the IoT 1676 device, across multiple components. 1678 This requirement effectively means that it must be possible to 1679 construct a tree of manifests on a multi-image target. 1681 In order to enable devices with a heterogeneous storage architecture, 1682 the manifest must enable specification of both storage system and the 1683 storage location within that storage system. 1685 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1686 (Section 4.4.4) 1688 Implemented by Manifest Element: Dependencies, StorageIdentifier, 1689 ComponentIdentifier 1691 4.5.3.1. Example 1: Multiple Microcontrollers 1693 An IoT device with multiple microcontrollers in the same physical 1694 device (HeSA) will likely require multiple payloads with different 1695 component identifiers. 1697 4.5.3.2. Example 2: Code and Configuration 1699 A firmware image can be divided into two payloads: code and 1700 configuration. These payloads may require authorizations from 1701 different actors in order to install (see REQ.SEC.RIGHTS 1702 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1703 structure means that multiple manifests may be required, with a 1704 dependency structure between them. 1706 4.5.3.3. Example 3: Multiple Software Modules 1708 A firmware image can be divided into multiple functional blocks for 1709 separate testing and distribution. This means that code would need 1710 to be distributed in multiple payloads. For example, this might be 1711 desirable in order to ensure that common code between devices is 1712 identical in order to reduce distribution bandwidth. 1714 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1716 It MUST be possible to authenticate a manifest multiple times so that 1717 authorizations from multiple parties with different permissions can 1718 be required in order to authorize installation of a manifest. 1720 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1722 Implemented by: Signature (Section 3.15) 1724 4.5.5. REQ.USE.IMG.FORMAT: Format Usability 1726 The manifest format MUST accommodate any payload format that an 1727 Operator wishes to use. This enables the recipient to detect which 1728 format the Operator has chosen. Some examples of payload format are: 1730 o Binary 1732 o Executable and Linkable Format (ELF) 1734 o Differential 1736 o Compressed 1738 o Packed configuration 1740 o Intel HEX 1742 o Motorola S-Record 1744 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1745 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1747 Implemented by: Payload Format (Section 3.8) 1749 4.5.6. REQ.USE.IMG.NESTED: Nested Formats 1751 The manifest format MUST accommodate nested formats, announcing to 1752 the target device all the nesting steps and any parameters used by 1753 those steps. 1755 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1757 Implemented by: Processing Steps (Section 3.9) 1759 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 1761 The manifest format MUST provide a method to specify multiple version 1762 numbers of firmware to which the manifest applies, either with a list 1763 or with range matching. 1765 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1767 Implemented by: Required Image Version List (Section 3.6) 1769 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 1771 The manifest format MUST provide a mechanism to list multiple 1772 equivalent payloads by Execute-In-Place Installation Address, 1773 including the payload digest and, optionally, payload URIs. 1775 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1777 Implemented by: XIP Address (Section 3.20) 1779 4.5.9. REQ.USE.EXEC: Executable Manifest 1781 It MUST be possible to describe an executable system with a manifest 1782 on both Execute-In-Place microcontrollers and on complex operating 1783 systems. This requires the manifest to specify the digest of each 1784 statically linked dependency. In addition, the manifest format MUST 1785 be able to express metadata, such as a kernel command-line, used by 1786 any loader or bootloader. 1788 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1790 Implemented by: Run-time metadata (Section 3.22) 1792 4.5.10. REQ.USE.LOAD: Load-Time Information 1794 It MUST be possible to specify additional metadata for load time 1795 processing of a payload, such as cryptographic information, load- 1796 address, and compression algorithm. 1798 N.B. load comes before exec/boot. 1800 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1802 Implemented by: Load-time metadata (Section 3.21) 1804 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope 1806 It MUST be possible to place a payload in the same structure as the 1807 manifest. This MAY place the payload in the same packet as the 1808 manifest. 1810 Integrated payloads may include, for example, wrapped encryption 1811 keys, configuration information, public keys, authorization tokens, 1812 or X.509 certificates. 1814 When an integrated payload is provided, this increases the size of 1815 the manifest. Manifest size can cause several processing and storage 1816 concerns that require careful consideration. The payload can prevent 1817 the whole manifest from being contained in a single network packet, 1818 which can cause fragmentation and the loss of portions of the 1819 manifest in lossy networks. This causes the need for reassembly and 1820 retransmission logic. The manifest MUST be held immutable between 1821 verification and processing (see REQ.SEC.MFST.CONST 1822 (Section 4.3.20)), so a larger manifest will consume more memory with 1823 immutability guarantees, for example internal RAM or NVRAM, or 1824 external secure memory. If the manifest exceeds the available 1825 immutable memory, then it MUST be processed modularly, evaluating 1826 each of: delegation chains, the security container, and the actual 1827 manifest, which includes verifying the integrated payload. If the 1828 security model calls for downloading the manifest and validating it 1829 before storing to NVRAM in order to prevent wear to NVRAM and energy 1830 expenditure in NVRAM, then either increasing memory allocated to 1831 manifest storage or modular processing of the received manifest may 1832 be required. While the manifest has been organised to enable this 1833 type of processing, it creates additional complexity in the parser. 1834 If the manifest is stored in NVRAM prior to processing, the 1835 integrated payload may cause the manifest to exceed the available 1836 storage. Because the manifest is received prior to validation of 1837 applicability, authority, or correctness, integrated payloads cause 1838 the recipient to expend network bandwidth and energy that may not be 1839 required if the manifest is discarded and these costs vary with the 1840 size of the integrated payload. 1842 See also: REQ.SEC.MFST.CONST (Section 4.3.20). 1844 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1846 Implemented by: Payload (Section 3.23) 1848 4.5.12. REQ.USE.PARSE: Simple Parsing 1850 The structure of the manifest MUST be simple to parse, without need 1851 for a general-purpose parser. 1853 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1855 Implemented by: N/A 1857 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1859 Any manifest format MUST enable the delivery of a key claim with, but 1860 not authenticated by, a manifest. This key claim delivers a new key 1861 with which the recipient can verify the manifest. 1863 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1865 Implemented by: Delegation Chain (Section 3.24) 1867 5. IANA Considerations 1869 This document does not require any actions by IANA. 1871 6. Acknowledgements 1873 We would like to thank our working group chairs, Dave Thaler, Russ 1874 Housley and David Waltermire, for their review comments and their 1875 support. 1877 We would like to thank the participants of the 2018 Berlin SUIT 1878 Hackathon and the June 2018 virtual design team meetings for their 1879 discussion input. In particular, we would like to thank Koen 1880 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1881 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1882 Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias 1883 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1884 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1885 Gharout, and Milen Stoychev. 1887 We would like to thank those who contributed to the development of 1888 this information model. In particular, we would like to thank 1889 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary 1890 Thomson. 1892 7. References 1894 7.1. Normative References 1896 [I-D.ietf-suit-architecture] 1897 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 1898 Firmware Update Architecture for Internet of Things", 1899 draft-ietf-suit-architecture-14 (work in progress), 1900 October 2020. 1902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1903 Requirement Levels", BCP 14, RFC 2119, 1904 DOI 10.17487/RFC2119, March 1997, 1905 . 1907 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1908 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1909 DOI 10.17487/RFC4122, July 2005, 1910 . 1912 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1913 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1914 . 1916 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1917 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1918 . 1920 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1921 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1922 May 2017, . 1924 7.2. Informative References 1926 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1927 . 1930 Authors' Addresses 1932 Brendan Moran 1933 Arm Limited 1935 EMail: Brendan.Moran@arm.com 1936 Hannes Tschofenig 1937 Arm Limited 1939 EMail: hannes.tschofenig@gmx.net 1941 Henk Birkholz 1942 Fraunhofer SIT 1944 EMail: henk.birkholz@sit.fraunhofer.de