Database access operation processing method and device

Abstract

The embodiment of the invention discloses a database access operation processing method, a database comprises a first secret state table, the plaintext content of the first secret state table comprises a plurality of real key value pairs and imaginary key value pairs, and the index of the first secret state table is the ciphertext of a key. The method is applied to a client, and comprises the following steps: firstly querying whether a target key value pair is stored in a secret state cache constructed based on an oblivious mechanism in a database; if no cache exists, the first secret state table is queried based on the target key, and otherwise, the first secret state table is queried based on the imaginary key. And then, analyzing an original key value pair corresponding to the target key based on a result of querying the secret state cache and the first secret state table, and locally performing target access operation on the original key value pair to obtain a new key value pair, thereby writing the new key value pair into the secret state cache. Then, first enqueue operation is carried out on a secret state queue in the database based on the target key, and the secret state queue is used for writing the ciphertext of the new key value pair back to the first secret state table;

Description

Technical Field

[0001] This specification relates to the field of database technology, and more particularly to a method and apparatus for processing database access operations, a computer-readable storage medium, and a computing device. Background Technology

[0002] Cloud-based encrypted databases refer to databases where users encrypt their own databases and host them on servers provided by cloud service providers to reduce their investment in hardware and software. To facilitate daily database queries and access, these systems typically employ specific encryption schemes, allowing the cloud server to efficiently process user queries and access requests without knowing the original data content. With the increasing maturity of cloud computing technology and related infrastructure, this type of database system is being adopted by more and more users due to its advantages such as ease of management.

[0003] However, in practical applications, users still face a type of privacy protection risk: although data is encrypted when stored statically, cloud service providers may still infer sensitive information by analyzing users' database access patterns (such as query frequency and accessed objects). For example, service providers can observe user-initiated query commands to infer the specific data records accessed or the business logic behind them, thereby leading to user privacy leaks.

[0004] To address these risks, the industry has proposed several database processing solutions aimed at protecting data access privacy. However, existing solutions often introduce significant performance overhead and system costs while achieving strong privacy protection capabilities, limiting their practicality and scalability. Therefore, how to effectively control the risk of user privacy leakage during data access while simultaneously ensuring processing efficiency and cost control remains a pressing technical challenge. Summary of the Invention

[0005] This specification describes a method and apparatus for processing database access operations, which can solve the above-mentioned technical problems.

[0006] According to a first aspect, a method for processing database access operations is provided. The database includes a first encrypted table, the plaintext content of which includes n real data records and a first set of fictitious data records, wherein each real data record includes a real key-value pair; the index of the first encrypted table is the ciphertext of the key in the data record. The method is applied to a client and includes:

[0007] Based on the target key, a first access operation is performed on the encrypted cache constructed using an unintentional mechanism in the database to obtain a first access result, which indicates whether the key-value pair corresponding to the target key exists in the encrypted cache. Based on the first key, a first query operation is performed on the first encrypted table to obtain the encrypted text of the first data record; the determination of the first key includes: if the first access result indicates that it does not exist, the target key is used as the first key; otherwise, the first fictitious key involved in the first group of fictitious data records is used as the first key. Based on the new key-value pair corresponding to the target key, a second access operation is performed on the encrypted cache, so that the encrypted text of the new key-value pair is cached; the new key-value pair is obtained by performing a target access operation on the original key-value pair, and the original key-value pair is determined based on the encrypted text of the first data record and the first access result. Based on the target key, a first enqueue operation is performed on the encrypted queue in the database, and the encrypted queue is used to write the encrypted text of the new key-value pair back to the first encrypted table.

[0008] In one embodiment, determining the original key-value pair includes: if the first access result indicates that the original key-value pair exists, parsing the original key-value pair from the access result; otherwise, parsing the original key-value pair from the first data record ciphertext.

[0009] In one embodiment, the queue length of the encrypted queue is configured by the logged-in user of the client.

[0010] In one embodiment, each real data record further includes a sequence number added to its key-value pair; the database further includes a second encrypted table, the plaintext content of which includes the n real data records and a second set of fictitious data records; the index of the second encrypted table is the encrypted sequence number in the data record. The method further includes:

[0011] Based on the first sequence number, a second query operation is performed on the second encrypted state table to obtain the encrypted text of the second data record. Determining the first sequence number includes: if the first access result indicates that the record does not exist, using the first fictitious sequence number involved in the second group of fictitious data records as the first sequence number; otherwise, using the first real sequence number involved in several currently uncached real data records as the first sequence number. A third access operation is performed on the encrypted state cache, such that if the first sequence number is the first real sequence number, the encrypted text of the second data record is cached. Based on the first sequence number, a second enqueue operation is performed on the encrypted state queue, which is used to write the encrypted text of the second data record back to the first and second encrypted state tables if the first sequence number is the first real sequence number.

[0012] Furthermore, in a specific embodiment, based on the second data record ciphertext, a third access operation is performed on the encrypted cache, including: when the first sequence number is the first real sequence number, the third access operation is performed on the encrypted cache using the first real data record parsed from the second data record ciphertext, which is a real write operation; when the first sequence number is the first fictitious sequence number, the third access operation is performed on the encrypted cache, which is disguised as a write operation, thereby not triggering data writing.

[0013] In another specific embodiment, after performing a second enqueue operation on the encrypted queue based on the first sequence number, the method further includes: reading the current head element from the encrypted queue, which is the ciphertext of the first sequence number; performing a fourth access operation on the encrypted cache to obtain the ciphertext of the current data record corresponding to the first sequence number; and writing the ciphertext of the current data record back to the first and second encrypted tables if the first sequence number is the first real sequence number.

[0014] Furthermore, in one example, the method further includes: when the first sequence number is the first fictitious sequence number, writing the current data record ciphertext back to the second encrypted state table based on the first fictitious sequence number, and performing a write-back operation on the first encrypted state table based on the second fictitious key involved in the first group of fictitious data records.

[0015] On the other hand, in a specific embodiment, the encrypted cache includes a first search and a second search tree constructed based on an unintentional mechanism, wherein the node indices in the first and second search trees are the encrypted keys and sequence numbers in the data records, respectively; wherein, based on the target key, performing a first access operation on the encrypted cache constructed based on the unintentional mechanism in the database includes:

[0016] Based on the target key, the first access operation is performed on the first search tree; wherein, taking the first real sequence number involved in a plurality of real data records that are not currently cached as the first sequence number includes: performing a fifth access operation on the second search tree to obtain the first real sequence number.

[0017] Furthermore, in one example, the nodes in the first search tree are configured with a target attribute, wherein the first attribute value corresponding to the target attribute indicates that the key-value pair stored in this node has been written back to the secret state table, and the second attribute value indicates the opposite; wherein, the second access operation also causes: the target node corresponding to the target key to have the second attribute value, and the target node to store the operation timestamp for the new key-value pair.

[0018] The encrypted queue includes a first sub-queue and a second sub-queue, which are used to store data record indexes that have been written back and those that have not been written back to the encrypted table, respectively. Each queue element in the encrypted queue also includes a corresponding operation timestamp. The first enqueue operation is performed on the second sub-queue. After the first enqueue operation, the method further includes: reading the current head element from the second sub-queue, which includes the ciphertext of the target key and the corresponding first operation timestamp; performing a sixth access operation on the encrypted cache based on the target key to obtain the ciphertext of the current data record corresponding to the target key and the corresponding second operation timestamp; if the first operation timestamp and the second operation timestamp match, performing a write-back operation on the first and second encrypted tables based on the current data record ciphertext; performing a seventh access operation on the first search tree based on the target key, so that the target node is set to have the first attribute value; and removing the ciphertext of the target key from the second sub-queue and moving it to the tail of the first sub-queue.

[0019] Furthermore, in a specific example, the method further includes: if the first operation timestamp and the second operation timestamp are found to be inconsistent, performing write-back operations on the first and second secret state tables respectively based on the first set of fictitious data and / or the second set of fictitious data.

[0020] In a specific example, after removing the ciphertext of the target key from the second sub-queue and moving it to the tail of the first sub-queue, the method further includes: reading the current head element from the first sub-queue, which is the ciphertext of the target key and the corresponding first operation timestamp; performing an eighth access operation on the encrypted cache based on the target key to obtain the third operation timestamp corresponding to the target key; if the first operation timestamp and the third operation timestamp are found to be consistent, deleting the node corresponding to the target key from the first and second search trees, otherwise not deleting it; and deleting the current head element in the first sub-queue.

[0021] In another specific embodiment, the first and second secret state tables are initially uploaded to the database by the client.

[0022] According to a second aspect, a processing apparatus for database access operations is provided, wherein the database includes a first encrypted table, the plaintext content of which includes n real data records and a first set of fictitious data records, wherein each real data record includes a real key-value pair; the index of the first encrypted table is the ciphertext of the key in the data record; the apparatus is integrated into a client and includes:

[0023] The first access module is configured to perform a first access operation on the encrypted cache built by an unintentional mechanism in the database based on the target key, and obtain a first access result, which indicates whether the key-value pair corresponding to the target key exists in the encrypted cache. The first query module is configured to perform a first query operation on the first encrypted table based on a first key, and obtain the encrypted text of a first data record; the determination of the first key includes: if the first access result indicates that the target key does not exist, using the target key as the first key; otherwise, using the first fictitious key involved in the first group of fictitious data records as the first key. The second access module is configured to perform a second access operation on the encrypted cache based on the new key-value pair corresponding to the target key, so that the encrypted text of the new key-value pair is cached; the new key-value pair is obtained by performing a target access operation on the original key-value pair, and the original key-value pair is determined based on the encrypted text of the first data record and the first access result. The first enqueue module is configured to perform a first enqueue operation on the encrypted queue in the database based on the target key, and the encrypted queue is used to write the encrypted text of the new key-value pair back to the first encrypted table.

[0024] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method provided in the first aspect.

[0025] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method provided in the first aspect.

[0026] In summary, the methods and apparatus disclosed in the embodiments of this specification provide the first OMAP solution that can reduce security to improve usability. In particular, this solution supports users in dynamically adjusting the security of OMAP, thereby meeting different security requirements in actual business scenarios. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of the implementation architecture of the pioneering solution disclosed in the embodiments of this specification;

[0029] Figure 2 This is a schematic diagram of the interaction steps of the processing method for database access operations disclosed in the embodiments of this specification;

[0030] Figure 3 The embodiments disclosed in this specification are in Figure 2 A diagram illustrating the further improvements to the interaction steps based on the existing model;

[0031] Figure 4 This is a schematic diagram illustrating the division of a queue into two sub-queues as disclosed in the embodiments of this specification;

[0032] Figure 5 This is a schematic diagram illustrating the process steps for writing cached records back to the encrypted table as disclosed in the embodiments of this specification.

[0033] Figure 6 This is a schematic diagram illustrating the process steps for deleting cached records as disclosed in the embodiments of this specification;

[0034] Figure 7 This is a schematic diagram illustrating the interactive steps of an implementation example of the solution disclosed in the embodiments of this specification.

[0035] Figure 8 This is a functional structure diagram of the database access operation processing device disclosed in the embodiments of this specification. Detailed Implementation

[0036] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0037] As mentioned above, the industry has proposed several database processing solutions aimed at protecting the privacy of data access. However, while achieving strong privacy protection capabilities, existing solutions often introduce significant performance overhead and system costs, resulting in limitations in their practicality and scalability.

[0038] Specifically, existing solutions include persistent storage for databases built on oblivious mechanisms. The core idea of ​​oblivious mechanisms is to hide data access patterns. In the context of key-value databases, Oblivious Maps (OMAPs) are one of the core implementation tools of oblivious mechanisms. The working mechanism of OMAPs is as follows:

[0039] 1) Input: The user wants to query, insert or update the corresponding value based on a key.

[0040] 2) Process: OMAP encapsulates all low-level operations. When a user needs to access a specific key (e.g., key_id=123), the system does not directly locate the actual physical address of that key. Instead, it executes a predefined protocol flow independent of the accessed key. The inevitable result of this flow is that the system must read, decrypt, and re-encrypt and write all data blocks along an entire path or on a complete partition in the underlying storage structure. In this process, the target data block is merely one of many data blocks being operated on; its access is hidden within the necessary maintenance operations on non-target data blocks.

[0041] 3) Output: Users can finally correctly obtain or modify the value corresponding to key_id=123.

[0042] The above working mechanism can achieve the following: For an external observer (such as a cloud service provider), he can only see that OMAP is constantly accessing a large number of data blocks, but he cannot distinguish from these access sequences which key the user really wants to access, nor can he associate any accessed data block with a specific key-value pair stored.

[0043] While OMAP offers robust privacy protection, it comes at a very high cost, which manifests in various aspects of system performance, primarily including:

[0044] 1) Huge communication overhead: In order to hide access to a key, OMAP may need to transfer O(log N) data blocks between the client and the server, where N is the total number of KV pairs in the database.

[0045] For example, in a database containing 1 million key-value records, reading a single 1KB record might require transmitting approximately 20 data blocks (e.g., 20 * 4KB = 80KB) over the network. This means that 80KB of network traffic is generated for just 1KB of valid data, demonstrating a significant communication amplification effect.

[0046] 2) High computational overhead: Every data block read from or written to the server needs to be decrypted and encrypted.

[0047] 3) Path Operations: For OMAP implemented using a tree-based Oblivious Random Access Machine (ORAM), each access requires traversing and updating all nodes along the entire path, involving a large number of hash calculations, data block encryption / decryption, and obfuscation operations. This results in significantly higher latency and CPU consumption per query compared to ordinary encrypted databases.

[0048] 4) Significant storage overhead: To effectively rearrange and obfuscate data, OMAP requires maintaining a storage structure on the server side that is much larger than the original database. Server-side storage overhead is typically several times to ten times or more the size of the original key-value database. This directly increases the cost of cloud storage.

[0049] Therefore, while building database storage based on unintentional mechanisms can achieve strong privacy protection, it also introduces significant performance overhead and system costs, resulting in poor practicality and difficulty in promotion.

[0050] To address this bottleneck, industry research suggests that OMAP's performance in practical applications can be improved by lowering security requirements. Compared to high security requirements (i.e., preventing external attackers from continuously observing and querying logs), actual adversaries are more likely to be short-lived online attackers rather than those permanently residing on the cloud server. Therefore, weakening security requirements to effectively defend against adversaries whose access patterns can only be observed a few consecutive times (c times) precisely addresses the core issue and meets the actual security needs of clients. However, no such protocol has yet been designed.

[0051] Based on the above observations and analysis, the embodiments in this specification aim to provide the first OMAP solution (hereinafter referred to as the pioneering solution) that can reduce security to improve availability. In particular, this solution supports users in dynamically adjusting the security of OMAP, thereby meeting different security requirements in actual business scenarios.

[0052] like Figure 1 As shown, in the pioneering solution, the interacting parties include the client and the database system (such as the database server provided by the cloud service provider), and the interaction phases include the preparation phase, the online access phase, and the operation write-back phase.

[0053] I. In the preparatory phase, the client initializes the following data structure information and then uploads it to the database system:

[0054] 1) Dense state table.

[0055] For the sake of brevity, the encrypted data table will be referred to as the encrypted table in this article. Specifically, the client can construct a key-value pair data table based on the user's input data, and then upload the encrypted table to the database system. Only the client can successfully decrypt the encrypted data in the table.

[0056] The plaintext of the key-value pairs in the data table is adapted to the input data. For example, the input data can be photos, audio / video files, or text files that the user submits to cloud storage for hosting. In this case, the plaintext key in the key-value pair can be the file name, and the plaintext value can be the file content.

[0057] The encryption process described above can employ either symmetric or asymmetric encryption schemes. For example, the Advanced Encryption Standard (AES), a symmetric encryption scheme, can be used.

[0058] It should be understood that the secret table is persisted to the database, or in other words, the secret table is stored in the database's data file.

[0059] 2) Configuration information for dense caching

[0060] For the sake of brevity, the encrypted database cache will be referred to as the encrypted cache in this article.

[0061] Users can configure settings for the encrypted cache. For example, the search index for the encrypted cache can be built on the keys of key-value pairs. Alternatively, the encrypted cache can be configured to support unobtrusive mechanisms (such as OMAP), which are implemented at the level of access interface functions, hardware, or protocols. Furthermore, unobtrusive mechanisms involve encrypting and decrypting data in the encrypted cache; the configuration information can also include the key information used for encryption and decryption. Another example is configuring the encrypted cache's storage structure as a tree structure to improve search efficiency, and so on.

[0062] 3) Configuration information of dense queues

[0063] For the sake of brevity, the queue in the encrypted state will be referred to as the encrypted queue in this article.

[0064] The dense queue is used to record the order in which key-value pairs were accessed in the past c operations. It records the most recently accessed key-value pair at the tail of the queue and removes the earliest accessed key-value pair from the head of the queue. In this way, data records in the dense cache can be periodically written back to the dense table based on the dense queue.

[0065] The specific value of the upper limit 'c' for the number of operations can be defined by the user and adjusted as needed. The value of 'c' determines the length of the queue and also the maximum number of access operations or the maximum number of key-value pairs in the cache, thus determining the security strength of the pioneering solution.

[0066] Decreasing the value of 'c' reduces security, but also lowers cost. This is because: a dense cache is built on an inadvertent mechanism, meaning that the access pattern of c consecutive accesses to the dense cache is securely hidden, preventing attackers from obtaining useful information; while for the three data structures mentioned above—tables, caches, and queues—the most expensive is the database cache built on an inadvertent mechanism. A smaller 'c' means fewer key-value pairs need to be cached, resulting in lower cost.

[0067] II. Online Access Phase

