Hardware-Enabled Secure Firmware Updates in Embedded Systems

. Firmware updates on embedded systems are essential for patching vulnerabilities and improving the functionality of devices. Despite the importance of ﬁrmware updates, manufacturers and ﬁrmware developers often consider ﬁrmware security as a secondary task. As a result, ﬁrmware often turns into an alluring target for adversaries to inject malicious code into embedded devices. In this work, we present a framework that supports secure and fast ﬁrmware update delivery with minimal downtime on embedded devices. The proposed framework makes use of cryptographic primitives implemented on hardware in addition to the device’s intrinsic physical characteristics acting as digital authentication ﬁngerprints. Our implementation ensures ﬁrmware authenticity, conﬁ-dentiality, and integrity. A proof-of-concept design is emulated on FPGA demonstrating high performance, strong security guarantees, and minimal hardware overhead.


Introduction
Embedded devices are increasingly integrated into several Cyber-Physical System (CPS) domains such as Industrial Control Systems (ICS), home and automation networks, wireless sensing services, automobiles, etc.The deployment of these devices in mission-critical environments, however, introduces security challenges that require a different approach compared to general-purpose computing systems security [30].Embedded systems are highly constrained in terms of performance and resources, therefore it is typically not realistic to employ similar security methods as those in general-purpose systems.Embedded device manufacturers and CPS integrators have to incorporate specialized security measures to protect these devices, and thus the CPS application they support.Studies, however, have shown that these security strategies are not a priority for enterprises [22].This is evident by the growing number of attack incidents related to microprocessor-based embedded devices [38].
A prominent example of attacks against embedded systems is the 2010 Stuxnet incident.This computer worm targeted Programmable Logic Controllers (PLCs) modifying their firmware code to perform malicious actions while also hiding its presence.Stuxnet leveraged zero-day 1 exploits in the PLCs firmware to take control over critical machinery in a nuclear power plant facility, leading to catastrophic failure [20].Another example is the 2015 attack on Ukraine's power grid [50].This Advanced Persistent Threat's (APT) objective was to launch a Denial-of-Service (DoS) attack on the power distribution entity's call center, disabling the Uninterruptible Power Supplies (UPS) for the control centers, and corrupting the firmware of Human-Machine Interfaces (HMI) found in Remote Terminal Units (RTU) and serial-to-Ethernet port servers.Due to the firmware corruption, circuit breakers were disabled and a power outage occurred that the customers could not report since the call centers were overloaded.A more recent large-scale attack, the Mirai botnet, was able to turn networked devices into controlled bots [23].Mirai identified devices connected to the internet and tried to log into them using a table of more than 60 common factory default usernames and passwords.It then proceeded to infect them with the Mirai malware.The devices continued to function correctly except for some occasional sluggishness and increased bandwidth usage.These zombie devices were then directed to certain web-services to overwhelm anti-DoS software and make the service inaccessible.The fact that hundreds of thousands of networked embedded devices still use default credentials is very concerning; the effectiveness of these attacks indicates that embedded system security can no longer be an afterthought.
Firmware in embedded systems is the dedicated software that acts as an abstraction layer between bare metal hardware and software.Firmware is often residing in read-only memory, playing the role of the "operating system" in an embedded device [4,28,35], providing low-level control of the device.Due to this ability, firmware is considered a critical component of a device that has to be routinely updated and maintained in order to fix bugs, address performancerelated issues, and even enhance or change the device's intended functionality.However, embedded device owners are often reluctant to update their devices' firmware due to the chance of rendering their devices inoperable in case of an error and because of the extensive downtime that they may experience [17,24].On the other hand, manufacturers often do not provide firmware updates or support once their devices are released to the market.Even if they do, their updates typically do not conform to security principles including encryption and authentication.A recent survey proves that there have not been significant security gains in the firmware domain for the last 15 years [45].The firmware security of embedded systems is not addressed to the same level as that of general-purpose computers or BIOS security [36].
1 "Day Zero" or "Zero-day" is the day which a vulnerability of a system is made known to its vendor or to those who should be interested in mitigating the vulnerability.Hackers discovering these vulnerabilities can exploit them well before they are mitigated.Such exploits are known as "zero-day exploits".

Firmware Image
Digital Signature

