An internet of things data transmission system and method based on quantum encryption communication

Abstract

The application relates to an Internet of Things data transmission system and method based on quantum encryption communication and belongs to the technical field of network and information security. The application comprises a client transparent agent module, a server front transparent gateway module and a quantum key service platform; the client agent realizes system-level application flow interception, uses a SIM card security element as a hardware trusted root, obtains plaintext by combining a dynamic man-in-the-middle technology, matches quantum encryption, applies for quantum session key encryption to the quantum key service platform, the server front transparent gateway module is based on the quantum key service platform to apply for quantum session key decryption and forwarding, and quantum session key distribution is realized through main and called key negotiation. The application can realize quantum session key automatic encryption and decryption of specified API interface data without modifying existing mobile application and service code, and has the advantages of zero invasion, high security, low time delay, easy operation and maintenance, low cost and the like.

Description

Technical Field

[0001] This invention belongs to the fields of network and information security, mobile terminal security, quantum session key distribution and application transparent proxy technology, and specifically relates to an Internet of Things data transmission system and method based on quantum encrypted communication. Background Technology

[0002] The statements in this section are merely background information relating to this disclosure and do not necessarily constitute prior art.

[0003] With the rapid development of quantum computing technology, traditional communication security systems based on public-key cryptography algorithms such as RSA and ECC are facing unprecedented disruptive threats. Quantum Session Key Distribution (QKD), as the only key generation method that has been rigorously mathematically proven to possess information-theoretical security, does not rely on computational complexity assumptions but is based on fundamental principles of quantum mechanics. Even if an attacker possesses unlimited computing power and a future general-purpose quantum computer, they will not be able to steal key information without being detected.

[0004] However, although quantum session key distribution has been engineered and deployed at the backbone network and data center interconnect (DCI) level, its implementation on the terminal side, especially in the access link between massive mobile smart terminals and cloud services, still faces serious obstacles. These obstacles are mainly reflected in the following aspects: First, the strong coupling of application code leads to high integration costs. Existing commercial quantum session key distribution solutions generally require client and server developers to explicitly call dedicated SDK interfaces to complete key application, encryption / decryption operations, session management, and other logic. This means that mobile apps need to manually inject encryption logic during the HTTP request construction phase and manually decrypt during the response parsing phase; the server needs to embed decryption middleware in the API gateway or business controller layer; and both parties must strictly adhere to the same key negotiation protocol and data encapsulation format. For large enterprises with hundreds of microservices and thousands of API endpoints, such transformations involve cross-departmental coordination, multi-version compatibility testing, and gray-scale release risk control, resulting in high integration costs. Furthermore, a large number of existing mobile applications cannot be frequently updated due to security modifications, and the consistency of encryption / decryption implementations by third-party developers is difficult to guarantee, easily creating security vulnerabilities. Therefore, a solution is needed that can automatically perform quantum session key encryption and decryption on specified interface traffic without modifying the application, while ensuring performance and user experience. Summary of the Invention

[0005] To solve the above-mentioned technical problems, or at least partially solve them, the present invention provides an Internet of Things data transmission system and method based on quantum encrypted communication.

[0006] This invention provides an Internet of Things (IoT) data transmission system based on quantum encrypted communication, comprising:

[0007] The trusted root and key management module deployed on the mobile terminal uses the SIM card security element as the trusted root to bind the traffic encryption and decryption security processing to the device's physical identity; it pre-fills the quantum session key or key application credential in the SIM card security element to support session key negotiation in calling / called mode;

[0008] A client-side transparent proxy module deployed at the application layer of a mobile terminal intercepts outbound network traffic from a preset application, parses the application layer protocol, and, when matching a preset encryption strategy, applies for a quantum session key based on the SIM card security element as a trusted root vector quantum key service platform. The quantum session key is then used to encrypt the request body data, and a new HTTP packet is formed by combining it with a request header containing an encrypted session identifier and forwarded.

[0009] A server-side transparent gateway module deployed in the business service cluster receives quantum-encrypted traffic from the client transparent proxy module, decrypts it to obtain a session identifier, extracts the session identifier, applies for the same quantum session key from the quantum key service platform, decrypts the quantum-encrypted traffic using the applied quantum session key, forwards it to the corresponding business service, and encrypts the response data of the business service matching the configuration file using the same quantum session key before returning it.

[0010] The quantum key service platform is used to coordinate key applications between the calling and called parties, issue consistent quantum session keys based on the service session identifier, and verify device identity with the SIM card security element.

