Privacy preserving cloud storage system based on virtual access insertion

Abstract

A privacy protection cloud storage system based on virtual access insertion, which maintains a location mapping table at the client side and continuously generates virtual accesses at fixed time periods; when a real access request arrives and there is no pending compensation access, the current virtual access is replaced by the real access and the replaced virtual access address is recorded, and the recorded virtual access is executed when the compensation condition is met subsequently. Real access and virtual access are both represented as a data bucket read and a data bucket write back at the cloud server side, thereby hiding the user's access location, access order, access frequency and access time under a given security model, and achieving privacy protection of the cloud storage access mode; at the same time, real access directly locates the target data bucket through the location mapping table, so as to reduce the number of online server input and output times and access latency and maintain the consistency of access scheduling rules through request queuing and compensation execution when request bursts arrive.

Description

Technical Field

[0001] This invention relates to a technology in the field of information security, specifically a privacy-preserving cloud storage system based on virtual access insertion. Background Technology

[0002] Existing cloud storage systems typically employ symmetric encryption, access control, and authentication to protect data content, preventing attackers from directly reading plaintext data. However, current inadvertent access storage technologies cannot maintain consistency in the distribution of access locations and access levels observed by the cloud server while ensuring that real access requests only access the single data bucket containing the target data block, reducing the number of online server input / output operations and access latency. Furthermore, they cannot continuously maintain access pattern protection capabilities through request queuing and compensatory execution when real requests arrive in concentrated bursts. Existing cloud server access technologies cannot prevent the cloud server from inferring the data blocks and their relationships actually accessed by users based on physical storage location, access order, and access frequency. They also cannot maintain consistency in server-side access levels and distribution through compensatory virtual access when real access requests only access the target data bucket. Summary of the Invention

[0003] To address the aforementioned shortcomings of existing technologies, this invention proposes a privacy-preserving cloud storage system based on virtual access insertion. This system maintains a location mapping table on the client side and continuously generates virtual accesses at fixed time intervals. When a real access request arrives and there are no requests to be compensated, the current virtual access is replaced by the real access, and the address of the replaced virtual access is recorded. The recorded virtual access is then executed when compensation conditions are met subsequently. Both real and virtual accesses on the cloud server side manifest as a single data bucket read and a single data bucket write-back, thereby hiding the user's access location, access order, access frequency, and access time within a predetermined security model, achieving privacy protection for cloud storage access patterns. Simultaneously, real accesses directly locate the target data bucket through the location mapping table, reducing the number of online server input / output operations and access latency. Furthermore, in the event of a sudden surge in requests, request queuing and compensation execution maintain the consistency of access scheduling rules.

[0004] This invention is achieved through the following technical solution:

[0005] This invention relates to a privacy-preserving cloud storage system based on virtual access insertion, comprising: a main control module, a timer module, a virtual access generation module, an access compensation module, an encryption / decryption module, and a background eviction module located on the client side; and a storage module located on the cloud server side containing an encrypted bucket-style tree storage structure. Specifically: the main control module performs access scheduling processing based on user requests, timed trigger signals, request queues, and compensation status information to obtain data bucket access instructions; the timer module performs periodic trigger processing based on a preset timer period to obtain timed trigger signals; the virtual access generation module performs random address generation processing based on tree storage structure parameters to obtain virtual access addresses; the access compensation module performs compensation condition judgment based on the replaced virtual access address and subsequent virtual access addresses to obtain a compensated access address; the encryption / decryption module performs encryption / decryption processing based on the client key and the encrypted data bucket to obtain plaintext data blocks or re-encrypted data buckets; the background eviction module performs data block write-back processing based on a temporary storage area, a location mapping table, and a selected path to obtain updated data buckets and a location mapping table; and the storage module performs read or write processing of encrypted data buckets based on bucket access instructions to obtain encrypted data buckets or write results.

