An efficient hybrid oram-based side-channel defense method

Abstract

The application provides a high-efficiency hybrid ORAM-based side channel defense method, which is a high-efficiency hybrid ORAM-based method for protecting an access mode and resisting a side channel attack in cloud computing, and comprises a code-involuntary access stage and a data-involuntary access stage; is divided into an ORAM tree filling stage, a target block request stage, a target block execution stage and a data block write-back stage, the method can hide the access mode of program execution in a TEE and realizes obfuscated computation of the program. The security provided by the TEE is used to optimize the ORAM memory operation, the sensitive data structure in the ORAM access process is hidden by using an involuntary reading operation, so that the access mode is effectively hidden, and in addition, different ORAM schemes are used according to the access characteristics of data and code, so that the overall efficiency of the scheme is effectively improved.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, specifically relating to an efficient side-channel defense method based on hybrid ORAM. Background Technology

[0002] With the rapid development of cloud computing, an increasing number of computing tasks are being handled by cloud servers and controlled by cloud platforms, seriously impacting user privacy and security. Homomorphic encryption technology enables data to be processed in an encrypted state, providing a certain level of security for user privacy. However, encrypting data only guarantees the privacy of input / output data; the user's access patterns to data and code (i.e., the sequence of accesses to code and data addresses during program execution) remain exposed to the cloud server, potentially leading to the leakage of a large amount of user privacy information. Therefore, an effective technology is needed to hide access patterns during program execution and obfuscate computation.

[0003] An Oblivious Random Access Machine (ORAM) effectively hides the correspondence between user access behavior and access targets by constructing appropriate storage structures and access mechanisms, making it a secure access mechanism for concealing user access intentions. ORAM is currently the primary means of hiding user access patterns. ORAM can effectively protect the following four attributes: (1) the location of the access target block; (2) the order of target block requests; (3) the frequency of access to the same target block; and (4) the specific read / write access method. This prevents attackers from distinguishing between any two access sequences of the same length based on the access pattern after the access is complete.

[0004] Trusted Execution Environment (TEE) technology can establish secure computing regions within a computer, providing hardware-level security isolation and protection for internal code and data. Implementing ORAM-based obfuscated computing schemes in commercial hardware TEEs can effectively improve the versatility of the solution. However, existing commercial TEE technologies (such as ARM TrustZone and Intel SGX) suffer from side-channel attack vulnerabilities. Attackers can exploit these attacks to obtain data access patterns within the TEE and thus infer users' private information. In existing research, solutions like Obliviate and ZeroTrace hide file or data access patterns on top of ORAM, but do not protect code access patterns. OBFUSCURO is a hardware-software hybrid solution combining SGX and ORAM technologies to resist access pattern leakage. It is currently the most comprehensive defense against side-channel attacks, but its high-frequency data and code access by ORAM leads to significant communication and time overhead, resulting in low performance. Furthermore, the solution does not differentiate between code and data characteristics. Therefore, implementing an efficient side-channel defense method based on hybrid ORAM is essential. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes an efficient side-channel defense method based on hybrid ORAM. This method provides an efficient protection access mode and defense against side-channel attacks in cloud computing based on hybrid ORAM, comprising: an unintentional code access phase and an unintentional data access phase. The unintentional code access phase includes a code ORAM tree filling phase, a code block request phase, and a code block execution phase. The unintentional data access phase includes a data ORAM tree filling phase, a data block request phase, a data block execution phase, and a data block write-back phase.

[0006] The code ORAM tree filling stage is used to fill code blocks into the ORAM tree and use inadvertent read operations to update the table entries in the Address Translation Table and Position Map corresponding to the code blocks;

[0007] The code block request phase is used to convert the code block address requested by the source program into the leaf node label corresponding to the code block by querying the Address Translation Table and Position Map, and to obtain the target code block by accessing the path corresponding to the leaf node.

[0008] The code block execution phase is used to read the target code block into a 64B memory space for code execution.

[0009] The data ORAM tree filling stage is used to fill data blocks into the ORAM tree and use inadvertent read operations to update the table entries in the Address Translation Table and Position Map corresponding to the code blocks;

[0010] The data block request phase is used to convert the address of the data block requested by the source program into the subtree and leaf node label corresponding to the data block by querying the Address Translation Table and Position Map, and to obtain the target data block by accessing the path corresponding to the leaf node.

[0011] The data block execution phase is used to read the target data block into a 64B memory for data read and write operations;

[0012] The data block write-back phase is used to write the data blocks stored in the Stash back to the ORAM binary tree.

