1 Introduction

There has been a significant surge in the quantity of Internet-of-Thing (IoT) devices in recent years. They are used in home automation [28], energy management [22], health monitoring [25], industrial control systems [30], agriculture [11], transportation [26], and many other sectors. IoT devices have access to many sensitive and important data. Therefore, security is of utmost concern in these devices. However, IoT devices are vulnerable to attacks since they do not have sufficient hardware resources to implement complex security measures [12]. Therefore, many IoT devices use weak authentication and attestation mechanisms such as default passwords or no passwords at all. Additionally, they lack advanced encryption mechanisms since they have limited resources. Not receiving regular firmware updates makes them open to attacks as well. Because of all these weaknesses, many of these devices become targets of attackers. Attackers have created various malware to take control IoT devices. The malware can be used for DDoS (Distributed Denial of Service) attacks, spamming, cryptocurrency mining, and other malicious activities.

There are several reported widely known instances of cyber-attacks on IoT devices. Among these instances, a notable one is the Mirai Botnet emerged in 2016 [19]. This botnet used weak passwords and security vulnerabilities to take over devices and launch DDoS attacks, which resulted in the crashing of various websites and severely impacted internet traffic. Additionally, the BrickerBot malware [32] serves as another example of malicious attacks on IoT devices. By gaining control of devices, the malware caused them to become permanently inoperable, causing significant financial losses for their owners. Furthermore, the Persirai malware [36] targeted IP cameras, enabling the creation of a malicious botnet that could take control of the devices and record video content.

IoT devices range from simple sensors to complex industrial devices with unique microcontrollers for each device. Since each device has unique security challenges, it is not easy to come up with general IoT security standards. Nonetheless, there have been efforts to develop standards for IoT security such as the guidelines published by the International Electrotechnical Commission (IEC) [20] and the National Institute of Standards and Technology (NIST) [10]. However, these standards are not yet universally adopted. Another important attempt for an IoT security standard is an architecture called Device Identifier Composition Engine (DICE), which was developed by Microsoft and proposed as a standard to the Trusted Computing Group (TCG) to provide a hardware-rooted security foundation for IoT devices [5, 6]. DICE adds an extra security layer to IoT devices at a low cost and with minimal silicon requirements. This specification is based on a combination of hardware and software security mechanisms that ensure the confidentiality, integrity, and authenticity of device identifiers.

DICE provides several benefits for IoT device manufacturers and users. First, it provides each IoT device with a unique and immutable identifier, making it resistant to spoofing and tampering. This ensures that only authorized devices can communicate with the network, protecting the network from unauthorized access and attacks. With DICE, even if the attacker clones the device, the clone will not have the same DICE identifier as the original device, making it easily detectable. Second, DICE utilizes cryptographic techniques to ensure the security of device identification and authentication. This ensures that the device identifier is securely stored and cannot be tampered with, providing a solid defense against attacks. DICE incorporates hardware-based root-of-trust, such as a Trusted Platform Module (TPM) to provide a secure environment for cryptographic operations.

However, a previous study demonstrated that DICE has also security vulnerabilities [14]. The authors of this study showed that there is a possibility of planting malware in the flash memory of a restricted microcontroller, which can escape detection via DICE-based attestation. Attestation is a security primitive used by the remote backend to verify through the firmware of the IoT device if it is integrated into the system. The malware then retrieves the valid attestation key and saves it on the device’s flash memory. After a reboot, the malware utilizes the saved key for all future attestations to the backend. This way, until the vulnerability in the firmware is detected, the attacker can authenticate to the server and decrypt encrypted assets. Essentially, the attack revolves around the concept of injecting malware into the top firmware layer during the run-time of application logic. The authors employed Return-Oriented Programming (ROP) to execute the malware installation and key copying. The type of attack is called a remote Time-Of-Check Time-Of-Use (TOCTOU) attack on DICE-based attestation.

In this article, we present an enhanced DICE model called DICEguard that can address the vulnerabilities of DICE related to firmware security flaws. We utilize the periodic memory forensics (PMF) technique to detect attacks resulting from security vulnerabilities in firmware. We add a hardware-based hash engine to perform the PMF operation. This hash engine cannot be stopped until the next reset when operated in memory forensics mode and periodically calculates the digest of the firmware. If the digest differs from the original value, the system triggers a reset. Thus, if an attacker exploits the system, it can be detected by the memory forensics peripheral (MFP). We also add a one-time programmable memory to the system to prevent the original digest from being modified by attackers. The producer should write the public part of the key pair generated during production to this memory and store the digest in memory along with its signature by the producer. Therefore, any changes made by attackers can be easily detected. Additionally, we design the MFP in such a way that it can be used in general-purpose operations as well. We implement the hash operations required by DICE in hardware rather than in firmware to make it more secure from attacks on the firmware. We present a proof-of-concept design of DICEguard implemented on the open-source RISC-V platform Ibex platform. We use the MbedTLS library for the implementations of cryptographic operations.