[0006] The storage module on the cloud server side uses a complete binary tree of height L to organize encrypted data blocks, with levels numbered from 0 to L-1 from the root node to the leaf nodes. Each node in the tree is a data bucket, and each data bucket contains Z storage locations; if a data bucket is not filled with real data blocks, virtual data blocks are used to fill it. Both real and virtual data blocks are encrypted by the client and written to the cloud server, therefore the cloud server cannot distinguish between real and virtual data blocks based solely on the ciphertext content. The m-th data bucket at level h is uniquely identified by the address (h, m), where: 0 ≤ h ≤ L-1, 0 ≤ m ≤ ... .

[0007] The main control module on the client side maintains a position mapping table. For each data block identifier (id), the position mapping table records the corresponding path position[id] = ... The client queries the location mapping table based on the data block identifier (id) to obtain the bucket address (h,m) and uses this address to directly access the target data bucket, where: the bucket number of the level where the target data block resides. , The leaf is numbered, h is the level, and 0 ≤ h ≤ h. ≤ , 0≤h≤L-1.

[0008] This invention relates to a privacy-preserving cloud storage method based on the aforementioned system. During the initialization phase, a timer module is set up on the client side. In each timer cycle, the main control module initiates an access operation to the storage module on the cloud server side. The virtual access generation module on the client side first randomly generates a virtual access request. If there is no real access request from the user in the current cycle, the virtual access request generated by the virtual access generation module is executed. If there is a real access request from the user in the current cycle, and there are no historical real access requests that have not yet been compensated, the main control module on the client side executes the real access request, replacing the virtual access request in the current timer cycle. This allows the real access request to be mixed into the continuously generated virtual access sequence, thereby hiding the occurrence time and access target of the user's real access request.

[0009] Technical effect

[0010] This invention generates virtual accesses on the client side at fixed time intervals, ensuring that these virtual accesses exhibit consistent bucket read / write behavior with real accesses on the cloud server side. Under a predetermined security model, it hides the user's access location, frequency, and order. A location mapping table determines the data bucket containing the target data block, ensuring that real requests only access the corresponding single data bucket, unlike traditional ORAM schemes which require reading entire paths or multiple data buckets. This reduces online server input / output frequency and lowers online access latency for user requests. Furthermore, a real access request compensation mechanism is employed. When a real access replaces the current virtual access, the replaced virtual access address is recorded, and the virtual access is executed in subsequent periods when compensation conditions are met, maintaining consistency in access hierarchy distribution and preventing significant statistical bias caused by real access request insertions. When real requests arrive consecutively before the previous compensation is complete, subsequent requests are added to a request queue and processed sequentially after compensation is completed, maintaining consistency in access scheduling rules. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the structure of the present invention;

[0012] Figure 2 The flowchart for timed driver access of the main control module;

[0013] Figure 3 This is a diagram illustrating the compensation mechanism for genuine access requests.

[0014] Figure 4 This is a flowchart of a single-bucket read / write access process;

[0015] Figure 5 This is a flowchart of the background expulsion process. Detailed Implementation

[0016] In this embodiment, the application scenario is that the user outsources the storage of data blocks to a cloud server that is used to store the encrypted data blocks and perform read and write operations according to the client's request. The cloud server is regarded as an untrusted storage backend. It can observe the storage location, access order, access time and read / write type of each physical access, but cannot obtain the key saved by the client, nor can it directly know the plaintext content in the encrypted data block.

[0017] like Figure 1 As shown, this embodiment relates to a privacy-preserving cloud storage system based on virtual access insertion, including: a main control module, a timer module, a virtual access generation module, an access compensation module, an encryption / decryption module, and a background eviction module located on the client side, and a storage module located on the cloud server side containing an encrypted bucket-style tree storage structure.

[0018] In this embodiment, only the single data bucket containing the target data block is accessed during a real access request, thereby reducing the number of server-side inputs and outputs on the online path requested by the user.

[0019] The main control module includes a request management unit, a status judgment unit, an address selection unit, and an instruction generation unit. Specifically: the request management unit receives and queues user requests to obtain pending requests; the status judgment unit judges the pending requests and compensation status to obtain the current access type; the address selection unit selects the target bucket address based on the current access type, a location mapping table, a virtual access address, and a compensation access address; and the instruction generation unit generates a bucket access instruction based on the current access type and the target bucket address.