Insecure Channel
Fig. 1.An overview of the proposed approach.A firmware package is formed by combining necessary metadata, the encrypted firmware image, and the manufacturer's digital signature.The firmware package is transmitted to the embedded system through an insecure channel.The device unpacks it and verifies its source and contents utilizing hardware-implemented cryptographic primitives.
Existing industry efforts aim to secure firmware and other sensitive information stored at the device hardware in the form of secure storage and trusted execution environments.However, these methods have been proven to leak data to malicious attackers using a variety of attacks that take advantage of bugs and exploits in operating systems [39], user applications [33], and even proprietary code that aims at securing cryptographic keys and encrypted data [37].To tackle these challenges, our work proposes the utilization of hardware-based cryptographic primitives to avoid storing secrets in non-volatile memory and alleviate reliance on software routines.Our proposed framework ensures firmware data integrity and confidentiality in a time-efficient manner by using hardwareimplemented cryptographic modules while hardware-intrinsic characteristics are used as "digital fingerprints" to perform authentication procedures.
The overview of our framework is shown in Fig. 1.Firmware updates are transmitted from the manufacturer to the embedded device through an insecure channel.The proposed approach relies on hardware as a root-of-trust to attain high security levels and is motivated towards low-end embedded devices [19].The framework is designed in a way that user intervention and device downtime are minimized.Hence, there is no need for intermediate authenticators to perform key exchange and management.The embedded device can be deployed without requiring any secure key-enrollment phase.Specifically, we employ hardwareimplemented encryption and cryptographic hash functions to provide firmware confidentiality and data integrity, respectively.The means of digital fingerprinting are demonstrated via Physical Unclonable Functions (PUFs) [52].The unclonable nature of PUFs bounds the firmware packages created by the manufacturer to a single device.If a device gets compromised, same model devices retain security.The PUF used in our proof-of-concept design is a Public PUF (PPUF), meaning that it does not rely on the secrecy of the Integrated Circuit's (IC) physical parameters since the model describing the PPUF is public.
Our framework is implemented and evaluated in an experimental setup using both software and hardware.A general-purpose computer is in charge of the firmware packaging procedure, acting as the device manufacturer.The embedded device to be updated is emulated on FPGA as a proof-of-concept hardware design.The unpacking process, involving the authentication and decryption, is carried out on the embedded device.Our security analysis of the proposed approach shows strong security guarantees while our experimental measurements demonstrate the feasibility of the approach and applicability for constrained embedded devices.
The rest of the chapter is organized as follows.Related work on firmware update security mechanisms and PUF-based authentication protocols are discussed in Section 2. The underlying security primitives considered in our proofof-concept design are discussed in Section 3. The proposed methodology for secure firmware updates is presented in Section 4 alongside with the security analysis of the approach.The experimental setup and implementation details are presented in Section 5. Section 6 concludes the chapter.

