Encryption database-oriented B+ tree-based ciphertext efficient join query method and system

Abstract

The application discloses a kind of face to face encryption database based on B+ tree's ciphertext efficient connection query method and system, by constructing support dynamic adjustment with structure, traditional static connection query mechanism is extended to dynamic scene.Wherein, for storing the inverted index of non-connection attribute value, and then B+ tree structure is used to store the cross label processed by randomization.In data update, client generates ciphertext according to operation type (addition or deletion) and uploads, server is dynamically adjusted B+ tree node or is stored in revocation list according to this.In query stage, server is searched by synthesizing query token and in B+ tree, realizes tuple level's equivalent connection.This application fundamentally eliminates the false positive problem of bloom filter, supports asynchronous revocation mechanism, while ensuring the stability of search performance under large-scale encrypted data set, significantly improves the practicability of encrypted database under complex business logic.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of cryptography and information security technology, and relates to a method and system for ciphertext retrieval in a database, particularly a method and system for efficient ciphertext join (table) query based on B+ tree for encrypted databases. Background Technology

[0002] With the widespread adoption of cloud computing, individuals and organizations tend to upload large-scale data to servers, making data outsourcing a mainstream trend. This approach not only alleviates the burden of local storage but also provides users with high-quality data services. However, untrusted servers raise serious privacy concerns about this technology. Potential attack threats lead most users to choose to upload encrypted data. This presents a new challenge: how to perform efficient queries on encrypted databases.

[0003] While ideal privacy encryption schemes (such as fully homomorphic encryption) are secure, they incur significant computational overhead, making them unsuitable for large-scale databases. Hardware solutions (such as TEEs) rely on trusted hardware and are vulnerable to side-channel vulnerabilities. To address this issue, the concept of symmetric searchable encryption emerged. Symmetric searchable encryption allows users to perform keyword-based queries on encrypted databases. This process achieves high search efficiency and scalability by allowing the server to learn a small amount of information (leaking information) during query execution. However, this technology is primarily suitable for document-oriented encrypted database designs and cannot meet the core requirement of relational databases—join queries.

[0004] Currently, the mainstream search protocols supporting join queries include the following: The CryptDB system, proposed by Popa et al., based on attribute-preserving encryption, supports most SQL operations and achieves equi-join queries by re-encrypting and comparing the ciphertext during the query. However, Naveed et al. pointed out that the data security of this deterministic encryption strongly relies on the underlying plaintext distribution, making it vulnerable to attacks. Kamara and Moataz et al. proposed SPX, a scheme that supports join queries by pre-computing all possible joins; however, this design lacks flexibility and incurs high storage overhead. Hahn et al. proposed an alternative construct that provides security by selectively displaying joinable tuples that meet the requirements, but it still essentially uses deterministic encryption, which presents security issues.

[0005] Julta and Patranabis developed a novel join mechanism, JXT, which requires no pre-computation. It uses two data structures, TSet and XSet, to store the inverted index and encoding of all attribute-value pairs, enabling single-table searches. The results of join queries are then obtained by combining these structures. JXT only supports natural joins, and its search complexity is O(n log n). Subsequently, Du et al. extended the scheme, proposing JXT+ and JXT++, which support multi-table equi-join queries. Xu et al. optimized the scheme, proposing OTJXT, which enables the design of equi-joins with sublinear complexity and minimal leakage on encrypted relational databases.

[0006] However, these methods only support static database join queries and cannot handle dynamic database additions and deletions. Therefore, there is an urgent need for a join query scheme that can achieve efficient querying on relational databases while also supporting dynamic additions and deletions, in order to meet the needs of practical database information processing. Summary of the Invention

[0007] To address the aforementioned technical issues, this invention proposes a method and system for efficient encrypted join query based on B+ trees for encrypted databases, providing users with more flexible data processing technology that better meets their actual needs.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is: a method for efficient encrypted join query based on B+ tree for encrypted databases, comprising an initialization phase, a data update phase, and a query phase; and including two data structures. and , Inverted index for non-connected attribute values, Store cross-labels using a B+ tree structure. Cross-label The string type is converted to a 256-bit unsigned integer as the key value of the B+ tree; during the initialization phase, the client generates the key. Preprocess each table in the plaintext database; calculate cross-labels based on join attribute values ​​and record indexes. And construct a B+ tree structured encrypted index. ; Build inverted indexes for non-connected attribute values During the data update phase, the client generates encrypted data based on the operation type and uploads it. The server then dynamically adjusts the B+ tree nodes or stores them in the revocation list accordingly. During the query phase, the server synthesizes query tokens and performs logarithmic-level retrieval in the B+ tree to achieve tuple-level equi-joins.