[0020] The timer module includes a period setting unit and a trigger unit, wherein the period setting unit is used to set the timing period; and the trigger unit generates a timing trigger signal according to the timing period.

[0021] The virtual access generation module includes a hierarchy selection unit and a bucket selection unit, wherein the hierarchy selection unit randomly selects a hierarchy of the tree storage structure; the bucket selection unit randomly selects a data bucket in the selected hierarchy to obtain a virtual access address.

[0022] The access compensation module includes an address recording unit, a condition judgment unit, and a status update unit, wherein: the address recording unit records the virtual access address replaced by the real access; the condition judgment unit determines whether to perform compensation based on the hierarchy of subsequent virtual accesses; and the status update unit clears the compensation status after compensation is completed.

[0023] The encryption / decryption module includes a decryption unit and an encryption unit, wherein: the decryption unit decrypts the data bucket returned by the cloud server according to the client key; the encryption unit re-encrypts the processed real data block and virtual data block to obtain an encrypted data bucket.

[0024] The background eviction module includes: a path selection unit, a data collection unit, a data placement unit, and a write-back unit, wherein: the path selection unit determines the eviction path; the data collection unit adds the real data blocks in the path data bucket to the temporary storage area; the data placement unit places the data blocks that meet the conditions into the corresponding data bucket according to the location mapping table; and the write-back unit supplements the virtual data blocks and re-encrypts and writes back the data bucket.

[0025] The storage module includes a data organization unit, a bucket addressing unit, and a read / write unit, wherein: the data organization unit stores encrypted data buckets in a complete binary tree format; the bucket addressing unit determines the target data bucket based on the bucket address; and the read / write unit reads or writes to the target data bucket according to the bucket access instruction.

[0026] like Figure 2 As shown, this embodiment relates to a privacy-preserving cloud storage method based on the above system. During the initialization phase, a timer module is set on the client side, and the timer period is denoted as... In each timed cycle, the main control module initiates an access operation to the storage module on the cloud server side. The virtual access generation module on the client side first randomly generates a virtual access request. If there is no real access request from the user in the current cycle, the virtual access request generated by the virtual access generation module is executed. If there is a real access request from the user in the current cycle, and there are no historical real access requests that have not yet been compensated, the main control module on the client side executes the real access request, replacing the virtual access request in the current timed cycle. This allows the real access request to be mixed into the continuously generated virtual access sequence, thereby hiding the time and target of the user's real access request.

[0027] The actual access requests include: read requests and write requests, wherein:

[0028] A) When a user initiates a read request, the client-side master control module queries the location mapping table based on the data block identifier to obtain the leaf number and level of the path where the target data block is located, and calculates the corresponding data bucket number. The client-side encryption / decryption module reads the data bucket from the cloud server-side storage module, decrypts it locally, locates the target data block, and returns the target data to the user. Then, the client-side master control module reallocates a new random path location for the data block and updates the location mapping table; the target data block location in the original data bucket is replaced by a virtual data block, and the remaining data is re-encrypted and written back to the cloud server.

[0029] B) When a user initiates a write request, the client-side main control module also queries the location mapping table based on the data block identifier and reads the target data bucket. The client-side encryption / decryption module decrypts the data locally and locates the target data block, then replaces the original data content with the new data submitted by the user, reallocates a new random path location for the data block, and updates the location mapping table. The written data block is temporarily stored in the temporary storage area of ​​the client-side background eviction module. The original bucket location is filled with virtual data blocks, and the processed data bucket is re-encrypted and written back to the cloud server.

[0030] The virtual access request is randomly generated by the virtual access generation module on the client side, including the virtual access level and bucket number. The virtual access does not correspond to user read / write requests; its access type is set to bucket read, and it is written back to the original data bucket after decryption and re-encryption on the client side.

