A method and apparatus for cross-server multi-copy certificateless auditing that supports lightweight ownership transfer

Abstract

This application discloses a cross-server multi-copy certificateless auditing method and apparatus supporting lightweight ownership transfer, relating to the field of cloud storage. The method includes: the original data owner, the new data owner, and each cloud server calculating corresponding pseudonyms based on their real identities and submitting them to a key generation center to generate corresponding public and private keys; the original data owner dividing the file into several data blocks, sending the data block set to any three cloud servers for verification, and uploading it to each cloud server upon successful verification, with each cloud server recording the ownership information corresponding to the data block set; wherein, the ownership information includes an initial transfer factor; the original data owner and the new data owner mutually verify each other, updating the transfer factor and ownership information upon successful verification; and the cloud servers performing integrity audits. This method achieves the effects of improving auditing efficiency, reducing computational overhead, improving ownership transfer efficiency, and ensuring data security.

Description

Technical Field

[0001] This application relates to the field of cloud storage technology, and in particular to a method and apparatus for cross-server multi-copy certificateless auditing that supports lightweight ownership transfer. Background Technology

[0002] With the rapid development of technologies such as the Internet of Things (IoT) and artificial intelligence (AI), users can no longer handle massive amounts of data files using local architectures. Cloud storage provides a crucial solution, allowing users to outsource the storage and management of data files to the cloud. However, this data hosting model, which does not store copies locally, faces a fatal flaw: users cannot trust that cloud data is consistently and correctly preserved. Data integrity auditing technology has emerged to address this, allowing users themselves or authorized third-party auditors to verify the integrity of data stored in the cloud. Typically, during the data processing phase, users are required to use their private keys to generate authenticable tags for data blocks within the data file. These data blocks and corresponding tags are then uploaded to the cloud server for storage. During the auditing phase, the user or third-party auditor randomly selects a series of data block indexes and requests the cloud server to calculate data evidence based on the block content of these specified indexes, and simultaneously calculate tag evidence based on the corresponding tags. The data evidence and tag evidence are then returned to the auditor. The auditor determines the integrity of the stored data by checking whether the data evidence and tag evidence satisfy a pre-defined computational relationship. If the verification fails, it can be determined that the cloud data has been corrupted; if the verification succeeds, it can be assured with a very high probability that the data remains intact. Typically, the model of introducing a third-party auditor to conduct auditing interactions with the server on behalf of the user is called public auditing.

[0003] Currently, public auditing is divided into two main categories: single-copy storage auditing and multi-copy storage auditing. Single-copy storage refers to storing only one copy of the data on the server side. Related research focuses on improving auditing performance and security, or enriching its functionality, such as group data sharing, data privacy protection, data dynamics, and resistance to key leakage. Although some research efforts have strived to improve the security of auditing schemes, the single-copy model has a fatal flaw: once the copy is corrupted, it is often too late. This is because data integrity auditing relies heavily on detection, leading to users often being unaware until they receive notification of data corruption, at which point the data is irrecoverable. To improve data availability and recoverability, distributing multiple copies of user data across multiple cloud servers is an ideal solution. Researchers have also conducted a series of explorations into multi-copy storage auditing, mainly focusing on data dynamics and auditing efficiency.

[0004] Although some research on multi-copy auditing exists in the field of public auditing, these studies have the following limitations:

[0005] (1) Most auditing schemes are still built on public key infrastructure, which inevitably introduces too much certificate overhead. The subsequent use of identity signature-based multi-copy methods has inherent key custody problems. Currently, there are several schemes that use certificateless signatures to achieve multi-copy auditing. However, these schemes have failed to achieve cross-server storage and are also limited by the bottleneck of local tag computing performance.

[0006] (2) High tag generation overhead: Traditional methods require data owners to generate authentication tags for each data block. The calculation process involves a large number of group multiplications and exponentiation operations. The computational overhead always increases linearly with the number of blocks. Even if partitioning technology is applied to data partitioning, it fails to fundamentally solve the problem. As the amount of data increases, the heavy computational overhead will burden the local system.

[0007] (3) Difficulty in transferring data ownership: Existing solutions are not efficient enough to support data acquisition scenarios. This is because, after user A's data is acquired by user B, directly applying existing solutions requires the user to re-download and recalculate the tags for the acquired data, which is a very time-consuming process. Although the computational cost of tag conversion can be transferred to other entities besides the local end, the cost of tag conversion is always proportional to the number of data blocks being converted. The larger the amount of acquired data, the greater the cost.

[0008] (4) Reliance on a Trusted Third Party: Most solutions rely on a fully trusted third-party auditor (TPA) to perform the audit. Although some studies have attempted to introduce blockchain to address the trust assumption problem, neither uploading audit logs to the blockchain nor migrating data to blockchain storage is the optimal solution. This is because blockchain faces various potential threats, and some users do not want to interact with the blockchain solely for audit data, as such interaction consumes their bandwidth resources. In other words, how to exclude third-party auditors from the existing audit framework is a research question worthy of in-depth exploration. Summary of the Invention