Related work
Firmware images and updates are typically provided online via vendors or manufacturers' websites.It has been shown that web crawlers can be used to gather images of critical equipment by traversing websites that host firmware [13].These files can be accessed, downloaded, and modified due to the lack of access control measures and encryption.Firmware can also be acquired through physical access to the device [25].By having access to the firmware image, a malicious adversary can retrieve the inner workings of a device and expose its functionality.
The information acquired from reverse engineering the firmware can lead to revealing zero-day exploits or other known vulnerabilities, that may provide an adversary an "attack path" to the system utilizing the aforementioned device.For example, access to the firmware image binary may allow adversaries to launch firmware modification attacks able to cause severe implications to a system's functionality.Recent works have demonstrated the severity of such attacks in the ICS domain when targeting devices such as PLCs and protection relays [4,26,54].These types of attacks have also been shown to be effective against a large variety of other embedded devices such as printers, cameras, and network switches [13,14].
Efforts to secure the firmware update mechanisms on embedded devices led to secure storage and trusted execution environments, such as i-NVMM [12] and ARM TrustZone [41].However, the design of such systems is an attractive target for both invasive and non-invasive attacks [8,27,29].For instance, since the JTAG protocol is not designed with security in mind, the JTAG test port can provide access to secure memories allowing embedded devices to be reconfigured.Also, it has been demonstrated that attackers are able to exploit implementation-based weaknesses to leak sensitive information through covert channels [40].
To overcome these shortcomings, we propose avoiding reliance on software and pre-stored data in non-volatile memories by moving towards a hardware root-of-trust.Research works towards this end, suggest using the hardware's intrinsic properties to design and support security mechanisms.Such solutions include PUFs that leverage manufacturing variability to produce secret keys for authentication and encryption purposes.Different types of PUFs are used to produce unique identifiers that can be used in security schemes for authentication and secure code updates.Silicon-based PUFs (ring-oscillator, SRAM, arbiter, etc.) utilize manufacturing variability as an entropy source to create chip-specific identifiers.Examples of non-silicon designs include optical PUFs that exploit the random scattering of light to act as physical one-way functions.These kinds of solutions are successful in several domains such as intellectual property protection and Internet-of-Things (IoT) [9,32].
Several approaches incorporating PUFs have been proposed to address the problem of storing sensitive information in non-volatile memories.Rostami et al. propose a PUF-based authentication and key exchange protocol based on substring matching [47].The scheme utilizes PUFs for secure communications while alleviating the need for error correction against PUF's inherent noise.In [2], an end-to-end privacy-preserving authentication protocol is described, suitable for resource-constrained devices.The protocol attempts to perform mutual authentication procedures between enrolled embedded devices and a server utilizing reverse fuzzy-extraction mechanisms for key recreation on each side.In the context of IoT, a PUF-based communication protocol is presented in [10].Before any secure communication is initiated between two devices, each PUF-enabled party has to share its Challenge-Response Pairs (CRPs) with an intermediate server.This server coordinates the communication between the two devices by issuing a public and a private key for each party.Feng et al. demonstrate a code update protocol utilizing PUFs [21].The protocol starts with a temporary session in a secure environment between a server and the embedded device to share symmetric keys.The enrolled device is then employed and can securely communicate and update its code using its PUF for authentication.Che et al.
show how within-die path delay variations can be utilized to enable a mutual PUF-based authentication protocol [11].
Most of the proposed solutions incorporate either strong or weak PUFs2 which are highly susceptible to a variety of attacks.For example, weak PUFs have to remain entirely secret and an attacker with physical access could easily extract the required CRPs and break the authentication protocol in place [46].Strong PUFs are more difficult to reverse engineer or extract information from, but they are highly susceptible to modeling and machine learning attacks.Such attacks involve producing a relatively low number of CRPs from the PUF and then create a machine learning model that will be trained using the gathered CRPs.The model then can quickly derive the remaining CRPs and create a dictionary that will contain an excessive amount of known pairs [48,49,55].The aforementioned proposed protocols also require a secure setup phase; an essential key exchange procedure that must happen in a secure environment.A number of the proposed approaches also require intermediate servers to coordinate key distribution or enable communication between embedded devices.In comparison with the existing works on hardware-based secure communication protocols, our proposed framework neither requires a secure setup phase nor intermediate authenticator servers.The public-key infrastructure of our firmware update scheme alleviates the need for the aforementioned measures due to the public-key components including PPUFs, public-key cryptography, and digital signatures.

