Efficient dynamic searchable encryption method supporting equivalent connection query
Through XOR operation and pseudo-random function, encrypted search keywords and dynamic connection tags are generated, combined with hidden connection result set HJS, the inefficiency and security risks of searchable encryption technology in connection query are solved, and efficient and secure dynamic connection query is achieved.
Patent Information
- Application Number
- CN202510532945.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-25
- Publication Date
- 2025-08-01
AI Technical Summary
Existing searchable encryption technologies are inefficient and have security risks when supporting connection queries, especially when dynamic updates and multi-table connections, performance bottlenecks and privacy leakage problems are prominent.
XOR operation and pseudo-random functions are used to generate encrypted search keywords and dynamic connection marks, design hidden connection result set HJS, and use dynamic connection marks xtag and multi-table equivalent connection query methods to ensure forward and backward security and reduce information leakage.
It realizes efficient connection query in an encrypted environment, supports dynamic updates, reduces computing complexity and storage costs, enhances data security, and reduces the risk of information leakage.
Smart Images
Figure CN120408677A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of searchable encryption, and particularly relates to an efficient dynamic searchable encryption method supporting equi-join queries, including dynamic searchable encryption with forward and backward security, as well as dynamic join tags supporting equi-join queries and hiding join result sets. Background Art
[0002] The need for data privacy protection and cloud computing has driven the development of encrypted databases. As a technology that combines data privacy protection and efficient data processing, encrypted databases have developed rapidly in recent years. With the popularization of big data and cloud computing, the storage and processing of massive data have gradually shifted from local to the cloud. Although this shift has greatly reduced costs and improved resource utilization, it has also raised concerns about data privacy leakage. In a cloud environment, the ownership and use rights of data are separated, and cloud service providers can usually directly access the plaintext data stored on their servers, resulting in potential privacy and security risks.
[0003] In this context, encrypted databases have emerged. By applying encryption technology throughout the entire life cycle of data storage and processing, encrypted databases achieve the support for efficient query and analysis of data while protecting data privacy. Its core idea is that after data is encrypted, it can still support complex query operations, such as keyword search, range query, and join query, etc. This ability enables encrypted databases to provide an operation experience close to that of plaintext databases without sacrificing security, thus achieving a balance between security and usability.
[0004] As an important part of encrypted databases, searchable encryption technology has received extensive attention in the academic and industrial fields in recent years. With the explosive growth of data volume and the continuous increase in privacy protection requirements, searchable encryption is regarded as the key technology to solve the problem of efficient query of data in an encrypted state. Although traditional encryption methods can protect data security, they also hinder the flexible operation and efficient utilization of data. These methods usually need to decrypt data first during query operations, resulting in performance bottlenecks and security risks. Even homomorphic encryption technology that supports encrypted computing, although theoretically powerful, is often difficult to meet the needs of large-scale data processing due to huge computational overhead and high operation complexity in practical applications. Searchable encryption technology enables users to complete complex data retrieval operations without decrypting by embedding query capabilities in encrypted data. This feature makes it possible to achieve efficient query while protecting privacy, and thus becomes an important supporting technology for the development of data privacy protection and cloud computing.
[0005] However, the expressiveness of query statements is a necessary ability for searchable encryption schemes to meet various retrieval requirements and improve the practical application and deployment of the schemes. In this field, researchers have developed various searchable encryption schemes that support keyword search, range query, Boolean operation, and join query. Among them, join query, as one of the core functions in database operations, is particularly complex to implement. This kind of query requires establishing associations between different tables to match specific conditions and return the qualified results. Since join query involves cross-table data association, this operation requires complex processing of data in the encrypted environment while avoiding leakage of sensitive information. However, the existing searchable encryption technologies still face many challenges when supporting join query. First, how to efficiently execute the join operation while ensuring the security of encrypted data is a technical difficulty. This involves complex index design, data structure optimization, and performance trade-off of encryption algorithms. Second, the join query operation itself is prone to security risks, such as leakage of query patterns, exposure of access patterns, and inference attacks on statistical characteristics of encrypted data, etc., which may all lead to indirect leakage of sensitive information.
[0006] As an important function in database operations, join query not only plays a crucial role in traditional databases but also has the same important status in the context of searchable encryption. It enables users to extract valuable information from scattered data through cross-table and cross-column association operations and is the core function of many complex applications. In fields such as data analysis, financial services, and medical information, join query is often the key means to achieve in-depth insights and efficient decision-making. However, when join query is introduced into encrypted databases, the complexity of its implementation increases significantly, involving both technical difficulties in function support and risks in privacy and security.
[0007] The complexity of join query is first reflected in the fact that existing searchable encryption schemes are difficult to effectively support dynamic updates. In practical applications, databases need to frequently insert, delete, or update data, and dynamic updates in the encrypted environment bring significant performance overhead and security risks. Dynamic updates not only require synchronous updates of the encrypted index structure but also ensure data security during the update process. However, many existing schemes do not fully consider the dynamic update requirements during design, which makes them inefficient in processing join queries and may even lead to security vulnerabilities. In addition, most searchable encryption technologies are mainly applied to record-based databases, and the problem becomes more complex when dealing with relational databases. In relational databases, join queries often involve joint operations of multiple tables and multiple columns, which pose higher requirements for index design, encryption structure, and query algorithms. For example, how to establish encrypted association relationships between multiple tables and how to perform efficient encrypted queries within multiple column ranges have not been fully solved yet.
[0008] Meanwhile, the implementation of join queries also faces the risk of information leakage. In traditional encrypted databases, query patterns and access patterns may expose sensitive information, such as the association relationships between tables or the distribution characteristics between columns. When performing join queries, this risk is further amplified because join queries usually need to span a larger data range, which may enable attackers to infer the private content of the data by analyzing the query results. In addition, when existing encryption schemes handle multi-table joins, they often need to introduce additional auxiliary information or leak some data characteristics to improve query efficiency, which undoubtedly increases the possibility of indirect inference of data. Summary of the Invention
[0009] The present invention contemplates an efficient dynamic searchable encryption method with forward and backward security that supports equi-join queries, focusing on solving how to achieve efficient join queries in an encrypted environment and ensure its privacy protection. While ensuring the join efficiency, the data security is further enhanced. This scheme can not only support two-table joins, but also be extended to multi-table joins, and has a relatively low computational complexity and storage cost. By designing a dynamic searchable encryption method, this scheme supports secure join queries. In addition, the present invention will further explore the issue of forward and backward security. Forward security means that in encrypted queries, future leakage attacks can be effectively prevented; while backward security involves the query security after data updates, ensuring that data updates do not lead to the leakage of historical query data. By designing an efficient dynamic join scheme, it is expected to solve the security vulnerabilities and performance bottlenecks in existing encrypted query methods, thereby realizing a more efficient and secure encrypted data query mechanism.
[0010] The present invention provides an efficient dynamic searchable encryption method that supports equi-join queries to solve the problems that existing searchable encryption methods supporting joins do not support dynamic updates and the join results are leaked.
[0011] To achieve the above object, the present invention adopts the following technical solutions:
[0012] An efficient dynamic searchable encryption method that supports equi-join queries includes the following steps
[0013] Step 1, when the client processes insert and delete operations, it uses flag bits to distinguish different types of data updates. Subsequently, for the updated data, the client generates encrypted search keywords and dynamic join tags (for supporting equi-join queries) through exclusive-or operations and pseudo-random functions, and sends them to the server, storing them in the hidden join result set. The whole process ensures forward security and backward security;
[0014] Step 2, the client parses the search statement, calculates the encrypted token and sends it to the server for searching;
[0015] Step 3, the server responds to the search request, calculates the dynamic connection tag through XOR operation, checks whether it is stored, and returns the corresponding data to the client.
[0016] For further optimization of this technical solution, the method for encrypting the search keyword using XOR and pseudo-random calculation in step 1 is as follows:
[0017] Step 11, setup phase, the server constructs a key-value dictionary, called TSet.
[0018] Step 12, update phase, for each keyword w, the update count and the connection column attribute name, corresponding to each operation involving keyword w, use a pseudo-random function to generate the keyword encryption value addr, and store it in the server's key-value dictionary TSet.
[0019] The client also calculates the dynamic connection factor corresponding to each update operation, and also uses XOR operation and pseudo-random function to encrypt the dynamic connection factor with the update count and the connection column attribute value involving keyword w, and stores it in the server's key-value dictionary TSet.
[0020] For further optimization of this technical solution, in the method of calculating the encrypted search keyword using XOR operation and pseudo-random function, during the update process, the server only sees a key-value dictionary TSet (address, value) pair and a connection tag, all of which are generated using a pseudo-random function and only appear once under the assumption of never repeating record identifiers, meaning the update is forward secure. The specific steps include that the connection tag is generated during each update operation instead of in the initial setup phase; by including the operation op ∈ {add, del} and the update count in the generation of the connection tag, its semantics are extended to represent whether a certain operation involves a certain keyword-connection attribute value pair.
[0021] For further optimization of this technical solution, the hidden connection result set where the dynamic connection tag calculated in step 1 is sent to the server for storage, the specific steps include:
[0022] Step 14, setup phase, the system generates a key, which contains two different parts, and uses these two keys to protect the data during subsequent encryption and query processes.
[0023] Step 15, Encryption Phase: Perform encryption processing on the set of encrypted row identifiers for the given dynamic connection tags. For each dynamic connection tag, a position is calculated for storage in the encrypted structure. After encrypting the dynamic connection tag and its corresponding row identifier, insert them into the encrypted structure. The encrypted structure consists of multiple sets, each containing multiple encrypted pairs. After processing, these sets have the same size, and each position is filled with encrypted data to ensure the consistency of the encrypted structure and its non-identifiability from the outside.
[0024] Step 16, During Search: The server uses the encryption key to generate a token for each queried dynamic connection tag. This token is used to confirm whether the dynamic connection tag exists in the encrypted data during the query process, ensuring the security of the query. The generation and verification of the token do not expose the content of specific elements.
[0025] Step 17, The server queries whether the corresponding dynamic connection tag exists in the encrypted structure. The server uses the token for the query and returns a response, which represents the query result but the content is encrypted and cannot be directly viewed.
[0026] Step 18, After receiving the query response, the client uses the token to verify the matching of each dynamic connection tag. The client can confirm which dynamic connection tags meet the query conditions and returns the encrypted result of the row identifier. However, the actual data is not leaked throughout the process, ensuring security.
[0027] For further optimization of this technical solution, in the method of checking whether the dynamic connection tag is stored in Step 3, the server can check the membership of each dynamic connection tag in the set HJS and let the client know the corresponding result. The specific steps include:
[0028] Step 31, After parsing the sql statement, select the keyword with the fewest update operations among the keywords as w1. In a real database, keywords that appear in fewer documents usually also involve fewer update operations, especially in systems where a single update operation involves adding / deleting the entire record.
[0029] Step 32, The client calculates the token stoken of the keyword w1 and the connection attribute value and sends it to the server.
[0030] Step 33, The client additionally generates a connection token (xtoken) and sends it to the server.
[0031] Step 34, The server can calculate each other keyword w i , where w i ∈{w2,...,w nFor the dynamic connection tag (xtag) of {}}, the server can check the entire set of each dynamic connection tag at a centralized location and return it to the client;
[0032] Step 35, after the client receives the response, it starts the verification process to determine whether the returned set contains the dynamic connection tag xtag;
[0033] Step 36, the client can calculate the final list of row identifiers that pass the verification.
[0034] For step 1, the present invention designs a dynamic connection tag for equijoin. In traditional searchable encryption connection schemes, connection tags are widely used to identify the relationship between specific document-keyword pairs. Especially in static datasets, these tags can effectively represent the existence relationship between documents and keywords. However, for encryption connection query schemes that support dynamic data updates, traditional connection tags need to be further improved to adapt to the dynamic nature of the data, especially data insertion and deletion operations.
[0035] To solve this problem, a connection tag (xtag) that supports dynamic updates is proposed. This tag can not only represent the relationship between query keywords and connection keywords but also adapt to the update operations of dynamic data. That is, when entries in the dataset are inserted or deleted, the corresponding tags can be updated in a timely manner to ensure the accuracy and security during search. By introducing connection tags, the complexity in query operations can be decomposed into relatively simple elements, thus reducing the computational amount when performing join queries.
[0036] Specifically, the design of the dynamic connection tag xtag includes two key parts: First, each dynamic connection tag xtag is generated by using a pseudorandom function (PRF) in combination with a keyword (w), the keyword update count (C[w]), and the connection attribute name (attr*) and join keyword (w*). Second, the dynamic connection tag xtag can not only identify the basic relationship between query keywords and connection keywords but also identify the insertion or deletion operations of entries. For example, the dynamic connection tag xtag can be divided into two types: insertion tags and deletion tags, which are used to indicate whether an entry has been inserted or deleted. Whenever there is data update, the system generates a new value of the dynamic connection tag xtag to ensure that the updated data still meets the requirements of privacy protection and can support subsequent queries.
[0037] The key advantage of this design is that it can ensure that when performing join queries in a dynamic environment, the system can determine whether a record meets the query conditions based on the latest dynamic connection tag xtag information, and at the same time, it will not disclose any unnecessary sensitive information. This solution not only enhances the flexibility of the query but also ensures strong privacy protection during the data update process.
[0038] For Step 2, the present invention designs an efficient multi-table equi-join query method. Specifically, the client first calculates the token stoken of the primary key w1 and the join attribute name and sends it to the server. In addition, the client additionally generates a join token (xtoken), where xtoken is about the primary key w1 and other keys w2,..., w n and the corresponding join attribute names and sends it to the server. The server obtains the records that match the key w1 from TSet in the main table Tab1, and then checks whether the combination is included in the Hidden Join Set (HJS), where the join attribute values come from Tab1, and the attribute value pairs (w2,..., w n ) and the attribute names come from the remaining k - 1 tables. The client obtains the final result by checking the record identifiers retrieved from all k tables. In addition, the efficient multi-table equi-join query method can mitigate the subquery leakage problem caused by multi-table joins and perform excellently in terms of query and storage efficiency.
[0039] For Step 3, the present invention designs the Hidden Join Set HJS method. Although traditional encrypted query algorithms have certain advantages in query efficiency, they are prone to leaking sensitive query information, such as query patterns, size patterns, and distribution patterns of join attributes. Therefore, targeted optimizations are proposed for these potential security threats, and the Hidden Join Set HJS is designed to effectively enhance the security of encrypted join queries.
[0040] HJS aims to enhance security by hiding the pattern of query results. Its main task is to ensure that the server cannot know which data matches the query conditions during the encrypted query, thus avoiding the risk of information leakage. By concealing the result pattern during the query process, HJS not only reduces the possibility of information leakage but also provides a significant efficiency improvement in terms of calculation and storage.
[0041] Specifically, HJS improves query security in the following aspects:
[0042] Protecting the result pattern: In traditional encrypted queries, the pattern of query results (i.e., which records meet the query conditions) may be leaked to the server, providing clues that can be exploited by potential attackers. HJS ensures that the server cannot directly observe the specific pattern of query results through encryption, and can only obtain the identifiers of the query results without being able to further infer the query content.
[0043] Hidden size mode: The size mode reveals the size of the query result, that is, how many records the query returns. With HJS, the size information during the query process is concealed, preventing attackers from inferring data content by comparing the size modes of different queries.
[0044] Protect connection attribute distribution mode: For join queries, especially in multi-table join operations, the distribution mode of query attributes may disclose sensitive information, such as whether certain attributes often appear. This leakage risk is effectively controlled by HJS, avoiding the disclosure of the connection attribute distribution mode.
[0045] The core design of HJS is to encrypt and represent the query data and perform pseudorandomization processing, hiding the query results in multiple randomly generated tokens. In this way, even if an attacker attempts to analyze the query process, they cannot accurately obtain any useful information. An important advantage of HJS is that it can effectively avoid the high false positive rate generated by traditional Bloom Filter when hiding query results, ensuring the accuracy of the query.
[0046] Compared with other methods, the main advantage of HJS is its low storage overhead and nearly constant computational overhead. This makes HJS an essential security enhancement tool in dynamic encrypted queries. Especially when dealing with large-scale databases, its storage and computational efficiency have been greatly optimized.
[0047] By introducing HJS, the encrypted join query scheme not only improves security, reduces the risk of leakage, but also significantly optimizes performance. Specifically, HJS reduces the storage cost and improves the query response speed by eliminating unnecessary leakage information, making the entire encrypted query system more efficient and practical.
[0048] Different from the prior art, the above technical solution has the following beneficial effects:
[0049] 1. Solve the problem that the equality join scheme based on searchable encryption cannot support dynamic updates;
[0050] 2. Solve the problem of connection result leakage in the dynamic join scheme;
[0051] 3. Improve the storage of the dynamic join scheme;
[0052] 4. Improve the limitation of extending the searchable encryption method supporting joins to multiple clients. Description of the Drawings
[0053] Figure 1 It is a storage schematic diagram of the client and the server;
[0054] Figure 2It is a flowchart for data insertion / delete / update;
[0055] Figure 3 It is a schematic diagram of hiding the joined result set HJS;
[0056] Figure 4 It is a search flowchart;
[0057] Figure 5 It is a schematic diagram showing the security comparison between the present invention and other searchable encryption schemes that support joins. Detailed implementation manners
[0058] 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 reference to specific embodiments and in conjunction with the accompanying drawings.
[0059] In this specific embodiment, the client is responsible for generating encrypted tokens to execute update and search requests, as well as verifying and decrypting the results; the server is responsible for encrypted storage and encrypted search matching, and returns the encrypted results to the client.
[0060] Refer to Figure 1 As shown, it is a storage schematic diagram of the client and the server. An efficient dynamic searchable encryption method that supports equality join queries includes the following steps.
[0061] Step 1: The client generates a key and initializes the local state. The client randomly selects a key for subsequent pseudo-random function operations. At the same time, the client initializes a local structure for recording the update times of each query keyword to support the generation of dynamic join tags and the correctness of query tokens.
[0062] Step 2: Establish an encryption structure and upload updated data. For insert or delete update operations, the client sets a flag to distinguish the data type. Subsequently, using the pseudo-random function and XOR operation, the corresponding encrypted search keyword and dynamic join tag are calculated. The generated ciphertext pairs are sent to the server and stored in the encrypted dictionary (TSet) and the hidden join result set (HJS) respectively to achieve forward and backward security.
[0063] Step 3: The client generates a query token and initiates a query. The client parses the search statement according to the user query request, and calculates and generates an encrypted query token in combination with the keyword update times, including the stoken of the main keyword and the xtoken of the join tag, and sends the token to the server.
[0064] Step 4: The server performs matching and returns the result. The server receives the query token, calculates the dynamic join tag through the XOR operation and the pseudo-random function, and checks whether there is a matching item in the hidden join result set. If there is, an encrypted query result is generated and returned to the client.
[0065] Step 5: The client verifies and decrypts the query result. The client completes the matching verification with the local token according to the received result and decrypts the encrypted result to obtain the final query result, ensuring the correctness and privacy of the query.
[0066] Step 1, when the client processes insert and delete operations, it uses a flag bit to distinguish different types of data updates. Subsequently, for the updated data, the client generates an encrypted search keyword and a dynamic connection marker (for supporting equality join queries) through exclusive-or operation and a pseudo-random function, and sends them to the server for storage in the hidden connection result set. The whole process ensures forward security and backward security.
[0067] The method for encrypting the search keyword using exclusive-or and pseudo-random calculations is as follows:
[0068] Step 11, Setup phase, the server constructs a key-value dictionary, called TSet;
[0069] Step 12, Update phase, for each keyword w, the update count and the connection column attribute name, corresponding to each operation involving keyword w, use a pseudo-random function to generate the keyword encryption value addr and store it in the server's TSet dictionary.
[0070] Step 13, the client also calculates the dynamic connection factor corresponding to each update operation. Similarly, use exclusive-or operation and a pseudo-random function to encrypt the update count and the connection column attribute value involving keyword w for the dynamic connection factor and store it in the server's TSet dictionary.
[0071] The method for calculating the encrypted search keyword using exclusive-or operation and a pseudo-random function. During the update process, the server only sees a TSet (address, value) pair and a connection marker, all of which are generated using a pseudo-random function and only appear once under the assumption of never repeating record identifiers, meaning the update is forward secure. Its specific steps include that the connection marker is generated at each update operation, rather than in the initial setup phase. By including the operation op ∈ {add, del} and the update count in the generation of the connection marker, its semantics is extended to represent whether a certain operation (either addition or deletion) involves a certain keyword-connection attribute value pair. This is achieved while maintaining forward privacy (because the dynamic connection marker does not reveal any information about the underlying operation, row identifier, or keyword), which is crucial for resisting information leakage abuse attacks and record injection attacks.
[0072] Calculating the dynamic connection marker and sending it to the hidden connection result set in the server for storage, its specific steps include,
[0073] Step 14, Setup Phase: The system generates a key set, which is responsible for encrypting all plaintext combinations and locating dynamic connection tags respectively. These two keys are used to protect data during subsequent encryption and query processes;
[0074] Step 15, Encryption Phase: Perform encryption processing on the set of encrypted row identifiers for the given dynamic connection tags. Each dynamic connection tag calculates a position for storage in the encrypted structure. After encrypting the dynamic connection tag encrypted row identifiers, insert them into the encrypted structure. The encrypted structure includes multiple sets, and these sets contain multiple encrypted pairs. After processing, these sets are of the same size, and each position is filled with encrypted data to ensure the consistency of the encrypted structure and its non-identifiability externally;
[0075] Step 16, Search: The server generates a token for each queried dynamic connection tag using the encryption key. The token is used to confirm whether the dynamic connection tag is in the encrypted data during the query. This process ensures the security of the query, and the generation and verification of the token do not expose the content of specific elements;
[0076] Step 17, The server queries whether the corresponding dynamic connection tag exists in the encrypted structure. The server uses the token for the query and returns a response. This response represents the query result, but the content is encrypted and cannot be viewed directly;
[0077] Step 18, After receiving the query response, the client uses the token to verify the matching of each dynamic connection tag. The client can confirm which dynamic connection tags meet the query conditions and returns the encrypted result of the row identifier, but the actual data is not leaked during the whole process to ensure security.
[0078] Refer to Figure 2 As shown in the figure, it is the flowchart of data insertion / delete update. The method of data update (insertion / delete) specifically includes the following steps:
[0079] 1. As Figure 2 shown by arrows ①②③④, first calculate the keyword encrypted value of the updated entry Connect the calculation factor Dynamic connection tag Row identifier encrypted value
[0080] It should be noted that the dynamic connection tag xtag not only identifies the basic relationship between the query keyword and the connection keyword, but also can identify the insert or delete operation of the entry, indicating whether the entry has been inserted or deleted. Whenever there is data update, the system generates a new dynamic connection tag xtag value to ensure that the updated data still meets the requirements of privacy protection and can support subsequent queries.
[0081] 2. As Figure 2 shown by arrow ⑤, after the calculation is completed, the encrypted value is sent to the server.
[0082] 3. As Figure 2 shown by arrow ⑥, the encrypted database EDB is updated.
[0083] The connection query method provided by this example provides forward security and backward security guarantees for connection queries in a dynamic database, ensuring that the user's privacy is not leaked when performing connection keyword searches in the dynamic database. Forward security ensures that database update operations (such as adding or deleting records) do not allow the server to associate with any previously executed search operations, that is, the update operation itself does not disclose the search content related to it. Our invention, JoinDynamicCross Tags (JDXT), achieves this by hiding the details of the update operation. Specifically, during an update, the record identifier, keyword, and connection value are all encrypted through a pseudorandom function (PRF), and the server cannot know which records or keywords the update involves. The encryption and randomness of the update operation ensure that even operations such as adding or deleting records do not expose information about any previously executed search operations, preventing attackers from inferring the query history through updates. The core of forward security lies in the fact that the update operation itself is "leak-free", that is, the server cannot infer the distribution of keywords or whether a specific record has been queried from the update.
[0084] Backward security ensures that when performing a keyword search, the server cannot know any information about the deleted records. Specifically, even if a record has been deleted from the database, the server will not obtain the existence of these records or the keywords they once contained during the search. JDXT achieves this through connection calculation factors and dynamic connection tags. Each time an update occurs, a connection calculation factor is generated, indicating whether the operation is an insertion or a deletion. The connection calculation factor is generated based on the keyword, connection value, and update operation, and is encrypted through a pseudorandom function (PRF), which ensures that the server cannot infer the specific information of the deleted records based on these connection calculation factors. At the same time, JDXT uses dynamic connection tags, which are dynamically generated each time an update occurs, indicating whether each keyword record in Table 1 can be successfully connected to other tables. Since the generation of the connection tag involves the operation type (such as insertion or deletion), the server cannot know whether a record has been deleted through the tag. The design of the dynamic connection calculation factor ensures backward security, and even if a record is deleted, the search operation cannot reveal the content of these records.
[0085] The core technology of JDXT is to combine dynamic connection calculation factors with connection tags, so that each update operation generates a unique encrypted tag, and these tags can be safely used during each query. The server can only see the encrypted tags and pseudo-randomly generated identifiers, and cannot infer the actual content of the records or the deletion history from them. In this way, JDXT achieves the combination of forward security and backward security, ensuring that the user's privacy will not be leaked when performing join queries in a dynamic database. The design of the dynamic connection calculation factor not only supports efficient query operations, but also avoids leaking any information about deleted records during each update, ensuring backward privacy.
[0086] In summary, the JDXT scheme solves the problems of forward and backward privacy protection in the dynamic SSE scheme by combining the technologies of dynamic connection calculation factors and connection tags, while reducing the amount of leaked information, and ensuring the performance of queries and updates through an efficient design. This enables JDXT to provide strong privacy protection while also operating efficiently in practical applications.
[0087] Refer to Figure 3 As shown, it is a schematic diagram of the Hidden Join Result Set (HJS). The method of the Hidden Join Result Set specifically includes the following steps: It is an array of sets with three attributes:
[0088] 1. Using each xtag / val pair as input, the prf function and the hash function are used to locate a position (pos) in the encrypted structure HJS. In HJS, each position contains a set, and the padding strategy is used to make the sizes of all these sets the same, all consisting of seemingly random strings.
[0089] 2. Given an element's dynamic connection tag xtag as input, whether it exists in the set or not, the algorithm uses the prf function and the hash function to output the corresponding position pos in the encrypted structure HJS. When the server executes a query, it is ensured that the adversary can only observe that the set HJS[pos] is accessed, where the position pos represents the position in HJS corresponding to the dynamic connection tag xtag, and HJS[pos] is returned to the client.
[0090] 3. The client then obtains the query result val by locally checking whether HJS[pos] records the dynamic connection tag xtag and decrypts it.
[0091] In step 2, the client parses the search statement, calculates the encrypted token, and sends it to the server for searching.
[0092] Step 21: The client parses the SQL query statement to be executed and extracts the set of query keywords from it;
[0093] Step 22: The client selects the keyword w with the fewest update operations from the query keywords, denoted as w1. Since in an actual database, keywords with lower frequencies usually also involve fewer update operations. Especially in a system where a single update operation can simultaneously involve the addition / deletion of an entire record, this strategy helps optimize query efficiency;
[0094] Step 23: The client calculates the query token stoken based on the keyword w1 and its connection attribute values, and sends it to the server;
[0095] Step 24: The client further generates the connection token xtoken corresponding to the connection attribute values and also sends it to the server.
[0096] Step 3, the server responds to the search request, calculates the dynamic connection flag through XOR operation, checks whether it is stored, and returns the corresponding data to the client.
[0097] For the method of checking whether the dynamic connection flag is stored, the server can check the membership of each dynamic connection flag in the HJS and let the client know the corresponding result. The specific steps include,
[0098] Step 31, the server matches the records related to the keyword w1 in the storage structure according to the received stoken;
[0099] Step 32, the server can calculate the dynamic connection flags (xtag) for other keywords w i (where w i ∈{w2,...,w n}) involved in the query.
[0100] Step 33, the server can check the entire set of positions of each dynamic connection flag in the HJS and return it to the client.
[0101] Step 34, after receiving the response, the client starts the verification process to determine whether the returned set contains the dynamic connection flag xtag;
[0102] Step 35, the client can calculate the final list of row identifiers that pass the verification.
[0103] Refer to Figure 4 As shown, it is the search flow chart. The method of data search, the specific steps include:
[0104] 1. As Figure 4 shown by arrows ①②③, first parse the filtering conditions in the sql statement. According to the keyword update times table stored on the client, select the keyword with the fewest update times as w1, and calculate the query of w1 In addition, calculate the connection
[0105] and send it to the server.
[0106] 2. As Figure 4 shown by arrow ④, the server retrieves α that meets the conditions in the TSet structure.
[0107] 3. As Figure 4 shown by arrow ⑤, the server generates xtokenList i .size tokens for each retrieved value α (i.e.,
[0108] where i ∈ [1, C[w1]], j ∈ [1, k]), and these tokens are used for positioning in HJS.
[0109] 4. As Figure 4 shown by arrow ⑥, use the prf and hash functions to output the corresponding position pos in the encrypted structure HJS, and HJS[pos] is returned to the client.
[0110] 5. As Figure 4 shown by arrow ⑦, the client then obtains the query result val by locally checking whether result records the dynamic connection tag xtag and decrypts it.
[0111] Refer to Figure 5 shown, which is a schematic diagram of the security comparison between the present invention and other searchable encryption schemes that support connections.
[0112] To prove the advancement of the present invention, this embodiment is compared with the state-of-the-art join query scheme. A detailed leakage comparison of four schemes is provided. The earliest searchable encryption-based join query scheme was "Efficient Searchable Symmetric Encryption for Join Queries" (abbreviated as JXT) proposed by Jutla et al. in ASIACRYPT 2022. A pure symmetric key solution was proposed, supporting efficient equi-join queries on encrypted tables without any precomputation. Based on this scheme, the state-of-the-art searchable encryption-based join query scheme is "Scalable Equi-Join Queries over Encrypted Database" (abbreviated as JXT+ and JXT++) proposed by Du et al. in ACM CCS 2024. An equi-join query protocol named JXT+ was proposed, which allows join attributes to use arbitrary names, rather than requiring the same join attribute names as in JXT. In addition, JXT++ was proposed, which is the first to support equi-join queries in an encrypted database with three or more tables without precomputation, and at the same time reduces the leakage of subqueries in three or more tables and hides the leakage of matching records from the join of two tables.
[0113] Theoretically, the present invention JDXT performs best in terms of security. In the join queries of two tables and multiple tables, in addition to maintaining the security aligned with the latest scheme JXT++, it also protects the forward security and backward security of dynamic searchable encryption. In addition, the leakage of the join attribute distribution pattern JD is further reduced, and the JRP is protected in terms of the join result pattern.
[0114] 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 such actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or terminal device comprising a series of elements includes not only those elements but also other elements not expressly listed, or 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 existence of additional elements in the process, method, article or terminal device comprising the said elements. In addition, in this article, "greater than", "less than", "exceeding" etc. are understood not to include the present number; "above", "below", "within" etc. are understood to include the present number.
[0115] 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 the embodiments of the present invention, and do not limit the patent protection scope of the present invention. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present invention, or directly or indirectly applied in other related technical fields, is similarly included in the patent protection scope of the present invention.
Claims
1. An efficient dynamic searchable encryption method supporting equi-join queries, characterized in that: It includes the following steps: Step 1, when the client processes insertion and deletion operations, it uses flag bits to distinguish different types of data updates. Subsequently, for the updated data, the client generates encrypted search keywords and dynamic connection tags through exclusive-or operations and pseudo-random functions, and sends them to the server, which are stored in the hidden connection result set. The whole process ensures forward security and backward security. Step 2, the client parses the search statement, calculates the encrypted search token and sends it to the server for searching. Step 3, the server responds to the search request, calculates the dynamic connection tag through exclusive-or operations, checks whether it is stored, and returns the corresponding data to the client.
2. The efficient dynamic searchable encryption method for supporting equijoin queries as described in claim 1, wherein: The method of using exclusive-or and pseudo-random calculations to encrypt search keywords in step 1: Step 11, in the setup phase, the server constructs a key-value dictionary, called TSet. Step 12, in the update phase, for each keyword w, the update count and the join column attribute name, corresponding to each operation involving keyword w, use a pseudo-random function to generate the keyword encrypted value addr, which is stored in the server's key-value dictionary TSet. Step 13, the client also calculates the dynamic connection factor corresponding to each update operation, and also uses exclusive-or operations and pseudo-random functions to encrypt the update count and the join column attribute value involving keyword w for the dynamic connection factor, which is stored in the server's key-value dictionary TSet.
3. The efficient dynamic searchable encryption method for supporting equivalent join queries as claimed in claim 2, wherein: The method of using exclusive-or operations and pseudo-random functions to calculate encrypted search keywords. During the update process, the server only sees a key-value dictionary TSet (address, value) pair and a connection tag, all of which are generated using pseudo-random functions and only appear once under the assumption of never repeating record identifiers, meaning the update is forward secure. Its specific steps include that the connection tag is generated during each update operation, rather than in the initial setup phase; by including the operation op ∈ {add, del} and the update count in the generation of the connection tag, its semantics is extended to represent whether a certain operation involves a certain keyword-join attribute value pair.
4. The efficient dynamic searchable encryption method for supporting equijoin queries as described in claim 1, wherein: When calculating the dynamic connection tag in step 1 and sending it to the hidden connection result set of the server for storage, its specific steps include: Step 14, in the setup phase, the system generates a key, which contains two different parts, and uses these two keys to protect the data in the subsequent encryption and query processes. Step 15, Encryption Phase: Perform encryption processing on the set of encrypted row identifiers for the given dynamic connection tags. For each dynamic connection tag, a position is calculated for storage in the encrypted structure. After encrypting the dynamic connection tag - encrypted row identifier pair, insert it into the encrypted structure. The encrypted structure includes multiple sets, which contain multiple encrypted pairs. After processing, these sets have the same size, and each position is filled with encrypted data, ensuring the consistency of the encrypted structure and its non - recognizability from the outside. Step 16, During Search: The server uses the encryption key to generate a token for each queried dynamic connection tag. The token is used to confirm whether the dynamic connection tag exists in the encrypted data during the query. This process ensures the security of the query, and the generation and verification of the token do not expose the content of specific elements. Step 17, The server queries whether the corresponding dynamic connection tag exists in the encrypted structure. The server uses the token for the query and returns a response. This response represents the query result, but the content is encrypted and cannot be directly viewed. Step 18, After receiving the query response, the client uses the token to verify the matching situation of each dynamic connection tag. The client can confirm which dynamic connection tags meet the query conditions and returns the encrypted result of the row identifier. However, the actual data is not leaked throughout the process, ensuring security.
5. The efficient dynamic searchable encryption method for supporting equi - join queries as claimed in claim 1, wherein: In the method for checking whether the dynamic connection tag is stored in step 3, the server can check the membership of each dynamic connection tag in the set HJS and let the client know the corresponding result. The specific steps include: Step 31, after parsing the sql statement, select the keyword w with the least number of update operations in the keywords as w1. In a real - world database, keywords that appear in fewer documents usually also involve fewer update operations, especially in systems where one update operation involves the addition / deletion of the entire record. Step 32, The client calculates the token stoken of the keyword w1 and the connection attribute value and sends it to the server. Step 33, The client additionally generates a connection token (xtoken) and sends it to the server. Step 34, the server can calculate each other keyword w i , where w i ∈ {w2,..., w n}), for the dynamic connection tag (xtag), the server can check the entire set of each dynamic connection tag at the centralized location and return it to the client; Step 35, After receiving the response, the client starts the verification process to determine whether the returned set contains the dynamic connection tag xtag. Step 36, The client can calculate the final list of row identifiers that pass the verification.