idnits 2.17.1 draft-ietf-suit-information-model-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 168 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 20, 2020) is 1555 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1887 -- Looks like a reference, but probably isn't: '2' on line 1889 -- Looks like a reference, but probably isn't: '3' on line 1892 == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-08 ** Downref: Normative reference to an Informational draft: draft-ietf-suit-architecture (ref. 'I-D.ietf-suit-architecture') -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 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: Standards Track Arm Limited 5 Expires: July 23, 2020 H. Birkholz 6 Fraunhofer SIT 7 January 20, 2020 9 An Information Model for Firmware Updates in IoT Devices 10 draft-ietf-suit-information-model-05 12 Abstract 14 Vulnerabilities with Internet of Things (IoT) devices have raised the 15 need for a solid 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 July 23, 2020. 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 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 74 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 75 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 76 3.1. Manifest Element: Version ID of the manifest structure . 6 77 3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6 78 3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 7 79 3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7 80 3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7 81 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8 82 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 9 83 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9 84 3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 9 85 3.5. Manifest Element: Precursor Image Digest Condition . . . 10 86 3.6. Manifest Element: Required Image Version List . . . . . . 10 87 3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10 88 3.8. Manifest Element: Payload Format . . . . . . . . . . . . 11 89 3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11 90 3.10. Manifest Element: Storage Location . . . . . . . . . . . 11 91 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 12 92 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12 93 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12 94 3.11. Manifest Element: Component Identifier . . . . . . . . . 12 95 3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12 96 3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 13 97 3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13 98 3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13 99 3.16. Manifest Element: Additional installation instructions . 14 100 3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14 101 3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 14 102 3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 15 103 3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 15 104 3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15 105 3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 15 106 3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 16 107 3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 16 108 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 109 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16 110 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17 111 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 17 112 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old 113 Firmware . . . . . . . . . . . . . . . . . . . . . . 17 114 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 17 115 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 116 the type of payload . . . . . . . . . . . . . . . . . 18 117 4.2.5. THREAT.IMG.LOCATION: The target device installs the 118 payload to the wrong location . . . . . . . . . . . . 18 119 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 120 payload hosting . . . . . . . . . . . . . . . . . . . 19 121 4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 19 122 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 19 123 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 20 124 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 125 images . . . . . . . . . . . . . . . . . . . . . . . 20 126 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 20 127 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of 128 Firmware Image for Vulnerability Analysis . . . . . . 22 129 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 130 Elements . . . . . . . . . . . . . . . . . . . . . . 22 131 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 132 Exposure . . . . . . . . . . . . . . . . . . . . . . 23 133 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 23 134 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 23 135 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or 136 payload prior to signing . . . . . . . . . . . . . . 23 137 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 138 authentication and use . . . . . . . . . . . . . . . 24 139 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 24 140 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 24 141 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 25 142 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 25 143 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 25 144 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 25 145 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 146 Authenticated Storage Location . . . . . . . . . . . 26 147 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote 148 Resource Location . . . . . . . . . . . . . . . . . . 26 149 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 26 150 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 151 images . . . . . . . . . . . . . . . . . . . . . . . 26 152 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 153 Class IDs . . . . . . . . . . . . . . . . . . . . . . 27 154 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 27 155 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 27 156 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 28 157 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 28 158 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 28 159 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 29 160 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing 161 keys . . . . . . . . . . . . . . . . . . . . . . . . 29 162 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to 163 deployment . . . . . . . . . . . . . . . . . . . . . 29 164 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 165 trusted environment . . . . . . . . . . . . . . . . . 29 166 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between 167 check and use . . . . . . . . . . . . . . . . . . . . 29 168 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 30 169 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 170 Instructions . . . . . . . . . . . . . . . . . . . . 30 171 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 30 172 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 173 Elements . . . . . . . . . . . . . . . . . . . . . . 31 174 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 31 175 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 31 176 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 32 177 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 178 Information Disclosures . . . . . . . . . . . . . . . 32 179 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from 180 Unpacking Unknown Formats . . . . . . . . . . . . . . 32 181 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 182 Numbers of Target Firmware . . . . . . . . . . . . . 32 183 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 184 Between Images . . . . . . . . . . . . . . . . . . . 33 185 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 186 Manifests . . . . . . . . . . . . . . . . . . . . . . 33 187 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 33 188 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 33 189 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 33 190 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 191 Manifest . . . . . . . . . . . . . . . . . . . . . . 34 193 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 34 194 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 34 195 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 34 196 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 197 Resource Location . . . . . . . . . . . . . . . . . . 34 198 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 35 199 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 36 200 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 36 201 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 36 202 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 37 203 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 37 204 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 37 205 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 37 206 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 38 207 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 39 208 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 209 Manifest . . . . . . . . . . . . . . . . . . . . . . 39 210 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 211 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 212 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 213 7.1. Normative References . . . . . . . . . . . . . . . . . . 40 214 7.2. Informative References . . . . . . . . . . . . . . . . . 40 215 Appendix A. Mailing List Information . . . . . . . . . . . . . . 42 216 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 218 1. Introduction 220 The information model describes all the information elements required 221 to secure firmware updates of IoT devices from the threats described 222 in Section 4.1 and enables the user stories captured in Section 4.4. 223 These threats and user stories are not intended to be an exhaustive 224 list of the threats against IoT devices, nor of the possible user 225 stories that describe how to conduct a firmware update. Instead they 226 are intended to describe the threats against firmware updates in 227 isolation and provide sufficient motivation to specify the 228 information elements that cover a wide range of user stories. The 229 information model does not define the serialization, encoding, 230 ordering, or structure of information elements, only their semantics. 232 Because the information model covers a wide range of user stories and 233 a wide range of threats, not all information elements apply to all 234 scenarios. As a result, various information elements could be 235 considered optional to implement and optional to use, depending on 236 which threats exist in a particular domain of application and which 237 user stories are required. Elements marked as REQUIRED provide 238 baseline security and usability properties that are expected to be 239 required for most applications. Those elements are REQUIRED to 240 implement and REQUIRED to use. Elements marked as recommended 241 provide important security or usability properties that are needed on 242 most devices. Elements marked as optional enable security or 243 usability properties that are useful in some applications. 245 The definition of some of the information elements include examples 246 that illustrate their semantics and how they are intended to be used. 248 2. Conventions and Terminology 250 This document uses terms defined in [I-D.ietf-suit-architecture]. 251 The term 'Operator' refers to both Device and Network Operator. 253 This document treats devices with a homogeneous storage architecture 254 as devices with a heterogeneous storage architecture, but with a 255 single storage subsystem. 257 2.1. Requirements Notation 259 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 260 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 261 "OPTIONAL" in this document are to be interpreted as described in 262 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 263 capitals, as shown here. 265 3. Manifest Information Elements 267 Each manifest information element is anchored in a security 268 requirement or a usability requirement. The manifest elements are 269 described below, justified by their requirements. 271 3.1. Manifest Element: Version ID of the manifest structure 273 An identifier that describes which iteration of the manifest format 274 is contained in the structure. 276 This element is REQUIRED and MUST be present in order to allow 277 devices to identify the version of the manifest data model that is in 278 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 easily accessible so that code 286 choosing one out of several manifests can choose which is the latest. 288 This element is REQUIRED and is necessary to prevent malicious actors 289 from reverting a firmware update against the policies of the relevant 290 authority. 292 Implements: REQ.SEC.SEQUENCE (Section 4.3.1) 294 3.3. Manifest Element: Vendor ID 296 Vendor IDs must be unique. This is to prevent similarly, or 297 identically named entities from different geographic regions from 298 colliding in their customer's infrastructure. Recommended practice 299 is to use [RFC4122] version 5 UUIDs with the vendor's domain name and 300 the DNS name space ID. Other options include type 1 and type 4 301 UUIDs. 303 Vendor ID is not intended to be a human-readable element. It is 304 intended for binary match/mismatch comparison only. 306 The use of a Vendor ID is RECOMMENDED. It helps to distinguish 307 between identically named products from different vendors. 309 Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), 310 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 312 3.3.1. Example: Domain Name-based UUIDs 314 Vendor A creates a UUID based on their domain name: 316 vendorId = UUID5(DNS, "vendor-a.com") 318 Because the DNS infrastructure prevents multiple registrations of the 319 same domain name, this UUID is (with very high probability) 320 guaranteed to be unique. Because the domain name is known, this UUID 321 is reproducible. Type 1 and type 4 UUIDs produce similar guarantees 322 of uniqueness, but not reproducibility. 324 This approach creates a contention when a vendor changes its name or 325 relinquishes control of a domain name. In this scenario, it is 326 possible that another vendor would start using that same domain name. 327 However, this UUID is not proof of identity; a device's trust in a 328 vendor must be anchored in a cryptographic key, not a UUID. 330 3.4. Manifest Element: Class ID 332 A device "Class" is a set of different device types that can accept 333 the same firmware update without modification. Class IDs MUST be 334 unique within the scope of a Vendor ID. This is to prevent 335 similarly, or identically named devices colliding in their customer's 336 infrastructure. 338 Recommended practice is to use [RFC4122] version 5 UUIDs with as much 339 information as necessary to define firmware compatibility. Possible 340 information used to derive the class UUID includes: 342 o model name or number 344 o hardware revision 346 o runtime library version 348 o bootloader version 350 o ROM revision 352 o silicon batch number 354 The Class Identifier UUID SHOULD use the Vendor ID as the name space 355 ID. Other options include version 1 and 4 UUIDs. Classes MAY be 356 more granular than is required to identify firmware compatibility. 357 Classes MUST NOT be less granular than is required to identify 358 firmware compatibility. Devices MAY have multiple Class IDs. 360 Class ID is not intended to be a human-readable element. It is 361 intended for binary match/mismatch comparison only. 363 The use of Class ID is RECOMMENDED. It allows devices to determine 364 applicability of a firmware in an unambiguous way. 366 If Class ID is not implemented, then each logical device class MUST 367 use a unique trust anchor for authorisation. 369 Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), 370 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 372 3.4.1. Example 1: Different Classes 374 Vendor A creates product Z and product Y. The firmware images of 375 products Z and Y are not interchangeable. Vendor A creates UUIDs as 376 follows: 378 o vendorId = UUID5(DNS, "vendor-a.com") 380 o ZclassId = UUID5(vendorId, "Product Z") 382 o YclassId = UUID5(vendorId, "Product Y") 383 This ensures that Vendor A's Product Z cannot install firmware for 384 Product Y and Product Y cannot install firmware for Product Z. 386 3.4.2. Example 2: Upgrading Class ID 388 Vendor A creates product X. Later, Vendor A adds a new feature to 389 product X, creating product X v2. Product X requires a firmware 390 update to work with firmware intended for product X v2. 392 Vendor A creates UUIDs as follows: 394 o vendorId = UUID5(DNS, "vendor-a.com") 396 o XclassId = UUID5(vendorId, "Product X") 398 o Xv2classId = UUID5(vendorId, "Product X v2") 400 When product X receives the firmware update necessary to be 401 compatible with product X v2, part of the firmware update changes the 402 class ID to Xv2classId. 404 3.4.3. Example 3: Shared Functionality 406 Vendor A produces two products, product X and product Y. These 407 components share a common core (such as an operating system), but 408 have different applications. The common core and the applications 409 can be updated independently. To enable X and Y to receive the same 410 common core update, they require the same class ID. To ensure that 411 only product X receives application X and only product Y receives 412 application Y, product X and product Y must have different class IDs. 413 The vendor creates Class IDs as follows: 415 o vendorId = UUID5(DNS, "vendor-a.com") 417 o XclassId = UUID5(vendorId, "Product X") 419 o YclassId = UUID5(vendorId, "Product Y") 421 o CommonClassId = UUID5(vendorId, "common core") 423 Product X matches against both XclassId and CommonClassId. Product Y 424 matches against both YclassId and CommonClassId. 426 3.4.4. Example 4: White-labelling 428 Vendor A creates a product A and its firmware. Vendor B sells the 429 product under its own name as Product B with some customised 430 configuration. The vendors create the Class IDs as follows: 432 o vendorIdA = UUID5(DNS, "vendor-a.com") 434 o classIdA = UUID5(vendorIdA, "Product A-Unlabelled") 436 o vendorIdB = UUID5(DNS, "vendor-b.com") 438 o classIdB = UUID5(vendorIdB, "Product B") 440 The product will match against each of these class IDs. If Vendor A 441 and Vendor B provide different components for the device, the 442 implementor MAY choose to make ID matching scoped to each component. 443 Then, the vendorIdA, classIdA match the component ID supplied by 444 Vendor A, and the vendorIdB, classIdB match the component ID supplied 445 by Vendor B. 447 3.5. Manifest Element: Precursor Image Digest Condition 449 When a precursor image is required by the payload format, a precursor 450 image digest condition MUST be present in the conditions list. The 451 precursor image may be installed or stored as a candidate. 453 This element is OPTIONAL to implement. 455 Enables feature: differential updates. 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. 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 is only usable in conjunction 479 with a secure source of time. 481 This element is OPTIONAL and MAY enable user stories where a secure 482 source of time is provided and firmware is intended to expire 483 predictably. 485 Implements: REQ.SEC.EXP (Section 4.3.3) 487 3.8. Manifest Element: Payload Format 489 The format of the payload MUST be indicated to devices in an 490 unambiguous way. This element provides a mechanism to describe the 491 payload format, within the signed metadata. 493 This element is REQUIRED and MUST be present to enable devices to 494 decode payloads correctly. 496 Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT 497 (Section 4.5.5) 499 3.9. Manifest Element: Processing Steps 501 A representation of the Processing Steps required to decode a 502 payload. The representation MUST describe which algorithm(s) is used 503 and any additional parameters required by the algorithm(s). The 504 representation MAY group Processing Steps together in predefined 505 combinations. 507 A Processing Step MAY indicate the expected digest of the payload 508 after the processing is complete. 510 Processing steps are RECOMMENDED to implement. 512 Enables feature: Encrypted, compressed, packed formats 514 Implements: REQ.USE.IMG.NESTED (Section 4.5.6) 516 3.10. Manifest Element: Storage Location 518 This element tells the device where to store a payload within a given 519 component. The device can use this to establish which permissions 520 are necessary and the physical storage location to use. 522 This element is REQUIRED and MUST be present to enable devices to 523 store payloads to the correct location. 525 Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 527 3.10.1. Example 1: Two Storage Locations 529 A device supports two components: an OS and an application. These 530 components can be updated independently, expressing dependencies to 531 ensure compatibility between the components. The Author chooses two 532 storage identifiers: 534 o "OS" 536 o "APP" 538 3.10.2. Example 2: File System 540 A device supports a full filesystem. The Author chooses to use the 541 storage identifier as the path at which to install the payload. The 542 payload may be a tarball, in which case, it unpacks the tarball into 543 the specified path. 545 3.10.3. Example 3: Flash Memory 547 A device supports flash memory. The Author chooses to make the 548 storage identifier the offset where the image should be written. 550 3.11. Manifest Element: Component Identifier 552 In a heterogeneous storage architecture, a storage identifier is 553 insufficient to identify where and how to store a payload. To 554 resolve this, a component identifier indicates which part of the 555 storage architecture is targeted by the payload. In a homogeneous 556 storage architecture, this element is unnecessary. 558 This element is OPTIONAL and only necessary in heterogeneous storage 559 architecture devices. 561 N.B. A serialisation MAY choose to combine Component Identifier and 562 Storage Location (Section 3.10) 564 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 566 3.12. Manifest Element: Resource Indicator 568 This element provides the information required for the device to 569 acquire the resource. This can be encoded in several ways: 571 o One URI 573 o A list of URIs 574 o A prioritised list of URIs 576 o A list of signed URIs 578 This element is OPTIONAL and only needed when the target device does 579 not intrinsically know where to find the payload. 581 N.B. Devices will typically require URIs. 583 Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 585 3.13. Manifest Element: Payload Digests 587 This element contains one or more digests of one or more payloads. 588 This allows the target device to ensure authenticity of the 589 payload(s). A serialisation MUST provide a mechanism to select one 590 payload from a list based on system parameters, such as Execute-In- 591 Place Installation Address. 593 This element is REQUIRED to implement and fundamentally necessary to 594 ensure the authenticity and integrity of the payload. Support for 595 more than one digest is OPTIONAL to implement in a recipient device. 597 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT 598 (Section 4.5.8) 600 3.14. Manifest Element: Size 602 The size of the payload in bytes. 604 Variable-size storage locations MUST be set to exactly the size 605 listed in this element. 607 This element is REQUIRED and informs the target device how big of a 608 payload to expect. Without it, devices are exposed to some classes 609 of denial of service attack. 611 Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) 613 3.15. Manifest Element: Signature 615 This is not strictly a manifest element. Instead, the manifest is 616 wrapped by a standardised authentication container, such as a COSE 617 ([RFC8152]) or CMS ([RFC5652]) signature object. The authentication 618 container MUST support multiple actors and multiple authentication 619 methods. 621 This element is REQUIRED in non-dependency manifests and represents 622 the foundation of all security properties of the manifest. Manifests 623 which are included as dependencies by another manifest SHOULD include 624 a signature so that the recipient can distinguish between different 625 actors with different permissions. 627 A manifest MUST NOT be considered authenticated by channel security 628 even if it contains only channel information (such as URIs). If the 629 authenticated remote or channel were compromised, the threat actor 630 could induce recipients to queries traffic over any accessible 631 network. Lightweight authentication with pre-existing relationships 632 SHOULD be done with MAC. 634 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS 635 (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) 637 3.16. Manifest Element: Additional installation instructions 639 Instructions that the device should execute when processing the 640 manifest. This information is distinct from the information 641 necessary to process a payload. Additional installation instructions 642 include information such as update timing (for example, install only 643 on Sunday, at 0200), procedural considerations (for example, shut 644 down the equipment under control before executing the update), pre- 645 and post-installation steps (for example, run a script). 647 This element is OPTIONAL. 649 Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 651 3.17. Manifest Element: Aliases 653 A mechanism for a manifest to augment or replace URIs or URI lists 654 defined by one or more of its dependencies. 656 This element is OPTIONAL and enables some user stories. 658 Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 660 3.18. Manifest Element: Dependencies 662 A list of other manifests that are required by the current manifest. 663 Manifests are identified an unambiguous way, such as a digest. 665 This element is REQUIRED to use in deployments that include both 666 multiple authorities and multiple payloads. 668 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 670 3.19. Manifest Element: Encryption Wrapper 672 Encrypting firmware images requires symmetric content encryption 673 keys. The encryption wrapper provides the information needed for a 674 device to obtain or locate a key that it uses to decrypt the 675 firmware. Typical choices for an encryption wrapper include CMS 676 ([RFC5652]) or COSE ([RFC8152]). This MAY be included in a 677 decryption step contained in Processing Steps (Section 3.9). 679 This element is REQUIRED to use for encrypted payloads, 681 Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 683 3.20. Manifest Element: XIP Address 685 In order to support XIP systems with multiple possible base 686 addresses, it is necessary to specify which address the payload is 687 linked for. 689 For example a microcontroller may have a simple bootloader that 690 chooses one of two images to boot. That microcontroller then needs 691 to choose one of two firmware images to install, based on which of 692 its two images is older. 694 Implements: REQ.USE.IMG.SELECT (Section 4.5.8) 696 3.21. Manifest Element: Load-time metadata 698 Load-time metadata provides the device with information that it needs 699 in order to load one or more images. This is effectively a copy 700 operation from the permanent storage location of an image into the 701 active use location of that image. The metadata contains the source 702 and destination of the image as well as any operations that are 703 performed on the image. 705 Implements: REQ.USE.LOAD (Section 4.5.10) 707 3.22. Manifest Element: Run-time metadata 709 Run-time metadata provides the device with any extra information 710 needed to boot the device. This may include information such as the 711 entry-point of an XIP image or the kernel command-line of a Linux 712 image. 714 Implements: REQ.USE.EXEC (Section 4.5.9) 716 3.23. Manifest Element: Payload 718 The Payload element provides a recipient device with the whole 719 payload, contained within the manifest superstructure. This enables 720 the manifest and payload to be delivered simultaneously. 722 Implements: REQ.USE.PAYLOAD (Section 4.5.11) 724 3.24. Manifest Element: Key Claims 726 The Key Claims element is not authenticated by the Signature 727 (Section 3.15), instead, it provides a chain of key delegations (or 728 references to them) for the device to follow in order to verify the 729 key that authenticated the manifest using a trusted key. 731 Implements: REQ.USE.DELEGATION (Section 4.5.13) 733 4. Security Considerations 735 The following sub-sections describe the threat model, user stories, 736 security requirements, and usability requirements. This section also 737 provides the motivations for each of the manifest information 738 elements. 740 4.1. Threat Model 742 The following sub-sections aim to provide information about the 743 threats that were considered, the security requirements that are 744 derived from those threats and the fields that permit implementation 745 of the security requirements. This model uses the S.T.R.I.D.E. 746 [STRIDE] approach. Each threat is classified according to: 748 o Spoofing identity 750 o Tampering with data 752 o Repudiation 754 o Information disclosure 756 o Denial of service 758 o Elevation of privilege 760 This threat model only covers elements related to the transport of 761 firmware updates. It explicitly does not cover threats outside of 762 the transport of firmware updates. For example, threats to an IoT 763 device due to physical access are out of scope. 765 4.2. Threat Descriptions 767 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 769 Classification: Elevation of Privilege 771 An attacker sends an old, but valid manifest with an old, but valid 772 firmware image to a device. If there is a known vulnerability in the 773 provided firmware image, this may allow an attacker to exploit the 774 vulnerability and gain control of the device. 776 Threat Escalation: If the attacker is able to exploit the known 777 vulnerability, then this threat can be escalated to ALL TYPES. 779 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 781 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old Firmware 783 Classification: Elevation of Privilege 785 An attacker targets a device that has been offline for a long time 786 and runs an old firmware version. The attacker sends an old, but 787 valid manifest to a device with an old, but valid firmware image. 788 The attacker-provided firmware is newer than the installed one but 789 older than the most recently available firmware. If there is a known 790 vulnerability in the provided firmware image then this may allow an 791 attacker to gain control of a device. Because the device has been 792 offline for a long time, it is unaware of any new updates. As such 793 it will treat the old manifest as the most current. 795 Threat Escalation: If the attacker is able to exploit the known 796 vulnerability, then this threat can be escalated to ALL TYPES. 798 Mitigated by: REQ.SEC.EXP (Section 4.3.3) 800 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 802 Classification: Denial of Service 804 An attacker sends a valid firmware image, for the wrong type of 805 device, signed by an actor with firmware installation permission on 806 both types of device. The firmware is verified by the device 807 positively because it is signed by an actor with the appropriate 808 permission. This could have wide-ranging consequences. For devices 809 that are similar, it could cause minor breakage, or expose security 810 vulnerabilities. For devices that are very different, it is likely 811 to render devices inoperable. 813 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 815 4.2.3.1. Example: 817 Suppose that two vendors, Vendor A and Vendor B, adopt the same trade 818 name in different geographic regions, and they both make products 819 with the same names, or product name matching is not used. This 820 causes firmware from Vendor A to match devices from Vendor B. 822 If the vendors are the firmware authorities, then devices from Vendor 823 A will reject images signed by Vendor B since they use different 824 credentials. However, if both devices trust the same Author, then, 825 devices from Vendor A could install firmware intended for devices 826 from Vendor B. 828 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 829 payload 831 Classification: Denial of Service 833 If a device misinterprets the format of the firmware image, it may 834 cause a device to install a firmware image incorrectly. An 835 incorrectly installed firmware image would likely cause the device to 836 stop functioning. 838 Threat Escalation: An attacker that can cause a device to 839 misinterpret the received firmware image may gain elevation of 840 privilege and potentially expand this to all types of threat. 842 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 844 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 845 the wrong location 847 Classification: Denial of Service 849 If a device installs a firmware image to the wrong location on the 850 device, then it is likely to break. For example, a firmware image 851 installed as an application could cause a device and/or an 852 application to stop functioning. 854 Threat Escalation: An attacker that can cause a device to 855 misinterpret the received code may gain elevation of privilege and 856 potentially expand this to all types of threat. 858 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.5) 860 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 862 Classification: Denial of Service 864 If a device does not know where to obtain the payload for an update, 865 it may be redirected to an attacker's server. This would allow an 866 attacker to provide broken payloads to devices. 868 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 870 4.2.7. THREAT.NET.MITM: Traffic interception 872 Classification: Spoofing Identity, Tampering with Data 874 An attacker intercepts all traffic to and from a device. The 875 attacker can monitor or modify any data sent to or received from the 876 device. This can take the form of: manifests, payloads, status 877 reports, and capability reports being modified or not delivered to 878 the intended recipient. It can also take the form of analysis of 879 data sent to or from the device, either in content, size, or 880 frequency. 882 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), 883 REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC 884 (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), 885 REQ.SEC.REPORTING (Section 4.3.16) 887 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 889 Classification: Elevation of Privilege 891 An attacker replaces a newly downloaded firmware after a device 892 finishes verifying a manifest. This could cause the device to 893 execute the attacker's code. This attack likely requires physical 894 access to the device. However, it is possible that this attack is 895 carried out in combination with another threat that allows remote 896 execution. This is a typical Time Of Check/Time Of Use threat. 898 Threat Escalation: If the attacker is able to exploit a known 899 vulnerability, or if the attacker can supply their own firmware, then 900 this threat can be escalated to ALL TYPES. 902 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 904 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 906 Classification: Elevation of Privilege / All Types 908 If an attacker can install their firmware on a device, by 909 manipulating either payload or metadata, then they have complete 910 control of the device. 912 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 914 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 916 Classification: Denial of Service / All Types 918 An attacker sends a valid, current manifest to a device that has an 919 unexpected precursor image. If a payload format requires a precursor 920 image (for example, delta updates) and that precursor image is not 921 available on the target device, it could cause the update to break. 923 An attacker that can cause a device to install a payload against the 924 wrong precursor image could gain elevation of privilege and 925 potentially expand this to all types of threat. However, it is 926 unlikely that a valid differential update applied to an incorrect 927 precursor would result in a functional, but vulnerable firmware. 929 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 931 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 933 Classification: Denial of Service, Elevation of Privilege 935 This threat can appear in several ways, however it is ultimately 936 about ensuring that devices retain the behaviour required by their 937 Owner, Device Operator, or Network Operator. The owner or operator 938 of a device typically requires that the device maintain certain 939 features, functions, capabilities, behaviours, or interoperability 940 constraints (more generally, behaviour). If these requirements are 941 broken, then a device will not fulfill its purpose. Therefore, if 942 any party other than the device's Owner or the Owner's contracted 943 Device Operator has the ability to modify device behaviour without 944 approval, then this constitutes an elevation of privilege. 946 Similarly, a network operator may require that devices behave in a 947 particular way in order to maintain the integrity of the network. If 948 devices behaviour on a network can be modified without the approval 949 of the network operator, then this constitutes an elevation of 950 privilege with respect to the network. 952 For example, if the owner of a device has purchased that device 953 because of Features A, B, and C, and a firmware update is issued by 954 the manufacturer, which removes Feature A, then the device may not 955 fulfill the owner's requirements any more. In certain circumstances, 956 this can cause significantly greater threats. Suppose that Feature A 957 is used to implement a safety-critical system, whether the 958 manufacturer intended this behaviour or not. When unapproved 959 firmware is installed, the system may become unsafe. 961 In a second example, the owner or operator of a system of two or more 962 interoperating devices needs to approve firmware for their system in 963 order to ensure interoperability with other devices in the system. 964 If the firmware is not qualified, the system as a whole may not work. 965 Therefore, if a device installs firmware without the approval of the 966 device owner or operator, this is a threat to devices or the system 967 as a whole. 969 Similarly, the operator of a network may need to approve firmware for 970 devices attached to the network in order to ensure favourable 971 operating conditions within the network. If the firmware is not 972 qualified, it may degrade the performance of the network. Therefore, 973 if a device installs firmware without the approval of the network 974 operator, this is a threat to the network itself. 976 Threat Escalation: If the firmware expects configuration that is 977 present in devices deployed in Network A, but not in devices deployed 978 in Network B, then the device may experience degraded security, 979 leading to threats of All Types. 981 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 982 (Section 4.3.13) 984 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 985 Operator 987 In this example, assume that Device Operators expect the rights to 988 create firmware but that Network Operators expect the rights to 989 qualify firmware as fit-for-purpose on their networks. Additionally, 990 assume that Device Operators manage devices that can be deployed on 991 any network, including Network A and B in our example. 993 An attacker may obtain a manifest for a device on Network A. Then, 994 this attacker sends that manifest to a device on Network B. Because 995 Network A and Network B are under control of different Operators, and 996 the firmware for a device on Network A has not been qualified to be 997 deployed on Network B, the target device on Network B is now in 998 violation of the Operator B's policy and may be disabled by this 999 unqualified, but signed firmware. 1001 This is a denial of service because it can render devices inoperable. 1002 This is an elevation of privilege because it allows the attacker to 1003 make installation decisions that should be made by the Operator. 1005 4.2.11.2. Example 2: Single Network Operator with Multiple Device 1006 Operators 1008 Multiple devices that interoperate are used on the same network and 1009 communicate with each other. Some devices are manufactured and 1010 managed by Device Operator A and other devices by Device Operator B. 1011 A new firmware is released by Device Operator A that breaks 1012 compatibility with devices from Device Operator B. An attacker sends 1013 the new firmware to the devices managed by Device Operator A without 1014 approval of the Network Operator. This breaks the behaviour of the 1015 larger system causing denial of service and possibly other threats. 1016 Where the network is a distributed SCADA system, this could cause 1017 misbehaviour of the process that is under control. 1019 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 1020 for Vulnerability Analysis 1022 Classification: All Types 1024 An attacker wants to mount an attack on an IoT device. To prepare 1025 the attack he or she retrieves the provided firmware image and 1026 performs reverse engineering of the firmware image to analyze it for 1027 specific vulnerabilities. 1029 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1031 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 1033 Classification: Elevation of Privilege 1035 An authorised actor, but not the Author, uses an override mechanism 1036 (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information 1037 element in a manifest signed by the Author. For example, if the 1038 authorised actor overrides the digest and URI of the payload, the 1039 actor can replace the entire payload with a payload of their choice. 1041 Threat Escalation: By overriding elements such as payload 1042 installation instructions or firmware digest, this threat can be 1043 escalated to all types. 1045 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1047 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 1049 Classification: Information Disclosure 1051 A third party may be able to extract sensitive information from the 1052 manifest. 1054 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 1056 4.2.15. THREAT.IMG.EXTRA: Extra data after image 1058 Classification: All Types 1060 If a third party modifies the image so that it contains extra code 1061 after a valid, authentic image, that third party can then use their 1062 own code in order to make better use of an existing vulnerability. 1064 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 1066 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 1068 Classification: All Types 1070 If a third party obtains a key or even indirect access to a key, for 1071 example in an HSM, then they can perform the same actions as the 1072 legitimate owner of the key. If the key is trusted for firmware 1073 update, then the third party can perform firmware updates as though 1074 they were the legitimate owner of the key. 1076 For example, if manifest signing is performed on a server connected 1077 to the internet, an attacker may compromise the server and then be 1078 able to sign manifests, even if the keys for manifest signing are 1079 held in an HSM that is accessed by the server. 1081 Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17) 1083 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 1084 prior to signing 1086 Classification: All Types 1088 If an attacker can alter a manifest or payload before it is signed, 1089 they can perform all the same actions as the manifest author. This 1090 allows the attacker to deploy firmware updates to any devices that 1091 trust the manifest author. If an attacker can modify the code of a 1092 payload before the corresponding manifest is created, they can insert 1093 their own code. If an attacker can modify the manifest before it is 1094 signed, they can redirect the manifest to their own payload. 1096 For example, the attacker deploys malware to the developer's computer 1097 or signing service that watches manifest creation activities and 1098 inserts code into any binary that is referenced by a manifest. 1100 For example, the attacker deploys malware to the developer's computer 1101 or signing service that replaces the referenced binary (digest) and 1102 URI with the attacker's binary (digest) and URI. 1104 Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18), 1105 REQ.SEC.MFST.TRUSTED (Section 4.3.19) 1107 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 1108 authentication and use 1110 Classification: All Types 1112 If an attacker can modify a manifest after it is authenticated (Time 1113 Of Check) but before it is used (Time Of Use), then the attacker can 1114 place any content whatsoever in the manifest. 1116 Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.20) 1118 4.3. Security Requirements 1120 The security requirements here are a set of policies that mitigate 1121 the threats described in Section 4.1. 1123 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 1125 Only an actor with firmware installation authority is permitted to 1126 decide when device firmware can be installed. To enforce this rule, 1127 manifests MUST contain monotonically increasing sequence numbers. 1128 Manifests MAY use UTC epoch timestamps to coordinate monotonically 1129 increasing sequence numbers across many actors in many locations. If 1130 UTC epoch timestamps are used, they MUST NOT be treated as times, 1131 they MUST be treated only as sequence numbers. Devices MUST reject 1132 manifests with sequence numbers smaller than any onboard sequence 1133 number. 1135 Note: This is not a firmware version. It is a manifest sequence 1136 number. A firmware version may be rolled back by creating a new 1137 manifest for the old firmware version with a later sequence number. 1139 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 1141 Implemented by: Monotonic Sequence Number (Section 3.2) 1143 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1145 Devices MUST only apply firmware that is intended for them. Devices 1146 MUST know with fine granularity that a given update applies to their 1147 vendor, model, hardware revision, software revision. Human-readable 1148 identifiers are often error-prone in this regard, so unique 1149 identifiers SHOULD be used. 1151 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1153 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1154 (Section 3.4) 1156 4.3.3. REQ.SEC.EXP: Expiration Time 1158 Firmware MAY expire after a given time. Devices MAY provide a secure 1159 clock (local or remote). If a secure clock is provided and the 1160 Firmware manifest has an expiration timestamp, the device MUST reject 1161 the manifest if current time is later than the expiration time. 1163 Mitigates: THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2) 1165 Implemented by: Expiration Time (Section 3.7) 1167 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1169 The authenticity of an update MUST be demonstrable. Typically, this 1170 means that updates must be digitally authenticated. Because the 1171 manifest contains information about how to install the update, the 1172 manifest's authenticity MUST also be demonstrable. To reduce the 1173 overhead required for validation, the manifest contains the digest of 1174 the firmware image, rather than a second digital signature. The 1175 authenticity of the manifest can be verified with a digital signature 1176 or Message Authentication Code. The authenticity of the firmware 1177 image is tied to the manifest by the use of a digest of the firmware 1178 image. 1180 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.MITM 1181 (Section 4.2.7) 1183 Implemented by: Signature (Section 3.15), Payload Digest 1184 (Section 3.13) 1186 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1188 The type of payload (which may be independent of format) MUST be 1189 authenticated. For example, the target must know whether the payload 1190 is XIP firmware, a loadable module, or serialized configuration data. 1192 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1194 Implemented by: Payload Format (Section 3.8), Storage Location 1195 (Section 3.10) 1197 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1198 Location 1200 The location on the target where the payload is to be stored MUST be 1201 authenticated. 1203 Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) 1205 Implemented by: Storage Location (Section 3.10) 1207 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location 1209 The location where a target should find a payload MUST be 1210 authenticated. 1212 Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.MITM 1213 (Section 4.2.7) 1215 Implemented by: Resource Indicator (Section 3.12) 1217 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 1219 The target SHOULD verify firmware at time of boot. This requires 1220 authenticated payload size, and digest. 1222 Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) 1224 Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) 1226 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 1228 If an update uses a differential compression method, it MUST specify 1229 the digest of the precursor image and that digest MUST be 1230 authenticated. 1232 Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10) 1234 Implemented by: Precursor Image Digest (Section 3.5) 1236 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs 1238 The identifiers that specify firmware compatibility MUST be 1239 authenticated to ensure that only compatible firmware is installed on 1240 a target device. 1242 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1244 Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition 1245 (Section 3.4) 1247 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 1249 If a device grants different rights to different actors, exercising 1250 those rights MUST be accompanied by proof of those rights, in the 1251 form of proof of authenticity. Authenticity mechanisms such as those 1252 required in REQ.SEC.AUTHENTIC (Section 4.3.4) can be used to prove 1253 authenticity. 1255 For example, if a device has a policy that requires that firmware 1256 have both an Authorship right and a Qualification right and if that 1257 device grants Authorship and Qualification rights to different 1258 parties, such as a Device Operator and a Network Operator, 1259 respectively, then the firmware cannot be installed without proof of 1260 rights from both the Device Operator and the Network Operator. 1262 Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11) 1264 Implemented by: Signature (Section 3.15) 1266 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 1268 The manifest information model MUST enable encrypted payloads. 1269 Encryption helps to prevent third parties, including attackers, from 1270 reading the content of the firmware image. This can protect against 1271 confidential information disclosures and discovery of vulnerabilities 1272 through reverse engineering. Therefore the manifest must convey the 1273 information required to allow an intended recipient to decrypt an 1274 encrypted payload. 1276 Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.MITM 1277 (Section 4.2.7) 1279 Implemented by: Encryption Wrapper (Section 3.19) 1281 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 1283 If a device grants different rights to different actors, then an 1284 exercise of those rights MUST be validated against a list of rights 1285 for the actor. This typically takes the form of an Access Control 1286 List (ACL). ACLs are applied to two scenarios: 1288 1. An ACL decides which elements of the manifest may be overridden 1289 and by which actors. 1291 2. An ACL decides which component identifier/storage identifier 1292 pairs can be written by which actors. 1294 Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), 1295 THREAT.UPD.UNAPPROVED (Section 4.2.11) 1297 Implemented by: Client-side code, not specified in manifest. 1299 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 1301 It MUST be possible to encrypt part or all of the manifest. This may 1302 be accomplished with either transport encryption or with at-rest 1303 encryption. 1305 Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.MITM 1306 (Section 4.2.7) 1308 Implemented by: External Encryption Wrapper / Transport Security 1310 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 1312 The digest SHOULD cover all available space in a fixed-size storage 1313 location. Variable-size storage locations MUST be restricted to 1314 exactly the size of deployed payload. This prevents any data from 1315 being distributed without being covered by the digest. For example, 1316 XIP microcontrollers typically have fixed-size storage. These 1317 devices should deploy a digest that covers the deployed firmware 1318 image, concatenated with the default erased value of any remaining 1319 space. 1321 Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) 1323 Implemented by: Payload Digests (Section 3.13) 1325 4.3.16. REQ.SEC.REPORTING: Secure Reporting 1327 Status reports from the device to any remote system SHOULD be 1328 performed over an authenticated, confidential channel in order to 1329 prevent modification or spoofing of the reports. 1331 Mitigates: THREAT.NET.MITM (Section 4.2.7) 1333 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 1335 Cryptographic keys for signing/authenticating manifests SHOULD be 1336 stored in a manner that is inaccessible to networked devices, for 1337 example in an HSM, or an air-gapped computer. This protects against 1338 an attacker obtaining the keys. 1340 Keys SHOULD be stored in a way that limits the risk of a legitimate, 1341 but compromised, entity (such as a server or developer computer) 1342 issuing signing requests. 1344 Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) 1346 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment 1348 Manifests SHOULD be parsed and examined prior to deployment to 1349 validate that their contents have not been modified during creation 1350 and signing. 1352 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1354 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted 1355 environment 1357 For high risk deployments, such as large numbers of devices or 1358 critical function devices, manifests SHOULD be constructed in an 1359 environment that is protected from interference, such as an air- 1360 gapped computer. Note that a networked computer connected to an HSM 1361 does not fulfill this requirement (see THREAT.MFST.MODIFICATION 1362 (Section 4.2.17)). 1364 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1366 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between check and 1367 use 1369 Both the manifest and any data extracted from it MUST be held 1370 immutable between its authenticity verification (time of check) and 1371 its use (time of use). To make this guarantee, the manifest MUST fit 1372 within an internal memory or a secure memory, such as encrypted 1373 memory. The recipient SHOULD defend the manifest from tampering by 1374 code or hardware resident in the recipient, for example other 1375 processes or debuggers. 1377 If an application requires that the manifest is verified before 1378 storing it, then this means the manifest MUST fit in RAM. 1380 Mitigates: THREAT.MFST.TOCTOU (Section 4.2.18) 1382 4.4. User Stories 1384 User stories provide expected use cases. These are used to feed into 1385 usability requirements. 1387 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 1389 As a Device Operator, I want to provide my devices with additional 1390 installation instructions so that I can keep process details out of 1391 my payload data. 1393 Some installation instructions might be: 1395 o Use a table of hashes to ensure that each block of the payload is 1396 validate before writing. 1398 o Do not report progress. 1400 o Pre-cache the update, but do not install. 1402 o Install the pre-cached update matching this manifest. 1404 o Install this update immediately, overriding any long-running 1405 tasks. 1407 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1409 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 1411 As a designer of a resource-constrained IoT device, I want bad 1412 updates to fail as early as possible to preserve battery life and 1413 limit consumed bandwidth. 1415 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1417 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 1419 As a Device Operator, I would like to be able to override the non- 1420 critical information in the manifest so that I can control my devices 1421 more precisely. The authority to override this information is 1422 provided via the installation of a limited trust anchor by another 1423 authority. 1425 Some examples of potentially overridable information: 1427 o URIs (Section 3.12): this allows the Device Operator to direct 1428 devices to their own infrastructure in order to reduce network 1429 load. 1431 o Conditions: this allows the Device Operator to pose additional 1432 constraints on the installation of the manifest. 1434 o Directives (Section 3.16): this allows the Device Operator to add 1435 more instructions such as time of installation. 1437 o Processing Steps (Section 3.9): If an intermediary performs an 1438 action on behalf of a device, it may need to override the 1439 processing steps. It is still possible for a device to verify the 1440 final content and the result of any processing step that specifies 1441 a digest. Some processing steps should be non-overridable. 1443 Satisfied by: USER_STORY.OVERRIDE (Section 4.4.3), 1444 REQ.USE.MFST.COMPONENT (Section 4.5.3) 1446 4.4.4. USER_STORY.COMPONENT: Component Update 1448 As a Device Operator, I want to divide my firmware into components, 1449 so that I can reduce the size of updates, make different parties 1450 responsible for different components, and divide my firmware into 1451 frequently updated and infrequently updated components. 1453 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1455 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations 1457 As a Device Operator, I want to ensure the quality of a firmware 1458 update before installing it, so that I can ensure interoperability of 1459 all devices in my product family. I want to restrict the ability to 1460 make changes to my devices to require my express approval. 1462 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), 1463 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1465 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1467 As a Device Operator, I want to be able to send multiple payload 1468 formats to suit the needs of my update, so that I can optimise the 1469 bandwidth used by my devices. 1471 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) 1473 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1474 Disclosures 1476 As a firmware author, I want to prevent confidential information from 1477 being disclosed during firmware updates. It is assumed that channel 1478 security or at-rest encryption is adequate to protect the manifest 1479 itself against information disclosure. 1481 Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1483 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 1484 Unknown Formats 1486 As a Device Operator, I want devices to determine whether they can 1487 process a payload prior to downloading it. 1489 In some cases, it may be desirable for a third party to perform some 1490 processing on behalf of a target. For this to occur, the third party 1491 MUST indicate what processing occurred and how to verify it against 1492 the Trust Provisioning Authority's intent. 1494 This amounts to overriding Processing Steps (Section 3.9) and 1495 Resource Indicator (Section 3.12). 1497 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED 1498 (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 1500 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 1501 Target Firmware 1503 As a Device Operator, I want to be able to target devices for updates 1504 based on their current firmware version, so that I can control which 1505 versions are replaced with a single manifest. 1507 Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7) 1509 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 1511 As a developer, I want to be able to sign two or more versions of my 1512 firmware in a single manifest so that I can use a very simple 1513 bootloader that chooses between two or more images that are executed 1514 in-place. 1516 Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8) 1518 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 1520 As a signer for both secure execution/boot and firmware deployment, I 1521 would like to use the same signed document for both tasks so that my 1522 data size is smaller, I can share common code, and I can reduce 1523 signature verifications. 1525 Satisfied by: REQ.USE.EXEC (Section 4.5.9) 1527 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 1529 As a developer of firmware for a run-from-RAM device, I would like to 1530 use compressed images and to indicate to the bootloader that I am 1531 using a compressed image in the manifest so that it can be used with 1532 secure execution/boot. 1534 Satisfied by: REQ.USE.LOAD (Section 4.5.10) 1536 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 1538 As an operator of devices on a constrained network, I would like the 1539 manifest to be able to include a small payload in the same packet so 1540 that I can reduce network traffic. 1542 Small payloads may include, for example, wrapped encryption keys, 1543 encoded configuration, public keys, [RFC8392] CBOR Web Tokens, or 1544 X.509 certificates. 1546 Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) 1548 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 1550 As a developer for constrained devices, I want a low complexity 1551 library for processing updates so that I can fit more application 1552 code on my device. 1554 Satisfied by: REQ.USE.PARSE (Section 4.5.12) 1556 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 1558 As a Device Operator that rotates delegated authority more often than 1559 delivering firmware updates, I would like to delegate a new authority 1560 when I deliver a firmware update so that I can accomplish both tasks 1561 in a single transmission. 1563 Satisfied by: REQ.USE.DELEGATION (Section 4.5.13) 1565 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 1567 As an operator of a constrained network, I would like devices on my 1568 network to be able to evaluate the suitability of an update prior to 1569 initiating any large download so that I can prevent unnecessary 1570 consumption of bandwidth. 1572 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1574 4.5. Usability Requirements 1576 The following usability requirements satisfy the user stories listed 1577 above. 1579 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 1581 It MUST be possible for a manifest author to place ALL information 1582 required to process an update in the manifest. 1584 For example: Information about which precursor image is required for 1585 a differential update MUST be placed in the manifest, not in the 1586 differential compression header. 1588 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1589 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1591 Implemented by: Additional installation instructions (Section 3.16) 1593 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1595 It MUST be possible to redirect payload fetches. This applies where 1596 two manifests are used in conjunction. For example, a Device 1597 Operator creates a manifest specifying a payload and signs it, and 1598 provides a URI for that payload. A Network Operator creates a second 1599 manifest, with a dependency on the first. They use this second 1600 manifest to override the URIs provided by the Device Operator, 1601 directing them into their own infrastructure instead. Some devices 1602 may provide this capability, while others may only look at canonical 1603 sources of firmware. For this to be possible, the device must fetch 1604 the payload, whereas a device that accepts payload pushes will ignore 1605 this feature. 1607 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1609 Implemented by: Aliases (Section 3.17) 1611 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 1613 It MUST be possible express the requirement to install one or more 1614 payloads from one or more authorities so that a multi-payload update 1615 can be described. This allows multiple parties with different 1616 permissions to collaborate in creating a single update for the IoT 1617 device, across multiple components. 1619 This requirement effectively means that it must be possible to 1620 construct a tree of manifests on a multi-image target. 1622 In order to enable devices with a heterogeneous storage architecture, 1623 the manifest must enable specification of both storage system and the 1624 storage location within that storage system. 1626 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1627 (Section 4.4.4) 1629 Implemented by Manifest Element: Dependencies, StorageIdentifier, 1630 ComponentIdentifier 1632 4.5.3.1. Example 1: Multiple Microcontrollers 1634 An IoT device with multiple microcontrollers in the same physical 1635 device (HeSA) will likely require multiple payloads with different 1636 component identifiers. 1638 4.5.3.2. Example 2: Code and Configuration 1640 A firmware image can be divided into two payloads: code and 1641 configuration. These payloads may require authorizations from 1642 different actors in order to install (see REQ.SEC.RIGHTS 1643 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1644 structure means that multiple manifests may be required, with a 1645 dependency structure between them. 1647 4.5.3.3. Example 3: Multiple Software Modules 1649 A firmware image can be divided into multiple functional blocks for 1650 separate testing and distribution. This means that code would need 1651 to be distributed in multiple payloads. For example, this might be 1652 desirable in order to ensure that common code between devices is 1653 identical in order to reduce distribution bandwidth. 1655 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1657 It MUST be possible to authenticate a manifest multiple times so that 1658 authorisations from multiple parties with different permissions can 1659 be required in order to authorise installation of a manifest. 1661 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1663 Implemented by: Signature (Section 3.15) 1665 4.5.5. REQ.USE.IMG.FORMAT: Format Usability 1667 The manifest serialisation MUST accommodate any payload format that 1668 an Operator wishes to use. This enables the recipient to detect 1669 which format the Operator has chosen. Some examples of payload 1670 format are: 1672 o Binary 1674 o Elf 1676 o Differential 1678 o Compressed 1680 o Packed configuration 1682 o Intel HEX 1684 o S-Record 1686 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1687 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1689 Implemented by: Payload Format (Section 3.8) 1691 4.5.6. REQ.USE.IMG.NESTED: Nested Formats 1693 The manifest serialisation MUST accommodate nested formats, 1694 announcing to the target device all the nesting steps and any 1695 parameters used by those steps. 1697 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1699 Implemented by: Processing Steps (Section 3.9) 1701 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 1703 The manifest serialisation MUST provide a method to specify multiple 1704 version numbers of firmware to which the manifest applies, either 1705 with a list or with range matching. 1707 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1709 Implemented by: Required Image Version List (Section 3.6) 1711 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 1713 The manifest serialisation MUST provide a mechanism to list multiple 1714 equivalent payloads by Execute-In-Place Installation Address, 1715 including the payload digest and, optionally, payload URIs. 1717 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1719 Implemented by: XIP Address (Section 3.20) 1721 4.5.9. REQ.USE.EXEC: Executable Manifest 1723 It MUST be possible to describe an executable system with a manifest 1724 on both Execute-In-Place microcontrollers and on complex operating 1725 systems. This requires the manifest to specify the digest of each 1726 statically linked dependency. In addition, the manifest 1727 serialisation MUST be able to express metadata, such as a kernel 1728 command-line, used by any loader or bootloader. 1730 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1732 Implemented by: Run-time metadata (Section 3.22) 1734 4.5.10. REQ.USE.LOAD: Load-Time Information 1736 It MUST be possible to specify additional metadata for load time 1737 processing of a payload, such as cryptographic information, load- 1738 address, and compression algorithm. 1740 N.B. load comes before exec/boot. 1742 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1744 Implemented by: Load-time metadata (Section 3.21) 1746 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure 1748 It MUST be possible to place a payload in the same structure as the 1749 manifest. This MAY place the payload in the same packet as the 1750 manifest. 1752 Integrated payloads may include, for example, wrapped encryption 1753 keys, encoded configuration, public keys, [RFC8392] CBOR Web Tokens, 1754 or X.509 certificates. 1756 When an integrated payload is provided, this increases the size of 1757 the manifest. Manifest size can cause several processing and storage 1758 concerns that require careful consideration. The payload can prevent 1759 the whole manifest from being contained in a single network packet, 1760 which can cause fragmentation and the loss of portions of the 1761 manifest in lossy networks. This causes the need for reassembly and 1762 retransmission logic. The manifest must be held immutable between 1763 verification and processing (see REQ.SEC.MFST.CONST 1764 (Section 4.3.20)), so a larger manifest will consume more memory with 1765 immutability guarantees, for example internal RAM or NVRAM, or 1766 external secure memory. If the manifest exceeds the available 1767 immutable memory, then it must be processed modularly, evaluating 1768 each of: delegation chains, the security container, and the actual 1769 manifest, which includes verifying the integrated payload. If the 1770 security model calls for downloading the manifest and validating it 1771 before storing to NVRAM in order to prevent wear to NVRAM and energy 1772 expenditure in NVRAM, then either increasing memory allocated to 1773 manifest storage or modular processing of the received manifest may 1774 be required. While the manifest has been organised to enable this 1775 type of processing, it creates additional complexity in the parser. 1776 If the manifest is stored in NVRAM prior to processing, the 1777 integrated payload may cause the manifest to exceed the available 1778 storage. Because the manifest is received prior to validation of 1779 applicability, authority, or correctness, integrated payloads cause 1780 the recipient to expend network bandwidth and energy that may not be 1781 required if the manifest is discarded and these costs vary with the 1782 size of the integrated payload. 1784 See also: REQ.SEC.MFST.CONST (Section 4.3.20). 1786 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1788 Implemented by: Payload (Section 3.23) 1790 4.5.12. REQ.USE.PARSE: Simple Parsing 1792 The structure of the manifest MUST be simple to parse, without need 1793 for a general-purpose parser. 1795 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1797 Implemented by: N/A 1799 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1801 Any serialisation MUST enable the delivery of a key claim with, but 1802 not authenticated by, a manifest. This key claim delivers a new key 1803 with which the recipient can verify the manifest. 1805 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1807 Implemented by: Key Claims (Section 3.24) 1809 5. IANA Considerations 1811 This document does not require any actions by IANA. 1813 6. Acknowledgements 1815 We would like to thank our working group chairs, Dave Thaler, Russ 1816 Housley and David Waltermire, for their review comments and their 1817 support. 1819 We would like to thank the participants of the 2018 Berlin SUIT 1820 Hackathon and the June 2018 virtual design team meetings for their 1821 discussion input. In particular, we would like to thank Koen 1822 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1823 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1824 Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias 1825 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1826 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1827 Gharout, and Milen Stoychev. 1829 We would like to thank those who contributed to the development of 1830 this information model. In particular, we would like to thank 1831 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary 1832 Thomson. 1834 7. References 1836 7.1. Normative References 1838 [I-D.ietf-suit-architecture] 1839 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 1840 Firmware Update Architecture for Internet of Things", 1841 draft-ietf-suit-architecture-08 (work in progress), 1842 November 2019. 1844 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1845 Requirement Levels", BCP 14, RFC 2119, 1846 DOI 10.17487/RFC2119, March 1997, 1847 . 1849 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1850 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1851 DOI 10.17487/RFC4122, July 2005, 1852 . 1854 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1855 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1856 May 2017, . 1858 7.2. Informative References 1860 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1861 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1862 . 1864 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1865 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1866 . 1868 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1869 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1870 May 2018, . 1872 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1873 . 1876 7.3. URIs 1878 [1] mailto:suit@ietf.org 1880 [2] https://www1.ietf.org/mailman/listinfo/suit 1882 [3] https://www.ietf.org/mail-archive/web/suit/current/index.html 1884 Appendix A. Mailing List Information 1886 The discussion list for this document is located at the e-mail 1887 address suit@ietf.org [1]. Information on the group and information 1888 on how to subscribe to the list is at 1889 https://www1.ietf.org/mailman/listinfo/suit [2] 1891 Archives of the list can be found at: https://www.ietf.org/mail- 1892 archive/web/suit/current/index.html [3] 1894 Authors' Addresses 1896 Brendan Moran 1897 Arm Limited 1899 EMail: Brendan.Moran@arm.com 1901 Hannes Tschofenig 1902 Arm Limited 1904 EMail: hannes.tschofenig@gmx.net 1906 Henk Birkholz 1907 Fraunhofer SIT 1909 EMail: henk.birkholz@sit.fraunhofer.de