[0011] The client-side transparent proxy module and the server-side front-end transparent gateway module are completely transparent to upper-layer applications and business services.

[0012] Furthermore, the trusted root and key management module deployed on the mobile terminal establishes a secure communication channel between the SIM card and the system by calling the OpenMobile API through zdxlzSKF.jar; it reads a customized file from the SIM card's EF file through the quantum SDK, and the customized file stores the device's unique identifier devUUID; it concatenates the device's unique identifier devUUID with the application package name to generate a binding key; it uses the binding key to encrypt the local key cache to prevent key theft under rooted devices; each time a key is requested, the SDK attaches a device fingerprint to the quantum key service platform, which is the MD5 hash of the bootloader version, baseband version, and device's unique identifier devUUID. The quantum key service platform compares the historical fingerprints to verify the device's identity, and refuses service if there are abnormal fluctuations.

[0013] Furthermore, the client-side transparent proxy module specifically includes:

[0014] The traffic redirection unit, based on the setHttpProxy interface of the VpnService in the terminal operating system, redirects the traffic of the specified target application to the local loopback address;

[0015] The local proxy service unit, based on the Netty framework, listens to the loopback address and uses HttpServerCodec to parse the application layer protocol in real time. It employs a dynamic man-in-the-middle mechanism to handle CONNECT requests and configures encryption / decryption processing pipelines for encryption and decryption transmission. When encryption is required, it constructs a random session identifier for the matching protected application. Using the session identifier, it calls the quantum SDK interface to initiate a caller key application to the quantum key service platform to obtain the quantum session key. After receiving the encrypted response from the server-side transparent gateway module, the local proxy server retrieves the quantum session key cache based on the session identifier, decrypts it using the quantum session key, and injects it into the original man-in-the-middle encryption / decryption processing pipeline before delivering it to the application.

[0016] Furthermore, the dynamic man-in-the-middle mechanism handles CONNECT requests and configures the encryption / decryption processing pipeline, including:

[0017] The initial encryption / decryption processing pipeline is initialized by mapping from HttpServerCodec to HttpObjectAggregator, and then to the dynamic man-in-the-middle handle MitmHandler; it is used to handle basic HTTP protocol parsing and capture CONNECT requests sent by the terminal.

[0018] When the dynamic man-in-the-middle handle MitmHandler of the initialized encryption / decryption processing pipeline receives a CONNECT request, it triggers the following actions to switch the encryption / decryption processing pipeline: Parses request.uri() to obtain the target hostname; calls the root management to construct a temporary domain name certificate for the target host in real time; writes back the CONNECT establishment response to the terminal to establish a TLS handshake; upon successful write-back, immediately performs pipeline reconstruction, switching from HTTP mode to SSL mode: removes the old HttpServerCodec and HttpObjectAggregator from the initialized encryption / decryption processing pipeline, inserts an SSL handle SslHandler at the beginning of the pipeline, and re-adds a new HttpServerCodec and HttpObjectAggregator after the SSL handle SslHandler; subsequent encrypted handshake packets initiated by the client will be decrypted through the SSL handle SslHandler, and the decrypted plaintext HTTP request will flow back into the subsequent HttpServerCodec, ultimately re-entering the dynamic man-in-the-middle handle MitmHandler as a FullHttpRequest object for quantum encryption / decryption business processing.

[0019] Furthermore, on the terminal, the preset encryption policy allows specified applications to use the client-side transparent proxy module for encryption and decryption only through the application-level whitelist addAllowedApplication; it automatically identifies and excludes the client-side transparent proxy module's own process from entering the application-level whitelist; on the terminal, the preset encryption policy sets the domain names to be intercepted and the interfaces of the domain names to be intercepted for the application.

[0020] Furthermore, on the server side, encryption conditions for responses are set through configuration files, so that quantum session encryption and decryption are only used for responses between whitelisted applications and business services that meet the encryption conditions. The configuration file sets the encrypted interface.

[0021] Furthermore, the application for the caller-sending collaborative key coordination key includes the following steps:

[0022] The client transparent proxy module, acting as the calling end, generates a random session identifier for the application. After generating the session identifier, it sends a calling key application to the quantum key service platform. The quantum key service platform records the session identifier, device fingerprint, and timestamp, and provides feedback on the key application acceptance certificate.

[0023] After receiving a request header containing an SM4-encrypted session identifier from the client transparent proxy module, the server-side transparent gateway module, acting as the called party, decrypts the request to obtain the session identifier and sends a called party key application to the quantum key service platform with the same session identifier.

