A Variable Adaptive Oblivious Storage Method for Dynamic Workloads

Abstract

Embodiments of the present application relate to a variable and adaptive oblivious storage method for dynamic workloads. By determining the service order of each ORAM based on a planner, and responding to a user's service conversion request message, RingORAM is used as an intermediary to convert between ConcurORAM services and / or PathORAM. A two-refresh algorithm is used to refresh and store the data buckets and metadata of the data buckets in the currently accessed ORAM client, and obtain the accessed data stored in the ORAM server. This application uses three representative ORAMs (PathORAM, RingORAM, and ConcurORAM) as examples to provide a service conversion process. During the conversion process, variable ORAM can ensure the confidentiality and obliviousness of the original ORAM data without any data leakage.

Description

Technical Field

[0001] Embodiments of the present application relate to the field of storage technology, and in particular to a variable adaptive oblivious storage method for dynamic workloads. Background Art

[0002] Encrypted databases, which enable query and update operations on encrypted data without revealing the data's content, have long been the subject of extensive research and attention in academia and industry, with applications in fields such as healthcare (encrypting electronic health records) and finance (anonymous blockchain systems such as Zero Cash). Existing solutions primarily focus on improving the query performance or expanding the query capabilities of encrypted databases. Among them, oblivious random access memory (ORAM) has been widely researched and applied in the encrypted database field due to its strong security guarantees. ORAM is a technology that hides user access patterns—the frequency and type of operations performed by users accessing data—providing stronger security than data encryption.

[0003] Despite ORAM's strong security, its network communication overhead is still high for storage devices. For accessing N data blocks, the most classic PathORAM will incur O(logN) communication overhead per operation. In addition, ORAM inevitably generates nearly twice the redundant storage, which also poses a challenge to the server memory size. Such prohibitive access overhead limits the application of ORAM to a wider range of scenarios. To this end, existing research is committed to improving the ORAM system structure or using new storage devices to improve its performance. For example, RingORAM uses the computing power of the server to achieve O(1) client online overhead; PS-ORAM applies ORAM to non-volatile memory (NVM) to obtain crash consistency and better system scalability. In addition, many studies are also focused on expanding its application scenarios. For example, ConcurORAM maintains metadata on the server side for parallel access under asynchronous network; Oblix uses ORAM and Trusted Execution Environment (TEE) to build an oblivious ciphertext search system that supports dynamic updates. These ORAMs are designed for specific workloads and can serve the workloads efficiently.

[0004] However, in real life, workloads often change dynamically. Take a medical database as an example. When doctors directly access the database during routine consultations, they typically have no specific latency or throughput requirements. However, in telemedicine or disaster recovery, the database needs to process large amounts of data in real time, requiring lower latency and higher throughput. Furthermore, during daily consultations, doctors typically search for items solely by keyword, but medical analysis may require more complex query operations such as sorting, judgment, and aggregation. These workloads can be briefly summarized as: general storage to minimize maintenance costs, real-time updates to provide low latency and high throughput, and other specific functional requirements. These dynamic workloads place diverse performance and functional requirements on ORAM, which cannot be effectively met by a single ORAM.

[0005] A straightforward approach to addressing this dynamic nature is to maintain multiple ORAM instances and update all of them simultaneously upon each access. However, this results in greater access overhead and increases data redundancy and maintenance costs. Another approach is to download and rebuild ORAM during different workloads. While this approach can adapt to dynamic workloads, it also incurs significant communication overhead and can lead to prolonged service interruptions. Summary of the Invention

[0006] In view of this, an embodiment of the present application proposes a variable and adaptive oblivious storage method for dynamic workloads, which aims to ensure the original data confidentiality and obliviousness of ORAM without causing any data leakage.

[0007] To achieve the above-mentioned purpose, an embodiment of the present application provides a variable adaptive oblivious storage method for dynamic workloads, which is applied to a client of a variable ORAM, wherein the client has a planner, and the variable adaptive oblivious storage method for dynamic workloads comprises: in response to first configuration information input by a user, determining the service order of each ORAM based on the planner, wherein the ORAM represents oblivious memory, each of the ORAMs includes RingORAM, PathORAM and ConcurORAM, and each of the ORAMs has a data bucket and metadata of the data bucket, wherein the metadata of the data bucket is based on the maximum number of accesses to the data bucket. and the current number of visits; in response to the user's service conversion request message, using the RingORAM as an intermediary, performing conversion between ConcurORAM services and / or PathORAM; in response to the user's pre-access message, refreshing the first data bucket and the metadata of the first data bucket in the currently accessed ORAM client based on the refresh algorithm, obtaining the metadata of the second data bucket and the second data bucket; in response to the user's access request message, obtaining the accessed data stored in the ORAM server, refreshing the second data bucket and the metadata of the second data bucket based on the refresh algorithm, and obtaining the third data bucket and the metadata of the third data bucket.

[0008] Optionally, before performing the conversion between ConcurORAM services and / or PathORAM services using RingORAM as an intermediary in response to the user's service conversion request message, the variable adaptive oblivious storage method for dynamic workloads further includes: generating an encrypted database in response to the content information input by the user, and sending the encrypted database to the server of the variable ORAM.

