Decentralized incremental auditing method and device based on homomorphic encryption

Abstract

The invention discloses a decentralized incremental auditing method and device based on homomorphic encryption, and relates to the field of cloud storage security and trusted computing. The method comprises the following steps: performing homomorphic encryption through a data block to obtain a ciphertext block; constructing a Merkle tree according to the ciphertext block, obtaining root hash bound with the current version number, and constructing a version tree composed of the root hash; locating the modified data block index set by querying the version tree, and determining a target range for generating challenges; generating a shared random seed through a Byzantine fault-tolerant protocol, and generating a challenge message based on the seed and the target range by using a pseudo-random function; performing Hash verification and linear aggregation calculation based on homomorphic encryption additive property on a challenge ciphertext block in the challenge message to obtain an aggregation ciphertext; and performing decryption and verification according to the aggregated ciphertext, and executing a Byzantine fault-tolerant consensus algorithm based on a local verification result to generate an audit result. The method achieves the purposes of privacy protection, efficient incremental auditing and decentralized auditing.

Description

Technical Field

[0001] This application relates to the fields of cloud storage security and trusted computing technology, and in particular to a decentralized incremental auditing method and apparatus based on homomorphic encryption. Background Technology

[0002] With the rapid iteration of cloud computing technology, cloud storage, with its advantages of elastic scalability, low-cost operation and maintenance, and cross-terminal access, has become the core choice for individuals, enterprises, and government agencies to store data. However, after data is uploaded to the cloud, users lose physical control over their data. Cloud servers may experience data loss due to hardware failures or software vulnerabilities, or data may be tampered with due to mismanagement by operators or third-party attacks. There is even a risk that cloud service providers may arbitrarily delete infrequently used data to reduce storage costs. Therefore, data integrity auditing, as a key technology for verifying whether cloud data is complete and tamper-proof, has become a core link in ensuring the trustworthiness of cloud storage. As cloud storage scenarios become more complex, some subsequent integrity auditing solutions have gradually revealed many shortcomings.

[0003] Traditional auditing solutions often require auditors to access raw plaintext data or core feature information to verify data integrity, leading to fundamental vulnerabilities in privacy protection. On one hand, some solutions directly employ plaintext verification, requiring the transmission of sensitive user data to the audit node during the audit process, or allowing auditors to directly access plaintext data in cloud storage. If the audit node has security vulnerabilities, internal personnel misconduct, or is maliciously attacked, sensitive information will be leaked, triggering compliance risks and a crisis of user trust. On the other hand, even solutions using simple encryption methods still pose privacy risks. For example, symmetric encryption solutions require sharing keys with the auditor, which can be easily stolen if not properly managed. While hash-based verification solutions avoid plaintext transmission, hash values ​​can be used to infer the characteristics of the original data through data correlation analysis, and the verification process exposes information such as the index and length of data blocks, indirectly revealing the data structure. Existing privacy-protecting auditing solutions mostly focus on a single encryption dimension, failing to establish a fully encrypted design for the verification process, and thus cannot fundamentally eliminate privacy leaks during the audit process.

[0004] One of the core application scenarios of cloud storage is dynamic data updates. However, traditional auditing solutions generally adopt a full-scale auditing model, which requires complete verification of all data blocks for each audit, regardless of whether the data has changed. This leads to a linear increase in computational and communication overhead. The shortcomings of this model are particularly prominent in scenarios with frequent data updates. First, the computational overhead is enormous. For large files or massive collections of small files, full verification consumes a significant amount of computing power from both the auditor and the cloud server, resulting in audit latency of minutes or even hours, which cannot meet the needs of real-time auditing. Second, the communication overhead is too high. Transmitting the credential data required for full verification, such as data block hashes and signature information, consumes a large amount of bandwidth, especially for mobile terminal users or edge nodes with limited bandwidth, potentially leading to network congestion and transmission timeouts. Third, resource utilization is low. Data updates often involve only a small number of data blocks, and the repeated verification of unchanged data blocks during full auditing is an ineffective waste of resources, significantly increasing auditing costs and cloud service operating costs.