[0068] In response to a user-initiated business request (such as a transfer request), the client sends the target key (such as the user's account) to the database system. The database system interacts with the client multiple times based on the encrypted cache, encrypted table, and encrypted queue, so that: 1) the encrypted cache stores the new key-value pair corresponding to the target key (which is the result of performing the target access operation on the original key-value pair in the encrypted table or encrypted cache, for example, the new value is the updated account balance); 2) the encrypted text of the target key is added to the encrypted queue as an index to the new key-value pair.

[0069] Furthermore, regardless of whether the original key-value pairs exist in the secret table or the secret cache, the access paths (including the types and order of access interfaces) seen by the attacker are extremely similar or completely consistent. For example, the client accesses the following interfaces in sequence: the query interface of the secret cache, the query interface of the secret table, the update interface of the secret cache, and the write interface of the secret queue.

[0070] III. Operation Write-back Phase

[0071] In a typical scenario, the client triggers a write-back process, which, based on the access object index read from the secret state queue, writes the corresponding current key-value pair back to the secret state table and deletes it from the cache.

[0072] The above combination Figure 1 This section provides a brief overview of the preparation phase, online access phase, and operation write-back phase in the pioneering solution. It's important to understand that the preparation phase occurs before the online access and operation write-back phases and generally only needs to be executed once. The online access and operation write-back phases can be executed multiple times and alternately, as long as the data flow conforms to the logic.

[0073] In summary, compared to existing solutions that rely on unobservable storage engines to build a database that carries all key-value pairs, this pioneering approach achieves the following advantages: 1) Effectively reduces costs: Since all key-value pairs are stored in ordinary encrypted tables, only a cache supporting an unobservable mechanism is needed to store a small portion of the key-value pairs; 2) Effectively ensures data privacy and security: The encrypted cache supports an unobservable mechanism, and regardless of whether the key-value data to be accessed exists in the cache, the access path observed by the attacker for the database system remains consistent; 3) Supports dynamic security: Users can customize the length of the encrypted queue or the maximum number of cache access operations allowed, thereby dynamically adapting to different security level requirements and effectively balancing security and the performance cost of the database system.

[0074] Next, the implementation steps of the above-mentioned pioneering solution will be described in detail with reference to more embodiments. Figure 2The diagram illustrates the interactive steps of a processing method for database access operations, wherein the database includes a first encrypted table whose plaintext content includes n real data records and a first set of fictitious data records, and the index of the first encrypted table is the ciphertext of the key in the data record.

[0075] It should be noted that the "first" in "first dense state table" and similar terms such as "second" and "third" elsewhere in the text are used to distinguish similar things and do not have any other limiting function such as ordering.

[0076] For the above n real data records, where n is a positive integer greater than 1, and may number in the millions in practical applications. Each real data record includes real key-value pairs (k... i ,v i ), for example, where the real key k i It can be the user's username, or the actual value v. i This can include account balance, account investment information, etc.

[0077] The first set of fictitious data records is fake data, used to confuse attackers when processing access operations. Each fictitious data record includes fictitious key-value pairs (dk...). j ,dv j ), fictional key dk j It does not overlap with any real keys. Furthermore, to reduce storage requirements, dk... j The data can be regular strings, so the client doesn't need constant-level storage to record them. The number of records in the first set of fictitious data records can be set as needed, for example, to be the same as the number of real data records, i.e., n.

[0078] For the above n real data records and the first set of fictitious data records, in the preparation stage, each data record is encrypted into a string of equal length and then filled into the first encrypted state table before being uploaded to the database system. It may change afterward as access operations are processed.

[0079] The index of the first encrypted table is the ciphertext of the key in the data record. There are various encryption functions to obtain this ciphertext. Generally, the industry uses hash functions. In this case, the data index in the first encrypted table is the hash value, and the first encrypted table can be referred to as the first hash table.

[0080] Improved approach: The applicant proposes using a specific function selected from a family of pseudorandom function families (PRFs) instead of a hash function to generate the index. Specifically, a PRF function F_key() can be specified from the PRF function family by setting a key (denoted as key) to process the key K, thereby using the resulting pseudorandom number F_key(K) as the index. It should be understood that pseudorandom number functions possess determinism and pseudo-randomness. Determinism means that for a fixed (key, K) pair, F_key(K) is always fixed. Pseudo-randomness means that for an adversary who does not know the key, the output of F_key() is computationally indistinguishable from the output of a true random function, thus ensuring data security.

[0081] In addition, it should be noted that when different data records are mapped to the same index location, they can be stored in that location as a linked list.

[0082] The above introduces the first dense-state table in a database system. Next, we will introduce... Figure 2 The following interactive steps are shown in the image:

[0083] In step S201, the client performs a first access operation on the encrypted cache built in the database based on the target key using an unintentional mechanism. In step S202, the client receives the returned first access result, which indicates whether the key-value pair corresponding to the target key exists in the cache.

[0084] It should be noted that the target key can refer to any key to be accessed, and is determined by the client based on the user's triggering action. In one example, suppose a user initiates a transfer through their client, involving either the sending or receiving account; in this case, the target key could be the account identifier of the sending or receiving account. In another example, suppose a user intends to delete a file in their cloud drive; in this case, the target key could be the file identifier of that file.

[0085] A dense cache includes at least a data structure whose indexes are built on the keys. This data structure can be in the form of an array, a tree, or a graph, etc. In one embodiment, the dense cache includes a first search tree, where the index of a node is the ciphertext of the key, and the storage content of the node is the ciphertext of the key-value pair. Exemplarily, the node indexes of the first search tree can be consistent with the data indexes of a first dense table. Thus, setting the data structure of the dense cache as a tree structure can improve the access efficiency of the dense cache.

[0086] For example, the first search tree can be implemented as an AVL tree. An AVL tree is a self-balancing binary search tree named after the first letter of its inventor's last name. Its core feature is that, through rotation operations, it ensures that the absolute value of the height difference (balance factor) between the left and right subtrees of any node in the tree does not exceed 1. This guarantees that the time complexity of the search, insertion, and deletion operations in the tree can be kept stable at O(log n).

[0087] The first access operation can be a query operation. For example, the client can pass the ciphertext of the target key to the query interface of the cipher cache.

[0088] The first access result indicates whether the key-value pair corresponding to the target key (hereinafter referred to as the target key-value pair) exists in the encrypted cache. Further, exemplarily, if the encrypted cache stores the target key-value pair, the first access result may also include the target key-value pair.

[0089] From the above, the client can obtain the first access result for the target key. It should be understood that the first access operation is implemented based on an inadvertent mechanism, therefore the corresponding access pattern is hidden, and the attacker cannot obtain any useful information.

[0090] Step S203: The client determines the first key based on the first access result. It should be noted that the first key is subsequently used for query operations on the first secret state table. Specifically, the execution of this step involves two branches, corresponding to the following two sub-steps:

[0091] Step S203a: If the first access result indicates that the target key-value pair does not currently exist in the encrypted cache, the target key is used as the first key, so that the target key-value pair can be read from the encrypted table subsequently.

[0092] Step S203b: If the first access result indicates that the target key-value pair currently exists in the encrypted cache, the first fictitious key selected based on the first set of fictitious data records is used as the first key.

[0093] In one example, the client locally maintains the first variable j, and sets the fictitious key dk. j It is determined as the first key, and in the dk of this fictional key j After using it (to query the first dense state table), increment the first variable j locally: j = j + 1; assuming the value range of the first variable j is an integer from 1 to n, then when j = n + 1, set j back to 1.

[0094] In another example, the client can randomly select one of the fictitious keys involved in the first set of fictitious data records as the first key.

[0095] Thus, regardless of whether the target key-value pair exists in the encrypted cache, subsequent queries to the encrypted table will be performed, preventing attackers from obtaining valid information by observing the access path. Furthermore, when the target key-value pair exists in the encrypted cache, using a fictitious key instead of the target key for table queries prevents attackers from knowing the actual query frequency for the target key, further enhancing data security.

[0096] In step S204, the client performs a first query operation on the first encrypted state table based on the first key, thereby obtaining the returned first data record ciphertext in step S205.

[0097] Specifically, the ciphertext of the first key can be passed to the query interface of the first encrypted table to obtain the ciphertext of the first data record. If the first key is the target key, the obtained ciphertext of the first data record belongs to the real data record ciphertext; if the first key is the first fictitious key, the ciphertext of the first data record belongs to the fictitious data record ciphertext.

[0098] Step S206: The client performs a target access operation on the original key-value pair (or simply original key-value pair) corresponding to the target key to obtain a new key-value pair, wherein the original key-value pair is determined based on the first data record ciphertext and the first access result.

[0099] Specifically, regarding the determination of the original key-value pair, if the first access result indicates that the target key-value pair is not stored in the encrypted cache, then the encrypted first data record is the encrypted data record corresponding to the target key, and thus the original key-value pair can be decrypted from it.

[0100] If the first access result indicates that the target key-value pair is stored in the encrypted cache, in one embodiment, the original key-value pair can be directly parsed from the first access result. For example, if the first access result contains the ciphertext of the target value read from the cache, the client can decrypt it using a symmetric key to obtain the target value. In another embodiment, the encrypted cache can be queried again based on the target key to obtain the original key-value pair.

[0101] Based on the determined original key-value pairs, the client can perform target access operations on the pairs locally, and the result of the operation is a new key-value pair.

[0102] It should be understood that, similar to the target key, the target access operation is also determined based on the user's triggering operation on the client. For example, assuming the triggering operation is a transfer operation, when the transfer-out account is used as the target key, the corresponding target access operation is to decrease the account balance, while when the transfer-in account is used as the target key, the corresponding target access operation is to increase the account balance.

