Post-Quantum Entropy as a Service for Embedded Systems

This paper presents a Quantum Entropy as a Service (QEaaS) system that delivers post-quantum-secured entropy to embedded ESP32 devices, demonstrating that ML-KEM-512 and ML-DSA-44 protocols achieve DTLS 1.3 handshakes significantly faster than classical ECDHE P-256 counterparts while maintaining robust security.

The Gist

Imagine you are building a tiny, battery-powered robot (like a smart thermostat or a sensor in a forest) that needs to keep secrets. To keep those secrets safe, the robot needs to generate random numbers to create its locks and keys.

In the world of computers, these random numbers are called entropy. If the numbers aren't truly random, a hacker can guess the lock and break in.

Here is the problem: Tiny robots are "dumb" in a good way—they are small, cheap, and have very little brainpower. They often struggle to generate truly random numbers on their own. They might rely on a shaky hardware sensor that isn't very good at it.

This paper presents a clever solution: Don't make the robot generate the randomness; just send it some from a super-powerful source.

The Big Idea: "Randomness as a Service"

Think of this like a water utility company.

• The Robot (Client): It's a small house with a tiny, leaky well. It can't produce enough clean water (randomness) to survive.
• The Server (QEaaS): It's a massive, high-tech water treatment plant powered by Quantum Physics. It produces an endless supply of perfectly pure, unpredictable water.
• The Delivery Truck: It drives the water from the plant to the house.

The authors built a system where a powerful server (using a special quantum device called a Quantis QRNG) generates perfect randomness and sends it to tiny robots over the internet.

The "Quantum" Twist

Usually, if you send secret data over the internet, you use standard encryption (like a padlock). But scientists predict that in the future, Quantum Computers will be so powerful they can pick those standard locks instantly.

To stop this, the authors used Post-Quantum Cryptography (PQC).

• Analogy: Instead of a standard padlock, they used a super-complex, futuristic safe that even a quantum computer couldn't crack.
• They used new, standardized algorithms (called ML-KEM and ML-DSA) to protect the "water truck" so no one could steal the randomness while it was being delivered.

The Surprise: It's Actually Faster!

The biggest shock in this paper is the speed.
Usually, when you add extra security (like a bigger, heavier safe), things get slower. You'd expect the tiny robot to struggle with these heavy quantum locks.

But the opposite happened.

• The "Quantum" locks were actually 35% to 63% faster than the old standard locks on these tiny robots.
• Why? The old locks (Elliptic Curve) require the robot to do complex math that its small brain finds difficult. The new "Quantum" locks use a different type of math (matrix operations) that happens to be much easier for these specific tiny chips (ESP32) to calculate.

It's like trying to carry a heavy stone (old lock) vs. a heavy feather (new lock). Even though the feather looks "lighter" in the air, the robot's hands are built to grab feathers easily, but the stone is too awkward.

How It Works (The Journey)

1. The Source: A server in Madrid uses a laser and a camera to catch photons (particles of light) bouncing around. This is true quantum randomness.
2. The Delivery: The server packages this randomness and sends it to the robot using CoAP (a lightweight language for tiny devices) protected by the new Quantum-safe locks.
3. The Mixing: The robot receives the "pure water" and mixes it into its own small internal bucket (a BLAKE2s pool). This ensures the robot always has a fresh supply of perfect randomness, even if its own hardware is shaky.

The Results

The team tested this on a tiny chip (ESP32) that costs a few dollars.

• Speed: Setting up the secure connection took less than a quarter of a second (225 milliseconds).
• Efficiency: The robot could request fresh randomness about 40 times a second.
• Verdict: Not only is this system secure against future quantum computers, but it is also more efficient than the current standard for these tiny devices.

The Takeaway

This paper proves that we don't have to choose between security and speed for tiny devices. By outsourcing the hard work of generating randomness to a powerful server and using smart, future-proof locks, we can make the Internet of Things (IoT) safer and faster, even against the computers of the future.

In short: They built a "Randomness Delivery Service" that uses quantum physics to make tiny robots safer, and surprisingly, it made them run faster too.

Technical Summary

Here is a detailed technical summary of the paper "Post-Quantum Entropy as a Service for Embedded Systems."

1. Problem Statement

Embedded cryptography relies heavily on high-quality entropy for key generation, nonces, and salting. However, constrained IoT devices (e.g., microcontrollers) face two critical challenges:

• Weak Local Entropy: Many small devices lack trustworthy hardware random number generators (HRNGs), or the path from the physical noise source to the software API is opaque and potentially compromised by vendor post-processing.
• Transport Security: While Quantum Random Number Generators (QRNGs) offer high-quality entropy, distributing this entropy to remote devices requires a transport channel that is secure against future quantum attacks. Traditional protocols (TLS/HTTPS) are vulnerable to quantum decryption.

The paper addresses the gap in delivering Quantum Entropy as a Service (QEaaS) to resource-constrained embedded systems over Post-Quantum Cryptography (PQC) secured channels, specifically focusing on the CoAP protocol preferred by IoT devices.

2. Methodology and System Architecture

The authors designed and implemented a full end-to-end QEaaS architecture comprising a server, a transport layer, and an embedded client.

Server Architecture