[0013] The code ORAM tree filling phase includes:

[0014] Step 1.1.1: Select the block to be added to the ORAM tree, use the RDRAND hardware instruction to randomly generate a leaf node leaf_id, fill the code block into the node corresponding to the path of the leaf node, and from the leaf node to the root node, find an empty position in the bucket and store the code block.

[0015] Step 1.1.2: Based on the location where the code block is stored, the ORAM controller updates the mapping between the virtual address and physical address of the code block in the Address Translation Table; an inadvertent read operation is used to update the Address Translation Table, hiding the mapping between table entries and code blocks; the Position Map stores the mapping between code blocks and leaf nodes;

[0016] Step 1.1.3: Repeat steps 1.1.1 to 1.1.2 until all code blocks are filled into the ORAM tree.

[0017] The code block request phase includes:

[0018] Step 1.2.1: The source program sends a code block request R1 = (op_r, index, address) to the code ORAM controller, where op_r indicates that the request type is a read operation, index indicates the unique index of the requested code block, and address indicates the virtual address of the target code block;

[0019] Step 1.2.2: The ORAM controller uses an inadvertent read operation to access the Address Translation Table and obtain the physical address corresponding to the virtual address in R1; at the same time, the ORAM controller uses an inadvertent read operation to query the PositionMap and obtain the corresponding leaf tag leaf_id based on the physical address of the target code block;

[0020] Step 1.2.3: After obtaining the value of the corresponding leaf node `leaf_id`, a unique path P(l) can be determined in the binary tree. Then, the code ORAM controller uses the metadata information stored in each bucket of the binary tree to determine whether the requested block is in that bucket and its offset within the bucket. If the requested code block is not in the bucket, a randomly selected unread block with a valid value of 1 is retrieved from that bucket. If the requested code block is in the bucket, the requested block is retrieved. Finally, a total of [number missing] blocks are retrieved from all buckets of path P(l). Each code block retrieves the block and stores it in a register in the ORAM controller. N represents the number of nodes in the binary tree.

[0021] The code block execution phase includes:

[0022] Step 1.3.1: The source program performs processing operations on the code block in the code access module; since the module's location in memory is fixed, the source program's access mode will always be displayed at a fixed location, which can effectively hide the access mode of the code block;

[0023] Step 1.3.2: After completing the current operation, the source program sends the next code block request R2 = (op_r, index, address) to the ORAM controller.

[0024] The data ORAM tree filling stage includes:

[0025] Step 2.1.1: Select the block to be added to the ORAM tree, use the RDRAND hardware instruction to randomly generate a leaf node leaf_id and a subtree position part_id, fill the data block into the node corresponding to the leaf node of the part_id subtree, from the leaf node to the root node, find the free position in the bucket and store the code block.

[0026] Step 2.1.2: Based on the location where the data block is stored, the ORAM controller updates the mapping between the virtual address and physical address of the data block to the Address Translation Table; an inadvertent read operation is used to update the Address Translation Table, hiding the mapping between table entries and data blocks; the Position Map stores the mapping between data blocks, leaf nodes, and subtrees;

[0027] Step 2.1.3: Repeat steps 2.1.1 to 2.1.2 until all data blocks are filled into the ORAM tree.

[0028] The data block request phase includes:

[0029] Step 2.2.1: The source program sends a data block request Q1 = (op, index, address) to the data ORAM controller, where op represents the type of request, including two types: data read operation op_r and data write-back operation op_w; index represents the unique index of the requested data block; and address represents the virtual address of the target data block.

[0030] Step 2.2.2: The ORAM controller uses an inadvertent read operation to access the Address Translation Table and obtain the physical address corresponding to the virtual address in Q1; at the same time, the ORAM controller uses an inadvertent read operation to query the PositionMap and obtain the corresponding subtree label part_id and leaf label leaf_id based on the physical address of the target data block;

[0031] Step 2.2.3: After obtaining the corresponding subtree label `part_id` and leaf node `leaf_id` values, a subtree and a path `P(l)` within that subtree can be uniquely identified in the binary tree. Then, the data ORAM controller uses the metadata stored in each bucket of the binary tree to determine whether the requested block is in that bucket and its offset within the bucket. If the requested code block is not in the bucket, a randomly selected unread block with a valid value of 1 is retrieved. If the requested code block is in the bucket, the requested block is retrieved. Finally, a total of [number] blocks are retrieved from all buckets of path `P(l)`. Each data block is retrieved and stored in a Stash array within the ORAM controller.

