Distributed quantum key link control method and key management system

Abstract

The present application discloses a distributed quantum key link control method and a key management system (KMS). The method comprises: in KMS clusters, using a Raft distributed consensus algorithm to elect leader nodes; among the KMS clusters, synchronizing information of the current leader nodes of the KMS clusters, so that the leader nodes of the KMS clusters store full data of clients; the KMS clusters using charge keys of the corresponding clients for initialization authentication, and then performing key synchronization by means of QKD key relaying. According to the present application, in KMS nodes, a Raft distributed consensus algorithm is used to implement state consistency, avoiding possible single point of failure problems in centralized service, and improving the overall availability of the system.

Description

Distributed quantum key link control method and key management system

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on November 1, 2023, with application number 202311436073.0, and application name “Distributed Quantum Key Link Control Method and Key Management System”, all contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of quantum communication technology, and in particular to a distributed quantum key link control method and a key management system. Background Art

[0004] At present, as shown in Figure 1, in the user layer of the quantum key distribution (QKD) network, a cryptographic management service platform is generally used to uniformly manage multiple key management systems (KMS) to provide key management and cryptographic operation services to the outside world. For example, the patent application document with publication number CN111934871A provides information management for quantum key management service nodes and their connected key application devices through a quantum key management service center. The problems with this centralized service mode are: (1) once a centralized cryptographic management service platform fails, it will affect the use of the entire system; (2) there is a lack of security protection in the cluster master election process; (3) a single key management cluster is difficult to meet the security requirements of physical isolation of keys for different services.

[0005] Summary of the Invention

[0006] The technical problem to be solved by this application is how to provide a distributed quantum key link control method to avoid the single point failure problem that may exist in a single service and improve the overall availability of the system.

[0007] This application solves the above technical problems through the following technical means:

[0008] In a first aspect, the present application proposes a distributed quantum key link control method, the method comprising:

[0009] The KMS cluster uses the Raft distributed consensus algorithm (a consistency algorithm for managing replication logs) to elect a leader node.

[0010] KMS clusters synchronize information about the current leader nodes of each KMS cluster so that the leader nodes of each KMS cluster store all client data.

[0011] After the KMS cluster uses the corresponding client's injection key for initial authentication, it synchronizes the key through the QKD key relay.

[0012] In some embodiments of the present application, the KMS cluster uses the Raft distributed consensus algorithm to elect a leader node, including:

[0013] Within the KMS cluster, the candidate node sends a voting request to other nodes in the cluster, so that other nodes can verify the candidate node's HMAC (Hash-based Message Authentication Code) value using the candidate node's injection key.

[0014] After verification, it receives voting information sent by other nodes. The voting information is obtained by encrypting its own node ID (identifier), its own charging key number and voting results using its own charging key.

[0015] Use the node ID and charging key number corresponding to the node sending the voting information to obtain the corresponding charging key, and use the charging key to decrypt the voting information to obtain the voting result;

[0016] When the voting ratio of other nodes exceeds the set number, the candidate node is determined to be the leader node.

[0017] In some embodiments of the present application, after the vote share of other nodes exceeds a set number and the candidate node is determined to be the leader node, the method further includes:

[0018] The leader node sends an additional log message to other nodes in the cluster. The additional log message includes the leader node information and the HMAC signature obtained by encrypting the leader node information with the leader node's own injection key. The leader node information includes the leader node's node ID, the leader node's term number, the index and term number of the previous log entry, the log entry to be copied, the commit index, and the leader node's injection key number.

[0019] Receive responses to additional log messages sent by other nodes. After the HMAC signature is verified, the response is processed according to the Raft protocol rules (a distributed consensus algorithm for managing replicated logs) to generate additional log messages, and encrypted with the injection key of the node sending the response;

[0020] The response result is decrypted using the injection key corresponding to the sending node of the response result, and the status of the leader node itself and other nodes in the cluster are updated according to the Raft protocol rules.

[0021] In some embodiments of the present application, when a new KMS node joins the cluster, the method further includes:

[0022] The leader node receives the authentication request from the new KMS node. The authentication request is obtained by performing an HMAC operation on the ID of the new KMS node and the authentication key injected by the leader node.

[0023] The leader node synchronizes the authentication key to all follower nodes in the cluster.

[0024] In some embodiments of the present application, after the vote share of other nodes exceeds a set number and the candidate node is determined to be the leader node, the method further includes:

[0025] The leader node polls all nodes in the KMS cluster and sends requests to all other nodes in the KMS cluster to pull full data.

[0026] In some embodiments of the present application, KMS clusters synchronize information about the current leader node of each KMS cluster so that the leader node of each KMS cluster stores the full client data, including:

[0027] The leader nodes of each KMS cluster periodically send heartbeat information to each other. The heartbeat information is the metadata of all data on the KMS cluster corresponding to each leader node.

[0028] If a KMS cluster detects that its local data is inconsistent with the data on other KMS clusters, it sends a full pull request to obtain the full data.

[0029] In some embodiments of the present application, each KMS cluster corresponds to a QKD node, and is connected to the corresponding QKD node through the key manager KM (Key Manager) of the QKD node; the heartbeat information is encrypted using the cross-domain key generated by the QKD corresponding to the current KMS cluster.

[0030] In some embodiments of the present application, the method further comprises:

[0031] Receive write operation requests sent by the client. When the current node receives a write request for the instance that the node is responsible for, it directly writes to the instance.

[0032] When the current node receives a write request for an instance that it is not responsible for, it routes the request within the cluster and forwards the request to the corresponding node for writing.

[0033] Periodically execute synchronization tasks to synchronize all instance information of this node to all nodes in the cluster.

[0034] In some embodiments of the present application, the method further comprises:

[0035] When each node in the KMS cluster receives a read operation request, it queries the local node for the content corresponding to the read operation request and returns it.

[0036] In some embodiments of the present application, after the KMS cluster uses the corresponding client's injection key for initialization authentication, key synchronization is performed through the QKD key relay, including:

[0037] Receive an authentication request from the client, which carries the client ID, the cryptographic sequence i, and the SM3 (SM3 Cryptographic Hash Algorithm) digest of the key KAi. The key KAi is pre-charged to the client by the charging machine.

[0038] When the SM3 digest of KAi is verified to be consistent, the client's initial authentication is completed;

[0039] Key synchronization via QKD key relay.

[0040] In some embodiments of the present application, key synchronization is performed through QKD key relay, including:

[0041] The leader node of the KMS cluster corresponding to the service initiator queries the leader node address and corresponding QKD node information of the KMS cluster corresponding to the service receiver;

[0042] Using the sessionId (session identifier) ​​generated by the service initiator as the unique identifier, a key relay request is initiated to the corresponding key manager KM, so that the key manager KM requests the QKDN controller (Quantum Key Distribution Network Controller) to calculate the key relay link, perform QKD key relay, and complete key synchronization.

[0043] In a second aspect, the present application proposes a key management system, which includes:

[0044] The KMS cluster consistency module is used to select the leader node using the Raft distributed consensus algorithm within the KMS cluster;

[0045] The KMS inter-cluster consistency module is used to synchronize the information of the current leader node of each KMS cluster between KMS clusters, so that the leader node of each KMS cluster stores the full client data;

[0046] The cross-domain key relay module is used to initialize authentication using the corresponding client's injection key and then synchronize keys through the QKD key relay.

[0047] Thirdly, the present application proposes a distributed quantum key link control system, which includes: a quantum trunk and a quantum network, a quantum key management system arranged in each quantum metropolitan area network, the quantum key management system is connected to the quantum trunk and the quantum network via a quantum key distribution node, the quantum key management system is connected to the client, and the quantum key management system is used to execute the above-mentioned distributed quantum key link control method for key synchronization.

[0048] The advantages of this application are:

[0049] (1) This application distributes the functions of the Cryptographic Management Service Platform (CMSP) to the key management systems (KMS) within each quantum metropolitan area network. Each key management system (KMS) is peer-to-peer, avoiding the single point problem of CMSP. The Raft distributed consensus algorithm is used within the KMS node to achieve state consistency, avoiding the single point failure problem that may exist in centralized services and improving the overall availability of the system. At the same time, since the full client data is stored in each KMS, when initiating a cross-KMS service call, there is no need to query the CMSP for the target KMS address, and key relay can be completed, meeting the security requirements of physical isolation of keys for different services.

[0050] (2) The Raft protocol leader election process uses encryption with a key injection, which can improve the security of the distributed system and prevent malicious nodes or attackers from tampering with or forging messages, affecting the normal operation of the cluster.

[0051] (3) Due to factors such as network delay between KMS clusters, an AP (Availability and Partition Tolerance) distributed protocol is adopted to achieve eventual consistency. The consistency check across clusters is guaranteed to be secure through QKD key distribution.

[0052] (4) Utilize QKD key relay to distribute and control the distribution and use of quantum keys to meet the cross-domain key distribution and use in KMS cluster mode.

[0053] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] FIG1 is a schematic diagram of the structure of a password management service platform mentioned in the background technology of this application that uniformly manages multiple key management systems;