[0009] Therefore, it is necessary to provide a method and apparatus for cross-server multi-copy certificateless auditing that supports lightweight ownership transfer, addressing the aforementioned technical issues.

[0010] Firstly, this application provides a certificate-free auditing method for cross-server multi-copy systems supporting lightweight ownership transfer, including the original data owner, the new data owner, a key generation center, and several cloud servers. The method includes:

[0011] The key generation center generates the system's public parameters and the system's master private key;

[0012] The original data owner, the new data owner, and each cloud server calculate the corresponding pseudonym based on their real identity and submit it to the key generation center. The center then obtains the corresponding private key fragment by combining the system's public parameters and the system's master private key, and generates the corresponding public key and private key based on the private key fragment and the selected secret value.

[0013] The original data owner divides the file into several data blocks, encodes the data blocks, constructs a Merkle tree using the hash values ​​of the encoded data blocks, and sends the processed data block set and the root node of the Merkle tree to any three cloud servers to complete the calculation and verification of block labels. If the verification is successful, a file signature is generated based on the owner's private key, and the file signature, data block set, file identifier, and root node are uploaded to each cloud server. Each cloud server reconstructs the Merkle tree to verify the uploaded data set and file signature. After successful verification, the uploaded data information is stored and the ownership information corresponding to the data block set is recorded. The ownership information includes the current system timestamp, file identifier, original data owner pseudonym, file signature, and initial conversion factor.

[0014] The original data owner generates an ownership transfer certificate based on the corresponding private key, and the new data owner generates an ownership acceptance certificate based on the corresponding private key. The original data owner and the new data owner verify each other based on the ownership transfer certificate and the ownership acceptance certificate, and update the conversion factor and ownership information if the verification is successful.

[0015] The cloud server performs integrity audits based on ownership information, data block sets, and block tag sets.

[0016] In one embodiment, the original data owner, the new data owner, and each cloud server calculate corresponding pseudonyms based on their real identities and submit them to the key generation center. The corresponding private key fragment is obtained by combining the system's public parameters and the system's master private key. Based on the private key fragment and the secret value, the corresponding public and private keys are generated, including:

[0017] The original data owner, the new data owner, and each cloud server randomly select secret values, and calculate the corresponding public parameters and pseudonyms based on the secret values.

[0018] The receiving key generation center calculates the corresponding private key fragment based on the pseudonym and the system master private key, verifies the private key fragment according to the system's public parameters, and constructs a complete private key based on the private key fragment and secret value after successful verification, and constructs a public key based on the public parameters and the system's public parameters.

[0019] In one embodiment, the data blocks are encoded, a Merkle tree is constructed using the hash value of the encoded data blocks, and the processed set of data blocks and the root node of the Merkle tree are sent to any three cloud servers to complete the calculation and verification of block labels, including:

[0020] After encoding each data block, calculate its hash value, construct a Merkle tree based on the block hash value, and obtain the root node;

[0021] The encoded data block set and root node are sent to the first cloud server, the second cloud server and the third cloud server randomly selected from several cloud servers;

[0022] The first cloud server recalculates the hash value of each data block in the data block set, constructs a Merkle tree, and verifies the consistency of the root node. If the consistency verification is successful, it calculates a block label for each data block, aggregates all block labels into an aggregate label, and sends it to the second cloud server.

[0023] The second cloud server verifies the aggregated tag. If the verification fails, it coordinates with the third cloud server to recalculate the block tag. If the verification succeeds, it sends a notification to the original data owner.

[0024] In one embodiment, the original data owner and the new data owner mutually verify each other based on the ownership transfer certificate and the ownership acceptance certificate, and update the transfer factor and ownership information upon successful verification, including:

[0025] The new data owner calculates the public value based on a random number of selections and sends the public value and ownership acceptance certificate to the original data owner;

[0026] The original data owner verifies the correctness of the ownership acceptance certificate. After the verification is successful, the first verification value is calculated based on the public value and the original data owner's corresponding secret value. The first verification value and the ownership transfer certificate are then sent to the new data owner.

[0027] The new data owner verifies the correctness of the ownership conversion certificate. After the verification is successful, the second verification value is calculated based on the original data owner's corresponding public parameters and the number of random selections.

[0028] The first verification value and the second verification value are mutually verified. After the verification is successful, the conversion factor is calculated based on the first verification value, the pseudonym of the original data owner, the pseudonym of the new data owner, and the file identifier.

[0029] The new data owner calculates the file signature and sends a transfer request to all cloud servers; the transfer request includes an ownership transfer certificate, an ownership acceptance certificate, a transfer factor, a current system timestamp, and a file identifier;

[0030] Each cloud server verifies the validity of the ownership conversion certificate, ownership acceptance certificate, and the current system timestamp. After successful verification, the ownership information is updated based on the conversion factor.

[0031] In one embodiment, the cloud server performs integrity auditing based on ownership information, a set of data blocks, and a set of block tags, including:

[0032] Select two cloud servers from a number of cloud servers to serve as the auditor and the initial auditee, respectively.

