Data encryption method and system and storage medium

Abstract

The invention discloses a data encryption method and system and a storage medium, and the method comprises the steps: firstly, a central coordination node generates an initial master key, derives a first data encryption key, creates a first version node of a global key version chain, and carries out the distribution; establishing a local key version chain copy by each node, marking the local key version chain copy as a head node, and setting a local active pointer to point to the node; during encryption, a sender encrypts a plaintext by using a current version key, and embeds a serial number and hash; the receiver verifies continuity and hash, version use evidences are generated and reported after decryption, and the central coordination node collects the version use evidences into a global version state track; when the track triggers an updating condition, the central coordination node generates a new key and a candidate version node through a chain cryptography algorithm and a distribution obstacle coefficient based on the current version, and distributes and calculates timeout time; each node takes the node as a to-be-selected successor; and finally, according to the local chain and the timeout time, each node carries out multi-level activation verification based on the local observation distribution completion rate on the candidate nodes and feeds back a processing result.

Description

Technical Field

[0001] This invention relates to the field of data encryption, and more particularly to a data encryption method, system, and storage medium. Background Technology

[0002] Dynamic key updates are a core mechanism for ensuring long-term communication security in distributed encryption systems. Traditional dynamic key update methods typically involve a central coordinating node periodically generating new keys and broadcasting them to all participating nodes. Upon receiving the new key, each node either switches to the new key within a fixed time window or immediately. However, traditional methods suffer from the following significant technical drawbacks when applied to large-scale, geographically dispersed, and heterogeneous distributed systems:

[0003] First, in real-world large-scale distributed systems, the network topology between nodes changes dynamically, and communication latency across data centers and regions often differs by tens or even hundreds of times. Broadcast distribution uses the same push path for all nodes, causing high-latency nodes to become the overall synchronization bottleneck, severely prolonging the key distribution completion time. More seriously, some edge nodes may fail to receive the key within the preset timeout window, directly leading to key update failure. Although some solutions attempt to introduce hierarchical distribution, their core node selection is based solely on static configuration and cannot dynamically adjust the distribution path and load distribution according to real-time network conditions. When the core node is overloaded or the link quality deteriorates, the forwarding efficiency will non-linearly decrease with the increase of the number of relay layers, further exacerbating the packet loss rate and latency accumulation of edge nodes, ultimately preventing candidate version nodes from covering the entire network within a reasonable time.

[0004] Secondly, hierarchical distribution essentially relies on forwarding data from core nodes to edge nodes in a step-by-step manner. Each additional relay hop increases transmission delay and packet loss probability, and this attenuation is strongly correlated with dynamic factors such as network congestion, link stability, and node processing capacity. Traditional solutions lack mathematical models to measure the severity of attenuation and fail to incorporate historical distribution performance into current decisions. This results in fixed timeout parameters and rigid load balancing strategies. Overloaded core nodes cannot be identified in time, while the idle capacity of lightly loaded core nodes remains unused, and links with high reception difficulty for edge nodes are reused. This distribution execution makes the system completely insensitive to network fluctuations, and the key update success rate decreases exponentially with the increase in node size.

[0005] Third, in the traditional method, during the key version activation phase, each participating node, upon receiving a candidate version node, typically completes the version switch independently based on locally preset activation conditions (such as fixed delay or relying solely on the local clock), completely unaware of the synchronization progress of other nodes. This decentralized activation easily leads to a split in the version state across the entire network: some nodes switch to the new version prematurely due to superior network conditions, while other nodes continue to use the old version due to reception delays. Data packets encrypted with both new and old version keys in parallel trigger frequent decryption failures and retransmission requests during cross-transmission between nodes, forming an oscillating cycle of "repeated switching-failure-re-switching." More critically, traditional solutions simply discard nodes that fail to activate within the timeout period, neither generating any traceable failure records nor incorporating this feedback into subsequent distribution decisions. This results in the recurrence of similar problems in the same network environment, preventing the system from self-optimizing based on historical experience.

[0006] In summary, existing dynamic key update technologies have systemic defects in addressing network heterogeneity, decay-aware distribution, load balancing optimization, node collaborative activation, and closed-loop feedback adaptation. There is an urgent need for a key update method that can perceive network status in real time, quantify distribution obstacles, dynamically adjust hierarchical strategies, and complete smooth switching based on full node observation and collaboration. Summary of the Invention

[0007] The purpose of this invention is to provide a data encryption method, system, and storage medium, which solves the aforementioned technical problems pointed out in the prior art.

[0008] This invention provides a data encryption method, comprising the following steps:

[0009] The central coordinating node generates the initial master key of the system, processes the initial master key with the initial salt value through the key derivation function to obtain the first data encryption key; creates the first version node of the global key version chain based on the first data encryption key; the central coordinating node distributes the first version node to all participating nodes, each node establishes a copy of the key version chain locally, marks the first version node as the currently effective version node, and sets the local active pointer to point to the currently effective version node;

[0010] When performing encrypted data transmission, the sender and receiver sequentially perform encryption transmission and verification and decryption processes based on the current effective version and the receiver's key version along with a copy to obtain plaintext data. Afterward, the receiver generates version usage evidence information and generates a global version status track through the central coordination node.

[0011] The central coordination node monitors the global version status trajectory in real time. When the usage information of the currently effective version node in the global version status trajectory reaches the condition for triggering key update, it analyzes the currently effective version node through chain cryptography algorithm to generate a new generation key and the candidate version node corresponding to the new generation key. Combined with the distribution obstacle coefficient, the candidate version node is distributed to all participating nodes, and the timeout time is analyzed.

[0012] Each participating node performs multi-level activation verification on candidate version nodes based on the locally established key version chain copy and the timeout period, and obtains the verification results; feedback processing is carried out based on the verification results.

[0013] Preferably, during encrypted data transmission, the sender and receiver sequentially perform encryption, transmission, verification, and decryption processes based on the current effective version and the receiver's key version along with a copy, obtaining plaintext data. Afterward, the receiver generates version usage evidence information and uses this evidence information to generate a global version status track via a central coordination node, including the following steps:

[0014] The sender encrypts the plaintext data to be sent using the first data encryption key corresponding to the currently effective version node pointed to by the local active pointer, obtaining ciphertext data. The sender then embeds the sequence number and version hash corresponding to the currently effective version node into the header of the ciphertext data, forming an encrypted data packet. After sending the encrypted data packet to the receiver, the receiver extracts the sequence number and version hash from the header of the encrypted data packet. Based on the extracted sequence number and version hash, the receiver verifies the numerical continuity of the sequence number and the validity of the version hash using a locally established copy of the key version chain. Upon successful verification, the receiver decrypts the encrypted data packet using the first data encryption key of the locally established key version chain copy, obtaining plaintext data. Simultaneously, the receiver generates version usage evidence information consisting of the sequence number, communication timestamp, and the currently effective version node during this communication process. This version usage evidence information is sent to the central coordination node, which then aggregates the version usage evidence information obtained over the duration to obtain the global version status trajectory.

[0015] Preferably, the trigger condition for key update refers to the current timestamp reaching the expiration timestamp corresponding to the currently active version node;

[0016] Or, the number of times the currently active version node appears in the version usage evidence information of the global version status trajectory reaches a preset usage threshold.

[0017] Alternatively, within a preset time window, the number of decryption failures reported by the receiver exceeds a preset decryption failure threshold.

[0018] Preferably, based on the currently active version node, a chain cryptographic algorithm is used to analyze and generate a new generation key and the corresponding candidate version node. Then, the candidate version node is distributed to all participating nodes in combination with the distribution barrier coefficient, including the following steps:

[0019] Obtain the communication delay record between every two participating nodes, and construct the inter-node delay matrix based on the communication delay record;

[0020] Calculate the network-wide average communication delay and delay standard deviation based on the inter-node delay matrix; simultaneously obtain the maximum value of the communication delay between any two participating nodes as the network diameter; calculate the distribution barrier coefficient based on the network-wide average communication delay, delay standard deviation, and network diameter;

[0021] Get a high-intensity random number and the current timestamp;

[0022] The serial number of the currently active version node, the first data encryption key, the current timestamp, and a high-strength random number are encoded and combined to form a key derivation input string; the key derivation input string is subjected to k rounds of iterative hash operation to obtain the target hash value; all bytes of the target hash value are used as the new data encryption key.

[0023] Calculate the new version hash of the new data encryption key, and simultaneously determine the candidate sequence number based on the sequence number of the currently active version node; at the same time, calculate the estimated activation timestamp based on the network diameter and latency standard deviation; calculate the estimated expiration timestamp based on the estimated activation timestamp and the preset key validity period.

[0024] The candidate version node is constructed by combining the new version hash, candidate serial number, estimated activation timestamp, and estimated expiration timestamp.

[0025] The distribution method is determined based on the distribution barrier coefficient, and the distribution of candidate version nodes is performed according to the distribution method. At the same time, the timeout time corresponding to the distribution method is calculated.

[0026] Preferably, the distribution method is determined based on the distribution barrier coefficient, and the candidate version node is distributed according to the distribution method. At the same time, the timeout time corresponding to the distribution method is calculated, including the following operation steps:

[0027] If the distribution obstacle coefficient is less than the preset obstacle risk threshold, the candidate version node is broadcast to each participating node. At the same time, the broadcast timeout is calculated based on the average communication delay of the entire network and the preset safety buffer time. If not, the candidate version node is sent to each participating node through hierarchical distribution. At the same time, the hierarchical distribution timeout is calculated based on the network diameter, the standard deviation of delay, and the preset safety buffer time.

[0028] Preferably, candidate version nodes are sent to participating nodes through a tiered distribution process, including the following steps:

[0029] For each participating node, the average latency of each participating node is calculated through the inter-node latency matrix; after sorting the participating nodes in ascending order according to the average latency, the top N participating nodes are selected as the core node set; and the edge node set is obtained; for each edge node in the edge node set, the core node with the smallest communication latency value in the core node set is searched, thereby establishing an initial allocation relationship mapping table;

[0030] Obtain the key distribution history database, calculate the attenuation ratio for each record in the key distribution history database, and calculate the current efficiency attenuation factor based on the attenuation ratios of records over a continuous time period.

[0031] The number of edge nodes corresponding to each core node is counted according to the initial allocation relationship mapping table to obtain the initial load of the core node; historical dimension indicator statistics are extracted for each edge node corresponding to each core node; and the reception difficulty score from each core node to each corresponding edge node is calculated based on the historical dimension indicator statistics.

[0032] The average load across the entire network is calculated based on the number of all participating nodes and the number of core nodes; the load balancing tolerance is calculated based on the preset baseline load tolerance and the current efficiency decay factor; and the first load tolerance threshold for each core node is calculated based on the average load across the entire network and the load balancing tolerance.

[0033] After judging and filtering based on the initial load of the core nodes and the first load tolerance threshold, multiple edge nodes to be adjusted are obtained. The edge nodes to be adjusted are analyzed and processed according to the core node adaptability score of each core node, and the initial allocation relationship mapping table is reconstructed to obtain the final allocation relationship mapping table. Based on the final allocation relationship mapping table, the candidate version nodes are sent to each participating node.

[0034] Preferably, after judging and filtering based on the initial load of the core nodes and the first load tolerance threshold, multiple edge nodes to be adjusted are obtained; the edge nodes to be adjusted are analyzed and processed according to the core node adaptability score of each core node, and the initial allocation relationship mapping table is reconstructed to obtain the final allocation relationship mapping table, including the following operation steps:

[0035] When the initial load of a core node exceeds the first load tolerance threshold, the core node is identified as an overloaded core node. The excess load is calculated based on the initial load of the core node and the first load tolerance threshold. The edge nodes corresponding to the overloaded core nodes are sorted from largest to smallest according to their reception difficulty scores. Then, the edge nodes with the highest excess load are selected as the edge nodes to be adjusted.

[0036] The second load tolerance threshold for each core node is calculated based on the average load of the entire network and the load balancing tolerance; the current load of each core node is calculated.

[0037] Iterate through each edge node e to be adjusted and calculate the core node fit score of each core node for the edge node e to be adjusted.

[0038] All core nodes whose current load is less than the second load tolerance threshold are selected as candidate light-load core nodes. If the candidate light-load core node set is not empty, the core node with the highest core node adaptability score is selected from the candidate light-load core node set as the new responsible core node for the edge node e to be adjusted. If the candidate light-load core node set is empty, the core node with the highest core node adaptability score is selected directly from all core nodes. The highest-level core node becomes the new responsible core node for the edge node e to be adjusted.

[0039] Based on the new responsible core node of each edge node, the initial allocation relationship mapping table is updated to obtain the final allocation relationship mapping table; according to the final allocation relationship mapping table, candidate version nodes are sent to each participating node.

[0040] Preferably, the current method for calculating the efficiency decay factor is to retrieve the M most recent consecutive time period's historical key distribution task records from the key distribution history database, numbering them sequentially from the earliest to the latest as record 1 to record M; for the m-th historical key distribution task record, the corresponding decay ratio is extracted. ; Calculate the initial weight corresponding to the m-th record based on the preset attenuation coefficient β; calculate the sum of the initial weights of all M records; divide the initial weight of the m-th record by the sum of the initial weights to obtain the normalized weight of the m-th record; calculate the attenuation ratio of each record. Multiply by the corresponding normalized weight to obtain the weighted decay ratio of each record; sum the weighted decay ratios of all M records to obtain the current efficiency decay factor λ.

[0041] Historical dimensional indicator statistics include basic latency dimensional indicators. Link stability dimension indicators and node load metrics ;

[0042] Preferably, each participating node performs multi-level activation verification on candidate version nodes based on its locally established key version chain copy and timeout period, obtaining verification results; feedback processing is then performed based on the verification results, including the following steps:

[0043] Each participating node receives a candidate version node distributed by the central coordinating node and performs chain continuity verification and version hash validity verification on the candidate version node. After the verification is successful, each participating node stores the candidate version node in the pending area of ​​its local key version chain copy and records the receiving timestamp of the participating node. At the same time, the status of the candidate version node in the local key version chain copy is marked as pending activation. Starting from the receiving timestamp of the participating node and using the timeout period as the timing duration, a local timeout timer is started.

[0044] During the timeout period, each participating node continuously listens for candidate version node confirmation messages broadcast by participating nodes other than the current participating node. Upon receiving a candidate version node confirmation message, the participating node extracts the sender node identifier from the candidate version node confirmation message, adds the sender node identifier to the locally maintained list of confirmed nodes, and records the receiving timestamp of the candidate version node confirmation message.

[0045] Each participating node reads the total number of participating nodes in the entire network from the global participating node list, and calculates the local observation distribution completion rate in real time based on the number of nodes in the confirmed node list;

[0046] Each participating node reads the preset multi-level activation threshold from the local system parameter configuration table; performs hierarchical activation processing based on the local observation distribution completion rate and the multi-level activation threshold, and obtains the hierarchical activation processing result;

[0047] The current active version node is determined based on the tiered activation process results and the activation completion rate, and feedback processing is performed based on the analysis of the local timeout timer and synchronization failure logs.

[0048] Preferably, the currently active version node is determined based on the tiered activation process results and the activation completion rate, and feedback processing is performed based on local timeout timers and synchronization failure log analysis, including the following steps:

[0049] When the activation process result is activation, an activation confirmation message is generated and sent to the central coordination node. The central coordination node calculates the activation completion rate of the entire network based on the received activation confirmation message. When the activation completion rate reaches the system's preset activation success threshold, the central coordination node marks the candidate version node as the currently effective version node across the entire network.

[0050] If the local observation distribution completion rate of the participating nodes has not reached the third activation threshold T3 in the multi-level activation threshold when the local timeout timer reaches zero, the participating nodes determine that the key update synchronization has failed, mark the status of the candidate version node stored in the pending area of ​​the local key version chain replica as activation failure, maintain the local active pointer at the original currently effective version node, and generate a synchronization failure log at the same time, and report the synchronization failure log to the network security monitoring system of the central coordination node.

[0051] The network security monitoring system of the central coordination node updates the failure records in the key distribution history database based on the received synchronization failure logs, returns to the processing step of calculating the current efficiency decay factor λ, obtains the new current efficiency decay factor, and returns the new current efficiency decay factor for re-execution.

[0052] Compared with the prior art, the embodiments of the present invention have at least the following technical advantages:

[0053] Analysis of the data encryption method, system, and storage medium provided by this invention reveals that, in practical applications, the central coordinating node first generates an initial master key. A first data encryption key is obtained by combining the initial salt value with a key derivation function. Based on this first data encryption key, a first version node of the global key version chain is created. Then, the central coordinating node distributes the first version node to all participating nodes. Each node establishes a local copy of the key version chain, marks the first version node as the currently effective version node, and sets a local active pointer to point to the currently effective version node, thus completing the generation of the initial master key and the creation and distribution of the first version node. Each participating node establishes a local key version chain copy and identifies the currently active version node. Then, when sending encrypted data, the sender encrypts the plaintext data using the first data encryption key corresponding to the currently active version node pointed to by its local active pointer, obtaining ciphertext data. The sender embeds the sequence number and version hash of the currently active version node into the ciphertext header to form an encrypted data packet and sends it. The receiver extracts the sequence number and version hash from the header, verifies the continuity of the sequence number value and the validity of the version hash using its local key version chain copy, and decrypts the plaintext data using its local first data encryption key after successful verification. Simultaneously, it generates the process data for this communication. Version usage evidence information is sent to the central coordination node. The central coordination node collects version usage evidence information based on the duration to obtain a global version status trajectory, enabling secure transmission of encrypted data and key version verification. Version usage evidence is generated and aggregated into the global version status trajectory. Furthermore, the central coordination node monitors the global version status trajectory in real time. When the usage status information of the currently effective version node in the trajectory reaches the condition for triggering a key update, a new generation key and its corresponding candidate version node are generated based on the current effective version node through chain cryptography algorithm analysis. Combined with the distribution obstacle coefficient, the candidate version node is distributed to all participating nodes, and the timeout period is analyzed. Each participating node uses the candidate version node as a candidate successor node for the currently effective version node in its local key version chain copy. It monitors the key usage trigger update condition, generates and distributes candidate version nodes, establishing their status as candidate successor nodes. Finally, each participating node performs multi-level activation verification of the candidate version node based on the local key version chain copy and the timeout period, obtaining verification results. Feedback processing is performed based on the verification results, and participating nodes complete the local verification of the candidate version node and provide feedback on the processing results. Attached Figure Description

