A method, system, and node device for multi-node device key synchronization

Abstract

This application discloses a method, system, and node device for key synchronization among multiple node devices. The method includes: in response to a synchronization update command, importing key materials stored in a source node into a target node via a cloud server; specifically, the target node generates a first public-private key pair, including a first public key and a first private key; forwards the first public key to the source node via the cloud server; the source node generates a dynamic session key based on the first public key, encrypts the key materials to be synchronized, and obtains encrypted materials; and forwards the encrypted materials and the source node's second public key to the target node via the cloud server; the target node uses the first private key and the second public key to parse the encrypted materials, obtains the key materials, and imports them locally. This application enables automatic key synchronization in remote deployment scenarios, achieving encrypted and secure transmission of key information between nodes and adaptive consistency maintenance.

Description

Technical Field

[0001] This application relates to the field of information security technology, and more specifically, to a method, system, and node device for key synchronization among multiple node devices. Background Technology

[0002] With the rapid development of high-security businesses such as finance, telecommunications, and government, key-loading devices (KLDs) are widely used for key generation, injection, export, and signing operations. To achieve business continuity and disaster recovery capabilities, enterprises typically deploy multiple KLD systems in different locations and run them simultaneously.

[0003] However, in a multi-KLD system architecture, inconsistencies in keys between geographically dispersed nodes may arise due to network partitioning, deployment time differences, or manual maintenance errors, potentially leading to a series of security and operational risks. First, discrepancies may occur between signatures and verification results, resulting in authentication failures or abnormal interruptions to business transactions. Second, during cross-node switching or data synchronization, key mismatches may cause errors in user request processing or data inconsistencies, affecting service continuity. Furthermore, the dispersed and difficult-to-trace nature of key states significantly increases the complexity of security audits, hindering timely risk identification and compliance checks.

[0004] Therefore, the industry urgently needs a key synchronization method that can remotely achieve rapid synchronization of key content in a multi-KLD system architecture while ensuring the security of key content. Summary of the Invention

[0005] To address the aforementioned technical problems, this application discloses a method, system, and node device for key synchronization among multiple node devices. This method enables automatic key synchronization in remote deployment scenarios, achieving encrypted and secure transmission of key information between KLD nodes and adaptive consistency maintenance, thereby improving system security and operational efficiency. Specifically, the technical solution of this application is as follows: In a first aspect, this application discloses a method for key synchronization between multiple node devices, comprising: in response to a synchronization update command, importing key materials stored in the source node into the target node via a cloud server; Specifically, the steps include the following: The target node generates a first public-private key pair, including a first public key and a first private key; the first public key is forwarded to the source node through the cloud server; The source node generates a dynamic session key based on the first public key, encrypts the key material to be synchronized, and obtains encrypted material; then forwards the encrypted material and the source node's second public key to the target node through the cloud server. The target node uses the first private key and the second public key to parse the encrypted material, obtain the key material, and import it into the local machine.

[0006] In some implementations, the source node generates a dynamic session key based on the first public key, and encrypts the key material to be synchronized to obtain encrypted material; specifically including: After receiving the first public key, the source node exports the key material and generates a second public-private key pair, including the second public key and the second private key. Based on the first encryption algorithm, a first session key is generated using the second private key and the first public key; Based on the second encryption algorithm, the key material is encrypted using the first session key to obtain the encrypted material.

[0007] In some implementations, the target node uses the first private key and the second public key to parse the encrypted material, obtain the key material, and import it locally; specifically including: The target node calculates the second session key based on the first encryption algorithm, using the first private key and the second public key; Based on the second encryption algorithm, the encrypted material is parsed using the second session key, and the key material is obtained after parsing. The key material is synchronized to the target node.

[0008] In some implementations, the step of generating the first public-private key pair before the target node generates the following steps is included: The cloud server calls the bridging service of each node at fixed intervals to obtain the key distribution information of each node, so as to determine whether the key materials of each node need to be updated synchronously. If so, the node that needs to be synchronized and updated will be designated as the target node, and a synchronization request will be sent to the target node.

