Multi-table connection method supporting Boolean query in cryptographic database

Abstract

The invention belongs to the research field of data privacy protection and efficient cryptographic calculation in a cryptographic database, particularly a relational cryptographic database, and particularly relates to a multi-table connection method supporting Boolean query in the cryptographic database. The method comprises the following steps: step 1, a client executes an initialization protocol (including four modules of plaintext data analysis, Boolean attribute orthogonalization processing, index construction and database encryption) of a secret database; step 2, the client and the server interact to realize a search protocol (including that the client sends a generated'query message 'to the server, and the server sends a generated'response message' to the client); and step 3, the client decrypts the response result to obtain a matching result of the plaintext line identifier meeting the query condition.

Description

Technical Field

[0001] The present invention relates to the technical field of encrypted databases, and particularly to a multi-table join method supporting Boolean queries, which is applicable to scenarios of realizing data privacy protection and efficient encrypted computing in relational encrypted databases. The method includes an initialization protocol for the encrypted database (including four modules: plaintext data parsing, Boolean attribute orthogonalization processing, index construction, and data encryption) and a search protocol (including three stages: the client generates and sends a "query message", the server generates a "response message" and returns it to the client, and the client decrypts the response result). Background Art

[0002] The multi-table join query in a relational encrypted database aims to perform a secure join operation on two or more relation tables that have been randomly encrypted, ensuring that no other information is leaked except for the query result. As a key function in encrypted databases, the secure equijoin query has wide applications in various practical scenarios. For example, in an e-commerce platform, merchants store user information (such as registration information, order information, and product information, etc.) in a cloud encrypted database to achieve efficient storage and query analysis. Due to the privacy of user personal information, merchants need to ensure that the data remains 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 by using logical operators (such as AND, OR, NOT) to accurately filter data that meets specific conditions. This combined query method can effectively reduce redundant calculations and communication overhead in a large-scale data environment, thereby improving the overall query efficiency. For example, in an e-commerce platform, by joining the user table and the order table and combining the filtering conditions, the user information of those who purchased a certain product within a specific time can be queried, thus achieving accurate business analysis. Therefore, on the premise of ensuring data privacy, implementing a multi-table join method supporting Boolean queries on relational encrypted databases is a key issue that urgently needs to be solved in the field of encrypted databases and has great potential in both theory and practical applications.

[0004] Consider the task of implementing multi-table joins that support boolean queries in a relational encrypted database, i.e., on the premise of data encryption, perform secure join queries on data entries that meet the boolean query conditions and return the matching data entries. In recent years, a variety of equijoin query schemes have been proposed in this field. Among them, in pure software implementations, one type is the scheme that designs a new data encryption algorithm using public key encryption technologies (such as attribute-based encryption technologies), which can achieve the security goal of fine-grained frequency hiding and the functional requirements of complex condition filtering. However, the computational complexity of such query algorithms is high and the query efficiency is low. Another type is the "join cross-tag" scheme based on pure symmetric encryption algorithms, which constructs a "join inverted index" similar to that in searchable encryption and generates cross-tags for join attributes in the table. The server side receives the query token and calculates the match with the index item to identify the join result. Such schemes usually have the characteristics of simple structure, high query efficiency, and low computational complexity, and have good practical deployment feasibility. However, most of the existing multi-table join methods based on cross-tags focus on single-keyword filtering and join queries between two tables. The schemes that support multi-table joins are relatively limited, and it is difficult to effectively handle complex boolean conditions, and it is still impossible to balance query functionality and privacy protection requirements. Summary of the Invention

[0005] Aiming at the deficiencies of the existing technologies in terms of functionality, security, and performance, the present invention proposes a multi-table join method that supports boolean queries. By using efficient symmetric encryption technologies and indexing technologies, it realizes the join operation of any boolean condition matching items on a relational encrypted database, can securely and efficiently implement join queries of three or more tables, has stronger functionality than the existing symmetric encryption two-table join scheme, and can ensure higher security and lower query complexity.

[0006] The present invention aims to provide a boolean query multi-table join method for a relational encrypted database system to solve the limitations existing in the existing technologies in terms of functionality, security, performance, etc. The proposed scheme achieves an effective balance among functionality, security, and computational performance, and has good scalability and practicability.

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