[0103] On the other hand, the target access operation can be an update operation, a view operation, or a deletion operation on all or part of the fields in the original key-value pair. In one example, in a money transfer transaction, it's necessary to change a user's balance. In another example, in a cloud storage service, a user might initiate a view operation on their photos in the cloud. In yet another example, in a social application, a user might initiate a cancellation operation on their social media account. Exemplarily, account cancellation can be accomplished by changing the account validity status field in the original value, such as changing the field value from a first value indicating validity to a second value indicating invalidity.

[0104] Based on the above, the client can determine the new key-value pair under the target key.

[0105] In step S207, the client performs a second access operation on the encrypted cache based on the new key-value pair, so that the ciphertext of the new key-value pair is cached.

[0106] It should be noted that the second access operation can be an insert / update operation. The dense cache can provide a composite interface that supports both insert and update operations simultaneously, or it can provide two separate interfaces that each support insert and update. For the case of separate configurations, through special design, external systems can at most observe that an interface is called, but cannot observe which interface was called.

[0107] In one example, the client can pass the ciphertext of the target key and the ciphertext of the new key-value pair to the update interface provided by the crypto-cache, so that the crypto-cache can use the ciphertext of the target key as an index to locate the ciphertext of the original key-value pair and replace the ciphertext of the original key-value pair with the ciphertext of the new key-value pair.

[0108] In another example, the client can pass the ciphertext of the target key and the ciphertext of the new key-value pair to the insertion interface provided by the crypto-cache, so that the crypto-cache can create a cache record (i.e., the cached data record) indexed by the ciphertext of the target key and include the ciphertext of the new key-value pair in the cache record.

[0109] The above can be used to cache new key-value pairs for a target key in a dense cache.

[0110] In step S208, the client performs a first enqueue operation on the encrypted queue in the database based on the target key. The encrypted queue is used to write the ciphertext of the new key-value pair back to the first encrypted table.

[0111] In this step, the client can add the ciphertext of the target key as the index of the target access operation or the new key-value pair to the tail of the encrypted queue.

[0112] For example, if the client determines that the new key-value pair has been successfully cached based on the returned second access result (corresponding to the second access operation), it initiates the first enqueue operation; otherwise, it terminates the current process and performs a rollback.

[0113] It should be understood that the secret queue is used to record the index of the accessed data record, so that the data record in the secret cache and the data table that has undergone a specific access operation can be safely and correctly written back to the secret table.

[0114] Furthermore, the queue length of the encrypted queue can be customized by the user bound to the client (or a legitimately logged-in user). It should be understood that in different implementations of the pioneering solution, there may be different conversion relationships between the queue length and the maximum number of access operations c that the encrypted cache can cache. This conversion relationship can be set by staff based on professional knowledge and practical experience. Accordingly, users can either directly configure the queue length or configure the maximum number of access operations c, thereby determining the corresponding queue length based on the conversion relationship. For example, the queue length can be determined to be 4c based on the user-defined value of c.

[0115] It should be noted that after performing step S208 above, the new key-value pairs in the cache can also be written back according to the dense queue. In one embodiment, this write-back can be performed by executing the following interactive steps S209-S212 ( Figure 2 (Not shown in the image) to complete:

[0116] In step S209, the client reads the element currently at the head of the encrypted queue, which is the ciphertext of the target key.

[0117] In step S210, the client accesses the encrypted cache based on the ciphertext of the target key to obtain the ciphertext of the new key-value pair.

[0118] In step S211, the client accesses the first encrypted state table based on the ciphertext of the target key, so that the ciphertext of the original key-value pair in the first encrypted state table is replaced with the ciphertext of the new key-value pair.

[0119] In step S212, the client deletes the head element in the secret queue and deletes the cache record for the target key in the secret cache, or in other words, deletes the new key-value pair.

[0120] Therefore, the write-back of new key-value pairs in the cache can be completed based on the dense queue.

[0121] The above combination Figure 2 This section introduces the basic implementation methods of the pioneering solution.

[0122] According to another embodiment, considering the actual application of the above basic implementation method, there is a possible situation: some real data records are encrypted and have not been read or written back in the encrypted state table for a long time, and attackers may be able to analyze some sensitive information based on this.

[0123] Therefore, the applicant proposes a further improvement to the above-mentioned basic implementation method (hereinafter referred to as Improved Implementation Method A), which enables the encrypted real data records to be read or written back (such as being read and written periodically) regardless of whether they are accessed by the user, thereby further enhancing the security of the data.

[0124] Specifically, in improved implementation A, the data records, the encrypted table, and the encrypted cache have been further improved, and some interactive steps have been added. The related improvements to the data structure include:

[0125] 1) For each real key-value pair (k i ,v i Add a serial number. At this point, any real data record will include not only the real key-value pair (k...) i ,v i This also includes the corresponding sequence number. It should be noted that the sequence number may differ in different actual data records.

[0126] The sequence number can be a number, letter, symbol, or a combination thereof. To reduce storage complexity, the sequence number can be set to an integer; that is, each key-value pair can be bound to a corresponding integer i. For example, n real data records can be...

[0127] 2) Add a second encrypted table. The plaintext content corresponding to this table also includes the above n real data records, in addition to a second set of fictitious data, and the index of the second encrypted table is the encrypted sequence number in the data record.

[0128] The second set of fictitious data records is also fake data, used to confuse attackers when processing access operations. Each fictitious data record includes a sequence number. For clarity, the sequence numbers in the real and fictitious data records will be referred to as the real sequence number and the fictitious sequence number, respectively. The fictitious sequence number does not overlap with any real sequence number. Furthermore, to reduce storage requirements, the fictitious sequence number can also be an integer.

[0129] It should be noted that the first and second sets of fictitious data records can be different or completely identical. For example, the first set of fictitious data records is... The second set of fictitious data records are as follows: Where dk j Indicates a fictitious key, h represents a fictitious sequence number, ⊥ j and ⊥ hBoth can be randomly filled with content. To improve security, you can set ⊥ j Length and v i The concatenation length between and i is the same, ⊥ h The length of k i and v i The splicing lengths between them are the same.

[0130] Feasibly, assuming that ⊥ j Fill with (dv) j ,j+n), at this point we can directly set h=j+n,⊥ h =(dk j ,dv j ),then,

[0131] 3) Improvements to dense-state caching include:

[0132] The encrypted cache is also configured to store cache records indexed by the ciphertext of the sequence number. In one embodiment, to improve the search efficiency of the encrypted cache, a second search tree (e.g., implemented as an AVL tree) can be configured, similar to the first search tree, where the node index is the ciphertext of the sequence number, and the node's stored content can be empty. Based on this, the key- and sequence-based access operations to the encrypted cache described in this paper can be further refined into access operations to the first and second search trees, respectively.

[0133] It should be understood that the data structures and configuration information involved in the above improvements are also uploaded to the database system after initialization by the client.

[0134] Based on the above further improvements related to data structures, and also Figure 2 Add some interactive steps to the existing content; for details, please refer to... Figure 3 The following steps are shown:

[0135] Step S31: The client determines the first sequence number based on the first access result. It should be noted that the first sequence number is subsequently used for querying the second secret state table. Specifically, this step involves two branches, corresponding to the following two sub-steps:

[0136] Step S31a: If the first access result indicates that the target key-value pair currently exists in the encrypted cache, the first real sequence number involved in several uncached real data records is used as the aforementioned first sequence number. Therefore, subsequent read and write operations will be performed on the real data record corresponding to the first real sequence number, ensuring that even if this real data record is not the user's target access object for a considerable period, attackers cannot detect this through observation and analysis.

[0137] Specifically, the client can access the encrypted cache to obtain the first real sequence number mentioned above. It should be understood that the encrypted cache is pre-configured with a relevant interface, which is used to determine and return the real sequence number corresponding to a real data record that is not currently cached.

[0138] Step S31b: If the first access result indicates that the target key-value pair does not currently exist in the encrypted cache, the first fictitious sequence number involved in the second set of fictitious data records shall be used as the aforementioned first sequence number.

[0139] In one example, the client locally maintains a second variable h for the fictitious sequence number, sets h as the first sequence number, and increments h locally after using it: h = h + 1; assuming the fictitious sequence number takes the value of an integer from n+1 to 2n, when h = 2n+1, h is reset to n+1.

[0140] In another example, the client can randomly select a fictitious serial number as the first serial number.

[0141] Therefore, regardless of whether the target key-value pair exists in the encrypted cache, subsequent queries to the second encrypted table will still occur, preventing attackers from obtaining valid information by observing the access path. Furthermore, when the target key-value pair exists in the encrypted cache, querying the data table using a different real sequence number instead of the target sequence number corresponding to the target key-value pair prevents attackers from knowing the actual query frequency for the target sequence number, thereby further improving data security.

[0142] In step S32, the client performs a second query operation on the second encrypted state table based on the first sequence number, thereby obtaining the returned second data record ciphertext in step S33.

[0143] Specifically, the ciphertext of the first sequence number can be passed to the query interface of the second encrypted table to obtain the returned ciphertext of the second data record. If the first sequence number is the first real sequence number, the obtained ciphertext of the second data record belongs to the real data record ciphertext; if the first sequence number is the first fictitious sequence number, the second data record ciphertext belongs to the fictitious data record ciphertext.

[0144] Step S34: The client performs a third access operation on the encrypted cache based on the encrypted second data record, so that when the first sequence number is the first real sequence number, the corresponding encrypted second data record is cached.

