Multi-table join method supporting Boolean query in encrypted database

Abstract

This invention belongs to the research field of data privacy protection and efficient secret computation in secret databases, particularly relational secret databases. Specifically, it relates to a multi-table join method supporting Boolean queries in secret databases. The method comprises the following steps: Step 1: The client executes a secret database initialization protocol (including four modules: plaintext data parsing, Boolean attribute orthogonalization, index construction, and database encryption); Step 2: The client and server interact to implement a search protocol (including the client generating a "query message" and sending it to the server, and the server generating a "response message" and sending it to the client); Step 3: The client decrypts the response and obtains matching results for plaintext row identifiers that meet the query criteria.

Description

Technical Field

[0001] This invention relates to the field of encrypted database technology, and more particularly to a multi-table join method supporting Boolean queries, suitable for implementing data privacy protection and efficient encrypted computation within relational encrypted databases. The method includes a encrypted database initialization protocol (including four modules: plaintext data parsing, Boolean attribute orthogonalization, index construction, and data encryption), and a search protocol (including three stages: the client generates and sends a "query message," the server generates and returns a "response message," and the client decrypts the response). Background Art

[0002] Multi-table join queries in relational secret databases are designed to perform secure join operations on two or more randomized and encrypted relational tables, ensuring that no information other than the query results is leaked. As a key function in secret databases, secure equivalent join queries are widely used in various practical scenarios. For example, in e-commerce platforms, merchants store user information (such as registration information, order information, and product information) in cloud-based secret databases to achieve efficient storage and query analysis. Due to the privacy of user personal information, merchants need to ensure that the data is always encrypted during storage and query. Even if the cloud server is "honest but curious", it cannot obtain the plaintext information of the data.

[0003] The combination of join queries and filter conditions is also a common query form in SQL operations, especially Boolean filter conditions. Boolean filtering is a query method based on Boolean logic. It combines query conditions using logical operators (such as AND, OR, and NOT) to accurately filter data that meets specific conditions. This combined query method can effectively reduce redundant calculations and communication overhead in large-scale data environments, thereby improving overall query efficiency. For example, in an e-commerce platform, by joining the user table and the order table, combined with filter conditions, you can query the user information of users who purchased a certain product within a specific time period, thereby achieving accurate business analysis. Therefore, under the premise of ensuring data privacy, implementing a multi-table join method that supports Boolean queries on a relational encrypted database is a key issue that needs to be urgently addressed in the field of encrypted databases, and it has great potential in both theoretical and practical applications.

[0004] Consider the task of implementing multi-table joins supporting Boolean queries in a relational, encrypted database. Specifically, under the premise of data encryption, secure join queries are performed on data entries that meet the Boolean query conditions, returning matching data entries. In recent years, various equi-join query schemes have been proposed. Among these, one type of pure software implementation utilizes public key cryptography (such as attribute-based encryption) to design novel data encryption algorithms. These schemes can achieve the security goal of fine-grained frequency hiding and the functional requirements of complex conditional filtering. However, these query algorithms suffer from high computational complexity and low query efficiency. Another type of scheme, based on purely symmetric encryption algorithms, is a "join cross-label" scheme. This scheme constructs a "join inverted index" similar to that used in searchable encryption and generates cross-labels for the join attributes in the tables. The server receives the query token and matches it against the index terms to identify the join result. These schemes generally feature simple structure, high query efficiency, and low computational complexity, making them well-suited for practical deployment. However, existing cross-label-based multi-table join methods mostly focus on single keyword filtering and join queries between two tables. The solutions that support multi-table joins are relatively limited, and it is difficult to effectively handle complex Boolean conditions. It is still impossible to balance query functionality and privacy protection requirements. Summary of the Invention

[0005] In response to the deficiencies of existing technologies in functionality, security and performance, the present invention proposes a multi-table connection method that supports Boolean queries. It uses efficient symmetric encryption technology and indexing technology to implement connection operations for arbitrary Boolean condition matching items on a relational encrypted database. It can safely and efficiently implement connection queries of three or more tables. It has stronger functionality than the existing symmetric encryption two-table connection solution, and can ensure higher security and lower query complexity.

[0006] This invention aims to provide a Boolean query multi-table join method for relational, encrypted database systems, addressing the functional, security, and performance limitations of existing technologies. The proposed solution achieves an effective balance between functionality, security, and computational performance, and exhibits good scalability and practicality.

[0007] To achieve the above objectives, the present invention provides the following technical solutions:

[0008] A multi-table equal-value join method supporting Boolean condition filtering on a relational encrypted database comprises the following steps:

[0009] In step 1, the client executes a random algorithm locally—the EDBSetup protocol, which takes a plain text database as input and generates an encrypted database (secret database), and outsources the database to an (untrusted) server.

[0010] In step 2, the client and server jointly execute a two-party protocol, the Search protocol. Based on the query token generated by the client, the server completes Boolean condition filtering and multi-table join query calculations in the encrypted database and returns the query results.

[0011] Step 3: The client decrypts the encrypted row identifier returned by the Search protocol, extracts and recovers the set of records that ultimately meet the query conditions from the encrypted database.

[0012] This technical solution is further optimized, and the step 1 specifically includes:

[0013] Step 11: After the EDBSetup protocol begins, the client first parses the plaintext database, including selecting a pseudo-random encryption function and a symmetric encryption algorithm, randomly selecting a key set, and classifying attribute columns in the plaintext relational table into Boolean attributes, join attributes, and index attributes.

[0014] Step 12: After the EDBSetup protocol completes database parsing, it performs orthogonalization on the Boolean attributes. The client uses a pseudo-random permutation function to pseudo-randomly permute the Boolean attribute set and concatenates the permuted attribute values ​​with the position vectors to obtain an initial set of uncorrelated Boolean vectors. All vectors are then processed using the Schmidt orthogonalization function to obtain the final mapping set of attribute values ​​and their orthogonal vectors.