Underlying Security Primitives
The proposed framework employs cryptographic primitives in hardware in order to implement securely the firmware image exchange protocol.The approach requires both a private and a public key encryption/decryption core, a cryptographic hash function, and a PPUF in order to provide confidentiality, authenticity, and integrity guarantees.
PPUFs are a category of PUFs whose IC characteristics can be made public since they do not rely on their secrecy, unlike traditional PUFs.A PPUF is designed to be fast-to-execute and slow-to-simulate [42].In the context of this work, a differential PPUF (dPPUF) is utilized due to its characteristics of not requiring ultra-accurate timing mechanisms.For instance, traditional XORbased PPUFs, as the one shown in Fig. 2, require a very high clock resolution to accurately "catch" the racing signals at the end of the PPUF circuit.A 256-bit dPPUF is adopted from [43], presented in Fig. 3 the PUF's inherent noise, in this work, and without loss of generality, we consider a Bose-Chaudhuri-Hocquenghem (BCH)-based code-offset fuzzy extractor as an effective PUF error correction mechanism [15].In order to create a PPUF model, as required in our framework, the manufacturer has to perform gate-level characterization 3 .The measured IC characteristics form a software model that can be stored in a public repository.The software model is the "public part" of the PPUF since it does not provide any advantage to any adversary.This is because of the Execution-Simulation Gap (ESG).ESG is the time advantage the PPUF hardware owner has over a simulating attacker when calculating a CRP.A CRP is formed by the input to the PPUF's model, i.e., the challenge, and its corresponding output, i.e., the response.The procedure to produce a CRP is very fast when executed on hardware but significantly slower when done via simulation.In order to take advantage of this disparity we use the challenge as an encryption key while responding to the decrypting party.The inverse operation, i.e., deriving which challenge created the provided response, can only be completed on the actual PPUF hardware since simulating all the possible challenges to find a matching response is infeasible in simulation.Therefore, this ESG can be used as a root-of-trust and the model can be stored publicly without any security implications.ESG can also be manipulated to give as much advantage to the PPUF owner over the simulating adversary as needed.Increasing either the key width or number of challenges that need to be calculated increases the simulation effort for any attacker trying to derive the challenge of a particular response.
In order to provide confidentiality guarantees, we encrypt the firmware image.Encryption is the process of encoding plaintext data making it unintelligible and scrambled in a way that no unauthorized party can understand them.To decrypt the data, a cryptographic key is required.The key acts as a guide, helping the authorized party rearrange and reassemble the encrypted data correctly, so that access to the plaintext is possible.To address confidentiality, we employ the symmetric-key encryption algorithm Advanced Encryption Standard in Galois/Counter Mode (AES-GCM).AES-GCM is an authenticated encryption algorithm providing both data integrity and confidentiality [16].Its hardware implementation provides a high encryption/decryption data rate while being adequately efficient in the use of hardware resources.AES-GCM is operating with 128-bit blocks and has four inputs: a 128-bit secret key, a 96-bit initialization vector, a plaintext, and optional additional authenticated data.AES-GCM generates two outputs: a message authentication code and a ciphertext.The message authentication code acts as a checksum value that enables integrity checks.
Towards ensuring that the firmware package contains undeniable truth that it originated from the manufacturer (non-repudiation) and thus protecting the device from impersonation attacks, the proposed approach utilizes digital signatures.The concept of digital signatures is depicted in Fig. 4.They are data that accompany the firmware image and provide evidence of their origin.To effectively use digital signatures, a cryptographic hash function is required along with the utilization of a public-key cryptosystem.Essentially, the sender has to hash the data payload, e.g., the firmware image, and encrypt it with a private key.In our setup, the procedure to create the manufacturer's digital signature is the following: (1) the manufacturer has to select a secret private key and (2) a public key.
(3) A hash digest of the firmware image is created and encrypted by a public-key cryptosystem using the manufacturer's private key.The public-key cryptosystem utilized in our setup is RSA, also known as Rivest-Shamir-Adleman, while the cryptographic hash function employed is SHA-256, both NIST-approved cryptographic implementations [3,44].The verifier, in this case the device, is able to receive the data alongside the digital signature and recreate the digest on Fig. 4. Digital signature creation involves the usage of a cryptographic hash function and a public-key cryptosystem.A hash of the payload data is encrypted using the signer's private key.The verifier decrypts the digital signature using the signer's public key and hashes the payload data.The signature is considered valid if the resulting hashes match.its side.Then the signature is decrypted using the manufacturer's public key and compared to that digest.If the hashes match, then the manufacturer is authenticated.
While the aforementioned cryptographic primitives are well established and widely used mechanisms in the area of cryptography and security, alternatives with similar characteristics can still be utilized in our proposed framework.Our approach is designed with modularity and flexibility in mind.Alternative cryptographic hash functions and encryption algorithms can be considered as long as they adhere to the needs of the secure firmware update protocol.For example, alternative encryption algorithms of symmetrical type can be chosen instead of AES-GCM.Examples include Simon [5], a lightweight block cipher released by the National Security Agency (NSA) and optimized for performance in hardware implementations, and Twofish [51], a symmetric key block cipher alternative to AES.The cryptographic hash function and public-key cryptosystem can also be interchanged with similar mechanisms.For instance, lighter alternatives can be used to adjust the design for even more constrained devices, such as a lightweight implementation of Keccak using only 200 permutations [7].This flexibility gives the ability to the manufacturer to adjust their devices to certain security level constraints and available computational resources depending on each domain and application scenario.

Methodology
In this section, we provide the details of the proposed framework under the consideration of a malicious individual trying to manipulate the firmware updating procedure.The main objective is to encrypt a firmware image and deliver it to the embedded device through an insecure channel.An attacker observing the insecure channel should be unable to extract information from the firmware image.Only the intended device can decrypt the firmware image and verify its authenticity.