[0032] To ensure the security of data blocks, all data blocks in the ORAM tree can only be accessed once, and the valid field of the metadata in the bucket will be set to 0 for data that has been accessed.

[0033] The data block execution phase includes:

[0034] Step 2.3.1: During the ORAM tree data block execution phase, an inadvertent read operation is used to retrieve the target data block into a 64B memory space for data read and write operations; after the operation is completed, the next data block request is sent to the ORAM controller.

[0035] Step 2.3.2: The source program performs read and write operations on a 64B data block in memory. It does not need to start from the beginning of this memory during execution; it allows offset-based access.

[0036] Step 2.3.3: After completing the current operation, the source program sends a request for the next data block, Q2 = (op, index, address), to the ORAM controller. It's also important to note that the execution of each code block requires access to a data block.

[0037] The data block write-back phase includes:

[0038] Step 2.4.1: Stash stores the data blocks read from the binary tree subtree each time. Retrieving A data points from the binary tree and storing them in Stash requires one data write-back; specifically:

[0039] For each real data block, a leaf node is randomly assigned again and the values ​​of Address TranslationTable and Position Map are updated. Then, the Z+S blocks in Stash are written back to the buckets in the subtree using a reverse lexicographical strategy, where S represents the number of fake blocks stored in the bucket.

[0040] During write-back, Z blocks (containing all remaining real blocks and some fake blocks) are taken from each bucket along a path in the subtree and put into the Stash;

[0041] Step 2.4.2: For the metadata information in the bucket, when accessing the data block, the data ORAM controller will first check the metadata information of the bucket on the access path P(l). If the count value in the metadata is greater than S+Y, then the path needs to be written back. If the count value is less than S+Y, then dummy blocks can continue to be obtained from the bucket. Y represents the number of dummy blocks that can be treated as real blocks in each bucket.

[0042] At this point, the data block write-back phase ends, and the ORAM controller will perform the next data block read operation based on request Q.

[0043] Furthermore, the ORAM controller uses an inadvertent read operation. Specifically, the ORAM controller compares the virtual address of the target block in requests R1 and Q1 with the virtual address of each entry in the Address Translation Table. Based on the comparison result, it determines whether to perform a real value retrieval operation to obtain the corresponding physical address. After the ORAM controller completes the inadvertent read operation on all entries, only the value in the entry with the same virtual address as R1 and Q1 is actually retrieved. Externally, it can only be observed that the ORAM controller performed the same access operation on each entry.

[0044] The beneficial effects of this invention are:

[0045] This invention proposes a highly efficient side-channel defense method based on hybrid ORAM, which fully utilizes the security features of TEE and reduces unnecessary access overhead. Furthermore, this method differentiates between data and code access characteristics, utilizing different ORAMs to improve scheme performance based on their respective characteristics. Specifically, this invention has the following advantages:

[0046] (1) By hiding the access mode, it can resist most of the side-channel attacks of SGX and has comprehensive attack resistance.

[0047] (2) Utilize the security guarantees provided by TEE to optimize ORAM memory access operations and reduce computational overhead;

[0048] (3) To address the characteristics of code access, an improved Ring ORAM without virtual blocks is used, and register-based inadvertent read operations are used to eliminate the Stash data structure, thereby reducing memory overhead and communication overhead for data transmission.

[0049] (4) For the characteristics of data access, a compact block ORAM scheme is used to divide a large tree into several subtrees, which reduces the amount of data read when reading the path, reduces communication overhead and client memory size, and improves memory utilization by using a compact ORAM structure. Attached Figure Description

[0050] Figure 1 This is a flowchart of the method described in this invention.

[0051] Figure 2 This is a schematic diagram of the method described in this invention.

[0052] Figure 3 This is a flowchart of the ORAM tree filling process in this invention.

[0053] Figure 4 This is a flowchart of the target block request phase in this invention.

[0054] Figure 5 This is a flowchart of the target block execution phase in this invention.

[0055] Figure 6 This is a flowchart of the data block write-back stage in this invention.

[0056] Figure 7 These are three ORAM structure diagrams in this invention, where (a) is a block ORAM structure diagram, (b) is a Ring ORAM structure diagram, and (c) is a compact ORAM structure diagram. Detailed Implementation

[0057] The invention will be further explained below with reference to the accompanying drawings and specific implementation examples.

[0058] This invention provides a highly efficient side-channel defense method based on hybrid ORAM. This method can hide the access patterns of program execution in a TEE (Transmission Equipment) and achieve obfuscated computation. The method optimizes ORAM memory access operations by leveraging the security guarantees provided by the TEE, using unintentional read operations to hide sensitive data structures during ORAM access, thereby effectively concealing its access patterns. Furthermore, different ORAM schemes are used for data and code access characteristics, effectively improving the overall efficiency of the solution.

