Internet DRAFT - draft-zhu-suit-automatic-fu-arch
draft-zhu-suit-automatic-fu-arch
SUIT J. Zhu
Internet-Draft Huawei
Intended status: Standards Track March 5, 2018
Expires: September 6, 2018
A Secure and Automatic Firmware Update Architecture for IoT Devices
draft-zhu-suit-automatic-fu-arch-00
Abstract
Firmware update is one of the key features for all Internet of
Things(IoT) Devices. Incentives of firmware update is to fix bugs,
upgrade configurations, add new services from constained devices to
connected vehicles. The IETF SUIT working group is focusing on
defining a firmware update solution that will be usable on Class 1
devices as well as more capable devices with existing mechanisms.
This document provides an firmware update architechture, that aims at
helping build a secure, automatic and interoperable IoT firmware
update mechanism.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Zhu Expires September 6, 2018 [Page 1]
Internet-Draft Automatic FU Architecture March 2018
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Client-Initiated Update . . . . . . . . . . . . . . . . . 4
3.2. Server-Initiated Update . . . . . . . . . . . . . . . . . 5
3.3. Negotiated Update . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Firmware update is one of the key features for all Internet of
Things(IoT) Devices. Incentives of firmware update is to fix bugs,
upgrade configurations, add new services from constained devices to
connected vehicles. The IETF SUIT working group is focusing on
defining a firmware update solution that will be usable on Class 1
devices as well as more capable devices with existing mechanisms.
This document provides an firmware update architechture, that aims at
helping build a secure, automatic and interoperable IoT firmware
update mechanism.
Considering the security aspects of IoT device firmware update, it is
not only the cryptographic mechanisms that used to protect the
firmware images and the manifest, or the secure transmission
protocols, but also the timeliness. An old-fashioned firmware with
vulnerabilities is very harmful for an IoT device, which leaves
potential target for a cyber attack.
The 2016 Dyn cyberattack is the most impressive example that why all
IoT devices SHOULD implement the firmware update. In October 2016,
the Dyn cyberattack took place and this huge DDoS attack affected a
large number of the US and EU websites. The direct reason of this
attack is that many IoT devices such as printers, IP cameras,
residential gateways and baby monitors are infected by Mirai malware,
Zhu Expires September 6, 2018 [Page 2]
Internet-Draft Automatic FU Architecture March 2018
and the attacker used a list of default username/password to access
and control the devices. However, one of the actual reasons is that
those infected IoT devices are not updated in time. The new version
firmware has a mandatory feature to ask the users to change the
default username/password pair when they log in.
In order to provide a firmware update in time, the mechanism SHOULD
be automatic. The rest of this document describes an automatic
solution for the IoT device firmware update. Section 3 provides the
architecture. Section 4 provides some of the requirements.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this specification are to be interpreted as described
in [RFC2119].
3. Architecture
In the existing IoT firmware update standards such as OMA DM FUMO and
LwM2M Firmware Update, the devices usually play the core role during
the update procedure. They download the firmware images from a
storage location under the guidance of the device management(DM)
server, and then setup a status machine and start processing the
firmware when they become "Idle".
However, in most IoT use cases, the "Idle" status itself is really
confused and hard to reach. For example, a smart electricity meter
works 7*24 after it is plugged into the grid. It always runs under
"Working" status, then how to execute a firmware update on this kind
of devices when needed? Another example is how to update the ECUs in
a connected vehicle. The server can only access the ECUs when the
vehicle is started, but the ECUs also start to work. Even if the in-
car gateway can download the firmware image, it is hardly for a car
to update the firmware immediately. When the car gets into "Idle"
status, it is usually shut down as well, no ECUs can do further
update process.
Moreover, the DM server usually manages multiple different devices at
a large amount. The existing standard does not have the scheduling
of manage and update firmwares. The DM server MAY store multiple
different firmware images at the same time. The firmware images have
different functionalities, thus they SHOULD have different urgency
levels when updating. For example, a bug fix update firmware has a
higher urgency level than a configuration update firmware.
Zhu Expires September 6, 2018 [Page 3]
Internet-Draft Automatic FU Architecture March 2018
Therefore, there is a need for the secure automatic firmware update
mechanism to address the issues mention above. A brief message flow
of secure automatic firmware update is shown in Figure 1. There are
generally 3 steps. Most of the cryptographic related steps are shown
in Figure 4/[I-D.draft-moran-suit-architecture] and not described
again in this document.
Author Server Device
| | |
| (A) Firmware | |
+----------------->| |
| Manifest | |
| | |
| |(B)Check Manifest |
| +----------------+ |
| |<---------------+ |
| | |
| |(C)Update Process |
| |<---------------->|
| | |
Figure 1: Brief message flow of Firmware Update
(A) The server gets the firmware image and related manifest from the
firmware author.
(B) The server checks the manifest to know the firmware image urgency
class and determine the update mode of the targeted device.
(C) The device downloads the firmware image and manifest, and then
start to process the firmware update.
For a secure automatic firmware update solution, there may be three
different update mode to be considered.
1. Client-Initiated Update
2. Server-Initiated Update
3. Negotiated Update
3.1. Client-Initiated Update
The Client-Initiated Update is a mechanism that the client update
itself unilaterally.
In this case, the client MAY retrieve the latest firmware image
information periodically from the server. Once there is a new
Zhu Expires September 6, 2018 [Page 4]
Internet-Draft Automatic FU Architecture March 2018
firmware image on the server, the client itself started to download
the firmware image and manifest. After successful downloading, the
client start to process the firmware update when it goes into idle
status.
3.2. Server-Initiated Update
The Server-Initiated Update is a mechanism that the server update the
device unilaterally.
This mechanism is suggested especially for the 7*24 working device
since it has no idle status. Then even if it has downloaded the
firmware images from the server. It is hard for the device itself to
determine when to process a firmware update.
The traditional way of updating this kind of device is to ask human
intervetion. This is not a good idea for large amount of devices and
also for the automatic solutions. This has already been proved in
the Mirai Cyberattack example.
A better solution for this case is to let the server take charge of
the update process. The server determines when to update the devices
according to the service status retrieved from the device or a pre-
provisioned update strategy. The server pushes the firmware image
when the device is accessible and trigger the update process based on
the previous determinations.
The device in this Solution is considered as an executor and SHOULD
follow the commands from server strictly.
3.3. Negotiated Update
The Negotiated Update is the most common use mechanism for existing
firmware update standards for IoT devices. E.g.OMA DM and LwM2M .
The server notifies the client once it gets a firmware image from the
author. This notification MAY only contain the existance information
of a new firmware image. It may also contain the firmware manifest.
The client then decided if it is OK with this update automatically.
If the status is idle the client may generates a OK response to the
server to ack the notification. Then the server SHOULD start pushing
the firmware image to the client; It the status is not good enough
for update, the client then generates a response with a scheduled
update time. The server then waited and trigger the update after the
scheduled update time expires.
Zhu Expires September 6, 2018 [Page 5]
Internet-Draft Automatic FU Architecture March 2018
4. Requirements
The firmware update mechanism SHOULD be automatic in order to enhance
the availability.
The firmware update mechanism SHOULD consider not only single image
update, but also multiple images update use cases.
The firmware manifest SHOULD contain enough information for the
server to determine the urgency class of the related firmware image.
The server SHOULD be pre-provisioned some strategies to determine the
urgency class of received firmware image.
If the denial of service is unavoidable during the firmware update
process, this situation SHOULD be notified to the device.
The update mode for each device SHOULD be determined during the
registration process.
5. Conclusion
Timeliness is a key consideration when discussing and defining the
IoT firmware update mechanism. Unlike the traditional cryptographic
considerations that focus more on the confidentiality and integrity,
this automatic firmware update solution focuses more on the
availability aspect of security when updating an IoT device.
The automatic firmware update solution provided in this document
makes the IoT device update in time to shorten the possible
vulnerability exposure time for the attackers. This solution also
consider the impact of the update process itself SHOULD not cause a
denial of service for the device for the minimum period of time.
6. Security Considerations
The whole document can be seen as security considerations for IoT
device firmware update.
7. IANA Considerations
TBD.
8. Acknowledgements
TBD.
Zhu Expires September 6, 2018 [Page 6]
Internet-Draft Automatic FU Architecture March 2018
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References
[I-D.draft-moran-suit-architecture]
Moran, B., Meriac, M., and H. Tschofenig, "A Firmware
Update Architecture for Internet of Things Devices",
draft-moran-suit-architecture-02 (work in progress), March
2018.
Author's Address
Jintao Zhu
Huawei
P.R.China
Email: jintao.zhu@huawei.com
Zhu Expires September 6, 2018 [Page 7]