Qkd remote key distribution method, system, device and medium based on pqc channel

Abstract

The present application belongs to the technical field of quantum communication, and particularly relates to a QKD remote key distribution method, system, device and medium based on a PQC channel. In view of the fact that the prior art fails to coordinate performance overhead and risk exposure, the present application adopts the following technical solution: a QKD remote key distribution method based on a PQC channel, comprising: pre-storing a parent key in a service end in a hardware security module; establishing a temporary, forward-secure, anti-quantum-attack PQC authentication key exchange channel between a client and the service end, the service end performing identity authentication by using a standard PQC digital signature, and the client indirectly implementing identity authentication of the service end through a key encapsulation mechanism; the remotely distributed key is a one-time business key; and the business keys are used for encrypted communication between clients. The present application has the beneficial effect of resolving the contradiction between performance overhead and risk exposure through an asymmetric authentication protocol and a strict risk isolation architecture.

Description

Technical Field

[0001] This invention belongs to the field of quantum communication technology, specifically relating to a QKD remote key distribution method, system, device, and medium based on a PQC channel. Background Technology

[0002] Quantum key distribution (QKD) technology, based on the principles of quantum physics, can generate keys with information-theoretic security, making it a key technology for future secure communication. However, QKD systems rely on dedicated quantum channels (such as optical fibers), which have limited coverage and make it difficult to directly serve the numerous remote applications in wide area networks that lack direct fiber connections. This constitutes the "last mile" bottleneck for the widespread application of QKD technology.

[0003] Existing technologies attempt to use post-quantum cryptography (PQC) to construct secure channels (such as PQC-TLS) for remote distribution of QKD keys. However, this direct combination scheme faces two major, mutually constraining technical challenges:

[0004] 1. Performance overhead of remote authentication: To ensure channel security, both communicating parties (especially the client) need to authenticate each other. If PQC digital signature algorithms (such as CRYSTALS-Dilithium) are used for authentication, their huge computational overhead and signature size constitute an unbearable performance burden for remote devices (such as IoT terminals) with limited computing power, power consumption, or storage space.

[0005] 2. Risk Exposure of Core Security Assets: The original key generated by QKD is the root of trust for the entire system, possessing information-theoretic security and representing a highly valuable core security asset. Transmitting this "master key" directly through a generic PQC channel exposes this core asset to the complex attack surface of the wide area network. Any security vulnerability at the channel endpoint (gateway or terminal) could lead to a global leak of the master key, causing catastrophic consequences. This "all-or-nothing" risk model lacks depth defense and risk isolation for core assets.

[0006] Existing technologies have failed to provide a systematic solution that can simultaneously resolve the contradiction between the aforementioned performance overhead and risk exposure. Summary of the Invention

[0007] This invention addresses the shortcomings of existing technologies that use PQC to construct secure channels for remote QKD key distribution, failing to reconcile performance overhead and risk exposure. It provides a PQC-based remote QKD key distribution method that systematically resolves the conflict between performance overhead and risk exposure through a collaborative design. This invention also provides a PQC-based remote QKD key distribution system, a computer device, and a computer-readable storage medium.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: a QKD remote key distribution method based on a PQC channel, wherein the QKD remote key distribution method based on a PQC channel includes:

[0009] The master key generated by the QKD device is pre-stored on the server within the tamper-proof hardware security module;

[0010] A PQC authentication key exchange channel is established between the client and the server. The PQC authentication key exchange channel is a temporary, quantum-resistant encryption channel with forward secrecy. The server uses standard PQC digital signatures for identity authentication. The client indirectly authenticates the server by performing a key encapsulation mechanism with lower computational and communication overhead than PQC digital signatures.

[0011] Risk-isolated key distribution: The remotely distributed key is a one-time business key generated online through a key derivation function using a master key combined with the session context.

[0012] Clients use business keys for encrypted communication.

[0013] As an improvement, the establishment process of the PQC authentication key exchange channel includes:

[0014] The client generates a temporary client KEM key pair (eph_sk_c, eph_pk_c) and encapsulates the temporary public key eph_pk_c in a ClientHello message and sends it to the server.