[0005] Furthermore, relying on a single audit node is prone to single-point failures or malicious behavior. Over-reliance on the trustworthiness and availability of a single audit node poses a dual risk: First, a single-point failure can lead to audit interruption. If an audit node goes offline due to hardware failure, network outage, system crash, or other reasons, the entire audit process will be halted, making it impossible to verify the integrity of cloud storage data in a timely manner and affecting data availability assessment. Second, there is the risk of malicious behavior and collusion. A single audit node lacks a supervisory and constraint mechanism, which may lead to subjective malicious behavior or collusion with the cloud server. When the cloud server needs to evade responsibility for data loss or tampering, the audit node may conceal the true situation, preventing users from noticing data security risks. In addition, the computing power and storage resources of a single audit node are limited. When facing the auditing needs of large-scale cloud storage clusters, performance bottlenecks are likely to occur, and the risk of malicious attacks on the node is concentrated. Existing multi-node audit solutions mostly adopt a centralized management model, which has not formed a decentralized collaborative mechanism. Problems such as central node failure and abuse of management authority still exist, and the reliability and anti-attack issues cannot be solved from an architectural perspective. Summary of the Invention

[0006] Therefore, it is necessary to provide a decentralized incremental auditing method and apparatus based on homomorphic encryption that can integrate privacy protection, efficient incremental auditing, and decentralized architecture to address the aforementioned technical problems.

[0007] Firstly, this application provides a decentralized incremental auditing method based on homomorphic encryption. The method includes:

[0008] The file is divided into several data blocks, and the data blocks are encrypted using a preset homomorphic encryption key to obtain ciphertext blocks. A Merkle tree is constructed based on the ciphertext blocks, the root hash bound to the current version number is obtained, the ciphertext block sequence and the root hash are uploaded to the cloud server, and a version tree composed of the root hash is constructed.

[0009] By querying the version tree and comparing the differences between the current version and the previous version, the set of data block indexes that have been modified can be located, and the target range for generating challenges can be determined.

[0010] A shared random seed is generated using a Byzantine fault-tolerant protocol, and a challenge message is generated based on the seed and target range using a pseudo-random function.

[0011] Retrieve the challenge ciphertext block from the ciphertext block sequence based on the challenge message, perform hash verification and linear aggregation calculation based on the additive property of homomorphic encryption on the challenge ciphertext block to obtain the aggregated ciphertext;

[0012] The aggregated ciphertext is decrypted and verified, and the Byzantine fault-tolerant consensus algorithm is executed based on the local verification result to generate an audit result.

[0013] In one embodiment, generating challenge messages based on a seed and target range using a pseudo-random function includes:

[0014] Sort each data block in the target range according to its index to form an ordered set;

[0015] Using pseudo-random functions on the set of integers For each element in the set, a pseudo-random number is calculated, and the hash value of the pseudo-random number is obtained. The position value k is obtained by taking the modulo of each hash value. The data block index corresponding to the k-th element is selected from the ordered set and added to the challenge index set; where z represents the number of challenge ciphertext blocks.

[0016] Generate challenge messages based on the challenge index set.

[0017] In one embodiment, generating a challenge message based on a challenge index set includes:

[0018] A new seed is generated using a Byzantine fault-tolerant protocol, and random coefficients are generated based on the new seed and the plaintext space of homomorphic encryption using a pseudo-random function. A challenge message including a challenge index set and random coefficients is then constructed.

[0019] In one embodiment, performing hash verification and linear aggregation calculation based on the additive properties of homomorphic encryption on the challenge ciphertext block to obtain the aggregated ciphertext includes:

[0020] Perform hash verification on each challenge ciphertext;

[0021] After the hash verification is successful, the result of the power calculation is calculated with the challenge ciphertext block as the base and the corresponding random coefficient as the exponent. The product of the power results of all challenge ciphertexts is then calculated to obtain the aggregate ciphertext.

[0022] In one embodiment, the aggregated ciphertext is decrypted and verified, and the Byzantine fault-tolerant consensus algorithm is executed based on the local verification result to generate an audit result including:

[0023] Preliminary verification includes verifying the authenticity of the entity signature that sent the aggregated ciphertext and verifying the mathematical validity of the aggregated ciphertext.

[0024] After the initial verification is passed, the local private key share of the audit node participating in the decryption is used to decrypt the aggregated ciphertext and obtain the decrypted fragment;

[0025] Calculate the Lagrange coefficients for the audit nodes involved in decryption, and combine the decrypted fragments based on the Lagrange coefficients to obtain the aggregated plaintext value;

