The security of Industrial Internet of Things (IIoT) systems is a challenge that needs to be addressed immediately, as the increasing use of new communication paradigms and the abundant use of sensors opens up new opportunities to compromise these types of systems. In this sense, technologies such as Trusted Execution Environments (TEEs) and Hardware Security Modules (HSMs) become crucial for adding new layers of security to IIoT systems, especially to edge nodes that incorporate sensors and perform continuous measurements.
Traditionally, IoT device architectures that incorporate hardware security attach an HSM to the main board that is used to perform the necessary cryptographic operations: encryption of communications, data signing, public--private key generation, etc. In this type of architecture, the microcontroller is in charge of scheduling the necessary cryptographic tasks, delegating them to the HSM and receiving the response from it. On the other hand, the communication is normally carried out through standardised buses such as Inter-Integrated Circuit (I2C) and Serial Peripheral Interface (SPI). In the event that it is necessary to sign the data received by a sensor to ensure their integrity, the microcontroller will receive them from the sensor and then delegate the signing operation to the HSM. This approach, which can be seen in Figure 2, shows a serious drawback: when the data arrive to the microcontroller, an attacker can modify the data without being detected. In the case where the modification is made after the data are signed, this manipulation can be detected at the verification process and the data will be discarded.
Figure 2. Design proposed.
In this sense, the secure sensor proposed in this article establishes that the data are sent directly to the HSM and, there, the HSM is in charge of sending it to the microcontroller once it is signed. In this way, if any change is made, it is automatically detected in the verification process, since the data have been previously signed within the secure environment that an HSM offers. Both an HSM and a TEE can play this secure environment role within this proposal.
The design of a hardware-secure IoT node following this concept relies on a careful choice of the platform on which it will be developed. One of the most straightforward choices would be to choose an ARM platform with OS support in order to be able to successfully and easily install a TEE such as the ones discussed above (ARM TrustZone or Intel SGX). However, these types of platforms have some disadvantages that can become a problem in an IoT environment. These disadvantages are related to consumption, since the platforms that support OS, such as Raspberry Pi, usually have a high consumption of energy, and this is a serious drawback when applied to a real environment.
Another requirement to take into account in the design is the ability to modularise the software running on the platform since, on one side, we have to consider the TEE, and on the other side, the rest of the platform firmware. Being able to create isolated execution environments becomes crucial for providing security in this type of architecture where there are two execution environments: a secure processing environment (SPE), represented by the TEE, and a non-secure processing environment (NSPE), where the rest of the application is executed.
This requirement translates into the use of a platform with more than one core. In this way, a core would be in charge of running the SPE and communicating with the NSPE that is running in the other core.
The platform chosen for this proposal was the PSoC64, which contains two cores: one core is an ARM Cortex-M4 and the other one is an ARM Cortex-M0+. In the Cortex-M4 core, the main application of the device is executed. This has the firmware necessary to carry out the communication with the outside world through a communications protocol that will vary depending on the application (BLE, Wi-Fi, Ethernet, etc.), as well as the libraries and kernel of the embedded OS. The ARM Cortex-M0+ is in charge of running the TEE, which is the TF-M, and incorporates support for the ARM-M microcontrollers family. The communication between the two cores is via an inter-process communication bus. The TF-M isolates the different execution environments (NSPE and SPE) through APIs that are called through the processes that form the system. In addition, the TF-M offers different services such as cryptography and attestation and allows for the execution of secure processes through secure partitions (this will be explained in detail in the following sections). These secure processes allow for the execution of firmware such as sensor drivers or communication protocols. Figure 3 illustrates this design.
Figure 3. Secure sensor concept.
In this way, the driver of the HSM is implemented within the TEE, improving the reliability of the accesses to the HSM functionality. The functionality of the HSM can only be used from the NSPE (ARM Cortex-M4) through a controlled and predefined API by the TF-M. Additional mechanisms can be integrated in the TEE, such as a sensor driver through a secured I2C peripheral, enabling high-level and high-value functionality, such as an API request to obtain the value of the sensor directly signed by the HSM from the NSPE, greatly limiting the attack vectors and tampering with possibilities of the sensor value from the~NSPE.
In conclusion, this paper proposes a secure sensor design and implementation using different mechanisms for providing a data root of trust. By combining a TEE and an HSM in a dual-core microcontroller with a secure sensor driver implemented in the secure core, the immutability and integrity of data are achieved. The main goal of the proposal is the use of the secure sensor concept, where a secure core is located between the main microcontroller and the sensor. In the secure core, both the HSM and TEE work together, obtaining the advantages of both solutions. HSMs offer hardware and certified protection against physical attacks. However, they do not typically support flexible high-level functionality, such as programmable device drivers or secure peripherals, features provided in this solution by the TEE. Combining an HSM with a flexible TEE, running in the secure processor, a secure environment is created where sensor drivers can be implemented, protecting the communication bus from software attacks as well as providing the ability to sign the data received by the HSM before the data leave the secure core.
The design of this secure sensor fits the role of a Blockchain Oracle, capable of providing reliable data to the ledger thanks to the incorporation of timestamping mechanisms to provide reliability against replay attacks. This fills a gap in the literature regarding Blockchain Oracles, which are rarely addressed.
The feasibility of this approach in a real use case is demonstrated in a wine logistics scenario, in which the secure sensor acts as an Oracle sending temperature and humidity data to the Blockchain. Thanks to these records stored in the Blockchain, customers can obtain accurate information about these products and, through smart contracts, automate business logic and reduce operating costs, delays and the possibility of fraud.
The incorporation of this secure sensor proposal into Blockchain technologies as an Oracle role makes this concept a promising proposition for the future, adding security and integrity to the data required by scenarios as a wine logistic chain. Whether in Blockchain or non-Blockchain networks, the secure sensor solution fills a gap in the security of systems that make intensive use of data from the outside world.