Verifiable data sharing auditing method supporting ownership transfer

Abstract

The invention discloses a verifiable data sharing auditing method supporting ownership transfer. The method comprises the following steps: 1) a system initializes common parameters; 2) a data owner encrypts the data based on a block-level message locking encryption algorithm; 3) the data owner calculates a data related label and uploads the data related label to the cloud server; 4) the user side can interact with the cloud server to carry out ownership one-to-many transfer; 5) after the transfer is completed, the transfer party inherits data access and auditing authority; and 6) the new data owner entrusts a third party to verify the integrity of the encrypted data of the target cloud. And 7) the new owner can dynamically update the data. In order to solve the problem that user data in cloud storage is managed by a cloud server so as to lose ownership of the data, an improved encryption algorithm based on block-level message locking encryption is designed to provide block-level ciphertext auditing and realize one-to-many transfer of the ownership of the data at the same time; and the utilization rate of the cloud server and the security of cloud data storage and use are improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of cloud computing and data security, and particularly relates to a verifiable cloud storage auditing method that supports batch transfer of data ownership to multiple users, and is particularly applicable to the secure sharing and dynamic management of encrypted data in a multi-user environment. This method combines block-level message-locked encryption (BL-MLE), proxy re-encryption technology, and Merkle hash trees to achieve "one-to-many" transfer of data ownership, integrity auditing, and dynamic modification, significantly enhancing the security and efficiency of data circulation in the cloud. Background Art

[0002] With the popularization of cloud storage technology, outsourcing data storage has become an important means for enterprises to reduce operation and maintenance costs. However, the existing technologies have the following defects: traditional solutions only support "one-to-one" ownership transfer and cannot meet the batch transfer requirements in multi-user collaboration scenarios, resulting in low data sharing efficiency; existing encryption methods rely on centralized key management, and key leakage may lead to malicious tampering or unauthorized access to data; during the dynamic data auditing process, bilinear pairing calculations and frequent label update operations increase the load on the cloud server and are difficult to support large-scale data applications; after the ownership transfer in the existing solutions, the new owner cannot dynamically modify the encrypted data and cannot maintain the integrity auditing ability. Summary of the Invention

[0003] In view of this, the main object of the present invention is to provide a verifiable data sharing auditing method that supports ownership transfer, aiming to solve the problems of flexibility and efficiency of data ownership transfer, and security access control and key management risks of encrypted data.

[0004] To achieve the above object, the technical solution adopted by the present invention is: a verifiable data sharing auditing method that supports ownership transfer. The method includes the following steps:

[0005] S1. System parameter initialization, establishing a cryptographic basic environment to ensure the security and scalability of the solution; S2. Block-level message-locked encryption (BL-MLE), realizing block-level data encryption and decentralized key management to avoid the risk of centralized key storage; S3. Data generation and upload, ensuring data integrity and ownership identification, providing a credible basis for subsequent auditing and transfer; S4. Ownership batch transfer mechanism, supporting the transfer of ownership of multiple files to multiple users in one transaction to improve data circulation efficiency; S5. Data access, ensuring that the transferee decrypts and accesses the data securely while verifying data integrity; S6. Efficient integrity auditing, reducing the computational load on the cloud server and the auditor, supporting large-scale data auditing; S7. Support for dynamic data operations, allowing the new owner to modify the data after transfer and maintaining audit continuity.

[0006] Furthermore, in the above S1, by using bilinear pairing and collision-resistant hash function to provide a mathematical basis for subsequent encryption, tag generation and verification, the method for resisting key leakage and forgery attacks specifically includes the following 2 steps:

[0007] Step S1.1, generating public parameters: Select two multiplicative cyclic groups G and G of prime order p, T define the bilinear pairing mapping e: G×G→G T ;

[0008] Define a set of hash functions H0 to H4 for key derivation, encryption mask generation and tag binding;

[0009] Define the index function I for mapping an identifier to the corresponding storage location in the data set stored in the cloud server;