[0059] The work of this invention includes three common phases and a data block write-back phase, such as Figure 1-2 As shown, these are the ORAM tree filling phase, the target (i.e., data or code) block request phase, the target (i.e., data or code) block execution phase, and the data block write-back phase, respectively.

[0060] The symbols and terms used in this invention are explained as follows: Z: The number of blocks that can be stored in a bucket; A: The number of times data can be read; after A reads, a data block write-back operation is required; S: The number of dummy blocks stored in a bucket; Y: The number of dummy blocks that can be treated as real blocks in each bucket; N: The number of nodes in the binary tree;

[0061] ORAM Tree (ORAM Storage Module): This storage module stores user blocks in the form of a complete binary tree. Let the number of nodes in this complete binary tree be N, then the depth of the tree is Log N (base 2). The nodes of the tree are also called buckets, and each bucket contains Z blocks of the same size. In the data binary tree, the number of actual data blocks cannot exceed 1 / 2*(N+1)*Z; the rest are virtual data blocks. In the code ORMA tree, the entire binary tree is used to store actual code blocks; for example... Figure 7 The diagram shows three ORAM structures.

[0062] Address Translation Table (ATC): This table records the mapping between the virtual and physical addresses of blocks accessed by a program. The number of entries in the ATC is the same as the number of actual blocks.

[0063] Position Map: In the code ORAM controller, this array stores the mapping between code blocks and leaf nodes in the ORAM tree. In the data ORAM controller, this array stores the subtree containing the data and its corresponding leaf nodes. This mapping is randomly assigned during ORAM tree filling, and the path represented by a leaf node must contain the node containing the target block. The number of entries in the position map is the same as the number of actual data blocks.

[0064] ORAM Controller: Used to implement ORAM-related operations, including ORAM tree filling, ORAM tree reading and writing back, Position Map querying and updating, etc.

[0065] Metadata information: Stored in each bucket of the binary tree, it includes information such as the count of the bucket being visited, the validity of the data in the bucket, and the offset of the data. The size of the metadata information is usually much smaller than the block size.

[0066] Inadvertent Read Operation Based on CMOV: Inadvertent read operations can be used to hide access patterns. This invention uses the unconditional branch instruction CMOV under the x86 architecture to implement an inadvertent read operation. Specifically, the input parameters of the CMOV instruction are a condition code, a source operand, and a destination operand. If the condition is true, the instruction copies the source operand to the address of the destination operand; otherwise, it does not assign a value. Since both the source and destination operands are fetched and stored in registers during the execution of this instruction, the attacker sees the same access pattern regardless of whether the assignment is successful or not.

[0067] 1. Unintentional code access phase

[0068] 1.1 Code ORAM Tree Filling Stage

[0069] During the ORAM tree code block population phase, the ORAM controller is responsible for populating the code blocks into the ORAM tree and updating the corresponding entries in the Address Translation Table and Position Map using inadvertent read operations. This phase is executed only once during the ORAM tree initialization process. The specific execution steps are as follows:

[0070] Step 1.1.1: Select the block to be added to the ORAM tree and randomly generate a leaf node (leaf_id) using the RDRAND hardware instruction. Fill the nodes in the corresponding path of the leaf node with the code block. From the leaf node to the root node, find an empty position in the bucket and store the code block.

[0071] Step 1.1.2: Based on the location where the code block is stored, the ORAM controller updates the mapping between the virtual address and physical address of the code block in the Address Translation Table; an inadvertent read operation is used to update the Address Translation Table, hiding the mapping between table entries and code blocks; the Position Map stores the mapping between code blocks and leaf nodes. It includes multiple entries, each of which is a key-value pair, representing the unique index value of the data block and its corresponding leaf node, represented as follows:<index,leaf_id> .

[0072] Step 1.1.3: Repeat the above steps until all code blocks are filled into the ORAM tree.

[0073] 1.2 Code Block Request Phase

[0074] During the ORAM tree code block reading phase, the ORAM controller converts the code block address requested by the source program into the leaf node label corresponding to the code block by querying the Address Translation Table and Position Map, and obtains the target code block by accessing the path corresponding to the leaf node; specifically, the following operations are performed:

[0075] Step 1.2.1: The source program sends a code block request R1 = (op_r, index, address) to the code ORAM controller, where op_r indicates that the request type is a read operation, index indicates the unique index of the requested code block, and address indicates the virtual address of the target code block.

