A key injection method and system

Abstract

This invention belongs to the field of quantum communication technology and discloses a key injection method and system, comprising: generating a temporary key pair and dynamic parameters; generating a transformation factor based on a preset shared key, an identity identifier, and dynamic parameters, and performing a reversible operation on the temporary public key to generate a transformed public key; generating a first authentication tag based on the preset shared key and a request digest including the identity identifier, the transformed public key, and dynamic parameters; sending an injection request including the identity identifier, the transformed public key, dynamic parameters, and the first authentication tag; receiving a response message including encapsulated ciphertext, ciphertext of the key to be injected, and a second authentication tag; decapsulating the encapsulated ciphertext based on the temporary private key to obtain key material; reconstructing an interaction feature sequence containing the identity identifier, the transformed public key, dynamic parameters, the first authentication tag, and the encapsulated ciphertext, and deriving a session key and an authentication key based on the key material; verifying the second authentication tag based on the authentication key, and decrypting it based on the session key after verification to obtain the key to be injected.

Description

Technical Field

[0001] This invention belongs to the field of quantum communication technology, specifically relating to a key injection method and system. Background Technology

[0002] In engineering practice, quantum keys are typically generated and stored within a controlled secure domain, while the terminals that actually use these keys are often distributed across public networks, private networks, or complex edge networks. How to reliably distribute quantum keys to remote terminals without compromising security has become a critical issue in the deployment of quantum communication systems. Current practices mostly involve first authenticating the terminal, then establishing a secure channel, and finally distributing the key. While this approach is feasible in traditional environments, it often reveals new contradictions when applied to post-quantum scenarios.

[0003] 1. Limited computing and storage resources on the terminal side. If the terminal side directly adopts post-quantum digital signature for explicit identity authentication, it will generate extremely high computing power and storage consumption. Moreover, the message expansion caused by digital signature is extremely unfriendly to field terminal equipment with limited processor computing power, power sensitivity and tight communication bandwidth.

[0004] 2. Insufficient deep integration at the protocol layer leads to low engineering efficiency. Most solutions simply connect the lightweight authentication mechanism and post-quantum key encapsulation (KEM) in a simple linear chain, failing to achieve deep integration at the protocol layer. This results in lengthy protocol interaction processes, high repetition of message fields, and low system operating efficiency.

[0005] 3. The server faces serious risks of resource exhaustion and denial-of-service attacks. In existing solutions, the server blindly invests high computing power to perform high-overhead cryptographic operations such as quantum key encapsulation before the authenticity and legitimacy of the request are clear. This makes it extremely vulnerable to being overwhelmed by malicious forged requests, leading to denial-of-service (DoS) risks on core computing resources.

[0006] 4. Lack of continuously evolving dynamic access control and verification capabilities. The traditional static security model of "one-time authentication, long-term trust" cannot meet the strict security constraints of continuous verification and dynamic access control of terminal entity identity, real-time environment status, and access context under a zero-trust architecture.

[0007] Therefore, a new remote key injection scheme is needed that, while keeping the standard post-quantum key encapsulation and decapsulation mechanism unchanged, naturally integrates terminal request pre-authentication, session context binding, anti-replay protection, and zero-trust policy verification into the same injection process, so that the system can both take into account the feasibility of resource-constrained terminals and meet high-strength security requirements. Summary of the Invention

[0008] To address the problems of high terminal authentication overhead, server vulnerability to denial-of-service attacks, and insufficient session binding security in existing technologies, this invention provides a key injection method and system. By using a pre-set shared key to drive the reversible transformation of the terminal-side temporary public key and request pre-authentication, the server can complete low-cost request screening and admission determination before investing high-overhead cryptographic computing power in key encapsulation. This significantly reduces terminal computing and communication overhead while improving the server's resistance to resource exhaustion and attacks.