[0015] Upon receiving a message from the client, the server responds immediately: First, it generates a temporary gateway KEM key pair (eph_sk_s, eph_pk_s). Then, it constructs a digest containing the temporary public keys of both parties and signs the digest using its long-term signing private key SK_S_Sig to generate a signature value Sig_S. Finally, it packages its own identity certificate Cert_S, the signature value Sig_S, the long-term KEM public key PK_S_KEM, and the temporary KEM public key eph_pk_s into a gateway message ServerFlight and returns it to the client.

[0016] After receiving the ServerFlight message from the gateway, the client performs the following verification and authentication steps: First, it verifies the validity of the gateway's identity certificate Cert_S using the pre-stored root certificate, and verifies the signature value Sig_S using the public key in the certificate, thus completing the authentication of the gateway. After successful authentication, the client performs two KEM encapsulation operations: one encapsulates the server's long-term KEM public key PK_S_KEM to generate a static shared secret ss_static and the corresponding ciphertext cA_static; the other encapsulates the gateway's temporary KEM key eph_pk_s to generate a temporary shared secret ss_eph and the corresponding ciphertext. The two shared secrets, cA_eph and cA_eph, are fused together using the key derivation function HKDF to form the final PQC session key SK_pqc_session and client authentication key Auth_Key. Finally, the client uses Auth_Key to calculate a message authentication code Auth_Tag_C that binds its own certificate Cert_C and the complete handshake record. The client then encrypts this authentication code, its own certificate, and the two KEM ciphertexts cA_static and cA_eph using the PQC session key SK_pqc_session, and sends them to the gateway as the client's secondary message ClientFlight.

[0017] After receiving the ClientFlight secondary message from the client, the server completes the final verification: it uses the client's long-term and temporary KEM private keys to decrypt the two KEM ciphertexts respectively, obtaining the static shared secret ss_static and the temporary shared secret ss_eph. It then derives the PQC session key SK_pqc_session and the client authentication key Auth_Key in the same way. Using the PQC session key, it decrypts the received data to obtain the client certificate Cert_C and the authentication code Auth_Tag_C. After verifying the validity of the client certificate Cert_C, the server independently calculates the expected authentication code and compares it with the received authentication code Auth_Tag_C. If they match, the client authentication is successful, and the PQC secure channel is officially established.

[0018] As an improvement, the key distribution phase includes the following steps:

[0019] First, client A initiates a service key request to server A through the established PQC secure channel. This request contains the target communication party AppB_ID.

[0020] After receiving the business key request, server A immediately initiates a synchronization negotiation protocol with peer server B. First, server A generates a session context SessionCtx containing a globally unique SessionID, a timestamp, and the IDs of both communicating parties. Then, server A sends the SessionCtx to peer server B through a preset cross-domain secure channel. After receiving it, server B verifies the validity of the request and returns an acknowledgment or rejection message to server A.

[0021] Once confirmation is received from peer server B, both servers simultaneously and independently perform key derivation operations within their respective HSMs.

[0022] Finally, the business key is distributed: Server A uses the PQC session key SK_pqc_session to encrypt the newly generated AK using the AEAD (Authenticated Encryption with Associated Data) algorithm, and then securely distributes it to application A through the established secure channel; at the same time, peer server B caches the AK and waits for application B to come online and establish a PQC channel before distributing the key to it.

[0023] As an improvement, before the client leaves the factory, the authorized agency burns its identity certificate and device unique identifier into its built-in security element (TPM / TEE); the hash value of the identity certificate is pre-registered in the server's whitelist database; TPM is a trusted platform module, and TEE is a trusted execution environment.

[0024] The client comes pre-installed with the root certificate of the authoritative CA, which is used to verify the validity of the identity certificate presented by the server when establishing a secure channel.

[0025] As an improvement, the server is linked with external policy decision points to dynamically decide whether to allow access based on the client's real-time dynamic attributes.

[0026] The server side includes a quantum key distribution gateway (QKDG). Before Phase 1, the same master key is pre-injected into the quantum key distribution gateway.

[0027] As an improvement, key lifecycle management is also included, which includes:

[0028] Rotation: The business key AK has a preset lifespan. After it expires, the application needs to re-initiate the request.

