Secure Sensor Prototype in a Blockchain Application: History
View Latest Version
Please note this is an old version of this entry, which may differ significantly from the current revision.
Subjects: Engineering, Industrial
Contributor:
Antonio J. Cabrera-Gutiérrez
,
Encarnación Castillo
,
Antonio Escobar-Molero
,
Juan Cruz-Cozar
,
Diego P. Morales
,
Luis Parrilla

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.

  • Blockchain Oracle
  • hardware security modules
  • Hyperledger Fabric
  • trusted execution enviroment

1. Introduction

In Industrial IoT (IIoT) networks, the extraction of data from the physical to the digital world via sensors is becoming increasingly important [1]. This data collection takes place at nodes distributed within a specific network topology at the edge that are equipped with various sensors that convert physical measurements into digital information. In Industry 4.0, these edge devices are the most important part of the IIoT system because, in addition to extracting data, they can also perform computations at the edge without having to delegate decisions and data flows to a centralised entity [2].
Figure 1 shows the typical IIoT architecture, where different layers have been considered. The edge/perception layer is responsible for collecting data from the outside world through different types of sensors. These sensors are usually attached to an IoT device, which has a communication system to send these data or the necessary information to higher layers of the system. The network layer is responsible for sending these data to the various technologies that process the information. Technologies such as Wi-Fi and Bluetooth Low Energy (BLE) are included in this layer, as well as the hardware devices that perform this task: routers, gateways, etc. The processing layer includes the technologies that allow information to be stored and processed, such as databases, data analysis systems or control software. An even higher layer can be defined in terms of system application, where data and information are delivered to the client in different ways depending on the use case [3].
Electronics 12 02987 g001 550
Figure 1. IIoT architecture.
Nowadays, providing security for IIoT devices and the overall system that they are a part of is critical [4]. At first glance, it might seem that, by providing communications security, the system would be protected, but nothing could be further from the truth. Although one of the main aspects is to protect communications, as these provide the largest attackable area of the system [5], this is not enough. In this type of system, paradigms such as traditional client–server-based protocols and implement access control through a public key infrastructure (PKI) are no longer enough [6].
New Decentralised Ledger Technologies (DLTs) [7]-based paradigms such as Blockchain are becoming a fundamental scheme for ensuring the security of these IIoT systems [8]. Through decentralisation and the underlying cryptography, Blockchain offers secure machine-to-machine communication in which every piece of information or data entered into the network has to be validated by different entities that make up this network [9].

2. Secure Sensor Prototype Using Hardware Security Modules and Trusted Execution Environments in a Blockchain Application

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.

 

This entry is adapted from the peer-reviewed paper 10.3390/electronics12132987

