ORAM system execution processing method, apparatus, computer equipment, and media

Abstract

This application relates to a method, apparatus, computer device, storage medium, and computer program product for executing processing in the aforementioned ORAM system. The method includes: acquiring a task request and classifying it into read operation type requests and write operation type requests; detecting whether the accessed target block is stored in a trusted region; if the accessed target block is not stored in a trusted region, classifying and scheduling the read operation type requests and write operation type requests, and accessing PosMap to determine the target path; loading all blocks in the target path from the ORAM tree in memory into the trusted region; updating the target block in the trusted region to a new leaf label; and evicting the data after the read operation and the data after the write operation, respectively. The entire scheme classifies and schedules read and write operations, avoiding the simultaneous loading of all data blocks for ORAM access, optimizing the processing flow, and achieving efficient ORAM system execution processing.

Description

Technical Field

[0001] This application relates to the field of ORAM technology, and in particular to an ORAM system execution processing method, apparatus, computer device, storage medium and computer program product. Background Technology

[0002] As cloud computing and storage become increasingly popular, the privacy of users' sensitive data has become a major issue in computing and storage outsourcing.

[0003] Ideally, users would want to "throw their encrypted data over the wall" to a cloud service without revealing any information about that data to the server. However, it is well known that encryption is insufficient for privacy. User access patterns have proven capable of revealing a great deal of information about encrypted files or private user data computed on them. Unintentional RAM (ORAM) is a cryptographic primitive that completely eliminates information leakage in memory access tracking. In an ORAM scheme, the client stores its data in encrypted and scrambled form on an untrusted server. On each access, the client reads the untrusted memory, reshuffles it, and may update some state in a trusted local storage location that becomes the client's storage.

[0004] Under ORAM, any memory access pattern is computationally indistinguishable from any other access pattern of the same length. The main obstacle to using ORAM is its large memory access overhead. For each ORAM access, many virtual blocks and data blocks are loaded along with the expected data block, resulting in poor system performance. Summary of the Invention

[0005] Therefore, it is necessary to provide an efficient ORAM system execution processing method, apparatus, computer device, computer-readable storage medium, and computer program product to address the aforementioned technical problems.

[0006] Firstly, this application provides an ORAM system execution processing method. The method includes:

[0007] Obtain task requests and classify them into read operation type requests and write operation type requests;

[0008] Detect whether the target block being accessed is stored in a trusted region;

[0009] If the target block being accessed is not stored in a trusted area, then the read operation type request and the write operation type request are classified and scheduled, and the PosMap is accessed to determine the target path (Position Map).

[0010] Load all blocks in the target path from the ORAM tree in memory into the trusted region;

[0011] Update the target block in the trusted region to the new leaf label;

[0012] Evict the data after the read operation and the data after the write operation, respectively.

[0013] In one embodiment, the ORAM system execution processing method further includes:

[0014] If the accessed target block is stored in the trusted region, then for a read operation type request, the accessed target block is read into the processor; for a write operation type request, the value of the accessed target block is updated to the trusted region.

[0015] In one embodiment, classifying and scheduling read operation type requests and write operation type requests, and accessing PosMap to determine the target path includes:

[0016] For the read operation type request, the path to the target block is determined by checking the PosMap using the address;

[0017] For the write operation type request, the path to the target block is determined by checking the PosMap using the address.

[0018] In one embodiment, loading all blocks in the target path from the ORAM tree in memory into the trusted region includes:

[0019] Return all blocks in the target path from memory;

[0020] The data is returned from memory to the XOR scheduling module for XOR processing, and the data blocks of adjacent nodes on the access path are obtained.

[0021] Decrypt the data blocks of the adjacent nodes of the access path;

[0022] The decrypted data block is stored in the trusted area.

[0023] In one embodiment, evictping data after a read operation includes: evicting read data and non-target blocks in the trusted region to the target path; evictping data after a write operation includes: evicting read data and non-target data in the trusted region to path l-2, path l-1, path l, and path l+1, where path l is the target path.

[0024] In one embodiment, the step of evicting read data and non-target blocks from the trusted region to the target path includes:

[0025] Encrypt the read data and non-target blocks in the trusted region to obtain encrypted data to be evicted;

[0026] The encrypted data to be evicted is XORed in the XOR scheduling module to form a new data block value;

[0027] The new data block value is evicted to the corresponding target path via the memory controller.

[0028] Secondly, this application also provides an ORAM system execution processing apparatus. The apparatus includes:

[0029] The task partitioning module is used to obtain task requests and divide them into read operation type requests and write operation type requests;

[0030] The detection module is used to detect whether the accessed target block is stored in a trusted area;

[0031] The access module is used to classify and schedule read operation type requests and write operation type requests when the accessed target block is not stored in the trusted area, and to access PosMap to determine the target path;

[0032] A loading module is used to load all blocks in the target path from the ORAM tree in memory into the trusted region;

[0033] The update module is used to update the target block in the trusted region to the new leaf label;

[0034] The data eviction module is used to evict data after read operations and data after write operations, respectively.

[0035] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0036] Obtain task requests and classify them into read operation type requests and write operation type requests;

[0037] Detect whether the target block being accessed is stored in a trusted region;

[0038] If the target block being accessed is not stored in a trusted region, then the read operation type requests and write operation type requests are classified and scheduled, and the PosMap is accessed to determine the target path;

[0039] Load all blocks in the target path from the ORAM tree in memory into the trusted region;

[0040] Update the target block in the trusted region to the new leaf label;

[0041] Evict the data after the read operation and the data after the write operation, respectively.

[0042] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0043] Obtain task requests and classify them into read operation type requests and write operation type requests;

[0044] Detect whether the target block being accessed is stored in a trusted region;

[0045] If the target block being accessed is not stored in a trusted region, then the read operation type requests and write operation type requests are classified and scheduled, and the PosMap is accessed to determine the target path;

[0046] Load all blocks in the target path from the ORAM tree in memory into the trusted region;

[0047] Update the target block in the trusted region to the new leaf label;

[0048] Evict the data after the read operation and the data after the write operation, respectively.

[0049] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0050] Obtain task requests and classify them into read operation type requests and write operation type requests;

[0051] Detect whether the target block being accessed is stored in a trusted region;

[0052] If the target block being accessed is not stored in a trusted region, then the read operation type requests and write operation type requests are classified and scheduled, and the PosMap is accessed to determine the target path;

[0053] Load all blocks in the target path from the ORAM tree in memory into the trusted region;

[0054] Update the target block in the trusted region to the new leaf label;

[0055] Evict the data after the read operation and the data after the write operation, respectively.

[0056] The aforementioned ORAM system execution processing method, apparatus, computer device, storage medium, and computer program product acquires task requests and classifies them into read operation type requests and write operation type requests; detects whether the accessed target block is stored in a trusted region; if the accessed target block is not stored in a trusted region, it classifies and schedules read operation type requests and write operation type requests, and accesses the PosMap to determine the target path; loads all blocks in the target path from the ORAM tree in memory into the trusted region; updates the target block in the trusted region to a new leaf label; and evicts the data after read operations and write operations, respectively. Throughout this process, the task requests are classified into read operation type requests and write operation type requests, and in subsequent processing, read operations and write operations are classified and scheduled, avoiding the simultaneous loading of all data blocks for ORAM access, thus optimizing the processing flow and achieving efficient ORAM system execution processing. Attached Figure Description

[0057] Figure 1 This is an application environment diagram of the ORAM system executing a processing method in one embodiment;

[0058] Figure 2 A schematic diagram illustrating the process of initializing the tree;

[0059] Figure 3 This is a flowchart illustrating the ORAM system's execution of a processing method in one embodiment;

[0060] Figure 4 This is a flowchart illustrating the ORAM system's execution of a processing method in another embodiment;

[0061] Figure 5 This is a diagram illustrating the data loading and processing flow.

[0062] Figure 6 This is a structural block diagram of the ORAM system execution processing device in one embodiment;