[0029] Revocation: Based on the Key Revocation List (KRL) mechanism, the server maintains a globally synchronized Key Revocation List (KRL), which is synchronized in a distributed database within the server cluster. When a business key AK is used, its unique ID is added to the KRL. Before each use of the business key AK, its validity is queried from the local server or the server actively pushes an update to ensure near real-time consistency of the key status.

[0030] As an improvement, this also includes deploying a highly available architecture, the deployment process of which includes:

[0031] The load balancer deployed at the front end distributes massive application requests to multiple stateless server computing nodes at the back end. These nodes share a distributed state database, which is responsible for storing key state information, including at least one of session context, whitelist, and key revocation list.

[0032] The QKD remote key distribution system based on the PQC channel employs the aforementioned QKD remote key distribution method based on the PQC channel. The QKD remote key distribution system based on the PQC channel includes:

[0033] Physical security domain A includes QKD node A and server A. Server A is directly connected to QKD node A through a dedicated, physically isolated interface. Server A holds a pair of post-quantum cryptography long-term signature key pairs for authentication and a pair of post-quantum cryptography long-term key encapsulation key pairs. The public key of the post-quantum cryptography long-term signature key pairs is encapsulated in an X.509 identity certificate Cert_S issued by an authoritative CA.

[0034] Physical security domain B includes QKD node B and server B. Server B is directly connected to QKD node B through a dedicated, physically isolated interface.

[0035] Client A communicates with server A via the PQC channel and has completed trusted registration and identity binding before access;

[0036] Client B communicates with server B via the PQC channel;

[0037] In this scenario, server A and server B communicate through a quantum encryption channel and share the same master key.

[0038] In this process, a temporary, forward-secret, quantum-resistant encrypted channel is established between client A and server A.

[0039] A computer device includes a processor and a storage medium, wherein a computer program is stored in the storage medium, and when the computer program is executed by the processor, it implements the aforementioned QKD remote key distribution method based on the PQC channel.

[0040] A computer-readable storage medium having a computer program stored thereon, which, when executed, implements the aforementioned QKD remote key distribution method based on a PQC channel.

[0041] The beneficial effects of the QKD remote key distribution method based on the PQC channel of the present invention are:

[0042] 1. An asymmetric authentication protocol is designed: In this protocol, the powerful server (Quantum Key Distribution Gateway QKDG) uses standard PQC digital signatures for identity authentication; while the less powerful client indirectly authenticates the server by performing a PQC key encapsulation (KEM) operation, which has significantly lower computational and communication overhead than signing. This design significantly reduces the implementation threshold and operational overhead for resource-constrained terminals while ensuring strong authentication security.

[0043] 2. A strict risk isolation architecture was designed: the original key generated by the QKD device is defined as the "Master Key (MK)" and strictly confined within the physically secure Hardware Security Module (HSM) to ensure that it never crosses the security domain boundary for transmission; what is distributed remotely is not the Master Key itself, but a one-time "Business Key (AK)" generated online by combining the Master Key with the session context through the Key Derivation Function (KDF); this design reduces the potential damage caused by attackers breaching the terminal or channel from the systemic and permanent risk of obtaining the Master Key to the session-level and temporary loss caused by obtaining only the current Business Key, thus achieving effective protection for QKD, a high-value and scarce security asset.

[0044] The QKD remote key distribution system, computer device, and computer-readable storage medium based on the PQC channel of the present invention implement the QKD remote key distribution method based on the PQC channel of the present invention and have all the beneficial effects of the QKD remote key distribution method based on the PQC channel of the present invention. Attached Figure Description

[0045] Figure 1 This is a flowchart of a QKD remote key distribution method based on a PQC channel according to an embodiment of the present invention.

[0046] Figure 2 This is an architecture diagram of a QKD remote key distribution system based on a PQC channel according to an embodiment of the present invention.

[0047] Figure 3 This is a schematic diagram of the specific process of the QKD remote key distribution method based on the PQC channel in an embodiment of the present invention (taking App A initiating communication to App B as an example).

[0048] Figure 4This is a schematic diagram of the QKDG high-availability cluster architecture according to an embodiment of the present invention. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be explained and described below. However, the following embodiments are only preferred embodiments of the present invention and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments in the implementation methods without creative effort are all within the protection scope of the present invention.