[0145] In implementation method A, no distinction is made between whether the second data record ciphertext is real or fictitious; instead, the second data record ciphertext is directly written into the encrypted state cache.

[0146] In implementation method B, a distinction is made as to whether the second data record ciphertext is real or fictitious. Specifically:

[0147] When the first sequence number is the first real sequence number, the third access operation is performed on the encrypted cache using the first real data record parsed from the second data record ciphertext, which is a real write operation.

[0148] When the first sequence number is a first fictitious sequence number, the third access operation is performed on the encrypted cache, which is disguised as a write operation, so as not to trigger the writing of data.

[0149] It's important to understand that the data corresponding to the first fictitious sequence number is randomly filled and meaningless, so it doesn't need to be actually written to the cache. Furthermore, the interface called when triggering a real write and when faking a write is the same. As for how to achieve faking, special characters can be encapsulated in the data calling the encrypted cache interface, allowing the interface function to recognize the data based on these special characters without performing any further operations. Alternatively, existing related technologies can be used, which will not be elaborated on here.

[0150] The above allows for the insertion of ciphertext of the real data record corresponding to the first real sequence number into the encrypted state cache.

[0151] Step S35: Perform a second enqueue operation on the encrypted queue based on the first sequence number. The encrypted queue is used to write the encrypted second data record back to the first and second encrypted tables when the first sequence number is the first real sequence number.

[0152] It should be noted that the ciphertext of the first sequence number can be enqueued, and / or the ciphertext of the key corresponding to the first sequence number. The key point is that it can be used to index the corresponding cache record.

[0153] Furthermore, the relative execution order of the newly added interactive steps in the improved implementation method A and the interactive steps in the basic implementation method is not unique; it is sufficient that the flow of data is logical.

[0154] The above describes an improved implementation method A for the pioneering solution, which ensures that n real data records will be read or written back regardless of whether they are the user's target access object (e.g., periodically read and written), thereby further enhancing data security.

[0155] Next, taking the example of step S35 above, where the enqueued element of the second enqueue operation includes at least the ciphertext with the first sequence number, the execution of the subsequent write-back phase will be described exemplarily. Specifically, after step S35, the following interactive steps S36-S39 can also be executed ( Figure 3 (Not shown in the image):

[0156] Step S36: The client reads the current head element from the encrypted queue, which includes the ciphertext of the first sequence number.

[0157] For example, the read queue head element may also include the ciphertext of the key corresponding to the first sequence number.

[0158] Step S37: The client performs a fourth access operation on the encrypted cache based on the first sequence number, and obtains the returned fourth access result, which includes the encrypted data record corresponding to the first sequence number.

[0159] In step S38, the client writes the encrypted data records back to the first and second encrypted state tables based on the fourth access result.

[0160] In one implementation, each data record in the second set of fictitious data records includes not only a fictitious serial number but also a fictitious key.

[0161] Based on this, the client can disregard whether the encrypted data record in the fourth access result is real or fictitious, and directly perform write-back operations on the first and second encrypted state tables respectively according to the key and sequence number corresponding to the obtained encrypted data record.

[0162] In another implementation, each data record in the second set of fictitious data records includes only a fictitious serial number, and the fill content therein does not distinguish between fictitious keys and values.

[0163] Based on this, if the fourth access result includes the ciphertext of the first fictitious data record corresponding to the first fictitious sequence number, the ciphertext of the first fictitious data record is written back to the second encrypted state table based on the first fictitious sequence number; and, based on the second fictitious key involved in the first group of fictitious data records, the ciphertext of the corresponding second fictitious data record is written back to the first encrypted state table. It should be understood that the second fictitious key can be randomly selected.

[0164] If the fourth access result includes the encrypted first real data record corresponding to the first real sequence number, the record is written back to the first and second encrypted state tables according to the key and sequence number of the first real data record.

[0165] As shown above, regardless of whether the fourth access result contains real or fictitious encrypted data records, a write-back operation will be performed on the first and second encrypted tables, and the call interface observed by the attacker will be the same.

[0166] In step S39, the client accesses the encrypted cache based on the first sequence number, causing the cache record corresponding to the first sequence number in the encrypted cache to be deleted. It should be understood that cache records indexed by both the key and the sequence number can be deleted simultaneously.

[0167] Therefore, the cache record for the first sequence number can be written back based on the dense queue.

[0168] The above combination Figure 3This section introduces an improved implementation method A for the pioneering solution.

[0169] According to another embodiment, in order to improve the "operation write-back phase" (see...) Figure 1 To improve the execution stability, an improved implementation method B is proposed, wherein the improvements can be implemented based on the basic implementation method or the improved implementation method A.

[0170] The improvements in Implementation Method B include further improvements to the dense-state buffer and dense-state queue, as well as adaptive adjustments to relevant steps in the write-back phase. Specifically, the further improvements to the dense-state buffer and dense-state queue include:

[0171] 1) Add a target attribute field to cached records in the encrypted cache. This field indicates whether the corresponding cached record has been written back to the encrypted table. The first attribute value of this field (e.g., 1) indicates that it has been written back to the encrypted table, and the second attribute value (e.g., 0) indicates that it has not been written back to the encrypted table. For example, a target attribute field can be added to nodes in the first search tree. In addition, cached records are also associated with corresponding access operation timestamps.

[0172] 2) See Figure 4 The encrypted queue is divided into a first sub-queue and a second sub-queue. The first sub-queue records the access operation indices (including data record indices and access operation timestamps) that have been written back to the encrypted table, while the second sub-queue stores the access operation indices that have not yet been written back to the encrypted table. Generally, the first and second sub-queues are of equal length.

[0173] Furthermore, adaptive adjustments have been made to relevant steps in the write-back phase. Briefly, the access operation index first enters the second sub-queue. After the corresponding data record is written back to the first encrypted table (or both the first and second encrypted tables) according to the second sub-queue, the access operation index is removed from the second sub-queue and moved into the first sub-queue. Then, according to the first sub-queue, the cache record corresponding to the access operation index is deleted from the encrypted cache, and the access operation index is removed from the first sub-queue. It should be understood that writing back the data table according to the second sub-queue and deleting the cache according to the first sub-queue can be triggered separately, thus supporting cache deletion only if the data table write-back is error-free, increasing the stability and reliability of cache record write-back.

[0174] To illustrate this clearly, the following provides an example of the two sub-stages included in the write-back phase: writing back to the cryptic table and deleting from the cryptic cache.

[0175] 1. Write back the secret state table. For details, please refer to... Figure 5 The following steps are shown in the figure:

[0176] In step S51, the client reads the element currently at the head of the second sub-queue, also known as the current access operation index, which includes the corresponding data record identifier (key and / or sequence number) and the first operation timestamp. It should be understood that the data record identifier can be referred to as the data record index.

[0177] For example, the data record identifier can be the ciphertext of the target key written in step S208, or it can be the ciphertext of the first sequence number written in step S35.

[0178] In step S52, the client performs a sixth access operation on the encrypted cache based on the data record identifier to obtain the corresponding current data record ciphertext and the second operation timestamp.

[0179] Step S53: The client compares whether the first operation timestamp and the second operation timestamp are consistent.

[0180] In step S54a, if the two timestamps match, the client performs a write-back operation on all encrypted tables based on the current data record ciphertext. For example, the write-back operation is performed on the first and second encrypted tables.

[0181] In step S55a, the client performs a seventh access operation on the encrypted cache based on the data record identifier in the current access operation index, so that the target attribute of the cache record corresponding to the data record identifier is set to the first attribute value, which indicates that the cache record has been written back.

[0182] In step S54b, if the two timestamps are found to be inconsistent, the client performs a write-back operation on all the secret state tables based on the fictitious data record identifier.

[0183] It's important to understand that if two timestamps are inconsistent, it means that the data record targeted by the current access operation index has been accessed by other operations after the current access operation was performed, so there's no need to write it back. For example, suppose multiple operations are performed on the value corresponding to the same key K over a period of time, such as the balance of the same account changing 10 times, then only the balance after the 10th change needs to be written back. Furthermore, to mislead attackers, write operations targeting the encrypted table are still designed to be performed.

[0184] In one embodiment, a write-back operation is performed on the first encrypted state table based on a fictitious key. In another embodiment, write-back operations are performed on the first and second encrypted state tables based on a fictitious key and a fictitious sequence number, respectively. It should be understood that the fictitious key and fictitious sequence number can be randomly selected locally by the client. In addition, the content written back can be the content filled in when constructing the encrypted state table during the preparation stage, or it can be randomly generated, or it can be empty.

[0185] In step S55b, the client performs a seventh access operation on the encrypted cache based on the data record identifier in the current access operation index. This is a disguised operation to change the target attribute value, but it will not actually trigger a change. It should be noted that the method of disguise can be found in the relevant descriptions in the preceding embodiments, or existing related technologies can be used, which will not be elaborated upon here.

[0186] In step S56, the client removes the current access operation index from the second sub-queue and moves it to the tail of the first sub-queue.

[0187] Based on the above, the cached records after the access operation can be written back to the secret state table according to the second sub-queue.

[0188] 2) Remove from the dense cache. For details, please refer to... Figure 6 The following steps are shown in the figure:

