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

cs.CRAug 19, 2026

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

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

Organizations: Islamic University of Technology, Gazipur, Bangladesh · Laurentian University, Sudbury, ON, Canada · Centennial College, Toronto, ON, Canada

Abstract

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.

Figures & tables

Work	No Device	No Cloud	Vendor	HVAC	PQC	Empirical
	Change	Change	Agnostic	Domain	Standard	Validation
Malina et al. 17	$\times$	$\times$	$\sim$	$\times$	✓	$\sim$
Varanasi 36	$\times$	$\times$	✓	$\times$	✓	✓
Chhetri 6	✓	✓	✓	$\times$	✓	✓
Fitzgibbon & Ottaviani 9	✓	✓	✓	$\times$	✓	✓
Shahid et al. 32	$\times$	$\times$	$\sim$	$\times$	✓	✓

Table 1: Comparison of related work. Symbols: ✓= addressed,

\times

= not addressed,

\sim

= partially addressed.

Panel of Figure 1 — Figure 1: Proposed four-tier system architecture. The PQC Layer terminates the quantum-safe session with the Mobile App using ML-KEM-768 and ML-DSA-65. All downstream components remain unmodified.

Panel of Figure 2 — Figure 2: Post-quantum handshake flow (Steps 1–6). The PQC Layer generates a fresh ML-KEM-768 session keypair per session. The ML-DSA-65 signature authenticates that ephemeral key to the Mobile Application via a pre-installed pinned verification key. Command forwarding is shown in Figure 3 .

Panel of Figure 3 — Figure 3: Command forwarding phase (Steps 7–9). The PQC Layer decrypts the AES-256-GCM command, re-encrypts it over the existing classical TLS session, and forwards it to the Vendor Cloud, which relays it to the HVAC Device via the existing vendor protocol. The HVAC Device is unaware of the PQC exchange in Figure 2 .

Config	Op	Mean (ms)	Std	P95	Energy (mJ)
ECDH-X25519 $+$ Ed25519	keygen	0.3300	0.0865	0.5618	0.198015
	exchange	0.5950	0.0929	0.8219	0.356998
	sign	0.2835	0.0679	0.4620	0.170113
	verify	0.4434	0.0735	0.6371	0.26603
ML-KEM-512 $+$ ML-DSA-44	keygen	0.4631	0.1553	0.8474	0.277844
	encap	0.4535	0.1423	0.8202	0.272124

Table 2: Mean operation latency (ms) and estimated energy (mJ) on Raspberry Pi 4B. Values: mean

\pm

std (500 runs, 50 warm-up, CPU at 1800 MHz).

Figure 4: Mean operation latency by configuration, corresponding to Table 2 .

Figure 5: Estimated energy per operation by configuration, corresponding to Table 2 .

Config	PK (B)	CT (B)	SS (B)	Sig (B)
ML-KEM-512 $+$ ML-DSA-44	800	768	32	2420
ML-KEM-768 $+$ ML-DSA-65	1184	1088	32	3309
ML-KEM-1024 $+$ ML-DSA-87	1568	1568	32	4627

Table 3: Public key, ciphertext, shared secret, and signature sizes (bytes).

Config	Phase	Mean (ms)	Std	P95	Energy (mJ)
ECDH baseline	Handshake (Steps 1–6)	2.0987	0.4578	2.9963	1.259242
	Cmd encrypt	0.0790	0.0286	0.1334	0.047379
	Cmd decrypt	0.0369	0.0076	0.0496	0.022154
ML-KEM-768 proxy	Handshake (Steps 1–6)	2.4765	0.7659	3.9971	1.485922
	Cmd encrypt	0.0909	0.0398	0.1803	0.054524
	Cmd decrypt	0.0427	0.0160	0.0703	0.025628

Table 4: Post-quantum handshake latency (Steps 1–6) and command round-trip (500 runs, long-term DSA keypair persists across sessions).