[0008] A multi-table equijoin method that supports boolean condition filtering on a relational encrypted database, including the following steps,

[0009] Step 1, the client executes a random algorithm - EDBSetup protocol locally. This protocol takes a plaintext database as input, generates an encrypted database (encrypted database), and outsources this database to an (untrusted) server.

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

[0011] Step 3: The client decrypts the encrypted row identifiers returned by the Search protocol and extracts and recovers the final record set that meets the query conditions from the encrypted database.

[0012] For further optimization of this technical solution, step 1 specifically includes:

[0013] Step 11: After the EDBSetup protocol starts, the client will first perform the parsing of the plaintext database, including the selection of the pseudo-random encryption function and the symmetric encryption algorithm, the random selection of the key set, and the division of the attribute columns in the plaintext relation table into Boolean attributes, join attributes, and index attributes.

[0014] Step 12: After the EDBSetup protocol completes the parsing of the database, perform the orthogonalization process of the Boolean attributes. The client uses the pseudo-random permutation function to pseudo-randomly permute the Boolean attribute set, and cascades the permuted attribute values with the position vectors to obtain an initial set of mutually uncorrelated Boolean vectors. Then, all the vectors are processed by the Schmidt orthogonalization function to obtain the final mapping set of the attribute values and their orthogonal vectors.

[0015] Step 13: The EDBSetup protocol constructs the index. For each index attribute, first process the row identifier set, Boolean attribute set, and join attribute set in each record included in each index attribute using the pseudo-random function, and then perform vector addition, multiplication of the vector and the pseudo-random function value, and XOR operation of the pseudo-random function values to obtain the Bloom filters of each index item and join label, and upload them to the server.

[0016] Step 14: The EDBSetup protocol encrypts the data table. The client will use the random encryption algorithm to encrypt the data table.

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

[0018] For further optimization of this technical solution, the EDBSetup protocol in step 11 includes the method for the client to parse the plaintext database, and its specific steps include:

[0019] Step 112: After the EDBSetup protocol starts, the client will select 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 set of keys K to ensure the secure encryption processing of local data;

[0021] Step 114, classify the attribute columns in the relationship table into three categories: boolean attributes for boolean condition filtering, join attributes involved in join operations, and index attributes for building indexes, to support the differential processing of different attributes by subsequent modules. So far, the parsing of the plaintext database in the initial steps of the protocol is completed.

[0022] For the further optimization of this technical solution, the EDBSetup protocol in Step 1 includes the orthogonalization processing of boolean attributes, and its specific steps are as follows:

[0023] Step 121, use the pseudo-random permutation function Π(·) to randomly permute the boolean attributes and the set of auxiliary query vectors to enhance the privacy protection ability of the attributes during storage and calculation;

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

[0025] Step 123, input the set of boolean vectors {f} into the Schmidt orthogonalization function GS_orth(·) to obtain the final mapping V of the attribute values and their orthogonal vectors. So far, the orthogonalization of the boolean attributes is completed.

[0026] For the further optimization of this technical solution, the construction of the query index in the EDBSetup protocol in Step 1, its specific steps are as follows:

[0027] Step 131, for each index attribute, first obtain the set of row identifiers {ind} containing this attribute, and obtain the set of boolean attributes W bl and the set of join attributes W jn ;

[0028] Step 132, for each index attribute, process by row: calculate the sum of the orthogonal vectors of the boolean attributes and the auxiliary attributes, calculate the product value 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 term of this row;

[0029] Step 133, calculate the pseudo-random encrypted value of each index attribute of this row and the pseudo-random encrypted value of the sum of an index attribute and a counter, perform an exclusive OR operation on the two values to obtain the join index term of this row, and perform an exclusive OR operation on the pseudo-random encrypted value of each index attribute of this row and the row identifier to obtain the join label;

[0030] Step 134, perform symmetric encryption on the row identifier of this row to obtain the encrypted row identifier. So far, all index-related terms 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 used T 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 the calculation efficiency. At this point, all query indexes are ready.

[0032] The 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 random symmetric encryption algorithm to achieve the protection goal of semantic security and build a relational secret database. This project greatly improves the efficiency of the solution and uses index technology to complete the 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.

[0034] The 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 attributes and connection attributes. Then, the calculation tokens of Boolean condition filtering and connection query are obtained according to the Boolean attributes and connection attribute names respectively.