[0031] C) The client-side virtual access generation module first randomly selects a level from all levels of the tree, and then randomly selects a bucket number from that level to form a virtual access address. Subsequently, the client-side encryption / decryption module reads the data bucket corresponding to this address, re-encrypts the data within the bucket, and writes it back to the original address. Because the virtual access also performs the same bucket read, encryption, and bucket write-back operations as the real access request, the behavior observed by the cloud server from the outside is consistent with the real access request.

[0032] D) When the client-side master control module waits for the next timed period, it uses the virtual access generation module to randomly generate a virtual access request. If there is no virtual access request to be compensated, it checks whether there is a real user request to be processed. If there is a real request, it queries the location mapping table and replaces the current access address with the real target bucket address. At the same time, the access compensation module records the replaced virtual access request. If there is a virtual access request to be compensated, the access compensation module determines whether the currently randomly generated virtual access level meets the compensation conditions. If it does, the master control module executes the previously recorded replacement virtual access request. Finally, the client-side master control module performs the bucket access operation according to the determined access address and returns the result to the user after the real access request is completed.

[0033] like Figure 3As shown, within any given period, the virtual access generation module on the client side generates a virtual access request according to a timer. If a real access request requiring immediate processing exists within that period, the client executes the real access request and uses the access compensation module to record the virtual access request replaced by the real access request. Let the replaced virtual access be located at level h, and the real access request be located at level h'. In subsequent timer periods, when the client generates another virtual access request at level h', the client does not execute the newly generated virtual access request but instead executes the previously recorded virtual access request at level h. After this operation, it is considered that the virtual access request replaced by the previous real access request has been compensated.

[0034] Through the aforementioned compensation mechanism, although a real access request replaces a virtual access, the system will compensate for the replacement in subsequent accesses, thus avoiding deviations in the overall access hierarchy distribution caused by real access requests. Before compensation is complete, the client will not execute new real access requests; if a new user request arrives at this time, it will be placed in a request queue for processing. This mechanism enables the system to process real requests immediately when requests are sparse, and to maintain the consistency of access distribution through queuing when requests surge.

[0035] like Figure 4 As shown, the client-side main control module sends the specified bucket address to the cloud server-side storage module. After the cloud server-side storage module returns the corresponding encrypted data bucket, the client-side encryption / decryption module decrypts the data bucket. If this is a virtual access, the client does not extract user data, but only re-encrypts the data in the bucket and writes it back to the original bucket. If this is a real access request, the client extracts the target data block according to the data block identifier and returns or updates data according to the read request or write request, respectively; at the same time, the target data block is removed from the original bucket, the original bucket is filled with virtual data blocks, and the original bucket is re-encrypted and written back to the cloud server. This process ensures that both real and virtual access requests are represented by one bucket read and one bucket write on the server side.

[0036] like Figure 5 As shown, to prevent data from remaining in the client's staging area for an extended period or causing data bucket overflow, this embodiment implements a background eviction mechanism. The eviction process proceeds along a path in the tree-like storage structure, gradually writing data blocks from the staging area back to the appropriate data buckets at their path locations. Specifically, this includes:

[0037] During eviction, the client-side background eviction module selects a leaf path and processes data level by level from the leaf node to the root node. The client-side background eviction module reads the data buckets on the current path, adds the actual data blocks to the staging area, and then determines whether the data blocks in the staging area can be written to the current data bucket based on the location mapping table. If a data block's path matches the current bucket, and the current bucket still has empty space, the data block is written to the current bucket, and the location mapping table is updated. If the current bucket is not full, virtual data blocks are used to fill it. The processed data bucket is then re-encrypted and written back to the cloud server. This process is executed periodically to maintain the stability of the data distribution in the tree-structured storage.

[0038] The client-side control module preferably caches several upper-level data buckets in a tree-structured storage architecture. Since the number of upper-level data buckets is relatively small, storing them on the client reduces the number of accesses to the cloud server. When the target data block is located in an upper-level bucket cached on the client, the client can access it directly locally without sending a request to the cloud server for the corresponding bucket. This optimization is particularly suitable for scenarios involving frequent access to hot data.

