A cloud storage data integrity auditing method

Abstract

This disclosure relates to the field of network security technology and provides a cloud storage data integrity auditing method. Based on the splay tree concept in the field of load balancing, a scalable dynamic hash tree structure is designed, which can be applied to common access imbalance scenarios in cloud storage. This dynamic hash tree structure helps to reduce performance waste caused by data verification. Based on the dynamic hash tree structure, a data integrity auditing scheme is proposed using path proof, enabling the cloud storage system to have both high efficiency and reliability.

Description

Technical Field

[0001] This disclosure relates to the field of cybersecurity technology, and in particular to a method for auditing the integrity of cloud storage data. Background Technology

[0002] With the continuous development of the internet and the increasing digital demands of people, cloud storage has become increasingly prevalent, leading to a surge in cybersecurity attacks targeting cloud services. This has heightened public concern about data security in cloud storage. Regarding data integrity, some special scenarios can utilize hardware-enhanced data integrity mechanisms, while general scenarios often employ integrity verification mechanisms based on hash tree structures like Merkle trees. However, in large-scale cloud storage scenarios, introducing traditional hash tree structures can result in significant performance losses. This is because traditional hash tree structures, such as Merkle trees, typically assume average data access, meaning each data node is accessed at a randomized frequency. In reality, most cloud storage services experience skewed data access, where a small number of data blocks are accessed frequently. If these frequently accessed blocks are far from the hash tree root, integrity verification and data retrieval can lead to substantial performance waste. Therefore, addressing the skewed access scenarios in cloud services requires resolving the urgent issues of constructing efficient data storage structures and developing dynamic auditing mechanisms. Summary of the Invention

[0003] This disclosure aims to address at least one of the problems existing in the prior art by providing a method for auditing data integrity in cloud storage.

[0004] One aspect of this disclosure provides a cloud storage data integrity auditing method, the method comprising:

[0005] The client divides the file to be stored into multiple data blocks, constructs a corresponding dynamic hash tree structure with the hash value of each data block as the leaf node, stores it locally, and sends the multiple data blocks and their corresponding dynamic hash tree structures to the cloud storage server.

[0006] The cloud storage server receives and stores multiple data blocks and their corresponding dynamic hash tree structures;

[0007] The client and the cloud storage server dynamically adjust the dynamic hash tree structure they store according to the access or update status of each data block, so that the parent node corresponding to the accessed or updated data block is the root node of the dynamic hash tree structure, while keeping the preorder sequence of the dynamic hash tree structure and the node attributes of each node unchanged; wherein, the preorder sequence only includes the leaf nodes of the dynamic hash tree structure.

[0008] In response to the need for data integrity auditing, the cloud storage server sends the latest flag of the root node of the dynamic hash tree structure and the corresponding critical path proof to the client; the critical path proof is used to indicate that the hash value of the data block to be verified is the hash value of the sibling node of the leaf node.

[0009] The client performs integrity audit verification on the data block to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server.

[0010] Optionally, the client and the cloud storage server dynamically adjust the dynamic hash tree structure they store according to the access or update status of each data block, so that the parent node corresponding to the accessed or updated data block becomes the root node of the dynamic hash tree structure, while keeping the preorder sequence of the dynamic hash tree structure and the node attributes of each node unchanged, including:

[0011] After each data access or update, if the leaf node containing the hash value of the accessed or updated data block belongs to a non-root child node of the dynamic hash tree structure stored by the client and the cloud storage server respectively, then the client and the cloud storage server respectively adjust the parent node of the leaf node containing the hash value of the accessed or updated data block to the root node of the dynamic hash tree they store.

[0012] Optionally, the client and the cloud storage server respectively adjust the parent node of the leaf node containing the hash value of the accessed or updated data block to the root node of their respective stored dynamic hash trees, including:

[0013] The client and the cloud storage server respectively adopt an operation similar to the stretching operation of a splay tree, adjusting the parent node of the leaf node where the hash value of the accessed or updated data block is located to the root node of the dynamic hash tree they store.

