Cloud server data storage method and system

Abstract

The application provides a cloud server data storage method and system, comprising the following steps: S1, when a user requests to upload non-repeated data, a cloud storage server checks whether the data has been stored and performs data blocking and data encryption; S2, when the user requests to upload repeated data, the cloud storage server performs data duplication checking and data deletion; S3, a user ownership proof protocol is realized based on a Bloom filter; S4, a re-encryption center manages a re-encryption B+ tree to realize user update; S5, when the user requests to download data, the cloud storage server searches a database, and if the data label and the user label both exist reasonably, the re-encryption ciphertext is returned to the user; the user first decrypts the re-encryption ciphertext to obtain convergent encryption ciphertext, and then decrypts the convergent encryption ciphertext to obtain data blocks. The application can realize the efficiency and real-time performance of dynamic user ownership update, and ensure the system security and data integrity.

Description

Technical Field

[0001] This invention relates to the field of data security technology in cloud storage systems, specifically to a cloud server data storage method and system for secure deduplication of duplicate data across users, and more particularly to a cloud server data storage method and system. Background Technology

[0002] In the modern era of cloud computing, the rapid development of cloud storage and big data technologies has significantly impacted how people process information and improved the efficiency of information storage. Through cloud servers, people can perform scalable computing anytime, anywhere, and store the data effectively. Therefore, outsourcing the storage of sensitive data to remote cloud servers is gradually becoming a trend for businesses and individuals.

[0003] However, while enjoying the convenience brought by cloud servers, people have also encountered many problems. In cloud storage spaces, duplicate data accounts for more than half, significantly consuming storage space and bandwidth resources. Faced with exponentially increasing data volumes and communication traffic, a large amount of redundant data is stored on cloud storage servers, placing a huge storage and communication burden on them. Furthermore, maintaining data security is also a problem faced by cloud storage servers; due to data breaches, the world faces economic losses of up to 3.8 million yuan.

[0004] However, research on the security and storage efficiency of cloud storage systems is still in its early stages. Based on current trends, future research on storage security and efficiency in cloud storage systems will primarily focus on the following aspects:

[0005] 1. Effectively promote data deduplication and reduce storage space. Apply technologies such as data segmentation and encryption algorithms to securely deduplicate data, reducing bandwidth consumption during transmission.

[0006] 2. Further expand the existing user ownership proof mechanism. Use multiple copies for verification and improve and extend the user ownership proof mechanism. Further protect and maintain the privacy of data owners, ensuring that their privacy information is not easily leaked.

[0007] 3. Achieve a reasonable balance between securely deduplicating data, protecting personal privacy, and improving efficiency. Employ security-matching methods such as deduplication checks to ensure the security of encrypted data and effectively protect users' private information. Achieve deduplication and efficiency optimization while reasonably protecting users' private information.

[0008] 4. Improve the security and robustness of cloud storage systems to resist both internal and external attacks to a certain extent. Cloud storage systems may be vulnerable to external attacks, such as side-channel attacks. Furthermore, they may also be susceptible to internal attacks, such as "honest and curious" cloud storage servers. This means that while cloud servers strictly fulfill their responsibilities of data retrieval, deduplication, and storage, they may also try to obtain user information as much as possible. Therefore, a crucial research direction for future cloud storage systems is to focus on improving their ability to withstand malicious attacks.

[0009] In conclusion, protecting data security while efficiently reducing data redundancy is of great practical significance for improving storage security and efficiency in cloud storage systems.

[0010] A Chinese patent with publication number CN105487818B discloses a system and method for deduplicating redundant data in a cloud storage system. Users obtain data to be uploaded from multiple clients. The data routing unit is a data superblock. Data feature fingerprints are used by a server cluster to match similar routing nodes, and a load-balancing routing protocol is used to determine the routing address. Through communication between the server and clients, the server can identify and delete duplicate data. Summary of the Invention

[0011] To address the shortcomings of existing technologies, this invention provides a cloud server data storage method and system.

[0012] According to the present invention, a cloud server data storage method and system are provided, the solution of which is as follows:

[0013] Firstly, a cloud server data storage method is provided, the method comprising:

[0014] Step S1: When a user requests to upload non-duplicate data, the cloud storage server checks whether the data has already been stored and performs data segmentation and encryption; the data owner requests re-encryption from the re-encryption center, and the user creates a Bloom filter, which will be used for the user ownership proof protocol; finally, the user sends the re-encrypted ciphertext, data tag, user tag, and Bloom filter to the cloud storage server.

[0015] Step S2: When a user requests to upload duplicate data, the cloud storage server performs data deduplication and data deletion; if the database on the server side has already saved the data, but the user tag has not yet been saved, the user ownership proof mechanism will be invoked and executed.

[0016] Step S3: Implement the user ownership proof protocol based on Bloom filters; when a user uploads data, if the file tag has been stored but the user tag has not been stored, the cloud storage server will perform ownership proof.

[0017] Step S4: The re-encryption center manages the re-encryption B+ tree to enable user updates; by performing deletion and update operations on the user's re-encrypted ciphertext, the system achieves dynamic updates of the user's file ownership;

[0018] Step S5: When a user requests to download data, the cloud storage server will search the database. If both the data tag and the user tag exist reasonably, it will return the re-encrypted ciphertext to the user. The user first decrypts the re-encrypted ciphertext to obtain the converged encrypted ciphertext, and then decrypts the converged encrypted ciphertext to obtain the data block.

[0019] Preferably, step S1 includes:

[0020] Step S1.1: The user generates a file tag and sends a request to the cloud storage server to upload the data, including the file tag and user tag {tag, id}. u The data is sent to a cloud storage server to check for duplicates.

[0021] Step S1.2: Once the request to upload data is sent to the server, the cloud storage server will use the file tag and user tag {tag, id}. u The server checks whether the file tag already exists in the database. If the database does not contain the file tag, the server requests the user to send the relevant file information.

[0022] Step S1.3: After receiving the relevant instructions to send the file, the user executes a file chunking algorithm on the file:

[0023] {b i} i∈[1，n] =Divide(F, n)

[0024] Among them, {b i} i∈[1，n] This represents the set of n data blocks into which the original file is divided; b i Let i represent the i-th data block, i∈[1,n]; F represents the original file; n represents the number of data blocks;

[0025] Then, the user uses a strong hash function to generate a convergent cryptographic key K. i The Encrypt algorithm is called to generate a converged encrypted ciphertext C. i The convergence encryption key for the data block {k i} i∈[1,n] Produced by a strong hash function:

[0026] K i =H(b) i ), i∈[1,n]

[0027] Where H(.) represents a strong hash function;

[0028] Converging encrypted ciphertext C i From the convergent encryption key {k i} i∈[1,n] The data blocks are generated using an encryption algorithm:

[0029] C i =Encrypt(b i K i )

[0030] Finally, in order to obtain the re-encryption key and perform the re-encryption operation, the user sends the file tag, the number of data blocks n, and the user tag ID to the re-encryption center. u ;

[0031] Step S1.4: After receiving the user's request to obtain the re-encryption key, the re-encryption center determines the key based on the user's tag ID. u Find the tuple of the user's group by searching the re-encryption tree:

[0032] R[u]=<userrekey,filelist>

[0033] Obtain the user's re-encryption key using the binary tuple:

[0034] userrekey u =R[u].userrekey

[0035] The re-encryption center calls the Derekey algorithm to obtain a set of re-encryption keys {userrekey}. i} i∈[1,n] And return it to the user:

[0036] {userrekey i} i∈[1,n] =Derekey(userrekey) u (n)

[0037] Step S1.5: After receiving a set of re-encryption keys, the user re-encrypts the converged encrypted ciphertext to obtain a set of re-encrypted ciphertext {C′}. i} i∈[1,n] ;

[0038] Step S1.6: The user creates a Bloom filter for the cloud storage server to perform ownership verification, and re-encrypts the ciphertext {C′ i} i∈[1,n] File tag, user tag ID u And the Bloom filter is sent to the cloud storage server;

[0039] Step S1.7: The relevant information of the file is stored in the database on the server side.

[0040] Preferably, step S2 includes:

[0041] Step S2.1: The user generates a file tag and sends a request to the cloud storage server to upload the data, including the file tag and user tag {tag, id}. u The data is sent to a cloud storage server to check for duplicates.

[0042] Step S2.2: The cloud storage server receives the user's request to upload data, searches the database and finds that the file tag has been stored, indicating that the data has already been stored;

[0043] The cloud storage server checks whether the user has already been stored; if the user has already been stored, proceed to step S2.3; if the user has not been stored, proceed to step S2.4.

[0044] Step S2.3: The file tags and users have been stored. The cloud storage server sends the data redundancy results to the user. The user does not need to upload any data, and the process ends.

[0045] Step S2.4: If the file tag has been stored but the user has not been stored, the cloud storage server performs ownership verification to confirm that the user actually owns the data; if the user fails the ownership verification, proceed to step S2.5; if the user succeeds in the ownership verification, proceed to step S2.6.

[0046] Step S2.5: If the file tag has been stored, but the user has not been stored and the user has not passed ownership verification, the cloud storage server will not perform any operation, and the process ends.

[0047] Step S2.6: The file tag has been stored, but the user has not. The user proves ownership, and then the cloud storage server stores the ID. u The process is now complete.

[0048] Preferably, step S3 includes:

[0049] Step S3.1: t data blocks of the file are randomly selected by the cloud storage server and sent to the user:

[0050] B = {b1, b2, ..., b} t}, 1≤t≤n

[0051] Where B is the set of data blocks; b t Let t represent the t-th data block, 1≤t≤n; n represents the number of data blocks.

[0052] Step S3.2: The user calculates the label for each data block:

[0053]

[0054] Among them, b q H represents the q-th data block; H(.) represents a strong hash function. Represents data block b q The label; t represents the number of data blocks.

[0055] Step S3.3: The user labels the data blocks. Send to cloud storage server;

[0056] Step S3.4: For each data block, if all hash functions in the Bloom filter produce a value of 1, the cloud storage server determines that the data block has passed the ownership proof mechanism; when all t data blocks have passed the ownership proof mechanism, the user tag ID... u It is then stored on the server side;

[0057] If the hash function of a data block produces a value of 0 in the Bloom filter, the user cannot pass the proof of ownership, the cloud storage server will not store any data, and will return a result indicating that the user's verification has failed.

[0058] Preferably, step S4 includes:

[0059] Step S4.1: The re-encryption center searches for the specified user in the re-encryption tree and performs the corresponding deletion, modification, or insertion operation; it obtains the new user re-encryption key userrekey′ through the reKeyUpdate algorithm;

[0060] userrekey′ i =reKeyUpdate(userrekey) i )

[0061] Step S4.2: The re-encryption center sends the file tag to the cloud storage server based on the user group's tuple R[u] = <userrekey,filelist>, in preparation for updating the re-encrypted ciphertext;

[0062] Step S4.3: After receiving the file tag, the cloud storage server sends the old re-encrypted ciphertext {C′ i} i∈[1,n] Supreme Encryption Center;

[0063] Step S4.4: The re-encryption center receives the old re-encrypted ciphertext {C′ i} i∈[1,n] Then, the ReDecrypt algorithm is executed to decrypt and obtain the converged encrypted ciphertext {C}. i} i∈[1,n] ;

[0064] {C i} i∈[1,n] ={C′ i} i∈[1, n ] -userrekey

[0065] Step S4.5: The re-encryption center executes the ReEncrypt algorithm, using the new re-encryption key userrekey′ to encrypt the converged ciphertext {C}. i} i∈[1,n] Re-encryption yields a new re-encrypted ciphertext {C″ i} i∈[1,n] ;

[0066] {C″ i} i∈[1,n] ={C i} i∈[1,n] +userrekey′

[0067] Step S4.6: The re-encryption center will update the re-encrypted ciphertext {C″ i} i∈[1，n] The message is sent to a cloud storage server, which then saves the newly re-encrypted ciphertext.

[0068] Preferably, step S5 includes:

[0069] Step S5.1: The user requests to download data and sends the file tag and user tag {tag, id}. u Send to the cloud storage server;

[0070] Step S5.2: The cloud storage server determines the file tag and user tag {tag, id} based on the file tag and user tag. u} Retrieve the database; if the search is successful, send the corresponding re-encrypted ciphertext {C′}. i} i∈[1,n] If the data is not found, return a request failure to the user.

[0071] Step S5.3: The user sends a request to the re-encryption center to obtain the re-encryption key userrekey;

[0072] Step S5.4: The re-encryption center uses the user tag ID. u Find the re-encryption tree and return the re-encryption key userrekey to the user;

[0073] Step S5.5: The user executes the ReDecrypt algorithm to decrypt the re-encrypted ciphertext, obtaining the converged encrypted ciphertext {C}. i} i∈[1,n] ;

[0074] {C i} i∈[1,n] ={C′ i} i∈[1,n] -userrekey

[0075] Step S5.6: The user executes the Decrypt algorithm to obtain data blocks, and integrates the data blocks to obtain the original file.

[0076] b i =Decrypt(C i K i )

[0077] F = {b i} i∈[1，n] .

[0078] Secondly, a cloud server data storage system is provided, the system comprising:

[0079] Module M1: When a user requests to upload non-duplicate data, the cloud storage server checks whether the data has already been stored and performs data segmentation and encryption; the data owner requests re-encryption from the re-encryption center, and the user creates a Bloom filter, which will be used for the user ownership proof protocol; finally, the user sends the re-encrypted ciphertext, data tag, user tag, and Bloom filter to the cloud storage server.

[0080] Module M2: When a user requests to upload duplicate data, the cloud storage server performs data deduplication and data deletion; if the database on the server side has already saved the data, but the user tag has not yet been saved, the user ownership proof mechanism will be invoked and executed.

[0081] Module M3: Implements a user ownership proof protocol based on a Bloom filter; when a user uploads data, if the file tag has already been stored but the user tag has not been stored, the cloud storage server will perform ownership proof.

[0082] Module M4: The re-encryption center manages the re-encryption B+ tree to enable user updates; by performing deletion and update operations on user re-encrypted ciphertexts, the system achieves dynamic updates of user file ownership;

[0083] Module M5: When a user requests to download data, the cloud storage server will search the database. If both the data tag and the user tag exist reasonably, it will return the re-encrypted ciphertext to the user. The user first decrypts the re-encrypted ciphertext to obtain the converged encrypted ciphertext, and then decrypts the converged encrypted ciphertext to obtain the data block.