[0009] In some implementations, obtaining the key distribution information of each node to determine whether the key materials of each node need to be synchronized and updated specifically includes: The cloud server collects key distribution information from the key loading devices of each node, and the key distribution information includes key identifiers and public key modulo. Compare the key identifier lists of each node to determine if there are any missing or inconsistent key identifiers; if so, determine that the node needs to be synchronized and updated.

[0010] In some implementations, the forwarding of the encrypted material and the second public key of the source node to the target node via the cloud server specifically includes: The encrypted material and the second public key are encapsulated based on the specified data format to obtain encapsulated material; the encapsulated material is then forwarded to the target node via the cloud server.

[0011] In some implementations, the first public-private key pair and the second public-private key pair are dynamically generated based on the elliptic curve Diffie-Hellman key exchange algorithm and are used only for encryption and decryption processes in a single session.

[0012] Secondly, this application also discloses a system for key synchronization between multiple nodes, including a cloud server and several nodes; the nodes include at least a source node and a target node; the system is used to perform the steps of a method for key synchronization between multiple nodes as described in any of the above embodiments.

[0013] In some implementations, the cloud server communicates with each of the nodes via an encrypted channel; the encrypted channel has an authentication and access control mechanism.

[0014] Thirdly, this application also discloses a node device, which is the node in the method for key synchronization between multiple node devices described in any of the above embodiments; The node device includes: a bridging service module and a key loading device; The bridging service module is used to establish an encrypted channel between the node and the cloud server to send and receive instructions or data. The key loading device is used to store key materials and generate key distribution information based on the storage status of the key materials, so that the cloud server can determine whether the key materials need to be updated synchronously. The key loading device is also used to generate a public-private key pair based on the node identifier, encrypt the key material to be synchronized, and export the key material; or, it is used to parse the encrypted material and import the key material.

[0015] Compared with the prior art, this application has at least one of the following beneficial effects: 1. This application's solution adopts a two-way authentication key exchange mechanism based on a key exchange protocol. Each synchronization dynamically generates a unique temporary session key to encrypt transmitted materials, ensuring the confidentiality and integrity of key materials during transmission, resulting in a high level of security. Furthermore, the architecture of this application is designed for cross-regional and cross-platform scalability, enabling unified management and synchronization of key policies in multi-node scenarios.

[0016] 2. This application proactively checks the key status periodically through a preset strategy, autonomously completing full or incremental synchronization without manual intervention, greatly improving operational efficiency. When missing or inconsistent key materials are detected, it can be determined that the node needs to be synchronized and updated immediately. This design not only eliminates delays and oversights caused by human operation but also transforms key management into a monitorable system behavior, avoiding a series of security and operational risks caused by inconsistencies between active-active nodes.

[0017] 3. This application generates timestamp logs for each stage of key synchronization, including triggering, transmission, reception, and storage, supporting full traceability and queryability, and providing a chain of evidence for security incident analysis, compliance auditing, and operational responsibility determination. Attached Figure Description

[0018] The preferred embodiments will now be described in a clear and easy-to-understand manner, in conjunction with the accompanying drawings, to further explain the above-mentioned characteristics, technical features, advantages, and implementation methods of this application.

[0019] Figure 1 This is a schematic diagram of the structure of an embodiment of a system for key synchronization between multiple node devices according to this application; Figure 2 This is a flowchart illustrating the steps of an embodiment of a method for key synchronization between multiple node devices according to this application. Figure 3 This is a flowchart illustrating a sub-step of step S2 in another embodiment of a method for key synchronization between multiple nodes according to this application. Figure 4 This is a flowchart illustrating a sub-step of step S3 in another embodiment of a method for key synchronization between multiple nodes according to this application. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or sets.

[0022] To keep the drawings concise, each figure only schematically shows the parts relevant to the invention, and these do not represent the actual structure of the product. Furthermore, to facilitate understanding, in some figures, only one of components with the same structure or function is schematically depicted, or only one is labeled. In this document, "one" not only means "only one," but can also mean "more than one."

[0023] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] In this document, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0025] Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the specific implementation methods of this application will be described below with reference to the accompanying drawings. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without creative effort.