[0189] Step S61: The client reads the element currently at the head of the queue from the first sub-queue, also known as the current access operation index, which includes the corresponding data record identifier (key and / or sequence number) and the first operation timestamp.

[0190] In step S62, the client performs an eighth access operation on the encrypted cache based on the data record identifier to obtain the corresponding third operation timestamp and target attribute value.

[0191] Step S63: The client determines whether the target attribute value indicates that the cached record has been written back to the secret state table.

[0192] Step S64: If it is determined that the data has been written back, the client compares whether the first operation timestamp and the third operation timestamp are consistent.

[0193] In step S65, if the two timestamps are found to be consistent, the client triggers the deletion of the cache record corresponding to the data record identifier.

[0194] In step S66, if it is determined that the data has not been written back or the two timestamps are inconsistent, the client does not delete the cached record corresponding to the data record identifier. It should be noted that an access operation disguised as deletion can be performed.

[0195] Step S67: The client removes the current access operation index from the first sub-queue.

[0196] Based on the above, cached records can be deleted according to the first sub-queue.

[0197] The above describes the basic implementation, improved implementation A, and improved implementation B of the pioneering solution. To aid understanding, a specific example is provided below to fully illustrate the implementation of the pioneering solution, which integrates improved implementations A and B. It should also be noted that, for brevity, the distinction between plaintext and ciphertext has been omitted in the description of this implementation example. For instance, "key" may refer to the ciphertext of the key; those skilled in the art can determine whether it refers to plaintext or ciphertext based on the context (e.g., see the relevant descriptions in the foregoing embodiments).

[0198] First, the data structures involved in the implementation example of this solution are described. The construction of these structures can be regarded as the initialization process of the implementation example of this solution on the user side. After the user completes the initialization, these structures are uploaded to the cloud service provider for subsequent data management and access.

[0199] 1. Key-value pair portion (corresponding to the above n actual data records): Given key-value pairs and each key-value pair (k i ,v i ) and integers i Binding, meaning the key-value pair is stored in the form of (k i ,v i (i). It should be noted that k i It can be any string, and it does not have to be consecutive.

[0200] 2. Hash table section (corresponding to the aforementioned secret state table):

[0201] 2.1) Two hash tables are used to build an index for all key-value pairs: Hash table A builds an index for the key value of each key-value pair, i.e., the index for each key-value pair (k... i ,v i The storage location of i) is Accordingly, hash table B takes the bound integer i as input and stores the key-value pair at location: The above and This represents two independent PRF functions, known only to the user. Furthermore, although no hash function is used, this table is still referred to as a hash table in this example scheme.

[0202] 2.2) Hash tables A and B each store an additional n data items, denoted as ... and The value of ⊥ can be filled arbitrarily, dk i This requires special settings by the user to ensure: (1) dk i The regularity of the strings means that users do not need constant-level or higher storage to record them; (2) dk iIt does not overlap with any real key-value pairs in the database.

[0203] 2.3) Hash tables A and B are both 2^n in size. Both hash tables guarantee that all key-value pairs are encrypted with AES, each key-value pair being encrypted with AES into a random string of the same length. When multiple pieces of data are mapped to the same location, resulting in a collision, the user can store them in a linked list at that location.

[0204] 3. AVL tree section (corresponding to the search tree above):

[0205] 3.1) This part uses an unobtrusive data structure for storing AVL trees. Such a structure can be implemented using existing technologies, and this implementation example further innovates and modifies the AVL tree based on these existing technologies.

[0206] Specifically, this implementation example constructs two unintentional data structures, AVL trees C and D, for the encrypted database. C is built based on the keys in key-value pairs, and D is built based on the integers bound to the key-value pairs. Furthermore, the storage of the values ​​in the key-value pairs and the operation timestamps can be flexibly designed. In one possible design, AVL tree C stores the key and timestamp, and AVL tree D stores the sequence number and value. In another possible design, both AVL trees C and D store complete data records.

[0207] In another possible design approach, only the node indexes in the AVL tree D contain valid information. For example, the index of a node can indicate that the corresponding data record is cached, while other valid information, such as key-value pairs and timestamps, are stored in the AVL tree C. The online query process in the implementation example of this solution will be described later (see [link]). Figure 7 When discussing this topic, we will introduce it in conjunction with this design approach.

[0208] The modification to C in this implementation example is the addition of an attribute `op` (corresponding to the target attribute mentioned above) to the key-value pairs corresponding to each node. This attribute indicates whether the most recent operation on the key-value pair was retrieved back into the AVL tree (or not written back to the hash table) or written back to the hash table. The modification to D in this implementation example is the addition of two attributes (sign) to the key-value pairs corresponding to each node. L ,sing R The sign flag indicates whether the left and right subspaces of the node have been fully visited. If the integer corresponding to the node is 32, then sign... L =False indicates that the key-value pairs corresponding to the integers {1,2,…,31} have all been stored in the left subtree of this node. This can improve search efficiency, including improving search efficiency when querying the real sequence number corresponding to the real data record that has not been cached.

[0209] 3.2) The two AVL trees are mainly used to record the user's past c operations. By recording the key-value pairs accessed in the past c query operations, this implementation example ensures that the access patterns of the key-value pairs targeted by the current query and the previous c queries on the hash table are independent and random, thereby preventing attackers from inferring the user's query information, i.e., the user's sensitive information, from the access patterns on the hash table.

[0210] 4. Queue Q (corresponding to the dense queue mentioned above): The queue records the query order of key-value pairs in the past c operations. It records the most recently accessed key-value pair at the tail of the queue and removes the earliest accessed key-value pair from the head of the queue. Simultaneously, it retains the timestamp of each key-value pair operated on within the queue. If the timestamp indicates that the key-value pair was operated on before the past c operations, then the key-value pair can be operated on (either written back to the hash table or directly deleted from the queue).

[0211] Next, the online query process of this implementation example is described. The user locally stores variables named j and h, with initial values ​​of 1 and n+1 respectively. Suppose the user initiates a query to the cloud service provider, requesting an operation on the key-value pair (k,v) (corresponding to the target access operation mentioned above). This operation can be deletion, modification, query, and various variations and combinations of key-value storage.

[0212] See Figure 7 This shows 10 query operations to the database and several write operations to the dense queue. It should be noted that the access path observed by the observer is consistent in the following three cases:

[0213] Scenario 1: The key-value pair that the user wants to query is in AVL tree C, and the attribute op of the key-value pair indicates that the key-value pair has not been written back to the data table.

[0214] Scenario 2: The key-value pair that the user wants to query is in the AVL tree C, and the attribute op of the key-value pair indicates that the key-value pair has been written back to the data table.

[0215] Case 3: The key-value pair that the user wants to query is not in AVL tree C.

[0216] In addition, it should be noted that there is no difference in the user's perception for the above three situations. The user only needs to see the final business result through the client, such as the successful transfer result or the changed account balance.

[0217] The following are Figure 7 A brief introduction to the content shown:

[0218] The first query operation is used to check whether the key-value pair is in the AVL tree C, and to query the node's attribute op.

[0219] The first query result shows that all three of the above possibilities exist.

[0220] The second query operation is used to retrieve key-value pairs from the AVL tree C. In cases 1 or 2, this query operation is a real operation; in case 3, it is a disguised operation.

[0221] The second query result: In case 1 or 2, it returns the original key-value pair corresponding to the target key. In case 3, it may return null values ​​or meaningless results.

[0222] The third query operation is used to find an unvisited integer d1 from the AVL tree D. In cases 1 or 2, this query operation is a real operation; in case 3, it is a disguised operation.

[0223] The third query result: In case 1 or 2, it returns the integer d1. In case 3, it may return a null value or a meaningless result.

[0224] The fourth query operation updates the key-value pairs in the AVL tree C, specifically replacing them with new key-value pairs obtained after performing a target access operation on the original key-value pairs locally on the client. In cases 1 or 2, this query operation is a real operation; in case 3, it is a disguised operation. Furthermore, in case 2, the `op` attribute value is modified to indicate that the data has not been written back to the table.

[0225] The fourth query result: In case 1 or 2, it returns a successful update notification; in case 3, it may return a null value or a meaningless result. Furthermore, if it returns an update failure notification, the current process is terminated and a rollback is performed.

[0226] The fifth query operation: A query is performed on hash table A using the key; this is the actual query operation. In cases 1 or 2, the key used is not the target key corresponding to the user's actual query intent, but a locally determined fictitious key j. After the query is completed, j is incremented (j = j + 1), and when j = b + 1, j is reset to 1. In case 3, the key used is the target key.

[0227] The fifth query result: In case 1 or 2, it returns meaningless data corresponding to the fictitious key j. In case 3, it returns the target value.

[0228] The first enqueue operation: This is used to record the 5th query operation (which is a query operation on the data table) in the queue. The record can be the key used and the operation timestamp.

[0229] The sixth query operation: This is a real query operation that uses an integer to query hash table B. In cases 1 or 2, the integer used is the integer d1 obtained in the third query operation. In case 3, the integer used can be a fictitious sequence number h, the integer d1, or a locally randomly selected fictitious sequence number. It should be understood that if the integer used is h, then after completing the query, h is incremented, i.e., h = h + 1. When h = 2n + 1, h is reset to n + 1.