[0009] Optionally, each ORAM has a client, a server, a server API, and a client API. In response to the user's service conversion request message, the RingORAM is used as an intermediary to complete the conversion between the ConcurORAM service and / or the PathORAM service, including: encrypting and processing the local cache data, and using virtual blocks to fill the local cache data to obtain first synchronization metadata, uploading the first synchronization metadata to the ConcurORAM server, and using the ConcurORAM client API to download the first synchronization metadata and the second synchronization metadata, and restoring the local cache data based on the first synchronization metadata and the second synchronization metadata, respectively switching the ConcurORAM server API, the client API, and the data structure to the RingORAM server API, the client API, and the metadata of the data bucket to complete the conversion of the ConcurORAM service to the RingORAM service; respectively switching the RingORAM server API, the client API, and the data structure to the PathORAM server API, the client API, and the metadata of the data bucket to complete the conversion of the RingORAM service to the PathORAM service.

[0010] Optionally, in response to the user's pre-access message, refreshing the first data bucket and the metadata of the first data bucket in the currently accessed ORAM client based on the refresh algorithm to obtain the metadata of the second data bucket and the second data bucket includes: obtaining the refresh mode of the currently accessed ORAM based on the user's pre-access message, wherein the refresh mode includes a periodic refresh mode and an immediate refresh mode; if it is the periodic refresh mode, traversing the data buckets in the ORAM, determining the data buckets that meet the refresh conditions, and setting the metadata of the data buckets that meet the conditions to the initial value, and the expression of the initial value of the metadata of the data bucket is;

[0011] RecordMap[bid]=(0,lim b )

[0012] Among them, lim bRepresents the maximum number of accesses to a data bucket in a base ORAM client, where the base ORAM is RingORAM, bid represents a data bucket in the ORAM client, and RecordMap represents metadata of the data bucket in the ORAM client; if the previously accessed ORAM is in immediate refresh mode, no operation is performed; the metadata values ​​of all the data buckets that meet the refresh condition are updated from (cnt, lim) to (cnt+1, min(lim, lim′)) to obtain metadata of the second data bucket and the second data bucket, where lim′ represents the maximum number of accesses to the data bucket before the refresh.

[0013] Optionally, in response to the user's access request message, the accessed data stored in the ORAM server is obtained, the second data bucket and the metadata of the second data bucket are refreshed based on the refresh algorithm, and the third data bucket and the metadata of the third data bucket are obtained, including: traversing all the second data buckets, if the currently accessed ORAM is in periodic refresh mode, the metadata of all the second data buckets are reset to the initial value, if the currently accessed ORAM is in instant refresh mode, the metadata of the second data bucket is reset to (1, 1), and the second data bucket after the metadata is reset is obtained, and the second data bucket after the metadata is reset is traversed again, if the currently accessed ORAM is in periodic refresh mode, each second data bucket after the metadata is reset is reset to the initial value again, if the currently accessed ORAM is in instant access mode, no operation is performed.

[0014] Optionally, the determining the service order of each ORAM based on the planner in response to the first configuration information input by the user includes: determining the server-side monetary cost based on the planner in response to the first configuration information input by the user, wherein the server-side monetary cost includes communication cost, server-side computing cost and server-side storage cost, and the first configuration information is the client workload order; determining the server-side parameters of the variable ORAM based on the server-side monetary cost; determining the first overhead model and the second overhead model of the client based on the server-side parameters of the variable ORAM; determining the minimum monetary cost of the client of each ORAM based on the first overhead model and the second overhead model of the client; and determining the service order of each ORAM based on the minimum monetary cost.

[0015] Optionally, determining the first and second overhead models of the client based on the server parameters of the variable ORAM includes: determining the first overhead model based on the server parameters and data capacity parameters of the variable ORAM, wherein the expression of the first overhead model is:

[0016]

[0017] Among them, op represents the client operation, which can represent the query operation of a certain ORAM or the conversion operation between any two ORAMs. Lop represents the client operation delay, C cpu represents the computing capacity of the client, C down Indicates the client's download capacity, C up Indicates the client's upload capacity, n cpu Indicates the number of CPU cores on the server, P cpu Indicates the processing speed of a single CPU core on the server, P down Indicates the download speed of the server, P up Indicates the upload speed of the server, L net Indicates the network delay of the server, L IO represents the hardware delay of the server; based on the preset batch queue size and the delay of the client, the expression of the second overhead model is determined as:

[0018]

[0019] Among them, X op Indicates the client throughput, and BatchSize indicates the client batch queue size.

[0020] Optionally, after determining the service order of each ORAM based on the server currency and the client overhead, the variable adaptive oblivious storage method for dynamic workloads further includes: determining the parameters of each ORAM based on the planner in response to the second configuration information input by the user.

[0021] Optionally, determining the parameters of each ORAM based on the planner in response to the second configuration information input by the user includes: obtaining a data bucket size of each ORAM, a data block size in the data bucket, and a size of a data set to be stored; and determining a first bandwidth expansion parameter and a second bandwidth expansion parameter of the parameters of each ORAM based on the data bucket size, the data block size, and the size of the data set to be stored.

