PaperlayerView exact revision on arXiv

Source-linked AI summary

A Non-Invasive Cloud-Based Migration Strategy for Post-Quantum Cybersecurity in Smart HVAC Systems: Architecture, Implementation, and Empirical Evaluation

Mahedee Zaman Moon, Kaysarul Anas Apurba, Md Hasibul Hasan, Sk Md Mizanur Rahman

arXiv:2609.27828v1cs.CRcs.AIeess.SY

TL;DR

Legacy HVAC controllers can remain in service for decades, while Shor’s algorithm breaks RSA and ECDH. The paper proposes a post-quantum proxy between the mobile app and vendor cloud that leaves existing infrastructure unchanged. Its complete post-quantum handshake adds 0.38 ms over the classical baseline.

  • Problem

    Legacy HVAC controllers remain in service for a decade or more, while Shor’s algorithm breaks RSA and ECDH, making post-quantum protection relevant to these long-lived devices.

    Source: §1 · pp. 1–2

  • Method

    The paper inserts a post-quantum proxy between the mobile application and vendor cloud, leaving the HVAC device, firmware, and existing infrastructure unchanged.

    Source: §1 · p. 2

  • Results

    0.38 ms over the classical baseline for the complete post-quantum handshake; the gateway sustains 443 sessions per second on commodity hardware.

    Source: §11 · p. 24

  • Takeaways & Limitations

    The architecture was empirically evaluated on real hardware rather than through estimation alone.

    Source: §11 · p. 24

    Energy per operation is estimated using a constant-power model because direct hardware energy measurement was unavailable.

    Source: §6.3 · p. 12

Abstract

from arXiv · show

Legacy smart HVAC controllers rely on vendor-cloud TLS secured by ECDH and RSA, both broken by Shor's algorithm, and typical 10-15 year lifespans mean today's devices remain in service through the quantum-threat era. Direct on-device post-quantum cryptography is infeasible: an ESP32-S3, representative of capable HVAC hardware, has only 339 KB free heap against the 900 KB ML-KEM-768 requires, and even classical ECDH-P256 keygen (111.93 ms) dwarfs hardware AES-128 (0.032 ms). We propose a non-invasive PQC proxy, requiring no device, firmware, or vendor-cloud changes, performing ML-KEM-768 encapsulation and ML-DSA-65 authentication (NIST FIPS 203/204) with AES-256-GCM session keys via HKDF, implemented with Open Quantum Safe liboqs on a Raspberry Pi 4B gateway. Over 500 runs, the post-quantum handshake (Steps 1-6) completes in 2.48 ms, 0.38 ms slower than classical baseline, with PQC computation around 8% of handshake time at 20 ms simulated round-trip network latency. The gateway sustains 443 sessions/second, 100% success under 32 concurrent connections, extrapolating to 3546 sessions/second on a 32-core cloud instance. Five side-channel tests, including verified in-place session-key zeroization and a fixed-vs-random TVLA timing analysis, found no exploitable timing leakage or susceptibility to man-in-the-middle attacks. The architecture is vendor-agnostic and becomes unnecessary once vendors adopt NIST PQC natively.

1. Introduction

Long-lived smart HVAC controllers remain exposed to quantum-vulnerable TLS, while their hardware and update constraints make on-device post-quantum cryptography impractical. The paper proposes a vendor-independent PQC proxy that leaves the device, firmware, and vendor cloud unchanged.