[0055] FIG2 is a schematic flow chart of a distributed quantum key link control method proposed in some embodiments of the present application;

[0056] FIG3 is a Raft node state transition diagram in some embodiments of the present application;

[0057] FIG4 is a schematic diagram of a QKD network key relay in some embodiments of the present application;

[0058] FIG5 is a schematic diagram of the structure of a quantum key management system proposed in some embodiments of the present application;

[0059] FIG6 is a schematic structural diagram of a distributed quantum key link control system proposed in some embodiments of the present application. DETAILED DESCRIPTION

[0060] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0061] As shown in FIG2 , some embodiments of the present application disclose a distributed quantum key link control method, which includes the following steps:

[0062] S10. The KMS cluster uses the Raft distributed consensus algorithm to elect a leader node.

[0063] S20: Synchronize the information of the current leader node of each KMS cluster between KMS clusters so that the leader node of each KMS cluster stores the full client data;

[0064] S30. After the KMS cluster uses the injection key of the corresponding client to perform initial authentication, it synchronizes the key through the QKD key relay.

[0065] This embodiment distributes the functions of the cryptographic management service platform CMSP to the key management systems KMS within each quantum metropolitan area network. Each key management system KMS is peer-to-peer, and the Raft distributed consensus algorithm is used within the KMS node to achieve state consistency. At the same time, since the full client data is stored in each KMS, when initiating a cross-KMS service call, there is no need to query the CMSP for the target KMS address. This avoids the single point failure problem that may exist in centralized services and improves the overall availability of the system.

[0066] In some embodiments of the present application, step S10: the KMS cluster uses the Raft distributed consensus algorithm to elect a leader node, which specifically includes the following steps:

[0067] S11. Within the KMS cluster, the candidate node sends a voting request message to other nodes in the cluster, so that other nodes use the candidate node's injection key to verify the candidate node's HMAC value;

[0068] S12. After verification, the node receives voting information from other nodes. The voting information is obtained by encrypting the node ID, the node key number, and the voting result using the node's own key.

[0069] S13. Obtain the corresponding charging key using the node ID and charging key number corresponding to the node sending the voting information, and use the charging key to decrypt the voting information to obtain the voting result;

[0070] S14: If the voting percentage of other nodes exceeds the set number, the candidate node is determined to be the leader node.

[0071] This embodiment uses the injection key to encrypt the Raft protocol leader election process, which can improve the security of the distributed system and prevent malicious nodes or attackers from tampering with or forging messages and affecting the normal operation of the cluster.

[0072] Specifically, Raft nodes have three states: follower, candidate, and leader. The transitions between these states are shown in Figure 3. Follower: Completely passive, unable to send any requests, and only accepting and responding to messages (units of information transmitted between nodes) from leaders and candidates. The initial state of each node after startup must be follower. Leader: Processes all requests from clients and copies logs to all followers. Leaders also need to actively send heartbeats to all followers to maintain their leadership position. Candidate: Used to run for a new leader (a candidate is created by a follower triggering a timeout).

[0073] In some embodiments of the present application, in step S14: after the vote share of other nodes exceeds a set number and the candidate node is determined to be the leader node, the method further includes the following steps:

[0074] S15. The leader node sends an additional log message to other nodes in the cluster. The additional log message includes the leader node information and the HMAC signature obtained by encrypting the leader node information using the leader node's own injection key. The leader node information includes the leader node's node ID, the leader node's term number, the index and term number of the previous log entry, the log entry to be copied, the commit index, and the leader node's injection key number.

[0075] S16. Receive the response results of the additional log messages sent by other nodes, process the additional log messages according to the Raft protocol rules after the HMAC signature verification is passed, and encrypt them using the injection key of the node sending the response results;

[0076] S17. Decrypt the response result using the injection key corresponding to the sending node of the response result, and update the status of the leader node itself and other nodes in the cluster according to the Raft protocol rules.

[0077] In detail, the leader node election process is as follows: when a node in the KMS cluster receives a voting request message, it uses the candidate's injection key to verify the candidate's HMAC value. If the verification passes, it decides whether to vote for the candidate according to the Raft protocol rules, and encrypts its own node ID, injection key number and voting result with its own injection key and sends them to other candidates.

[0078] When a candidate receives the voting results, it uses the voting node ID and the charging private key corresponding to the charging key number to decrypt the voting results. If it obtains the votes of the majority of nodes, it becomes the leader and sends an additional log message to other nodes. The message contains the leader's node ID, the leader's term number, the index and term number of the previous log entry, the log entry to be copied, the submission index, the leader's charging key number, and the HMAC value of the above information. The HMAC value is encrypted using the charging key corresponding to the leader's charging key number;