[0039] In this embodiment, the background eviction process can be executed in parallel with the actual access request process. Since this embodiment separates actual data access and obfuscation maintenance operations, as long as the eviction frequency meets system maintenance requirements, the eviction process does not need to block every actual read / write request. When a conflict occurs between the target bucket of an actual access request and the data bucket being evictioned, the client uses a mutual exclusion or waiting mechanism to ensure the atomicity of operations on the same data bucket, avoiding read / write inconsistencies.

[0040] When network latency fluctuations are small or the system needs to enhance time obfuscation capabilities, the client-side master control module makes real access requests and virtual accesses indistinguishable within a preset time window by using random delays, thus hiding the occurrence time of real access requests. Specifically, the client-side master control module sets a timing period based on the actual latency fluctuation range of the cloud storage access link and adds controlled random delays to real access requests when necessary, so that real access requests appear mixed with multiple virtual accesses within the time window observed by the server.

[0041] Based on simulation experiments using real cloud storage access trajectories, and in a single-machine environment with 16 processor cores and 32GB of memory, the conceptual prototypes of this invention, non-recursive Path ORAM, and Ring ORAM were implemented using Python, and each scheme was run on a single processor core. In the experiment, the data block size was set to 4KB, the data bucket capacity Z to 8, the tree height L to 20, the network bandwidth to 100MB / s, the network round-trip latency to 2ms, the single server input / output latency to 50μs, and the timing period to 0.25ms. Trajectory-driven simulations were performed using real access trajectories from MSRC and AliCloud. Experimental results show that under the MSRC trajectory, the average end-to-end response latency of this invention is 1.2853s, which is 39.1% and 84.5% lower than that of Ring ORAM (2.1120s) and Path ORAM (8.2768s), respectively. Under the AliCloud trajectory, the average end-to-end response latency of this invention is 2.7037s, which is 48.9% and 84.3% lower than that of Ring ORAM (5.2910s) and Path ORAM (17.1815s), respectively. In the synthetic load experiment with a tree height L of 24, the online access latency of this invention is 2.38ms, which is 74.4% and 89.7% lower than that of Ring ORAM (9.30ms) and Path ORAM (23.07ms), respectively, indicating that this invention can reduce the number of online server input / output operations and access latency.

[0042] This invention implements a privacy-preserving cloud storage system for untrusted cloud servers based on a virtual access insertion mechanism, a real access request compensation mechanism, and an encrypted bucket-based tree storage structure. In practical implementation, a client access proxy is deployed on the user side, and the storage service is deployed in the cloud. The client access proxy handles key management, location mapping maintenance, access scheduling, encryption / decryption processing, and background eviction; the cloud storage service only reads and writes encrypted data buckets based on the bucket address provided by the client.

[0043] During system initialization, the client determines the height of the tree-like storage structure, bucket capacity, and data block size based on the size of the data to be stored, and generates a symmetric key for encrypting the data blocks. The cloud server initializes a bucket-like storage area in the form of a complete binary tree, with each empty space in the bucket filled with encrypted virtual data blocks. The client also initializes a location mapping table, a temporary storage area, and a request queue to record the leaf number and level of each real data block in the tree-like storage structure.

[0044] For client read and write requests, the system executes according to the single-bucket access process described above. The client first queries the location mapping table based on the data block identifier in the user request to determine the data bucket containing the target data block. Then, it reads the encrypted data bucket from the cloud server and performs decryption, target data extraction, or data update locally. After access is complete, the client reallocates a new random path location for the accessed data block, updates the location mapping table, replaces the corresponding location in the original data bucket with a virtual data block, and finally re-encrypts the bucket and writes it back to the cloud server.

[0045] During system operation, the client continuously generates virtual access requests at fixed time intervals. If there are no real user requests, the virtual access request is executed; if a real user request exists and the compensation conditions allow, the current virtual access request is replaced with the real access request, and the replacement virtual access address is recorded. In subsequent time intervals, when the system generates a virtual access request that meets the compensation conditions, the client executes the previously recorded replacement virtual access request, thereby completing the compensation for the real access request. If a new real request arrives before the compensation is completed, the request enters the request queue to await processing.