Threat Model and Countermeasures
We consider that the firmware packaging procedure from the manufacturer is an error-free process taking place in a secure facility, i.e., the firmware package is prepared correctly.The dPPUF model, however, is publicly available since accessing it does not give the attacker any advantage.The firmware package is transferred to the device over an insecure channel.The attacker can intercept packages on that channel.The attacker's goal is to uncover the firmware image binary and reverse-engineer it to place backdoors and uncover proprietary device operations.Using a malicious firmware binary the attacker tries to impersonate the device manufacturer to transfer a modified firmware package to the embedded system as the legitimate one.
In order to prevent this malicious activity, we employ several cryptographic techniques utilizing their hardware-implemented counterparts.To encrypt the firmware image and protect its binary form from unauthorized access, we use a symmetric cipher, specifically the AES-GCM.The keys required for this encryption procedure will be provided by the dPPUF and its model, making the firmware package chip-specific.In addition, the device receiving the firmware update must also have proof of the firmware package's origins in order to be secure against impersonation attacks.In order to alleviate this issue, we employ asymmetric cryptography as well in the form of digital signatures.A digital signature accompanying a payload gives proof of firmware origins while also being a checksum for integrity checks.The digital signatures in our setup utilize SHA-256 for cryptographic hashing and RSA for asymmetric cryptography.

Firmware Update Procedure
The firmware update procedure consists of two main parts, each undertaken -in sequence -by the device manufacturer and the device user.The manufacturer constructs a firmware package that contains the encrypted firmware image as well as metadata.Metadata allows the embedded device to authenticate and decrypt the firmware image without revealing useful information to any malicious entity observing the insecure channel used for data transfer.For this methodology to be successful, a combination of security primitives is utilized such as a cryptographic hash function (SHA-256), a symmetric (AES-GCM) and an asymmetric (RSA) encryption/decryption module, and a PPUF (dPPUF).These cryptomodules are implemented on the hardware of the embedded device to avoid reliance on software routines and pre-stored data.The firmware transition, from the manufacturer packaging to the embedded device delivery, is shown in Fig. 5.
Secure Firmware Package Generation by Manufacturer: The upper half of Fig. 5 presents the steps required by the manufacturer to produce a valid and secure firmware package.The manufacturer uses a challenge to create a response from the dPPUF model, encrypts the firmware image using that challenge, and creates a digital signature.Then, these 3 output products are bundled together in a firmware package to be sent to the embedded device.In particular, the overall process involves the following: 1.The manufacturer generates a random challenge I 1 .This is a 256-bit long binary that is going to be used as input to the dPPUF model.This challenge creates the 256-bit response O 1 .This CRP's challenge I 1 is used to encrypt the firmware image such that only the intended device is able to decrypt it.The length of the CRP strings can be increased, if necessary, to further reduce the risk of brute force attacks.
2. The firmware image F I is concatenated with firmware metadata F V and then encrypted with AES-GCM using I 1 as the encryption key.The F I is the firmware binary and F V contains identifiers that will help the device further evaluate the firmware, namely firmware version and revision number.This information can help the device avoid rollback attacks as discussed in Section 4.3.3. A hash of F I||F V is calculated to create a digital signature.The resulting 256-bit digest of SHA-256 H(F I||F V ) is then encrypted using the manufacturer's private key K pr to create (H(F I||F V )) Kpr .The public key encryption scheme used is RSA.The digital signature allows the device to authenticate the manufacturer since it is the only one capable of decrypting the firmware image and create a hash for comparison.4. The three output products from the manufacturer are packaged and forwarded to the embedded device in this form: Firmware Unpacking Process by the Embedded Device: The generated firmware package is delivered to the dPPUF-enabled embedded system through an insecure network.The device utilizes the response O 1 to decrypt (F I||F V ) I1 and authenticate the package's origins using the digital signature (H(F I||F V )) Kpr .The unpacking process steps include the following: 1.The embedded device makes use of the response O 1 to recreate challenge I 1 .
In order to achieve it, the device iterates throughout all possible input combinations to the dPPUF until it finds a response that matches O 1 .This CRP iteration is only feasible using dedicated hardware and it is computationally prohibitive to carry out this operation through simulation [6].Therefore, only the correct recipient device is able to perform this operation efficiently.2. Once I 1 is derived, the embedded device uses I 1 as the key, for the hardwareimplemented AES-GCM module, to decrypt (F I||F V ) I1 and get F I||F V .
Once the F V is obtained, the device is able to check the firmware version of the update and compared it to the firmware currently installed at the device.
If the firmware image F I indicates an older version of the device's existing firmware, the update operation is aborted.3.In parallel to the previous step, the digital signature (H(F I||F V )) Kpr is decrypted with RSA using the manufacturer's public key.This operation results in H(F I||F V ). 4. If the firmware image indicates a firmware update, a cryptographic hash digest of F I||F V is generated using SHA-256.The hash digest is compared to the result of the RSA decryption.If the hashes match, then the embedded device authenticates the origin of the firmware from the legitimate manufacturer.5.If all the required authentication and decryption procedures are completed, the device can proceed with updating its firmware code.
As explained in Section 3, the dPPUF is a series of cascading gates which, when a challenge is introduced, a response is created.The manufacturer has access to a software model describing the dPPUF present in the device which is going to be updated.Using a software model to simulate CRPs is significantly slower than performing the same operation directly on hardware.By using the challenge as an encryption key while providing the response in plaintext, we ensure that only the intended device is be able to decrypt the firmware image in a feasible time frame.This is based on the fact that in order to find a challenge for a corresponding response requires iterating through all possible challenges until a matching response is found.Therefore, we leverage the ESG characteristic of PPUFs to keep malicious attackers from getting a plaintext version of the firmware binary.The time advantage of the dPPUF hardware during CRP iteration over an attacker, simulating the same procedure, can vary depending on the dPPUF implementation.For example, a 1024-bit implementation of the dPPUF makes breaking the protocol extremely prohibitive, according to the analysis in [6].Our implementation focuses on constrained devices, thus the structure is based on a 256-bit design.The firmware package is also chip-specific since every device will have a different PPUF and consequently different CRPs.The manufacturer also appends a digital signature to the encrypted firmware so that the embedded device can authenticate it.
Overall, our proposed framework has the following features: (1) it does not require a secure setup phase for key exchange between the firmware sender and receiver because the decryption key is dynamically generated by the hardware, (2) a malicious attacker observing the insecure channel cannot uncover the firmware image and cannot impersonate the manufacturer, (3) the firmware can only be decrypted by the intended device, and (4) the methodology can be easily adapted to incorporate different cryptographic primitives.Encryption/decryption modules and cryptographic hash functions can be substituted with other equivalent crypto-cores without altering the overall functionality of the design.