[0076] Step 1.2.2: The ORAM controller uses an inadvertent read operation to access the Address Translation Table and obtain the physical address corresponding to the virtual address in R1; at the same time, the ORAM controller uses an inadvertent read operation to query the PositionMap and obtain the corresponding leaf tag leaf_id based on the physical address of the target code block;

[0077] Step 1.2.3: After obtaining the value of the corresponding leaf node `leaf_id`, a unique path P(l) can be determined in the binary tree. Then, the code ORAM controller uses the metadata information stored in each bucket of the binary tree to determine whether the requested block is in that bucket and its offset within the bucket. If the requested code block is not in the bucket, a randomly selected unread block with a `valid` value of 1 is retrieved from that bucket. If the block is in the bucket, the requested block is retrieved. Finally, a total of [number missing] blocks are retrieved from all buckets of path P(l). Each code block stores the retrieved block in a register in the ORAM controller.

[0078] 1.3 Code Block Execution Phase

[0079] During the ORAM tree code block execution phase, the target code block is retrieved using an unintentional read operation. Figure 1 The processing operation is performed in the code access module; after the operation is completed, the next code block request is sent to the ORAM controller; specifically, the following operations are performed:

[0080] Step 1.3.1: The source program performs processing operations on the code block in the code access module; since the module's location in memory is fixed, the source program's access mode will always be displayed at a fixed location, which can effectively hide the access mode of the code block;

[0081] Step 1.3.2: After completing the current operation, the source program sends the next code block request R2 = (op_r, index, address) to the ORAM controller.

[0082] 2. Unintentional data access phase

[0083] 2.1 Data ORAM Tree Filling Stage

[0084] The process of filling the data ORAM tree is basically the same as that of filling the code ORAM tree. The difference lies in the Position Map array. Each entry in the Position Map still stores the correspondence between blocks and leaf nodes, but after using block ORAM, the subtree position where the block is located needs to be added to the entry, specifically represented as follows:<index,leaf_id,part_id> .

[0085] The data ORAM tree filling stage includes:

[0086] Step 2.1.1: Select the block to be added to the ORAM tree, use the RDRAND hardware instruction to randomly generate a leaf node leaf_id and a subtree position part_id, fill the data block into the node corresponding to the leaf node of the part_id subtree, from the leaf node to the root node, find the free position in the bucket and store the code block.

[0087] Step 2.1.2: Based on the location where the data block is stored, the ORAM controller updates the mapping between the virtual address and physical address of the data block to the Address Translation Table; an inadvertent read operation is used to update the Address Translation Table, hiding the mapping between table entries and data blocks; the Position Map stores the mapping between data blocks, leaf nodes, and subtrees;

[0088] Step 2.1.3: Repeat steps 2.1.1 to 2.1.2 until all data blocks are filled into the ORAM tree.

[0089] 2.2 Data Block Request Phase

[0090] During the ORAM tree data block reading phase, the ORAM controller translates the data block address requested by the source program into the subtree and leaf node labels corresponding to the data block by querying the Address Translation Table and Position Map, and obtains the target data block by accessing the path corresponding to the leaf node; specifically, the following operations are performed:

[0091] Step 2.2.1: The source program sends a data block request Q1 = (op, index, address) to the data ORAM controller, where op represents the request type, including two types: data read operation op_r and data write-back operation op_w. index represents the unique index of the requested data block, and address represents the virtual address of the target data block.

[0092] Step 2.2.2: The ORAM controller uses an inadvertent read operation to access the Address Translation Table and obtain the physical address corresponding to the virtual address in Q1; at the same time, the ORAM controller uses an inadvertent read operation to query the PositionMap and obtain the corresponding subtree label part_id and leaf label leaf_id based on the physical address of the target data block;

[0093] Step 2.2.3: After obtaining the corresponding subtree label `part_id` and leaf node `leaf_id` values, a subtree and a path `P(l)` within that subtree can be uniquely identified in the binary tree. Then, the data ORAM controller uses the metadata stored in each bucket of the binary tree to determine whether the requested block is in that bucket and its offset within the bucket. If the requested code block is not in the bucket, a randomly selected unread block with a `valid` value of 1 is retrieved from that bucket. If the block is in the bucket, the requested block is retrieved. Finally, a total of [number missing] blocks are retrieved from all buckets of path `P(l)`. Each data block is retrieved and stored in a Stash array within the ORAM controller. Furthermore, to ensure data block security, each data block in the ORAM tree can only be accessed once; the metadata valid field of accessed data will be set to 0.