[0015] Step 13: The EDBSetup protocol executes index construction. For each index attribute, the row identifier set, Boolean attribute set, and connection attribute set in each record of each index attribute are first processed using a pseudorandom function. Then, vector addition, vector multiplication by the pseudorandom function value, and XOR operation on the pseudorandom function value are performed to obtain the Bloom filter for each index item and connection tag, and upload it to the server.

[0016] Step 14: The EDBSetup protocol executes encryption of the data table. The client uses a random encryption algorithm to encrypt the data table.

[0017] Step 15: The EDBSetup protocol uploads the encrypted data table to the server.

[0018] This technical solution is further optimized. In step 11, the EDBSetup protocol includes a method for the client to parse the plaintext database. The specific steps include:

[0019] Step 112: After the EDBSetup protocol starts, the client selects a secure pseudo-random encryption function F(·) that meets the system security and performance requirements and a symmetric encryption technology Enc(·) for encrypting the result set;

[0020] Step 113: The client randomly selects a key set K to ensure secure encryption of local data.

[0021] Step 114 categorizes the attribute columns in the relationship table into three types: Boolean attributes used for Boolean filtering, join attributes involved in join operations, and index attributes used for index building. This allows subsequent modules to differentiate their attributes. This completes the initial protocol steps of parsing the plaintext database.

[0022] This technical solution is further optimized. In step 1, the EDBSetup protocol includes orthogonalization of Boolean attributes. The specific steps include:

[0023] Step 121: Randomly permuting the Boolean attributes and the auxiliary query vector set using a pseudo-random permutation function π(·) to enhance the privacy protection capability of the attributes during storage and calculation.

[0024] Step 122, concatenate the replaced attribute values ​​with the position vector e to obtain an initial set of uncorrelated Boolean vectors {f};

[0025] Step 123 , input the Boolean vector set {f} into the Schmidt orthogonalization function GS_orth(·) to obtain the final attribute value and its orthogonal vector mapping V. At this point, the orthogonalization of the Boolean attribute is completed.

[0026] This technical solution is further optimized. The construction of the query index of the EDBSetup protocol in step 1 includes the following specific steps:

[0027] Step 131: For each index attribute, first obtain the row identifier set {ind} containing the attribute, and obtain the Boolean attribute set W of each record where the row identifier is located. bl , connection attribute set W jn ;

[0028] Step 132: For each index attribute, process row by row: calculate the sum of the orthogonal vectors of the Boolean attribute and the auxiliary attribute, calculate the product of the pseudo-random encrypted value of the row identifier and the auxiliary orthogonal vector, and add the two values ​​to obtain the Boolean index item of the row;

[0029] Step 133: Calculate the pseudo-random encrypted value of each index attribute of the row and the pseudo-random encrypted value of the index attribute and a counter, perform an XOR operation on the two values ​​to obtain the join index entry of the row, and perform an XOR operation on each index attribute of the row and the pseudo-random encrypted value of the row identifier to obtain the join label.

[0030] Step 134: symmetrically encrypt the row identifier of the row to obtain an encrypted row identifier. At this point, all index-related items are calculated.

[0031] Step 135: Pack the Boolean index items and encrypted row identifiers of each row of the index attribute into T, and combine the T used into the Boolean index TSet of the table. Store the deduplicated connection index items in the connection index JSet of the table, and store the connection labels in the Bloom filter XSet to improve computing efficiency. At this point, all query indexes are ready.

[0032] This technical solution is further optimized, and the encryption of the data table in the EDBSetup protocol in step 1 includes the following specific steps:

[0033] Each data table in the plaintext database is encrypted using a randomized symmetric encryption algorithm to achieve semantic security and build a relational, encrypted database. This project significantly improved the efficiency of the solution by using indexing technology to implement a join query method that supports Boolean queries, separate from the encryption of the data tables. Finally, the client uploads the indexed and encrypted data tables to the server, resulting in a semantically secure, relational, encrypted database. This completes the EDBSetup protocol.

[0034] This technical solution is further optimized, and the step 2 is specifically:

[0035] The client generates a "query message" and sends it to the server. The "query message" is the query token information calculated from the index attributes, connection attributes, and Boolean attributes extracted from the SQL query statement. The Search protocol first calculates the TSet search token based on the index attributes and the JSet search token based on the index attribute and connection attribute pair. Then, it calculates the Boolean condition filtering and connection query calculation tokens based on the Boolean attribute and connection attribute names respectively.

[0036] The server generates a "response message" and sends it to the client. The "response message" is a set of encrypted row identifiers filtered by the server based on the calculation between the token information provided by the client and the index items it maintains. Boolean filtering is accomplished by performing an inner product operation on the Boolean query token and the orthogonal vector of the corresponding index entry in TSet. The join operation is performed by performing an XOR operation on the join query token with the corresponding entry in JSet to calculate the intersection set of the join attributes between the query tables, completing the private set intersection operation of the join attributes.

[0037] The server then performs an XOR operation on each connection attribute value in the intersection set with the Boolean inner product result to generate the final label value. The server further performs a membership test on the label value in the Bloom filter XSet. If the test result is True, the connection label is considered a valid match and its corresponding encrypted row identifier is retained and returned to the client as the query result.

[0038] The client decrypts the received row identifier to obtain the final matching result.

[0039] This technical solution is further optimized, and the method for generating the client token in step 2 includes the following specific steps:

[0040] Step 21: Based on the relevant information of the query table and query column in the plaintext SQL statement, an index search token for searching TSet and JSet related items is generated according to the token generation algorithm of the encrypted multi-mapping technology, and the token is sent to the server. The server receives the token and reads the index related items;

