UpdaThing: a secure firmware update system for of Things devices

Tomás Alexandre Diniz de Pinho Instituto Superior Técnico, Universidade de Lisboa Av. Rovisco Pais, 1 1049-001 Lisboa, Portugal [email protected]

ABSTRACT The Internet of Things (IoT) has amassed interest from in- dustry and consumers, and devices belonging to this class are being deployed at a rapid rate, to collected data that will help to solve problems in many different domains. Man- ufacturers have to provide support to such deployments and thus have to patch the software running on these devices when a bug is found and corrected. Therefore, updating the firmware running on these devices requires a firmware update mechanism, which presents security challenges, as it can be used by malicious actors to compromise these devices in bulk. In this , we propose, implement and evaluate a firm- ware update system that is easy to deploy and easy to use, Figure 1: Gateway connecting limited devices assures code authenticity (integrity and proof of origin), con- to a Data Center. fidentiality and freshness in the update process, defeating the most relevant external security threats. As the IoT continues to grow, so does the number of con- nected devices that require manufacturer support. “All soft- ware has bugs” is a known fact of Software Engineering [19], so manufacturers have to plan for and provide some sort of patch management process that corrects them in end-user Keywords devices. Updating software in IoT devices is usually performed via Internet of Things; ; Software update; Over-the- updating their firmware in its entirety[5]. This process in- air update; Security; Public Key Infrastructure; Embedded volves some firmware update mechanism that allows devices Systems to connect to a server deployed by the manufacturer in order to download and update to a newer firmware image. How- ever, if not correctly designed, this mechanism may pose a severe threat as it may be used by malicious actors to com- promise these devices in bulk, obtain proprietary code or 1. INTRODUCTION sensitive information[24]. For the past few years, there has been a surge in pop- This paper presents an open-source secure firmware up- ularity of the Internet of Things (IoT) among consumers date mechanism aimed at IoT gateways. Our system assures and manufacturers and it is now a well-known class of de- proof of origin, integrity and in-transit confidentiality of the vices with multiple software libraries and development kits update images, while still being easy to use and deploy. available[25]. IoT systems, in small-business or home de- We assess the security of our system by conducting a ployments, are usually implemented via a set of that STRIDE threat assessment on its endpoints, measuring net- capture events or measurements; and a central IoT gateway, work overhead and energy consumption, before comparing a more capable device that sits between resource-constrained it to relevant related work. devices, which operate on specific protocols, and the In- ternet, serving as a bridge between them[17]. The sensors 1.1 Overview transmit data using specific low-energy protocols to the IoT This paper is organized as follows: we present all necessary gateway which may pre-process the data or add some more background on the development and updating of firmware data collected by its own sensors (if it has them). The gate- for embedded systems in Section 2. In Section 3, we spec- way then sends collected data to a Data Center, where it may ify the requirements that our system must satisfy and the be processed and made available through some other media mechanisms which we will be using to provide our security (i.e. Web/Mobile Applications). The role of the gateway is guarantees. In Section 4, we provide the implementation illustrated in Figure 1. details of our system, what components it has and how they interoperate. In Section 5, we evaluate our system in five that shared-keys are susceptible to attacks since an attacker domains: which initial requirements it satisfies, how it fares may be able to obtain it by exploiting a device and then against a STRIDE analysis, which includes possible attacks using it to sign images for all devices of the same model. and their mitigation, how much network overhead it causes, Public-Private Key pairs are more difficult to obtain since how much energy it consumes and how much it costs to run it is a difficult process to obtain a Private Key (held by the it. In Section 6, we take a look at previously studied related manufacturer) from a Public Key (present in devices)[23]. work and briefly analyse some of its shortcomings and how our system fares against it, comparatively. Finally, in Sec- 2.3 Image Generation tion 7, we conclude this document and propose further work In order to have an update image to flash a device with, it in this field. must be generated somehow. A filesystem with the OS, re- quired services and applications must be put together in or- 2. BACKGROUND der to produce a flashable image. -based devices must, at the bare minimum, run a Linux kernel, an init system (a In this section we provide technical details for the firmware program that is responsible for launching all services and image operations that are relevant to our solution. applications after the kernel finishes ) and required 2.1 Image Flashing services and applications[10]. Therefore, the manufacturer has to configure and compile the Linux kernel with any re- IoT devices possess some kind of permanent bootable mem- quired kernel modules for the target architecture, write or ory from which the device boots its Operating System (OS) choose an init system and write or choose required services via its bootloader[8]. In order for the device to be updatable and applications to include in the image. Usually, this pro- after being initially flashed at a factory plant, this memory cess is automated by the development or usage of scripts must be writable by the device’s bootloader, or even by its that do all these tasks in a repeatable manner to integrate OS. The manufacturer has to write some specialized code, all manufacturer-developed applications into a useful filesys- that is run alongside the device’s main application, which in tem image. turn is responsible for looking for and fetching new firmware update images. The code may or may not perform additional functionality (such as image verification) and flash the image 3. TECHNICAL SPECIFICATION directly or instruct the bootloader to do so on the device’s Since there are numerous and distinct chipsets and System- next reboot. On-a-Chip (SoC) offerings geared towards the development Devices running the Linux OS may write to their perma- and integration of IoT gateway devices, we chose to develop nent bootable memory (their root filesystem) as long as its an update management system targeted at IoT devices that not being used by any running services or applications. The run the Linux OS. These devices may be powered, for in- manufacturers usually implement some sort of two-phased stance, by ARMv6 and ARMv7-based SoC packages. As boot process in which a minimal initramfs[18]1 is loaded into all Raspberry Pi2 models belong to this category, that was the device’s Random Access Memory (RAM)[20] that can one of the reasons why we chose them as a development perform this sort of operations on the permanent bootable platform. By being partly open source and relatively cheap memory before booting the entire system, with its services (5-40$, depending on the model, as of the time of writing), and applications. the has been used by many companies as the SoC for their products. 2.2 Image Verification The Raspberry Pi may serve as an IoT gateway since it After downloading an update image, the device’s firmware can connect to the Internet, via its built-in (dependent on update mechanism may perform some steps to verify the the model) port or Universal Serial Bus (USB) Wi- transferred image. Some devices perform integrity checks, Fi adapter, and it can interface with other sensors, via other by running an hashing function (i.e., CRC32, MD5, SHA1/2, USB adapters, such as or ZigBee adapters. One etc.) through the image and comparing its output to addi- may also connect sensors directly to the Raspberry Pi via its tional downloaded metadata[7]. This sort of integrity check General-Purpose Input/Output (GPIO) pins, functioning as does not provide any security guarantees, as the metadata an IoT gateway with included sensors. and image could have been altered in-transit by a malicious The cost of these devices, ease of use and popularity were actor, but guarantees some safety in the update process by the main reasons why we picked these SoCs as the tool for safeguarding against data of the update image. our work. Other devices may perform proof of origin checks of the downloaded update images by coupling the previously men- tioned integrity checks with a signed hash of the update image[21][11]. These devices calculate the hash of the up- date image and then perform a cryptographic operation on it to verify that a specific shared-key or public-key has been used to sign the downloaded hash, present in the update metadata, thus verifying the image’s origin. We should note 1The initramfs is a cpio (”copy in and out”) archive of the initial file system that gets loaded into memory during the Linux startup process. It solves the ”chicken or the egg” problem of loading required modules for using file systems 2The Raspberry Pi is a series of credit card–sized single- before actually reading the kernel image inside the same file board developed in the United Kingdom by the systems. Raspberry Pi Foundation. 3.1 Requirements As with any software project, we had to carefully define the requirements for our system. As our system aims at solving specific security problems that concern a firmware update image, the majority of such requirements would be to provide certain security guarantees. Therefore, our solution aims to satisfy the following requirements:

1. Assure authentication of all parties participating in the update process: the updating client device and the update server.

2. Assure secure communication between updating client device and update server, guaranteeing integrity and confidentiality of the transferred filesystem image. Figure 2: UpdaThing UML Deployment Diagram

3. Provide an easy-to-use system for generating Linux 4.1 uLinux Distribution filesystem images including the proprietary software We choose to custom build our own developed by the manufacturer. because we aimed to target devices that benefit from booting simple and small Linux environments and since we needed to control the device’s boot process and init system to apply 4. Perform automated key management to unburden the firmware updates. is a set of Makefiles that allows developers from doing it manually. This should include for the configuration, compilation and generation of custom any keys and certificates used in the update process. Linux filesystem images[1]. Buildroot allows us to generate minimal Linux filesystem structures that contain just the packages we need. 3.2 Mechanisms to guarantee security Our devices’ permanent storage is split in three partitions: Transport Layer Security (TLS) sockets were chosen to the first partition is where the minimal initramfs-backed ker- satisfy Requirement 1 and 2, via the usage of the HTTPS nel image is placed and booted by the Raspberry Pi, the protocol for all of the communications. The certificate val- second partition is where the main read-only root filesys- idation phase of the TLS handshake can validate the iden- tem is flashed and the third one acts as a writable overlay tities of all entities participating in the update process and filesystem over the second partition’s contents. The last two in-transit integrity and confidentiality are guaranteed by the partitions are mounted on top of one another by our custom cipher suites negotiated by TLS[13]. Both Server and Client init process which we will describe later. certificates shall be used to identify all entities, namely the Our first fork of Buildroot allows us to generate a mini- Server certificates for both the Update Server and Sign- mal initramfs that contains just the Linux kernel, a copy of ing Server and the Client certificates for the devices. The Busybox (a small contained implementation of several Unix Servers’ Certificate Authority (CA) and the Clients’ CA command line tools) and our custom init script. This custom should not be the same, since the clients should be capable init script takes care of the actual update image flashing, of generating and signing their own certificates, by having a before the rest of the services are initiated, by checking a local copy of the CA. predefined filesystem location for an already verified update Additionally, in order to guarantee proof of origin, the image, flashing it, deleting it and then proceeding to boot system can verify the integrity of the downloaded image af- the rest of the system by switching the Linux root filesystem ter transferring it by calculating a hash using SHA512 of and initiating Busybox’s init system. the image and verifying its signature using a trusted RSA The second Buildroot fork is responsible for generating im- Public-Key. ages of the root filesystem and contains directives to install packages such as network utilities, interpreters and our own Device Daemon. This is the Buil- droot source code tree that is to be used by developers work- ing on the devices’ integration with manufacturer-developed applications. By writing a simple Makefile, any custom ap- plication may be added to the Buildroot build process and included in the generated image. The developer only has to 4. UpdaThing checkout our repository, install compilation tools and type UpdaThing is the name of this project and is an umbrella make on each file tree to generate working images. term for all its components. UpdaThing has a Linux dis- tribution and its development tools, two distinct server im- 4.2 Components plementations and a device daemon. Figure 2 presents a As previously described, our system is composed of four Unified Modeling Language (UML) deployment diagram of components: the uLinux distribution and its development the system, including the Update Server, the Signing Server, tools, the Update Server, the Signing Server and the Device the Device Daemon, and the Developer Tools. Daemon. In this section we will be fully describing their respective roles. • Update Server The uLinux distribution is used by the manufacturers’ de- velopers to generate working Linux filesystem images. An – GET /updates/{id} - Download an update pack- included tool may be used to upload the resulting images to age by its ID. Must provide a valid device certifi- the Signing Server. cate. The Signing Server is responsible for receiving raw firmware – POST /newUpdate - Get the newest update pack- update images and including keys, certificates and configura- age after given timestamp. Post body: { times- tion files in them. These artifacts are part of our automatic tamp: UNIX Timestamp (Number) }. Must pro- key management process and are used by the Client Dae- vide a valid device certificate. mon to authenticate images and the identity of the Update Server during TLS. To do so, the Signing Server spawns a – POST /updates/ - Upload a new update package Docker3 container that runs a custom shell script which in file. Must provide a valid server certificate and turn mounts the filesystem image and copies the required Signing Server Auth token (in HTTP header). files onto it. Then, the Signing Server calculates a SHA512 – POST /imAlive - Send I’m Alive message. Post hash of the resulting firmware image and signs it with its body: { deviceId: UUID (String), firmwareVer- RSA Private key, including it in a Tar4 package along with sion: Number, port: Number }. Must provide a the image. Finally, the Signing Server uploads this package valid device certificate. to the Update Server. The Update Server is responsible for notifying alive clients • Signing Server of new updates, serving update packages by their ID when requested, receiving I’m Alive messages from devices and – POST /updates/ - Upload a new update image responding to queries for newest update packages’ IDs by file. Must provide a valid developer Auth token. timestamp. • Device Daemon The Device Daemon is tasked with periodically sending “I’m Alive” messages to the Update Server, being notified of – POST /newUpdate - Notify of a new download- new update packages when they are available, querying for able update package. Post body: { id: Update ID newest update packages on the device’s boot and download- (Number), timestamp: UNIX Timestamp (Num- ing and verifying update images. The update images are ber)} verified by opening the Tar archive, hashing the included firmware update image using SHA512 and verifying the in- Example scenarios for sequential usage of these endpoints cluded signed SHA512 hash by using the the Signing Server’s are as follows: Signing Public-Key that is installed on the device’s perma- nent memory. The Device Daemon also attempts to estab- • Device Daemon attempts to update on boot: the De- lish port forward mappings with the router it is connect- vice Daemon calls the Update Server’s endpoint“POST ing to through the usage of UPnP[2]. This enables the De- /newUpdate”, if an ID was returned, it then calls“GET vice Daemon to receive push notifications from the Update /updates/{id}” to download the update and proceed Server Directly. with the update process. The Signing Server, the Update Server and the Device Daemon were implemented in Node.js. We chose this plat- • Device Daemon is notified of new update: the Update form because JavaScript is a quick prototyping language and Server calls the endpoint exposed by the Device Dae- Node.js provides useful APIs out-of-the-box, such as imple- mon “POST /newUpdate” and then the Device Dae- mentations for HyperText Transfer Protocol (HTTP), TLS mon calls “GET /updates/{id}”, downloading the im- and a library (based on OpenSSL bindings) age and proceeding with the update process, if the that more than fits our use case. Moreover, Node.js’s vi- received timestamp is higher than the one for the cur- brant open-source community has developed libraries im- rently installed firmware version. plementing functionality we required (i.e., integration with the Docker API) in a way that is not convoluted and could 5. EVALUATION easily be integrated in our project. 5.1 Requirements Satisfaction 4.3 Protocols In this section we give a brief summary of what require- In this section we would like to delve deeper into the end- ments were satisfied and how. points exposed by each of our components, the messages Requirement 1 was satisfied by the usage of X.509 certifi- that are sent and received and the sequential logic behind cates signed by trusted Certificate Authorities in the authen- them. As explained before, these endpoints are exposed tication part of the TLS protocol of HTTPS. Requirement via HTTPS and benefit from all the guarantees provided 2 was satisfied by the use of TLS which guarantees confi- by TLS. An additional Data Flow Diagram (DFD) may be dentiality and integrity of transferred data. Requirement 3 consulted in Figure 3. The implemented endpoints are as was satisfied by the Development Tools that were developed follows: as part of this system that allow the developers to auto- matically configure and generate complete Linux filesystem 3Docker is an open-source project that automates the de- images using Buildroot. Finally, Requirement 4 was satis- ployment of applications inside software containers. fied by the process of including all required keys, certificates 4Tar stands for Tape ARchive and it is a file archiving for- and configuration files before signing a given update image mat. in the Signing Server. Amount of traffic 5.2 STRIDE Action generated (bytes) The STRIDE Threat Model is an industry standard for Checking for update images newer evaluating systems in regards to their security. STRIDE 7.6 kB than the current image’s timestamp stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of dervice and Elevation of Privilege. In Sending of I’m Alive messages 7.6 kB Downloading of firmware update this section we perform a security analysis of our system and 3 148 MB its endpoints. image In Figure 3 we present a DFD for all UpdaThing’s com- Push notification of new firmware 4 4.6 kB ponents and their respective endpoints. Considering a sce- update image nario where some or all of the endpoints are not protected by X.509 certificates as an authentication mechanism or the Table 2: Network overhead for each HTTP request TLS protocol as a mean to guarantee integrity and confi- dentiality in the update process, we can think of the attack The discrepancy between the measured value (148 MB) situations presented in Table 1. and the size of the image on disk (140,25 MB) is caused by Taking into account the thorough STRIDE analysis we the network overhead inherent to the TLS protocol, which have performed, we believe the usage of TLS as part of adds atleast 6%[12] more of network traffic. That happens HTTPS defeat all mentioned attacks as long as the certifi- because TLS adds an entry that varies between 20 and 40 cates, their keys, and the Signing Key are not obtained by an bytes in size to the header of the packet, adding to the entries attacker. We conclude that our is system safe and protected of the upper protocols, such as a 20-byte header for IP, and against all enumerated attacks. 20-byte header for TCP (with no options). As a result, there can be 60 to 100 bytes of overhead for each packet, which at a typical Maximum Transmission Unit (MTU) size of 1500 bytes, constitutes a minimum of 6% overhead. The authors believe the measured overhead values are neg- 5.3 Network Overhead ligible with modern Internet connections and are a small We measured the network overhead of protecting the com- trade-off for the security properties guaranteed by UpdaThing. munications of our firmware update solution. To do so, we used Wireshark, which is a well-known protocol analyzer, 5.4 Energy Consumption to capture firmware update sessions in order to measure the As IoT gateways are devices that are usually running 24/7, amount of traffic they generated. Unfortunately, Node.js we need to ensure that our solution is energy efficient as not does not allow us to generate a NSS Key Log file (a file to pose an obstacle for product adoption. Therefore, we that contains all keys and parameters used in a TLS ses- went ahead and tested our device daemon in several states sion) consumable by Wireshark and used to decrypt TLS in regards to the device’s energy consumption. We placed a 5 connections . Since TLS connections, which are backed by multimeter in series with the Raspberry Pi and proceeded ephermeral Diffie-Hellman cipher suites, prevent us from to record the current flowing through the circuit. A diagram autonomously generating the shared secret derived by the of such set-up can be found in Figure 4. Diffie-Hellman algorithm[9], even when we do have access to both servers’ private RSA keys, as the keys used in the proto- col are ephemeral6, we cannot directly measure the overhead of each protocol (ciper suite negotiations, the transmission of X.509 certificates, HTTP headers, etc.). This is as opposed to cipher suites that use shared secret keys directly derived from pre-shared secrets. Therefore, only estimates from raw traffic and known facts regarding the HTTP headers and payload (request body) are possible. In Table 2, the readers may see the average of the measure- ments that were performed. For each HTTP request, three measurements were taken from Wireshark’s Transmission Control Protocol (TCP) conversations statistics screen. Both the device and a laptop acting as both the Update Server and the Signing Server were connected to the same wire- less router, which may also incur in network overhead as TCP retransmissions are likely to occur. For reference, the Figure 4: Diagram of set-up for current measure- firmware update image that was used for testing purposes ments had a size on disk of 140 252 672 bytes. As is widely known, the formula for the Electric Power is P = V I. Since the Raspberry Pi 2 operates at 5V, the results shown in Table 3 can be obtained. 3The same image was downloaded and flashed three times. We used some tampering to change the image’s timestamp to force its installation. 5https://github.com/nodejs/node/issues/2363 4The image is not transmitted. The device is purely noti- 6https://wiki.openssl.org/index.php/Diffie Hellman#Diffie- fied and then proceeds to download the image in a separate Hellman in SSL.2FTLS HTTP request. Figure 3: Data Flow Diagram of UpdaThing’s components