The additions and enhancements to the original DICE architecture implemented on Ibex platform are:

  • A new DICE controller peripheral for controlling DICE core.

  • A memory-mapped register to store the Compound Device Identifier (CDI).

  • A memory-mapped MFP that we designed.

  • A one-time programmable (OTP) memory to store the public key used for signature verification.

  • A reset mechanism to the pipeline to enable the MFP to reset the CPU when it detects a security breach.

  • A 3-port RAM instead of 2-port RAM to the Ibex to allow access by the MFP.

We can summarize the contribution of this work as follows:

  1. 1.

    We present an improved DICE design that can detect remote attacks on microcontroller-based IoT devices.

  2. 2.

    We give the FPGA implementation of our design that uses RISC-V processor.

  3. 3.

    We compare our design with the base DICE model. Although our design adds extra area overhead, it is comparably small when considering the overall microcontroller system.

We organized the remaining paper as follows: In the next section, we review the related work. In Sect. 3, we give the background information about DICE and PMF. We present the design of our enhanced DICE architecture in Sect. 4. We explain the implementation details in Sect. 5. We give the evaluation results of our implementation in Sect. 6. Finally, we conclude this paper in Sect. 7 with future directions.

2 Related work

IoT security has been a growing concern in recent years, and several solutions have been proposed to address the vulnerabilities of IoT devices. One approach is to use secure boot mechanisms to ensure that only trusted firmware is loaded onto the device [23, 31]. This approach can prevent unauthorized firmware modifications and protect the device against malicious attacks. However, secure boot mechanisms can be bypassed through hardware or software vulnerabilities, which makes them vulnerable to attacks [15, 17].

Another approach is to use hardware-based root-of-trust mechanisms, such as Trusted Platform Modules (TPMs), to ensure the security of IoT devices [8, 37]. TPMs provide a secure environment for cryptographic operations and can be used to store device identifiers and keys securely. However, TPMs can be expensive and unsuitable for all IoT devices. In recent years, a new approach called Device Identifier Composition Engine (DICE) has been proposed to address the security vulnerabilities of IoT devices. DICE provides a low-cost solution for adding a security layer to IoT devices and ensures device identifiers’ confidentiality, integrity, and authenticity. However, DICE is susceptible to vulnerabilities in Updatable Device Firmware, allowing attackers to take control of devices and access users’ sensitive data.

Eldefrawy et al. [8] introduced a new primitive called SMART, a hardware–software co-design approach for establishing a dynamic root of trust in remote embedded devices, specifically targeting low-end microcontroller units (MCUs) that lack specialized memory management or protection features. SMART requires minimal changes to existing MCUs while providing concrete security guarantees and only assumes a few restrictions on adversarial capabilities. The authors demonstrate the practicality and feasibility of SMART by implementing it through hardware modifications on two common MCU platforms, AVR and MSP430. Their results show that SMART implementations only require a few changes to memory bus access logic and the synthesis of both implementations to a 180nm ASIC process confirms its small impact on MCU size and overall cost. This approach offers a simple, efficient, and secure solution for establishing a dynamic root of trust in remote embedded devices, addressing the limitations of current attestation methods.

Jäger et al. [16] implemented DICE by modifying VexRiscV, a RISC-V Platform. However, since only DICE is implemented in this study, precautions are taken against security vulnerabilities in the user application layer.

Hristozov et al. [13] presented a practical runtime attestation technique for small IoT devices. The authors focus on the generation of attestation evidence during runtime, specifically on a DICE-based hardware/software method that requires only standard on-chip hardware. The proposed method does not require external components, trusted execution environments, or non-standard hardware features. Instead, it utilizes a small, privileged, write-protected software layer that manages access to secrets at runtime using the memory protection unit (MPU) and generates attestation evidence upon request from a verifier. The method targets inexpensive off-the-shelf microcontrollers with limited resources. The authors demonstrate the feasibility and practicality of their approach through the implementation of the STM32L476, an ARM Cortex-M4 microcontroller. However, this study cannot provide a countermeasure against attacks such as TOCTOU.