[0024] The quantum key service platform responds to the called party's key request, verifies the existence of the session identifier, generates a quantum session key, and distributes it to both parties.

[0025] If there is no activity within the set time period, the quantum key service platform will automatically destroy the key.

[0026] Furthermore, the server-side transparent gateway module employs the following performance optimization measures:

[0027] Build a multi-threaded Reactor model and configure multiple worker threads to handle I / O events; use Caffeine to build an LRU key cache pool with session identifiers as keys; reuse key handles for consecutive requests with the same session identifier to reduce the number of interface calls.

[0028] Furthermore, to prevent SIM card cloning attacks, the quantum key service platform regularly interacts with operators: when receiving a key application, it initiates a signaling query to check the current base station location of the SIM card; it compares the GPS coordinates reported by the transparent proxy module of the application device client, and if the distance is greater than the set distance threshold, it marks the risk; and it forces the use of two-factor authentication for risky sessions.

[0029] Secondly, the present invention provides an IoT data transmission method based on quantum encrypted communication, wherein the IoT data transmission system based on quantum encrypted communication includes:

[0030] The client-side transparent proxy module executes the following steps: S1. The client-side transparent proxy module intercepts the target application's HTTPS request and obtains plaintext data through a dynamic man-in-the-middle mechanism; S2. If the application request further matches the encryption policy, a random session identifier is constructed for the protected domain name interface of the matched protected application; S3. The quantum SDK is called to apply for a quantum session key from the quantum key service platform; S4. The request body of the request is encrypted using the issued quantum session key, and a new HTTP request is constructed using the encrypted request body combined with a request header containing an SM4-encrypted session identifier and sent to the server-side front-end transparent gateway module.

[0031] The server-side transparent gateway module executes the following steps: S5. It receives a request from the client-side transparent proxy module containing a session identifier request header encrypted with SM4, extracts and decrypts the session identifier, uses it as the called party to apply for the same quantum session key from the quantum key service platform, decrypts the request body using the quantum session key, and forwards the plaintext request to the business service according to the HTTP protocol format; S6. The server-side transparent gateway module receives the plaintext response returned by the business service, encrypts the plaintext response returned by the business service that needs to be encrypted according to the configuration file using the quantum session key, and returns it to the client-side transparent proxy module.

[0032] S7: The client-side transparent proxy module decrypts the response and delivers it to the application, completing the transparent encryption / decryption closed loop.

[0033] The technical solutions provided in the embodiments of the present invention have the following advantages compared with the prior art:

[0034] This invention combines a transparent client-side proxy module at the application layer with a transparent front-end gateway module at the server side to achieve quantum key encryption and decryption of communication traffic between mobile applications and backend business services. The entire process is completely transparent to both the mobile application and the backend business services. The application requires no code modification, SDK integration, or recompilation and signing, and the business services maintain their original architecture, reducing integration costs and deployment risks. It uses a SIM card secure element as the root of trust, binding the device and security policy; and employs quantum session keys for secondary encryption, resulting in strong security. It is suitable for critical information infrastructure fields with stringent requirements for data confidentiality and long-term resistance to quantum attacks, and is particularly suitable for security hardening and compliance upgrades of massive existing mobile terminal applications. This invention solves the problems of "difficult deployment, difficult integration, and difficult maintenance" of quantum security capabilities in real mobile business scenarios, promoting the application of quantum key technology on the terminal side. Both the client and server support selective encryption, avoiding the performance overhead of full encryption. Attached Figure Description

[0035] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0037] Figure 1 An architecture diagram of an IoT data transmission system based on quantum encrypted communication is provided for an embodiment of the present invention;

[0038] Figure 2 A flowchart of the caller-called collaborative key distribution provided in an embodiment of the present invention;

[0039] Figure 3 A flowchart illustrating an IoT data transmission method based on quantum encrypted communication, provided as an embodiment of the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0041] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0042] Example 1

[0043] like Figure 1 As shown, the present invention provides an IoT data transmission system based on quantum encrypted communication, comprising:

[0044] The trusted root and key management module deployed on mobile terminals uses the SIM card security element as the trusted root to bind the traffic encryption and decryption security processing to the device's physical identity; it pre-fills the quantum session key or key application credential in the SIM card security element to support session key negotiation in calling / called modes.

[0045] This invention uses the SIM card security element as the hardware trust anchor for the quantum session key, achieving a unified binding of device, identity, and key. Specifically, it includes:

[0046] Establish a secure communication channel between the SIM card and the system by calling the OpenMobile API through zdxlzSKF.jar;

[0047] Device Identifier Binding: A customized file in the SIM card EF file is read using the Quantum SDK based on `SDKImplC`. The customized file stores the device's unique identifier, devUUID. The device's unique identifier devUUID is concatenated with the application package name, and a binding key bindKey = hash(devUUID, "application package name") is generated using a hash algorithm. The binding key bindKey is used to encrypt the local key cache to prevent key theft under rooted devices.

[0048] Each time a key is requested, the SDK attaches a device fingerprint to the quantum key service platform. The device fingerprint is the MD5 hash of the bootloader version, baseband version, and device unique identifier devUUID: "deviceFp":"MD5(bootloader+baseband+devUUID)".

[0049] When the quantum key service platform receives a key application, it compares the historical fingerprints. If there are abnormal fluctuations, it will refuse the service or conduct further verification.

[0050] A client-side transparent proxy module deployed at the application layer of a mobile terminal intercepts outbound network traffic of the target application, parses the application layer protocol, and, when matching a preset encryption strategy, applies for a quantum session key based on the SIM card security element as a trusted root vector quantum key service platform. The quantum session key is then used to encrypt the request body data of the parsed request and form a new HTTP packet with the request header containing an SM4-encrypted session identifier for forwarding.

[0051] Specifically, the client-side transparent proxy module uses a combination of the terminal operating system's VpnService and the Netty framework's local proxy service, rather than general network interception.

[0052] The traffic redirection unit of the client-side transparent proxy module utilizes the terminal operating system's VpnService to redirect the traffic of a specified protected application to a local loopback address. Taking an Android terminal as an example, it uses the setHttpProxy interface of AndroidVpnService.Builder to redirect the application's HTTP / HTTPS traffic to the local loopback address 127.0.0.1:8888.

[0053] Local Proxy Service Unit: A proxy service based on the Netty framework listens to the loopback address and parses application layer protocols in real time. Specifically, the terminal runs a NettyMitmServer proxy server based on the Netty framework locally, which parses application layer protocols in real time using HttpServerCodec. HttpServerCodec is a codec class in the Netty framework whose function is to convert byte streams to and from HTTP request / response objects.

[0054] To bypass HTTPS encryption and obtain plaintext business data, this invention constructs a secure and controllable dynamic man-in-the-middle mechanism through dynamic domain name certificate issuance and atomic pipelines. The dynamic man-in-the-middle mechanism handles CONNECT requests and configures encryption / decryption processing pipelines for encryption and decryption transmission. The dynamic man-in-the-middle mechanism's handling of CONNECT requests to bypass HTTPS encryption and configure encryption / decryption processing pipelines includes: initializing the encryption / decryption processing pipeline state; the initialized encryption / decryption processing pipeline is mapped from HttpServerCodec to HttpObjectAggregator, and then to the dynamic man-in-the-middle handle MitmHandler; it is used to handle basic HTTP protocol parsing and capture CONNECT requests sent by the terminal.

[0055] When the dynamic man-in-the-middle handle MitmHandler of the initialized encryption / decryption processing pipeline receives a CONNECT request, it triggers the following actions to acquire the encryption / decryption processing pipeline:

[0056] The process involves parsing `request.uri()` to obtain the target hostname; calling the root management function to construct a temporary domain name certificate for the target host in real time using a pre-generated private root certificate; writing back the `CONNECT` command to the terminal to establish a TLS handshake, thus enabling local TLS decryption; upon successful write-back, the pipeline is immediately restructured, switching from the HTTP mode initialization encryption / decryption pipeline to the SSL mode encryption / decryption pipeline: removing the old `HttpServerCodec` and `HttpObjectAggregator` from the initialization pipeline, inserting an SSL handle `SslHandler` at the beginning of the pipeline, and adding a new `HttpServerCodec` and `HttpObjectAggregator` after the SSL handle `SslHandler`; subsequent encrypted handshake packets initiated by the client will be decrypted through the SSL handle `SslHandler`, and the decrypted plaintext HTTP request will flow back into the subsequent `HttpServerCodec`, ultimately re-entering the dynamic man-in-the-middle handle `MitmHandler` as a `FullHttpRequest` object for quantum encryption / decryption business transmission processing. Among them, HttpObjectAggregator is a processing class in Netty used to handle HTTP chunked messages or segmented transmissions. Its function is to aggregate multiple HTTP content fragments (such as HttpContent, LastHttpContent) into a complete FullHttpRequest or FullHttpResponse object, which facilitates unified processing of subsequent business logic.