[0014] Optionally, the dynamic adjustment of the dynamic hash tree structure stored by the client and the cloud storage server occurs after each data access and / or after each data update, while avoiding the data integrity audit verification period and the data processing period.

[0015] Optionally, the response to the existence of a data integrity audit requirement includes:

[0016] After accessing or updating the data block stored on the cloud storage server, the client proactively sends an integrity audit request to the cloud storage server for the data block to be verified.

[0017] Optionally, the response to the existence of a data integrity audit requirement includes:

[0018] After the client accesses or updates the data block stored on the cloud storage server, the cloud storage server proactively initiates an integrity audit request for the data block to be verified.

[0019] Optionally, the client performs integrity audit verification on the data block to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server, including:

[0020] The client performs hash calculation on the critical path proof sent by the cloud storage server and the hash value of the data block to be verified to obtain the root node calculation flag corresponding to the dynamic hash tree in the cloud storage server, and uses the root node calculation flag to verify the latest root node flag sent by the cloud storage server.

[0021] Optionally, the client performs integrity audit verification on the data block to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server, including:

[0022] After each data update, the client uses the latest root node flag and corresponding critical path proof of the dynamic hash tree structure stored locally to verify the latest root node flag and corresponding critical path proof sent by the cloud storage server.

[0023] Optionally, before the client and the cloud storage server dynamically adjust the dynamic hash tree structure they store respectively based on the access or update status of each data block, the method further includes:

[0024] The cloud storage server sends the preorder sequence of the dynamic hash tree structure it stores and the root node initial flag to the client.

[0025] Another aspect of this disclosure provides a cloud storage data integrity auditing system, the system comprising a client and a cloud storage server, wherein...

[0026] The client is used to divide the file to be stored into multiple data blocks, construct a corresponding dynamic hash tree structure with the hash value of each data block as the leaf node and store it locally, and send the multiple data blocks and their corresponding dynamic hash tree structures to the cloud storage server.

[0027] The cloud storage server is used to receive and store multiple data blocks and their corresponding dynamic hash tree structures;

[0028] The client and the cloud storage server are also configured to dynamically adjust the dynamic hash tree structure stored by each according to the access or update status of each data block, so that the parent node corresponding to the accessed or updated data block is the root node of the dynamic hash tree structure, while keeping the preorder sequence of the dynamic hash tree structure unchanged and the node attributes of each node unchanged; wherein, the preorder sequence only includes the leaf nodes of the dynamic hash tree structure.

[0029] The cloud storage server is also used to send the latest flag of the root node of the dynamic hash tree structure and the corresponding critical path proof to the client when there is a data integrity audit requirement; the critical path proof is used to indicate that the hash value of the data block to be verified is the hash value of the sibling node of the leaf node.

[0030] The client is also used to perform integrity audit verification on the data block to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server.

[0031] Compared with the prior art, this disclosure has the following advantages: It designs a scalable dynamic hash tree structure that is applicable to the common unbalanced access scenarios in cloud storage, and this structure helps to reduce the performance waste caused by data verification; Based on the dynamic hash tree structure, a data integrity auditing scheme is proposed using path proof, which enables the cloud storage system to have both high efficiency and reliability. Attached Figure Description

[0032] One or more embodiments are illustrated by way of example with the corresponding pictures in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0033] Figure 1 A flowchart illustrating a cloud storage data integrity auditing method provided in one embodiment of this disclosure;

[0034] Figure 2 A schematic diagram illustrating a cloud storage application scenario provided by another embodiment of this disclosure;

[0035] Figure 3 A schematic diagram illustrating the adjustment process of a dynamic hash tree provided for another embodiment of this disclosure;

[0036] Figure 4 A schematic diagram illustrating the application process of a cloud storage data integrity auditing method provided in another embodiment of this disclosure. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the various embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this disclosure to facilitate a better understanding of the disclosure. However, the technical solutions claimed in this disclosure can be implemented even without these technical details and with various variations and modifications based on the following embodiments. The division of the various embodiments below is for ease of description and should not constitute any limitation on the specific implementation of this disclosure. The various embodiments can be combined with and referenced by each other without contradiction.