[0009] This invention provides the following technical solution: The primary objective of this invention is to provide a key injection method for use in terminal devices, comprising: Generate temporary key pairs and dynamic parameters; Based on a pre-set shared key, terminal identity identifier, and dynamic parameters, a transformation factor is generated through a deterministic derivation function; based on the transformation factor, a reversible operation is performed on the public key in the temporary key pair to generate a transformed public key; A first authentication tag is generated based on a pre-set shared key and a request digest; the request digest includes the terminal identity identifier, the transformed public key, and dynamic parameters. Send an injection request to the key injection server. The injection request includes the terminal identity identifier, the transformed public key, dynamic parameters, and the first authentication tag. Receive a response message returned by the key injection server, the response message including encapsulated ciphertext, the ciphertext of the key to be injected, and a second authentication tag; Based on the private key in the temporary key pair, the encapsulated ciphertext is decapsulated to obtain key material; an interaction feature sequence containing terminal identity, transformed public key, dynamic parameters, first authentication tag and encapsulated ciphertext is reconstructed, and a session key and authentication key are derived based on the key material and interaction feature sequence; the second authentication tag is verified based on the authentication key, and after the verification is successful, the ciphertext to be injected is decrypted based on the session key to obtain the key to be injected.

[0010] By reversibly transforming the public key using a pre-set shared key and generating an authentication tag, the server can perform request legitimacy screening using low-cost symmetric operations before performing high-overhead decryption or encapsulation operations. This effectively reduces the computational overhead on the terminal side and prevents malicious requests from consuming server resources.

[0011] Preferably, the reversible operation on the public key in the temporary key pair based on the transformation factor includes: performing a bitwise XOR operation on the data sequence of the public key in the temporary key pair and the key stream generated by the transformation factor; or performing a modular addition operation on the data sequence of the public key in the temporary key pair or the elements of a polynomial matrix using the transformation factor; or performing a symmetric encryption operation on the public key in the temporary key pair using the transformation factor as the key of a symmetric encryption algorithm.

[0012] Preferably, generating the first authentication tag includes: performing a message authentication code operation on the request digest based on a preset shared key to generate the first authentication tag. Binding the terminal identity to the transformed public key via the message authentication code further enhances the request's tamper-proof capability.

[0013] Preferably, the injection request and the request digest further include context parameters, which include one or more of time window information, location digests, device status digests, and remote measurement result digests. By introducing context parameters, the authentication process can incorporate the terminal's environmental state, meeting the dynamic verification requirements of a zero-trust architecture.

[0014] Preferably, after obtaining the key to be injected, the method further includes: sending a confirmation message to the key injection server, the confirmation message including a third authentication tag generated based on the authentication key.

[0015] The second objective of this invention is to provide a key injection method, applied to a key injection server, comprising: Receive an injection request sent by a terminal device. The injection request includes at least the terminal identity identifier, the transformation public key, dynamic parameters, and the first authentication tag. The first authentication tag is verified based on the preset shared key corresponding to the terminal identity identifier. After the verification is successful, a transformation factor is generated through a deterministic derivation function based on the preset shared key, the terminal identity identifier, and dynamic parameters. The transformation public key is then inversely operated on based on the transformation factor to restore the public key in the temporary key pair. Perform key encapsulation based on the public key in the temporary key pair to generate encapsulated ciphertext and key material; Construct an interaction feature sequence containing terminal identity identifier, transformation public key, dynamic parameters, first authentication tag and encapsulated ciphertext, and derive session key and authentication key based on key material and interaction feature sequence; The key to be injected is encrypted using the session key to generate the ciphertext of the key to be injected. Generate a second authentication tag based on the authentication key; A response message is sent to the terminal device, the response message including encapsulated ciphertext, the ciphertext of the key to be injected, and a second authentication tag.

[0016] Before restoring the public key and encapsulating the execution key, the server first filters out illegal requests through low-cost computation, which significantly improves the server's ability to resist denial-of-service attacks.

[0017] Preferably, after verifying the first authentication tag based on the preset shared key corresponding to the terminal identity, the method further includes: performing a replay protection check on the dynamic parameters; and / or performing a zero-trust verification on the injection request. The replay protection check and zero-trust verification further enhance the security of the key injection process, preventing replay attacks and unauthorized access.

