Internet DRAFT - draft-nandakumar-suit-secfu-solution-arch
draft-nandakumar-suit-secfu-solution-arch
Network Working Group S. Nandakumar
Internet-Draft C. Jennings
Intended status: Standards Track S. Cooley
Expires: May 3, 2018 Cisco
October 30, 2017
Solution Architecture - Secure Firmware Upgrade (SecFU)
draft-nandakumar-suit-secfu-solution-arch-00
Abstract
This specification defines a solution architecture for performing
secure firmware upgrade for Internet of Things (IoT). The ulterior
motive is to have a framework that is simple, secure, and that uses
most common formats and standards in the industry and that works over
Internet.
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 http://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 May 3, 2018.
Copyright Notice
Copyright (c) 2017 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
(http://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
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Nandakumar, et al. Expires May 3, 2018 [Page 1]
Internet-Draft SecFU October 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Device Considerations . . . . . . . . . . . . . . . . . . . . 3
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
5. Solution Components . . . . . . . . . . . . . . . . . . . . . 4
5.1. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Manifest Format . . . . . . . . . . . . . . . . . . . . . 6
5.3. Manifest Security . . . . . . . . . . . . . . . . . . . . 6
5.4. Manifest Optional Extensions . . . . . . . . . . . . . . 6
5.5. Firmware Server Discovery . . . . . . . . . . . . . . . . 6
5.6. Firmware Download protocol . . . . . . . . . . . . . . . 7
5.6.1. Validation Procedures . . . . . . . . . . . . . . . . 7
5.6.2. Manifest Download . . . . . . . . . . . . . . . . . . 8
5.6.3. Firmware Download . . . . . . . . . . . . . . . . . . 8
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Internet of Things (IOT) represents a plethora of devices that come
in varying flavors of constrained sizes, computing power, and
operating considerations. These devices usually need minimal or no
management for their operation.
Vulnerabilities within IOT devices have raised serious concerns.
There needs to be a way to install or update the firmware on these
devices in an automated and secure fashion. A common challenge with
the existing firmware update mechanism is they do not work in an
automated manner in many environments where IoT devices are deployed.
Hence, there is a need to define a firmware update solution that is
light weight, secure, can operate in variety of deployment
environments, and is built on well established standards.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", "MAY", and "OPTIONAL" are to be interpreted as described in RFC
2119 [RFC2119] and indicate requirement levels for compliant
implementations.
Nandakumar, et al. Expires May 3, 2018 [Page 2]
Internet-Draft SecFU October 2017
3. Device Considerations
This draft targets devices that have a boot loader that run in less
than 100K bytes of flash and less than 32K bytes of RAM.
There are certain types of devices that delete the firmware image,
except for the boot-loader, before proceeding with the upgrade.
Alternatively, many devices have sufficient storage to completely
download a new firmware image before updating. This solution should
be naturally applicable to both.
4. Solution Overview
draft-nandakumar-suit-secfu-requirements captures various
requirements that drives the solution defined in this specification.
Below is a high-level solution flow for a successful firmware update
on a IoT device.
Nandakumar, et al. Expires May 3, 2018 [Page 3]
Internet-Draft SecFU October 2017
Successful Firmware Update Flow
on-ready to update
firmware
|
|
Can access firmware sever
in the local domain ?
|
|
------------------
Yes | | No
| |
Download signed Download signed
manifest from manifest from
local server manufacturer's
well-known URL pre-configured URL
| |
| |
Validate manifest via
pre-installed public key
|
|
Download the firmware image
from the location in manifest
|
|
verify commit hashes
on the firmware image
|
|
complete installation
5. Solution Components
Following several sub-sections define various components that makes
up the proposed solution architecture
5.1. Manifest
A firmware manifest serves as information representation for metadata
about the firmware. A manifest file identifies information about the
actual firmware image, its location, applicable device(s), and so on.
It is cryptographically signed by the provider (usually the
manufacturer) of the firmware.
Nandakumar, et al. Expires May 3, 2018 [Page 4]
Internet-Draft SecFU October 2017
Minimal Manifest in JSON format
{
"manifestVersion" : "1.0",
"timestamp": "2017-12-10T15:12:15Z",
"manufacturer": "manufacturer.com",
"model": "c7960",
"firmwareVersion": "10.4.12",
"firmwareLocation": "well-known location",
"firmwareCryptoInfo": {
{
"commitHash": [
{
"digestAlgo": "sha256",
"hash": "..................."
},
{
"digestAlgo": "sha512",
"hash": "..................."
}
]
}
}
"key-info": <most recent public key info>
}
Above shows example of a minimally defined manifest that identifies
the mandatory attributes as explained below
o manifestVersion: Version of the manifest
o timestamp: Time when the manifest was created.
o manufacturer: An identifier of the manufacturer providing the
firmware image, represented as String
o model: Device Model, a String
o firmwareVersion: Firmware Version in the format
"major.minor.revision"
o firmwareLocation: Location of the firmware images. This can be an
absolute URI or a relative URI that is relative to where the
manifest was downloaded from.
o firmwareCryptoInfo: Commit Hash information
Nandakumar, et al. Expires May 3, 2018 [Page 5]
Internet-Draft SecFU October 2017
5.2. Manifest Format
JSON representation is recommended as the default format for
describing the manifest. Optionally, formats such as CBOR (see
example section) can be used for the same. If more than one format
is used, the IoT device can pick one based on its implementation.
The firmware download protocol identifies the right format supported
by the IoT device.
5.3. Manifest Security
The Manifest file MUST be cryptographically signed by the private key
of the manufacturer or the provider of the firmware. This is to
ensure source authenticity and to protect integrity of the manifest
and the firmware itself.
JWS is the format recommended to store the signed manifest.
signed_manifest := JWS(manifest.json)
If CBOR is used for describing the manifest, COSE is recommended for
signing.
Optionally, the proposed solution also recommends hash based
signatures (hash-sigs) to sign the manifest.
signed_manifest := hash-sigs(manifest.json, private-key)
5.4. Manifest Optional Extensions
There may be scenarios where the minimalistic manifest defined above
may not capture all the requirements for a given deployment setting.
In those circumstances, the manifest can be optionally extended to
meet the requirements in a extensional specifications.
5.5. Firmware Server Discovery
When it is time for an IoT device to perform a firmware upgrade, the
device performs couple of steps to decide the location to download
the needed firmware. A device might need to download the new
firmware when it is either booting for the first time after
deployment or there is a need to upgrade to a newer firmware.
The server discovery procedure starts with the boot-loader attempting
to access a server that is local to the domain in which the device
operates. The URL to look for a local server is automatically
generated using the DHCP domain name.
Nandakumar, et al. Expires May 3, 2018 [Page 6]
Internet-Draft SecFU October 2017
For example, if the domain name was example.com, and the device was a
Cisco 7960, the HTTP URL might be
http://_firmware.example.com/.wellknown/firmware/cisco.com/c7960/manifest.json
In situations where the IoT device cannot access the Internet
(factory/enterprise settings, for example), the aforementioned
approach might be the only way for the device to perform any kind of
firmware or security updates.
However, if the local server cannot be reached or not deployed (say
home environments), the device proceeds to download the manifest and
firmware from the firmware server URL pre-configured in the boot-
loader by the manufacturer of the device. For example
http://_firmware.cisco.com/.wellknown/firmware/cisco.com/c7960/manifest.json
If either of the procedures doesn't work, the IoT device is either
unusable or might end up running an old version of the firmware.
5.6. Firmware Download protocol
One can envision two possibilities while downloading the firmware:
o Scenarios where the IoT device downloads firmware directly. This
is done in order to minimize number of connections. In this
scenario, the firmware image must have a digital signature
included within the downloaded firmware. The exact placement of
this digital signature (prepended, appended, etc) is up to the
device manufacturer, but it MUST provided source and integrity
guarantees on the entirety of the firmware image and must be
verified by the device prior to upgrade.
o Scenarios where a manifest is retrieved and followed by
downloading the actual firmware image.
5.6.1. Validation Procedures
The downloaded manifest and firmware is validated before being used:
o Manifest file signature is validated for source and integrity
verification. If encrypted, the manifest is decrypted before
proceeding with the firmware download.
o On successful validation of the manifest, the device verifies the
commit hashes for component(s) of the firmware downloaded against
the ones provided in the "firmwareCryptoInfo" section of the
manifest.
Nandakumar, et al. Expires May 3, 2018 [Page 7]
Internet-Draft SecFU October 2017
5.6.2. Manifest Download
Firmware download protocol enables choosing the approach appropriate
to the IoT device for downloading the manifest file.
For example, on performing the "Firmware Server Discovery", if a
local server is chosen, the device forms a query URL by constructing
an endpoint at ".well-known/manifest/<manufacturer>/<model-
no>/manifest.json"
Then a HTTP GET request is sent to that URL. For example
http://_firmware.example.com/.wellknown/manifest/cisco.com/c7960/manifest.json
The response would be a JSON result of the manifest file. Similarly,
the end-point supporting CBOR parsing can request for the CBOR
version of the mannifest.
5.6.3. Firmware Download
Once the manifest is downloaded and validated, the device proceeds to
download the firmware image from the location identified in the
firmware manifest. There might be situations where a firmware image
is split into multiple files to imply a functional division of the
components. This type of firmware can be used by devices that are
memory constrained and thus loading the complete image might not be
possible. The manifest file may contain the information to indicate
the same.
Above example shows use of HTTP as the communication protocol to talk
to the firmware server. If the end-point is capable of doing COAP or
other protocols, a similar process as above can be applied to
retrieve the manifest and the firmware from a well-known place on the
local server.
6. IANA Consideration
TODO
7. Security Considerations
TODO - Talk about roaming IoT Device
8. Acknowledgements
Nandakumar, et al. Expires May 3, 2018 [Page 8]
Internet-Draft SecFU October 2017
9. 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, <https://www.rfc-
editor.org/info/rfc2119>.
Authors' Addresses
Suhas Nandakumar
Cisco
Email: snandaku@cisco.com
Cullen Jennings
Cisco
Email: fluffy@iii.ca
Shaun Cooley
Cisco
Email: scooley@cisco.com
Nandakumar, et al. Expires May 3, 2018 [Page 9]