[0038] In cloud storage scenarios, users often tend to access specific types of data, resulting in some data being accessed frequently while others are accessed infrequently, leading to a skewed data access phenomenon. Users typically need to verify data integrity after storage and before subsequent access. Existing data integrity verification methods usually employ balanced binary hash trees such as Merkle trees. Traditional hash trees typically have a fixed structure, with data access paths from the root node to an intermediate or leaf node. Given this skewed data access phenomenon in cloud storage, if frequently accessed nodes are far from the root node while infrequently accessed nodes are close, each data access query incurs significant performance overhead. Furthermore, considering security scenarios for data integrity verification, the path from the root node to a node far from the root node further exacerbates the performance burden of data integrity verification.

[0039] To address the problems caused by skewed data access in the aforementioned cloud storage scenarios, one embodiment of this disclosure provides a cloud storage data integrity auditing method, the process of which is as follows: Figure 1 As shown, it includes steps S110 to S150.

[0040] The cloud storage data integrity auditing method provided in this embodiment can be applied to… Figure 2 The cloud storage scenario shown. For example... Figure 2 As shown, in this scenario, the client can include applications such as browsers, database management systems (DBMS), web services, and email services, and can utilize the file system to store the relevant data files of these applications. The client can also divide the relevant data files of each application into several data blocks and store them in a data block layer. Using the cloud storage data integrity auditing method provided in this embodiment, a dynamic hash tree structure for the files that need to be stored on the cloud storage server is constructed. This dynamic hash tree is stored on the cloud storage server, and the integrity of the stored files can be verified using this dynamic hash tree structure.

[0041] In step S110, the client divides the file to be stored into multiple data blocks, constructs a corresponding dynamic hash tree structure using the hash value of each data block as the leaf node, stores it locally, and sends the multiple data blocks and their corresponding dynamic hash tree structures to the cloud storage server.

[0042] Specifically, the file to be stored refers to the file on the client that needs to be stored on the cloud storage server. For example, the client can slice the file F to be stored, dividing it into data blocks B0-Bn and storing them, where n represents the maximum number of the data blocks, and the total number of data blocks in the file F is n+1. The hash values ​​of data blocks B0-Bn can be represented as H(B0)-H(Bn), where H represents the hash function. The client can use H(B0)-H(Bn) as leaf nodes to construct corresponding hash trees as dynamic hash tree structures, and send the data blocks B0-Bn and the corresponding hash tree structures to the cloud storage server. To distinguish between the dynamic hash tree structures stored on the client and the cloud storage server, the dynamic hash tree structure on the client can be denoted as Tree_L, and the dynamic hash tree structure on the cloud storage server can be denoted as Tree_G.

[0043] It should be noted that the dynamic hash tree structure in this embodiment is a structure similar to a splay tree. Splay trees are mainly used in scenarios such as garbage collection mechanisms and Internet Protocol (IP) routing queries. Since splay trees can adjust their size in real time according to the load, this embodiment builds a dynamic hash tree structure based on a splay tree and uses this dynamic hash tree structure to implement data querying and integrity security verification in cloud storage scenarios.

[0044] In step S120, the cloud storage server receives and stores multiple data blocks and their corresponding dynamic hash tree structures.

[0045] Specifically, when the client sends data blocks B0-Bn and the corresponding hash tree structure Tree_G to the cloud storage server, the cloud storage server receives and stores data blocks B0-Bn and the hash tree structure Tree_G.

[0046] In step S130, the client and the cloud storage server dynamically adjust their respective dynamic hash tree structures based on the access or update status of each data block. This ensures that the parent node corresponding to the accessed or updated data block becomes the root node of the dynamic hash tree structure, while maintaining the preorder sequence of the dynamic hash tree structure and the node attributes of each node. The preorder sequence only includes the leaf nodes of the dynamic hash tree structure.