[0041] Step 22: Based on the Boolean attributes involved in the Where condition in the plaintext SQL statement, the client obtains the corresponding orthogonal vector from the mapping V and generates the corresponding large integer using a pseudo-random generator. The client multiplies the orthogonal vector by the integer and calculates the vector sum. The resulting vector is sent to the server as a Boolean query token.

[0042] Step 23: Based on the index attributes and table connection attributes in the plaintext SQL statement, the client calculates the pseudo-random function value of the index attribute name and the pseudo-random function value of the index attribute cascade counter, XORs the two values ​​to obtain a connection query token, and sends it to the server.

[0043] Step 24: Based on the relevant calculations of the Boolean query token and the connection query token, the client calculates the obtained random large integer and performs an XOR operation with the index attribute pseudo-random function value to obtain the result test token and sends this token to the server. At this point, the token generation phase is completed.

[0044] This technical solution is further optimized. The index calculation of the Boolean condition filtering in the Search protocol in step 2 includes the following specific steps:

[0045] In step 25, the server performs an inner product calculation on the received Boolean query token and the query-related items in the TSet index items, obtaining the calculated result value. This calculation process is identical for each query table, so it can be run in parallel. At this point, the calculations related to the Boolean conditional filtering are complete.

[0046] A further optimization of this technical solution is that the Search protocol in step 2 supports the intersection of private sets of inter-table connection attributes. The specific steps include:

[0047] Step 26: The server performs an XOR operation on the received connection query token and the corresponding item in the JSet to obtain the relevant value of the connection attribute;

[0048] Step 27: The XOR result is tested for membership in the Bloom filter XSet. If True is returned, the connection attribute contained in the relevant value is a common connection attribute contained in the query table, and the value is retained as the intermediate result of the query. If False is returned, it is not a common connection attribute, and the value is not retained. At this point, the intersection process of the privacy set of connection attributes is completed.

[0049] This technical solution is further optimized. The specific steps of selecting the query results in the Search protocol in step 3 include:

[0050] Step 31: Perform an XOR operation on the intermediate result of the JSet index calculation and the inner product value calculated by TSet to obtain the final label value. This step is calculated in parallel across tables, effectively improving the execution efficiency of the solution.

[0051] Step 32: Perform a membership test on the tag value in the Bloom filter XSet. If the return value is True, the relevant entry is part of the query result. The set {ct} of encrypted row identifiers corresponding to TSet for all tables is returned and sent to the client. If the return value is False, the value is skipped. This completes all operations of the Search protocol.

[0052] Different from the existing technology, the above technical solution has the following beneficial effects:

[0053] 1. Enhanced the functionality of the symmetric encryption connection scheme, especially supporting Boolean condition filtering and multi-table join functions;

[0054] 2. Reduce information leakage during multi-table join queries and improve security;

[0055] 3. Improved query efficiency for Boolean query join schemes;

[0056] 4. Reduced storage pressure for Boolean query join solutions. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 It is a schematic diagram of the relational encrypted database system model;

[0058] Figure 2 It is a flowchart of the multi-table join method that supports Boolean queries;

[0059] Figure 3 This is a flowchart of the EDBSetup protocol for the multi-table join method that supports Boolean queries;

[0060] Figure 4 This is a flowchart of the Search protocol that supports the multi-table join method for Boolean queries;

[0061] Figure 5 This is a comparison of the safety of the present invention and other connection methods;

[0062] Figure 6 It is a comparison of the storage load, computational complexity and functionality of the present invention and other connection methods. DETAILED DESCRIPTION

[0063] In order to explain the technical content, structural features, achieved objectives and effects of the technical solution in detail, the following is a detailed description in conjunction with specific embodiments and accompanying drawings.

[0064] In this specific implementation, the complete query process for a relational encrypted database primarily involves client-driven parsing and encryption of plaintext SQL statements into encrypted query SQL statements. The cloud-based database management system parses the received SQL statements and reads and processes the encrypted data.

[0065] See Figure 1 The following is a schematic diagram of the query process model for a relational encrypted database system. The innovation of this technology primarily involves client-driven parsing of multi-table join query SQL statements with Boolean filter conditions (the query token generation protocol), and the server-side database management system's ability to execute join queries supporting Boolean attribute filtering on encrypted data. A complete execution process includes:

[0066] 1. Such as Figure 1 As shown by arrow ①, when executing a query, the user enters plaintext SQL commands through the local app, and the client driver is responsible for parsing and encrypting them.

[0067] 2. Such as Figure 1 As shown by arrows ②③④, the client driver obtains the key set K, encrypts the private attributes in the SQL statement, calculates the query token, and embeds it into the SQL statement and sends it to the server in ciphertext form.

[0068] 3. Such as Figure 1 As shown by arrows ⑤ and ⑥, the server receives the SQL statement, performs parsing and optimization, obtains relevant indexes and encrypted data tables from the encrypted storage, performs query calculations, and returns the query results to the client after completion.

[0069] 4. Such as Figure 1 As shown by arrows ⑦⑧, after the client receives the encrypted result set, the client driver decrypts the ciphertext.

[0070] The plaintext query content is displayed to the user in the form of APP response information.

[0071] See Figure 2As shown, the innovation of this technology mainly involves the design of a protocol that supports Boolean queries, mainly involving the client initialization protocol (EDBSetup protocol), which completes the construction of the encrypted database based on the plaintext data information. There is also a search protocol (Search protocol) completed by the interaction between the client and the server, which completes the entire query process by calculating the search token and index. The specific steps include:

[0072] In step 1, the client executes the EDBSetup protocol locally, which takes the plaintext database as input and generates an encrypted database, which is outsourced to the (untrusted) cloud server.

[0073] This embodiment designs an EDBSetup protocol for initializing encryption of a plaintext database. The protocol's core processing flow includes plaintext data parsing, Boolean attribute orthogonalization, query index structure construction, and data table encryption. Ultimately, the initialization of the encrypted database content is sent to the server. Parsing the plaintext data primarily involves the client selecting a pseudo-random encryption function and key set that meets system security policies and computational efficiency requirements. It also categorizes the attributes in the relational table into three categories: Boolean attributes used for Boolean filtering, join attributes involved in join operations, and index attributes related to index construction.