[0046] To prevent data from accumulating in the staging area, the client periodically performs background eviction operations. Background eviction proceeds along a specified path in the tree-like storage structure, writing data blocks suitable for writing to the current bucket back to the cloud and filling the remaining space with virtual data blocks. During eviction, the client synchronously updates the location mapping table and re-encrypts the data buckets written back to the cloud. Background eviction can be performed in parallel with normal access; when both access the same data bucket, mutual exclusion control ensures the atomicity of bucket read and write operations.

[0047] In practical deployments, clients can set timing periods based on latency fluctuations in the cloud storage access chain. In scenarios where latency fluctuations are insufficient to mix real and virtual access requests, clients can add controlled random delays to real access requests. For scenarios with a large amount of hot data, clients can also cache upper-level data buckets in a tree-structured storage architecture to reduce the number of accesses to the cloud server.

[0048] Compared to existing technologies, this invention directly determines the target data bucket through a location mapping table and decouples timed virtual access, access compensation, and background eviction from real data access. This ensures that real requests access only one target data bucket during the online phase, thereby reducing the number of online server input / output operations and access latency. Experimental results show that with a tree height L of 24, the online access latency of this invention is 2.38ms, which is 74.4% and 89.7% lower than Ring ORAM and Path ORAM, respectively. Under the MSRC and AliCloud real access trajectories, the average end-to-end response latency is reduced by 39.1% and 48.9% compared to Ring ORAM, and by 84.5% and 84.3% compared to Path ORAM, respectively. What is observed on the cloud server side is a continuous bucket access sequence composed of real access requests and virtual accesses. Because all data within each bucket is encrypted, the cloud server cannot distinguish between real and virtual data blocks. Simultaneously, the access compensation mechanism reduces the bias caused by real access on the access hierarchy distribution. Under the established security model, this prevents the server from differentiating between real and virtual access based on observed physical access location, access level, and access time. This solution is suitable for file block storage, object storage, cloud database backend storage, and other outsourced data storage scenarios requiring hidden access patterns.

[0049] Compared to Path ORAM, this invention directly locates the target data bucket through a location mapping table and performs access obfuscation in the background through timed virtual access and compensation mechanisms, so that real requests usually only need to access a single data bucket, thereby reducing the server read and write overhead on the online access path.

[0050] Compared with low online bandwidth solutions such as Ring ORAM and Burst ORAM, this invention decouples real data reading from access obfuscated operations, allowing real read and write requests to directly access the target bucket, while virtual access, compensation, and eviction operations are completed in timed processes or background processes. Therefore, it is more suitable for cloud storage scenarios that are sensitive to response time.

[0051] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.

Claims

1. A privacy-preserving cloud storage system based on virtual access insertion, characterized in that, include: The system comprises a main control module, a timer module, a virtual access generation module, an access compensation module, an encryption / decryption module, and a background eviction module located on the client side, and a storage module on the cloud server side containing an encrypted bucket-style tree storage structure. Specifically: the main control module performs access scheduling based on user requests, timed trigger signals, request queues, and compensation status information to obtain data bucket access instructions; the timer module performs periodic triggering based on a preset timer period to obtain timed trigger signals; the virtual access generation module generates virtual access addresses based on tree storage structure parameters; the access compensation module determines compensation conditions based on the replaced virtual access address and subsequent virtual access addresses to obtain a compensated access address; the encryption / decryption module performs encryption / decryption based on the client key and the encrypted data bucket to obtain plaintext data blocks or re-encrypted data buckets; the background eviction module writes data blocks back based on the temporary storage area, location mapping table, and selected path to obtain updated data buckets and location mapping tables; and the storage module reads or writes encrypted data buckets based on bucket access instructions to obtain encrypted data buckets or write results. The storage module on the cloud server side uses a complete binary tree of height L to organize encrypted data blocks. The levels from the root node to the leaf nodes are numbered sequentially from 0 to L-1. Each node in the tree is a data bucket, and each data bucket contains Z storage locations. If a data bucket is not filled with real data blocks, virtual data blocks are used to fill it. Both real and virtual data blocks are encrypted by the client and written to the cloud server. Therefore, the cloud server cannot distinguish between real and virtual data blocks based solely on the ciphertext content. The m-th data bucket at level h is uniquely identified by the address (h, m), where: 0 ≤ h ≤ L-1, 0 ≤ m ≤ ... ; The main control module on the client side maintains a position mapping table. For each data block, identified by an id, the position mapping table records the corresponding path position[id] = The client queries the location mapping table based on the data block identifier (id) to obtain the bucket address (h,m) and uses this address to directly access the target data bucket, where: the bucket number of the level where the target data block resides. , The leaf is numbered, h is the level, and 0 ≤ h ≤ h. ≤ , 0≤h≤L-1.