[0026] Verification based on aggregated plaintext values ​​includes verifying the integrity of data blocks based on homomorphic encryption properties and verifying the mathematical rationality of aggregated plaintext values.

[0027] Based on the verification results of each audit node using aggregated plaintext values, the Byzantine Fault Tolerance consensus algorithm is executed to generate audit results. The system then determines whether Byzantine Fault Tolerance consensus has been achieved based on the audit results. If yes, the root hash and version tree stored in the blockchain are updated. If no, a new round of audit verification is triggered.

[0028] In one embodiment, after generating the audit results, the method further includes:

[0029] Create an audit transaction record; the audit transaction record includes the signatures of all audit nodes that participated in the decryption;

[0030] After the smart contract verifies the audit transaction record, the audit transaction record is written to the blockchain;

[0031] The smart contract's verification of audited transaction records includes:

[0032] Verify the validity of each signature;

[0033] Check whether the audit node corresponding to the signature is a blockchain registered audit node based on the audit node registration information;

[0034] Verify whether the number of signatures meets the conditions for reaching the Byzantine fault-tolerant consensus.

[0035] Secondly, this application also provides a decentralized incremental auditing device based on homomorphic encryption. The device includes:

[0036] Data owner, cloud server, decentralized audit network including several audit nodes, and blockchain;

[0037] The data owner is responsible for dividing the file into several data blocks, encrypting the data blocks with a preset homomorphic encryption key, obtaining ciphertext blocks, constructing a Merkle tree based on the ciphertext blocks, obtaining the root hash bound to the current version number, uploading the ciphertext block sequence and root hash to the cloud server, and constructing a version tree composed of the root hash.

[0038] The audit node is responsible for querying the version tree, comparing the differences between the current version and the previous version, locating the set of data block indexes that have been modified, and determining the target range for generating challenges; it generates a shared random seed through the Byzantine fault tolerance protocol, and uses a pseudo-random function to generate challenge messages based on the seed and the target range.

[0039] The cloud server is responsible for retrieving the challenge ciphertext block from the ciphertext block sequence based on the challenge message, performing hash verification and linear aggregation calculation based on the additive property of homomorphic encryption on the challenge ciphertext block, and obtaining the aggregated ciphertext.

[0040] The audit node is responsible for decrypting and verifying the aggregated ciphertext, executing the Byzantine fault-tolerant consensus algorithm based on the local verification result, and generating the audit result.

[0041] The blockchain is responsible for storing audit node registration information, root hash, seed, and audit transaction records.

[0042] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps in the aforementioned decentralized incremental auditing method based on homomorphic encryption.

[0043] Fourthly, this application also provides a computer-readable storage medium. This computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps in the aforementioned decentralized incremental auditing method based on homomorphic encryption.

[0044] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps in the aforementioned decentralized incremental auditing method based on homomorphic encryption.

[0045] The aforementioned decentralized incremental auditing method and apparatus based on homomorphic encryption divides a file into several data blocks, encrypts the data blocks using a preset homomorphic encryption key to obtain ciphertext blocks, constructs a Merkle tree based on the ciphertext blocks, obtains the root hash bound to the current version number, uploads the ciphertext block sequence and root hash to a cloud server, and constructs a version tree composed of root hashes. By querying the version tree, the differences between the current version and the previous version are compared to locate the set of modified data block indices and determine the target range for generating challenges. A shared random seed is generated using a Byzantine fault-tolerant protocol, and a challenge message is generated based on the seed and the target range using a pseudo-random function. The challenge ciphertext block is retrieved from the ciphertext block sequence based on the challenge message, and hash verification and linear aggregation calculation based on the additive properties of homomorphic encryption are performed on the challenge ciphertext block to obtain aggregated ciphertext. The aggregated ciphertext is decrypted and verified, and the Byzantine fault-tolerant consensus algorithm is executed based on the local verification result to generate audit results. This method employs homomorphic encryption technology to achieve privacy protection; it utilizes Merkle trees to locate modified data blocks and designs a lightweight incremental audit framework to reduce computational and communication overhead; and it utilizes a decentralized audit design with multi-point collaboration to effectively avoid single-point failure issues and adapt to the trusted verification requirements of large-scale cloud storage clusters. Attached Figure Description

