idnits 2.17.00 (12 Aug 2021) /tmp/idnits40204/draft-ietf-suit-firmware-encryption-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (20 April 2022) is 24 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) == Outdated reference: A later version (-17) exists of draft-ietf-suit-manifest-16 ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Downref: Normative reference to an Informational RFC: RFC 9180 -- Obsolete informational reference (is this intentional?): RFC 2630 (Obsoleted by RFC 3369, RFC 3370) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT H. Tschofenig 3 Internet-Draft Arm Limited 4 Intended status: Standards Track R. Housley 5 Expires: 22 October 2022 Vigil Security 6 B. Moran 7 Arm Limited 8 20 April 2022 10 Firmware Encryption with SUIT Manifests 11 draft-ietf-suit-firmware-encryption-04 13 Abstract 15 This document specifies a firmware update mechanism where the 16 firmware image is encrypted. Firmware encryption uses the IETF SUIT 17 manifest with key establishment provided by the hybrid public-key 18 encryption (HPKE) scheme and the AES Key Wrap (AES-KW) with a pre- 19 shared key-encryption key. Encryption of the firmware image is 20 accomplished using the established content encryption key and a 21 mutually agreed symmetric encryption algorithm, such as AES-GCM or 22 AES-CCM. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 22 October 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 71 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. SUIT Envelope and SUIT Manifest . . . . . . . . . . . . . . . 6 73 5. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6. Hybrid Public-Key Encryption (HPKE) . . . . . . . . . . . . . 11 75 7. CEK Verification . . . . . . . . . . . . . . . . . . . . . . 13 76 8. Complete Examples . . . . . . . . . . . . . . . . . . . . . . 13 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 11.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 Vulnerabilities with Internet of Things (IoT) devices have raised the 88 need for a reliable and secure firmware update mechanism that is also 89 suitable for constrained devices. To protect firmware images the 90 SUIT manifest format was developed [I-D.ietf-suit-manifest]. The 91 SUIT manifest provides a bundle of metadata about the firmware for an 92 IoT device, where to find the firmware image, and the devices to 93 which it applies. 95 The SUIT information model [RFC9124] details the information that has 96 to be offered by the SUIT manifest format. In addition to offering 97 protection against modification, which is provided by a digital 98 signature or a message authentication code, the firmware image may 99 also be afforded confidentiality using encryption. 101 Encryption prevents third parties, including attackers, from gaining 102 access to the firmware binary. Hackers typically need intimate 103 knowledge of the target firmware to mount their attacks. For 104 example, return-oriented programming (ROP) requires access to the 105 binary and encryption makes it much more difficult to write exploits. 107 The SUIT manifest provides the data needed for authorized recipients 108 of the firmware image to decrypt it. The firmware image is encrypted 109 using a symmetric key. This symmetric cryptographic key is 110 established for encryption and decryption, and that key can be 111 applied to a SUIT manifest, firmware images, or personalization data, 112 depending on the encryption choices of the firmware author. 114 A symmetric key can be established using a variety of mechanisms; 115 this document defines two approaches for use with the IETF SUIT 116 manifest, namely: 118 * hybrid public-key encryption (HPKE), and 120 * AES Key Wrap (AES-KW) using a pre-shared key-encryption key (KEK). 122 These choices reduce the number of possible key establishment options 123 and thereby help increase interoperability between different SUIT 124 manifest parser implementations. 126 The document also contains a number of examples. 128 2. Conventions and Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 This document assumes familiarity with the IETF SUIT manifest 137 [I-D.ietf-suit-manifest], the SUIT information model [RFC9124] and 138 the SUIT architecture [RFC9019]. 140 The terms sender and recipient are defined in [RFC9180] and have the 141 following meaning: 143 * Sender: Role of entity which sends an encrypted message. 145 * Recipient: Role of entity which receives an encrypted message. 147 Additionally, the following abbreviations are used in this document: 149 * Key Wrap (KW), defined in RFC 3394 [RFC3394] for use with AES. 151 * Key-encryption key (KEK), a term defined in RFC 4949 [RFC4949]. 153 * Content-encryption key (CEK), a term defined in RFC 2630 154 [RFC2630]. 156 * Hybrid Public Key Encryption (HPKE), defined in [RFC9180]. 158 The main use case of this document is to encrypt firmware. However, 159 SUIT manifests may require other payloads than firmware images to 160 experience confidentiality protection using encryption. While the 161 term firmware is used throughout the document, plaintext other than 162 firmware images may get encrypted using the described mechanism. 163 Hence, the terms firmware (image) and plaintext are used 164 interchangably. 166 3. Architecture 168 [RFC9019] describes the architecture for distributing firmware images 169 and manifests from the author to the firmware consumer. It does, 170 however, not detail the use of encrypted firmware images. 172 This document enhances the SUIT architecutre to include firmware 173 encryption. Figure 1 shows the distribution system, which represents 174 the firmware server and the device management infrastructure. The 175 distribution system is aware of the individual devices to which a 176 firmware update has to be delivered. 178 +----------+ 179 | | 180 | Author | 181 | | 182 +----------+ +----------+ 183 | Device |---+ | 184 |(Firmware | | | Firmware + 185 | Consumer)| | | Manifest 186 +----------+ | | 187 | | 188 | +--------------+ 189 | | | 190 +----------+ | Firmware + Manifest | Distribution | 191 | Device |---+------------------------| System | 192 |(Firmware | | | | 193 | Consumer)| | | | 194 +----------+ | +--------------+ 195 | 196 | 197 +----------+ | 198 | Device +---+ 199 |(Firmware | 200 | Consumer)| 201 +----------+ 203 Figure 1: Firmware Encryption Architecture. 205 Firmware encryption requires the sender to know the firmware 206 consumers and the respective credentials used by the key distribution 207 mechanism. For AES-KW the KEK needs to be known and, in case of 208 HPKE, the sender needs to be in possession of the public key of the 209 recipient. 211 The firmware author may have knowledge about all devices that need to 212 receive an encrypted firmware image but in most cases this will not 213 be likely. The distribution system certainly has the knowledge about 214 the recipients to perform firmware encryption. 216 To offer confidentiality protection for firmware images two 217 deployment variants need to be supported: 219 * The firmware author acts as the sender and the recipient is the 220 firmware consumer (or the firmware consumers). 222 * The firmware author encrypts the firmware image with the 223 distribution system as the initial recipient. Then, the 224 distribution system decrypts and re-encrypts the firmware image 225 towards the firmware consumer(s). Delegating the task of re- 226 encrypting the firmware image to the distribution system offers 227 flexiblity when the number of devices that need to receive 228 encrypted firmware images changes dynamically or when updates to 229 KEKs or recipient public keys are necessary. As a downside, the 230 author needs to trust the distribution system with performing the 231 re-encryption of the firmware image. 233 Irrespectively of the two variants, the key distribution data (in 234 form of the COSE_Encrypt structure) is included in the SUIT envelope 235 rather than in the SUIT manifest since the manifest will be digitally 236 signed (or MACed) by the firmware author. 238 Since the SUIT envelope is not protected cryptographically an 239 adversary could modify the COSE_Encrypt structure. For example, if 240 the attacker alters the key distribution data then a recipient will 241 decrypt the firmware image with an incorrect key. This will lead to 242 expending energy and flash cycles until the failure is detected. To 243 mitigate this attack, the optional suit-cek-verification parameter is 244 added to the manifest. Since the manifest is protected by a digital 245 signature (or a MAC), an adversary cannot successfully modify this 246 value. This parameter allows the recipient to verify whether the CEK 247 has successfully been derived. 249 Details about the changes to the envelope and the manifest can be 250 found in the next section. 252 4. SUIT Envelope and SUIT Manifest 254 This specification introduces two extensions to the SUIT envelope and 255 the manifest structure, as motivated in Section 3. 257 The SUIT envelope is enhanced with a key exchange payload, which is 258 carried inside the suit-protection-wrappers parameter, see Figure 2. 259 One or multiple SUIT_Encryption_Info payload(s) are carried within 260 the suit-protection-wrappers parameter. The content of the 261 SUIT_Encryption_Info payload is explained in Section 5 (for AES-KW) 262 and in Section 6 (for HPKE). When the encryption capability is used, 263 the suit-protection-wrappers parameter MUST be included in the 264 envelope. 266 SUIT_Envelope_Tagged = #6.107(SUIT_Envelope) 267 SUIT_Envelope = { 268 suit-authentication-wrapper => bstr .cbor SUIT_Authentication, 269 suit-manifest => bstr .cbor SUIT_Manifest, 270 SUIT_Severable_Manifest_Members, 271 suit-protection-wrappers => bstr .cbor { 272 *(int/str) => [+ SUIT_Encryption_Info] 273 } 274 * SUIT_Integrated_Payload, 275 * SUIT_Integrated_Dependency, 276 * $$SUIT_Envelope_Extensions, 277 * (int => bstr) 278 } 280 Figure 2: SUIT Envelope CDDL. 282 The manifest is extended with a CEK verification parameter (called 283 suit-cek-verification), see Figure 3. This parameter is optional and 284 is utilized in environments where battery exhaustion attacks are a 285 concern. Details about the CEK verification can be found in 286 Section 7. 288 SUIT_Manifest = { 289 suit-manifest-version => 1, 290 suit-manifest-sequence-number => uint, 291 suit-common => bstr .cbor SUIT_Common, 292 ? suit-reference-uri => tstr, 293 ? suit-cek-verification => bstr, 294 SUIT_Severable_Members_Choice, 295 SUIT_Unseverable_Members, 296 * $$SUIT_Manifest_Extensions, 297 } 299 Figure 3: SUIT Manifest CDDL. 301 5. AES Key Wrap 303 The AES Key Wrap (AES-KW) algorithm is described in RFC 3394 304 [RFC3394], and it can be used to encrypt a randomly generated 305 content-encryption key (CEK) with a pre-shared key-encryption key 306 (KEK). The COSE conventions for using AES-KW are specified in 307 Section 12.2.1 of [RFC8152]. The encrypted CEK is carried in the 308 COSE_recipient structure alongside the information needed for AES-KW. 309 The COSE_recipient structure, which is a substructure of the 310 COSE_Encrypt structure, contains the CEK encrypted by the KEK. 312 When the firmware image is encrypted for use by multiple recipients, 313 there are three options. We use the following notation KEK(R1,S) is 314 the KEK shared between recipient R1 and the sender S. Likewise, 315 CEK(R1,S) is shared between R1 and S. If a single CEK or a single 316 KEK is shared with all authorized recipients R by a given sender S in 317 a certain context then we use CEK(_,S) or KEK(_,S), respectively. 318 The notation ENC(plaintext, key) refers to the encryption of 319 plaintext with a given key. 321 * If all authorized recipients have access to the KEK, a single 322 COSE_recipient structure contains the encrypted CEK. This means 323 KEK(*,S) ENC(CEK,KEK), and ENC(firmware,CEK). 325 * If recipients have different KEKs, then multiple COSE_recipient 326 structures are included but only a single CEK is used. Each 327 COSE_recipient structure contains the CEK encrypted with the KEKs 328 appropriate for the recipient. In short, KEK_1(R1, S),..., 329 KEK_n(Rn, S), ENC(CEK, KEK_i) for i=1 to n, and ENC(firmware,CEK). 330 The benefit of this approach is that the firmware image is 331 encrypted only once with a CEK while there is no sharing of the 332 KEK accross recipients. Hence, authorized recipients still use 333 their individual KEKs to decrypt the CEK and to subsequently 334 obtain the plaintext firmware. 336 * The third option is to use different CEKs encrypted with KEKs of 337 the authorized recipients. Assume there are KEK_1(R1, S),..., 338 KEK_n(Rn, S), and for i=1 to n the following computations need to 339 be made: ENC(CEK_i, KEK_i) and ENC(firmware,CEK_i). This approach 340 is appropriate when no benefits can be gained from encrypting and 341 transmitting firmware images only once. For example, firmware 342 images may contain information unique to a device instance. 344 Note that the AES-KW algorithm, as defined in Section 2.2.3.1 of 345 [RFC3394], does not have public parameters that vary on a per- 346 invocation basis. Hence, the protected structure in the 347 COSE_recipient is a byte string of zero length. 349 The COSE_Encrypt conveys information for encrypting the firmware 350 image, which includes information like the algorithm and the IV, even 351 though the firmware image is not embedded in the 352 COSE_Encrypt.ciphertext itself since it conveyed as detached content. 354 The CDDL for the COSE_Encrypt_Tagged structure is shown in Figure 4. 356 COSE_Encrypt_Tagged = #6.96(COSE_Encrypt) 358 SUIT_Encryption_Info = COSE_Encrypt_Tagged 360 COSE_Encrypt = [ 361 protected : bstr .cbor outer_header_map_protected, 362 unprotected : outer_header_map_unprotected, 363 ciphertext : null, ; because of detached ciphertext 364 recipients : [ + COSE_recipient ] 365 ] 367 outer_header_map_protected = 368 { 369 1 => int, ; algorithm identifier 370 * label =values ; extension point 371 } 373 outer_header_map_unprotected = 374 { 375 5 => bstr, ; IV 376 * label =values ; extension point 377 } 379 COSE_recipient = [ 380 protected : bstr .size 0, 381 unprotected : recipient_header_map, 382 ciphertext : bstr ; CEK encrypted with KEK 383 ] 385 recipient_header_map = 386 { 387 1 => int, ; algorithm identifier 388 4 => bstr, ; key identifier 389 * label =values ; extension point 390 } 392 Figure 4: CDDL for AES Key Wrap Encryption 394 The COSE specification requires a consistent byte stream for the 395 authenticated data structure to be created, which is shown in 396 Figure 5. 398 Enc_structure = [ 399 context : "Encrypt", 400 protected : empty_or_serialized_map, 401 external_aad : bstr 402 ] 403 Figure 5: CDDL for Enc_structure Data Structure 405 As shown in Figure 4, there are two protected fields: one protected 406 field in the COSE_Encrypt structure and a second one in the 407 COSE_recipient structure. The 'protected' field in the 408 Enc_structure, see Figure 5, refers to the content of the protected 409 field from the COSE_Encrypt structure. 411 The value of the external_aad MUST be set to null. 413 The following example illustrates the use of the AES-KW algorithm 414 with AES-128. 416 We use the following parameters in this example: 418 * IV: 0x26, 0x68, 0x23, 0x06, 0xd4, 0xfb, 0x28, 0xca, 0x01, 0xb4, 419 0x3b, 0x80 421 * KEK: "aaaaaaaaaaaaaaaa" 423 * KID: "kid-1" 425 * Plaintext Firmware: "This is a real firmware image." 427 * Firmware (hex): 428 546869732069732061207265616C206669726D7761726520696D6167652E 430 The COSE_Encrypt structure, in hex format, is (with a line break 431 inserted): 433 D8608443A10101A1054C26682306D4FB28CA01B43B80F68340A2012204456B69642D 434 315818AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D 436 The resulting COSE_Encrypt structure in a dignostic format is shown 437 in Figure 6. 439 96( 440 [ 441 / protected field with alg=AES-GCM-128 / 442 h'A10101', 443 { 444 / unprotected field with iv / 445 5: h'26682306D4FB28CA01B43B80' 446 }, 447 / null because of detached ciphertext / 448 null, 449 [ / recipients array / 450 h'', / protected field / 451 { / unprotected field / 452 1: -3, / alg=A128KW / 453 4: h'6B69642D31' / key id / 454 }, 455 / CEK encrypted with KEK / 456 h'AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D' 457 ] 458 ] 459 ) 461 Figure 6: COSE_Encrypt Example for AES Key Wrap 463 The CEK, in hex format, was "4C805F1587D624ED5E0DBB7A7F7FA7EB" and 464 the encrypted firmware (with a line feed added) was: 466 A8B6E61EF17FBAD1F1BF3235B3C64C06098EA512223260 467 F9425105F67F0FB6C92248AE289A025258F06C2AD70415 469 6. Hybrid Public-Key Encryption (HPKE) 471 Hybrid public-key encryption (HPKE) [RFC9180] is a scheme that 472 provides public key encryption of arbitrary-sized plaintexts given a 473 recipient's public key. 475 For use with firmware encryption the scheme works as follows: HPKE, 476 which internally utilizes a non-interactive ephemeral-static Diffie- 477 Hellman exchange to derive a shared secret, is used to encrypt a CEK. 478 This CEK is subsequently used to encrypt the firmware image. Hence, 479 the plaintext passed to HPKE is the randomly generated CEK. The 480 output of the HPKE SealBase function is therefore the encrypted CEK 481 along with HPKE encapsulated key (i.e. the ephemeral ECDH public 482 key). 484 Only the holder of recipient's private key can decapsulate the CEK to 485 decrypt the firmware. Key generation in HPKE is influced by 486 additional parameters, such as identity information. 488 This approach allows all recipients to use the same CEK to encrypt 489 the firmware image, in case there are multiple recipients, to fulfill 490 a requirement for the efficient distribution of firmware images using 491 a multicast or broadcast protocol. 493 [I-D.ietf-cose-hpke] defines the use of HPKE with COSE. 495 An example of the COSE_Encrypt structure using the HPKE scheme is 496 shown in Figure 7. It uses the following algorithm combination: 498 * AES-GCM-128 for encryption of the (detached) firmware image. 500 * AES-GCM-128 for encryption of the CEK as well as ECDH with NIST 501 P-256 and HKDF-SHA256 as a Key Encapsulation Mechanism (KEM). 503 96_0([ 504 / protected header with alg=AES-GCM-128 / 505 h'a10101', 506 / unprotected header with nonce / 507 {5: h'938b528516193cc7123ff037809f4c2a'}, 508 / detached ciphertext / 509 null, 510 / recipient structure / 511 [ 512 / protected field with alg for HPKE / 513 h'a1013863', 514 / unprotected header / 515 { 516 / ephemeral public key with x / y coodinate / 517 -1: h'a401022001215820a596f2ca8d159c04942308ca90 518 cfbfca65b108ca127df8fe191a063d00d7c5172258 519 20aef47a45d6d6c572e7bd1b9f3e69b50ad3875c68 520 f6da0caaa90c675df4162c39', 521 / kid for recipient static ECDH public key / 522 4: h'6b69642d32', 523 }, 524 / encrypted CEK / 525 h'9aba6fa44e9b2cef9d646614dcda670dbdb31a3b9d37c7a 526 65b099a8152533062', 527 ], 528 ]) 530 Figure 7: COSE_Encrypt Example for HPKE 532 7. CEK Verification 534 The suit-cek-verification parameter contains a byte string resulting 535 from the encryption of 8 bytes of 0xA5 using the CEK with a nonce of 536 all zeros and empty additional data using the cipher algorithm and 537 mode also used to encrypt the plaintext. 539 As explained in Section 3, the suit-cek-verification parameter is 540 optional to implement and optional to use. When used, it reduces the 541 risk of an battery exhaustion attack against the IoT device. 543 8. Complete Examples 545 [[Editor's Note: Add examples for a complete manifest here (including 546 a digital signature), multiple recipients, encryption of manifests 547 (in comparison to firmware images).]] 549 9. Security Considerations 551 The algorithms described in this document assume that the party 552 performing the firmware encryption 554 * shares a key-encryption key (KEK) with the firmware consumer (for 555 use with the AES-Key Wrap scheme), or 557 * is in possession of the public key of the firmware consumer (for 558 use with HPKE). 560 Both cases require some upfront communication interaction, which is 561 not part of the SUIT manifest. This interaction is likely provided 562 by an IoT device management solution, as described in [RFC9019]. 564 For AES-Key Wrap to provide high security it is important that the 565 KEK is of high entropy, and that implementations protect the KEK from 566 disclosure. Compromise of the KEK may result in the disclosure of 567 all key data protected with that KEK. 569 Since the CEK is randomly generated, it must be ensured that the 570 guidelines for random number generations are followed, see [RFC8937]. 572 In some cases third party companies analyse binaries for known 573 security vulnerabilities. With encrypted firmware images this type 574 of analysis is prevented. Consequently, these third party companies 575 either need to be given access to the plaintext binary before 576 encryption or they need to become authorized recipients of the 577 encrypted firmware images. In either case, it is necessary to 578 explicitly consider those third parties in the software supply chain 579 when such a binary analysis is desired. 581 10. IANA Considerations 583 This document does not require any actions by IANA. 585 11. References 587 11.1. Normative References 589 [I-D.ietf-cose-hpke] 590 Tschofenig, H., Housley, R., and B. Moran, "Use of Hybrid 591 Public-Key Encryption (HPKE) with CBOR Object Signing and 592 Encryption (COSE)", Work in Progress, Internet-Draft, 593 draft-ietf-cose-hpke-01, 7 March 2022, 594 . 597 [I-D.ietf-suit-manifest] 598 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 599 "A Concise Binary Object Representation (CBOR)-based 600 Serialization Format for the Software Updates for Internet 601 of Things (SUIT) Manifest", Work in Progress, Internet- 602 Draft, draft-ietf-suit-manifest-16, 25 October 2021, 603 . 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, 609 . 611 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 612 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 613 September 2002, . 615 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 616 RFC 8152, DOI 10.17487/RFC8152, July 2017, 617 . 619 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 620 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 621 May 2017, . 623 [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid 624 Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, 625 February 2022, . 627 11.2. Informative References 629 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 630 DOI 10.17487/RFC2630, June 1999, 631 . 633 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 634 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 635 . 637 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 638 and C. Wood, "Randomness Improvements for Security 639 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 640 . 642 [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 643 Firmware Update Architecture for Internet of Things", 644 RFC 9019, DOI 10.17487/RFC9019, April 2021, 645 . 647 [RFC9124] Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest 648 Information Model for Firmware Updates in Internet of 649 Things (IoT) Devices", RFC 9124, DOI 10.17487/RFC9124, 650 January 2022, . 652 Appendix A. Acknowledgements 654 We would like to thank Henk Birkholz for his feedback on the CDDL 655 description in this document. Additionally, we would like to thank 656 Michael Richardson and Carsten Bormann for their review feedback. 657 Finally, we would like to thank Dick Brooks for making us aware of 658 the challenges firmware encryption imposes on binary analysis. 660 Authors' Addresses 662 Hannes Tschofenig 663 Arm Limited 664 Email: hannes.tschofenig@arm.com 666 Russ Housley 667 Vigil Security, LLC 668 Email: housley@vigilsec.com 670 Brendan Moran 671 Arm Limited 672 Email: Brendan.Moran@arm.com