[0033] The auditor generates a set of challenges and sends them to the auditee.

[0034] The auditee calculates data evidence and label evidence based on the challenge set, data block set, and block labels, and sends the data evidence and label evidence to the auditor;

[0035] Auditors determine whether ownership has changed based on ownership information, and verify the cases of ownership change and ownership not change separately;

[0036] If verification fails, immediately notify the current data owner to reselect an auditee from several cloud servers for cross-verification to determine whether the initial auditee's data is corrupted.

[0037] In one embodiment, when the auditee determines that the data is corrupt, the method further includes:

[0038] The auditor initiates integrity checks on all cloud servers except the auditor and the auditee, and selects several cloud servers as recovery sources from those that respond to the integrity checks and pass the verification, based on their response speed.

[0039] Based on the set of data blocks stored in the recovery source, the auditor uses a voting mechanism to select the target set of data blocks to obtain the recovery file;

[0040] The auditee generates new block labels based on the recovered files;

[0041] The auditor verifies the correctness of the new block label. If the verification passes, the auditee is reintroduced into the audit cycle.

[0042] Secondly, this application also provides a certificateless auditing apparatus for cross-server multi-copy systems that supports lightweight ownership transfer. The apparatus includes the original data owner, the new data owner, several cloud servers, and a key generation center, wherein:

[0043] The key generation center is used to generate the system's public parameters and the system's master private key; and the original data owner, the new data owner, and each cloud server calculate the corresponding pseudonym based on their real identity and submit it to the key generation center. The center then combines the system's public parameters and the system's master private key to obtain the corresponding private key fragment, and generates the corresponding public key and private key based on the private key fragment and the selected secret value.

[0044] The original data owner divides the file into several data blocks, encodes the data blocks, constructs a Merkle tree using the hash values ​​of the encoded data blocks, and sends the processed data block set and the root node of the Merkle tree to any three cloud servers to complete the calculation and verification of block labels. If the verification is successful, a file signature is generated based on the private key, and the file signature, data block set, file identifier, and root node are uploaded to each cloud server. Each cloud server reconstructs the Merkle tree to verify the uploaded data set and the file signature. After successful verification, the uploaded data information is stored and the ownership information corresponding to the data block set is recorded. The ownership information includes the current system timestamp, file identifier, original data owner pseudonym, file signature, and initial conversion factor.

[0045] The original data owner generates an ownership transfer certificate based on the corresponding private key, and the new data owner generates an ownership acceptance certificate based on the corresponding private key. The original data owner and the new data owner verify each other based on the ownership transfer certificate and the ownership acceptance certificate, and update the conversion factor and ownership information if the verification is successful.

[0046] The cloud server performs integrity audits based on ownership information, data block sets, and block tag sets.

[0047] 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 above-described method for cross-server multi-copy certificateless auditing supporting lightweight ownership transfer.

[0048] 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 method for cross-server multi-copy certificateless auditing supporting lightweight ownership transfer.

[0049] 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 above-described method for cross-server multi-copy certificateless auditing supporting lightweight ownership transfer.

[0050] The aforementioned method and apparatus for cross-server multi-copy certificateless auditing supporting lightweight ownership transfer includes the following steps: A key generation center generates system public parameters and a system master private key; the original data owner, the new data owner, and each cloud server calculate corresponding pseudonyms based on their real identities and submit them to the key generation center; the center obtains corresponding private key fragments by combining the system public parameters and the system master private key; and generates corresponding public and private keys based on the private key fragments and selected secret values; the original data owner divides the file into several data blocks, encodes the data blocks, constructs a Merkle tree using the hash values ​​of the encoded data blocks, sends the processed data block set and the root node of the Merkle tree to any three cloud servers to complete the calculation and verification of block labels; if the verification is successful, a file signature is generated based on the private key, and the file signature is then sent to the cloud servers. The data block set, file identifier, and root node are uploaded to each cloud server. Each cloud server reconstructs a Merkle tree to verify the uploaded data set and file signature. After successful verification, the uploaded data information is stored, and the ownership information corresponding to the data block set is recorded. This ownership information includes the current system timestamp, file identifier, original data owner pseudonym, file signature, and initial conversion factor. The original data owner generates an ownership conversion credential based on their private key, and the new data owner generates an ownership acceptance credential based on their private key. The original and new data owners mutually verify each other's ownership conversion and acceptance credentials, and update the conversion factor and ownership information upon successful verification. The cloud servers perform integrity auditing based on the ownership information, data block set, and block tag set. This method achieves lightweight ownership transfer by introducing a conversion factor; achieves efficient and autonomous auditing through mutual auditing verification between cloud servers; improves data availability and recoverability through cross-server multi-copy storage; and avoids the complexity of certificate management in traditional public key infrastructures and the key escrow problems of identity-based cryptography by employing certificateless signing technology. Therefore, this method has achieved certain results in improving audit efficiency, reducing computational overhead, improving ownership transfer efficiency, and ensuring data security. Attached Figure Description