[0009] Preferably, during the initialization phase, the client generates a key for the pseudo-random function. ,in, Indicates an index on records in the table. The key for randomization This indicates the value of the join attribute in the table. The key for randomization This represents the random factor introduced in the scheme. or The key for randomization This represents the random factor introduced in the scheme. or The key for randomization The master key is used to access the values ​​of each non-connected attribute in the table. Derivate the corresponding key; initialize , ;in, Used to store cross labels , Used to store deleted cross tags; key Used for Processing is required; only the entity possessing the key can perform the operation. Processing; Key Used for Processing is required; only the entity possessing the key can perform the operation. Process it; Indicates to Perform initialization; for the plaintext database Each table in the database undergoes preprocessing; among them, the plaintext database... It stores a collection formed after preprocessing a series of table data. This represents the i-th table. This refers to the number of tables stored in the encrypted database during the initialization phase (the encrypted database stores the initial table data, while the plaintext database refers to the database formed after preprocessing a series of table data). Each table consists of a series of attribute values ​​and corresponding record tuples. composition; This represents the set after processing the table data, that is, the set of data processed from the table. The set of non-connected attribute values ​​in each table; calculate Among them, the key Used for Processing is required; only the entity possessing the key can perform the operation. To process, Indicates the first The set corresponding to Zhang's table Indicates to Initialize; Output key and encrypted database .

[0010] Preferably, the plaintext database Each table in the database undergoes preprocessing, specifically including the following steps: Step A1: Define the index for each group of records Each has its corresponding table index Binding, i.e. and There will be no duplicate record indexes. Specify the number of join attributes that each table shares with other tables. The data is fixed during the initialization phase, therefore the table... Each group of records index and join attribute values This tuple is constructed as follows: : (1) It is stipulated that for each table It shares a join property with other tables. It is fixed. Randomize the record index and join attribute values: , ,in For the index value of the corresponding connection attribute, calculate the cross label. This is an XOR operation, and the same applies below.

[0011] (2) Add to In the middle. That is... ;in, This indicates an add operation. () indicates an update operation (add indicates an add operation, which can actually be identified by a single bit in the implementation). () indicates an update operation; please see the main text for details. (Implementation details) Step A2: Check the table Each non-connected attribute value in Establish in the following manner : (1) Calculate a set of fill factors to be added. and ,in , .

[0012] (2) For ,definition For inclusion matching The set of all record indexes for each entry, containing join attribute values ​​for the same record index. Therefore, For the table All of them Tuple, initialize the counter And perform the following calculations: 1) Calculation , .

[0013] 2) For each join attribute value in the tuple : Randomize the index and join attribute values ​​of this tuple record: , .

[0014] Calculate the corresponding value: , .

[0015] 3) Based on the non-connected attribute value Compute key Then calculate the ciphertext of the record index. Where ENC() represents an encryption operation; 4) Add to list middle.

[0016] 5) Counter increments automatically .

[0017] Step A3: Calculation ,make .in, Indicates generation .

[0018] Note and In the calculation, for and The computations are essentially the same and can be reused in actual algorithm execution.

[0019] Preferably, during the data update phase, the client generates encrypted data packets on a per-line record basis, according to the update operation type. ,in For the set containing the new cross labels, To encrypt the record index and corresponding auxiliary offset, Then, for the randomized string of the non-connected attribute value that should be recorded, in The middle pointer refers to the record; the server determines the type of operation based on the data. Insert it Or insert an undo list .

[0020] Preferably, the client indexes the row data and each non-connected attribute value on a single-row record basis. Perform the following calculations: Step B1: Randomize the record index and join attribute values: , Calculate cross-labels All Add to collection ,in For table indexes.

[0021] Step B2: For each non-connected attribute value Perform the following calculations: Step 2.1: Calculate a set of fill factors and ,in , .in, . These represent add or delete operations (identified by a single bit); for For all Tuples from the counter list Read the corresponding counter Perform the following calculations: (1) Calculation , .