[0084] Preferably, the module M1 includes:

[0085] Module M1.1: The user generates a file tag and sends a request to the cloud storage server to upload the data, including the file tag and user tag {tag, id}. u The data is sent to a cloud storage server to check for duplicates.

[0086] Module M1.2: Once the request to upload data arrives at the server, the cloud storage server uses file tags and user tags {tag, id}. u The server checks whether the file tag already exists in the database. If the database does not contain the file tag, the server requests the user to send the relevant file information.

[0087] Module M1.3: After receiving the user's instructions regarding sending a file, the module executes a file chunking algorithm on the file.

[0088] {b i} i∈[1，n = Divide(F, n)

[0089] Among them, {b i} i∈[1，n] This represents the set of n data blocks into which the original file is divided; b i Let i represent a data block, i∈[1,n]; F represents the original file; n represents the number of data blocks;

[0090] Then, the user uses a strong hash function to generate a convergent cryptographic key K. i The Encrypt algorithm is called to generate a converged encrypted ciphertext C. i The convergence encryption key for the data block {k i} i∈[1，n] Produced by a strong hash function:

[0091] K i =H(b) i ), i∈[1,n]

[0092] Where H(.) represents a strong hash function;

[0093] Converging encrypted ciphertext C i From the convergent encryption key {k i} i∈[1，n] The data blocks are generated using an encryption algorithm:

[0094] C i =Encrypt(b i K i )

[0095] Finally, in order to obtain the re-encryption key and perform the re-encryption operation, the user sends the file tag, the number of data blocks n, and the user tag ID to the re-encryption center.u ;

[0096] Module M1.4: After receiving a request from a user to obtain a re-encryption key, the re-encryption center uses the user's tag ID to... u Find the tuple of the user's group by searching the re-encryption tree:

[0097] R[u]=<userrekey,filelist>

[0098] Obtain the user's re-encryption key using the binary tuple:

[0099] userrekey u =R[u].userrekey

[0100] The re-encryption center calls the Derekey algorithm to obtain a set of re-encryption keys {userrekey}. i} i∈[1，n] And return it to the user:

[0101] {userrekeyi} i∈[1，n] =Derekey(userrekey) u (n)

[0102] Module M1.5: After receiving a set of re-encryption keys, the user re-encrypts the converged encrypted ciphertext to obtain a set of re-encrypted ciphertext {C′}. i} i∈[1，n] ;

[0103] Module M1.6: User-created Bloom filters are used for ownership verification on cloud storage servers, re-encrypting the ciphertext {C′ i} i∈[1，n] File tag, user tag ID u And the Bloom filter is sent to the cloud storage server;

[0104] Module M1.7: File-related information is stored in a database on the server side.

[0105] Preferably, the module M2 includes:

[0106] Module M2.1: The user generates a file tag and sends a request to the cloud storage server to upload the data, including the file tag and user tag {tag, id}. u The data is sent to a cloud storage server to check for duplicates.

[0107] Module M2.2: When the cloud storage server receives a request from the user to upload data, it searches the database and finds that the file tag has already been stored, indicating that the data has already been stored.

[0108] The cloud storage server checks whether the user has already been stored; if the user has already been stored, it redirects to module M2.3; if the user has not been stored, it redirects to module M2.4.

[0109] Module M2.3: The file tags and users have been stored. The cloud storage server sends the data redundancy results to the user. The user does not need to upload any data, and the process ends.

[0110] Module M2.4: If the file tag has been stored but the user has not, the cloud storage server performs ownership verification to confirm that the user actually owns the data; if the user fails the ownership verification, proceed to module M2.5; if the user succeeds in the ownership verification, proceed to module M2.6.

[0111] Module M2.5: If the file tag has been stored, the user has not been stored, and the user has not passed ownership verification, the cloud storage server will not perform any operation, and the process ends.

[0112] Module M2.6: File tags have been stored, but user information has not. The cloud storage server stores the user's ID after the user proves ownership. u The process is now complete.

[0113] Preferably, the module M3 includes:

[0114] Module M3.1: t data blocks of the file are randomly selected by the cloud storage server and sent to the user.

[0115] B = {b1, b2, ..., b} t}, 1≤t≤n

[0116] Where B is the set of data blocks; b t Let t represent the t-th data block, 1≤t≤n; n represents the number of data blocks.

[0117] Module M3.2: User calculates the label for each data block:

[0118]

[0119] Among them, b q H represents the q-th data block; H(.) represents a strong hash function. Represents data block b q The label; t represents the number of data blocks.

[0120] Module M3.3: Users label data blocks Send to cloud storage server;

[0121] Module M3.4: For each data block, if all hash functions in the Bloom filter return a value of 1, the cloud storage server determines that the data block has passed the ownership proof mechanism; when all t data blocks have passed the ownership proof mechanism, the user tag ID... u It is then stored on the server side;

[0122] If the hash function of a data block produces a value of 0 in the Bloom filter, the user cannot pass the proof of ownership, the cloud storage server will not store any data, and will return a result indicating that the user's verification has failed.

[0123] The module M4 includes:

[0124] Module M4.1: The re-encryption center searches for a specified user in the re-encryption tree and performs the corresponding deletion, modification, or insertion operation; it obtains the new user re-encryption key userrekey′ through the reKeyUpdate algorithm;

[0125] userrekey′ i =reKeyUpdate(userrekey) i )

[0126] Module M4.2: The re-encryption center sends the file tag to the cloud storage server based on the user group's tuple R[u] = <userrekey,filelist>, in preparation for updating the re-encrypted ciphertext;

[0127] Module M4.3: After receiving the file tag, the cloud storage server sends the old, re-encrypted ciphertext {C′ i} i∈[1，n] Supreme Encryption Center;

[0128] Module M4.4: The re-encryption center receives the old re-encrypted ciphertext {C″ i} i∈[1，n] Then, the ReDecrypt algorithm is executed to decrypt and obtain the converged encrypted ciphertext {C}. i} i∈[1，n] ;

[0129] {C i} i∈[1，n] ={C′ i} i∈[1，n] -userrekey

[0130] Module M4.5: The re-encryption center executes the ReEncrypt algorithm, using the new re-encryption key userrekey′ to encrypt the converged ciphertext {C i} i∈[1，n] Re-encryption yields a new re-encrypted ciphertext {C″ i} i∈[1，n] ;

[0131] {C″ i} i∈[1，n] ={C i} i∈[1，n] +userrekey′

[0132] Module M4.6: The re-encryption center will update the re-encrypted ciphertext {C″ i} i∈[1，n] The message is sent to a cloud storage server, which then saves the newly re-encrypted ciphertext.

[0133] The module M5 includes:

[0134] Module M5.1: User requests to download data and includes file tags and user tags {tag, id} u Send to the cloud storage server;

[0135] Module M5.2: The cloud storage server uses file tags and user tags {tag, id} u} Retrieve the database; if the search is successful, send the corresponding re-encrypted ciphertext {C′}. i} i∈[1,n] If the data is not found, return a request failure to the user.

[0136] Module M5.3: The user sends a request to the re-encryption center to obtain the re-encryption key userrekey;