[0051] Figure 1 This is a flowchart illustrating a cross-server multi-replica certificateless auditing method that supports lightweight ownership transfer in one embodiment.

[0052] Figure 2 This is a block diagram of a cross-server multi-copy certificateless auditing apparatus that supports lightweight ownership transfer in one embodiment. Detailed Implementation

[0053] 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.

[0054] This application provides a method for cross-server multi-replica certificate-free auditing that supports lightweight ownership transfer. This method involves the following three entities:

[0055] 1. Users (U): Divided into two categories: the original data owner (User A) and the new data owner (User B). User A is responsible for processing the files, including partitioning and creating copies. When a data acquisition occurs, User B acquires ownership of the files.

[0056] 2. Multiple Cloud Servers (CS): These servers possess sufficient storage space and are responsible for storing and managing uploaded user data. Replicas of user data are distributed across multiple cloud servers. It is assumed that each replica is stored as a single unit on one server; that is, individual replicas are not sharded.

[0057] 3. Key Generation Center (KGC): Responsible for generating public parameters and private keys during the system initialization phase.

[0058] like Figure 1 As shown, the method includes the following steps:

[0059] S102, The key generation center generates the system's public parameters and the system's master private key;

[0060] S104, the original data owner, the new data owner, and each cloud server calculate the corresponding pseudonym based on their real identity and submit it to the key generation center. Combine the system's public parameters and the system's master private key to obtain the corresponding private key fragment, and generate the corresponding public key and private key based on the private key fragment and the selected secret value.

[0061] S106, the original data owner divides the file into several data blocks, encodes the data blocks, constructs a Merkle tree using the hash values ​​of the encoded data blocks, and sends the processed data block set and the root node of the Merkle tree to any three cloud servers to complete the calculation and verification of block labels. If the verification is successful, a file signature is generated based on the private key, and the file signature, data block set, file identifier, and root node are uploaded to each cloud server. Each cloud server reconstructs the Merkle tree to verify the uploaded data set and the file signature. After successful verification, the uploaded data information is stored and the ownership information corresponding to the data block set is recorded. The ownership information includes the current system timestamp, file identifier, original data owner pseudonym, file signature, and initial conversion factor.

[0062] S108, the original data owner generates an ownership transfer certificate based on the corresponding private key, the new data owner generates an ownership acceptance certificate based on the corresponding private key, the original data owner and the new data owner verify each other based on the ownership transfer certificate and the ownership acceptance certificate, and update the conversion factor and ownership information if the verification is successful;

[0063] S110, the cloud server performs integrity auditing based on ownership information, data block set, and block tag set.

[0064] Specifically, S102 includes the following steps:

[0065] S1021, KGC selects two multiplication cyclic groups. and Their order is all large prime numbers. .

[0066] S1022, KGC selects a computable bilinear pair. .

[0067] S1023, KGC selects 4 one-way cryptographic hash functions: , , .

[0068] S1024, KGC randomly selects a cyclic group Two generators and .

[0069] S1025, KGC randomly selects the system master key. And calculate the system public key. .

[0070] S1026, KGC releases system parameters And secretly store the system's master private key. .

[0071] In S104, the original data owner New data owner L cloud storage servers Each user submits their pseudonym to KGC to obtain a portion of the private key, and then combines this with their chosen secret parameters to generate their complete public and private keys. The specific steps include:

[0072] S1041, Randomly select a secret value And calculate the public parameters Calculate your own katakana ,in for The real identity identifier, the introduction of pseudonyms is to protect the user's real identity. Submit your pseudonym to KGC To obtain a portion of the private key.

[0073] S1042, KGC is Calculate private key fragment Send to .

[0074] S1043, receive Afterwards, verification Correctness: If the equation holds true, then accept As a fragment of the private key. Otherwise, reject.

[0075] S1044, Build a complete private key .at the same time Build your own public key And made public.

[0076] S1045, similarly. Submit pseudonyms to KGC in the same manner. Obtain the complete private key With public key .

[0077] S1046, each cloud server Submit your pseudonym to KGC in the same manner. Obtain the complete private key With public key .

[0078] In S106, it is assumed that Has a corresponding file identifier Data files , File The data is divided into blocks, encoded, and a Merkle tree is constructed using the hash values ​​of the encoded blocks. The processed set of data blocks and the root node of the Merkle tree are then sent to L cloud servers. Any three cloud servers in the cloud can be used to complete the calculation and verification of the block tag. If the verification passes, Generate file signatures and upload the corresponding data sets to L cloud servers for storage. The specific steps are as follows:

[0079] S1061, Original data file Divide into n data blocks: { ,in .

[0080] S1062, Calculate the hash value of the original file For each raw data block ,Will Encoded as The processed file is The purpose of encoding is to protect data privacy.

[0081] S1063, For each data block Calculate hash value ,in Obtain the set of hash values . use As leaf nodes, construct a Merkle tree. Group the leaf nodes in pairs, calculate the hash value of their parent nodes, and recursively move upwards until a unique root node is obtained, denoted as . .

[0082] S1064, block set as well as Send to any two of the L cloud servers, assuming it is the first cloud server. With the second cloud server , Additionally, a third-party cloud server will be randomly selected. As a backup verifier, .

[0083] S1065, For each data block received Recalculate its hash value Using the calculated As a leaf node, the Merkle root is recalculated. .if This proves that the received set of data blocks has not been tampered with. If This indicates that the data has been tampered with during transmission. Refuse to store and request to re-upload.

[0084] S1066, Calculate a block label for each block hash value: Then, aggregate all the block tags to get the aggregated tag: . Will Return to .

[0085] S1067, Verify the equation Is it true or false? If the verification fails, Coordination Perform the block label calculation process. If the verification passes, Prepare for data upload.

[0086] S1068, Use the full private key Generate file signature . Sign the file and data block set Document Identifier and tree roots Uploaded to L cloud servers.

[0087] S1069, each Perform the following operations before storing the data:

[0088] 1) For each received data block Recalculate its hash value Using the calculated As a leaf node, recalculate the Merkle root to obtain... .if This proves that the received data block has not been tampered with during transmission. If This indicates that the data has been tampered with during transmission. Refuse to store and request to re-upload.

[0089] 2) Verification Validity: If verification fails, Re-request Upload the dataset. If successful, all... One server storage And record the ownership information of the uploaded files. , This is the current system timestamp. The initial conversion factor is set to 1.

[0090] S108 primarily performs data ownership transfer operations, the specific operations are as follows:

[0091] S1081, Select random number Calculate the public value hash value , Use the current system timestamp. Then use your private key and a random number. Generate ownership transfer certificate and send .

[0092] S1082, Select random number Calculate the public value hash value , Use the current system timestamp and a private key with a random number. Generate conversion acceptance certificate .

[0093] S1083, Generate random selection values ,calculate ,send Give .

[0094] S1084, verify Correctness: After successful verification, calculate the first verification value. ,send Give .

[0095] S1085, verify Correctness: After successful verification, calculate the second verification value. .

[0096] S1086, Calculate the final conversion factor .

[0097] S1087, Calculate the new file signature Send transfer request to all servers . This is the current system timestamp.

[0098] S1088, each use verify ,use verify and verification timestamp The validity of the verification is confirmed. Once verified, the ownership information is updated. , This is the current system timestamp.

[0099] S1089, the server returned a confirmation of successful transfer. And record the ownership change log: .

[0100] The primary purpose of S110 is to identify abnormal cloud servers; therefore, a cloud server in a "normal" state is selected as the auditor, assuming it is... The auditor selected a cloud server in the system that was "potentially damaged" as an example. This refers to storage servers considered to be at risk of data corruption. . Generate a set of random challenges And send to , Calculate audit evidence Send to . The audit evidence is verified based on two scenarios involving ownership division.

[0101] A cloud server in a "normal" state refers to a server that can stably, efficiently, and securely perform its data storage and management functions, such as normal data read / write, normal data management functions (e.g., data organization, classification, and retrieval), and meets security standards and performance stability. A server in a "potentially damaged" state refers to a server that cannot normally perform its data storage and management functions due to various reasons, such as: damaged storage media, damage to hardware components such as CPU, memory, and motherboard, system crashes, software vulnerabilities, and network anomalies.

[0102] The specific steps for S110 are as follows:

[0103] S1101, Generate a set of challenges ,in Belongs to a randomly selected index set , These are random coefficients. Send to .

[0104] S1102, Computational data evidence With label evidence . audit evidence Send to .

[0105] S1103, Verify the evidence. Verification equations fall into two categories based on ownership:

[0106] Scenario 1: The ownership of the data file has not changed; the file belongs to the original owner. The verification formula is: .