[0079] When a node receives an additional log message, it verifies the leader's HMAC signature using the charging key corresponding to the leader's charging key number. If the verification succeeds, it processes the additional log message according to the Raft protocol rules and encrypts the response result with its own charging key and sends it to the leader.

[0080] When the leader receives the response result, it uses the injection key corresponding to the sending node to decrypt the response result and updates the status of itself and other nodes according to the Raft protocol rules.

[0081] Specifically, leader elections are driven by a timeout: the Heartbeat / Election timeout. The random timeout is used to reduce the probability of split votes due to election collisions, and to prevent tie votes by using an odd number of nodes.

[0082] (1) The election process is as follows:

[0083] Follower–>Candidate (election timeout trigger)

[0084] Winning an election: Candidate–>Leader

[0085] Another node wins the election: Candidate–>Follower

[0086] No node wins the election for a period of time: Candidate–>Candidate.

[0087] (2) Election Action:

[0088] Current term++

[0089] Send a RequestVote RPC.

[0090] (3) New Leader Selection Principle (Maximum Submission Principle)

[0091] Candidates include log info in RequestVote RPCs(index&term of last log entry)

[0092] During elections, choose candidate with log most likely to contain all committed entries

[0093] Voting server V denies vote if its log is "more complete":(lastTermV>lastTermC)||((lastTermV==lastTermC)&&(lastIndexV>lastIndexC))

[0094] Leader will have "most complete" log among electing majority.

[0095] It should be noted that during a term, at most one leader is elected. If there is no leader, another leader will be elected in the next term. The term is a globally visible, increasing number that represents the period of influence a leader exercises. The term is incremented when a follower becomes a candidate. If a follower has not received a heartbeat from the leader for an extended period, it increments the term, becoming a candidate and initiating an election. The updated term is then sent to other nodes.

[0096] It should be noted that several time parameters that affect the success rate of Raft elections include:

[0097] (1) RTT (Round Trip Time): network delay;

[0098] (2) Heartbeat timeout: The heartbeat interval should usually be an order of magnitude smaller than the election timeout. This allows the leader to continue sending heartbeats to prevent followers from triggering elections.

[0099] (3) Election timeout: The time when the communication between the leader and followers times out and triggers the election;

[0100] (4) MTBF (Meantime Between Failure): Servers (server) continuous regular failure time interval RTT < <Heartbeat timeout<Election timeout(ET)<<MTBF。

[0101] Furthermore, after the leader node is elected, when a client sends a write request to the KMS cluster, the Raft protocol stipulates that only the leader node has the right to process the request. If a follower receives the request, it will forward it to the leader node. If a candidate receives the request, it will directly reject the request. The leader node packages the request received from the client into a record entry (a record in the log library) and stores it in the log library. Each entry has a globally increasing subscript log sequence number index (globally increasing log sequence number). The leader node will send a replication message to the entire cluster to synchronize the entry. If it receives a confirmation response from the majority of nodes in the cluster, it can return the ok (confirmed) flag to the client.

[0102] It should be noted that the Raft log format is: (TermId, LogIndex, LogValue), where (TermId, LogIndex) can identify a unique log.

[0103] The key requirements for log replication are:

[0104] (1) Continuity: Logs are not allowed to have gaps

[0105] (2) Validity:

[0106] The log values ​​(specific data or information stored in a log entry) of different nodes with the same term and logIndex (log sequence number) must be the same;

[0107] The log on the leader must be valid;

[0108] Whether the log on the Follower is valid can be determined by comparing it with the leader log.

[0109] (3) Followers log validity check: The AppendEntries RPC (remote procedure call) also carries the unique identifier of the previous log (prevTermId, prevLogIndex).

[0110] (4) Followers log recovery: The leader node decrements nextIndex (next log sequence number) and resends AppendEntries until it is consistent with the leader log.

[0111] (5) Snapshot and log compaction: Generate snapshots regularly, implement log compaction to accelerate startup and recovery, and InstallSnapshot to copy data to followers.

[0112] (6) CommitIndex (TermId, LogIndex): commitIndex refers to the latest log position that has reached a majority and can be applied to the state machine. After the log is copied to the followers, it is first persisted and cannot be applied to the state machine immediately. Only the leader knows whether the log has reached a majority and whether it can be applied to the state machine. Followers record the current commitIndex sent by the leader. All logs less than or equal to commitIndex can be applied to the state machine.

[0113] (7) CommitIndex promotion:

[0114] The leader carries the current commitIndex in the next AppendEntries RPC (including Heartbeat);

[0115] Followers check the validity of the log and accept the AppendEntries and update the local commitIndex at the same time. Finally, all logs less than or equal to commitIndex are applied to the state machine.