[0074] The main computational focus of this embodiment is the orthogonalization of Boolean attributes and the construction of the index structure. The orthogonalization of Boolean attributes primarily involves the client calling the Schmidt orthogonalization function GS_orth(·) on the Boolean attribute set and the auxiliary data set (a predefined set of common attributes to assist in Boolean condition filtering). The orthogonalization vectors are then stored in a mapping so that the corresponding orthogonal vectors can be retrieved based on the Boolean attribute values ​​in the query conditions. After the orthogonalization is complete, the client then proceeds to construct the index components TSet, JSet, and XSet. For each index attribute, the client first obtains the set of row identifiers containing the attribute, and then obtains the Boolean attribute orthogonal vectors and pseudo-random encrypted items of the row identifiers for each record containing the row identifier. The pseudo-random encrypted items of the concatenated attributes, index attributes, and a counter are then combined, along with the symmetrically encrypted row identifier items. These three items serve as the index entries for the record. TSet is a multi-mapping of index attribute values ​​to the Boolean attributes and row identifier-related index entry sets for the records containing the attribute values. The Boolean attributes included in the Boolean filter conditions are used to filter the Boolean attributes in the records. JSet is a multi-mapping of index attributes to the set of index entries related to the join attributes containing records with that attribute. It is used to perform private set intersection of join attributes across multiple query tables during a query, thereby identifying shared join attribute values. XSet, a set of join labels generated by processing all row identifiers and join attribute values ​​in a relational table through a pseudorandom function, is used to perform private set intersection of join attributes during multi-table joins and assist in validating and filtering matching records.

[0075] Finally, the protocol will package the constructed connection indexes TSet, JSet and XSet and upload them to the server, and encrypt the relational table using a randomized encryption algorithm to obtain a semantically secure relational encrypted database that supports flexible Boolean condition filtering connection queries.

[0076] See Figure 3 The following is a flowchart of the EDBSetup protocol for the multi-table connection method that supports Boolean queries. The specific steps of the EDBSetup protocol for the multi-table connection method that supports Boolean queries include:

[0077] Step 11. Figure 3 As shown by arrow ①, after the protocol begins, the client first parses the plaintext database. This includes selecting a pseudo-random encryption function and a symmetric encryption algorithm, randomly selecting a key set K, and classifying the attribute columns in the plaintext relational table into Boolean attributes, join attributes, and index attributes.

[0078] Step 112: After the EDBSetup protocol starts, the client selects a secure pseudo-random encryption function F(·) (e.g., HMAC hash message authentication code) and a symmetric encryption technology Enc(·) (e.g., AES symmetric encryption algorithm) to encrypt the result set that meets the system security and performance requirements.

[0079] Step 113: The client randomly selects a key set K to ensure secure encryption of local data.

[0080] In step 114, the attribute columns in the relational table are classified into three categories: Boolean attributes used for Boolean condition filtering, connection attributes involved in connection operations, and index attributes used to build indexes, to support differentiated processing operations of subsequent attribute types. At this point, the initial step of the protocol regarding the parsing of the plaintext database is completed.

[0081] Step 12. Figure 3 As shown by arrow ②, after the protocol completes database parsing, it performs orthogonalization of Boolean attributes. The client uses a pseudo-random permutation function to pseudo-randomly permute the Boolean attribute set and concatenates the permuted attribute values ​​with the position vectors to obtain an initial set of uncorrelated Boolean vectors. All vectors are then processed using the Schmidt orthogonalization function to obtain the final set of mappings between attribute values ​​and their orthogonal vectors.

[0082] Step 121: Use a pseudo-random permutation function Π(·) to randomly permute the Boolean attributes and the auxiliary query vector set to ensure the privacy of the attributes;

[0083] Step 122, concatenate the replaced attribute values ​​with the position vector e to obtain an initial set of uncorrelated Boolean vectors {f};

[0084] Step 123 , input the Boolean vector set {f} into the Schmidt orthogonalization function GS_orth(·) to obtain the final attribute value and its orthogonal vector mapping V. At this point, the orthogonalization of the Boolean attribute is completed.

[0085] Step 13. Figure 3 As shown by arrow ③, the protocol executes index construction. For each index attribute, the row identifier set, Boolean attribute set, and connection attribute set in each record contained in each index attribute are first processed using a pseudorandom function. Then, vector addition, vector multiplication by the pseudorandom function value, and XOR operation on the pseudorandom function value are performed to obtain the Bloom filter for each index item and connection label, which is then uploaded to the server.

[0086] Step 131: For each index attribute, first obtain the row identifier set {ind} containing the attribute, and obtain the Boolean attribute set W of each record where the row identifier is located. bl , connection attribute set W jn;

[0087] Step 132: For each index attribute, process row by row: calculate the sum of the orthogonal vectors of the Boolean attribute and the auxiliary attribute, calculate the product of the pseudo-random encrypted value of the row identifier and the auxiliary orthogonal vector, and add the two values ​​to obtain the Boolean index item of the row;

[0088] Step 133: Calculate the pseudo-random encrypted value of each index attribute of the row and the pseudo-random encrypted value of the index attribute and a counter, perform an XOR operation on the two values ​​to obtain the join index entry of the row, and perform an XOR operation on each index attribute of the row and the pseudo-random encrypted value of the row identifier to obtain the join tag value.

[0089] Step 134: symmetrically encrypt the row identifier of the row to obtain an encrypted row identifier. At this point, all index-related items are calculated.