[0057] When switching pipelines, atomic pipeline switching is used to avoid data loss during pipeline switching.

[0058] In the terminal implementation, this application achieves two levels of encryption configuration—application and in-application domain interface level—through an encryption strategy. The preset encryption strategy uses an application-level whitelist (addAllowedApplication) to allow only specified applications to use the client-side transparent proxy module for encryption and decryption, resolving the potential infinite recursion loop problem that may occur when the client-side transparent proxy module forwards traffic; it automatically identifies and excludes the client-side transparent proxy module's own process from entering the application-level whitelist; and the preset encryption strategy sets the domains to be intercepted and the interfaces of those domains for the application.

[0059] When encryption is required, a random session identifier is generated for the protected domain interface of the application. Using the session identifier, the quantum SDK interface is called as the calling end to initiate a calling key application to the quantum key service platform to obtain the quantum session key. The quantum session key is used to encrypt the request body of the request sent by the protected domain interface. The encrypted request body and the request header containing the SM4 encrypted session identifier are combined to form a new HTTP packet and forwarded. After receiving the encrypted response returned by the server-side front-end transparent gateway module, the local proxy server retrieves the quantum session key cache based on the session identifier, decrypts it using the quantum session key, and injects it into the original man-in-the-middle encryption / decryption processing pipeline to deliver it to the protected domain interface of the application.

[0060] By employing the aforementioned method of nested quantum encryption logic within the TLS tunnel, specific sensitive data undergoes secondary quantum encryption reinforcement in a controlled environment after decryption, enhancing security. Before forwarding, not only is a business tag injected, but the quantum SDK is also invoked to perform secondary encryption on the entire request body using a quantum session key, forming a dual protection system consisting of the external TLS tunnel and the internal quantum-encrypted request body. Even if the external certificate is hijacked or the TLS protocol is brute-forced, the core business data remains secure because the request body is protected by the quantum session key.

[0061] A server-side transparent gateway module deployed in the business service cluster receives quantum-encrypted traffic from the client-side transparent proxy module, decrypts it to obtain the session identifier, extracts the session identifier, applies for the same quantum session key from the quantum key service platform, decrypts the request body using the quantum session key, forwards it to the original business service, and encrypts the response data of the business service matching the configuration file using the same quantum session key before returning it.

[0062] Specifically, the server-side transparent gateway module adopts a high-performance encryption / decryption forwarding pipeline design. It utilizes a Reactor multi-threaded model, enabling a single node to support large-scale concurrent connections. The module employs Caffeine to build an LRU cache as a key cache pool, storing key information in key-value pairs, where the key is the session identifier and the value is the quantum session key and expiration time. For consecutive requests with the same sessionId, the module reuses key handles to reduce API call overhead.

[0063] The client-side transparent proxy module and the server-side front-end transparent gateway module are completely transparent to upper-layer applications and business services.

[0064] Quantum Key Service Platform: An independently deployed key distribution center responsible for accepting quantum session key applications, executing session binding, issuing quantum session keys, and verifying device identity with the SIM card security element.

[0065] In the specific implementation process, in addition to verifying the device identity through device fingerprint, in order to prevent SIM card cloning attacks, the quantum key service platform regularly interacts with the operator's HLR: when receiving a key application, it initiates a signaling query to check the current base station location of the SIM card; compares the GPS coordinates reported by the transparent proxy module of the applying device client (obtained through LocationManager), and if the distance is greater than the set distance threshold, it marks the risk; and forces the use of secondary authentication for risky sessions.

[0066] To prevent malicious attacks from overloading the key service, a built-in circuit breaker policy is implemented, such as limiting the number of key requests per IP address per second to a set number, and returning too many requests beyond this limit.

[0067] On the server side, encryption conditions for responses are set through configuration files, allowing quantum session encryption and decryption to be applied only to responses between whitelisted applications and business services that meet the encryption conditions. The configuration files also configure encrypted business service response interfaces. This eliminates the need for encryption of responses that do not require it, reducing the workload of the server-side transparent gateway module.

[0068] The client-side transparent proxy module, the server-side front-end transparent gateway module, and the quantum key service platform achieve collaborative key distribution between the calling and called parties through lightweight token hash mapping, such as... Figure 2 As shown, the steps include:

[0069] The client-side transparent proxy module generates a random session identifier for the protected domain interface of the application. Specifically, a random session identifier is generated only when the request of the protected domain interface of the application matches the encryption policy, ensuring that all requests within the same user session share the session identifier and are naturally isolated across user sessions.

[0070] The Quantum SDK interacts with the SIM card's secure element via the OpenMobile API to obtain the device fingerprint;

[0071] The client transparent proxy module, acting as the calling end, calls the QCT_ApplyKeyWithSessionID function of the quantum SDK, carrying the session identifier and device fingerprint to the quantum key service platform to initiate a calling key application. The quantum key service platform records the session identifier, device fingerprint, and timestamp involved in the application: {sessionId, callerDevFP, timestamp}, and returns the key application acceptance certificate.

[0072] After receiving a request header containing an SM4-encrypted session identifier from the client transparent proxy module, the server-side transparent gateway module, acting as the called party, decrypts the request to obtain the session identifier and sends a called party key application to the quantum key service platform with the same session identifier.

[0073] If the quantum key service platform verifies that the session identifier exists and has not expired, it generates a quantum session key and sends the same quantum session key to the server-side front-end transparent gateway module. If the server-side front-end transparent gateway module fails to apply for the key within the time limit, the quantum key service platform automatically destroys the key materials to prevent the key from being left unused.

[0074] When encryption is required, the client-side transparent proxy module uses the quantum session key to encrypt the request body of the original request, generating a ciphertext request body. This is then combined with a request header containing an SM4 encrypted session identifier to obtain a quantum-encrypted HTTP request. The server-side front-end transparent gateway module uses the quantum session key to decrypt the request body in the quantum-encrypted HTTP request, recovering the plaintext request body. It then constructs a standard HTTP request from the plaintext request body and forwards it to the backend business service. The business service processes the request and responds: The BusinessServer receives the plaintext request using standard HTTP, executes the request processing logic, generates a plaintext response, and returns it to the server-side front-end transparent gateway module. The server-side front-end transparent gateway module encrypts the response of the interface matching the configuration file: It captures the plaintext response body, encrypts it using the same quantum session key, generates a quantum-encrypted response body, and constructs a standard HTTP response, returning it to the client-side transparent proxy module. The client-side transparent proxy module performs response decryption and delivery: After receiving the encrypted response, the client-side transparent proxy module extracts the session identifier (sessionId) and uses the session identifier to retrieve the local key cache; it uses the matched quantum session key to decrypt the quantum encrypted response body in the encrypted response and recover the plaintext response body; it injects the plaintext response into the original pipeline, which is then encapsulated into a standard HTTP response by the Netty framework; and finally delivers it to the application, allowing the user to complete the entire quantum encrypted communication process without any awareness.

[0075] Throughout the entire process, neither the original application nor the business service is aware of the encryption behavior. The application still sends plaintext requests and receives plaintext responses; the business service still processes plaintext data and returns plaintext results. All quantum-safe logic is automatically completed in the proxy layer of the client-side transparent proxy module and the server-side front-end transparent gateway module, achieving zero code intrusion.

[0076] This application overcomes the shortcomings of existing quantum key distribution technologies when applied to mobile terminals, such as high invasiveness, weak trust binding, low performance overhead, and difficulty in operation and maintenance. This invention can achieve automatic encryption / decryption and forwarding of specified application traffic driven by quantum keys without modifying existing mobile application and business service code. This ensures the smooth embedding and long-term operation of quantum security capabilities in real-world business scenarios.

[0077] Example 2

[0078] like Figure 3 As shown, this embodiment of the invention provides an IoT data transmission method based on quantum encrypted communication, including:

[0079] The client-side transparent proxy module executes the following steps: S1. Intercept HTTPS requests from a specified application and obtain the plaintext data of the request through a dynamic man-in-the-middle mechanism; S2. If the application request further matches the encryption policy, construct a random session identifier for the protected domain name interface of the matched protected application; S3. Call the quantum SDK to apply for a quantum session key from the quantum key service platform; S4. Use the issued quantum session key to encrypt the request body, and use the encrypted request body combined with the request header containing the SM4 encrypted session identifier to construct a new HTTP request and send it to the server-side front-end transparent gateway module.