Introduction

  • 10–15-year HVAC lifespans extend legacy controllers into the quantum-threat era, where Shor’s algorithm threatens RSA and ECDH and HNDL can expose captured traffic retroactively.The passage notes that devices purchased today may operate into the 2030s and 2040s.Source: §1 · pp. 1–2
  • On ESP32-S3, ML-KEM-768 needs 900 KB for key generation versus 339 KB free heap, while ECDH-P256 takes 111.93 ms versus 0.032 ms for hardware-accelerated AES-128.The passage reports that malloc(900 KB) fails and concludes that asymmetric cryptography needs to be offloaded from the device.Source: §1 · pp. 2–3
  • Prior MQTT PQC proposals require endpoint changes, while gateway benchmarks omit legacy integration; none combines non-invasive HVAC integration, vendor independence, and empirical validation.The paper positions its ESP32-S3 measurements as extending earlier work to the hardware class used in HVAC.Source: §1 · p. 2
  • The proposed proxy uses ML-KEM-768, ML-DSA-65, and HKDF-derived AES-256-GCM session keys on a Raspberry Pi 4B, without changing the HVAC device, firmware, or vendor cloud.The prototype uses Open Quantum Safe liboqs and follows NIST FIPS 203 and FIPS 204.Source: §1 · p. 2
  • A Steps 1–6 handshake adds 0.38 ms of overhead, with network RTT dominating under all realistic conditions.The paper reports benchmarking ML-KEM-512/768/1024 and ML-DSA-44/65/87 against ECDH-X25519 and Ed25519 across five operations, over 500 runs each.Source: §1 · p. 3
  • The four-core Raspberry Pi 4B gateway sustains 443 sessions per second and 100% success under 32 concurrent connections, with a 3,546 sessions-per-second extrapolation for a 32-core cloud instance.Memory growth is 60 KB over 500 sequential sessions, below the leakdetection threshold.Source: §1 · p. 3
  • Five side-channel tests cover in-place session-key zeroization, ML-DSA-65 impersonation blocking, nonce collisions, timing consistency against AES-256-GCM, and fixed-vs-random TVLA leakage on decapsulation.The passage identifies these as empirical tests conducted on the architecture.Source: §1 · p. 3

2. Related Work

Prior work establishes that PQC is practical on gateway-class hardware but constrained by microcontroller resources and often assumes modifiable endpoints. The identified gap is a real-hardware, vendor-independent HVAC proxy that leaves both the device and vendor cloud unchanged.

2.1. PQC Performance on Constrained and Gateway Hardware

  • Gateway-class devices run PQC with low overhead, while microcontroller-class devices face memory barriers that worsen at higher security levels.Prior benchmarks include submillisecond ML-KEM and ML-DSA operations on Raspberry Pi 4B hardware and an ML-KEM-512 exchange in 35.7 ms on an RP2040 with 264 KB SRAM. Other studies report practical constrained-IoT integration [21], TLS energy results dependent on device role and authentication mode, and up to 1.84× Kyber encapsulation speedup with ESP32 dual-core execution and coprocessor offload.Source: §2.1 · p. 3

2.2. Quantum-Resistant IoT Communication Protocols

  • Existing quantum-resistant MQTT approaches require endpoint updates, whereas this HVAC setting cannot modify either the controller firmware or vendor cloud.Varanasi evaluates six PQC KEMs across 4,608 MQTT configurations but also assumes updateable endpoints; a broader IoT survey identifies ML-KEM as a practical choice based on performance and key sizes.Source: §2.2 · pp. 3–4

2.3. PQC for Industrial and Medical IoT

  • Industrial and medical IoT studies demonstrate gateway-layer PQC feasibility or offloading, but do not address a transparent proxy before an unchanged HVAC vendor cloud.Related work identifies memory and side-channel resistance as key deployment constraints and recommends gateway-mediated security for devices that cannot be updated.Source: §2.3 · p. 4

2.4. Smart Home Security and HVAC Architectures

  • Smart-home research identifies vendor heterogeneity, classical-TLS reliance, and limited firmware updates as security liabilities, while prior gateway proposals lack a specific HVAC implementation.Surveys and architecture work discuss edge or gateway tiers for offloading cryptography from constrained devices.Source: §2.4 · p. 4

2.5. PQC Migration Strategies and Standardisation

  • NIST finalized ML-KEM and ML-DSA in August 2024, while migration guidance, EU update obligations, TLS benchmarks, and liboqs foundations frame PQC deployment.Federal migration is outlined for 2035, and the EU Cyber Resilience Act requires lifecycle security-update mechanisms from 2027. TLS handshake overhead is reported to depend mainly on larger keys and signatures rather than gateway computation; liboqs is provided by Open Quantum Safe, and ML-KEM’s predecessor rests on structured-LWE assumptions [32].Source: §2.5 · p. 4

2.6. Research Gap

  • No existing work simultaneously leaves the HVAC device and vendor cloud unchanged, requires no vendor cooperation, and empirically evaluates a real-hardware implementation and device-side infeasibility.Table 1 summarizes the comparison with related work.Source: §2.6 · p. 5, Table 1 · p. 5