Xu et al. [35] have introduced a system called CIDER, featuring a component known as AWDT. This primitive, akin to our MFP, serves the critical function of detecting firmware exploits and triggering a system reset to initiate recovery. However, unlike a traditional watchdog timer, AWDT relies on a periodically generated, cryptographically protected message for its operation. In this system, firmware requests a nonce from AWDT, which is then signed with the Alias Key generated by DICE and transmitted to a remote server. Upon approval of the signature by the remote server, an authenticated acknowledgment message is sent back, allowing the firmware to relay it to AWDT and defer the system reset. Failure to receive such confirmation leads to a system reset. While offering functionality akin to our MFP, CIDER presents several drawbacks. Notably, it requires a constant connection to a remote server for AWDT functionality. Without this connection, AWDT cannot be activated, resulting in unwarranted system resets. Moreover, unlike our MFP, CIDER lacks protection against sophisticated attacks like TOCTOU, where an attacker could exploit vulnerabilities to manipulate the system. Another limitation of AWDT is its periodic interruption of firmware operation. To execute the kick operation, the firmware must briefly pause its execution to fulfill necessary tasks. In contrast, MFP operates seamlessly in parallel with the CPU, ensuring minimal disruption to firmware execution.

Suzaki et al.[34] propose a solution based on PMF as in this work. The article presents a system called RO-IoT that addresses security and life cycle management in IoT devices by extending existing system-reset architectures. RO-IoT involves network boot, live memory forensics, and life cycle management, all protected by the Trusted Execution Environment (TEE). This setup allows for recovery from compromised systems through autonomous rebooting and ensures safe device termination after support expiration. The main contributions and challenges of RO-IoT include managing IoT security and life cycle, secure network bootloader protection by TEE, TEE-protected live memory forensics, IoT life cycle management protected by TEE and PKI-based certificates, and the implementation of RO-IoT using a small Linux image as the bootloader in collaboration with OP-TEE, a trusted OS for ARM TrustZone. Unlike DICEguard, the processor has expensive hardware.

In this article, unlike previous studies, we propose a new method to address the vulnerability of DICE related to firmware security flaws. We utilize the PMF technique to detect attacks resulting from security vulnerabilities in firmware and add a hardware-based hash engine to the system to perform the PMF operation. Our approach provides an additional layer of security to DICE and ensures the integrity of device firmware.

3 Background

3.1 DICE

The Device Identifier Composition Engine (DICE) specification is published by the Trusted Computing Group (TCG) in 2016 to establish a Root of Trust in devices with minimal hardware overhead [5]. Initially, it was a part of Microsoft’s RIoT concept [9], which divides the software running on a device into multiple layers. We give DICE architecture in Fig. 1. Each layer in this architecture is assigned a unique key when it runs. The key for the next layer is then derived by applying a one-way function to the measurement of that layer and its key. This feature allows the layers to form a chain of trust, with the key for the next layer as evidence for the integrity of all firmware layers below it.

Fig. 1
figure 1

DICE Architecture

Full size image

However, the initial layer of software is not measured by any entity, making it challenging to detect manipulation or unspecified behavior. Therefore, the specification of this initial layer with all necessary security measures is called the DICE Core. DICE Core’s first requirement is to make the memory containing it read-only to prevent manipulations. Its second requirement is to have a non-volatile read-only memory with a Unique Device Secret (UDS), which is unique and random for each device it is assigned to. This UDS is used to compute the key for the subsequent levels and must be kept secret to prevent impersonation or forged attestations. Its third requirement is that the UDS must only be readable for code within the DICE Core memory to ensure its secrecy. In DICE terminology, the key for Layer 0 generated by DICE Core is called the Compound Device Identifier (CDI). The key derivation process can be stacked infinitely, although a typical application might use three levels: DICE Core, a bootloader, and the application code itself.

DICE follows a layered approach to secure the boot process of a device and establish a chain of trust from the hardware root of trust to the application code. The key that is assigned to each layer is used as proof of the identity of the software layer. The computation is usually done using a hash function. The key of the next layer is derived by applying a one-way function to the measurement and the current layer’s key. If all the keys are derived in this way, then the key of the highest layer provides evidence of the integrity of all firmware layers below it. This forms a chain of trust that can be used to detect if any of the layers have been compromised. This ensures that cryptographic keys cannot be derived correctly for the compromised layer, preventing unauthorized access or data manipulation.