[0080] The server-side transparent gateway module executes the following steps: S5. It receives a request from the client-side transparent proxy module containing a session identifier request header encrypted with SM4, extracts and decrypts the session identifier, uses it as the called party to apply for the same quantum session key from the quantum key service platform, decrypts the request body using the quantum session key, and forwards the plaintext request to the business service according to the HTTP protocol format; S6. The server-side transparent gateway module receives the plaintext response returned by the business service, encrypts the plaintext response returned by the business service that needs to be encrypted according to the configuration file using the quantum session key, and returns it to the client-side transparent proxy module.

[0081] S7: The client-side transparent proxy module decrypts the response and delivers it to the application, completing the transparent encryption / decryption closed loop.

[0082] In the embodiments provided by this invention, it should be understood that the disclosed structures and methods can be implemented in other ways. For example, the structural embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, structures, or units, and may be electrical, mechanical, or other forms.

[0083] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0085] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. An Internet of Things data transmission system based on quantum encryption communication, characterized in that, include: The trusted root and key management module deployed on the mobile terminal uses the SIM card's secure element as the trusted root, binding the traffic encryption and decryption security processing to the device's physical identity. Specifically, it reads a customized file from the SIM card's EF file via the quantum SDK; this customized file stores the device's unique identifier, devUUID. The device's unique identifier, devUUID, is concatenated with the application package name to generate a binding key. This binding key is used to encrypt the local key cache, preventing key theft by rooted devices. Each time a key is requested, the SDK attaches a device fingerprint to the quantum key service platform. This device fingerprint is the MD5 hash of the bootloader version, baseband version, and the device's unique identifier, devUUID. The quantum key service platform compares historical fingerprints for device identity verification; if abnormal fluctuations are detected, service is denied. A quantum session key or key request credential is pre-loaded into the SIM card's secure element, supporting session key negotiation in calling / received modes. A client-side transparent proxy module deployed at the application layer of a mobile terminal intercepts outbound network traffic of requests sent by a preset application, parses the application layer protocol, and when matching a preset encryption strategy, applies for a quantum session key based on the SIM card security element as a trusted root vector quantum key service platform, and uses the quantum session key to encrypt the request body data, and then forms a new HTTP request forwarding with the request header containing the SM4 encrypted session identifier. The client-side transparent proxy module specifically includes: The traffic redirection unit, based on the setHttpProxy interface of the VpnService in the terminal operating system, redirects the traffic of the specified target application to the local loopback address; The local proxy service unit, based on the Netty framework, listens to the loopback address and parses the application layer protocol in real time using HttpServerCodec. It employs a dynamic man-in-the-middle mechanism to handle CONNECT requests and configures encryption / decryption processing pipelines for encryption and decryption transmission. When encryption is required, it constructs a random session identifier for the matching protected application. Using the session identifier, it calls the quantum SDK interface to initiate a caller key application to the quantum key service platform to obtain the quantum session key. After receiving the encrypted response from the server-side transparent gateway module, the local proxy server retrieves the quantum session key cache based on the session identifier, decrypts it using the quantum session key, and injects it into the original man-in-the-middle encryption / decryption processing pipeline before delivering it to the application. The dynamic man-in-the-middle mechanism for handling CONNECT requests and configuring encryption / decryption processing pipelines includes: The initial encryption / decryption processing pipeline is initialized by mapping from HttpServerCodec to HttpObjectAggregator, and then to the dynamic man-in-the-middle handle MitmHandler; it is used to handle basic HTTP protocol parsing and capture CONNECT requests sent by the terminal. When the dynamic man-in-the-middle handle MitmHandler of the initialized encryption / decryption processing pipeline receives a CONNECT request, it triggers the following actions to switch the encryption / decryption processing pipeline: Parses request.uri() to obtain the target hostname; calls the root management to construct a temporary domain name certificate for the target host in real time; writes back the CONNECT response to the terminal to establish a TLS handshake; upon successful write-back, immediately performs pipeline reconstruction, switching from HTTP mode to SSL mode: removes the old HttpServerCodec and HttpObjectAggregator from the initialized encryption / decryption processing pipeline, inserts an SSL handle SslHandler at the beginning of the pipeline, and adds a new HttpServerCodec and HttpObjectAggregator after the SSL handle SslHandler; subsequent encrypted handshake packets initiated by the client will be decrypted through the SSL handle SslHandler, and the decrypted plaintext HTTP request will flow back into the subsequent HttpServerCodec, ultimately re-entering the dynamic man-in-the-middle handle MitmHandler as a FullHttpRequest object for quantum encryption / decryption business processing; and, during pipeline switching, atomic pipeline switching is used to avoid data loss during pipeline switching. On the terminal, the preset encryption policy allows specified applications to use the client transparent proxy module for encryption and decryption only through the application-level whitelist addAllowedApplication; it automatically identifies and excludes the client transparent proxy module's own process from entering the application-level whitelist; on the terminal, the preset encryption policy sets the domain names to be intercepted and the interfaces of the domain names to be intercepted for the application. A server-side transparent gateway module deployed in the business service cluster receives quantum-encrypted traffic from the client-side transparent proxy module, decrypts it to obtain a session identifier, applies for the same quantum session key from the quantum key service platform, decrypts the quantum-encrypted traffic using the applied quantum session key, forwards it to the corresponding business service, and encrypts the response data of the business service matching the configuration file using the same quantum session key before returning it to the client-side transparent proxy module. The quantum key service platform is used to coordinate key applications between the calling and called parties, issue consistent quantum session keys based on the service session identifier, and verify device identity with the SIM card security element. The client-side transparent proxy module and the server-side front-end transparent gateway module are completely transparent to upper-layer applications and business services. The client-side transparent proxy module performs the following steps: S1. The client-side transparent proxy module intercepts the target application's HTTPS request and obtains plaintext data through a dynamic man-in-the-middle mechanism; S2. If the application request further matches the encryption policy, a random session identifier is constructed for the protected domain name interface of the matched protected application; S3. The quantum SDK is called to apply for a quantum session key from the quantum key service platform; S4. The request body of the request is encrypted using the issued quantum session key, and a new HTTP request is constructed using the encrypted request body combined with a request header containing an SM4-encrypted session identifier and sent to the server-side front-end transparent gateway module. The server-side transparent gateway module executes the following steps: S5. It receives a request from the client-side transparent proxy module containing a session identifier request header encrypted with SM4, extracts and decrypts the session identifier, uses it as the called party to apply for the same quantum session key from the quantum key service platform, decrypts the request body using the quantum session key, and forwards the plaintext request to the business service according to the HTTP protocol format; S6. The server-side transparent gateway module receives the plaintext response returned by the business service, encrypts the plaintext response returned by the business service that needs to be encrypted according to the configuration file using the quantum session key, and returns it to the client-side transparent proxy module. S7: The client-side transparent proxy module decrypts the response and delivers it to the application, completing the transparent encryption / decryption closed loop.