[0137] Module M5.4: Re-encryption center based on user tag ID u Find the re-encryption tree and return the re-encryption key userrekey to the user;

[0138] Module M5.5: The user executes the ReDecrypt algorithm to decrypt the re-encrypted ciphertext, obtaining the converged encrypted ciphertext {C}. i} i∈[1,n] ;

[0139] {C i} i∈[1,n] ={C′ i} i∈[1,n] -userrekey

[0140] Module M5.6: Users execute the Decrypt algorithm to obtain data blocks, and integrate the data blocks to obtain the original file.

[0141] b i =Decrypt(C i K i )

[0142] F = {b i}i∈[1,n] .

[0143] Compared with the prior art, the present invention has the following beneficial effects:

[0144] 1. This invention improves the resource utilization of cloud server data storage systems through fine-grained block-level deduplication. Simultaneously, it uses a Bloom filter-based user ownership verification mechanism to verify user identity, avoiding security risks caused by data leakage. Furthermore, it constructs a B+ tree-based re-encryption tree to perform insertion, query, and deletion operations on data tags and user tags. The cloud storage server and re-encryption center efficiently achieve dynamic updates of user file ownership through the B+ tree data structure.

[0145] 2. This invention provides a cloud server data storage method and system for secure deduplication of duplicate data across users, which can effectively achieve high efficiency and real-time dynamic updating of user ownership, and ensure system security and data integrity.

[0146] Other beneficial effects of the present invention will be explained in detail through the introduction of specific technical features and technical solutions in specific embodiments. Those skilled in the art should be able to understand the beneficial technical effects brought about by these technical features and technical solutions through the introduction of these technical features and technical solutions. Attached Figure Description

[0147] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0148] Figure 1 A cloud server data storage system model for secure deduplication of duplicate data across users;

[0149] Figure 2 This invention primarily illustrates the flowchart of the user's upload of non-duplicate data;

[0150] Figure 3 This is a schematic diagram illustrating the principle of the block-level deduplication method of this invention;

[0151] Figure 4 This is a schematic diagram illustrating the principle of the user ownership proof protocol implemented using a Bloom filter in this invention.

[0152] Figure 5 This invention primarily illustrates the flowchart of a user uploading duplicate data.

[0153] Figure 6 This is a flowchart illustrating the ownership proof mechanism of this invention.

[0154] Figure 7 This invention primarily embodies the flowchart of the dynamic update of user ownership;

[0155] Figure 8 This invention primarily illustrates the user's data download flow diagram. Detailed Implementation

[0156] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0157] This invention provides a cloud server data storage method, referring to... Figure 1 As shown, the method is as follows:

[0158] Step S1: Reference Figure 2 Flowchart of user upload of non-duplicate data. When a user requests to upload non-duplicate data, the cloud storage server checks whether the data has already been stored and performs data segmentation and encryption. The data owner requests re-encryption from the re-encryption center. The user creates a Bloom filter, which will be used in the user ownership proof protocol. Finally, the user sends the re-encrypted ciphertext, data tag, user tag, and Bloom filter to the cloud storage server.

[0159] Specifically, step S1 includes:

[0160] Step S1.1: The user generates a file tag and sends a request to the cloud storage server to upload the data, including the file tag and user tag {tag, id}. u The data is sent to a cloud storage server to check for duplicates.

[0161] Step S1.2: Once the request to upload data is sent to the server, the cloud storage server will use the file tag and user tag {tag, id}. u The server checks whether the file tag already exists in the database. Since the user uploads non-duplicate data, the server will find that the database does not contain the file tag, and then the server will request the user to send the relevant information about the file.

[0162] Step S1.3: Reference Figure 3 Block-level deduplication. After receiving instructions from the user regarding the file to be sent, the file is divided into blocks using a file partitioning algorithm:

[0163] {b i} i∈[1，n] =Divide(F, n)

[0164] Among them, {bi} i∈[1，n] This represents the set of n data blocks into which the original file is divided; b i Let i represent a data block, i∈[1,n]; F represents the original file; n represents the number of data blocks;

[0165] Then, the user uses a strong hash function to generate a convergent cryptographic key K. i The Encrypt algorithm is called to generate a converged encrypted ciphertext C. i The convergence encryption key for the data block {k i} i∈[1，n] Produced by a strong hash function:

[0166] K i =H(b) i ), i∈[1,n]

[0167] Where H(.) represents a strong hash function;

[0168] Converging encrypted ciphertext C i From the convergent encryption key {k i} i∈[1，n] The data blocks are generated using an encryption algorithm:

[0169] C i =Encrypt(b i K i )

[0170] Finally, in order to obtain the re-encryption key and perform the re-encryption operation, the user sends the file tag, the number of data blocks n, and the user tag ID to the re-encryption center. u .

[0171] Step S1.4: After receiving the user's request to obtain the re-encryption key, the re-encryption center determines the key based on the user's tag ID. u Find the tuple of the user's group by searching the re-encryption tree:

[0172] R[u]=<userrekey,filelist>

[0173] Obtain the user's re-encryption key using the binary tuple:

[0174] userrekey u =R[u].userrekey

[0175] The re-encryption center calls the Derekey algorithm to obtain a set of re-encryption keys {userrekeyi}. i∈[1，n] And return it to the user:

[0176] {userrekey i}i∈[1，n] =Derekey(userrekey) u (n)

[0177] Step S1.5: After receiving a set of re-encryption keys, the user re-encrypts the converged encrypted ciphertext to obtain a set of re-encrypted ciphertext {C′}. i} i∈[1，n] .

[0178] Step S1.6: Reference Figure 4 This diagram illustrates the principle of using a Bloom filter to implement a user ownership proof protocol. Users create Bloom filters for use on cloud storage servers to prove ownership, re-encrypting the ciphertext {C′}. i} i∈[1，n] File tag, user tag ID u And Bloom filters are sent to the cloud storage server.

[0179] Step S1.7: The relevant information of the file is stored in the database on the server side.

[0180] Step S2: Reference Figure 5 Flowchart of user uploading duplicate data. When a user requests to upload duplicate data, the cloud storage server performs data deduplication and deletion. If the server-side database has already saved the data, but the user tag has not yet been saved, the user ownership proof mechanism will be invoked and executed.

[0181] Specifically, in step S2:

[0182] Step S2.1: The user generates a file tag and sends a request to the cloud storage server to upload the data, including the file tag and user tag {tag, id}. u The data is sent to a cloud storage server to check for duplicates.

[0183] Step S2.2: The cloud storage server receives the user's request to upload data, searches the database and finds that the file tag has already been stored, indicating that the data has been stored. Then, the cloud storage server checks if the user's data has already been stored. If the user's data has also been stored, proceed to step S2.3. If the user's data has not been stored, proceed to step S2.4.

[0184] Step S2.3: The file tags and users have been stored. The cloud storage server sends the data redundancy results to the user. The user does not need to upload any data, and the process ends.

[0185] Step S2.4: If the file tag has been stored but the user has not, the cloud storage server performs ownership verification to confirm that the user actually owns the data. If the user fails ownership verification, proceed to step S2.5. If the user succeeds in ownership verification, proceed to step S2.6.

[0186] Step S2.5: If the file tag has been stored, but the user has not been stored and the user has not passed ownership verification, the cloud storage server will not perform any operation, and the process ends.

