< draft-ietf-suit-architecture-10.txt		draft-ietf-suit-architecture-11.txt >
	skipping to change at page 1, line 13 ¶		skipping to change at page 1, line 13 ¶
	SUIT B. Moran		SUIT B. Moran
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Intended status: Informational Arm Limited		Intended status: Informational Arm Limited
	Expires: November 28, 2020 D. Brown		Expires: November 28, 2020 D. Brown
	Linaro		Linaro
	M. Meriac		M. Meriac
	Consultant		Consultant
	May 27, 2020		May 27, 2020
	A Firmware Update Architecture for Internet of Things		A Firmware Update Architecture for Internet of Things
	draft-ietf-suit-architecture-10		draft-ietf-suit-architecture-11
	Abstract		Abstract
	Vulnerabilities with Internet of Things (IoT) devices have raised the		Vulnerabilities with Internet of Things (IoT) devices have raised the
	need for a solid and secure firmware update mechanism that is also		need for a solid and secure firmware update mechanism that is also
	suitable for constrained devices. Incorporating such update		suitable for constrained devices. Incorporating such update
	mechanism to fix vulnerabilities, to update configuration settings as		mechanism to fix vulnerabilities, to update configuration settings as
	well as adding new functionality is recommended by security experts.		well as adding new functionality is recommended by security experts.
	This document lists requirements and describes an architecture for a		This document lists requirements and describes an architecture for a
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other
	than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Agnostic to how firmware images are distributed . . . . . 8		3.1. Agnostic to how firmware images are distributed . . . . . 7
	3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 8		3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 7
	3.3. Use state-of-the-art security mechanisms . . . . . . . . 8		3.3. Use state-of-the-art security mechanisms . . . . . . . . 8
	3.4. Rollback attacks must be prevented . . . . . . . . . . . 9		3.4. Rollback attacks must be prevented . . . . . . . . . . . 8
	3.5. High reliability . . . . . . . . . . . . . . . . . . . . 9		3.5. High reliability . . . . . . . . . . . . . . . . . . . . 8
	3.6. Operate with a small bootloader . . . . . . . . . . . . . 9		3.6. Operate with a small bootloader . . . . . . . . . . . . . 9
	3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 10		3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 10
	3.8. Minimal impact on existing firmware formats . . . . . . . 10		3.8. Minimal impact on existing firmware formats . . . . . . . 10
	3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 10		3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 10
	3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 11		3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 10
	3.11. Suitability to software and personalization data . . . . 13		3.11. Suitability to software and personalization data . . . . 12
	4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Communication Architecture . . . . . . . . . . . . . . . . . 14		5. Communication Architecture . . . . . . . . . . . . . . . . . 13
	6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 18		6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	7. Device Firmware Update Examples . . . . . . . . . . . . . . . 19		7. Device Firmware Update Examples . . . . . . . . . . . . . . . 18
	7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 19		7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 18
	7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 19		7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 18
	7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 19		7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 18
	7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 19		7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 18
	8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 20		8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 26		11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	12. Mailing List Information . . . . . . . . . . . . . . . . . . 27		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27		13. Informative References . . . . . . . . . . . . . . . . . . . 27
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	14.1. Normative References . . . . . . . . . . . . . . . . . . 28
	14.2. Informative References . . . . . . . . . . . . . . . . . 28
	14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	When developing Internet of Things (IoT) devices, one of the most		When developing Internet of Things (IoT) devices, one of the most
	difficult problems to solve is how to update firmware on the device.		difficult problems to solve is how to update firmware on the device.
	Once the device is deployed, firmware updates play a critical part in		Once the device is deployed, firmware updates play a critical part in
	its lifetime, particularly when devices have a long lifetime, are		its lifetime, particularly when devices have a long lifetime, are
	deployed in remote or inaccessible areas where manual intervention is		deployed in remote or inaccessible areas where manual intervention is
	cost prohibitive or otherwise difficult. Updates to the firmware of		cost prohibitive or otherwise difficult. Updates to the firmware of
	an IoT device are done to fix bugs in software, to add new		an IoT device are done to fix bugs in software, to add new
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 29 ¶
	to mount an attack since it gives the adversary valuable insights		to mount an attack since it gives the adversary valuable insights
	into used software libraries, configuration settings and generic		into used software libraries, configuration settings and generic
	functionality (even though reverse engineering the binary can be a		functionality (even though reverse engineering the binary can be a
	tedious process).		tedious process).
	This version of the document assumes asymmetric cryptography and a		This version of the document assumes asymmetric cryptography and a
	public key infrastructure. Future versions may also describe a		public key infrastructure. Future versions may also describe a
	symmetric key approach for very constrained devices.		symmetric key approach for very constrained devices.
	While the standardization work has been informed by and optimised for		While the standardization work has been informed by and optimised for
	firmware update use cases of Class 1 (as defined in RFC 7228		firmware update use cases of Class 1 devices (according to the device
	[RFC7228]) devices, there is nothing in the architecture that		class definitions in RFC 7228 [RFC7228]), there is nothing in the
	restricts its use to only these constrained IoT devices. Software		architecture that restricts its use to only these constrained IoT
	update and delivery of arbitrary data, such as configuration		devices. Software update and delivery of arbitrary data, such as
	information and keys, can equally be managed by manifests.		configuration information and keys, can equally be managed by
			manifests.
	More details about the security goals are discussed in Section 5 and		More details about the security goals are discussed in Section 5 and
	requirements are described in Section 3.		requirements are described in Section 3.
	2. Conventions and Terminology		2. Conventions and Terminology
	This document uses the following terms:		This document uses the following terms:
	- Manifest: The manifest contains meta-data about the firmware		- Manifest: The manifest contains meta-data about the firmware
	image. The manifest is protected against modification and		image. The manifest is protected against modification and
	skipping to change at page 9, line 4 ¶		skipping to change at page 8, line 33 ¶
	For confidentiality protection of the firmware image, it must be done		For confidentiality protection of the firmware image, it must be done
	in such a way that every intended recipient can decrypt it. The		in such a way that every intended recipient can decrypt it. The
	information that is encrypted individually for each device must		information that is encrypted individually for each device must
	maintain friendliness to Content Distribution Networks, bulk storage,		maintain friendliness to Content Distribution Networks, bulk storage,
	and broadcast protocols.		and broadcast protocols.
	A manifest specification must support different cryptographic		A manifest specification must support different cryptographic
	algorithms and algorithm extensibility. Due of the nature of		algorithms and algorithm extensibility. Due of the nature of
	unchangeable code in ROM for use with bootloaders the use of post-		unchangeable code in ROM for use with bootloaders the use of post-
	quantum secure signature mechanisms, such as hash-based signatures		quantum secure signature mechanisms, such as hash-based signatures
			[RFC8778], are attractive. These algorithms maintain security in
	[I-D.ietf-cose-hash-sig], are attractive. These algorithms maintain		presence of quantum computers.
	security in presence of quantum computers.
	A mandatory-to-implement set of algorithms will be specified in the		A mandatory-to-implement set of algorithms will be specified in the
	manifest specification [I-D.ietf-suit-manifest]}.		manifest specification [I-D.ietf-suit-manifest]}.
	3.4. Rollback attacks must be prevented		3.4. Rollback attacks must be prevented
	A device presented with an old, but valid manifest and firmware must		A device presented with an old, but valid manifest and firmware must
	not be tricked into installing such firmware since a vulnerability in		not be tricked into installing such firmware since a vulnerability in
	the old firmware image may allow an attacker to gain control of the		the old firmware image may allow an attacker to gain control of the
	device.		device.
	skipping to change at page 27, line 5 ¶		skipping to change at page 26, line 5 ¶
	involvement.		involvement.
	- energy efficiency and battery lifetime considerations.		- energy efficiency and battery lifetime considerations.
	- key management required for verifying the digital signature		- key management required for verifying the digital signature
	protecting the manifest.		protecting the manifest.
	- incentives for manufacturers to offer a firmware update mechanism		- incentives for manufacturers to offer a firmware update mechanism
	as part of their IoT products.		as part of their IoT products.
	12. Mailing List Information		12. Acknowledgements
	The discussion list for this document is located at the e-mail
	address suit@ietf.org [1]. Information on the group and information
	on how to subscribe to the list is at
	https://www1.ietf.org/mailman/listinfo/suit [2]
	Archives of the list can be found at: https://www.ietf.org/mail-
	archive/web/suit/current/index.html [3]
	13. Acknowledgements
	We would like to thank the following persons for their feedback:		We would like to thank the following persons for their feedback:
	- Geraint Luff		- Geraint Luff
	- Amyas Phillips		- Amyas Phillips
	- Dan Ros		- Dan Ros
	- Thomas Eichinger		- Thomas Eichinger
	skipping to change at page 28, line 4 ¶		skipping to change at page 26, line 42 ¶
	- Phillip Hallam-Baker		- Phillip Hallam-Baker
	- Marti Bolivar		- Marti Bolivar
	- Andrzej Puzdrowski		- Andrzej Puzdrowski
	- Markus Gueller		- Markus Gueller
	- Henk Birkholz		- Henk Birkholz
	- Jintao Zhu		- Jintao Zhu
	- Takeshi Takahashi		- Takeshi Takahashi
	- Jacob Beningo		- Jacob Beningo
	- Kathleen Moriarty		- Kathleen Moriarty
	We would also like to thank the WG chairs, Russ Housley, David		We would also like to thank the WG chairs, Russ Housley, David
	Waltermire, Dave Thaler for their support and their reviews.		Waltermire, Dave Thaler for their support and their reviews.
	14. References		13. Informative References
	14.1. Normative References
	[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
	Security (TLS) / Datagram Transport Layer Security (DTLS)
	Profiles for the Internet of Things", RFC 7925,
	DOI 10.17487/RFC7925, July 2016,
	<https://www.rfc-editor.org/info/rfc7925>.
	14.2. Informative References
	[I-D.ietf-cose-hash-sig]
	Housley, R., "Use of the HSS/LMS Hash-based Signature
	Algorithm with CBOR Object Signing and Encryption (COSE)",
	draft-ietf-cose-hash-sig-09 (work in progress), December
	2019.
	[I-D.ietf-suit-information-model]		[I-D.ietf-suit-information-model]
	Moran, B., Tschofenig, H., and H. Birkholz, "An		Moran, B., Tschofenig, H., and H. Birkholz, "An
	Information Model for Firmware Updates in IoT Devices",		Information Model for Firmware Updates in IoT Devices",
	draft-ietf-suit-information-model-05 (work in progress),		draft-ietf-suit-information-model-05 (work in progress),
	January 2020.		January 2020.
	[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", draft-ietf-suit-manifest-04		of Things (SUIT) Manifest", draft-ietf-suit-manifest-05
	(work in progress), March 2020.		(work in progress), May 2020.
	[I-D.ietf-teep-architecture]		[I-D.ietf-teep-architecture]
	Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,		Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
	"Trusted Execution Environment Provisioning (TEEP)		"Trusted Execution Environment Provisioning (TEEP)
	Architecture", draft-ietf-teep-architecture-08 (work in		Architecture", draft-ietf-teep-architecture-08 (work in
	progress), April 2020.		progress), April 2020.
	[LwM2M] OMA, ., "Lightweight Machine to Machine Technical		[LwM2M] OMA, ., "Lightweight Machine to Machine Technical
	Specification, Version 1.0.2", February 2018,		Specification, Version 1.0.2", February 2018,
	<http://www.openmobilealliance.org/release/LightweightM2M/		<http://www.openmobilealliance.org/release/LightweightM2M/
	V1_0_2-20180209-A/OMA-TS-LightweightM2M-		V1_0_2-20180209-A/OMA-TS-LightweightM2M-
	V1_0_2-20180209-A.pdf>.		V1_0_2-20180209-A.pdf>.
	[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
	(AES) Key Wrap with Padding Algorithm", RFC 5649,
	DOI 10.17487/RFC5649, September 2009,
	<https://www.rfc-editor.org/info/rfc5649>.
	[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management		[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
	Requirements", RFC 6024, DOI 10.17487/RFC6024, October		Requirements", RFC 6024, DOI 10.17487/RFC6024, October
	2010, <https://www.rfc-editor.org/info/rfc6024>.		2010, <https://www.rfc-editor.org/info/rfc6024>.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,		Constrained-Node Networks", RFC 7228,
	DOI 10.17487/RFC7228, May 2014,		DOI 10.17487/RFC7228, May 2014,
	<https://www.rfc-editor.org/info/rfc7228>.		<https://www.rfc-editor.org/info/rfc7228>.
	[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet		[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet
	of Things Software Update (IoTSU) Workshop 2016",		of Things Software Update (IoTSU) Workshop 2016",
	RFC 8240, DOI 10.17487/RFC8240, September 2017,		RFC 8240, DOI 10.17487/RFC8240, September 2017,
	<https://www.rfc-editor.org/info/rfc8240>.		<https://www.rfc-editor.org/info/rfc8240>.
	14.3. URIs		[RFC8778] Housley, R., "Use of the HSS/LMS Hash-Based Signature
			Algorithm with CBOR Object Signing and Encryption (COSE)",
	[1] mailto:suit@ietf.org		RFC 8778, DOI 10.17487/RFC8778, April 2020,
			<https://www.rfc-editor.org/info/rfc8778>.
	[2] https://www1.ietf.org/mailman/listinfo/suit
	[3] https://www.ietf.org/mail-archive/web/suit/current/index.html
	Authors' Addresses		Authors' Addresses
	Brendan Moran		Brendan Moran
	Arm Limited		Arm Limited
	EMail: Brendan.Moran@arm.com		EMail: Brendan.Moran@arm.com
	Hannes Tschofenig		Hannes Tschofenig
	Arm Limited		Arm Limited
End of changes. 15 change blocks.
	89 lines changed or deleted		40 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/