[0022] (2) For each connection attribute value Randomize the index and join attribute values ​​of this tuple record: , Calculate the corresponding value: , .

[0023] (3) Based on the non-connection attribute value Compute key Then calculate the ciphertext of the record index. Here, ENC() represents the encryption operation; (4) Counter increments automatically .

[0024] Step B3: Obtain If return Then calculate .in, Indicates reading The corresponding stag, This indicates that the tuple is empty (in practice, it can return an error indicating that the tuple has not been generated before). ); Step B4: Upload to the server.

[0025] Preferably, the server is configured according to the operation type. Insert it Or insert an undo list The specific implementation process is as follows: add the recorded data to In, that is Read operation ,if ,Will All of them Add to In the structure, if ,Will All of them Add to undo list In, that is .

[0026] As a preferred option, during the query phase... The protocol involves interaction between the client and the server, whereby the client transmits a secret key. A connection query As input, where Corresponding link query and , In a join query, the non-join attribute values ​​of the two tables are considered. Query, This corresponds to the join attribute of the two tables. The client calculates the corresponding query token and uploads it to the server, then calculates the join query result based on the server's return value.

[0027] Client: Step C1: The client calculates the key corresponding to the two connectionless attribute values. , And store it locally. The client reads... and will Upload to the server. Indicates non-connected attributes The corresponding tags This indicates a return value. The corresponding stag; Step C2: The client reads the counter list. ,right Each count value Perform the following operations: Calculate search token , Ultimately, Upload to the server.

[0028] Step C3: For Each count value Perform the following operations: Calculate search token , Ultimately, Upload to the server.

[0029] server: Step D1: The server will As input, receive from the client. , , ,according to Read the corresponding list ,Right now , . Indicates taking out The corresponding set; Step D2: For Perform the following calculations: from Read the first tuples Read the corresponding connection attributes of value It should be noted that this tuple may contain... and corresponding The value is such that there may be more than one corresponding value.

[0030] For each ,calculate and add to the collection In the middle. Calculation and add to the collection middle.

[0031] right Perform the following calculations: from Read the first tuples Read the corresponding connection attributes of value Similarly, this tuple may contain and corresponding The value is such that there may be more than one corresponding value.

[0032] For each ,calculate and add to the collection In the middle. Calculation and add to the collection middle.

[0033] Step D3: For the set and All combinations If satisfied Then Add to result set In the middle. For sets and All combinations If satisfied Then From the result set Delete it.

[0034] The final result set Returned to the client, the client returns each Tuples, decrypted and output locally on the client side .

[0035] In this invention, for The data structure uses a variable-length list for storage. and The structure is constructed using a B+ tree. Specific implementation details are shown below: Stored in a variable-length list format, As the key, its corresponding A tuple is a value, a single tuple It may correspond to multiple tuples. During initialization or update, This is used to store each set of unconnected attribute values ​​in the database and its corresponding record information. During the search process, the corresponding values ​​are calculated... This allows you to obtain a list of associated records.

[0036] The structure contains five algorithms, namely , , , and .

[0037] :by As input, construct a variable-length list, and finally output the corresponding... .

[0038] Input a set Output the corresponding randomized sequence This algorithm is a probabilistic algorithm.

[0039] Enter key and a group ,in For the corresponding table index, For a non-connected property value, output Chinese correspondence If not, output .

[0040] Enter key , , and single record data Output the updated version .

[0041] :enter and Return the corresponding list .

[0042] and It uses a B+ tree structure. This is due to the storage of cross-tags. In reality, it is a randomized string of record index and join attribute values, so this string type can be converted to a 256-bit unsigned integer and used to build a B+ tree in integer form.

[0043] and The structure contains four algorithms, namely , , and .

[0044] :initialization or Storage structure, including setting the order Number of keywords The structure of parent nodes and child nodes, etc.

[0045] :enter ,like Then, according to the B+ tree rules, insert In the structure, otherwise insert In the structure. Due to cross-labels In reality, it's a randomized string of record index and join attribute values, so this string type can be converted to a 256-bit unsigned integer and added to the B+ tree. Return the updated... .

[0046] :enter If the In the corresponding If the result is found in the search, then return it. Otherwise return .

[0047] Server maintenance cycle The audit algorithm is executed periodically each cycle. The algorithm's input... For each The algorithm will Delete the corresponding part Finally, return to the updated version. and initialization .