[0187] Step S2.6: The file tag has been stored, but the user has not. The user proves ownership, and then the cloud storage server stores the ID. u The process is now complete.

[0188] Step S3: Reference Figure 6 Ownership Proof Protocol Flowchart. This protocol implements user ownership proof based on a Bloom filter. When a user uploads data, if the file tag has already been stored but the user tag has not, the cloud storage server will perform ownership proof.

[0189] In step S3:

[0190] Step S3.1: t data blocks of the file are randomly selected by the cloud storage server and sent to the user:

[0191] B = {b1, b2, ..., b} t}, 1≤t≤n

[0192] Where B is the set of data blocks; b t Let t represent the t-th data block, 1≤t≤n; n represents the number of data blocks.

[0193] Step S3.2: The user calculates the label for each data block:

[0194]

[0195] Among them, b q H represents the q-th data block; H(.) represents a strong hash function. Represents data block b q The label; t represents the number of data blocks.

[0196] Step S3.3: The user labels the data blocks. Send to the cloud storage server.

[0197] Step S3.4: Reference Figure 4This diagram illustrates the principle of a user ownership proof protocol using a Bloom filter. For each data block, if all hash functions in the Bloom filter return a value of 1, the cloud storage server determines that the data block has passed the ownership proof mechanism. When all t data blocks have passed the ownership proof mechanism, the user tag ID... u The data will then be stored on the server. If the hash function of a data block produces a value of 0 in the Bloom filter, the user will fail the proof of ownership, the cloud storage server will not store any data, and will return a result indicating that the user's verification failed.

[0198] Step S4: Reference Figure 7 Flowchart of dynamic update of user ownership. The re-encryption center manages the re-encryption B+ tree to achieve user updates. By performing deletion and update operations on user re-encrypted ciphertext, the system can achieve dynamic updates of user file ownership.

[0199] Specifically, in step S4:

[0200] Step S4.1: The re-encryption center searches for the specified user in the re-encryption tree and performs the corresponding deletion, modification, or insertion operation. The new user re-encryption key, userrekey′, is obtained through the reKeyUpdate algorithm.

[0201] userrekey′ i =reKeyUpdate(userrekey) i )

[0202] Step S4.2: The re-encryption center sends the file tag to the cloud storage server based on the user group's tuple R[u] = <userrekey,filelist>, in preparation for updating the re-encrypted ciphertext.

[0203] Step S4.3: After receiving the file tag, the cloud storage server sends the old re-encrypted ciphertext {C′ i} i∈[1，n] The most important encryption center.

[0204] Step S4.4: The re-encryption center receives the old re-encrypted ciphertext {C′ i} i∈[1，n] Then, the ReDecrypt algorithm is executed to decrypt and obtain the converged encrypted ciphertext {C}. i} i∈[1，n] .

[0205] {C i} i∈[1，n] ={C′ i} i∈[1，n] -userrekey

[0206] Step S4.5: The re-encryption center executes the ReEncrypt algorithm, using the new re-encryption key userrekey′ to encrypt the converged ciphertext {C}. i} i∈[1，n] Re-encryption yields a new re-encrypted ciphertext {C″ i} i∈[1，n] .

[0207] {C″ i} i∈[1，n] ={C i} i∈[1，n] +userrekey′

[0208] Step S4.6: The re-encryption center will update the re-encrypted ciphertext {C″ i} i∈[1，n] The message is sent to a cloud storage server, which then saves the newly re-encrypted ciphertext.

[0209] Step S5: Reference Figure 8 User data download flow diagram. When a user requests to download data, the cloud storage server searches the database. If both the data tag and the user tag exist validly, it returns a re-encrypted ciphertext to the user. The user first decrypts the re-encrypted ciphertext to obtain the converged encrypted ciphertext, and then decrypts the converged encrypted ciphertext again to obtain the data block.

[0210] Specifically, in step S5:

[0211] Step S5.1: The user requests to download data and sends the file tag and user tag {tag, id}. u Send to the cloud storage server.

[0212] Step S5.2: The cloud storage server determines the file tag and user tag {tag, id} based on the file tag and user tag. u} Retrieve the database; if the search is successful, send the corresponding re-encrypted ciphertext {C′}. i} i∈[1，n] Provided to the user. If not found, a request failure is returned.

[0213] Step S5.3: The user sends a request to the re-encryption center to obtain the re-encryption key userrekey.

[0214] Step S5.4: The re-encryption center uses the user tag ID. u Find the re-encryption tree and return the re-encryption key userrekey to the user.

[0215] Step S5.5: The user executes the ReDecrypt algorithm to decrypt the re-encrypted ciphertext, obtaining the converged encrypted ciphertext {C}. i} i∈[1，n]。

[0216] {C i} i∈[1，n] ={C′ i} i∈[1，n] -userrekey

[0217] Step S5.6: The user executes the Decrypt algorithm to obtain data blocks, and integrates the data blocks to obtain the original file.

[0218] b i =Decrypt(C i K i )

[0219] F = {b i} i∈[1，n] .

[0220] This invention also provides a cloud server data storage system, which can be implemented by executing the process steps of the cloud server data storage method. That is, those skilled in the art can understand the cloud server data storage method as a preferred embodiment of the cloud server data storage system. Specifically, the system includes the following:

[0221] Module M1: Reference Figure 2 Flowchart of user upload of non-duplicate data. When a user requests to upload non-duplicate data, the cloud storage server checks whether the data has already been stored and performs data segmentation and encryption. The data owner requests re-encryption from the re-encryption center. The user creates a Bloom filter, which will be used in the user ownership proof protocol. Finally, the user sends the re-encrypted ciphertext, data tag, user tag, and Bloom filter to the cloud storage server.

[0222] Specifically, module M1 includes:

[0223] Module M1.1: The user generates a file tag and sends a request to the cloud storage server to upload the data, including the file tag and user tag {tag, id}. u The data is sent to a cloud storage server to check for duplicates.

[0224] Module M1.2: Once the request to upload data arrives at the server, the cloud storage server uses file tags and user tags {tag, id}. u The server checks whether the file tag already exists in the database. Since the user uploads non-duplicate data, the server will find that the database does not contain the file tag, and then the server will request the user to send the relevant information about the file.

[0225] Module M1.3: Reference Figure 3Block-level deduplication. After receiving instructions from the user regarding the file to be sent, the file is divided into blocks using a file partitioning algorithm:

[0226] {b i} i∈[1，n] =Divide(F, n)

[0227] Among them, {b i} i∈[1，n]表 The original file is divided into a set of n data blocks; b i Let i represent a data block, i∈[1,n]; F represents the original file; n represents the number of data blocks;

[0228] Then, the user uses a strong hash function to generate a convergent cryptographic key K. i The Encrypt algorithm is called to generate a converged encrypted ciphertext C. i The convergence encryption key for the data block {k i} i∈[1，n] Produced by a strong hash function:

[0229] K i =H(b) i ), i∈[1,n]

[0230] Where H(.) represents a strong hash function;

[0231] Converging encrypted ciphertext C i From the convergent encryption key {k i} i∈[1，n] The data blocks are generated using an encryption algorithm:

[0232] C i =Encrypt(b i K i )