[0010] Introduce an identity-based signature scheme S = <Kgen, Sig, Vrf> to simplify certificate management.

[0011] Step S1.2, user key generation: The transferor generates a public-private key pair (SK A , PK A ), and the transferee generates (SK B , PK B ).

[0012] Furthermore, in the above S2, by binding the key of BL-MLE to the data content, the same ciphertext is generated after encrypting the same content, supporting deduplication and dynamic modification, and at the same time avoiding the risk of centralized key management. The specific implementation steps are as follows:

[0013] Step S2.1, block processing: used to divide the data file to be uploaded, divide the data file Fi to be stored into multiple data blocks {b i1 , b i2 ,... b in};

[0014] Step S2.2, key derivation: Generate a unique key k ij = H1(b ij );

[0015] Step S2.3, encryption operation: Use the block key k ij to generate the data block ciphertext c ij = H2(k ij )·b ij .

[0016] Furthermore, in the above S3, the Merkle tree root hash R iAs a global anchor for data integrity, any tampering will result in a change in the root value, ensuring that the data has not been tampered with before uploading. At the same time, the file tag is used to verify the identity of the data owner, and the data tag is used to define the ownership of the data. The specific implementation steps are as follows:

[0017] Step S3.1, constructing the Merkle hash tree root tag: Calculate the block ciphertext H0(c ij ), and recursively generate the root hash R i ; Bind the hash of the file identifier filename i and the root R i to obtain the tag of the root

[0018] Step S3.2, generating the file and data tags: In this case, the owner of the uploaded data uses the signature private key ssk generated by the signature scheme to sign the file parameter information (the number of data blocks, the file identifier, the audit auxiliary parameter) to generate the overall file tag

[0019] At the same time, the data owner calculates the homomorphic authentication tag of each data block, that is, the data tag where u is the generator of the multiplicative cyclic group;

[0020] Step S3.3, uploading to the cloud server: The data owner sends a data storage request to the cloud server. The data storage request includes the data, the Merkle hash tree root tag, the overall file tag, and the data block tag set composed of the block tags of each data block, so that the cloud server stores all the received data.

[0021] Furthermore, in S4, the file to be transferred is quickly located through the index function, and m files are batch transferred to multiple users, realizing one-to-many ownership transfer. The specific implementation steps are as follows:

[0022] Step S4.1, generating the transfer token: The transferor calculates the transfer token: where r i is the audit auxiliary parameter, where α is the transferor's private key, is the transferee's public key;

[0023] Step S4.2, generating the transfer-in token: The transferee recalculates the file parameter information, generates the overall file tag according to the same calculation, and calculates the transfer-in token through the file parameter information: where r' i is the audit auxiliary parameter, where β i is the transferor's private key, and pk A is the transferee's public key;

[0024] Step S4.3, Re-encryption: The cloud server receives the transfer tokens from the transferor and the transferee, and recalculates the data tag of each data block as

[0025] Step S4.4, Tag Update: Update the file tag in the stored data to the file tag of the transferee Meanwhile, update the data tag of each data block to the homomorphic authentication tag σ' after recalculation ij , ensuring that the new owner, i.e., the transferee, has the audit and access rights.

[0026] Furthermore, in the said S5, based on the decryption mechanism of BL-MLE, it is ensured that only the legitimate owner can recover the data through the private key, and the integrity is automatically verified during the decryption process. The specific implementation steps are 2 steps:

[0027] Step S5.1, Decrypt the block key: The new data owner, i.e., the transferee, uses the private key β i to calculate

[0028] Step S5.2, Recover the plaintext data: Decrypt through b ij =H2(k ij )·c ij , and verify k ij =H1(b ij ) to confirm that the data has not been tampered with.

[0029] Furthermore, in the said S6, the n - time bilinear pair verification is combined into a single operation through aggregation calculation, effectively improving the calculation efficiency. In this case, the data owner initiates an integrity audit entrustment of file F to the third - party auditor. The specific implementation steps are 3 steps: i Step S6.1, Challenge Generation: The third - party auditor randomly selects the data block index j and the coefficient a

