Framework for Serverless IoT Firmware Updates using Blockchain & Distributed Storage

In this article I will describe a basic framework for how blockchain and distributed storage can be used to implement secure Over the Air firmware update process for IoT devices. A simple implementation for this process is described using the Solar blockchain and IPFS.

Table of Contents

    Background

    With the rapid development of embedded systems and cost reductions in wireless connectivity chipsets it is now common for even simple devices to be connected to the internet. This connectivity opens up significant vulnerabilities and is a huge security challenge for manufacturers.
    Enabling IoT devices with Over the Air (OTA) remote firmware updates provides the following value to the manufacturer and end user:

    • Allows manufactures to add new features and value to the customer over time.
    • Provides developers an easy way to iterate and test with large quantity of devices in alpha and beta stages of development.
    • Allows the manufacturer to fix bugs and security vulnerabilities quickly without physical access to the device or requiring the customer to manually reprogram.

    Integrity, authenticity and availability during the firmware update process is complex and requires extensive effort in order to create a highly secure system.

    Solar.org is an open-source blockchain operating via a Delegated Proof of Stake(DPoS) consensus and secured by 53 voted-in delegates that produce blocks and validate transactions. Solar uses the ARK DPoS Framework which is a very efficient architecture and does not suffer from the high CPU requirements and cost associated with proof of work blockchains.
    Solar provides a flexible dedicated transaction type for recording IPFS CID hashes along with metadata associated with the file. There is no requirement to develop a custom smart contract.

    IPFS is a distributed system for storing and accessing data files. The data is addressed based on a cryptographic hash of its content and not by its location.

    Firmware Update Process

    1. Manufacturer creates wallet using Solar Desktop Wallet and secures private keys.
    2. Manufacturer runs a light Relay node that is used to submit transactions and read from the blockchain. This node provide an easy to use REST-API.
    3. Manufacturer builds new firmware image.
    4. Manufacturer signs firmware image using Schnorr algorithm using private keys and prepending it to the firmware image. The desktop wallet has message signing feature however normally this would be done using a custom script calling Typescript SDK.
    5. Manufacturer uploads signed firmware image to IPFS node. File is pinned across multiple nodes to ensure high availability.
    6. Manufacturer creates firmware metadata that could be serialized or a JSON string. Metadata can be up to 255 characters. Example:
    {
    "PID": "IotDeviceA",
    "Ver": 1.0.1,
    "File": "IotDeviceA-2.bin"
}
    • PID: Product ID is a unique name or number to identify a hardware product.
    • Ver: Version number of firmware. Can be single number or semantic version.
    • File: filename extension appended to the IPFS CID when downloading from IPFS gateway.
    1. Manufacturer creates and broadcasts special IPFS transaction which contains the IPFS CID hash and metadata to Solar blockchain.
    2. When preparing the IoT device the public key of the manufacturer is securely stored within a secure memory element to prevent tampering.
    3. IoT device periodically checks the blockchain transaction activity of the manufacturer’s public address. When device sees a new firmware transaction it compares the metadata with its own firmware parameters. If new firmware is available then IoT device downloads new firmware from IPFS gateway using the CID hash recorded on the blockchain.
    4. IoT device verifies the Schnorr signature using manufacturer’s public key stored in its secure memory to ensure that the firmware image has not been tampered with by a compromised communication path.
    5. IoT device updates its firmware with verified image.

    Summary

    The presented framework provides an overview of an efficient basic update process. For large scale deployments there are more complex features and security features required such as release channels, staggered deployment over geography and time, and file encryption. Often IoT devices may not include a direct communication link to the internet. An example of this is a public Lorawan network such as Helium. In this case an edge gateway device is used as intermediary.
    Each IoT device should also include its own set of private keys to ensure the authenticity of the device along with permissions to install specific firmware.

    In a follow-up post I will provide a complete working example of the provided firmware update framework using the popular ESP32 microprocessor.

    Related Posts