< draft-ietf-suit-firmware-encryption-02.txt		draft-ietf-suit-firmware-encryption-03.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: April 28, 2022 Vigil Security		Expires: 8 September 2022 Vigil Security
	B. Moran		B. Moran
	Arm Limited		Arm Limited
	October 25, 2021		7 March 2022
	Firmware Encryption with SUIT Manifests		Firmware Encryption with SUIT Manifests
	draft-ietf-suit-firmware-encryption-02		draft-ietf-suit-firmware-encryption-03
	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.		encrypted using AES-GCM or AES-CCM.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 April 28, 2022.		This Internet-Draft will expire on 8 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified 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
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 28 ¶
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . . . 15		7. CEK Verification . . . . . . . . . . . . . . . . . . . . . . 13
	8. Complete Examples . . . . . . . . . . . . . . . . . . . . . . 15		8. Complete Examples . . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 16		9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 16		11.1. Normative References . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		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
	IoT device, where to find the firmware image, and the devices to		IoT device, where to find the firmware image, and the devices to
	which it applies.		which it applies.
	The SUIT information model [I-D.ietf-suit-information-model] details		The SUIT information model [RFC9124] details the information that has
	the information that has to be offered by the SUIT manifest format.		to be offered by the SUIT manifest format. In addition to offering
	In addition to offering protection against modification, which is		protection against modification, which is provided by a digital
	provided by a digital signature or a message authentication code, the		signature or a message authentication code, the firmware image may
	firmware image may also be afforded confidentiality using encryption.		also be afforded confidentiality using encryption.
	Encryption prevents third parties, including attackers, from gaining		Encryption prevents third parties, including attackers, from gaining
	access to the firmware binary. Hackers typically need intimate		access to the firmware binary. Hackers typically need intimate
	knowledge of the target firmware to mount their attacks. For		knowledge of the target firmware to mount their attacks. For
	example, return-oriented programming (ROP) requires access to the		example, return-oriented programming (ROP) requires access to the
	binary and encryption makes it much more difficult to write exploits.		binary and encryption makes it much more difficult to write exploits.
	The SUIT manifest provides the data needed for authorized recipients		The SUIT manifest provides the data needed for authorized recipients
	of the firmware image to decrypt it. The firmware image is encrypted		of the firmware image to decrypt it. The firmware image is encrypted
	using a symmetric key. This symmetric cryptographic key is		using a symmetric key. This symmetric cryptographic key is
	established for encryption and decryption, and that key can be		established for encryption and decryption, and that key can be
	applied to a SUIT manifest, firmware images, or personalization data,		applied to a SUIT manifest, firmware images, or personalization data,
	depending on the encryption choices of the firmware author.		depending on the encryption choices of the firmware author.
	A symmetric key can be established using a variety of mechanisms;		A symmetric key can be established using a variety of mechanisms;
	this document defines two approaches for use with the IETF SUIT		this document defines two approaches for use with the IETF SUIT
	manifest, namely:		manifest, namely:
	- hybrid public-key encryption (HPKE), and		* hybrid public-key encryption (HPKE), and
	- AES Key Wrap (AES-KW) using a pre-shared key-encryption key (KEK).		* AES Key Wrap (AES-KW) using a pre-shared key-encryption key (KEK).
	These choices reduce the number of possible key establishment options		These choices reduce the number of possible key establishment options
	and thereby help increase interoperability between different SUIT		and thereby help increase interoperability between different SUIT
	manifest parser implementations.		manifest parser implementations.
	The document also contains a number of examples.		The document also contains a number of examples.
	2. Conventions and Terminology		2. Conventions and Terminology
	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		[I-D.ietf-suit-manifest], the SUIT information model [RFC9124] and
	[I-D.ietf-suit-information-model] and the SUIT architecture		the SUIT architecture [RFC9019].
	[RFC9019].
	The terms sender and recipient are defined in [I-D.irtf-cfrg-hpke]		The terms sender and recipient are defined in [I-D.irtf-cfrg-hpke]
	and have the following meaning:		and have the 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
	[I-D.irtf-cfrg-hpke].		[I-D.irtf-cfrg-hpke].
	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
	skipping to change at page 5, line 46 ¶		skipping to change at page 5, line 46 ¶
	recipient.		recipient.
	The firmware author may have knowledge about all devices that need to		The firmware author may have knowledge about all devices that need to
	receive an encrypted firmware image but in most cases this will not		receive an encrypted firmware image but in most cases this will not
	be likely. The distribution system certainly has the knowledge about		be likely. The distribution system certainly has the knowledge about
	the recipients to perform firmware encryption.		the recipients to perform firmware encryption.
	To offer confidentiality protection for firmware images two		To offer confidentiality protection for firmware images two
	deployment variants need to be supported:		deployment variants need to be supported:
	- The firmware author acts as the sender and the recipient is the		* The firmware author acts as the sender and the recipient is the
	firmware consumer (or the firmware consumers).		firmware consumer (or the firmware consumers).
	- The firmware author encrypts the firmware image with the		* The firmware author encrypts the firmware image with the
	distribution system as the initial recipient. Then, the		distribution system as the initial recipient. Then, the
	distribution system decrypts and re-encrypts the firmware image		distribution system decrypts and re-encrypts the firmware image
	towards the firmware consumer(s). Delegating the task of re-		towards the firmware consumer(s). Delegating the task of re-
	encrypting the firmware image to the distribution system offers		encrypting the firmware image to the distribution system offers
	flexiblity when the number of devices that need to receive		flexiblity when the number of devices that need to receive
	encrypted firmware images changes dynamically or when updates to		encrypted firmware images changes dynamically or when updates to
	KEKs or recipient public keys are necessary. As a downside, the		KEKs or recipient public keys are necessary. As a downside, the
	author needs to trust the distribution system with performing the		author needs to trust the distribution system with performing the
	re-encryption of the firmware image.		re-encryption of the firmware image.
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 14 ¶
	When the firmware image is encrypted for use by multiple recipients,		When the firmware image is encrypted for use by multiple recipients,
	there are three options. We use the following notation KEK(R1,S) is		there are three options. We use the following notation KEK(R1,S) is
	the KEK shared between recipient R1 and the sender S. Likewise,		the KEK shared between recipient R1 and the sender S. Likewise,
	CEK(R1,S) is shared between R1 and S. If a single CEK or a single		CEK(R1,S) is shared between R1 and S. If a single CEK or a single
	KEK is shared with all authorized recipients R by a given sender S in		KEK is shared with all authorized recipients R by a given sender S in
	a certain context then we use CEK(_,S) or KEK(_,S), respectively.		a certain context then we use CEK(_,S) or KEK(_,S), respectively.
	The notation ENC(plaintext, key) refers to the encryption of		The notation ENC(plaintext, key) refers to the encryption of
	plaintext with a given key.		plaintext with a given key.
	- If all authorized recipients have access to the KEK, a single		* If all authorized recipients have access to the KEK, a single
	COSE_recipient structure contains the encrypted CEK. This means		COSE_recipient structure contains the encrypted CEK. This means
	KEK(*,S) ENC(CEK,KEK), and ENC(firmware,CEK).		KEK(*,S) ENC(CEK,KEK), and ENC(firmware,CEK).
	- If recipients have different KEKs, then multiple COSE_recipient		* If recipients have different KEKs, then multiple COSE_recipient
	structures are included but only a single CEK is used. Each		structures are included but only a single CEK is used. Each
	COSE_recipient structure contains the CEK encrypted with the KEKs		COSE_recipient structure contains the CEK encrypted with the KEKs
	appropriate for the recipient. In short, KEK_1(R1, S), ...,		appropriate for the recipient. In short, KEK_1(R1, S),...,
	KEK_n(Rn, S), ENC(CEK, KEK_i) for i=1 to n, and ENC(firmware,CEK).		KEK_n(Rn, S), ENC(CEK, KEK_i) for i=1 to n, and ENC(firmware,CEK).
	The benefit of this approach is that the firmware image is		The benefit of this approach is that the firmware image is
	encrypted only once with a CEK while there is no sharing of the		encrypted only once with a CEK while there is no sharing of the
	KEK accross recipients. Hence, authorized recipients still use		KEK accross recipients. Hence, authorized recipients still use
	their individual KEKs to decrypt the CEK and to subsequently		their individual KEKs to decrypt the CEK and to subsequently
	obtain the plaintext firmware.		obtain the plaintext firmware.
	- The third option is to use different CEKs encrypted with KEKs of		* The third option is to use different CEKs encrypted with KEKs of
	the authorized recipients. Assume there are KEK_1(R1, S),...,		the authorized recipients. Assume there are KEK_1(R1, S),...,
	KEK_n(Rn, S), and for i=1 to n the following computations need to		KEK_n(Rn, S), and for i=1 to n the following computations need to
	be made: ENC(CEK_i, KEK_i) and ENC(firmware,CEK_i). This approach		be made: ENC(CEK_i, KEK_i) and ENC(firmware,CEK_i). This approach
	is appropriate when no benefits can be gained from encrypting and		is appropriate when no benefits can be gained from encrypting and
	transmitting firmware images only once. For example, firmware		transmitting firmware images only once. For example, firmware
	images may contain information unique to a device instance.		images may contain information unique to a device instance.
	Note that the AES-KW algorithm, as defined in Section 2.2.3.1 of		Note that the AES-KW algorithm, as defined in Section 2.2.3.1 of
	[RFC3394], does not have public parameters that vary on a per-		[RFC3394], does not have public parameters that vary on a per-
	invocation basis. Hence, the protected structure in the		invocation basis. Hence, the protected structure in the
	skipping to change at page 9, line 41 ¶		skipping to change at page 9, line 41 ¶
	ciphertext : bstr ; CEK encrypted with KEK		ciphertext : bstr ; CEK encrypted with KEK
	]		]
	recipient_header_map =		recipient_header_map =
	{		{
	1 => int, ; algorithm identifier		1 => int, ; algorithm identifier
	4 => bstr, ; key identifier		4 => bstr, ; key identifier
	* label =values ; extension point		* label =values ; extension point
	}		}
	Figure 4: CDDL for AES Key Wrap Encryption		Figure 4: CDDL for AES Key Wrap Encryption
	The COSE specification requires a consistent byte stream for the		The COSE specification requires a consistent byte stream for the
	authenticated data structure to be created, which is shown in		authenticated data structure to be created, which is shown in
	Figure 5.		Figure 5.
	Enc_structure = [		Enc_structure = [
	context : "Encrypt",		context : "Encrypt",
	protected : empty_or_serialized_map,		protected : empty_or_serialized_map,
	external_aad : bstr		external_aad : bstr
	]		]
	skipping to change at page 10, line 10 ¶		skipping to change at page 10, line 4 ¶
	The COSE specification requires a consistent byte stream for the		The COSE specification requires a consistent byte stream for the
	authenticated data structure to be created, which is shown in		authenticated data structure to be created, which is shown in
	Figure 5.		Figure 5.
	Enc_structure = [		Enc_structure = [
	context : "Encrypt",		context : "Encrypt",
	protected : empty_or_serialized_map,		protected : empty_or_serialized_map,
	external_aad : bstr		external_aad : bstr
	]		]
	Figure 5: CDDL for Enc_structure Data Structure		Figure 5: CDDL for Enc_structure Data Structure
	As shown in Figure 4, there are two protected fields: one protected		As shown in Figure 4, there are two protected fields: one protected
	field in the COSE_Encrypt structure and a second one in the		field in the COSE_Encrypt structure and a second one in the
	COSE_recipient structure. The 'protected' field in the		COSE_recipient structure. The 'protected' field in the
	Enc_structure, see Figure 5, refers to the content of the protected		Enc_structure, see Figure 5, refers to the content of the protected
	field from the COSE_Encrypt structure.		field from the COSE_Encrypt structure.
	The value of the external_aad MUST be set to null.		The value of the external_aad MUST be set to null.
	The following example illustrates the use of the AES-KW algorithm		The following example illustrates the use of the AES-KW algorithm
	with AES-128.		with AES-128.
	We use the following parameters in this example:		We use the following parameters in this example:
	- IV: 0x26, 0x68, 0x23, 0x06, 0xd4, 0xfb, 0x28, 0xca, 0x01, 0xb4,		* IV: 0x26, 0x68, 0x23, 0x06, 0xd4, 0xfb, 0x28, 0xca, 0x01, 0xb4,
	0x3b, 0x80		0x3b, 0x80
	- KEK: "aaaaaaaaaaaaaaaa"		* KEK: "aaaaaaaaaaaaaaaa"
	- KID: "kid-1"		* KID: "kid-1"
	- Plaintext Firmware: "This is a real firmware image."		* Plaintext Firmware: "This is a real firmware image."
	- Firmware (hex):		* Firmware (hex):
	546869732069732061207265616C206669726D7761726520696D6167652E		546869732069732061207265616C206669726D7761726520696D6167652E
	The COSE_Encrypt structure, in hex format, is (with a line break		The COSE_Encrypt structure, in hex format, is (with a line break
	inserted):		inserted):
	D8608443A10101A1054C26682306D4FB28CA01B43B80F68340A2012204456B69642D		D8608443A10101A1054C26682306D4FB28CA01B43B80F68340A2012204456B69642D
	315818AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D		315818AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D
	The resulting COSE_Encrypt structure in a dignostic format is shown		The resulting COSE_Encrypt structure in a dignostic format is shown
	in Figure 6.		in Figure 6.
	96(		96(
	[		[
	// protected field with alg=AES-GCM-128		/ protected field with alg=AES-GCM-128 /
	h'A10101',		h'A10101',
	{		{
	// unprotected field with iv		/ unprotected field with iv /
	5: h'26682306D4FB28CA01B43B80'		5: h'26682306D4FB28CA01B43B80'
	},		},
	// null because of detached ciphertext		/ null because of detached ciphertext /
	null,		null,
	[ // recipients array		[ / recipients array /
	h'', // protected field		h'', / protected field /
	{ // unprotected field		{ / unprotected field /
	1: -3, // alg=A128KW		1: -3, / alg=A128KW /
	4: h'6B69642D31' // key id		4: h'6B69642D31' / key id /
	},		},
	// CEK encrypted with KEK		/ CEK encrypted with KEK /
	h'AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D'		h'AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D'
	]		]
	]		]
	)		)
	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:
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 10 ¶
	Only the holder of recipient's private key can decapsulate the CEK to		Only the holder of recipient's private key can decapsulate the CEK to
	decrypt the firmware. Key generation in HPKE is influced by		decrypt the firmware. Key generation in HPKE is influced by
	additional parameters, such as identity information.		additional parameters, such as identity information.
	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.
	[cose-hpke] defines the use of HPKE with COSE and this specification		[I-D.ietf-cose-hpke] defines the use of HPKE with COSE.
	profiles it.
	COSE_Encrypt_Tagged = #6.96(COSE_Encrypt)
	SUIT_Encryption_Info = COSE_Encrypt_Tagged
	; Layer 0
	COSE_Encrypt = [
	protected : bstr .cbor header_map, ; must contain alg
	unprotected : header_map, ; must contain iv
	ciphertext : null, ; because of detached ciphertext
	recipients : [+COSE_recipient_outer]
	]
	; Layer 1
	COSE_recipient_outer = [
	protected : bstr .size 0,
	unprotected : header_map, ; must contain alg
	encCEK : bstr, ; CEK encrypted based on HPKE algo
	recipients : [ + COSE_recipient_inner ]
	]
	; Layer 2
	COSE_recipient_inner = [
	protected : bstr .cbor header_map, ; must contain HPKE alg
	unprotected : header_map, ; must contain kid and ephemeral public key
	empty : null,
	empty : null
	]
	header_map = {
	Generic_Headers,
	* label =values,
	}
	Generic_Headers = (
	? 1 => int, ; algorithm identifier
	? 2 => crv, ; EC identifier
	? 4 => bstr, ; key identifier
	? 5 => bstr ; IV
	)
	Figure 7: CDDL for HPKE-based COSE_Encrypt Structure
	The COSE_Encrypt structure (layer 0) contains algorithm parameters
	for encryption of the firmware image. The protected field MUST
	contain the 'alg' parameter and the unprotected field MUST contain
	the 'iv' parameter. The ciphertext is always detached.
	The COSE_recipient_outer structure (layer 1) contains the encrypted
	CEK. The protected structure MUST be empty and the unprotected
	structure MUST contain the 'alg' parameter, which carries the
	algorithm information for protecting the CEK.
	The COSE_recipient_inner structure (layer 2) contains the HPKE-
	related information. The protected structure MUST contain the 'alg'
	parameter set to the algorithm values in Section 6 of [cose-hpke] and
	the unprotected structure MUST contain the 'kid' and the 'ephemeral'
	parameter.
	To populate the SUIT_Encryption_Info structure the sender creates a
	CEK randomly. The CEK is used to encrypt the firmware image with the
	selected algorithm.
	The HPKE SealBase function takes various input parameters, as
	explained in [cose-hpke]. The most important input parameters are
	the plaintext (CEK in our case) and the public key of the recipient.
	If successful, SealBase will return the encrypted CEK and the
	ephemeral public key.
	The recipient receives the ephemeral public key and the encrypted CEK
	from the sender. It then uses the HPKE OpenBase function to decrypt
	the ciphertext (which contains the CEK).
	If the HPKE OpenBase function is successful, the recipient obtains
	the CEK and can decrypt the firmware. The decryption operation is
	shown in Figure 4 of [cose-hpke].
	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 8. It uses the following algorithm combination:		shown in Figure 7. It uses the following algorithm combination:
	- AES-GCM-128 for encryption of the firmware image.
	- AES-GCM-128 for encrytion of the CEK.
	- Key Encapsulation Mechanism (KEM): NIST P-256		* AES-GCM-128 for encryption of the (detached) firmware image (at
			layer 0).
	- Key Derivation Function (KDF): HKDF-SHA256		* AES-GCM-128 for encryption of the CEK in layer 1 as well as ECDH
			with NIST P-256 and HKDF-SHA256 as a Key Encapsulation Mechanism
			(KEM).
	96(		96_0([
	[		/ protected header with alg=AES-GCM-128 /
	// protected field with alg=AES-GCM-128		h'a10101',
	h'A10101',		/ unprotected header with nonce /
	{ // unprotected field with iv		{5: h'938b528516193cc7123ff037809f4c2a'},
	5: h'26682306D4FB28CA01B43B80'		/ detached ciphertext /
	},		null,
	// null because of detached ciphertext		/ recipient structure /
	null,		[
	[ // COSE_recipient_outer		/ protected field with alg for HPKE /
	h'', // empty protected field		h'a1013863',
	{ // unprotected field with ...		/ unprotected header /
	1: 1 // alg=A128GCM		{
	},		/ ephemeral public key with x / y coodinate /
	// Encrypted CEK		-1: h'a401022001215820a596f2ca8d159c04942308ca90
	h'FA55A50CF110908DA6443149F2C2062011A7D8333A72721A',		cfbfca65b108ca127df8fe191a063d00d7c5172258
	[ // COSE_recipient_inner		20aef47a45d6d6c572e7bd1b9f3e69b50ad3875c68
	// protected field with alg HPKE/P-256+HKDF-256 (new)		f6da0caaa90c675df4162c39',
	h'A1013818',		/ kid for recipient static ECDH public key /
	{ // unprotected field with ...		4: h'6b69642d32',
	// HPKE encapsulated key		},
	-1: h'A4010220012158205F...979D51687187510C445',		/ encrypted CEK /
	// kid for recipient static ECDH public key		h'9aba6fa44e9b2cef9d646614dcda670dbdb31a3b9d37c7a
	4: h'6B69642D31'		65b099a8152533062',
	},		],
	// empty ciphertext		])
	null
	]
	]
	]
	)
	Figure 8: 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.
	[[Editor's Note: Guidance about the selection of an IV needs to be		[[Editor's Note: Guidance about the selection of an IV needs to be
	added here.]]		added here.]]
	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
	performing the firmware encryption		performing the firmware encryption
	- shares a key-encryption key (KEK) with the firmware consumer (for		* shares a key-encryption key (KEK) with the firmware consumer (for
	use with the AES-Key Wrap scheme), or		use with the AES-Key Wrap scheme), or
	- is in possession of the public key of the firmware consumer (for		* is in possession of the public key of the firmware consumer (for
	use with HPKE).		use with HPKE).
	Both cases require some upfront communication interaction, which is		Both cases require some upfront communication interaction, which is
	not part of the SUIT manifest. This interaction is likely provided		not part of the SUIT manifest. This interaction is likely provided
	by an IoT device management solution, as described in [RFC9019].		by an IoT device management solution, as described in [RFC9019].
	For AES-Key Wrap to provide high security it is important that the		For AES-Key Wrap to provide high security it is important that the
	KEK is of high entropy, and that implementations protect the KEK from		KEK is of high entropy, and that implementations protect the KEK from
	disclosure. Compromise of the KEK may result in the disclosure of		disclosure. Compromise of the KEK may result in the disclosure of
	all key data protected with that KEK.		all key data protected with that KEK.
	skipping to change at page 16, line 45 ¶		skipping to change at page 14, line 13 ¶
	when such a binary analysis is desired.		when such a binary analysis is desired.
	10. IANA Considerations		10. IANA Considerations
	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
	[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)", October 2021,		Encryption (COSE)", Work in Progress, Internet-Draft,
	<https://datatracker.ietf.org/doc/html/		draft-ietf-cose-hpke-00, 10 January 2022,
	draft-tschofenig-cose-hpke-00>.		<https://www.ietf.org/archive/id/draft-ietf-cose-hpke-
			00.txt>.
	[I-D.ietf-suit-manifest]		[I-D.ietf-suit-manifest]
	Arm Limited, Arm Limited, Fraunhofer SIT, and Inria, "A		Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
	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", draft-ietf-suit-manifest-14		of Things (SUIT) Manifest", Work in Progress, Internet-
	(work in progress), July 2021.		Draft, draft-ietf-suit-manifest-16, 25 October 2021,
			<https://www.ietf.org/archive/id/draft-ietf-suit-manifest-
			16.txt>.
	[I-D.irtf-cfrg-hpke]		[I-D.irtf-cfrg-hpke]
	Cisco, Inria, Inria, and Cloudflare, "Hybrid Public Key		Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood,
	Encryption", draft-irtf-cfrg-hpke-12 (work in progress),		"Hybrid Public Key Encryption", Work in Progress,
	September 2021.		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>.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-suit-information-model]
	Arm Limited, Arm Limited, and Fraunhofer SIT, "A Manifest
	Information Model for Firmware Updates in IoT Devices",
	draft-ietf-suit-information-model-13 (work in progress),
	July 2021.
	[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>.
	[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,		[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
	and C. Wood, "Randomness Improvements for Security		and C. Wood, "Randomness Improvements for Security
	Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,		Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
	<https://www.rfc-editor.org/info/rfc8937>.		<https://www.rfc-editor.org/info/rfc8937>.
	[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A		[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
	Firmware Update Architecture for Internet of Things",		Firmware Update Architecture for Internet of Things",
	RFC 9019, DOI 10.17487/RFC9019, April 2021,		RFC 9019, DOI 10.17487/RFC9019, April 2021,
	<https://www.rfc-editor.org/info/rfc9019>.		<https://www.rfc-editor.org/info/rfc9019>.
			[RFC9124] Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest
			Information Model for Firmware Updates in Internet of
			Things (IoT) Devices", RFC 9124, DOI 10.17487/RFC9124,
			January 2022, <https://www.rfc-editor.org/info/rfc9124>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	We would like to thank Henk Birkholz for his feedback on the CDDL		We would like to thank Henk Birkholz for his feedback on the CDDL
	description in this document. Additionally, we would like to thank		description in this document. Additionally, we would like to thank
	Michael Richardson and Carsten Bormann for their review feedback.		Michael Richardson and Carsten Bormann for their review feedback.
	Finally, we would like to thank Dick Brooks for making us aware of		Finally, we would like to thank Dick Brooks for making us aware of
	the challenges firmware encryption imposes on binary analysis.		the challenges firmware encryption imposes on binary analysis.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Arm Limited		Arm Limited
			Email: hannes.tschofenig@arm.com
	EMail: hannes.tschofenig@arm.com
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
			Email: housley@vigilsec.com
	EMail: housley@vigilsec.com
	Brendan Moran		Brendan Moran
	Arm Limited		Arm Limited
			Email: Brendan.Moran@arm.com
	EMail: Brendan.Moran@arm.com
End of changes. 53 change blocks.
	200 lines changed or deleted		116 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/