[0027] A Key-Loading Device (KLD) is a hardware device specifically designed for the secure generation, storage, transmission, and injection of keys, primarily used for key lifecycle management in cryptographic systems. It plays a core security role, securely loading key materials from a trusted generation or storage environment into the target encryption device terminal in a protected manner. The entire key management process is controllable and reliable, effectively reducing the risks faced by keys during distribution and loading. Therefore, KLDs are widely used in high-security applications such as finance, telecommunications, and government services.

[0028] In real-world business scenarios, enterprises typically deploy multiple KLD systems in different locations to ensure high service availability. However, it is difficult to keep the key states of nodes in different locations synchronized at all times, causing a series of business problems in actual operation: for example, different nodes may use inconsistent keys to generate different digital signatures for the same data, resulting in signature verification failure and interruption of related business; when users request to switch between different nodes, encryption and decryption failures or data processing errors may also occur due to key mismatch, affecting business continuity, etc.

[0029] In existing technical solutions, key synchronization between KLD nodes located in different geographical locations typically relies on manually sending the physical KLD devices online. The specific process involves a security officer connecting the delivered KLD to a bridging service in a secure data center to complete the key import and export operations. However, this method is not only labor-intensive during the physical transportation of the KLD devices but also carries potential risks of data leakage, which could threaten key security, thus limiting its practicality.

[0030] To address the technical shortcomings caused by key inconsistencies between remote nodes, this application discloses a method, system, and node device for key synchronization among multiple nodes. This method enables automatic key synchronization in remote deployment scenarios, achieving encrypted and secure transmission of key information between KLD nodes and adaptive consistency maintenance, thereby improving system security and operational efficiency. (See attached specification.) Figure 1 As shown, Figure 1 The diagram shows a structural schematic of a multi-node device key synchronization system according to this embodiment. The system includes a cloud server and several nodes. The nodes include at least a source node and a target node. The cloud server communicates with each node via an encrypted channel. In response to a synchronization update command, the key material stored in the source node is imported into the target node through the cloud server.

[0031] Specifically, before executing the steps, a bridging service needs to be deployed at each local node to act as a communication proxy between the local KLD and the cloud, responsible for the interface encapsulation and data transmission of key-related operations. The bridging service provides standardized interfaces to the upper-layer cloud server, mainly including interfaces for obtaining local KLD key distribution information, exporting specified keys, and importing received keys.

[0032] Reference manual attached Figure 2 As shown, this embodiment of a method for key synchronization between multiple node devices specifically includes the following steps: S1, the target node generates the first public-private key pair, including the first public key and the first private key. The first public key is forwarded to the source node through the cloud server.

[0033] refer to Figure 1Optionally, in this embodiment, the first node is used as the target node and the second node as the source node. If the first node needs to update its key, the key material stored in the second node is imported into the first node.

[0034] In practice, the cloud server sends a synchronization request to the first node, requesting to obtain the first node's public key. Upon receiving the request, the first node's KLD dynamically generates a first public-private key pair, including a first public key and a first private key.

[0035] Optionally, the first public-private key pair of the first node is an asymmetric key pair generated based on the Elliptic-curve Diffie–Hellman Key Exchange (ECDH) algorithm. ECDH is an encryption protocol used to negotiate shared keys over insecure channels. In other optional implementations, those skilled in the art can also generate the node's public-private key pair based on other asymmetric encryption algorithms, which will not be described in detail here.

[0036] In some alternative implementations, the generated public-private key pairs are associated with unique node identifiers to ensure that each key pair can be accurately mapped to its respective node entity, thereby enabling precise identification and key management of node objects in a distributed system.

[0037] After the KLD module generates the first public-private key pair, it securely stores the first private key locally, and simultaneously transmits the first public key from the first key pair to the cloud server for distribution via the bridging service.

[0038] S2, the source node generates a dynamic session key based on the first public key, encrypts the key material to be synchronized, and obtains encrypted material. Then, it forwards the encrypted material and the source node's second public key to the target node via a cloud server.

[0039] Specifically, after receiving the target node's first public key, the source node dynamically negotiates and generates a temporary session key based on this first public key. This session key is then used to encrypt the original key material to be distributed, forming an encrypted data packet. Subsequently, the source node submits this encrypted data packet along with its own public key to the cloud server, which is then responsible for securely forwarding it to the designated target node.

[0040] S3, the target node uses the first private key and the second public key to parse the encrypted material, obtain the key material, and import it into the local machine.

