Block chain driven server data encryption storage system and method

Abstract

The invention discloses a blockchain-driven server data encryption storage system and method, and relates to the technical field of distributed data security storage. After original data are encrypted and fragmented, a dynamic signature group is established for each fragment, and a search token is generated by using a searchable encryption engine; dynamically calculating a node number threshold value required by signature through an intelligent contract deployed on a block chain, and realizing authorized signature of a search token; the storage node executes search based on authorization, returns a result, generates an operation fingerprint composed of search token hash, result set hash, a timestamp and a participation node identifier, and stores the operation fingerprint to the block chain to realize operation full-link audit; the intelligent contract continuously monitors node behaviors, updates reputation scores and dynamically adjusts signature group composition and threshold values, dynamic self-adaptive access control and non-tampering operation auditing can be achieved, the safety and controllability of a system in a node dynamic change environment are improved, and the safety and reliability of the system are improved. And meanwhile, the search security and the operation efficiency are enhanced through blind processing and lightweight verification.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed data security storage, in particular to a blockchain-driven server data encryption storage system and method. BACKGROUND

[0002] With the rapid development of cloud computing and blockchain technology, distributed storage systems are widely used in data management due to their decentralization and tamper resistance. However, in a highly dynamic and untrusted distributed node environment, how to ensure the controllability of encrypted data access and the auditability of operation throughout the life cycle still faces serious challenges. Existing technologies mostly use static key management or fixed threshold group signature schemes, which are difficult to adapt to dynamic scenarios with frequent node joining and exiting, and lack effective auditing mechanisms for data query operations, resulting in significant contradictions between system dynamics and security.

[0003] In existing patent technologies, for example, the invention patent with publication number CN115567550B, a file information data storage method based on blockchain and national secret algorithm, realizes the storage and tamper-proofing of file key information by combining blockchain and national secret SM3 hash algorithm, and uses Kafka consensus mechanism to improve the collaboration efficiency between nodes. However, this method relies on a fixed key management strategy and does not solve the problem of key group update and access control strategy adaptive adjustment when nodes change dynamically. Another related patent CN117792604B, a blockchain transaction data storage and access method combining on-chain and off-chain, realizes secure retrieval and fine-grained access control of off-chain data through attribute-based searchable encryption technology, but its permission management is based on a static attribute set, lacks a response mechanism for real-time reputation and dynamic behavior of nodes, and fails to record the query operation process in an undeniable way on the blockchain, limiting its auditing ability in dynamic distributed environments.

[0004] Based on the above, the deficiencies of existing technologies are: how to realize dynamic access control and operation full-link audit in the data encryption storage and query process in a distributed storage system with dynamic node changes and some untrusted nodes. Existing solutions often focus on the security of the storage phase, ignoring the operation traceability requirements of the query phase, or using a fixed threshold mechanism that is difficult to balance security and availability, leading to permission leakage or audit blind spots in dynamic network environments.

[0005] In summary, there is no complete solution in the prior art that can deeply integrate dynamic threshold group signature with searchable encryption, and realize real-time reputation evaluation based on node behavior and operation full-link evidence storage. Therefore, there is an urgent need for a blockchain-driven encrypted storage system and method that can adapt to dynamic changes in nodes and support query operation non-repudiation audit to address the security and controllability issues faced by existing technologies in dynamic environments. SUMMARY

[0006] The purpose of the present application is to overcome the shortcomings of the prior art, and provide a blockchain-driven server data encryption storage system and method. By introducing the technical means of combining dynamic threshold signature, searchable encryption and blockchain evidence storage, fine-grained access control of encrypted data and operation full-link tamper-proof audit in a dynamic node changing environment can be realized, thereby effectively improving the security, controllability and traceability of the distributed storage system.

[0007] To solve the above technical problems, the present application provides the following technical solutions: on the one hand, a blockchain-driven server data encryption storage method, comprising the following steps: Step one, the data owner divides the original data into multiple data fragments after encryption; Step two, create and initialize a dynamic signature group for each data fragment, the dynamic signature group is composed of multiple storage nodes, and the corresponding group private key share is distributed to the members in the group through a distributed key generation protocol; Step three, generate a search token for the query keyword using a searchable encryption engine; Step four, submit the search token to the target data fragment corresponding dynamic signature group for authorized signature, wherein the node number threshold required for signature is dynamically calculated by the smart contract deployed on the blockchain according to the real-time state of the dynamic signature group; Step five, the storage node executes the search operation and returns the encrypted search result after receiving the authorized search token that meets the dynamic threshold signature; Step six, generate an operation fingerprint corresponding to this query operation, the operation fingerprint is composed of at least search token hash, returned result set hash, timestamp and dynamic signature group member identification participating in signature, and store the operation fingerprint to the blockchain; Step seven, the smart contract continuously monitors the behavior data of the storage node and updates its reputation score, and dynamically adjusts the member composition of the dynamic signature group and the node number threshold required for signature based on the updated reputation score.

