The migration from classical to post-quantum security is still an on-going task on the information security field. To that end, the Quantum-secure IoT-based Digital Manufacturing pilot has been designed to study the requirements and specifications of this Post-Quantum Cryptography (PQC) migration, as well as the potential impact on a real environment protected by classical cryptography.
In a digital manufacturing system, different IoT devices are used to control and monitor the factory by exchanging data using a classical approach. However, this pilot aims to migrate this process to a quantum-secure environment. To that end, several PQC algorithms will be implemented, like ML-KEM for key agreement, or ML-DSA and SLH-DSA for signatures. In this pilot, two flavors of the same IoT device (i.e. Microcontroller Unit or MCU and Microprocessor Unit or MPU-based) are connected to a main Data Server, hereinafter the Broker. This server’s job is to store and process all the data collected from the field. The system is designed for:
- Getting data from outside sensors that are physically connected to IoT devices.
- The Broker will set a Quantum-Secure Transport Layer Security (TLS) channel up, PQ/TLS, with the IoT devices.
- On top of that, the Message Queuing Telemetry Transport (MQTT) protocol is used at the application layer for IoT data exchange.
- Check that the software on IoT devices is safe by using a Quantum-secure Remote Attestation (RA) protocol for the MPU-based IoT devices.
Integration
This pilot integrates several quantum-secure building blocks developing during the first part of the project as follows:
- IoT devices: As previously mentioned, these are the MCU and MPU-based IoT devices. These devices have the capacity to perform classical and PQC operations, provided by a hardware Secure Element (SE). The SE will include, at the end of the project, all the NIST standardized PQC algorithms (i.e., ML-KEM, ML-DSA and SLH-DSA) up to now. It also securely stores the private keys of the MPU and MCU, protecting them from unauthorized access.
- Cryptographic libraries: These libraries are embodied in the OpenSSL and MbedTLS libraries for MPU and MCU-based IoT devices in charge of performing the PQ/TLS connection with the Broker. Both libraries will use the SE to perform cryptographic operations, thereby ensuring a fast and secure communication.
- Public Key Infrastructure (PKI): The pilot demonstrator also establishes a PKI with the following components:
- Certification Authority (CA): A trusted entity responsible for issuing, managing, and revoking digital certificates. The function of the entity in question is twofold: firstly, it verifies the identity of those requesting certificates; secondly, it ensures the authenticity of their public keys.
- The Root Certification Authority (RCA) acts as an intermediary between the entities (i.e. IoT devices) and the CA. It is responsible for verifying the identity of devices prior to the issuance of a digital certificate by the CA. The RCA plays a crucial role in the verification process, though it does not issue certificates directly. In both cases, RCA and CA, composite certificates with EdDSA25519/ML-DSA-{44/65} and pure-PQ SLH-DSA certificates will be used.
- An Online Certificate Status Protocol (OCSP): used during the TLS handshake by system entities to verify the validity of a certificate in real time. In that case, this protocol will be deployed on MPU devices with a pure-PQ ML-DSA-65.
- Integrity Verification: This will validate the integrity of the MPU platform during the boot process. The secure boot will include a quantum-secure LMS algorithm and SHA3-512. In line with this approach, the Attestation Agent will be incorporated into the platform with supporting for SLH-DSA for the remote attestation, whose communication will be performed over the pre-stablished PQ/TLS connection. The device’s private key, stored in the PQ firmware Trusted Platform Module (fTPM), will be used to sign an integrity report when requested by a Remote Verifier.
Architecture
The architecture of the Quantum-Secure IoT-based Digital Manufacturing pilot is depicted in Figure 1.
The IoT device, in this case acting as the client, establishes a quantum-secure PQ/TLS channel with the Broker (i.e. the MQTT Broker), which acts as the server. The PQ/TLS handshake can be performed in a hybrid mode (e.g., X25119 / ML-KEM-768 + EdDSA25519 / ML-DSA-{44/65}) or pure-PQ mode (ML-KEM-768 + ML-DSA-{44/65}), since the server also incorporates PQC capabilities. On top of that, the MQTT Broker acts as a central hub for managing messages between devices in the MQTT-based communication system. The system utilizes a publish/subscribe model, in which the publisher (i.e., IoT devices) disseminates messages to specific topics and the subscriber (i.e., the Data Server) consumes the published messages. Both flavors of IoT devices collect data from specific sensors through their I/O interfaces. Once the quantum-secure communication channel is established, the IoT devices will send the collected data to the MQTT Broker, which in turn will publish data on specific topics. The Data Server subscribes to the respective topics and accesses data.
Furthermore, a Remote Attestation (RA) process is in place to ensure the continuous monitoring of the health status of MPU-based IoT devices. RA relies on the presence of a Remote Verifier, which is deployed on the same node as the MQTT broker. The Remote Verifier set a PQ/TLS connection up with every single IoT devices and challenges them to prove their trustworthy status through a tamper-proof integrity evidence. To do that the SHA3-512 hash function and the SLH-DSA signature algorithm are used. If all MPU-based IoT devices are assessed as trustworthy, the system continues to operate as described above. Should the Remote Verifier detect any signs of compromise on one or more MPU-based IoT devices, it will promptly notify the MQTT Broker that a device with a particular device ID has been compromised. From that point on, the MQTT Broker has taken the following measures to protect the system: the compromised device has been isolated by the Broker, which has refused connections from it and closed any ongoing connections. This has been done to prevent data from tampered devices from being injected into the Data Server (i.e. the injection of potentially malicious data).
Figure 1: Quantum-Secure IoT-based Digital Manufacturing Pilot schematic
Use Cases and Validation Plan
The Validation Plan will be responsible for evaluating the performance, resource utilization and power consumption of the various IoT devices in a relevant environment. To that end, we have defined two different use cases in which the Pilot will be tested in a real environment:
- In the first use case, different IoT devices will monitor the ambient temperature of the production environment and the number of parts produced by the FLEXIM device (https://www.smartfactory.it/flexim-en.html).
- In the second use case, the IoT devices will be used for the tracking of manufacturing machine data and production data in the same FLEXIM device, which includes the number of parts produced or discarded, temperature, and error codes.
In such cases, we will assess the impact of implementing PQC algorithms on performance in comparison to classical ones. Additionally, we will examine how the SE implemented in HW could accelerate this process.
Conclusions
The Quantum-Secure IoT-based Digital Manufacturing Pilot involved the design of a complete quantum-secure infrastructure, beginning with the design of specific IoT devices for PQC. In pursuit of this objective, we have integrated a variety of building blocks, with further integration processes underway. In order to evaluate the platform in a real environment, we have defined several use cases in which the Pilot will be integrated into a real manufacturing process, as is the case with FLEXIM device.