[0090] Step 135: Pack the Boolean index items and encrypted row identifiers of each row of the index attribute into T, and combine the T used into the Boolean index TSet of the table. Store the deduplicated connection index items in the connection index JSet of the table, and store the connection labels in the Bloom filter XSet to improve computing efficiency. At this point, all query indexes are ready.

[0091] Step 14. Figure 3 As shown by arrow ④, the protocol performs encryption of the data table. The client will encrypt the data table using a random encryption algorithm;

[0092] Each data table in the plaintext database is encrypted using a randomized symmetric encryption algorithm, ensuring a semantically secure relational, encrypted database. This technology uses indexing to implement join queries that support Boolean queries, separate from table encryption. Finally, the client uploads the indexed and encrypted data tables to the server, resulting in a semantically secure relational, encrypted database. This completes the EDBSetup protocol.

[0093] Step 15. Figure 3 As shown by arrow ⑤, the protocol uploads the encrypted data table to the server. At this time, the entire database processing is completed, and a semantically secure relational encrypted database is obtained.

[0094] In step 2, the client and the server jointly execute a two-party Search protocol, which performs a join query supporting Boolean condition filtering in a relational encrypted database.

[0095] This embodiment designs a search protocol for executing secure multi-table join queries on a relational encrypted database. In summary, it is a two-party search protocol jointly executed by a client and a server, where the client input is the query to be executed, and the server input is the encrypted database (EDB). It consists of a single round of communication (i.e., a query message from the client to the server, followed by a response message from the server to the client). At the end of the protocol, the client should have learned the set of record indexes that match the Boolean query condition.

[0096] In the first step of a query, the client generates a "query message" and sends it to the server. This "query message" is a token calculated from the index attributes, join attributes, and Boolean properties extracted from the SQL query statement. The protocol first calculates a TSet lookup token based on the index attributes and a JSet lookup token based on the index attribute and join attribute pairs. It then calculates the Boolean conditional filter and join query calculation tokens based on the Boolean attribute and join attribute names, respectively. After the client calculates all the token information using pseudo-random encryption, it sends it as a "query message."

[0097] In the second step of the query, the server generates a "response message" and sends it to the client. The "response message" is an encrypted row identifier selected based on the calculation between the token information received from the client and the relevant index items. The Boolean operation involves the inner product of the orthogonal vectors of the Boolean token and the corresponding entry in the TSet. The join operation is the exclusive-or operation of the join token and the corresponding entry in the JSet to obtain the intersection of the join attributes of the query table. This result is exclusive-ored with the inner product result to obtain the final join label. The encrypted row identifier of the final matching join record is obtained by determining whether the XSet contains the label.

[0098] In the third step of the query, the client decrypts the received row identifier to obtain the final matching result. The process of the client retrieving the encrypted data from the secret database based on the row identifier is omitted in this embodiment. Its implementation method can refer to the conventional data access method in the plaintext database.

[0099] See Figure 4 The figure shows a flowchart of the Search protocol for a multi-table join method that supports Boolean queries. The specific steps of the Search protocol for a multi-table join method that supports Boolean queries include:

[0100] 1. Such as Figure 4 As shown by arrow ①, the client parses the SQL statement, obtains the Boolean attributes, index attributes, and connection attribute names involved in the Where condition in the plaintext SQL statement, and prepares a pseudo-random encryption function, a symmetric encryption algorithm, and a key set.

[0101] 2. Such as Figure 4 As shown by arrow ②, the client inputs the attributes into the pseudo-random encryption function based on the index attributes and the token generation algorithm of the encrypted multi-mapping technology to generate an index lookup token for reading the relevant index items.

[0102] The method for generating a client token includes the following steps:

[0103] Step 21: Based on the relevant information of the query table and query column in the plaintext SQL statement, an index search token for searching TSet and JSet related items is generated according to the token generation algorithm of the encrypted multi-mapping technology, and the token is sent to the server. The server receives the token and reads the index related items;

[0104] Step 22: Based on the Boolean attributes involved in the Where condition in the plaintext SQL statement, the client obtains the corresponding orthogonal vector from the mapping V and generates the corresponding large integer using a pseudo-random generator. The client multiplies the orthogonal vector by the integer and calculates the vector sum. The resulting vector is sent to the server as a Boolean query token.

[0105] Step 23: Based on the index attributes and table connection attributes in the plaintext SQL statement, the client calculates the pseudo-random function value of the index attribute name and the pseudo-random function value of the index attribute cascade counter, XORs the two values ​​to obtain a connection query token, and sends it to the server.

[0106] Step 24: Based on the relevant calculations of the Boolean query token and the connection query token, the client calculates the obtained random large integer and performs an XOR operation with the index attribute pseudo-random function value to obtain the result test token and sends this token to the server. At this point, the token generation phase is completed.

[0107] 3. Such as Figure 4 As shown by arrow ③, the client obtains the orthogonal vector of the Boolean attribute and uses a pseudo-random generator to generate the corresponding random large integer. The orthogonal vector and the integer are multiplied one by one and summed. The sum is the Boolean query token.

[0108] 4. Such as Figure 4 As shown by arrow ④, the client calculates the pseudo-random function value of the index attribute name and the pseudo-random function value of the index attribute cascade counter, and XORs the two values ​​to obtain the connection query token.

[0109] 5. Such as Figure 4 As shown by arrow ⑤, the client calculates all query tokens and sends them to the server. This technical method does not include the encryption design of the relational table, so it is omitted here.

[0110] 6. Such as Figure 4 As shown by arrow ⑥, the server looks up the token based on the index and reads the index entries of all connection tables, including Boolean index, connection index and result Bloom filter.

[0111] 7. Such as Figure 4 As shown by arrow ⑦, the server performs an inner product operation on the Boolean query token and the Boolean index related items to filter the Boolean conditions in the query.

[0112] The server computes the inner product of the received Boolean query token with the query-related items in the TSet index, obtaining the calculated result value. This calculation process is identical for each query table, allowing parallel computation. At this point, the Boolean conditional filtering calculations are complete.

