By Masab Iqbal, PhD, Cryptography Engineer at Multiverse Computing
The work described in this article is the result of a collaborative effort across multiple teams at Multiverse Computing. You can find the full list of contributors at the end of this article.
In the realm of internet of things (IoT), confidentiality is often treated as a "real-time" requirement; however, a time-shifted attack known as Harvest Now, Decrypt Later (HNDL) changes the stakes [1]. Adversaries do not need to read your traffic today. Instead, they can silently record encrypted IoT data at scale—across Wi-Fi, gateways, ISP links, or cloud paths—and simply wait.
Most current IoT communication relies on transport layer security (TLS) where classical encryption like RSA or ECC are used to derive session keys. This is endangered because its security relies on mathematical problems (factorization and discrete logarithms) that quantum computers can efficiently solve using Shor’s algorithm [2]. Once the IoT "encrypted diary" becomes readable, the consequences are severe and vary by sector.
Examples of Long-Term Data Exposure
- Industrial Operations: Historical telemetry can be exploited to reveal production cycles, batch cadence, machine utilization, downtime, and yield patterns—providing valuable operational intelligence to competitors.
- Healthcare & Privacy: Previously secure streams can expose sensitive diagnoses, medication timing, and vulnerable moments; these are privacy harms that do not expire just because time has passed.
- Smart Environments: Even simple data like temperature readings can be used to reconstruct occupancy patterns in homes or offices (such as sleep schedules or vacations) and can even correlate with specific factory states.
To prevent this, we must upgrade how TLS derives its session keys using Post-Quantum Cryptography (PQC) [3], which is built on mathematical problems believed to resist both classical and quantum attacks.
The Challenge: Hybrid PQC in TLS Under Tight IoT Budgets
The transition to post-quantum cryptography (PQC) is driven by ongoing standardization efforts (e.g., ML-KEM in FIPS 203 and ML-DSA in FIPS 204 for signatures). However, integrating PQC into IoT systems is particularly challenging due to resource constraints and ecosystem limitations.
- High combined overhead: Incorporating both PQC key exchange and PQC certificates simultaneously significantly increases computational cost, memory usage, and handshake size—beyond what many constrained devices can efficiently support.
- Limited ecosystem readiness: Tooling, libraries, and certificate management workflows for end-to-end PQC are still evolving, making immediate full deployment impractical.
As a result, feasibility of the practical deployment of PQC in resource-constrained devices should be evaluated in a gradual step-by-step migration strategy.
The Solution: A Step Toward PQC-Ready IoT Confidentiality
To address these challenges, this work adopts a stepwise migration strategy that introduces PQC gradually rather than attempting full integration at once.
- Stage 1 – PQC for key exchange: Hybrid TLS 1.3 is used with ECDHE + ML-KEM for key establishment, while retaining classical certificates for authentication. This enables quantum-resistant confidentiality without requiring a full PQC PKI.
- Compatibility and deployability: Leveraging existing TLS workflows (e.g., via wolfSSL) ensures minimal architectural changes and maintains interoperability with current systems.
- Path to full PQC: Once feasibility is validated, the approach can be extended to a second stage where both key exchange and certificates adopt PQC, enabling full end-to-end quantum-resistant communication.
The Tech Stack and Workflow
The work is organized around a simple but realistic IoT flow: an ESP32, a low-cost microcontroller with integrated Wi-Fi and Bluetooth, emulates a sensor device, while a gateway/server running on macOS receives the telemetry and forwards it to the monitoring stack.
The ESP32 side is implemented as an ESP-IDF application, and the server side is a C program that accepts incoming connections and processes the received measurements. For security, both sides use wolfSSL, which enables TLS session establishment and PQC-ready or hybrid key exchange.
The summary of the tech stack is as follows:
The architecture of this system consists of four layers, as illustrated in Figure 1. At the edge layer, the ESP32 acts as a TLS client and telemetry publisher, formatting temperature readings as a small payload to emulate a smart-environment scenario in which seemingly harmless data may reveal sensitive patterns such as occupancy or operational states.
This telemetry is transmitted over a secure channel established through the security layer, which implements Hybrid TLS 1.3 using wolfSSL, combining ECDHE and ML-KEM for key exchange and providing authentication and encryption. At the gateway layer, a wolfSSL-based TLS endpoint receives the connection, performs payload validation, and handles application-level processing such as acknowledgment and logging.
The processed data is then forwarded to the data and monitoring layer, where it is stored in InfluxDB as time-series data and visualized through Grafana dashboards. This layered workflow demonstrates that secure, PQC-ready telemetry can be integrated into a practical monitoring pipeline while preserving existing system architecture and observability.
Verification: Under the Hood
To validate the migration, we analyze the client and server-side logs and the network traffic to ensure PQC is actually in use.
The serial monitor confirms the ESP32 has upgraded the connection to a TLS 1.3 session and is transmitting encrypted application messages.
The server logs confirm that the session keys were established using a post-quantum/hybrid KEM approach during the TLS handshake.
Wire-Level Evidence
The most critical proof exists in the TLS handshake data. Using Wireshark, we can inspect the ClientHello and ServerHellopackets to verify the specific algorithms used.
In this prototype, Wireshark identifies the key exchange group as 12109. This is the identifier for WOLFSSL_P521_ML_KEM_1024, which combines the traditional NIST P-521 elliptic curve with ML-KEM-1024.
End-to-End Success
The result is a secure, quantum-resistant pipeline where PQC secure telemetry travels from the device to a live monitoring stack for without compromising performance of the resource constrained edge device.
What We Proved—and What Comes Next
- Practical PQC deployment in constrained IoT systems is already feasible today to tackle HNDL attacks, as demonstrated in a smart-environment temperature-monitoring scenario using resource-constrained devices.
- Migration to PQC can start today, beginning with hybrid key exchange rather than attempting full replacement in a single step.
- PQC is enabled in existing telemetry pipelines, including monitoring, storage, and visualization platforms compatible with the existing infrastructure.
- For Multiverse Computing, this creates a concrete opportunity to support customers with quantum-readiness assessments, hybrid TLS integration, constrained-device validation, and step-by-step migration toward broader PQC adoption.
References
[1] M. Mosca, “Cybersecurity in an era with quantum computers: Will we be ready?” IEEE Security & Privacy, vol. 16, no. 5, pp. 38–41, Sept.–Oct. 2018.
[2] CISA, “Post-Quantum Considerations for Operational Technology,” 2024.
[3] J. Zheng, H. Zhu, Y. Dong, Z. Song, Z. Zhang, Y. Yang, and Y. Zhao, “Faster Post-Quantum TLS 1.3 Based on ML-KEM: Implementation and Assessment,” in Proc. ESORICS, 2024.
Acknowledgement
This work was developed within the framework of the ZE-2025/00041 – BAQURA proiektua project, an action co-financed by the Gobierno Vasco (Departamento de Industria, Transición Energética y Sostenibilidad) and the European Union through the Fondo Europeo de Desarrollo Regional 2021-2027 (FEDER).
I would like to sincerely thank Director DoÄźancan Gemici for encouraging me to write this post; Javier GĂłmez and Miquel Brunet for reviewing it; and Margarita Torres, Gabriela Milan and Ignacio Iturrarte for the support.