Endpoint Server Client Possible attacks Device controlled by an attacker could download update images. Malicious actor could perform a Man-in-the-Middle (MitM) attack and force a device to download a given update image (could cause a Denial of Service (DoS), achieve Remote Code Execution (RCE) if the signing server’s key has been compromised and images signed

GET Update Server Device with the correct keys were produced or even force a rollback to a previous legitimate vulner- /updates/{id} able firmware version). Spoofing a device and update server identity, Tampering with a client’s update image, Information disclosure of firmware update image and Elevation of privilege in regards to access to the updating device are, thus, possible.

Threat actor could perform a MitM attack and force devices to download update images

POST Update Server Device by their IDs (forcing rollback to a previous legitimate vulnerable version). Spoofing the /newUpdate Update Server’s identity and Tampering with the update ID are possible. Attacker could upload malformed or badly signed images as well as sniff and obtain legitimate firmware images. Spoofing Update Server or Signing Server identities, Information dis-

POST Update Server Signing Server closure of firmware update images and Denial of service by uploading malformed/badly /updates/ signed images are, thus, possible.

Malicious actor could perform a Denial of service to the Update Server by injecting a

POST Update Server Device high number of malformed I’m Alive messages and Spoofing devices’ identities, because the /imAlive Update Server notifies available clients when a new firmware update is available.