[0113] 8. Such as Figure 4 As shown by arrow ⑧, the server performs an XOR operation on the connection query token and the connection index related items, and uses the Bloom filter to perform a membership test to achieve the intersection operation of multi-table connection attributes and reduce the leakage of subqueries.

[0114] Improve the security of the solution.

[0115] In the Search protocol, the process of finding the intersection of private sets of inter-table join attributes includes the following steps:

[0116] Step 26: The server performs an XOR operation on the received connection query token and the corresponding item in the JSet to obtain the relevant value of the connection attribute;

[0117] Step 27: The XOR result is tested for membership in the Bloom filter XSet. If True is returned, the connection attribute contained in the relevant value is a common connection attribute contained in the query table, and the value is retained as the intermediate result of the query. If False is returned, it is not a common connection attribute, and the value is not retained. At this point, the intersection process of the privacy set of connection attributes is completed.

[0118] 9. Such as Figure 4 As shown by arrow ⑨, the server performs an XOR operation on the inner product result and the intermediate result that passed the membership test, and then performs a membership test on the XOR result value again using the filter. This step constitutes the key path for supporting parallel computing optimization in this invention and significantly improves the efficiency of join queries under parallel execution optimization.

[0119] 10. Such as Figure 4 As shown by arrow ⑩, the server returns the encrypted row identifier item of the member test pass entry to the client.

[0120] Complete the entire search process for the protocol.

[0121] Step 3: The client obtains the records that meet the query requirements from the database relational table based on the row identifier returned by the Search protocol.

[0122] The specific steps of selecting query results in the Search protocol include:

[0123] Step 31: XOR the intermediate result of the JSet index calculation with the inner product value of the TSet calculation to obtain the final connection label. This step is calculated in parallel between tables, greatly improving the efficiency of the solution.

[0124] Step 32 performs a membership test on the connection tag Bloom filter XSet. If the return value is True, the relevant entry is part of the query result. The set {ct} of encrypted row identifiers corresponding to TSet for all tables is returned and sent to the client. If the return value is False, the value is skipped. This completes all operations of the Search protocol.

[0125] The join index structure JSet designed in this embodiment combines with a Bloom filter to perform a private set intersection operation on join attributes. Furthermore, by implementing a Distinct storage strategy on join index entries, only the unique representation of each join attribute value within a single table is retained. This effectively improves the security and computational efficiency of this method during queries and significantly reduces server-side storage load.

[0126] 1. The client performs an XOR operation on the deduplicated join index and the pseudo-random encrypted value of the concatenated counter of the current index attribute. The counter ensures the randomness of the encryption result, improving the security of the method. This is because the server cannot obtain any plaintext information by reading and analyzing the ciphertext data. Deduplicated join indexes can reduce server storage pressure and the additional computational overhead caused by repeated calculations.

[0127] 2. During the intersection of join attribute privacy sets, a table's JSet and a Bloom filter XSet for all tables are specified. The server performs the intersection filtering operation on the join attributes between multiple tables on the JSet, and subsequent calculations are performed only on these common items. This process only involves deduplicating join attribute index information for one query table, reducing the subquery leakage issues faced by traditional join queries and facilitating subsequent parallel computing optimization, thereby improving the security and computational efficiency of this technology.

[0128] 3. After obtaining the JSet index items related to the common connection attributes, these items are XORed in parallel with the intermediate results of the Boolean calculations of all query tables. This reduces the time overhead caused by serial calculations in traditional connection query methods and improves the query efficiency of the solution.

[0129] See Figure 5 The figure shows a comparison of the security of the present invention and other connection methods. Theoretically, the present invention has less leakage than the existing solution, performs better in security, and supports more functions.

[0130] To demonstrate the advanced nature of the present invention, this embodiment is compared with the most advanced symmetric join method. The first paper to use non-precomputed symmetric index technology to solve join queries on encrypted databases was "Efficient Searchable Symmetric Encryption for Join Queries" (JXT) proposed by Jutla et al. in ASIACRYPT'22. This protocol uses a searchable encrypted inverted index to establish a join index and designs a random cross-labeling technique to jointly complete the calculation of the join query. However, the security and query efficiency of this query are low, which is not conducive to practical deployment. To improve the security and efficiency of JXT and expand the secure multi-table join query function, Du et al. proposed "Scalable Equi-Join Queries over Encrypted Database" (JXT+ for the two-table join solution and JXT++ for the multi-table join solution) in CCS'24. This protocol can safely and efficiently support multi-table join solutions through the transformation of the index structure and the introduction of Xor filters. However, the current JXT series of solutions can only support fixed-type SQL statements and cannot support flexible filtering of Boolean where conditions, resulting in limited query functionality. Wu et al. proposed "Practical Searchable Symmetric Encryption for Arbitrary Boolean Query-Join in Cloud Storage" (TNT-QJ) at TIFS'24. This technically integrates the Boolean query functionality and JXT join functionality of "Highly-scalable searchable symmetric encryption with support for boolean queries" (OXT) proposed by Cash et al. at CRYPTO'13 and "Two-in-one-sse: Fast, scalable and storage-efficient searchable symmetric encryption for conjunctive and disjunctive boolean queries" (TWIN) proposed by Bag et al. at PETS'22. This solution implements join functionality under Boolean query conditions and reduces storage and query costs by utilizing a semi-complete multi-branch search tree. However, this solution has high computational complexity and cannot simply support all types of Boolean queries. It also lacks flexible and secure multi-table query capabilities (due to the problem of subquery leakage between multiple tables). The present invention effectively enhances the system's privacy protection capabilities during join queries by introducing a padding strategy without increasing the computational burden.At the same time, the privacy set intersection mechanism based on connection attributes and the index processing flow that supports parallel computing significantly improve the overall query efficiency.