[0107] Scenario 2: Data file ownership changes, the file belongs to the new owner ( The verification formula is: .

[0108] S1104, Audit Decision:

[0109] If the verification passes Record success and update the audit log. No user notification is required.

[0110] If verification fails Immediately alert the current data owner and initiate cross-validation with other replica servers to identify potentially corrupted replicas.

[0111] In one embodiment, when the auditor Upon verification failure and confirmation of data corruption, a data recovery mechanism is triggered to recover the damaged data from a healthy copy. The specific steps are as follows:

[0112] S201, After verification fails, immediately initiate cross-validation requests to other servers storing the same data copies to confirm the extent of the corruption. Confirmation After the copy on the device is corrupted, Will Mark it as "potentially damaged" and temporarily suspend its participation in the audit process.

[0113] S202, Send a corruption alert to the current data owner, including the identifier of the corrupted server and the corruption timestamp.

[0114] S203, As the coordinator, initiate rapid integrity checks to the other L-2 servers. Each response... examine: The servers that passed verification were selected, and those with the fastest response time were chosen. One server as the recovery source ( ).

[0115] S204, Coordination selected A complete server The majority voting mechanism is used to resolve data block inconsistencies. In other words, for each data block, each recovery source votes on the state of the data block, and the voting results determine which version of the data block is adopted as the final consistent version. In this mechanism, as long as more than half (i.e., a majority) of the cloud servers reach a consensus, the result is considered reliable and can be used as the unified data block state for the entire system. .

[0116] S205, Recover Complete Data back, Regenerate new block tags: .

[0117] S206, verify Correctness of newly generated block tags: If the verification passes, The status was restored from "potentially damaged" to "normal" and the system was reinstated for audit polling.

[0118] S207, Update system audit log, record recovery events. .

[0119] S208, if during the recovery process, it is found that most copies are corrupted (e.g., the number of cloud servers in the "potentially corrupted" state exceeds...). Immediately notify the system and inform the data owner to intervene manually.

[0120] Throughout the method's lifecycle, the entities interact as follows: First, the Key Generation Center (KGC) initializes the system and generates pseudonymous partial private keys for users and cloud servers. Then, the original data owner, User A, delegates the arduous task of calculating data block labels to an optional cloud server, only uploading the data by constructing a Merkle tree and generating a file signature. Upon data acquisition, the original owner, User A, and the new owner, User B, jointly generate a conversion factor through a secure two-way authentication protocol and notify all cloud servers storing copies to update audit permissions, achieving a lightweight transfer of ownership. During auditing, the scheme removes the traditional third-party auditor; instead, cloud servers challenge and verify evidence against each other, notifying users only when verification fails. Finally, when auditing reveals data corruption, the cloud server acting as the auditor coordinates with other cloud servers holding intact copies to perform data recovery and reconstruction, ensuring data availability.

[0121] The innovative aspects of this invention are as follows:

[0122] First, the computational burden on the labeling side is transferred. During the labeling phase, the user is only responsible for calculating the hash value, building the Merkle tree, and generating the file signature; the labeling itself is handled by the cloud server. The user possesses the plaintext data locally, calculates the hash value based on this data, and then hands it over to the cloud server for label calculation. The servers then verify each other. Compared to traditional methods where users must calculate labels for each data block individually, in this solution, the user does not participate in the block labeling process. This indicates that the computational burden on the user's local end is significantly reduced during the labeling phase.

[0123] Secondly, in real-world scenarios, acquisitions between companies are common. Once company A is acquired by company B, the owner of the data stored in the cloud changes from A to B. Traditional auditing solutions require corresponding data tag conversion. The most intuitive idea is for the new owner to generate new tags for all converted data blocks, which incurs enormous overhead for large files. Current solutions attempt to use cloud servers as the central hub for conversion, where the cloud server updates tags based on user-calculated conversion factors. The computational cost of this method also increases linearly with the number of data blocks. It's important to note that audit evidence can be verified because there's a corresponding computational relationship between data blocks and tags. Although the owner changes, the data itself remains the same. Users can calculate conversion factors, which are then sent to the auditor. The auditor uses these conversion factors to verify the audit evidence, thus effectively verifying the converted evidence. This conversion strategy makes the overhead independent of the size of the converted data, making it suitable for performance-constrained IoT scenarios.

[0124] Finally, cloud servers act as auditors for each other, eliminating TPAs ​​and simplifying the audit framework. Since different servers store their own data copies, the cloud server acting as the auditor generates random challenges, and the cloud server acting as the validator generates corresponding evidence based on these challenges. The cloud server does not need to notify the user as long as the verification passes; it only needs to notify the user if the verification fails.

[0125] The beneficial effects achieved by this invention are as follows:

[0126] (1) Eliminating public auditing of TPA: By utilizing mutual auditing and verification between cloud servers, this solution removes the reliance on trusted third-party auditors (TPAs). This not only simplifies the auditing framework and reduces system complexity and potential trust risks, but also avoids bandwidth consumption caused by user interaction with the blockchain. The cloud server itself acts as the auditor, responsible for initiating challenges and verifying evidence, and only notifies the user when verification fails, thus achieving efficient and autonomous auditing.

[0127] (2) Cross-server multi-replica storage: By distributing data replicas across multiple cloud servers, the availability and recoverability of data are improved. Even if one replica is damaged, the other replicas can still ensure the integrity and accessibility of the data, effectively avoiding the risk of permanent data loss in the single-replica storage mode.

[0128] (3) Certificateless signing system: The certificateless signing technology avoids the complexity of certificate management in traditional public key infrastructure and the key custody problem of identity-based cryptography system.

[0129] (4) Lightweight transfer of ownership: In scenarios involving changes in data ownership (such as data acquisition), the solution introduces a conversion factor to achieve a lightweight transfer of data auditing rights. The computational overhead of the conversion process is independent of the data size, thus efficiently supporting the migration of ownership of large-scale data and solving the problem of huge computational overhead caused by regenerating labels in existing solutions.

[0130] (5) Constant local overhead during tag computation: The heavy task of data block tag computation is transferred to the cloud server for execution, and the local computation overhead of the user is reduced to a constant level. The cloud server is responsible for tag computation, which reduces the computational burden on the user's local device, and is especially suitable for terminal devices with limited computing power.

[0131] (6) Data privacy protection: During the data processing stage, the solution is designed to ensure that no entity other than the data owner (including cloud servers and auditors) can obtain or infer the plaintext of the data.

[0132] (7) Identity privacy protection: Users and cloud servers participate in the entire process under pseudonyms, and other entities cannot obtain their real identities.

[0133] (8) Data corruption recovery: When a cloud server storing a copy faces data corruption, it can use copies on other cloud servers storing the same file to recover the data.

[0134] 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.

[0135] Based on the same inventive concept, this application also provides a cross-server multi-copy certificateless auditing device that supports lightweight ownership transfer. 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 cross-server multi-copy certificateless auditing device supporting lightweight ownership transfer provided below can be found in the limitations of the cross-server multi-copy certificateless auditing method supporting lightweight ownership transfer described above, and will not be repeated here.

[0136] In one embodiment, such as Figure 2 As shown, a certificate-free auditing device for cross-server multi-copy systems that supports lightweight ownership transfer is provided, including the original data owner, the new data owner, several cloud servers, and a key generation center, wherein:

[0137] The key generation center is used to generate the system's public parameters and the system's master private key; and the original data owner, the new data owner, and each cloud server calculate the corresponding pseudonym based on their real identity and submit it to the key generation center. The center then combines the system's public parameters and the system's master private key to obtain the corresponding private key fragment, and generates the corresponding public key and private key based on the private key fragment and the selected secret value.

[0138] The original data owner divides the file into several data blocks, encodes the data blocks, constructs a Merkle tree using the hash values ​​of the encoded data blocks, and sends the processed data block set and the root node of the Merkle tree to any three cloud servers to complete the calculation and verification of block labels. If the verification is successful, a file signature is generated based on the private key, and the file signature, data block set, file identifier, and root node are uploaded to each cloud server. Each cloud server reconstructs the Merkle tree to verify the uploaded data set and the file signature. After successful verification, the uploaded data information is stored and the ownership information corresponding to the data block set is recorded. The ownership information includes the current system timestamp, file identifier, original data owner pseudonym, file signature, and initial conversion factor.

[0139] The original data owner generates an ownership transfer certificate based on the corresponding private key, and the new data owner generates an ownership acceptance certificate based on the corresponding private key. The original data owner and the new data owner verify each other based on the ownership transfer certificate and the ownership acceptance certificate, and update the conversion factor and ownership information if the verification is successful.

[0140] The cloud server is used for integrity auditing based on ownership information, data block sets, and block tag sets.

[0141] The modules in the aforementioned cross-server multi-copy certificateless auditing device supporting lightweight ownership transfer 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.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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.

[0146] 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.

[0147] 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.

[0148] 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 patent 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 cross-server multi-copy certificate-free auditing method supporting lightweight ownership transfer, comprising the original data owner, the new data owner, a key generation center, and several cloud servers, characterized in that, The method includes: The key generation center generates the system's public parameters and the system's master private key; The original data owner, the new data owner, and each cloud server calculate the corresponding pseudonym based on their real identity and submit it to the key generation center. The center then obtains the corresponding private key fragment by combining the system's public parameters and the system's master private key, and generates the corresponding public key and private key based on the private key fragment and the selected secret value. The original data owner divides the file into several data blocks, encodes the data blocks, constructs a Merkle tree using the hash values ​​of the encoded data blocks, and sends the processed set of data blocks and the root node of the Merkle tree to any three cloud servers to complete the calculation and verification of block labels. If the verification is successful, a file signature is generated based on the private key, and the file signature, the set of data blocks, the file identifier, and the root node are uploaded to each cloud server. Each cloud server reconstructs the Merkle tree to verify the uploaded data set and the file signature. After successful verification, the uploaded data information is stored and the ownership information corresponding to the set of data blocks is recorded. The ownership information includes the current system timestamp, file identifier, original data owner pseudonym, file signature, and initial conversion factor. The original data owner generates an ownership transfer certificate based on the corresponding private key, and the new data owner generates an ownership acceptance certificate based on the corresponding private key. The original data owner and the new data owner verify each other based on the ownership transfer certificate and the ownership acceptance certificate, and update the transfer factor and the ownership information if the verification is successful. The cloud server performs an integrity audit based on the ownership information, the data block set, and the block tag set.

2. The method according to claim 1, characterized in that, The process of calculating corresponding pseudonyms based on the original data owner, the new data owner, and each cloud server's real identity and submitting them to the key generation center, obtaining corresponding private key fragments by combining the system's public parameters and the system's master private key, and generating corresponding public and private keys based on the private key fragments and the selected secret value includes: The original data owner, the new data owner, and each cloud server randomly select a secret value, and calculate the corresponding public parameters and the corresponding pseudonym based on the secret value; The receiving key generation center calculates the corresponding private key fragment based on the pseudonym and the system master private key, verifies the private key fragment according to the system public parameters, and constructs a complete private key based on the private key fragment and the secret value after successful verification, and constructs a public key based on the public parameters and the system public parameters.

3. The method according to claim 1, characterized in that, The data blocks are encoded, and a Merkle tree is constructed using the hash values ​​of the encoded data blocks. The processed set of data blocks and the root node of the Merkle tree are sent to any three cloud servers to complete the calculation and verification of block labels, including: After encoding each data block, calculate its hash value, construct a Merkle tree based on the block hash value, and obtain the root node; The encoded set of data blocks and the root node are sent to a first cloud server, a second cloud server, and a third cloud server randomly selected from a plurality of cloud servers; The first cloud server recalculates the hash value of each data block in the data block set, constructs a Merkle tree, and verifies the consistency of the root node. If the consistency verification is successful, it calculates the block label for each data block, aggregates all the block labels into an aggregate label, and sends it to the second cloud server. The second cloud server verifies the aggregated tag. If the verification fails, it coordinates with the third cloud server to recalculate the block tag. If the verification succeeds, it sends a response to the original data owner.

4. The method according to claim 2, characterized in that, The original data owner and the new data owner mutually verify each other based on the ownership conversion certificate and the ownership acceptance certificate, and update the conversion factor and ownership information upon successful verification, including: The new data owner calculates the public value based on a randomly selected number and sends the public value and the ownership acceptance certificate to the original data owner. The original data owner verifies the correctness of the ownership acceptance certificate. After successful verification, the original data owner calculates a first verification value based on the public value and the secret value corresponding to the original data owner, and sends the first verification value and the ownership conversion certificate to the new data owner. The new data owner verifies the correctness of the ownership transfer certificate. After the verification is successful, a second verification value is calculated based on the public parameters corresponding to the original data owner and the random selection number. The first verification value and the second verification value are mutually verified. After the verification is successful, the conversion factor is calculated based on the first verification value, the pseudonym of the original data owner, the pseudonym of the new data owner, and the file identifier. The new data owner calculates the file signature and sends a transfer request to all cloud servers; the transfer request includes the ownership transfer certificate, the ownership acceptance certificate, the transfer factor, the current system timestamp, and the file identifier; Each cloud server verifies the validity of the ownership conversion certificate, the ownership acceptance certificate, and the current system timestamp. After successful verification, the ownership information is updated according to the conversion factor.

5. The method according to claim 1, characterized in that, The cloud server performs integrity auditing based on the ownership information, the data block set, and the block tag set, including: Select two cloud servers from a number of cloud servers to serve as the auditor and the initial auditee, respectively. The auditor generates a set of challenges and sends them to the auditee. The auditee calculates data evidence and tag evidence based on the challenge set, the data block set, and the block tag set, and sends the data evidence and tag evidence to the auditor; The auditor determines whether ownership has changed based on the ownership information, and verifies the cases where ownership has changed and ownership has not changed. If verification fails, immediately notify the current data owner to reselect an auditee from several cloud servers for cross-verification to determine whether the initial auditee's data is corrupted.

6. The method according to claim 5, characterized in that, When the auditee determines that the data is corrupt, the method further includes: The auditor initiates integrity checks on all cloud servers except the auditor and the auditee, and selects several cloud servers as recovery sources from those that respond to the integrity checks and pass the verification, based on their response speed. Based on the set of data blocks stored in the recovery source, the auditor uses a voting mechanism to select the target set of data blocks to obtain the recovery file; The auditee generates new block labels based on the recovered files; The auditor verifies the correctness of the new block label. If the verification passes, the auditee is reintroduced into the audit poll.

7. A certificate-free auditing device for cross-server multi-copy systems supporting lightweight ownership transfer, comprising the original data owner, the new data owner, several cloud servers, and a key generation center, characterized in that: The key generation center is used to generate system public parameters and system master private key; and the original data owner, new data owner and each cloud server calculate the corresponding pseudonym according to their real identity and submit it to the key generation center. Combined with the system public parameters and the system master private key, the center obtains the corresponding private key fragment and generates the corresponding public key and private key according to the private key fragment and the selected secret value. The original data owner divides the file into several data blocks, encodes the data blocks, constructs a Merkle tree using the hash values ​​of the encoded data blocks, and sends the processed set of data blocks and the root node of the Merkle tree to any three cloud servers to complete the calculation and verification of block labels. If the verification is successful, a file signature is generated based on the private key, and the file signature, the set of data blocks, the file identifier, and the root node are uploaded to each cloud server. Each cloud server reconstructs the Merkle tree to verify the uploaded data set and the file signature. After successful verification, the uploaded data information is stored and the ownership information corresponding to the set of data blocks is recorded. The ownership information includes the current system timestamp, file identifier, original data owner pseudonym, file signature, and initial conversion factor. The original data owner generates an ownership transfer certificate based on the corresponding private key, and the new data owner generates an ownership acceptance certificate based on the corresponding private key. The original data owner and the new data owner verify each other based on the ownership transfer certificate and the ownership acceptance certificate, and update the transfer factor and the ownership information if the verification is successful. The cloud server is used to perform integrity auditing based on the ownership information, the data block set, and the block tag set.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

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

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

Images