[0116] In some embodiments of the present application, when a new KMS node joins the cluster, the method further includes the following steps:

[0117] The leader node receives the authentication request from the new KMS node. The authentication request is obtained by performing an HMAC operation on the ID of the new KMS node and the authentication key injected by the leader node.

[0118] The leader node synchronizes the authentication key to all follower nodes in the cluster.

[0119] In this embodiment, when the KMS node is initialized, the leader node needs to inject a key as the authentication credential for joining the cluster. At the same time, the master node will synchronize the injected authentication key to all followers. The injected key used for authentication and authorization is protected by a security chip or software password module in each KMS node.

[0120] In some embodiments of the present application, in step S14: after the vote share of other nodes exceeds a set number and the candidate node is determined to be the leader node, the method further includes:

[0121] The leader node polls all nodes in the KMS cluster and sends requests to all other nodes in the KMS cluster to pull full data.

[0122] In some embodiments of the present application, step S20: synchronizing information of the current leader node of each KMS cluster between KMS clusters so that the leader node of each KMS cluster stores the full client data, includes:

[0123] The leader nodes of each KMS cluster periodically send heartbeat information to each other. The heartbeat information is the metadata of all data on the KMS cluster corresponding to each leader node.

[0124] If a KMS cluster detects that its local data is inconsistent with the data on other KMS clusters, it sends a full pull request to obtain the full data.

[0125] It should be noted that after the cluster is started, heartbeat information will be sent periodically between the leaders of each cluster. The heartbeat information mainly contains metadata of all data on each cluster (meta-information is used because it is necessary to ensure that the level of data transmission in the network is maintained at a low level).

[0126] In some embodiments of the present application, each KMS cluster corresponds to a QKD node, and is connected to the corresponding QKD node through the key manager KM of the QKD node; the heartbeat information is encrypted using the cross-domain key generated by the QKD corresponding to the current KMS cluster.

[0127] It should be noted that each cluster's leader node sends heartbeat messages to the leader nodes of other clusters at regular intervals to perform data verification requests. This verification process uses cross-domain encryption keys generated by QKD to prevent malicious nodes or attackers from tampering with or forging messages. If a cluster discovers that the data on another cluster is inconsistent with its local data during the data verification process, it will initiate a full pull request to complete the data.

[0128] Specifically, KMS clusters only need to synchronize information about the current leader node of each cluster to facilitate cross-domain key distribution between clusters. Due to factors such as network latency, this embodiment adopts an AP distributed protocol to achieve eventual consistency, specifically:

[0129] The leader node of each cluster is equal and can process write requests and synchronize new data to other nodes. The leader of each cluster is only responsible for part of the data and regularly sends the verification value of the data it is responsible for to other nodes to maintain data consistency. The leader node of each cluster independently processes read requests and responds locally in a timely manner. It also performs data verification regularly to ensure that the full amount of data is stored in the cluster.

[0130] Due to factors such as network delay between KMS clusters, this embodiment adopts an AP distributed protocol to achieve eventual consistency. The consistency check across clusters is guaranteed to be secure through QKD key distribution.

[0131] In some embodiments of the present application, the method further comprises:

[0132] Receive write operation requests sent by the client. When the current node receives a write request for the instance that the node is responsible for, it directly writes to the instance.

[0133] When the current node receives a write request for an instance that it is not responsible for, it routes the request within the cluster and forwards the request to the corresponding node for writing.

[0134] Periodically execute synchronization tasks to synchronize all instance information of this node to all nodes in the cluster.

[0135] It should be noted that for a cluster that has been started, in the process of a client initiating a write operation, the responsible node is first calculated based on the user information contained in the request (the user is load balanced within the cluster, and the node that matches the user ID is hashed as the responsible node), and the request is forwarded to the responsible node. The synchronization task is performed regularly to synchronize all instance information that this node is responsible for to other nodes. When the node receives any read request, it directly queries and returns it locally (because all instances are synchronized to each node), pulls data, and responds quickly.

[0136] In some embodiments of the present application, step S30: after the KMS cluster uses the corresponding client's injection key to perform initial authentication, key synchronization is performed through the QKD key relay, including the following steps:

[0137] S31. Receive an authentication request sent by the client. The authentication request carries information including the client ID, the password sequence i, and the SM3 digest of the key KAi. The key KAi is pre-charged to the client by the charging machine.

[0138] S32. When the SM3 digest of KAi is verified to be consistent, the client's initial authentication is completed;

[0139] S33. Perform key synchronization through QKD key relay.