[0018] A third objective of this invention is to provide a key injection system, comprising: A key injection server, deployed within a security domain, is configured to perform the method as provided in the second objective of this invention; The endpoint security agent runs in a controlled execution environment of a remote terminal device, which is configured as a terminal device of the system to execute the method provided as the first objective of this invention. An identity management database is used to maintain the mapping relationship between terminal identity identifiers and pre-set shared keys; The quantum key source interface is used to connect to a quantum key pool or quantum key distribution device and provide the key to be injected to the key injection server.

[0019] Preferably, the system also includes an anti-replay library for caching processed terminal device dynamic parameters, request indexes, or request summaries to prevent the same request from being reused.

[0020] Preferably, the system further includes a zero-trust policy verification module, which is used to perform round-by-round judgment on the context parameters in the injection request.

[0021] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention generates a transformed public key by reversibly transforming a temporary public key using a pre-set shared key, and then generates an authentication tag based on this pre-set shared key. This allows terminal devices to complete identity authentication without performing high-overhead asymmetric signature operations, significantly reducing the computational burden and power consumption on the terminal side, making it particularly suitable for resource-constrained IoT terminals. Simultaneously, upon receiving a request, the server first performs low-cost verification of the authentication tag using the pre-set shared key. Only after successful verification does it perform high-overhead public key restoration and key encapsulation operations, effectively preventing unauthorized requests from consuming server computing resources and improving the system's resistance to denial-of-service attacks.

[0022] Furthermore, by incorporating dynamic parameters and transformed public keys into requests, a tight binding between terminal identity and session parameters is achieved, enhancing the anti-replay and anti-tampering capabilities of the interaction process. Combined with zero-trust verification of context parameters, the security of the key injection process is further guaranteed.

[0023] This invention can be widely applied to remote quantum key loading, secure access to power terminals, key updates for industrial control equipment, high-security key distribution for mobile edge nodes, and distributed key management platforms that need to work in conjunction with quantum key distribution (QKD) systems, and has strong engineering application value. Attached Figure Description

[0024] Figure 1 A schematic diagram of the macroscopic process of the key injection method; Figure 2 This diagram illustrates the composition and module relationships of a key injection system. Figure 3 A schematic diagram of the cross-domain deployment architecture for the key injection system; Figure 4 A detailed timing interaction diagram for remote key injection. Detailed Implementation

[0025] 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.

[0026] The present invention will now be described in further detail with reference to the accompanying drawings: Example 1: like Figure 1 and Figure 4 As shown, this embodiment provides a key injection method applied to terminal devices. This method demonstrates the overall process of key injection performed on the terminal side, establishing a core logical closed loop of pre-set shared key, public key transformation, and pre-authentication. The method includes the following steps: A temporary key pair and dynamic parameters are generated; in this embodiment, the dynamic parameters are random numbers. A transformation factor is generated using a deterministic derivation function based on a preset shared key, terminal identity identifier, and dynamic parameters. A transform public key is generated by performing a reversible operation on the public key in the temporary key pair based on the transformation factor. A first authentication tag is generated based on the preset shared key and a request digest; the request digest includes the terminal identity identifier, the transform public key, and the dynamic parameters. An injection request is sent to a key injection server; the injection request includes the terminal identity identifier, the transform public key, the dynamic parameters, and the first authentication tag. A response message is received from the key injection server. The process includes encapsulated ciphertext, the ciphertext of the key to be injected, and a second authentication tag. The response message is generated by the key injection server after verifying the first authentication tag and performing a key encapsulation operation using the restored public key. Based on the private key in the temporary key pair, the encapsulated ciphertext is decapsulated to obtain key material. An interaction feature sequence containing the terminal identity identifier, transformed public key, dynamic parameters, the first authentication tag, and the encapsulated ciphertext is reconstructed, and a session key and an authentication key are derived based on the key material and the interaction feature sequence. The second authentication tag is verified based on the authentication key, and after successful verification, the ciphertext of the key to be injected is decrypted based on the session key to obtain the key to be injected.