[0048] This invention also provides a high-efficiency ciphertext join query system based on B+ trees for encrypted databases, comprising: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the described method for efficient ciphertext join query based on a B+ tree for encrypted databases.

[0049] Compared to existing solutions, the advantages of this invention include: (1) This invention constructs a system that supports dynamic adjustment. and This structure extends the traditional static join query scheme to dynamic scenarios, overcoming the shortcomings of existing solutions and enabling dynamic encrypted join queries. While maintaining join query functionality, this scheme allows for dynamic addition and deletion operations on a single record basis, significantly improving the flexibility and practicality of join query schemes in relational databases. (2) This invention is achieved by using a B+ tree structure. This invention eliminates the false positive problem inherent in existing solutions due to the use of Bloom filter structures. Simultaneously, leveraging the characteristic of B+ trees—that data is stored only in leaf nodes and only indices in non-leaf nodes—this invention stores cross-label data in leaf nodes, increasing the number of indexes that non-leaf nodes can hold, thereby reducing the height of the B+ tree and effectively lowering the cost. The overall storage space overhead of the ciphertext index in the structure; (3) The B+ tree storage structure used in this invention naturally supports dynamic balancing and addition / deletion, and can perform data maintenance in real time according to the actual update needs of the relational database. This approach enables it to be widely used in relational encrypted database scenarios that require frequent updates; (4) This invention maintains high operating efficiency while achieving dynamic addition and deletion. The non-leaf node indexing mechanism of the B+ tree structure and the sequential access pointers between leaf nodes significantly improve the efficiency of cross-labeling during the search phase. Search efficiency. Furthermore, since all query operations need to reach [location]... For leaf nodes, the query complexity is logarithmically related only to the tree height. This invention ensures the stability of query time in large-scale data processing scenarios.

[0050] (5) This invention introduces a cancellation list. By periodically performing auditing and deletion functions, irregular deletion operations are transformed into periodic batch processing. This mechanism further reduces the system's instantaneous computing resource consumption by dynamic update operations and optimizes computational overhead. Attached Figure Description

[0051] The technical solutions of the present invention will be further illustrated below using embodiments and specific implementation methods. In addition, some accompanying drawings are used in the description of the technical solutions. Those skilled in the art can obtain other drawings and the intent of the present invention from these drawings without any creative effort.

[0052] Figure 1 This is a schematic diagram of the method in an embodiment of the present invention. Detailed Implementation

[0053] To facilitate understanding and implementation of the present invention by those skilled in the art, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0054] Searchable encryption schemes allow users to perform searches on encrypted databases. For more widely used relational databases, the corresponding join query scheme, JXT, performs well. However, existing cross-table join query schemes support static queries; implementing dynamic functionality solely through rebuilding the encrypted database each time incurs unpredictable computational overhead.

[0055] This embodiment addresses the shortcomings of the aforementioned technologies by proposing a method, system, and product for efficient join queries on encrypted databases based on B+ tree construction. The aim is to provide users with more flexible data processing technologies that better meet their actual needs.

[0056] Request Figure 1 This embodiment provides a method for efficient ciphertext join query based on B+ tree for encrypted databases, including an initialization phase, a data update phase, and a query phase; it includes two data structures. and , Inverted index for non-connected attribute values, Store cross-labels using a B+ tree structure. Cross-label The string type is converted to a 256-bit unsigned integer as the key value of the B+ tree; during the initialization phase, the client generates the key. Preprocess each table in the plaintext database; calculate cross-labels based on join attribute values ​​and record indexes. And construct a B+ tree structured encrypted index. ; Build inverted indexes for non-connected attribute values During the data update phase, the client generates encrypted data based on the operation type (add or delete) and uploads it. The server then dynamically adjusts the B+ tree nodes or stores them in the revocation list accordingly. During the query phase, the server synthesizes query tokens and performs logarithmic-level retrieval in the B+ tree to achieve tuple-level equi-joins.

[0057] The invention will be further illustrated below through specific experiments.

[0058] This experiment demonstrates a join query process in a student course selection scenario, including a student course selection table. With the course schedule .

[0059] Step 1: Set up the student table The corresponding attribute is student ID. With name Course Selection Form The corresponding attribute is student ID. ,course The join query aims to find the names of students who have taken a specified course.