Figure 6: Full handshake latency, ECDH baseline versus ML-KEM-768 proxy, corresponding to Table 4 .

RTT (ms)	Mean (ms)	P95 (ms)	Energy (mJ)
0	2.870	4.340	1.721997
20	43.517	44.655	26.109944
50	103.599	104.588	62.159098
100	203.628	204.989	122.177007
250	503.705	504.704	302.223219

Table 5: ML-KEM-768 handshake latency under simulated network RTT (500 runs each, 4 one-way hops simulated).

Figure 7: Handshake latency versus simulated network round-trip time, corresponding to Table 5 .

Deployment Scenario	Sessions / Second
Raspberry Pi 4B (1 core)	110.8
Raspberry Pi 4B (4 cores)	443.3
Cloud instance (8 cores)	886.6
Cloud instance (32 cores)	3546.4

Table 6: Extrapolated ML-KEM-768 proxy throughput for deployment scenarios. Based on measured Pi 4B performance, assuming linear per-core scaling.

Figure 8: Extrapolated throughput across deployment scenarios, corresponding to Table 6 .

Threads	Success (%)	Mean lat. (ms)	Max lat. (ms)	Sessions/s
1	100.0	4.07	4.07	160.7
2	100.0	3.34	3.43	473.6
4	100.0	3.06	3.45	887.9
8	100.0	7.41	10.32	358.2
16	100.0	10.55	17.35	444.5
32	100.0	13.92	23.87	303.6

Table 7: ML-KEM-768 proxy performance under concurrent load (Raspberry Pi 4B).

Figure 9: Throughput and latency versus concurrent thread count, corresponding to Table 7 .

Figure 10: Process memory at the start and end of 500 sequential sessions.

Hardware		Classical Cryptography		Post-Quantum Cryptography
Metric	Value	Operation	Latency	Metric	Value
Platform	ESP32-S3	AES-128	0.0320 ms	ML-KEM-768 memory	900 KB
CPU frequency	240 MHz	ECDH-P256	111.9270 ms	malloc(900 KB)	FAILED
Total SRAM	380 KB			ML-KEM-768 feasible	No
Free heap	339 KB

Table 8: ESP32-S3 memory feasibility for ML-KEM-768 and classical cryptography timing, including classical timing results and memory allocation failure.

Figure 11: ESP32-S3 free heap versus ML-KEM working memory requirements by security level, corresponding to Table 8 .

Property	Mechanism	Guarantee
Quantum-safe key establishment	ML-KEM-768 20	Shared secret protected under Module-LWE
Per-session forward secrecy	Fresh keypair per session 20	Past sessions remain unrecoverable
Entity authentication	ML-DSA-65 21	PQC Layer identity authenticated
Message confidentiality	AES-256-GCM 18	Commands remain confidential
Message integrity	AES-256-GCM GHASH tag 18	Ciphertext modification detected
Replay resistance	GCM tag $+$ per-session nonce registry	Replay attempts detected and rejected

Table 9: Security properties of the proposed architecture.

Test	Key Result	Status
Memory Forensics	Session key not found post-zeroization	✓
MITM Attack Simulation	ML-DSA-65 raised ValueError, forgery blocked	✓
Nonce Collision Test	10,000/10,000 unique, $P=6.310\times 10^{-22}$	✓
TVLA Fixed-vs-Random	$t=-0.268$ (threshold $\pm 4.5$ )	✓

Table 10: Side-channel analysis results. Memory forensics, MITM, nonce, and TVLA tests follow documented methodologies; AES-GCM timing comparison in Table 11 is descriptive.

Operation	Mean (ms)	CV (%)
AES-256-GCM (baseline)	0.1377	80.68
PQCProxy.decapsulate()	1.2326	38.80

Table 11: Timing variability of the decapsulation path and AES-256-GCM baseline (5,000 samples each). Descriptive comparison, not a pass/fail test.

