< 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/