Browser post-quantum encryption communication system based on ESP32 hardware isolation and implementation method

Abstract

The application discloses a browser post-quantum encryption communication system based on ESP32 hardware isolation and an implementation method, and belongs to the field of Web post-quantum security. The application automatically adapts a SIMD / scalar dual-version WASM post-quantum algorithm, shunts ML-KEM intensive operation by means of a Web Worker thread pool, and avoids browser main thread lag; a general ESP32 is connected through a Web Serial API, private key fragments are stored in a chip NVS, the firmware prohibits reading out of the private key in plaintext, and only the shared secret after unpacking is outputted externally; all messages are attached with ML-DSA signatures, HKDF-SHA-256 is adopted to derive an AES-GCM key to encrypt business data, and file support is provided for fragment confirmation and cross-connection breakpoint resume transmission; when a hardware link is abnormal, a software encryption mode is automatically switched to rebuild a session, and the application is suitable for weak network scenarios such as smart home gateways and remote operation and maintenance of industrial equipment.

Description

Technical Field

[0001] This invention relates to the fields of post-quantum cryptography communication and web security technology, and in particular to a hybrid post-quantum encryption system and method for resource-constrained browser environments that integrates WebAssembly operation scheduling, hardware key isolation, and recoverable transmission. Background Technology

[0002] With the development of quantum computing technology, Shor's algorithm can pose a threat to traditional public-key cryptosystems such as RSA and ECC. The "collect first, decrypt later" attack mode puts long-term confidential data at continuous risk. In 2024, NIST officially released the ML-KEM key encapsulation standard and the ML-DSA digital signature standard, marking the gradual transition of post-quantum cryptography from standard setting to engineering application.

[0003] Browsers are the most widely used terminal operating environment, but they are also constrained by the JavaScript main thread execution method, memory capacity, and differences in browser compatibility. Existing WebAssembly post-quantum algorithm implementations typically focus on providing cryptographic primitives; intensive computations may still consume the browser's main thread, and private keys are primarily stored in browser memory or persistent storage. While traditional USB keys and dedicated security chips can isolate keys, they often rely on proprietary drivers or middleware, making them difficult to directly access through general browser interfaces. Conventional encrypted web communication mainly relies on transport layer protection and has not yet simultaneously addressed application-layer post-quantum authentication, hardware private key isolation, and cross-connection file resuming issues.

[0004] Therefore, a hybrid hardware and software quantum encryption system is needed for resource-constrained browsers to address engineering challenges such as main thread blocking, private key exposure, and file transfer interruptions in weak network conditions without altering standard cryptographic algorithms. Currently, these three types of technologies have developed independently, addressing only individual technical pain points. They fail to propose an integrated collaborative architecture that combines browser background computation scheduling, general-purpose MCU hardware key isolation, and cross-connection resume download with quantum signatures, thus failing to simultaneously resolve the three engineering defects of interaction lag, private key leakage, and transmission errors in weak network conditions. Summary of the Invention

[0005] This invention mainly solves the following technical problems: The browser-side quantum cryptography intensive computation blocks the main thread, leading to increased page interaction latency. In pure software mode, the risk of private key exposure is high, while dedicated hardware has the problem of incompatibility with general browsers; In weak network environments, the transmission of post-quantum signed files is prone to interruption and lacks the ability to resume transmission across connections.

[0006] To address the aforementioned technical problems, this invention provides a browser-based quantum encrypted communication system with ESP32 hardware isolation. The system includes a browser-side software module, an ESP32 hardware coordination module, and a communication transmission module.

[0007] The browser-side software module includes a cryptographic computation unit, a worker scheduling unit, and a key management unit. The cryptographic computation unit contains two versions of the ML-KEM-768 and ML-DSA-44 WebAssembly modules: SIMD and scalar. At runtime, it detects the browser's SIMD support capabilities and automatically loads the corresponding version. The worker scheduling unit uses a Web Worker thread pool to offload intensive operations such as ML-KEM key generation, encapsulation, and decapsulation from the main thread, and sets request numbers, a 15-second timeout for key recycling, exception reconstruction, and main thread rollback mechanisms. The key management unit supports switching between software and hardware modes; in software mode, it derives keys using PBKDF2, encrypts the private key with AES-GCM, and stores it in IndexedDB; in hardware mode, it fragments the ML-KEM private key and sends it to external hardware storage.