[0041] Specifically, after receiving the encrypted materials and the source node's second public key, the target node will use its own first private key and the received second public key to perform key negotiation operations, restore the session key used by the sender for encryption, and then use the session key to decrypt the encrypted materials, recover the original key materials, and securely import them into the local key storage area, thereby completing cross-node key synchronization and secure deployment.

[0042] This application provides another embodiment of a method for key synchronization between multiple node devices. Based on the above method embodiment, please refer to the appendix to the specification. Figure 3 As shown, step S2 specifically includes the following sub-steps: S21, after receiving the first public key, the source node exports the key material and generates a second public-private key pair, including the second public key and the second private key.

[0043] Specifically, after receiving the first public key uploaded by the first node, the cloud server forwards it to the second node, which is the source node. In practice, after receiving the first public key forwarded by the first node, the second node calls the KLD service. First, the second KLD generates a second public-private key pair based on itself. Optionally, the second public-private key pair is an asymmetric key pair generated based on the Elliptic Curve Diffie–Hellman Key Exchange (ECDH) algorithm, which will not be elaborated in detail in this embodiment.

[0044] S22, based on the first encryption algorithm, use the second private key and the first public key to generate the first session key.

[0045] Specifically, the second KLD of the second node uses its own generated second private key and the first public key received from the first node to calculate a one-time session key using a first encryption algorithm. Optionally, the first encryption algorithm is an Elliptic Curve Cryptography (ECC) algorithm, which will not be described in detail in this embodiment.

[0046] S23, based on the second encryption algorithm, the key material is encrypted using the first session key to obtain encrypted material.

[0047] Specifically, a second encryption algorithm is used to encrypt and protect the key materials to be synchronized locally based on the session key. Optionally, the second encryption algorithm is the Advanced Encryption Standard (AES) algorithm based on symmetric-key cryptography, which will not be described in detail in this embodiment.

[0048] In some alternative implementations, step S2 further includes a sub-step: S24: Encapsulate the encrypted material and the second public key according to the specified data format to obtain the encapsulated material. The encapsulated material is then forwarded to the target node via a cloud server.

[0049] Specifically, in this embodiment, the encrypted key material and related metadata are encapsulated according to a specified transmission structure and returned to the cloud server to complete the subsequent cross-node secure synchronization process.

[0050] Optionally, in specific implementation, the KLD of the second node encapsulates the encrypted key material and its own generated second public key in a TLV structured format. The encapsulation format includes: a Tag field to identify the data item type, a Length field to accurately record the length of subsequent data, and a Value field to store the actual second public key and encrypted material. After encapsulation, the complete TLV data packet is returned to the cloud server through the bridging service for subsequent forwarding to the target node to complete the key synchronization process.

[0051] This application provides another embodiment of a method for key synchronization between multiple node devices. Based on any of the above embodiments, refer to the appendix to the specification. Figure 4 As shown, step S3 specifically includes the following sub-steps: S31, the target node calculates the second session key using the first private key and the second public key based on the first encryption algorithm.

[0052] Specifically, the target node receives the encapsulated data forwarded by the cloud server, first parses the encapsulated data, and extracts the source node's second public key and encryption material.

[0053] After obtaining the encrypted materials and the second public key of the source node, the second KLD first uses the key negotiation mechanism to perform calculations on its pre-generated first private key and the received second public key to derive a temporary session key that matches the encryption end.

[0054] S32, based on the second encryption algorithm, uses the second session key to parse the encrypted material, and obtains the key material after parsing.

[0055] Specifically, the second KLD uses the session key to decrypt the encrypted material and extract the original key material.

[0056] S33, synchronize the key material to the target node.

[0057] Specifically, the second KLD securely stores the decrypted key material in the local key management module of the target node, thereby achieving reliable synchronization and consistency maintenance of the key among distributed nodes.

[0058] Based on any of the above embodiments, this application discloses another embodiment of a method for key synchronization between multiple node devices, which further includes the following before step S1 is executed: S01, the cloud server calls the bridging service of each node at fixed intervals to obtain the key distribution information of each node in order to determine whether the key materials of each node need to be updated synchronously.

