Quantum-Resistant Encryption for IoT Communication in Critical Engineering Infrastructure †
Abstract
1. Introduction
2. Literature Review
- Device and sensing layer: Embedded controllers with PUF-based identity seeds [16];
- Network and transport layer: Hybrid TLS 1.3 handshake supporting PQC + Elliptic-Curve Diffie–Hellman Ephemeral (ECDHE) [2];
- Governance layer: IEC 62443/ISO 30141 compliance and key-management policies [15].
3. Methodology
- Requirements: Security, performance, and compliance criteria were extracted from the IEC 62443-4-2 and ISO/IEC 30141 standards [15];
- Hybrid protocol architecture: Integration of PQC + LWC + PUF layers into an IoT communication stack (Figure 1);
- Prototype implementation: Embedded firmware development using ARM Cortex-M33 and RISC-V microcontrollers;
- Evaluation and validation: Benchmarking under latency, power, and throughput metrics; security analysis via simulated quantum adversary models.
- PQC layer: CRYSTALS-Kyber (ML-KEM-768) for key encapsulation [7];
- Signature layer: Dilithium (ML-DSA-768) for device authentication [7];
- Device and sensing layer: Embedded MCUs generate PUF-derived entropy to seed Kyber keypairs. Local Ascon-protected data buffers collect telemetry (sensor status, voltage, temperature);
- Edge security layer: Edge gateways aggregate data and perform Kyber KEM handshakes with central servers. Session keys rotate every 100 transactions to minimize harvest-now/decrypt-later risk [6];
- Network and transport layer: Implements Hybrid TLS 1.3 (PQC + ECDHE) with server certificate signed using Dilithium [2]. Session key negotiation uses Kyber for KEM and AES-GCM fallback for legacy devices;
- Governance layer: Security monitoring dashboard enforcing IEC 62443/ISO 30141 compliance [15]. Policy engine logs key rotation, firmware signing, and audit events.
- Client Hello: Client announces PQC support (kyber768+ecdhe_secp256r1);
- Server Hello: Server responds with Kyber public key and ECDHE parameters;
- Client Key Exchange: Client encapsulates shared secret via Kyber ciphertext;
- Server Decrypt: Server decapsulates to recover shared secret;
- Symmetric Phase: Both sides derive Ascon-128a session key = HKDF(Shared Secret).
- Handshake latency (ms): Time for client–server PQC session setup;
- Encryption throughput (Mbps): Measured for Ascon payloads of 128–4096 bytes;
- Message authentication latency: Ascon tag generation time.
4. Results
5. Discussion
6. Conclusions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Acknowledgments
Conflicts of Interest
References
- Shor, P.W. Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. SIAM J. Comput. 1997, 26, 1484–1509. [Google Scholar] [CrossRef]
- RFC 8446; The Transport Layer Security (TLS) Protocol Version 1.3. IETF: Wilmington, DE, USA, 2018. [CrossRef]
- Chen, L.; Jordan, S.; Liu, Y.; Moody, D. Report on Post-Quantum Cryptography; NIST Internal Report 8105; U.S. Department of Commerce: Washington, DC, USA, 2016. [Google Scholar] [CrossRef]
- Alagic, G.; Alperin-Sheriff, J.; Cooper, D.; Dang, Q.; Kelsey, J.; Liu, Y.-K.; Miller, C.; Moody, D.; Peralta, R.; Perlner, R.; et al. Status Report on the Second Round of the NIST Post-Quantum Cryptography Standardization Process. NIST IR 8309; US Department of Commerce, National Institute of Standards and Technology: Gaithersburg, MD, USA, 2020. [Google Scholar] [CrossRef]
- Alagic, G.; Alperin-Sheriff, J.; Cooper, D.; Dang, Q.; Kelsey, J.; Liu, Y.-K.; Miller, C.; Moody, D.; Peralta, R.; Perlner, R.; et al. Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process. NIST IR 8413; US Department of Commerce, National Institute of Standards and Technology: Gaithersburg, MD, USA, 2022. [Google Scholar] [CrossRef]
- NIST. NIST Releases First 3 Finalized Post-Quantum Encryption Standards (ML-KEM, ML-DSA, SLH-DSA). NIST News Release. 13 August 2024. Available online: https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards (accessed on 1 January 2020).
- Ojha, V.P.; Chauhan, S.; Yarahmadian, S.; Carvalho, D. Unfolding Post-Quantum Cryptosystems: CRYSTALS-Dilithium, McEliece, BIKE, and HQC. Mathematics 2025, 13, 2841. [Google Scholar] [CrossRef]
- Dobraunig, C.; Eichlseder, M.; Mendel, F.; Schläffer, M. Ascon v1.2: Lightweight Authenticated Encryption and Hashing. J. Cryptol. 2021, 34, 33. [Google Scholar] [CrossRef]
- NIST. NIST Selects “Ascon” as the Lightweight Cryptography Standard. Press Release. 7 February 2023. Available online: https://www.nist.gov/news-events/news/2023/02/nist-selects-lightweight-cryptography-algorithms-protect-small-devices (accessed on 8 April 2026).
- Alotaibi, B.; Al-Nasser, M.; Alabdulatif, A.; Alghamdi, A.; Alharbi, A. A Survey on Industrial Internet of Things Security. Sensors 2023, 23, 7470. [Google Scholar] [CrossRef] [PubMed]
- Kong, L.; Jin, J.; Wang, Z.; Gao, L.; Zhang, Y.; Shi, W. Edge-Computing-Driven Internet of Things: A Survey. ACM Comput. Surv. 2022, 55, 1–45. [Google Scholar] [CrossRef]
- Andriulo, F.C.; Postorino, M.N. Edge Computing and Cloud Computing for Internet of Things: A Review. Informatics 2024, 11, 71. [Google Scholar] [CrossRef]
- IEC 62443-4-2:2019; Security for Industrial Automation and Control Systems—Part 4-2: Technical Security Requirements for IACS Components. International Electrotechnical Commission (IEC): Geneva, Switzerland, 2019. Available online: https://standards.iteh.ai/catalog/standards/sist/3ed80464-8d4d-41e1-97ea2783bd958502/iec-62443-4-2-2019 (accessed on 21 April 2026).
- NIST. Lightweight Cryptography—Ascon Standardization and Implementation Updates (Workshop 2023 Materials). Available online: https://csrc.nist.gov/projects/lightweight-cryptography (accessed on 8 April 2026).
- IEC 62443-4-2; Security for Industrial Automation and Control Systems—Part 4-2: Technical Security Requirements for IACS Components (with 2022 Corrigendum). International Electrotechnical Commission (IEC): Geneva, Switzerland, 2019. Available online: https://webstore.iec.ch/en/publication/34421 (accessed on 8 April 2026).
- Babaei, A.; Schiele, G. Physical Unclonable Functions in the Internet of Things: State of the Art and Open Challenges. Sensors 2019, 19, 3208. [Google Scholar] [CrossRef] [PubMed]
- Shamsoshoara, A.; Korenda, A.; Afghah, F.; Zeadally, S. A Survey on Physical Unclonable Functions (PUFs): Architecture and Applications. Comput. Netw. 2020, 183, 107593. [Google Scholar] [CrossRef]
- ISO/IEC 30141:2024; Internet of Things (IoT)—Reference Architecture, Edition 2. ISO: Geneva, Switzerland, 2024. Available online: https://www.iso.org/standard/88800.html (accessed on 21 April 2026).