[0233] Finally, in order to obtain the re-encryption key and perform the re-encryption operation, the user sends the file tag, the number of data blocks n, and the user tag ID to the re-encryption center. u .

[0234] Module M1.4: After receiving a request from a user to obtain a re-encryption key, the re-encryption center uses the user's tag ID to... u Find the tuple of the user's group by searching the re-encryption tree:

[0235] R[u]=<userrekey,filelist>

[0236] Obtain the user's re-encryption key using the binary tuple:

[0237] userrekey u =R[u].userrekey

[0238] The re-encryption center calls the Derekey algorithm to obtain a set of re-encryption keys {userrekey}. i} i∈[1，n] And return it to the user:

[0239] {userrekey i} i∈[1，n] =Derekey(userrekey) u (n)

[0240] Module M1.5: After receiving a set of re-encryption keys, the user re-encrypts the converged encrypted ciphertext to obtain a set of re-encrypted ciphertext {C′}. i} i∈[1，n] .

[0241] Module M1.6: Reference Figure 4 This diagram illustrates the principle of using a Bloom filter to implement a user ownership proof protocol. Users create Bloom filters for use on cloud storage servers to prove ownership, re-encrypting the ciphertext {C′}. i} i∈[1，n] File tag, user tag ID u And Bloom filters are sent to the cloud storage server.

[0242] Module M1.7: File-related information is stored in a database on the server side.

[0243] Module M2: Reference Figure 5 Flowchart of user uploading duplicate data. When a user requests to upload duplicate data, the cloud storage server performs data deduplication and deletion. If the server-side database has already saved the data, but the user tag has not yet been saved, the user ownership proof mechanism will be invoked and executed.

[0244] Specifically, in module M2:

[0245] Module M2.1: The user generates a file tag and sends a request to the cloud storage server to upload the data, including the file tag and user tag {tag, id}. u The data is sent to a cloud storage server to check for duplicates.

[0246] Module M2.2: The cloud storage server receives a request from the user to upload data. It searches the database and finds that the file tag has already been stored, indicating that the data has been stored. Then, the cloud storage server checks if the user's data has already been stored. If the user's data has also been stored, it proceeds to module M2.3. If the user's data has not been stored, it proceeds to module M2.4.

[0247] Module M2.3: File tags and users have been stored. The cloud storage server sends the data redundancy results to the user. The user does not need to upload any data, and the process ends.

[0248] Module M2.4: If the file tag has been stored but the user has not, the cloud storage server performs proof of ownership to verify that the user indeed owns the data. If the user fails proof of ownership, proceed to module M2.5. If the user succeeds in proving ownership, proceed to module M2.6.

[0249] Module M2.5: If the file tag has been stored, the user has not been stored, and the user has not passed ownership verification, the cloud storage server will not perform any operation, and the process ends.

[0250] Module M2.6: File tags have been stored, but user information has not. The cloud storage server stores the user's ID after the user proves ownership. u， The process is complete.

[0251] Module M3: Reference Figure 6 Ownership Proof Protocol Flowchart. This protocol implements user ownership proof based on a Bloom filter. When a user uploads data, if the file tag has already been stored but the user tag has not, the cloud storage server will perform ownership proof.

[0252] In module M3:

[0253] Module M3.1: t data blocks of the file are randomly selected by the cloud storage server and sent to the user.

[0254] B = {b1, b2, ..., b} t}, 1≤t≤n

[0255] Where B is the set of data blocks; b t Let t represent the t-th data block, 1≤t≤n; n represents the number of data blocks.

[0256] Module M3.2: User calculates the label for each data block:

[0257]

[0258] Among them, b q H represents the q-th data block; H(.) represents a strong hash function. Represents data block b q The label; t represents the number of data blocks.

[0259] Module M3.3: Users label data blocks Send to the cloud storage server.

[0260] Module M3.4: Reference Figure 4 This diagram illustrates the principle of a user ownership proof protocol using a Bloom filter. For each data block, if all hash functions in the Bloom filter return a value of 1, the cloud storage server determines that the data block has passed the ownership proof mechanism. When all t data blocks have passed the ownership proof mechanism, the user tag ID... u The data will then be stored on the server. If the hash function of a data block produces a value of 0 in the Bloom filter, the user will fail the proof of ownership, the cloud storage server will not store any data, and will return a result indicating that the user's verification failed.

[0261] Module M4: Reference Figure 7 Flowchart of dynamic update of user ownership. The re-encryption center manages the re-encryption B+ tree to achieve user updates. By performing deletion and update operations on user re-encrypted ciphertext, the system can achieve dynamic updates of user file ownership.

[0262] Specifically, in module M4:

[0263] Module M4.1: The re-encryption center searches for a specified user in the re-encryption tree and performs the corresponding deletion, modification, or insertion operation. It obtains the new user re-encryption key, userrekey′, through the reKeyUpdate algorithm.

[0264] userrekey′ i =reKeyUpdate(userrekey) i )

[0265] Module M4.2: The re-encryption center sends the file tag to the cloud storage server based on the user group's tuple R[u] = <userrekey,filelist>, in preparation for updating the re-encrypted ciphertext.

[0266] Module M4.3: After receiving the file tag, the cloud storage server sends the old, re-encrypted ciphertext {C′ i} i∈[1,n] The most important encryption center.

[0267] Module M4.4: The re-encryption center receives the old re-encrypted ciphertext {C′ i} i∈[1，n] Then, the ReDecrypt algorithm is executed to decrypt and obtain the converged encrypted ciphertext {C}. i} i∈[1,n] .

[0268] {C i} i∈[1,n] ={C′ i} i∈[1,n] -userrekey

[0269] Module M4.5: The re-encryption center executes the ReEncrypt algorithm, using the new re-encryption key userrekey′ to encrypt the converged ciphertext {C i} i∈[1,n] Re-encryption yields a new re-encrypted ciphertext {C″ i} i∈[1,n] .

[0270] {C″ i} i∈[1,n] ={C i} i∈[1,n] +userrekey′

[0271] Module M4.6: The re-encryption center will update the re-encrypted ciphertext {C″ i} i∈[1,n] The message is sent to a cloud storage server, which then saves the newly re-encrypted ciphertext.

[0272] Module M5: Reference Figure 8 User data download flow diagram. When a user requests to download data, the cloud storage server searches the database. If both the data tag and the user tag exist validly, it returns a re-encrypted ciphertext to the user. The user first decrypts the re-encrypted ciphertext to obtain the converged encrypted ciphertext, and then decrypts the converged encrypted ciphertext again to obtain the data block.

[0273] Specifically, in module M5:

[0274] Module M5.1: User requests to download data and includes file tags and user tags {tag, id} u Send to the cloud storage server.

[0275] Module M5.2: The cloud storage server uses file tags and user tags {tag, id} u} Retrieve the database; if the search is successful, send the corresponding re-encrypted ciphertext {C′}. i} i∈[1,n] Provided to the user. If not found, a request failure is returned.

[0276] Module M5.3: The user sends a request to the re-encryption center to obtain the re-encryption key userrekey.

[0277] Module M5.4: Re-encryption center based on user tag ID u Find the re-encryption tree and return the re-encryption key userrekey to the user.

[0278] Module M5.5: The user executes the ReDecrypt algorithm to decrypt the re-encrypted ciphertext, obtaining the converged encrypted ciphertext {C}. i} i∈[1，n] .