[0063] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0065] The ORAM system execution processing method provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, the user performs operations on terminal 102. Terminal 102 responds to the user's operation, obtains the task request, and classifies the task request into read operation type requests and write operation type requests; it detects whether the accessed target block is stored in a trusted region; if the accessed target block is not stored in a trusted region, it classifies and schedules the read operation type requests and write operation type requests, and accesses PosMap to determine the target path; it loads all blocks in the target path from the ORAM tree in memory into the trusted region; it updates the target block in the trusted region to a new leaf label; and it evicts the data after the read operation and the data after the write operation, respectively. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, etc.

[0066] To explain in detail the technical solution and principles of the ORAM system execution processing method of this application, some related technologies will be introduced first below.

[0067] The ORAM tree construction rules stipulate that each node contains four blocks. The first and second blocks in a node are the actual data blocks (already encrypted), and the third and fourth blocks are the XOR values ​​of the two encrypted data blocks. The XOR value in the leaf nodes of the corresponding even-numbered paths (corresponding to odd-numbered leaf labels) is the XOR value of the actual data blocks. The XOR value in the odd-numbered paths (corresponding to even-numbered leaf labels) is the dummy block value.

[0068] Detailed initialization tree construction process:

[0069] 1. The XOR value of the child node with path ID 1 is equal to the XOR of the data block value in the leaf node with the adjacent path, i.e., the value of the data block with path ID 2. For example, ... Figure 2 As shown: d2⊕d4, C2⊕C4. If the XOR value of the leaf node in the longest path in the tree (corresponding to path ID=7 in the diagram) is equal to the XOR value of the data block in the leaf node of that path with the data block value in the leaf node of the first path (corresponding to path 0 in the diagram).

[0070] 2. Traversing from the leaf node to the root node, taking path 1 as an example. The XOR value of a node in the (L-1)th level is equal to the XOR value of the actual blocks of its two child nodes. For example... Figure 2 In the formula, d0⊕d2, C0⊕C2, where d0, d2, C0, and C2 are derived from the actual data block values ​​of the two child nodes corresponding to this node. Similarly, the XOR values ​​in other nodes, excluding leaf nodes, are constructed in a similar manner.

[0071] The core idea of ​​the ORAM system execution processing method in this application is as follows:

[0072] We know that conventional computer systems, when accessing data, first prefetch data blocks from memory into a cache, and then perform corresponding operations on the data blocks in the cache, i.e., read, write / update operations. Conventional ORAM systems, however, read data blocks from untrusted memory areas into trusted stash areas, and then allow the processor to perform read and write / update operations in the stash. Therefore, the system can classify requested data operations into two categories: read operations and write operations (or update operations). This application optimizes based on the above execution flow. Because the planned operation for requesting the target block is known in advance, i.e., whether to perform a read operation or a write operation, a scheduler classifier is designed to classify these two types of planned data blocks. After scheduling, read operations will first access ORAM memory, and then perform the ORAM read operation.

[0073] In one embodiment, such as Figure 3 As shown, an ORAM system execution processing method is provided, which is applied to... Figure 1 Taking terminal 102 as an example, the explanation includes the following steps:

[0074] S100: Obtain task requests and classify them into read operation type requests and write operation type requests.

[0075] Obtain the task request to be executed by the ORAM system, and divide the task request into read operation type request and write operation type request, that is, determine whether the read operation type request or the write operation type request needs to be processed later.

[0076] S200: Detect whether the target block being accessed is stored in a trusted region.

[0077] Query the trusted region Stash to check if the target block being accessed is stored in Stash.

[0078] S300: If the target block to be accessed is not stored in the trusted area, then the read operation type request and the write operation type request are classified and scheduled, and the PosMap is accessed to determine the target path.

[0079] If the target block being accessed is not stored in a trusted area, read and write operation requests are categorized and scheduled, and the target path is determined by accessing the PosMap. Specifically, task requests are divided into two categories based on read / write (update) operations: as many read operations as possible are grouped into one category, and the other category is for write (update) operations. After categorization, read operation data requests are executed first, followed by write (update) operation data requests.

[0080] Typically, read operations check the PosMap to determine the physical location of the required data block on disk. The PosMap is a data structure that records the mapping between Logical Block Addresses (LBAs) and Physical Block Addresses (PBAs). When the target block being accessed is not stored in a trusted zone, the system categorizes and schedules read and write operations, using the PosMap to determine the target block's location on disk. Accessing the PosMap determines the path to the target block, i.e., the target path.