[0008] The ESP32 hardware collaboration module uses an ESP32-WROOM-32E microcontroller and connects to the browser via a Web Serial API. The module sets up an NVS non-volatile storage partition, receives and persistently stores the ML-KEM private key written in fragments by the browser, and disables private key read commands in the firmware. Upon receiving the ciphertext from the browser, a task with its own stack space performs decapsulation within the chip, returning only 32 bytes of shared secret to the browser. The firmware provides reset cleanup and private key erase commands: reset cleanup only clears the temporary buffer in RAM while retaining the NVS private key, and the private key erase command clears the private key and digest from the NVS. When the hardware connection is interrupted or decapsulation times out, the system switches to software mode, generates a new key pair, and rebuilds the session.

[0009] The communication transmission module builds an application-layer communication protocol based on WebSocket and JSON format. Key exchange messages, message messages, and file messages are all included in the ML-DSA-44 signature field, with the signature covering the protocol identifier, session identifier, monotonic sequence number, timestamp, and business fields. Files are transmitted in fixed-size fragments, and the receiver returns an acknowledgment message for each fragment; after a connection interruption and recovery, transmission continues according to the acknowledged fragment sequence number.

[0010] The system takes the ML-KEM shared secret as input and derives a 256-bit AES-GCM session key through context-bound HKDF-SHA-256. The derivation process binds the protocol version, algorithm combination, session identifier, and information of the communicating parties, thus separating the keys for different sessions.

[0011] This invention also provides a method for implementing browser-based quantum encrypted communication based on ESP32 hardware isolation, comprising the following steps: S1 Capability Negotiation and Identity Registration: The two communicating parties establish a WebSocket connection, exchange protocol capability messages, register their respective ML-DSA-44 signature public keys, and verify the legality of the parameters; S2 Key Exchange and Session Establishment: The initiator uses the recipient's ML-KEM-768 public key to perform encapsulation, generate ciphertext and shared secret, and sign and send them; the recipient selects WASM software decapsulation or ESP32 hardware decapsulation according to the current mode to obtain the shared secret; after both parties verify the shared secret digest, they derive the AES-GCM session key through HKDF-SHA-256. S3 business data encrypted transmission: ordinary messages and file fragments are encrypted with AES-GCM and then sent with an ML-DSA-44 signature attached; the receiving end decrypts the data after the signature is verified, and each file fragment is confirmed one by one. S4 Error Recovery and Resumption: After a WebSocket disconnection, reconnection is performed using an exponential backoff strategy; after a file transfer is interrupted, transmission resumes from the most recently confirmed fragment sequence number; when the ESP32 hardware disconnects, software mode is switched and the session is rebuilt; S5 Key Rotation: When the ML-KEM key reaches the threshold of 30 minutes or 100 cumulative uses, a new key pair is generated, the storage is updated, and the key exchange is re-executed. Compared with the prior art, the present invention has the following beneficial effects:

[0012] By scheduling intensive post-quantum operations through the Worker pool, when continuously executing 1000 rounds of ML-KEM-768 key generation, encapsulation, and decapsulation tasks, the maximum additional latency of the event loop in the main thread SIMD mode is 126.7 ms, while that in the Worker SIMD mode is 1.6 ms, representing a latency reduction of 98.7%. At the same time, by combining SIMD with scalar automatic fallback and main thread degradation mechanisms, browser compatibility and operational continuity are improved.

[0013] It uses a general-purpose ESP32 to connect to the browser via the Web Serial API, requiring no proprietary driver; the firmware disables the private key readback command, so the browser cannot obtain the plaintext of the ML-KEM private key through the public serial port interface; when the hardware is disconnected, it can switch to software mode, balancing key isolation and communication availability.