[0022] Optionally, determining a first bandwidth expansion parameter and a second bandwidth expansion parameter of each ORAM parameter based on the size of the data bucket, the size of the data block, and the size of the data set to be stored includes: determining a size relationship between the data volume of the data set to be stored and the data volume of the data block; if the data volume of the data set to be stored is smaller than the data volume of the data block, calculating the first bandwidth expansion parameter of each ORAM using a first formula, the first formula being:

[0023]

[0024] Wherein, Z represents the size of the data bucket, B represents the size of the data block, F represents the size of the data set to be stored in each ORAM, and M represents the total size of the data set to be stored. If the amount of data in the data set to be stored is greater than the amount of data in the data block, the second bandwidth expansion parameter of each ORAM is calculated using the second formula, which is:

[0025]

[0026] Here, Z represents the size of the data bucket, B represents the size of the data block, and M represents the total size of the data set to be stored.

[0027] To achieve the above objectives, an embodiment of the present application further provides a variable adaptive oblivious storage method for dynamic workloads.

[0028] The embodiment of the present application proposes a variable adaptive oblivious storage method for dynamic workloads. In response to first configuration information input by the user, the service order of each ORAM is determined based on a planner. ORAM stands for oblivious memory. Each ORAM includes RingORAM, PathORAM, and ConcurORAM. Each ORAM has a data bucket and metadata of the data bucket. The metadata of the data bucket is determined based on the maximum access count and the current access count of the data bucket. In response to the user's service conversion request message, the RingORAM is used as an intermediary to perform conversion between ConcurORAM services and / or PathORAM. In response to the user's pre-access message, the first data bucket and metadata of the first data bucket in the currently accessed ORAM client are refreshed based on a refresh algorithm to obtain the second data bucket and metadata of the second data bucket. In response to the user's access request message, the accessed data stored in the ORAM server is obtained. The metadata of the second data bucket and the second data bucket in the ORAM client are refreshed based on the refresh algorithm to obtain the third data bucket and metadata of the third data bucket. The present invention first designs a variable ORAM. Variable ORAM can efficiently convert between different ORAM services. This paper identifies two potential leakage risks during the conversion process. Using three representative ORAMs (PathORAM, RingORAM, and ConcurORAM) as examples, it presents a service conversion process. Finally, it provides a planner suitable for a variety of application scenarios. Mutable ORAM has undergone rigorous security verification and can maintain the inherent data confidentiality and inadvertence of ORAM, while preventing any data leakage during the conversion process. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1is a flow chart of a variable adaptive oblivious storage method for dynamic workloads provided in one embodiment of the present application;

[0030] Figure 2 This is a message flow diagram of a variable and adaptive oblivious storage method for dynamic workloads provided in one embodiment of the present application;

[0031] Figure 3 This is an OST principle diagram of a variable adaptive oblivious storage method for dynamic workloads provided in one embodiment of the present application. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, each embodiment of the present application will be described in detail below with reference to the accompanying drawings. However, it will be understood by those skilled in the art that in each embodiment of the present application, many technical details are proposed to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical solutions claimed in the present application can be implemented. The division of the following embodiments is for convenience of description and should not constitute any limitation on the specific implementation of the present application. The various embodiments can be combined and referenced with each other under the premise of no contradiction.

[0033] One embodiment of the present application proposes a variable, adaptive, oblivious storage method for dynamic workloads, which is applied to an electronic device, where the electronic device can be a terminal or a server. This embodiment and the following embodiments are described using a server as an example. The implementation details of the variable, adaptive, oblivious storage method for dynamic workloads proposed in this embodiment are described below. The following content is provided solely for ease of understanding and is not essential for implementing this solution.

[0034] This method is a variable and adaptive oblivious storage method for dynamic workloads, involving research fields such as memory (usually random access memory, RAM), oblivious RAM (Oblivious RAM, ORAM) and encrypted database (Encrypted Database), especially applying ORAM to dynamic workloads (Dynamic Workload).

[0035] Encrypted databases, which enable query and update operations on encrypted data without revealing the data's content, have long been the subject of extensive research and attention in academia and industry, with applications in fields such as healthcare (encrypting electronic health records) and finance (anonymous blockchain systems such as Zero Cash). Existing solutions primarily focus on improving the query performance or expanding the query capabilities of encrypted databases. Among them, oblivious random access memory (ORAM) has been widely researched and applied in the encrypted database field due to its strong security guarantees. ORAM is a technology that hides user access patterns—the frequency and type of operations performed by users accessing data—providing stronger security than data encryption.

[0036] In real life, workloads often change dynamically. Take a medical database as an example. When doctors directly access the database during routine consultations, they typically have no specific latency or throughput requirements. However, in telemedicine or disaster recovery, the database needs to process large amounts of data in real time, requiring lower latency and higher throughput. Furthermore, during routine consultations, doctors typically search for items solely by keyword, but medical analysis may require more complex query operations such as sorting, judgment, and aggregation. These workloads can be briefly summarized as: general storage to minimize maintenance costs, real-time updates to provide low latency and high throughput, and other specific functional requirements. These dynamic workloads place diverse performance and functional requirements on ORAM, which cannot be effectively met by a single ORAM.