DICE Core generates the CDI by using the hash of Layer 0 and the UDS, and then, it transfers control to Layer 0. Layer 0 uses the CDI received from DICE to derive the Device Identity key pair called DeviceID, which forms the device identity and is based on the assumption that Layer 0 will not be modified. If Layer 0 is modified for any reason, the device is considered different. Layer 0 then uses the digest of the application running in Layer 1 along with the CDI to create another public–private key pair called Alias Key. In addition, Layer 0 uses the private part of DeviceID to create an X.509 certificate [27] for Alias Key. It sends this certificate and Alias Key to Layer 1 for authentication and encryption.

3.2 Periodic memory forensics

Memory forensics is a technique that can be used to detect attacks on IoT devices in real-time [21]. Memory forensics involves capturing and analyzing memory contents for signs of malicious activities. Memory forensics can provide valuable insights into the activities of an attacker. In the DICE architecture, there is no mechanism to check the integrity of the firmware running in Layer 1 at runtime. To address this, we utilized the memory forensics technique for integrity verification. Our designed memory forensics peripheral uses a cryptographic hash function for integrity checking. By periodically calculating the digest of Layer 1, malware detection can be performed at runtime.

3.3 TOCTOU attack

Time-Of-Check Time-Of-Use (TOCTOU) attacks represent a class of security vulnerabilities prevalent in systems where the state of a resource is checked at one point in time (Time-Of-Check) and then used at a later point in time (Time-Of-Use). These attacks typically involve an attacker manipulating the resource state between the check and the use, leading to unexpected behavior or exploitation of the system.

In the context of IoT devices, TOCTOU attacks pose significant threats, especially when dealing with sensitive data or critical operations. For instance, an attacker could exploit a TOCTOU vulnerability in a device’s authentication mechanism, allowing unauthorized access to the device or its resources.

3.4 Return-oriented programming

Return-oriented programming (ROP) is a sophisticated exploitation technique commonly employed in security attacks, particularly against systems with non-executable stacks or other memory protection mechanisms. ROP attacks involve manipulating the program’s control flow by redirecting the execution to existing code sequences called "gadgets," typically ending with a return instruction.

In the context of IoT security, ROP attacks can be devastating, especially when targeting firmware or system-level components. By chaining together sequences of gadgets, an attacker can execute arbitrary code or commands, bypassing security mechanisms and gaining unauthorized access to the device or its data.

3.5 Threat model

In our threat model, we consider an attacker targeting IoT devices that employ DICE-based attestation for firmware integrity verification. The attacker’s goal is to compromise the device’s firmware by installing malware without being detected during the attestation process. We assume the following in our model:

  1. 1.

    Attacker’s Capabilities:

    • The attacker has remote access to the targeted IoT device through a network connection (e.g., Wi-Fi, Bluetooth, or cellular).

    • The attacker possesses knowledge of the device’s binary firmware image. This can be obtained by physically acquiring a device from the same fleet, which typically runs identical software, and analyzing its firmware offline.

    • The attacker can exploit a memory corruption vulnerability (e.g., buffer overflow) present in the device’s firmware. This vulnerability allows the attacker to execute arbitrary code and perform a return-oriented programming (ROP) attack.

  2. 2.

    Victim Device:

    • The victim is an IoT device running firmware that includes the DICE-based attestation mechanism.

    • The device has limited computational resources and memory, typical of deeply embedded systems.

    • The device’s firmware contains a memory corruption vulnerability that can be exploited remotely.

  3. 3.

    Attack Scope:

    • The attacker aims to bypass the DICE-based attestation and install malware on the victim device.

    • The malware can be used for various malicious purposes, such as manipulating the device’s functionality, exfiltrating sensitive data, or using the device as part of a botnet for Distributed Denial of Service (DDoS) attacks.

    • The attacker may attempt to evade detection by triggering a device reset immediately after installing the malware, hoping to remove any traces of the compromise.

  4. 4.

    Assumptions:

    • The attacker does not have physical access to the victim device, relying solely on remote exploitation.

    • The attacker cannot directly tamper with the hardware components of the device, such as the DICE-based secure key storage or the hash engine.

    • The initial firmware flashed onto the device is trusted and free from malware.

  5. 5.

    Security Objectives:

    • Maintain the integrity of the device’s firmware and prevent unauthorized modifications.

    • Detect and mitigate attempts to install malware on the device, even in the presence of memory corruption vulnerabilities.

    • Provide a secure attestation mechanism that can reliably verify the firmware’s integrity and report any compromises to a remote verifier.