[0230] The sixth query result: In case 1 or 2, it returns the key-value pair corresponding to the integer d1, which is the actual key-value pair. In case 3, it returns meaningless data.

[0231] The second enqueue operation: This is used to record the 6th query operation (which is a query operation on the data table) in the queue. The recorded data can be the integer used and the operation timestamp.

[0232] The 7th query operation updates the key-value pairs in the AVL tree C. Specifically, it replaces them with new key-value pairs obtained after performing a target access operation on the original key-value pairs locally on the client side, and sets the `op` attribute value to indicate that the data has not been written back to the table. In cases 1 or 2, this query operation is a spoofing operation; in case 3, this query operation is a real operation.

[0233] The 7th query result: In case 1 or 2, it may return a null value or a meaningless result; in case 3, it returns a success update notification. Furthermore, if a failure update notification is returned, the current process is terminated and a rollback is performed.

[0234] The 8th query operation: Insert the target index corresponding to the target key into AVL tree D. This is a spoofing operation in case 1 or 2, and a real operation in case 3.

[0235] The 8th query result: In case 1 or 2, the returned result may be null or meaningless; in case 3, the returned result is a successful update notification. Furthermore, if the returned result is a failed update notification, the current process is terminated and a rollback is performed.

[0236] The third enqueue operation: Write the index of the new key-value pair (such as the target key and target sequence number) and the operation timestamp (e.g., the nth update operation at what time) into queue Q.

[0237] The 9th query operation updates the key-value pairs in the AVL tree C by inserting the actual key-value pair corresponding to the integer d1. In cases 1 or 2, this query operation is a real operation; in case 3, this query operation can be either a real operation or a disguised operation.

[0238] The 9th query result: In case 1 or 2, it may return a successful update notification; in case 3, it may return a successful update notification or a meaningless result such as null. Furthermore, if it returns a failed update notification, the current process will terminate and a rollback will be performed.

[0239] The 10th query operation: Insert the integer d1 into the AVL tree D. This is a real operation in case 1 or 2, and in case 3 it can be either a real operation or a disguised operation.

[0240] The 10th query result: In case 1 or 2, it may return a success update notification; in case 3, it may return a success update notification or a meaningless result such as null. Furthermore, if it returns a failure update notification, the current process will terminate and a rollback will be performed.

[0241] The fourth enqueue operation: Write the index of the key-value pair corresponding to the integer d1 (such as the integer d1 or its corresponding key) and the operation timestamp (e.g., the nth update operation at what time) into the queue Q.

[0242] The above combination Figure 7 This section describes the online query process for implementing this solution.

[0243] Afterwards, cached records can be written back to the data table based on queue Q. In one triggering method, the user manually checks the timestamps of key-value pairs in queue Q. If some timestamps correspond to operations earlier than the most recent c operations, then the write-back of these operations or their deletion from the queue is triggered. In another triggering method, when queue Q is about to overflow, the user can be notified to trigger the write-back of cached records.

[0244] Specifically, queue Q is divided into two sub-queues (Q1, Q2), where Q2 retains key-value pairs that have not been written back to the hash table, and Q1 retains key-value pairs that have been written back to the hash table. For details on how to write cached records back to the hash table based on Q2 and how to delete cached records based on Q1, please refer to the relevant descriptions in the preceding embodiments, which will not be repeated here.

[0245] Furthermore, users do not need to push all key-value pairs that meet the criteria (timestamps earlier than the most recent c operations) at once in every operation. The worst-case performance of a single operation can be reduced by distributing the operation evenly across multiple operations. In addition, when writing back a single key-value pair to both hash tables, the user will write back the key-value pair simultaneously as well as its corresponding integer value, ensuring that both hash tables retain the latest version of the key-value pair.

[0246] The above provides an implementation example of this solution.

[0247] In summary, by adopting the pioneering solutions disclosed in the embodiments of this specification, the following beneficial effects can be achieved:

[0248] 1) Effectively reduce solution costs: All key-value pairs are stored in ordinary encrypted data tables, and only a cache that supports an unobtrusive mechanism needs to be built to store a small portion of the key-value pairs.

[0249] 2) Effectively ensures data privacy and security: The encrypted cache supports an undetectable mechanism, and regardless of whether the key-value data to be accessed exists in the cache, the access path to the database system observed by the attacker is consistent.

[0250] 3) Supports dynamic security: Users can customize the length of the encrypted queue or the maximum number of cached access operations, thereby dynamically adapting to different security level requirements and effectively balancing security and database system performance costs.

[0251] Corresponding to the above processing method, embodiments of this specification also disclose a processing apparatus for database access operations. It should be noted that the database includes a first encrypted table, the plaintext content of which includes n real data records and a first set of fictitious data records, wherein each real data record includes a real key-value pair; the index of the first encrypted table is the ciphertext of the keys in the data records, and the processing apparatus is integrated into the client. See also Figure 8 The schematic processing device 800 includes the following functional modules:

[0252] The first access module 802 is configured to perform a first access operation on the encrypted cache built by an unintentional mechanism in the database based on the target key, and obtain a first access result, which indicates whether the key-value pair corresponding to the target key exists in the encrypted cache. The first query module 804 is configured to perform a first query operation on the first encrypted table based on a first key, and obtain the encrypted text of a first data record; the determination of the first key includes: if the first access result indicates that the target key does not exist, the target key is used as the first key; otherwise, the first fictitious key involved in the first group of fictitious data records is used as the first key. The second access module 806 is configured to perform a second access operation on the encrypted cache based on the new key-value pair corresponding to the target key, so that the encrypted text of the new key-value pair is cached; the new key-value pair is obtained by performing a target access operation on the original key-value pair, and the original key-value pair is determined based on the encrypted text of the first data record and the first access result. The first enqueue module 808 is configured to perform a first enqueue operation on the encrypted queue in the database based on the target key, and the encrypted queue is used to write the encrypted text of the new key-value pair back to the first encrypted table.

[0253] In one embodiment, determining the original key-value pair includes: if the first access result indicates that the original key-value pair exists, parsing the original key-value pair from the access result; otherwise, parsing the original key-value pair from the first data record ciphertext.

[0254] In one embodiment, the queue length of the encrypted queue is configured by the logged-in user of the client.

[0255] In one embodiment, each real data record further includes a sequence number added to its key-value pair; the database further includes a second encrypted table, the plaintext content of which includes the n real data records and a second set of fictitious data records; the index of the second encrypted table is the encrypted sequence number in the data record. The processing device 800 further includes:

[0256] The second query module 810 is configured to perform a second query operation on the second encrypted state table based on the first sequence number to obtain the encrypted text of the second data record. The determination of the first sequence number includes: if the first access result indicates that the first fictitious sequence number involved in the second group of fictitious data records is not present, then the first real sequence number involved in several currently uncached real data records is used as the first sequence number. The third access module 812 is configured to perform a third access operation on the encrypted state cache, such that the encrypted text of the second data record is cached when the first sequence number is the first real sequence number. The second enqueue module 814 is configured to perform a second enqueue operation on the encrypted state queue based on the first sequence number. The encrypted state queue is used to write the encrypted text of the second data record back to the first and second encrypted state tables when the first sequence number is the first real sequence number.

[0257] Furthermore, in a specific embodiment, the third access module 812 is specifically configured as follows: when the first sequence number is the first real sequence number, the third access operation is performed on the encrypted cache using the first real data record parsed from the second data record ciphertext, which is a real write operation; when the first sequence number is the first fictitious sequence number, the third access operation is performed on the encrypted cache, which is disguised as a write operation, so as not to trigger data writing.

[0258] On the other hand, in a specific embodiment, the processing device 800 further includes a first write-back module 816, configured to: read the current head element from the encrypted queue, which is the ciphertext of the first sequence number; perform a fourth access operation on the encrypted cache to obtain the current data record ciphertext corresponding to the first sequence number; and, if the first sequence number is the first real sequence number, write the current data record ciphertext back to the first and second encrypted tables.

[0259] Furthermore, in one example, the first write-back module 816 is also configured to: when the first sequence number is the first fictitious sequence number, write the current data record ciphertext back to the second encrypted state table based on the first fictitious sequence number, and perform a write-back operation on the first encrypted state table based on the second fictitious key involved in the first group of fictitious data records.

[0260] On another front, in a specific embodiment, the encrypted cache includes a first search and a second search tree constructed based on an unintentional mechanism, where the node indices in the first and second search trees are the encrypted keys and sequence numbers in the data records, respectively. The first access module 802 is specifically configured to: perform the first access operation on the first search tree based on the target key; wherein, taking the first real sequence number involved in several currently uncached real data records as the first sequence number includes: performing a fifth access operation on the second search tree to obtain the first real sequence number.

[0261] Furthermore, in one example, the nodes in the first search tree are configured with a target attribute, wherein the first attribute value corresponding to the target attribute indicates that the key-value pair stored in this node has been written back to the secret state table, and the second attribute value indicates the opposite; wherein, the second access operation also causes: the target node corresponding to the target key to have the second attribute value, and the target node to store the operation timestamp for the new key-value pair.