[0050] See Figure 1 The QKD remote key distribution method based on the PQC channel in this embodiment of the invention includes:

[0051] Phase 1: Establish a PQC authentication key exchange channel between the client and QKDG. The PQC authentication key exchange channel is a temporary, forward-secret, quantum-resistant encrypted channel.

[0052] Phase Two: Risk-Isolated Key Distribution;

[0053] Phase 3: Encrypted communication between clients;

[0054] Prior to Phase 1, the original key generated by the QKD device is stored in the QKDG within the tamper-proof hardware security module.

[0055] In Phase 1, QKDG uses standard PQC digital signatures for identity authentication. Clients indirectly authenticate their QKDG identity by executing KEM, a key encapsulation mechanism with computational and communication overhead far lower than that of signatures.

[0056] In Phase Two, the remotely distributed key is a one-time business key AK, which is generated online using the key derivation function KDF by combining the master key with the session context.

[0057] In Phase 3, clients use business keys for encrypted communication.

[0058] See Figure 2This embodiment of the QKD remote key distribution system based on a PQC channel involves a physical security domain A, a physical security domain B, application A (included in client A), and application B (included in client B). Physical security domain A contains QKD node A and QKDG A, while physical security domain B contains QKD node B and QKDG B. QKD node A injects an original key (master key MK) into QKDG A, and QKD node B injects the same (represented as symmetric or shared in the diagram) original key (master key MK) into QKDG B. QKD node A and QKD node B communicate via a quantum channel. QKDG A and QKDG B communicate via a cross-domain secure channel (encrypted public network communication link). A PQC authentication key exchange channel (PQC trust delivery channel) is established between application A and QKDG A, and a PQC authentication key exchange channel (PQC trust delivery channel) is established between application B and QKDG B. Application A and Application B communicate over a wide area network (non-secure domain). End-to-end encrypted communication between Application A and Application B uses a derived key (business key) AK.

[0059] In this embodiment, the quantum key distribution gateway (QKDG) is the core trust hub of the remote key distribution system, and its primary design principle is to achieve hardware-level security. To defend against software-level attacks, all critical security operations, especially the storage of the master key (MK) and the execution of the key derivation function (KDF), are enforced to be completed within a tamper-proof hardware security module (HSM) / trusted platform module (TPM). Each QKDG holds a pair of post-quantum cryptographic long-term signature key pairs (SK_S_Sig, PK_S_Sig) for authentication, with its public key encapsulated in an X.509 certificate Cert_S issued by an authoritative CA. Furthermore, to support the lightweight asymmetric authentication protocol proposed in this embodiment, the QKDG also holds a pair of post-quantum cryptographic long-term key encapsulation (KEM) key pairs (SK_S_KEM, PK_S_KEM). Secure injection of the master key is a crucial step in establishing physical security anchoring. In this embodiment, the QKDG connects directly to QKD nodes within the local physical security domain via a dedicated, physically isolated interface (such as SPI or PCIe). This interface utilizes a hardware-based authentication mechanism to ensure that the master key, after generation, can be directly and securely transmitted to the trusted execution environment of the HSM, without being exposed outside the QKDG's host operating system. To achieve key derivation synchronization across gateways, a long-term, two-way authenticated secure channel needs to be established between QKDGs, for example, using the standard PQC-TLS 1.3 protocol. To strengthen this channel, strict rate limiting and abnormal behavior detection mechanisms are implemented to prevent resource exhaustion attacks caused by malicious synchronization requests. Simultaneously, the initiator and receiver IDs included in all synchronization requests must be verified by the whitelist or policy of the peer QKDG to ensure that only communication between authorized entities can be processed.

[0060] In this embodiment, the remote application (client) serves as the foundation of trust for accessing the system, stemming from its pre-existing trusted registration and identity binding. Before leaving the factory, the client's identity certificate (Cert_C) and device unique identifier (ID) are burned into its built-in security element, such as TPM / TEE (Trusted Execution Environment), by an authorized authority. Simultaneously, the hash value of this certificate is pre-registered in QKDG's whitelist database, thus completing a static trusted binding. For more granular access control, a zero-trust architecture can also be incorporated. In this mode, QKDG collaborates with external Policy Decision Points (PDPs) to dynamically decide whether to allow access based on the client's real-time security status, behavioral profile, and other dynamic attributes. Furthermore, each client is pre-installed with the root certificate of an authoritative CA, used to verify the validity of the identity certificate (Cert_S) presented by QKDG when establishing a secure channel.