[0094] 2.3 Data Block Execution Phase

[0095] The execution of data blocks is essentially the same as the execution of code blocks. It's important to note that the execution of each code block requires access to a data block. Data block execution does not need to begin at the start of the data access module; it allows for offset-based access.

[0096] The data block execution phase includes:

[0097] Step 2.3.1: During the ORAM tree data block execution phase, an inadvertent read operation is used to retrieve the target data block into a 64B memory space for data read and write operations; after the operation is completed, the next data block request is sent to the ORAM controller.

[0098] Step 2.3.2: The source program performs read and write operations on the data block in 64B memory. It does not need to start from the beginning of the memory during execution, and it allows offset-based access.

[0099] Step 2.3.3: After completing the current operation, the source program sends a request for the next data block, Q2 = (op, index, address), to the ORAM controller. It's also important to note that the execution of each code block requires access to a data block.

[0100] 2.4 Data Block Write-back Phase

[0101] Because the Stash memory size in the data ORAM controller is limited, it is necessary to write the data blocks stored in the Stash back to the ORAM binary tree. Another purpose of writing back the data is to update the content of the data blocks. The data block write-back phase of this scheme includes two steps: writing back the Stash data blocks and updating the metadata information in the bucket.

[0102] Step 2.4.1: For Stash, it stores data blocks read from the binary tree subtree each time. For every A accesses (i.e., A data entries are retrieved from the binary tree and stored in Stash), a data write-back is required. During the write-back, Z blocks (containing all remaining real blocks and some dummy blocks) are retrieved from each bucket along a path in the subtree and placed into Stash. Before the write-back, a leaf node needs to be randomly assigned to each real data block again, and the values ​​of the AddressTranslation Table and Position Map need to be updated. Then, a reverse lexicographical strategy is used to write Z+S blocks from Stash back to the buckets in the subtree.

[0103] Step 2.4.2: Regarding the metadata information in the buckets, during data block access, the data ORAM controller first checks the metadata information of the buckets on the access path P(l). If the count value in the metadata is greater than S+Y, the path needs to be written back to initialize the metadata. If the count value is less than S+Y, a dummy block can continue to be retrieved from the bucket. The purpose of this step is to ensure that the access process can safely read only one block from each bucket.

[0104] At this point, the data block write-back phase ends, and the ORAM controller will perform the next data block read operation based on request Q.

[0105] In the above steps, the ORAM controller uses an inadvertent read operation. Specifically, the ORAM controller compares the virtual address of the target block in requests R1 and Q1 with the virtual address of each entry in the Address Translation Table. Based on the comparison result, it determines whether to perform a real value retrieval operation to obtain the corresponding physical address. After the ORAM controller completes the inadvertent read operation on all entries, only the value in the entry with the same virtual address as R1 and Q1 is actually retrieved. Externally, it can only be observed that the ORAM controller performs the same access operation on each entry.

[0106] Figure 3 This is a flowchart of ORAM tree filling. According to... Figure 3 As shown in the process, the ORAM controller accepts a new block T. d_p If the block is a code block, a leaf node `leaf_id` is randomly assigned as the filling path. If it is a data block, a leaf node `leaf_id` and a subtree position `part_id` are randomly assigned. During filling, if it is a data block, the subtree position needs to be found first. Then, the ORAM controller performs checks from `leaf_id` towards the root node. If an empty node is encountered, the T... d_p If it's a code block, the ORAM controller doesn't need to search the subtree; it can directly find an empty location in the path to store it. Then, the ORAM controller, based on T... d_p Based on the current physical address and path information, update the contents of the Address TranslationTable and Position Map arrays.

[0107] Figure 4 This is a flowchart of the target block request. According to... Figure 4The process is as follows: The ORAM controller first receives a code block request R1 = (op_r, index, address) or a data block request Q1 = (op, index, address) from the source program, and checks the data block request (e.g., write operations to code blocks will be rejected). After the check, the ORAM controller first accesses the Address Translation Table array, comparing the address in request Q1 or R1 with the address v-address stored in the Address Translation Table, and extracts the successfully matched elements. This access to the Address Translation Table is also implemented using an inadvertent read operation, so the outside world is unaware of which element in the Address Translation Table has been read. Then, the ORAM controller accesses the PositionMap; if it is a data block, it obtains the corresponding part_id and leaf_id; if it is a code block, it only obtains the leaf_id. Similarly, this process is also implemented using an inadvertent read operation. The above process implements the translation from the virtual address of the target block to the path in the ORAM tree. After obtaining the leaf_id, the ORAM controller retrieves the nodes on the leaf_id path based on the metadata information to obtain the target block. Finally, the ORAM controller extracts the data block into the Stash, and if it is code, it extracts the code block into a register.