[0081] S400: Load all blocks in the target path from the ORAM tree in memory into the trusted region.

[0082] All blocks in the target path l are loaded from the ORAM tree in memory into the trusted area Stash. Specifically, the entire process may include the following: 1) Retrieving blocks from the ORAM tree: Accessing the ORAM tree in memory and using the ORAM access protocol to retrieve all blocks on the target path. Since ORAM is designed to hide the true access pattern, this retrieval process may involve some pseudo-random operations, such as randomizing the access order or accessing additional pseudo-random blocks. 2) Decrypting and verifying blocks: If the blocks in the ORAM tree are stored encrypted, they need to be decrypted before being loaded into the trusted area. Simultaneously, the integrity and authenticity of the blocks may need to be verified to ensure that the data has not been tampered with during transmission. 3) Loading into the trusted area: Loading the decrypted and verified blocks into the trusted area. This trusted area can be a CPU cache, a protected memory region, or a storage device protected by hardware encryption. The loading process should ensure that the data is not exposed to unauthorized observers when transmitted to the trusted area. 4) Updating the ORAM tree state: After loading the blocks into the trusted area, updating the state of the ORAM tree according to the ORAM protocol. This might include updating block positions on the path, rearranging blocks to maintain stealth, or logging which blocks have been loaded into trusted regions. 5) Processing Access Requests: Once all blocks on the target path have been loaded into trusted regions, the original access requests can be safely processed. This can include reading data, modifying data, or performing other operations without concern for data leakage or access patterns being captured by external observers. 6) Maintaining the Stealth of the ORAM Tree: Throughout the process, the stealth of the ORAM tree must always be maintained. This includes maintaining randomized access patterns when loading, processing, and writing back data, and periodically rearranging blocks in the ORAM tree to prevent pattern leakage.

[0083] S500: Update the target block in the trusted region to the new leaf label.

[0084] For trusted regions like Stash, the target blocks within the Stash also need to be updated to the new leaf label l'. This ensures that the data blocks in the Stash have the latest values ​​and leaf labels.

[0085] S600: Evicts the data after a read operation and the data after a write operation, respectively.

[0086] Eviction typically refers to the process of removing data from a storage area (such as a cache) due to resource constraints (such as insufficient memory). Eviction occurs separately for data following read operations and data following write operations.

[0087] The aforementioned ORAM system execution method involves: acquiring task requests and classifying them into read operation requests and write operation requests; detecting whether the target block to be accessed is stored in a trusted region; if the target block is not stored in a trusted region, classifying and scheduling read and write operation requests, and accessing the PosMap to determine the target path; loading all blocks in the target path from the ORAM tree in memory into the trusted region; updating the target block in the trusted region to a new leaf label; and evicting the data after read operations and write operations, respectively. Throughout this process, classifying task requests into read and write operation requests, and classifying and scheduling read and write operations in subsequent processing, avoids loading all data blocks simultaneously for ORAM access, thus optimizing the processing flow and achieving efficient ORAM system execution.

[0088] In one embodiment, the ORAM system execution processing method further includes:

[0089] If the target block being accessed is stored in the trusted region, then for read operation type requests, the target block being accessed will be read into the processor; for write operation type requests, the value of the target block being accessed will be updated into the trusted region.

[0090] Specifically, if the target block being accessed is stored in a trusted region, for both read and write operation requests, when the system receives a read operation request and the requested data block is located in a trusted region, the system will read the contents of that data block into the processor. This typically involves retrieving the data block from physical storage media (such as RAM, hard disk, etc.) and transferring it to the processor's cache or registers for subsequent processing or computation. Because these data blocks are located in a trusted region, the system may take additional measures to ensure data integrity and security during the read process, such as using encryption or verification mechanisms to verify the correctness of the data.