Our proposed DICEguard solution is designed to address the threats outlined in this model. By introducing periodic memory forensics using a hardware-based hash engine and secure key storage, DICEguard aims to detect and prevent firmware compromise attempts, including the TOCTOU attack described in [13]. The periodic checks and secure key storage ensure that any unauthorized modifications to the firmware are promptly detected, triggering a reset to restore the device to a trusted state.

4 Design

In this section, we describe our design’s software and hardware blocks. We utilize the DICE architecture for cryptographic attestation and device identity in this design. However, the DICE architecture does not provide a solution for runtime malware detection. An attacker can inject malware into the firmware by exploiting any security vulnerabilities in the user firmware and obtaining the Alias Key. In this case, the attacker can authenticate with the IoT server and obtain encrypted assets. DICE suggests a firmware update as a solution to this issue. However, detecting this vulnerability in the firmware can take a long time. During this period, the attacker can manipulate the IoT network. To prevent this situation, we propose memory forensics. We incorporate an MFP to the original DICE architecture as shown in Fig. 2. This figure shows our additions to the original DICE given in Fig. 1. MFP is a hash engine that periodically calculates the digest of the user firmware. It uses the sha256 algorithm [18] to calculate the digest periodically and compares it with the original value. If the computed digest differs, it resets the system like a watchdog timer. After the reset, the system can be forced to update the firmware using the firmware update software stored in the read-only memory, or this situation can be reported to the IoT server.

Fig. 2
figure 2

DICEguard Architecture (the enhanced DICE)

Full size image

4.1 Enhanced DICE architecture design

The DICE architecture is divided into two parts, hardware and software. We use a memory-mapped ROM for the DICE core to function in the hardware part. We also add a Unique Device Secret (UDS) register and a hardware-based register to transfer CDI to Layer 0. Layer 0 reads the CDI through this register.

The developed firmware combines the UDS with Layer 0 and calculates digest to generate the CDI. We use MFP in the general-purpose mode for hash operation. By performing the hash operation in hardware, we can avoid the need for an enormous DICE ROM size. Otherwise, if we perform the hash operation as software-based, the ROM size increases significantly, and CDI generation takes longer computation times. We use the elliptic curve (EC) algorithm in Layer 0 since it requires less processing power than RSA for key generation [24]. Layer 0 first generates a deterministic 256-bit ECDSA (Elliptic Curve Digital Signature Algorithm ) key pair for the DeviceID using the CDI received from the DICE core. The reason to use the ECDSA algorithm is that it can only be used for certificate production. Then, Layer 0 generates a deterministic EC P-256 key pair for the Alias Key, which is later used for authentication. After generating the key pairs, we use the private part of the DeviceID to produce an X.509 certificate for the Alias Key. Once generating the certificate, we clear the DeviceID and CDI from memory as a security measure. Configuring and running the MFP is also one of the tasks of Layer 0. After completing this process, it sends the addresses of the X.509 certificate and Alias Key to Layer 1 and initiates Layer 1.

4.2 Memory forensics peripheral design

The MFP is a hardware-based memory-mapped hash engine that uses the cryptographic hash function sha256. It accesses the memory directly so that memory forensics can be done without interrupting the CPU. It is designed in such a way that it can also be used in general-purpose hash calculations. Once started, the peripheral scans the memory at the specified interval and calculates the digest. The scan period of the MFP is programmable; thus, it allows the designer to adjust the scan intervals to reduce the power consumption of the task. MFP resets the system if the computed digest differs from the one written to the configuration registers. Once the peripheral enters the memory forensics mode, it cannot be stopped until the next reset, which prevents its operation from being blocked by attackers. Before running the MFP, the First Stage Boot Loader (FSBL) itself performs a hash check. If the hash is consistent, it runs the MFP and loads the user application. If the hash is inconsistent, it initiates the firmware update process. Thus, even if the malware is implanted between two PMF checks and immediately triggers a reset, DICEguard will still be able to detect the presence of the malware in the subsequent boot.

We utilize digital signatures to prevent tampering with the digest that the peripheral will compare. To enable this process, we add a one-time programmable (OTP) memory to store the public part of an ECDSA key pair. This feature ensures that attackers cannot manipulate the public key. The digest value that the MFP compares is stored along with a signature created using the private key corresponding to this public key. Before running the MFP, Layer 0 verifies this signature. If the signature is invalid, Layer 0 reports this to the server and does not run Layer 1. We give the overall flow chart of the system in Fig. 3.