[0054] Figure 1 This is a schematic diagram of the main process of a data encryption method;

[0055] Figure 2 A schematic diagram simulating the overall information interaction of a data encryption method;

[0056] Figure 3 This is a simulation diagram of the initial allocation relationship mapping table in a data encryption method;

[0057] Figure 4 This is a schematic diagram simulating the activation of verification feedback in a data encryption method. Detailed Implementation

[0058] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0059] The present invention will now be described in further detail with reference to specific embodiments and accompanying drawings.

[0060] Example 1

[0061] like Figure 1 As shown, Embodiment 1 of the present invention provides a data encryption method, including the following steps:

[0062] Step S10: The central coordinating node (equivalent to the master node, also known as the master server or central server) generates the initial master key of the system. The initial master key is then processed using a key derivation function in combination with the initial salt value to obtain the first data encryption key. Based on the first data encryption key Create the first version node of the global key version chain First version node Includes serial number SEQ=1 and a globally unified activation timestamp. with expiration timestamp And the version hash (the version hash is the encryption key for the first data). (The hash value obtained through hash operation); the central coordinating node will be the first version node. Distribute to all participating nodes, each node creates a local copy of the key version chain, and sets the first version node as the first version node. Mark it as the currently active version node and set the local active pointer to point to the currently active version node;

[0063] The local active pointer refers to the key that is actually used by the system or application for encryption or authentication operations at a specific point in time. In a key chain, there is typically only one active key (i.e., ActiveKey) for the sending direction at any given time. It can be understood that the local active pointer determines which version node is the currently effective version node;

[0064] Step S20: The sender encrypts the plaintext data to be sent using the first data encryption key corresponding to the currently effective version node pointed to by the local active pointer, obtaining ciphertext data; the sequence number and version hash corresponding to the currently effective version node are embedded into the header of the ciphertext data to form an encrypted data packet; after the encrypted data packet is sent to the receiver, the receiver extracts the sequence number and version hash from the header of the encrypted data packet, and verifies the numerical continuity of the sequence number and the validity of the version hash using the key version chain copy established locally by the receiver. If the verification is successful (successful verification means that the key version chain copy established locally by the receiver verifies that the extracted sequence number is numerically continuous and the version hash is valid; if the verification fails, that is, the key version chain copy established locally by the receiver verifies that the extracted sequence number is not numerically continuous or the version hash is invalid), no further processing is performed; for example: numerical continuity means that the sender uses sequence number SEQ=2 The encryption process is as follows: the receiver's local current effective version sequence number is also 2 (instead of 1 or 3), indicating that the key version is continuous and consistent on the chain; the hash version is valid. The hash value 0x3F4A... appended to the packet header by the sender is exactly the same as the hash value calculated by the key corresponding to sequence number 2 stored locally by the receiver, proving that the key has not been tampered with and matches. The receiver uses the first data encryption key of the locally established key version chain copy to decrypt the encrypted data packet, obtaining the plaintext data. At the same time, the receiver generates version usage evidence information consisting of the sequence number, communication timestamp, and the current effective version node (i.e., node key) from this communication process (this communication refers to the series of processes in which the sender encrypts plaintext data, embeds it into an encrypted data packet and sends it, and then the receiver receives, extracts, verifies, and decrypts it). Version usage evidence information is a structured data tuple in the format {seq: integer, timestamp: Unix timestamp, key_version_hash: byte string, reporting_node_id:} The string `}` is used to record the fact that a specific key version was used for decryption at a specific time. Version usage evidence information is sent to the central coordination node, which then aggregates the version usage evidence information obtained over a duration to obtain a global version status trajectory. (Specifically, the receiver temporarily stores the generated version usage evidence information in a local cache. Every 10 seconds, or when the cache reaches 100 entries, all evidence information in the cache is packaged and sent to the central coordination node. The central coordination node aggregates the received evidence information in chronological order to obtain the global version status trajectory. The global version status trajectory is a collection of version usage evidence information collected by the central coordination node and sorted by time; it can be understood as a log database with the key version sequence number and time as keys.)

[0065] Step S30: The central coordinating node monitors the global version status trajectory in real time. When the usage information of the currently effective version node in the global version status trajectory (i.e., generally including the current timestamp, the number of times the currently effective version node has been used, and the security threats or anomalies detected against the current key version) reaches the condition for triggering a key update, the central coordinating node analyzes the currently effective version node through a chain cryptographic algorithm to generate a new generation key and the candidate version node corresponding to the new generation key. The central coordinating node then distributes the candidate version node to all participating nodes in combination with the distribution obstacle coefficient and analyzes the timeout time (including broadcast timeout time or hierarchical distribution timeout time).

[0066] It should be noted that the above-mentioned triggering key update condition refers to the current timestamp reaching the expiration timestamp corresponding to the currently effective version node;

[0067] Or the number of times the currently active version node is used (the number of times the currently active version node appears in the version usage evidence information of the global version status track) reaches the preset number of times of use (the number of times a single key encryption is used exceeds a certain number, which will increase the risk of being cracked).

[0068] Or a security threat or anomaly is detected against the current key version (i.e., the number of decryption failures reported by the receiver exceeds a preset decryption failure threshold within a certain time window).

[0069] Step S40: Each participating node performs multi-level activation verification on the candidate version node based on the local observed distribution completion rate, according to the locally established key version chain copy and the timeout period, and obtains the verification result; feedback processing is performed based on the verification result.

[0070] It should be noted that, as Figure 2 As shown in the above embodiment of this application, the central coordinating node first generates the initial master key of the system, and obtains the first data encryption key by combining the initial salt value with the key derivation function. Based on the first data encryption key, the first version node of the global key version chain is created. Then, the central coordinating node distributes the first version node to all participating nodes. Each node establishes a copy of the key version chain locally, marks the first version node as the currently effective version node, sets the local active pointer to point to the currently effective version node, and completes the generation of the initial master key and the creation and distribution of the first version node. Each participating node establishes a local copy of the key version chain and establishes the currently effective version node.

[0071] Next, when sending encrypted data, the sender encrypts the plaintext data using the first data encryption key corresponding to the currently effective version node pointed to by the local active pointer, obtaining ciphertext data. The sender embeds the sequence number and version hash of the currently effective version node into the ciphertext header to form an encrypted data packet and sends it. The receiver extracts the sequence number and version hash from the header, verifies the continuity of the sequence number value and the validity of the version hash using a local key version chain copy. Upon successful verification, the receiver decrypts the plaintext data using the local first data encryption key. Simultaneously, version usage evidence information is generated during this communication process and sent to the central coordination node. The central coordination node aggregates the version usage evidence information obtained over the duration to obtain a global version status trajectory, achieving secure transmission of encrypted data and key version verification, generating version usage evidence and aggregating it into a global version status trajectory.

[0072] Furthermore, the central coordination node monitors the global version status trajectory in real time. When the usage information of the currently effective version node in the trajectory reaches the condition for triggering a key update, it analyzes the currently effective version node using a chain cryptographic algorithm to generate a new generation key and its corresponding candidate version node. Combining the distribution obstacle coefficient, the candidate version node is distributed to all participating nodes, and the timeout time is analyzed. Each participating node regards the candidate version node as the candidate successor node of the currently effective version node in its local key version chain copy, monitors the key usage trigger update condition, generates and distributes candidate version nodes, and establishes its status as a candidate successor node. Finally, each participating node performs multi-level activation verification of the candidate version node based on the local observed distribution completion rate according to the local key version chain copy and the timeout time, obtains the verification result, and performs feedback processing based on the verification result. The participating nodes complete the local verification of the candidate version node and provide feedback processing results.

[0073] Specifically, in step S30, based on the currently effective version node, a new generation key and the corresponding candidate version node are generated through chain cryptography algorithm analysis. The candidate version node is then distributed to all participating nodes in combination with the distribution barrier coefficient, including the following steps:

[0074] Step S31: Obtain the communication delay record between every two participating nodes, and construct the inter-node delay matrix based on the communication delay record (each element in the inter-node delay matrix represents the communication delay value between participating node i and participating node j).

[0075] Step S32: Calculate the network-wide average communication delay (the network-wide average communication delay is the average of all elements in the inter-node delay matrix, representing the overall average transmission speed of the network) and the delay standard deviation (the delay standard deviation is the degree of dispersion of the communication delay of each participating node relative to the network-wide average communication delay, representing the volatility of network delay) based on the inter-node delay matrix; and simultaneously obtain the maximum value of the communication delay between any two participating nodes as the network diameter (representing the time consumed by the two participating nodes corresponding to the slowest communication path in the network); calculate the distribution obstacle coefficient based on the network-wide average communication delay, delay standard deviation, and network diameter;

[0076] The distribution barrier coefficient is calculated as follows:

[0077] ;