[0008] Further, the node number threshold required for signature in step four is determined by the smart contract through a dynamic threshold calculation function, and the dynamic threshold calculation function is: where t represents the calculated dynamic threshold value, N represents the total number of nodes in the current dynamic signing group that are online and in normal state, represents the real-time reputation score of the i-th node, which is dynamically updated according to the historical behavior of the node, represents the weight coefficient of the i-th node, which is positively correlated with the storage contribution and online stability of the node, is a baseline threshold parameter preset according to the system security policy, is a minimum threshold preset by the system to ensure a minimum level of security, represents a floor operator, is a max function; The smart contract periodically executes the dynamic threshold calculation function to ensure that the dynamic threshold value t can adapt to the changes in the state of the nodes in the dynamic signing group.

[0009] Further, the specific steps of generating the operation fingerprint corresponding to the current query operation in step six include: extracting the search token authorized by the dynamic signing group in the current query request, calculating its hash value, denoted as ; calculating the overall hash value of the encrypted result set returned by the current search, denoted as ; obtaining the timestamp of the current block of the blockchain, denoted as ; combining the unique node identifiers of all dynamic signing group members participating in the signature of the search token this time to generate a participant list, calculating the hash value of the list, denoted as ; concatenating , , and in a predetermined order, and then calculating the hash value again to generate the final operation fingerprint , whose generation function is: where represents the string concatenation operation, is a specified cryptographic hash function; The operation fingerprint is stored on the blockchain as tamper-proof audit evidence.

[0010] Further, the specific implementation of the smart contract continuously monitoring the behavior data of the storage node and updating its reputation score in step seven includes: The smart contract defines and records multiple behavior indicators of each storage node, including but not limited to: the number of successful responses to data integrity challenges, the timeliness of submitting storage proofs, the enthusiasm of participating in dynamic signature group signature processes, and the historical online duration ratio; The smart contract periodically recalculates the reputation score of each node according to a pre-defined reputation update algorithm, which contains a reward mechanism and a punishment mechanism. For nodes that behave as expected, their reputation scores are raised, and for nodes that behave abnormally or maliciously, their reputation scores are lowered. When the reputation score of a node is lower than the system-set malicious node threshold, the smart contract triggers a node eviction procedure, removes the node from the dynamic signature group it belongs to, triggers a distributed key update protocol to generate new group private key shares for the group without re-encrypting the original data shards stored off-chain, and triggers the confiscation of the deposit staked by the evicted node.

[0011] Further, the specific steps of triggering the distributed key update protocol include: Selecting the nodes with the highest reputation scores in the dynamic signature group as key update coordinators; Each key update coordinator generates a new random secret and uses a secret sharing algorithm to construct new private key shares among the remaining nodes in the group except the evicted node; Based on the received new private key share information, the remaining nodes in the group locally calculate the final new private key share through a non-interactive key agreement protocol, while destroying the old private key share; The distributed key update protocol ensures that the complete group private key is not reconstructed at any time during the key update process, and the new private key share is still compatible with the data shard ciphertext before the update.

[0012] On the other hand, a blockchain-driven server data encrypted storage system suitable for the method, the system includes: A data preprocessing module configured to receive raw data, perform encryption operations, and split the encrypted data into multiple data shards; A dynamic signature group management module configured to create, maintain and update the dynamic signature group corresponding to each data shard for each data shard, including managing the node members in the group, coordinating the generation and update of distributed keys, and obtaining the dynamically calculated signature threshold from the smart contract interface; A searchable encryption engine module configured to generate search tokens according to query keywords and verify the authorized signature of the search token by the dynamic signature group; The operation evidence and audit chain module is configured to collect relevant data of the query operation, generate an operation fingerprint, and submit the operation fingerprint to a blockchain network for permanent evidence storage. The smart contract module is deployed on the blockchain and is configured to perform dynamic threshold calculation, monitor node behavior, update node reputation score, manage node margin, and trigger reconstruction of the dynamic signature group and key update according to predefined rules.

[0013] Furthermore, the dynamic signature group management module further includes a lightweight node behavior verification submodule, which realizes non-missing verification of node storage behavior in the following manner: The lightweight node behavior verification submodule periodically sends a random challenge to the storage node, requiring the node to generate a storage proof based on the specific data shard stored by the node; The storage proof generated by the node combines the group private key share fragment currently held by the node, so that the storage proof not only verifies the existence and integrity of the data, but also indirectly proves the validity of the key share; The lightweight node behavior verification submodule uses the bilinear mapping property to batch verify the received storage proof, and the verification formula is:

[0014] where e represents a bilinear mapping function, represents an aggregated storage proof, G is a generator of an elliptic curve cyclic group, is a point mapped from the challenge information to the elliptic curve group, is the public key of the jth node participating in verification, and K is the number of nodes participating in the proof; This verification process can efficiently identify malicious or lost nodes without significantly increasing network overhead.

[0015] Furthermore, the searchable encryption engine module is further configured to blind the generated search token based on the node reputation, specifically including: After generating the basic search token, the searchable encryption engine module queries the smart contract module to obtain the real-time reputation score of each node in the current dynamic signature group, and then performs blind processing on the basic search token based on the obtained reputation score, and then sends the blinded token to the dynamic signature group; The searchable encryption engine module adds a dynamically generated blinding factor to the token according to the obtained reputation score, which is associated with the overall reputation of the target dynamic signature group; The authorized signature of the token after being blinded needs to be unblinded before being used for searching, and the mechanism ensures that even if the search token or part of the authorized signature is intercepted during transmission, the attacker cannot replay and use it in other contexts or future time, thereby enhancing the security of the search process.

