Secure Firmware Updates for Constrained IoT Devices Using Open Standards: A Reality Check Koen Zandberg, Kaspar Schleiser, Francisco Acosta, Hannes Tschofenig, Emmanuel Baccelli To cite this version: Koen Zandberg, Kaspar Schleiser, Francisco Acosta, Hannes Tschofenig, Emmanuel Baccelli. Secure Firmware Updates for Constrained IoT Devices Using Open Standards: A Reality Check. IEEE Access, IEEE, 2019, 7, pp.71907-71920. 10.1109/ACCESS.2019.2919760. hal-02351794 HAL Id: hal-02351794 https://hal.inria.fr/hal-02351794 Submitted on 6 Nov 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Secure Firmware Updates for Constrained IoT Devices using Open Standards: A Reality Check Koen Zandberg Kaspar Schleiser Francisco Acosta Inria & FU Berlin Inria & FU Berlin Inria Hannes Tschofenig Emmanuel Baccelli Arm Ltd. Inria ABSTRACT This highlights the need to design a firmware update mecha- While IoT deployments multiply in a wide variety of verticals, most nism into IoT devices at the beginning of the product development. IoT devices lack a built-in secure firmware update mechanism. With- Of course, if designed incorrectly, firmware updates can become at- out such a mechanism, however, critical security vulnerabilities tack vectors themselves. The Zigbee Worm54 [ ], for example, trig- cannot be fixed, and IoT devices can become a permanent liabil- gered a chain reaction combining a series of malicious firmware ity, as demonstrated by recent large-scale attacks. In this paper, updates and promiscuous wireless communications. The situation we survey open standards and open source libraries that provide would be significantly improved if developers could use a stan- useful building blocks for secure firmware updates for constrained dardized firmware update mechanism rather than having to design IoT devices – by which we mean low-power, microcontroller-based their own. devices such as networked sensors/actuators with a small amount In this paper, therefore, we explore the options that developers of memory, among other constraints. We design and implement a have today, and we design a prototype that enables IoT firmware prototype that leverages these building blocks and assess the se- updates based on standardized building blocks. curity properties of this prototype. We present experimental re- We focus in particular on firmware update mechanisms that can sults, including first experiments with SUIT, a new IETF standard work on constrained IoT devices. Such devices, as specified in RFC for secure IoT firmware updates. We evaluate the performance of 7228 [19], use microcontrollers – for instance Arm Cortex-M – on our implementation on a variety of commercial off-the-shelf con- which run real-time operating systems, such as RIOT, FreeRTOS, strained IoT devices. We conclude that it is possible to create a µC/OS, Contiki, mbed OS, among others [30]. Compared to ma- secure, standards-compliant firmware update solution that uses chines that run full-blown operating systems, such as Linux, con- state-of-the-art security for IoT devices with less than 32kB of RAM strained IoT devices use a fraction of the power and are equipped and 128kB of flash memory. with RAM and flash sizes in the kilobyte range. Constrained IoT devices cannot afford the energy drain of Wi-Fi, and thus connect CCS CONCEPTS to the network using low-power, wireless, link-layer technologies, such as Bluetooth Low-Energy, IEEE 802.15.4, LoRa, 3GPP Cellular • Computer systems organization → Embedded systems. IoT (NB-IoT), or through wired buses, such as BACnet. KEYWORDS Internet of Things, IoT, Security, Software Update, Firmware Up- The contributions of this paper are structured as follows: date, Open Standards, Constrained Device (1) In Sections II-III, we survey available open standards and open source libraries, which provide useful generic building 1 INTRODUCTION blocks that can be used to enable IoT firmware updates; The increasing availability of low-cost hardware, new low-power (2) In Section IV, we design and implement a prototype that radio technologies, and real-time operating systems specially de- leverages the building blocks we surveyed. This prototype signed for these embedded devices makes the Internet of Things enables secure firmware updates on a large variety of con- (IoT) accessible to a broader range of developers. IoT devices are strained IoT devices, while entirely avoiding proprietary mech- now used in many verticals, from logistics to precision farming, anisms and code; introducing new ways to optimize existing business processes and (3) In Section V, we measure and compare the performance of enabling novel use cases. IoT devices are also used in critical infras- various crypto libraries that are relevant in this context; tructures where safety and security plays an even more important (4) In Section VI, we assess the security properties of our pro- role. totype; However, while IoT devices are expected to have a major impact (5) In Section VII, we measure and compare the performance of on our economy, they are also known for their weak security. The several deployment configurations using our prototype, and Mirai botnet [5], for example, demonstrated that large-scale DDoS provide the first experimental evaluation of the IETF SUIT attacks using compromised IoT devices threaten other communi- specification; cation infrastructures. It is equally alarming that many of these (6) In Section VIII, we discuss the limitations of our prototype. compromised IoT devices are not equipped with a firmware update We conclude that, as we have shown, it is possible today to mechanism and, therefore, remain unpatched to this day. create a generic, secure firmware update mechanism that complies with open standards, and we provide recommen- In addition to authentication and integrity protection, even when dations for future work. updates are stored on untrusted repositories, the SUIT specifica- tions enable encrypting the firmware image, to protect against at- 2 PRIOR WORK ON SOFTWARE UPDATES tacks based on reverse engineering. SUIT followed previous work FOR CONSTRAINED IOT DEVICES such as FOSE [? ] which proposed firmware encryption and sign- ing using JSON and JOSE. The Update Framework (TUF)3 [ ] and An IoT firmware update solution is a special case of software up- Uptane [37], designed for use in connected cars, aim to ensure the date, and consists of three areas of work [23], namely: (a) embed- security of a software update system, even against attackers who ded software design on low-end IoT devices, (b) backend frame- compromise the repository or signing keys. ASSURED [14] builds work, and (c) network transport of the firmware towards the IoT on TUF to improve support for constrained IoT devices by lever- devices. aging a trusted intermediate controller between the update reposi- Embedded software design on low-end IoT devices. The software tory and IoT device. CHAINIAC [46] is another approach that uses on an IoT device has to be prepared to support a firmware update a blockchain-like mechanism to attest to the history of prior up- mechanism. The device needs a bootloader, the logic that is exe- dates, even without central authority. cuted first when the device boots and determines which firmware it launches. Sometimes devices are equipped with multiple boot- Network transport. The third aspect of IoT firmware updates con- loaders; for example, a stage 1 bootloader in the ROM and a stage cerns the dissemination of software through the network. The vari- 2 bootloader that can be updated. The reason for such designs is ety of approaches to this topic, as presented in recently published security-related because updating a bootloader can lead to a bricked literature, includes protocols that optimize the dissemination of up- device. Whenever a bootloader is present on a device, the memory dates through multiple paths in a multi-hop, low-power wireless layout of the hardware has to be considered, and exception han- network [31]; updating network stack modules to reconfigure the dlers1 must be repositioned. network on the fly [65]; and using the Message Queuing Teleme- The typical firmware update procedure is fairly simple: adevel- try Transport (MQTT) protocol to disseminate software updates oper recompiles the code and generates an entirely new firmware to a fleet of IoT devices [27]. 6LoWPAN protocols [58] enable end- image, which is then distributed to the device. The flash memory to-end IP connectivity from constrained IoT devices to anywhere of the IoT device is split into memory regions (slots) containing (i) on the (IPv6) internet. The IETF Trusted Execution Environment the bootloader and (ii) firmware images (with some metadata). The Provisioning (TEEP) working group [32] is standardizing a trans- new firmware is stored into one of the available slots. TheIoTde- port mechanism to update trusted applications running in trusted vice is then reset so that the bootloader can boot the new firmware execution environments (TEEs), such as Arm TrustZone and Intel image [10]. This approach is used, for example, by MCUboot [2] SGX. and ESPer [27]. Other considerations can lead to different designs. For instance, 3 OPEN STANDARDS FOR SECURE one may consider the granularity of the software update, or the CONSTRAINED IOT FIRMWARE UPDATES amount of data that needs to be transmitted for an update. Certain Over the last few years, the technical community has been work- approaches enable partial update via dynamic loading of binary ing on open standards [36] that can be combined to facilitate IoT modules [26, 55], while others use differential binary patching [33]. firmware updates.