[0061] Phase 1: Establish a PQC authentication key exchange channel.

[0062] In this embodiment, the goal of establishing the PQC authentication key exchange channel is to create a temporary, forward-secret, quantum-resistant encrypted channel between the client and the QKDG. The entire interaction process follows the asymmetric lightweight authentication mode proposed in this embodiment.

[0063] The following explanation uses the interaction between client A (including application A) and QKDG A as an example. See [link to main process details] for details. Figure 3 .

[0064] The channel establishment process begins with client A. Application A generates a temporary KEM key pair (eph_sk_c, eph_pk_c) and encapsulates the temporary public key eph_pk_c in a ClientHello message and sends it to QKDG A.

[0065] QKDG A responds immediately upon receiving the message. It first generates its own temporary KEM key pair (eph_sk_s, eph_pk_s), then constructs a digest containing handshake information such as the temporary public keys of both parties, and signs the digest using its long-term signing private key SK_S_Sig, generating a signature value Sig_S. Subsequently, QKDG A packages its identity certificate Cert_S, signature Sig_S, long-term KEM public key PK_S_KEM, and temporary KEM public key eph_pk_s together into a ServerFlight message and returns it to the client.

[0066] Upon receiving a ServerFlight message, the client performs crucial verification and authentication steps. First, it verifies the validity of the QKDG certificate Cert_S using the pre-installed root certificate and verifies the signature Sig_S using the public key from the certificate, thus completing authentication of the server. After successful verification, the client performs two KEM encapsulation operations: one encapsulates the server's long-term KEM public key PK_S_KEM, generating a static shared secret ss_static and the corresponding ciphertext cA_static; the other encapsulates the server's temporary KEM public key eph_pk_s, generating a temporary shared secret ss_eph and the corresponding ciphertext cA_eph. These two shared secrets are then merged using a key derivation function (HKDF) to form the final PQC session key SK_pqc_session and the client authentication key Auth_Key. Finally, the client uses Auth_Key to calculate a message authentication code Auth_Tag_C that binds its own certificate Cert_C and the complete handshake record. The client then encrypts the authentication code, its own certificate, and two KEM ciphertexts cA_static and cA_eph using the session key SK_pqc_session, and sends them as a ClientFlight message to QKDG A.

[0067] The final step in establishing the channel is the final verification by the QKDG. Upon receiving the ClientFlight, QKDG A uses its long-term and temporary KEM private keys to decrypt the two ciphertexts, obtaining the static shared secret `ss_static` and the temporary shared secret `ss_eph`, and derives the PQC session key `SK_pqc_session` and the client authentication key `Auth_Key` in the same way. It uses the session key to decrypt the received data, obtaining the client certificate `Cert_C` and the authentication code `Auth_Tag_C`. After verifying the validity of `Cert_C` (e.g., by checking a whitelist), QKDG A independently calculates the expected authentication code and compares it with the received `Auth_Tag_C`. If they match, the client authentication is successful, and the PQC secure channel is officially established.

[0068] Phase Two: Risk-based Key Distribution.

[0069] After the PQC secure channel is established, the key distribution phase begins. The core of this phase is the synchronous negotiation between QKDGs to ensure the generation of symmetric business keys for both communicating parties, while ensuring that the master key (MK), which serves as the root of trust, does not leave the physical security domain.

[0070] First, application A initiates a service key request to QKDG A through the established PQC channel. This request contains the target communication party AppB_ID.

[0071] Upon receiving the request, QKDG A, as the initiator, immediately initiates a synchronization negotiation protocol with its peer, QKDG B. It first generates a session context (SessionCtx) containing a globally unique SessionID, a timestamp, and the IDs of both communicating parties (AppA_ID, AppB_ID). Then, QKDG A sends this SessionCtx to QKDG B via a pre-defined cross-domain secure channel. Upon receiving it, QKDG B verifies the validity of the request (e.g., checking if the policy allows communication) and returns an acknowledgment or rejection message to QKDG A.