[0091] When the system receives a write operation request, and the data block requested is located in the trusted zone, the system updates the corresponding data block in the trusted zone with the new data value. Specifically, this includes the following steps: 1) Request Verification: The system first verifies the legality and validity of the write operation request. This may include checking the request's origin, permissions, data format, etc. 2) Data Validation: Before updating the data block, the system may validate the new data value to ensure its integrity and accuracy. This may include using checksums, hash functions, or other algorithms to verify the data's correctness. 3) Updating the Data Block: Once the request is verified and the data is verified as correct, the system writes the new data value to the corresponding data block in the trusted zone. This process needs to ensure the integrity and security of the data during the write process, which may involve mechanisms such as encryption, atomic operations, or transaction management. 4) Recording Changes: To track the data change history and provide a rollback mechanism, the system may record every write operation to the data block in the trusted zone. This can be achieved through logging, version control, or other mechanisms. 5) Notification and Synchronization: If data blocks in a trusted zone are shared by multiple systems or components, the system may need to notify other relevant parties or synchronize data in other copies after updating the data blocks.

[0092] In one embodiment, classifying and scheduling read operation type requests and write operation type requests, and accessing PosMap to determine the target path includes:

[0093] Step 1: For read operation type requests, determine the path to the target block by checking the PosMap using the address.

[0094] When processing read operation requests, the address is used to check a location map (PosMap) to determine the path to the target block. Specifically, the process includes the following steps: 1) Receiving a read operation request: The system first receives a read operation request containing the address of the data block to be read. 2) Looking up the PosMap: The PosMap is a data structure typically used to store mapping information from addresses to physical locations. This mapping information may include the actual location of the data block on the storage device, the storage device identifier, partition information, file system indexes, etc. The system searches for the corresponding mapping entry in the PosMap based on the address in the read operation request. 3) Parsing the mapping information: After finding the mapping entry, the system parses the entry to obtain the path information required to access the target block. This path information may include the path to the storage device, the mount point of the file system, the logical location of the file, etc. 4) Constructing the access path: Based on the parsed path information, the system constructs a complete access path. This path describes the specific steps or instructions to reach the target data block from the system's root directory or starting point. 5) Read the target block: Using the constructed access path, the system accesses the storage device and reads the contents of the target data block. This may involve steps such as communicating with the storage device, reading file system metadata, and parsing the internal structure of the file. 6) Return the data: Once the contents of the target data block are read, the system returns them to the application or user that initiated the read operation.

[0095] Step 2: For write operation type requests, determine the path to the target block by checking the PosMap using the address.

[0096] For write operation requests, the target address can also be used to check the PosMap to determine the path to the target block. Specifically, the process includes the following steps: 1) Receiving a write operation request: The system first receives a write operation request, which typically contains the address of the data block to be written and the new data content. 2) Looking up the PosMap: The PosMap is a data structure that stores information mapping addresses to physical locations. The system searches for the corresponding mapping entry in the PosMap based on the address in the write operation request. 3) Parsing the mapping information: Once the mapping entry is found, the system parses the entry to obtain the physical location information of the target data block. This information may include the storage device identifier, partition information, file system indexes, logical block addresses (LBAs), etc. 4) Constructing a write path: Based on the parsed physical location information, the system constructs a complete write path. This path describes the specific steps or instructions for reaching the target data block and writing to it. 5) Executing the write operation: Using the constructed write path, the system accesses the target storage device and executes the write operation. This may include steps such as communicating with the storage device, updating the file system's metadata, and modifying the file's internal structure. 6) Confirm Write: The system verifies whether the write operation was successful and may return a confirmation message to the application or user that initiated the write operation request.

[0097] In practical applications, for read operations, data requests and PosMap updates are performed as follows: The read operation request checks the PosMap using the address to determine the path of the target block, i.e., path l. If path l is even, l is incremented by 1; if l is odd, no operation is performed. Then, a new path (page label) l' is randomly generated and updated for the accessed target block, followed by subsequent data loading processing. For update (write) operations, data requests and PosMap updates are performed as follows: The write operation request checks the PosMap using the address to determine the path of the target block, i.e., path l. Then, a path l' is randomly generated and updated for the accessed target block, followed by subsequent data loading processing.

[0098] like Figure 4 As shown, in one embodiment, S400 includes:

[0099] S420: Return all blocks in the target path from memory;

[0100] S440: Returns data from memory to the XOR scheduling module for XOR processing to obtain data blocks of adjacent nodes on the access path;

[0101] S460: Decrypt the data blocks of adjacent nodes in the access path;

[0102] S480: Store the decrypted data block into a trusted area.

[0103] All blocks in the target path l are loaded from the ORAM tree in memory into the Stash. Specifically, data is returned from memory to the XOR scheduling module for XOR operation to obtain data blocks of adjacent nodes on the access path. Then, the encryption / decryption circuit module decrypts the data blocks and finally stores them in the Stash. If it is a read operation, the accessed target data block is returned to the processor; if it is an update (write) operation, the value in the Stash is updated. The specific processing flow is as follows: Figure 5 As shown.

[0104] In one embodiment, evictping data after a read operation includes: evicting read data and non-target blocks in the trusted region to the target path; evictping data after a write operation includes: evicting read data and non-target data in the trusted region to path l-2, path l-1, path l, and path l+1, where path l is the target path.

[0105] Data eviction after a read operation: When data is read from a trusted zone, this data (and possibly other non-target data) is moved to the target path. This may be to free up space in the trusted zone for other operations, or for security reasons, to prevent read data from being accessed or tampered with again. Data eviction after a write operation: When a write operation (i.e., modifying or writing new data) is performed in a trusted zone, other data (including data that may have been read before) besides the target data (i.e., the data being written) is moved to adjacent paths (such as paths l-2, l-1, l, l+1). Here, "l" represents the identifier of the target path, while l-2, l-1, and l+1 represent other paths adjacent to the target path. This strategy may be to maintain some distribution or redundancy of data, ensuring data integrity and accessibility, while reducing the impact of write operations on system performance.

[0106] Specifically, data eviction after a read operation: Data that has been read and non-target data blocks in the Stash are evicted onto path l. Specifically, first, the data block is encrypted; then, the corresponding data block undergoes an XOR operation in the XOR scheduling module to form a new data block value; finally, it is evicted onto the corresponding path l by the memory controller. Data eviction after a write (update) operation: Data that has been read and non-target data blocks in the Stash are evicted onto paths l-2, l-1, l, l+1. Here, l is an odd number, meaning the minimum value of l is 1. If l-2 < 0, then l-2 = (2... (L+1) -1); if l equals (2) (L+1) If l+1 is equal to the maximum path value, then l+1 = 0.

[0107] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0108] Based on the same inventive concept, this application also provides an ORAM system execution processing apparatus for implementing the ORAM system execution processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more ORAM system execution processing apparatus embodiments provided below can be found in the limitations of the ORAM system execution processing method described above, and will not be repeated here.

[0109] In one embodiment, such as Figure 6 As shown, an ORAM system execution processing apparatus is provided, comprising:

[0110] The task partitioning module 100 is used to obtain task requests and divide the task requests into read operation type requests and write operation type requests.

[0111] Detection module 200 is used to detect whether the accessed target block is stored in a trusted area;

[0112] Access module 300 is used to classify and schedule read operation type requests and write operation type requests when the target block being accessed is not stored in the trusted area, and to access PosMap to determine the target path;

[0113] Loading module 400 is used to load all blocks in the target path from the ORAM tree in memory into the trusted region;

[0114] Update module 500 is used to update the target block in the trusted region to the new leaf label;

[0115] The data eviction module 600 is used to evict data after read operations and data after write operations, respectively.

[0116] In one embodiment, the ORAM system execution processing apparatus further includes an update module, which is used to read the accessed target block into the processor for a read operation type request and update the value of the accessed target block into the trusted region for a write operation type request when the accessed target block is stored in the trusted region.

[0117] In one embodiment, the access module 300 is further configured to determine the path of the target block by checking the PosMap using the address for read operation type requests, and to determine the path of the target block by checking the PosMap using the address for write operation type requests.

[0118] In one embodiment, the loading module 400 is further configured to return all blocks in the target path from memory; return data from memory to the XOR scheduling module for XOR processing to obtain data blocks of adjacent nodes of the access path; decrypt the data blocks of adjacent nodes of the access path; and store the decrypted data blocks into a trusted area.