[0014] This technology combines post-quantum signature authentication with cross-connection file retransmission. In a browser-side application layer network simulation environment with 1% packet loss and 100 ms latency, a 300 KB file can be completely reassembled, and a 700 KB file can continue to be transmitted after an active disconnection, avoiding the retransmission of acknowledged fragments.

[0015] The system does not modify the underlying standard cryptographic algorithm, focuses on the collaborative design of the Web-side engineering architecture, and can be directly reused in scenarios such as smart home gateways and industrial equipment maintenance, demonstrating strong engineering applicability. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the hybrid encryption and signature process of the present invention.

[0017] Figure 2 This is a graph showing the test results of memory overhead during the browser runtime phase of this invention.

[0018] Figure 3 This is a graph showing the performance test results of the ESP32 serial port fragmentation of this invention.

[0019] Figure 4 This is a diagram illustrating the layered deployment structure of smart home and industrial equipment scenarios in this invention. Detailed Implementation

[0020] The preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Those skilled in the art can fully reproduce the technical solution of the present invention based on the content described in this section.

[0021] This invention provides a hybrid quantum encryption system suitable for resource-constrained browser environments. The system employs a hybrid cryptographic architecture that combines ML-KEM-768 key encapsulation, ML-DSA-44 signature authentication, and AES-GCM data encryption. It integrates WebAssembly operation scheduling, ESP32 hardware key isolation mechanism, and WebSocket recoverable transmission mechanism to construct a complete end-to-end encrypted communication process. System Overall Architecture

[0022] The entire system is structured in three layers: the front-end interaction layer, the cryptography and scheduling layer, and the hardware and transport layer. The front-end interaction layer, built on HTML5 and JavaScript, is configured with a strict CSP security policy and is used to implement user interface, communication status display, identity management, file transfer, and operation auditing functions. The cryptography and scheduling layer includes a WASM cryptographic calculation module, a Worker scheduling module, a key management module, and an HKDF key derivation module. The ML-KEM-768 and ML-DSA-44 cryptographic algorithms are compiled into WebAssembly programs using the Emscripten toolchain. During compilation, -O3 optimization, modular loading, and dynamic memory expansion configuration are enabled. The compiled SIMD version includes the v128 instruction set; if the browser does not support SIMD instructions, the scalar version is automatically loaded. The hardware and transport layer includes an ESP32 hardware coordination unit and a WebSocket communication unit. The ESP32 hardware establishes a connection with the browser via a USB serial port, and is responsible for persistent storage of the private key and internal decapsulation and descrambling operations; the WebSocket communication unit implements message sending and receiving, automatic disconnection and reconnection, and file fragment retransmission functions. ESP32 Hardware Coordination Module Implementation

[0023] The hardware platform uses the ESP32-WROOM-32E main control chip, equipped with an Xtensa LX6 dual-core processor with a main frequency of 240MHz and 16MB of Flash storage. The firmware is developed based on the Arduino IDE and uses serial port commands to drive the transaction state machine, defining a total of 8 interactive commands: STORE_BEGIN, STORE_CHUNK, STORE_END, DECAP_BEGIN, DECAP_CHUNK, DECAP_END, RESET, and ERASE_KEY.

[0024] After the browser generates the ML-KEM-768 key pair locally, it splits the 2400-byte private key into 256-byte fragments and sequentially sends the STORE_BEGIN, fragment data, and STORE_END commands. The ESP32 verifies that the fragment sequence number, total data length, and SHA-256 digest all match, and then writes the private key to the NVS non-volatile partition for permanent storage. The RESET command only clears the in-memory private key cache, ciphertext cache, and shared secret cache, retaining the private key stored in the NVS partition; the ERASE_KEY command is used to clear all ML-KEM private keys and their corresponding digests within the NVS. The firmware at the underlying level blocks commands related to reading the private key, preventing the browser from obtaining the plaintext private key via the serial port interface. This hardware isolation scheme is only used to reduce the risk of XSS script attacks stealing the private key and does not require the ESP32 to have physical tamper-proof or anti-probe security capabilities.