[0078] The distribution barrier coefficient is a dimensionless index constructed based on the standard deviation of network-wide latency and network diameter. It is used to quantify the degree to which network heterogeneity hinders key synchronization. The larger the coefficient value, the greater the difficulty that the key version may encounter during network-wide synchronization. The distribution barrier coefficient is a dimensionless index with a typical value range of [0.5, 5.0]. When the coefficient < 1.0, the network is in a low-latency, low-jitter state; 1.0 to 2.0 is within the normal range; > 2.0 indicates the existence of significant distribution barriers. The upper limit of the coefficient applicable to broadcast distribution is 2.0. If this threshold is exceeded, hierarchical distribution should be enabled. The design of the distribution barrier coefficient is based on the following considerations: It reflects the relative fluctuation of network latency; the greater the fluctuation, the worse the determinism of synchronization between nodes. This reflects the network diameter as a multiple of the average delay. The larger the value, the more hops the farthest node needs to traverse or the longer the delay, and the greater the synchronization overhead. The product of these two factors amplifies the impact of network heterogeneity on the synchronization process. The base value of 1 (which becomes 2 after adding the constant 1) corresponds to a medium level of network condition. The larger the value of this coefficient, the greater the potential difficulty in synchronizing candidate version nodes across the entire network.

[0079] Step S33: Obtain a high-strength random number (a high-strength random number is a 256-bit random number generated by a cryptographically secure pseudo-random number generator, possessing good statistical randomness and unpredictability, and generated by a deterministic random number generator that conforms to [specific security standards, such as FIPS 140-2]) and the current timestamp (the current timestamp is the current absolute time value obtained from a trusted time source).

[0080] Step S34: Encode the current effective version node's sequence number, the first data encryption key, the current timestamp, and the high-strength random number to form a key derivation input string (the key derivation input string is a string formed by encoding the current effective version node's sequence number, the first data encryption key, the current timestamp, and the high-strength random number and then concatenating them according to a fixed format); perform k rounds of iterative hash operations on the key derivation input string to obtain the target hash value; use all bytes of the target hash value as the new data encryption key;

[0081] It should be noted that the above embodiments of this application are based on chain cryptography algorithm, that is, the chain cryptography algorithm is specifically implemented as follows: the successor key is determined by iterative hash operation (i.e. the first data encryption key mentioned above, which in this embodiment also refers to the data encryption key corresponding to the current effective version node), the sequence number of the current effective version node, and the current timestamp. The k rounds of iterative hash operation is a cryptographic operation that uses the output of the hash function (i.e. the key derivation input string mentioned above) as input again for multiple hashing operations, which is used to enhance the security of the key derivation process. The k rounds is the number of iterations, which is determined by the security strategy. For example, k=10000, which can be adjusted. The adjustment range is recommended to be [5000, 100000]. The higher the value, the greater the computational overhead and the stronger the resistance to brute force attacks.

[0082] Step S35: Calculate the new version hash of the new data encryption key (the version hash is a fixed-length digest obtained by hashing the key material, used to uniquely identify and verify the key version; the calculation method is...). Simultaneously, a candidate sequence number is determined based on the sequence number of the currently active version node (the candidate sequence number is the sequential identifier of the new generation key version in the key version chain, i.e., the sequence number of the currently active version node plus 1); at the same time, the estimated activation timestamp is calculated based on the network diameter and latency standard deviation (estimated activation timestamp = network diameter + 3 × latency standard deviation + current timestamp + security buffer time; where the security buffer time is a preset value, which is an extra time margin added to cope with unforeseen network fluctuations, such as 300 milliseconds, configurable, with a recommended range of 100~1000 milliseconds); the estimated expiration timestamp is calculated based on the estimated activation timestamp and the preset key validity period (the estimated expiration timestamp is calculated by adding the estimated activation timestamp to the preset key validity period, where the key validity period is the total time length from key version activation to expiration, such as 24 hours).

[0083] Step S36: Construct candidate version nodes from the new version hash, candidate sequence number, estimated activation timestamp, and estimated failure timestamp; determine whether the distribution obstacle coefficient is less than the preset obstacle risk threshold (the recommended value for the obstacle risk threshold is 2.0, which can be dynamically adjusted through historical data: the initial value is 2.0, and if three consecutive broadcast distributions time out, it will be automatically increased by 0.2; if three consecutive hierarchical distributions are successful and λ<1.2, it will be automatically decreased by 0.1, with the adjustment range limited to [1.5, 3.0]). If yes, send the candidate version nodes to each participating node via broadcast, and calculate the broadcast timeout time based on the average communication delay of the entire network and the preset safety buffer time (i.e., broadcast timeout time = average communication delay of the entire network × 2 + safety buffer time). If no, send the candidate version nodes to each participating node through hierarchical distribution, and calculate the hierarchical distribution timeout time based on the network diameter, delay standard deviation, and the preset safety buffer time (i.e., hierarchical distribution timeout time = network diameter × 1.5 + 2 × delay standard deviation + safety buffer time).

[0084] In the specific processing of the above-described embodiments of this application, those skilled in the art also discovered that during the hierarchical distribution process, due to the heterogeneity of the network topology and the dynamic fluctuations in node performance, a key problem arises: distribution efficiency exhibits a non-linear decay as the number of relay layers increases. Specifically, when a candidate version node forwards data from a core node to an edge node, each additional relay hop accumulates the transmission delay, increases the probability of packet loss, and decreases the overall distribution success rate. If this efficiency decay effect is not controlled, it will lead to severe delays in edge node reception, or even timeout failures, ultimately preventing the candidate version node from completing network-wide synchronization within the preset timeout window.

[0085] Specifically, in step S36, the candidate version node is sent to each participating node through a hierarchical distribution process, including the following steps:

[0086] Step S361: For each participating node, calculate the average latency of each participating node using the inter-node latency matrix; after sorting the participating nodes in ascending order based on the average latency, select the top N participating nodes as the core node set; and obtain the edge node set (i.e., the remaining participating nodes in the network excluding the core node set are the edge nodes, which constitute the edge node set); for each edge node in the edge node set, search for the core node with the smallest communication latency value in the core node set, thereby establishing an initial allocation relationship mapping table (e.g., ...). Figure 3 (as shown)

[0087] It should be noted that the above average latency is obtained by averaging the communication latency values ​​between each participating node and other participating nodes in the inter-node latency matrix. This average latency measures the average latency level of communication between node i and other participating nodes in the network. The lower the value, the more central the position of the participating node and the stronger its communication capability.

[0088] Furthermore, by sorting the average latency in ascending order, the top N participating nodes are selected as core nodes, and a core node set is formed based on all the core nodes. These core nodes are located relatively centrally in the entire network, and their communication capabilities are stronger than the remaining participating nodes (i.e., the aforementioned edge nodes). Then, for each edge node, a search is performed in the core node set to find the core node with the smallest communication latency value for each edge node based on the inter-node latency matrix. Based on this, an initial allocation relationship mapping table is constructed. In the initial allocation relationship mapping table, each core node will be connected to one or more edge nodes, indicating that the core node distributes candidate version nodes to the corresponding connected edge nodes.

[0089] Step S362: Obtain the key distribution history database (the key distribution history database is a record of historical key distribution tasks stored in the network security monitoring system in the central coordination node. Each historical key distribution task record contains the set of core nodes used in the historical key distribution processing, the allocation relationship mapping at that time, the estimated distribution time calculated based on the inter-node delay matrix at that time, and the actual observed distribution completion time at that time). Calculate the attenuation ratio corresponding to each record in the key distribution history database (i.e., the actual observed distribution completion time ÷ the estimated distribution time calculated based on the inter-node delay matrix at that time. This attenuation ratio quantifies the magnification factor of the actual time relative to the theoretical time when the hierarchical distribution candidate version node corresponds to the record. The attenuation ratio value is usually greater than or equal to 1. The larger the value, the more severe the efficiency attenuation of the hierarchical distribution candidate version node at that time). Calculate the current efficiency attenuation factor based on the attenuation ratios of records in continuous time periods.

[0090] The current method for calculating the efficiency decay factor is as follows:

[0091] The calculation of the current efficiency decay factor involves retrieving the most recent M consecutive historical key distribution task records from the key distribution history database, numbering them sequentially from the earliest to the latest as record 1 to record M; for the m-th historical key distribution task record, the corresponding decay ratio is extracted. Based on the preset attenuation coefficient β, calculate the initial weight corresponding to the m-th record. This initial weight is equal to (1 minus β) multiplied by β raised to the power of (M minus m). Calculate the sum of the initial weights of all M records. This sum of initial weights is equal to 1 minus β raised to the power of M. Divide the initial weight of the m-th record by the sum of these initial weights to obtain the normalized weight of the m-th record. Calculate the attenuation ratio of each record. Multiply by the corresponding normalized weight to obtain the weighted decay ratio of each record; sum the weighted decay ratios of all M records to obtain the current efficiency decay factor λ.

[0092] In the formula, Let m be the number of records (i.e., the number of historical key distribution task records mentioned above), and m be the m-th record (i.e., the m-th historical key distribution task record). The preset decay coefficient (0 < β < 1, such as 0.9) gives higher weight to records closer to the current time. The decay rate (actual time consumed / theoretical time consumed) for the m-th record. To normalize the denominator, ensure that the sum of all weights is 1;

[0093] The current efficiency decay factor in the above embodiments of this application The calculation is equivalent to The calculated result is dimensionless and represents a weighted amplification factor between the actual and theoretical time consumption of historical hierarchical task distribution. It is a dynamically updated parameter used to predict how much the actual time consumption of hierarchical distribution will be amplified compared to the theoretical optimal time consumption under current network conditions. A larger λ value indicates more significant efficiency degradation due to network conditions, requiring more conservative timeout settings and better load balancing. In the calculations of this application, λ represents the historical degradation ratio. The weighted arithmetic mean, physically representing the average magnification factor of the actual time spent on hierarchical distribution relative to the theoretical time in the recent network environment. This value naturally satisfies λ≥1, and a larger value indicates a more severe network degradation. It is subsequently used for timeout compensation and load balancing threshold adjustment; weights As the value of Mm increases (the older the record), it decreases exponentially, and the sum of all weights is always 1, strictly following the principle of exponentially weighted moving average, which highlights the dominant role of the recent network state and smooths out short-term sudden fluctuations.