Security Analysis
The framework is designed to adhere to certain security requirements.First, we need to ensure that adversaries eavesdropping in the communication channel and able to intercept the firmware package, cannot reveal the binary of the firmware, and thus identify code subroutines that expose the embedded device's functionality.We also need to ensure that if the firmware package is corrupted or tampered during transmission, the device would be able to detect it.The device must also have the ability to authenticate the package's origins in order to be protected against impersonation and man-in-the-middle attacks.Installing earlier versions of firmware may re-introduce bugs and thus firmware rollback should be avoided.
To fulfill the above requirements we employ hardware-implemented versions of the AES-GCM algorithm, SHA-256 cryptographic hash functions, and RSA public-key cryptosystem.Since the firmware image, alongside the necessary metadata, is encrypted using AES-GCM, an attacker cannot extract the firmware binary from the transmitted package in plaintext form without having access to the key.The key, however, is only known by the manufacturer and only the intended device can recreate it.RSA and SHA-256 are used to form the manufacturer's digital signature.The role of the digital signature is not only to act as a checksum value that allows the device to check the firmware's data integrity but also as undeniable evidence that the sender is indeed the manufacturer.Digital signatures require a hash digest which acts as a checksum value.The digest is encrypted by the manufacturer's private key.Therefore, it can only be decrypted using the manufacturer's public key, authenticating the package's origins.After completing the decryption and authentication procedures, the embedded device checks F V to determine the firmware version of the update.If it is not an update to the existing firmware, the device halts the updating operation to avoid rollback attacks.
The aforementioned security primitives are utilized as hardware-based cryptographic modules implemented on the embedded device.These primitives alleviate the need for secure storage of secret information such as credentials and encryption keys directly on the device's non-volatile memory.Keys and other secret information are dynamically recreated on the device upon demand.The firmware update operation is also non-dependent on software-based routines, and thus less susceptible to software-based attacks [53].
The utilized dPPUF circuit inherits by design certain security guarantees.The effort to simulate dPPUF using its public model scales exponentially with the dPPUF's depth and width.A small increase in depth or width may prove prohibitive in terms of time, for pre-computing all sets of CRPs.Even with enough computing capabilities for generating CRP lookup tables, the storage requirement would be impractically high.Also, the public model of dPPUF ensures that profile characterization (e.g., power profile) of the circuit would not reveal any side-channel information.