[0279] {C i} i∈[1，n] ={C′ i} i∈[1，n] -userrekey

[0280] Module M5.6: Users execute the Decrypt algorithm to obtain data blocks, and integrate the data blocks to obtain the original file.

[0281] b i =Decrypt(C i K i )

[0282] F = {b i} i∈[1，n] .

[0283] This invention provides a cloud server data storage method and system. It improves the resource utilization of the cloud server data storage system through fine-grained block-level deduplication, verifies user identity using a user ownership proof protocol to avoid security risks caused by data leakage, and constructs a re-encryption tree based on a B+ tree to achieve efficient and real-time dynamic updates of user ownership, ensuring system security and data integrity.

[0284] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0285] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A cloud server data storage method, characterized in that, include: Step S1: When a user requests to upload non-duplicate data, the cloud storage server checks whether the data has already been stored and performs data segmentation and encryption. The data owner requests re-encryption from the re-encryption center, and the user creates a Bloom filter, which will be used for the user ownership proof protocol. Finally, the user sends the re-encrypted ciphertext, data tag, user tag, and Bloom filter to the cloud storage server. Step S2: When a user requests to upload duplicate data, the cloud storage server performs data deduplication and data deletion. If the server-side database has already saved the data, but the user tag has not yet been saved, the user ownership proof mechanism will be invoked and executed. Step S3: Implement the user ownership proof protocol based on Bloom filters; when a user uploads data, if the file tag has been stored but the user tag has not been stored, the cloud storage server will perform ownership proof. Step S4: The re-encryption center manages the re-encryption B+ tree to enable user updates; by performing deletion and update operations on the user's re-encrypted ciphertext, the system achieves dynamic updates of the user's file ownership; Step S5: When a user requests to download data, the cloud storage server will search the database. If both the data tag and the user tag exist reasonably, it will return the re-encrypted ciphertext to the user. The user first decrypts the re-encrypted ciphertext to obtain the converged encrypted ciphertext, and then decrypts the converged encrypted ciphertext to obtain the data block. Step S4 includes: Step S4.1: The re-encryption center searches for the specified user in the re-encryption tree and performs the corresponding deletion, modification, or insertion operation; through... The algorithm obtains a new user re-encryption key. ; Step S4.2: The re-encryption center uses the user group's binary data. Send the file tag to the cloud storage server to prepare for updating and re-encrypting the ciphertext; Step S4.3: After receiving the file tag, the cloud storage server sends the old re-encrypted ciphertext. Supreme Encryption Center; Step S4.4: The re-encryption center receives the old re-encrypted ciphertext. Execute after The algorithm decrypts the convergent encrypted ciphertext. ; Step S4.5: Re-encryption center execution The algorithm uses a new re-encryption key. Converging encrypted ciphertext Re-encryption yields a new re-encrypted ciphertext. ; Step S4.6: The re-encryption center will update the re-encrypted ciphertext. The message is sent to a cloud storage server, which then saves the newly re-encrypted ciphertext. Step S5 includes: Step S5.1: The user requests to download data and includes file tags and user tags. Send to cloud storage server; Step S5.2: The cloud storage server determines the file tags and user tags. The database is searched, and if the result is found successfully, the corresponding re-encrypted ciphertext is sent. If the data is not found, return a request failure to the user. Step S5.3: The user sends a request to the re-encryption center to obtain the re-encryption key. The request; Step S5.4: The re-encryption center uses user tags. Find the re-encryption tree and return the re-encryption key to the user. ; Step S5.5: User execution The algorithm decrypts the re-encrypted ciphertext to obtain the converged encrypted ciphertext. ; Step S5.6: User execution The algorithm obtains data blocks, and the data blocks are integrated to obtain the original file:

2. The cloud server data storage method according to claim 1, characterized in that, Step S1 includes: Step S1.1: User generates file tags Send a request to the cloud storage server to upload the data, including file tags and user tags. Send the data to the cloud storage server to check for duplicates; Step S1.2: Once the request to upload data is sent to the server, the cloud storage server will use file tags and user tags. To check the document labels Whether it already exists in the database; in this case, the server finds that the database does not contain the file tag. The server then requests the user to send relevant information about the file; Step S1.3: After receiving the instructions to send the file, the user executes a file chunking algorithm on the file: in, This indicates that the original file is divided into A collection of data blocks; Represents a data block. ; This refers to the original file; Indicates the number of data blocks; Then, the user uses a strong hash function to generate a convergent encryption key. , call Algorithm generates convergent encrypted ciphertext The convergence encryption key for the data block Produced by a strong hash function: in, Indicates a strong hash function; Converging encrypted ciphertext From converged encryption key The data blocks are generated using an encryption algorithm: Finally, in order to obtain the re-encryption key and perform the re-encryption operation, the user sends a file tag to the re-encryption center. Number of data blocks and user tags ; Step S1.4: After receiving the user's request to obtain the re-encryption key, the re-encryption center determines the key based on the user's tag. Find the tuple of the user's group by searching the re-encryption tree: Obtain the user's re-encryption key using the binary tuple: Re-encryption center call The algorithm obtains a set of re-encryption keys. And return it to the user: Step S1.5: After receiving a set of re-encryption keys, the user re-encrypts the converged encrypted ciphertext to obtain a set of re-encrypted ciphertext. ; Step S1.6: The user creates a Bloom filter for the cloud storage server to perform ownership verification, and re-encrypts the ciphertext. File tags User tags And the Bloom filter is sent to the cloud storage server; Step S1.7: The relevant information of the file is stored in the database on the server side.

3. The cloud server data storage method according to claim 1, characterized in that, Step S2 includes: Step S2.1: User generates file tags Send a request to the cloud storage server to upload the data, including file tags and user tags. Send the data to the cloud storage server to check for duplicates; Step S2.2: The cloud storage server receives the user's request to upload data and searches the database to find file tags. It has already been stored, meaning the data has already been stored. The cloud storage server checks whether the user has already been stored; if the user has already been stored, proceed to step S2.3; if the user has not been stored, proceed to step S2.

4. Step S2.3: The file tags and users have been stored. The cloud storage server sends the data redundancy results to the user. The user does not need to upload any data, and the process ends. Step S2.4: If the file tag has been stored but the user has not been stored, the cloud storage server performs ownership verification to confirm that the user actually owns the data; if the user fails the ownership verification, proceed to step S2.5; if the user succeeds in the ownership verification, proceed to step S2.

6. Step S2.5: If the file tag has been stored, but the user has not been stored and the user has not passed ownership verification, the cloud storage server will not perform any operation, and the process ends. Step S2.6: The file tag has been stored, but the user has not. The user proves ownership, and then the cloud storage server stores the file. The process is now complete.

4. The cloud server data storage method according to claim 1, characterized in that, Step S3 includes: Step S3.1: File Each data block is randomly selected by the cloud storage server and sent to the user: in, A collection of data blocks; This represents the t-th data block. n represents the number of data blocks; Step S3.2: The user calculates the label for each data block: in, This represents the q-th data block; Indicates a strong hash function; Represents data block Tags; Indicates the number of data blocks; Step S3.3: The user labels the data blocks. Send to cloud storage server; Step S3.4: For each data block, if all hash functions in the Bloom filter produce a value of 1, the cloud storage server determines that the data block has passed the ownership proof mechanism; when Each data block is verified through an ownership proof mechanism, and user tags are used. It is then stored on the server side; If the hash function of a data block produces a value of 0 in the Bloom filter, the user cannot pass the proof of ownership, the cloud storage server will not store any data, and will return a result indicating that the user's verification has failed.