[0059] The cloud server periodically polls the bridging service interface of each node to collect and aggregate the list of unique key identifiers stored in the KLD of each node. By comparing the Key ID sets between different nodes, the system can detect in real time whether there are missing keys or inconsistent versions. Specifically, the cloud server collects key distribution information reported by each node's KLD. This key distribution information includes key identifiers and their corresponding public key modulo. By comparing the key identifier lists of different nodes, the system can detect in real time whether there are missing key identifiers or inconsistent versions, thereby accurately determining whether the key status of each node in the distributed environment is consistent. If there is inconsistency or missing key identifiers, it is determined that the node needs to be synchronized and updated.

[0060] S02, if so, then the node that needs to be synchronized and updated is taken as the target node, and a synchronization request is sent to the target node.

[0061] Specifically, once a discrepancy is detected, the key synchronization process will be automatically triggered to ensure the consistency and integrity of the key status of each node in the distributed system.

[0062] Optionally, in addition to determining the target node, it also includes: S03, determining the source node.

[0063] In some alternative implementations, the source node is specified before key synchronization is performed. To ensure the accuracy and validity of the synchronized content, when selecting the source node, it must be confirmed that the key material stored locally has been updated to the latest version, thereby avoiding the distribution of expired or invalid key material to the target node.

[0064] In some alternative implementations, the source node is determined by the cloud server during key synchronization. The cloud server obtains the key distribution information of each node, determines and selects the node with the most complete key distribution information list as the source node.

[0065] In some alternative implementations, if the cloud server periodically or automatically detects that the key material of one of the nodes has been updated, it will automatically use the first updated node as the source node, thereby achieving synchronous updates to other nodes.

[0066] This application provides another embodiment of a method for key synchronization between multi-node devices. In this embodiment, to ensure the traceability of the key synchronization process while implementing the above steps, a unique task ID is generated for each synchronization operation, and detailed logs including trigger time, node information, key version, and operation result are recorded, supporting complete audit tracing. Simultaneously, the system supports parallel batch synchronization of multiple keys, achieving concurrent processing through task scheduling to improve efficiency. If a temporary failure is encountered during execution, the system will automatically retry according to a preset strategy and notify manual intervention after a retry failure, thereby enhancing the system's robustness while ensuring consistency.

[0067] Based on the same concept, this application also discloses a system for key synchronization between multiple nodes. The system includes a cloud server and several nodes. The nodes include at least a source node and a target node. The system is used to perform the steps of a method for key synchronization between multiple nodes as described in any of the above embodiments.

[0068] In some implementations, the cloud server communicates with each node via an encrypted channel. This encrypted channel includes authentication and access control mechanisms.

[0069] Specifically, all communication between the cloud server and each node is conducted through a two-way encrypted channel. This channel is established using a two-way identity authentication mechanism based on digital certificates to ensure that both communicating parties are trusted entities and to prevent unauthorized nodes from accessing the network.

[0070] Optionally, after successful authentication, the system will perform fine-grained permission verification on the types of operations that a node can request and the range of keys that it can access, based on predefined access control policies, to ensure that each node can only perform operations within its authorized scope, thus guaranteeing information security during the operation process.

[0071] Based on the same concept, this application also discloses a node device, which is a node in the method for key synchronization between multiple node devices described in any of the above embodiments.

[0072] The node device includes a bridging service module and a key loading device.

[0073] The bridging service module is used to establish an encrypted channel between the node and the cloud server to send and receive commands or data.

[0074] The key loading device is used to store key materials and generate key distribution information based on the storage status of the key materials, so that the cloud server can determine whether the key materials need to be updated synchronously.

[0075] The key loading device is also used to generate public-private key pairs based on node identifiers, encrypt the key materials to be synchronized, and export the key materials. Alternatively, it can be used to parse encrypted materials and import the key materials.

[0076] In some embodiments, the node device is an encrypted device terminal equipped with a key loading device. Optionally, the encrypted device terminal includes financial payment devices such as bank POS machines and ATMs; or high-security terminal devices with dedicated key injection and management functions. This application does not specifically limit the type of device.

[0077] The method, system and node device for key synchronization among multiple node devices disclosed in this application have the same technical concept, and the technical details of the embodiments of the three are applicable to each other. To reduce repetition, they will not be described again here.