[0047] It should be noted that the dynamic adjustment of the dynamic hash tree structure stored by the client and the cloud storage server occurs after each data access and / or after each data update, while avoiding the data integrity audit verification period and the data processing period.

[0048] Specifically, during the data integrity audit and verification period, data consistency is typically required. Therefore, it is not advisable to adjust the dynamic hash tree structure during this period to avoid deviations in the data integrity audit and verification. Similarly, during the data processing period, such as when background storage tasks require privacy-sensitive data processing, strong consistency of the data structure tree is also necessary. In this case, it is also not advisable to adjust the dynamic hash tree structure.

[0049] In other words, the client and cloud storage server can adjust the dynamic hash tree structure they store after each data access or after each data update. However, the adjustment process must avoid periods of data integrity auditing and verification, as well as data processing periods, to maintain strong consistency of the data structure tree. To this end, an adjustment bit f can be set to indicate whether adjustments to the dynamic hash tree structure are allowed. For example, the adjustment bit f can take the value 0 or 1. A value of 0 indicates that adjustments to the dynamic hash tree structure are not allowed, while a value of 1 indicates that adjustments are allowed. Alternatively, a value of 0 also indicates that adjustments are allowed, while a value of 1 indicates that adjustments are not allowed.

[0050] During the adjustment of the dynamic hash tree structure, maintaining the unchanged node attributes means that a node that was a leaf node before the adjustment remains a leaf node after the adjustment, and similarly, a node that was a non-leaf node before the adjustment remains a non-leaf node after the adjustment. Keeping the preorder traversal and node attributes unchanged during the adjustment of the dynamic hash tree structure facilitates subsequent data integrity auditing and verification.

[0051] By adjusting the dynamic hash tree structure, frequently accessed nodes can be made into children of the root node, thereby shortening the data access path and improving data access efficiency.

[0052] For example, in step S130, the client and the cloud storage server dynamically adjust their respective dynamic hash tree structures according to the access or update status of each data block, so that the parent node corresponding to the accessed or updated data block becomes the root node of the dynamic hash tree structure, while keeping the preorder sequence of the dynamic hash tree structure and the node attributes of each node unchanged. This includes: after each data access or data update, if the leaf node where the hash value of the accessed or updated data block is located belongs to a non-root child node of the dynamic hash tree structure stored by the client and the cloud storage server respectively, then the client and the cloud storage server respectively adjust the parent node of the leaf node where the hash value of the accessed or updated data block is located to the root node of their respective dynamic hash trees.

[0053] Specifically, if the leaf node containing the hash value of the accessed or updated data block is already a child node of the root node of the dynamic hash tree structure, then the dynamic hash tree structure can already reflect that the leaf node belongs to a frequently accessed node. In this case, there is no need to adjust the dynamic hash tree structure.

[0054] For example, the client and the cloud storage server respectively adjust the parent node of the leaf node containing the hash value of the accessed or updated data block to the root node of their respective stored dynamic hash trees. This includes: the client and the cloud storage server respectively use an operation similar to the stretching operation of a splay tree to adjust the parent node of the leaf node containing the hash value of the accessed or updated data block to the root node of their respective stored dynamic hash trees.

[0055] Specifically, a splay tree is a self-adjusting form of binary search tree that maintains its balance through a series of processes called splay operations. A splay operation involves moving a node to the root of the tree after accessing it (whether through searching, insertion, or deletion), effectively shortening the access path and helping to redistribute nodes within the tree. This implementation improves upon this by using splay operations to adjust the parent node of a visited or updated leaf node to the root node, thereby reducing the performance overhead of the adjustment process to some extent.

[0056] For example, combined Figure 3 Suppose that the leaf node containing the hash value of the accessed or updated data block is B, its parent node is T, and T's parent node is P. Then, depending on the specific position of T in the dynamic hash tree structure, the adjustment process of the dynamic hash tree structure can be divided into different cases.