[0016] Compared with the prior art, the blockchain-driven server data encryption storage system and method has the following beneficial effects: Firstly, the application deeply integrates the dynamic threshold group signature mechanism with searchable encryption technology, and calculates the threshold value of the number of nodes required for signature authorization in real time based on the smart contract, so that the system can adapt to the network environment of dynamic joining and exiting of nodes, and realize fine and dynamic access control in the encrypted data query process.

[0017] Secondly, the application introduces a blinding processing mechanism based on real-time reputation score of nodes and a lightweight behavior verification method, which can effectively enhance the anti-replay attack capability in the transmission and use process of the search token, and realize efficient monitoring and verification of the storage behavior of the nodes without significantly increasing the network overhead; combined with the distributed key update protocol, the key share can be updated safely without re-encrypting the original data fragments when the node is changed, which significantly reduces the system maintenance cost and running delay, thereby improving the overall efficiency and robustness of the system while ensuring data privacy and integrity.

[0018] Other advantages, objects, and features of the application will be set forth in part in the following specification, and in part will become apparent to those skilled in the art upon examination of the following specification, or can be learned from practice of the application. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiment or prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and those skilled in the art can obtain other drawings according to these drawings without any creative effort.

[0020] Fig. 1 The step flowchart of the application; Fig. 2 The system module interaction diagram of the application; Fig. 3 Figure of dynamic reputation management and key update mechanism of the present application. DETAILED DESCRIPTION

[0021] In order to further illustrate the technical means and effects adopted by the present application to achieve the predetermined inventive purposes, the specific embodiments, structures, features and effects thereof according to the present application are described in detail below in combination with the drawings and preferred embodiments.

[0022] Embodiment one As Figs. 1-3 shown, in order to more clearly illustrate the technical solutions of the present application, the method and system of the present application are described in detail below in combination with typical application scenarios of distributed data storage. This embodiment is based on an enterprise-level distributed data management scenario to realize secure storage, controllable query and operation audit of encrypted data, which is described in detail below.

[0023] In this embodiment, the method implementation process is as follows: Data encryption and sharding processing: when the data owner initiates a data storage request, the data preprocessing module receives the original data. First, the original data is encrypted, and a symmetric encryption mechanism is used to encrypt the data as a whole. The key generated during the encryption process is securely kept by the data owner. This encryption method can balance data processing efficiency while ensuring data security.

[0024] After encryption is completed, the encrypted data is divided according to the preset sharding strategy, forming multiple data shards. The shard size is dynamically adapted according to the system storage performance and network transmission efficiency, and the number of shards is adjusted according to the change in the amount of original data. Through data sharding processing, on the one hand, the storage pressure of a single data block is reduced, and the parallelism of data storage is improved; on the other hand, the risk of data leakage is reduced by avoiding storing complete data on a single node.

[0025] Dynamic signature group creation and key distribution: for each data shard, the dynamic signature group management module creates a corresponding dynamic signature group. The node selection of the dynamic signature group is based on the initial reputation score, storage resource status and network stability of the node. The initial reputation score is determined by the smart contract according to the qualification information and historical service records submitted by the node when it is accessed, to ensure that the nodes in the group have basic credibility and service capability.

[0026] After the dynamic signature group is created, the group private key shares are generated through a distributed key generation protocol. This protocol does not need to rely on a trusted third party. Each node in the group generates its own private key share through interactive calculation. There is no complete group private key in the entire process, effectively avoiding the risk of centralized key leakage. The generated group private key shares are distributed to each node in the group through an encrypted transmission channel. After receiving the private key shares, the nodes store them in the local secure storage area to ensure the confidentiality of the private key shares.

[0027] Search token generation: When the data user needs to query the target data, the query keyword is submitted to the searchable encryption engine module. The searchable encryption engine module preprocesses the query keyword, removes redundant information, and generates a basic search token based on the preset searchable encryption algorithm.

[0028] The searchable encryption algorithm is designed based on the public key encryption system, which can realize keyword matching without decrypting the data, ensuring the privacy and security of the data during the query process. The generated basic search token contains the encrypted representation information of the keyword, which can support subsequent search matching operations and will not leak the original content of the keyword.

[0029] Dynamic threshold signature authorization: The searchable encryption engine module submits the generated basic search token to the dynamic signature group corresponding to the target data shard, requesting authorization signature. In this process, the node number threshold required for signature is dynamically calculated by the smart contract deployed on the blockchain, using the following dynamic threshold calculation function:

[0030] Wherein, the specific description of each parameter is as follows: t is the dynamically calculated signature threshold, i.e. the minimum number of nodes required to complete the authorized signature; N is the total number of online and normal nodes in the current dynamic signature group, which is counted by the smart contract through real-time heartbeat detection mechanism. The node sends a status report to the smart contract every fixed time interval, and the node that does not send the report on time or has abnormal report status is not included in N; is the real-time reputation score of the ith node, with a value range of 0 to 100, which is dynamically updated by the smart contract according to the historical behavior of the node, and the initial value is 50. This score directly reflects the credibility of the node; is the weight coefficient of the ith node, with a value range of 0 to 1, which is positively related to the storage contribution and online stability of the node. The storage contribution is determined by the number and length of the data shards stored by the node, and the online stability is calculated according to the historical online time ratio of the node. The setting of the weight coefficient makes the nodes with high credibility and high contribution occupy a higher proportion in the threshold calculation; is the baseline threshold parameter, which is preset according to the system security policy. Its value needs to balance the system security and availability. The higher the security level requirement is, the larger the value is; is the minimum threshold value preset by the system, with a value of 2, which is used to ensure the minimum security and avoid the risk of too small threshold value caused by too few nodes or too low node reputation; The floor operator ensures that the calculation result is an integer, consistent with the count characteristics of the number of nodes; The maximum value function ensures that the final signature threshold is not lower than , avoiding the case of invalid threshold.

[0031] The smart contract executes the dynamic threshold calculation function every fixed time interval, ensuring that the dynamic threshold can adapt to the node state changes of the dynamic signature group in real time. After receiving the search token, the nodes in the dynamic signature group sign the search token according to their group private key shares. When the number of nodes that have completed signing reaches the dynamic threshold t, the authorized search token is generated.

[0032] Search operation execution and result return: After receiving the authorized search token, the storage node first verifies the validity of the signature. The verification process is performed by the group public key, which is generated by the private key shares of each node. The storage node verifies the aggregated signature on the authorized search token using the group public key to confirm that the signature meets the dynamic threshold requirements and has not been tampered with.

[0033] After verification, the storage node performs a search operation on the locally stored encrypted data shards based on the encrypted representation information in the authorized search token. The search process uses a ciphertext matching mechanism to identify data segments containing the target keyword without decrypting the data shards. After matching, the relevant data segments are integrated to form an encrypted search result set, which is returned to the data user through an encrypted transmission channel.

[0034] Operation fingerprint generation and blockchain storage: The operation storage and audit chain module collects relevant data for this query operation and generates an operation fingerprint according to the preset process, as follows: Extract the search token authorized by the dynamic signature group and calculate its hash value using a cryptographic hash function, denoted as , which uniquely represents the search token information for this query; Perform an overall hash calculation on the encrypted result set returned by this search to obtain the hash value , which can verify the integrity of the search result set. If the result set is tampered with, the hash value will change; Obtain the timestamp of the current block of the blockchain, denoted as , which accurately records the execution time of this query operation; Combine the unique node identifiers of all dynamic signature group members participating in the signature of this search token to form a participant list, and calculate the hash value of this list, denoted as , which explicitly identifies the participating nodes of this authorized signature; According to , , and The strings are concatenated in a predetermined order, and then a cryptographic hash calculation is performed on the concatenated result to generate the final operation fingerprint. Its generating function is:

[0035] in This represents a string concatenation operation. The specified cryptographic hash function is collision-resistant and one-way, ensuring the uniqueness and unforgeability of the operation fingerprint.

[0036] After the operation fingerprint is generated, the operation evidence storage and auditing chain module submits it to the blockchain network, where it is permanently stored in blocks through the blockchain's consensus mechanism. Because of the blockchain's immutable nature, the operation fingerprint serves as immutable audit evidence, providing a basis for subsequent operation tracing and accountability.

[0037] Node behavior monitoring and dynamic system adjustment: The smart contract module continuously monitors and stores node behavior data. Based on preset behavior indicators and reputation update algorithms, it periodically updates the node's reputation score and dynamically adjusts the composition of the dynamic signature group and the signature threshold. The specific process is as follows: Behavioral Metric Monitoring: The smart contract defines and records multiple behavioral metrics for each storage node, including the number of times it successfully responds to data integrity challenges, the timeliness of submitting storage proofs, its participation in the dynamic signature group signing process, and the historical online time ratio. The number of times it successfully responds to data integrity challenges is counted by the lightweight node behavior verification submodule; the timeliness of submitting storage proofs is evaluated by the difference between the storage proof submission time and the preset time limit; the participation in signing is determined based on the node's response speed and completion rate to signature requests; and the historical online time ratio is the ratio of the node's actual online time to the total monitoring time. Reputation Score Update: The smart contract periodically recalculates the reputation score of each node according to a predefined reputation update algorithm. This algorithm includes reward and penalty mechanisms. For nodes that successfully respond to integrity challenges, submit storage proofs in a timely manner, actively participate in signing, and have high online stability, their reputation scores are increased according to preset rules. For nodes that fail to respond to integrity challenges, submit storage proofs at a timeout, refuse to participate in signing, or submit false proofs, their reputation scores are decreased. The adjustment range is determined based on the severity of the behavior. Node Eviction and Key Update: When a node's reputation score falls below the system's malicious node threshold, the smart contract triggers a node eviction procedure, removing the node from its dynamic signature group. Simultaneously, a distributed key update protocol is triggered. The specific steps are as follows: Several nodes with the highest reputation scores are selected within the dynamic signature group as key update coordinators; each key update coordinator generates a new random secret and uses a secret-sharing algorithm to construct a new private key share among the remaining nodes in the group (excluding the evictioned node); based on the received new private key share information, the remaining nodes in the group locally calculate the final new private key share using a non-interactive key negotiation protocol, while simultaneously destroying the old private key share. The distributed key update protocol ensures that the complete group private key will never be reconstructed, and that the new private key share remains compatible with the ciphertext of the data fragments before the update, without requiring re-encryption of the original data fragments. Margin Management: The smart contract also manages the margin staked by nodes. When a node is evicted, the smart contract triggers a margin forfeiture operation. The forfeited margin is used to compensate for potential losses to the system due to malicious behavior by nodes. This mechanism further constrains node behavior and improves node credibility. Dynamic adjustment: Based on the updated node reputation scores, the smart contract recalculates the signature threshold of the dynamic signature group and adds new trusted nodes to the dynamic signature group or removes nodes with consistently low reputation scores, depending on the node reputation status and system storage requirements, to ensure the overall trustworthiness and service capabilities of the dynamic signature group.