2. The privacy-preserving cloud storage system based on virtual access insertion according to claim 1, characterized in that, The main control module includes: a request management unit, a status judgment unit, an address selection unit, and an instruction generation unit, wherein: the request management unit receives and queues user requests to obtain pending requests; the status judgment unit judges the pending requests and compensation status to obtain the current access type; the address selection unit selects the target bucket address based on the current access type, the location mapping table, the virtual access address, and the compensation access address; and the instruction generation unit generates a bucket access instruction based on the current access type and the target bucket address. When network latency fluctuations are small or the system needs to enhance time obfuscation capabilities, the client-side master control module makes real access requests and virtual accesses indistinguishable within a preset time window by using random delays, thus hiding the occurrence time of real access requests. Specifically, the client-side master control module sets a timing period based on the actual latency fluctuation range of the cloud storage access link and adds controlled random delays to real access requests when necessary, so that real access requests appear mixed with multiple virtual accesses within the time window observed by the server.

3. The privacy-preserving cloud storage system based on virtual access insertion according to claim 1, characterized in that, The virtual access generation module includes a hierarchy selection unit and a bucket selection unit, wherein the hierarchy selection unit randomly selects a hierarchy of the tree storage structure; the bucket selection unit randomly selects a data bucket in the selected hierarchy to obtain a virtual access address.

4. The privacy-preserving cloud storage system based on virtual access insertion according to claim 1, characterized in that, The access compensation module includes an address recording unit, a condition judgment unit, and a status update unit, wherein: the address recording unit records the virtual access address replaced by the real access; the condition judgment unit determines whether to perform compensation based on the hierarchy of subsequent virtual accesses; and the status update unit clears the compensation status after compensation is completed.

5. The privacy-preserving cloud storage system based on virtual access insertion according to claim 1, characterized in that, The encryption / decryption module includes a decryption unit and an encryption unit, wherein: the decryption unit decrypts the data bucket returned by the cloud server according to the client key; the encryption unit re-encrypts the processed real data block and virtual data block to obtain an encrypted data bucket.

6. The privacy-preserving cloud storage system based on virtual access insertion according to claim 1, characterized in that, The background eviction module includes: a path selection unit, a data collection unit, a data placement unit, and a write-back unit, wherein: the path selection unit determines the eviction path; the data collection unit adds the real data blocks in the path data bucket to the temporary storage area; the data placement unit places the data blocks that meet the conditions into the corresponding data bucket according to the location mapping table; and the write-back unit replenishes the virtual data blocks and re-encrypts and writes the data bucket back. During eviction, the client-side background eviction module selects a leaf path and processes it level by level from the leaf node to the root node. The client-side background eviction module reads the data buckets on the current path, adds the actual data blocks to the temporary storage area, and then determines whether the data blocks in the temporary storage area should be written to the current data bucket based on the location mapping table. If the path of a data block matches the current bucket and the current bucket still has empty space, the data block is written to the current bucket and the location mapping table is updated. If the current bucket is not full, virtual data blocks are used to fill it. The processed data bucket is re-encrypted and written back to the cloud server. This process is executed periodically to maintain the stability of the data distribution in the tree storage structure.