[0037] A straightforward approach to addressing this dynamic nature is to maintain multiple ORAM instances and update all of them simultaneously upon each access. However, this results in greater access overhead and increases data redundancy and maintenance costs. Another approach is to download and rebuild ORAM during different workloads. While this approach can adapt to dynamic workloads, it also incurs significant communication overhead and can lead to prolonged service interruptions.

[0038] To address the above-mentioned issues, the present invention first designs a variable and adaptive ORAM framework (Versatile ORAM Framework, V-ORAM). V-ORAM can efficiently convert between different ORAM services. Secondly, the present invention discovers two potential leakage risks during the conversion process and proposes an ORAM Service Transformation (OST) protocol. The OST protocol can complete the conversion between ORAMs with a constant overhead that is independent of the total amount of ORAM data while ensuring security. The present invention uses three representative ORAMs (PathORAM, RingORAM, and ConcurORAM) as examples to provide a specific conversion process. Finally, the present invention provides a planner that can model the user's monetary cost and ORAM system performance. The planner is applicable to a variety of application scenarios, for example, selecting the appropriate and most cost-effective ORAM based on the user's system performance requirements, adjusting the server configuration based on performance requirements, and selecting the optimal ORAM parameters based on the user's data set.

[0039] Some important terms in this invention are explained:

[0040] Oblivious random access memory: As the core content of the present invention, the present invention first briefly introduces the operation process of ORAM using PathORAM as an example. In PathORAM, the client maintains the encrypted data block (size) in a data bucket, each data bucket contains Z data blocks, and then maintains the data bucket as a full binary tree and stores it on the server. Each data block is mapped to the path of the binary tree (the path refers to all data buckets from a leaf node to the root node). When the client accesses a data block, it first reads the entire path where the data block is located and saves all data blocks in the local cache (Stash). The data blocks in the Stash are then re-encrypted, scrambled, and written back to the binary tree on the server side. This operation is called refresh (Eviction). PathORAM randomly maps the accessed data block to a new path after each access. In this way, the server will not be able to infer the accessed block based on the client's access operation.

[0041] RingORAM Basic Process: RingORAM is an ORAM that utilizes server-side computation. It maintains user-reproducible virtual blocks within data buckets. Each access uses the virtual block to perform an XOR operation with the target block, requiring only a single data block to be transmitted, achieving O(1) online communication overhead. Furthermore, to maintain constant overhead, RingORAM changes its refresh operation to a periodic one, performing a refresh every A operations.

[0042] ConcurORAM Basic Process: ConcurORAM is an asynchronous ORAM architecture with batch processing. It supports a maximum of c concurrent accesses. It maintains metadata for synchronization on the server, primarily including StashSet and DRLogSet. StashSet contains c entries, each of which is an encrypted stash generated by an access, called TempStash. TempStash contains up to MasStashSize encrypted data blocks and at least c virtual blocks. DRLogSet, used to record the results of each access, contains c data entries and c virtual blocks.

[0043] Virtual Blocks and Metadata: Some ORAMs maintain virtual blocks within data buckets. These virtual blocks are used for ORAM access operations. Each virtual block is initially marked as valid and invalidated after being accessed once. Each virtual block can only be accessed once; repeated accesses will result in data leaks. Additionally, ORAMs require metadata to track the validity and location of virtual blocks. Both RingORAM and ConcurORAM maintain both virtual blocks and metadata.

[0044] Instant Refresh and Periodic Refresh: Different ORAMs have different refresh operations. In this paper, the type that refreshes on every access is called Instant Refresh, such as PathORAM. The type that refreshes after a certain number of accesses is called Periodic Refresh, such as RingORAM and ConcurORAM. Periodic Refresh typically maintains the aforementioned virtual blocks for periodic refreshes, while Instant Refresh only accesses and refreshes real blocks.

[0045] The specific process of the variable adaptive oblivious storage method for dynamic workloads proposed in this embodiment can be as follows: Figure 1 As shown, reference Figure 1 , the method is applied to a client of a variable ORAM, the client having a planner, and the storage method may include:

[0046] S10. In response to first configuration information input by a user, determine a service order of each ORAM based on a planner, where ORAM stands for Oblivious Memory, and each ORAM includes RingORAM, PathORAM, and ConcurORAM. Each ORAM has a data bucket and metadata of the data bucket, where the metadata of the data bucket is determined based on a maximum access count and a current access count of the data bucket.

[0047] S20. In response to the user's service conversion request message, use RingORAM as an intermediary to convert between ConcurORAM services and / or PathORAM services.

[0048] In an embodiment of the present invention, before step S20, the variable adaptive oblivious storage method for dynamic workloads may further include the following specific execution process:

[0049] S01. Generate an encrypted database in response to content information input by a user, and use a planner to send the encrypted database to a server end of a variable ORAM.

[0050] Specifically, this step involves the client of the variable ORAM sending data to the server of the variable ORAM. This step is performed by the planner in the client of the variable ORAM. The planner generates an ORAM-based encrypted database based on the client input and uploads the database to the server of the variable ORAM. At the same time, the client locally generates the client and API of each ORAM, and the server of the variable ORAM generates the server and API of each ORAM accordingly. Each ORAM maintains the necessary state on both the client and the server.

[0051] When the user wants to switch the service type, he sends a conversion request to the OST module, which converts the API and status of each ORAM.

