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