[0060] In one implementation, step 1 specifically includes the following sub-steps: Step 1.1: Key Generation. The client calls... Protocol-generated key .

[0061] Step 1.2: For Each record in the database (record index is...) The connection attribute value is Client-side cross-label calculation . Indicates an index on records in the table. The key for randomization This indicates the value of the join attribute in the table. The key for randomization This is the index value of the corresponding connection attribute.

[0062] Step 1.3: This Converted to a 256-bit integer and inserted into a B+ tree-based structure middle.

[0063] Step 1.4: For Each non-connected attribute value in Client-side calculation of inverted index and index it with the encrypted record contained in the associated tuple. and auxiliary values Store together to middle.

[0064] Step 1.5: For Perform the same initialization operation, and finally output the updated version. and and initialization .

[0065] Step 2: When the student table When a new student is added, the client executes... protocol.

[0066] In one implementation, step 2 specifically includes the following sub-steps: Step 2.1: Calculate the new updated entry First of all, Search corresponding If the search fails, then calculate Then index the records. Encryption is performed. Ciphertext is obtained. Then calculate the auxiliary value. , here The update operation is bound to it. This is to enable dynamic addition and deletion of tags. For encrypted record indexing and the corresponding auxiliary offset; Step 2.2: When the server receives... At that time, according to the B+ tree insertion rules, ... Place it on a leaf node, and split non-leaf nodes as needed to maintain the balance of the tree. If Then store the tag in In the tree, the audit period is pending. Upon arrival, by The algorithm uniformly removes items from the main tree, ensuring that the latency overhead of the deletion operation is minimized.

[0067] Step 3: User initiates connection query Search and Records with the same middle school number.

[0068] In one implementation, step 3 specifically includes the following sub-steps: Step 3.1: Query Token Generation. The client generates the query token based on the non-connection attribute value to be queried. and counter table Calculate search token .in, , ;in, Used to generate randomized search tokens These represent the student's course selection form. With the course schedule The non-connected attribute value to be queried in the middle. These represent the values ​​of non-connected attributes. The number of updates in its corresponding table.

[0069] Step 3.2: The server, according to... from Take the corresponding Value, and synthesized with search token .Right now , .

[0070] Step 3.3: If exist In the middle, and Not here In the structure, the corresponding value is returned. .

[0071] Step 4: Client decrypts the corresponding... Returns the results of the join query.

[0072] This embodiment provides an efficient join query scheme for encrypted databases based on B+ tree construction. Its correctness is based on the following mathematical logic: According to the protocol described in this invention, the client in or Phase targeting table Record index and table Connection attribute value The following intermediate variables are generated: Cross-label ; Stored auxiliary offset: , ;in As a pseudo-random fill factor, , .

[0073] exist In the protocol, the client targets the query keywords. Generate query token: , .

[0074] After the server receives the query token, it combines it with the... Found Calculate the matching value: First matching component: Substitute Defined ;because , After they cancel each other out, we get .

[0075] The second matching component: Substitute in the same way Defined After mutual cancellation, we get .

[0076] Therefore, if record index With attribute value If it matches, then it is in In Server computing .

[0077] Under a specific configuration of the present invention, when an update operation... If the results are identical, the above verification process is successful. The server uses a B+ tree structure... Search for the result in the middle, if it exists (i.e. If the function returns true, it proves that the join condition is true and the solution is correct. They are not the same, the calculated values ​​are meaningless and cannot be used in practice. or The search returned the corresponding results.

[0078] This invention presents an efficient join (table) query method based on B+ trees for encrypted databases, leveraging the tree's order adjustability to optimize the retrieval depth of large-scale encrypted indexes. This invention also introduces an asynchronous deletion mechanism through the setting of an undo list. In conjunction with periodic auditing algorithms This invention balances update frequency with server computational overhead. It achieves sublinear search complexity, and query latency is only affected by the height of the B+ tree (…). (Level) Impact. This effectively solves the problem that current join query schemes cannot handle dynamic database updates. Compared to existing schemes, this invention, while retaining the original query mode, adds dynamic add / delete functionality on a per-record basis. Its query efficiency is only related to the height of the tree, making it more suitable for large-scale databases and providing a practical technical solution for flexible data processing.

[0079] It should be understood that the embodiments described above are only some, not all, of the embodiments of the present invention. Furthermore, the technical features of the various embodiments or individual embodiments provided by the present invention can be combined with each other to form feasible technical solutions. Such combinations are not constrained by the order of steps and / or structural composition patterns, but must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0080] It should be noted that the above description of the embodiments is quite detailed, but it should not be considered as a limitation on the scope of protection of this invention. Those skilled in the art can make substitutions or modifications without departing from the scope of protection of the claims of this invention, and all such substitutions or modifications fall within the scope of protection of this invention. The scope of protection of this invention should be determined by the appended claims.