• Source: A Quantis QRNG PCIe-240M generates raw quantum entropy (58 Mbit/s) via photon counting.
• Dual Access Paths:
  1. Direct Path: A custom OpenSSL provider exposes raw quantum entropy directly.
  2. Mixed Path: The rng-tools daemon injects quantum entropy into the Linux system pool, which is then consumed via standard interfaces.
• Protocols: The server exposes both HTTPS (via Nginx/OQS-OpenSSL) and secure CoAP (via a CoAP-HTTP proxy using wolfSSL).
• PQC Implementation: The server utilizes NIST-standardized lattice-based algorithms: ML-KEM (FIPS 203) for key encapsulation and ML-DSA (FIPS 204) for digital signatures.

Client Architecture (Embedded)

• Hardware: ESP32-DevKitC V4 (Dual-core Xtensa LX6 @ 240 MHz, 520 kB SRAM, 4 MB Flash).
• OS & Stack: Runs Zephyr RTOS.
  • Connectivity: Uses mbedTLS for WiFi (WPA2).
  • Application Layer: Uses libcoap (extended with POSIX APIs) for CoAP.
  • Security: Uses wolfSSL (5.8.2) as the DTLS 1.3 backend, configured with native ML-KEM and ML-DSA implementations.
• Entropy Pool: The authors implemented a custom BLAKE2s-based entropy pool within Zephyr. This pool:
  • Maintains 512 bytes of mixed entropy.
  • Supports an entropy_add_entropy() API to inject server-provided quantum bytes.
  • Preserves the standard entropy_get_entropy() interface for applications.
• Optimization: To fit PQC on the ESP32, the team redirected memory allocations from the limited newlib heap (~22 kB) to the Zephyr system heap (105 kB) and disabled unused cipher suites.

3. Key Contributions

1. First End-to-End QEaaS for Embedded PQC: Demonstrates a working system delivering QRNG entropy to microcontrollers over CoAP protected by DTLS 1.3 with NIST-standardized PQC algorithms.
2. Custom Zephyr Entropy Driver: Developed a BLAKE2s-based entropy pool for Zephyr that allows external entropy injection while maintaining compatibility with standard application APIs.
3. PQC Optimization on ESP32: Successfully ported ML-KEM and ML-DSA to the ESP32, overcoming memory constraints (heap overflow) and MTU fragmentation issues (via HelloRetryRequest) without cryptographic weakening.
4. Performance Benchmarking: Provided a comprehensive latency analysis comparing PQC configurations against classical baselines (ECDHE P-256 + ECDSA) in a real-world IoT setting.

4. Experimental Results

The system was benchmarked over a local LAN (WiFi) with 100 iterations per configuration.

Local Entropy Pool Performance

• Latency: Extremely low. Injecting and extracting 32 bytes of entropy takes approximately 51 µs total.
• Impact: Local pool operations are negligible (<0.1 ms) compared to network round trips.

Handshake and Transport Latency

The study compared three key exchange algorithms (ECDHE P-256, X25519, ML-KEM-512) paired with two signature schemes (ECDSA, ML-DSA-44) under two verification modes (No Verify, Full Verify).

• Fastest Configuration: ML-KEM-512 + ML-DSA-44 with full certificate verification completed the DTLS 1.3 handshake in 249 ms (mean).
• Classical Baseline: ECDHE P-256 + ECDSA with full verification took 668 ms.
• Performance Gain: The fully post-quantum configuration is 63% faster than the classical baseline, even with full certificate verification enabled.
  • Without verification: ML-KEM-512 + ML-DSA-44 took 225 ms (35% faster than ECDHE P-256).
• Signature Efficiency: The primary driver of speed was the signature scheme. ML-DSA-44 certificate verification added only 17 ms, whereas ECDSA added 194 ms.
• Key Exchange: ML-KEM-512 was faster than ECDHE P-256 because its matrix-vector operations map efficiently to the Xtensa LX6 architecture, whereas ECDHE requires two expensive elliptic-curve scalar multiplications.

Resource Footprint

• Flash: Increased by ~30 kB for the full PQC stack (888 kB total vs. 855 kB baseline).
• Heap: Peak heap usage increased by ~31 kB (97 kB used vs. 66 kB for classical), remaining within the 105 kB available system heap.

5. Significance and Conclusion

This paper challenges the prevailing assumption that Post-Quantum Cryptography is too heavy for constrained IoT devices.

• Feasibility: It proves that PQC is not only feasible but faster than classical ECC on the ESP32 platform when using optimized implementations (wolfSSL) and efficient algorithms (ML-KEM/ML-DSA).
• Operational Viability: With a handshake time of ~250 ms and a steady-state CoAP RTT of ~24 ms, the system can support duty-cycled nodes that wake up, refresh their entropy pool, and return to sleep within a practical timeframe.
• Architectural Impact: The work establishes a blueprint for "Entropy as a Service" where the trust anchor is a remote QRNG, secured by a quantum-resistant transport layer, solving the local entropy scarcity problem for IoT without compromising security against future quantum threats.

Future Work: The authors plan to integrate entropy injection into Zephyr's OS work queue, test higher-security PQC variants on the ESP32-S3, and conduct energy consumption analysis for battery-powered deployments.