Experimental Setup and Results
We implement a proof-of-concept experimental setup in order to validate and evaluate our approach.As shown in Fig. 5, both the firmware packing and unpacking phases have been implemented.The procedures performed by the manufacturer are implemented in software using a 64-bit computer with 3.2GHz Intel Core i5-4460 quad-core processor and 8GB RAM.The unpacking process, on the embedded device's end, is emulated utilizing a Xilinx Kintex7 FPGA with a system clock frequency of 100M Hz.
Our PPUF implementation is using multiple layers of boosters (2-input XOR gate) followed by repressers (small NAND-based circuit [43]), i.e., b = 1 and r = 1 with the height and width of the dPPUF being h = 10 and w = 256, respectively.It is implemented on hardware, using the aforementioned FPGA, using artificial transmission and switching delays at each gate, shown in Fig. 3, to emulate manufacturing variations.The delay values are generated by a pseudo-random number generator software to avoid any kind of bias.The model of the dPPUF is constructed in C++ as a graph, where its nodes represent the dPPUF gates and their respective delays.The effectiveness of a dPPUF design is determined by the entropy that it exhibits.We ensure that the responses cannot be correlated to their corresponding challenges and its CRPs are adequately random by conducting extensive tests.Specifically, we validate the dPPUF's software model with 10k input vectors and compare them with the resulting outputs.Then, we utilize the Strict Avalanche Criterion (SAC) to quantify the entropy.SAC is measured by calculating the correlation probability of the corresponding outputs of two input vectors that have a hamming distance equal to 1. Fig. 7 presents the SAC demonstrated by our dPPUF design with an average probability of each output switching equal to 0.3425, similar to the results in the related literature [43].
Every procedure needed for completing the firmware packaging process is done in software.Firstly, the dPPUF model is utilized to create a CRP that will be used for encrypting the firmware package in a chip-specific way.The resulting response O 1 is going to be used as an unencrypted header for the firmware pack- age while its corresponding challenge I 1 is also used as a secret key to encrypt the concatenation of the firmware image and the firmware version data (F I||F V ) to create (F I||F V ) I1 .The manufacturer also needs to prepare a digital signature to prove the firmware's origins to the device.The procedure for creating a digital signature involves hashing the concatenation (F I||F V ) to create H(F I||F V ) and then encrypting it using the manufacturer's private key.The resulting digital signature (H(F I||F V )) Kpr is appended to O 1 and (F I||F V ) to create the firmware package.The required cryptographic algorithms, such as encryption/decryption and hashing, are implemented in Python using the pycryptodome library [18].
For our experiments, we choose three commercial firmware files acquired from the vendors' websites to be tested.The firmware images are those of embedded systems designed for ICS environments.The devices are a Sercos III field bus interface module, a Zelio Logic SRA2/SR3 smart relay, and a Modicon M258 logic controller.
We use an FPGA to emulate the embedded device supporting the described hardware-implemented cryptographic primitives.The unpacking process is carried out using Hardware Description Language (HDL) to demonstrate the effectiveness of the approach when running directly on hardware.We make use of Xilinx Vivado Design Suite 2018.3.The hardware resources required for these primitives are presented in Table 1.The hardware overhead for each security primitive is shown as the hardware usage of the overall design.Synthesis and implementation algorithms provided by the the HDL development tools help with optimizing the overall design in terms of area.Also, routing and placement algorithms can remove a lot of redundant hardware between these modules.
The firmware package produced by the manufacturer (e.g., the computer in our setup) is transferred at the receiving party which loads it into the memory and initiates the unpacking process.In our implementation, we first pre-load the firmware image in block RAM and then proceed with decryption and authen- tication procedures.During the unpacking process of the firmware, the dPPUF input challenge, O 1 , from the firmware package header is used to recreate the key of AES-GCM, I 1 .Then, the dPPUF iterates through all the possible challenges of a given set (10 6 possible inputs in our setup), until it finds a response matching O 1 .This is the CRP iteration explained in Section 3, utilizing the ESG to have an advantage over the attacker.Once I 1 is derived, the AES-GCM decryption core is ready to decrypt (F I||F V ) I1 and get the plaintext F I||F V .In parallel, the RSA core decrypts (H(F I||F V )) Kpr using the manufacturer's public key K pub to uncover H(F I||F V ).This hash derived from the digital signature is going to be compared to the output of the SHA-256 core when the input is the plaintext F I||F V .If the resulting hash matches the hash uncovered from the digital signature, then the manufacturer is authenticated and the embedded device is assured of the firmware image's origin and integrity.Finally, the F V is examined to determine the firmware image's version and revision number.If it is determined to be an actual update, then the firmware update procedure can be initiated.If the version or revision number indicate a downgrade, the firmware image is rejected to avoid rollback attacks.The whole experiment is run for each one of the industrial-grade firmware images.The time to finish the decryption and authentication is measured, starting from the package's arrival to the device.The three firmware images are presented in Table 2 along with their respective total unpacking time.
Table 3 provides a comparison with relevant state-of-the-art methods in terms of area and performance overhead.The time measured by [2] and [11] is the time that the device needs to establish a secure connection with the server and authenticate it.On the other hand, we measure our performance as the time a device takes to unpack a firmware package and perform all the necessary authentication and decryption procedures.Therefore, our measurements include time-consuming decryption procedures that put us at a disadvantage when compared to the time measurements reported by [2] and [11].The performance for the proposed methodology, reported in Table 3, is the time needed to completely unpack the Modicon firmware image and authenticate the manufacturer.In [2] and [11], PUF-based privacy-preserving authentication protocols are being considered.When we only compare area overhead, [2] is lighter; however, it exhibits several drawbacks.As discussed in Section 2, the proposed approach by Aysu et al. requires initial setup and an enrollment phase (on top of PUF hardware characterization), steps which our approach does not require.It also necessitates having a trusted third-party server to complete the authentication handshake.Also, the protocol does not take into account data integrity issues neither implements any countermeasures.In addition, the work utilizes an SRAM-based PUF which is known to be vulnerable to a variety of attacks [1,46].An authentication protocol that provides both confidentiality and mutual authentication is presented in [11].This protocol is utilizing a new type of PUF, the hardwareembedded path delay (HELP) PUF.This kind of PUF derives randomness from path delay variance within a hardware implementation of AES.The work shows comparable resource usage.Nevertheless, the protocol does not address data integrity.Also, our implementation performs significantly better in terms of execution time than the mechanism proposed by [11], while also requiring a lot fewer hardware resources.