[0057] For example, such as Figure 3As shown in (1), when the dynamic hash tree structure before adjustment includes B, T, P and leaf nodes L1 and L2, and B and T are both left child nodes, only one right rotation is needed to turn T into the root node. Since the right rotation during the adjustment of the dynamic hash tree structure increases the level of B by one level, the level fq of B also changes from 0 to 1, that is, from fq=0 to fq=1. Figure 3 The adjustment process of the dynamic hash tree structure shown in (1) is a single adjustment.

[0058] For example, such as Figure 3 As shown in (2), when the dynamic hash tree structure before adjustment includes B, T, P, leaf nodes L1, L2, L3 and root node N1, and B, T and P are all left child nodes, two right rotations are required, namely, first right rotation P and then right rotation T to make T the root node. Since each right rotation in the process of adjusting the dynamic hash tree structure increases the level of B by one level, the level fq of B also changes from 0 to 1 and then to 2, that is, from fq=0 to fq=1 and then to fq=2. Figure 3 The adjustment process of the dynamic hash tree structure shown in (2) belongs to the case of multiple unidirectional adjustments.

[0059] For example, such as Figure 3 As shown in (3), when the dynamic hash tree structure before adjustment includes B, T, P, leaf nodes L1, L2, L3 and root node N1, with B and T being right child nodes and P being a left child node, two rotations are required, namely, rotating T to the left and then rotating P to the right to make T the root node. Since rotating to the left during the adjustment of the dynamic hash tree structure increases the level of B by one level while rotating to the right does not change the level of B, the level fq of B only changes from 0 to 1, that is, from fq = 0 to fq = 1. Figure 3 The adjustment process of the dynamic hash tree structure shown in (3) belongs to the case of multiple bidirectional adjustments.

[0060] For example, before the client and cloud storage server dynamically adjust their respective stored dynamic hash tree structures based on the access or update status of each data block, the cloud storage data integrity auditing method further includes: the cloud storage server sending the preorder sequence and root node initial flag of its stored dynamic hash tree structure to the client, so that the client can ensure that its stored dynamic hash tree structure is consistent with the dynamic hash tree structure stored by the cloud storage server before dynamically adjusting the dynamic hash tree structure, based on the preorder sequence and root node initial flag. Here, the root node initial flag refers to the location identifier of the root node of the dynamic hash tree structure sent by the client to the cloud storage server.

[0061] In step S140, in response to the need for data integrity auditing, the cloud storage server sends the latest flag of the root node of the dynamic hash tree structure and the corresponding critical path proof to the client. The critical path proof is used to indicate the hash value of the sibling node of the leaf node, where the hash value of the data block to be verified is the same as the hash value of the leaf node.

[0062] Specifically, data integrity audit requirements can be proposed by the client or by the cloud storage server.

[0063] When a data integrity audit request is made by a client, in step S140, in response to the existence of a data integrity audit request, the client actively sends an integrity audit request for the data block to be verified to the cloud storage server after accessing or updating the data block stored on the cloud storage server.

[0064] When a data integrity audit request is made by the cloud storage server, in step S140, in response to the existence of a data integrity audit request, the cloud storage server actively initiates an integrity audit request for the data block to be verified after the client accesses or updates the data block stored on the cloud storage server.

[0065] In step S150, the client performs integrity audit verification on the data block to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server.

[0066] Specifically, when the data integrity audit request is initiated by the client, the client proactively performs data integrity audit verification. When the data integrity audit request is initiated by the cloud storage server, the client passively performs data integrity audit verification.

[0067] Client-side data integrity audit verification includes regular verification and rigorous verification. Regular verification is performed for each data integrity audit, while rigorous verification is performed after each data update.

[0068] For example, during routine verification, step S150 includes: the client performing hash calculation on the critical path proof sent by the cloud storage server and the hash value of the data block to be verified to obtain the root node calculation flag corresponding to the dynamic hash tree in the cloud storage server, and using the root node calculation flag to verify the latest root node flag sent by the cloud storage server.