Claims

1. A method for efficient ciphertext join query based on B+ tree for encrypted databases, characterized in that: It includes the initialization phase, the data update phase, and the query phase; Includes two data structures and , Inverted index for non-connected attribute values, Store cross-labels using a B+ tree structure. Cross-label The string type is converted to a 256-bit unsigned integer as the key value of the B+ tree; during the initialization phase, the client generates the key. Preprocess each table in the plaintext database; calculate cross-labels based on join attribute values ​​and record indexes. And construct a B+ tree structured encrypted index. ; Build inverted indexes for non-connected attribute values ; During the data update phase, the client generates encrypted data based on the operation type and uploads it. The server then dynamically adjusts the B+ tree nodes or stores the encrypted data in the revocation list accordingly. ; During the query phase, the server synthesizes query tokens and performs logarithmic-level retrieval in the B+ tree to achieve tuple-level equi-joins.

2. The method for efficient ciphertext join query based on B+ tree for encrypted databases according to claim 1, characterized in that: During the initialization phase, the client generates a key. ,in, Indicates an index on records in the table. The key for randomization This indicates the value of the join attribute in the table. The key for randomization Represents the introduced random factor or The key for randomization Represents the introduced random factor or The key for randomization The master key is used to access the values ​​of each non-connected attribute in the table. Derivate the corresponding key; initialize , ,in, Used to store cross labels , Used to store deleted cross tags; key Used for Processing is required; only the entity possessing the key can perform the operation. Processing; Key Used for Processing is required; only the entity possessing the key can perform the operation. Process it; Indicates to Perform initialization; for the plaintext database Each table in the database undergoes preprocessing; among them, the plaintext database... It stores a collection formed after preprocessing a series of table data. This represents the i-th table. The number of tables stored in the encrypted database during the initialization phase; each table consists of a series of attribute values ​​and tuples corresponding to the records. composition; This represents the set after processing the table data, that is, the set of data processed from the table. The set of non-connected attribute values ​​in each table; calculate Among them, the key Used for Processing is required; only the entity possessing the key can perform the operation. To process, Indicates the first The set corresponding to Zhang's table Indicates to Initialize; Output key and encrypted database .

3. The method for efficient ciphertext join query based on B+ tree for encrypted databases according to claim 2, characterized in that: The plaintext database Each table in the database undergoes preprocessing, specifically including the following steps: Step A1: Define the index for each group of records Each has its corresponding table index Binding, i.e. and There will be no duplicate record indexes. Specify the number of join attributes that each table shares with other tables. The data is fixed during the initialization phase, therefore the table... Each group of records index and join attribute values This tuple is constructed as follows: : The regulations specify that for each table Common join attributes with other tables It is fixed; the record index and join attribute values ​​are randomized: , ,in, It involves randomizing the index of each record in the table. It is a randomization of the connection attribute values; () is a pseudo-random function. For the connection attribute index, For record indexing, Let t be the t-th connection attribute value; construct an inverted index list for the non-connection attribute values. It contains an index of encrypted records. and the corresponding auxiliary offset ; Calculate cross-labels , here For XOR operation; Add to In, that is ,in, This indicates an add operation. () indicates an update operation; Step A2: Check the table Each non-connected attribute value in Establish in the following manner ; Calculate a set of fill factors to add. and ,in , ; for ,definition For inclusion matching The set of all record indexes for the entry, including the join attribute values ​​of the same record index; ; For the table All of them Tuple, initialize the counter And perform the following calculations: (1) Calculation , ; (2) For each join attribute value in the tuple Randomize the index and join attribute values ​​of the tuple record: , ; Calculate the corresponding value: , ; (3) Based on the non-connection attribute value Compute key Then calculate the ciphertext of the record index. Where ENC() represents an encryption operation; (4) Add to middle; (5) Counter increments automatically ; Step A3: Calculation ,make ;in, Indicates generation .

