idnits 2.17.1 draft-ietf-suit-information-model-03.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 143 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 (July 08, 2019) is 1747 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 1649 -- Looks like a reference, but probably isn't: '2' on line 1651 -- Looks like a reference, but probably isn't: '3' on line 1654 == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-05 ** Downref: Normative reference to an Informational draft: draft-ietf-suit-architecture (ref. 'I-D.ietf-suit-architecture') ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: January 9, 2020 H. Birkholz 6 Fraunhofer SIT 7 July 08, 2019 9 Firmware Updates for Internet of Things Devices - An Information Model 10 for Manifests 11 draft-ietf-suit-information-model-03 13 Abstract 15 Vulnerabilities with Internet of Things (IoT) devices have raised the 16 need for a solid and secure firmware update mechanism that is also 17 suitable for constrained devices. Incorporating such an update 18 mechanism to fix vulnerabilities, to update configuration settings, 19 as well as adding new functionality is recommended by security 20 experts. 22 One component of such a firmware update is a concise and machine- 23 processable meta-data document, or manifest, that describes the 24 firmware image(s) and offers appropriate protection. This document 25 describes the information that must be present in the manifest. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 75 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 76 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 77 3.1. Manifest Element: Version ID of the manifest structure . 6 78 3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6 79 3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 6 80 3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7 81 3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7 82 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8 83 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 8 84 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9 85 3.5. Manifest Element: Precursor Image Digest Condition . . . 9 86 3.6. Manifest Element: Required Image Version List . . . . . . 9 87 3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10 88 3.8. Manifest Element: Payload Format . . . . . . . . . . . . 10 89 3.9. Manifest Element: Processing Steps . . . . . . . . . . . 10 90 3.10. Manifest Element: Storage Location . . . . . . . . . . . 11 91 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 11 92 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 11 93 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 11 94 3.11. Manifest Element: Component Identifier . . . . . . . . . 11 95 3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12 96 3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 12 97 3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 12 98 3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13 99 3.16. Manifest Element: Additional installation instructions . 13 100 3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 13 101 3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 13 102 3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 14 103 3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 14 104 3.21. Manifest Element: Load-time metadata . . . . . . . . . . 14 105 3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 14 106 3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 15 107 3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15 108 4. Motivation for Manifest Fields . . . . . . . . . . . . . . . 15 109 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 15 110 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16 111 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16 112 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old 113 Firmware . . . . . . . . . . . . . . . . . . . . . . 16 114 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 16 115 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 116 the type of payload . . . . . . . . . . . . . . . . . 17 117 4.2.5. THREAT.IMG.LOCATION: The target device installs the 118 payload to the wrong location . . . . . . . . . . . . 17 119 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 120 payload hosting . . . . . . . . . . . . . . . . . . . 18 121 4.2.7. THREAT.NET.MITM . . . . . . . . . . . . . . . . . . . 18 122 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 18 123 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 18 124 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 125 images . . . . . . . . . . . . . . . . . . . . . . . 18 126 4.2.11. THREAT.UPD.INTEROP: Unqualified Firmware . . . . . . 19 127 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of 128 Firmware Image for Vulnerability Analysis . . . . . . 20 129 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 130 Elements . . . . . . . . . . . . . . . . . . . . . . 20 131 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 132 Exposure . . . . . . . . . . . . . . . . . . . . . . 21 133 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 21 134 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 21 135 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 21 136 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 22 137 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 22 138 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 22 139 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 22 140 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 141 Authenticated Storage Location . . . . . . . . . . . 23 142 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote 143 Resource Location . . . . . . . . . . . . . . . . . . 23 144 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 23 145 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 146 images . . . . . . . . . . . . . . . . . . . . . . . 23 147 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 148 Class IDs . . . . . . . . . . . . . . . . . . . . . . 23 149 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 24 150 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 24 151 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 24 152 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 25 153 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 25 154 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 25 155 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 156 Instructions . . . . . . . . . . . . . . . . . . . . 25 157 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 26 158 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 159 Elements . . . . . . . . . . . . . . . . . . . . . . 26 160 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 27 161 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 27 162 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 27 163 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 164 Information Disclosures . . . . . . . . . . . . . . . 27 165 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from 166 Unpacking Unknown Formats . . . . . . . . . . . . . . 27 167 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 168 Numbers of Target Firmware . . . . . . . . . . . . . 28 169 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 170 Between Images . . . . . . . . . . . . . . . . . . . 28 171 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 172 Manifests . . . . . . . . . . . . . . . . . . . . . . 28 173 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 28 174 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 28 175 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 29 176 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 177 Manifest . . . . . . . . . . . . . . . . . . . . . . 29 178 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 29 179 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 29 180 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 29 181 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 182 Resource Location . . . . . . . . . . . . . . . . . . 30 183 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 30 184 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 31 185 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 31 186 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 32 187 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 32 188 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 32 189 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 32 190 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 33 191 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 33 192 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 33 193 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 194 Manifest . . . . . . . . . . . . . . . . . . . . . . 33 195 5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 196 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 197 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 198 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 199 8.1. Normative References . . . . . . . . . . . . . . . . . . 34 200 8.2. Informative References . . . . . . . . . . . . . . . . . 35 201 Appendix A. Mailing List Information . . . . . . . . . . . . . . 36 202 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 204 1. Introduction 206 The information model describes all the information elements required 207 to secure firmware updates of IoT devices from the threats described 208 in Section 4.1 and enables the user stories captured in Section 4.4. 209 These threats and user stories are not intended to be an exhaustive 210 list of the threats against IoT devices, nor of the possible user 211 stories that describe how to conduct a firmware update. Instead they 212 are intended to describe the threats against firmware updates in 213 isolation and provide sufficient motivation to specify the 214 information elements that cover a wide range of user stories. The 215 information model does not define the serialization, encoding, 216 ordering, or structure of information elements, only their semantics. 218 Because the information model covers a wide range of user stories and 219 a wide range of threats, not all information elements apply to all 220 scenarios. As a result, various information elements could be 221 considered optional to implement and optional to use, depending on 222 which threats exist in a particular domain of application and which 223 user stories are required. Elements marked as mandatory provide 224 baseline security and usability properties that are expected to be 225 required for most applications. Those elements are mandatory to 226 implement and mandatory to use. Elements marked as recommended 227 provide important security or usability properties that are needed on 228 most devices. Elements marked as optional enable security or 229 usability properties that are useful in some applications. 231 The definition of some of the information elements include examples 232 that illustrate their semantics and how they are intended to be used. 234 2. Conventions and Terminology 236 This document uses terms defined in [I-D.ietf-suit-architecture]. 237 The term 'Operator' refers to both, Device and Network Operator. 239 This document treats devices with a homogeneous storage architecture 240 as devices with a heterogeneous storage architecture, but with a 241 single storage subsystem. 243 2.1. Requirements Notation 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 247 "OPTIONAL" in this document are to be interpreted as described in 248 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 249 capitals, as shown here. 251 3. Manifest Information Elements 253 Each manifest information element is anchored in a security 254 requirement or a usability requirement. The manifest elements are 255 described below, justified by their requirements. 257 3.1. Manifest Element: Version ID of the manifest structure 259 An identifier that describes which iteration of the manifest format 260 is contained in the structure. 262 This element is MANDATORY and MUST be present in order to allow 263 devices to identify the version of the manifest data model that is in 264 use. 266 3.2. Manifest Element: Monotonic Sequence Number 268 A monotonically increasing sequence number. For convenience, the 269 monotonic sequence number MAY be a UTC timestamp. This allows global 270 synchronisation of sequence numbers without any additional 271 management. This number MUST be easily accessible so that code 272 choosing one out of several manifests can choose which is the latest. 274 This element is MANDATORY and is necessary to prevent malicious 275 actors from reverting a firmware update against the policies of the 276 relevant authority. 278 Implements: REQ.SEC.SEQUENCE (Section 4.3.1) 280 3.3. Manifest Element: Vendor ID 282 Vendor IDs MUST be unique. This is to prevent similarly, or 283 identically named entities from different geographic regions from 284 colliding in their customer's infrastructure. Recommended practice 285 is to use [RFC4122] version 5 UUIDs with the vendor's domain name and 286 the UUID DNS prefix. Other options include type 1 and type 4 UUIDs. 288 Vendor ID is not intended to be a human-readable element. It is 289 intended for match/mismatch comparison only. 291 The use of a Vendor ID is RECOMMENDED. It helps to distinguish 292 between identically named products from different vendors. 294 Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), 295 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 297 3.3.1. Example: Domain Name-based UUIDs 299 Vendor A creates a UUID based on their domain name: 301 vendorId = UUID5(DNS, "vendor-a.com") 303 Because the DNS infrastructure prevents multiple registrations of the 304 same domain name, this UUID is guaranteed to be unique. Because the 305 domain name is known, this UUID is reproducible. Type 1 and type 4 306 UUIDs produce similar guarantees of uniqueness, but not 307 reproducibility. 309 This approach creates a contention when a vendor changes its name or 310 relinquishes control of a domain name. In this scenario, it is 311 possible that another vendor would start using that same domain name. 312 However, this UUID is not proof of identity; a device's trust in a 313 vendor must be anchored in a cryptographic key, not a UUID. 315 3.4. Manifest Element: Class ID 317 A device "Class" is a set of different device types that can accept 318 the same firmware update without modification. Class IDs MUST be 319 unique within the scope of a Vendor ID. This is to prevent 320 similarly, or identically named devices colliding in their customer's 321 infrastructure. 323 Recommended practice is to use [RFC4122] version 5 UUIDs with as much 324 information as necessary to define firmware compatibility. Possible 325 information used to derive the class UUID includes: 327 o model name or number 329 o hardware revision 331 o runtime library version 333 o bootloader version 335 o ROM revision 336 o silicon batch number 338 The Class Identifier UUID SHOULD use the Vendor ID as the UUID 339 prefix. Other options include version 1 and 4 UUIDs. Classes MAY be 340 more granular than is required to identify firmware compatibility. 341 Classes MUST NOT be less granular than is required to identify 342 firmware compatibility. Devices MAY have multiple Class IDs. 344 Class ID is not intended to be a human-readable element. It is 345 intended for match/mismatch comparison only. 347 The use of Class ID is RECOMMENDED. It allows devices to determine 348 applicability of a firmware in an unambiguous way. 350 If Class ID is not implemented, then each logical device class MUST 351 use a unique Root of Trust for authorisation. 353 Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), 354 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 356 3.4.1. Example 1: Different Classes 358 Vendor A creates product Z and product Y. The firmware images of 359 products Z and Y are not interchangeable. Vendor A creates UUIDs as 360 follows: 362 o vendorId = UUID5(DNS, "vendor-a.com") 364 o ZclassId = UUID5(vendorId, "Product Z") 366 o YclassId = UUID5(vendorId, "Product Y") 368 This ensures that Vendor A's Product Z cannot install firmware for 369 Product Y and Product Y cannot install firmware for Product Z. 371 3.4.2. Example 2: Upgrading Class ID 373 Vendor A creates product X. Later, Vendor A adds a new feature to 374 product X, creating product X v2. Product X requires a firmware 375 update to work with firmware intended for product X v2. 377 Vendor A creates UUIDs as follows: 379 o vendorId = UUID5(DNS, "vendor-a.com") 381 o XclassId = UUID5(vendorId, "Product X") 383 o Xv2classId = UUID5(vendorId, "Product X v2") 384 When product X receives the firmware update necessary to be 385 compatible with product X v2, part of the firmware update changes the 386 class ID to Xv2classId. 388 3.4.3. Example 3: Shared Functionality 390 Vendor A produces two products, product X and product Y. These 391 components share a common core (such as an operating system), but 392 have different applications. The common core and the applications 393 can be updated independently. To enable X and Y to receive the same 394 common core update, they require the same class ID. To ensure that 395 only product X receives application X and only product Y receives 396 application Y, product X and product Y must have different class IDs. 397 The vendor creates Class IDs as follows: 399 o vendorId = UUID5(DNS, "vendor-a.com") 401 o XclassId = UUID5(vendorId, "Product X") 403 o YclassId = UUID5(vendorId, "Product Y") 405 o CommonClassId = UUID5(vendorId, "common core") 407 Product X matches against both XclassId and CommonClassId. Product Y 408 matches against both YclassId and CommonClassId. 410 3.5. Manifest Element: Precursor Image Digest Condition 412 When a precursor image is required by the payload format, a precursor 413 image digest condition MUST be present in the conditions list. The 414 precursor image may be installed or stored as a candidate. 416 This element is OPTIONAL to implement. 418 Enables feature: differential updates. 420 Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 422 3.6. Manifest Element: Required Image Version List 424 When a payload applies to multiple versions of a firmware, the 425 required image version list specifies which versions must be present 426 for the update to be applied. This allows the update author to 427 target specific versions of firmware for an update, while excluding 428 those to which it should not be applied. 430 Where an update can only be applied over specific predecessor 431 versions, that version MUST be specified by the Required Image 432 Version List. 434 This element is OPTIONAL. 436 Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) 438 3.7. Manifest Element: Expiration Time 440 This element tells a device the time at which the manifest expires 441 and should no longer be used. This is only usable in conjunction 442 with a secure source of time. 444 This element is OPTIONAL and MAY enable user stories where a secure 445 source of time is provided and firmware is intended to expire 446 predictably. 448 Implements: REQ.SEC.EXP (Section 4.3.3) 450 3.8. Manifest Element: Payload Format 452 The format of the payload MUST be indicated to devices is in an 453 unambiguous way. This element provides a mechanism to describe the 454 payload format, within the signed metadata. 456 This element is MANDATORY and MUST be present to enable devices to 457 decode payloads correctly. 459 Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT 460 (Section 4.5.5) 462 3.9. Manifest Element: Processing Steps 464 A representation of the Processing Steps required to decode a 465 payload. The representation MUST describe which algorithm(s) is used 466 and any additional parameters required by the algorithm(s). The 467 representation MAY group Processing Steps together in predefined 468 combinations. 470 A Processing Step MAY indicate the expected digest of the payload 471 after the processing is complete. 473 Processing steps are RECOMMENDED to implement. 475 Enables feature: Encrypted, compressed, packed formats 477 Implements: REQ.USE.IMG.NESTED (Section 4.5.6) 479 3.10. Manifest Element: Storage Location 481 This element tells the device where to store a payload within a given 482 component. The device can use this to establish which permissions 483 are necessary and the physical storage location to use. 485 This element is MANDATORY and MUST be present to enable devices to 486 store payloads to the correct location. 488 Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 490 3.10.1. Example 1: Two Storage Locations 492 A device supports two components: an OS and an application. These 493 components can be updated independently, expressing dependencies to 494 ensure compatibility between the components. The firmware authority 495 chooses two storage identifiers: 497 o "OS" 499 o "APP" 501 3.10.2. Example 2: File System 503 A device supports a full filesystem. The firmware authority chooses 504 to use the storage identifier as the path at which to install the 505 payload. The payload may be a tarball, in which case, it unpacks the 506 tarball into the specified path. 508 3.10.3. Example 3: Flash Memory 510 A device supports flash memory. The firmware authority chooses to 511 make the storage identifier the offset where the image should be 512 written. 514 3.11. Manifest Element: Component Identifier 516 In a heterogeneous storage architecture, a storage identifier is 517 insufficient to identify where and how to store a payload. To 518 resolve this, a component identifier indicates which part of the 519 storage architecture is targeted by the payload. In a homogeneous 520 storage architecture, this element is unnecessary. 522 This element is OPTIONAL and only necessary in heterogeneous storage 523 architecture devices. 525 N.B. A serialisation MAY choose to combine Component Identifier and 526 Storage Location (Section 3.10) 527 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 529 3.12. Manifest Element: Resource Indicator 531 This element provides the information required for the device to 532 acquire the resource. This can be encoded in several ways: 534 o One URI 536 o A list of URIs 538 o A prioritised list or URIs 540 o A list of signed URIs 542 This element is OPTIONAL and only needed when the target device does 543 not intrinsically know where to find the payload. 545 N.B. Devices will typically require URIs. 547 Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 549 3.13. Manifest Element: Payload Digests 551 This element contains one or more digests of one or more payloads. 552 This allows the target device to ensure authenticity of the 553 payload(s). A serialisation MUST provide a mechanism to select one 554 payload from a list based on system parameters, such as XIP address. 556 This element is MANDATORY to implement and fundamentally necessary to 557 ensure the authenticity and integrity of the payload. Support for 558 more than one digest is OPTIONAL to implement in a recipient device. 560 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT 561 (Section 4.5.8) 563 3.14. Manifest Element: Size 565 The size of the payload in bytes. 567 Variable-size storage locations MUST be set to exactly the size 568 listed in this element. 570 This element is MANDATORY and informs the target device how big of a 571 payload to expect. Without it, devices are exposed to some classes 572 of denial of service attack. 574 Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) 576 3.15. Manifest Element: Signature 578 This is not strictly a manifest element. Instead, the manifest is 579 wrapped by a standardised authentication container, such as a COSE 580 ([RFC8152]) or CMS ([RFC5652]) signature object. The authentication 581 container MUST support multiple actors and multiple authentication 582 methods. 584 This element is MANDATORY and represents the foundation of all 585 security properties of the manifest. There are two exceptions to 586 this requirement: 1) if the manifest is authenticated by a second 587 manifest as a dependency and 2) if the manifest is authenticated by 588 channel security and contains only channel information (such as 589 URIs). 591 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS 592 (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) 594 3.16. Manifest Element: Additional installation instructions 596 Instructions that the device should execute when processing the 597 manifest. This information is distinct from the information 598 necessary to process a payload. Additional installation instructions 599 include information such as update timing (For example, install only 600 on Sunday, at 0200), procedural considerations (for example, shut 601 down the equipment under control before executing the update), pre 602 and post-installation steps (for example, run a script). 604 This element is OPTIONAL. 606 Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 608 3.17. Manifest Element: Aliases 610 A mechanism for a manifest to augment or replace URIs or URI lists 611 defined by one or more of its dependencies. 613 This element is OPTIONAL and enables some user stories. 615 Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 617 3.18. Manifest Element: Dependencies 619 A list of other manifests that are required by the current manifest. 620 Manifests are identified an an unambiguous way, such as a digest. 622 This element is MANDATORY to use in deployments that include both 623 multiple authorities and multiple payloads. 625 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 627 3.19. Manifest Element: Encryption Wrapper 629 Encrypting firmware images requires symmetric content encryption 630 keys. The encryption wrapper provides the information needed for a 631 device to obtain or locate a key that it uses to decrypt the 632 firmware. Typical choices for an encryption wrapper include CMS 633 ([RFC5652]) or COSE ([RFC8152]). This MAY be included in a 634 decryption step contained in Processing Steps (Section 3.9). 636 This element is MANDATORY to use for encrypted payloads, 638 Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 640 3.20. Manifest Element: XIP Address 642 In order to support XIP systems with multiple possible base 643 addresses, it is necessary to specify which address the payload is 644 linked for. 646 For example a microcontroller may have a simple bootloader that 647 chooses one of two images to boot. That microcontroller then needs 648 to choose one of two firmware images to install, based on which of 649 its two images is older. 651 Implements: REQ.USE.IMG.SELECT (Section 4.5.8) 653 3.21. Manifest Element: Load-time metadata 655 Load-time metadata provides the device with information that it needs 656 in order to load one or more images. This is effectively a copy 657 operation from the permanent storage location of an image into the 658 active use location of that image. The metadata contains the source 659 and destination of the image as well as any operations that are 660 performed on the image. 662 Implements: REQ.USE.LOAD (Section 4.5.10) 664 3.22. Manifest Element: Run-time metadata 666 Run-time metadata provides the device with any extra information 667 needed to boot the device. This may include information such as the 668 entry-point of an XIP image or the kernel command-line of a linux 669 image. 671 Implements: REQ.USE.EXEC (Section 4.5.9) 673 3.23. Manifest Element: Payload 675 The Payload element provides a recipient device with the whole 676 payload, contained within the manifest superstructure. This enables 677 the manifest and payload to be delivered simultaneously. 679 Implements: REQ.USE.PAYLOAD (Section 4.5.11) 681 3.24. Manifest Element: Key Claims 683 The Key Claims element is not authenticated by the Signature 684 (Section 3.15), instead, it provides a chain of key delegations (or 685 references to them) for the device to follow in order to verify the 686 key that authenticated the manifest using a trusted key. 688 Implements: REQ.USE.DELEGATION (Section 4.5.13) 690 4. Motivation for Manifest Fields 692 The following sub-sections describe the threat model, user stories, 693 security requirements, and usability requirements. 695 4.1. Threat Model 697 The following sub-sections aim to provide information about the 698 threats that were considered, the security requirements that are 699 derived from those threats and the fields that permit implementation 700 of the security requirements. This model uses the S.T.R.I.D.E. 701 [STRIDE] approach. Each threat is classified according to: 703 o Spoofing Identity 705 o Tampering with data 707 o Repudiation 709 o Information disclosure 711 o Denial of service 713 o Elevation of privilege 715 This threat model only covers elements related to the transport of 716 firmware updates. It explicitly does not cover threats outside of 717 the transport of firmware updates. For example, threats to an IoT 718 device due to physical access are out of scope. 720 4.2. Threat Descriptions 722 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 724 Classification: Elevation of Privilege 726 An attacker sends an old, but valid manifest with an old, but valid 727 firmware image to a device. If there is a known vulnerability in the 728 provided firmware image, this may allow an attacker to exploit the 729 vulnerability and gain control of the device. 731 Threat Escalation: If the attacker is able to exploit the known 732 vulnerability, then this threat can be escalated to ALL TYPES. 734 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 736 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old Firmware 738 Classification: Elevation of Privilege 740 An attacker targets a device that has been offline for a long time 741 and runs an old firmware version. The attacker sends an old, but 742 valid manifest to a device with an old, but valid firmware image. 743 The attacker-provided firmware is newer than the installed one but 744 older than the most recently available firmware. If there is a known 745 vulnerability in the provided firmware image then this may allow an 746 attacker to gain control of a device. Because the device has been 747 offline for a long time, it is unaware of any new updates. As such 748 it will treat the old manifest as the most current. 750 Threat Escalation: If the attacker is able to exploit the known 751 vulnerability, then this threat can be escalated to ALL TYPES. 753 Mitigated by: REQ.SEC.EXP (Section 4.3.3) 755 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 757 Classification: Denial of Service 759 An attacker sends a valid firmware image, for the wrong type of 760 device, signed by an actor with firmware installation permission on 761 both types of device. The firmware is verified by the device 762 positively because it is signed by an actor with the appropriate 763 permission. This could have wide-ranging consequences. For devices 764 that are similar, it could cause minor breakage, or expose security 765 vulnerabilities. For devices that are very different, it is likely 766 to render devices inoperable. 768 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 770 4.2.3.1. Example: 772 Suppose that two vendors, Vendor A and Vendor B, adopt the same trade 773 name in different geographic regions, and they both make products 774 with the same names, or product name matching is not used. This 775 causes firmware from Vendor A to match devices from Vendor B. 777 If the vendors are the firmware authorities, then devices from Vendor 778 A will reject images signed by Vendor B since they use different 779 credentials. However, if both devices trust the same firmware 780 authority, then, devices from Vendor A could install firmware 781 intended for devices from Vendor B. 783 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 784 payload 786 Classification: Denial of Service 788 If a device misinterprets the format of the firmware image, it may 789 cause a device to install a firmware image incorrectly. An 790 incorrectly installed firmware image would likely cause the device to 791 stop functioning. 793 Threat Escalation: An attacker that can cause a device to 794 misinterpret the received firmware image may gain elevation of 795 privilege and potentially expand this to all types of threat. 797 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 799 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 800 the wrong location 802 Classification: Denial of Service 804 If a device installs a firmware image to the wrong location on the 805 device, then it is likely to break. For example, a firmware image 806 installed as an application could cause a device and/or an 807 application to stop functioning. 809 Threat Escalation: An attacker that can cause a device to 810 misinterpret the received code may gain elevation of privilege and 811 potentially expand this to all types of threat. 813 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.5) 815 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 817 Classification: Denial of Service 819 If a device does not know where to obtain the payload for an update, 820 it may be redirected to an attacker's server. This would allow an 821 attacker to provide broken payloads to devices. 823 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 825 4.2.7. THREAT.NET.MITM 827 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 829 Classification: Elevation of Privilege 831 An attacker replaces a newly downloaded firmware after a device 832 finishes verifying a manifest. This could cause the device to 833 execute the attacker's code. This attack likely requires physical 834 access to the device. However, it is possible that this attack is 835 carried out in combination with another threat that allows remote 836 execution. This is a typical Time Of Check/Time Of Use threat. 838 Threat Escalation: If the attacker is able to exploit a known 839 vulnerability, or if the attacker can supply their own firmware, then 840 this threat can be escalated to ALL TYPES. 842 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 844 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 846 Classification: Elevation of Privilege / All Types 848 If an attacker can install their firmware on a device, by 849 manipulating either payload or metadata, then they have complete 850 control of the device. 852 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 854 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 856 Classification: Denial of Service / All Types 858 An attacker sends a valid, current manifest to a device that has an 859 unexpected precursor image. If a payload format requires a precursor 860 image (for example, delta updates) and that precursor image is not 861 available on the target device, it could cause the update to break. 863 An attacker that can cause a device to install a payload against the 864 wrong precursor image could gain elevation of privilege and 865 potentially expand this to all types of threat. However, it is 866 unlikely that a valid differential update applied to an incorrect 867 precursor would result in a functional, but vulnerable firmware. 869 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 871 4.2.11. THREAT.UPD.INTEROP: Unqualified Firmware 873 Classification: Denial of Service, Elevation of Privilege 875 This threat can appear in several ways, however it is ultimately 876 about interoperability of devices with other systems. The owner or 877 operator of a network needs to approve firmware for their network in 878 order to ensure interoperability with other devices on the network, 879 or the network itself. If the firmware is not qualified, it may not 880 work. Therefore, if a device installs firmware without the approval 881 of the network owner or operator, this is a threat to devices and the 882 network. 884 Threat Escalation: If the firmware expects configuration that is 885 present in devices deployed in Network A, but not in devices deployed 886 in Network B, then the device may experience degraded security, 887 leading to threats of All Types. 889 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 890 (Section 4.3.13) 892 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 893 Operator 895 In this example, assume that Device Operators expect the rights to 896 create firmware but that Network Operators expect the rights to 897 qualify firmware as fit-for-purpose on their networks. Additionally, 898 assume that Device Operators manage devices that can be deployed on 899 any network, including Network A and B in our example. 901 An attacker may obtain a manifest for a device on Network A. Then, 902 this attacker sends that manifest to a device on Network B. Because 903 Network A and Network B are under control of different Operators, and 904 the firmware for a device on Network A has not been qualified to be 905 deployed on Network B, the target device on Network B is now in 906 violation of the Operator B's policy and may be disabled by this 907 unqualified, but signed firmware. 909 This is a denial of service because it can render devices inoperable. 910 This is an elevation of privilege because it allows the attacker to 911 make installation decisions that should be made by the Operator. 913 4.2.11.2. Example 2: Single Network Operator with Multiple Device 914 Operators 916 Multiple devices that interoperate are used on the same network and 917 communicate with each other. Some devices are manufactured and 918 managed by Device Operator A and other devices by Device Operator B. 919 A new firmware is released by Device Operator A that breaks 920 compatibility with devices from Device Operator B. An attacker sends 921 the new firmware to the devices managed by Device Operator A without 922 approval of the Network Operator. This breaks the behaviour of the 923 larger system causing denial of service and possibly other threats. 924 Where the network is a distributed SCADA system, this could cause 925 misbehaviour of the process that is under control. 927 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 928 for Vulnerability Analysis 930 Classification: All Types 932 An attacker wants to mount an attack on an IoT device. To prepare 933 the attack he or she retrieves the provided firmware image and 934 performs reverse engineering of the firmware image to analyze it for 935 specific vulnerabilities. 937 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 939 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 941 Classification: Elevation of Privilege 943 An authorised actor, but not the firmware authority, uses an override 944 mechanism (USER_STORY.OVERRIDE (Section 4.4.3)) to change an 945 information element in a manifest signed by the firmware authority. 946 For example, if the authorised actor overrides the digest and URI of 947 the payload, the actor can replace the entire payload with a payload 948 of their choice. 950 Threat Escalation: By overriding elements such as payload 951 installation instructions or firmware digest, this threat can be 952 escalated to all types. 954 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 956 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 958 Classification: Information Disclosure 960 A third party may be able to extract sensitive information from the 961 manifest. 963 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 965 4.2.15. THREAT.IMG.EXTRA: Extra data after image 967 Classification: All Types 969 If a third party modifies the image so that it contains extra code 970 after a valid, authentic image, that third party can then use their 971 own code in order to make better use of an existing vulnerability 973 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 975 4.3. Security Requirements 977 The security requirements here are a set of policies that mitigate 978 the threats described in Section 4.1. 980 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 982 Only an actor with firmware installation authority is permitted to 983 decide when device firmware can be installed. To enforce this rule, 984 manifests MUST contain monotonically increasing sequence numbers. 985 Manifests MAY use UTC epoch timestamps to coordinate monotonically 986 increasing sequence numbers across many actors in many locations. If 987 UTC epoch timestamps are used, they MUST NOT be treated as times, 988 they MUST be treated only as sequence numbers. Devices MUST reject 989 manifests with sequence numbers smaller than any onboard sequence 990 number. 992 Note: This is not a firmware version. It is a manifest sequence 993 number. A firmware version may be rolled back by creating a new 994 manifest for the old firmware version with a later sequence number. 996 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 998 Implemented by: Monotonic Sequence Number (Section 3.2) 1000 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1002 Devices MUST only apply firmware that is intended for them. Devices 1003 MUST know with fine granularity that a given update applies to their 1004 vendor, model, hardware revision, software revision. Human-readable 1005 identifiers are often error-prone in this regard, so unique 1006 identifiers SHOULD be used. 1008 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1010 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1011 (Section 3.4) 1013 4.3.3. REQ.SEC.EXP: Expiration Time 1015 Firmware MAY expire after a given time. Devices MAY provide a secure 1016 clock (local or remote). If a secure clock is provided and the 1017 Firmware manifest has an expiration timestamp, the device MUST reject 1018 the manifest if current time is later than the expiration time. 1020 Mitigates: THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2) 1022 Implemented by: Expiration Time (Section 3.7) 1024 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1026 The authenticity of an update MUST be demonstrable. Typically, this 1027 means that updates must be digitally authenticated. Because the 1028 manifest contains information about how to install the update, the 1029 manifest's authenticity MUST also be demonstrable. To reduce the 1030 overhead required for validation, the manifest contains the digest of 1031 the firmware image, rather than a second digital signature. The 1032 authenticity of the manifest can be verified with a digital signature 1033 or Message Authentication Code, the authenticity of the firmware 1034 image is tied to the manifest by the use of a digest of the firmware 1035 image. 1037 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9) 1039 Implemented by: Signature (Section 3.15), Payload Digest 1040 (Section 3.13) 1042 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1044 The type of payload (which may be independent of format) MUST be 1045 authenticated. For example, the target must know whether the payload 1046 is XIP firmware, a loadable module, or serialized configuration data. 1048 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1050 Implemented by: Payload Format (Section 3.8), Storage Location 1051 (Section 3.10) 1053 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1054 Location 1056 The location on the target where the payload is to be stored MUST be 1057 authenticated. 1059 Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) 1061 Implemented by: Storage Location (Section 3.10) 1063 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location 1065 The location where a target should find a payload MUST be 1066 authenticated. 1068 Mitigates: THREAT.NET.REDIRECT (Section 4.2.6) 1070 Implemented by: Resource Indicator (Section 3.12) 1072 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 1074 The target SHOULD verify firmware at time of boot. This requires 1075 authenticated payload size, and digest. 1077 Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) 1079 Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) 1081 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 1083 If an update uses a differential compression method, it MUST specify 1084 the digest of the precursor image and that digest MUST be 1085 authenticated. 1087 Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10) 1089 Implemented by: Precursor Image Digest (Section 3.5) 1091 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs 1093 The identifiers that specify firmware compatibility MUST be 1094 authenticated to ensure that only compatible firmware is installed on 1095 a target device. 1097 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1099 Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition 1100 (Section 3.4) 1102 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 1104 If a device grants different rights to different actors, exercising 1105 those rights MUST be accompanied by proof of those rights, in the 1106 form of proof of authenticity. Authenticity mechanisms such as those 1107 required in REQ.SEC.AUTHENTIC (Section 4.3.4) are acceptable but need 1108 to follow the end-to-end security model. 1110 For example, if a device has a policy that requires that firmware 1111 have both an Authorship right and a Qualification right and if that 1112 device grants Authorship and Qualification rights to different 1113 parties, such as a Device Operator and a Network Operator, 1114 respectively, then the firmware cannot be installed without proof of 1115 rights from both the Device and the Network Operator. 1117 Mitigates: THREAT.UPD.INTEROP (Section 4.2.11) 1119 Implemented by: Signature (Section 3.15) 1121 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 1123 The manifest information model MUST enable encrypted payloads. 1124 Encryption helps to prevent third parties, including attackers, from 1125 reading the content of the firmware image. This can protect against 1126 confidential information disclosures and discovery of vulnerabilities 1127 through reverse engineering. Therefore the manifest must convey the 1128 information required to allow an intended recipient to decrypt an 1129 encrypted payload. 1131 Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12) 1133 Implemented by: Encryption Wrapper (Section 3.19) 1135 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 1137 If a device grants different rights to different actors, then an 1138 exercise of those rights MUST be validated against a list of rights 1139 for the actor. This typically takes the form of an Access Control 1140 List (ACL). ACLs are applied to two scenarios: 1142 1. An ACL decides which elements of the manifest may be overridden 1143 and by which actors. 1145 2. An ACL decides which component identifier/storage identifier 1146 pairs can be written by which actors. 1148 Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), THREAT.UPD.INTEROP 1149 (Section 4.2.11) 1151 Implemented by: Client-side code, not specified in manifest. 1153 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 1155 It MUST be possible to encrypt part or all of the manifest. This may 1156 be accomplished with either transport encryption or with at-rest 1157 encryption. 1159 Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14) 1161 Implemented by: External Encryption Wrapper / Transport Security 1163 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 1165 The digest SHOULD cover all available space in a fixed-size storage 1166 location. Variable-size storage locations MUST be restricted to 1167 exactly the size of deployed payload. This prevents any data from 1168 being distributed without being covered by the digest. For example, 1169 XIP microcontrollers typically have fixed-size storage. These 1170 devices should deploy a digest that covers the deployed firmware 1171 image, concatenated with the default erased value of any remaining 1172 space. 1174 Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) 1176 Implemented by: Payload Digests (Section 3.13) 1178 4.4. User Stories 1180 User stories provide expected use cases. These are used to feed into 1181 usability requirements. 1183 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 1185 As a Device Operator, I want to provide my devices with additional 1186 installation instructions so that I can keep process details out of 1187 my payload data. 1189 Some installation instructions might be: 1191 o Use a table of hashes to ensure that each block of the payload is 1192 validate before writing. 1194 o Do not report progress. 1196 o Pre-cache the update, but do not install. 1198 o Install the pre-cached update matching this manifest. 1200 o Install this update immediately, overriding any long-running 1201 tasks. 1203 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1205 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 1207 As a designer of a resource-constrained IoT device, I want bad 1208 updates to fail as early as possible to preserve battery life and 1209 limit consumed bandwidth. 1211 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1213 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 1215 As a Network Operator, I would like to be able to override the non- 1216 critical information in the manifest so that I can control my devices 1217 more precisely. The authority to override this information is 1218 provided via the installation of a limited trust relationship by 1219 another authority. 1221 Some examples of potentially overridable information: 1223 o URIs (Section 3.12): this allows the Network Operator to direct 1224 devices to their own infrastructure in order to reduce network 1225 load. 1227 o Conditions: this allows the Network Operator to pose additional 1228 constraints on the installation of the manifest. 1230 o Directives (Section 3.16): this allows the Network Operator to add 1231 more instructions such as time of installation. 1233 o Processing Steps (Section 3.9): If an intermediary performs an 1234 action on behalf of a device, it may need to override the 1235 processing steps. It is still possible for a device to verify the 1236 final content and the result of any processing step that specifies 1237 a digest. Some processing steps should be non-overridable. 1239 Satisfied by: USER_STORY.OVERRIDE (Section 4.4.3), 1240 REQ.USE.MFST.COMPONENT (Section 4.5.3) 1242 4.4.4. USER_STORY.COMPONENT: Component Update 1244 As an Operator, I want to divide my firmware into components, so that 1245 I can reduce the size of updates, make different parties responsible 1246 for different components, and divide my firmware into frequently 1247 updated and infrequently updated components. 1249 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1251 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations 1253 As a Device Operator, I want to ensure the quality of a firmware 1254 update before installing it, so that I can ensure interoperability of 1255 all devices in my product family. I want to restrict the ability to 1256 make changes to my devices to require my express approval. 1258 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), 1259 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1261 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1263 As an Operator, I want to be able to send multiple payload formats to 1264 suit the needs of my update, so that I can optimise the bandwidth 1265 used by my devices. 1267 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) 1269 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1270 Disclosures 1272 As an firmware author, I want to prevent confidential information 1273 from being disclosed during firmware updates. It is assumed that 1274 channel security or at-rest encryption is adequate to protect the 1275 manifest itself against information disclosure. 1277 Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1279 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 1280 Unknown Formats 1282 As a Device Operator, I want devices to determine whether they can 1283 process a payload prior to downloading it. 1285 In some cases, it may be desirable for a third party to perform some 1286 processing on behalf of a target. For this to occur, the third party 1287 MUST indicate what processing occurred and how to verify it against 1288 the Trust Provisioning Authority's intent. 1290 This amounts to overriding Processing Steps (Section 3.9) and 1291 Resource Indicator (Section 3.12). 1293 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED 1294 (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 1296 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 1297 Target Firmware 1299 As a Device Operator, I want to be able to target devices for updates 1300 based on their current firmware version, so that I can control which 1301 versions are replaced with a single manifest. 1303 Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7) 1305 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 1307 As a developer, I want to be able to sign two or more versions of my 1308 firmware in a single manifest so that I can use a very simple 1309 bootloader that chooses between two or more images that are executed 1310 in-place. 1312 Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8) 1314 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 1316 As a signer for both secure execution/boot and firmware deployment, I 1317 would like to use the same signed document for both tasks so that my 1318 data size is smaller, I can share common code, and I can reduce 1319 signature verifications. 1321 Satisfied by: REQ.USE.EXEC (Section 4.5.9) 1323 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 1325 As a developer of firmware for a run-from-RAM device, I would like to 1326 use compressed images and to indicate to the bootloader that I am 1327 using a compressed image in the manifest so that it can be used with 1328 secure execution/boot. 1330 Satisfied by: REQ.USE.LOAD (Section 4.5.10) 1332 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 1334 As an operator of a constrained network, I would like to be able to 1335 send a small payload in the same packet as the manifest so that I can 1336 reduce network traffic. 1338 Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) 1340 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 1342 As a developer for constrained devices, I want a low complexity 1343 library for processing updates so that I can fit more application 1344 code on my device. 1346 Satisfied by: REQ.USE.PARSE (Section 4.5.12) 1348 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 1350 As an operator that rotates delegated authority more often than 1351 delivering firmware updates, I would like to delegate a new authority 1352 when I deliver a firmware update so that I can accomplish both tasks 1353 in a single transmission. 1355 Satisfied by: REQ.USE.DELEGATION (Section 4.5.13) 1357 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 1359 As an operator of a constrained network, I would like devices on my 1360 network to be able to evaluate the suitability of an update prior to 1361 initiating any large download so that I can prevent unnecessary 1362 consumption of bandwidth. 1364 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1366 4.5. Usability Requirements 1368 The following usability requirements satisfy the user stories listed 1369 above. 1371 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 1373 It MUST be possible for a manifest author to place ALL information 1374 required to process an update in the manifest. 1376 For example: Information about which precursor image is required for 1377 a differential update MUST be placed in the manifest, not in the 1378 differential compression header. 1380 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1381 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1383 Implemented by: Additional installation instructions (Section 3.16) 1385 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1387 It MUST be possible to redirect payload fetches. This applies where 1388 two manifests are used in conjunction. For example, a Device 1389 Operator creates a manifest specifying a payload and signs it, and 1390 provides a URI for that payload. A Network Operator creates a second 1391 manifest, with a dependency on the first. They use this second 1392 manifest to override the URIs provided by the Device Operator, 1393 directing them into their own infrastructure instead. Some devices 1394 may provide this capability, while others may only look at canonical 1395 sources of firmware. For this to be possible, the device must fetch 1396 the payload, whereas a device that accepts payload pushes will ignore 1397 this feature. 1399 N.B. If a manifest is delivered over an authenticated channel and 1400 that manifest contains only override information for which the remote 1401 is authorised, then it can be considered authenticated by the channel 1402 authentication. 1404 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1406 Implemented by: Aliases (Section 3.17) 1408 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 1410 It MUST be possible express the requirement to install one or more 1411 payloads from one or more authorities so that a multi-payload update 1412 can be described. This allows multiple parties with different 1413 permissions to collaborate in creating a single update for the IoT 1414 device, across multiple components. 1416 This requirement effectively means that it must be possible to 1417 construct a tree of manifests on a multi-image target. 1419 In order to enable devices with a heterogeneous storage architecture, 1420 the manifest must enable specification of both storage system and the 1421 storage location within that storage system. 1423 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1424 (Section 4.4.4) 1426 Implemented by Manifest Element: Dependencies, StorageIdentifier, 1427 ComponentIdentifier 1429 4.5.3.1. Example 1: Multiple Microcontrollers 1431 An IoT device with multiple microcontrollers in the same physical 1432 device (HeSA) will likely require multiple payloads with different 1433 component identifiers. 1435 4.5.3.2. Example 2: Code and Configuration 1437 A firmware image can be divided into two payloads: code and 1438 configuration. These payloads may require authorizations from 1439 different actors in order to install (see REQ.SEC.RIGHTS 1440 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1441 structure means that multiple manifests may be required, with a 1442 dependency structure between them. 1444 4.5.3.3. Example 3: Multiple Software Modules 1446 A firmware image can be divided into multiple functional blocks for 1447 separate testing and distribution. This means that code would need 1448 to be distributed in multiple payloads. For example, this might be 1449 desirable in order to ensure that common code between devices is 1450 identical in order to reduce distribution bandwidth. 1452 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1454 It MUST be possible to authenticate a manifest multiple times so that 1455 authorisations from multiple parties with different permissions can 1456 be required in order to authorise installation of a manifest. 1458 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1460 Implemented by: Signature (Section 3.15) 1462 4.5.5. REQ.USE.IMG.FORMAT: Format Usability 1464 The manifest serialisation MUST accommodate any payload format that 1465 an Operator wishes to use. This enables the recipient to detect 1466 which format the Operator has chosen. Some examples of payload 1467 format are: 1469 o Binary 1471 o Elf 1473 o Differential 1475 o Compressed 1476 o Packed configuration 1478 o Intel HEX 1480 o S-Record 1482 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1483 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1485 Implemented by: Payload Format (Section 3.8) 1487 4.5.6. REQ.USE.IMG.NESTED: Nested Formats 1489 The manifest serialisation MUST accommodate nested formats, 1490 announcing to the target device all the nesting steps and any 1491 parameters used by those steps. 1493 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1495 Implemented by: Processing Steps (Section 3.9) 1497 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 1499 The manifest serialisation MUST provide a method to specify multiple 1500 version numbers of firmware to which the manifest applies, either 1501 with a list or with range matching. 1503 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1505 Implemented by: Required Image Version List (Section 3.6) 1507 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 1509 The manifest serialisation MUST provide a mechanism to list multiple 1510 equivalent payloads by Execute-In-Place Installation Address, 1511 including the payload digest and, optionally, payload URIs. 1513 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1515 Implemented by: XIP Address (Section 3.20) 1517 4.5.9. REQ.USE.EXEC: Executable Manifest 1519 It MUST be possible to describe an executable system with a manifest 1520 on both Execute-In-Place microcontrollers and on complex operating 1521 systems. This requires the manifest to specify the digest of each 1522 statically linked dependency. In addition, the manifest 1523 serialisation MUST be able to express metadata, such as a kernel 1524 command-line, used by any loader or bootloader. 1526 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1528 Implemented by: Run-time metadata (Section 3.22) 1530 4.5.10. REQ.USE.LOAD: Load-Time Information 1532 It MUST be possible to specify additional metadata for load time 1533 processing of a payload, such as cryptographic information, load- 1534 address, and compression algorithm. 1536 N.B. load comes before exec/boot. 1538 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1540 Implemented by: Load-time metadata (Section 3.21) 1542 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure 1544 It MUST be possible to place a payload in the same structure as the 1545 manifest. This MAY place the payload in the same packet as the 1546 manifest. 1548 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1550 Implemented by: Payload (Section 3.23) 1552 4.5.12. REQ.USE.PARSE: Simple Parsing 1554 The structure of the manifest MUST be simple to parse, without need 1555 for a general-purpose parser. 1557 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1559 Implemented by: N/A 1561 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1563 Any serialisation MUST enable the delivery of a key claim with, but 1564 not authenticated by a manifest. This key claim delivers a new key 1565 with which the recipient can verify the manifest. 1567 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1569 Implemented by: Key Claims (Section 3.24) 1571 5. Security Considerations 1573 Security considerations for this document are covered in Section 4. 1575 6. IANA Considerations 1577 This document does not require any actions by IANA. 1579 7. Acknowledgements 1581 We would like to thank our working group chairs, Dave Thaler, Russ 1582 Housley and David Waltermire, for their review comments and their 1583 support. 1585 We would like to thank the participants of the 2018 Berlin SUIT 1586 Hackathon and the June 2018 virtual design team meetings for their 1587 discussion input. In particular, we would like to thank Koen 1588 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1589 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1590 Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias 1591 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1592 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1593 Gharout, and Milen Stoychev. 1595 We would like to thank those who contributed to the development of 1596 this information model. In particular, we would like to thank 1597 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, Gary 1598 Thomson. 1600 8. References 1602 8.1. Normative References 1604 [I-D.ietf-suit-architecture] 1605 Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A 1606 Firmware Update Architecture for Internet of Things 1607 Devices", draft-ietf-suit-architecture-05 (work in 1608 progress), April 2019. 1610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1611 Requirement Levels", BCP 14, RFC 2119, 1612 DOI 10.17487/RFC2119, March 1997, 1613 . 1615 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1616 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1617 DOI 10.17487/RFC4122, July 2005, 1618 . 1620 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1621 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1622 . 1624 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1625 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1626 . 1628 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1629 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1630 May 2017, . 1632 8.2. Informative References 1634 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1635 . 1638 8.3. URIs 1640 [1] mailto:suit@ietf.org 1642 [2] https://www1.ietf.org/mailman/listinfo/suit 1644 [3] https://www.ietf.org/mail-archive/web/suit/current/index.html 1646 Appendix A. Mailing List Information 1648 The discussion list for this document is located at the e-mail 1649 address suit@ietf.org [1]. Information on the group and information 1650 on how to subscribe to the list is at 1651 https://www1.ietf.org/mailman/listinfo/suit [2] 1653 Archives of the list can be found at: https://www.ietf.org/mail- 1654 archive/web/suit/current/index.html [3] 1656 Authors' Addresses 1658 Brendan Moran 1659 Arm Limited 1661 EMail: Brendan.Moran@arm.com 1663 Hannes Tschofenig 1664 Arm Limited 1666 EMail: hannes.tschofenig@gmx.net 1668 Henk Birkholz 1669 Fraunhofer SIT 1671 EMail: henk.birkholz@sit.fraunhofer.de