[0038] In this embodiment, the system modules are implemented as follows: The blockchain-driven server data encryption and storage system corresponding to this embodiment includes a data preprocessing module, a dynamic signature group management module, a searchable encryption engine module, an operation evidence storage and auditing chain module, and a smart contract module. The specific implementation of each module is as follows: Data Preprocessing Module: The data preprocessing module adopts a modular design, including an encryption unit and a sharding unit. The encryption unit integrates a symmetric encryption algorithm, performs encryption operations on the received raw data, and generates encrypted data. The sharding unit divides the encrypted data into multiple data shards according to a preset sharding strategy. After sharding, each data shard is distributed to the corresponding storage node, and the sharding information is synchronized to the smart contract module to facilitate subsequent node behavior verification and data management. The core function of this module is to provide basic security for data storage through encryption and sharding, while improving the efficiency of data storage and access.

[0039] The dynamic signature group management module comprises a group management unit, a key coordination unit, and a lightweight node behavior verification submodule. The group management unit is responsible for the creation, maintenance, and updating of dynamic signature groups, including node addition, removal, and status monitoring. The key coordination unit coordinates the generation and updating of distributed keys, ensuring the secure distribution and synchronization of group private key shares. The lightweight node behavior verification submodule periodically sends random challenges to storage nodes, requiring them to generate storage proofs based on specific data fragments they store. These proofs combine fragments of the group private key share currently held by the node, verifying both the existence and integrity of the data and indirectly proving the validity of the key share.

[0040] The lightweight node behavior verification submodule utilizes the bilinear mapping property to perform batch verification of the received storage proofs. The verification formula is as follows:

[0041] The parameters are explained below: e is a bilinear mapping function, which has bilinearity and nondegeneracy, and can efficiently realize batch verification of multiple stored proofs; The storage proof is aggregated and generated by a specific algorithm from the storage proofs submitted by each node, reducing the amount of data transmission and computational overhead during the verification process; G is a generator of an elliptic curve cyclic group, which possesses secure cryptographic properties and provides the basic mathematical environment for bilinear mappings. To map the challenge information to points on the elliptic curve group, the challenge information includes data fragment identifiers and random numbers, which are mapped to the elliptic curve group through a hash function; The public key of the j-th node participating in the verification is generated in correspondence with the private key share of the node, and is used to verify the legality of the storage proof; K represents the number of nodes participating in this proof, which is determined by the lightweight node behavior verification submodule.

[0042] This verification process eliminates the need to verify the storage proof of each node individually. It can efficiently identify malicious or disconnected nodes without significantly increasing network overhead, ensuring the authenticity and integrity of node storage behavior.

[0043] Searchable Encryption Engine Module: The searchable encryption engine module includes a token generation unit, a signature verification unit, and a blinding processing unit. The token generation unit generates a basic search token based on the query keywords; the signature verification unit receives the authorized signature returned by the dynamic signature group and verifies whether the signature meets the dynamic threshold requirements to ensure the legality of the authorization; after generating the basic search token, the blinding processing unit queries the smart contract module to obtain the real-time reputation score of each node in the current dynamic signature group, and generates a dynamic blinding factor based on this reputation score. This blinding factor is related to the overall reputation status of the target dynamic signature group; the better the overall reputation status, the lower the complexity of the blinding factor.

[0044] The base search token is blinded to form a blinded token, which is then sent to the dynamic signature group. After the blinded token receives authorization from a signature that meets the threshold conditions, it must be deblinded to become a valid search token before being used for searching. This blinding mechanism prevents the search token or partial authorized signature from being intercepted and replayed during transmission, further enhancing the security of the search process.

[0045] Operation Evidence Preservation and Audit Chain Module: This module comprises a data collection unit, a fingerprint generation unit, and a blockchain interaction unit. The data collection unit gathers relevant data during the query operation process, including the encrypted result set of the authorized search token, the blockchain timestamp, and the identifiers of the nodes participating in the signing. The fingerprint generation unit calculates the operation fingerprint according to a preset process. The blockchain interaction unit submits the operation fingerprint to the blockchain network. Through the blockchain's P2P network and consensus mechanism, the operation fingerprint is written into a block for permanent evidence preservation. It also provides a query interface for the operation fingerprint, supporting subsequent audit traceability.