3. Background

The background motivates PQC migration by outlining the quantum threat to long-lived classical cryptography, identifying the NIST standards used, and locating TLS in the cloud-mediated HVAC communication path.

3.1. Quantum Threat to Asymmetric Cryptography

  • Shor’s algorithm threatens RSA and ECDH, while harvest-now-decrypt-later collection puts long-lived systems at risk before quantum computers arrive.NIST IR 8547 sets 2030 deprecation and 2035 disallowance deadlines for these algorithms in federal systems; Grover’s quadratic speedup for unstructured search can be addressed by doubling symmetric key lengths and hash sizes.Source: §3.1 · p. 5

3.2. NIST Post-Quantum Cryptography Standards

  • NIST published post-quantum standards in August 2024, and this work uses ML-KEM-768 and ML-DSA-65 at NIST Level 3.FIPS 203 defines ML-KEM, with ML-KEM-512, -768, and -1024 at Levels 1, 3, and 5; FIPS 204 defines ML-DSA, while FIPS 205 specifies hash-based SLH-DSA independent of lattice assumptions.Source: §3.2 · pp. 5–6

3.3. Smart Home HVAC Communication Model

  • Smart HVAC control uses a four-tier cloud-mediated model in which the mobile app communicates with the vendor cloud over TLS, and the cloud relays commands to the controller.The controller does not communicate directly with the app; the proposed proxy targets the app–cloud TLS link, where migration can occur transparently, while the vendor cloud remains a custodian of commands and behavioral data.Source: §3.3 · p. 6

3.4. Implementation Platform and Libraries

  • The implementation uses liboqs 0.12 on a Raspberry Pi 4B gateway and benchmarks an ESP32-S3 representative of upper-end HVAC microcontrollers.liboqs provides constant-time ML-KEM and ML-DSA implementations with AArch64 optimizations and Python bindings. The Pi 4B has 4 GB RAM and a quad-core 1.8 GHz Cortex-A72; the ESP32-S3 has 380 KB SRAM, and its benchmarks use Arduino with mbedTLS for classical cryptography.Source: §3.4 · pp. 6–7

4. System Architecture

The architecture inserts a separately updatable PQC proxy between the mobile application and the unchanged vendor cloud and HVAC controller, without requiring changes to those systems. Quantum-safe protection is limited to the mobile-application–to-proxy link; the remaining path stays classical.

4.1. Design Principles

  • Non-invasive integration, vendor independence, and cryptographic agility motivate a dedicated proxy instead of adding PQC to the HVAC device, firmware, or vendor cloud.The proxy can be updated independently if NIST’s selected algorithms change.Source: §4.1 · p. 7

4.2. System Overview

  • The four-tier model places the PQC Layer between the mobile application and vendor cloud, while the cloud and HVAC controller remain unmodified.Traffic can be redirected by a one-time app endpoint configuration or, in a home-gateway deployment, a local DNS override without changing the app binary.Source: §4.2 · pp. 7–8
  • The PQC Layer secures only the mobile-application link; proxy-to-cloud and cloud-to-controller links retain classical protocols, avoiding the need for vendor cooperation or device access.This bounded scope targets the segment identified as most exposed to Harvest-Now-Decrypt-Later collection.Source: §4.2 · p. 7

4.3. Justification for a Separate PQC Layer

  • A separate PQC Layer avoids dependence on inaccessible proprietary vendor clouds and can serve multiple HVAC vendors while allowing algorithm updates without vendor or device changes.Vendor-embedded integration would require vendor cooperation and a separate implementation for each ecosystem.Source: §4.3 · p. 8
  • The proxy adds a potential single point of failure, so production deployment should use high-availability measures such as load balancing and geographic redundancy.The paper presents single-instance throughput and concurrent-session measurements as a baseline.Source: §4.3 · p. 8