[0025] After receiving the 1088-byte ciphertext from the peer, the browser fragments it into 256-byte segments and sends them to the ESP32. The chip reassembles the fragments and verifies the digest; if correct, it schedules a dedicated FreeRTOS task with a 64KB stack space to read the NVS private key and perform decryption. Upon completion, the private key, ciphertext, and shared secret caches in memory are automatically cleared, and only 32 bytes of the shared secret and the computation time are returned to the browser.

[0026] If Web Serial authorization fails, serial port opening fails, or private key fragmentation synchronization verification fails, the system automatically closes the serial port channel and reverts to IndexedDB software key mode. If the browser does not have a usable software private key, it regenerates the ML-KEM key pair and registers the public key. If the serial port is disconnected, decapsulation operation times out, or digest verification fails, the system clears the current session shared secret, switches to pure software encryption mode, generates a new public key, and initiates a new key exchange to avoid ciphertext decryption failure due to mismatch between the old and new keys. Worker scheduling and memory management mechanism

[0027] The Worker scheduling unit maintains 2-4 running Web Worker instances and uses a load balancing strategy to distribute ML-KEM intensive computation tasks. Each computation task is assigned a unique request number and a 15-second timeout timer is set synchronously. If a Worker process crashes abnormally or a task times out, the system destroys the failed instance and recreates it; if the entire thread pool becomes unavailable, the computation task is rolled back to the browser's main thread for execution.

[0028] The memory employs a buffer pre-allocation and reuse mechanism. The ML-KEM public key, private key, ciphertext, and shared secret buffer are allocated once during module initialization and reused cyclically using a mutex lock. Sensitive data in the buffer is cleared after each operation. The ML-DSA algorithm buffer reuses the same management logic; the message transmission buffer has an initial capacity of 4096 bytes, automatically doubling in size when insufficient. Communication protocols and file resume mechanisms

[0029] The system uses a custom PQC-CHAT / 3 application layer message protocol, carried over JSON format and a WebSocket channel. All business message signature fields include a protocol identifier, message type, session identifier, sender / receiver identifier, monotonically increasing sequence number, timestamp, and business data digest. The receiving end verifies the signature public key registration status, signature length, message time window (5 minutes before and after), and sequence number continuity; messages that fail verification are discarded.

[0030] File transfer employs a fragmentation mechanism, with each fragment carrying a fragment sequence number, a fragment digest, and a complete file digest. The receiving end immediately returns an acknowledgment message upon successful verification of each fragment. After connection loss and reconnection, both communicating parties verify the largest sequence number of the acknowledged fragment and resume transmission from the next fragment. All file fragments and fragment acknowledgment messages are appended with an ML-DSA digital signature. Key derivation and automatic rotation strategy

[0031] The session key is derived based on the HKDF-SHA-256 algorithm. Using the 32-byte shared secret output by ML-KEM-768 as the key input, the protocol identifier, algorithm combination identifier, session identifier, and the identities of both communicating parties are concatenated in a fixed order to generate the session context. A 32-byte salt value is generated by combining the salt usage tag, and an info parameter is generated by combining the key usage tag, ultimately deriving a 256-bit AES-GCM session key. A 12-byte initialization vector is randomly generated for each encryption, and the session identifier, message sequence number, and service type identifier are used as additional authentication data in the encryption verification.

[0032] ML-KEM keys have dual rotation thresholds; rotation is triggered when either of the following conditions is met: the key has been in continuous use for 30 minutes or a total of 100 messages / files have been sent / received. After key rotation is complete, the old session key is cleared, a new key pair is generated, and the key exchange process is re-executed. ML-DSA signature identities are managed independently and require manual rotation by the user after entering a password for confirmation. Performance and security verification testing

[0033] The test hardware platform uses a 12th generation Intel Core i5-12500H processor, Chrome version 150 browser, ESP32 running at a clock speed of 240MHz, and serial port baud rate of 115200bit / s.