[0069] Specifically, the root node calculation flag here refers to the current position identifier of the root node in the dynamic hash tree of the cloud storage server, calculated by the client based on the critical path proof sent by the cloud storage server and the hash value of the data block to be verified. The latest root node flag sent by the cloud storage server refers to the actual current position identifier of the root node in the dynamic hash tree of the cloud storage server. If the root node calculation flag matches the latest root node flag sent by the cloud storage server, the cloud storage data is considered complete; otherwise, the cloud storage data is considered incomplete.

[0070] For example, during rigorous verification, step S150 includes: after each data update, the client uses the latest root node flag and corresponding critical path proof of the locally stored dynamic hash tree structure to verify the latest root node flag and corresponding critical path proof sent by the cloud storage server.

[0071] Specifically, to prevent security and privacy risks associated with cloud storage servers, during rigorous verification, the client uses its locally stored latest root node identifier and corresponding critical path proof to verify the latest root node identifier and corresponding critical path proof sent by the cloud storage server. If the latest root node identifier in the client's local storage matches the latest root node identifier sent by the cloud storage server, and the critical path proof in the client's local storage matches the critical path proof sent by the cloud storage server, then the cloud storage data is considered complete; otherwise, the cloud storage data is considered incomplete.

[0072] To enable those skilled in the art to better understand the above embodiments, a specific example is provided below.

[0073] like Figure 4 As shown, a cloud storage data integrity auditing method is applied to cloud storage scenarios, including steps ① to ⑨.

[0074] Step ①: The client divides the file F into data blocks B0 to Bn, and constructs a dynamic hash tree based on the data blocks B0 to Bn, denoted as Tree_L. The data blocks B0 to Bn and the dynamic hash tree Tree_L are then stored locally.

[0075] Step 2: The client sends data blocks B0 to Bn and a dynamic hash tree (Tree_G) identical to the dynamic hash tree (Tree_L) to the server, which can be a cloud storage server. The server receives data blocks B0 to Bn and the dynamic hash tree (Tree_G), and sends the initial root flag (r) of the root node of the dynamic hash tree (Tree_G) and the hash preorder sequence L to the client. Suppose the client divides file F into 4 data blocks B0, B1, B2, and B3, with hash values ​​H(B0), H(B1), H(B2), and H(B3) respectively. H(B0), H(B1), H(B2), and H(B3) correspond to the leaf nodes B, L1, L2, and L3 of the dynamic hash tree Tree_G, respectively. The parent node of B and L1 is T, the parent node of T and L2 is P, and the parent node of P and L3 is the root node N1. Then, the initial root flag r of the dynamic hash tree Tree_G can be represented as r = H(H(H(H(B0),H(B1)),H(B2)),H(B3)), and the hash preorder sequence L can be represented as L = {H(B0),H(B1),H(B2),H(B3)}.

[0076] Step 3: The client and server interact multiple times for data access and updates.

[0077] Step 4: Assuming the last data interaction update between the client and the server was of data block B0 corresponding to leaf node B, the server adjusts the dynamic hash tree Tree_G according to the interaction, changing the parent node of leaf node B to the root node. The client synchronizes the dynamic hash tree Tree_L. After the adjustment, the new root flag of the dynamic hash tree Tree_G is r', and r' is represented as r' = H(H(B0), H(H(B1), H(H(B2), (B3)))).

[0078] Step 5: After updating data block B0, the client sends a data block B0 integrity audit request Rv(H(B0)) to the server.

[0079] Step 6: The server sends the new root flag r' = H(H(B0), H(H(B1), H(H(B2), (B3)))) of the dynamic hash tree Tree_G and the critical path proof proof = H(P) = H(H(B1), H(H(B2), H(B3))) to the client.

[0080] Step 7: The client uses the critical path proofs proof = H(P) = H(H(B1), H(H(B2), H(B3))) and H(B0) to perform hash calculations to obtain the root node calculation flag r^ = H(H(B0), proof).

