draft-ietf-suit-architecture-03.txt   draft-ietf-suit-architecture-04.txt 
SUIT B. Moran SUIT B. Moran
Internet-Draft Arm Limited Internet-Draft Arm Limited
Intended status: Informational M. Meriac Intended status: Informational M. Meriac
Expires: September 12, 2019 Consultant Expires: September 28, 2019 Consultant
H. Tschofenig H. Tschofenig
Arm Limited Arm Limited
D. Brown D. Brown
Linaro Linaro
March 11, 2019 March 27, 2019
A Firmware Update Architecture for Internet of Things Devices A Firmware Update Architecture for Internet of Things Devices
draft-ietf-suit-architecture-03 draft-ietf-suit-architecture-04
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 1, line 48 skipping to change at page 1, line 48
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 September 12, 2019. This Internet-Draft will expire on September 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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/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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
- Device: A device refers to the entire IoT product, which consists - Device: A device refers to the entire IoT product, which consists
of one or many MCUs, sensors and/or actuators. Many IoT devices of one or many MCUs, sensors and/or actuators. Many IoT devices
sold today contain multiple MCUs and therefore a single device may sold today contain multiple MCUs and therefore a single device may
need to obtain more than one firmware image and manifest to need to obtain more than one firmware image and manifest to
succesfully perform an update. The terms device and firmware succesfully perform an update. The terms device and firmware
consumer are used interchangably since the firmware consumer is consumer are used interchangably since the firmware consumer is
one software component running on an MCU on the device. one software component running on an MCU on the device.
- Status Tracker: The status tracker offers device management - Status Tracker: The status tracker offers device management
functionality that includes keep track of the firmware update functionality to monitor the firmware update process. A status
process. This includes fine-grained monitoring of changes at the tracker may, for example, want to know what state of the firmware
device, for example, what state of the firmware update cycle the update cycle the device is currently in.
device is currently in.
- Firmware Server: The firmware server stores firmware images and - Firmware Server: The firmware server stores firmware images and
manifests and distributes them to IoT devices. Some deployments manifests and distributes them to IoT devices. Some deployments
may require a store-and-forward concept, which requires storing may require a store-and-forward concept, which requires storing
the firmware images/manifests on more than one entity before the firmware images/manifests on more than one entity before
they reach the device. they reach the device.
- Device Operator: The actor responsible for the day-to-day - Device Operator: The actor responsible for the day-to-day
operation of a fleet of IoT devices. operation of a fleet of IoT devices.
skipping to change at page 6, line 21 skipping to change at page 6, line 20
The terms 'trust anchor' and 'trust anchor store' are defined in The terms 'trust anchor' and 'trust anchor store' are defined in
[RFC6024]: [RFC6024]:
- "A trust anchor represents an authoritative entity via a public - "A trust anchor represents an authoritative entity via a public
key and associated data. The public key is used to verify digital key and associated data. The public key is used to verify digital
signatures, and the associated data is used to constrain the types signatures, and the associated data is used to constrain the types
of information for which the trust anchor is authoritative." of information for which the trust anchor is authoritative."
- "A trust anchor store is a set of one or more trust anchors stored - "A trust anchor store is a set of one or more trust anchors stored
in a device. A device may have more than one trust anchor store, in a device. A device may have more than one trust anchor store,
each of which may be used by one or more applications." each of which may be used by one or more applications." A trust
anchor store must resist modification against unauthorized
insertion, deletion, and modification.
3. Requirements 3. Requirements
The firmware update mechanism described in this specification was The firmware update mechanism described in this specification was
designed with the following requirements in mind: designed with the following requirements in mind:
- Agnostic to how firmware images are distributed - Agnostic to how firmware images are distributed
- Friendly to broadcast delivery - Friendly to broadcast delivery
skipping to change at page 25, line 12 skipping to change at page 25, line 12
EMail: Brendan.Moran@arm.com EMail: Brendan.Moran@arm.com
Milosch Meriac Milosch Meriac
Consultant Consultant
EMail: milosch@meriac.com EMail: milosch@meriac.com
Hannes Tschofenig Hannes Tschofenig
Arm Limited Arm Limited
EMail: hannes.tschofenig@gmx.net EMail: hannes.tschofenig@arm.com
David Brown David Brown
Linaro Linaro
EMail: david.brown@linaro.org EMail: david.brown@linaro.org
 End of changes. 7 change blocks. 
10 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/