[0034] Main thread latency test: After continuously executing 1000 complete ML-KEM operations, the maximum latency of the main thread SIMD mode event loop was 126.7ms, and the maximum latency of the Worker thread SIMD mode was 1.6ms, with a main thread blocking latency reduction of 98.7%. Hardware decapsulation test: The average time for individual decapsulation within the ESP32 chip was 8.999ms, and all shared secrets were matched in 50 rounds of repeated tests; the average time for a complete link transaction, including serial port fragmented transmission and reception and verification, was 336.903ms. File transfer resumption test: With browser application layer network simulation set to 1% packet loss and 100ms one-way latency, a 300,000-byte file could be completely reassembled, with a total time of 4487.29ms; a 700,000-byte file could be resumed after active disconnection, with a complete transmission time of 12415.27ms. Security boundary verification: In hardware mode, the browser cannot read the ML-KEM private key through the public serial port, and there is no attack path for XSS scripts to directly export the private key; based on the ProVerif symbolic cryptography model verification, the private key stored in the hardware partition meets the confidentiality security requirements. Actual deployment scenarios

[0035] In smart home gateway management scenarios, the browser management page relies on Worker scheduling to ensure smooth page interaction. The ESP32 hardware stores the gateway's ML-KEM private key and completes on-chip decapsulation. The segmented transmission mechanism is used for gateway firmware upgrades, configuration distribution, and operation audit log transmission.

[0036] In remote operation and maintenance scenarios for industrial equipment, ML-DSA signatures verify the legitimacy of operation and maintenance instructions and equipment log sources; ESP32 hardware key isolation reduces the risk of browser local private key leakage; cross-connection breakpoint resume transmission adapts to weak network environments in industrial sites and is used for stable transmission of equipment logs and firmware installation packages.

[0037] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Equivalent substitutions or simple adjustments made by those skilled in the art without departing from the core technical concept of the present invention are all within the scope of protection of the present invention.

Claims

1. A post-quantum encrypted communication system for resource-constrained browsers, comprising a browser WebAssembly cryptographic processing unit, an ESP32 hardware storage module, and a WebSocket communication unit; characterized in that, The browser-side software module includes a cryptographic computation unit, a worker scheduling unit, and a key management unit. The cryptographic computation unit integrates both SIMD and scalar versions of ML-KEM-768 and ML-DSA-44 WebAssembly modules. At runtime, it detects the browser's support for SIMD and automatically selects the corresponding version to complete key generation, encapsulation, decapsulation, signing, and verification operations. The worker scheduling unit uses a Web Worker thread pool to move ML-KEM cryptographic computation tasks off the browser's main thread for execution and includes request numbering, 15-second timeout recycling, exception reconstruction, and main thread rollback mechanisms. The key management unit supports both software and hardware modes. In software mode, it derives keys from passwords, encrypts private keys with AES-GCM, and stores them in the browser's IndexedDB. In hardware mode, it fragments the ML-KEM private key and sends it to the ESP32 storage. The ESP32 hardware collaboration module uses Web Serial... The API connects to the browser; the module has a built-in NVS storage partition and an independent decapsulation task. After receiving the ciphertext sent by the browser, it completes the ML-KEM-768 decapsulation within the chip and only returns the shared secret to the browser. The firmware disables the private key reading command; when the hardware connection is interrupted, the system switches to software mode and rebuilds the session; the communication transmission module implements quantum signature message transmission, automatic reconnection, and cross-connection file resume transmission based on the WebSocket protocol; key exchange messages, message messages, and file messages are all included in the ML-DSA-44 signature field. File transmission adopts a fragment sequence number, digest confirmation, and session reconstruction mechanism. After the connection is restored, transmission continues from the confirmed fragment position.

2. The browser-based quantum encrypted communication system with hardware isolation based on ESP32 as described in claim 1, characterized in that, The Worker scheduling unit is equipped with a reusable memory buffer. The public key, private key, ciphertext, and shared secret buffer for ML-KEM operations are allocated once during module initialization and reused cyclically under mutual exclusion protection. Sensitive data is cleared after the operation is completed. At the same time, a 5-minute memory idle cleanup timer is set.