References

  1. Barnaghi, P.; Bauer, M.; Biswas, A.R.; Botterman, M.; Cheng, B.; Cirillo, F.; Dillinger, M.; Graux, H.; Hoseinitabatabaie, S.A.; Kovacs, E.; et al. IoT Analytics: Collect, Process, Analyze, and Present Massive Amounts of Operational Data–Research and Innovation Challenges. In Building the Hyperconnected Society-Internet of Things Research and Innovation Value Chains, Ecosystems and Markets; River Publishers: London, UK, 2022; pp. 221–260.
  2. Naveen, S.; Kounte, M.R. Key Technologies and challenges in IoT Edge Computing. In Proceedings of the 2019 Third International Conference on I-SMAC (IoT in Social, Mobile, Analytics and Cloud) (I-SMAC), Palladam, India, 12–14 December 2019; pp. 61–65.
  3. Hassija, V.; Chamola, V.; Saxena, V.; Jain, D.; Goyal, P.; Sikdar, B. A Survey on IoT Security: Application Areas, Security Threats, and Solution Architectures. IEEE Access 2019, 7, 82721–82743.
  4. Mrabet, H.; Belguith, S.; Alhomoud, A.; Jemai, A. A Survey of IoT Security Based on a Layered Architecture of Sensing and Data Analysis. Sensors 2020, 20, 3625.
  5. Mathur, S.; Arora, A. Internet of things (IoT) and PKI-based security architecture. In Industrial Internet of Things and Cyber-Physical Systems: Transforming the Conventional to Digital; IGI Global: Hershey, PA, USA, 2020; pp. 25–46.
  6. Sabt, M.; Achemlal, M.; Bouabdallah, A.; Trusted Execution Environment: What It is, and What It is Not.. IEEE Trustcom/BigDataSE/ISPA 2015, 3, 57--64, .
  7. Arias, O.; Wurm, J.; Hoang, K.; Jin, Y. Privacy and Security in Internet of Things and Wearable Devices. IEEE Trans. Multi-Scale Comput. Syst. 2015, 1, 99–109.
  8. Kaur, J.; Agrawal, A.; Khan, R.A. Security Issues in Fog Environment: A Systematic Literature Review. Int. J. Wirel. Inf. Netw. 2020, 27, 467–483.
  9. Yoon, M.-K.; Mohan, S.; Choi, J.; Kim, J.-E.; Sha, L. SecureCore: A multicore-based intrusion detection architecture for real-time embedded systems. In Proceedings of the 2013 IEEE 19th Real-Time and Embedded Technology and Applications Symposium (RTAS), Philadelphia, PA, USA, 9–11 April 2013; pp. 21–32.
  10. Rahmatian, M.; Kooti, H.; Harris, I.G.; Bozorgzadeh, E. Hardware-Assisted Detection of Malicious Software in Embedded Systems. IEEE Embed. Syst. Lett. 2012, 4, 94–97.
  11. Mao, S.; Wolf, T. Hardware support for secure processing in embedded systems. In Proceedings of the 44th Annual Design Automation Conference (DAC ’07), San Diego, CA, USA, 4–8 June 2007; Association for Computing Machinery: New York, NY, USA, 2007; pp. 483–488.
  12. Bravos, G.; Cabrera, A.J.; Correa, C.; Danilović, D.; Evangeliou, N.; Ezov, G.; Gajica, Z.; Jakovetić, D.; Kallipolitis, L.; Lukić, M.; et al. Cybersecurity for Industrial Internet of Things: Architecture, Models and Lessons Learned. IEEE Access 2022, 10, 124747–124765.
  13. Cabrera-Gutiérrez, A.J.; Castillo, E.; Escobar-Molero, A.; Álvarez-Bermejo, J.A.; Morales, D.P.; Parrilla, L. Integration of Hardware Security Modules and Permissioned Blockchain in Industrial IoT Networks. IEEE Access 2022, 10, 114331–114345.
  14. Huang, Z.; Wang, Q. A PUF-based unified identity verification framework for secure IoT hardware via device authentication. World Wide Web 2020, 23, 1057–1088.
  15. Matas, K.; La, T.; Grunchevski, N.; Pham, K.; Koch, D. Invited tutorial: FPGA hardware security for datacenters and beyond. In Proceedings of the 2020 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, Seaside, CA, USA, 23–25 February 2020; pp. 11–20.
  16. Hategekimana, F.; Whitaker, T.J.; Pantho, M.J.H.; Bobda, C. IoT Device security through dynamic hardware isolation with cloud-Based update. J. Syst. Archit. 2020, 109, 101827.
  17. Peters, T.; Lal, R.; Varadarajan, S.; Pappachan, P.; Kotz, D. BASTION-SGX: Bluetooth and architectural support for trusted I/O on SGX. In Proceedings of the 7th International Workshop on Hardware and Architectural Support for Security and Privacy, Los Angeles, CA, USA, 2 June 2018; pp. 1–9.
  18. McKeen, F.; Alexandrovich, I.; Anati, I.; Caspi, D.; Johnson, S.; Leslie-Hurd, R.; Rozas, C. Intel® software guard extensions (intel® sgx) support for dynamic memory management inside an enclave. In Proceedings of the Hardware and Architectural Support for Security and Privacy 2016, Seoul, Republic of Korea, 18 June 2016; pp. 1–9.
  19. Zhang, N.; Li, J.; Lou, W.; Hou, Y.T. PrivacyGuard: Enforcing private data usage with blockchain and attested execution. In Data Privacy Management, Cryptocurrencies and Blockchain Technology, Proceedings of the ESORICS 2018 International Workshops, DPM 2018 and CBT 2018, Barcelona, Spain, 6–7 September 2018; Springer International Publishing: Cham, Switzerland, 2018; pp. 345–353.
  20. Cao, C.; Guan, L.; Zhang, N.; Gao, N.; Lin, J.; Luo, B.; Liu, P.; Xiang, J.; Lou, W. CryptMe: Data Leakage Prevention for Unmodified Programs on ARM Devices. In Research in Attacks, Intrusions, and Defenses. RAID 2018; Bailey, M., Holz, T., Stamatogiannakis, M., Ioannidis, S., Eds.; Lecture Notes in Computer Science; Springer: Cham, Switzerland, 2018; Volume 11050.
  21. Wang, J.; Hong, Z.; Zhang, Y.; Jin, Y. Enabling Security-Enhanced Attestation With Intel SGX for Remote Terminal and IoT. IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst. 2018, 37, 88–96.
  22. Pettersen, R.; Johansen, H.D.; Johansen, D. Secure Edge Computing with ARM TrustZone. In Proceedings of the IoTBDS 2017, Porto, Portugal, 24–26 April 2017; pp. 102–109.
  23. Alves, T. Trustzone: Integrated hardware and software security. Inf. Q. 2004, 3, 18–24.
  24. Guan, L.; Liu, P.; Xing, X.; Ge, X.; Zhang, S.; Yu, M.; Jaeger, T. Trustshadow: Secure execution of unmodified applications with arm trustzone. In Proceedings of the 15th Annual International Conference on Mobile Systems, Applications, and Services, Niagara Falls, NY, USA, 19–23 June 2017; pp. 488–501.
  25. Paulin, D.; Hennebert, C.; Franco-Rondisson, T.; Jayles, R.; Loubier, T.; Collado, R. HistoTrust: Ethereum-Based Attestation of a Data History Built with OP-TEE and TPM. In Foundations and Practice of Security. FPS 2021; Aïmeur, E., Laurent, M., Yaich, R., Dupont, B., Garcia-Alfaro, J., Eds.; Lecture Notes in Computer Science; Springer: Cham, Switzerland, 2022; Volume 13291.
  26. Shepherd, C.; Akram, R.N.; Markantonakis, K. EmLog: Tamper-Resistant System Logging for Constrained Devices with TEEs. In Information Security Theory and Practice. WISTP 2017; Hancke, G., Damiani, E., Eds.; Lecture Notes in Computer Science; Springer: Cham, Switzerland, 2018; Volume 10741.
More
© Text is available under the terms and conditions of the Creative Commons Attribution (CC BY) license; additional terms may apply. By using this site, you agree to the Terms and Conditions and Privacy Policy.
This entry is offline, you can click here to edit this entry!
ScholarVision Creations
Feedback