4.4. Authentication and Key Establishment Flow

  • ML-KEM-768 establishes a fresh shared secret each session, and ML-DSA-65 authenticates the ephemeral key; the app verifies a pinned key before deriving an AES-256-GCM key with HKDF.The signature covers the handshake transcript, and the session nonce is used as the HKDF salt; the shared secret itself is never transmitted.Source: §4.4 · pp. 8–9
  • For command forwarding, the proxy decrypts and authenticates AES-256-GCM commands, checks per-session nonces against replay, and forwards them over existing classical TLS; responses return along the same path.An unclean proxy termination invalidates the nonce registry, requiring a fresh handshake; the HVAC device remains unaware of the PQC exchange.Source: §4.4 · p. 9, Figure 3 · p. 10

5. Implementation

The implementation uses a Raspberry Pi 4B PQC proxy with per-session ML-KEM-768 keys and ML-DSA-65 authentication, alongside a structurally matched classical baseline. It also isolates session state across threads and tests ESP32-S3 memory and classical-crypto capabilities without running liboqs on the device.

5.1. Implementation Stack

  • The PQC layer uses Python 3.13.5 with liboqs for ML-KEM-768 and ML-DSA-65, and Python cryptography for AES-256-GCM, HKDF, ECDH, and Ed25519.Raspberry Pi 4B benchmarks use 64-bit aarch64 Linux at a fixed 1800 MHz CPU frequency; algorithm parameters are centralized for benchmark scripts.Source: §5.1 · p. 10

5.2. PQC Proxy Implementation

  • The proxy generates a persistent ML-DSA-65 signing key and fresh per-session ML-KEM-768 keys, then decapsulates, signs the transcript, and derives session keys through HKDF.The per-session private key is discarded at session end, providing the described forward secrecy; timing measurements of the decapsulation path include all three operations.Source: §5.2 · p. 10
  • Mutable session-key buffers enable end_session() to zero every byte in place, while AES-256-GCM uses fresh 96-bit per-message nonces and a registry rejects reused nonces.The paper reports that Section 8.3 empirically verifies in-place zeroization.Source: §5.2 · pp. 10–11

5.3. Classical Baseline Implementation

  • The classical baseline substitutes X25519 and Ed25519 for ML-KEM-768 and ML-DSA-65 while matching the PQC proxy’s HKDF, AES-256-GCM handling, and timed-operation measurement code path.This mirrored structure enables comparison on equal terms.Source: §5.3 · p. 11

5.4. Thread Safety and Session Isolation

  • Concurrent benchmarks use one proxy instance per thread, sharing a read-only long-term ML-DSA-65 keypair while keeping session keys and nonce registries independent.Per-session state is not shared, avoiding races on session keys or nonce registries.Source: §5.4 · p. 11

5.5. ESP32-S3 Device Simulation

  • ESP32-S3 device-side infeasibility is assessed by testing allocation of the 900 KB ML-KEM-768 working-memory requirement against free heap and benchmarking AES-128 and ECDH-P256 with mbedTLS.The device checks distinguish a PQC-specific memory constraint from a general inability to perform classical cryptography; they do not run liboqs on the device.Source: §5.5 · p. 11

6. Experimental Setup

The experiments benchmarked the PQC gateway on a Raspberry Pi 4B and used an ESP32-S3 to represent controller constraints. The setup compared standardized PQC configurations with a classical baseline using controlled repeated runs, estimated energy from execution time, and varied network latency and concurrency.

6.1. Hardware Configuration

  • The Pi 4B ran a 64-bit aarch64 Linux kernel with its CPU fixed at 1800 MHz; device-side measurements used an ESP32-S3, and a workstation drove mobile-app simulations.The simulations supported end-to-end and network-latency benchmarks.Source: §6.1 · p. 11

6.2. Benchmark Methodology

  • Each configuration had 50 discarded warm-ups followed by 500 measured runs, spaced 10 ms apart; runs were aborted above 72°C, and latency summaries included mean, standard deviation, minimum, maximum, and 95th percentile.Measurements used raw nanosecond-resolution timestamps.Source: §6.2 · pp. 11–12

6.3. Energy Estimation Model

  • Energy per operation was estimated as execution time multiplied by fixed 0.6 W power, so the model captures duration-based differences but not power differences between equally long operations.The power estimate scaled a 0.5 W ARM Cortex-A72 reference at 1500 MHz to the Pi 4B’s 1800 MHz benchmark frequency; direct energy instrumentation was left for future work.Source: §6.3 · p. 12