[0140] Specifically, the client's security chip (SE) connects to a charging machine (CHR), which securely charges the quantum key generated by QKD into the security chip (SE). The initiator and receiver each use the previously charged key and their respective KMSs for initial authentication. Both the KMS and the client's security chip are pre-installed with charging keys. The client selects the charging key KAi with cryptographic sequence i in the security chip and sends the client ID, cryptographic sequence i, and the SM3 digest of the key KAi to the cryptographic management service system KMS. The KMS verifies that the SM3 digest of KAi is consistent, completing the initial authentication.

[0141] In some embodiments of the present application, step S33: performing key synchronization through QKD key relay specifically includes the following steps:

[0142] The leader node of the KMS cluster corresponding to the service initiator queries the leader node address and corresponding QKD node information of the KMS cluster corresponding to the service receiver;

[0143] Using the sessionId generated by the service initiator as the unique identifier, a key relay request is initiated to the corresponding key manager KM, so that the key manager KM requests the QKDN controller to calculate the key relay link, perform QKD key relay, and complete key synchronization.

[0144] It should be noted that the service initiator generates a globally unique sessionId, and directly queries the KMS cluster leader node address and the corresponding QKD node information of the receiver through the KMS cluster leader node corresponding to the initiator. The initiator's KMS cluster uses the sessionId as the unique identifier to initiate a key relay request to the corresponding KM. The KM requests the QKDN to calculate the key relay link. The KMA connects the relay node and the destination node, and performs the final XOR operation at the destination node. The relay node only needs to perform an XOR operation on the results of the previous and subsequent negotiations. For example, KM-B only needs to calculate KM-C only needs to calculate The destination node KM-D is finally calculated You can get the negotiated key between node A and node D. It is an XOR operation, as shown in Figure 4. This embodiment uses QKD key relay to distribute and control the distribution and use of quantum keys, meeting the cross-domain key distribution and use in the KMS cluster mode.

[0145] In addition, as shown in FIG5 , some embodiments of the present application disclose a key management system, which includes:

[0146] The KMS cluster consistency module 10 is used to select the leader node using the Raft distributed consensus algorithm within the KMS cluster;

[0147] The KMS inter-cluster consistency module 20 is used to synchronize the information of the current leader node of each KMS cluster between KMS clusters so that the leader node of each KMS cluster stores the full amount of client data;

[0148] The cross-domain key relay module 30 is used to perform key synchronization through the QKD key relay after initialization authentication using the injection key of the corresponding client.

[0149] In some embodiments of the present application, the KMS cluster consistency module 10 includes:

[0150] A voting request information sending unit is used for a candidate node in a KMS cluster to send a voting request information to other nodes in the cluster, so that other nodes can use the candidate node's injection key to verify the candidate node's HMAC value;

[0151] The voting information receiving unit is used to receive voting information sent by other nodes after verification. The voting information is obtained by encrypting the node ID, the key number and the voting result of the other node using its own key.

[0152] The voting information decryption unit is used to obtain the corresponding charging key using the node ID corresponding to the node sending the voting information and the charging key number, and decrypt the voting information using the charging key to obtain the voting result;

[0153] The leader node determination unit is used to determine the candidate node as the leader node when the voting ratio of other nodes exceeds the set number.

[0154] In some embodiments of the present application, the KMS cluster consistency module 10 further includes:

[0155] An additional log message sending unit is used to send additional log messages to other nodes in the cluster through the leader node. The additional log message includes the leader node information and the HMAC signature obtained by encrypting the leader node information with the leader node's own injection key. The leader node information includes the leader node's node ID, the leader node's term number, the index and term number of the previous log entry, the log entry to be copied, the submission index, and the leader node's injection key number.

[0156] The response receiving unit is used to receive the response results of the additional log messages sent by other nodes. After the HMAC signature verification is passed, the response result is processed according to the Raft protocol rules to generate the additional log message and encrypted with the injection key of the node sending the response result;

[0157] The status update unit is used to decrypt the response result using the injection key corresponding to the sending node of the response result, and update the status of the leader node itself and other nodes in the cluster according to the Raft protocol rules.

[0158] In some embodiments of the present application, the KMS cluster consistency module 10 further includes a node authentication module, which is specifically configured to:

[0159] The leader node receives the authentication request from the new KMS node. The authentication request is obtained by performing an HMAC operation on the ID of the new KMS node and the authentication key injected by the leader node.

[0160] The leader node synchronizes the authentication key to all follower nodes in the cluster.

[0161] In some embodiments of the present application, the KMS inter-cluster consistency module 20 is specifically configured to:

[0162] The leader nodes of each KMS cluster periodically send heartbeat information to each other. The heartbeat information is the metadata of all data on the KMS cluster corresponding to each leader node.