[0027] Specifically, a pre-configured shared key refers to a symmetric key that is pre-negotiated and securely stored between the terminal device and the key injection server. Its storage format can include a Hardware Security Module (HSM), a Trusted Execution Environment (TEE), or a Physically Unclonable Function (PUF) unit, ensuring that the secret seed is not exposed in ordinary software environments. A temporary key pair refers to an asymmetric key pair temporarily generated by the terminal device during the current session, such as a key pair conforming to post-quantum cryptography standards, or a key pair conforming to traditional public-key cryptography standards. A reversible transformation is a mathematical operation that can map the public key from its original state to a transformed state, and, given the pre-configured shared key, can be uniquely restored from the transformed state to the original state. Through this step, the terminal device deeply binds public key transmission with authentication without exposing the original public key. This prevents attackers from reconstructing the original public key even if they intercept the transformed public key, without knowing the pre-configured shared key, thus hindering subsequent key encapsulation operations and effectively improving the security of public key transmission.

[0028] Performing reversible operations on the public key in a temporary key pair refers to symmetric reversible operations that do not compromise the recoverability of the public key data. Specifically, these reversible operations include, but are not limited to: performing a bitwise XOR operation on the data sequence of the public key in the temporary key pair and the key stream generated by the transformation factor; or performing a modular addition operation on the data sequence of the public key in the temporary key pair or the elements of a polynomial matrix using the transformation factor; or using the transformation factor as the key for a symmetric encryption / decryption algorithm to perform a symmetric encryption operation on the public key in the temporary key pair to generate the transformed public key. Correspondingly, the key injection server can generate the same transformation factor based on the same preset shared key, terminal identity, and dynamic parameters, and perform the corresponding inverse operation on the transformed public key to recover the public key in the temporary key pair.

[0029] Deterministic derivation functions are a class of functions that can deterministically output pseudo-random data from input seed material, such as HMAC-based key derivation functions (HKDF) or cryptographic algorithm-based key derivation functions (KDF). In this process, as long as the input parameters are the same, the generated transformation factors will necessarily be the same, thus ensuring that the server can reconstruct the transformation factors using the same input parameters.

[0030] The generation of the transformation public key and the first authentication tag both occur before the terminal device sends the request. The first authentication tag is used by the key injection server to verify the legitimacy of the request source and the integrity of the data. By reusing the same pre-set shared key to generate the transformation public key and the first authentication tag, this embodiment establishes an inherent association mechanism: only a legitimate terminal holding the correct pre-set shared key can generate the correct transformation public key and the first authentication tag. This design avoids the terminal device performing high-overhead asymmetric digital signature operations (such as post-quantum signature algorithms), significantly reducing the computational pressure and energy consumption on the terminal side, and is particularly suitable for resource-constrained scenarios such as power terminals and IoT devices.

[0031] Generating the first authentication tag specifically includes: performing a message authentication code operation on the request digest based on a preset shared key to generate the first authentication tag. This embodiment constructs a tamper-proof data packet by binding the terminal identity identifier, the transformed public key, and dynamic parameters together for authentication calculation. If an attacker intercepts the request and attempts to modify the transformed public key (e.g., replacing it with their own public key) or the dynamic parameters (e.g., replaying the old request), the server-side verification will fail because the attacker cannot obtain the correct preset shared key to recalculate the first authentication tag, thus effectively resisting man-in-the-middle attacks and replay attacks.

[0032] Furthermore, to meet the continuous verification requirements of the terminal environment status under the zero-trust architecture, the device terminal can also simultaneously collect one or more of the following as context parameters: time window information, location summary, device status summary, and remote measurement result summary. By introducing context parameters, identity authentication is combined with environment awareness, constructing a dynamic trust assessment mechanism. Even if an attacker steals the terminal's pre-set shared key and attempts to launch an injection request in an unauthorized environment, the generated first authentication tag will fail the server-side verification because the attacker cannot forge context parameters consistent with those of a legitimate terminal. This mechanism effectively prevents the security risks caused by the leakage of static credentials.

