| < draft-ietf-suit-firmware-encryption-03.txt | draft-ietf-suit-firmware-encryption-04.txt > | |||
|---|---|---|---|---|
| SUIT H. Tschofenig | SUIT H. Tschofenig | |||
| Internet-Draft Arm Limited | Internet-Draft Arm Limited | |||
| Intended status: Standards Track R. Housley | Intended status: Standards Track R. Housley | |||
| Expires: 8 September 2022 Vigil Security | Expires: 22 October 2022 Vigil Security | |||
| B. Moran | B. Moran | |||
| Arm Limited | Arm Limited | |||
| 7 March 2022 | 20 April 2022 | |||
| Firmware Encryption with SUIT Manifests | Firmware Encryption with SUIT Manifests | |||
| draft-ietf-suit-firmware-encryption-03 | draft-ietf-suit-firmware-encryption-04 | |||
| Abstract | Abstract | |||
| This document specifies a firmware update mechanism where the | This document specifies a firmware update mechanism where the | |||
| firmware image is encrypted. Firmware encryption uses the IETF SUIT | firmware image is encrypted. Firmware encryption uses the IETF SUIT | |||
| manifest with key establishment provided by the hybrid public-key | manifest with key establishment provided by the hybrid public-key | |||
| encryption (HPKE) scheme and the AES Key Wrap (AES-KW) with a pre- | encryption (HPKE) scheme and the AES Key Wrap (AES-KW) with a pre- | |||
| shared key-encryption key. Encryption of the firmware image is | shared key-encryption key. Encryption of the firmware image is | |||
| encrypted using AES-GCM or AES-CCM. | accomplished using the established content encryption key and a | |||
| mutually agreed symmetric encryption algorithm, such as AES-GCM or | ||||
| AES-CCM. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 8 September 2022. | This Internet-Draft will expire on 22 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| This document may contain material from IETF Documents or IETF | This document may contain material from IETF Documents or IETF | |||
| Contributions published or made publicly available before November | Contributions published or made publicly available before November | |||
| 10, 2008. The person(s) controlling the copyright in some of this | 10, 2008. The person(s) controlling the copyright in some of this | |||
| material may not have granted the IETF Trust the right to allow | material may not have granted the IETF Trust the right to allow | |||
| skipping to change at page 2, line 34 ¶ | skipping to change at page 2, line 37 ¶ | |||
| 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4. SUIT Envelope and SUIT Manifest . . . . . . . . . . . . . . . 6 | 4. SUIT Envelope and SUIT Manifest . . . . . . . . . . . . . . . 6 | |||
| 5. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . . . 7 | 5. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 6. Hybrid Public-Key Encryption (HPKE) . . . . . . . . . . . . . 11 | 6. Hybrid Public-Key Encryption (HPKE) . . . . . . . . . . . . . 11 | |||
| 7. CEK Verification . . . . . . . . . . . . . . . . . . . . . . 13 | 7. CEK Verification . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 8. Complete Examples . . . . . . . . . . . . . . . . . . . . . . 13 | 8. Complete Examples . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 15 | 11.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
| Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 1. Introduction | 1. Introduction | |||
| Vulnerabilities with Internet of Things (IoT) devices have raised the | Vulnerabilities with Internet of Things (IoT) devices have raised the | |||
| need for a reliable and secure firmware update mechanism that is also | need for a reliable and secure firmware update mechanism that is also | |||
| suitable for constrained devices. To protect firmware images the | suitable for constrained devices. To protect firmware images the | |||
| SUIT manifest format was developed [I-D.ietf-suit-manifest]. The | SUIT manifest format was developed [I-D.ietf-suit-manifest]. The | |||
| SUIT manifest provides a bundle of metadata about the firmware for an | SUIT manifest provides a bundle of metadata about the firmware for an | |||
| skipping to change at page 3, line 50 ¶ | skipping to change at page 3, line 50 ¶ | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| This document assumes familiarity with the IETF SUIT manifest | This document assumes familiarity with the IETF SUIT manifest | |||
| [I-D.ietf-suit-manifest], the SUIT information model [RFC9124] and | [I-D.ietf-suit-manifest], the SUIT information model [RFC9124] and | |||
| the SUIT architecture [RFC9019]. | the SUIT architecture [RFC9019]. | |||
| The terms sender and recipient are defined in [I-D.irtf-cfrg-hpke] | The terms sender and recipient are defined in [RFC9180] and have the | |||
| and have the following meaning: | following meaning: | |||
| * Sender: Role of entity which sends an encrypted message. | * Sender: Role of entity which sends an encrypted message. | |||
| * Recipient: Role of entity which receives an encrypted message. | * Recipient: Role of entity which receives an encrypted message. | |||
| Additionally, the following abbreviations are used in this document: | Additionally, the following abbreviations are used in this document: | |||
| * Key Wrap (KW), defined in RFC 3394 [RFC3394] for use with AES. | * Key Wrap (KW), defined in RFC 3394 [RFC3394] for use with AES. | |||
| * Key-encryption key (KEK), a term defined in RFC 4949 [RFC4949]. | * Key-encryption key (KEK), a term defined in RFC 4949 [RFC4949]. | |||
| * Content-encryption key (CEK), a term defined in RFC 2630 | * Content-encryption key (CEK), a term defined in RFC 2630 | |||
| [RFC2630]. | [RFC2630]. | |||
| * Hybrid Public Key Encryption (HPKE), defined in | * Hybrid Public Key Encryption (HPKE), defined in [RFC9180]. | |||
| [I-D.irtf-cfrg-hpke]. | ||||
| The main use case of this document is to encrypt firmware. However, | ||||
| SUIT manifests may require other payloads than firmware images to | ||||
| experience confidentiality protection using encryption. While the | ||||
| term firmware is used throughout the document, plaintext other than | ||||
| firmware images may get encrypted using the described mechanism. | ||||
| Hence, the terms firmware (image) and plaintext are used | ||||
| interchangably. | ||||
| 3. Architecture | 3. Architecture | |||
| [RFC9019] describes the architecture for distributing firmware images | [RFC9019] describes the architecture for distributing firmware images | |||
| and manifests from the author to the firmware consumer. It does, | and manifests from the author to the firmware consumer. It does, | |||
| however, not detail the use of encrypted firmware images. | however, not detail the use of encrypted firmware images. | |||
| This document enhances the SUIT architecutre to include firmware | This document enhances the SUIT architecutre to include firmware | |||
| encryption. Figure 1 shows the distribution system, which represents | encryption. Figure 1 shows the distribution system, which represents | |||
| the firmware server and the device management infrastructure. The | the firmware server and the device management infrastructure. The | |||
| skipping to change at page 11, line 37 ¶ | skipping to change at page 11, line 37 ¶ | |||
| Figure 6: COSE_Encrypt Example for AES Key Wrap | Figure 6: COSE_Encrypt Example for AES Key Wrap | |||
| The CEK, in hex format, was "4C805F1587D624ED5E0DBB7A7F7FA7EB" and | The CEK, in hex format, was "4C805F1587D624ED5E0DBB7A7F7FA7EB" and | |||
| the encrypted firmware (with a line feed added) was: | the encrypted firmware (with a line feed added) was: | |||
| A8B6E61EF17FBAD1F1BF3235B3C64C06098EA512223260 | A8B6E61EF17FBAD1F1BF3235B3C64C06098EA512223260 | |||
| F9425105F67F0FB6C92248AE289A025258F06C2AD70415 | F9425105F67F0FB6C92248AE289A025258F06C2AD70415 | |||
| 6. Hybrid Public-Key Encryption (HPKE) | 6. Hybrid Public-Key Encryption (HPKE) | |||
| Hybrid public-key encryption (HPKE) [I-D.irtf-cfrg-hpke] is a scheme | Hybrid public-key encryption (HPKE) [RFC9180] is a scheme that | |||
| that provides public key encryption of arbitrary-sized plaintexts | provides public key encryption of arbitrary-sized plaintexts given a | |||
| given a recipient's public key. | recipient's public key. | |||
| For use with firmware encryption the scheme works as follows: HPKE, | For use with firmware encryption the scheme works as follows: HPKE, | |||
| which internally utilizes a non-interactive ephemeral-static Diffie- | which internally utilizes a non-interactive ephemeral-static Diffie- | |||
| Hellman exchange to derive a shared secret, is used to encrypt a CEK. | Hellman exchange to derive a shared secret, is used to encrypt a CEK. | |||
| This CEK is subsequently used to encrypt the firmware image. Hence, | This CEK is subsequently used to encrypt the firmware image. Hence, | |||
| the plaintext passed to HPKE is the randomly generated CEK. The | the plaintext passed to HPKE is the randomly generated CEK. The | |||
| output of the HPKE SealBase function is therefore the encrypted CEK | output of the HPKE SealBase function is therefore the encrypted CEK | |||
| along with HPKE encapsulated key (i.e. the ephemeral ECDH public | along with HPKE encapsulated key (i.e. the ephemeral ECDH public | |||
| key). | key). | |||
| skipping to change at page 12, line 15 ¶ | skipping to change at page 12, line 15 ¶ | |||
| This approach allows all recipients to use the same CEK to encrypt | This approach allows all recipients to use the same CEK to encrypt | |||
| the firmware image, in case there are multiple recipients, to fulfill | the firmware image, in case there are multiple recipients, to fulfill | |||
| a requirement for the efficient distribution of firmware images using | a requirement for the efficient distribution of firmware images using | |||
| a multicast or broadcast protocol. | a multicast or broadcast protocol. | |||
| [I-D.ietf-cose-hpke] defines the use of HPKE with COSE. | [I-D.ietf-cose-hpke] defines the use of HPKE with COSE. | |||
| An example of the COSE_Encrypt structure using the HPKE scheme is | An example of the COSE_Encrypt structure using the HPKE scheme is | |||
| shown in Figure 7. It uses the following algorithm combination: | shown in Figure 7. It uses the following algorithm combination: | |||
| * AES-GCM-128 for encryption of the (detached) firmware image (at | * AES-GCM-128 for encryption of the (detached) firmware image. | |||
| layer 0). | ||||
| * AES-GCM-128 for encryption of the CEK in layer 1 as well as ECDH | * AES-GCM-128 for encryption of the CEK as well as ECDH with NIST | |||
| with NIST P-256 and HKDF-SHA256 as a Key Encapsulation Mechanism | P-256 and HKDF-SHA256 as a Key Encapsulation Mechanism (KEM). | |||
| (KEM). | ||||
| 96_0([ | 96_0([ | |||
| / protected header with alg=AES-GCM-128 / | / protected header with alg=AES-GCM-128 / | |||
| h'a10101', | h'a10101', | |||
| / unprotected header with nonce / | / unprotected header with nonce / | |||
| {5: h'938b528516193cc7123ff037809f4c2a'}, | {5: h'938b528516193cc7123ff037809f4c2a'}, | |||
| / detached ciphertext / | / detached ciphertext / | |||
| null, | null, | |||
| / recipient structure / | / recipient structure / | |||
| [ | [ | |||
| skipping to change at page 13, line 8 ¶ | skipping to change at page 13, line 8 ¶ | |||
| h'9aba6fa44e9b2cef9d646614dcda670dbdb31a3b9d37c7a | h'9aba6fa44e9b2cef9d646614dcda670dbdb31a3b9d37c7a | |||
| 65b099a8152533062', | 65b099a8152533062', | |||
| ], | ], | |||
| ]) | ]) | |||
| Figure 7: COSE_Encrypt Example for HPKE | Figure 7: COSE_Encrypt Example for HPKE | |||
| 7. CEK Verification | 7. CEK Verification | |||
| The suit-cek-verification parameter contains a byte string resulting | The suit-cek-verification parameter contains a byte string resulting | |||
| from the encryption of 8 bytes of 0xA5 using the CEK. | from the encryption of 8 bytes of 0xA5 using the CEK with a nonce of | |||
| all zeros and empty additional data using the cipher algorithm and | ||||
| mode also used to encrypt the plaintext. | ||||
| [[Editor's Note: Guidance about the selection of an IV needs to be | As explained in Section 3, the suit-cek-verification parameter is | |||
| added here.]] | optional to implement and optional to use. When used, it reduces the | |||
| risk of an battery exhaustion attack against the IoT device. | ||||
| 8. Complete Examples | 8. Complete Examples | |||
| [[Editor's Note: Add examples for a complete manifest here (including | [[Editor's Note: Add examples for a complete manifest here (including | |||
| a digital signature), multiple recipients, encryption of manifests | a digital signature), multiple recipients, encryption of manifests | |||
| (in comparison to firmware images).]] | (in comparison to firmware images).]] | |||
| 9. Security Considerations | 9. Security Considerations | |||
| The algorithms described in this document assume that the party | The algorithms described in this document assume that the party | |||
| skipping to change at page 14, line 17 ¶ | skipping to change at page 14, line 17 ¶ | |||
| This document does not require any actions by IANA. | This document does not require any actions by IANA. | |||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [I-D.ietf-cose-hpke] | [I-D.ietf-cose-hpke] | |||
| Tschofenig, H., Housley, R., and B. Moran, "Use of Hybrid | Tschofenig, H., Housley, R., and B. Moran, "Use of Hybrid | |||
| Public-Key Encryption (HPKE) with CBOR Object Signing and | Public-Key Encryption (HPKE) with CBOR Object Signing and | |||
| Encryption (COSE)", Work in Progress, Internet-Draft, | Encryption (COSE)", Work in Progress, Internet-Draft, | |||
| draft-ietf-cose-hpke-00, 10 January 2022, | draft-ietf-cose-hpke-01, 7 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-cose-hpke- | <https://www.ietf.org/archive/id/draft-ietf-cose-hpke- | |||
| 00.txt>. | 01.txt>. | |||
| [I-D.ietf-suit-manifest] | [I-D.ietf-suit-manifest] | |||
| Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, | Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, | |||
| "A Concise Binary Object Representation (CBOR)-based | "A Concise Binary Object Representation (CBOR)-based | |||
| Serialization Format for the Software Updates for Internet | Serialization Format for the Software Updates for Internet | |||
| of Things (SUIT) Manifest", Work in Progress, Internet- | of Things (SUIT) Manifest", Work in Progress, Internet- | |||
| Draft, draft-ietf-suit-manifest-16, 25 October 2021, | Draft, draft-ietf-suit-manifest-16, 25 October 2021, | |||
| <https://www.ietf.org/archive/id/draft-ietf-suit-manifest- | <https://www.ietf.org/archive/id/draft-ietf-suit-manifest- | |||
| 16.txt>. | 16.txt>. | |||
| [I-D.irtf-cfrg-hpke] | ||||
| Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, | ||||
| "Hybrid Public Key Encryption", Work in Progress, | ||||
| Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, | ||||
| <https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke- | ||||
| 12.txt>. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard | [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard | |||
| (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, | (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, | |||
| September 2002, <https://www.rfc-editor.org/info/rfc3394>. | September 2002, <https://www.rfc-editor.org/info/rfc3394>. | |||
| [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | |||
| RFC 8152, DOI 10.17487/RFC8152, July 2017, | RFC 8152, DOI 10.17487/RFC8152, July 2017, | |||
| <https://www.rfc-editor.org/info/rfc8152>. | <https://www.rfc-editor.org/info/rfc8152>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid | ||||
| Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, | ||||
| February 2022, <https://www.rfc-editor.org/info/rfc9180>. | ||||
| 11.2. Informative References | 11.2. Informative References | |||
| [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, | [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, | |||
| DOI 10.17487/RFC2630, June 1999, | DOI 10.17487/RFC2630, June 1999, | |||
| <https://www.rfc-editor.org/info/rfc2630>. | <https://www.rfc-editor.org/info/rfc2630>. | |||
| [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", | [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", | |||
| FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, | FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, | |||
| <https://www.rfc-editor.org/info/rfc4949>. | <https://www.rfc-editor.org/info/rfc4949>. | |||
| End of changes. 18 change blocks. | ||||
| 30 lines changed or deleted | 38 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||