[0046] Smart Contract Module: Deployed on the blockchain and developed using the Solidity language, the smart contract module includes a threshold calculation unit, a behavior monitoring unit, a reputation update unit, a margin management unit, and a group adjustment unit. The threshold calculation unit executes a dynamic threshold calculation function, dynamically generating signature thresholds based on node status; the behavior monitoring unit continuously monitors and stores node behavior data, recording the behavior indicators of each node; the reputation update unit periodically updates the node's reputation score according to a preset reputation update algorithm; the margin management unit manages the margin staked by nodes and performs forfeiture operations when a node is evicted; the group adjustment unit triggers the reconstruction of dynamic signature groups and key updates based on node reputation scores and system requirements, ensuring the system's dynamic adaptability and security.

[0047] This embodiment achieves the following beneficial effects by implementing blockchain-driven encrypted storage of server data through the above method and system: The blockchain-driven server data encryption storage system and method provided in this embodiment achieves secure retrieval and dynamic access control of encrypted data in a distributed storage environment by combining dynamic threshold signatures with searchable encryption technology. The design of dynamic thresholds enables signature authorization requirements to adapt to changes in node status, ensuring system security and improving availability in dynamic environments. Blockchain-based evidence storage of operation fingerprints provides an immutable audit basis for query operations, enabling full-link traceability of operation behavior and facilitating accountability.

[0048] Smart contracts enable real-time monitoring and dynamic adjustment of node reputation, enhancing the system's ability to resist malicious nodes and reducing the risk of data leakage or tampering. The application of a distributed key update protocol avoids data re-encryption when nodes change, improving system operating efficiency. Meanwhile, the lightweight node behavior verification submodule, through a batch verification mechanism, effectively monitors node storage behavior without increasing network overhead, ensuring the integrity of data storage.

[0049] Example 2 like Figs. 1-3 As shown, this embodiment, based on embodiment one, optimizes data encryption efficiency, node behavior verification accuracy, and key update security for high-concurrency enterprise distributed data storage scenarios, further adapting to the high availability requirements in dynamic node environments. The details are as follows.

[0050] Building upon Example 1, this example refines the data encryption and fragmentation strategies to adapt to the large-capacity and high-concurrency access requirements of enterprise-level data. Specifically, after receiving the raw data, the data preprocessing module first selects the corresponding encryption method based on the data's sensitivity level—for core business data, the AES-256 symmetric encryption algorithm is used. This algorithm is widely used in the industry, its security has been verified over a long period, and its encryption and decryption efficiency can meet the real-time processing requirements of high-concurrency scenarios; for non-core reference data, the lightweight SM4 symmetric encryption algorithm is used to reduce system computational overhead while ensuring basic security.

[0051] After encryption, the data fragmentation process employs a "fixed baseline + dynamic adjustment" strategy. For example, the system defaults to a base fragment size of 1GB. When the original data size is an integer multiple of the base size (e.g., 6GB), it is directly divided into six 1GB data fragments. When the original data size is not an integer multiple of the base size (e.g., 4.3GB), it is divided into four 1GB fragments and one 0.3GB fragment. Simultaneously, the data preprocessing module generates a unique identifier for each data fragment, containing the data owner ID, fragment sequence number, and generation timestamp, facilitating precise management and location of fragments by the subsequent dynamic signature group.

[0052] To further enhance the overall credibility of dynamic signature groups, this embodiment supplements the node selection criteria for dynamic signature groups. In some optional implementations, when the dynamic signature group management module creates a signature group, in addition to referencing the initial reputation score of the nodes, it will also filter nodes with "no abnormal behavior records in the past 90 days"—abnormal behavior records include situations such as failing to respond to integrity challenges, submitting false proof of storage, and signature response timeouts. This filtering condition can reduce potentially risky nodes within the initial group, decrease the frequency of subsequent node evictions, and improve system stability.

[0053] In the distributed key generation and distribution process, this embodiment adds a "key share verification" step. Specifically, after distributing the group private key share to each node, the key coordination unit of the dynamic signature group management module sends a random verification request to each node. The node must use the received private key share to sign the random string in the verification request and return the signature result to the key coordination unit. The key coordination unit verifies the signature validity using the group public key. If the verification passes, it confirms that the node has successfully received and correctly stored the private key share; if the verification fails, the private key share is re-distributed to the node until the verification passes. This step avoids the problem of invalid key shares caused by network packet loss or node storage errors, ensuring the normal execution of subsequent signing operations.

[0054] Regarding the "blinding of search tokens based on node reputation" in Implementation Example 1, this embodiment further clarifies the generation logic and deblinding process of the blinding factor. After the searchable encryption engine module generates the basic search token, it first queries the smart contract module to obtain the "overall reputation value" of the current dynamic signature group—this value is the arithmetic mean of the real-time reputation scores of all nodes in the group. For example, when the overall reputation value is higher than 80, the blinding factor uses a 16-bit random number; when the overall reputation value is lower than 80, the blinding factor uses a 32-bit random number. After the blinding factor is generated, it is combined with the basic search token through an XOR operation to form the blinding token.

[0055] In the authorization and signing process of the blinded token in the dynamic signature group, this embodiment adds a "signature order optimization" mechanism. Specifically, the dynamic signature group management module sorts the nodes in the group into "priority response nodes" and "backup response nodes" based on their online response speed. After the blinded token is issued, the priority response node performs the signing operation first. If the number of signatures of the priority response node has reached the dynamic threshold, the issuance of tokens to the backup response node is stopped; if some nodes in the priority response node fail to respond within the timeout period, the backup response node is automatically triggered to fill in the signature. This mechanism can shorten the total time of signature authorization and improve the query response speed in high-concurrency scenarios.