[0033] The ciphertext is generated by the key injection server using the restored public key to execute a key encapsulation algorithm. Since only the terminal device holding the corresponding private key can successfully decapsulate it, this step ensures that the key material can only be obtained by the legitimate requester. Even if the response message is intercepted during transmission, the attacker cannot recover the key material.

[0034] The interaction signature sequence refers to a set of key parameters mutually agreed upon by the terminal device and the server during this round of key injection interaction. Incorporating these context-dependent parameters into the Key Derivation Function (KDF) input ensures that the derived session key and authentication key not only depend on the key material but are also strongly bound to the entire interaction process. This means that if an attacker attempts to tamper with any field during the interaction process (e.g., replacing the public key or modifying dynamic parameters), the derived key will be completely different due to the change in the interaction signature sequence, leading to subsequent verification failures. This mechanism effectively prevents parameter tampering in man-in-the-middle attacks.

[0035] The second authentication tag is a message authentication code calculated by the server using an authentication key derived from the server side when generating the response message, based on the response content (such as encapsulated ciphertext, ciphertext of the key to be injected, etc.). The terminal device recalculates the authentication tag on the received response message using its locally derived authentication key and compares it with the received second authentication tag. If they match, it proves that the response message indeed comes from a legitimate server holding a pre-set shared key and has not been tampered with during transmission; if the verification fails, the terminal device will discard the response message and terminate the process, thereby preventing attackers from forging server responses or launching replay attacks.

[0036] Only after confirming the integrity and legitimacy of the response message will the terminal device perform the decryption operation. This sequential control of verification before decryption prevents the terminal device from blindly processing maliciously constructed ciphertext data without verifying the security of the response, effectively improving system security. Furthermore, since the private key in the temporary key pair stored locally on the terminal device is never transmitted over the network, only this terminal can decapsulate the key material and obtain the final key to be injected.

[0037] The terminal device uses the authentication key to confirm the key to be injected, generating a third authentication tag. Upon receiving the confirmation message, the server verifies the third authentication tag to confirm that the key has been successfully injected into the target terminal and that the terminal's identity is correct. This two-way confirmation mechanism not only ensures the reliability of the service but also provides an audit basis for potential key synchronization disputes. If the terminal device fails to send a confirmation message within the specified time or the confirmation message verification fails, the server can determine that the injection has failed and trigger corresponding exception handling procedures (such as retry or alarm) to ensure the consistency of the system state. After obtaining the key to be injected, a confirmation message is sent to the key injection server, the confirmation message including the third authentication tag generated based on the authentication key.

[0038] This embodiment completes the binding of the terminal identity identifier and public key, as well as the pre-authentication preparation work, through the above steps before sending the injection request. This allows the server to complete the request legitimacy screening using low-cost symmetric operations before performing high-overhead decryption or encapsulation operations, thereby effectively reducing the computational overhead on the terminal side and preventing malicious requests from consuming server resources.

[0039] Example 2: like Figure 1 and Figure 4 As shown, this embodiment provides a key injection method applied to a key injection server. This method demonstrates the overall process of key injection performed on the server side, establishing a logic of pre-authentication verification followed by high-overhead encapsulation. The overall process corresponds to the terminal-side process described in Embodiment 1, together forming a complete key injection interaction loop. The method includes the following steps: The system receives an injection request from a terminal device, the injection request including at least a terminal identity identifier, a transformation public key, dynamic parameters, and a first authentication tag; verifies the first authentication tag based on a preset shared key corresponding to the terminal identity identifier; after successful verification, generates a transformation factor based on the preset shared key, the terminal identity identifier, and the dynamic parameters using a deterministic derivation function, and performs an inverse operation on the transformation public key based on the transformation factor to restore the public key in the temporary key pair; performs key encapsulation based on the public key in the temporary key pair to generate encapsulated ciphertext and key material; constructs an interaction feature sequence containing the terminal identity identifier, the transformation public key, dynamic parameters, the first authentication tag, and the encapsulated ciphertext, and derives a session key and an authentication key based on the key material and the interaction feature sequence; encrypts the key to be injected based on the session key to generate the key ciphertext to be injected; generates a second authentication tag based on the authentication key; and sends a response message to the terminal device, the response message including the encapsulated ciphertext, the key ciphertext to be injected, and the second authentication tag.