[0046] Figure 1 This is a diagram illustrating the application environment of a decentralized incremental auditing method based on homomorphic encryption in one embodiment.

[0047] Figure 2 This is a flowchart illustrating a decentralized incremental auditing method based on homomorphic encryption in one embodiment. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0049] This application provides a decentralized incremental auditing method based on homomorphic encryption, applicable to, for example... Figure 1 In the scenario shown, the entities involved in this method include: Data Owner (DO), Cloud Storage Server (CSS), Decentralized Audit Network (DAN), and Blockchain.

[0050] like Figure 2 As shown, the decentralized incremental auditing method based on homomorphic encryption includes the following steps:

[0051] S101: Divide the file into several data blocks, encrypt the data blocks using a preset homomorphic encryption key to obtain ciphertext blocks; construct a Merkle tree based on the ciphertext blocks, obtain the root hash bound to the current version number, upload the ciphertext block sequence and root hash to the cloud server, and construct a version tree composed of root hashes;

[0052] S102, by querying the version tree, comparing the differences between the current version and the previous version, locating the set of data block indexes that have been modified, and determining the target range for generating the challenge;

[0053] S103 generates a shared random seed through the Byzantine fault-tolerant protocol and uses a pseudo-random function to generate challenge messages based on the seed and target range;

[0054] S104, retrieve the challenge ciphertext block from the ciphertext block sequence according to the challenge message, perform hash verification and linear aggregation calculation based on the homomorphic encryption additive property on the challenge ciphertext block to obtain the aggregated ciphertext;

[0055] S105 decrypts and verifies the aggregated ciphertext, executes the Byzantine fault-tolerant consensus algorithm based on the local verification result, and generates an audit result.

[0056] Before the method begins, system initialization is required, including homomorphic encryption key generation, DAN initialization, and version tree initialization steps.

[0057] First, the steps for generating a homomorphic encryption key are as follows:

[0058] Randomly select two large prime numbers p and q, satisfying and ,in It is the greatest common divisor.

[0059] Calculate the public key modulus . This will serve as the base template for the encryption algorithm, ensuring that the plaintext space is... .

[0060] Select generator ,but They form a cyclic subgroup and exhibit homomorphism:

[0061]

[0062] in This is a homomorphic encryption algorithm. To simplify calculations, let... Using the binomial theorem, we can obtain:

[0063]

[0064] In the model During the calculation, due to It is the modulus, all containing Terms of power 1 or higher will disappear, resulting in:

[0065]

[0066] The above formula facilitates homomorphic operations.

[0067] Define public key It is made public to DAN and CSS.

[0068] Calculate the least common multiple ,in The least common multiple; calculate the decryption auxiliary parameters. , where the function Used for decryption operations.

[0069] Define the private key as .

[0070] The decryption formula is as follows:

[0071]

[0072] Where 'c' represents ciphertext.

[0073] Secondly, the decentralized auditing network consists of N auditing nodes. DAN initialization includes the following steps:

[0074] Each audit node generates an identity identifier and registers with the centralized audit network via a broadcast protocol. Registration information is recorded on the blockchain to ensure its immutability.

[0075] Define the total number of audit nodes To ensure fault tolerance, the maximum number of fault-tolerant nodes is defined based on the PBFT (Practical Byzantine Fault Tolerance) algorithm. This refers to the maximum number of malicious or faulty nodes the system can tolerate. The consensus threshold is set to... It requires at least A resolution can only be passed if all nodes agree, even if there are... One malicious node committed wrongdoing, the remaining... Even an honest node can still guarantee the correct decision.

[0076] Private key Partitioning via Shamir's secret sharing scheme: Choosing a polynomial of degree t-1 ,in Each audit node Obtain private key share Threshold .

[0077] Parameters such as public key PK, node list, and consensus threshold are written into the smart contract for subsequent auditing processes.

[0078] Finally, the version tree initialization steps are as follows:

[0079] Set the initial version number This corresponds to the empty state before data is uploaded.

[0080] For empty data, calculate the root. hash value ,in It is a hash function, which is collision-resistant and one-way.

[0081] Construct a Merkle tree with empty leaf nodes and a root hash. As a version The identifier is stored in the blockchain. During subsequent data uploads, the leaf nodes will be updated with the hash of the data block.