[0036] The server generates a "response message" and sends it to the client. The "response message" is the encrypted row identifier set obtained by filtering the server based on the calculation result between the token information provided by the client and the index items it maintains. Among them, the Boolean condition filtering is completed by performing an inner product operation on the Boolean query token and the orthogonal vector of the corresponding index entry in TSet; the connection operation is completed by performing an XOR operation on the connection query token and the corresponding entry in JSet to calculate the intersection set of the connection attributes between the query tables, and complete the privacy set intersection operation of the connection attributes.

[0037] Subsequently, the server performs an XOR operation on each connection attribute value in the intersection set and 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 determined to be a valid match, and its corresponding encrypted row identifier is retained as the query result and returned to the client.

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

[0039] The technical solution is further optimized, and the method for generating the token of the client 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, according to the token generation algorithm of the encrypted multi-mapping technology, an index search token for searching TSet and JSet related items is generated and sent to the server. The server receives the token and reads the index related items;

[0041] Step 22: According to the Boolean attribute 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. After multiplying an orthogonal vector by an integer, the vector sum is calculated, and the final vector is sent to the server as a Boolean query token.

[0042] Step 23: According to the index attribute and table connection attribute 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 related calculations of the Boolean query token and the connection query token, the client calculates the obtained random large integer and the 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] The technical solution is further optimized, and the index calculation of the Boolean condition filtering in the Search protocol in step 2 includes the following specific steps:

[0045] Step 25, the server performs inner product calculation on the received Boolean query token and the query related item in the TSet index item to obtain the calculated result value. The calculation process of each query table is the same, so it can be calculated in parallel. At this point, the calculation related to the Boolean condition filtering is completed.

[0046] The technical solution is further optimized in that the Search protocol in step 2 supports the intersection of private sets of connection attributes between tables, and the specific steps include:

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

[0048] Step 27: Perform a membership test on the XOR result in the Bloom filter XSet. If the return value is True, the connection attribute contained in the relevant value is the common connection attribute contained in the query table, and this value is retained as the intermediate result of the query. If the return value is False, it is a non-common connection attribute and this value is not retained. Thus, the process of private set intersection of connection attributes is completed.

[0049] For a further optimization of this technical solution, in the selection of the query result in the Search protocol in step 3, the specific steps are as follows:

[0050] Step 31: Perform an XOR operation on the intermediate result of the previous JSet index calculation and the inner product value calculated by TSet to obtain the final tag value. This step is calculated in parallel between 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 the content of the query result. At this time, return the set {ct} of the encrypted row identifiers corresponding to the TSet of all tables and send this set to the client. If the return value is False, skip this value. Thus, all operations of the Search protocol are completed.

[0052] Different from the prior art, the above technical solution has the following beneficial effects:

[0053] 1. Enhance the functionality of the symmetric encryption connection solution, especially support Boolean condition filtering and multi-table join functions;

[0054] 2. Reduce information leakage in the multi-table join query process and improve security;

[0055] 3. Improve the query efficiency of the Boolean query connection solution;

[0056] 4. Reduce the storage pressure of the Boolean query connection solution. Description of the Drawings

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

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

[0059] Figure 3 It is a flowchart of the EDBSetup protocol of the multi-table join method supporting Boolean queries;

[0060] Figure 4 It is a flowchart of the Search protocol of the multi-table join method supporting Boolean queries;

[0061] Figure 5 It is a schematic diagram showing the security comparison between the present invention and other connection methods;

[0062] Figure 6 It is a schematic diagram showing the comparison of storage load, computational complexity, and functionality between the present invention and other connection methods. Specific embodiments

[0063] To describe in detail the technical content, structural features, achieved objectives, and effects of the technical solution, the following will be described in detail with specific embodiments in conjunction with the accompanying drawings.

[0064] In this specific embodiment, the complete query process of a relational confidential database mainly includes the parsing and encryption operations from plaintext SQL statements to encrypted query SQL statements driven by the client. The database management system in the cloud parses the received SQL statements and performs the reading and processing of confidential data.