6.4. Experimental Configurations

  • All three ML-KEM/ML-DSA security-level pairs were compared with ECDH-X25519/Ed25519; ML-KEM-768/ML-DSA-65 was used for broader evaluations across simulated network latency and concurrent sessions.Tested round-trip latencies were 0, 20, 50, 100, and 250 ms; concurrency levels were 1, 2, 4, 8, 16, and 32 threads. Side-channel sample sizes were reported with their individual results.Source: §6.4 · p. 12

7. Evaluation Results … 7.4. Network Latency Impact

Across 500-run measurements, the ML-KEM-768 handshake averaged 2.48 ms versus 2.10 ms for the classical ECDH baseline, while realistic network latency dominated total handshake time.

7.1. Individual Operation Latency

  • ML-KEM operations at all three security levels averaged under 0.55 ms, decapsulation was fastest, and ML-DSA signing dominated handshake time.Signing was the most expensive operation in every ML-DSA configuration, at roughly twice the corresponding KEM operation cost.Source: §7.1 · p. 12

7.2. Cryptographic Artifact Sizes

  • The handshake transmitted an ML-KEM-768 public key of 1,184 bytes, a 1,088-byte ciphertext, and an ML-DSA-65 signature of 3,309 bytes.These artifacts are sent in handshake Steps 2, 3, and 5, respectively.Source: §7.2 · p. 12

7.3. Full Handshake Latency

  • 2.48 ms was the average ML-KEM-768 handshake latency, 0.38 ms slower than the 2.10 ms classical ECDH baseline.The comparison covers the complete handshake (Steps 1–6) over 500 runs.Source: §7.3 · p. 12
  • The measured 2.48 ms handshake was roughly 3.2× faster than the earlier 8.04 ms literature-derived estimate.The earlier estimate summed primitive timings without accounting for scheduling, object construction, and measurement conditions in the complete implementation.Source: §7.3 · p. 13

7.4. Network Latency Impact

  • At 0 ms RTT, total latency was 2.87 ms, close to the 2.48 ms handshake latency, with the difference attributed to session setup overhead in the network benchmark loop.The passage describes the comparison as part of the simulated network RTT benchmark.Source: §7.4 · p. 13
  • At 20 ms RTT, PQC computation accounted for approximately 8% of the 43.52 ms total, as network latency dominated.The passage identifies 20 ms RTT as representative of typical home broadband.Source: §7.4 · p. 14

7.5. Energy Estimation … 7.9. ESP32-S3 Device-Side Infeasibility

The evaluation reports gateway throughput and concurrency results, estimates energy from execution time rather than measuring it independently, and finds ML-KEM-768 key generation infeasible on the ESP32-S3 because of its memory requirement. Memory remained stable under sustained sequential load, while higher session demand is better served by scaling across gateway instances.

7.5. Energy Estimation

  • Energy is estimated at 1.486 mJ for the ML-KEM-768 handshake versus 1.259 mJ for the classical baseline, derived from execution time under a constant-power model.The energy figures are not independent measurements or findings beyond the latency data.Source: §7.5 · p. 14

7.6. Sequential Throughput and Scalability

  • 443.3 sessions per second were sustained across 500 sequential Raspberry Pi 4B sessions, with a mean per-session latency of 2.22 ms.The measurement showed 60 KB of memory growth and no detected leak; the projected cloud throughput is covered separately.Source: §7.6 · p. 14
  • Approximately 3,546 sessions per second are projected for a 32-core cloud instance under an assumption of linear per-core scaling.Actual cloud throughput would also depend on network I/O and load balancing, which were not modelled.Source: §7.6 · p. 14

7.7. Concurrent Session Performance

  • Every tested concurrency level from 1 to 32 simultaneous session threads achieved 100% session success, with no failures.Throughput peaked at 887.9 sessions per second at 4 threads, matching the Pi 4B’s 4 physical cores, then declined as additional threads competed for those cores; the authors recommend scaling across gateway instances.Source: §7.7 · p. 15

7.8. Memory Stability Under Load

  • After 500 sequential sessions, process memory grew by 60 KB, from 31,942 KB to 32,002 KB, below the 5 MB potential-leak threshold; no leak was detected.The result depends on session-key zeroization, which prevents keys from accumulating in memory across sessions.Source: §7.8 · p. 15