[0082] After system initialization, the system enters S101, which includes the following steps:

[0083] S1011, DO divides file F into t data blocks of fixed size L, denoted as t. The block size L must satisfy... This is to prevent the encrypted data from bloating or overflowing.

[0084] S1012, each data block (Binary) to integer conversion, ensuring (Right now The formula is expressed as follows:

[0085]

[0086] in, It is the binary number of the k-th bit of the data block.

[0087] S1013, for each data block Generate random numbers independently (Right now This ensures that multiple encryptions of the same plaintext yield different results. Even given n, an attacker cannot efficiently factor p and q. This utilizes the public key. Compute ciphertext blocks :

[0088]

[0089] Check each Does it meet the requirements? To avoid invalid ciphertext.

[0090] Assume there is and The aggregation of two data blocks exhibits the following homomorphic properties:

[0091]

[0092] This property allows data to be aggregated in encrypted form during subsequent audits without the need for decryption.

[0093] S1014, Leaf node generation. Calculate each ciphertext block. The hash value is used as the leaf node. leaf node set .

[0094] S1015, Merkle tree structure construction. The hash of the parent node is recursively calculated from bottom to top until the root node. Let... (This can be achieved by padding, where h is the tree height), Level 0 (leaf nodes): ; k-th layer node : The root hash is finally obtained. (v is the current version number).

[0095] S1016, Associated with version number v, stored on the blockchain. Initial version. root hash Calculated based on initial data. Root hash. This uniquely represents the current data state. Any data modification will cause changes in the leaf nodes, which will then propagate through the tree, altering the root hash. Verification can be performed via... Path calculation and location changes. Version sequence. Record the history of data changes.

[0096] S1017, DO encapsulates the ciphertext block sequence and the current version root hash into an upload packet. ,in For timestamps, For the digital signature of DO. Send to CSS, DO verifies successful storage.

[0097] S102 specifically includes the following steps: by querying the version tree, comparing the differences between the current version and the last audited version, extracting the set of modified data block indexes, and providing a target range for challenge generation.

[0098] DAN obtains version sequences from the blockchain. Compare with the previous audit version. And the current version root hash and The modified data block is located by recursively checking the hash changes of leaf nodes through a Merkle tree path. Based on the collision resistance of the hash function, a difference in the root hash necessarily corresponds to a change in a leaf node. Where t is the total number of data blocks, This represents the hash value of the leaf node of the j-th data block in version v. Starting from the root node, compare the hashes of child nodes layer by layer to locate the changed leaf nodes. Extract the set of indices of all modified data blocks, denoted as . Size of the difference set Reflecting the scale of data changes ensures that incremental audits only target specific data. The number of blocks is not the total number of t blocks. Therefore, the complexity is determined by the given blocks. Superior to full scan .

[0099] S103 specifically includes the following steps:

[0100] S1031, DAN nodes generate a shared random seed s using the PBFT protocol. First, the master node proposes a seed value and broadcasts it to all nodes. Then, the nodes reach consensus through preparation and commit phases, requiring at least... All nodes agree, and finally the seed s is recorded on the blockchain to prevent tampering.

[0101] Using a pseudorandom function (PRF) based on a seed s and a difference set Generate challenge index set I. Let the number of challenge blocks be... Then I contains z indices.

[0102]

[0103] right Sort by index to form an ordered set. For each ,calculate Output hash value, modulo Get location Then from Select the k-th index ,join in .make sure ,and If PRF output conflicts occur, they can be avoided by recalculating or adjusting the seed.

[0104] S1032, to avoid association with index selection, a new seed s' is used to ensure coefficient randomness. The new seed s' is also generated through PBFT consensus, ensuring its independence from s. The consensus process for the new seed s' is similar to that of s and needs to be recorded in the blockchain. For each challenge index... Generate random coefficients , The DAN node performs coefficient verification locally. .

[0105] S1033, Construct the challenge message as a tuple Audit the master node to assign sequence numbers and broadcast them. To all nodes. Node verification. Ensure the parameters are valid. Nodes exchange commit messages, when at least... Consensus is reached when all nodes agree. After consensus is passed, DAN will... Broadcast to CSS via a secure channel.

[0106] S104 specifically includes the following steps:

[0107] S1041, CSS receives a challenge message from DAN. Please check the following:

[0108] 1. Does index set I satisfy...? ;

[0109] 2. Verify each random coefficient ;

[0110] 3. Confirm the scale of the challenge Within the limits allowed by the system.

[0111] S1042 will challenge the index Mapping to physical storage location, retrieving challenge ciphertext blocks For each retrieval challenge ciphertext block Perform hash verification: ,in This is the hash of the leaf node of this block in the current version of the Merkle tree. If verification fails, log the error and terminate the audit; if verification succeeds, proceed to S1043.

[0112] S1043 utilizes the additive property of homomorphic encryption to perform linear aggregation computation on the ciphertext block specified in the challenge. For each challenge index... , ciphertext block Increase to coefficient powers

[0113]

[0114] The aggregate ciphertext is obtained by weighted multiplication of all challenge blocks.

[0115] Expanding the above equation using homomorphism:

[0116]

[0117] S1044 encapsulates the aggregated ciphertext into a response message and returns it to the DAN via a secure channel, ensuring the confidentiality and integrity of the transmission process. Response message construction: ,in To aggregate ciphertext, In response to the generation of timestamps, To prevent replay attacks using random numbers, CSS signatures .

[0118] S105 specifically includes the following steps:

[0119] S1051, the DAN node receives the response message returned by the CSS. Verify the authenticity of the CSS signature: .

[0120] Verify aggregated ciphertext Mathematical validity: and .

[0121] S1052 utilizes Shamir's secret sharing technology to enable each audit node to... (That is, all N nodes in DAN) use the local private key share to calculate the decryption fragment: .

[0122] For the set of nodes participating in decryption That is, to achieve Given a set of valid nodes with thresholds, calculate the Lagrange coefficients: Combine and decrypt fragments Finally, the aggregated plaintext value is calculated: ,in , This is another part of the private key.

[0123] Mathematical derivation based on the decryption principle of homomorphic encryption:

[0124]

[0125] S1053, According to the homomorphic encryption property, the aggregated ciphertext C should correspond to a linear combination of the plaintext:

[0126]

[0127] Because DAN does not store plaintext Data integrity is verified through Merkle tree root hashing, and the current version root hash is obtained from the blockchain. Verify that the locally stored Merkle tree structure is consistent with the blockchain; root hash consistency ensures data block consistency. It has not been tampered with. If... This means that the data state upon which DAN builds the Merkle tree is completely consistent with the state when DO last successfully uploaded data to CSS, implying that the data in CSS has not been tampered with since the last update. If This proves that the current data state stored in CSS is inconsistent with the state expected by DO, and the data integrity has been compromised.

[0128] In addition, check the decryption results. Mathematical rationality: And according to the coefficient and data blocks The scope should include .

[0129] S1054, each node Voting is generated based on local verification: ,when And the root hash verification passed. The value is 1 for the first case and 0 for the others. : Binary voting result, 1 indicates pass, 0 indicates failure.

[0130] Then the PBFT consensus process begins, based on the maximum number of fault-tolerant nodes defined in the initialization phase. The conditions for reaching a consensus are determined as follows: .

[0131] Even if there are A malicious node provided an error. The remaining Even an honest node can still guarantee the correct decision.

[0132] S1055, Generate standardized audit result records. When consensus is reached, conditions hour, This indicates that a consensus has been reached; other situations... This indicates that no consensus has been reached.

[0133] Create audit transaction records: ,in This indicates a unique identifier for auditing. It is the set of signatures of the participating nodes, ensuring non-repudiation.

[0134] Smart contracts verify each signature To verify the validity of the signature, check if the signing node is in the list of registered nodes and verify the number of signatures. Ensure that the consensus threshold is reached. Audit transaction records. Write to the blockchain and generate transaction hashes .

[0135] if Update to the latest valid version: , ;if This triggers the exception handling process: the data owner (DO) is notified, the DO re-uploads the difference data block, rebuilds the Merkle tree and updates the root hash, and then triggers a new round of audit verification.

[0136] The beneficial effects of this invention are as follows:

[0137] 1. Employing Paillier homomorphic encryption technology, it supports audit nodes in completing integrity verification without accessing the plaintext, meeting the privacy compliance requirements of sensitive data and preventing privacy leaks.

[0138] 2. Introduce an incremental auditing mechanism and design a lightweight incremental auditing framework driven by Merkle tree and consensus. Only the data update part is verified, reducing the computation and communication overhead in frequent update scenarios.

[0139] 3. Construct a decentralized auditing network. Through the PBFT consensus mechanism and the immutability of blockchain, build a multi-node collaborative auditing network. Through Shamir secret sharing, achieve distributed management of private keys, solve the single point of failure and malicious collusion risks of traditional centralized auditing, and adapt to the trusted verification needs of large-scale cloud storage clusters.

[0140] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0141] Based on the same inventive concept, this application also provides a decentralized incremental auditing device based on homomorphic encryption. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more embodiments of the decentralized incremental auditing device based on homomorphic encryption provided below can be found in the limitations of the decentralized incremental auditing method based on homomorphic encryption above, and will not be repeated here.

[0142] In one embodiment, such as Figure 1 As shown, a decentralized incremental auditing device based on homomorphic encryption is provided, including: a data owner, a cloud server, a decentralized auditing network including several audit nodes, and a blockchain.

[0143] Among them, the data owner (DO) owns the original data, is responsible for data segmentation, homomorphic encryption, Merkle tree construction and encrypted data upload, initiates audits and reprocesses discrepancies when audits fail.

[0144] The cloud storage server CSS stores encrypted data uploaded by DO. After receiving an audit challenge, it verifies the parameters, retrieves the ciphertext block, performs homomorphic aggregation calculation, generates a signed response message, and records the operation log.

[0145] The decentralized auditing network DAN consists of N auditing nodes, which are responsible for network initialization and distributed management of private keys, generating audit challenges, verifying CSS responses, completing threshold decryption and data integrity verification, determining audit results through PBFT consensus and submitting them to the blockchain.

[0146] The blockchain network stores key data such as node registration information, data version hashes, and audit records. It supports node management, parameter calls, and anomaly handling through smart contracts, ensuring process consensus and transparent traceability.

[0147] Specifically, the data owner is responsible for dividing the file into several data blocks, encrypting the data blocks using a preset homomorphic encryption key, obtaining ciphertext blocks, constructing a Merkle tree based on the ciphertext blocks, obtaining the root hash bound to the current version number, uploading the ciphertext block sequence and root hash to the cloud server, and constructing a version tree composed of the root hash.

[0148] The audit node is responsible for querying the version tree, comparing the differences between the current version and the previous version, locating the set of data block indexes that have been modified, and determining the target range for generating challenges; it generates a shared random seed through the Byzantine fault tolerance protocol, and uses a pseudo-random function to generate challenge messages based on the seed and the target range.

[0149] The cloud server is responsible for retrieving the challenge ciphertext block from the ciphertext block sequence based on the challenge message, performing hash verification and linear aggregation calculation based on the additive property of homomorphic encryption on the challenge ciphertext block, and obtaining the aggregated ciphertext.

[0150] The audit node is responsible for decrypting and verifying the aggregated ciphertext, executing the Byzantine fault-tolerant consensus algorithm based on the local verification result, and generating the audit result.

[0151] The blockchain is responsible for storing audit node registration information, root hash, seed, and audit transaction records.

[0152] The modules in the aforementioned decentralized incremental auditing device based on homomorphic encryption can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the corresponding operations of each module.

[0153] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in all of the above method embodiments.

[0154] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in all of the above method embodiments.

[0155] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in all of the above method embodiments.

[0156] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0157] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0158] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0159] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A homomorphic encryption based decentralized incremental auditing method, characterized in that, The method comprises: Splitting a file into a plurality of data blocks, encrypting the data blocks by a preset homomorphic encryption key to obtain ciphertext blocks, constructing a Merkle tree according to the ciphertext blocks to obtain a root hash bound to a current version number, uploading the ciphertext block sequence and the root hash to a cloud server, and constructing a version tree composed of the root hash; By querying the version tree, comparing the differences between the current version and the previous version, locating the modified data block index set, and determining the target range for generating a challenge; A shared random seed is generated by a Byzantine fault tolerance protocol, and a pseudo-random function is used to generate a challenge message based on the seed and the target range; According to the challenge message, the challenge ciphertext block is retrieved from the ciphertext block sequence, and the challenge ciphertext block is subjected to hash verification and linear aggregation calculation based on the additive property of homomorphic encryption to obtain aggregated ciphertext; According to the aggregated ciphertext, decryption and verification are performed, a Byzantine fault tolerance consensus algorithm is executed based on the local verification result, and an audit result is generated.

