idnits 2.17.00 (12 Aug 2021) /tmp/idnits55589/draft-ietf-suit-firmware-encryption-02.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 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 25, 2021) is 208 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-14 == 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 == Outdated reference: draft-ietf-suit-information-model has been published as RFC 9124 -- Obsolete informational reference (is this intentional?): RFC 2630 (Obsoleted by RFC 3369, RFC 3370) Summary: 2 errors (**), 0 flaws (~~), 5 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: April 28, 2022 Vigil Security 6 B. Moran 7 Arm Limited 8 October 25, 2021 10 Firmware Encryption with SUIT Manifests 11 draft-ietf-suit-firmware-encryption-02 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 April 28, 2022. 39 Copyright Notice 41 Copyright (c) 2021 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 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 70 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. SUIT Envelope and SUIT Manifest . . . . . . . . . . . . . . . 6 72 5. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6. Hybrid Public-Key Encryption (HPKE) . . . . . . . . . . . . . 11 74 7. CEK Verification . . . . . . . . . . . . . . . . . . . . . . 15 75 8. Complete Examples . . . . . . . . . . . . . . . . . . . . . . 15 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 11.2. Informative References . . . . . . . . . . . . . . . . . 17 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 Vulnerabilities with Internet of Things (IoT) devices have raised the 87 need for a reliable and secure firmware update mechanism that is also 88 suitable for constrained devices. To protect firmware images the 89 SUIT manifest format was developed [I-D.ietf-suit-manifest]. The 90 SUIT manifest provides a bundle of metadata about the firmware for an 91 IoT device, where to find the firmware image, and the devices to 92 which it applies. 94 The SUIT information model [I-D.ietf-suit-information-model] details 95 the information that has to be offered by the SUIT manifest format. 96 In addition to offering protection against modification, which is 97 provided by a digital signature or a message authentication code, the 98 firmware image may also be afforded confidentiality using encryption. 100 Encryption prevents third parties, including attackers, from gaining 101 access to the firmware binary. Hackers typically need intimate 102 knowledge of the target firmware to mount their attacks. For 103 example, return-oriented programming (ROP) requires access to the 104 binary and encryption makes it much more difficult to write exploits. 106 The SUIT manifest provides the data needed for authorized recipients 107 of the firmware image to decrypt it. The firmware image is encrypted 108 using a symmetric key. This symmetric cryptographic key is 109 established for encryption and decryption, and that key can be 110 applied to a SUIT manifest, firmware images, or personalization data, 111 depending on the encryption choices of the firmware author. 113 A symmetric key can be established using a variety of mechanisms; 114 this document defines two approaches for use with the IETF SUIT 115 manifest, namely: 117 - hybrid public-key encryption (HPKE), and 119 - AES Key Wrap (AES-KW) using a pre-shared key-encryption key (KEK). 121 These choices reduce the number of possible key establishment options 122 and thereby help increase interoperability between different SUIT 123 manifest parser implementations. 125 The document also contains a number of examples. 127 2. Conventions and Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 This document assumes familiarity with the IETF SUIT manifest 136 [I-D.ietf-suit-manifest], the SUIT information model 137 [I-D.ietf-suit-information-model] and the SUIT architecture 138 [RFC9019]. 140 The terms sender and recipient are defined in [I-D.irtf-cfrg-hpke] 141 and have the 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 157 [I-D.irtf-cfrg-hpke]. 159 3. Architecture 161 [RFC9019] describes the architecture for distributing firmware images 162 and manifests from the author to the firmware consumer. It does, 163 however, not detail the use of encrypted firmware images. 165 This document enhances the SUIT architecutre to include firmware 166 encryption. Figure 1 shows the distribution system, which represents 167 the firmware server and the device management infrastructure. The 168 distribution system is aware of the individual devices to which a 169 firmware update has to be delivered. 171 +----------+ 172 | | 173 | Author | 174 | | 175 +----------+ +----------+ 176 | Device |---+ | 177 |(Firmware | | | Firmware + 178 | Consumer)| | | Manifest 179 +----------+ | | 180 | | 181 | +--------------+ 182 | | | 183 +----------+ | Firmware + Manifest | Distribution | 184 | Device |---+------------------------| System | 185 |(Firmware | | | | 186 | Consumer)| | | | 187 +----------+ | +--------------+ 188 | 189 | 190 +----------+ | 191 | Device +---+ 192 |(Firmware | 193 | Consumer)| 194 +----------+ 196 Figure 1: Firmware Encryption Architecture. 198 Firmware encryption requires the sender to know the firmware 199 consumers and the respective credentials used by the key distribution 200 mechanism. For AES-KW the KEK needs to be known and, in case of 201 HPKE, the sender needs to be in possession of the public key of the 202 recipient. 204 The firmware author may have knowledge about all devices that need to 205 receive an encrypted firmware image but in most cases this will not 206 be likely. The distribution system certainly has the knowledge about 207 the recipients to perform firmware encryption. 209 To offer confidentiality protection for firmware images two 210 deployment variants need to be supported: 212 - The firmware author acts as the sender and the recipient is the 213 firmware consumer (or the firmware consumers). 215 - The firmware author encrypts the firmware image with the 216 distribution system as the initial recipient. Then, the 217 distribution system decrypts and re-encrypts the firmware image 218 towards the firmware consumer(s). Delegating the task of re- 219 encrypting the firmware image to the distribution system offers 220 flexiblity when the number of devices that need to receive 221 encrypted firmware images changes dynamically or when updates to 222 KEKs or recipient public keys are necessary. As a downside, the 223 author needs to trust the distribution system with performing the 224 re-encryption of the firmware image. 226 Irrespectively of the two variants, the key distribution data (in 227 form of the COSE_Encrypt structure) is included in the SUIT envelope 228 rather than in the SUIT manifest since the manifest will be digitally 229 signed (or MACed) by the firmware author. 231 Since the SUIT envelope is not protected cryptographically an 232 adversary could modify the COSE_Encrypt structure. For example, if 233 the attacker alters the key distribution data then a recipient will 234 decrypt the firmware image with an incorrect key. This will lead to 235 expending energy and flash cycles until the failure is detected. To 236 mitigate this attack, the optional suit-cek-verification parameter is 237 added to the manifest. Since the manifest is protected by a digital 238 signature (or a MAC), an adversary cannot successfully modify this 239 value. This parameter allows the recipient to verify whether the CEK 240 has successfully been derived. 242 Details about the changes to the envelope and the manifest can be 243 found in the next section. 245 4. SUIT Envelope and SUIT Manifest 247 This specification introduces two extensions to the SUIT envelope and 248 the manifest structure, as motivated in Section 3. 250 The SUIT envelope is enhanced with a key exchange payload, which is 251 carried inside the suit-protection-wrappers parameter, see Figure 2. 252 One or multiple SUIT_Encryption_Info payload(s) are carried within 253 the suit-protection-wrappers parameter. The content of the 254 SUIT_Encryption_Info payload is explained in Section 5 (for AES-KW) 255 and in Section 6 (for HPKE). When the encryption capability is used, 256 the suit-protection-wrappers parameter MUST be included in the 257 envelope. 259 SUIT_Envelope_Tagged = #6.107(SUIT_Envelope) 260 SUIT_Envelope = { 261 suit-authentication-wrapper => bstr .cbor SUIT_Authentication, 262 suit-manifest => bstr .cbor SUIT_Manifest, 263 SUIT_Severable_Manifest_Members, 264 suit-protection-wrappers => bstr .cbor { 265 *(int/str) => [+ SUIT_Encryption_Info] 266 } 267 * SUIT_Integrated_Payload, 268 * SUIT_Integrated_Dependency, 269 * $$SUIT_Envelope_Extensions, 270 * (int => bstr) 271 } 273 Figure 2: SUIT Envelope CDDL. 275 The manifest is extended with a CEK verification parameter (called 276 suit-cek-verification), see Figure 3. This parameter is optional and 277 is utilized in environments where battery exhaustion attacks are a 278 concern. Details about the CEK verification can be found in 279 Section 7. 281 SUIT_Manifest = { 282 suit-manifest-version => 1, 283 suit-manifest-sequence-number => uint, 284 suit-common => bstr .cbor SUIT_Common, 285 ? suit-reference-uri => tstr, 286 ? suit-cek-verification => bstr, 287 SUIT_Severable_Members_Choice, 288 SUIT_Unseverable_Members, 289 * $$SUIT_Manifest_Extensions, 290 } 292 Figure 3: SUIT Manifest CDDL. 294 5. AES Key Wrap 296 The AES Key Wrap (AES-KW) algorithm is described in RFC 3394 297 [RFC3394], and it can be used to encrypt a randomly generated 298 content-encryption key (CEK) with a pre-shared key-encryption key 299 (KEK). The COSE conventions for using AES-KW are specified in 300 Section 12.2.1 of [RFC8152]. The encrypted CEK is carried in the 301 COSE_recipient structure alongside the information needed for AES-KW. 302 The COSE_recipient structure, which is a substructure of the 303 COSE_Encrypt structure, contains the CEK encrypted by the KEK. 305 When the firmware image is encrypted for use by multiple recipients, 306 there are three options. We use the following notation KEK(R1,S) is 307 the KEK shared between recipient R1 and the sender S. Likewise, 308 CEK(R1,S) is shared between R1 and S. If a single CEK or a single 309 KEK is shared with all authorized recipients R by a given sender S in 310 a certain context then we use CEK(_,S) or KEK(_,S), respectively. 311 The notation ENC(plaintext, key) refers to the encryption of 312 plaintext with a given key. 314 - If all authorized recipients have access to the KEK, a single 315 COSE_recipient structure contains the encrypted CEK. This means 316 KEK(*,S) ENC(CEK,KEK), and ENC(firmware,CEK). 318 - If recipients have different KEKs, then multiple COSE_recipient 319 structures are included but only a single CEK is used. Each 320 COSE_recipient structure contains the CEK encrypted with the KEKs 321 appropriate for the recipient. In short, KEK_1(R1, S), ..., 322 KEK_n(Rn, S), ENC(CEK, KEK_i) for i=1 to n, and ENC(firmware,CEK). 323 The benefit of this approach is that the firmware image is 324 encrypted only once with a CEK while there is no sharing of the 325 KEK accross recipients. Hence, authorized recipients still use 326 their individual KEKs to decrypt the CEK and to subsequently 327 obtain the plaintext firmware. 329 - The third option is to use different CEKs encrypted with KEKs of 330 the authorized recipients. Assume there are KEK_1(R1, S),..., 331 KEK_n(Rn, S), and for i=1 to n the following computations need to 332 be made: ENC(CEK_i, KEK_i) and ENC(firmware,CEK_i). This approach 333 is appropriate when no benefits can be gained from encrypting and 334 transmitting firmware images only once. For example, firmware 335 images may contain information unique to a device instance. 337 Note that the AES-KW algorithm, as defined in Section 2.2.3.1 of 338 [RFC3394], does not have public parameters that vary on a per- 339 invocation basis. Hence, the protected structure in the 340 COSE_recipient is a byte string of zero length. 342 The COSE_Encrypt conveys information for encrypting the firmware 343 image, which includes information like the algorithm and the IV, even 344 though the firmware image is not embedded in the 345 COSE_Encrypt.ciphertext itself since it conveyed as detached content. 347 The CDDL for the COSE_Encrypt_Tagged structure is shown in Figure 4. 349 COSE_Encrypt_Tagged = #6.96(COSE_Encrypt) 351 SUIT_Encryption_Info = COSE_Encrypt_Tagged 353 COSE_Encrypt = [ 354 protected : bstr .cbor outer_header_map_protected, 355 unprotected : outer_header_map_unprotected, 356 ciphertext : null, ; because of detached ciphertext 357 recipients : [ + COSE_recipient ] 358 ] 360 outer_header_map_protected = 361 { 362 1 => int, ; algorithm identifier 363 * label =values ; extension point 364 } 366 outer_header_map_unprotected = 367 { 368 5 => bstr, ; IV 369 * label =values ; extension point 370 } 372 COSE_recipient = [ 373 protected : bstr .size 0, 374 unprotected : recipient_header_map, 375 ciphertext : bstr ; CEK encrypted with KEK 376 ] 378 recipient_header_map = 379 { 380 1 => int, ; algorithm identifier 381 4 => bstr, ; key identifier 382 * label =values ; extension point 383 } 385 Figure 4: CDDL for AES Key Wrap Encryption 387 The COSE specification requires a consistent byte stream for the 388 authenticated data structure to be created, which is shown in 389 Figure 5. 391 Enc_structure = [ 392 context : "Encrypt", 393 protected : empty_or_serialized_map, 394 external_aad : bstr 395 ] 397 Figure 5: CDDL for Enc_structure Data Structure 399 As shown in Figure 4, there are two protected fields: one protected 400 field in the COSE_Encrypt structure and a second one in the 401 COSE_recipient structure. The 'protected' field in the 402 Enc_structure, see Figure 5, refers to the content of the protected 403 field from the COSE_Encrypt structure. 405 The value of the external_aad MUST be set to null. 407 The following example illustrates the use of the AES-KW algorithm 408 with AES-128. 410 We use the following parameters in this example: 412 - IV: 0x26, 0x68, 0x23, 0x06, 0xd4, 0xfb, 0x28, 0xca, 0x01, 0xb4, 413 0x3b, 0x80 415 - KEK: "aaaaaaaaaaaaaaaa" 417 - KID: "kid-1" 419 - Plaintext Firmware: "This is a real firmware image." 421 - Firmware (hex): 422 546869732069732061207265616C206669726D7761726520696D6167652E 424 The COSE_Encrypt structure, in hex format, is (with a line break 425 inserted): 427 D8608443A10101A1054C26682306D4FB28CA01B43B80F68340A2012204456B69642D 428 315818AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D 430 The resulting COSE_Encrypt structure in a dignostic format is shown 431 in Figure 6. 433 96( 434 [ 435 // protected field with alg=AES-GCM-128 436 h'A10101', 437 { 438 // unprotected field with iv 439 5: h'26682306D4FB28CA01B43B80' 440 }, 441 // null because of detached ciphertext 442 null, 443 [ // recipients array 444 h'', // protected field 445 { // unprotected field 446 1: -3, // alg=A128KW 447 4: h'6B69642D31' // key id 448 }, 449 // CEK encrypted with KEK 450 h'AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D' 451 ] 452 ] 453 ) 455 Figure 6: COSE_Encrypt Example for AES Key Wrap 457 The CEK, in hex format, was "4C805F1587D624ED5E0DBB7A7F7FA7EB" and 458 the encrypted firmware (with a line feed added) was: 460 A8B6E61EF17FBAD1F1BF3235B3C64C06098EA512223260 461 F9425105F67F0FB6C92248AE289A025258F06C2AD70415 463 6. Hybrid Public-Key Encryption (HPKE) 465 Hybrid public-key encryption (HPKE) [I-D.irtf-cfrg-hpke] is a scheme 466 that provides public key encryption of arbitrary-sized plaintexts 467 given a recipient's public key. 469 For use with firmware encryption the scheme works as follows: HPKE, 470 which internally utilizes a non-interactive ephemeral-static Diffie- 471 Hellman exchange to derive a shared secret, is used to encrypt a CEK. 472 This CEK is subsequently used to encrypt the firmware image. Hence, 473 the plaintext passed to HPKE is the randomly generated CEK. The 474 output of the HPKE SealBase function is therefore the encrypted CEK 475 along with HPKE encapsulated key (i.e. the ephemeral ECDH public 476 key). 478 Only the holder of recipient's private key can decapsulate the CEK to 479 decrypt the firmware. Key generation in HPKE is influced by 480 additional parameters, such as identity information. 482 This approach allows all recipients to use the same CEK to encrypt 483 the firmware image, in case there are multiple recipients, to fulfill 484 a requirement for the efficient distribution of firmware images using 485 a multicast or broadcast protocol. 487 [cose-hpke] defines the use of HPKE with COSE and this specification 488 profiles it. 490 COSE_Encrypt_Tagged = #6.96(COSE_Encrypt) 492 SUIT_Encryption_Info = COSE_Encrypt_Tagged 494 ; Layer 0 495 COSE_Encrypt = [ 496 protected : bstr .cbor header_map, ; must contain alg 497 unprotected : header_map, ; must contain iv 498 ciphertext : null, ; because of detached ciphertext 499 recipients : [+COSE_recipient_outer] 500 ] 502 ; Layer 1 503 COSE_recipient_outer = [ 504 protected : bstr .size 0, 505 unprotected : header_map, ; must contain alg 506 encCEK : bstr, ; CEK encrypted based on HPKE algo 507 recipients : [ + COSE_recipient_inner ] 508 ] 510 ; Layer 2 511 COSE_recipient_inner = [ 512 protected : bstr .cbor header_map, ; must contain HPKE alg 513 unprotected : header_map, ; must contain kid and ephemeral public key 514 empty : null, 515 empty : null 516 ] 518 header_map = { 519 Generic_Headers, 520 * label =values, 521 } 523 Generic_Headers = ( 524 ? 1 => int, ; algorithm identifier 525 ? 2 => crv, ; EC identifier 526 ? 4 => bstr, ; key identifier 527 ? 5 => bstr ; IV 528 ) 530 Figure 7: CDDL for HPKE-based COSE_Encrypt Structure 532 The COSE_Encrypt structure (layer 0) contains algorithm parameters 533 for encryption of the firmware image. The protected field MUST 534 contain the 'alg' parameter and the unprotected field MUST contain 535 the 'iv' parameter. The ciphertext is always detached. 537 The COSE_recipient_outer structure (layer 1) contains the encrypted 538 CEK. The protected structure MUST be empty and the unprotected 539 structure MUST contain the 'alg' parameter, which carries the 540 algorithm information for protecting the CEK. 542 The COSE_recipient_inner structure (layer 2) contains the HPKE- 543 related information. The protected structure MUST contain the 'alg' 544 parameter set to the algorithm values in Section 6 of [cose-hpke] and 545 the unprotected structure MUST contain the 'kid' and the 'ephemeral' 546 parameter. 548 To populate the SUIT_Encryption_Info structure the sender creates a 549 CEK randomly. The CEK is used to encrypt the firmware image with the 550 selected algorithm. 552 The HPKE SealBase function takes various input parameters, as 553 explained in [cose-hpke]. The most important input parameters are 554 the plaintext (CEK in our case) and the public key of the recipient. 555 If successful, SealBase will return the encrypted CEK and the 556 ephemeral public key. 558 The recipient receives the ephemeral public key and the encrypted CEK 559 from the sender. It then uses the HPKE OpenBase function to decrypt 560 the ciphertext (which contains the CEK). 562 If the HPKE OpenBase function is successful, the recipient obtains 563 the CEK and can decrypt the firmware. The decryption operation is 564 shown in Figure 4 of [cose-hpke]. 566 An example of the COSE_Encrypt structure using the HPKE scheme is 567 shown in Figure 8. It uses the following algorithm combination: 569 - AES-GCM-128 for encryption of the firmware image. 571 - AES-GCM-128 for encrytion of the CEK. 573 - Key Encapsulation Mechanism (KEM): NIST P-256 575 - Key Derivation Function (KDF): HKDF-SHA256 577 96( 578 [ 579 // protected field with alg=AES-GCM-128 580 h'A10101', 581 { // unprotected field with iv 582 5: h'26682306D4FB28CA01B43B80' 583 }, 584 // null because of detached ciphertext 585 null, 586 [ // COSE_recipient_outer 587 h'', // empty protected field 588 { // unprotected field with ... 589 1: 1 // alg=A128GCM 590 }, 591 // Encrypted CEK 592 h'FA55A50CF110908DA6443149F2C2062011A7D8333A72721A', 593 [ // COSE_recipient_inner 594 // protected field with alg HPKE/P-256+HKDF-256 (new) 595 h'A1013818', 596 { // unprotected field with ... 597 // HPKE encapsulated key 598 -1: h'A4010220012158205F...979D51687187510C445', 599 // kid for recipient static ECDH public key 600 4: h'6B69642D31' 601 }, 602 // empty ciphertext 603 null 604 ] 605 ] 606 ] 607 ) 609 Figure 8: COSE_Encrypt Example for HPKE 611 7. CEK Verification 613 The suit-cek-verification parameter contains a byte string resulting 614 from the encryption of 8 bytes of 0xA5 using the CEK. 616 [[Editor's Note: Guidance about the selection of an IV needs to be 617 added here.]] 619 8. Complete Examples 621 [[Editor's Note: Add examples for a complete manifest here (including 622 a digital signature), multiple recipients, encryption of manifests 623 (in comparison to firmware images).]] 625 9. Security Considerations 627 The algorithms described in this document assume that the party 628 performing the firmware encryption 630 - shares a key-encryption key (KEK) with the firmware consumer (for 631 use with the AES-Key Wrap scheme), or 633 - is in possession of the public key of the firmware consumer (for 634 use with HPKE). 636 Both cases require some upfront communication interaction, which is 637 not part of the SUIT manifest. This interaction is likely provided 638 by an IoT device management solution, as described in [RFC9019]. 640 For AES-Key Wrap to provide high security it is important that the 641 KEK is of high entropy, and that implementations protect the KEK from 642 disclosure. Compromise of the KEK may result in the disclosure of 643 all key data protected with that KEK. 645 Since the CEK is randomly generated, it must be ensured that the 646 guidelines for random number generations are followed, see [RFC8937]. 648 In some cases third party companies analyse binaries for known 649 security vulnerabilities. With encrypted firmware images this type 650 of analysis is prevented. Consequently, these third party companies 651 either need to be given access to the plaintext binary before 652 encryption or they need to become authorized recipients of the 653 encrypted firmware images. In either case, it is necessary to 654 explicitly consider those third parties in the software supply chain 655 when such a binary analysis is desired. 657 10. IANA Considerations 659 This document does not require any actions by IANA. 661 11. References 663 11.1. Normative References 665 [cose-hpke] 666 Tschofenig, H., Housley, R., and B. Moran, "Use of Hybrid 667 Public-Key Encryption (HPKE) with CBOR Object Signing and 668 Encryption (COSE)", October 2021, 669 . 672 [I-D.ietf-suit-manifest] 673 Arm Limited, Arm Limited, Fraunhofer SIT, and Inria, "A 674 Concise Binary Object Representation (CBOR)-based 675 Serialization Format for the Software Updates for Internet 676 of Things (SUIT) Manifest", draft-ietf-suit-manifest-14 677 (work in progress), July 2021. 679 [I-D.irtf-cfrg-hpke] 680 Cisco, Inria, Inria, and Cloudflare, "Hybrid Public Key 681 Encryption", draft-irtf-cfrg-hpke-12 (work in progress), 682 September 2021. 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, 686 DOI 10.17487/RFC2119, March 1997, 687 . 689 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 690 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 691 September 2002, . 693 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 694 RFC 8152, DOI 10.17487/RFC8152, July 2017, 695 . 697 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 698 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 699 May 2017, . 701 11.2. Informative References 703 [I-D.ietf-suit-information-model] 704 Arm Limited, Arm Limited, and Fraunhofer SIT, "A Manifest 705 Information Model for Firmware Updates in IoT Devices", 706 draft-ietf-suit-information-model-13 (work in progress), 707 July 2021. 709 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 710 DOI 10.17487/RFC2630, June 1999, 711 . 713 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 714 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 715 . 717 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 718 and C. Wood, "Randomness Improvements for Security 719 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 720 . 722 [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 723 Firmware Update Architecture for Internet of Things", 724 RFC 9019, DOI 10.17487/RFC9019, April 2021, 725 . 727 Appendix A. Acknowledgements 729 We would like to thank Henk Birkholz for his feedback on the CDDL 730 description in this document. Additionally, we would like to thank 731 Michael Richardson and Carsten Bormann for their review feedback. 732 Finally, we would like to thank Dick Brooks for making us aware of 733 the challenges firmware encryption imposes on binary analysis. 735 Authors' Addresses 737 Hannes Tschofenig 738 Arm Limited 740 EMail: hannes.tschofenig@arm.com 742 Russ Housley 743 Vigil Security, LLC 745 EMail: housley@vigilsec.com 747 Brendan Moran 748 Arm Limited 750 EMail: Brendan.Moran@arm.com