7.9. ESP32-S3 Device-Side Infeasibility

  • ML-KEM-768 key generation requires 900 KB of working memory, exceeding the ESP32-S3’s 339 KB of free heap; a direct 900 KB allocation fails.The device has 380 KB of total SRAM. It runs AES-128 encryption in 0.032 ms and ECDH-P256 key generation in 111.93 ms, indicating that the memory constraint is specific to ML-KEM-768 and that the supported classical asymmetric operation is slow on this hardware.Source: §7.9 · p. 16

8. Security Analysis

The analysis evaluates a network-level quantum-capable adversary and reports four passing side-channel tests on the proxy’s actual decapsulation path. Its conclusions are scoped to timing analysis and the stated threat model, with power and electromagnetic analysis left to future work.

8.1. Threat Model

  • The adversary may record traffic on both links and actively intercept or substitute messages on the app-to-proxy link, but lacks physical access and cannot break Module-LWE.Cloud-throughput extrapolation assumes linear per-core scaling; actual throughput depends on network I/O and load balancing.Source: §8.1 · pp. 16–17

8.2. Security Properties

  • ML-DSA-65 binds the nonce, ML-KEM public key, and ciphertext to the proxy’s signing identity, preventing acceptance of a substituted-key transcript.Without this authentication, an attacker could substitute a key and establish separate sessions with the application and proxy.Source: §8.2 · p. 17

8.3. Practical Side-Channel Analysis

  • All four pass/fail side-channel tests pass on the implementation’s actual PQCProxy.decapsulate() path, rather than on the liboqs primitive in isolation.The evaluation also includes a descriptive timing comparison, which is not a pass/fail test.Source: §8.3 · p. 17
  • Memory forensics found no nonzero bytes at the session-key buffer’s address after end_session(), verifying in-place key zeroization.The test inspected the exact buffer address rather than searching process memory for a copied key.Source: §8.3 · p. 18
  • An attacker recovered the shared secret after substituting an ML-KEM public key but could not forge a valid ML-DSA-65 signature, so verification rejected the session.Signature verification raised ValueError, as intended by the protocol.Source: §8.3 · p. 18
  • 10,000 generated random 96-bit nonces had zero collisions, consistent with a 6.310 × 10−22 birthday-bound collision probability.This supports the replay-resistance mechanism’s practical robustness against nonce reuse in the test.Source: §8.3 · p. 18
  • At t = −0.268, fixed-versus-random timing showed no detected leakage, below the ±4.5 threshold using Welch’s t-test methodology.The comparison used the actual decapsulation path and pregenerated random-group inputs to avoid timing object construction.Source: §8.3 · p. 18
  • The decapsulation path had a lower coefficient of variation than AES-256-GCM in the same run, but this is only a sanity check, not a security claim.The comparison is descriptive because operating-system timing noise affects both measurements; timing leakage conclusions rely on TVLA instead. Power and electromagnetic analysis was unavailable and remains future work.Source: §8.3 · pp. 18–19

9. Discussion

The discussion reports a full-protocol measurement below the earlier estimate, identifies classical asymmetric-cryptography slowness as a present device constraint, and frames the proxy as an interim migration layer until vendor-native PQC is adopted.

9.1. Performance vs Prior Estimates

  • 2.48 ms measured full-protocol latency was roughly one-third of the earlier 8.04 ms estimate based on summed isolated primitive timings.Summing corresponding primitive timings from the authors’ own measurements gives approximately 2.98 ms; warm caches, persistent long-term keys, and connection reuse likely help explain the difference. The authors caution that primitive-level estimates remain provisional until confirmed by a full implementation.Source: §9.1 · p. 21

9.2. The ECDH-on-Device Finding

  • 111.93 ms ESP32-S3 ECDH-P256 key generation is roughly two orders of magnitude slower than on the Raspberry Pi 4B, exposing a present-day constraint beyond PQC memory limits.ML-KEM-768 needs 900 KB while the device has 339 KB free; the proposed proxy offloads all asymmetric cryptography, not only post-quantum operations.Source: §9.2 · pp. 21–22