2. The method of claim 1, wherein, The method comprises: The target range is sorted according to the data block index to form an ordered set; Using pseudo-random functions on the set of integers For each element in the set, a pseudo-random number is calculated, and the hash value of the pseudo-random number is obtained. The position value k is obtained by taking the modulo of each hash value. The data block index corresponding to the k-th element is selected from the ordered set and added to the challenge index set; where z represents the number of challenge ciphertext blocks. The challenge message is generated according to the challenge index set.

3. The method of claim 2, wherein, The method comprises: A new seed is generated by a Byzantine fault tolerance protocol, a pseudo-random function is used to generate a random coefficient based on the new seed and the plaintext space of homomorphic encryption, and the challenge message including the challenge index set and the random coefficient is constructed.

4. The method of claim 3, wherein, The method comprises: Each challenge ciphertext is subjected to hash verification; After the hash verification is passed, the result of the power calculation with the challenge ciphertext block as the base and the corresponding random coefficient as the exponent is calculated, and the product of the results corresponding to the power of all challenge ciphertexts is calculated to obtain the aggregated ciphertext.

5. The method of claim 1, wherein, The method comprises: Preliminary verification, including verifying the authenticity of the entity signature of the aggregated ciphertext and verifying the mathematical validity of the aggregated ciphertext; After the preliminary verification is passed, the aggregated ciphertext is decrypted using the local private key share of the audit node participating in the decryption to obtain a decryption fragment; The Lagrange coefficient of the audit node participating in the decryption is calculated, and the decryption fragments are combined according to the Lagrange coefficient to obtain an aggregated plaintext value; Based on the aggregated plaintext value, verification is performed, including verifying the integrity of the data block and verifying the mathematical reasonableness of the aggregated plaintext value according to the homomorphic encryption property; According to the results of the verification based on the aggregated plaintext value by each audit node, a Byzantine fault tolerance consensus algorithm is executed to generate an audit result, and it is judged whether the Byzantine fault tolerance consensus is reached according to the audit result; if yes, the root hash and the version tree stored in the blockchain are updated; if no, a new round of audit verification is triggered.