[0072] Once QKDG B's confirmation is received, both parties' QKDGs simultaneously and independently perform key derivation operations within their respective HSMs. Since they share the same master key MK and a completely identical session context SessionCtx, they can compute the exact same business key AK using the key derivation function (e.g., AK = HKDF(salt=MK, IKM="QKD-derived-key", info=SessionCtx)). This operation ensures the symmetry, one-time use, and traceability of the business key.

[0073] Finally, the service key is distributed. QKDG A uses the PQC session key SK_pqc_session to encrypt the newly generated AK using the AEAD algorithm and securely distributes it to application A through the established secure channel. Meanwhile, QKDGB caches the AK, waiting for application B to come online and establish a PQC channel before distributing the key to it.

[0074] Phase 3: End-to-end encrypted communication and key lifecycle management.

[0075] End-to-end encrypted communication: Applications A and B share the same one-time symmetric business key AK, which originates from the QKD master key and can be directly used for authentication and encryption of end-to-end business data.

[0076] Key lifecycle management includes:

[0077] (1) Rotation: The business key AK has a preset lifespan (such as 24 hours or a specific business session). After the expiration, the application needs to re-initiate the request.

[0078] (2) Revocation: To address dynamic threats, this embodiment proposes a mechanism based on a Key Revocation List (KRL). QKDG maintains a globally synchronized Key Revocation List, which is synchronized in a distributed database within the QKDG cluster. When an AK is revoked (e.g., App A is added to the untrusted list), its unique ID is added to the KRL. Before each use of an AK, the application can query its validity from the local QKDG (or QKDG can proactively push an update), ensuring near real-time consistency of the key status.

[0079] Security Analysis

[0080] The protocol design in this embodiment further enhances security by introducing HSM and an explicit synchronization / revocation mechanism on the basis of the original.

[0081] Master Key Compromise Risk: The core architecture of this embodiment ensures that the master key MK never leaves the cryptographic boundaries of the HSM. All remotely distributed keys are one-time, time-limited business keys AK. Even if a single AK is compromised, the damage is strictly limited to specific time, space, and business operations, and will not jeopardize the foundation of trust in the system.

[0082] QKDG vulnerability: Even if the QKDG server's operating system is compromised, attackers cannot directly steal the MK or forge any AK because both MK and KDF operations are within HSM, greatly improving security.

[0083] Synchronization channel attack: The synchronization channel between QKDGs is protected by a strong security protocol (such as PQC-TLS) to resist eavesdropping and tampering.

[0084] System robustness and scalability

[0085] High Availability and DDoS Protection: To address single points of failure and performance bottlenecks, QKDG employs a high-availability architecture (such as...). Figure 4 (As shown). By deploying a load balancer at the front end, massive application requests are distributed to multiple stateless QKDG compute nodes at the back end. These nodes share a distributed state database, which is responsible for storing critical state information such as session context, whitelists, and key revocation lists (KRLs). This architecture not only achieves load balancing and failover but also provides the foundation for horizontal scaling of the system.

[0086] Scalability: For scenarios with large-scale application access, multiple geographically dispersed QKDG clusters can be deployed to form a federated key management system, further diversifying risks and optimizing network latency.

[0087] To further illustrate the technical advantages of the asymmetric authentication method in this embodiment, it is compared with the traditional scheme that uses PQC digital signatures for client authentication:

[0088] (1) Protocol Overhead and Efficiency: This embodiment significantly reduces performance overhead by embedding client authentication within the KEM operation. Taking the NIST Level 3 security standard as an example, the existing CRYSTALS-Dilithium signature operation requires millions of clock cycles on constrained platforms like the ARM Cortex-M4, while the CRYSTALS-Kyber key encapsulation operation used in this embodiment requires only hundreds of thousands of cycles, reducing computational overhead by nearly an order of magnitude. Regarding communication overhead, the Dilithium signature size is 2420 bytes, while the Kyber ciphertext size used in this embodiment is 1088 bytes, reducing the client's uplink data volume by more than 50%. This optimization is crucial for power- and bandwidth-sensitive IoT devices.

