idnits 2.17.1 draft-ietf-suit-information-model-13.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 177 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 (July 08, 2021) is 1015 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: January 9, 2022 H. Birkholz 6 Fraunhofer SIT 7 July 08, 2021 9 A Manifest Information Model for Firmware Updates in IoT Devices 10 draft-ietf-suit-information-model-13 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 January 9, 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Requirements and Terminology . . . . . . . . . . . . . . . . 6 62 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 65 3.1. Version ID of the Manifest Structure . . . . . . . . . . 7 66 3.2. Monotonic Sequence Number . . . . . . . . . . . . . . . . 7 67 3.3. Vendor ID . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Class ID . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 9 70 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 10 71 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 10 72 3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 10 73 3.5. Precursor Image Digest Condition . . . . . . . . . . . . 11 74 3.6. Required Image Version List . . . . . . . . . . . . . . . 11 75 3.7. Expiration Time . . . . . . . . . . . . . . . . . . . . . 11 76 3.8. Payload Format . . . . . . . . . . . . . . . . . . . . . 12 77 3.9. Processing Steps . . . . . . . . . . . . . . . . . . . . 12 78 3.10. Storage Location . . . . . . . . . . . . . . . . . . . . 12 79 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 13 80 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . 14 85 3.14. Size . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 3.15. Manifest Envelope Element: Signature . . . . . . . . . . 14 87 3.16. Additional Installation Instructions . . . . . . . . . . 15 88 3.17. Manifest text information . . . . . . . . . . . . . . . . 15 89 3.18. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 3.19. Dependencies . . . . . . . . . . . . . . . . . . . . . . 15 91 3.20. Encryption Wrapper . . . . . . . . . . . . . . . . . . . 16 92 3.21. XIP Address . . . . . . . . . . . . . . . . . . . . . . . 16 93 3.22. Load-time Metadata . . . . . . . . . . . . . . . . . . . 16 94 3.23. Run-time metadata . . . . . . . . . . . . . . . . . . . . 17 95 3.24. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 3.25. Manifest Envelope Element: Delegation Chain . . . . . . . 17 97 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 98 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 18 99 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 19 100 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 19 101 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old 102 Firmware . . . . . . . . . . . . . . . . . . . . . . 19 103 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 20 104 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 105 the type of payload . . . . . . . . . . . . . . . . . 20 106 4.2.5. THREAT.IMG.LOCATION: The target device installs the 107 payload to the wrong location . . . . . . . . . . . . 21 108 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 109 payload hosting . . . . . . . . . . . . . . . . . . . 21 110 4.2.7. THREAT.NET.ONPATH: Traffic interception . . . . . . . 21 111 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 21 112 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 22 113 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 114 images . . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . 24 118 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 119 Elements . . . . . . . . . . . . . . . . . . . . . . 25 120 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 121 Exposure . . . . . . . . . . . . . . . . . . . . . . 25 122 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 25 123 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 25 124 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or 125 payload prior to signing . . . . . . . . . . . . . . 26 126 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 127 authentication and use . . . . . . . . . . . . . . . 26 128 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 26 129 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 27 130 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 27 131 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 27 132 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 28 133 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 28 134 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 135 Authenticated Storage Location . . . . . . . . . . . 28 136 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 29 137 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 29 138 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 139 images . . . . . . . . . . . . . . . . . . . . . . . 29 140 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 141 Class IDs . . . . . . . . . . . . . . . . . . . . . . 29 142 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 29 143 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 30 144 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 30 145 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 31 146 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 31 147 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 31 148 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing 149 keys . . . . . . . . . . . . . . . . . . . . . . . . 31 150 4.3.18. REQ.SEC.KEY.ROTATION: Protected storage of signing 151 keys . . . . . . . . . . . . . . . . . . . . . . . . 32 152 4.3.19. REQ.SEC.MFST.CHECK: Validate manifests prior to 153 deployment . . . . . . . . . . . . . . . . . . . . . 32 154 4.3.20. REQ.SEC.MFST.TRUSTED: Construct manifests in a 155 trusted environment . . . . . . . . . . . . . . . . . 32 156 4.3.21. REQ.SEC.MFST.CONST: Manifest kept immutable between 157 check and use . . . . . . . . . . . . . . . . . . . . 33 158 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 33 159 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 160 Instructions . . . . . . . . . . . . . . . . . . . . 33 161 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 34 162 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 163 Elements . . . . . . . . . . . . . . . . . . . . . . 34 164 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 34 165 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 35 166 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 35 167 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 168 Information Disclosures . . . . . . . . . . . . . . . 35 169 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from 170 Unpacking Unknown Formats . . . . . . . . . . . . . . 35 171 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 172 Numbers of Target Firmware . . . . . . . . . . . . . 36 173 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 174 Between Images . . . . . . . . . . . . . . . . . . . 36 175 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 176 Manifests . . . . . . . . . . . . . . . . . . . . . . 36 177 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 36 178 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 36 179 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 37 180 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 181 Manifest . . . . . . . . . . . . . . . . . . . . . . 37 182 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 37 183 4.4.17. USER_STORY.MFST.ADMINISTRATION: Administration of 184 manifests . . . . . . . . . . . . . . . . . . . . . . 37 185 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 37 186 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 37 187 4.5.2. REQ.USE.MFST.TEXT: Descriptive Manifest Information . 38 188 4.5.3. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 189 Resource Location . . . . . . . . . . . . . . . . . . 38 190 4.5.4. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 38 191 4.5.5. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 39 192 4.5.6. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 39 193 4.5.7. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 40 194 4.5.8. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 40 195 4.5.9. REQ.USE.IMG.SELECT: Select Image by Destination . . . 40 196 4.5.10. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 41 197 4.5.11. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 41 198 4.5.12. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 41 199 4.5.13. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 42 200 4.5.14. REQ.USE.DELEGATION: Delegation of Authority in 201 Manifest . . . . . . . . . . . . . . . . . . . . . . 42 202 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 203 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 204 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 205 7.1. Normative References . . . . . . . . . . . . . . . . . . 43 206 7.2. Informative References . . . . . . . . . . . . . . . . . 44 207 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 209 1. Introduction 211 Vulnerabilities with Internet of Things (IoT) devices have raised the 212 need for a reliable and secure firmware update mechanism that is also 213 suitable for constrained devices. Ensuring that devices function and 214 remain secure over their service life requires such an update 215 mechanism to fix vulnerabilities, to update configuration settings, 216 as well as adding new functionality. 218 One component of such a firmware update is a concise and machine- 219 processable meta-data document, or manifest, that describes the 220 firmware image(s) and offers appropriate protection. This document 221 describes the information that must be present in the manifest. 223 This document describes all the information elements required in a 224 manifest to secure firmware updates of IoT devices. Each information 225 element is motiviated by user stories and threats it aims to 226 mitigate. These threats and user stories are not intended to be an 227 exhaustive list of the threats against IoT devices, nor of the 228 possible user stories that describe how to conduct a firmware update. 229 Instead they are intended to describe the threats against firmware 230 updates in isolation and provide sufficient motivation to specify the 231 information elements that cover a wide range of user stories. 233 To distinguish information elements from their encoding and 234 serialization over the wire this document presents an information 235 model. RFC 3444 [RFC3444] describes the differences between 236 information and data models. 238 Because this document covers a wide range of user stories and a wide 239 range of threats, not all information elements apply to all 240 scenarios. As a result, various information elements are optional to 241 implement and optional to use, depending on which threats exist in a 242 particular domain of application and which user stories are important 243 for deployments. 245 2. Requirements and Terminology 247 2.1. Requirements Notation 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 251 "OPTIONAL" in this document are to be interpreted as described in 252 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 253 capitals, as shown here. 255 Unless otherwise stated these words apply to the design of the 256 manifest format, not its implementation or application. Hence, 257 whenever an information is declared as "REQUIRED" this implies that 258 the manifest format document has to include support for it. 260 2.2. Terminology 262 This document uses terms defined in [I-D.ietf-suit-architecture]. 263 The term 'Operator' refers to both Device and Network Operator. 265 Secure time and secure clock refer to a set of requirements on time 266 sources. For local time sources, this primarily means that the clock 267 must be monotonically increasing, including across power cycles, 268 firmware updates, etc. For remote time sources, the provided time 269 must be both authenticated and guaranteed to be correct to within 270 some predetermined bounds, whenever the time source is accessible. 272 The term Envelope is used to describe an encoding that allows the 273 bundling of a manifest with related information elements that are not 274 directly contained within the manifest. 276 The term Payload is used to describe the data that is delivered to a 277 device during an update. This is distinct from a "firmware image", 278 as described in [I-D.ietf-suit-architecture], because the payload is 279 often in an intermediate state, such as being encrypted, compressed 280 and/or encoded as a differential update. The payload, taken in 281 isolation, is often not the final firmware image. 283 3. Manifest Information Elements 285 Each manifest information element is anchored in a security 286 requirement or a usability requirement. The manifest elements are 287 described below, justified by their requirements. 289 3.1. Version ID of the Manifest Structure 291 An identifier that describes which iteration of the manifest format 292 is contained in the structure. This allows devices to identify the 293 version of the manifest data model that is in use. 295 This element is REQUIRED. 297 3.2. Monotonic Sequence Number 299 A monotonically increasing (unsigned) sequence number to prevent 300 malicious actors from reverting a firmware update against the 301 policies of the relevant authority. This number must not wrap 302 around. 304 For convenience, the monotonic sequence number may be a UTC 305 timestamp. This allows global synchronisation of sequence numbers 306 without any additional management. 308 This element is REQUIRED. 310 Implements: REQ.SEC.SEQUENCE (Section 4.3.1) 312 3.3. Vendor ID 314 The Vendor ID element helps to distinguish between identically named 315 products from different vendors. Vendor ID is not intended to be a 316 human-readable element. It is intended for binary match/mismatch 317 comparison only. 319 Recommended practice is to use [RFC4122] version 5 UUIDs with the 320 vendor's domain name and the DNS name space ID. Other options 321 include type 1 and type 4 UUIDs. 323 Fixed-size binary identifiers are preferred because they are simple 324 to match, unambiguous in length, explicitly non-parsable, and require 325 no issuing authority. Guaranteed unique integers are preferred 326 because they are small and simple to match, however they may not be 327 fixed length and they may require an issuing authority to ensure 328 uniqueness. Free-form text is avoided because it is variable-length, 329 prone to error, and often requires parsing outside the scope of the 330 manifest serialization. 332 If human-readable content is required, it SHOULD be contained in a 333 separate manifest information element: Manifest text information 334 (Section 3.17) 336 This element is RECOMMENDED. 338 Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), 339 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 341 Here is an example for a domain name-based UUID. Vendor A creates a 342 UUID based on a domain name it controls, such as vendorId = 343 UUID5(DNS, "vendor-a.example") 345 Because the DNS infrastructure prevents multiple registrations of the 346 same domain name, this UUID is (with very high probability) 347 guaranteed to be unique. Because the domain name is known, this UUID 348 is reproducible. Type 1 and type 4 UUIDs produce similar guarantees 349 of uniqueness, but not reproducibility. 351 This approach creates a contention when a vendor changes its name or 352 relinquishes control of a domain name. In this scenario, it is 353 possible that another vendor would start using that same domain name. 354 However, this UUID is not proof of identity; a device's trust in a 355 vendor must be anchored in a cryptographic key, not a UUID. 357 3.4. Class ID 359 A device "Class" is a set of different device types that can accept 360 the same firmware update without modification. It thereby allows 361 devices to determine applicability of a firmware in an unambiguous 362 way. Class IDs must be unique within the scope of a Vendor ID. This 363 is to prevent similarly, or identically named devices colliding in 364 their customer's infrastructure. 366 Recommended practice is to use [RFC4122] version 5 UUIDs with as much 367 information as necessary to define firmware compatibility. Possible 368 information used to derive the class UUID includes: 370 o model name or number 372 o hardware revision 374 o runtime library version 376 o bootloader version 378 o ROM revision 380 o silicon batch number 382 The Class ID UUID should use the Vendor ID as the name space 383 identifier. Classes may be more fine-grained granular than is 384 required to identify firmware compatibility. Classes must not be 385 less granular than is required to identify firmware compatibility. 386 Devices may have multiple Class IDs. 388 Class ID is not intended to be a human-readable element. It is 389 intended for binary match/mismatch comparison only. A manifest 390 serialization SHOULD NOT permit free-form text content to be used for 391 Class ID. A fixed-size binary identifier SHOULD be used. 393 Some organizations desire to keep the same product naming across 394 multiple, incompatible hardware revisions for ease of user 395 experience. If this naming is propagated into the firmware, then 396 matching a specific hardware version becomes a challenge. An opaque, 397 non-readable binary identifier has no naming implications and so is 398 more likely to be usable for distinguishing among incompatible device 399 groupings, regardless of naming. 401 Fixed-size binary identifiers are preferred because they are simple 402 to match, unambiguous in length, opaque and free from naming 403 implications, and explicitly non-parsable. Free-form text is avoided 404 because it is variable-length, prone to error, often requires parsing 405 outside the scope of the manifest serialization, and may be 406 homogenized across incompatible device groupings. 408 If Class ID is not implemented, then each logical device class must 409 use a unique trust anchor for authorization. 411 This element is RECOMMENDED. 413 Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), 414 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 416 3.4.1. Example 1: Different Classes 418 Vendor A creates product Z and product Y. The firmware images of 419 products Z and Y are not interchangeable. Vendor A creates UUIDs as 420 follows: 422 o vendorId = UUID5(DNS, "vendor-a.example") 424 o ZclassId = UUID5(vendorId, "Product Z") 426 o YclassId = UUID5(vendorId, "Product Y") 428 This ensures that Vendor A's Product Z cannot install firmware for 429 Product Y and Product Y cannot install firmware for Product Z. 431 3.4.2. Example 2: Upgrading Class ID 433 Vendor A creates product X. Later, Vendor A adds a new feature to 434 product X, creating product X v2. Product X requires a firmware 435 update to work with firmware intended for product X v2. 437 Vendor A creates UUIDs as follows: 439 o vendorId = UUID5(DNS, "vendor-a.example") 441 o XclassId = UUID5(vendorId, "Product X") 443 o Xv2classId = UUID5(vendorId, "Product X v2") 445 When product X receives the firmware update necessary to be 446 compatible with product X v2, part of the firmware update changes the 447 class ID to Xv2classId. 449 3.4.3. Example 3: Shared Functionality 451 Vendor A produces two products, product X and product Y. These 452 components share a common core (such as an operating system), but 453 have different applications. The common core and the applications 454 can be updated independently. To enable X and Y to receive the same 455 common core update, they require the same class ID. To ensure that 456 only product X receives application X and only product Y receives 457 application Y, product X and product Y must have different class IDs. 458 The vendor creates Class IDs as follows: 460 o vendorId = UUID5(DNS, "vendor-a.example") 462 o XclassId = UUID5(vendorId, "Product X") 464 o YclassId = UUID5(vendorId, "Product Y") 466 o CommonClassId = UUID5(vendorId, "common core") 468 Product X matches against both XclassId and CommonClassId. Product Y 469 matches against both YclassId and CommonClassId. 471 3.4.4. Example 4: White-labelling 473 Vendor A creates a product A and its firmware. Vendor B sells the 474 product under its own name as Product B with some customised 475 configuration. The vendors create the Class IDs as follows: 477 o vendorIdA = UUID5(DNS, "vendor-a.example") 478 o classIdA = UUID5(vendorIdA, "Product A-Unlabelled") 480 o vendorIdB = UUID5(DNS, "vendor-b.example") 482 o classIdB = UUID5(vendorIdB, "Product B") 484 The product will match against each of these class IDs. If Vendor A 485 and Vendor B provide different components for the device, the 486 implementor may choose to make ID matching scoped to each component. 487 Then, the vendorIdA, classIdA match the component ID supplied by 488 Vendor A, and the vendorIdB, classIdB match the component ID supplied 489 by Vendor B. 491 3.5. Precursor Image Digest Condition 493 This element provides information about the payload that needs to be 494 present on the device for an update to apply. This may, for example, 495 be the case with differential updates. 497 This element is OPTIONAL. 499 Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 501 3.6. Required Image Version List 503 Payloads may only be applied to a specific firmware version or 504 firmware versions. For example, a payload containing a differential 505 update may be applied only to a specific firmware version. 507 When a payload applies to multiple versions of a firmware, the 508 required image version list specifies which firmware versions must be 509 present for the update to be applied. This allows the update author 510 to target specific versions of firmware for an update, while 511 excluding those to which it should not or cannot be applied. 513 This element is OPTIONAL. 515 Implements: REQ.USE.IMG.VERSIONS (Section 4.5.8) 517 3.7. Expiration Time 519 This element tells a device the time at which the manifest expires 520 and should no longer be used. This element should be used where a 521 secure source of time is provided and firmware is intended to expire 522 predictably. This element may also be displayed (e.g. via an app) 523 for user confirmation since users typically have a reliable knowledge 524 of the date. 526 Special consideration is required for end-of-life if a firmware will 527 not be updated again, for example if a business stops issuing updates 528 to a device. In this case the last valid firmware should not have an 529 expiration time. 531 This element is OPTIONAL. 533 Implements: REQ.SEC.EXP (Section 4.3.3) 535 3.8. Payload Format 537 This element describes the payload format within the signed metadata. 538 It is used to enable devices to decode payloads correctly. 540 This element is REQUIRED. 542 Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT 543 (Section 4.5.6) 545 3.9. Processing Steps 547 A representation of the Processing Steps required to decode a 548 payload, in particular those that are compressed, packed, or 549 encrypted. The representation must describe which algorithms are 550 used and must convey any additional parameters required by those 551 algorithms. 553 A Processing Step may indicate the expected digest of the payload 554 after the processing is complete. 556 This element is RECOMMENDED. 558 Implements: REQ.USE.IMG.NESTED (Section 4.5.7) 560 3.10. Storage Location 562 This element tells the device where to store a payload within a given 563 component. The device can use this to establish which permissions 564 are necessary and the physical storage location to use. 566 This element is REQUIRED. 568 Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 570 3.10.1. Example 1: Two Storage Locations 572 A device supports two components: an OS and an application. These 573 components can be updated independently, expressing dependencies to 574 ensure compatibility between the components. The Author chooses two 575 storage identifiers: 577 o "OS" 579 o "APP" 581 3.10.2. Example 2: File System 583 A device supports a full-featured filesystem. The Author chooses to 584 use the storage identifier as the path at which to install the 585 payload. The payload may be a tarball, in which case, it unpacks the 586 tarball into the specified path. 588 3.10.3. Example 3: Flash Memory 590 A device supports flash memory. The Author chooses to make the 591 storage identifier the offset where the image should be written. 593 3.11. Component Identifier 595 In a device with more than one storage subsystem, a storage 596 identifier is insufficient to identify where and how to store a 597 payload. To resolve this, a component identifier indicates to which 598 part of the storage subsystem the payload shall be placed. 600 A serialization may choose to combine Component Identifier and 601 Storage Location (Section 3.10). 603 This element is OPTIONAL. 605 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.4) 607 3.12. Payload Indicator 609 This element provides the information required for the device to 610 acquire the payload. This functionality is only needed when the 611 target device does not intrinsically know where to find the payload. 613 This can be encoded in several ways: 615 o One URI 617 o A list of URIs 618 o A prioritised list of URIs 620 o A list of signed URIs 622 This element is OPTIONAL. 624 Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 626 3.13. Payload Digests 628 This element contains one or more digests of one or more payloads. 629 This allows the target device to ensure authenticity of the 630 payload(s) when combined with the Signature (Section 3.15) element. 631 A manifest format must provide a mechanism to select one payload from 632 a list based on system parameters, such as Execute-In-Place 633 Installation Address. 635 This element is REQUIRED. Support for more than one digest is 636 OPTIONAL. 638 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT 639 (Section 4.5.9) 641 3.14. Size 643 The size of the payload in bytes, which informs the target device how 644 big of a payload to expect. Without it, devices are exposed to some 645 classes of denial of service attack. 647 This element is REQUIRED. 649 Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) 651 3.15. Manifest Envelope Element: Signature 653 The Signature element contains all the information necessary to 654 protect the contents of the manifest against modification and to 655 offer authentication of the signer. Because the Signature element 656 authenticates the manifest, it cannot be contained within the 657 manifest. Instead, the manifest is either contained within the 658 signature element, or the signature element is a member of the 659 Manifest Envelope and bundled with the manifest. 661 The Signature element represents the foundation of all security 662 properties of the manifest. Manifests, which are included as 663 dependencies by another manifests, should include a signature so that 664 the recipient can distinguish between different actors with different 665 permissions. 667 The Signature element must support multiple signers and multiple 668 signing algorithms. A manifest format may allow multiple manifests 669 to be covered by a single Signature element. 671 This element is REQUIRED in non-dependency manifests. 673 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS 674 (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.5) 676 3.16. Additional Installation Instructions 678 Additional installation instructions are machine-readable commands 679 the device should execute when processing the manifest. This 680 information is distinct from the information necessary to process a 681 payload. Additional installation instructions include information 682 such as update timing (for example, install only on Sunday, at 0200), 683 procedural considerations (for example, shut down the equipment under 684 control before executing the update), pre- and post-installation 685 steps (for example, run a script). Other installation instructions 686 could include requesting user confirmation before installing. 688 This element is OPTIONAL. 690 Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 692 3.17. Manifest text information 694 Textual information pertaining to the update described by the 695 manifest. This information is for human consumption only. It MUST 696 NOT be the basis of any decision made by the recipient. 698 Implements: REQ.USE.MFST.TEXT (Section 4.5.2) 700 3.18. Aliases 702 A mechanism for a manifest to augment or replace URIs or URI lists 703 defined by one or more of its dependencies. 705 This element is OPTIONAL. 707 Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.3) 709 3.19. Dependencies 711 A list of other manifests that are required by the current manifest. 712 Manifests are identified an unambiguous way, such as a cryptographic 713 digest. 715 This element is REQUIRED to support deployments that include both 716 multiple authorities and multiple payloads. 718 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.4) 720 3.20. Encryption Wrapper 722 Encrypting firmware images requires symmetric content encryption 723 keys. The encryption wrapper provides the information needed for a 724 device to obtain or locate a key that it uses to decrypt the 725 firmware. 727 This element is REQUIRED for encrypted payloads. 729 Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 731 3.21. XIP Address 733 In order to support execute in place (XIP) systems with multiple 734 possible base addresses, it is necessary to specify which address the 735 payload is linked for. 737 For example a microcontroller may have a simple bootloader that 738 chooses one of two images to boot. That microcontroller then needs 739 to choose one of two firmware images to install, based on which of 740 its two images is older. 742 This element is OPTIONAL. 744 Implements: REQ.USE.IMG.SELECT (Section 4.5.9) 746 3.22. Load-time Metadata 748 Load-time metadata provides the device with information that it needs 749 in order to load one or more images. This metadata may include any 750 of: 752 o the source (e.g. non-volatile storage) 754 o the destination (e.g. an address in RAM) 756 o cryptographic information 758 o decompression information 760 o unpacking information 761 Typically, loading is done by copying an image from its permanent 762 storage location into its active use location. The metadata allows 763 operations such as decryption, decompression, and unpacking to be 764 performed during that copy. 766 This element is OPTIONAL. 768 Implements: REQ.USE.LOAD (Section 4.5.11) 770 3.23. Run-time metadata 772 Run-time metadata provides the device with any extra information 773 needed to boot the device. This may include the entry-point of an 774 XIP image or the kernel command-line to boot a Linux image. 776 This element is OPTIONAL. 778 Implements: REQ.USE.EXEC (Section 4.5.10) 780 3.24. Payload 782 The Payload element is contained within the manifest or manifest 783 envelope and enables the manifest and payload to be delivered 784 simultaneously. This is used for delivering small payloads, such as 785 cryptographic keys or configuration data. 787 This element is OPTIONAL. 789 Implements: REQ.USE.PAYLOAD (Section 4.5.12) 791 3.25. Manifest Envelope Element: Delegation Chain 793 The delegation chain offers enhanced authorization functionality via 794 authorization tokens, such as CBOR Web Tokens [RFC8392] with Proof of 795 Possession Key Semantics [RFC8747]. Each token itself is protected 796 and does not require another layer of protection. Each authorization 797 token typically includes a public key or a public key fingerprint, 798 however this is dependent on the tokens used. Each token MAY include 799 additional metadata, such as key usage information. Because the 800 delegation chain is needed to verify the signature, it must be placed 801 in the Manifest Envelope, rather than the Manifest. 803 The first token in any delegation chain MUST be autheticated by the 804 recipient's Trust Anchor. Each subsequent token MUST be 805 authenticated using the previous token. This allows a recipient to 806 discard each antecedent token after it has authenticated the 807 subsequent token. The final token MUST enable authentication of the 808 manifest. More than one delegation chain MAY be used if more than 809 one signature is used. Note that no restriction is placed on the 810 encoding order of these tokens, the order of elements is logical 811 only. 813 This element is OPTIONAL. 815 Implements: REQ.USE.DELEGATION (Section 4.5.14), REQ.SEC.KEY.ROTATION 816 (Section 4.3.18) 818 4. Security Considerations 820 The following sub-sections describe the threat model, user stories, 821 security requirements, and usability requirements. This section also 822 provides the motivations for each of the manifest information 823 elements. 825 Note that it is worthwhile to recall that a firmware update is, by 826 definition, remote code execution. Hence, if a device is configured 827 to trust an entity to provide firmware, it trusts this entity to do 828 the "right thing". Many classes of attacks can be mitigated by 829 verifying that a firmware update came from a trusted party and that 830 no rollback is taking place. However, if the trusted entity has been 831 compromised and distributes attacker-provided firmware to devices 832 then the possibilities for deference are limited. 834 4.1. Threat Model 836 The following sub-sections aim to provide information about the 837 threats that were considered, the security requirements that are 838 derived from those threats and the fields that permit implementation 839 of the security requirements. This model uses the S.T.R.I.D.E. 840 [STRIDE] approach. Each threat is classified according to: 842 o Spoofing identity 844 o Tampering with data 846 o Repudiation 848 o Information disclosure 850 o Denial of service 852 o Elevation of privilege 854 This threat model only covers elements related to the transport of 855 firmware updates. It explicitly does not cover threats outside of 856 the transport of firmware updates. For example, threats to an IoT 857 device due to physical access are out of scope. 859 4.2. Threat Descriptions 861 Many of the threats detailed in this section contain a "threat 862 escalation" description. This explains how the described threat 863 might fit together with other threats and produce a high severity 864 threat. This is important because some of the described threats may 865 seem low severity but could be used with others to construct a high 866 severity compromise. 868 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 870 Classification: Elevation of Privilege 872 An attacker sends an old, but valid manifest with an old, but valid 873 firmware image to a device. If there is a known vulnerability in the 874 provided firmware image, this may allow an attacker to exploit the 875 vulnerability and gain control of the device. 877 Threat Escalation: If the attacker is able to exploit the known 878 vulnerability, then this threat can be escalated to ALL TYPES. 880 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 882 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old Firmware 884 Classification: Elevation of Privilege 886 An attacker targets a device that has been offline for a long time 887 and runs an old firmware version. The attacker sends an old, but 888 valid manifest to a device with an old, but valid firmware image. 889 The attacker-provided firmware is newer than the installed one but 890 older than the most recently available firmware. If there is a known 891 vulnerability in the provided firmware image then this may allow an 892 attacker to gain control of a device. Because the device has been 893 offline for a long time, it is unaware of any new updates. As such 894 it will treat the old manifest as the most current. 896 The exact mitigation for this threat depends on where the threat 897 comes from. This requires careful consideration by the implementor. 898 If the threat is from a network actor, including an on-path attacker, 899 or an intruder into a management system, then a user confirmation can 900 mitigate this attack, simply by displaying an expiration date and 901 requesting confirmation. On the other hand, if the user is the 902 attacker, then an online confirmation system (for example a trusted 903 timestamp server) can be used as a mitigation system. 905 Threat Escalation: If the attacker is able to exploit the known 906 vulnerability, then this threat can be escalated to ALL TYPES. 908 Mitigated by: REQ.SEC.EXP (Section 4.3.3), REQ.USE.MFST.PRE_CHECK 909 (Section 4.5.1), 911 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 913 Classification: Denial of Service 915 An attacker sends a valid firmware image, for the wrong type of 916 device, signed by an actor with firmware installation permission on 917 both types of device. The firmware is verified by the device 918 positively because it is signed by an actor with the appropriate 919 permission. This could have wide-ranging consequences. For devices 920 that are similar, it could cause minor breakage, or expose security 921 vulnerabilities. For devices that are very different, it is likely 922 to render devices inoperable. 924 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 926 For example, suppose that two vendors, Vendor A and Vendor B, adopt 927 the same trade name in different geographic regions, and they both 928 make products with the same names, or product name matching is not 929 used. This causes firmware from Vendor A to match devices from 930 Vendor B. 932 If the vendors are the firmware authorities, then devices from Vendor 933 A will reject images signed by Vendor B since they use different 934 credentials. However, if both devices trust the same Author, then, 935 devices from Vendor A could install firmware intended for devices 936 from Vendor B. 938 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 939 payload 941 Classification: Denial of Service 943 If a device misinterprets the format of the firmware image, it may 944 cause a device to install a firmware image incorrectly. An 945 incorrectly installed firmware image would likely cause the device to 946 stop functioning. 948 Threat Escalation: An attacker that can cause a device to 949 misinterpret the received firmware image may gain elevation of 950 privilege and potentially expand this to all types of threat. 952 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 954 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 955 the wrong location 957 Classification: Denial of Service 959 If a device installs a firmware image to the wrong location on the 960 device, then it is likely to break. For example, a firmware image 961 installed as an application could cause a device and/or an 962 application to stop functioning. 964 Threat Escalation: An attacker that can cause a device to 965 misinterpret the received code may gain elevation of privilege and 966 potentially expand this to all types of threat. 968 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 970 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 972 Classification: Denial of Service 974 If a device is tricked into fetching a payload for an attacker 975 controlled site, the attacker may send corrupted payloads to devices. 977 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 979 4.2.7. THREAT.NET.ONPATH: Traffic interception 981 Classification: Spoofing Identity, Tampering with Data 983 An attacker intercepts all traffic to and from a device. The 984 attacker can monitor or modify any data sent to or received from the 985 device. This can take the form of: manifests, payloads, status 986 reports, and capability reports being modified or not delivered to 987 the intended recipient. It can also take the form of analysis of 988 data sent to or from the device, either in content, size, or 989 frequency. 991 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), 992 REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC 993 (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), 994 REQ.SEC.REPORTING (Section 4.3.16) 996 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 998 Classification: Elevation of Privilege 1000 An attacker replaces a newly downloaded firmware after a device 1001 finishes verifying a manifest. This could cause the device to 1002 execute the attacker's code. This attack likely requires physical 1003 access to the device. However, it is possible that this attack is 1004 carried out in combination with another threat that allows remote 1005 execution. This is a typical Time Of Check/Time Of Use (TICTOC) 1006 attack. 1008 Threat Escalation: If the attacker is able to exploit a known 1009 vulnerability, or if the attacker can supply their own firmware, then 1010 this threat can be escalated to ALL TYPES. 1012 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 1014 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 1016 Classification: Elevation of Privilege / All Types 1018 If an attacker can install their firmware on a device, for example by 1019 manipulating either payload or metadata, then they have complete 1020 control of the device. 1022 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 1024 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 1026 Classification: Denial of Service / All Types 1028 Modifications of payloads and metadata allow an attacker to introduce 1029 a number of denial of service attacks. Below are some examples. 1031 An attacker sends a valid, current manifest to a device that has an 1032 unexpected precursor image. If a payload format requires a precursor 1033 image (for example, delta updates) and that precursor image is not 1034 available on the target device, it could cause the update to break. 1036 An attacker that can cause a device to install a payload against the 1037 wrong precursor image could gain elevation of privilege and 1038 potentially expand this to all types of threat. However, it is 1039 unlikely that a valid differential update applied to an incorrect 1040 precursor would result in a functional, but vulnerable firmware. 1042 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 1044 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 1046 Classification: Denial of Service, Elevation of Privilege 1048 This threat can appear in several ways, however it is ultimately 1049 about ensuring that devices retain the behaviour required by their 1050 owner, or operator. The owner or operator of a device typically 1051 requires that the device maintain certain features, functions, 1052 capabilities, behaviours, or interoperability constraints (more 1053 generally, behaviour). If these requirements are broken, then a 1054 device will not fulfill its purpose. Therefore, if any party other 1055 than the device's owner or the owner's contracted Device Operator has 1056 the ability to modify device behaviour without approval, then this 1057 constitutes an elevation of privilege. 1059 Similarly, a Network Operator may require that devices behave in a 1060 particular way in order to maintain the integrity of the network. If 1061 devices behaviour on a network can be modified without the approval 1062 of the Network Operator, then this constitutes an elevation of 1063 privilege with respect to the network. 1065 For example, if the owner of a device has purchased that device 1066 because of features A, B, and C, and a firmware update is issued by 1067 the manufacturer, which removes feature A, then the device may not 1068 fulfill the owner's requirements any more. In certain circumstances, 1069 this can cause significantly greater threats. Suppose that feature A 1070 is used to implement a safety-critical system, whether the 1071 manufacturer intended this behaviour or not. When unapproved 1072 firmware is installed, the system may become unsafe. 1074 In a second example, the owner or operator of a system of two or more 1075 interoperating devices needs to approve firmware for their system in 1076 order to ensure interoperability with other devices in the system. 1077 If the firmware is not qualified, the system as a whole may not work. 1078 Therefore, if a device installs firmware without the approval of the 1079 device owner or operator, this is a threat to devices or the system 1080 as a whole. 1082 Similarly, the operator of a network may need to approve firmware for 1083 devices attached to the network in order to ensure favourable 1084 operating conditions within the network. If the firmware is not 1085 qualified, it may degrade the performance of the network. Therefore, 1086 if a device installs firmware without the approval of the Network 1087 Operator, this is a threat to the network itself. 1089 Threat Escalation: If the firmware expects configuration that is 1090 present in devices deployed in Network A, but not in devices deployed 1091 in Network B, then the device may experience degraded security, 1092 leading to threats of All Types. 1094 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 1095 (Section 4.3.13) 1097 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 1098 Operator 1100 In this example, assume that Device Operators expect the rights to 1101 create firmware but that Network Operators expect the rights to 1102 qualify firmware as fit-for-purpose on their networks. Additionally, 1103 assume that Device Operators manage devices that can be deployed on 1104 any network, including Network A and B in our example. 1106 An attacker may obtain a manifest for a device on Network A. Then, 1107 this attacker sends that manifest to a device on Network B. Because 1108 Network A and Network B are under control of different Operators, and 1109 the firmware for a device on Network A has not been qualified to be 1110 deployed on Network B, the target device on Network B is now in 1111 violation of the Operator B's policy and may be disabled by this 1112 unqualified, but signed firmware. 1114 This is a denial of service because it can render devices inoperable. 1115 This is an elevation of privilege because it allows the attacker to 1116 make installation decisions that should be made by the Operator. 1118 4.2.11.2. Example 2: Single Network Operator with Multiple Device 1119 Operators 1121 Multiple devices that interoperate are used on the same network and 1122 communicate with each other. Some devices are manufactured and 1123 managed by Device Operator A and other devices by Device Operator B. 1124 A new firmware is released by Device Operator A that breaks 1125 compatibility with devices from Device Operator B. An attacker sends 1126 the new firmware to the devices managed by Device Operator A without 1127 approval of the Network Operator. This breaks the behaviour of the 1128 larger system causing denial of service and possibly other threats. 1129 Where the network is a distributed SCADA system, this could cause 1130 misbehaviour of the process that is under control. 1132 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 1133 for Vulnerability Analysis 1135 Classification: All Types 1137 An attacker wants to mount an attack on an IoT device. To prepare 1138 the attack he or she retrieves the provided firmware image and 1139 performs reverse engineering of the firmware image to analyze it for 1140 specific vulnerabilities. 1142 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1144 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 1146 Classification: Elevation of Privilege 1148 An authorized actor, but not the Author, uses an override mechanism 1149 (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information 1150 element in a manifest signed by the Author. For example, if the 1151 authorized actor overrides the digest and URI of the payload, the 1152 actor can replace the entire payload with a payload of their choice. 1154 Threat Escalation: By overriding elements such as payload 1155 installation instructions or firmware digest, this threat can be 1156 escalated to all types. 1158 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1160 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 1162 Classification: Information Disclosure 1164 A third party may be able to extract sensitive information from the 1165 manifest. 1167 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 1169 4.2.15. THREAT.IMG.EXTRA: Extra data after image 1171 Classification: All Types 1173 If a third party modifies the image so that it contains extra code 1174 after a valid, authentic image, that third party can then use their 1175 own code in order to make better use of an existing vulnerability. 1177 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 1179 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 1181 Classification: All Types 1183 If a third party obtains a key or even indirect access to a key, for 1184 example in an hardware security module (HSM), then they can perform 1185 the same actions as the legitimate owner of the key. If the key is 1186 trusted for firmware update, then the third party can perform 1187 firmware updates as though they were the legitimate owner of the key. 1189 For example, if manifest signing is performed on a server connected 1190 to the internet, an attacker may compromise the server and then be 1191 able to sign manifests, even if the keys for manifest signing are 1192 held in an HSM that is accessed by the server. 1194 Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17), 1195 REQ.SEC.KEY.ROTATION (Section 4.3.18) 1197 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 1198 prior to signing 1200 Classification: All Types 1202 If an attacker can alter a manifest or payload before it is signed, 1203 they can perform all the same actions as the manifest author. This 1204 allows the attacker to deploy firmware updates to any devices that 1205 trust the manifest author. If an attacker can modify the code of a 1206 payload before the corresponding manifest is created, they can insert 1207 their own code. If an attacker can modify the manifest before it is 1208 signed, they can redirect the manifest to their own payload. 1210 For example, the attacker deploys malware to the developer's computer 1211 or signing service that watches manifest creation activities and 1212 inserts code into any binary that is referenced by a manifest. 1214 For example, the attacker deploys malware to the developer's computer 1215 or signing service that replaces the referenced binary (digest) and 1216 URI with the attacker's binary (digest) and URI. 1218 Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.19), 1219 REQ.SEC.MFST.TRUSTED (Section 4.3.20) 1221 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 1222 authentication and use 1224 Classification: All Types 1226 If an attacker can modify a manifest after it is authenticated (Time 1227 Of Check) but before it is used (Time Of Use), then the attacker can 1228 place any content whatsoever in the manifest. 1230 Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.21) 1232 4.3. Security Requirements 1234 The security requirements here are a set of policies that mitigate 1235 the threats described in Section 4.1. 1237 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 1239 Only an actor with firmware installation authority is permitted to 1240 decide when device firmware can be installed. To enforce this rule, 1241 manifests MUST contain monotonically increasing sequence numbers. 1242 Manifests may use UTC epoch timestamps to coordinate monotonically 1243 increasing sequence numbers across many actors in many locations. If 1244 UTC epoch timestamps are used, they must not be treated as times, 1245 they must be treated only as sequence numbers. Devices must reject 1246 manifests with sequence numbers smaller than any onboard sequence 1247 number, i.e. there is no sequence number roll over. 1249 Note: This is not a firmware version field. It is a manifest 1250 sequence number. A firmware version may be rolled back by creating a 1251 new manifest for the old firmware version with a later sequence 1252 number. 1254 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 1256 Implemented by: Monotonic Sequence Number (Section 3.2) 1258 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1260 Devices MUST only apply firmware that is intended for them. Devices 1261 must know that a given update applies to their vendor, model, 1262 hardware revision, and software revision. Human-readable identifiers 1263 are often error-prone in this regard, so unique identifiers should be 1264 used instead. 1266 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1268 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1269 (Section 3.4) 1271 4.3.3. REQ.SEC.EXP: Expiration Time 1273 A firmware manifest MAY expire after a given time and devices may 1274 have a secure clock (local or remote). If a secure clock is provided 1275 and the Firmware manifest has an expiration timestamp, the device 1276 must reject the manifest if current time is later than the expiration 1277 time. 1279 Special consideration is required for end-of-life in case device will 1280 not be updated again, for example if a business stops issuing updates 1281 for a device. The last valid firmware should not have an expiration 1282 time. 1284 If a device has a flawed time source (either local or remote), an old 1285 update can be deployed as new. 1287 Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2) 1289 Implemented by: Expiration Time (Section 3.7) 1291 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1293 The authenticity of an update MUST be demonstrable. Typically, this 1294 means that updates must be digitally signed. Because the manifest 1295 contains information about how to install the update, the manifest's 1296 authenticity must also be demonstrable. To reduce the overhead 1297 required for validation, the manifest contains the cryptographic 1298 digest of the firmware image, rather than a second digital signature. 1299 The authenticity of the manifest can be verified with a digital 1300 signature or Message Authentication Code. The authenticity of the 1301 firmware image is tied to the manifest by the use of a cryptographic 1302 digest of the firmware image. 1304 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.ONPATH 1305 (Section 4.2.7) 1307 Implemented by: Signature (Section 3.15), Payload Digest 1308 (Section 3.13) 1310 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1312 The type of payload MUST be authenticated. For example, the target 1313 must know whether the payload is XIP firmware, a loadable module, or 1314 configuration data. 1316 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1318 Implemented by: Payload Format (Section 3.8), Signature 1319 (Section 3.15) 1321 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1322 Location 1324 The location on the target where the payload is to be stored MUST be 1325 authenticated. 1327 Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) 1329 Implemented by: Storage Location (Section 3.10) 1331 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 1333 The location where a target should find a payload MUST be 1334 authenticated. Remote resources need to receive an equal amount of 1335 cryptographic protection as the manifest itself, when dereferencing 1336 URIs. The security considerations of Uniform Resource Identifiers 1337 (URIs) are applicable [RFC3986]. 1339 Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.ONPATH 1340 (Section 4.2.7) 1342 Implemented by: Payload Indicator (Section 3.12) 1344 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 1346 The target SHOULD verify firmware at time of boot. This requires 1347 authenticated payload size, and digest. 1349 Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) 1351 Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) 1353 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 1355 If an update uses a differential compression method, it MUST specify 1356 the digest of the precursor image and that digest MUST be 1357 authenticated. 1359 Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10) 1361 Implemented by: Precursor Image Digest (Section 3.5) 1363 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs 1365 The identifiers that specify firmware compatibility MUST be 1366 authenticated to ensure that only compatible firmware is installed on 1367 a target device. 1369 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1371 Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition 1372 (Section 3.4) 1374 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 1376 If a device grants different rights to different actors, exercising 1377 those rights MUST be accompanied by proof of those rights, in the 1378 form of proof of authenticity. Authenticity mechanisms, such as 1379 those required in REQ.SEC.AUTHENTIC (Section 4.3.4), can be used to 1380 prove authenticity. 1382 For example, if a device has a policy that requires that firmware 1383 have both an Authorship right and a Qualification right and if that 1384 device grants Authorship and Qualification rights to different 1385 parties, such as a Device Operator and a Network Operator, 1386 respectively, then the firmware cannot be installed without proof of 1387 rights from both the Device Operator and the Network Operator. 1389 Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11) 1391 Implemented by: Signature (Section 3.15) 1393 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 1395 The manifest information model MUST enable encrypted payloads. 1396 Encryption helps to prevent third parties, including attackers, from 1397 reading the content of the firmware image. This can protect against 1398 confidential information disclosures and discovery of vulnerabilities 1399 through reverse engineering. Therefore the manifest must convey the 1400 information required to allow an intended recipient to decrypt an 1401 encrypted payload. 1403 Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.ONPATH 1404 (Section 4.2.7) 1406 Implemented by: Encryption Wrapper (Section 3.20) 1408 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 1410 If a device grants different rights to different actors, then an 1411 exercise of those rights MUST be validated against a list of rights 1412 for the actor. This typically takes the form of an Access Control 1413 List (ACL). ACLs are applied to two scenarios: 1415 1. An ACL decides which elements of the manifest may be overridden 1416 and by which actors. 1418 2. An ACL decides which component identifier/storage identifier 1419 pairs can be written by which actors. 1421 Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), 1422 THREAT.UPD.UNAPPROVED (Section 4.2.11) 1424 Implemented by: Client-side code, not specified in manifest. 1426 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 1428 A manifest format MUST allow encryption of selected parts of the 1429 manifest or encryption of the entire manifest to prevent sensitive 1430 content of the firmware metadata to be leaked. 1432 Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.ONPATH 1433 (Section 4.2.7) 1435 Implemented by: Manifest Encryption Wrapper / Transport Security 1437 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 1439 The digest SHOULD cover all available space in a fixed-size storage 1440 location. Variable-size storage locations MUST be restricted to 1441 exactly the size of deployed payload. This prevents any data from 1442 being distributed without being covered by the digest. For example, 1443 XIP microcontrollers typically have fixed-size storage. These 1444 devices should deploy a digest that covers the deployed firmware 1445 image, concatenated with the default erased value of any remaining 1446 space. 1448 Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) 1450 Implemented by: Payload Digests (Section 3.13) 1452 4.3.16. REQ.SEC.REPORTING: Secure Reporting 1454 Status reports from the device to any remote system MUST be performed 1455 over an authenticated, confidential channel in order to prevent 1456 modification or spoofing of the reports. 1458 Mitigates: THREAT.NET.ONPATH (Section 4.2.7) 1460 Implemented by: Transport Security / Manifest format triggering 1461 generation of reports 1463 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 1465 Cryptographic keys for signing/authenticating manifests SHOULD be 1466 stored in a manner that is inaccessible to networked devices, for 1467 example in an HSM, or an air-gapped computer. This protects against 1468 an attacker obtaining the keys. 1470 Keys SHOULD be stored in a way that limits the risk of a legitimate, 1471 but compromised, entity (such as a server or developer computer) 1472 issuing signing requests. 1474 Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) 1476 Implemented by: Hardware-assisted isolation technologies, which are 1477 outside the scope of the manifest format. 1479 4.3.18. REQ.SEC.KEY.ROTATION: Protected storage of signing keys 1481 Cryptographic keys for signing/authenticating manifests SHOULD be 1482 replaced from time to time. Because it is difficult and risky to 1483 replace a Trust Anchor, keys used for signing updates SHOULD be 1484 delegates of that Trust Anchor. 1486 If key expiration is performed based on time, then a secure clock is 1487 needed. If the time source used by a recipient to check for 1488 expiration is flawed, an old signing key can be used as current, 1489 which compounds THREAT.KEY.EXPOSURE (Section 4.2.16). 1491 Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) 1493 Implemented by: Secure storage technology, which is a system design/ 1494 implementation aspect outside the scope of the manifest format. 1496 4.3.19. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment 1498 Manifests SHOULD be verified prior to deployment. This reduces 1499 problems that may arise with devices installing firmware images that 1500 damage devices unintentionally. 1502 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1504 Implemented by: Testing infrastructure. While outside the scope of 1505 the manifest format, proper testing of low-level software is 1506 essential for avoiding unnecessary down-time or worse situations. 1508 4.3.20. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted 1509 environment 1511 For high risk deployments, such as large numbers of devices or 1512 critical function devices, manifests SHOULD be constructed in an 1513 environment that is protected from interference, such as an air- 1514 gapped computer. Note that a networked computer connected to an HSM 1515 does not fulfill this requirement (see THREAT.MFST.MODIFICATION 1516 (Section 4.2.17)). 1518 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1519 Implemented by: Physical and network security for protecting the 1520 environment where firmware updates are prepared to avoid unauthorized 1521 access to this infrastructure. 1523 4.3.21. REQ.SEC.MFST.CONST: Manifest kept immutable between check and 1524 use 1526 Both the manifest and any data extracted from it MUST be held 1527 immutable between its authenticity verification (time of check) and 1528 its use (time of use). To make this guarantee, the manifest MUST fit 1529 within an internal memory or a secure memory, such as encrypted 1530 memory. The recipient SHOULD defend the manifest from tampering by 1531 code or hardware resident in the recipient, for example other 1532 processes or debuggers. 1534 If an application requires that the manifest is verified before 1535 storing it, then this means the manifest MUST fit in RAM. 1537 Mitigates: THREAT.MFST.TOCTOU (Section 4.2.18) 1539 Implemented by: Proper system design with sufficient resources and 1540 implementation avoiding TOCTOU attacks. 1542 4.4. User Stories 1544 User stories provide expected use cases. These are used to feed into 1545 usability requirements. 1547 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 1549 As a Device Operator, I want to provide my devices with additional 1550 installation instructions so that I can keep process details out of 1551 my payload data. 1553 Some installation instructions might be: 1555 o Use a table of hashes to ensure that each block of the payload is 1556 validated before writing. 1558 o Do not report progress. 1560 o Pre-cache the update, but do not install. 1562 o Install the pre-cached update matching this manifest. 1564 o Install this update immediately, overriding any long-running 1565 tasks. 1567 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1569 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 1571 As a designer of a resource-constrained IoT device, I want bad 1572 updates to fail as early as possible to preserve battery life and 1573 limit consumed bandwidth. 1575 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1577 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 1579 As a Device Operator, I would like to be able to override the non- 1580 critical information in the manifest so that I can control my devices 1581 more precisely. The authority to override this information is 1582 provided via the installation of a limited trust anchor by another 1583 authority. 1585 Some examples of potentially overridable information: 1587 o URIs (Section 3.12): this allows the Device Operator to direct 1588 devices to their own infrastructure in order to reduce network 1589 load. 1591 o Conditions: this allows the Device Operator to pose additional 1592 constraints on the installation of the manifest. 1594 o Directives (Section 3.16): this allows the Device Operator to add 1595 more instructions such as time of installation. 1597 o Processing Steps (Section 3.9): If an intermediary performs an 1598 action on behalf of a device, it may need to override the 1599 processing steps. It is still possible for a device to verify the 1600 final content and the result of any processing step that specifies 1601 a digest. Some processing steps should be non-overridable. 1603 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.4) 1605 4.4.4. USER_STORY.COMPONENT: Component Update 1607 As a Device Operator, I want to divide my firmware into components, 1608 so that I can reduce the size of updates, make different parties 1609 responsible for different components, and divide my firmware into 1610 frequently updated and infrequently updated components. 1612 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.4) 1614 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations 1616 As a Device Operator, I want to ensure the quality of a firmware 1617 update before installing it, so that I can ensure interoperability of 1618 all devices in my product family. I want to restrict the ability to 1619 make changes to my devices to require my express approval. 1621 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.5), 1622 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1624 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1626 As a Device Operator, I want to be able to send multiple payload 1627 formats to suit the needs of my update, so that I can optimise the 1628 bandwidth used by my devices. 1630 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.6) 1632 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1633 Disclosures 1635 As a firmware author, I want to prevent confidential information in 1636 the manifest from being disclosed when distributing manifests and 1637 firmware images. Confidential information may include information 1638 about the device these updates are being applied to as well as 1639 information in the firmware image itself. 1641 Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1643 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 1644 Unknown Formats 1646 As a Device Operator, I want devices to determine whether they can 1647 process a payload prior to downloading it. 1649 In some cases, it may be desirable for a third party to perform some 1650 processing on behalf of a target. For this to occur, the third party 1651 MUST indicate what processing occurred and how to verify it against 1652 the Trust Provisioning Authority's intent. 1654 This amounts to overriding Processing Steps (Section 3.9) and Payload 1655 Indicator (Section 3.12). 1657 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.6), REQ.USE.IMG.NESTED 1658 (Section 4.5.7), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.3) 1660 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 1661 Target Firmware 1663 As a Device Operator, I want to be able to target devices for updates 1664 based on their current firmware version, so that I can control which 1665 versions are replaced with a single manifest. 1667 Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.8) 1669 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 1671 As a developer, I want to be able to sign two or more versions of my 1672 firmware in a single manifest so that I can use a very simple 1673 bootloader that chooses between two or more images that are executed 1674 in-place. 1676 Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.9) 1678 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 1680 As a signer for both secure execution/boot and firmware deployment, I 1681 would like to use the same signed document for both tasks so that my 1682 data size is smaller, I can share common code, and I can reduce 1683 signature verifications. 1685 Satisfied by: REQ.USE.EXEC (Section 4.5.10) 1687 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 1689 As a developer of firmware for a run-from-RAM device, I would like to 1690 use compressed images and to indicate to the bootloader that I am 1691 using a compressed image in the manifest so that it can be used with 1692 secure execution/boot. 1694 Satisfied by: REQ.USE.LOAD (Section 4.5.11) 1696 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 1698 As an operator of devices on a constrained network, I would like the 1699 manifest to be able to include a small payload in the same packet so 1700 that I can reduce network traffic. 1702 Small payloads may include, for example, wrapped content encryption 1703 keys, configuration information, public keys, authorization tokens, 1704 or X.509 certificates. 1706 Satisfied by: REQ.USE.PAYLOAD (Section 4.5.12) 1708 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 1710 As a developer for constrained devices, I want a low complexity 1711 library for processing updates so that I can fit more application 1712 code on my device. 1714 Satisfied by: REQ.USE.PARSE (Section 4.5.13) 1716 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 1718 As a Device Operator that rotates delegated authority more often than 1719 delivering firmware updates, I would like to delegate a new authority 1720 when I deliver a firmware update so that I can accomplish both tasks 1721 in a single transmission. 1723 Satisfied by: REQ.USE.DELEGATION (Section 4.5.14) 1725 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 1727 As an operator of a constrained network, I would like devices on my 1728 network to be able to evaluate the suitability of an update prior to 1729 initiating any large download so that I can prevent unnecessary 1730 consumption of bandwidth. 1732 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1734 4.4.17. USER_STORY.MFST.ADMINISTRATION: Administration of manifests 1736 As a Device Operator, I want to understand what an update will do and 1737 to which devices it applies so that I can make informed choices about 1738 which updates to apply, when to apply them, and which devices should 1739 be updated. 1741 Satisfied by REQ.USE.MFST.TEXT (Section 4.5.2) 1743 4.5. Usability Requirements 1745 The following usability requirements satisfy the user stories listed 1746 above. 1748 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 1750 A manifest format MUST be able to carry all information required to 1751 process an update. 1753 For example: Information about which precursor image is required for 1754 a differential update must be placed in the manifest. 1756 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1757 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1759 Implemented by: Additional installation instructions (Section 3.16) 1761 4.5.2. REQ.USE.MFST.TEXT: Descriptive Manifest Information 1763 It MUST be possible for a Device Operator to determine what a 1764 manifest will do and which devices will accept it prior to 1765 distribution. 1767 Satisfies: USER_STORY.MFST.ADMINISTRATION (Section 4.4.17) 1769 Implemented by: Manifest text information (Section 3.17) 1771 4.5.3. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1773 A manifest format MUST be able to redirect payload fetches. This 1774 applies where two manifests are used in conjunction. For example, a 1775 Device Operator creates a manifest specifying a payload and signs it, 1776 and provides a URI for that payload. A Network Operator creates a 1777 second manifest, with a dependency on the first. They use this 1778 second manifest to override the URIs provided by the Device Operator, 1779 directing them into their own infrastructure instead. Some devices 1780 may provide this capability, while others may only look at canonical 1781 sources of firmware. For this to be possible, the device must fetch 1782 the payload, whereas a device that accepts payload pushes will ignore 1783 this feature. 1785 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1787 Implemented by: Aliases (Section 3.18) 1789 4.5.4. REQ.USE.MFST.COMPONENT: Component Updates 1791 A manifest format MUST be able to express the requirement to install 1792 one or more payloads from one or more authorities so that a multi- 1793 payload update can be described. This allows multiple parties with 1794 different permissions to collaborate in creating a single update for 1795 the IoT device, across multiple components. 1797 This requirement implies that it must be possible to construct a tree 1798 of manifests on a multi-image target. 1800 In order to enable devices with a heterogeneous storage architecture, 1801 the manifest must enable specification of both storage system and the 1802 storage location within that storage system. 1804 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1805 (Section 4.4.4) 1807 Implemented by: Dependencies, StorageIdentifier, ComponentIdentifier 1809 4.5.4.1. Example 1: Multiple Microcontrollers 1811 An IoT device with multiple microcontrollers in the same physical 1812 device will likely require multiple payloads with different component 1813 identifiers. 1815 4.5.4.2. Example 2: Code and Configuration 1817 A firmware image can be divided into two payloads: code and 1818 configuration. These payloads may require authorizations from 1819 different actors in order to install (see REQ.SEC.RIGHTS 1820 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1821 structure means that multiple manifests may be required, with a 1822 dependency structure between them. 1824 4.5.4.3. Example 3: Multiple Software Modules 1826 A firmware image can be divided into multiple functional blocks for 1827 separate testing and distribution. This means that code would need 1828 to be distributed in multiple payloads. For example, this might be 1829 desirable in order to ensure that common code between devices is 1830 identical in order to reduce distribution bandwidth. 1832 4.5.5. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1834 A manifest format MUST be able to carry multiple signatures so that 1835 authorizations from multiple parties with different permissions can 1836 be required in order to authorize installation of a manifest. 1838 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1840 Implemented by: Signature (Section 3.15) 1842 4.5.6. REQ.USE.IMG.FORMAT: Format Usability 1844 The manifest format MUST accommodate any payload format that an 1845 Operator wishes to use. This enables the recipient to detect which 1846 format the Operator has chosen. Some examples of payload format are: 1848 o Binary 1850 o Executable and Linkable Format (ELF) 1851 o Differential 1853 o Compressed 1855 o Packed configuration 1857 o Intel HEX 1859 o Motorola S-Record 1861 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1862 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1864 Implemented by: Payload Format (Section 3.8) 1866 4.5.7. REQ.USE.IMG.NESTED: Nested Formats 1868 The manifest format MUST accommodate nested formats, announcing to 1869 the target device all the nesting steps and any parameters used by 1870 those steps. 1872 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1874 Implemented by: Processing Steps (Section 3.9) 1876 4.5.8. REQ.USE.IMG.VERSIONS: Target Version Matching 1878 The manifest format MUST provide a method to specify multiple version 1879 numbers of firmware to which the manifest applies, either with a list 1880 or with range matching. 1882 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1884 Implemented by: Required Image Version List (Section 3.6) 1886 4.5.9. REQ.USE.IMG.SELECT: Select Image by Destination 1888 The manifest format MUST provide a mechanism to list multiple 1889 equivalent payloads by Execute-In-Place Installation Address, 1890 including the payload digest and, optionally, payload URIs. 1892 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1894 Implemented by: XIP Address (Section 3.21) 1896 4.5.10. REQ.USE.EXEC: Executable Manifest 1898 The manifest format MUST allow to describe an executable system with 1899 a manifest on both Execute-In-Place microcontrollers and on complex 1900 operating systems. In addition, the manifest format MUST be able to 1901 express metadata, such as a kernel command-line, used by any loader 1902 or bootloader. 1904 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1906 Implemented by: Run-time metadata (Section 3.23) 1908 4.5.11. REQ.USE.LOAD: Load-Time Information 1910 The manifest format MUST enable carrying additional metadata for load 1911 time processing of a payload, such as cryptographic information, 1912 load-address, and compression algorithm. Note that load comes before 1913 execution/boot. 1915 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1917 Implemented by: Load-time metadata (Section 3.22) 1919 4.5.12. REQ.USE.PAYLOAD: Payload in Manifest Envelope 1921 The manifest format MUST allow placing a payload in the same 1922 structure as the manifest. This may place the payload in the same 1923 packet as the manifest. 1925 Integrated payloads may include, for example, binaries as well as 1926 configuration information, and keying material. 1928 When an integrated payload is provided, this increases the size of 1929 the manifest. Manifest size can cause several processing and storage 1930 concerns that require careful consideration. The payload can prevent 1931 the whole manifest from being contained in a single network packet, 1932 which can cause fragmentation and the loss of portions of the 1933 manifest in lossy networks. This causes the need for reassembly and 1934 retransmission logic. The manifest MUST be held immutable between 1935 verification and processing (see REQ.SEC.MFST.CONST 1936 (Section 4.3.21)), so a larger manifest will consume more memory with 1937 immutability guarantees, for example internal RAM or NVRAM, or 1938 external secure memory. If the manifest exceeds the available 1939 immutable memory, then it MUST be processed modularly, evaluating 1940 each of: delegation chains, the security container, and the actual 1941 manifest, which includes verifying the integrated payload. If the 1942 security model calls for downloading the manifest and validating it 1943 before storing to NVRAM in order to prevent wear to NVRAM and energy 1944 expenditure in NVRAM, then either increasing memory allocated to 1945 manifest storage or modular processing of the received manifest may 1946 be required. While the manifest has been organised to enable this 1947 type of processing, it creates additional complexity in the parser. 1948 If the manifest is stored in NVRAM prior to processing, the 1949 integrated payload may cause the manifest to exceed the available 1950 storage. Because the manifest is received prior to validation of 1951 applicability, authority, or correctness, integrated payloads cause 1952 the recipient to expend network bandwidth and energy that may not be 1953 required if the manifest is discarded and these costs vary with the 1954 size of the integrated payload. 1956 See also: REQ.SEC.MFST.CONST (Section 4.3.21). 1958 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1960 Implemented by: Payload (Section 3.24) 1962 4.5.13. REQ.USE.PARSE: Simple Parsing 1964 The structure of the manifest MUST be simple to parse to reduce the 1965 attack vectors against manifest parsers. 1967 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1969 Implemented by: N/A 1971 4.5.14. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1973 A manifest format MUST enable the delivery of delegation information. 1974 This information delivers a new key with which the recipient can 1975 verify the manifest. 1977 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1979 Implemented by: Delegation Chain (Section 3.25) 1981 5. IANA Considerations 1983 This document does not require any actions by IANA. 1985 6. Acknowledgements 1987 We would like to thank our working group chairs, Dave Thaler, Russ 1988 Housley and David Waltermire, for their review comments and their 1989 support. 1991 We would like to thank the participants of the 2018 Berlin SUIT 1992 Hackathon and the June 2018 virtual design team meetings for their 1993 discussion input. 1995 In particular, we would like to thank Koen Zandberg, Emmanuel 1996 Baccelli, Carsten Bormann, David Brown, Markus Gueller, Frank Audun 1997 Kvamtro, Oyvind Ronningstad, Michael Richardson, Jan-Frederik 1998 Rieckers, Francisco Acosta, Anton Gerasimov, Matthias Waehlisch, Max 1999 Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, Steve Patrick, 2000 Fabio Utzig, Paul Lambert, Said Gharout, and Milen Stoychev. 2002 We would like to thank those who contributed to the development of 2003 this information model. In particular, we would like to thank 2004 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary 2005 Thomson. 2007 Finally, we would like to thank the following IESG members for their 2008 review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa 2009 Cooper, Stephen Farrell and Benjamin Kaduk. 2011 7. References 2013 7.1. Normative References 2015 [I-D.ietf-suit-architecture] 2016 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 2017 Firmware Update Architecture for Internet of Things", 2018 draft-ietf-suit-architecture-16 (work in progress), 2019 January 2021. 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2022 Requirement Levels", BCP 14, RFC 2119, 2023 DOI 10.17487/RFC2119, March 1997, 2024 . 2026 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2027 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2028 DOI 10.17487/RFC4122, July 2005, 2029 . 2031 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2032 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2033 May 2017, . 2035 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2036 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2037 May 2018, . 2039 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2040 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2041 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2042 2020, . 2044 7.2. Informative References 2046 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2047 Information Models and Data Models", RFC 3444, 2048 DOI 10.17487/RFC3444, January 2003, 2049 . 2051 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2052 Resource Identifier (URI): Generic Syntax", STD 66, 2053 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2054 . 2056 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 2057 . 2060 Authors' Addresses 2062 Brendan Moran 2063 Arm Limited 2065 EMail: Brendan.Moran@arm.com 2067 Hannes Tschofenig 2068 Arm Limited 2070 EMail: hannes.tschofenig@gmx.net 2072 Henk Birkholz 2073 Fraunhofer SIT 2075 EMail: henk.birkholz@sit.fraunhofer.de