[0163] If a KMS cluster detects that its local data is inconsistent with the data on other KMS clusters, it sends a full pull request to obtain the full data.

[0164] In some embodiments of the present application, each KMS cluster corresponds to a QKD node, and is connected to the corresponding QKD node through the key manager KM of the QKD node; the heartbeat information is encrypted using the cross-domain key generated by the QKD corresponding to the current KMS cluster.

[0165] In some embodiments of the present application, the cross-domain key relay module 30 includes:

[0166] The initialization authentication unit is used to receive an authentication request from a client. The authentication request carries information including the client ID, the password sequence i, and the SM3 digest of the key KAi. The key KAi is pre-charged to the client by the charging machine. When the SM3 digest of KAi is verified to be consistent, the initialization authentication of the client is completed.

[0167] The key synchronization unit is used to use the leader node of the KMS cluster corresponding to the service initiator to query the leader node address and corresponding QKD node information of the KMS cluster corresponding to the service receiver; using the sessionId generated by the service initiator as the unique identifier, it initiates a key relay request to the corresponding key manager KM, so that the key manager KM requests the QKDN controller to calculate the key relay link, perform QKD key relay, and complete key synchronization.

[0168] It should be noted that other embodiments or implementation methods of the key management system provided in this application can refer to the above-mentioned method embodiments, which will not be repeated here.

[0169] In addition, as shown in Figure 6, some embodiments of the present application disclose a distributed quantum key link control system, which includes: a quantum trunk and a quantum network, a quantum key management system arranged in each quantum metropolitan area network, the quantum key management system is connected to the quantum trunk and the quantum network via a quantum key distribution node, the quantum key management system is connected to the client, and the quantum key management system is used to execute the distributed quantum key link control method of some of the above embodiments for key synchronization.

[0170] Specifically, the quantum key distribution module QKD is used to implement quantum key distribution with the quantum key distribution module of the connected node, so that both parties can obtain a key pair;

[0171] Key Manager KM: Responsible for receiving and managing the keys generated by QKD, relaying the keys and providing them to applications that require passwords.

[0172] QKDN Controller: Responsible for controlling various resources of the QKD network to ensure the secure, stable, efficient and robust operation of the QKD network.

[0173] Key Management System (KMS): responsible for creating and managing keys, protecting the confidentiality, integrity, and availability of keys, and meeting the key management requirements of applications and businesses.

[0174] It should be noted that other embodiments or implementation methods of the key management system in the distributed quantum key link control system provided in this application can refer to the above-mentioned method embodiments, which will not be repeated here.

[0175] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0176] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of such features. Throughout the description of this application, "plurality" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0177] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A distributed quantum key link control method, characterized in that: The method comprises: The KMS cluster uses the Raft distributed consensus algorithm to elect a leader node. The KMS clusters synchronize the information of the current leader nodes of each KMS cluster so that the leader nodes of each KMS cluster store the full amount of client data; After the KMS cluster uses the corresponding client's injection key for initial authentication, it synchronizes the key through the QKD key relay.

2. The distributed quantum key link control method according to claim 1, characterized in that: The KMS cluster uses the Raft distributed consensus algorithm to elect a leader node, including: The candidate node in the KMS cluster sends a voting request message to other nodes in the cluster, so that other nodes use the candidate node's injection key to verify the candidate node's HMAC value; After verification, the voting information sent by other nodes is received. The voting information is obtained by encrypting the node ID, the injection key number and the voting result of other nodes using their own injection keys. The node ID and the charging key number corresponding to the node sending the voting information are used to obtain the corresponding charging key, and the charging key is used to decrypt the voting information to obtain the voting result; When the voting ratio of other nodes exceeds the set number, the candidate node is determined to be the leader node.

3. The distributed quantum key link control method according to claim 2, characterized in that: The voting information is obtained by encrypting the node ID, the injection key number and the voting result of other nodes using their own injection keys, and also includes: The other nodes decide whether to vote for the candidate node according to the Raft protocol rules, and encrypt their own node ID, their own injection key number and the voting result with their own injection key and send them to the candidate node.

4. The distributed quantum key link control method according to claim 2, characterized in that: After the voting ratio of the other nodes exceeds a set number and the candidate node is determined to be a leader node, the method further includes: The leader node sends an additional log message to other nodes in the cluster. The additional log message includes the leader node information and the HMAC signature obtained by encrypting the leader node information with the leader node's own injection key. The leader node information includes the leader node's node id, the leader node's term number, the index and term number of the previous log entry, the log entry to be copied, the submission index, and the leader node's injection key number. Receive the response results of the additional log messages sent by other nodes, process the additional log messages according to the Raft protocol rules after the HMAC signature verification, and use the response results to send the filling of the node Key encryption; The response result is decrypted using the injection key corresponding to the sending node of the response result, and the status of the leader node itself and other nodes in the cluster are updated according to the Raft protocol rules.