Fig. 3
figure 3

Overview of DICEguard

Full size image

Our enhanced DICE architecture with MFP support prevents TOCTOU attacks by detecting and responding to changes in the memory state through hash computation. Let \(S_{init}\), \(S_t\), and \(S_{ref}\) represent the initial state of the memory, the state of the memory at time t, and the reference memory state, respectively. We assume that the memory state initially matches the reference memory state. That is when the system is initialized, \(S_{init} = S_{ref}\). At each periodic scan, MFP calculates the current state of the memory using a hash function. If \(S_t \ne S_{ref}\), MFP detects a security breach and initiates a system reset. If \(S_t \ne S_{ref}\), MFP triggers a reset operation. By doing so, it eliminates the TOCTOU attacks to further affect the system. To provide a formal proof of how the reset operator enforces a transition between state regions, we direct the reader to [7].

5 Implementation

An important step of IoT system design is selecting a suitable processor. In our study, we use RISC-V as our processor. RISC-V is becoming increasingly popular for IoT applications due to its open-source nature, low power consumption, and flexibility. It is a modular architecture that allows designers to customize the instruction set for their specific needs. This makes it ideal for IoT devices that have specific power, performance, and memory requirements. RISC-V also has a small footprint and low power consumption, which is important for devices that need to operate on limited battery power. Additionally, RISC-V is an open-source architecture, which means that it can be freely used and modified by anyone. This makes it easier for device manufacturers to develop customized solutions for their specific IoT applications, without the licensing fees associated with proprietary architectures.

There are several open-source implementations of RISC-V. In this study, we use the Ibex platform, which is an open-source RISC-V processor core developed by lowRISC and written in SystemVerilog [2]. To validate our design, we created a simulator using Verilator [33]. This allows us to test our system in a simulation environment and ensure it functions as intended. Once satisfied with the simulation results, we synthesize our system on FPGAs. The Ibex project includes an instance called Artya7, developed explicitly for Xilinx’s Artix-7 platform [29]. For comparison purposes, we used Artix-7 as our target FPGA. Overall, the Ibex platform provided a reliable and efficient solution for our proof of concept design. Its open-source nature and high configurability feature allow us to tailor our system to meet the specific requirements of an IoT device.

5.1 Implementation of DICE

The original Ibex processor uses a single RAM for both data and instructions. We add a ROM to the system to operate the DICE Core firmware. We also add some logic to direct specific signals from the pipeline to RAM or the DICE-ROM, allowing the CPU to execute from ROM after reset. We connect the selection input of this mux to a signal called ‘DICEEn,’ which determines whether the pipeline signals are directed to DICE-ROM or RAM, as shown in Fig. 4. When ‘DICEEn’ is high, the CPU executes the instructions in DICE-ROM; otherwise, it executes the instructions in RAM. To prevent attackers from accessing UDS, we disable access to the DICE-ROM while ‘DICEEn’ is low. This means that once the DICE Core completes its operation, it cannot be read.

Fig. 4
figure 4

Ibex (RISC-V) core and its modified memory structure

Full size image

We add some extra functionalities to the firmware to ensure that the CPU executes the code from the DICE-ROM after the reset. While we place the DICE-ROM at the memory address 0x1000000, we set the Ibex’s boot address to 0x100000 since there is no way to change the boot address at runtime. As the selected ROM size in our design is less than 1 megabyte, we mask the instruction and data addresses generated by the ‘ibex_top’ core with the address 0xFFFFF. This allows us to avoid issues with the DICE-ROM’s address being 0x1000000. However, to prevent malfunctioning the program counter-relative instructions, we modify the reset vector so that the instruction pointer continues from the base address of the DICE Core, which is 0x1000000.

We add a memory-mapped CDI register of 32 bytes in length to the system to store the CDI. After calculating the CDI, the DICE Core writes it to this register. Additionally, we also add a memory-mapped DICE Controller peripheral to the system to terminate the DICE Core. When the finish command is given to this peripheral, it sets the DICEEn signal to low. In the startup file, we make the necessary changes to direct the instruction pointer to the start of Layer 0 and to give the finish command to the DICE Controller once the main function is completed. The memory footprint of the DICE Core is shown in Table 1. Since the hash operation is performed through our designed hash engine in hardware rather than in software, as can be seen from this table, the code size is significantly smaller.

Table 1 Memory Footprint of DICE Core
Full size table