[0052] The present invention designs an efficient ORAM service conversion protocol. First, it is unrealistic to design a conversion protocol between any two ORAMs. Therefore, to reduce the design difficulty of the OST protocol, the present invention selects a special ORAM as the conversion intermediary, called base ORAM. During the conversion, any ORAM is first converted to base ORAM, and then converted from base ORAM to target ORAM. As a result, OST only needs to design a set of conversion protocols for each ORAM. The conversion protocol is divided into two stages: metadata preparation and API switching. The present invention uses RingORAM as the conversion intermediary and provides a conversion algorithm for ConcurORAM and PathORAM.

[0053] As before, each ORAM has a client, a server, a server API, and a client API.

[0054] In an embodiment of the present invention, step S20 may include the following specific execution process:

[0055] S21. Encrypt the local cached data, fill the local cached data with virtual blocks to obtain first synchronization metadata, upload the first synchronization metadata to the ConcurORAM server, use the ConcurORAM client API to download the first synchronization metadata and the second synchronization metadata, and restore the local cached data based on the first synchronization metadata and the second synchronization metadata. Switch the ConcurORAM server API, client API, and data structure to RingORAM's server API, client API, and data bucket metadata, respectively, to complete the conversion of the ConcurORAM service to the RingORAM service.

[0056] The client of Variable ORAM first encrypts the Stash (local cache) locally, and then fills the local cache with virtual blocks to obtain TempStash, that is, obtains the first synchronization metadata. Then upload TempStash to the server of ConcurORAM to obtain the second synchronization metadata, where the second synchronization metadata can include the latest TempStash and DRLogSet. The client of ConcurORAM can restore Stash based on the second synchronization metadata. Here, the client only needs the latest TempStash because if the entire StashSet is restored, the refreshed blocks will be added to the Stash again, causing the size of the Stash to increase uncontrollably. The DRLogSet needs to be traversed in its entirety to avoid missing previous data blocks. Finally, the client and server of ConcurORAM replace the API and start the RingORAM service.

[0057] S22: Switch the RingORAM server API, client API, and data structure to the PathORAM server API, client API, and data bucket metadata, completing the conversion from the RingORAM service to the PathORAM service.

[0058] The service conversion between RingORAM and PathORAM does not involve server-side metadata, so there is no need to process metadata like ConcurORAM does. Simply switch the API. However, because RingORAM maintains virtual blocks in the bucket, while PathORAM does not. Therefore, the ORAM service conversion protocol (OST) also needs to handle the bucket size of PathORAM during access. A straightforward solution is to retrieve the entire bucket along with the virtual blocks and then write the same number of new virtual blocks back to the bucket. While safe and feasible, this method doubles PathORAM's access overhead because the number of virtual blocks is typically similar to that of real blocks. OST would like to maintain PathORAM's original bucket size, that is, access only real data blocks. However, this access method allows the server to detect virtual blocks in the bucket, thereby leaking the client's access pattern in subsequent accesses. Therefore, OST needs to additionally handle the leakage issues that exist during the conversion process.

[0059] The present invention points out two types of leakage in the conversion process and provides an efficient solution, namely the OST protocol. The OST protocol solves the leakage problem in the service conversion process through a data structure RecordMap and a refresh algorithm EvictRecord.

[0060] Specifically, the leakage problems existing in the conversion process include leakage 1 and leakage 2. Among them, leakage 1 (repeated access to invalid virtual blocks): Figure 2 As shown in Figure 2, when switching between two different ORAMs with periodic refresh cycles, for example, RingORAM and ConcurORAM, if the metadata corresponding to each ORAM is brute-force deleted and the metadata is regenerated for the subsequent ORAM, the subsequent ORAM will be unable to detect previously accessed virtual blocks, which will cause invalid virtual blocks to be accessed again, resulting in information leakage. Therefore, the metadata of the virtual blocks must be inherited.

[0061] Leak 2 (virtual block location leak): Figure 2 As shown in , when switching between two ORAMs with periodic refresh and immediate refresh, such as RingORAM and PathORAM, the server can immediately detect that the remaining blocks are virtual blocks after the access. These virtual blocks will leak if subsequently accessed by periodic refresh. This leak persists even if the metadata of the virtual blocks is inherited. Therefore, buckets accessed by immediate refresh must be flushed before periodic refresh access.

[0062] S30. In response to the user's pre-access message, refresh the first data bucket and the metadata of the first data bucket in the currently accessed ORAM client based on the refresh algorithm to obtain the second data bucket and the metadata of the second data bucket. In response to the user's access request message, obtain the accessed data stored in the ORAM server, refresh the metadata of the second data bucket and the second data bucket based on the refresh algorithm to obtain the third data bucket and the metadata of the third data bucket.

[0063] In order to prevent the above-mentioned leakage while achieving efficient ORAM service conversion, that is, conversion between different ORAMs, the present invention designs a cross-ORAM data structure RecordMap to record the access status of data buckets. Each data bucket is mapped to a pair of metadata (cnt, lim), where cnt represents the number of accesses to the current bucket and lim represents the maximum safe access number of the current bucket. Whenever the number of accesses to a bucket reaches the maximum safe access number, the data bucket needs to be refreshed in time. For this purpose, the present invention designs a corresponding block refresh method EvictRecord.