[0131] Figure 5 The comparison of the leakage patterns of various solutions in the two-table connection query scenario is shown. Since some existing solutions do not support multi-table connection, a general query statement for two tables is selected as a unified comparison standard. Solid represents complete leakage, hollow represents no leakage, half-heart represents partial information leakage, and horizontal line represents no relevant leakage because this function is not supported. n is the size of the table, RP is the result mode, EP1 is the token equality mode of Table 1, EP2 is the token equality mode of Table 2, SP1 is the size mode of the index item of Table 1, SP2 is the size mode of the index item of Table 2, JD is the distribution mode of the connection attribute, and IP is the information of two filter attributes leaked from multiple queries belonging to one record. It can be clearly seen from the table that the leakage items of the present invention are the least among all the solutions, and only the size of the table and the equality mode of the token will be leaked, which has extremely high security. Moreover, when supporting complex queries, the filtering of Boolean conditions will further hide the frequency information leakage on the index, which has better fine-grained security.

[0132] See Figure 6 The figure shows a comparison of the storage load, computational complexity, and functionality of the present invention and other join methods. Theoretically, the present invention performs well in terms of storage load and computational complexity. In terms of functionality, it performs best, supporting multi-table equijoin methods for Boolean queries.

[0133] Because JXT, JXT+ and JXT++ do not involve the filtering function of Boolean attributes, when it comes to complex Boolean condition filtering, the present invention can complete the query requirements with a single index access, but these three solutions need to be decomposed into more sub-queries, multiple index accesses and a large number of repeated calculations, resulting in serious waste of resources and time overhead, so the computational complexity and efficiency of the present invention will be better for complex queries. TNT-QJ essentially relies on the connection capabilities of the JXT solution and the Boolean operations of OXT, and its performance is worse than that of the present invention in terms of computational complexity and efficiency. The present invention and JXT++ can directly support multi-table queries, but the latter cannot directly support complex Boolean query conditions, so when executing complex query statements, the present invention is better in computational complexity, efficiency and functionality.

[0134] It should be noted that, in this document, relational terms such as first and second, etc., are used solely to distinguish one entity or operation from another, and do not necessarily require or imply any actual relationship or order between these entities or operations. Furthermore, the terms "include," "comprise," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or terminal device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. Without further limitation, elements defined by the phrase "include..." or "comprising..." do not exclude the presence of additional elements in the process, method, article, or terminal device comprising the elements. Furthermore, in this document, "greater than," "less than," "exceeding," etc., are understood to exclude the number itself; "above," "below," "within," etc., are understood to include the number itself.

[0135] Although the above embodiments have been described, those skilled in the art may make additional changes and modifications to these embodiments once they know the basic creative concepts. Therefore, the above descriptions are merely embodiments of the present invention and do not limit the scope of patent protection of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention's description and drawings, or directly or indirectly applied in other related technical fields, are also included in the scope of patent protection of the present invention.

Claims

1. A multi-table join method supporting Boolean queries in a secret database, characterized by: It includes the following steps, Step 1: The client locally executes a random algorithm—the EDBSetup protocol, which takes a plaintext database as input and generates an encrypted database and outsources it to the server. Step 11: After the EDBSetup protocol begins, the client first parses the plaintext database, including selecting a pseudo-random encryption function and a symmetric encryption algorithm, randomly selecting a key set, and classifying attribute columns in the plaintext relational table into Boolean attributes, join attributes, and index attributes. Step 12: After the EDBSetup protocol completes database parsing, it performs orthogonalization on the Boolean attributes. The client uses a pseudo-random permutation function to pseudo-randomly permute the Boolean attribute set and concatenates the permuted attribute values ​​with the position vectors to obtain an initial set of uncorrelated Boolean vectors. All vectors are then Schmidt-orthogonalized to obtain the final mapping set of attribute values ​​and their orthogonal vectors. Step 13: The EDBSetup protocol executes index construction. For each index attribute, the row identifier set, Boolean attribute set, and connection attribute set in each record of each index attribute are first processed using a pseudorandom function. Vector addition, multiplication of vectors with pseudorandom function values, and operations between pseudorandom function values ​​are then performed to obtain the Bloom filter for each index item and connection label, which is then uploaded to the server. Step 14: The EDBSetup protocol executes encryption of the data table. The client uses a random encryption algorithm to encrypt the data table. Step 15: The EDBSetup protocol uploads the encrypted data table to the server; Step 2: The client and server jointly execute a two-party protocol, the Search protocol, which inputs the encrypted database, performs Boolean condition filtering and join queries, and outputs the query results. Step 3: The client decrypts the encrypted row identifier output by the Search protocol to obtain the final query result.

2. The multi-table join method supporting Boolean query in a secret database according to claim 1, characterized in that: The EDBSetup protocol in step 11 includes a method for the client to parse the plaintext database, and its specific steps include: Step 112: After the EDBSetup protocol starts, the client selects a predetermined secure pseudo-random encryption function that meets local data processing requirements. and symmetric encryption technology to encrypt the result set ; Step 113: The client randomly selects a key set , ensuring the secure encryption processing of local data; Step 114 classifies the attribute columns in the relational table into three categories: Boolean attributes used for Boolean condition filtering, connection attributes involved in connection operations, and index attributes used to build indexes, to support subsequent classification processing of different attributes. At this point, the initial step of the protocol regarding the parsing of the plaintext database is completed.

3. The multi-table join method supporting Boolean query in a secret database according to claim 1, characterized in that: The EDBSetup protocol in step 1 includes orthogonalization of Boolean attributes, and the specific steps include: Step 121, using pseudo-random permutation function Randomly permuting the Boolean attributes and auxiliary query vector sets to ensure the privacy of the attributes; Step 122: Concatenate the replaced attribute value with the position vector Get the initial set of uncorrelated Boolean vectors ; Step 123, set the Boolean vector Input to the Schmidt orthogonalization function , get the final attribute value and its orthogonal vector mapping , at this point, the orthogonalization of Boolean attributes is completed.