[0040] The injection request is transmitted over the network to the server's communication interface. The server first parses the request message and extracts key fields. Among them, the terminal identity identifier is used to index the terminal's registration information; the transformed public key is a non-original public key processed by the terminal; dynamic parameters are used to prevent replay attacks; and the first authentication tag is the core credential for verifying the legitimacy of the request.

[0041] Upon receiving an injection request, the server searches the identity management database for a pre-set shared key uniquely bound to the terminal's identity. Using this pre-set shared key, the server recalculates the authentication tag based on the terminal's identity, transformed public key, and dynamic parameter fields in the request, employing the same message authentication code algorithm as the terminal. The server then compares the calculated result with the received first authentication tag. If they do not match, the request is deemed illegitimate or tampered with, and the request is discarded, terminating the process and preventing further high-overhead computations. This step utilizes low-computational-cost symmetric cryptography to create a highly efficient filtering barrier at the front end of the process.

[0042] After verifying the first authentication tag, the method further includes performing anti-replay checks on dynamic parameters and / or performing zero-trust verification on the injection request based on a context policy. This step builds a deep defense system on the server side, ensuring that even if an attacker intercepts legitimate historical request messages, they cannot steal server resources or keys through replay attacks.

[0043] During implementation, the server maintains an anti-replay database to store processed terminal device dynamic parameters, request indexes, or request digests. When the server receives a new injection request, it extracts the dynamic parameters, request index, or request digest and searches the anti-replay database. If the extracted content already exists in the history, the request is considered a replay attack, and the server discards the request and logs an alert. For example, if the dynamic parameter generated by the terminal is a random number Nc, the server stores Nc in the anti-replay database after processing the request and sets an expiration time (e.g., 24 hours). If the server receives another request containing the same Nc within the expiration time, it is considered a replay.

[0044] To meet the dynamic trust assessment requirements in high-security scenarios, zero-trust verification performs compliance checks on fields in context parameters. For example, the server checks whether the timestamp or time window information carried in the request is within the allowable error range of the current server time; verifies whether the terminal is located within an authorized geographical area based on the source IP address of the request or the location digest information reported by the terminal; and checks the device status information reported by the terminal.

[0045] Through the aforementioned multi-dimensional verification mechanism, continuous verification of the terminal's identity and environmental status is achieved. It should be understood that the replay protection check and zero-trust verification can be implemented individually or in combination. For example, in a high-security implementation scenario, the server can be configured to: first perform the replay protection check, then perform the zero-trust verification after passing both, and only proceed to the subsequent public key restoration step after both have passed.

[0046] After the initial authentication tag verification is successful, the key injection server reconstructs the public key in the temporary key pair based on the pre-set shared key. This mechanism of verification before reconstruction ensures that only legitimate requests can consume the server's core computing resources. During the reconstruction process, the server uses the pre-set shared key, terminal identity, and dynamic parameters to generate a transformation factor through a deterministic derivation function, and performs the inverse operation of a reversible transformation on the transformed public key, thereby recovering the public key from the original temporary key pair generated by the terminal device.

[0047] The server invokes the encapsulation algorithm, inputs the decrypted public key, and obtains the encapsulated ciphertext and randomly generated key material. Since encapsulation algorithms typically involve highly complex mathematical operations (such as modular exponentiation of large numbers or polynomial operations on lattices), the computational overhead is significant. Therefore, executing them after pre-authentication verification can significantly improve the system's resistance to attacks.

[0048] Finally, the server assembles the encapsulated ciphertext, the ciphertext of the key to be injected, and the second authentication tag into a response message and sends it back to the terminal device for the terminal device to perform decapsulation and decryption operations.

[0049] This embodiment executes a sequential logic of authentication first, then computation, which effectively solves the problem of server vulnerability to denial-of-service attacks and ensures the stability and security of the key injection service in a high-concurrency environment.