[0081] Step 8: The client performs a routine integrity verification, checking whether r^ is equal to r', i.e., r^? = r'. If r^ is equal to r', then the data block B0 stored on the server is considered complete; otherwise, the data block B0 stored on the server is considered incomplete.

[0082] Step 9: The client performs strict integrity verification, using the locally stored dynamic hash tree Tree_L to verify r' and proof. If the current root flag of the dynamic hash tree Tree_L is consistent with r' and the critical path proof obtained from the dynamic hash tree Tree_L is consistent with proof, then the data block B0 stored on the server is considered complete; otherwise, the data block B0 stored on the server is considered incomplete.

[0083] The cloud storage data integrity auditing method provided in this disclosure has the following advantages over the prior art: it designs a scalable dynamic hash tree structure, which is applicable to common access imbalance scenarios in cloud storage. This structure helps to reduce performance waste caused by data verification. Based on the dynamic hash tree structure, a data integrity auditing scheme is proposed using path proof, enabling the cloud storage system to have both high efficiency and reliability.

[0084] Another embodiment of this disclosure relates to a cloud storage data integrity auditing system, including a client and a cloud storage server.

[0085] The client is used to divide the file to be stored into multiple data blocks, construct a corresponding dynamic hash tree structure with the hash value of each data block as the leaf node, store it locally, and send multiple data blocks and their corresponding dynamic hash tree structures to the cloud storage server.

[0086] Cloud storage servers are used to receive and store multiple data blocks and their corresponding dynamic hash tree structures.

[0087] The client and cloud storage server are also used to dynamically adjust the dynamic hash tree structure of their respective storage based on the access or update status of each data block, so that the parent node corresponding to the accessed or updated data block is the root node of the dynamic hash tree structure, while keeping the preorder sequence of the dynamic hash tree structure unchanged and the node attributes of each node unchanged; wherein, the preorder sequence only includes the leaf nodes of the dynamic hash tree structure.

[0088] The cloud storage server is also used when data integrity auditing is required. It sends the latest flag of the root node of the dynamic hash tree structure and the corresponding critical path proof to the client. The critical path proof indicates the hash value of the sibling node of the leaf node, where the hash value of the data block to be verified is the same as the hash value of the leaf node.

[0089] The client is also used to perform integrity audit verification on the data blocks to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server.

[0090] The specific implementation method of the cloud storage data integrity auditing system provided in this disclosure can be found in the cloud storage data integrity auditing method provided in this disclosure, and will not be repeated here.

[0091] The cloud storage data integrity auditing system provided in this disclosure has the following advantages over the prior art: it designs a scalable dynamic hash tree structure, which is applicable to common access imbalance scenarios in cloud storage scenarios. This structure helps to reduce performance waste caused by data verification. Based on the dynamic hash tree structure, path proof is used to realize data integrity auditing, so that the cloud storage system has both high efficiency and reliability.

[0092] Those skilled in the art will understand that the above embodiments are specific implementations of this disclosure, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this disclosure.

Claims

1. A cloud storage data integrity auditing method, characterized in that, The method includes: The client divides the file to be stored into multiple data blocks, constructs a corresponding dynamic hash tree structure with the hash value of each data block as the leaf node, stores it locally, and sends the multiple data blocks and their corresponding dynamic hash tree structures to the cloud storage server. The cloud storage server receives and stores multiple data blocks and their corresponding dynamic hash tree structures; The client and the cloud storage server dynamically adjust the dynamic hash tree structure they store according to the access or update status of each data block, so that the parent node corresponding to the accessed or updated data block is the root node of the dynamic hash tree structure, while keeping the preorder sequence of the dynamic hash tree structure and the node attributes of each node unchanged; wherein, the preorder sequence only includes the leaf nodes of the dynamic hash tree structure. In response to the need for data integrity auditing, the cloud storage server sends the latest flag of the root node of the dynamic hash tree structure and the corresponding critical path proof to the client; the critical path proof is used to indicate that the hash value of the data block to be verified is the hash value of the sibling node of the leaf node. The client performs integrity audit verification on the data block to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server.