Figure 12: TVLA fixed-versus-random decapsulation timing and coefficient of variation relative to the AES-256-GCM baseline, corresponding to Table 10 and Table 11 .

Cybersecurity

Cybersecurity develops methods to protect digital and cyber-physical systems from attacks, vulnerabilities, data loss, and misuse.

See all 355 papers

Securing Edge & Physical AI: Post-Quantum IoT Blockchain for Mission-Critical Cyber-Physical Agents
Oct 24, 2026Kürşat Çakal, Suat ÖzdemirCPS Security Multi-Agent System Security
Department of Computer Engineering, Hacettepe University, Ankara, 06800 Turkey
Quantum Cryptanalysis on IBM Quantum Hardware: Extending Even--Mansour Period Recovery from $N=4$ to $N=10$
Jul 20, 2026Taebong Kim, Youngsik Hong, Minsik Kim +4
VIDRAFT AI Research · QuantumOS, Seoul, Republic of Korea
Blockchain Infrastructure for Intelligent Cyber--Physical--Social Systems:Post-Quantum Security, Interoperability, and Trustworthy Data Economies in the Era of Embodied AI
Jun 5, 2026Song Guo, Huawei Huang, Dongping Liu +2Post-Quantum Cryptography
Hong Kong University of Science and Technology · Sun Yat-sen University · Amazon Web Services +1

Oct 24, 2026J/K move · Enter open · S save

Securing Edge & Physical AI: Post-Quantum IoT Blockchain for Mission-Critical Cyber-Physical Agents

Kürşat Çakal, Suat Özdemir

Department of Computer Engineering, Hacettepe University, Ankara, 06800 Turkey

CPS Security Multi-Agent System Security Post-Quantum Cryptography Edge Computing

Open paper AskPDF arXiv

Distributed Cyber-Physical Systems (CPS) and Edge AI networks increasingly depend on public-key authentication and key-establishment mechanisms that are vulnerable to cryptographically relevant Quantum Computers (QC). Shor's algorithm threatens widely deployed asymmetric primitives, while Grover's algorithm reduces the effective security margins of symmetric and hash-based mechanisms. Although Post-Quantum Cryptography (PQC) provides a migration path, its larger public keys, ciphertexts, and signatures introduce additional computation, memory, communication, storage, and packet-fragmentation costs that can constrain dynamic multi-agent systems. In this article, we introduce rotational secrecy, an architectural objective that limits temporal key exposure through authenticated transitions between cryptographic epochs. We present Private Authentication for Rotational Secrecy (PARS), a reference mechanism that coordinates policy-triggered key establishment, rotation, and reconciliation among authorized Physical AI agents. For deployments that need distributed agreement on security state, we further develop the PARS-Enabled Edge Security Ledger (PARS-ESL), an optional permissioned architecture maintained by authorized validators or capable edge gateways. PARS-ESL does not store high-volume operational transactions. Instead, it records authenticated state for key epochs, group membership, revocation, algorithm-suite policies, challenge validation, and recovery checkpoints. As a result, resource-constrained agents can take part as lightweight clients, and low-latency operational traffic stays outside the ledger consensus path, protected by the currently active symmetric epoch keys. Our results show that ledger-assisted post-quantum key-epoch management is feasible for selected Edge AI and CPS security-control workloads under the stated trust, compromise, connectivity, and resource assumptions.

Abstract

Cybersecurity

Explore similar work

Securing Edge & Physical AI: Post-Quantum IoT Blockchain for Mission-Critical Cyber-Physical Agents

Quantum Cryptanalysis on IBM Quantum Hardware: Extending Even--Mansour Period Recovery from N=4N=4N=4 to N=10N=10N=10

Blockchain Infrastructure for Intelligent Cyber--Physical--Social Systems:Post-Quantum Security, Interoperability, and Trustworthy Data Economies in the Era of Embodied AI

Quantum Cryptanalysis on IBM Quantum Hardware: Extending Even--Mansour Period Recovery from $N=4$ to $N=10$