[0065] Refer to Figure 1 As shown, it is a model schematic diagram of the query process of a relational confidential database system. The innovation of this technology mainly involves the parsing of multi-table join query SQL statements with boolean filtering conditions by the client driver (the generation protocol of query tokens), and the database management system on the server side can perform join queries supporting boolean attribute filtering on encrypted data. A complete execution process includes:

[0066] 1. As Figure 1 shown by arrow ①, when the user executes a query, the user will input plaintext SQL commands through the local APP, and the client driver is responsible for parsing and encrypting;

[0067] 2. As Figure 1 shown by arrows ②③④, the client driver will obtain the key set K, encrypt the private attributes in the SQL statement and calculate the query tokens, and embed them into the SQL statement to be sent to the server in ciphertext form;

[0068] 3. As Figure 1 shown by arrows ⑤⑥, the server will parse and optimize the received SQL statement, and obtain relevant indexes and encrypted data tables from the confidential storage to execute query calculations. After completion, the query results will be returned to the client;

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

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

[0071] Refer to Figure 2As shown, the innovation of this technology mainly involves the design of a protocol to support Boolean queries, mainly the client initialization protocol (EDBSetup protocol), which constructs a ciphertext database based on plaintext data information. There is also a search protocol (Search protocol) completed through the interaction between the client and the server. Through the calculation of search tokens and indexes, the entire query process is completed. The specific steps are as follows:

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

[0073] This embodiment designs an initialization EDBSetup protocol for encrypting the plaintext database. The core processing flow of this protocol includes plaintext data parsing, Boolean attribute orthogonality, construction of the query index structure, and ciphertext processing of the data table. Finally, the relevant content of the initialized ciphertext database is sent to the server. Among them, the parsing of plaintext data is mainly the client's selection of a pseudo-random encryption function and a key set that meet the system security policy and computational efficiency requirements, and the classification of attributes in the relational table into three categories: Boolean attributes for Boolean condition filtering, join attributes involved in join operations, and index attributes related to index construction.

[0074] The main calculations in this embodiment focus on the orthogonalization of Boolean attributes and the construction of the index structure. The orthogonalization of Boolean attributes mainly involves the client calling the Schmidt orthogonalization function GS_orth(·) for the Boolean attribute set and the auxiliary data set (a predefined common attribute set for assisting Boolean condition filtering), and storing the orthogonal vectors in a map so that the corresponding orthogonal vectors can be obtained according to the Boolean attribute values in the query conditions. After the orthogonalization process is completed, the client will be committed to the construction of the index components TSet, JSet, and XSet. For each index attribute, first obtain the set of row identifiers containing this attribute, and obtain the Boolean attribute orthogonal vector and the pseudo-random encrypted item of the row identifier of each record where the row identifier is located. The concatenation of the attribute, the index attribute, and the pseudo-random encrypted item of a counter, as well as the symmetrically encrypted row identifier item, these three items serve as the index entry for this record. TSet is a multimap from the index attribute value to the set of index entries related to the Boolean attributes and row identifiers of the records containing this attribute value, and uses the Boolean attributes included in the Boolean filtering condition to perform filtering operations on the Boolean attributes in the records. JSet is a multimap from the index attribute to the set of index entries related to the join attributes of the records containing this attribute, and is used to perform private set intersection on the join attributes in multiple query tables during the query process to identify shared join attribute values. XSet is composed of a set of join tags generated by processing all row identifiers and join attribute values in the relational table through a pseudo-random function, and is used to perform private set intersection of the join attributes during the multi-table join process, and assist in completing the validity verification and screening of matching records.

[0075] Finally, the protocol will package and upload the constructed join indexes TSet, JSet, and XSet 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 join queries.

[0076] Refer to Figure 3 As shown, it is the flowchart of the EDBSetup protocol for the multi-table join method supporting Boolean queries. The EDBSetup protocol for the multi-table join method supporting Boolean queries, its specific steps include:

[0077] Step 11. As Figure 3 Shown by arrow ①, after the protocol starts, the client will first parse the plaintext database. This includes the selection of the pseudo-random encryption function and the symmetric encryption algorithm, the random selection of the key set K, and the division of 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 will select a secure pseudo-random encryption function F(·) (such as HMAC hash message authentication code) that meets the system security and performance requirements and a symmetric encryption technology Enc(·) (such as AES symmetric encryption algorithm) for encrypting the result set;