6. The method of claim 5, wherein, After the audit result is generated, the method further comprises: Creating an audit transaction record, wherein the audit transaction record includes signatures of all the audit nodes participating in the decryption; After the smart contract verifies the audit transaction record, the audit transaction record is written into the blockchain; The verification of the audit transaction record by the smart contract includes: Verifying the validity of each signature; Checking whether the audit node corresponding to the signature is a registered audit node of the blockchain according to the audit node registration information; Verifying whether the number of signatures meets the condition for reaching the Byzantine fault-tolerant consensus.

7. A homomorphic encryption based decentralized incremental auditing device, characterized in that, The device includes a data owner, a cloud server, a decentralized audit network including a plurality of audit nodes, and a blockchain; The data owner is responsible for splitting a file into a plurality of data blocks, encrypting the data blocks through a preset homomorphic encryption key to obtain ciphertext blocks, constructing a Merkle tree according to the ciphertext blocks, obtaining a root hash bound to a current version number, uploading the ciphertext block sequence and the root hash to the cloud server, and constructing a version tree composed of the root hash. The audit node is responsible for locating a set of modified data block indexes by querying the version tree and comparing the difference between the current version and the previous version, determining the target range for generating a challenge, generating a shared random seed through a Byzantine fault-tolerant protocol, and generating a challenge message based on the seed and the target range using a pseudo-random function. The cloud server is responsible for retrieving a challenge ciphertext block from the ciphertext block sequence according to the challenge message, performing hash verification and linear aggregation calculation based on the additive property of homomorphic encryption on the challenge ciphertext block, and obtaining an aggregated ciphertext. The audit node is responsible for decrypting and verifying based on the aggregated ciphertext, executing a Byzantine fault-tolerant consensus algorithm based on the local verification result, and generating an audit result. The blockchain is responsible for storing audit node registration information, the root hash, the seed, and an audit transaction record.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 6.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

Images