4. The method for efficient ciphertext join query based on B+ tree for encrypted databases according to claim 2, characterized in that: During the data update phase, the client generates encrypted data packets based on the update operation type, one row at a time. ,in For the set containing the new cross labels, For encrypted record indexing and corresponding auxiliary offset , Then, for the randomized string of the non-connected attribute value that should be recorded, in The middle pointer refers to the record; the server determines the type of operation based on the data. Insert it Or insert an undo list .

5. The method for efficient ciphertext join query based on B+ tree for encrypted databases according to claim 4, characterized in that: The client indexes the row data and each non-connected attribute value on a single-row basis. Perform the following calculations: Step B1: Randomize the record index and join attribute values. , Calculate cross-labels ; All Add to collection ,in For table index; Step B2: For each non-connected attribute value Calculate a set of fill factors and ,in , ;in, , These represent add or delete operations, respectively; for For all Tuples from the counter list Read the corresponding counter Perform the following calculations: (1) , ;in, , These represent the fill factors; (2) Each connection attribute value Randomize the tuple record index and join attribute values: , ; Calculate the corresponding value , ; (3) Based on the non-connection attribute value Compute key Then calculate the ciphertext of the record index. Where ENC() represents an encryption operation; (4) Counter increments automatically ; Step B3: Obtain If return Then calculate ;in, Indicates reading The corresponding stag, Indicates empty; Step B4: Upload to the server.

6. The method for efficient ciphertext join query based on B+ tree for encrypted databases according to claim 4, characterized in that: The server is based on the operation type. Insert it Or insert an undo list The specific implementation process is as follows: the server adds the recorded data to... In, that is: Read operation ,if ,Will All of them Add to In the structure; if ,Will All of them Add to undo list In, that is .

7. The method for efficient ciphertext join query based on B+ tree for encrypted databases according to claim 2, characterized in that: During the query phase, the client first performs the following operations: The client calculates the key corresponding to two connectionless attribute values. , And store it locally; the client reads it. and will Uploaded to the server; among which, among which Corresponding link query and , In a join query, the non-join attribute values ​​of the two tables are considered. Query, This corresponds to the join property of the two tables; This indicates the tag corresponding to a non-connected attribute. This indicates a return value. The corresponding stag; Client reads counter list ,right Each count value Calculate search token , Ultimately, Upload to the server; right Each count value Calculate search token , Ultimately, Upload to the server; The server performs the following operations: The server will As input, receive from the client. , , ,according to Read the corresponding list ,Right now , ; Indicates taking out The corresponding set; right ,from Read the first tuples Read the corresponding connection attributes of value For each ,calculate and add to the collection Chinese; calculation and add to the collection middle; right ,from Read the first tuples Read the corresponding connection attributes of value ; For each ,calculate and add to the collection Chinese; calculation and add to the collection middle; For sets and All combinations If satisfied Then Add to result set In the middle; for sets and All combinations If satisfied Then From the result set Delete; The final result set Return to the client; For each Tuples, decrypted and output locally on the client side .

8. The method for efficient ciphertext join query based on B+ tree for encrypted databases according to any one of claims 1-7, characterized in that: The The structure contains five algorithms, namely , , , and ; ,by As input, construct a variable-length list, and finally output the corresponding... ; Input a set Output the corresponding randomized sequence ;in For the corresponding table index, For a non-connected property value; Enter the key and a group Output Chinese correspondence If not, output ; Enter the key , , and single record data Output the updated version ; ,enter and Return the corresponding list .

9. The method for efficient ciphertext join query based on B+ tree for encrypted databases according to any one of claims 1-7, characterized in that: The and The structure contains four algorithms, namely , , and ; ,initialization or Storage structure, including setting the order Number of keywords The parent node and child node structure; ,enter ,like Then, according to the B+ tree rules, insert In the structure, otherwise insert In the structure, return the updated ; ,enter If the In the corresponding If the result is found in the search, then return it. Otherwise return ; Server maintenance cycle The audit algorithm is executed periodically each cycle, and the algorithm's input is... For each The algorithm will Delete the corresponding part Finally, return to the updated version. and initialization .

10. A high-efficiency ciphertext join query system based on B+ tree for encrypted databases, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the ciphertext efficient join query method for encrypted databases based on B+ trees as described in any one of claims 1 to 9.

Images