5. The distributed quantum key link control method according to claim 1, characterized in that: The leader node election is driven by a timeout, which includes a heartbeat / election timeout.

6. The distributed quantum key link control method according to claim 2, characterized in that: When a new KMS node joins the cluster, the method further includes: The leader node receives the authentication request sent by the new KMS node, which is obtained by performing an HMAC operation on the ID of the new KMS node and the authentication key injected by the leader node; The leader node synchronizes the authentication key to all follower nodes in the cluster.

7. The distributed quantum key link control method according to claim 2, characterized in that: After the voting ratio of the other nodes exceeds a set number and the candidate node is determined to be a leader node, the method further includes: The leader node polls all nodes in the KMS cluster and sends requests to all other nodes in the KMS cluster to pull full data.

8. The distributed quantum key link control method according to claim 1, characterized in that: The KMS clusters synchronize the information of the current leader nodes of each KMS cluster so that the leader nodes of each KMS cluster store the full amount of client data, including: The leader nodes of each KMS cluster periodically send heartbeat information to each other. The heartbeat information is the metadata of all data on the KMS cluster corresponding to each leader node. If a KMS cluster detects that its local data is inconsistent with the data on other KMS clusters, it sends a full pull request to obtain the full data.

9. The distributed quantum key link control method according to claim 8, characterized in that: Each KMS cluster corresponds to a QKD node, and is connected to the corresponding QKD node through the key manager KM of the QKD node; the heartbeat information is encrypted using the cross-domain key generated by the QKD corresponding to the current KMS cluster.

10. The distributed quantum key link control method according to claim 2, characterized in that: The method further comprises: Receive write operation requests sent by the client. When the current node receives a write request for the instance that the node is responsible for, it directly writes to the instance. When the current node receives a write request for an instance that is not responsible for the node, it routes the request within the cluster and forwards the request to the corresponding node for writing. Periodically execute synchronization tasks to synchronize all instance information that this node is responsible for to all nodes in the cluster.

11. The distributed quantum key link control method according to claim 10, characterized in that: After receiving the write operation request sent by the client, the method further includes: Calculate the responsible node to which the write operation request belongs according to the user information contained in the write operation request, where the responsible node is the node obtained by hashing the user ID; The write operation request is forwarded to the responsible node.

12. The distributed quantum key link control method according to claim 10, characterized in that: The method further comprises: When each node in the KMS cluster receives a read operation request, it queries the content corresponding to the read operation request locally and returns it.

13. The distributed quantum key link control method according to claim 1, characterized in that: After the KMS cluster uses the injection key of the corresponding client to perform initial authentication, it performs key synchronization through the QKD key relay, including: Receive an authentication request sent by a client, the authentication request carrying information including a client ID, a password sequence i, and an SM3 digest of a key KAi, the key KAi being pre-charged to the client by a charging machine; When the SM3 digest of KAi is verified to be consistent, the client's initial authentication is completed; Key synchronization via QKD key relay.

14. The distributed quantum key link control method according to claim 13, characterized in that: The key synchronization through QKD key relay includes: The leader node of the KMS cluster corresponding to the service initiator queries the leader node address of the KMS cluster corresponding to the service receiver and the corresponding QKD node information; Using the sessionId generated by the service initiator as the unique identifier, a key relay request is initiated to the corresponding key manager KM, so that the key manager KM requests the QKDN controller to calculate the key relay link, perform QKD key relay, and complete key synchronization.

15. A key management system, characterized in that: The key management system comprises: KMS cluster consistency module, used to adopt the Raft distributed consensus algorithm in the KMS cluster to elect the leader node; The KMS inter-cluster consistency module is used to synchronize the information of the current leader nodes of each KMS cluster between KMS clusters, so that the leader node of each KMS cluster stores the full client data; The cross-domain key relay module is used to perform key synchronization through the QKD key relay after initializing authentication using the injection key of the corresponding client.

16. A distributed quantum key link control system, characterized in that: The system includes: a quantum trunk and a quantum network, a quantum key management system arranged in each quantum metropolitan area network, the quantum key management system is connected to the quantum trunk and the quantum network via a quantum key distribution node, the quantum key management system is connected to a client, and the quantum key management system is used to execute the distributed quantum key link control method according to any one of claims 1 to 14 for key synchronization.

Images