idnits 2.17.1 draft-ietf-suit-firmware-encryption-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2021) is 990 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) ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-12 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-08 ** 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 normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-13) exists of draft-ietf-suit-information-model-11 -- Obsolete informational reference (is this intentional?): RFC 2630 (Obsoleted by RFC 3369, RFC 3370) Summary: 4 errors (**), 0 flaws (~~), 6 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: January 13, 2022 Vigil Security 6 B. Moran 7 Arm Limited 8 July 12, 2021 10 Firmware Encryption with SUIT Manifests 11 draft-ietf-suit-firmware-encryption-01 13 Abstract 15 This document specifies a firmware update mechanism where the 16 firmware image is encrypted. This mechanism uses the IETF SUIT 17 manifest with key establishment provided by the hybrid public-key 18 encryption (HPKE) scheme or AES Key Wrap (AES-KW) with a pre-shared 19 key-encryption key. In either case, AES-GCM or AES-CCM is used for 20 firmware encryption. 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 January 13, 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. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Hybrid Public-Key Encryption (HPKE) . . . . . . . . . . . . . 9 73 6. Complete Examples . . . . . . . . . . . . . . . . . . . . . . 14 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 9.2. Informative References . . . . . . . . . . . . . . . . . 17 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 Vulnerabilities with Internet of Things (IoT) devices have raised the 85 need for a reliable and secure firmware update mechanism that is also 86 suitable for constrained devices. To protect firmware images the 87 SUIT manifest format was developed [I-D.ietf-suit-manifest]. The 88 SUIT manifest provides a bundle of metadata about the firmware for an 89 IoT device, where to find the firmware image, and the devices to 90 which it applies. 92 The SUIT information model [I-D.ietf-suit-information-model] details 93 the information that has to be offered by the SUIT manifest format. 94 In addition to offering protection against modification, which is 95 provided by a digital signature or a message authentication code, the 96 firmware image may also be afforded confidentiality using encryption. 98 Encryption prevents third parties, including attackers, from gaining 99 access to the firmware image. For example, return-oriented 100 programming (ROP) requires intimate knowledge of the target firmware 101 and encryption makes this approach much more difficult to exploit. 102 The SUIT manifest provides the data needed for authorized recipients 103 of the firmware image to decrypt it. 105 A symmetric cryptographic key is established for encryption and 106 decryption, and that key can be applied to a SUIT manifest, firmware 107 images, or personalization data, depending on the encryption choices 108 of the firmware author. This symmetric key can be established using 109 a variety of mechanisms; this document defines two approaches for use 110 with the IETF SUIT manifest. Key establishment can be provided by 111 the hybrid public-key encryption (HPKE) scheme or AES Key Wrap (AES- 112 KW) with a pre-shared key-encryption key. These choices reduce the 113 number of possible key establishment options and thereby help 114 increase interoperability between different SUIT manifest parser 115 implementations. 117 The document also contains a number of examples for developers. 119 2. Conventions and Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 This document assumes familiarity with the IETF SUIT manifest 128 [I-D.ietf-suit-manifest] and the SUIT architecture [RFC9019]. 130 In context of encryption, the terms "recipient" and "firmware 131 consumer" are used interchangeably. 133 Additionally, the following abbreviations are used in this document: 135 - Key Wrap (KW), defined in RFC 3394 [RFC3394] for use with AES. 137 - Key-encryption key / key-encrypting key (KEK), a term defined in 138 RFC 4949 [RFC4949]. 140 - Content-encryption key (CEK), a term defined in RFC 2630 141 [RFC2630]. 143 - Hybrid Public Key Encryption (HPKE), defined in 144 [I-D.irtf-cfrg-hpke]. 146 3. Architecture 148 Figure 1 in [RFC9019] shows the architecture for distributing 149 firmware images and manifests from the author to the firmware 150 consumer. It does, however, not detail the use of encrypted firmware 151 images. Figure 1 therefore focuses on those aspects. The firmware 152 server and the device management infrastructure is represented by the 153 distribution system, which is aware of the individual devices a 154 firmware update has to be delivered to. 156 Firmware encryption requires the party doing the encryption to know 157 either the KEK (in case of AES-KW) or the public key of the recipient 158 (in case of HPKE). The firmware author may have knowledge about all 159 the devices but in most cases this will not be likely. Hence, it is 160 the responsibility of the distribution system to perform the firmware 161 encryption. 163 Since including the COSE_Encrypt structure in the manifest 164 invalidates a a digital signature or a MAC added by the author, this 165 structure needs to be added to the envelope by the distribution 166 system. This approach offers flexiblity when the number of devices 167 that need to receive encrypted firmware images changes dynamically or 168 when the updates to KEKs or recipient public keys are necessary. As 169 a downside, the author needs to trust the distribution system with 170 performing the encryption of the plaintext firmware image. 172 +----------+ 173 | | 174 | Author | 175 | | 176 +----------+ +----------+ 177 | | | 178 | Device |---+ | Firmware + 179 | | | | Manifest 180 +----------+ | | 181 | | 182 | +--------------+ 183 +----------+ | | | 184 | | | Firmware + Manifest | Distribution | 185 | Device |---+------------------------| System | 186 | | | | | 187 +----------+ | +--------------+ 188 | 189 | 190 +----------+ | 191 | | | 192 | Device +---+ 193 | | 194 +----------+ 196 Figure 1: Firmware Encryption Architecture. 198 4. AES Key Wrap 200 The AES Key Wrap (AES-KW) algorithm is described in RFC 3394 201 [RFC3394], and it can be used to encrypt a randomly generated 202 content-encryption key (CEK) with a pre-shared key-encryption key 203 (KEK). The COSE conventions for using AES-KW are specified in 204 Section 12.2.1 of [RFC8152]. The encrypted CEK is carried in the 205 COSE_recipient structure alongside the information needed for AES-KW. 206 The COSE_recipient structure, which is a substructure of the 207 COSE_Encrypt structure, contains the CEK encrypted by the KEK. 209 When the firmware image is encrypted for use by multiple recipients, 210 there are three options: 212 - If all of authorized recipients have access to the KEK, a single 213 COSE_recipient structure contains the encrypted CEK. 215 - If recipients have different KEKs, then the COSE_recipient 216 structure may contain the same CEK encrypted with many different 217 KEKs. The benefit of this approach is that the firmware image is 218 encrypted only once with the CEK while the authorized recipients 219 still need to use their individual KEKs to obtain the plaintext. 221 - The last option is to use different CEKs encrypted with KEKs of 222 the authorized recipients. This is appropriate when no benefits 223 can be gained from encrypting and transmitting firmware images 224 only once. For example, firmware images may contain information 225 unique to a device instance. 227 Note that the AES-KW algorithm, as defined in Section 2.2.3.1 of 228 [RFC3394], does not have public parameters that vary on a per- 229 invocation basis. Hence, the protected structure in the 230 COSE_recipient is a byte string of zero length. 232 The COSE_Encrypt conveys information for encrypting the firmware 233 image, which includes information like the algorithm and the IV, even 234 though the firmware image is not embedded in the 235 COSE_Encrypt.ciphertext itself since it conveyed as detached content. 237 The CDDL for the COSE_Encrypt_Tagged structure is shown in Figure 2. 239 COSE_Encrypt_Tagged = #6.96(COSE_Encrypt) 241 SUIT_Encryption_Info = COSE_Encrypt_Tagged 243 COSE_Encrypt = [ 244 protected : bstr .cbor outer_header_map_protected, 245 unprotected : outer_header_map_unprotected, 246 ciphertext : null, ; because of detached ciphertext 247 recipients : [ + COSE_recipient ] 248 ] 250 outer_header_map_protected = 251 { 252 1 => int, ; algorithm identifier 253 * label =values ; extension point 254 } 256 outer_header_map_unprotected = 257 { 258 5 => bstr, ; IV 259 * label =values ; extension point 260 } 262 COSE_recipient = [ 263 protected : bstr .size 0, 264 unprotected : recipient_header_map, 265 ciphertext : bstr ; CEK encrypted with KEK 266 ] 268 recipient_header_map = 269 { 270 1 => int, ; algorithm identifier 271 4 => bstr, ; key identifier 272 * label =values ; extension point 273 } 275 Figure 2: CDDL for AES Key Wrap-based Firmware Encryption 277 The COSE specification requires a consistent byte stream for the 278 authenticated data structure to be created, which is shown in 279 Figure 3. 281 Enc_structure = [ 282 context : "Encrypt", 283 protected : empty_or_serialized_map, 284 external_aad : bstr 285 ] 287 Figure 3: CDDL for Enc_structure Data Structure 289 As shown in Figure 2, there are two protected fields: one protected 290 field in the COSE_Encrypt structure and a second one in the 291 COSE_recipient structure. The 'protected' field in the 292 Enc_structure, see Figure 3, refers to the content of the protected 293 field from the COSE_Encrypt structure, not to the protected field of 294 the COSE_recipient structure. 296 The value of the external_aad is set to null. 298 The following example illustrates the use of the AES-KW algorithm 299 with AES-128. 301 We use the following parameters in this example: 303 - IV: 0x26, 0x68, 0x23, 0x06, 0xd4, 0xfb, 0x28, 0xca, 0x01, 0xb4, 304 0x3b, 0x80 306 - KEK: "aaaaaaaaaaaaaaaa" 308 - KID: "kid-1" 310 - Plaintext Firmware: "This is a real firmware image." 312 - Firmware (hex): 313 546869732069732061207265616C206669726D7761726520696D6167652E 315 The COSE_Encrypt structure in hex format is (with a line break 316 inserted): 318 D8608443A10101A1054C26682306D4FB28CA01B43B80F68340A2012204456B69642D 319 315818AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D 321 The resulting COSE_Encrypt structure in a dignostic format is shown 322 in Figure 4. 324 96( 325 [ 326 // protected field with alg=AES-GCM-128 327 h'A10101', 328 { 329 // unprotected field with iv 330 5: h'26682306D4FB28CA01B43B80' 331 }, 332 // null because of detached ciphertext 333 null, 334 [ // recipients array 335 h'', // protected field 336 { // unprotected field 337 1: -3, // alg=A128KW 338 4: h'6B69642D31' // key id 339 }, 340 // CEK encrypted with KEK 341 h'AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D' 342 ] 343 ] 344 ) 346 Figure 4: COSE_Encrypt Example for AES Key Wrap 348 The CEK was "4C805F1587D624ED5E0DBB7A7F7FA7EB" and the encrypted 349 firmware was: 351 A8B6E61EF17FBAD1F1BF3235B3C64C06098EA512223260 352 F9425105F67F0FB6C92248AE289A025258F06C2AD70415 354 5. Hybrid Public-Key Encryption (HPKE) 356 Hybrid public-key encryption (HPKE) [I-D.irtf-cfrg-hpke] is a scheme 357 that provides public key encryption of arbitrary-sized plaintexts 358 given a recipient's public key. 360 For use with firmware encryption the scheme works as follows: The 361 firmware author uses HPKE, which internally utilizes a non- 362 interactive ephemeral-static Diffie-Hellman exchange to derive a 363 shared secret, which is then used to encrypt plaintext. 365 In the firmware encryption scenario, the plaintext passed to HPKE for 366 encryption is the randomly generated CEK. The output of the HPKE 367 operation is therefore the encrypted CEK along with HPKE encapsulated 368 key (i.e. the ephemeral ECDH public key of the author). The CEK is 369 then used to encrypt the firmware. 371 Only the holder of recipient's private key can decapsulate the CEK to 372 decrypt the firmware. Key generation is influced by additional 373 parameters, such as identity information. 375 This approach allows all recipients to use the same CEK to encrypt 376 the firmware image, in case there are multiple recipients, to fulfill 377 a requirement for the efficient distribution of firmware images using 378 a multicast or broadcast protocol. 380 The CDDL for the COSE_Encrypt structure as used with HPKE is shown in 381 Figure 5. 383 COSE_Encrypt_Tagged = #6.96(COSE_Encrypt) 385 SUIT_Encryption_Info = COSE_Encrypt_Tagged 387 COSE_Encrypt = [ 388 protected : bstr .cbor header_map, ; must contain alg 389 unprotected : header_map, ; must contain iv 390 ciphertext : null, ; because of detached ciphertext 391 recipients : [ + COSE_recipient_outer ] 392 ] 394 COSE_recipient_outer = [ 395 protected : bstr .size 0, 396 unprotected : header_map, ; must contain alg 397 ciphertext : bstr ; CEK encrypted based on HPKE algo 398 recipients : [ + COSE_recipient_inner ] 399 ] 401 COSE_recipient_inner = [ 402 protected : bstr .cbor header_map, ; must contain alg 403 unprotected : header_map, ; must contain kid, 404 ciphertext : bstr ; CEK encrypted based on HPKE algo 405 recipients : null 406 ] 408 header_map = { 409 Generic_Headers, 410 * label =values, 411 } 413 Generic_Headers = ( 414 ? 1 => int, ; algorithm identifier 415 ? 2 => crv, ; EC identifier 416 ? 4 => bstr, ; key identifier 417 ? 5 => bstr ; IV 418 ) 420 Figure 5: CDDL for HPKE-based COSE_Encrypt Structure 422 The COSE_Encrypt structure in Figure 5 requires the encrypted CEK and 423 the ephemeral public key of the firmare author to be generated. This 424 is accomplished with the HPKE encryption function as shown in 425 Figure 6. 427 CEK = random() 428 pkR = DeserializePublicKey(recipient_public_key) 429 info = "cose hpke" || 0x00 || COSE_KDF_Context 430 enc, context = SetupBaseS(pkR, info) 431 ciphertext = context.Seal(null, CEK) 433 Figure 6 435 Legend: 437 - The functions DeserializePublicKey(), SetupBaseS() and Seal() are 438 defined in HPKE [I-D.irtf-cfrg-hpke]. 440 - CEK is a random byte sequence of keysize length whereby keysize 441 corresponds to the size of the indicated symmetric encryption 442 algorithm used for firmware encryption. For example, AES-128-GCM 443 requires a 16 byte key. The CEK would therefore be 16 bytes long. 445 - 'recipient_public_key' represents the public key of the recipient. 447 - 'info' is a data structure described below used as input to the 448 key derivation internal to the HPKE algorithm. In addition to the 449 constant prefix, the COSE_KDF_Context structure is used. The 450 COSE_KDF_Context is shown in Figure 7. 452 The result of the above-described operation is the encrypted CEK 453 (denoted as ciphertext) and the enc - the HPKE encapsulated key (i.e. 454 the ephemeral ECDH public key of the author). 456 PartyInfo = ( 457 identity : bstr, 458 nonce : nil, 459 other : nil 460 ) 462 COSE_KDF_Context = [ 463 AlgorithmID : int, 464 PartyUInfo : [ PartyInfo ], 465 PartyVInfo : [ PartyInfo ], 466 SuppPubInfo : [ 467 keyDataLength : uint, 468 protected : empty_or_serialized_map 469 ], 470 ] 472 Figure 7: COSE_KDF_Context Data Structure 474 Notes: 476 - PartyUInfo.identity corresponds to the kid found in the 477 COSE_Sign_Tagged or COSE_Sign1_Tagged structure (when a digital 478 signature is used). When utilizing a MAC, then the kid is found 479 in the COSE_Mac_Tagged or COSE_Mac0_Tagged structure. 481 - PartyVInfo.identity corresponds to the kid used for the respective 482 recipient from the inner-most recipients array. 484 - The value in the AlgorithmID field corresponds to the alg 485 parameter in the protected structure in the inner-most recipients 486 array. 488 - keyDataLength is set to the number of bits of the desired output 489 value. 491 - protected refers to the protected structure of the inner-most 492 array. 494 The author encrypts the firmware using the CEK with the selected 495 algorithm. 497 The recipient decrypts the encrypted CEK, using two input parameters: 499 - the private key skR corresponding to the public key pkR used by 500 the author when creating the manifest. 502 - the HPKE encapsulated key (i.e. ephemeral ECDH public key) created 503 by the author. 505 If the HPKE operation is successful, the recipient obtains the CEK 506 and can decrypt the firmware. 508 Figure 8 shows the HPKE computations performed by the recipient for 509 decryption. 511 info = "cose hpke" || 0x00 || COSE_KDF_Context 512 context = SetupBaseR(ciphertext, skR, info) 513 CEK = context.Open(null, ciphertext) 515 Figure 8 517 An example of the COSE_Encrypt structure using the HPKE scheme is 518 shown in Figure 9. It uses the following algorithm combination: 520 - AES-GCM-128 for encryption of the firmware image. 522 - AES-GCM-128 for encrytion of the CEK. 524 - Key Encapsulation Mechanism (KEM): NIST P-256 526 - Key Derivation Function (KDF): HKDF-SHA256 528 96( 529 [ 530 // protected field with alg=AES-GCM-128 531 h'A10101', 532 { // unprotected field with iv 533 5: h'26682306D4FB28CA01B43B80' 534 }, 535 // null because of detached ciphertext 536 null, 537 [ // COSE_recipient_outer 538 h'', // empty protected field 539 { // unprotected field with ... 540 1: 1 // alg=A128GCM 541 }, 542 // Encrypted CEK 543 h'FA55A50CF110908DA6443149F2C2062011A7D8333A72721A', 544 [ // COSE_recipient_inner 545 // protected field with alg HPKE/P-256+HKDF-256 (new) 546 h'A1013818', 547 { // unprotected field with ... 548 // HPKE encapsulated key 549 -1: h'A4010220012158205F...979D51687187510C445', 550 // kid for recipient static ECDH public key 551 4: h'6B69642D31' 552 }, 553 // empty ciphertext 554 null 555 ] 556 ] 557 ] 558 ) 560 Figure 9: COSE_Encrypt Example for HPKE 562 6. Complete Examples 564 TBD: Example for complete manifest here (which also includes the 565 digital signature). TBD: Multiple recipient example as well. TBD: 566 Encryption of manifest (in addition of firmware encryption). 568 7. Security Considerations 570 The algorithms described in this document assume that the firmware 571 author 573 - has either shared a key-encryption key (KEK) with the firmware 574 consumer (for use with the AES-Key Wrap scheme), or 576 - is in possession of the public key of the firmware consumer (for 577 use with HPKE). 579 Both cases require some upfront communication interaction, which is 580 not part of the SUIT manifest. This interaction is likely provided 581 by an IoT device management solution, as described in [RFC9019]. 583 For AES-Key Wrap to provide high security it is important that the 584 KEK is of high entropy, and that implementations protect the KEK from 585 disclosure. Compromise of the KEK may result in the disclosure of 586 all key data protected with that KEK. 588 Since the CEK is randomly generated, it must be ensured that the 589 guidelines for random number generations are followed, see [RFC8937]. 591 In some cases third party companies analyse binaries for known 592 security vulnerabilities. With encrypted firmware images this type 593 of analysis is prevented. Consequently, these third party companies 594 either need to be given access to the plaintext binary before 595 encryption or they need to become authorized recipients of the 596 encrypted firmware images. In either case, it is necessary to 597 explicitly consider those third parties in the software supply chain 598 when such a binary analysis is desired. 600 8. IANA Considerations 602 This document requests IANA to create new entries in the COSE 603 Algorithms registry established with [I-D.ietf-cose-rfc8152bis-algs]. 605 +-------------+-------+---------+------------+--------+---------------+ 606 | Name | Value | KDF | Ephemeral- | Key | Description | 607 | | | | Static | Wrap | | 608 +-------------+-------+---------+------------+--------+---------------+ 609 | HPKE/P-256+ | TBD1 | HKDF - | yes | none | HPKE with | 610 | HKDF-256 | | SHA-256 | | | ECDH-ES | 611 | | | | | | (P-256) + | 612 | | | | | | HKDF-256 | 613 +-------------+-------+---------+------------+--------+---------------+ 614 | HPKE/P-384+ | TBD2 | HKDF - | yes | none | HPKE with | 615 | HKDF-SHA384 | | SHA-384 | | | ECDH-ES | 616 | | | | | | (P-384) + | 617 | | | | | | HKDF-384 | 618 +-------------+-------+---------+------------+--------+---------------+ 619 | HPKE/P-521+ | TBD3 | HKDF - | yes | none | HPKE with | 620 | HKDF-SHA521 | | SHA-521 | | | ECDH-ES | 621 | | | | | | (P-521) + | 622 | | | | | | HKDF-521 | 623 +-------------+-------+---------+------------+--------+---------------+ 624 | HPKE | TBD4 | HKDF - | yes | none | HPKE with | 625 | X25519 + | | SHA-256 | | | ECDH-ES | 626 | HKDF-SHA256 | | | | | (X25519) + | 627 | | | | | | HKDF-256 | 628 +-------------+-------+---------+------------+--------+---------------+ 629 | HPKE | TBD4 | HKDF - | yes | none | HPKE with | 630 | X448 + | | SHA-512 | | | ECDH-ES | 631 | HKDF-SHA512 | | | | | (X448) + | 632 | | | | | | HKDF-512 | 633 +-------------+-------+---------+------------+--------+---------------+ 635 9. References 637 9.1. Normative References 639 [I-D.ietf-cose-rfc8152bis-algs] 640 Schaad, J., "CBOR Object Signing and Encryption (COSE): 641 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 642 (work in progress), September 2020. 644 [I-D.ietf-suit-manifest] 645 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 646 "A Concise Binary Object Representation (CBOR)-based 647 Serialization Format for the Software Updates for Internet 648 of Things (SUIT) Manifest", draft-ietf-suit-manifest-12 649 (work in progress), February 2021. 651 [I-D.irtf-cfrg-hpke] 652 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 653 "Hybrid Public Key Encryption", draft-irtf-cfrg-hpke-08 654 (work in progress), February 2021. 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, 658 DOI 10.17487/RFC2119, March 1997, 659 . 661 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 662 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 663 September 2002, . 665 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 666 RFC 8152, DOI 10.17487/RFC8152, July 2017, 667 . 669 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 670 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 671 May 2017, . 673 9.2. Informative References 675 [I-D.ietf-suit-information-model] 676 Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest 677 Information Model for Firmware Updates in IoT Devices", 678 draft-ietf-suit-information-model-11 (work in progress), 679 April 2021. 681 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 682 DOI 10.17487/RFC2630, June 1999, 683 . 685 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 686 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 687 . 689 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 690 and C. Wood, "Randomness Improvements for Security 691 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 692 . 694 [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 695 Firmware Update Architecture for Internet of Things", 696 RFC 9019, DOI 10.17487/RFC9019, April 2021, 697 . 699 Appendix A. Acknowledgements 701 We would like to thank Henk Birkholz for his feedback on the CDDL 702 description in this document. Additionally, we would like to thank 703 Michael Richardson and Carsten Bormann for their review feedback. 704 Finally, we would like to thank Dick Brooks for making us aware of 705 the challenges firmware encryption imposes on binary analysis. 707 Authors' Addresses 709 Hannes Tschofenig 710 Arm Limited 712 EMail: hannes.tschofenig@arm.com 714 Russ Housley 715 Vigil Security, LLC 717 EMail: housley@vigilsec.com 719 Brendan Moran 720 Arm Limited 722 EMail: Brendan.Moran@arm.com