[0050] Example 3: like Figure 2 As shown, this embodiment provides a key injection system, including: The key injection server, deployed within the security domain, is configured to execute the key injection method described in Example 2. It is responsible for receiving injection requests, performing first authentication tag verification, restoring the basic temporary public key, calling the standard post-quantum key encapsulation algorithm, retrieving the quantum key, and generating a response message. An identity management database is used to maintain the mapping relationship between terminal identity identifiers and pre-set shared keys; The anti-replay library is used to cache processed terminal device dynamic parameters, request indexes, or request summaries to prevent the same request from being reused. The zero-trust policy verification module is used to evaluate the context parameters (time window information, location summary, device status summary, and remote measurement result summary) in the injection request round by round. The terminal security agent runs in a controlled execution environment of the remote terminal device. As the terminal device of the system, it is configured to execute the key injection method described in Example 1, and is responsible for generating temporary key pairs, generating transformed public keys, generating first authentication tags, initiating injection requests, decapsulating, restoring session-related key materials, and completing quantum key injection. The quantum key source interface is used to connect to a quantum key pool or quantum key distribution device and provide the key to be injected to the key injection server.

[0051] Figure 2 The modules shown are not simply connected in series, but form a collaborative structure with pre-authentication filtering first, followed by quantum encapsulation, and quantum key loading and result confirmation closing the loop.

[0052] Example 4: Combination Figure 3 The cross-domain deployment architecture shown in Example 3, the key injection system, operates between at least two independent physical security domains and remote terminal devices distributed outside.

[0053] Specifically, the system architecture of this embodiment includes security domain A (e.g., a production control center or a main station-side business security domain) and security domain B (e.g., a remote core computer room or a key escrow security domain). Security domain A houses the Alice quantum key distribution device and the main station business applications; security domain B houses the Bob quantum key distribution device and a key management entity (i.e., a key injection server); the remote terminal device is located outside the wide-area untrusted network and runs a terminal security agent internally. This remote terminal device communicates remotely with the key injection server in security domain B through untrusted channels such as public networks, private networks, or wireless bearer networks.

[0054] Combination Figure 3 The specific steps of the injection key flow and injection interaction process under multi-domain collaborative conditions include: Alice, a quantum key distribution device in security domain A, and Bob, a quantum key distribution device in security domain B, negotiate quantum key distribution through a dedicated physical quantum channel, and generate a shared quantum key synchronously at both ends. The main station business applications within security domain A obtain the shared quantum key through a secure interface within security domain A; The key injection server in security domain B retrieves the shared source key synchronized with that in security domain A from the quantum key distribution device Bob or the local trusted quantum key pool through the built-in quantum key source interface, and uses it as the key to be injected. The key injection server initiates a remote injection process to the remote terminal device via a wide area untrusted network. The specific process is described in Examples 1 and 2. Finally, the key to be injected is securely injected into the controlled execution environment of the remote terminal device in the form of authenticated and encrypted ciphertext. After successfully completing the decapsulation, decryption, and closed-loop confirmation of the key to be injected in this round, the remote terminal device can directly use the key to be injected to carry out subsequent end-to-end symmetric encrypted communication with the main station business application in security domain A in the wide area network.

[0055] The aforementioned cross-domain deployment architecture and key flow indicate that the core focus of this invention is not the physical generation mechanism of the quantum key itself, but rather, under the premise of maintaining absolute trustworthiness of the key source, to solve the problem of securely loading high-security-level keys from security domain B to remote terminal devices on the wide area network side through the collaboration of reversible public key transformation pre-authentication on the terminal side and low-cost initial screening and filtering on the server side.