[0056] Regarding the distributed key update protocol as defined in claim 5, this embodiment refines the "key update coordinator selection" and "old key destruction" processes to ensure the security of the key update process. In some optional implementations, the dynamic signature group management module must meet two conditions when selecting a key update coordinator: first, the node's real-time reputation score must rank among the top 3 in the group; second, the node must have participated in key updates no more than twice in the past 30 days. After the coordinator is determined, the random secret generated by each coordinator must undergo "dual-node cross-verification"—that is, coordinator A encrypts its own random secret and sends it to coordinator B, coordinator B decrypts it and verifies the randomness of the secret; only after the verification is passed can it be used to construct a new private key share.

[0057] After the remaining nodes in the group receive the new private key share, this embodiment adds a "forced destruction of the old private key share" step. Specifically, after calculating the final new private key share locally, the node needs to call the "destruction confirmation interface" of the smart contract to upload the storage path and destruction timestamp of the old private key share to the smart contract. After receiving the confirmation information, the smart contract sends a "destruction command" to the node. The node executes the command to delete the old private key share and returns a hash value indicating successful deletion. The smart contract confirms that the old private key has been destroyed by comparing the hash value before allowing the node to use the new private key share. This step can avoid data security risks caused by the leakage of the old private key.

[0058] To enhance the auditing practicality of operation fingerprints, this embodiment supplements the dimensions for generating operation fingerprints. Specifically, when generating operation fingerprints, the operation evidence storage and audit chain module adds a "query initiator identity hash"—this hash is generated from the user ID of the query initiator using a one-way hash function—in addition to the search token hash, result set hash, timestamp, and participant list hash described in Embodiment 1. With this added dimension, the operation fingerprint can not only trace the query operation process but also be associated with the query initiator's identity, facilitating permission tracing in enterprise-level scenarios.

[0059] Meanwhile, this embodiment optimizes the blockchain-based notarization method for operation fingerprints. The operation notarization and auditing chain module no longer directly writes the operation fingerprint to the main chain; instead, it first stores it on a "sidechain" of the blockchain, and then writes the notarization address and notarization time from the sidechain to the main chain. This method reduces the performance overhead of operation fingerprint notarization on the main chain, ensuring that the main chain's transaction processing efficiency remains unaffected in high-concurrency query scenarios.

[0060] In this embodiment, the lightweight node behavior verification submodule of the dynamic signature group management module adds a "tiered challenge" mechanism. Specifically, this submodule sends a random challenge to the storage node every 24 hours. The challenge content is tiered according to the node's reputation score: for nodes with a reputation score higher than 90, the challenge frequency is once every 72 hours, and the challenge content only needs to verify the header checksum of the data shard; for nodes with a reputation score lower than 60, the challenge frequency is once every 12 hours, and the challenge content needs to verify the integrity of three random fragments of the data shard. This mechanism reduces the overall verification overhead of the system while ensuring verification coverage.

[0061] In this embodiment, the smart contract module adds "reputation score update cycle" and "margin gradation settings". Specifically, the reputation score update cycle is no longer a fixed value, but is dynamically adjusted according to the number of nodes—when the total number of nodes in the system exceeds 1000, the update cycle is set to 2 hours; when the total number of nodes is less than 1000, the update cycle is set to 4 hours. Regarding margin management, the margin required for node access is linked to the number of data shards the node plans to store, with each shard corresponding to a $100 margin. Furthermore, when a node's reputation score is higher than 90, it can apply to reduce the margin ratio by 30%. The reduced margin is still locked by the smart contract until the node actively leaves the system.

[0062] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A blockchain-driven method for encrypted storage of server data, characterized in that, Includes the following steps: Step 1: The data owner encrypts the original data and then divides it into multiple data fragments; Step 2: Create and initialize a dynamic signature group for each data shard. The dynamic signature group consists of multiple storage nodes, and generates a corresponding group private key share through a distributed key generation protocol and distributes it to the group members. Step 3: Generate search tokens for query keywords using a searchable encryption engine; Step 4: Submit the search token to the dynamic signature group corresponding to the target data shard for authorization signing. The threshold of the number of nodes required for signing is dynamically calculated and determined by the smart contract deployed on the blockchain based on the real-time status of the dynamic signature group. Step 5: After receiving an authorized search token that meets the dynamic threshold signature, the storage node performs a search operation and returns encrypted search results; Step 6: Generate an operation fingerprint corresponding to this query operation. The operation fingerprint consists of at least the search token hash, the returned result set hash, the timestamp, and the identifiers of the dynamic signature group members who participated in the signing. The operation fingerprint is then stored in the blockchain. Step 7: The smart contract continuously monitors the behavior data of the storage nodes and updates their reputation scores. Based on the updated reputation scores, it dynamically adjusts the composition of the dynamic signature group and the threshold number of nodes required for signing.