In our implementation, we name Layer 0 as the First Stage Boot Loader (FSBL) and Layer 1 as the user application. We place the FSBL at address 0x100000 and the user application at address 0x160000. We use the mbedTLS library [3] for cryptographic functions used in the FSBL. To keep the attack surface small, we minimize the code size of the FSBL. Firstly, FSBL reads the status register of the MFP to determine if there is a security breach in the previous operation. If there is a security breach, it reports it to the server and does not run the user application. Otherwise, FSBL first reads the CDI from the CDI Register and then generates the DeviceID using the ECDSA algorithm and the Alias Key using the EC P-256 algorithm. The Alias Key and DeviceID must be generated deterministically in the DICE architecture. To achieve this, we add an entropy source that outputs the digest of the CDI. As a result, the random number generators used in the ECDSA and EC-P key generation functions produce the same result every time. This makes the generated keys deterministic. After the key generation process, an X.509 certificate signed with the private part of the DeviceID is generated for the Alias Key. Then, the MFP starts to execute. For this operation, the signature of the digest, start address, and end address belonging to the user application are verified with the public key stored in the Public Key ROM that we added to the system. If the verification is successful, the memory forensic peripheral is activated. We developed a Python script to automatically generate these MFP parameters. This script, after the user app is compiled, parses the elf file, calculates the relevant information of the text segment (start address, end address, digest, etc.), creates a structure, and signs it. It then appends this frame to the beginning of the binary file of the user app. Finally, the CDI and DeviceID are erased from memory as a security measure. The Alias Key and X.509 certificate are passed as parameters to the main function of the user application and executed. Additionally, the vector table must be offset to enable interrupts to function correctly in the user application. We set the ‘mtvec’ register of Ibex to make the vector table the starting address of the user application, which is 0x160000.

The MFP periodically scans and compares the memory with the entered digest. If the comparison process yields an incorrect output, it resets the system. Once the MFP is initiated, the attacker cannot stop it until the reset.

5.2 Implementation of memory forensics peripheral

The memory-mapped MFP detects exploits resulting from security vulnerabilities in user applications. This peripheral scans the designated memory region at specified intervals, calculates its digest using the sha256 algorithm, and resets the system if the result differs from the input digest. The bit in the MFP’s CTRL register that enables memory forensics is the sticky bit. Once memory forensics is enabled, it cannot be disabled until the next reset. We use secworks sha256 IP core [4] for the sha256 algorithm and change the two-port Ram used in Ibex to a three-port Ram, which we connect to the peripheral to allow direct access to RAM. This change enables the MFP to calculate digests while the CPU continues to operate. The peripheral has two modes: memory forensics and general purpose. In the general-purpose mode, it is used for hash operations by DICE Core and FSBL. To perform MFP-based hash calculation using mbedTLS functions, we use the sha256_alt.c source file and compile mbedTLS with this source file. Thus, mbedTLS can use MFP for hashing operations.

We add a 32-byte Initial Value register to the peripheral. This feature allows the DICE Core to write UDS to this register and to calculate the digest combined with FSBL. We also incorporate the status register of this peripheral not to be reset after a soft reset. This way, the FSBL can read this register and determine whether there was a security breach in the previous run. All registers of this peripheral and its memory addresses are listed in Table 2.

Table 2 Registers and their memory addresses of MFP
Full size table

Since the digest value, the start address, and the end address of the application provided to the peripheral can be altered by an attacker, we store these three values in memory along with an ECDSA signature. Since the public key, which will be used to verify this signature, can also be changed by the attacker, it must be stored in read-only memory. Therefore, we add one-time programmable (OTP) memory to the system to store the public key. Once programmed during production, this RAM cannot be modified. This feature ensures that an attacker cannot manipulate the public key to verify the signature. In our proof of concept design, we use ROM instead of OTP memory, which is programmed during synthesis and cannot be modified after that. The memory map of the completed design is given in Table 3.

Table 3 Memory map of the design components
Full size table

6 Experimental results

We evaluated our design in terms of hardware overhead, power consumption, and latency and compared it with the base DICE architecture. The RISC-V Ibex architecture we used in our implementation includes an instance called Artya7, developed explicitly for Xilinx’s Artix-7 platform. For comparison purposes, we chose Artix-7 as our target FPGA. We modified the RAM in the design to be 3-ported so that the MFP could directly access it. However, block RAMs in Xilinx FPGAs can have a maximum of two ports. One solution can be using register-based RAM; however, this consumes too many resources on the FPGA. Therefore, we used two 2-ported block RAMs to mimic the 3-ported RAM, as shown in Fig. 5. In this design, we connect the data signals from the ’ibex_top’ core to both A ports of the two block RAMs. We connect the instruction signals from the ’ibex_top’ core to the B port of the first block RAM and the MFP to the B port of the second block RAM. Additionally, we program both block RAMs with the same firmware during synthesis. Therefore, if an attacker wants to modify an instruction, this change can be reflected in both block RAMs and can be detected by the MFP.