[0030] ij , and sends the challenge set chal i ={j,a ij};

[0031] Step S6.2, Aggregate Proof Calculation: The server receives the challenge from the third - party auditor and generates the aggregate proof of the linear combination

[0032] Step S6.3, Verify the Equation: The third - party auditor verifies the bilinear pair equation: If it holds, it is determined that the data is complete and the ownership is legal. Where g is the generator of the multiplicative cyclic group, h ij is the audit auxiliary parameter in the document tag.

[0033] ​Further, in S7, dynamic modification does not require global re-encryption, only local update, taking into account both efficiency and security. The specific implementation steps are as follows:

[0034] Step S7.1, local modification: The new owner, i.e., the transferee, modifies the data block b ij →b' ij , regenerates the key k' ij =H1(b' ij ) and the ciphertext c' ij =H2(k' ij )·b' ij ;

[0035] Step S7.2, update the Merkle tree: Recalculate the leaf node hash H0(c' ij ), generate the new root hash R' i and the label of the tree root

[0036] Step S7.3, cloud server verification: After verifying the legality of the signature of the new label, update the storage to ensure that subsequent audits are based on the latest data version.

[0037] It can be seen from the above specific steps: By combining block-level message locking encryption (BL-MLE), proxy re-encryption technology and Merkle hash tree, the "one-to-many" batch transfer, dynamic modification and efficient integrity audit of data ownership are realized. These steps solve the problems of low "one-to-one" transfer efficiency, high risk of centralized key management and large computational load of dynamic data audit in traditional solutions: By binding the key with the data content through BL-MLE, the risk of key leakage is avoided; The proxy re-encryption and token mechanism are used to achieve batch transfer, significantly improving the data circulation efficiency; Through aggregation calculation, multiple bilinear pair verifications are combined into a single operation, reducing the computational pressure on the cloud server and the auditor; At the same time, dynamic modification only requires local update of the Merkle hash tree to ensure audit continuity. Finally, the solution takes into account flexibility and scalability while ensuring data security and integrity, and is applicable to large-scale encrypted data sharing and management in multi-user collaboration scenarios. Description of the Drawings

[0038] Figure 1 is the interaction flowchart of the system model in the method of the present invention

[0039] Figure 2 is the flowchart of the data management method in the method of the present invention

[0040] Figure 3 is the schematic diagram of the construction of the Merkle hash tree in the method of the present invention

[0041] Figure 4Flow chart of ownership transfer in the method of the present invention

[0042] Figure 5 Flow chart of data integrity audit in the method of the present invention Detailed implementation manners

[0043] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0044] It should be noted that the following detailed description is exemplary and is intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present application belongs.

[0045] As Figure 1 shown, in an embodiment of the present invention, a verifiable data sharing audit method supporting "one-to-many" transfer of ownership, the system model includes three types of participating entities, namely a cloud server, a third-party auditor, and a user (where the user can be divided into an ownership transferor and an ownership transferee). The included entities and their function descriptions are as follows.

[0046] (1) Cloud Server (CS): It is a server with a large amount of storage and computing resources, responsible for storing remotely outsourced file data and executing computing commissions from cloud clients and third-party auditors.

[0047] (2) Third-Party Auditor (TPA): It is an entity with professional knowledge of integrity verification. It can provide convincing results for the audit commissions of users.

[0048] (3) User: All users in the solution can store data in the cloud server, access and update the data as needed, and can entrust the regular integrity audit tasks of these data to any third-party auditor. According to the position of data ownership transfer, users can be divided into the following two categories:

[0049] ① Ownership Transferor (A): It is the transferor of ownership during the batch transfer of data ownership and the original owner of the data. It uploads file data to the cloud for remote storage. During the batch transfer of data ownership, the transferor needs to calculate the transfer token and send it to the CS for the next step of the transfer.

[0050] ② Ownership Transferee (B): It is the target of the batch transfer of data ownership, that is, the new owner of the data. During the transfer of data ownership, the transferee calculates the transfer token and sends it to the CS to complete the update of the data label. Once the ownership is transferred, B will inherit the access, modification, and audit permissions of these data from A.

[0051] As Figure 2As shown, the method includes the following steps: S1. Initialize system parameters, establish a cryptographic basic environment, and ensure the security and scalability of the solution; S2. Block-level message locking encryption (BL-MLE) to achieve block-level data encryption and decentralized key management, avoiding the risk of centralized key storage; S3. Data generation and upload to ensure data integrity and ownership identification, providing a trustworthy basis for subsequent auditing and transfer; S4. Ownership batch transfer mechanism to support transferring the ownership of multiple files to multiple users in one transaction, improving data circulation efficiency; S5. Data access to ensure that the transferee decrypts and accesses the data securely while verifying data integrity; S6. Efficient integrity auditing to reduce the computational load on the cloud server and the auditor, supporting large-scale data auditing; S7. Support for dynamic data operations to allow the new owner to modify the data after transfer and maintain audit continuity.

[0052] Existing ownership transfer solutions rely on the collaborative update of data tags by the transferor and the cloud server. However, these solutions cannot support the batch transfer of multiple data ownerships and cannot ensure that the transferee inherits data access and auditing permissions, thus affecting the flexibility and security of data circulation.

[0053] In view of this, the embodiments of the present application provide a verifiable data sharing and auditing method that supports one-to-many transfer of ownership. The data owner stores the data in chunks on the cloud server. After the data owner transfers the data ownership, the ownership transferee can also entrust a third-party auditor to perform integrity auditing on the stored data chunks and dynamically modify the stored data, ensuring that during the ownership transfer process, not only the access permission of the encrypted data is entrusted to the new owner, but also the integrity auditing function of the data tags can be transferred.

[0054] In S1, for system parameter initialization, system parameters required for the operations of each execution entity need to be generated. The specific steps for establishing a cryptographic basic environment and ensuring the security and scalability of the solution are as follows:

[0055] Step S1.1. Generate public parameters: Select two multiplicative cyclic groups G and G of prime order p, T and a bilinear map e: G×G→G T , select two independent generators u, g ∈ R G; Define 5 hash functions: Set an index function for mapping the identifier to the corresponding storage location in the data set stored on the cloud server. In this case, for m users, the identity identifier ID ∈ {ID1, ID2,..., ID m}, the function can evenly map the ID to {1, 2,..., m}. Introduce a signature scheme S = <Kgen, Sig, Vrf>, where S.Sig is a signature algorithm using the signature key ssk, (ssk, spk) ← S.Kgen(1 λ ), return and publicly disclose the system parameters: param = (e, p, G, G T , g, u, H, H1, H2, H3, H4, S, I).

[0056] Step S1.2, User Key Generation: The cloud user inputs the system parameters param, then the transferor A and the transferee B i generate their respective key pairs according to the following algorithm. The transferor A selects calculate pk A = g α , run the signature key pair (ssk A , spk A ) generated by S.Kgen; The transferee B i selects calculate run S.Kgen to generate the signature key pair of B i The transferor A obtains the public key PK = {pk A , spk A}, the private key SK A = {sk A , ssk A , ssk A}; The transferee Bi obtains the public key private key

[0057] In the above S2, for block - level message - locked encryption (BL - MLE), the specific steps to achieve data block - level encryption and decentralized key management to avoid the risk of centralized key storage are as follows:

[0058] Step S2.1, Block Processing: The transferor A encodes the data file F to be stored i through erasure coding to form n data blocks, denoted as F i = {b i1 , b i2 ,...b in}, where i ∈ [1, m], that is, F = {F i}= {(b ij )} j∈[1,n] . Randomly select a file identifier for the file F i

[0059] ​Step S2.2, Key Derivation: The transferor A uses the system parameter param and the file F i as inputs to generate a unique key k ij = H1(b ij );

[0060] Step S2.3, Encryption Operation: The transferor A encrypts the block data of the file using an algorithm to obtain block ciphertext

[0061] In S3, the specific steps for data generation and upload to achieve data integrity and ownership identification, providing a trusted basis for subsequent auditing and transfer are as follows:

[0062] Step S3.1, Constructing the Merkle Hash Tree Root Label: The transferor A constructs a Merkle hash tree based on the block ciphertext c i = {c i1 , c i2 ,..., c in}, as Figure 2 shown. When n = 8, the construction method is: Calculate the hash value H0(c ij ), and then store it in the leaf node. The non-leaf node stores the hash value of the connection of its child nodes. Recursively construct layer by layer in this way, and finally obtain the root node R i of the Merkle hash tree. Through the root node R i of the Merkle hash tree, calculate the label i of the root R i.e.,

[0063] Step S3.2, Generating File and Data Labels: The transferor A calculates h ij = e(k ij , g), r i = H3(α||filename i ), let FID i = filename i ||n||r i ||h i , where h i = {h i1 ||h i2 ||...||h in}, to generate the file label Then At the same time, calculate the homomorphic authentication label of the block ciphertext c ij , that is, the data label: The homomorphic authentication label set is σ i = {σ i1 , σ i2,...σ in}.

[0064] Step S3.3, Upload to the cloud server: The data owner, i.e., the transferor A, sends a data storage request to the cloud server, and sends the storage request to CS. After receiving A's storage request, CS first uses the signature public key spk A to verify each file signature If it means the verification passes, and then recover filename i , n, h i , r i , and according to c i reconstruct the Merkle hash tree to get R' i and calculate If the verification passes, indicating that CS can store the data Return the storage success result "1", and the data owner deletes the local copy. Otherwise, it cannot be stored, and the cloud server returns the storage failure result "0".

[0065] In S4, for the one-to-many ownership transfer mechanism, in this case, the transferor A hopes to batch-transfer the ownership of the outsourced data. In this solution, it means allowing the transferees B = {B1, B2,..., B m} to inherit the ownership permissions of these m data files from the transferor A respectively and access them. As Figure 3 shown, the specific steps to support transferring the ownership of multiple files to multiple users in one transaction and improve the data circulation efficiency are as follows:

[0066] Step S4.1, Transfer token generation: The transferor A needs to upload a transfer calculation request for the transferee B i to CS, that is, note the transfer user identity identifier the transferee B i sends a transfer request to the transferor A. A sets an index according to B i 's identity identifier and sends it to CS. The transferor A calculates the transfer token for F through the public key i of the transferee B : i and encrypts the transfer token with CS's public key pk and sends it to CS after encryption. CS

[0067] Step S4.2, Receiving token generation: CS calculates the index pointing to σ i , and sends it to B​i , B i After the verification file label passes, calculate: r' i =H3(β i ||filename i ), FID' i =filename i ||n||r' i ||h i , and will With the encrypted transfer token' i Send to CS;

[0068] Step S4.3, re-encryption: CS verification content, and use sk CS Decrypt the encrypted token and get the token i 、token' i If CS accepts the ownership transfer request, it shall meet the following conditions:

[0069] Step S4.4, label update: CS updates the file label in the stored data to transferee B i File Tags At the same time, the data label of each data block is updated to the recalculated homomorphic authentication label σ′ ij , ensuring that the new owner, i.e. the transferee, has audit and access rights.

[0070] In S5, the specific implementation steps of ensuring that the transferee can securely decrypt and access data based on the BL-MLE decryption mechanism and verifying the data integrity are as follows:

[0071] Step S5.1, decryption block key: After the transfer is successful, CS will allow the new owner of the data, the transferee B, to i Using Private Key β i calculate:

[0072] Step S5.2: Restore plaintext data: Decrypt the block ciphertext using the block key to obtain the original data block And verify k' ij = = H1(b' ij ) to confirm that the data has not been tampered with.

[0073] In S6, efficient integrity audit, in this case, the transferee B i Select the appropriate TPA and send the audit documents to it i The entrustment request is sent by TPA to the file F stored by CS. iInitiate an audit challenge. As Figure 4 shown, the specific steps to achieve reducing the computational loads of the cloud server and the auditor and supporting large-scale data auditing are as follows:

[0074] Step S6.1, Challenge generation: The TPA first uses the signature public key to verify the file tag If then the TPA sends a challenge set of size c to the CS where j specifies the position of the block of the file F i to be checked.

[0075] Step S6.2, Aggregate proof calculation: When the CS receives the challenge set chal i , it calculates and sends an integrity proof P i for the file F i = {μ i , v i} to the TPA, where

[0076] Step S6.3, Verify the equation: The TPA receives the proof P i , and checks the validity of the proof by verifying the following equation: If it holds, it means that the user accessing the data is authorized and the data is valid, and "1" is returned; otherwise, "0" is returned indicating that the data is invalid.

[0077] This completes the description of the ownership transfer. Obviously, after the transfer, the homomorphic authentication tag of B i has the same structure as the homomorphic authentication tag of A before the transfer, that is, the ownership is transmitted along the tag used for integrity verification and ownership identification. Such a fact indicates that the integrity of the file F with the ownership transfer property can be checked by the authorized TPA in the same way as described in the audit, and the file ownership can be transferred to another cloud client through the same operation.

[0078] In S7, for the support of dynamic data operations, the specific steps to achieve allowing the new owner to modify the data after the transfer and maintaining the audit continuity are as follows:

[0079] Step S7.1, Local modification: The new owner, i.e., the transferee B i modifies the data block b ij → b' ij , regenerates the key k' ij = H1(b' ij ) and the ciphertext c' ij = H2(k' ij )·b' ij ;

[0080] Step S7.2, Update the Merkle tree: Recalculate the leaf node hash H0(c' ij ), and when necessary, reselect the file identifier for the file Generate a new root hash R' i and the label of the root node At the same time, re-sign and update the file label into the file label.

[0081] Step S7.3, Cloud server verification: After verifying the legality of the signature of the new label, update the storage to ensure that subsequent audits are based on the latest data version.

[0082] The above is an exemplary description of the present invention. It should be noted that any simple deformation, modification or equivalent substitution that can be made by those skilled in the art without creative labor falls within the protection scope of the present invention without departing from the core of the present invention.

Claims

1. A verifiable data sharing audit method supporting ownership transfer, characterized in that It includes the following steps: (1) System initialization: Generate and publicly disclose system public parameters, which include bilinear pair mapping, a set of hash functions, a secure prime number group, and a signature scheme; users generate public-private key pairs according to the public parameters, where the private key is used for data signature and decryption, and the public key is used for verification and encryption; (2) Data processing: The user performs block processing on the file data to be uploaded, generates multiple data blocks through erasure coding, and randomly selects a file identifier for the file; based on the block-level message-locked encryption (BL-MLE) algorithm, the content hash of each data block is mapped to a unique block key, and the data block is encrypted using the block key to generate a block ciphertext; (3) Data upload and storage: Construct a Merkle hash tree according to the block ciphertext to generate a file root hash value; use the user's private key to generate a file tag and data block tags, where the file tag includes a file identifier, the number of data blocks, and audit auxiliary parameters, and the homomorphic authentication tag is used for data integrity and ownership verification; upload the encrypted block ciphertext, file tag, and data tags to the cloud server for storage, and the cloud server confirms storage after verifying the legality of the tags; (4) Ownership transfer: The transferor generates a transfer token and interacts with the cloud server to batch transfer the ownership of multiple files to one or more transferees through proxy re-encryption technology; Update the file tag and homomorphic authentication tag during the transfer process to ensure that the transferee inherits the data access and audit rights. Among them, the block key used for accessing data is obtained by decrypting the homomorphic authentication tag. (5) Data access: Update the file tag and homomorphic authentication tag during the transfer process, and ensure that the transferee inherits the data access and audit rights after the transfer is completed, ensure that the transferee decrypts and accesses the data securely, and at the same time verify the data integrity; (6) Data integrity audit: The user can entrust a third-party auditor to initiate a challenge request to the cloud server. The cloud server generates an integrity proof according to the challenge, and the third-party auditor uses the audit auxiliary parameters in the file tag to verify the data integrity and ownership legality. (7) Dynamic data update: Based on the ownership transfer, the new owner can obtain operation permissions such as data modification, append, and deletion, and maintain the continuity of data integrity audit.

2. The method according to claim 1, wherein The specific implementation of the block-level message-locked encryption (BL-MLE) algorithm described in step (2) is: Generate the block key k according to the content of the data block ij = H1(b ij ), where H1 is a hash function, and b ij is the j-th data block of the i-th file; XOR encrypt the data block using the block key to generate the block ciphertext c ij = H2(k ij ), where H2 is a hash function.

3. The method according to claim 1, characterized in that The construction method of the Merkle hash tree described in step (3) is: Calculate the hash value of each block ciphertext as a leaf node; Recursively calculate the hash values of non-leaf nodes until the root hash value R is generated i ; Generate root R according to the root hash value i label t of Ri = H0(R i ) filenamei , where H0 is a hash function and filename i is the unique identifier of the file.

4. The method according to claim 1, characterized in that The construction method of the file tag and data block tags described in step (3) is: Signature file label Among them, FID i contains the file identifier filename i , the number of data blocks n and the audit auxiliary parameter r i and h i , ssk is the signature private key; Data label Where u is the generator of the safe prime group and α is the user's private key.

5. The method according to claim 4, wherein The signature key is from the signature scheme S=(Kgen, Sig, Vrf) in step (1) of claim 1. The scheme generation adopts identity-based cryptography to simplify certificate management, and through the certificateless signature compatible authenticator transformation method, the security of the ownership transfer process is enhanced.

6. The method according to claim 1, wherein The specific process of the ownership transfer described in step (4) includes: The transferor generates a transfer token where α is the transferor's private key and H4 is a hash function, and is the transferee's public key; The transferor maps the transferee identity identifier to a storage location based on an index function to generate a transfer index To achieve efficient data location and label update during batch ownership transfer, where f(·) is the index function and ID Bi is the identity identifier of the transferee; The transferee generates a transfer token where β i is the transferee's private key, pk A is the transferor's public key, r' i is the transferee's audit auxiliary parameter; After the server verifies the legality of the transfer token, it uses proxy re-encryption to update the homomorphic authentication tag And change the audit auxiliary parameter in the file tag to the transferee information; Support the simultaneous transfer of the ownership of multiple files to multiple transferees respectively to achieve "one-to-many" batch transfer, and the transfer process retains the data integrity verification ability.

7. The method according to claim 1, characterized in that, The specific process of the transferee accessing data in step (5) includes: The transferee uses the private key β according to the data tag i to calculate the data block encryption key: The transferee decrypts the block key to obtain the data content b ij = H2(k ij )·c ij , and verifies that k ij = H1(b ij ) to confirm that the data has not been tampered with.

8. The requirement according to claim 6, wherein the transfer process retains the data integrity verification ability, characterized in that, The verification process of the data integrity audit described in step (6) is as follows: The third-party auditor verifies the legality of the transferee file tag t' through the transferee's signed public key spk Bi ; Fi ​ A third-party auditor generates a random challenge set chal i ={j,a j}, where j is the data block index and a j is a random coefficient; The cloud server calculates the aggregate proof based on the challenge set v i = ∑c ij ·a j , and returns it to the auditor; The auditor verifies the equation to determine whether it holds, where g is the generator of a secure prime group and h ij is the audit auxiliary parameter in the file tag. If it holds, the data is determined to be complete and the ownership is legal.

9. The method according to claim 4, wherein The generation formula of the data tag introduces an audit parameter r i =(α||filename i ), ensuring dynamic binding of the tag with the file identifier and the user's private key, and preventing replay attacks and tag forgery.

10. The method according to claim 1, wherein The method described in step (7) supports the new owner to dynamically modify the encrypted data after the transfer of ownership.

Images