[0079] Step 113, the client randomly selects a key set K to ensure secure encryption of local data;

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

[0081] Step 12. Figure 3 As shown by arrow ②, after the protocol completes the database parsing, it performs the 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 the initial unrelated Boolean vector set, and then processes all vectors with the Schmidt orthogonalization function to obtain the final attribute value and its orthogonal vector mapping set.

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

[0083] Step 122, concatenating the replaced attribute value with the position vector e to obtain an initial unrelated Boolean vector set {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 pseudo-random function, and then vector addition, vector multiplication with the pseudo-random function value, and XOR operation of the pseudo-random function value are performed to obtain the Bloom filter of each index item and connection label, and upload it 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 the record where each 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 value 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 connection index item of the row, 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 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 used T 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 the calculation efficiency. At this point, all query indexes are ready.

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

[0092] Each data table in the plaintext database is encrypted using a random symmetric encryption algorithm to ensure that the database is a semantically secure relational secret database. This technology uses index technology to complete the 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.

[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 is processed and a semantically secure relational encrypted database is obtained.

[0094] 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 performing secure multi-table join queries on a relational encrypted database. Generally speaking, it is a two-party Search protocol jointly executed by the client and the server, where the input of the client is the query to be executed, and the input of the server is the encrypted database EDB. It consists of one round of communication (i.e., three steps: the query message from the client to the server, and then the response message from the server to the client). At the end of the protocol, the client should learn the set of record indexes that match the boolean query conditions.

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

[0097] In the second step of the query, the server generates a "response message" and sends it to the client. The "response message" is the encrypted row identifiers selected by calculation between the token information obtained from the client and the index-related items. The boolean operation involves the inner product operation of the boolean token and the orthogonal vector of 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, obtaining the intersection of the join attributes of the query table, and XORing the result with the inner product result to obtain the final join label. By determining whether the XSet has this label, the encrypted row identifiers of the finally matched join records are obtained.

[0098] In the third step of the query, the client decrypts the received row identifiers to obtain the final matching results. The process of the client retrieving encrypted data from the encrypted database according to the row identifiers is omitted in this embodiment, and its implementation method can refer to the conventional data access method in the plaintext database.

[0099] See Figure 4 As shown, it is the flowchart of the Search protocol for the multi-table join method that supports boolean queries. The specific steps of the Search protocol for the multi-table join method that supports boolean queries include:

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

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

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

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

[0104] Step 22: According to the Boolean attribute 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. After multiplying an orthogonal vector by an integer, the vector sum is calculated, and the final vector is sent to the server as a Boolean query token.

[0105] Step 23: According to the index attribute and table connection attribute 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 related calculations of the Boolean query token and the connection query token, the client calculates the obtained random large integer and the 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 a 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. 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 relationship 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 indexes, connection indexes, and result Bloom filters.

[0111] 7. As Figure 4 shown by arrow ⑦, the server performs an inner product operation on the Boolean query token and the Boolean index related item to implement the filtering of the Boolean conditions in the query.

[0112] The server performs an inner product calculation on the received Boolean query token and the query related item in the TSet index item to obtain the calculated result value. The calculation process for each query table is the same, so parallel calculation can be performed. Thus, the calculation related to Boolean condition filtering is completed.

[0113] 8. As Figure 4 shown by arrow ⑧, the server performs an exclusive OR operation on the join query token and the join index related item, and uses the Bloom filter for membership testing to implement the intersection operation of multi-table join attributes, reducing the leakage of subqueries,

[0114] improving the security of the solution.

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

[0116] Step 26, the server performs an exclusive OR operation on the received join query token and the related item in the corresponding JSet to obtain the related value of the join attribute;

[0117] Step 27, the exclusive OR result is used for membership testing in the Bloom filter XSet. If it returns True, the join attribute included in the related value is the common join attribute included in the query table, and this value is retained as the intermediate result of the query. If it returns False, it is a non-common join attribute and this value is not retained. Thus, the private set intersection process of the join attributes is completed.

[0118] 9. As Figure 4 shown by arrow ⑨, the server performs an exclusive OR operation on the inner product operation result and the intermediate result passed the membership test, and uses the filter to perform membership testing on the exclusive OR result value again. This step constitutes the critical path for the present invention to support parallel calculation optimization and significantly improves the efficiency of the join query under parallel execution optimization.

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

[0120] completing the entire search process of the protocol.

[0121] Step 3, the client obtains the records that meet the query requirements from the database relation table according to the row identifier returned by the Search protocol.

[0122] The selection of the query result in the Search protocol, its specific steps include,

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

[0124] Step 32, perform a membership test on the connection tag Bloom filter XSet. If True is returned, the relevant entry is the content of the query result. At this time, the set {ct} of encrypted row identifiers corresponding to TSet of all tables is returned and sent to the client. If False is returned, skip the value. At this point, all operations of the Search protocol are completed.

[0125] The connection index structure JSet designed in this embodiment is combined with a Bloom filter to complete the privacy set intersection operation of the connection attribute. At the same time, by executing the Distinct storage strategy on the connection index items, only the unique representation of each connection attribute value in a single table is retained, which effectively improves the security and computing efficiency of the method during the query process and significantly reduces the storage load on the server side.

[0126] 1. The client performs an XOR operation on the deduplicated connection index and the pseudo-random encrypted value of the current index attribute cascade counter. The counter ensures the randomness of the encryption result and improves the security of the method. Because the server cannot obtain any plaintext information by reading and analyzing the ciphertext data. The deduplicated connection index can reduce the storage pressure of the server and the additional computing overhead caused by repeated calculations.

[0127] 2. In the process of finding the intersection of the privacy sets of the connection attributes, a JSet of a table and a Bloom filter XSet of all tables are specified. The server performs the intersection filtering operation of the connection attributes between multiple tables on the JSet, and subsequent calculations will only be calculated on these common items. This process only involves the deduplication of the connection attribute index information of one query table, which not only reduces the subquery leakage problem faced by traditional connection queries, but also facilitates the subsequent parallel computing optimization, improving the security and computing efficiency of this technology.

[0128] 3. After obtaining the JSet index items related to the common connection attributes, these items will be XORed with the intermediate results of the Boolean calculations of all query tables in parallel, reducing the time overhead caused by the serial calculation of the traditional connection query method and improving the query efficiency of the solution.

[0129] See also Figure 5 The figure shows the security comparison 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 prove the advancement of the present invention, this embodiment is compared with the state-of-the-art symmetric connection method. The first one to use non-precomputed symmetric indexing technology to solve join queries on encrypted databases is "Efficient Searchable Symmetric Encryption for Join Queries" (abbreviated as JXT) proposed by Jutla et al. in ASIACRYPT'22. This protocol uses the inverted index of searchable encryption to establish a join index and designs a oblivious cross-tagging technique to jointly complete the calculation of join queries. However, the security and query efficiency of this query are relatively low, which is not conducive to actual 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" in CCS'24 (the two-table join scheme is abbreviated as JXT+, and the multi-table join scheme is abbreviated as JXT++). This protocol can securely and efficiently support multi-table join schemes through the transformation of the index structure and the introduction of Xor filters. However, currently, the JXT series of schemes can only support fixed types of SQL statements and cannot support the filtering of flexible where boolean conditions, resulting in limited query functions. Wu et al. proposed "Practical Searchable Symmetric Encryption for Arbitrary Boolean Query-Join in Cloud Storage" (abbreviated as TNT-QJ) in TIFS'24. Technically, it integrates the boolean query functions of "Highly-scalable searchable symmetric encryption with support for boolean queries" (abbreviated as OXT) proposed by Cash et al. in CRYPTO'13 and "Two-in-one-sse: Fast, scalable and storage-efficient searchable symmetric encryption for conjunctive and disjunctive boolean queries" (abbreviated as TWIN) proposed by Bag et al. in PETS'22, as well as the JXT join function, achieving the join function under boolean query conditions and using a semi-complete multi-way search tree to reduce storage and query costs. However, this scheme has a relatively high computational complexity, cannot simply support all types of boolean queries, and does not have flexible secure multi-table query capabilities (the problem of subquery leakage between multi-tables). The present invention can effectively enhance the privacy protection ability of the system during the join query process without increasing the computational burden by introducing a padding strategy.Meanwhile, by combining the private set intersection mechanism with connection attributes and the index processing flow supporting parallel computing, the overall query efficiency is significantly improved.

[0131] Figure 5 It shows the comparison of leakage patterns of each scheme in the scenario of two-table join query. Since some existing schemes do not support multi-table join yet, the general query statement for two tables is selected as the unified comparison standard. The solid circle represents full leakage, the hollow circle represents no leakage, the half-filled circle represents partial information leakage, and the horizontal line represents no relevant leakage because the function is not supported. n is the scale of the table, RP is the result pattern, EP1 is the token equality pattern of Table 1, EP2 is the token equality pattern of Table 2, SP1 is the size pattern of the index items in Table 1, SP2 is the size pattern of the index items in Table 2, JD is the distribution pattern of the connection attributes, and IP is the information that the two filtered attributes in multiple query leaks belong to one record. It can be clearly seen from the table that the leakage items of the present invention are the fewest among all the schemes, only leaking the scale of the table and the token equality pattern, with extremely high security. Moreover, when supporting complex queries, the filtering of Boolean conditions will further hide the frequency information leakage on the index, with better fine-grained security.

[0132] Refer to Figure 6 As shown, it is a schematic diagram of the comparison of storage load, computational complexity, and functionality between the present invention and other connection methods. Theoretically, the present invention performs well in terms of storage load and computational complexity. It performs best in functionality and can support the multi-table equijoin method for Boolean queries.

[0133] Since JXT, JXT+, and JXT++ do not involve the filtering function of Boolean attributes, when it comes to complex Boolean condition filtering, one index access of the present invention can complete the query requirements, but these three schemes need to be decomposed into more subqueries, with multiple index accesses and a large amount of repeated calculations, resulting in serious resource waste and time overhead. Therefore, the computational complexity and efficiency of the present invention are more optimal in complex queries. TNT-QJ essentially relies on the connection ability of the JXT scheme 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. Therefore, when executing complex query statements, the present invention is more optimal in terms of computational complexity, efficiency, and functionality.

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

[0135] Although the above-described embodiments have been described, those skilled in the art can make additional changes and modifications once they learn the basic creative concept. Therefore, the above are only embodiments of the present invention, and do not limit the patent protection scope of the present invention. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present invention, or directly or indirectly applied in other related technical fields, are equally included in the patent protection scope of the present invention.

Claims

1. A multi-table join method supporting Boolean queries in an encrypted database, characterized in that: It includes the following steps: Step 1, the client executes the random algorithm - EDBSetup protocol locally. This protocol takes the plaintext database as input, generates an encrypted database, and outsources it to the server. Step 2, the client and the server jointly execute the two-party protocol - Search protocol. This protocol inputs the encrypted database, performs boolean condition filtering and join queries, and outputs the query results. Step 3, the client decrypts the encrypted row identifiers output by the Search protocol to obtain the final query results.

2. The multi-table join method supporting boolean queries in the encrypted database as claimed in claim 1, wherein: The specific steps of Step 1 include: Step 11, after the EDBSetup protocol starts, the client will first perform the parsing of the plaintext database, including the selection of the pseudo-random encryption function and the symmetric encryption algorithm, the random selection of the key set, and the classification of the attribute columns in the plaintext relation table into boolean attributes, join attributes, and index attributes. Step 12, after the EDBSetup protocol completes the parsing of the database, perform the orthogonalization processing of the boolean attributes. The client uses the pseudo-random permutation function to pseudo-randomly permute the boolean attribute set, and cascades the permuted attribute values with the position vectors to obtain an initial set of mutually uncorrelated boolean vectors. Then, perform the Schmidt orthogonalization processing on all the vectors to obtain the final mapping set of the attribute values and their orthogonal vectors. Step 13, the EDBSetup protocol constructs the index. For each index attribute, first process the row identifier set, boolean attribute set, and join attribute set included in each record of each index attribute using the pseudo-random function, and then perform vector addition, multiplication of the vector and the pseudo-random function value, and operations between the pseudo-random function values to obtain the Bloom filters of each index item and the join tag, and upload them to the server. Step 14, the EDBSetup protocol encrypts the data table. The client will encrypt the data table using the random encryption algorithm. Step 15, the EDBSetup protocol uploads the encrypted data table to the server.

3. The multi-table join method supporting boolean queries in the encrypted database as claimed in claim 2, wherein: The EDBSetup protocol in Step 11 includes the method for the client to parse the plaintext database, and its specific steps include: Step 112, after the EDBSetup protocol starts, the client will select a pre-determined secure pseudo-random encryption function F(·) that meets the local data processing requirements and the symmetric encryption technology Enc(·) for encrypting the result set. Step 113, the client randomly selects the key set K to ensure the secure encryption processing of the local data. Step 114, classify the attribute columns in the relation table into three categories: boolean attributes for boolean condition filtering, join attributes involved in join operations, and index attributes for building indexes, to support subsequent classification processing of different attributes. Thus, the parsing of the plaintext database in the initial steps of the protocol is completed.

4. The multi-table join method supporting boolean queries in the encrypted database as claimed in claim 2, wherein: The EDBSetup protocol in step 1 includes orthogonalization of Boolean attributes, and the specific steps include: Step 121, using a pseudo-random permutation function Π(·) to randomly permute the Boolean attribute and the auxiliary query vector set to ensure the privacy of the attribute; Step 122, concatenating the replaced attribute value with the position vector e to obtain an initial unrelated Boolean vector set {f}; 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.

5. The multi-table connection method supporting Boolean query in a secret database according to claim 2, 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 property, first obtain the set {ind} of row identifiers containing the property, and obtain the set W of boolean properties of the record where each row identifier is located bl and concatenate the set W of properties jn ; 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 value 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 item of the row, 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 items and encrypted row identifiers of each row of the index attribute into T, and combine the used T 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 the calculation efficiency. At this point, all query indexes are ready.

6. The multi-table connection method supporting Boolean query in a secret database according to claim 2, 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 random symmetric encryption algorithm to achieve the goal of semantically secure ciphertext protection and build a relational secret database. This technology uses index technology to complete the 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.

7. The multi-table connection 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, and then obtains the calculation tokens for Boolean condition filtering and connection query 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 out after calculation based on the token constructed by the client and the index maintained by the server. The Boolean condition filtering operation is implemented by performing an inner product operation on the Boolean query token and the corresponding entry in TSet. The connection operation is performed by performing an XOR operation on the connection query token and the corresponding index item in JSet to obtain the intersection of the connection attributes of all query tables. Subsequently, the server performs an XOR operation on each element in the set and 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.

8. The multi-table connection method supporting Boolean query in a secret database according to claim 7, characterized in that: The method for generating the token set of the client in step 2 comprises the following specific steps: Step 21, based on the relevant information of the query table and query column in the plaintext SQL statement, according to the token generation algorithm of the encrypted multi-mapping technology, an index search token for searching TSet and JSet related items is generated and sent to the server. The server receives the token and reads the index related items; Step 22: According to the Boolean attribute involved in the Where condition in the plaintext SQL statement, the client obtains the corresponding orthogonal vector from the mapping V, and generates a corresponding large integer using a pseudo-random generator, multiplies an orthogonal vector by an integer, and then calculates the vector sum, which is sent to the server as a Boolean query token. Step 23: According to the index attribute and connection attribute name in the plain text 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, obtains the result test token, and sends this token to the server. At this point, the work of the token generation phase is completed.

9. The multi-table connection method supporting Boolean query in a secret database according to claim 8, 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 calculates the inner product of the received Boolean query token and the query-related items in the TSet index entry 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 the query efficiency. Step 26, the server performs an exclusive OR operation on the received join query token and the related items in the corresponding JSet to obtain a set of candidate join attribute values; Step 27, the server inputs the exclusive OR result into the Bloom filter XSet for membership testing. If the return is True, it means that the join attribute value is the common join attribute of each query table, and this value is retained as the query intermediate result; otherwise, it is discarded.

10. The multi-table join method supporting Boolean queries in the encrypted database according to claim 10, characterized in that: For the selection of the query result in the Search protocol in step 3, the specific steps include, Step 31, perform an exclusive OR operation on the intermediate result of the previous JSet index calculation and the inner product value calculated by TSet to obtain the final tag value. This step can be calculated in parallel between tables, improving the query execution efficiency; Step 32, input the tag value into the Bloom filter XSet for membership testing. If the return is True, the relevant entry is the content of the query result. At this time, return the set {ct} of the encrypted row identifiers corresponding to the TSet of all tables and send this set to the client. If the return is False, skip this value.

Images