3. The browser-based quantum encrypted communication system with hardware isolation based on ESP32 as described in claim 1, characterized in that, The ESP32 hardware collaboration module uses 256-byte fixed fragments to transmit the private key and ciphertext, and verifies the integrity of the reassembled data through SHA-256 digest verification. The decapsulation operation is performed by an independent task in isolation, and the private key, ciphertext and shared secret buffer are cleared after the operation is completed.

4. The browser-based quantum encrypted communication system with hardware isolation based on ESP32 as described in claim 1, characterized in that, The key management unit has a built-in ML-KEM key rotation mechanism, which triggers rotation according to a 30-minute time threshold or a cumulative 100 service transmission threshold, with the first one being used. After rotation, a new key pair is generated, the storage is updated, and the key exchange is re-executed.

5. The browser-based quantum encrypted communication system with hardware isolation based on ESP32 as described in claim 1, characterized in that, The signature field of the communication transmission module includes protocol identifier, message type, session identifier, sender, receiver, monotonic sequence number, timestamp, and service field; the receiver verifies the public key fingerprint, signature length, 5-minute time window, and sequence number continuity, and rejects duplicate, expired, and out-of-order messages; File chunked transfer supports resuming transfer from confirmed chunks after a disconnection, without needing to retransmit the entire file.

6. The browser-based quantum encrypted communication system with hardware isolation based on ESP32 as described in claim 1, characterized in that, The system uses HKDF-SHA-256 to derive the AES-GCM session key; taking the ML-KEM shared secret as input, it serializes the protocol identifier, algorithm identifier, session identifier, and communication information of both parties into a session context, and generates salt value and info parameter respectively, so that the derived key is bound to the protocol version, algorithm combination and session attributes.

7. The browser-based quantum encrypted communication system based on ESP32 hardware isolation according to claim 1, characterized in that, The ESP32 hardware collaboration module supports private key fragment writing, digest verification, restart persistence, reset cleanup, and private key erasure operations. The reset cleanup operation clears the private key receive buffer, ciphertext buffer, and shared secret buffer in RAM without affecting the persistent private key in the NVS partition. The private key erasure operation clears the ML-KEM private key and its digest stored in the NVS partition. In the official firmware state, the browser cannot read the plaintext ML-KEM private key via serial port.

8. The browser-based quantum encrypted communication system based on ESP32 hardware isolation according to claim 1, characterized in that, The browser-side software module is compatible with Chromium-based browsers and supports WASM SIMD and automatic rollback of scalar versions. Hardware mode is only enabled in browsers that support the Web Serial API; if the above conditions are not met, software mode will run.

9. The browser-based quantum encrypted communication system with hardware isolation based on ESP32 as described in claim 5, characterized in that, The cross-connection file resume mechanism supports fragment file reassembly and breakpoint resume in weak network environments with packet loss and transmission latency fluctuations, without having to retransmit confirmed fragment data.

10. A method for implementing browser-based quantum encrypted communication with hardware isolation based on ESP32, implemented using the system described in any one of claims 1 to 9, characterized in that, Includes the following steps: S1 Capability Negotiation and Identity Registration: The two communicating parties exchange capability messages via WebSocket and register their respective ML-DSA-44 signature public keys; S2 Key Exchange and Session Establishment: The initiator uses the receiver's ML-KEM-768 public key to encapsulate and generate ciphertext and a shared secret, and sends it; the receiver selects software or hardware mode to decapsulate and obtain the shared secret; both parties verify the shared secret digest through signed messages, and derive the AES-GCM session key using HKDF-SHA-256; S3 Encrypted Transmission of Business Data: Messages and file messages are encrypted with AES-GCM and then signed with ML-DSA-44 before transmission; files are sent in fragments, and the receiver confirms each fragment; S4 Error Recovery and Resumption: When the WebSocket connection is interrupted, it automatically reconnects according to the backoff strategy; After file transfer is interrupted, the transfer continues according to the confirmed fragment sequence number; when the ESP32 hardware is disconnected, the software mode is switched, a new key pair is generated and the session is rebuilt; S5 key rotation: when the time threshold or the number of uses threshold is reached, the ML-KEM key pair is updated and the key exchange is re-executed.

Images