[0094] Step S363: Count the number of edge nodes corresponding to each core node according to the initial allocation relationship mapping table to obtain the initial load of the core node (the initial load of the core node quantifies the number of downlink forwarding tasks that the core node needs to undertake in the current hierarchical distribution task (in units of 1); extract historical dimension indicator statistics for each edge node corresponding to each core node; calculate the reception difficulty score from each core node to its corresponding edge node based on the historical dimension indicator statistics.

[0095] Historical dimensional indicator statistics include basic latency dimensional indicators. Link stability dimension indicators and node load metrics ;

[0096] It should be noted that, in the above embodiments of this application, the basic latency dimension index The inter-node delay matrix represents the communication delay (in milliseconds) from core node c to the edge node e to be adjusted, characterizing the current physical distance and transmission speed of the link (here, the link refers to the link from the core node to the edge node); a link stability dimension indicator. This refers to the average packet loss rate (range 0-1) from core node c to the edge node e to be adjusted over the past hour, which is a value obtained statistically based on the success rate of heartbeat packet reception between nodes; node load dimension metric. This refers to the average CPU utilization of the edge node e to be adjusted over the past 5 minutes (range 0-1). This value is reported by the edge node e along with version usage evidence information, with a reporting cycle of 1 minute. The central coordinating node receives this value and stores it in its local cache, valid for 10 minutes. The value range is [0,1], and it has been normalized (actual CPU utilization / 100%).

[0097] The above-mentioned reception difficulty score is a dimensionless composite index used to comprehensively evaluate the relative cost required to reliably distribute a candidate version node from core node c to edge node e to be adjusted, given link conditions and node states. Its calculation is as follows: ;

[0098] In the embodiments described above, , and These are preset dimension weight coefficients, and they satisfy... + + =1, where (Base delay) is usually the highest value (e.g., 0.6). (Link stability) is the second most important factor (e.g., 0.3). (Node idle resources) minimum (e.g., 0.1); For idle resources, The higher the score, the fewer idle resources there are and the more difficult the distribution becomes. The calculation in the above embodiment of this application maps distance (latency), reliability (packet loss rate), and computing power (CPU idle rate) into a unified score through linear weighting. The higher the score, the more difficult it is for the edge node to receive candidate version nodes quickly and reliably under the current allocation.

[0099] Step S364: Calculate the network-wide average load based on the total number of participating nodes and the number of core nodes (the network-wide average load is quantified as the number of edge nodes each core node should support under ideal balanced conditions, i.e., ...). The load balancing tolerance is calculated based on the preset baseline load tolerance (the baseline load tolerance is the tolerance ratio for basic load deviation, dimensionless, with a default value of 0.3, configurable, and a value range of [0.1, 0.5]; a higher value allows for a larger load deviation and a smaller balancing adjustment overhead, but may exacerbate the risk of overload) and the current efficiency decay factor. The load balancing tolerance represents the maximum allowable deviation of a single core node's load from the average load. When the efficiency decay factor is large (i.e., severe network decay), the load balancing tolerance decreases, meaning stricter requirements for load balancing to prevent overloaded core nodes from further exacerbating decay; when the efficiency decay factor is small (good network conditions), the load balancing tolerance increases, allowing a certain degree of load imbalance to reduce adjustment overhead. Its calculation method is: baseline load tolerance × The first load tolerance threshold for each core node is calculated based on the average load of the entire network and the load balancing tolerance (the first load tolerance threshold represents the maximum allowable load of the core node, and its calculation method is (1 + load balancing tolerance) × average load of the entire network).

[0100] Step S365: When the initial load of a core node is greater than the first load tolerance threshold (if the initial load of a core node is less than or equal to the first load tolerance threshold, no further processing is required, and hierarchical distribution processing is performed directly), the core node is identified as an overloaded core node; and the excess load is calculated based on the initial load of the core node and the first load tolerance threshold (the excess load quantifies the number of edge nodes that the overloaded core node needs to reduce, and its calculation method is the initial load of the core node minus the first load tolerance threshold); the edge nodes corresponding to the overloaded core node are sorted from largest to smallest according to the reception difficulty score, and then the edge nodes with the largest excess load (that is, the edge nodes with the largest excess load in the sequence set obtained after sorting the edge nodes from largest to smallest according to the reception difficulty score, because these edge nodes exceed the first load tolerance threshold of the current corresponding overloaded core node, and they need to be reassigned to core nodes, that is, the initial allocation relationship mapping table is reconstructed, so that they are first identified as edge nodes to be adjusted for subsequent reallocation processing operations) are selected as edge nodes to be adjusted;

[0101] Step S366: Calculate the second load tolerance threshold for each core node based on the network average load and load balancing tolerance (the second load tolerance threshold represents the minimum allowable load for a core node, used to identify core nodes whose current load is significantly lower than the network average load; its calculation method is (1 - load balancing tolerance) × network average load; this threshold quantifies the upper limit of a core node in a light-load state, that is, when the current load of a core node is less than this threshold, the core node is determined to have sufficient idle capacity to undertake additional edge node forwarding tasks); calculate the current load of each core node (the current load of a core node is a dynamically updated integer value; the initial value is equal to the initial load of the core node obtained in step S361; in the subsequent redistribution process, it is decremented by 1 for each edge node removed from core node c, and incremented by 1 for each edge node assigned to core node c; this value represents in real time the actual number of forwarding tasks undertaken by the core node in the current distribution task);

[0102] Step S367: Traverse each edge node e to be adjusted and calculate the core node suitability score for each core node relative to edge node e. This core node suitability score is a dimensionless composite index used to comprehensively measure the overall suitability of core node c in undertaking the forwarding tasks of edge node e, considering four dimensions: transmission efficiency, link quality, node load, and attenuation impact. The higher the score, the more suitable the core node is as the new responsible core node for edge node e. The calculation formula is as follows:

[0103] ;

[0104] in, , , and The preset adaptation dimension weight coefficients satisfy... + + + =1, Corresponding to the dimension of transmission efficiency, Corresponding to the link quality dimension, Corresponding to the node load dimension, Corresponding attenuation impact dimensions; It is the reciprocal of the communication delay; the smaller the delay, the larger this value, indicating higher transmission efficiency. It is the reciprocal of the reception difficulty score. The lower the score (i.e., the easier the reception), the larger this value, which indicates better link quality and edge node processing capabilities. This is the ratio of the network-wide average load to the current load of the core nodes. Adding 1 to the numerator avoids the denominator being zero. A larger value indicates a lighter current load on the core nodes and more capacity to handle new tasks. It is the reciprocal of the current efficiency decay factor. The smaller λ is (the less network decay), the larger this value is, which indicates that the expected success rate of task distribution is higher in the current network environment.

[0105] The calculations in the above-described embodiments of this application map the four core factors affecting the redistribution decision—low latency, low reception difficulty, light load, and stable network environment—as four positive indicators, and fuse them into a comprehensive score through linear weighting. The higher the score, the more beneficial it is to allocate the edge node to the core node for improving the overall distribution efficiency and suppressing the attenuation effect. This ensures that the redistribution process can simultaneously take into account local optima (minimum latency) and global balance (lightest load), and can dynamically respond to changes in the degree of network attenuation.

[0106] Step S368: Filter out all that meet the requirements Core nodes with load tolerance below the second load tolerance threshold are selected as the candidate light-load core node set. If the candidate light-load core node set is not empty, then the core node adaptability score is selected from the candidate light-load core node set. The highest-ranking core node is designated as the new responsible core node for the edge node e to be adjusted; if the candidate lightly loaded core node set is empty, then a core node is directly selected from all core nodes. The highest core node becomes the new responsible core node for the edge node e to be adjusted (at this time, a certain degree of overload is allowed to prioritize transmission efficiency).

[0107] Step S369: Based on the new responsible core node of each edge node, update the initial allocation relationship mapping table to obtain the final allocation relationship mapping table; according to the final allocation relationship mapping table, send the candidate version node to each participating node (that is, the central coordinating node first sends the candidate version node to each core node, and then each core node forwards the candidate version node according to its corresponding edge node in the final allocation relationship mapping table).

[0108] It should be noted that the above update refers to reading the original core node (that is, the edge node corresponding to the core node in the initial setting) from the original initial allocation relationship mapping table, modifying the mapping relationship of the edge node to be adjusted in the initial allocation relationship mapping table to the new core node, decrementing the current load of the original core node by 1, and incrementing the current load of the new core node by 1, thereby obtaining the final allocation relationship mapping table.

[0109] Specifically, such as Figure 4 As shown, in step S40, each participating node performs multi-level activation verification on candidate version nodes based on the locally established key version chain copy and the timeout period, obtaining verification results; feedback processing is performed based on the verification results, including the following steps:

[0110] Step S41: Each participating node receives the candidate version node distributed by the central coordinating node and performs chain continuity verification (i.e., verifying whether the predecessor sequence number of the candidate version node is equal to the sequence number of the currently effective version node locally) and version hash validity verification (i.e., verifying whether the version hash stored in the candidate version node is equal to the digest value obtained by hashing the new data encryption key carried by the node); after the verification is successful (i.e., verifying that the predecessor sequence number of the candidate version node is equal to the sequence number of the currently effective version node locally and verifying that the version hash stored in the candidate version node is equal to the digest value obtained by hashing the new data encryption key carried by the node), each participating node stores the candidate version node in the pending area of ​​its local key version chain copy (the pending area is a logical area in the key version chain copy specifically used to store candidate nodes that have passed preliminary verification but have not yet been activated as the currently effective version node). The system partitions the storage space and records the receiving timestamp of the participating node. Simultaneously, it marks the candidate version node's status in the local key version chain replica as pending activation (the pending activation status indicates that the node has completed all local verifications and is ready to switch to the currently active version node once the activation conditions are met). Starting from the receiving timestamp of the participating node and using the timeout period as the timing duration, a local timeout timer is started (the local timeout timer uses the timeout period as the timing duration and starts counting down from the receiving timestamp). If the verification fails—that is, if the predecessor sequence number of the candidate version node is not equal to the sequence number of the currently active local version node, or if the version hash stored in the candidate version node is not equal to the digest value obtained by hashing the new data encryption key carried by the node—the system returns to step S30, indicating that a problem, such as an encoding error, occurred during the generation of the candidate version node, and it needs to be regenerated.

[0111] Step S42: During the timeout period, each participating node continuously listens for candidate version node confirmation messages broadcast by participating nodes other than the current participating node (the candidate version node confirmation message is a control message actively broadcast to the entire network by other participating nodes after successfully receiving and verifying the candidate version node; the message contains the sender node identifier, the sequence number of the candidate version node, and the sender's local verification result signature for the node); upon receiving a candidate version node confirmation message, the participating node extracts the sender node identifier from the candidate version node confirmation message and adds the sender node identifier to the locally maintained list of confirmed nodes (the list of confirmed nodes is a set of other participating node identifiers that have successfully received and verified the candidate version node, dynamically maintained by the participating node during this key update cycle), and simultaneously records the receiving timestamp of the candidate version node confirmation message;

[0112] Step S43: Each participating node reads the total number of participating nodes in the entire network from the global participating node list (the global participating node list is a fixed set stored in the static configuration library of the central coordinating node, recording the unique identifiers of all participating nodes; each participating node synchronously obtains a copy of this list during the initialization phase), and calculates the local observation distribution completion rate in real time based on the number of nodes in the confirmed node list (the local observation distribution completion rate is the estimated progress of candidate version node distribution across the entire network based on the number of confirmation messages received by the participating node, and its calculation method is...). This value represents the proportion of nodes that have completed the candidate version node acceptance verification from the perspective of this node.

[0113] Step S44: Each participating node reads the preset multi-level activation thresholds from its local system parameter configuration table (the system parameter configuration table is a set of static parameters stored in the local configuration files of each participating node, including preset constants such as multi-level activation thresholds and safety buffer time). The multi-level activation thresholds include a first activation threshold T1 (e.g., 50%), a second activation threshold T2 (e.g., 80%), and a third activation threshold T3 (e.g., 95%). Based on the local observed distribution completion rate and the multi-level activation thresholds, a hierarchical activation process is performed to obtain the hierarchical activation process results. The hierarchical activation process results include nodes that are ready for activation, pending submission, and currently active version nodes (the currently active version node is the activation status).

[0114] If the local observation distribution completion rate is greater than or equal to the first activation threshold and less than the second activation threshold, the participating node will upgrade the status of the candidate version node in the local key version chain replica pending area from pending activation to pre-activation (the pre-activation status indicates that the node is confident that the candidate version node has a broad acceptance base and can begin to prepare for resource pre-allocation and context switching before activation).

[0115] If the local observation distribution completion rate is greater than or equal to the second activation threshold and less than the third activation threshold, the participating nodes update the status of the candidate version node to pending submission (the pending submission status indicates that the node has entered the activation critical section, suspends processing new encryption requests for the old version, and only maintains the ability to decrypt the ciphertext of the old version that has been received), and send an activation preparation confirmation message to the central coordination node (the activation preparation confirmation message includes the node identifier, the candidate version node sequence number and the current local observation distribution completion rate value, which is used by the central coordination node to count the activation preparation progress of the entire network).

[0116] If the local observation distribution completion rate is greater than or equal to the third activation threshold, the participating node will redirect the local active pointer from the original currently effective version node to the candidate version node, update the status of the candidate version node in the local key version chain copy from pending submission to active, and mark the status of the original currently effective version node as a historical version (historical version means that the key version is no longer used to encrypt new data, but can still be used to decrypt old ciphertexts that have been received during the transition compatibility period).

[0117] Step S45: When the activation processing result is "activated" (meaning the participating node has completed the final activation operation), an activation confirmation message is generated (the activation confirmation message is the final confirmation sent by the participating node to the central coordination node after officially switching to the new key version, including the node identifier, candidate version node sequence number, activation timestamp, and a complete signature of the candidate version node), and the activation confirmation message is sent to the central coordination node; the central coordination node calculates the activation completion rate of the entire network based on the received activation confirmation message, and when the activation completion rate reaches the system's preset activation success threshold (e.g., 95%), the central coordination node promotes the candidate version node to the entire network. The status within the scope is uniformly marked as the currently effective version node. (In specific execution, the central coordination node marks the candidate version node as being in a network-wide effective state locally, and notifies all participating nodes by broadcasting a version effectiveness announcement message (containing the candidate version node sequence number, activation timestamp, and central coordination node signature). After receiving the announcement, each participating node ignores it if it has already activated the candidate version node locally; if it has not yet been activated but the version has been verified, it immediately points its local active pointer to the candidate version node; if it has not received the candidate version node, it triggers an emergency synchronization request, which means synchronizing the candidate version node into the corresponding participating node.)

[0118] Step S46: If the local observation distribution completion rate of the participating nodes has not reached the third activation threshold T3 when the timeout time calculated in step S36 (i.e., broadcast timeout time or hierarchical distribution timeout time, i.e., when the local timeout timer reaches zero) is exhausted, the participating nodes determine that the key update synchronization has failed, and mark the status of the candidate version node stored in the pending area of ​​the local key version chain replica as activation failure (activation failure status indicates that the node has been abandoned because it did not meet the activation conditions due to timeout), maintain the local active pointer at the original currently effective version node (i.e., restore the normal encryption and decryption service for the old version key); and at the same time generate a synchronization failure log (the synchronization failure log contains the node identifier, candidate version node sequence number, local observation distribution completion rate at the timeout time, and a list of locally recorded confirmation nodes), and report the synchronization failure log to the network security monitoring system of the central coordination node;

[0119] The network security monitoring system of the central coordination node updates the failure records in the key distribution history database based on the received synchronization failure logs, and returns to step S362 to recalculate the current efficiency decay factor λ, obtaining a new current efficiency decay factor (by incorporating the decay ratio of this failure case, the decay model more sensitively reflects the actual distribution difficulty in the current network environment), and returns the new current efficiency decay factor to step S363 for re-execution (thereby adaptively adjusting the hierarchical distribution strategy and timeout parameters in subsequent key update tasks).

[0120] It should be noted that, in the above embodiments of this application, after a participating node receives a candidate version node, it first performs chain continuity verification and version hash validity verification. After the verification is passed, the node is stored in the pending area of ​​the local key version chain copy, the receiving timestamp is recorded, and its status is marked as pending activation, thus completing the local legality confirmation of the candidate version node and placing it in the pending activation state to prepare the data foundation for subsequent activation. Further, during the timeout period, the participating node continuously listens for candidate version node confirmation messages broadcast by other nodes. For each message received, the sender node identifier is extracted, added to the local confirmed node list, and the message receiving timestamp is recorded. By passively listening, evidence that other nodes in the entire network have received verification is collected, and a confirmed node set from the local perspective is dynamically constructed. Then, the participating node reads the total number of nodes in the entire network from the global participating node list, and calculates the local observation distribution completion rate in real time using the number of nodes in the confirmed node list as the numerator. The collected evidence is quantified into an estimate of the network-wide distribution progress from a local perspective. Then, participating nodes read the local preset multi-level activation thresholds, perform hierarchical state transitions based on the local observed distribution completion rate interval, and autonomously and in stages promote key version switching according to the network-wide synchronization progress. In the pre-activation stage, resources are prepared in advance; in the pending submission stage, the old encryption is paused and progress is reported; and in the activation stage, the final switch is completed. After a node completes activation, it generates an activation confirmation message and sends it to the central coordination node. The central coordination node calculates the network-wide activation completion rate. When the system's preset activation success threshold is reached, the candidate version node is uniformly marked as the currently effective version node across the entire network, and all participating nodes are notified through a broadcast version effectiveness announcement. After receiving the announcement, each node ignores it if it is already activated locally; if it has been verified but not activated, it activates immediately; if it does not receive the announcement, it triggers emergency synchronization, realizing centralized confirmation and unified marking of the network-wide activation status, and ensuring the convergence of node version status through the announcement mechanism.

[0121] Furthermore, if the local observation distribution completion rate has not reached T3 when the local timeout timer reaches zero, the node determines that the key update synchronization has failed, marks the candidate version node status in the pending area as activation failure, maintains the original currently effective version node in the local active pointer, and generates a synchronization failure log to be reported to the network security monitoring system of the central coordination node. The central coordination node updates the key distribution history database accordingly and returns to step S362 to recalculate the current efficiency decay factor λ, which is used for the adaptive adjustment of the distribution strategy and timeout parameters of subsequent key update tasks, handles the scenario of timeout failure, rolls back to the old version, and corrects the decay model through failure feedback closed loop to enhance the adaptability of subsequent distribution strategies to the real network state.

[0122] Example 2

[0123] The present invention also provides a data encryption system, including a key generation module 10, a key encryption module 20, a key update module 30, and a key activation module 40;

[0124] The key generation module 10 controls the central coordination node to generate the system's initial master key. It then processes the initial master key using a key derivation function in conjunction with the initial salt value to obtain the first data encryption key. Based on the first data encryption key Create the first version node of the global key version chain First version node Includes serial number SEQ=1 and a globally unified activation timestamp. with expiration timestamp And version hash; the central coordinating node will be the first version node Distribute to all participating nodes, each node creates a local copy of the key version chain, and sets the first version node as the first version node. Mark it as the currently active version node and set the local active pointer to point to the currently active version node;

[0125] The key encryption module 20 is used to control the sender to encrypt the plaintext data to be sent by the sender according to the first data encryption key corresponding to the currently effective version node pointed to by the local active pointer, so as to obtain ciphertext data; embed the sequence number and version hash corresponding to the currently effective version node into the header of the ciphertext data to form an encrypted data packet; after the encrypted data packet is sent to the receiver, the receiver extracts the sequence number and version hash from the header of the encrypted data packet, and verifies the numerical continuity of the sequence number and the validity of the version hash through the key version chain copy established locally by the receiver. If the verification is successful (successful verification means that the key version chain copy established locally by the receiver verifies that the numerical continuity of the extracted sequence number and the version hash are valid; if the verification fails), ... If the receiver verifies that the extracted sequence number is not consecutive or the version hash is invalid, the receiver will not proceed to the next step if the key version chain copy established locally is verified. The receiver uses the first data encryption key of the locally established key version chain copy to decrypt the encrypted data packet to obtain plaintext data. At the same time, the receiver generates version usage evidence information consisting of the sequence number, communication timestamp, and currently active version node during this communication (this communication refers to the series of processes in which the sender encrypts plaintext data, embeds it into an encrypted data packet and sends it, and then the receiver receives, extracts, verifies, and decrypts it). The version usage evidence information is sent to the central coordination node, which collects the version usage evidence information obtained based on the duration to obtain the global version status trajectory.

[0126] The key update module 30 is used to control the central coordination node to monitor the global version status trajectory in real time. When the usage information of the currently effective version node in the global version status trajectory reaches the condition for triggering key update, the module analyzes the currently effective version node through chain cryptography algorithm to generate a new generation key and the candidate version node corresponding to the new generation key. The central coordination node then distributes the candidate version node to all participating nodes in combination with the distribution obstacle coefficient and analyzes the timeout time (including broadcast timeout time or hierarchical distribution timeout time).

[0127] The key activation module 40 is used to control each participating node to perform multi-level activation verification of candidate version nodes based on the local observed distribution completion rate according to the locally established key version chain copy and the timeout period, and obtain the verification result; and to perform feedback processing based on the verification result.

[0128] In another aspect, the present invention also provides a storage medium comprising a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the aforementioned data encryption method.

[0129] In summary, the data encryption method, system, and storage medium proposed in this invention construct a global key version chain through a central coordinating node. This chain uniformly manages the entire lifecycle of key versions, from initial creation, version update triggering, candidate version generation and distribution to network-wide activation. Each participating node maintains a copy of the key version chain locally and maintains state coordination with the central coordinating node. By integrating network state awareness (distribution obstacle coefficient), adaptive decision-making of distribution strategies, node collaborative activation mechanisms, and failure feedback loops, an end-to-end dynamic key update framework is formed. Through the combination of centralized version control and distributed collaborative execution, the key update process possesses full-process observability, dynamic adaptability, and continuous evolution capabilities, improving the success rate of key synchronization and system resilience in large-scale heterogeneous networks.

[0130] Further processing involves collecting communication delay records between every two participating nodes to construct a node delay matrix. Quantitative parameters are then extracted from this matrix, including the network-wide average communication delay, delay standard deviation, and network diameter. A distribution obstacle coefficient is proposed, mapping the degree of obstruction to key distribution by network topology heterogeneity, delay fluctuation, and the slowest communication path into a dimensionless decision index. This coefficient is then dynamically compared with a preset obstacle risk threshold, adaptively selecting either broadcast distribution or hierarchical distribution strategies. Based on real-time network parameters such as the network-wide average delay, network diameter, and delay standard deviation, broadcast timeout and hierarchical distribution timeout are calculated differently. This approach enables rapid broadcast distribution with minimal overhead in low-obstacle networks and proactively utilizes hierarchical distribution in high-obstacle networks to avoid long-tail delays, overcoming the lack of adaptability of traditional distribution strategies in heterogeneous network environments.

[0131] Furthermore, to address the efficiency degradation effects caused by relay hopping during the hierarchical distribution process, such as accumulated transmission delays and increased packet loss probability, the actual and theoretical time consumption of each hierarchical distribution task is stored in the key distribution history database. The degradation ratio is calculated, and the efficiency degradation factor λ is dynamically updated using an exponentially weighted moving average model, enabling the system to have real-time quantitative perception of the degree of nonlinear degradation. In addition, a two-level composite quantitative model of receiving difficulty score and core node adaptability score is proposed, which uniformly maps link quality, node processing capacity, load status, and current network degradation level as the decision basis. Based on the efficiency degradation factor, the load balancing tolerance is dynamically adjusted, and the first / second load tolerance threshold is set to accurately identify overloaded and lightly loaded core nodes. The redistribution is performed guided by the adaptability score, migrating the edge node with the highest receiving difficulty from the overloaded core node to the optimal lightly loaded core node, suppressing the nonlinear degradation of relay forwarding, and improving the receiving success rate of edge nodes and the synchronous convergence speed of the entire network.

[0132] On the other hand, this embodiment proposes a local observation distribution completion rate. Each participating node continuously listens to the candidate version node confirmation messages broadcast across the entire network during the timeout period, dynamically counts the number of confirmed nodes, and calculates the local observation distribution completion rate in real time, quantifying the synchronization progress of other nodes into a locally perceptible quantitative indicator. At the same time, it presets first, second, and third activation thresholds to guide nodes to perform hierarchical state transitions based on the threshold range where the local observation distribution completion rate is located, so that node switching decisions are precisely coordinated with the real synchronization progress of the entire network. Meanwhile, through the failure feedback closed loop, the efficiency decay model can continuously learn from the real network environment, driving the distribution strategy and timeout parameters to dynamically self-optimize, so that the system can always maintain a highly resilient key update capability under continuously evolving network conditions.

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; those skilled in the art can modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for data encryption, characterized in that, The following steps are included: The central coordinating node generates the initial master key of the system, processes the initial master key with the initial salt value through the key derivation function to obtain the first data encryption key; creates the first version node of the global key version chain based on the first data encryption key; the central coordinating node distributes the first version node to all participating nodes, each node establishes a copy of the key version chain locally, marks the first version node as the currently effective version node, and sets the local active pointer to point to the currently effective version node; When performing encrypted data transmission, the sender and receiver sequentially perform encryption transmission and verification and decryption processes based on the current effective version and the receiver's key version along with a copy to obtain plaintext data. Afterward, the receiver generates version usage evidence information and generates a global version status track through the central coordination node. The central coordination node monitors the global version status trajectory in real time. When the usage information of the currently effective version node in the global version status trajectory reaches the condition for triggering key update, it analyzes the currently effective version node through chain cryptography algorithm to generate a new generation key and the candidate version node corresponding to the new generation key. Combined with the distribution obstacle coefficient, the candidate version node is distributed to all participating nodes, and the timeout time is analyzed. Each participating node performs multi-level activation verification on candidate version nodes based on the locally established key version chain copy and the timeout period, and obtains the verification results. Feedback will be processed based on the verification results.

2. The data encryption method according to claim 1, characterized in that, During encrypted data transmission, the sender and receiver sequentially perform encryption, transmission, verification, and decryption processes based on the current effective version and the receiver's key version along with a copy, obtaining plaintext data. Afterward, the receiver generates version usage evidence information and uses this evidence information to generate a global version status track via the central coordination node, including the following steps: The sender encrypts the plaintext data to be sent using the first data encryption key corresponding to the currently effective version node pointed to by the local active pointer, obtaining ciphertext data. The sender then embeds the sequence number and version hash corresponding to the currently effective version node into the header of the ciphertext data, forming an encrypted data packet. After sending the encrypted data packet to the receiver, the receiver extracts the sequence number and version hash from the header of the encrypted data packet. Based on the extracted sequence number and version hash, the receiver verifies the numerical continuity of the sequence number and the validity of the version hash using a locally established copy of the key version chain. Upon successful verification, the receiver decrypts the encrypted data packet using the first data encryption key of the locally established key version chain copy, obtaining plaintext data. Simultaneously, the receiver generates version usage evidence information consisting of the sequence number, communication timestamp, and the currently effective version node during this communication process. This version usage evidence information is sent to the central coordination node, which then aggregates the version usage evidence information obtained over the duration to obtain the global version status trajectory.

3. The data encryption method according to claim 2, characterized in that, The trigger condition for key update is when the current timestamp reaches the expiration timestamp corresponding to the currently active version node; Or, the number of times the currently active version node appears in the version usage evidence information of the global version status trajectory reaches a preset usage threshold. Alternatively, within a preset time window, the number of decryption failures reported by the receiver exceeds a preset decryption failure threshold.

4. The data encryption method according to claim 3, characterized in that, Based on the current active version node, a chain cryptographic algorithm is used to analyze and generate a new generation key and corresponding candidate version nodes. Then, the candidate version nodes are distributed to all participating nodes in combination with the distribution barrier coefficient. The process includes the following steps: Obtain the communication delay record between every two participating nodes, and construct the inter-node delay matrix based on the communication delay record; Calculate the average communication delay and standard deviation of the entire network based on the inter-node delay matrix; and simultaneously obtain the maximum value of the communication delay between any two participating nodes as the network diameter. The distribution obstacle coefficient is calculated based on the average communication delay, delay standard deviation, and network diameter of the entire network. Get a high-intensity random number and the current timestamp; The serial number of the currently active version node, the first data encryption key, the current timestamp, and the high-strength random number are encoded and combined to form the key derivation input string; Perform k rounds of iterative hash operations on the key-derived input string and output the target hash value. Use all bytes of the target hash value as the new data encryption key; Calculate the new version hash of the new data encryption key, and simultaneously determine the candidate sequence number based on the sequence number of the currently active version node; at the same time, calculate the estimated activation timestamp based on the network diameter and latency standard deviation. The estimated expiration time stamp is calculated based on the estimated activation timestamp and the preset key validity period; The candidate version node is constructed by combining the new version hash, candidate serial number, estimated activation timestamp, and estimated expiration timestamp. The distribution method is determined based on the distribution barrier coefficient, and the distribution of candidate version nodes is performed according to the distribution method. At the same time, the timeout time corresponding to the distribution method is calculated.

5. A data encryption method according to claim 4, characterized in that, The distribution method is determined based on the distribution barrier coefficient, and the candidate version node is distributed according to the distribution method. At the same time, the timeout time corresponding to the distribution method is calculated, including the following operation steps: If the distribution obstacle coefficient is less than the preset obstacle risk threshold, the candidate version node is broadcast to each participating node. At the same time, the broadcast timeout is calculated based on the average communication delay of the entire network and the preset safety buffer time. If not, the candidate version node is sent to each participating node through hierarchical distribution. At the same time, the hierarchical distribution timeout is calculated based on the network diameter, the standard deviation of delay, and the preset safety buffer time.

6. The data encryption method according to claim 5, characterized in that, The candidate version node is sent to each participating node through a tiered distribution process, including the following steps: For each participating node, the average latency of each participating node is calculated through the inter-node latency matrix; after sorting the participating nodes in ascending order according to the average latency, the top N participating nodes are selected as the core node set; and the edge node set is obtained; for each edge node in the edge node set, the core node with the smallest communication latency value in the core node set is searched, thereby establishing an initial allocation relationship mapping table; Obtain the key distribution history database, and calculate the attenuation ratio for each record based on each record in the key distribution history database; The current efficiency decay factor is calculated based on the decay rate recorded over a continuous time period. The initial load of the core nodes is obtained by counting the number of edge nodes corresponding to each core node according to the initial allocation relationship mapping table. Historical dimension indicator statistics are extracted for each edge node corresponding to each core node; based on the historical dimension indicator statistics, the reception difficulty score from each core node to its corresponding edge node is calculated. The average load across the entire network is calculated based on the number of all participating nodes and the number of core nodes; the load balancing tolerance is calculated based on the preset baseline load tolerance and the current efficiency decay factor; and the first load tolerance threshold for each core node is calculated based on the average load across the entire network and the load balancing tolerance. After judging and filtering based on the initial load of the core nodes and the first load tolerance threshold, multiple edge nodes to be adjusted are obtained. The edge nodes to be adjusted are analyzed and processed according to the core node adaptability score of each core node, and the initial allocation relationship mapping table is reconstructed to obtain the final allocation relationship mapping table. Based on the final allocation relationship mapping table, candidate version nodes are sent to each participating node.

7. A data encryption method according to claim 6, characterized in that, After judging and filtering based on the initial load of the core nodes and the first load tolerance threshold, multiple edge nodes to be adjusted are obtained. These edge nodes are then analyzed based on their compatibility scores with each core node to reconstruct the initial allocation relationship mapping table, resulting in the final allocation relationship mapping table. This process includes the following steps: When the initial load of a core node exceeds the first load tolerance threshold, the core node is identified as an overloaded core node. The excess load is calculated based on the initial load of the core node and the first load tolerance threshold. The edge nodes corresponding to the overloaded core nodes are sorted from largest to smallest according to their reception difficulty scores. Then, the edge nodes with the highest excess load are selected as the edge nodes to be adjusted. The second load tolerance threshold for each core node is calculated based on the average load of the entire network and the load balancing tolerance; the current load of each core node is calculated. Iterate through each edge node e to be adjusted and calculate the core node fit score of each core node for the edge node e to be adjusted. All core nodes whose current load is less than the second load tolerance threshold are selected as candidate light-load core nodes. If the candidate light-load core node set is not empty, the core node with the highest core node adaptability score is selected from the candidate light-load core node set as the new responsible core node for the edge node e to be adjusted. If the candidate light-load core node set is empty, the core node with the highest core node adaptability score is selected directly from all core nodes. The highest-level core node becomes the new responsible core node for the edge node e to be adjusted. Based on the new responsible core node of each edge node, the initial allocation relationship mapping table is updated to obtain the final allocation relationship mapping table; Based on the final allocation relationship mapping table, candidate version nodes are sent to each participating node.

8. A data encryption method according to claim 7, characterized in that, The current efficiency decay factor is calculated by retrieving the most recent M consecutive key distribution task records from the key distribution history database, numbering them sequentially from the earliest to the latest as record 1 to record M; for the m-th historical key distribution task record, the corresponding decay ratio is extracted. ;Calculate the initial weight corresponding to the m-th record based on the preset attenuation coefficient β; Calculate the sum of the initial weights of all M records; Divide the initial weight of the m-th record by the sum of those initial weights to obtain the normalized weight of the m-th record; then calculate the decay ratio of each record. Multiply by the corresponding normalized weight to obtain the weighted decay ratio of each record; sum the weighted decay ratios of all M records to obtain the current efficiency decay factor λ. Historical dimensional indicator statistics include basic latency dimensional indicators. Link stability dimension indicators and node load metrics .

9. A data encryption method according to claim 8, characterized in that, Each participating node performs multi-level activation verification on candidate version nodes based on its locally established key version chain copy and timeout period, obtaining verification results. Feedback processing is then performed based on these verification results, including the following steps: Each participating node receives a candidate version node distributed by the central coordinating node and performs chain continuity verification and version hash validity verification on the candidate version node. After the verification is successful, each participating node stores the candidate version node in the pending area of ​​its local key version chain copy, records the receiving timestamp of the participating node, and marks the status of the candidate version node in the local key version chain copy as pending activation. Starting with the receiving timestamp of the participating node and using the timeout period as the timing duration, start the local timeout timer; During the timeout period, each participating node continuously listens for candidate version node confirmation messages broadcast by participating nodes other than the current participating node. Upon receiving a candidate version node confirmation message, the participating node extracts the sender node identifier from the candidate version node confirmation message, adds the sender node identifier to the locally maintained list of confirmed nodes, and records the receiving timestamp of the candidate version node confirmation message. Each participating node reads the total number of participating nodes in the entire network from the global participating node list, and calculates the local observation distribution completion rate in real time based on the number of nodes in the confirmed node list; Each participating node reads the preset multi-level activation threshold from the local system parameter configuration table; Based on the local observation distribution completion rate and the multi-level activation threshold, hierarchical activation processing is performed to obtain the hierarchical activation processing result; The current active version node is determined based on the tiered activation process results and the activation completion rate, and feedback processing is performed based on the analysis of the local timeout timer and synchronization failure logs.

10. A data encryption method according to claim 9, characterized in that, Based on the tiered activation process results and the activation completion rate, the currently active version node is determined, and feedback processing is performed based on the local timeout timer and synchronization failure log analysis, including the following steps: When the activation process result is activation, an activation confirmation message is generated and sent to the central coordination node. The central coordination node calculates the activation completion rate of the entire network based on the received activation confirmation message. When the activation completion rate reaches the system's preset activation success threshold, the central coordination node marks the candidate version node as the currently effective version node across the entire network. If the local observation distribution completion rate of the participating nodes has not reached the third activation threshold T3 in the multi-level activation threshold when the local timeout timer reaches zero, the participating nodes determine that the key update synchronization has failed, mark the status of the candidate version node stored in the pending area of ​​the local key version chain replica as activation failure, maintain the local active pointer at the original currently effective version node, and generate a synchronization failure log at the same time, and report the synchronization failure log to the network security monitoring system of the central coordination node. The network security monitoring system of the central coordination node updates the failure records in the key distribution history database based on the received synchronization failure logs, returns to the processing step of calculating the current efficiency decay factor λ, obtains the new current efficiency decay factor, and returns the new current efficiency decay factor for re-execution.

Images