| Algorithm | Type | Public Key Size (Bytes) | Ciphertext/ Signature (Bytes) | Security Level (bits) | Typical Handshake Latency (ms, ARM M4) | Suitability for IoT |
|---|---|---|---|---|---|---|
| Kyber-512 | Lattice (KEM) | 800 | 768 | 128 | 3.5 | High |
| SABER | Lattice (KEM) | 992 | 1088 | 128 | 4.0 | High |
| Dilithium-II | Lattice (Signature) | 1312 | 2420 | 128 | 6.2 | Medium |
| Classic McEliece | Code (KEM) | 261,120 | 128 | 256 | >200 | Low |
| BIKE-1 Level 1 | Code (KEM) | 12,803 | 1578 | 128 | 9.3 | Medium |
| SPHINCS+-SHA2-128s | Hash (Signature) | 32 | 7856 | 128 | 5.8 | High |
| Rainbow Ia | Multivariate (Signature) | 66 k | 66 k | 128 | — (vulnerable) | Discarded |
| Constraint Category | Representative Requirement | Source |
|---|---|---|
| Real-time operation | ≤5 ms encryption latency per message; deterministic response | IEC 62443-4-2 |
| Memory footprint | <256 kB Flash/64 kB RAM | Field controller specs |
| Power consumption | <10 mJ per handshake; battery operation > 1 year | IIoT node profiles |
| Quantum resilience | Security ≥ 128-bit against LWE/Grover attacks | NIST IR 8413 [5] |
| Interoperability | Backward-compatible with TLS 1.3, MQTT, CoAP | IETF RFC 8446 [2] |
| Governance compliance | IEC 62443 and ISO 30141 policies enforced | [15] |
| IEC 62443-4-2 Control Requirement | Requirement Description | Implemented Mechanism in the Proposed Framework | Compliance Level (✓ = Compliant) | Evidence/Reference |
|---|---|---|---|---|
| CR 1.1—Identification and Authentication Control | Each component shall provide a unique, verifiable identity. | PUF-based identity seeds and Dilithium digital signatures ensure tamper-proof device authentication. | ✓ Full Compliance | [7,15] |
| CR 1.2—Use Control | Only authorized entities may access component functions. | Role-based access integrated within Ascon-authenticated channels; MQTT ACLs enforce per-topic control. | ✓ Full Compliance | [8,9,10] |
| CR 2.1—Data Integrity | Prevent unauthorized modification of transmitted or stored data. | Ascon-128a authenticated encryption guarantees message integrity via hash-based MAC. | ✓ Full Compliance | [8,9] |
| CR 2.2—Data Confidentiality | Prevent disclosure of sensitive data to unauthorized parties. | Hybrid TLS 1.3 (PQC + ECDHE) sessions using Kyber KEM provide quantum-resilient secrecy. | ✓ Full Compliance | [2,7] |
| CR 2.3—Restricted Data Flow | Enforce data-flow control between security zones. | Network segmentation with crypto-agile gateway managing PQC-encrypted telemetry paths. | ✓ Partial Compliance (Policy Defined) | [10,12,15] |
| CR 3.1—System and Communication Protection | Protect against unauthorized network access and message replay. | Nonce-based Ascon AEAD with unique per-session keys; hybrid TLS 1.3 anti-replay mechanisms. | ✓ Full Compliance | [8,9,15] |
| CR 3.2—Event Logging | Log security-relevant events and maintain auditability. | Governance layer logs key exchange, firmware signing, and intrusion detection under IEC 62443 policy. | ✓ Full Compliance | [15] |
| CR 4.1—Use of Cryptography | Apply strong cryptographic measures appropriate to the risk. | NIST-standardized Kyber, Dilithium, and Ascon algorithms integrated in TLS stack. | ✓ Full Compliance | [5,6,7,9] |
| CR 4.2—Key Management | Secure generation, storage, and destruction of keys. | PUF-derived keys ensure non-exportable secrets; Kyber KEM manages ephemeral key exchange. | ✓ Full Compliance | [7,16,17] |
| CR 5.1—Availability | Maintain component availability under cyber-attack. | Lightweight cryptography minimizes computational load (<25% CPU usage), ensuring real-time continuity. | ✓ Full Compliance | [8,10] |
| CR 5.2—Resource Availability | Detect and prevent resource exhaustion (DoS). | Adaptive handshake timeout and Ascon AEAD rate-limiting; secure gateway buffering. | ✓ Partial Compliance (Test Stage) | [12,15] |
| CR 6.1—Firmware Integrity and Update | Verify authenticity and integrity of firmware. | Dilithium-signed firmware packages verified at secure boot and OTA update. | ✓ Full Compliance | [7,15] |
| CR 7.1—Security Monitoring and Alerting | Detect and respond to anomalous or malicious activity. | Governance dashboard aligned with IEC 62443 event categories; audit logs signed with ML-DSA. | ✓ Partial Compliance (Planned Automation) | [15] |
| Component | Specification |
|---|---|
| Microcontroller | ARM Cortex-M33 @ 96 MHz, 256 kB Flash, 64 kB RAM |
| Crypto library | PQM4 (optimized for PQC on ARM) + Ascon v1.2 implementation [8] |
| Compiler | GNU ARM GCC 10.3 with -O3 optimization |
| Operating system | FreeRTOS v10.5 |
| Communication protocol | Hybrid TLS 1.3 over MQTT broker (Mosquitto) [10] |
| Measurement tools | STM32 Energy Monitor and logic analyzer for cycle counting |
| Dataset | Simulated sensor telemetry (1 Hz sampling of pressure, temperature, vibration) |
| Algorithm | Type | Handshake Time (ms) | Reduction vs. ECC | Energy (mJ) | Security Level (bits) | Algorithm |
|---|---|---|---|---|---|---|
| ECC-256 (TLS 1.3 Baseline) | Classical | 9.8 ± 0.4 | – | 0.36 | 128 | ECC-256 (TLS 1.3 Baseline) |
| Kyber-768 | PQC (Lattice) | 3.5 ± 0.2 | −64% | 0.12 | 128 (quantum) | Kyber-768 |
| Hybrid Kyber + ECDHE | PQC + Classical | 5.1 ± 0.3 | −48% | 0.19 | 256 (effective) | Hybrid Kyber + ECDHE |
| Cipher | Mode | Average Throughput (Mbps) | Energy per Byte (μJ) | Memory Usage (kB) | Remarks |
|---|---|---|---|---|---|
| AES-GCM-128 | AEAD (Galois/Counter Mode) | 9.2 ± 0.3 | 7.6 | 52 | Baseline TLS 1.3 implementation; strong but energy-intensive. |
| Ascon-128a | AEAD (Permutation-based LWC) | 24.3 ± 0.5 | 3.1 | 36 | 2.6× faster and ≈59% more energy-efficient than AES-GCM; standardized as NIST LWC 2023 [8,9]. |
| ChaCha20-Poly1305 | AEAD (Stream cipher alternative) | 14.5 ± 0.4 | 4.8 | 44 | Moderate speed, software-friendly, not hardware-optimized. |
| Grain-128AEAD | Lightweight AEAD candidate | 18.6 ± 0.6 | 3.7 | 40 | High throughput but less mature toolchain support. |
| Firmware Component | Description/Function | Flash Memory (kB) | RAM Usage (kB) | CPU Load (% @ 1 Hz Sampling) | Remarks |
|---|---|---|---|---|---|
| PUF + Fuzzy Extractor | Generates unique entropy and stabilizes PUF output for seeding Kyber PRF [16,17]. | 6.0 | 2.0 | 2.8 | Lightweight hardware-bound identity generation; non-volatile keyless design. |
| Kyber KEM (ML-KEM-768) | Performs post-quantum key encapsulation and decapsulation using lattice-based arithmetic [7]. | 32.0 | 8.0 | 11.5 | Dominant computational module; still within embedded thresholds. |
| Ascon-128a AEAD Module | Provides lightweight authenticated encryption and hashing for telemetry streams [8,9]. | 4.0 | 1.5 | 4.7 | Optimized for 32-bit ARM cores; energy per byte ≈ 3.1 μJ. |
| TLS 1.3 Integration Layer | Hybrid key-exchange orchestrated |
| Framework | Crypto Primitives | Handshake (ms) | Energy/Handshake (mJ) | Average Payload Throughput (Mbps) | IEC 62443 Compliance Score | Security Resilience (SRI) | Memory Footprint (Flash/RAM, kB) | Backward Compatibility | Remarks |
|---|---|---|---|---|---|---|---|---|---|
| Classical TLS 1.3 | ECDHE-P256 + AES-GCM-128 | 9.8 ± 0.4 | 0.36 | 9.2 | 0.72 | 0.05 | ~70/18 | Yes | Mature but not quantum-safe; vulnerable to HNDL (harvest-now, decrypt-later). |
| PQC-Only | Kyber-768 (KEM) + AES-GCM-128 | 3.5 ± 0.2 | 0.12 | 9.2 | 0.85 | 4.65 | ~46/13 | Partial | Quantum-safe key exchange; symmetric layer remains heavier on MCU. |
| Hybrid PQC–LWC–PUF (Proposed) | Kyber-768 + Ascon-128a + PUF + Dilithium | 5.1 ± 0.3 | 0.19 | 24.3 | 0.86 | 5.20 | ~53/15 | Yes | Best overall balance: quantum-safe, fastest telemetry, hardware-rooted identity, crypto-agile TLS. |
| Hybrid (Kyber + ChaCha20-Poly1305) | Kyber-768 + ChaCha20-Poly1305 | 5.4 ± 0.3 | 0.21 | 14.5 | 0.84 | 5.00 | ~55/16 | Yes | Good software speed; throughput below Ascon; broader legacy support than AES-GCM-only. |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2026 by the author. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license.
Share and Cite
Leong, W.Y. Quantum-Resistant Encryption for IoT Communication in Critical Engineering Infrastructure. Eng. Proc. 2026, 134, 76. https://doi.org/10.3390/engproc2026134076
Leong WY. Quantum-Resistant Encryption for IoT Communication in Critical Engineering Infrastructure. Engineering Proceedings. 2026; 134(1):76. https://doi.org/10.3390/engproc2026134076
Chicago/Turabian StyleLeong, Wai Yie. 2026. "Quantum-Resistant Encryption for IoT Communication in Critical Engineering Infrastructure" Engineering Proceedings 134, no. 1: 76. https://doi.org/10.3390/engproc2026134076
APA StyleLeong, W. Y. (2026). Quantum-Resistant Encryption for IoT Communication in Critical Engineering Infrastructure. Engineering Proceedings, 134(1), 76. https://doi.org/10.3390/engproc2026134076