[0262] The encrypted queue includes a first and a second sub-queue, which are used to store data record indexes that have been written back and those that have not been written back to the encrypted table, respectively. Each queue element in the encrypted queue also includes a corresponding operation timestamp. The processing device 800 further includes a second write-back module 818, configured to: read the current head element from the second sub-queue, which includes the ciphertext of the target key and the corresponding first operation timestamp; perform a sixth access operation on the encrypted cache based on the target key to obtain the current data record ciphertext and the corresponding second operation timestamp corresponding to the target key; if the first and second operation timestamps match, perform write-back operations on the first and second encrypted tables based on the current data record ciphertext; perform a seventh access operation on the first search tree based on the target key, so that the target node is set to have the first attribute value; and remove the ciphertext of the target key from the second sub-queue and move it to the tail of the first sub-queue.

[0263] Furthermore, in one example, the second write-back module 818 is also configured to: if the first operation timestamp and the second operation timestamp are found to be inconsistent, perform write-back operations on the first and second secret state tables respectively based on the first set of fictitious data and / or the second set of fictitious data.

[0264] In one example, the processing device 800 further includes a cache deletion module 820, configured to: read the current head element from the first sub-queue, which is the ciphertext of the target key and the corresponding first operation timestamp; perform an eighth access operation on the encrypted cache based on the target key to obtain the third operation timestamp corresponding to the target key; if the first operation timestamp and the third operation timestamp are found to be consistent, delete the node corresponding to the target key from the first and second search trees, otherwise do not delete it; delete the current head element in the first sub-queue.

[0265] On the other hand, in a specific embodiment, the first and second secret state tables are initially uploaded to the database by the client.

[0266] It should be noted that for a description of the above-mentioned functional modules or functional units, please refer to the relevant description of the process method in the foregoing embodiments.

[0267] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0268] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for processing database access operations, wherein the database includes a first encrypted table, the plaintext content of which includes n real data records and a first set of fictitious data records, wherein each real data record includes a real key-value pair; The index of the first encrypted table is the ciphertext of the key in the data record; The method is applied to the client and includes: Based on the target key, a first access operation is performed on the encrypted cache built on an unintentional mechanism in the database to obtain a first access result, which indicates whether the key-value pair corresponding to the target key exists in the encrypted cache. Based on the first key, a first query operation is performed on the first encrypted table to obtain the encrypted text of the first data record; the determination of the first key includes: if the first access result indicates that it does not exist, the target key is used as the first key; otherwise, the first fictitious key involved in the first group of fictitious data records is used as the first key. Based on the new key-value pair corresponding to the target key, a second access operation is performed on the encrypted cache, so that the ciphertext of the new key-value pair is cached; the new key-value pair is obtained by performing a target access operation on the original key-value pair, and the original key-value pair is determined based on the first data record ciphertext and the first access result; Based on the target key, a first enqueue operation is performed on the encrypted queue in the database, the encrypted queue being used to write the ciphertext of the new key-value pair back to the first encrypted table.

2. The method according to claim 1, wherein determining the original key-value pair comprises: If the first access result indicates that the original key-value pair exists, the original key-value pair is parsed from the access result. Otherwise, the original key-value pair is parsed from the encrypted first data record.

3. The method according to claim 1, wherein, The queue length of the dense queue is configured by the logged-in user of the client.

4. The method according to claim 1, wherein, Each real data record also includes a sequence number added to its key-value pair; the database also includes a second encrypted table, the plaintext content of which includes the n real data records and the second set of fictitious data records; the index of the second encrypted table is the encrypted sequence number in the data record; wherein, the method further includes: Based on the first sequence number, a second query operation is performed on the second encrypted table to obtain the encrypted text of the second data record; the determination of the first sequence number includes: if the first access result indicates that there is no such indication, the first fictitious sequence number involved in the second group of fictitious data records is taken as the first sequence number; otherwise, the first real sequence number involved in several real data records that are not currently cached is taken as the first sequence number. A third access operation is performed on the encrypted cache so that, when the first sequence number is the first real sequence number, the encrypted text of the second data record is cached; Based on the first sequence number, a second enqueue operation is performed on the encrypted queue. The encrypted queue is used to write the encrypted second data record back to the first and second encrypted tables when the first sequence number is the first real sequence number.

5. The method according to claim 4, wherein, Based on the second data record ciphertext, a third access operation is performed on the encrypted cache, including: When the first sequence number is the first real sequence number, the third access operation is performed on the encrypted cache using the first real data record parsed from the second data record ciphertext, which is a real write operation. When the first sequence number is the first fictitious sequence number, the third access operation is performed on the encrypted cache, which is disguised as a write operation, so as not to trigger the writing of data.

6. The method according to claim 4, wherein, After performing a second enqueue operation on the dense-state queue based on the first sequence number, the method further includes: Read the current head element from the encrypted queue, which is the ciphertext of the first sequence number; Perform a fourth access operation on the encrypted cache to obtain the ciphertext of the current data record corresponding to the first sequence number; If the first sequence number is the first real sequence number, the current data record ciphertext is written back to the first and second encrypted state tables.

7. The method of claim 6, further comprising: When the first sequence number is the first fictitious sequence number, the current data record ciphertext is written back to the second encrypted state table based on the first fictitious sequence number, and the first encrypted state table is written back based on the second fictitious key involved in the first group of fictitious data records.

8. The method according to claim 4, wherein, The encrypted cache includes a first search tree and a second search tree constructed based on an unintentional mechanism, where the node indices in the first and second search trees are the encrypted keys and sequence numbers in the data records, respectively. The first access operation on the encrypted cache constructed based on the unintentional mechanism in the database, based on the target key, includes: Based on the target key, the first access operation is performed on the first search tree; Among them, the first real sequence number involved in a number of real data records that are not currently cached is used as the first sequence number, including: Perform a fifth access operation on the second search tree to obtain the first true sequence number.

9. The method according to claim 8, wherein, The nodes in the first search tree are configured with target attributes. The first attribute value corresponding to the target attribute indicates that the key-value pair stored in this node has been written back to the secret state table, and the second attribute value indicates the opposite. The second access operation also causes the target node corresponding to the target key to have the second attribute value, and the target node to store the operation timestamp for the new key-value pair. The encrypted queue includes a first sub-queue and a second sub-queue, respectively used to store data record indexes that have been written back and those that have not been written back to the encrypted table. Each queue element in the encrypted queue also includes a corresponding operation timestamp. The first enqueue operation is performed on the second sub-queue. After performing the first enqueue operation, the method further includes: Read the current head element from the second sub-queue, which includes the ciphertext of the target key and the corresponding first operation timestamp; Based on the target key, a sixth access operation is performed on the encrypted cache to obtain the current data record ciphertext corresponding to the target key and the corresponding second operation timestamp; If the first operation timestamp and the second operation timestamp are found to be the same, write-back operations are performed on the first and second encrypted tables based on the current data record ciphertext. Based on the target key, a seventh access operation is performed on the first search tree, such that the target node is set to have the first attribute value; The ciphertext of the target key is removed from the second sub-queue and moved to the tail of the first sub-queue.

10. The method of claim 9, further comprising: If the first operation timestamp and the second operation timestamp are found to be inconsistent, write-back operations are performed on the first and second encrypted tables based on the first set of fictitious data and / or the second set of fictitious data, respectively.

11. The method according to claim 9, wherein, After removing the ciphertext of the target key from the second sub-queue and moving it to the tail of the first sub-queue, the method further includes: Read the current head element from the first sub-queue, which is the ciphertext of the target key and the corresponding first operation timestamp; Based on the target key, the eighth access operation is performed on the encrypted cache to obtain the third operation timestamp corresponding to the target key; If the first operation timestamp and the third operation timestamp are found to be the same, the node corresponding to the target key is deleted from the first and second search trees; otherwise, it is not deleted. Delete the current head element from the first sub-queue.

12. The method according to claim 4, wherein, The first and second secret state tables are initially uploaded to the database by the client.

13. A processing apparatus for database access operations, the database including a first encrypted table, the plaintext content of which includes n real data records and a first set of fictitious data records, wherein each real data record includes a real key-value pair; The index of the first encrypted table is the ciphertext of the key in the data record; The device is integrated into the client and includes: The first access module is configured to perform a first access operation on the encrypted cache built by the unintentional mechanism in the database based on the target key, and obtain a first access result, which indicates whether the key-value pair corresponding to the target key exists in the encrypted cache. The first query module is configured to perform a first query operation on the first encrypted table based on a first key to obtain the encrypted first data record; the determination of the first key includes: if the first access result indicates that it does not exist, the target key is used as the first key; otherwise, the first fictitious key involved in the first group of fictitious data records is used as the first key. The second access module is configured to perform a second access operation on the encrypted cache based on the new key-value pair corresponding to the target key, so that the ciphertext of the new key-value pair is cached; the new key-value pair is obtained by performing a target access operation on the original key-value pair, and the original key-value pair is determined based on the first data record ciphertext and the first access result; The first enqueue module is configured to perform a first enqueue operation on the encrypted queue in the database based on the target key. The encrypted queue is used to write the ciphertext of the new key-value pair back to the first encrypted table.

14. A computer-readable storage medium having a computer program stored thereon, wherein, When the computer program is executed in the computer, it causes the computer to perform the method according to any one of claims 1-12.

15. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-12.

Images