2. The blockchain-driven server data encryption and storage method according to claim 1, characterized in that, The threshold number of nodes required for signing in step four is determined by the smart contract using a dynamic threshold calculation function, which is: Where t represents the calculated dynamic threshold, and N represents the total number of online and normal nodes in the current dynamic signature group. This represents the real-time reputation score of the i-th node, whose value is dynamically updated based on the node's historical behavior. This represents the weight coefficient of the i-th node, which is positively correlated with the node's storage contribution and online stability. Based on the baseline threshold parameters preset according to the system security policy, The minimum threshold preset for the system is used to ensure a minimum level of security. This represents the floor operator. This is the function for finding the maximum value.

3. The blockchain-driven server data encryption and storage method according to claim 1, characterized in that, The specific steps for generating the operation fingerprint corresponding to this query operation in step six include: Extract the search token authorized by the dynamic signature group from this query request, calculate its hash value, and denot it as . ; Calculate the overall hash value of the encrypted result set returned by this search, denoted as . ; Get the timestamp of the current block in the blockchain, denoted as ; Combine the unique node identifiers of all dynamic signature group members participating in this search token signing to generate a participant list, calculate the hash value of this list, and denot it as . ; Will , , and After being concatenated in a predetermined order, the hash value is calculated again to generate the final operation fingerprint. Its generating function is: in This represents a string concatenation operation. The specified cryptographic hash function; operation fingerprint It is stored on the blockchain as immutable audit evidence.

4. The blockchain-driven server data encryption and storage method according to claim 1, characterized in that, The specific implementation methods for the smart contract in step seven to continuously monitor the behavioral data of the storage node and update its reputation score include: The smart contract defines and records various behavioral indicators for each storage node, including but not limited to: the number of times data integrity challenges are successfully responded to, the timeliness of submitting storage proofs, the enthusiasm for participating in the dynamic signature group signing process, and the historical online time ratio. The smart contract periodically recalculates the reputation score of each node according to a predefined reputation update algorithm. The reputation update algorithm includes a reward mechanism and a penalty mechanism. For nodes whose behavior meets expectations, their reputation score is improved, and for nodes whose behavior is abnormal or malicious, their reputation score is reduced. When a node's reputation score falls below the malicious node threshold set by the system, the smart contract triggers a node eviction procedure to remove the node from its dynamic signature group and triggers a distributed key update protocol to generate a new group private key share for the group without re-encrypting the original data shards stored off-chain. The smart contract then triggers the forfeiture of the margin pledged by the eviction node.

5. A blockchain-driven server data encryption and storage method according to claim 4, characterized in that, The specific steps for triggering the distributed key update protocol include: Within the dynamic signature group, select several nodes with the highest reputation scores as key update coordinators; Each key update coordinator generates a new random secret and uses a secret sharing algorithm to construct a new private key share among the remaining nodes in the group, excluding the ousted node. The remaining nodes in the group calculate the final new private key share locally through a non-interactive key negotiation protocol based on the received new private key share information, and destroy the old private key share at the same time.

6. A blockchain-driven server data encryption and storage system, applicable to the blockchain-driven server data encryption and storage method according to any one of claims 1-5, characterized in that, The system includes: The data preprocessing module is configured to receive raw data, perform encryption operations, and divide the encrypted data into multiple data fragments. The dynamic signature group management module is configured to create, maintain, and update the corresponding dynamic signature group for each data shard, including managing node members within the group, coordinating the generation and updating of distributed keys, and obtaining dynamically calculated signature thresholds from the smart contract interface. The searchable encryption engine module is configured to generate search tokens based on query keywords and verify the authorization signature of the search token by the dynamic signature group. The operation evidence storage and audit chain module is configured to collect relevant data for query operations, generate operation fingerprints, and submit the operation fingerprints to the blockchain network for permanent evidence storage. The smart contract module, deployed on the blockchain, is configured to perform dynamic threshold calculations, monitor node behavior, update node reputation scores, manage node staking deposits, and trigger the reconstruction of dynamic signature groups and key updates according to predefined rules.

7. A blockchain-driven server data encryption and storage system according to claim 6, characterized in that, The dynamic signature group management module also includes a lightweight node behavior verification submodule, which performs comprehensive verification of node storage behavior in the following ways: The lightweight node behavior verification submodule periodically sends random challenges to the storage nodes, requiring the nodes to generate storage proofs based on specific data shards stored in their storage. The lightweight node behavior verification submodule utilizes the bilinear mapping property to perform batch verification of the received storage proofs. The verification formula is as follows: Where e represents the bilinear mapping function. The storage proof of aggregation is given, where G is a generator of the elliptic curve cyclic group. It maps the challenge information onto points on the elliptic curve group. is the public key of the j-th node participating in the verification, and K is the number of nodes participating in this verification.

8. A blockchain-driven server data encryption and storage system according to claim 6, characterized in that, The searchable encryption engine module is also configured to perform blinding processing on the generated search token based on node reputation, specifically including: After generating the basic search token, the searchable encryption engine module queries the smart contract module to obtain the real-time reputation scores of each node in the current dynamic signature group. Based on the obtained reputation scores, the basic search token is blinded and then sent to the dynamic signature group. The searchable encryption engine module attaches a dynamically generated blinding factor to the token based on the acquired reputation score. This blinding factor is associated with the overall reputation of the target dynamic signature group. After a token that has undergone blinding is granted a signature authorization by a dynamic signature group that meets the threshold conditions, its authorized signature must be deblinded before it can be used for searching.

Images