Threat actor could upload malicious images to get them signed and installed on devices, or sniff unsigned legitimate firmware images. Spoofing a developer’s or Signing Server

POST Signing Server Developer identities, Tampering with installable firmware update images, Repudiation of uploaded /updates/ images and Information Disclosure of firmware update images are possible.

Attacker could pose as the Update Server and notify the device of an outdated update

POST Device Update Server image, forcing it to rollback its software version. Spoofing Update Server’s identity and /newUpdate Tampering with installed firmware version are possible.

Table 1: STRIDE analysis for each endpoint State Current (A) Power (W) I’m Alive messages per day, with a default configuration of Idle 0.46 2.3 sending a message every 5 minutes. Therefore, in a day, each Radio blinking 0.47 2.35 device produces 288×126 = 36.29kB of database records per (in operation) day. One million devices would require 36.29GB of database Node.Js VM startup + records per day. AWS Elastic Block Storage (EBS) Solid Update Daemon check- 0.52 2.6 State Drives (SSDs) have a price of $0.11 per GB of provi- ing for updates sioned storage per month 10, which means that, for storing a Downloading firmware day worth of data for one device it would cost 3.99 × 10−6 $ 0.51 2.55 update image per month and for storing a day worth of data for one million Verifying firmware up- of devices it would cost 3.99$ per month. In order to cal- 0.50 2.5 date image culate for n days worth of storage, one would just compute Flashing firmware up- n × 3.99$. 0.34 1.7 date image Column Data type Total size (bytes) Table 3: Device energy consumption in each state device id text (64 characters) 68 firmware version int(11) 4 As can be concluded from the previous table, the differ- ip varchar(45) 46 ence between the device in an idle state and downloading port int(11) 4 and verifying update images is in the order of deciwatts. timestamp timestamp 4 The authors believe such a difference is negligible and should not in deployment scenarios where the device is con- Table 4: Columns, data types and total sizes of I’m nected to a wall outlet. Alive message records. Imagining a scenario where the Raspberry Pi is connected to a 3000mAh battery, a common capacity for a high-end Finally, we should estimate the costs of network transfers battery, and using a factor of 0.7 to account initiated by our system. Looking at Table 2, we have traffic for external factors which can affect battery life, the de- discriminated between outgoing (OUT), from the server to vice’s operating time on the battery can be computed by the device, and incoming (IN), coming from the device to BatteryCapacity(Ah)÷DeviceConsumption(A)×0.7. There- the server. At the time of writing, IN traffic (from Internet fore, in an idle state, the device can last for 4.57h on the pre- to AWS EC2) was free for all AWS deployment regions11, viously mentioned battery, while only downloading firmware however OUT traffic (AWS EC2 to Internet) was paid for in update images (doing it in a loop), it can last 4.12h, and a tiered scheme. We can compute the following estimates: could last 4.2h verifying update images. Since the device is in the idle state most of the time, as • Checking for update images on the device’s boot pro- downloading a 120Mb image takes minutes in a duces 4.4 kB of OUT traffic which means that, for ev- Internet connection, verifying it takes about 8s and flashing ery device’s boot, it costs the manufacturer, at most, it to the device’s main memory takes less than a minute, 4.4 × 10−6GB × 0.09$/GB = 3.96 × 10−7$, costing taking into account booting time, all other states are neg- about 0.4$ for one million device boots. ligible to its long-term power consumption. This depends, of course, on whether the device’s main application is radio • Every device sends 288 I’m Alive messages per day, intensive or not, in which case its ’idle’ power consumption which amounts to 288 × 4.6kB = 0.0013248GB, which is relatively higher. costs 0.0013248GB × 30 × 0.09$/GB = 0.00357696$ per device per month, meaning that, for one million 5.5 Cloud Deployment Cost of devices, the manufacturer would have a receipt for Evaluating our work in terms of costs it introduces when 3576.96$ at the end of the month deployed using a cloud provider is a good indicator of how the product may fare in the eyes of companies’ business • Downloading update images is another beast entirely. managers. Web Services (AWS) is one of, if not Our measurements indicate that, for a 140MB update the most, popular cloud provider 7 and is widely used by image, about 146.9MB is transferred from the server start-ups as the place of their system deployments. to device, meaning that each update costs 0.1469GB × Firstly, let us estimate how much space our I’m Alive mes- 0.09$/GB = 0.013221$ per updated device, which may sages take on disk. Currently, the system stores all of these not seem like much, but quickly piles up. One million messages in a MySQL8 database and we have to take into ac- of updated devices costs, thus, 13221$. The manufac- count the way it stores its data on disk. Innodb’s (MySQL’s turer has to find a way to balance the costs of this storage engine) data type sizes are well known9 and can be updates with their frequency, while attempting to not used to estimate the size of the MySQL database on disk. jeopardize their devices’ security. Our I’m Alive messages are kept as records in a table with the schema described in Table 4. The total size per record on • Push notifications are sent out to all connected devices disk is, thus, 126 bytes. Each device sends (24×60)/5 = 288 and take about 3kB of OUT traffic. This means that, for each connected device, 3 × 10−6 × 0.09$/GB = 7http://www.bbc.com/news/business-32442268 2.7×10−7$ would be paid to the cloud provider, costing 8MySQL is a relational database management system. 0.27 $ to send a update push notification to one million https://www.mysql.com/ 9http://dev.mysql.com/doc/refman/5.7/en/ 10https://aws.amazon.com/ebs/pricing/ storage-requirements.html 11https://aws.amazon.com/ec2/pricing/ of connected devices. The number of connected devices Code Signing as signing a binary using a Digital Certificate is usually lower than the number of sold devices, which (and related PKI), we do not take into account code signing makes it more affordable. that happens in some systems via symmetric keys. Confi- dentiality of the downloaded firmware image is commonly A device’s lifetime costs for the manufacturer encompass guaranteed through the usage of image-encrypting symmet- the cost per month of storing a given period of I’m Alive ric keys. messages, the amount of traffic that the device generates and CAO et al’s system[4] only guarantees Integrity and Confi- a shared cost for n devices connected to the same Update dentiality of the firmware image until the physician decrypts Server for its running time (EC2 instance pricing). Since we the AES-encrypted file using the PDA. Once it is decrypted, cannot estimate the latter, as it would imply an exhaustive it is transmitted unencrypted to the IPG via its controller. scalability study that we chose not to pursue, and because it Therefore, an attacker that can physically eavesdrop on com- should be relatively low, as any robust instance type should munications between the PDA and the IPG’s controller or be able to accommodate hundreds of devices, its cost per between the IPG’s controller and the IPG itself has access device should be negligible, when compared to the other to the decrypted firmware image and can pursue tamper- costs. ing attacks. However, this situation is highly unlikely and A reasonable period of time for device renewal is 2 years. will probably arise suspicion from health professionals as it During these 2 years, a gateway, using our update system, requires extremely close proximity to the patient. would cost (2 × 12) × (30 × 3.99 × 10−6$) ≈ 0.003$ to store As can be seen by analyzing table, we could not find a its I’m Alive messages for a period of 30 days. Assuming fully implemented research system that guaranteed all four that the device boots up, at most, once per day, for the properties without leaving room for a successful attack. For period of 2 years, the device would cost the manufacturer instance, Nilsson and Larson’s[22] system leaves the key (2 × 12 × 30) × 3.96 × 10−7$ ≈ 0.0003$ for doing update management to further work and works with unique perma- checks on boot. Sending I’m Alive messages costs about nent pre-shared keys between vehicles and the portal, which 0.0036$/month. which means that the manufacturer has makes the system easier to attack, in regards to the firmware to pay the cloud provider, at most, for 2 years of device image confidentiality it guarantees. operation, 2 × 12 × 0.00357696$ ≈ 0.086$. It is reasonable Two proprietary systems closer to what we developed are to assume that the manufacturer would release 10 updates the NEST [21] and the OnHub router[11]. in the device’s lifetime of 2 years, which means that, at They both update via HTTPS and make use of TLS as a way most, 10 push notifications would have to be sent out and 10 to assure data integrity and confidentiality while in tran- update images would have to be downloaded. These would sit, and both make use of Public-key Cryptography for code cost 10×2.7×10−7 = 2.7×10−6$ and 10×0.013221$ ≈ 0.13$, signing. respectively. Adding all of these costs up, we arrive at the grand total of approximately 0.219$ per device for its 2 years of lifespan, which is an amount that can easily be absorbed 7. CONCLUSIONS in the manufacturer’ margin. With the work described in this paper we propose a so- We would like to take a moment to compare our solu- lution for a major security problem in IoT: how to perform tion with service offerings by AWS. CloudFront, Amazon’s secure firmware updates in gateway devices. We established Content Delivery Network (CDN), has both per request requirements for a system attempting to solve this issue and and per transferred GB pricing. Amazon prices HTTP and chose HTTP over TLS as a way to solve our secure com- HTTPS requests differently: HTTPS requests cost 33%12 munication challenges. In order to guarantee code signing more than the same requests done by HTTP, although the of transmitted images, we used Binary Hashing and Public- price per transferred GB stays the same. This means that Key cryptography. We implemented the system, described Amazon estimates a 33% margin to account for overheads its architecture and evaluated it in three aspects: a security introduced by HTTPS, and, in order to use a custom X.509 analysis, measurements for network overhead and energy certificate for these HTTPS connections, Amazon charges consumption, and we finished by comparing it to existing 600$ per month to the manufacturer for the privilege. This systems. sort of solution would only allow for the download of update Further work that may be done in this area includes the images, discarding the rest of the additional features pro- usage of Trusted Platform Modules to store keys and cer- vided by UpdaThing. All of these reasons make our system tificates and perform cryptographic operations in updating more attractive in terms of costs. devices, unburdening the file system from storing these im- portant artifacts and making it more difficult for an attacker to obtain them. Important work should also be conducted in 6. RELATED WORK regards to devising lightweight logging strategies for IoT de- In preparation for this work, the authors studied available vices. Our system produces logs that are only stored in each research on firmware update systems. In this section we component’s file system and are currently not being trans- make a brief analysis on the studied systems and how they mitted off-site. Developing lightweight logging daemons for compare against UpdaThing. You may find a summary of IoT devices that integrate with solutions like Logstash13 the security properties guaranteed by such systems in Table would be an interesting research project. 5. We chose to conduct our firmware update process by re- As one can see, most systems rely on Code Signing (some placing entire firmware images in updating devices, which via symmetric keys) to ensure firmware image Integrity and presents inefficiencies when updates do not contain many update source Authentication. Since we consider the act of 13Logstash is a data pipeline aimed at processing logs. https: 12https://aws.amazon.com/cloudfront/pricing/ //www.elastic.co/products/logstash .REFERENCES 8. the in project the and so. software proprietary do update develop to to firmware infrastructure not secure opt that a and implement system to striving ufacturers sections only differential replacing filesystem, performs changed. device’s that that the functionality for a extend updates to with be system would project our research interesting An changes. 9 .DFI n .E ELA.Nwdrcin in directions New HELLMAN. E. M. and DIFFIE W. [9] your making 101: Bootloaders Durlin. D. and Davis T. [8] firmware When Stolfo. J. S. and Costello, M. Cui, A. [7] P. R. Biase, D. G. M. Herrero, A. R. Costa, C. L. [6] and pcs on firmware update to How Case. L. [5] Wang. W. and Li, L. Hao, H. Ma, B. Hu, C. Cao, Y. [4] https: updates. Ota Project. Source Open Android [3] UPnP. - Foundation Connectivity Open [2] https://buildroot.org. Buildroot. [1] l neetdprismyfidteetr orecd for code source entire the find may parties interested All man- for option an be may system our that conclude We cryptography. Bootloaders-101--making-your-embedded-design-future-proof. http://www.embedded. com/design/prototyping-and-development/4410233/ proof. future design embedded embedded of study exploitation. case A attack: modifications 2010 February 1, Issue 56 archive,Volume Electronics for Consumer download on air Transactions upgrade. the receivers Over television Zuffo. digital K. M. and Nunes, how-to-update-firmware-on-pcs-and-peripherals-3237825/. http://www.pcadvisor.co.uk/how-to/software/ peripherals. ) 5 Issue: , (Volume:15 implantable for devices. upgrades medical software for method Secure 2015. 11 //source.android.com/devices/tech/ota/index.html, http://openconnectivity.org/upnp.

