Trustworthy firmware update for Internet-of-Thing Devices using physical unclonable functions

Depósito de investigación de la Universidad de Sevilla https://idus.us.es/ This is an Accepted Manuscript of an article published by IEEE in 2017 Global Internet of Things Summit (GIoTS) on 24 August 2017, available at: https://doi.org/10.1109/GIOTS.2017.8016282 “© 2021 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other Works” Trustworthy Firmware Update for Internet-of-Thing Devices Using Physical Unclonable Functions M. A. Prada-Delgado, A. Vázquez-Reyes, and I. Baturone Instituto de Microelectrónica de Sevilla, IMSE, CNM Universidad de Sevilla, CSIC Seville, Spain {prada, lumi}@imse-cnm.csic.es Abstract— Connected devices that are part of the so-called Internet of Things (IoT) need to update their firmware over their lifetime. The problem is that updates can be used by attackers to inject malicious code. This work presents a lightweight protocol to update each device in a secure way. The cryptographic keys employed are fresh and are not stored but reconstructed by exploiting the Physical Unclonable Functions (PUFs) of the device hardware. The feasibility of the proposal is illustrated with experimental results of IoT devices that use the SRAM PUFs in their Bluetooth Low Energy (BLE) system on chips. Index Terms— IoT, firmware, update, security, PUF, Bluetooth. I. INTRODUCTION Nowadays, connectivity has become a tremendously important part of our daily life. Connectivity is reaching new fields such as health, homes, automotive, and cities [1], where continuous monitoring can be very helpful (or even vital) and save costs to public and private services. Being connected allows us not only to be informed, but also to control many devices that were not capable of responding to human actions before. Recent examples at homes are electronic smart locks or light bulbs that can be controlled remotely [2]-[3]. On the other hand, being constantly connected poses risks to our security and privacy. A recent case was the IoT worm reported in [3], which showed how the firmware of nearby lightbulbs can be updated over-the-air to run malicious code. To avoid security problems, some manufacturers such as ARM with TrustZone or Intel with SGX have implemented specific processor architectures. However, sensitive information inside the memories of these microprocessors can be read using novel attack techniques [3]-[4]. Another research line has focused on hardware security. One hot topic in this field is the use of Physical Unclonable Functions (PUFs). Although the use of PUFs was proposed at first for IC fingerprinting [5], PUFs can be found in the intrinsic hardware of many devices. Particularly interesting for IoT devices, which widely use wireless communication based on Bluetooth Low Energy (BLE), is that PUFs can be found in the Static Random Access Memory (SRAM) of the BLE system on chip, so that hardware security is available at very low cost [2]. Several works on secure protocols using PUFs can be found in literature [5]. PUFs are assumed to be resistant to hardware attacks and to provide a lightweight mechanism to exchange and/or store sensitive information. However, this requires obfuscating the cryptographic keys employed and the generation of true random bit strings. In the case of SRAM PUFs, this can be done efficiently if some SRAM cells are used for obfuscation and other ones for randomness generation [7]. This work presents a new lightweight and trustworthy firmware update for IoT devices using PUFs. The paper is organized as follows. Section II summarizes the PUF basis and metrics. The registration and reconstruction steps of the obfuscation method are explained in Section III. Section IV describes the message exchange and firmware update protocol and Section V depicts its advantages. Section VI summarizes with experimental results how to implement the proposed protocol based on SRAM PUFs in the CC2541 BLE system on chip. Finally, Section VII includes the conclusions. II. PRELIMINARIES The start-up values of SRAM cells have been used to generate device identifiers because they usually depend on the manufacturing process parameters of each SRAM. Hence, although the external conditions change, the SRAM intrinsic nature remains. If the variability of the manufacturing process is random, the identifier is difficult to be generated by another memory or ascertained by someone willing to clone the memory. In this situation, the SRAM behaves as a PUF [5]-[7]. PUFs are usually used to obfuscate sensitive information. If the SRAM start-up values are highly random and unique then the data resulting from combining a secret key with the SRAM values are highly entropic (no information can be leaked) and the secret can only be recovered by the SRAM which obfuscated it. Given k sequences, R, of n bits generated by the start-up values of k SRAMs, randomness and uniqueness are evaluated by the average inter fractional Hamming distance (HD), as follows (ideally taking the value of 0.5): 󰇣 󰇤 󰇛󰇜∑∑ ,      (1) Bit flipping of the start-up values of SRAM cells causes a detriment on the capability to reconstruct sensitive information, but it can be exploited to generate random sequences that change from one start-up to another. Randomness of these sequences, which can also be evaluated by Equation (1), can be analyzed more extensively by the NIST tests [8]. Also, the minimum entropy is used to measure how different are the nbit sequences in multiple start-ups [7], as follows ( is the maximum probability of the i-th bit taking logic value ‘0’ or ‘1’ in a set of measurements):   ∑󰇛󰇜   ∙100 (2) III. PUF-BASED OBFUSCATION A. Registration Since the communication between an IoT device and a server (manufacturer or manager) in the context of a device firmware update is always a point to point communication, symmetric cryptography is employed to encrypt information through the communication channel and to ensure the integrity and authenticity of the messages by message authentication codes (MACs). Symmetric-key schemes are much simpler than asymmetric ones and, hence, more suitable for IoT devices with constraints of power consumption and real-time operation. As drawbacks, nonrepudiation is not provided by standard symmetric schemes and the first symmetric keys must be established between parties using a secure channel. The proposed trustworthy firmware update contemplates a registration phase during the manufacturing process, in a secure environment, in which the first symmetric keys are established between the IoT devices and the server. The devices are characterized by reading the start-up values of their SRAM cells. Then, the cells are classified into cells to obfuscate information, which do not usually show neither bit flipping nor bias and provide the values; and cells to generate nonces, which usually show bit flipping and provide the values. At the end of this phase, the devices store the so-called Helper Data (HD) that help to reconstruct the keys of the encrypted firmware. Helper Data are generated by performing the operation1  ⨁ as described in [2], where ⨁ is a binary XOR operation, and “” is the coded version (using an error correction code, ECC) of the unique random key set generated by the manufacturer 󰇝1,1󰇞 to encrypt and authenticate the communication. Each device stores its HD in a non-volatile memory, and the server stores the keys 󰇝1,1󰇞 that will be used in future firmware updates. With the first phase finished, devices can be safely put into market. B. Reconstruction When the device is bought by a client and powered up for the first time, it reads the start-up values of its SRAM cells and saves temporarily the measure in a volatile memory. The values used to obfuscate information,′, are similar but not exactly equal to the original  read by the server at registration. Hence, when the device performs the operation′⨁1′, it obtains an erroneous version of the “” generated at registration. Then, it uses the decoder of the error correction code used at registration so as to reconstruct the original key set:  󰇛′󰇜. If the original secret keys󰇝1,1󰇞 are used by the device to update its firmware, they are never used again. Instead they are changed by using a Key Derivation Function (KDF) that follows NIST recommendations [9]. This function uses the original󰇝1,1󰇞, a nonce sent by the server, and a nonce generated by the device,′, to derive the new key set 󰇝2,2󰇞. The device removes 1 and stores the new 2, which obfuscates the new key set with ′. IV. TRUSTWORTHY COMMUNICATION The notation used to describe the operations of the proposed protocol is as follows:  󰇟||󰇠 represents the plaintext data “” concatenated with the plaintext data “”.  󰇟󰇠 represents the plaintext data “” encrypted by the key “” using, for example, the block cipher AES (Advanced Encryption Standard).  󰇛󰇜 represents the authentication code of the plaintext data “” with the key “” performed, for example, by a CMAC (Cipher-based Message Authentication Code). The notation used to describe the message exchanges is as follows:   represents the message time-out established for every message pair exchanged. Each message sent needs a response, so if the server or the device initiates a communication (it sends a message) but it doesn’t receive any response before , the message is retransmitted again.  "" represents a randomly initialized index which increases by 1 both in the server and the device simultaneously after each message exchange is successfully completed.    represents the   version of the  firmware.    and represents, respectively, the random seed generated by the server and the device, which are used to derive the new key set 󰇝2,2󰇞 from the old key set 󰇝1,1󰇞. Using the above notation, the trustworthy firmware update is shown in Figure 1. For clarity,  is represented just once, but it exists for every message pair sent. The encryption and authentication keys are used only once to ensure that firmware updates are released by a trusted source. In addition, the update is performed correctly despite the errors produced by message exchange exceptions, such as transmission and reception errors, errors in the integrity of the message, or a response delay that exceeds the time-out . An example of the steps performed by the proposed protocol (shown in Figure 1) is the following: 1) The server sends the firmware update to the device, encrypted by 1 and authenticated by 1. Since these keys have never been used before, it is difficult they could be compromised. The update includes the new firmware, , a nonce generated by the server, , and the update index Fig 1. Trustworthy firmware update "". The latter helps to avoid replay attacks and to verify the message integrity. 2) If the device receives the update message, it reconstructs both keys 󰇝1,1󰇞 with its 1 stored and the′read from its SRAM. If the integrity of the message is verified, it performs the firmware update and generates a nonce, , from the′read from its SRAM. The device replies with a message containing  and the update index “i+1”, encrypted by 1 and authenticated by S1. It is important to note that the device has to follow a very careful algorithm in order to protect the update process. Thus, if the firmware update message has been successfully received and checked, then the device stores the update message, the encrypted and authenticated reply message, and the index "1" in its non-volatile memory. After, it derives the new encryption and authentication keys with the Key Derivation Function (KDF) as follows: 2󰇟,󰇠 2󰇟,󰇠 The device creates and stores the new 2 obtained from 󰇝2,2󰇞 and PUF′, overwriting the previous 1 and updating the firmware. If the update process is interrupted because, for example, the device is powered off in the meantime, the device, when powered up, will recover the keys associated to the Helper Data stored. If the old 1 instead of the new ones are stored, the device recovers the old keys and it is able to check the integrity of the firmware stored and decrypt the encrypted reply message. If the decrypted index matches with the actual index ("i+1), it can be trivially inferred that the device neither has changed its keys nor updated the firmware, and, therefore, it should derive the new keys and finish the update process. Otherwise, if the new 2 are stored, the device cannot decrypt the content of the stored reply message, thus detecting it has already changed the keys and updated the firmware. Hence, the device can always detect the interruption and know if it should derive or not the new keys as well as update or not the firmware. Finally, in order to establish the new keys with the server, the device replies with the encrypted and authenticated reply message stored in its non-volatile memory. The next time, they both have to use 󰇝2,2󰇞. 3) If the server does not receive any message after time , it considers that the reply message is lost or that the device has not received the update. For this reason, the server will resend the update with the same index "" until it receives the reply message that contains the index "1". 4) The device receives the same firmware update message again, but it doesn’t perform the update because it has already been updated and it deleted the keys 󰇝1,1󰇞 that are necessary to decrypt and verify this update, so from the device point of view this update is a completely unknown message. For that reason, it replies sending to the server the last message stored in its non-volatile memory, with  and the update index "1". 5) When the server receives the message containing  and the update index "1", it derives the new keys 󰇝2,2󰇞 using  and, it deletes the old keys 󰇝1,1󰇞, and it considers that the firmware update has been performed properly. The next time that the manufacturer releases an update, the server will communicate with the device using 󰇝2,2󰇞. The above example considers cases where messages are lost, but in an error-free communication, the steps to be followed would be 1, 2 and 5. After that, the server could send the next future update using the index "2", it could wait for a reply "3" from the device, and so on. V. ADVANTAGES OF THE PROPOSAL In general terms, a conventional firmware update (frequently performed over the air) uses a predefined incremental counter with a seed starting by 0, or a very simple pseudorandom number generator to execute a challengeresponse exchange with no encryption at all. On the other hand, the keys used to encrypt the communication are exchanged in plain text [11], never change, and are written in the non-volatile memory. Hence, if an attacker dumps the content of the nonvolatile memory, it is possible to completely clone the device. Thus, the devices are vulnerable to replay and denial-of-service attacks, firmware modification or malicious code injection attacks, sniffing attack, and physical attacks, among others. The proposed protocol presents several advantages over conventional update methods [2]-[3] that should be noticed: Fig 2. Distribution of fractional Hamming Distances between the SRAM start-up values selected for obfuscation Fig 3. Convergence of the minimum entropy to its asymptotic value  The Helper Data do not reveal information about the shared secrets, so there is no sensitive information stored in the non-volatile memory of the device.  The device can derive fresh keys after its firmware update.  The firmware update is compiled only once because it is the same for all devices (it does not contain any hardcoded sensitive information).  The information is always encrypted, fresh and authenticated, so the protocol is resistant to passive sniffing, man-in-the-middle (MITM) and replay attacks, partial encrypted data manipulation, and device counterfeits.  In case the key 1 becomes compromised (for example due to a database server leak) and the message is decrypted, the message integrity will be preserved thanks to the other key 1, and a replay attack would not be possible thanks to the update index.  The SRAM PUF provides a true random source of entropy, which lets the device to generate and exchange true random nonces to derive keys. VI. USE CASE IN CC2541 AND EXPERIMENTAL RESULTS Implementation of the proposed protocol in the Bluetooth Low Energy CC2541 keyfob from Texas Instruments has been analyzed. The chip of this keyfob supports BLE up to 4.1 version, which has several improvements over classical Bluetooth [10] but has been reported as unsecure [11]. In this context of IoT devices using BLE, the proposed protocol improves security. The chip allows encryption process to be performed by the AES cipher integrated in the hardware, and the MAC signature to be performed by the CBC-MAC, both of them using a key size of 128 bits. The key  used to encrypt/decrypt the data, and the key  used to authenticate the encrypted messages are both obfuscated in the Helper Data, . Since the error correcting code selected is a repetition code of 8 bits, the  have a size of 2048 bits ((128+128)*8). In order to characterize the capability of the SRAM in the CC2541 to obfuscate the keys and to generate random nonces, the start-up values of 56,000 cells (7,000 Bytes) were read 40 times from 10 chips. These measures could be affected by changes in the operation conditions such as temperature and voltage variation, or by memory aging. Effect of memory aging over SRAM PUFs has been proved to be considerably lower compared to operation conditions variation [2], and the algorithm applied under nominal conditions shows quite similar results when compared to the results under voltage or temperature variation. Therefore, in order to simplify the characterization process performed by manufacturers, the CC2541 keyfob has been characterized under nominal conditions and an extra length security margin has been considered to include any worst-case operation condition. There were cells enough which do not usually show either bit flipping or bias (after detecting the stable cells and applying Von Neumann debiasing algorithm [2]). Using those cells and the same secret keys to generate the Helper Data of the devices, the distribution of the fractional Hamming distance between pairs of Helper Data from different devices is shown in Figure 2. The average inter fractional Hamming distance between  responses measured as in Equation (1) was 0.5, which means a very good uniqueness between the start-up values selected. Thus, a counterfeit device in which the memory content of the original device is copied would not be able to work as expected, mainly because the above ideal 0.5 average Hamming Distance and the Gaussian distribution shape would make the counterfeit device recover a fully random sequence with no sense at all. Moreover, the reconstruction method was measured to be performed successfully with an error rate as low as3.2510. There were cells enough (more than 128) which usually showed bit flipping. Using those cells to generate the nonces, the randomness obtained was good. Thanks to the selection of a good number of cells with bit flipping, the SRAM is able to generate enough random bits, no matter the operation condition. Figure 3 shows the minimum entropy calculated as in equation (2) with different number of measurements (from 1 to 100 start-ups) from the same cells of one of the devices. The minimum entropy of these cells converges to about 75%, which implies that the maximum probability of the start-up value of these cell taking logic value ‘0’ or ‘1’ in a set of TABLE I. RESULTS FOR THE UNIFORMITY OF P-VALUES AND THE PROPORTION OF PASSING SEQUENCES WITH NIST TESTS (FOR NONCES) C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 P-VALUE PROPORTION STATISTICAL TEST 12 9 11 7 6 20 8 10 6 11 0.085587 96/100 Frequency 9 10 6 9 8 12 3 17 15 11 0.090936 96/100 CumulativeSums (fw) 10 7 8 6 7 22 4 9 12 15 0.003201 96/100 CumulativeSums (bw) 15 8 11 12 10 9 9 14 6 6 0.494392 98/100 Runs measurements is, approximately, 59% on average, what makes these cells very suitable to generate the nonces for the key derivation function. The result of applying the NIST tests (frequency, forward and backward cumulative sums, and runs) to these sequences with a confidence of 99% are shown in Table 1. The frequency test measures if the number of 1’s and 0’s in the sequences (the start-up values of a set of these cells) are approximately the same as would be expected for a truly random sequence, that is, if there is or not bias. The cumulative sum tests evaluate if the cumulative sums of the partial sequences occurring in the tested sequence is near zero, as in a random walk. The run test measures if the oscillation among substrings of consecutive 1’s and consecutive 0’s is too fast or too slow. As it can be seen, the sequences passed the tests so the source of entropy is good enough for being used as a seed generator for nonces. No bias was found, which means that despite the cells don’t change its value every time they are powered-up, the average binary value of the sequences (according to the frequency test) tends to be 0.5, i.e., it cannot be predicted if the start-up value of a particular cell in the set of cells will be 0 or 1. This unpredictablity is actually an enormous advantage when compared to pseudorandom number generators. VII. CONCLUSIONS The use of PUFs inside the BLE hardware of IoT devices improves the security of firmware updates because the devices can be uniquely identified at low cost. In particular, using the entropy generated by their SRAM, the devices can store all the secret keys obfuscated instead of in clear, and they can derive new fresh keys from the previous ones. Experimental results with BLE chips of IoT devices confirm that the obfuscated data do not reveal sensitive information and that the keys needed by the proposed protocol are successfully reconstructed by only the original device. In addition, the nonces generated by the SRAM device are adequate to be used in Key Derivation Functions according to NIST. ACKNOWLEDGMENT This work was supported in part by RTC-2014-2932-8 and TEC2014-57971-R projects from Ministerio de Economía y Competitividad of the Spanish Government (with support from the PO FEDER-FSE). The work of Miguel A. Prada-Delgado was supported by V Plan Propio de Investigación through the University of Seville, Seville, Spain. REFERENCES [1] Z. Yang, Q. Zhou, L. Lei, K. Zheng, and W. Xiang, “An IoT- cloud Based Wearable ECG Monitoring System for Smart Healthcare,” J. Med. Syst., vol. 40, no. 12, p. 286, Dec. 2016. [2] M. A. Prada-Delgado, A. Vazquez-Reyes, and I. Baturone, “Physical unclonable keys for smart lock systems using Bluetooth Low Energy,” in IECON 2016 - 42nd Annual Conference of the IEEE Industrial Electronics Society, 2016, pp. 4808–4813. [3] E. Ronen, C. Oflynn, A. Shamir, and A.-O. Weingarten, “IoT Goes Nuclear: Creating a ZigBee Chain Reaction,” Cryptol. ePrint Arch., no. 1047. [4] D. Sanlyde, S. Skorobogatov, R. Anderson, and J.-J. Quisquater, “On a new way to read data from memory,” in First International IEEE Security in Storage Workshop, 2002. Proceedings., pp. 65–69. [5] B. Gassend, D. Clarke, M. van Dijk, and S. Devadas, “Silicon physical random functions,” in Proceedings of the 9th ACM conference on Computer and communications security - CCS ’02, 2002, p. 148. [6] J. Delvaux, R. Peeters, D. Gu, and I. Verbauwhede, “A Survey on Lightweight Entity Authentication with Strong PUFs,” ACM Comput. Surv., vol. 48, no. 2, pp. 1–42, Oct. 2015. [7] I. Baturone, M. A. Prada-Delgado, and S. Eiroa, “Improved Generation of Identifiers, Secret Keys, and Random Numbers From SRAMs,” IEEE Trans. Inf. Forensics Secur., vol. 10, no. 12, pp. 2653–2668, Dec. 2015. [8] L. E. Bassham III et al., “SP 800-22 Rev. 1a. A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications.” National Institute of Standards & Technology, 2010. [9] E. Barker and A. Roginsky, “Recommendation for Cryptographic Key Generation,” NIST Spec. Publ., pp. 800– 133. [10] J. Decuir, “Introducing Bluetooth Smart: Part II: Applications and updates,” IEEE Consum. Electron. Mag., vol. 3, no. 2, pp. 25–29, Apr. 2014. [11] M. Ryan, “Bluetooth: with low energy comes low security,” Proceedings of the 7th USENIX conference on Offensive Technologies. USENIX Association, pp. 4–4, 2013. [12] Texas Instruments, “BLE Developer’s Guide for Over-the-Air Download for CC254x.” version 1.2, http://processors.wiki.ti .com/images/8/82/OAD_for_CC254x.pdf, 2013. [13] Silicon Labs, “Over-the-Air Device Firmware Update for EFR32xG1 and BGM11x Series Products.”, Rev. 0.2, https:// www.silabs.com/documents/login/application-notes/an1045-bt- ota-dfu.pdf, 2017.