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": } 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///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, . 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]