Fig. 5
figure 5

Using two 2-port RAMs to construct of 3-port block RAM

Full size image

In the first set of experiments, we compared the execution times of using the hash engine, our design choice, and mbedTLS, a commonly used open-source cryptography library. Note that our design is hardware-based, while the alternative one is software-based running on the Ibex core. We give the execution times of both designs in terms of the clock cycle in Table 4. We evaluated both designs on the system running at 100 MHz. As can be seen from the execution times of both designs, DICEguard can improve the execution time 67 times for DICE against a software-based base DICE design.

Table 4 Execution times of DICEguard (hardware) and the base design that uses mbedTLS (software)
Full size table

As expected, the performance improvement comes with an extra hardware cost. In order to determine our area overhead, we implemented the original Ibex with no DICE support, Ibex with DICE, and DICEguard. We give the FPGA utilization report for different parts of each design in Table 5. In this table, the first column shows the type of site for different components. While columns two, four, and six show the utilization amount, the other columns show the percentage utilized (Util% in the table) in our selected FPGA. When we look at the slice LUTS, which consumes the highest area in the design, the original DICE increases the Ibex only 1.18 times. However, our design almost doubles it. A fair comparison can be between the original DICE and DICEguard. The area of DICEguard is 1.77 times higher than the original DICE implementation. The main reason for this area increase comes from the two 2-ported memory shown in Fig. 5. Although this area increase seems very high, it can be tolerable in commercial microcontrollers considering the improvement in performance and security. In order to see the area occupied by DICEguard in a microcontroller system, we compared it with BlackParrot platform, which is an ARM-based implementation on FPGAs [1]. While DICEguard uses 2686 LUTs, the implementation of the BlackParrot platform on the ArtyA7 FPGA utilizes 30264 LUTs. If we integrate DICEguard into this system, it can occupy only 7.5% of the total chip area. According to Yosys, an open-source ASIC synthesis tool, synthesis results, the original Ibex occupies 26.60 kGE (Gate Equivalence). Based on the synthesis results on the FPGA, we estimate that the inclusion of DICEguard in Ibex would increase the total consumed area to approximately 50 kGE.

Table 5 FPGA area utilization for three designs
Full size table

In the next set of experiments, we compare three designs in terms of power consumption on our FPGA platform. We give the power consumption and temperature values of each design in Table 6. DICEguard increases the on-chip power 5%, which is an acceptable increase for this component. Considering the overall microcontroller system, this overhead is negligible. The temperature values coming from the FPGA report are the same for the two DICE implementations.

Table 6 Power consumption report for three designs
Full size table

Finally, to verify DICEguard in terms of its success in detecting TOCTOU and similar attacks, we developed a user application that can run in the simulator we designed using Verilator. In the simulations, we modify instructions in the firmware after a certain period. We run the FSBL and this application onto the RAM in our design. After a certain period from the start of the application, we observe that the instruction is modified, and the MFP detects it and resets the system.

7 Conclusion

The rapid growth of IoT devices has brought new challenges to device security. Attackers are creating various malware to take control of these devices, causing significant financial losses and impacting internet traffic. To address these issues, TCG has introduced a new specification called DICE, which provides a solution for adding a security layer to IoT devices at a low cost and with minimal silicon requirements. However, vulnerabilities in Updatable Device Firmware can still allow attackers to take control of devices and access users’ sensitive data. To address this vulnerability, we have presented a new method utilizing PMF to detect attacks resulting from firmware security flaws. Our system adds a hardware-based hash engine to perform PMF, making it difficult for attackers to modify the device’s firmware undetected. The system we designed and implemented on the IBEX platform includes a DICE Controller peripheral, memory-mapped registers, a hash engine for memory forensics, and OTP memory to store the public key used for signature verification. Overall, our system provides a secure and cost-effective solution for enhancing the security of IoT devices. However, as new threats and vulnerabilities emerge, it is crucial to continue improving and innovating security measures to ensure the safety of IoT devices and their users’ privacy.