7. The privacy-preserving cloud storage system based on virtual access insertion according to claim 1, characterized in that, The storage module includes a data organization unit, a bucket addressing unit, and a read / write unit, wherein: the data organization unit stores encrypted data buckets in a complete binary tree format; the bucket addressing unit determines the target data bucket based on the bucket address; and the read / write unit reads or writes to the target data bucket according to the bucket access instruction.

8. A privacy-preserving cloud storage method based on the system described in any one of claims 1-7, characterized in that, During the initialization phase, a timer module is set up on the client side. In each timer period, the main control module initiates an access operation to the storage module on the cloud server side. The virtual access generation module on the client side first randomly generates a virtual access request. If there is no real access request from the user in the current period, the virtual access request generated by the virtual access generation module is executed. If there is a real access request from the user in the current period, and there are no historical real access requests that have not yet been compensated, the main control module on the client side executes the real access request, replacing the virtual access request in the current timer period. This allows the real access request to be mixed into the continuously generated virtual access sequence, thereby hiding the occurrence time and access target of the user's real access request.

9. The privacy-preserving cloud storage method according to claim 8, characterized in that, The actual access requests include: read requests and write requests, wherein: A) When a user initiates a read request, the client-side master control module queries the location mapping table based on the data block identifier to obtain the leaf number and level of the path where the target data block is located, and calculates the corresponding data bucket number. The client-side encryption / decryption module reads the data bucket from the storage module on the cloud server side, decrypts it locally, finds the target data block, and returns the target data to the user. Then, the client-side master control module reallocates a new random path location for the data block and updates the location mapping table. The target data block location in the original data bucket is replaced by a virtual data block, and the remaining data is re-encrypted and written back to the cloud server. B) When a user initiates a write request, the main control module on the client side also queries the location mapping table and reads the target data bucket based on the data block identifier. After the encryption and decryption module on the client side decrypts the data locally and finds the target data block, it replaces the original data content with the new data submitted by the user, reallocates a new random path location for the data block, and updates the location mapping table. The written data block is temporarily stored in the temporary storage area of ​​the background eviction module on the client side. The original bucket location is filled with virtual data blocks, and the processed data bucket is re-encrypted and written back to the cloud server. The virtual access request is randomly generated by the virtual access generation module on the client side, including the virtual access level and bucket number. The virtual access does not correspond to the user's read and write request. Its access type is set to bucket read and is written back to the original data bucket after the client completes decryption and re-encryption. C) The client-side virtual access generation module first randomly selects a level from all levels of the tree, and then randomly selects a bucket number from that level to form a virtual access address. Subsequently, the client-side encryption and decryption module reads the data bucket corresponding to the address, re-encrypts the data in the bucket, and writes it back to the original address. Since the virtual access also performs the same bucket reading, encryption processing, and bucket write-back operations as the real access request, the behavior observed by the cloud server from the outside is consistent with the real access request. D) When the client-side master control module waits for the next timed period, it uses the virtual access generation module to randomly generate a virtual access request. If there is no real access request to be compensated, it checks whether there is a real user request to be processed. If there is a real request, it queries the location mapping table and replaces the current access address with the real target bucket address, while recording the replaced virtual access request. If there is a real access request to be compensated, the access compensation module determines whether the currently randomly generated virtual access level meets the compensation conditions. If it does, it executes the previously recorded replacement virtual access request. Finally, the client-side master control module performs the bucket access operation according to the determined access address and returns the result to the user after the real access request is completed.

10. The privacy-preserving cloud storage method according to claim 8, characterized in that, During any given period, the virtual access generation module on the client side generates a virtual access request according to a timer. If there is a real access request that needs to be processed immediately during that period, the client executes the real access request and uses the access compensation module to record the virtual access request replaced by the real access request. Let the replaced virtual access be located at level h and the real access request be located at level h'. In subsequent timer periods, when the client generates a virtual access request at level h' again, the client does not execute the newly generated virtual access request, but instead executes the previously recorded virtual access request at level h. After this operation is completed, it is considered that the virtual access request replaced by the previous real access request has been compensated.

Images