[0108] Figure 5 This is a flowchart of the target block execution. After the ORAM controller acquires the target block, it will provide feedback to the source program. Upon receiving the feedback, the source program will perform the corresponding operations on the target block. Afterward, the source program will send the next block request to the ORAM controller.

[0109] Figure 6 This is a flowchart of the ORAM Tree data block write-back process. According to... Figure 6 The process shown requires checking whether the access count is A or whether the metadata information count in the path to be accessed is greater than S+Y before proceeding to the next data block access. If the access count is greater than A or the count value is greater than S+Y, a data block write-back operation is required.

[0110] First, for accesses greater than A times, a path in a subtree needs to be randomly selected and Z blocks (including real blocks and some fake blocks) are taken from that path and put into the Stash. Then, the ORAM controller randomly assigns a leaf node as its new path for the real data in the Stash and updates the Address Translation Table and Position Map arrays. Finally, the Z+S blocks in the Stash are written back to the buckets in the subtree using a reverse lexicographical strategy.

[0111] Secondly, if the count value is greater than S+Y, the metadata information for that path needs to be reinitialized, the path retrieved back to the Stash, and then written back using the steps described above after initializing the metadata information. After completing the write-back operation, the ORAM controller will continue to execute the next round of data requests.

Claims

1. A highly efficient side-channel defense method based on hybrid ORAM, characterized in that, include: The system comprises an unintentional code access phase and an unintentional data access phase; the unintentional code access phase includes a code ORAM tree filling phase, a code block request phase, and a code block execution phase; the unintentional data access phase includes a data ORAM tree filling phase, a data block request phase, a data block execution phase, and a data block write-back phase. The code ORAM tree filling stage is used to fill code blocks into the ORAM tree and use inadvertent read operations to update the table entries in the Address Translation Table and Position Map corresponding to the code blocks; The code block request phase is used to convert the code block address requested by the source program into the leaf node label corresponding to the code block by querying the Address Translation Table and Position Map, and to obtain the target code block by accessing the path corresponding to the leaf node. The code block execution phase is used to read the target code block into a 64B memory space for code execution. The data ORAM tree filling stage is used to fill data blocks into the ORAM tree and use inadvertent read operations to update the table entries in the Address Translation Table and Position Map corresponding to the code blocks; The data block request phase is used to convert the address of the data block requested by the source program into the subtree and leaf node label corresponding to the data block by querying the Address Translation Table and Position Map, and to obtain the target data block by accessing the path corresponding to the leaf node. The data block execution phase is used to read the target data block into a 64B memory for data read and write operations; The data block write-back phase is used to write the data blocks stored in the Stash back to the ORAM binary tree; The code ORAM tree filling phase includes: Step 1.1.1: Select the block to be added to the ORAM tree, use the RDRAND hardware instruction to randomly generate a leaf node leaf_id, fill the code block into the node corresponding to the path of the leaf node, and from the leaf node to the root node, find an empty position in the bucket and store the code block. Step 1.1.2: Based on the location where the code block is stored, the ORAM controller updates the mapping between the virtual address and physical address of the code block in the Address Translation Table; an inadvertent read operation is used to update the Address Translation Table, hiding the mapping between table entries and code blocks; the Position Map stores the mapping between code blocks and leaf nodes; Step 1.1.3: Repeat steps 1.1.1 to 1.1.2 until all code blocks are filled into the ORAM tree; The data ORAM tree filling stage includes: Step 2.1.1: Select the block to be added to the ORAM tree, use the RDRAND hardware instruction to randomly generate a leaf node leaf_id and a subtree position part_id, fill the data block into the node corresponding to the leaf node of the part_id subtree, from the leaf node to the root node, find the free position in the bucket and store the code block. Step 2.1.2: Based on the location where the data block is stored, the ORAM controller updates the mapping between the virtual address and physical address of the data block to the Address Translation Table; an inadvertent read operation is used to update the Address Translation Table, hiding the mapping between table entries and data blocks; the Position Map stores the mapping between data blocks, leaf nodes, and subtrees; Step 2.1.3: Repeat steps 2.1.1 to 2.1.2 until all data blocks are filled into the ORAM tree; The data block write-back phase includes: Stash stores the data blocks read from the subtree of the binary tree each time. If data is retrieved A times from the binary tree and stored in Stash, a data write-back is required. When accessing data blocks, the data ORAM controller first checks the metadata information of the buckets on the access path P(ℓ). If the count value in the metadata is greater than S+Y, the path needs to be written back. If the count value is less than S+Y, dummy blocks can continue to be obtained from the bucket. Y represents the number of dummy blocks that can be treated as real blocks in each bucket.