[0089] (2) Client implementation complexity: The client in this embodiment only needs to implement the KEM encapsulation algorithm, without integrating the PQC signature algorithm which has a larger code size and higher logical complexity. This greatly reduces the difficulty of firmware development and security auditing on resource-constrained devices (such as MCUs and low-power sensors).

[0090] (3) Security: The authentication protocol in this embodiment ensures security through the following mechanisms:

[0091] ① Resisting man-in-the-middle attacks: The server-side QKDG proves its identity to the client through Cert_S and Sig_S. The client verifies the signature, which can resist man-in-the-middle attacks.

[0092] ② Replay attack resistance: The handshake digest contains a random temporary public key eph_pk_c generated by the client, and the SessionCtx between QKDGs contains a unique SessionID and Timestamp, ensuring the timeliness and uniqueness of the handshake.

[0093] ③ Client Identity Forgery Prevention: The client encapsulates the long-term public key PK_S_KEM sent to the server to generate ss_static. Only a legitimate QKDG can decrypt cA_static and obtain the correct ss_static, thereby deriving the correct Auth_Key to verify Auth_Tag_C. Simultaneously, Auth_Tag_C is bound to the client certificate Cert_C and the complete handshake record, ensuring the authenticity of the identity.

[0094] This invention also discloses a QKD remote key distribution system based on a PQC channel, employing the aforementioned QKD remote key distribution method based on a PQC channel. The QKD remote key distribution system based on a PQC channel includes:

[0095] Physical security domain A includes QKD node A and QKDGA. QKDGA is directly connected to QKD node A through a dedicated, physically isolated interface. QKDGA holds a pair of post-quantum cryptography long-term signature key pairs for authentication and a pair of post-quantum cryptography long-term key encapsulation key pairs. The public key of the post-quantum cryptography long-term signature key pairs is encapsulated in an X.509 certificate Cert_S issued by an authoritative CA.

[0096] Physical security domain B includes QKD node B and QKDGB. QKDGB is directly connected to QKD node B through a dedicated, physically isolated interface.

[0097] Client A communicates with QKDGA via the PQC channel and has completed trusted registration and identity binding before access;

[0098] Client B communicates with QKDGB via the PQC channel;

[0099] Among them, QKDG A and QKDG B communicate through a quantum encryption channel and share the same master key;

[0100] In this process, a temporary, forward-secret, quantum-resistant encrypted channel is established between client A and QKDG A.

[0101] This invention also discloses a computer device, including a processor and a storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by the processor, it implements the aforementioned QKD remote key distribution method based on the PQC channel.

[0102] This invention also discloses a computer-readable storage medium storing a computer program that, when executed, implements the aforementioned QKD remote key distribution method based on a PQC channel.

[0103] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the content described in the above specific embodiments. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.

Claims

1. A QKD remote key distribution method based on a PQC channel, characterized in that: QKD remote key distribution methods based on PQC channels include: The master key generated by the QKD device is pre-stored on the server within the tamper-proof hardware security module; A PQC authentication key exchange channel is established between the client and the server. The PQC authentication key exchange channel is a temporary, quantum-resistant encryption channel with forward secrecy. The server uses standard PQC digital signatures for identity authentication. The client indirectly authenticates the server by performing a key encapsulation mechanism with lower computational and communication overhead than PQC digital signatures. Risk-isolated key distribution: The remotely distributed key is a one-time business key generated online through a key derivation function using a master key combined with the session context. Clients use business keys for encrypted communication. The process of establishing a PQC authentication key exchange channel includes: The client generates a temporary client key pair and encapsulates the temporary public key in a client message before sending it to the server. After receiving a message from the client, the server first generates a temporary gateway key pair, and then packages its own identity certificate, long-term public key, temporary public key, and signature value containing the temporary public keys of both parties into a gateway message and returns it to the client. After receiving the message from the gateway, the client first verifies the identity certificate and signature value. After successful authentication, it encapsulates the long-term public key and the temporary public key once to generate two shared secrets, which are then merged into the final session key and client authentication key. Finally, the client uses the client authentication key to calculate a message authentication code that binds its own certificate and complete handshake record, and sends the authentication code, its own certificate, and the two ciphertexts to the gateway after encrypting them with the session key. After receiving the secondary message from the client, the server uses its long-term and temporary private keys to decrypt the two ciphertexts respectively, obtaining two shared secrets. It then derives the session key and client authentication key in the same way. Using the session key, it decrypts the received data to obtain the client certificate and authentication code. After verifying the validity of the client certificate, it compares the independently calculated expected authentication code with the received authentication code. If they match, the client authentication is successful.