4. The multi-table join method supporting Boolean query in a secret database according to claim 1, characterized in that: The construction of the query index of the EDBSetup protocol in step 1 includes the following specific steps: Step 131: For each index attribute, first obtain the row identifier set containing the attribute , and get the Boolean attribute set of each row identifier record , connection property set ; Step 132: For each index attribute, process row by row: calculate the sum of the orthogonal vectors of the Boolean attribute and the auxiliary attribute, calculate the product of the pseudo-random encrypted value of the row identifier and the auxiliary orthogonal vector, and add the two values ​​to obtain the Boolean index item of the row; Step 133: Calculate the pseudo-random encrypted value of each connection attribute of the row and the pseudo-random encrypted value of the index attribute and a counter, perform an XOR operation on the two values ​​to obtain the connection index entry of the row, and perform an XOR operation on each index attribute of the row and the pseudo-random encrypted value of the row identifier to obtain the connection label. Step 134: symmetrically encrypt the row identifier of the row to obtain an encrypted row identifier. At this point, all index-related items are calculated. Step 135: Pack the Boolean index item and encrypted row identifier of each row of the index attribute into a and use The Boolean index TSet of the table is combined, the deduplicated connection index items are stored in the connection index JSet of the table, and the connection labels are stored in the Bloom filter XSet to improve computing efficiency. At this point, all query indexes are ready.

5. The multi-table join method supporting Boolean query in a secret database according to claim 1, characterized in that: The encryption of the data table in the EDBSetup protocol in step 1 includes the following specific steps: Each data table in the plaintext database is encrypted using a randomized symmetric encryption algorithm to achieve the goal of semantically secure ciphertext protection and build a relational secret database. This technology uses indexing technology to complete a connection query method that supports Boolean queries, which is separate from the encryption of the data table. Finally, the client uploads the index and encrypted data table to the server to obtain a semantically secure relational secret database. At this point, the EDBSetup protocol is executed.

6. The multi-table join method supporting Boolean query in a secret database according to claim 1, characterized in that: The step 2 specifically comprises: The client generates a "query message" and sends it to the server. The "query message" is a set of query tokens calculated from the index attributes, connection attributes, and Boolean attributes extracted from the SQL query statement. The Search protocol first calculates the TSet search token based on the index attributes and the JSet search token based on the index attributes and connection attribute names. It then calculates the Boolean condition filtering and connection query calculation tokens based on the Boolean attributes and connection attribute names respectively. The server generates a "response message" and sends it to the client. The "response message" is a set of encrypted row identifiers filtered by calculating the token constructed by the client and the index maintained by the server. The Boolean conditional filtering operation is implemented by performing an inner product operation on the Boolean query token and the corresponding entry in TSet. The join operation is implemented by performing an XOR operation on the join query token and the corresponding index item in JSet to obtain the intersection of the join attributes of all query tables. The server then XORs each element in this set with the inner product result to obtain a label value. The server determines whether the label value exists in the Bloom filter XSet to determine whether it is a valid match. The client decrypts the received row identifier to obtain the final matching result.

7. The multi-table join method supporting Boolean query in a secret database according to claim 6, characterized in that: The method for generating the client's token set in step 2 includes the following specific steps: Step 21: Based on the relevant information of the query table and query column in the plaintext SQL statement, an index search token for searching TSet and JSet related items is generated according to the token generation algorithm of the encrypted multi-mapping technology, and the token is sent to the server. The server receives the token and reads the index related items; Step 22: Based on the Boolean attributes involved in the Where condition in the plain text SQL statement, the client selects the mapping Get the corresponding orthogonal vector from , and use the pseudo-random generator to generate the corresponding large integer. After multiplying an orthogonal vector by an integer, calculate the vector sum, and send the vector sum as a Boolean query token to the server; Step 23: Based on the index attribute and connection attribute name in the plaintext SQL statement, the client calculates the pseudo-random function value of the connection attribute name and the pseudo-random function value of the index attribute cascade counter, XORs the two values ​​to obtain a connection query token, and sends it to the server. Step 24: Based on the related calculations of the Boolean query token and the connection query token, the client calculates the XOR operation of the random large integer and the index attribute pseudo-random function value to obtain the result test token and sends this token to the server. At this point, the token generation phase is completed.

8. The multi-table join method supporting Boolean query in a secret database according to claim 7, characterized in that: In step 2, the method for calculating the intersection of Boolean condition filtering and connection attributes of all query tables in the Search protocol includes the following specific steps: Step 25: To complete the Boolean condition filtering, the server performs an inner product calculation on the received Boolean query token and the query-related items in the TSet index items to obtain the calculated result value. Since this calculation process is the same and independent in each query table, it can be executed in parallel to improve query efficiency. Step 26: The server performs an XOR operation on the received connection query token and the corresponding item in the JSet to obtain a set of candidate connection attribute values. In step 27, the server inputs the XOR result into the Bloom filter XSet for membership test. If the return value is True, it means that the connection attribute value is a common connection attribute of all query tables, and the value is retained as the query intermediate result; otherwise, it is discarded.

9. The multi-table join method supporting Boolean query in a secret database according to claim 1, characterized in that: The specific steps of selecting the query results in the Search protocol in step 3 include: Step 31: XOR the intermediate result of the JSet index calculation with the inner product value calculated by TSet to obtain the final label value. This step can be calculated in parallel across tables, improving query execution efficiency. Step 32: Input the tag value into the Bloom filter XSet to perform a membership test. If True is returned, the relevant entry is the content of the query result. At this time, the set of encrypted row identifiers corresponding to TSet of all tables is returned. , and send the collection to the client, if it returns False, then skip the value.

Images