[0078] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of program modules is merely an example. In practical applications, the above functions can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program units or modules to complete all or part of the functions described above. The program modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software program unit. Furthermore, the specific names of the program modules are only for easy differentiation and are not intended to limit the scope of protection of this application.

[0079] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for key synchronization among multiple node devices, characterized in that, The method includes: in response to a synchronization update command, importing the key material stored in the source node into the target node via a cloud server; Specifically, the steps include the following: The target node generates a first public-private key pair, including a first public key and a first private key; the first public key is forwarded to the source node through the cloud server; The source node generates a dynamic session key based on the first public key, encrypts the key material to be synchronized, and obtains encrypted material; then forwards the encrypted material and the source node's second public key to the target node through the cloud server. The target node uses the first private key and the second public key to parse the encrypted material, obtain the key material, and import it into the local machine.

2. The method for key synchronization between multiple node devices as described in claim 1, characterized in that, The source node generates a dynamic session key based on the first public key, and encrypts the key material to be synchronized to obtain encrypted material. Specifically, it includes: After receiving the first public key, the source node exports the key material and generates a second public-private key pair, including the second public key and the second private key. Based on the first encryption algorithm, a first session key is generated using the second private key and the first public key; Based on the second encryption algorithm, the key material is encrypted using the first session key to obtain the encrypted material.

3. The method for key synchronization between multiple node devices as described in claim 2, characterized in that, The target node uses the first private key and the second public key to parse the encrypted material, obtain the key material, and import it locally; specifically including: The target node calculates the second session key based on the first encryption algorithm, using the first private key and the second public key; Based on the second encryption algorithm, the encrypted material is parsed using the second session key, and the key material is obtained after parsing. The key material is synchronized to the target node.

4. A method for key synchronization between multiple node devices as described in any one of claims 1-3, characterized in that, Before the target node generates the first public-private key pair, the following steps are also included: The cloud server calls the bridging service of each node at fixed intervals to obtain the key distribution information of each node, so as to determine whether the key materials of each node need to be updated synchronously. If so, the node that needs to be synchronized and updated will be designated as the target node, and a synchronization request will be sent to the target node.

5. The method for key synchronization between multiple node devices as described in claim 4, characterized in that, The step of obtaining the key distribution information of each node to determine whether the key materials of each node need to be synchronized and updated specifically includes: The cloud server collects key distribution information from the key loading devices of each node, and the key distribution information includes key identifiers and public key modulo. Compare the key identifier lists of each node to determine if there are any missing or inconsistent key identifiers; if so, determine that the node needs to be synchronized and updated.

6. The method for key synchronization between multiple node devices as described in claim 5, characterized in that, The process of forwarding the encrypted material and the second public key of the source node to the target node via the cloud server specifically includes: The encrypted material and the second public key are encapsulated based on the specified data format to obtain encapsulated material; the encapsulated material is then forwarded to the target node via the cloud server.

7. The method for key synchronization between multiple node devices as described in claim 2, characterized in that, The first public-private key pair and the second public-private key pair are dynamically generated based on the elliptic curve Diffie-Hellman key exchange algorithm and are used only for encryption and decryption processes in a single session.

8. A system for key synchronization between multiple nodes, comprising a cloud server and several nodes; wherein the nodes include at least a source node and a target node; characterized in that, The system is invoked to implement the steps of a method for key synchronization between multiple node devices as described in any one of claims 1-7.

9. A system for key synchronization between multiple node devices as described in claim 8, characterized in that, The cloud server communicates with each of the nodes through a preset encrypted channel; the encrypted channel has an authentication and access control mechanism.

10. A node device, characterized in that, The node device is the node in the method for key synchronization between multiple node devices as described in any one of claims 1-7; The node device includes: a bridging service module and a key loading device; The bridging service module is used to establish an encrypted channel between the node and the cloud server to send and receive instructions or data. The key loading device is used to store key materials and generate key distribution information based on the storage status of the key materials, so that the cloud server can determine whether the key materials need to be updated synchronously. The key loading device is also used to generate a public-private key pair based on the node identifier, encrypt the key material to be synchronized, and export the key material; or, it is used to parse the encrypted material and import the key material.

Images