[0056] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A key injection method, characterized in that, Applied to terminal devices, including: Generate temporary key pairs and dynamic parameters; Based on a pre-set shared key, terminal identity identifier, and dynamic parameters, a transformation factor is generated through a deterministic derivation function; based on the transformation factor, a reversible operation is performed on the public key in the temporary key pair to generate a transformed public key; A first authentication tag is generated based on a pre-set shared key and a request digest; the request digest includes the terminal identity identifier, the transformed public key, and dynamic parameters. Send an injection request to the key injection server. The injection request includes the terminal identity identifier, the transformed public key, dynamic parameters, and the first authentication tag. Receive a response message returned by the key injection server, the response message including encapsulated ciphertext, the ciphertext of the key to be injected, and a second authentication tag; Based on the private key in the temporary key pair, the encapsulated ciphertext is decapsulated to obtain key material; an interaction feature sequence containing terminal identity, transformed public key, dynamic parameters, first authentication tag and encapsulated ciphertext is reconstructed, and a session key and authentication key are derived based on the key material and interaction feature sequence; the second authentication tag is verified based on the authentication key, and after the verification is successful, the ciphertext to be injected is decrypted based on the session key to obtain the key to be injected.

2. The method according to claim 1, characterized in that, The reversible operation on the public key in the temporary key pair based on the transformation factor includes: performing a bitwise XOR operation on the data sequence of the public key in the temporary key pair and the key stream generated by the transformation factor; or performing a modular addition operation on the data sequence of the public key in the temporary key pair or the elements of a polynomial matrix using the transformation factor; or performing a symmetric encryption operation on the public key in the temporary key pair using the transformation factor as the key of a symmetric encryption algorithm.

3. The method according to claim 1, characterized in that, Generating the first authentication tag includes: performing a message authentication code operation on the request digest based on a preset shared key to generate the first authentication tag.

4. The method according to claim 1, characterized in that, The injection request and the request digest also include context parameters, which include one or more of time window information, location digest, device status digest, and remote measurement result digest.

5. The method according to claim 1, characterized in that, After obtaining the key to be injected, the method further includes: sending a confirmation message to the key injection server, the confirmation message including a third authentication tag generated based on the authentication key.

6. A key injection method, characterized in that, Applications include key injection servers, including: Receive an injection request sent by a terminal device. The injection request includes at least the terminal identity identifier, the transformation public key, dynamic parameters, and the first authentication tag. The first authentication tag is verified based on the preset shared key corresponding to the terminal identity identifier. After the verification is successful, a transformation factor is generated through a deterministic derivation function based on the preset shared key, the terminal identity identifier, and dynamic parameters. The transformation public key is then inversely operated on based on the transformation factor to restore the public key in the temporary key pair. Perform key encapsulation based on the public key in the temporary key pair to generate encapsulated ciphertext and key material; Construct an interaction feature sequence containing terminal identity identifier, transformation public key, dynamic parameters, first authentication tag and encapsulated ciphertext, and derive session key and authentication key based on key material and interaction feature sequence; The key to be injected is encrypted using the session key to generate the ciphertext of the key to be injected. Generate a second authentication tag based on the authentication key; A response message is sent to the terminal device, the response message including encapsulated ciphertext, the ciphertext of the key to be injected, and a second authentication tag.

7. The method according to claim 6, characterized in that, After verifying the first authentication tag based on the preset shared key corresponding to the terminal identity, the method further includes: performing a replay protection check on the dynamic parameters; and / or performing a zero-trust check on the injection request.

8. A key injection system, characterized in that, include: A key injection server, deployed within a security domain, is configured to perform the method as described in claim 6 or 7; An endpoint security agent runs in a controlled execution environment of a remote terminal device, wherein the terminal device of the system is configured to perform the method as described in any one of claims 1 to 5; An identity management database is used to maintain the mapping relationship between terminal identity identifiers and pre-set shared keys; The quantum key source interface is used to connect to a quantum key pool or quantum key distribution device and provide the key to be injected to the key injection server.

9. The system according to claim 8, characterized in that, The system also includes an anti-replay library, which caches processed terminal device dynamic parameters, request indexes, or request summaries to prevent the same request from being reused.

10. The system according to claim 8, characterized in that, The system also includes a zero-trust policy verification module, which is used to perform round-by-round judgment on the context parameters in the injection request.

Images