[0064] In an embodiment of the present invention, step S30 may include the following execution process:

[0065] S31. Based on the user's pre-access message, obtain a refresh mode of the currently accessed ORAM, where the refresh mode includes a periodic refresh mode and an immediate refresh mode;

[0066] S32. If the currently accessed ORAM is in periodic refresh mode, traverse the data buckets in the ORAM to determine the data buckets that meet the refresh conditions, and set the metadata of the data buckets that meet the conditions as the initial value. The expression of the initial value of the metadata of the data bucket is:

[0067] RecordMap[bid]=(0,lim b )

[0068] Among them, lim b Indicates the maximum number of accesses to a data bucket in the base ORAM client. Base ORAM represents RingORAM, bid represents a data bucket in the ORAM client, and RecordMap represents metadata about the data bucket in the ORAM client.

[0069] S33: If the currently accessed ORAM is in the immediate refresh mode, no operation is performed;

[0070] S34. Traverse the data buckets in ORAM again, and update the metadata values ​​of all data buckets that meet the refresh conditions from (cnt, lim) to (cnt+1, min(lim, lim′)) to obtain the second data bucket and the metadata of the second data bucket, where lim′ represents the maximum number of accesses to the data bucket before refresh.

[0071] In an embodiment of the present invention, step S30 may further include the following execution process:

[0072] S35. Traverse all second data buckets. If the currently accessed ORAM is in periodic refresh mode, reset the metadata of all second data buckets to the initial value. If the currently accessed ORAM is in immediate refresh mode, reset the metadata of the second data bucket to (1, 1), and obtain the second data bucket after resetting the metadata.

[0073] S36. Traverse the second data bucket after resetting the metadata again. If the currently accessed ORAM is in periodic refresh mode, reset each second data bucket after resetting the metadata to the initial value again. If the currently accessed ORAM is in immediate access mode, do nothing.

[0074] It should be noted that when OST performs ORAM service conversion, V-ORAM will inherit the RecordMap of each ORAM and the metadata of the virtual block, regardless of whether the current ORAM is refreshed immediately or periodically.

[0075] In an embodiment of the present invention, before step S20, the variable adaptive oblivious storage method for dynamic workloads may further include the following specific execution process:

[0076] S02. In response to first configuration information input by a user, determine a server-side monetary cost based on a planner, wherein the server-side monetary cost includes a communication cost, a server-side computing cost, and a server-side storage cost, and the first configuration information is a client workload order;

[0077] S03, determining server-side parameters of the variable ORAM based on the server-side monetary cost;

[0078] The planner of the present invention utilizes a given data set, client workload sequence, minimum throughput (X sys ) and maximum delay (L sys ) to estimate the optimal ORAM parameters, server configuration, and ORAM service order. The planner's assumptions about ORAM are simplified as follows: server configuration and monetary cost, that is, the monetary cost of the server includes communication (traffic billing or bandwidth billing), computing (CPU core number n cpu ) and storage (data volume). Assuming network and hardware delay (L net and L IO ) is constant, the processing speed of a single core (P cpu ) are also constant and averaged based on the specific workload. Download and upload speeds (P down and P up) is also constant. The client overhead is determined by the price of the cloud server. It should be noted that the server parameters of variable ORAM can include data volume, number of CPU cores n cpu , L net , L IO 、P down and P up .

[0079] S04, determining a first cost model and a second cost model of the client based on the server parameters of the variable ORAM;

[0080] S05. Determine the minimum monetary cost of each ORAM client based on the first cost model and the second cost model of the client;

[0081] Specifically, step S05 may include the following execution process:

[0082] S051. Determine a first overhead model based on the server parameters and data capacity parameters of the variable ORAM, wherein the expression of the first overhead model is:

[0083]

[0084] Among them, op represents the client operation, which can represent the query operation of a certain ORAM or the conversion operation between any two ORAMs. Lop represents the client operation delay, C cpu represents the computing capacity of the client, C down Indicates the client's download capacity, C up Indicates the client's upload capacity, P cpu Indicates the number of CPU cores on the server, n cpu Indicates the processing speed of a single CPU core on the server, P down Indicates the download speed of the server, P up Indicates the upload speed of the server, L net Indicates the network delay of the server, L IO Indicates the hardware delay of the server;

[0085] S052. Based on the preset batch queue size and the client's delay, determine the expression of the second overhead model as follows:

[0086]

[0087] Among them, X op Indicates the client throughput, and BatchSize indicates the client batch queue size.

[0088] S06. Determine the service order of each ORAM based on the minimum monetary cost.

[0089] Specifically, after step S06, the variable adaptive oblivious storage method for dynamic workloads may further include the following execution process:

[0090] S07 . In response to the second configuration information input by the user, determine the parameters of each ORAM based on the planner.

[0091] Specifically, step S06 may include the following execution process:

[0092] S071. Obtain the size of each ORAM data bucket, the size of the data block in the data bucket, and the size of the data set to be stored;

[0093] S072: Determine a first bandwidth expansion parameter and a second bandwidth expansion parameter of each ORAM based on the size of the data bucket, the size of the data block, and the size of the data set to be stored.

[0094] Step S072 may include the following execution process:

[0095] S071. Determine the relationship between the data volume of the data set to be stored and the data volume of the data block;

[0096] S0722: If the data volume of the data set to be stored is smaller than the data volume of the data block, a first bandwidth expansion parameter of each ORAM is calculated using a first formula. The first formula is:

[0097]

[0098] Wherein, Z represents the size of the data bucket, B represents the size of the data block, F represents the size of the data set to be stored in each ORAM, M represents the total size of the data set to be stored, and X represents the first bandwidth expansion parameter;

[0099] S073. If the data volume of the data set to be stored is greater than the data volume of the data block, a second bandwidth expansion parameter of each ORAM is calculated using a second formula. The second formula is:

[0100]

[0101] Wherein, Z represents the size of the data bucket, B represents the size of the data block, M represents the total size of the data set to be stored, and represents the second bandwidth expansion parameter.

[0102] Specifically, the planner mainly selects the bucket size Z and the data size B, while other parameters follow the security constraints of ORAM. We assume that Z and B are determined by the client before deployment and remain unchanged throughout the V-ORAM process. For different file sizes F in practice, for example, image files at the MB level and text files at the KB level. Different file sizes require opposite parameter settings. Taking the commonly used indicator bandwidth expansion (the ratio of the amount of transmitted data to the request block size) of PathORAM as an example, for a dataset with a total data volume of M, when F<B, the expansion is It decreases as B increases; when F>B, it expands to It increases with B. Therefore, there is an optimal parameter setting based on the client file size distribution and ORAM sequence.

[0103] In summary, the present invention is a variable adaptive oblivious storage method for dynamic workloads. First, a variable ORAM framework V-ORAM is designed to abstract the specific operations of ORAM. Secondly, the OST conversion protocol is given, and the specific conversion process is given by taking PathORAM, RingORAM and ConcurORAM as examples. The conversion overhead of OST is at a constant level and is only related to the system security parameters and the parameters selected by the ORAM itself, but not to the number of data blocks in the ORAM. In addition, the present invention points out the two types of leakage in the conversion process, and designs RecordMap and EvictRecord to generate only O(1) additional overhead to the original ORAM while ensuring security. Finally, in order to assist the client in making better decisions, the present invention provides a planner to assist the client in making decisions in various issues such as V-ORAM deployment, conversion and parameter selection. V-ORAM has been formally proven to be secure and can ensure the original data confidentiality and obliviousness of ORAM, and no data leakage will occur during the conversion process.

[0104] Those skilled in the art will appreciate that the above embodiments are specific embodiments for implementing the present application, and that in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present application.

Claims

1. A variable adaptive oblivious storage method for dynamic workloads, characterized in that: A method for a client of a variable ORAM having a planner includes: In response to first configuration information input by a user, determining a service order of each ORAM based on the planner, wherein the ORAM stands for Oblivious Memory, each ORAM includes a RingORAM, a PathORAM, and a ConcurORAM, each ORAM has a data bucket and metadata of the data bucket, and the metadata of the data bucket is determined based on a maximum access count and a current access count of the data bucket; In response to the user's service conversion request message, using RingORAM as an intermediary, convert between ConcurORAM services and / or PathORAM services; In response to a pre-access message from the user, refreshing a first data bucket and metadata of the first data bucket in the currently accessed ORAM client based on a refresh algorithm to obtain a second data bucket and metadata of the second data bucket; in response to an access request message from the user, obtaining accessed data stored in the ORAM server, refreshing the second data bucket and metadata of the second data bucket based on the refresh algorithm to obtain a third data bucket and metadata of the third data bucket; The method of refreshing the first data bucket and metadata of the first data bucket in the currently accessed ORAM client based on the refresh algorithm in response to the user's pre-access message to obtain the second data bucket and metadata of the second data bucket includes: Based on the pre-access message of the user, obtaining a refresh mode of the currently accessed ORAM, wherein the refresh mode includes a periodic refresh mode and an immediate refresh mode; If the previously accessed ORAM is in periodic refresh mode, traverse the data buckets in the ORAM, determine the data buckets that meet the refresh conditions, and set the metadata of the data buckets that meet the conditions as initial values. The expression for the initial value of the metadata of the data bucket is: in, Indicates the maximum number of accesses to a data bucket in the base ORAM client, where the base ORAM is RingORAM. Represents a data bucket in the ORAM client. Represents the metadata of a data bucket in the ORAM client; If the currently accessed ORAM is in immediate refresh mode, no operation is performed; Traverse the data buckets in the ORAM again and update the metadata values ​​of all the data buckets that meet the refresh conditions from Updated to , get the second data bucket and the metadata of the second data bucket, where, Indicates the maximum number of accesses to the bucket before refreshing; in, Indicates the number of visits to the current bucket. Indicates the maximum number of secure accesses to the current bucket.

2. The variable adaptive oblivious storage method for dynamic workloads according to claim 1, characterized in that: Before performing the conversion between ConcurORAM and / or PathORAM using RingORAM as an intermediary in response to the user's service conversion request message, the method further includes: An encrypted database is generated in response to the content information input by the user, and the encrypted database is sent to a server of the variable ORAM using the planner.

