Casual key value storage and access method with fixed interaction times
Through a fixed-height p forktree structure and ORAM storage solution, the problem of large amount of client storage and high number of interactions in unintentional key-value storage is solved, and the number of constant-level storage and interactions is realized, and data security and access mode are protected.
Patent Information
- Application Number
- CN202510541100.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-28
- Publication Date
- 2025-07-29
AI Technical Summary
The prior art has problems with large amount of client storage and large number of interactions in unintentional key-value storage, especially Path ORAM and OMAP solutions are not ideal in practical applications.
Using a fixed-height tree structure and ORAM storage scheme, by designing a fixed-height p fork tree, the number of interactions is reduced to O(1), and the tree height remains unchanged during data insertion and deletion, and a small number of fill operations are introduced to hide the operation type.
It realizes inadvertent key-value storage and access of constant-level client storage and constant-level interaction times, protects data confidentiality and access mode, and avoids the problems of excessive client storage and excessive interaction times.
Smart Images
Figure CN120389859A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of data security storage and query in cryptography, and specifically relates to an oblivious key-value storage and access method with a fixed number of interactions, including an oblivious key-value storage method based on a multi-way tree, as well as query, insertion, and deletion access operation methods for oblivious key-values. Background Art
[0002] Currently, more and more enterprises and users are hosting their data on cloud servers. For sensitive data, in addition to protecting the confidentiality of the data, it is equally important to protect the access pattern of the data. An attacker can infer private data by observing the access pattern. The Oblivious Random Access Machine (ORAM) is one of the most effective methods for protecting the access pattern. The current mainstream solution, Path ORAM, requires O(N) client storage. Through a recursive approach, the client storage can be reduced to O(1), but it introduces O(logN) interaction times. The oblivious data structure can implement oblivious key-value storage (Oblivious Map, OMAP) by constructing an AVL tree on the basis of Path ORAM, and also achieves O(1) client storage, but brings O(logN) interaction times. In practical applications, it is not ideal for the client to store a large amount of data, and it is also not ideal for a single query to require dozens of interactions with the server. Summary of the Invention
[0003] In order to achieve constant-level client storage and constant-level interaction times, the present invention provides an oblivious key-value storage and access method with a fixed number of interactions, including a tree structure with a fixed height layer replacing the AVL tree and its access strategy, to solve the problems of large interaction times overhead and large client storage in the prior art. Different from the prior art, the prior art uses an AVL tree, while the present invention designs a tree with a fixed height, reducing the interaction times from O(logN) to O(1). At the same time, in order to ensure obliviousness, during the data insertion process, the height of the AVL tree increases as the inserted data increases, but the tree height of the present invention remains unchanged, so fewer padding times are introduced.
[0004] To achieve the above object, the present invention adopts the following technical solutions:
[0005] The logical structure is a p-way tree with a height of H. The leaf nodes of the tree store data, and the intermediate nodes and the root node store indexes. To ensure the access patterns of the data and indexes, each tree node is packed into a data block and stored in the ORAM. Nodes with the same height in the tree are stored in one ORAM. Therefore, a total of H ORAMs are required for this solution, denoted by ORAM0, ORAM1,..., ORAM H-1 denoted.
[0006] The index node (internal node) stores the IDs of its child nodes and their corresponding position tags, with a capacity of p; the data node (leaf node) stores data, and its capacity B determines how many data items can be stored. The ID of the index node is the maximum value of the IDs of its child nodes, and the ID of the data node is the maximum value of the data IDs stored. The data in the data node is sorted, so indexing can be performed through simple size comparisons.
[0007] A key-value pair is usually represented as key:value. To distinguish it from an encryption key, this technical solution uses id:data. An oblivious key-value storage and access method with a fixed number of interactions includes the following steps:
[0008] Step 1: Initialization. The client encrypts the virtual block and sends it to the server for storage in ORAM0, ORAM1, …, ORAM H-1 and the client stores the encryption key. In the initial state, the client cache is empty, and the data identifier of the root node stored by the client is empty, and the position tag is a random value.
[0009] Step 2: The client access request includes the operation type (insert, query, delete), the data identifier id, and the data content data. The client first checks the data identifier and position tag of the root node stored locally.
[0010] Step 3: Start the search operation from the root node, retrieve the node back to the client for decryption, and find a k from childMap = (childKey, childPos) such that k = min{k|key ≤ k ∧ k ∈ childKey}, and find the next node to be searched according to childMap[k]. If it is a delete operation, the neighbor nodes of each node also need to be retrieved. Repeat Step 3 until the current node is a leaf node. All the nodes retrieved in this step are stored in the client's cache.
[0011] Step 4: The client processes the data according to the operation type.
[0012] Step 4-1: If it is a query operation, query the data identifier id from the leaf node and return the corresponding data.
[0013] Step 4-2: If it is an insert operation, insert the data identifier id and the data data into the retrieved leaf node. If this insert operation causes the node to overflow (exceed the node capacity), split the node into two. Add the information of the split node to the parent node of this node and update childList. If the parent node data overflows, continue to split until there is no data overflow situation or the root node is reached.
[0014] Step 4-3: If it is a deletion operation, delete the data item with the data identifier id from the leaf node. If the deletion operation causes the number of real data items in this node to be less than half of the capacity, then at this time, it is necessary to reorganize or merge the content of this node and its neighbor node. If the number of real data items in this node and its neighbor node is less than or equal to the node capacity, then merging can be performed; otherwise, it is necessary to reorganize the content of the two nodes. For example, move a piece of data from the neighbor node to this node, and finally ensure that the proportion of the real data content of all nodes is greater than or equal to 50%.
[0015] Step 5: For all nodes cached by the client, starting from the leaf node, allocate a random storage location and update the new location of this node in the childMap of its parent node. After re-encrypting all the nodes in the client cache, write them back to the server.
[0016] Step 6: Execute the padding strategy. To protect the access pattern, the operation type needs to be hidden, that is, for the server, it is impossible to distinguish whether an operation is an insertion operation or a read / write operation. It is necessary to pad the number of times the function is called for the four operations. Among the four operations, the only difference is the deletion operation. Since each layer of nodes needs to retrieve the neighbor node (if there is a neighbor node) at the same time, 1 or 2 read operations are required. To ensure obliviousness, pad the number of times of reading and writing back to the ORAM i in each operation to 2.
[0017] Differing from the prior art, the beneficial effects of the above technical solution are as follows:
[0018] The present invention is an oblivious key-value storage and access method with a fixed number of interactions. This method realizes one access operation through constant interactions even when the client does not require fixed storage. This method not only protects the data confidentiality through encryption without the need for secure hardware, but also protects the data access pattern through ORAM. Brief Description of the Drawings
[0019] Figure 1 are the flowcharts of the initialization phase and the access phase;
[0020] Figure 2 is a schematic diagram of a fork tree;
[0021] Figure 3 is a schematic diagram of insertion;
[0022] Figure 4 is a schematic diagram of deletion. Detailed Description of the Specific Embodiment
[0023] To describe in detail the technical content, structural features, achieved objectives, and effects of the technical solution, the following is described in detail in combination with specific embodiments and with reference to the accompanying drawings.
[0024] The logical structure is a p-ary tree with a height of H. The leaf nodes of the tree store data, and the intermediate nodes and root nodes store indexes. To ensure the access pattern of data and indexes, each tree node is packaged into a data block and stored in ORAM. Nodes with the same height in the tree are stored in one ORAM. Therefore, this solution requires a total of H ORAMs, ORAM0, ORAM1, ..., ORAM H-1 express.
[0025] Index nodes (internal nodes) store the IDs of their child nodes and their corresponding location labels, with a capacity of p. Data nodes (leaf nodes) store data, with a capacity of B that determines the number of data items they can store. The ID of an index node is the maximum value of its child node IDs, while the ID of a data node is the maximum value of its stored data IDs. Data in data nodes is ordered, allowing for indexing via simple size comparisons.
[0026] Key-value pairs are usually represented by key:value. To distinguish them from encryption keys, this article uses id:data. A method for storing and accessing oblivious key-value pairs with a fixed number of interactions includes the following steps:
[0027] Step 1: Initialization. The client encrypts the virtual block and sends it to the server to be stored in an Oblivious RAM (ORAM), namely ORAM0, ORAM1, ..., ORAM H-1 ,The client stores the encryption key.,In the initial state, the client cache is empty, the root node data identifier stored,by the client is empty, and the location label is a random value.
[0028] Step 2: The client initiates an access request, including the operation type (insert, query, delete), data identifier id, and data content data. The client first checks the root node data identifier and location tag stored locally.
[0029] Step 3: Perform a search operation starting from the root node and return the node to the client for decryption. Each node contains a mapping table, represented as childMap = (childKey, childPos). Next, find a k in the node mapping table that satisfies k = min{k|id≤k∧k∈childKey} and find the next node to be searched based on childMap[k]. If this is a delete operation, it is also necessary to retrieve the neighboring nodes of each node. Repeat step 3 until the current node is a leaf node. All nodes retrieved in this step are stored in the client's cache.
[0030] Step 4: The client processes the data according to the operation type.
[0031] Step 4-1: If it is a query operation, query the data identifier id from the leaf node and return the corresponding data.
[0032] Step 4-2: If it is an insertion operation, insert the data identifier id and the data data into the retrieved leaf node. If this insertion operation causes the node to overflow (exceed the node capacity), split the node into two. Add the information of the split node to the parent node of this node and update the childList. If the parent node data overflows, continue to split until there is no data overflow or reach the root node.
[0033] Step 4-3: If it is a deletion operation, delete the data item with the data identifier id from the leaf node. If the deletion operation causes the number of real data items in this node to be less than half of the capacity, at this time, it is necessary to reorganize or merge the content of this node and its neighbor node. If the number of real data items in this node and the neighbor node is less than or equal to the node capacity, then merging can be performed; otherwise, it is necessary to reorganize the content of the two nodes. For example, move a piece of data from the neighbor node to this node, and finally ensure that the proportion of the real data content of all nodes is greater than or equal to 50%.
[0034] Step 5: For all nodes cached by the client, allocate a random storage location starting from the leaf node and update the new location of this node in the childMap of its parent node. After re-encrypting all the nodes in the client cache, write them back to the server.
[0035] Step 6: Execute the padding strategy. To protect the access pattern, it is necessary to hide the operation type, that is, for the server, it is impossible to distinguish whether an operation is an insertion operation or a read / write operation. It is necessary to pad the number of times of calling functions for the four operations. Among the four operations, the only difference is the deletion operation. Since each layer of nodes needs to retrieve the neighbor node (if there is a neighbor node) at the same time, 1 or 2 read operations are required. To ensure obliviousness, pad the number of read and write-back ORAM i times in each operation to 2.
[0036] Table 1 Table of the number of read and write-back ORAM times
[0037]
[0038]
[0039] The present invention selects an example for detailed description. In this example, the tree height H = 4, p = c = 3. Figure 2 Describes the structure of this tree. Figure 3 、 4 Are the schematic diagrams of insertion and deletion respectively. In the following example, use Indicates on which path the node with id = i is in the ORAM j among them.
[0040] 1. In the initial stage, the client sends an initialization request to initialize the ORAM list {ORAM0, ORAM1, ORAM H-1} on the server side into random virtual blocks, where ORAM i stores all nodes in the (i + 1)-th layer of the multi-way tree. The client cache is empty in the initialization state.
[0041] 2. Assume that the set of key values of the key-value pairs already stored on the server through the insert operation is
[0042] {2, 6, 10, 11, 21, 22, 27, 31, 35, 44, 58, 61}. The constructed multi-way tree is as Figure 3-1 shown. The client stores the id = 61 of the root node and the position label indicating on which path the root node is in ORAM0.
[0043] 3. The user initiates an insert request insert(key = 60, value = data). The client sends to retrieve the root node from the server side, query the of the root node and find a k in it such that k = min{k|key ≤ k ∧ k ∈ childKey} (if no k satisfying the condition is found, then k takes the maximum value in childKey). After calculation, k = 61. According to retrieve the next node to be accessed from the server and repeat the above steps until the leaf node is retrieved from the server side. The retrieved node path is as Figure 3 shown by the light gray path in (1).
[0044] a) Perform the insert operation on the client side. Insert (key = 60, value = data) into the leaf node, and the content of the leaf node changes from {44:, 58:, 61:} to {44:, 58:, 60:data, 61:}, as Figure 3 shown in (2). The leaf node overflows and needs to be split into two leaf nodes {44:, 58:} and {60:data, 61:}, and at the same time update the index in the parent node, as Figure 3 shown in (3). Recursively perform the insert and split operations until no split is required or the root node is reached, as Figure 3 shown in (4).
[0045] 4. The user initiates a delete request delete(key = 35). The client sends to retrieve the root node from the server side, query the Find a k from them such that k = min{k|key ≤ k ∧ k ∈ childKey}
[0046] (If no k satisfying the condition is found, then k takes the maximum value in childKey), and find the neighbor node of the next layer node (by default, select the left neighbor). After calculation, k = 61 and there is no neighbor. According to
[0047] Fetch the next node to be accessed from the server and repeat the above steps until a leaf node is fetched from the server. The fetched node path is as shown by the dashed box in Figure 4 (1). The nodes with horizontal shading represent the fetched neighbor nodes, where {10:, 21:} at the third layer is the neighbor node of {27:, 35:}
[0048] a) Perform a deletion operation on the client. Delete the data item with (key = 35), and the leaf node {31:, 35:} becomes {31:}. The proportion of real data in this node is less than 50%, and it needs to be merged with the neighbor node into one node
[0049] {22:, 27:, 31:}, as shown in Figure 4 (2).
[0050] b) The third - layer index node {27:, 35:} is updated to {31:}, and it needs to be merged with the neighbor node into {10:, 21:, 31:}, as shown in Figure 4 (3).
[0051] c) The second - layer index node {21:, 61:} is updated to {31:, 61:}, and the root node does not need to be updated, as shown in Figure 4 (4).
[0052] 5. After each insert, query, and delete operation, for all nodes cached on the client, starting from the leaf node and going layer by layer downwards, assign a random storage location and update the new location label of this node in the childPos of its parent node.
[0053] 6. Write all the nodes in the client cache back to the server.
[0054] 7. Fill in the read operation, and then fill in the write - back operation.
[0055] It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or terminal device. Without further limitation, the elements defined by the statement "comprising..." or "comprising..." do not exclude the existence of additional elements in the process, method, article or terminal device comprising the said elements. In addition, in this article, "greater than", "less than", "more than" etc. are understood not to include the base number; "above", "below", "within" etc. are understood to include the base number.
[0056] Although the above-described embodiments have been described, those skilled in the art can make additional changes and modifications once they learn the basic creative concept. Therefore, the above are only embodiments of the present invention, and do not limit the patent protection scope of the present invention. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present invention, or directly or indirectly applied in other related technical fields, is similarly included in the patent protection scope of the present invention.
Claims
1. An oblivious key-value storage and access method with a fixed number of interactions, characterized in that It includes the following steps: Step 1, Initialization: The client encrypts the virtual blocks and sends them to the server for storage in H oblivious random access machines (ORAMs). The client stores the encryption key. In the initial state, the client cache is empty, the data identifier of the root node stored by the client is empty, and the location tag is a random value; Step 2, Client access request: It includes the operation type, data identifier id, and data content data. The client first checks the data identifier of the root node and the location tag stored locally; Step 3, Perform a lookup operation starting from the root node. Bring the node back to the client for decryption. Each node contains a mapping table, denoted as childMap=(childKey, childPos). Then, find a k in the node mapping table that satisfies k = min{k|id ≤ k ∧ k ∈ childKey}, and find the next node to be looked up according to childList[k]. If it is a deletion operation, the neighbor nodes of each node also need to be retrieved. Repeat Step 3 until the current node is a leaf node. All the nodes retrieved in this step are stored in the client's cache; Step 4, The client processes the data according to the operation type; Step 5, The client fills the ORAM read operation, re-encrypts all the nodes in the client cache, and writes them back to the server.
2. The oblivious key value storage and access method with a fixed number of interactions as claimed in claim 1, characterized in that The said Step 4 includes: Step 4-1, If it is a query operation, query the data identifier id from the leaf node and return the corresponding data; Step 4-2, If it is an insertion operation, insert the data identifier id and the data data into the retrieved leaf node. If this insertion operation causes the node to overflow, split the node into two, add the information of the split node to the parent node of this node and update childMap. If the parent node data overflows, continue to split until there is no data overflow situation or reach the root node; Step 4-3, If it is a deletion operation, delete the data item with the data identifier id from the leaf node. If the deletion operation causes the number of real data items in this node to be less than half of the capacity, at this time, it is necessary to reorganize or merge the content of this node and its neighbor nodes.
3. The oblivious key-value storage and access method with a fixed number of interactions according to claim 1, characterized in that, The said Step 5 includes: Step 5-1, The read and write access to each ORAM is 2 times. If it is less than 2 times, fill it up to 2 times; Step 5-2, For all the nodes in the client cache, assign a random storage location starting from the leaf node, and update the new location of this node in the childMap of its parent node. Re-encrypt all the nodes in the client cache and write them back to the server.