idnits 2.17.00 (12 Aug 2021) /tmp/idnits47815/draft-ietf-suit-information-model-04.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 162 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 (October 30, 2019) is 933 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 1795 -- Looks like a reference, but probably isn't: '2' on line 1797 -- Looks like a reference, but probably isn't: '3' on line 1800 == Outdated reference: draft-ietf-suit-architecture has been published as RFC 9019 ** Downref: Normative reference to an Informational draft: draft-ietf-suit-architecture (ref. 'I-D.ietf-suit-architecture') Summary: 1 error (**), 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: May 2, 2020 H. Birkholz 6 Fraunhofer SIT 7 October 30, 2019 9 An Information Model for Firmware Updates in IoT Devices 10 draft-ietf-suit-information-model-04 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 May 2, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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.5. Manifest Element: Precursor Image Digest Condition . . . 9 85 3.6. Manifest Element: Required Image Version List . . . . . . 10 86 3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10 87 3.8. Manifest Element: Payload Format . . . . . . . . . . . . 10 88 3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11 89 3.10. Manifest Element: Storage Location . . . . . . . . . . . 11 90 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 11 91 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 11 92 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12 93 3.11. Manifest Element: Component Identifier . . . . . . . . . 12 94 3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12 95 3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 12 96 3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13 97 3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13 98 3.16. Manifest Element: Additional installation instructions . 13 99 3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14 100 3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 14 101 3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 14 102 3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 14 103 3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15 104 3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 15 105 3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 15 106 3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15 107 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 108 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16 109 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16 110 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16 111 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old 112 Firmware . . . . . . . . . . . . . . . . . . . . . . 16 113 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 17 114 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 115 the type of payload . . . . . . . . . . . . . . . . . 17 116 4.2.5. THREAT.IMG.LOCATION: The target device installs the 117 payload to the wrong location . . . . . . . . . . . . 18 118 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 119 payload hosting . . . . . . . . . . . . . . . . . . . 18 120 4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 18 121 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 19 122 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 19 123 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 124 images . . . . . . . . . . . . . . . . . . . . . . . 19 125 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 20 126 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of 127 Firmware Image for Vulnerability Analysis . . . . . . 21 128 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 129 Elements . . . . . . . . . . . . . . . . . . . . . . 22 130 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 131 Exposure . . . . . . . . . . . . . . . . . . . . . . 22 132 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 22 133 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 22 134 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or 135 payload prior to signing . . . . . . . . . . . . . . 23 136 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 23 137 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 23 138 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 24 139 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 24 140 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 24 141 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 25 142 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 143 Authenticated Storage Location . . . . . . . . . . . 25 145 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote 146 Resource Location . . . . . . . . . . . . . . . . . . 25 147 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 25 148 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 149 images . . . . . . . . . . . . . . . . . . . . . . . 26 150 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 151 Class IDs . . . . . . . . . . . . . . . . . . . . . . 26 152 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 26 153 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 26 154 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 27 155 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 27 156 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 27 157 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 28 158 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing 159 keys . . . . . . . . . . . . . . . . . . . . . . . . 28 160 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to 161 deployment . . . . . . . . . . . . . . . . . . . . . 28 162 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 163 trusted environment . . . . . . . . . . . . . . . . . 28 164 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 29 165 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 166 Instructions . . . . . . . . . . . . . . . . . . . . 29 167 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 29 168 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 169 Elements . . . . . . . . . . . . . . . . . . . . . . 29 170 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 30 171 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 30 172 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 30 173 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 174 Information Disclosures . . . . . . . . . . . . . . . 30 175 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from 176 Unpacking Unknown Formats . . . . . . . . . . . . . . 31 177 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 178 Numbers of Target Firmware . . . . . . . . . . . . . 31 179 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 180 Between Images . . . . . . . . . . . . . . . . . . . 31 181 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 182 Manifests . . . . . . . . . . . . . . . . . . . . . . 31 183 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 32 184 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 32 185 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 32 186 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 187 Manifest . . . . . . . . . . . . . . . . . . . . . . 32 188 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 32 189 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 32 190 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 33 191 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 192 Resource Location . . . . . . . . . . . . . . . . . . 33 194 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 33 195 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 34 196 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 34 197 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 35 198 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 35 199 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 35 200 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 36 201 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 36 202 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 36 203 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 36 204 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 205 Manifest . . . . . . . . . . . . . . . . . . . . . . 37 206 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 207 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 208 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 209 7.1. Normative References . . . . . . . . . . . . . . . . . . 37 210 7.2. Informative References . . . . . . . . . . . . . . . . . 38 211 Appendix A. Mailing List Information . . . . . . . . . . . . . . 39 212 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 214 1. Introduction 216 The information model describes all the information elements required 217 to secure firmware updates of IoT devices from the threats described 218 in Section 4.1 and enables the user stories captured in Section 4.4. 219 These threats and user stories are not intended to be an exhaustive 220 list of the threats against IoT devices, nor of the possible user 221 stories that describe how to conduct a firmware update. Instead they 222 are intended to describe the threats against firmware updates in 223 isolation and provide sufficient motivation to specify the 224 information elements that cover a wide range of user stories. The 225 information model does not define the serialization, encoding, 226 ordering, or structure of information elements, only their semantics. 228 Because the information model covers a wide range of user stories and 229 a wide range of threats, not all information elements apply to all 230 scenarios. As a result, various information elements could be 231 considered optional to implement and optional to use, depending on 232 which threats exist in a particular domain of application and which 233 user stories are required. Elements marked as mandatory provide 234 baseline security and usability properties that are expected to be 235 required for most applications. Those elements are mandatory to 236 implement and mandatory to use. Elements marked as recommended 237 provide important security or usability properties that are needed on 238 most devices. Elements marked as optional enable security or 239 usability properties that are useful in some applications. 241 The definition of some of the information elements include examples 242 that illustrate their semantics and how they are intended to be used. 244 2. Conventions and Terminology 246 This document uses terms defined in [I-D.ietf-suit-architecture]. 247 The term 'Operator' refers to both Device and Network Operator. 249 This document treats devices with a homogeneous storage architecture 250 as devices with a heterogeneous storage architecture, but with a 251 single storage subsystem. 253 2.1. Requirements Notation 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 257 "OPTIONAL" in this document are to be interpreted as described in 258 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 259 capitals, as shown here. 261 3. Manifest Information Elements 263 Each manifest information element is anchored in a security 264 requirement or a usability requirement. The manifest elements are 265 described below, justified by their requirements. 267 3.1. Manifest Element: Version ID of the manifest structure 269 An identifier that describes which iteration of the manifest format 270 is contained in the structure. 272 This element is MANDATORY and MUST be present in order to allow 273 devices to identify the version of the manifest data model that is in 274 use. 276 3.2. Manifest Element: Monotonic Sequence Number 278 A monotonically increasing sequence number. For convenience, the 279 monotonic sequence number MAY be a UTC timestamp. This allows global 280 synchronisation of sequence numbers without any additional 281 management. This number MUST be easily accessible so that code 282 choosing one out of several manifests can choose which is the latest. 284 This element is MANDATORY and is necessary to prevent malicious 285 actors from reverting a firmware update against the policies of the 286 relevant authority. 288 Implements: REQ.SEC.SEQUENCE (Section 4.3.1) 290 3.3. Manifest Element: Vendor ID 292 Vendor IDs must be unique. This is to prevent similarly, or 293 identically named entities from different geographic regions from 294 colliding in their customer's infrastructure. Recommended practice 295 is to use [RFC4122] version 5 UUIDs with the vendor's domain name and 296 the DNS name space ID. Other options include type 1 and type 4 297 UUIDs. 299 Vendor ID is not intended to be a human-readable element. It is 300 intended for binary match/mismatch comparison only. 302 The use of a Vendor ID is RECOMMENDED. It helps to distinguish 303 between identically named products from different vendors. 305 Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), 306 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 308 3.3.1. Example: Domain Name-based UUIDs 310 Vendor A creates a UUID based on their domain name: 312 vendorId = UUID5(DNS, "vendor-a.com") 314 Because the DNS infrastructure prevents multiple registrations of the 315 same domain name, this UUID is (with very high probability) 316 guaranteed to be unique. Because the domain name is known, this UUID 317 is reproducible. Type 1 and type 4 UUIDs produce similar guarantees 318 of uniqueness, but not reproducibility. 320 This approach creates a contention when a vendor changes its name or 321 relinquishes control of a domain name. In this scenario, it is 322 possible that another vendor would start using that same domain name. 323 However, this UUID is not proof of identity; a device's trust in a 324 vendor must be anchored in a cryptographic key, not a UUID. 326 3.4. Manifest Element: Class ID 328 A device "Class" is a set of different device types that can accept 329 the same firmware update without modification. Class IDs MUST be 330 unique within the scope of a Vendor ID. This is to prevent 331 similarly, or identically named devices colliding in their customer's 332 infrastructure. 334 Recommended practice is to use [RFC4122] version 5 UUIDs with as much 335 information as necessary to define firmware compatibility. Possible 336 information used to derive the class UUID includes: 338 o model name or number 340 o hardware revision 342 o runtime library version 344 o bootloader version 346 o ROM revision 348 o silicon batch number 350 The Class Identifier UUID SHOULD use the Vendor ID as the name space 351 ID. Other options include version 1 and 4 UUIDs. Classes MAY be 352 more granular than is required to identify firmware compatibility. 353 Classes MUST NOT be less granular than is required to identify 354 firmware compatibility. Devices MAY have multiple Class IDs. 356 Class ID is not intended to be a human-readable element. It is 357 intended for binary match/mismatch comparison only. 359 The use of Class ID is RECOMMENDED. It allows devices to determine 360 applicability of a firmware in an unambiguous way. 362 If Class ID is not implemented, then each logical device class MUST 363 use a unique trust anchor for authorisation. 365 Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), 366 REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). 368 3.4.1. Example 1: Different Classes 370 Vendor A creates product Z and product Y. The firmware images of 371 products Z and Y are not interchangeable. Vendor A creates UUIDs as 372 follows: 374 o vendorId = UUID5(DNS, "vendor-a.com") 376 o ZclassId = UUID5(vendorId, "Product Z") 378 o YclassId = UUID5(vendorId, "Product Y") 380 This ensures that Vendor A's Product Z cannot install firmware for 381 Product Y and Product Y cannot install firmware for Product Z. 383 3.4.2. Example 2: Upgrading Class ID 385 Vendor A creates product X. Later, Vendor A adds a new feature to 386 product X, creating product X v2. Product X requires a firmware 387 update to work with firmware intended for product X v2. 389 Vendor A creates UUIDs as follows: 391 o vendorId = UUID5(DNS, "vendor-a.com") 393 o XclassId = UUID5(vendorId, "Product X") 395 o Xv2classId = UUID5(vendorId, "Product X v2") 397 When product X receives the firmware update necessary to be 398 compatible with product X v2, part of the firmware update changes the 399 class ID to Xv2classId. 401 3.4.3. Example 3: Shared Functionality 403 Vendor A produces two products, product X and product Y. These 404 components share a common core (such as an operating system), but 405 have different applications. The common core and the applications 406 can be updated independently. To enable X and Y to receive the same 407 common core update, they require the same class ID. To ensure that 408 only product X receives application X and only product Y receives 409 application Y, product X and product Y must have different class IDs. 410 The vendor creates Class IDs as follows: 412 o vendorId = UUID5(DNS, "vendor-a.com") 414 o XclassId = UUID5(vendorId, "Product X") 416 o YclassId = UUID5(vendorId, "Product Y") 418 o CommonClassId = UUID5(vendorId, "common core") 420 Product X matches against both XclassId and CommonClassId. Product Y 421 matches against both YclassId and CommonClassId. 423 3.5. Manifest Element: Precursor Image Digest Condition 425 When a precursor image is required by the payload format, a precursor 426 image digest condition MUST be present in the conditions list. The 427 precursor image may be installed or stored as a candidate. 429 This element is OPTIONAL to implement. 431 Enables feature: differential updates. 433 Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 435 3.6. Manifest Element: Required Image Version List 437 When a payload applies to multiple versions of a firmware, the 438 required image version list specifies which versions must be present 439 for the update to be applied. This allows the update author to 440 target specific versions of firmware for an update, while excluding 441 those to which it should not be applied. 443 Where an update can only be applied over specific predecessor 444 versions, that version MUST be specified by the Required Image 445 Version List. 447 This element is OPTIONAL. 449 Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) 451 3.7. Manifest Element: Expiration Time 453 This element tells a device the time at which the manifest expires 454 and should no longer be used. This is only usable in conjunction 455 with a secure source of time. 457 This element is OPTIONAL and MAY enable user stories where a secure 458 source of time is provided and firmware is intended to expire 459 predictably. 461 Implements: REQ.SEC.EXP (Section 4.3.3) 463 3.8. Manifest Element: Payload Format 465 The format of the payload MUST be indicated to devices in an 466 unambiguous way. This element provides a mechanism to describe the 467 payload format, within the signed metadata. 469 This element is MANDATORY and MUST be present to enable devices to 470 decode payloads correctly. 472 Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT 473 (Section 4.5.5) 475 3.9. Manifest Element: Processing Steps 477 A representation of the Processing Steps required to decode a 478 payload. The representation MUST describe which algorithm(s) is used 479 and any additional parameters required by the algorithm(s). The 480 representation MAY group Processing Steps together in predefined 481 combinations. 483 A Processing Step MAY indicate the expected digest of the payload 484 after the processing is complete. 486 Processing steps are RECOMMENDED to implement. 488 Enables feature: Encrypted, compressed, packed formats 490 Implements: REQ.USE.IMG.NESTED (Section 4.5.6) 492 3.10. Manifest Element: Storage Location 494 This element tells the device where to store a payload within a given 495 component. The device can use this to establish which permissions 496 are necessary and the physical storage location to use. 498 This element is MANDATORY and MUST be present to enable devices to 499 store payloads to the correct location. 501 Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) 503 3.10.1. Example 1: Two Storage Locations 505 A device supports two components: an OS and an application. These 506 components can be updated independently, expressing dependencies to 507 ensure compatibility between the components. The Author chooses two 508 storage identifiers: 510 o "OS" 512 o "APP" 514 3.10.2. Example 2: File System 516 A device supports a full filesystem. The Author chooses to use the 517 storage identifier as the path at which to install the payload. The 518 payload may be a tarball, in which case, it unpacks the tarball into 519 the specified path. 521 3.10.3. Example 3: Flash Memory 523 A device supports flash memory. The Author chooses to make the 524 storage identifier the offset where the image should be written. 526 3.11. Manifest Element: Component Identifier 528 In a heterogeneous storage architecture, a storage identifier is 529 insufficient to identify where and how to store a payload. To 530 resolve this, a component identifier indicates which part of the 531 storage architecture is targeted by the payload. In a homogeneous 532 storage architecture, this element is unnecessary. 534 This element is OPTIONAL and only necessary in heterogeneous storage 535 architecture devices. 537 N.B. A serialisation MAY choose to combine Component Identifier and 538 Storage Location (Section 3.10) 540 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 542 3.12. Manifest Element: Resource Indicator 544 This element provides the information required for the device to 545 acquire the resource. This can be encoded in several ways: 547 o One URI 549 o A list of URIs 551 o A prioritised list of URIs 553 o A list of signed URIs 555 This element is OPTIONAL and only needed when the target device does 556 not intrinsically know where to find the payload. 558 N.B. Devices will typically require URIs. 560 Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 562 3.13. Manifest Element: Payload Digests 564 This element contains one or more digests of one or more payloads. 565 This allows the target device to ensure authenticity of the 566 payload(s). A serialisation MUST provide a mechanism to select one 567 payload from a list based on system parameters, such as Execute-In- 568 Place Installation Address. 570 This element is MANDATORY to implement and fundamentally necessary to 571 ensure the authenticity and integrity of the payload. Support for 572 more than one digest is OPTIONAL to implement in a recipient device. 574 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT 575 (Section 4.5.8) 577 3.14. Manifest Element: Size 579 The size of the payload in bytes. 581 Variable-size storage locations MUST be set to exactly the size 582 listed in this element. 584 This element is MANDATORY and informs the target device how big of a 585 payload to expect. Without it, devices are exposed to some classes 586 of denial of service attack. 588 Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) 590 3.15. Manifest Element: Signature 592 This is not strictly a manifest element. Instead, the manifest is 593 wrapped by a standardised authentication container, such as a COSE 594 ([RFC8152]) or CMS ([RFC5652]) signature object. The authentication 595 container MUST support multiple actors and multiple authentication 596 methods. 598 This element is MANDATORY and represents the foundation of all 599 security properties of the manifest. There are two exceptions to 600 this requirement: 1) if the manifest is authenticated by a second 601 manifest as a dependency and 2) if the manifest is authenticated by 602 channel security and contains only channel information (such as 603 URIs). 605 Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS 606 (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) 608 3.16. Manifest Element: Additional installation instructions 610 Instructions that the device should execute when processing the 611 manifest. This information is distinct from the information 612 necessary to process a payload. Additional installation instructions 613 include information such as update timing (for example, install only 614 on Sunday, at 0200), procedural considerations (for example, shut 615 down the equipment under control before executing the update), pre- 616 and post-installation steps (for example, run a script). 618 This element is OPTIONAL. 620 Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 622 3.17. Manifest Element: Aliases 624 A mechanism for a manifest to augment or replace URIs or URI lists 625 defined by one or more of its dependencies. 627 This element is OPTIONAL and enables some user stories. 629 Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 631 3.18. Manifest Element: Dependencies 633 A list of other manifests that are required by the current manifest. 634 Manifests are identified an unambiguous way, such as a digest. 636 This element is MANDATORY to use in deployments that include both 637 multiple authorities and multiple payloads. 639 Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) 641 3.19. Manifest Element: Encryption Wrapper 643 Encrypting firmware images requires symmetric content encryption 644 keys. The encryption wrapper provides the information needed for a 645 device to obtain or locate a key that it uses to decrypt the 646 firmware. Typical choices for an encryption wrapper include CMS 647 ([RFC5652]) or COSE ([RFC8152]). This MAY be included in a 648 decryption step contained in Processing Steps (Section 3.9). 650 This element is MANDATORY to use for encrypted payloads, 652 Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 654 3.20. Manifest Element: XIP Address 656 In order to support XIP systems with multiple possible base 657 addresses, it is necessary to specify which address the payload is 658 linked for. 660 For example a microcontroller may have a simple bootloader that 661 chooses one of two images to boot. That microcontroller then needs 662 to choose one of two firmware images to install, based on which of 663 its two images is older. 665 Implements: REQ.USE.IMG.SELECT (Section 4.5.8) 667 3.21. Manifest Element: Load-time metadata 669 Load-time metadata provides the device with information that it needs 670 in order to load one or more images. This is effectively a copy 671 operation from the permanent storage location of an image into the 672 active use location of that image. The metadata contains the source 673 and destination of the image as well as any operations that are 674 performed on the image. 676 Implements: REQ.USE.LOAD (Section 4.5.10) 678 3.22. Manifest Element: Run-time metadata 680 Run-time metadata provides the device with any extra information 681 needed to boot the device. This may include information such as the 682 entry-point of an XIP image or the kernel command-line of a Linux 683 image. 685 Implements: REQ.USE.EXEC (Section 4.5.9) 687 3.23. Manifest Element: Payload 689 The Payload element provides a recipient device with the whole 690 payload, contained within the manifest superstructure. This enables 691 the manifest and payload to be delivered simultaneously. 693 Implements: REQ.USE.PAYLOAD (Section 4.5.11) 695 3.24. Manifest Element: Key Claims 697 The Key Claims element is not authenticated by the Signature 698 (Section 3.15), instead, it provides a chain of key delegations (or 699 references to them) for the device to follow in order to verify the 700 key that authenticated the manifest using a trusted key. 702 Implements: REQ.USE.DELEGATION (Section 4.5.13) 704 4. Security Considerations 706 The following sub-sections describe the threat model, user stories, 707 security requirements, and usability requirements. This section also 708 provides the motivations for each of the manifest information 709 elements. 711 4.1. Threat Model 713 The following sub-sections aim to provide information about the 714 threats that were considered, the security requirements that are 715 derived from those threats and the fields that permit implementation 716 of the security requirements. This model uses the S.T.R.I.D.E. 717 [STRIDE] approach. Each threat is classified according to: 719 o Spoofing identity 721 o Tampering with data 723 o Repudiation 725 o Information disclosure 727 o Denial of service 729 o Elevation of privilege 731 This threat model only covers elements related to the transport of 732 firmware updates. It explicitly does not cover threats outside of 733 the transport of firmware updates. For example, threats to an IoT 734 device due to physical access are out of scope. 736 4.2. Threat Descriptions 738 4.2.1. THREAT.IMG.EXPIRED: Old Firmware 740 Classification: Elevation of Privilege 742 An attacker sends an old, but valid manifest with an old, but valid 743 firmware image to a device. If there is a known vulnerability in the 744 provided firmware image, this may allow an attacker to exploit the 745 vulnerability and gain control of the device. 747 Threat Escalation: If the attacker is able to exploit the known 748 vulnerability, then this threat can be escalated to ALL TYPES. 750 Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) 752 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old Firmware 754 Classification: Elevation of Privilege 756 An attacker targets a device that has been offline for a long time 757 and runs an old firmware version. The attacker sends an old, but 758 valid manifest to a device with an old, but valid firmware image. 760 The attacker-provided firmware is newer than the installed one but 761 older than the most recently available firmware. If there is a known 762 vulnerability in the provided firmware image then this may allow an 763 attacker to gain control of a device. Because the device has been 764 offline for a long time, it is unaware of any new updates. As such 765 it will treat the old manifest as the most current. 767 Threat Escalation: If the attacker is able to exploit the known 768 vulnerability, then this threat can be escalated to ALL TYPES. 770 Mitigated by: REQ.SEC.EXP (Section 4.3.3) 772 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware 774 Classification: Denial of Service 776 An attacker sends a valid firmware image, for the wrong type of 777 device, signed by an actor with firmware installation permission on 778 both types of device. The firmware is verified by the device 779 positively because it is signed by an actor with the appropriate 780 permission. This could have wide-ranging consequences. For devices 781 that are similar, it could cause minor breakage, or expose security 782 vulnerabilities. For devices that are very different, it is likely 783 to render devices inoperable. 785 Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) 787 4.2.3.1. Example: 789 Suppose that two vendors, Vendor A and Vendor B, adopt the same trade 790 name in different geographic regions, and they both make products 791 with the same names, or product name matching is not used. This 792 causes firmware from Vendor A to match devices from Vendor B. 794 If the vendors are the firmware authorities, then devices from Vendor 795 A will reject images signed by Vendor B since they use different 796 credentials. However, if both devices trust the same Author, then, 797 devices from Vendor A could install firmware intended for devices 798 from Vendor B. 800 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 801 payload 803 Classification: Denial of Service 805 If a device misinterprets the format of the firmware image, it may 806 cause a device to install a firmware image incorrectly. An 807 incorrectly installed firmware image would likely cause the device to 808 stop functioning. 810 Threat Escalation: An attacker that can cause a device to 811 misinterpret the received firmware image may gain elevation of 812 privilege and potentially expand this to all types of threat. 814 Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5) 816 4.2.5. THREAT.IMG.LOCATION: The target device installs the payload to 817 the wrong location 819 Classification: Denial of Service 821 If a device installs a firmware image to the wrong location on the 822 device, then it is likely to break. For example, a firmware image 823 installed as an application could cause a device and/or an 824 application to stop functioning. 826 Threat Escalation: An attacker that can cause a device to 827 misinterpret the received code may gain elevation of privilege and 828 potentially expand this to all types of threat. 830 Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.5) 832 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 834 Classification: Denial of Service 836 If a device does not know where to obtain the payload for an update, 837 it may be redirected to an attacker's server. This would allow an 838 attacker to provide broken payloads to devices. 840 Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) 842 4.2.7. THREAT.NET.MITM: Traffic interception 844 Classification: Spoofing Identity, Tampering with Data 846 An attacker intercepts all traffic to and from a device. The 847 attacker can monitor or modify any data sent to or received from the 848 device. This can take the form of: manifests, payloads, status 849 reports, and capability reports being modified or not delivered to 850 the intended recipient. It can also take the form of analysis of 851 data sent to or from the device, either in content, size, or 852 frequency. 854 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), 855 REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC 856 (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), 857 REQ.SEC.REPORTING (Section 4.3.16) 859 4.2.8. THREAT.IMG.REPLACE: Payload Replacement 861 Classification: Elevation of Privilege 863 An attacker replaces a newly downloaded firmware after a device 864 finishes verifying a manifest. This could cause the device to 865 execute the attacker's code. This attack likely requires physical 866 access to the device. However, it is possible that this attack is 867 carried out in combination with another threat that allows remote 868 execution. This is a typical Time Of Check/Time Of Use threat. 870 Threat Escalation: If the attacker is able to exploit a known 871 vulnerability, or if the attacker can supply their own firmware, then 872 this threat can be escalated to ALL TYPES. 874 Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) 876 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 878 Classification: Elevation of Privilege / All Types 880 If an attacker can install their firmware on a device, by 881 manipulating either payload or metadata, then they have complete 882 control of the device. 884 Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) 886 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 888 Classification: Denial of Service / All Types 890 An attacker sends a valid, current manifest to a device that has an 891 unexpected precursor image. If a payload format requires a precursor 892 image (for example, delta updates) and that precursor image is not 893 available on the target device, it could cause the update to break. 895 An attacker that can cause a device to install a payload against the 896 wrong precursor image could gain elevation of privilege and 897 potentially expand this to all types of threat. However, it is 898 unlikely that a valid differential update applied to an incorrect 899 precursor would result in a functional, but vulnerable firmware. 901 Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) 903 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 905 Classification: Denial of Service, Elevation of Privilege 907 This threat can appear in several ways, however it is ultimately 908 about ensuring that devices retain the behaviour required by their 909 Owner, Device Operator, or Network Operator. The owner or operator 910 of a device typically requires that the device maintain certain 911 features, functions, capabilities, behaviours, or interoperability 912 constraints (more generally, behaviour). If these requirements are 913 broken, then a device will not fulfill its purpose. Therefore, if 914 any party other than the device's Owner or the Owner's contracted 915 Device Operator has the ability to modify device behaviour without 916 approval, then this constitutes an elevation of privilege. 918 Similarly, a network operator may require that devices behave in a 919 particular way in order to maintain the integrity of the network. If 920 devices behaviour on a network can be modified without the approval 921 of the network operator, then this constitutes an elevation of 922 privilege with respect to the network. 924 For example, if the owner of a device has purchased that device 925 because of Features A, B, and C, and a firmware update is issued by 926 the manufacturer, which removes Feature A, then the device may not 927 fulfill the owner's requirements any more. In certain circumstances, 928 this can cause significantly greater threats. Suppose that Feature A 929 is used to implement a safety-critical system, whether the 930 manufacturer intended this behaviour or not. When unapproved 931 firmware is installed, the system may become unsafe. 933 In a second example, the owner or operator of a system of two or more 934 interoperating devices needs to approve firmware for their system in 935 order to ensure interoperability with other devices in the system. 936 If the firmware is not qualified, the system as a whole may not work. 937 Therefore, if a device installs firmware without the approval of the 938 device owner or operator, this is a threat to devices or the system 939 as a whole. 941 Similarly, the operator of a network may need to approve firmware for 942 devices attached to the network in order to ensure favourable 943 operating conditions within the network. If the firmware is not 944 qualified, it may degrade the performance of the network. Therefore, 945 if a device installs firmware without the approval of the network 946 operator, this is a threat to the network itself. 948 Threat Escalation: If the firmware expects configuration that is 949 present in devices deployed in Network A, but not in devices deployed 950 in Network B, then the device may experience degraded security, 951 leading to threats of All Types. 953 Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL 954 (Section 4.3.13) 956 4.2.11.1. Example 1: Multiple Network Operators with a Single Device 957 Operator 959 In this example, assume that Device Operators expect the rights to 960 create firmware but that Network Operators expect the rights to 961 qualify firmware as fit-for-purpose on their networks. Additionally, 962 assume that Device Operators manage devices that can be deployed on 963 any network, including Network A and B in our example. 965 An attacker may obtain a manifest for a device on Network A. Then, 966 this attacker sends that manifest to a device on Network B. Because 967 Network A and Network B are under control of different Operators, and 968 the firmware for a device on Network A has not been qualified to be 969 deployed on Network B, the target device on Network B is now in 970 violation of the Operator B's policy and may be disabled by this 971 unqualified, but signed firmware. 973 This is a denial of service because it can render devices inoperable. 974 This is an elevation of privilege because it allows the attacker to 975 make installation decisions that should be made by the Operator. 977 4.2.11.2. Example 2: Single Network Operator with Multiple Device 978 Operators 980 Multiple devices that interoperate are used on the same network and 981 communicate with each other. Some devices are manufactured and 982 managed by Device Operator A and other devices by Device Operator B. 983 A new firmware is released by Device Operator A that breaks 984 compatibility with devices from Device Operator B. An attacker sends 985 the new firmware to the devices managed by Device Operator A without 986 approval of the Network Operator. This breaks the behaviour of the 987 larger system causing denial of service and possibly other threats. 988 Where the network is a distributed SCADA system, this could cause 989 misbehaviour of the process that is under control. 991 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image 992 for Vulnerability Analysis 994 Classification: All Types 996 An attacker wants to mount an attack on an IoT device. To prepare 997 the attack he or she retrieves the provided firmware image and 998 performs reverse engineering of the firmware image to analyze it for 999 specific vulnerabilities. 1001 Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1003 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 1005 Classification: Elevation of Privilege 1007 An authorised actor, but not the Author, uses an override mechanism 1008 (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information 1009 element in a manifest signed by the Author. For example, if the 1010 authorised actor overrides the digest and URI of the payload, the 1011 actor can replace the entire payload with a payload of their choice. 1013 Threat Escalation: By overriding elements such as payload 1014 installation instructions or firmware digest, this threat can be 1015 escalated to all types. 1017 Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1019 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 1021 Classification: Information Disclosure 1023 A third party may be able to extract sensitive information from the 1024 manifest. 1026 Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) 1028 4.2.15. THREAT.IMG.EXTRA: Extra data after image 1030 Classification: All Types 1032 If a third party modifies the image so that it contains extra code 1033 after a valid, authentic image, that third party can then use their 1034 own code in order to make better use of an existing vulnerability. 1036 Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) 1038 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 1040 Classification: All Types 1042 If a third party obtains a key or even indirect access to a key, for 1043 example in an HSM, then they can perform the same actions as the 1044 legitimate owner of the key. If the key is trusted for firmware 1045 update, then the third party can perform firmware updates as though 1046 they were the legitimate owner of the key. 1048 For example, if manifest signing is performed on a server connected 1049 to the internet, an attacker may compromise the server and then be 1050 able to sign manifests, even if the keys for manifest signing are 1051 held in an HSM that is accessed by the server. 1053 Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17) 1055 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 1056 prior to signing 1058 Classification: All Types 1060 If an attacker can alter a manifest or payload before it is signed, 1061 they can perform all the same actions as the manifest author. This 1062 allows the attacker to deploy firmware updates to any devices that 1063 trust the manifest author. If an attacker can modify the code of a 1064 payload before the corresponding manifest is created, they can insert 1065 their own code. If an attacker can modify the manifest before it is 1066 signed, they can redirect the manifest to their own payload. 1068 For example, the attacker deploys malware to the developer's computer 1069 or signing service that watches manifest creation activities and 1070 inserts code into any binary that is referenced by a manifest. 1072 For example, the attacker deploys malware to the developer's computer 1073 or signing service that replaces the referenced binary (digest) and 1074 URI with the attacker's binary (digest) and URI. 1076 Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18), 1077 REQ.SEC.MFST.TRUSTED (Section 4.3.19) 1079 4.3. Security Requirements 1081 The security requirements here are a set of policies that mitigate 1082 the threats described in Section 4.1. 1084 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 1086 Only an actor with firmware installation authority is permitted to 1087 decide when device firmware can be installed. To enforce this rule, 1088 manifests MUST contain monotonically increasing sequence numbers. 1089 Manifests MAY use UTC epoch timestamps to coordinate monotonically 1090 increasing sequence numbers across many actors in many locations. If 1091 UTC epoch timestamps are used, they MUST NOT be treated as times, 1092 they MUST be treated only as sequence numbers. Devices MUST reject 1093 manifests with sequence numbers smaller than any onboard sequence 1094 number. 1096 Note: This is not a firmware version. It is a manifest sequence 1097 number. A firmware version may be rolled back by creating a new 1098 manifest for the old firmware version with a later sequence number. 1100 Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) 1102 Implemented by: Monotonic Sequence Number (Section 3.2) 1104 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 1106 Devices MUST only apply firmware that is intended for them. Devices 1107 MUST know with fine granularity that a given update applies to their 1108 vendor, model, hardware revision, software revision. Human-readable 1109 identifiers are often error-prone in this regard, so unique 1110 identifiers SHOULD be used. 1112 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1114 Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition 1115 (Section 3.4) 1117 4.3.3. REQ.SEC.EXP: Expiration Time 1119 Firmware MAY expire after a given time. Devices MAY provide a secure 1120 clock (local or remote). If a secure clock is provided and the 1121 Firmware manifest has an expiration timestamp, the device MUST reject 1122 the manifest if current time is later than the expiration time. 1124 Mitigates: THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2) 1126 Implemented by: Expiration Time (Section 3.7) 1128 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 1130 The authenticity of an update MUST be demonstrable. Typically, this 1131 means that updates must be digitally authenticated. Because the 1132 manifest contains information about how to install the update, the 1133 manifest's authenticity MUST also be demonstrable. To reduce the 1134 overhead required for validation, the manifest contains the digest of 1135 the firmware image, rather than a second digital signature. The 1136 authenticity of the manifest can be verified with a digital signature 1137 or Message Authentication Code. The authenticity of the firmware 1138 image is tied to the manifest by the use of a digest of the firmware 1139 image. 1141 Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.MITM 1142 (Section 4.2.7) 1144 Implemented by: Signature (Section 3.15), Payload Digest 1145 (Section 3.13) 1147 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 1149 The type of payload (which may be independent of format) MUST be 1150 authenticated. For example, the target must know whether the payload 1151 is XIP firmware, a loadable module, or serialized configuration data. 1153 Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) 1155 Implemented by: Payload Format (Section 3.8), Storage Location 1156 (Section 3.10) 1158 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 1159 Location 1161 The location on the target where the payload is to be stored MUST be 1162 authenticated. 1164 Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) 1166 Implemented by: Storage Location (Section 3.10) 1168 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location 1170 The location where a target should find a payload MUST be 1171 authenticated. 1173 Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.MITM 1174 (Section 4.2.7) 1176 Implemented by: Resource Indicator (Section 3.12) 1178 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 1180 The target SHOULD verify firmware at time of boot. This requires 1181 authenticated payload size, and digest. 1183 Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) 1185 Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) 1187 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 1189 If an update uses a differential compression method, it MUST specify 1190 the digest of the precursor image and that digest MUST be 1191 authenticated. 1193 Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10) 1195 Implemented by: Precursor Image Digest (Section 3.5) 1197 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs 1199 The identifiers that specify firmware compatibility MUST be 1200 authenticated to ensure that only compatible firmware is installed on 1201 a target device. 1203 Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) 1205 Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition 1206 (Section 3.4) 1208 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 1210 If a device grants different rights to different actors, exercising 1211 those rights MUST be accompanied by proof of those rights, in the 1212 form of proof of authenticity. Authenticity mechanisms such as those 1213 required in REQ.SEC.AUTHENTIC (Section 4.3.4) can be used to prove 1214 authenticity. 1216 For example, if a device has a policy that requires that firmware 1217 have both an Authorship right and a Qualification right and if that 1218 device grants Authorship and Qualification rights to different 1219 parties, such as a Device Operator and a Network Operator, 1220 respectively, then the firmware cannot be installed without proof of 1221 rights from both the Device Operator and the Network Operator. 1223 Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11) 1225 Implemented by: Signature (Section 3.15) 1227 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 1229 The manifest information model MUST enable encrypted payloads. 1230 Encryption helps to prevent third parties, including attackers, from 1231 reading the content of the firmware image. This can protect against 1232 confidential information disclosures and discovery of vulnerabilities 1233 through reverse engineering. Therefore the manifest must convey the 1234 information required to allow an intended recipient to decrypt an 1235 encrypted payload. 1237 Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.MITM 1238 (Section 4.2.7) 1240 Implemented by: Encryption Wrapper (Section 3.19) 1242 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 1244 If a device grants different rights to different actors, then an 1245 exercise of those rights MUST be validated against a list of rights 1246 for the actor. This typically takes the form of an Access Control 1247 List (ACL). ACLs are applied to two scenarios: 1249 1. An ACL decides which elements of the manifest may be overridden 1250 and by which actors. 1252 2. An ACL decides which component identifier/storage identifier 1253 pairs can be written by which actors. 1255 Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), 1256 THREAT.UPD.UNAPPROVED (Section 4.2.11) 1258 Implemented by: Client-side code, not specified in manifest. 1260 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 1262 It MUST be possible to encrypt part or all of the manifest. This may 1263 be accomplished with either transport encryption or with at-rest 1264 encryption. 1266 Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.MITM 1267 (Section 4.2.7) 1269 Implemented by: External Encryption Wrapper / Transport Security 1271 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 1273 The digest SHOULD cover all available space in a fixed-size storage 1274 location. Variable-size storage locations MUST be restricted to 1275 exactly the size of deployed payload. This prevents any data from 1276 being distributed without being covered by the digest. For example, 1277 XIP microcontrollers typically have fixed-size storage. These 1278 devices should deploy a digest that covers the deployed firmware 1279 image, concatenated with the default erased value of any remaining 1280 space. 1282 Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) 1284 Implemented by: Payload Digests (Section 3.13) 1286 4.3.16. REQ.SEC.REPORTING: Secure Reporting 1288 Status reports from the device to any remote system SHOULD be 1289 performed over an authenticated, confidential channel in order to 1290 prevent modification or spoofing of the reports. 1292 Mitigates: THREAT.NET.MITM (Section 4.2.7) 1294 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 1296 Cryptographic keys for signing manifests SHOULD be stored in a manner 1297 that is inaccessible to networked devices, for example in an HSM, or 1298 an air-gapped computer. This protects against an attacker obtaining 1299 the keys. 1301 Keys SHOULD be stored in a way that limits the risk of a legitimate, 1302 but compromised, entity (such as a server or developer computer) 1303 issuing signing requests. 1305 Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) 1307 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment 1309 Manifests SHOULD be parsed and examined prior to deployment to 1310 validate that their contents have not been modified during creation 1311 and signing. 1313 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1315 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted 1316 environment 1318 For high risk deployments, such as large numbers of devices or 1319 critical function devices, manifests SHOULD be constructed in an 1320 environment that is protected from interference, such as an air- 1321 gapped computer. Note that a networked computer connected to an HSM 1322 does not fulfill this requirement (see THREAT.MFST.MODIFICATION 1323 (Section 4.2.17)). 1325 Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) 1327 4.4. User Stories 1329 User stories provide expected use cases. These are used to feed into 1330 usability requirements. 1332 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 1334 As a Device Operator, I want to provide my devices with additional 1335 installation instructions so that I can keep process details out of 1336 my payload data. 1338 Some installation instructions might be: 1340 o Use a table of hashes to ensure that each block of the payload is 1341 validate before writing. 1343 o Do not report progress. 1345 o Pre-cache the update, but do not install. 1347 o Install the pre-cached update matching this manifest. 1349 o Install this update immediately, overriding any long-running 1350 tasks. 1352 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1354 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 1356 As a designer of a resource-constrained IoT device, I want bad 1357 updates to fail as early as possible to preserve battery life and 1358 limit consumed bandwidth. 1360 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1362 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 1364 As a Device Operator, I would like to be able to override the non- 1365 critical information in the manifest so that I can control my devices 1366 more precisely. The authority to override this information is 1367 provided via the installation of a limited trust anchor by another 1368 authority. 1370 Some examples of potentially overridable information: 1372 o URIs (Section 3.12): this allows the Device Operator to direct 1373 devices to their own infrastructure in order to reduce network 1374 load. 1376 o Conditions: this allows the Device Operator to pose additional 1377 constraints on the installation of the manifest. 1379 o Directives (Section 3.16): this allows the Device Operator to add 1380 more instructions such as time of installation. 1382 o Processing Steps (Section 3.9): If an intermediary performs an 1383 action on behalf of a device, it may need to override the 1384 processing steps. It is still possible for a device to verify the 1385 final content and the result of any processing step that specifies 1386 a digest. Some processing steps should be non-overridable. 1388 Satisfied by: USER_STORY.OVERRIDE (Section 4.4.3), 1389 REQ.USE.MFST.COMPONENT (Section 4.5.3) 1391 4.4.4. USER_STORY.COMPONENT: Component Update 1393 As a Device Operator, I want to divide my firmware into components, 1394 so that I can reduce the size of updates, make different parties 1395 responsible for different components, and divide my firmware into 1396 frequently updated and infrequently updated components. 1398 Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) 1400 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations 1402 As a Device Operator, I want to ensure the quality of a firmware 1403 update before installing it, so that I can ensure interoperability of 1404 all devices in my product family. I want to restrict the ability to 1405 make changes to my devices to require my express approval. 1407 Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), 1408 REQ.SEC.ACCESS_CONTROL (Section 4.3.13) 1410 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 1412 As a Device Operator, I want to be able to send multiple payload 1413 formats to suit the needs of my update, so that I can optimise the 1414 bandwidth used by my devices. 1416 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) 1418 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 1419 Disclosures 1421 As a firmware author, I want to prevent confidential information from 1422 being disclosed during firmware updates. It is assumed that channel 1423 security or at-rest encryption is adequate to protect the manifest 1424 itself against information disclosure. 1426 Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) 1428 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 1429 Unknown Formats 1431 As a Device Operator, I want devices to determine whether they can 1432 process a payload prior to downloading it. 1434 In some cases, it may be desirable for a third party to perform some 1435 processing on behalf of a target. For this to occur, the third party 1436 MUST indicate what processing occurred and how to verify it against 1437 the Trust Provisioning Authority's intent. 1439 This amounts to overriding Processing Steps (Section 3.9) and 1440 Resource Indicator (Section 3.12). 1442 Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED 1443 (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) 1445 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 1446 Target Firmware 1448 As a Device Operator, I want to be able to target devices for updates 1449 based on their current firmware version, so that I can control which 1450 versions are replaced with a single manifest. 1452 Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7) 1454 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 1456 As a developer, I want to be able to sign two or more versions of my 1457 firmware in a single manifest so that I can use a very simple 1458 bootloader that chooses between two or more images that are executed 1459 in-place. 1461 Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8) 1463 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 1465 As a signer for both secure execution/boot and firmware deployment, I 1466 would like to use the same signed document for both tasks so that my 1467 data size is smaller, I can share common code, and I can reduce 1468 signature verifications. 1470 Satisfied by: REQ.USE.EXEC (Section 4.5.9) 1472 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 1474 As a developer of firmware for a run-from-RAM device, I would like to 1475 use compressed images and to indicate to the bootloader that I am 1476 using a compressed image in the manifest so that it can be used with 1477 secure execution/boot. 1479 Satisfied by: REQ.USE.LOAD (Section 4.5.10) 1481 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 1483 As an operator of devices on a constrained network, I would like the 1484 manifest to be able to include a small payload in the same packet so 1485 that I can reduce network traffic. 1487 Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) 1489 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 1491 As a developer for constrained devices, I want a low complexity 1492 library for processing updates so that I can fit more application 1493 code on my device. 1495 Satisfied by: REQ.USE.PARSE (Section 4.5.12) 1497 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 1499 As a Device Operator that rotates delegated authority more often than 1500 delivering firmware updates, I would like to delegate a new authority 1501 when I deliver a firmware update so that I can accomplish both tasks 1502 in a single transmission. 1504 Satisfied by: REQ.USE.DELEGATION (Section 4.5.13) 1506 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 1508 As an operator of a constrained network, I would like devices on my 1509 network to be able to evaluate the suitability of an update prior to 1510 initiating any large download so that I can prevent unnecessary 1511 consumption of bandwidth. 1513 Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) 1515 4.5. Usability Requirements 1517 The following usability requirements satisfy the user stories listed 1518 above. 1520 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 1522 It MUST be possible for a manifest author to place ALL information 1523 required to process an update in the manifest. 1525 For example: Information about which precursor image is required for 1526 a differential update MUST be placed in the manifest, not in the 1527 differential compression header. 1529 Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), 1530 USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) 1532 Implemented by: Additional installation instructions (Section 3.16) 1534 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 1536 It MUST be possible to redirect payload fetches. This applies where 1537 two manifests are used in conjunction. For example, a Device 1538 Operator creates a manifest specifying a payload and signs it, and 1539 provides a URI for that payload. A Network Operator creates a second 1540 manifest, with a dependency on the first. They use this second 1541 manifest to override the URIs provided by the Device Operator, 1542 directing them into their own infrastructure instead. Some devices 1543 may provide this capability, while others may only look at canonical 1544 sources of firmware. For this to be possible, the device must fetch 1545 the payload, whereas a device that accepts payload pushes will ignore 1546 this feature. 1548 N.B. If a manifest is delivered over an authenticated channel and 1549 that manifest contains only override information for which the remote 1550 is authorised, then it can be considered authenticated by the channel 1551 authentication. 1553 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) 1555 Implemented by: Aliases (Section 3.17) 1557 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 1559 It MUST be possible express the requirement to install one or more 1560 payloads from one or more authorities so that a multi-payload update 1561 can be described. This allows multiple parties with different 1562 permissions to collaborate in creating a single update for the IoT 1563 device, across multiple components. 1565 This requirement effectively means that it must be possible to 1566 construct a tree of manifests on a multi-image target. 1568 In order to enable devices with a heterogeneous storage architecture, 1569 the manifest must enable specification of both storage system and the 1570 storage location within that storage system. 1572 Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT 1573 (Section 4.4.4) 1575 Implemented by Manifest Element: Dependencies, StorageIdentifier, 1576 ComponentIdentifier 1578 4.5.3.1. Example 1: Multiple Microcontrollers 1580 An IoT device with multiple microcontrollers in the same physical 1581 device (HeSA) will likely require multiple payloads with different 1582 component identifiers. 1584 4.5.3.2. Example 2: Code and Configuration 1586 A firmware image can be divided into two payloads: code and 1587 configuration. These payloads may require authorizations from 1588 different actors in order to install (see REQ.SEC.RIGHTS 1589 (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This 1590 structure means that multiple manifests may be required, with a 1591 dependency structure between them. 1593 4.5.3.3. Example 3: Multiple Software Modules 1595 A firmware image can be divided into multiple functional blocks for 1596 separate testing and distribution. This means that code would need 1597 to be distributed in multiple payloads. For example, this might be 1598 desirable in order to ensure that common code between devices is 1599 identical in order to reduce distribution bandwidth. 1601 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 1603 It MUST be possible to authenticate a manifest multiple times so that 1604 authorisations from multiple parties with different permissions can 1605 be required in order to authorise installation of a manifest. 1607 Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) 1609 Implemented by: Signature (Section 3.15) 1611 4.5.5. REQ.USE.IMG.FORMAT: Format Usability 1613 The manifest serialisation MUST accommodate any payload format that 1614 an Operator wishes to use. This enables the recipient to detect 1615 which format the Operator has chosen. Some examples of payload 1616 format are: 1618 o Binary 1620 o Elf 1622 o Differential 1624 o Compressed 1626 o Packed configuration 1628 o Intel HEX 1630 o S-Record 1632 Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) 1633 USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) 1635 Implemented by: Payload Format (Section 3.8) 1637 4.5.6. REQ.USE.IMG.NESTED: Nested Formats 1639 The manifest serialisation MUST accommodate nested formats, 1640 announcing to the target device all the nesting steps and any 1641 parameters used by those steps. 1643 Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) 1645 Implemented by: Processing Steps (Section 3.9) 1647 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 1649 The manifest serialisation MUST provide a method to specify multiple 1650 version numbers of firmware to which the manifest applies, either 1651 with a list or with range matching. 1653 Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) 1655 Implemented by: Required Image Version List (Section 3.6) 1657 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 1659 The manifest serialisation MUST provide a mechanism to list multiple 1660 equivalent payloads by Execute-In-Place Installation Address, 1661 including the payload digest and, optionally, payload URIs. 1663 Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) 1665 Implemented by: XIP Address (Section 3.20) 1667 4.5.9. REQ.USE.EXEC: Executable Manifest 1669 It MUST be possible to describe an executable system with a manifest 1670 on both Execute-In-Place microcontrollers and on complex operating 1671 systems. This requires the manifest to specify the digest of each 1672 statically linked dependency. In addition, the manifest 1673 serialisation MUST be able to express metadata, such as a kernel 1674 command-line, used by any loader or bootloader. 1676 Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) 1678 Implemented by: Run-time metadata (Section 3.22) 1680 4.5.10. REQ.USE.LOAD: Load-Time Information 1682 It MUST be possible to specify additional metadata for load time 1683 processing of a payload, such as cryptographic information, load- 1684 address, and compression algorithm. 1686 N.B. load comes before exec/boot. 1688 Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) 1690 Implemented by: Load-time metadata (Section 3.21) 1692 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure 1694 It MUST be possible to place a payload in the same structure as the 1695 manifest. This MAY place the payload in the same packet as the 1696 manifest. 1698 Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) 1700 Implemented by: Payload (Section 3.23) 1702 4.5.12. REQ.USE.PARSE: Simple Parsing 1704 The structure of the manifest MUST be simple to parse, without need 1705 for a general-purpose parser. 1707 Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) 1709 Implemented by: N/A 1711 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 1713 Any serialisation MUST enable the delivery of a key claim with, but 1714 not authenticated by, a manifest. This key claim delivers a new key 1715 with which the recipient can verify the manifest. 1717 Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) 1719 Implemented by: Key Claims (Section 3.24) 1721 5. IANA Considerations 1723 This document does not require any actions by IANA. 1725 6. Acknowledgements 1727 We would like to thank our working group chairs, Dave Thaler, Russ 1728 Housley and David Waltermire, for their review comments and their 1729 support. 1731 We would like to thank the participants of the 2018 Berlin SUIT 1732 Hackathon and the June 2018 virtual design team meetings for their 1733 discussion input. In particular, we would like to thank Koen 1734 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1735 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1736 Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias 1737 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1738 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1739 Gharout, and Milen Stoychev. 1741 We would like to thank those who contributed to the development of 1742 this information model. In particular, we would like to thank 1743 Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary 1744 Thomson. 1746 7. References 1748 7.1. Normative References 1750 [I-D.ietf-suit-architecture] 1751 Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A 1752 Firmware Update Architecture for Internet of Things 1753 Devices", draft-ietf-suit-architecture-07 (work in 1754 progress), October 2019. 1756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1757 Requirement Levels", BCP 14, RFC 2119, 1758 DOI 10.17487/RFC2119, March 1997, 1759 . 1761 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1762 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1763 DOI 10.17487/RFC4122, July 2005, 1764 . 1766 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1767 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1768 May 2017, . 1770 7.2. Informative References 1772 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1773 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1774 . 1776 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1777 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1778 . 1780 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1781 . 1784 7.3. URIs 1786 [1] mailto:suit@ietf.org 1788 [2] https://www1.ietf.org/mailman/listinfo/suit 1790 [3] https://www.ietf.org/mail-archive/web/suit/current/index.html 1792 Appendix A. Mailing List Information 1794 The discussion list for this document is located at the e-mail 1795 address suit@ietf.org [1]. Information on the group and information 1796 on how to subscribe to the list is at 1797 https://www1.ietf.org/mailman/listinfo/suit [2] 1799 Archives of the list can be found at: https://www.ietf.org/mail- 1800 archive/web/suit/current/index.html [3] 1802 Authors' Addresses 1804 Brendan Moran 1805 Arm Limited 1807 EMail: Brendan.Moran@arm.com 1809 Hannes Tschofenig 1810 Arm Limited 1812 EMail: hannes.tschofenig@gmx.net 1814 Henk Birkholz 1815 Fraunhofer SIT 1817 EMail: henk.birkholz@sit.fraunhofer.de