[0119] In one embodiment, the data eviction module 600 is further configured to evict read data and non-target blocks in the trusted region to the target path; and to evict read data and non-target data in the trusted region to path l-2, path l-1, path l, and path l+1, where path l is the target path.

[0120] In one embodiment, the data eviction module 600 is further configured to encrypt the data read in the trusted area and the non-target block to obtain encrypted data to be evicted; to perform an XOR operation on the encrypted data to be evicted in the XOR scheduling module to form a new data block value; and to evict the new data block value to the corresponding target path through the memory controller.

[0121] The modules in the aforementioned ORAM system execution processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware within or independently of the processor in a computer device, or stored in software within the memory of the computer device, so that the processor can invoke and execute the operations corresponding to each module.

[0122] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements an ORAM system execution processing method. The display screen can be an LCD screen or an e-ink display screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0123] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0124] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described ORAM system execution processing method.

[0125] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the above-described ORAM system execution processing method.

[0126] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described ORAM system execution processing method.

[0127] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0128] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0129] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0130] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An ORAM system execution processing method, characterized in that, The method includes: Obtain task requests and classify them into read operation type requests and write operation type requests; Detect whether the target block being accessed is stored in a trusted region; If the target block being accessed is not stored in a trusted region, then the read operation type requests and write operation type requests are classified and scheduled, and the PosMap is accessed to determine the target path; Load all blocks in the target path from the ORAM tree in memory into the trusted region; Update the target block in the trusted region to the new leaf label; Eject the data after the read operation and the data after the write operation, respectively; Evicting data after a read operation includes: evicting read data and non-target blocks from the trusted region to the target path; eviction of data after a write operation includes: evicting read data and non-target data from the trusted region to the path. l -2. Path l -1. Path l and path l +1, the path l The target path; The step of evicting read data and non-target blocks in the trusted region to the target path includes: encrypting the read data and non-target blocks in the trusted region to obtain encrypted data to be evicted; performing an XOR operation on the encrypted data to be evicted in the XOR scheduling module to form a new data block value; and evicting the new data block value to the corresponding target path through the memory controller.

2. The method according to claim 1, characterized in that, Also includes: If the accessed target block is stored in a trusted region, then for a read operation type request, the accessed target block is read into the processor; For write operation type requests, update the value of the accessed target block to the trusted region.

3. The method according to claim 1, characterized in that, The process of classifying and scheduling read and write operation requests, and determining the target path by accessing the PosMap, includes: For the read operation type request, the path to the target block is determined by checking the PosMap using the address; For the write operation type request, the path to the target block is determined by checking the PosMap using the address.

4. The method according to claim 1, characterized in that, Loading all blocks from the target path from the ORAM tree in memory into the trusted region includes: Return all blocks in the target path from memory; The data is returned from memory to the XOR scheduling module for XOR processing, and the data blocks of adjacent nodes on the access path are obtained. Decrypt the data blocks of the adjacent nodes of the access path; The decrypted data block is stored in the trusted area.

5. An ORAM system execution processing apparatus, characterized in that, The device includes: The task partitioning module is used to obtain task requests and divide them into read operation type requests and write operation type requests; The detection module is used to detect whether the accessed target block is stored in a trusted area; The access module is used to classify and schedule read operation type requests and write operation type requests when the accessed target block is not stored in the trusted area, and to access PosMap to determine the target path; A loading module is used to load all blocks in the target path from the ORAM tree in memory into the trusted region; The update module is used to update the target block in the trusted region to the new leaf label; The data eviction module is used to evict data after read operations and data after write operations, respectively. The data eviction module is further configured to encrypt the read data and non-target blocks in the trusted region to obtain encrypted data to be evictioned; perform an XOR operation on the encrypted data to be evictioned in the XOR scheduling module to form a new data block value; eviction the new data block value to the corresponding target path via the memory controller; and eviction the read data and non-target data in the trusted region to the path. l -2. Path l -1. Path l and path l +1, the path l This refers to the target path.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Images