2. The quantum encryption communication based Internet of Things data transmission system according to claim 1, characterized in that, The trusted root and key management module deployed on the mobile terminal establishes a secure communication channel between the SIM card and the system by calling the OpenMobile API through zdxlzSKF.jar. 3.The quantum encryption communication based IoT data transmission system according to claim 1, wherein, On the server side, encryption conditions for responses are set through configuration files. Quantum session encryption and decryption are only used for responses between whitelisted applications and business services that meet the encryption conditions. The configuration file sets the encrypted business service response interface.

4. The quantum encryption communication based Internet of Things data transmission system according to claim 1, characterized in that, The process of requesting a coordination key for the calling and called parties includes the following steps: The client transparent proxy module, acting as the calling end, generates a random session identifier for the protected domain name interface of the application. After generating the session identifier, it sends a calling key application to the quantum key service platform. The quantum key service platform records the session identifier, device fingerprint, and timestamp, and provides feedback on the key application acceptance certificate. After receiving a request header containing an SM4-encrypted session identifier from the client transparent proxy module, the server-side transparent gateway module, acting as the called party, decrypts the request to obtain the session identifier and sends a called party key application to the quantum key service platform with the same session identifier. The quantum key service platform responds to the called party's key request, verifies the existence of the session identifier, generates a quantum session key, and distributes it to both parties. If there is no activity within the set time period, the quantum key service platform will automatically destroy the key.

5. The IoT data transmission system based on quantum encrypted communication according to claim 1, characterized in that, The server-side front-end transparent gateway module employs the following performance optimization measures: Build a multi-threaded Reactor model and configure multiple worker threads to handle I / O events; use Caffeine to build an LRU key cache pool with session identifiers as keys; reuse key handles for consecutive requests with the same session identifier to reduce the number of interface calls.

6. The quantum encryption communication based Internet of Things data transmission system according to claim 1, wherein, To prevent SIM card cloning attacks, the quantum key service platform interacts with operators regularly: when receiving a key application, it initiates a signaling query to check the current base station location of the SIM card; it compares the GPS coordinates reported by the transparent proxy module of the application device client, and if the distance is greater than the set distance threshold, it marks the risk; and it forces the use of two-factor authentication for risky sessions.

Images