2. The efficient side-channel defense method based on hybrid ORAM according to claim 1, characterized in that, The code block request phase includes: The source program sends a code block request R1 = (op_r, index, address) to the code ORAM controller, where op_r indicates that the request type is a read operation, index indicates the unique index of the requested code block, and address indicates the virtual address of the target code block; The ORAM controller uses an inadvertent read operation to access the Address Translation Table to obtain the physical address corresponding to the virtual address in R1; at the same time, the ORAM controller uses an inadvertent read operation to query the Position Map to obtain the corresponding leaf tag leaf_id based on the physical address of the target code block; After obtaining the leaf_id value of the corresponding leaf node, a unique path P(ℓ) can be determined in the binary tree. Then, the code ORAM controller uses the metadata information stored in each bucket of the binary tree to determine whether the requested block is in that bucket and its offset within the bucket. If the requested code block is not in the bucket, a randomly selected unread block with a valid value of 1 is retrieved from that bucket. If the requested code block is in the bucket, the requested block is retrieved. Finally, a total of [number missing] blocks are retrieved from all buckets along path P(ℓ). Each code block retrieves the block and stores it in a register in the ORAM controller. N represents the number of nodes in the binary tree.

3. The efficient side-channel defense method based on hybrid ORAM according to claim 1, characterized in that, The code block execution phase includes: The source program performs processing operations on code blocks in the code access module; After completing the current operation, the source program sends the next code block request R2=(op_r, index, address) to the ORAM controller.

4. The efficient side-channel defense method based on hybrid ORAM according to claim 1, characterized in that, The data block request phase includes: The source program sends a data block request Q1 = (op, index, address) to the data ORAM controller, where op represents the type of request, including two types: data read operation op_r and data write-back operation op_w; index represents the unique index of the requested data block; and address represents the virtual address of the target data block. The ORAM controller uses an inadvertent read operation to access the Address Translation Table to obtain the physical address corresponding to the virtual address in Q1; at the same time, the ORAM controller uses an inadvertent read operation to query the Position Map to obtain the corresponding subtree label part_id and leaf label leaf_id based on the physical address of the target data block. After obtaining the corresponding subtree label `part_id` and leaf node `leaf_id` values, a subtree and a path within that subtree can be uniquely identified in the binary tree. Then, the data ORAM controller uses the metadata information stored in each bucket of the binary tree to determine whether the requested block is in that bucket and its offset within the bucket. If the requested code block is not in the bucket, a randomly selected unread block with a valid value of 1 is retrieved from that bucket. If the requested code block is in the bucket, the requested block is retrieved. Finally, a total of [number] blocks are retrieved from all buckets along path P(ℓ). Each data block is retrieved and stored in a Stash array within the ORAM controller.

5. A highly efficient side-channel defense method based on hybrid ORAM according to claim 1, characterized in that, The data block execution phase includes: During the ORAM tree data block execution phase, an inadvertent read operation is used to retrieve the target data block into a 64-byte memory location for data read and write operations. After the operation is completed, the next data block request is sent to the ORAM controller. The source program performs read and write operations on a 64B data block in memory. After completing the current operation, the source program sends a request for the next data block, Q2 = (op, index, address), to the ORAM controller.

6. The efficient side-channel defense method based on hybrid ORAM according to claim 1, characterized in that, The data write-back is specifically described as follows: For each real data block, a leaf node is randomly assigned again and the values ​​of the Address Translation Table and Position Map are updated. Then, the Z+S blocks in the Stash are written back to the buckets in the subtree using a reverse lexicographical strategy, where S represents the number of fake blocks stored in the bucket. During write-back, Z blocks are taken from each bucket and written to Stash along a path in the subtree.

7. A highly efficient side-channel defense method based on hybrid ORAM according to any one of claims 1-6, characterized in that, The ORAM controller uses an inadvertent read operation, which involves comparing the target block virtual address in requests R1 and Q1 with the virtual address of each entry in the Address Translation Table. Based on the comparison result, it determines whether to perform a real value retrieval operation to obtain the corresponding physical address. After the ORAM controller completes the unintentional read operation on all entries, only the values ​​in the entries with the same virtual addresses in R1 and Q1 are actually retrieved. Externally, it can only be observed that the ORAM controller performs the same access operation on each entry.

Images