3. The variable adaptive oblivious storage method for dynamic workloads according to claim 1, characterized in that: Each ORAM has a client, a server, a server API, and a client API. In response to the user's service conversion request message, the RingORAM is used as an intermediary to complete the conversion between ConcurORAM services and / or PathORAM services, including: Encrypting the local cached data, filling the local cached data with virtual blocks to obtain first synchronization metadata, uploading the first synchronization metadata to the ConcurORAM server, and downloading the first synchronization metadata and the second synchronization metadata using the ConcurORAM client API, and restoring the local cached data based on the first synchronization metadata and the second synchronization metadata, respectively switching the ConcurORAM server API, the client API, and the data structure to the RingORAM server API, the client API, and the metadata of the data bucket, thereby completing the conversion from the ConcurORAM service to the RingORAM service; The server API, the client API, and the data structure of the RingORAM are respectively switched to the server API, the client API, and the metadata of the data bucket of the PathORAM, thereby completing the conversion of the RingORAM service to the PathORAM service.

4. The variable adaptive oblivious storage method for dynamic workloads according to claim 1, characterized in that: The step of obtaining the accessed data stored in the ORAM server in response to the user's access request message, refreshing the second data bucket and the metadata of the second data bucket based on the refresh algorithm, and obtaining the third data bucket and the metadata of the third data bucket includes: Traverse all the second data buckets. If the currently accessed ORAM is in periodic refresh mode, reset the metadata of all the second data buckets to the initial value. If the ORAM previously accessed is in immediate refresh mode, the metadata of the second data bucket is reset to (1, 1), and the second data bucket after the metadata is reset is obtained; Traverse the second data bucket after resetting the metadata again. If the currently accessed ORAM is in periodic refresh mode, reset each second data bucket after resetting the metadata to the initial value again. If the currently accessed ORAM is in immediate access mode, do nothing.

5. The variable adaptive oblivious storage method for dynamic workloads according to claim 1, characterized in that: The determining, in response to the first configuration information input by the user, a service order of each ORAM based on the planner, comprises: In response to first configuration information input by the user, determining a server-side monetary cost based on the planner, wherein the server-side monetary cost includes a communication cost, a server-side computation cost, and a server-side storage cost, wherein the first configuration information is a client workload order; determining a server-side parameter of the variable ORAM based on the server-side monetary cost; Determining a first cost model and a second cost model of the client based on the server parameters of the variable ORAM; Determining a minimum monetary cost for each client of the ORAM based on the first cost model and the second cost model of the client; A service order of each of the ORAMs is determined based on the minimum monetary cost.

6. The variable adaptive oblivious storage method for dynamic workloads according to claim 5, characterized in that: The determining of the first and second cost models of the client based on the server parameters of the variable ORAM includes: The first overhead model is determined based on the server parameters and data capacity parameters of the variable ORAM, wherein the expression of the first overhead model is: in, Indicates client operations. Client operations can represent query operations of a certain ORAM or conversion operations between any two ORAMs. Lop Indicates client operation delay, Indicates the computing capacity of the client, Indicates the client's download capacity, Indicates the client's upload capacity, Indicates the number of CPU cores on the server side. Indicates the processing speed of a single CPU core on the server side. Indicates the download speed of the server. Indicates the upload speed of the server. Indicates the network delay on the server side, Indicates the hardware delay of the server; Based on the preset batch queue size and the client's delay, the expression for determining the second overhead model is: in, X op Indicates the client throughput, Indicates the batch queue size for the client.

7. The variable adaptive oblivious storage method for dynamic workloads according to claim 5, characterized in that: After determining the service order of each ORAM based on the server currency and the client cost, the method further includes: In response to the second configuration information input by the user, parameters of each of the ORAMs are determined based on the planner.

8. The variable adaptive oblivious storage method for dynamic workloads according to claim 7, characterized in that: The determining, based on the planner and in response to the second configuration information input by the user, parameters of each of the ORAMs, comprises: Obtaining the size of each ORAM data bucket, the size of the data block in the data bucket, and the size of the data set to be stored; A first bandwidth expansion parameter and a second bandwidth expansion parameter of each ORAM parameter are determined based on the size of the data bucket, the size of the data block, and the size of the data set to be stored.

9. The variable adaptive oblivious storage method for dynamic workloads according to claim 8, characterized in that: The determining of the first bandwidth expansion parameter and the second bandwidth expansion parameter of each ORAM parameter based on the size of the data bucket, the size of the data block, and the size of the data set to be stored includes: Determining the relationship between the data volume of the to-be-stored data set and the data volume of the data block; If the data volume of the data set to be stored is smaller than the data volume of the data block, a first bandwidth expansion parameter of each ORAM is calculated using a first formula, where the first formula is: X = in, Z Indicates the size of the data bucket, B Indicates the size of the data block, Indicates the size of the data set to be stored in each ORAM, Indicates the total size of the data set to be stored, X represents the first bandwidth expansion parameter; If the data volume of the data set to be stored is greater than the data volume of the data block, a second bandwidth expansion parameter of each ORAM is calculated using a second formula, where the second formula is: Y = in, Z Indicates the size of the data bucket, B Indicates the size of the data block, Indicates the total size of the data set to be stored, Y represents the second bandwidth expansion parameter.

Images