Conclusions
In this work, we develop a flexible firmware update framework for securely updating embedded systems.The framework makes use of the unique physical characteristics of each embedded system's IC to bind firmware packages to a specific device.By utilizing hardware-implemented cryptographic primitives, we can guarantee the confidentiality and integrity of the firmware image while being transmitted through an insecure channel.Our framework's security analysis demonstrates the validity of the security measures while showing the device's protection mechanisms against impersonation and other types of attacks.A proof-of-concept implementation with a commercial-off-the-shelf firmware of an industrial embedded system verifies the practicality of the approach in resource constraint devices.The performance results show that the proposed framework not only provides security but also fast firmware updates.

Fig. 2 .
Fig. 2.An example of a small differential Public Physical Unclonable Function (dP-PUF).Left (1-4) and right (5-8) circuits are the same in functionality.The challenge (abcd) is presented at both sides at the same time.However, the output of gates 3-4 and 7-8 stabilizes at different times due to manufacturing variability.The fastest propagating signals determine the corresponding response that forms the CRP.

Fig. 5 .
Fig. 5.The firmware package generation flow: the firmware vendor encrypts the composed image utilizing a public PUF model.The firmware unpacking process at the device level: the firmware package is decrypted, verified, and uploaded to the embedded device by utilizing public PUF's (dPPUF) intrinsic manufacturing variability.

1 )
Creates a CRP using the C++ dPPUF model 2) Encrypts firmware and creates digital signature using Python script 3) Append into a firmware package Embedded Device (FPGA) 1) Unpacks the firmware package 2) Recreates decryption key using the dPPUF hardware 3) Decrypts firmware and constructs required hashes 4) Authenticates manufacturer using digital signature

Fig. 6 .
Fig.6.Experimental and evaluation setup.The hardware-implemented security primitives are developed on a FPGA in order to emulate a dPPUF-enabled device.The firmware packaging procedure are carried out on a computer which is connected to the FPGA through a serial cable.
. PUFs are inherently noisy and therefore require error correction mechanisms to stabilize them.To alleviate for CLK r b h Fig. 3.The differential Public Physical Unclonable Function (dPPUF) architecture consists of consecutive layers of boosters and repressers.The two sides are identical in structure but different in inherent delays (inertial, propagation, switching, etc.).A layer of arbiters is placed at the end to capture the fastest propagating signals and according to the result, create the appropriate response bit string.

Table 1 .
FPGA resource utilization for the firmware unpacking process.

Table 3 .
Comparison with previous work.