2. The method according to claim 1, characterized in that, The client and the cloud storage server dynamically adjust their respective stored dynamic hash tree structures based on the access or update status of each data block, so that the parent node corresponding to the accessed or updated data block becomes the root node of the dynamic hash tree structure, while maintaining the preorder tracing of the dynamic hash tree structure and the node attributes of each node unchanged, including: After each data access or update, if the leaf node containing the hash value of the accessed or updated data block belongs to a non-root child node of the dynamic hash tree structure stored by the client and the cloud storage server respectively, then the client and the cloud storage server respectively adjust the parent node of the leaf node containing the hash value of the accessed or updated data block to the root node of the dynamic hash tree they store.

3. The method according to claim 2, characterized in that, The client and the cloud storage server respectively adjust the parent node of the leaf node containing the hash value of the accessed or updated data block to the root node of their respective stored dynamic hash trees, including: The client and the cloud storage server respectively adopt an operation similar to the stretching operation of a splay tree, adjusting the parent node of the leaf node where the hash value of the accessed or updated data block is located to the root node of the dynamic hash tree they store.

4. The method according to any one of claims 1 to 3, characterized in that, The dynamic adjustments made by the client and the cloud storage server to the dynamic hash tree structure stored by each other occur after each data access and / or after each data update, while avoiding the data integrity audit verification period and the data processing period.

5. The method according to claim 1, characterized in that, The response to the existence of a data integrity audit requirement includes: After accessing or updating the data block stored on the cloud storage server, the client proactively sends an integrity audit request to the cloud storage server for the data block to be verified.

6. The method according to claim 1, characterized in that, The response to the existence of a data integrity audit requirement includes: After the client accesses or updates the data block stored on the cloud storage server, the cloud storage server proactively initiates an integrity audit request for the data block to be verified.

7. The method according to claim 1, characterized in that, The client performs integrity audit verification on the data block to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server, including: The client performs hash calculation on the critical path proof sent by the cloud storage server and the hash value of the data block to be verified to obtain the root node calculation flag corresponding to the dynamic hash tree in the cloud storage server, and uses the root node calculation flag to verify the latest root node flag sent by the cloud storage server.

8. The method according to claim 1, characterized in that, The client performs integrity audit verification on the data block to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server, including: After each data update, the client uses the latest root node flag and corresponding critical path proof of the dynamic hash tree structure stored locally to verify the latest root node flag and corresponding critical path proof sent by the cloud storage server.

9. The method according to claim 1, characterized in that, Before the client and the cloud storage server dynamically adjust the dynamic hash tree structure they store respectively based on the access or update status of each data block, the method further includes: The cloud storage server sends the preorder sequence of the dynamic hash tree structure it stores and the root node initial flag to the client.

10. A cloud storage data integrity auditing system, characterized in that, The system includes a client and a cloud storage server; The client is used to divide the file to be stored into multiple data blocks, construct a corresponding dynamic hash tree structure with the hash value of each data block as the leaf node and store it locally, and send the multiple data blocks and their corresponding dynamic hash tree structures to the cloud storage server. The cloud storage server is used to receive and store multiple data blocks and their corresponding dynamic hash tree structures; The client and the cloud storage server are also configured to dynamically adjust the dynamic hash tree structure stored by each according to the access or update status of each data block, so that the parent node corresponding to the accessed or updated data block is the root node of the dynamic hash tree structure, while keeping the preorder sequence of the dynamic hash tree structure unchanged and the node attributes of each node unchanged; wherein, the preorder sequence only includes the leaf nodes of the dynamic hash tree structure. The cloud storage server is also used to send the latest flag of the root node of the dynamic hash tree structure and the corresponding critical path proof to the client when there is a data integrity audit requirement; the critical path proof is used to indicate that the hash value of the data block to be verified is the hash value of the sibling node of the leaf node. The client is also used to perform integrity audit verification on the data block to be verified based on the latest root node flag and corresponding critical path proof sent by the cloud storage server.

Images