5. A cloud server data storage system, characterized in that, include: Module M1: When a user requests to upload non-duplicate data, the cloud storage server checks whether the data has already been stored and performs data segmentation and encryption. The data owner requests re-encryption from the re-encryption center, and the user creates a Bloom filter, which will be used for the user ownership proof protocol. Finally, the user sends the re-encrypted ciphertext, data tag, user tag, and Bloom filter to the cloud storage server. Module M2: When a user requests to upload duplicate data, the cloud storage server performs data deduplication and data deletion. If the server-side database has already saved the data, but the user tag has not yet been saved, the user ownership proof mechanism will be invoked and executed. Module M3: Implements a user ownership proof protocol based on a Bloom filter; when a user uploads data, if the file tag has already been stored but the user tag has not been stored, the cloud storage server will perform ownership proof. Module M4: The re-encryption center manages the re-encryption B+ tree to enable user updates; by performing deletion and update operations on user re-encrypted ciphertexts, the system achieves dynamic updates of user file ownership; Module M5: When a user requests to download data, the cloud storage server will search the database. If both the data tag and the user tag exist reasonably, it will return the re-encrypted ciphertext to the user. The user first decrypts the re-encrypted ciphertext to obtain the converged encrypted ciphertext, and then decrypts the converged encrypted ciphertext to obtain the data block. The module M4 includes: Module M4.1: The re-encryption center searches for a specified user in the re-encryption tree and performs the corresponding deletion, modification, or insertion operations; through... The algorithm obtains a new user re-encryption key. ; Module M4.2: Re-encryption center based on user group tuples Send the file tag to the cloud storage server to prepare for updating and re-encrypting the ciphertext; Module M4.3: After receiving the file tag, the cloud storage server sends the old, re-encrypted ciphertext. Supreme Encryption Center; Module M4.4: The re-encryption center receives the old re-encrypted ciphertext. Execute after The algorithm decrypts the convergent encrypted ciphertext. ; Module M4.5: Re-encryption center execution The algorithm uses a new re-encryption key. Converging encrypted ciphertext Re-encryption yields a new re-encrypted ciphertext. ; Module M4.6: The re-encryption center will update the re-encrypted ciphertext. The message is sent to a cloud storage server, which then saves the newly re-encrypted ciphertext. The module M5 includes: Module M5.1: User requests to download data and includes file tags and user tags. Send to cloud storage server; Module M5.2: Cloud storage server based on file tags and user tags The database is searched, and if the result is found successfully, the corresponding re-encrypted ciphertext is sent. If the data is not found, return a request failure to the user. Module M5.3: The user sends a request to the re-encryption center to obtain the re-encryption key. The request; Module M5.4: Re-encryption center based on user tags Find the re-encryption tree and return the re-encryption key to the user. ; Module M5.5: User Execution The algorithm decrypts the re-encrypted ciphertext to obtain the converged encrypted ciphertext. ; Module M5.6: User Execution The algorithm obtains data blocks, and the data blocks are integrated to obtain the original file: 。 6. The cloud server data storage system according to claim 5, characterized in that, The module M1 includes: Module M1.1: User-generated file tags Send a request to the cloud storage server to upload the data, including file tags and user tags. Send the data to the cloud storage server to check for duplicates; Module M1.2: Once the request to upload data arrives at the server, the cloud storage server uses file tags and user tags. To check the document labels Whether it already exists in the database; in this case, the server finds that the database does not contain the file tag. The server then requests the user to send relevant information about the file; Module M1.3: After receiving the user's instructions regarding sending a file, the module executes a file chunking algorithm on the file. in, This indicates that the original file is divided into A collection of data blocks; Represents a data block. ; This refers to the original file; Indicates the number of data blocks; Then, the user uses a strong hash function to generate a convergent encryption key. , call Algorithm generates convergent encrypted ciphertext The convergence encryption key for the data block Produced by a strong hash function: in, Indicates a strong hash function; Converging encrypted ciphertext From converged encryption key The data blocks are generated using an encryption algorithm: Finally, in order to obtain the re-encryption key and perform the re-encryption operation, the user sends a file tag to the re-encryption center. Number of data blocks and user tags ; Module M1.4: After receiving a request from a user to obtain a re-encryption key, the re-encryption center determines the key based on the user's tag. Find the tuple of the user's group by searching the re-encryption tree: Obtain the user's re-encryption key using the binary tuple: Re-encryption center call The algorithm obtains a set of re-encryption keys. And return it to the user: Module M1.5: After receiving a set of re-encryption keys, the user re-encrypts the converged encrypted ciphertext to obtain a set of re-encrypted ciphertext. ; Module M1.6: User-created Bloom filters are used for ownership verification on cloud storage servers, re-encrypting ciphertext. File tags User tags And the Bloom filter is sent to the cloud storage server; Module M1.7: File-related information is stored in a database on the server side.

7. The cloud server data storage system according to claim 5, characterized in that, The module M2 includes: Module M2.1: User-generated file tags Send a request to the cloud storage server to upload the data, including file tags and user tags. Send the data to the cloud storage server to check for duplicates; Module M2.2: The cloud storage server receives a request from the user to upload data and searches the database to find file tags. It has already been stored, meaning the data has already been stored. The cloud storage server checks whether the user has already been stored; if the user has already been stored, it redirects to module M2.3; if the user has not been stored, it redirects to module M2.

4. Module M2.3: The file tags and users have been stored. The cloud storage server sends the data redundancy results to the user. The user does not need to upload any data, and the process ends. Module M2.4: If the file tag has been stored but the user has not, the cloud storage server performs ownership verification to confirm that the user actually owns the data; if the user fails the ownership verification, proceed to module M2.5; if the user succeeds in the ownership verification, proceed to module M2.

6. Module M2.5: If the file tag has been stored, the user has not been stored, and the user has not passed ownership verification, the cloud storage server will not perform any operation, and the process ends. Module M2.6: File tags have been stored, but users have not. The cloud storage server stores the file after the user proves ownership. The process is now complete.

8. The cloud server data storage system according to claim 5, characterized in that, The module M3 includes: Module M3.1: Files Each data block is randomly selected by the cloud storage server and sent to the user: in, A collection of data blocks; This represents the t-th data block. n represents the number of data blocks; Module M3.2: User calculates the label for each data block: in, This represents the q-th data block; Indicates a strong hash function; Represents data block Tags; Indicates the number of data blocks; Module M3.3: Users label data blocks Send to cloud storage server; Module M3.4: For each data block, if all hash functions in the Bloom filter return a value of 1, the cloud storage server determines that the data block has passed the ownership proof mechanism; when... Each data block is verified through an ownership proof mechanism, and user tags are used. It is then stored on the server side; If the hash function of a data block produces a value of 0 in the Bloom filter, the user cannot pass the proof of ownership, the cloud storage server will not store any data, and will return a result indicating that the user's verification has failed.

Images