9.3. Deployment Considerations

  • 443.3 sessions per second and 100% success across 32 concurrent sessions show a single Raspberry Pi 4B has substantial headroom for household deployment.For cloud-hosted service, the reported results support scaling horizontally across gateway-class instances rather than adding threads beyond a device’s core count.Source: §9.3 · p. 22

9.4. Migration Strategy and Regulatory Alignment

  • The interim, non-invasive proxy addresses the regulatory and device-lifecycle gap without vendor cooperation and can be decommissioned once a vendor adopts ML-KEM natively.Neither NIST IR 8547 nor the EU Cyber Resilience Act currently addresses legacy consumer HVAC devices specifically, while firmware-level migration is not a near-term option for already-deployed hardware.Source: §9.4 · pp. 22–23

10. Limitations and Future Work

The study identifies methodological limits in energy estimation, side-channel scope, device infeasibility testing, hardware and load coverage, and simulated vendor-cloud validation. Future work proposes additional migration, authentication, verification, and implementation studies.

10.1. Methodological Limitations

  • Energy results use a constant-power estimate rather than direct measurement, which cannot distinguish power draw for operations of similar duration.An in-line current sensor on the Raspberry Pi 4B supply could measure energy directly.Source: §10.1 · p. 23
  • Side-channel analysis covers timing only; power and electromagnetic testing with dedicated instrumentation is needed to assess those channels and determine constant-time behavior.The proposed instrumentation would be applied to the same decapsulation path evaluated in this study.Source: §10.1 · p. 23
  • ESP32-S3 infeasibility was established through memory allocation and separately timed classical operations, not a full liboqs execution attempt on the device.The test demonstrates ML-KEM-768 key-generation memory requirements cannot be allocated, but does not show how far execution would proceed or whether memory optimization could narrow the gap.Source: §10.1 · p. 23
  • Benchmarks use one Raspberry Pi 4B and one ESP32-S3 board; testing covered 500 sequential sessions and up to 32 concurrent threads, not multi-day or multi-week stability.Other ARM-class gateways and x86-based home servers were not evaluated; longer runs could reveal gradual memory or performance drift.Source: §10.1 · p. 23
  • The PQC Layer-to-vendor-cloud link was represented by simulated network latency rather than a live commercial-cloud connection, leaving that segment validated by simulation.Vendor infrastructure is proprietary and inaccessible for independent academic testing under the non-invasive design constraint.Source: §10.1 · pp. 23–24

10.2. Future Work

  • Future work proposes hybrid ML-KEM-768/X25519 exchange, device-side authentication and credential rotation, formal verification, and a compiled-language reimplementation.The hybrid configuration would require remeasuring computation and key material; formal verification could complement empirical security analysis, while compiled code could separate cryptographic latency from Python overhead.Source: §10.2 · p. 24

11. Conclusions

The paper evaluates a non-invasive proxy that adds post-quantum cryptography to legacy smart HVAC systems without changing devices, firmware, or vendor infrastructure. Its measured handshake overhead is small, while the proxy remains an interim strategy that depends on a trusted gateway and can be retired when vendors adopt NIST post-quantum standards.

Conclusions

  • The proxy addresses legacy-device constraints: an ESP32-S3 has 339 KB of available heap against ML-KEM’s 900 KB requirement, and needs 111.93 ms for ECDH.Inserted between the mobile application and vendor cloud, the proxy requires no changes to the HVAC device, its firmware, or vendor infrastructure.Source: §11 · p. 24
  • Over 500 Raspberry Pi 4B runs, the complete ML-KEM-768/ML-DSA-65 handshake added 0.38 ms over the classical baseline; commodity hardware sustained 443 sessions per second.No memory leak was detected under sustained load.Source: §11 · p. 24
  • Four independent side-channel tests found no exploitable timing leakage, verified in-place session-key zeroization, and confirmed ML-DSA-65 blocks man-in-the-middle impersonation.The fixed-versus-random TVLA analysis tested the architecture’s actual decapsulation path.Source: §11 · p. 24
  • The trusted-proxy assumption is the architecture’s main limitation, and the authors frame it as an interim migration strategy that can be deployed without vendor cooperation.It is designed to be decommissioned once HVAC vendors natively adopt NIST post-quantum standards.Source: §11 · pp. 24–25
Loading 2609.27828v1…