Type of Proprietary DSSmoim2013 Symposium NDSS

tar.gz System EETASCIN ON TRANSACTIONS IEEE snhaSineadTechnology and Science Tsinghua al :Smayo urnespoie yssesi eae works related in systems by provided guarantees of Summary 5: Table ogeOHbrouter[11] OnHub Google thermostat[21] NEST OS[3] Android routers[14] Home al.[4] et CAO Schwartzman[16] and Katzir al.[15] et Itani al.[6] et Costa Larson[22] and Nilsson System Update otda http://bit.ly/28lpB9I. at hosted 2010. , 2010. , ora IEEE Journal 2013. ,                                   Authentication of Update source

- - - - Integrity (transit) 1]M arl.Lnx-bo rcs,ii n shutdown. and init process, boot - Linux Garrels. M. [10] 2]R .Rvs,A hmr n .Almn method A Adleman. L. and Shamir, A. Rivest, L. R. [23] firmware Secure Larson. E. U. and Nilsson K. D. [22] nest. at safe data Keeping Nest. [21] tutorial. Initramfs Mugabi. S. [20] McConnell. S. [19] initramfs. and rootfs ramfs, Landley. R. [18] architecture. and gateways IoT Konsek. H. [17] firmware Secure Schwartzman. I. and Katzir L. [16] secure a Petra: Chehab. A. and Kayssi, A. Itani, W. [15] SOHO Exploiting Evaluators. Security Independent [14] protocol (TLS) Security Layer Transport The IETF. [13] Grigorik. I. [12] https: features. security Onhub Google. [11] http://www.tldp.org/LDP/intro-linux/html/sect 1976. November THEORY INFORMATION 0.IE nentoa ofrneon Conference International IEEE Workshops ’08. ICC vehicles. 2008. intelligent Workshops, in Communications air the over updates https://nest.com/security/. http://nairobi-embedded.org/initramfs Construction Software of filesystems/ramfs-rootfs-initramfs.txt. https://www.kernel.org/doc/Documentation/ Things of Internet the to Guide on Exhibition PES and IEEE Conference International 2nd 2011 Europe), devices. (ISGT grid smart for updates networks and Mobile QoS and on Wireless symposium for ACM Security 5th the of Proceedings devices. for network protocol severely-constrained update software energy-efficient and studies/routers/soho http://www.securityevaluators.com/knowledge/case routers. 1.2. version 2013. O’Reilly, //support.google.com/onhub/answer/6309220?hl=en. 02.html. Confidentiality (transit)

Code signing ihPromneBosrNetworking Browser Performance High oeCmlt:APatclHandbook Practical A Complete: Code asymmetric/symmetric yeo encryption of Type ymti none / symmetric asymmetric asymmetric asymmetric asymmetric router symmetric irsf rs,2004. Press, . IT-22(6):644–654, , ak.h,2013. hacks.php, 2015. , noaieSatGrid Smart Innovative 2Wnt’09 Q2SWinet 2008. , tutorial.html. 2009. , h DZone The 2011. , 04 . for obtaining digital signatures and public-key cryptosystems. Commun. ACM, 21(2), Feb. 1978. [24] N. J. Rubenking. Securing the internet of things. http: //www.pcmag.com/article2/0,2817,2483635,00.asp. [25] P. Suresh, J. Daniel, V. Parthasarathy, and R. Aswathy. A state of the art review on the Internet of Things (IoT): history, and fields of deployment. Science Engineering and Management Research (ICSEMR), International Conference on, 2014.