2. The QKD remote key distribution method based on a PQC channel according to claim 1, characterized in that: The key distribution phase includes: First, client A initiates a business key request to server A through the established PQC secure channel. This request includes the target communication party. After receiving the business key request, server A immediately initiates a synchronization negotiation protocol with peer server B. First, server A generates a session context containing a globally unique session ID, a timestamp, and the IDs of both communicating parties. Then, server A sends the session context to peer server B through a preset cross-domain secure channel. Upon receiving the request, peer server B verifies its validity and returns an acknowledgment or rejection message to server A. Once confirmation is received from peer server B, both servers simultaneously and independently perform key derivation operations within their respective hardware security modules. Finally, the business key is distributed: Server A encrypts the newly generated business key using the session key and securely distributes it to application A through the established secure channel; at the same time, peer server B caches the business key and waits for application B to come online and establish a PQC channel before distributing the key to it.

3. The QKD remote key distribution method based on a PQC channel according to claim 1, characterized in that: Before leaving the factory, the client's identity certificate and device unique identifier are burned into its built-in security element by an authorized agency; The hash value of the identity certificate is pre-registered in the server's whitelist database; The client comes pre-installed with the root certificate of the authoritative CA, which is used to verify the validity of the identity certificate presented by the server when establishing a secure channel.

4. The QKD remote key distribution method based on a PQC channel according to claim 1, characterized in that: The server works in conjunction with external policy decision points to dynamically decide whether to allow access based on the client's real-time dynamic attributes. The server includes a quantum key distribution gateway. Before Phase 1, the same master key is pre-injected into the quantum key distribution gateway.

5. The QKD remote key distribution method based on a PQC channel according to claim 1, characterized in that: It also includes key lifecycle management, which includes: Rotation: Business keys have a preset lifespan. After the key expires, the application needs to re-initiate the request. Revocation: Based on the key revocation list mechanism, the server maintains a globally synchronized key revocation list, which is synchronized in a distributed database within the server cluster. When a business key is used, its unique ID is added to the key revocation list. Before each use of a business key, its validity is queried from the local server or the server actively pushes an update to ensure near real-time consistency of the key status.

6. The QKD remote key distribution method based on a PQC channel according to claim 1, characterized in that: This also includes deployment using a high-availability architecture, the deployment process of which includes: The load balancer deployed at the front end distributes massive application requests to multiple stateless server computing nodes at the back end. These nodes share a distributed state database, which is responsible for storing key state information, including at least one of session context, whitelist, and key revocation list.

7. A QKD remote key distribution system based on a PQC channel, employing the QKD remote key distribution method based on a PQC channel as described in any one of claims 1 to 6, characterized in that: The QKD remote key distribution system based on the PQC channel includes: Physical security domain A includes QKD node A and server A. Server A is directly connected to QKD node A through a dedicated, physically isolated interface. Server A holds a pair of post-quantum cryptography long-term signature key pairs for authentication and a pair of post-quantum cryptography long-term key encapsulation key pairs. The public key of the post-quantum cryptography long-term signature key pairs is encapsulated in an identity certificate issued by an authoritative CA. Physical security domain B includes QKD node B and server B. Server B is directly connected to QKD node B through a dedicated, physically isolated interface. Client A communicates with server A via the PQC channel and has completed trusted registration and identity binding before access; Client B communicates with server B via the PQC channel; In this scenario, server A and server B communicate through a quantum encryption channel and share the same master key. In this process, a temporary, forward-secret, quantum-resistant encrypted channel is established between client A and server A.

8. A computer device, comprising a processor and a storage medium, wherein the storage medium stores a computer program, characterized in that: When the computer program is executed by a processor, it implements the QKD remote key distribution method based on the PQC channel as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: It stores a computer program that, when executed, implements the QKD remote key distribution method based on the PQC channel as described in any one of claims 1 to 6.

Images