Secure and efficient joint range query method for a ciphertext database

Abstract

The application discloses a kind of secure and efficient joint range query methods for encrypted database, solve the problem of long time consumption, improve the joint range query efficiency of encrypted database.The method includes data owner generates system parameters, including finite field, hash function, pseudo-random function and three-party secret sharing parameters;For the table in database, construct JQR and XQR index, use hash function and shared key, encrypt it into encrypted index by three-party secret sharing, distribute to three cloud servers;Query user generates query token according to request, and sends to cloud server.Cloud server uses the token and key held, based on three-party sharing parameter collaborative calculation and secret welding protocol, executes joint query to encrypted index;Cloud server rearranges the position of encrypted index by secret sharing based on casual permutation, and collaboratively generates new shared key to update index.

Description

Technical Field

[0001] This invention relates to the field of data security and privacy protection technology, and in particular to a secure and efficient joint range query method for encrypted databases. Background Technology

[0002] In recent years, the rapid development of the Internet, the Internet of Things, and information technology has led to a continuous expansion of the scale of data generated across all sectors of society. From personal information to enterprise operational information, data types are becoming increasingly diverse, and the quantity and complexity are exploding. Traditional local data storage and processing models are no longer sufficient to meet such massive data demands. Faced with this challenge, hosting data in the cloud has gradually become the mainstream choice. By outsourcing data to cloud service providers, data owners can leverage the flexible computing power and scalable storage resources of cloud platforms to complete data management and analysis tasks. Simultaneously, with increasing awareness of data security and privacy protection, users often do not directly upload plaintext data to the cloud, but instead choose to encrypt the data locally before outsourcing. In this case, cloud servers must provide users with various data query and processing functions without access to the plaintext content. Therefore, how to achieve efficient data retrieval and computation under encrypted conditions has become an important research direction in the fields of encrypted databases and privacy protection.

[0003] As a widely used database type, relational databases possess a vast amount of SQL language. JOIN, which joins records from two tables based on one or more columns, is one of the most important SQL operations. Searchable Encryption (SSE) is one research direction for implementing JOIN equi-join queries. Researchers at the University of California first defined Searchable Encryption in their paper "Practical Techniques for Searches on Encrypted Data." Subsequently, in the paper "Executing SQL over Encrypted Data in the Database-service-provider Model," they first executed SQL queries on an encrypted relational database. This method divides each attribute domain into multiple data buckets, returning only the bucket corresponding to the queried data, but it leaks the range information of the queried data. Researchers at MIT, in their paper "CryptDB: Protecting Confidentiality with Encrypted Query Processing," implemented the first SQL-aware encrypted database system using Attribute Preservation Encryption (PPE) technology; however, PPE technology is vulnerable to leak and abuse attacks.

[0004] To reduce join query leakage, researchers at Brown University proposed SPX, a structured encryption scheme supporting join queries, in their paper "SQL on Structurally-Encrypted Databases." This scheme pre-computes all possible joins and stores the results in encrypted form in the database. While it offers optimal search complexity, its storage overhead is significant in some cases, especially when join properties are low-entropy. Subsequently, researchers at the University of Chicago proposed a variant of SPX in their paper "Improved Structured Encryption for SQL Databases via Hybrid Indexing." By introducing partially pre-computed joins, this variant achieves less leakage and communication with a moderate increase in client-side computation.

[0005] Researchers at IBM Research proposed the JXT query protocol in their paper "Efficient Searchable Symmetric Encryption for Join Queries," a Symmetric Encryption (SSE) scheme built on OXT (Oblivious Cross-Tags) to support equi-join queries on encrypted databases. During the construction phase, the protocol generates two new data structures, TSet and XSet, for each table. TSet is an inverted index of attribute / value pairs used for single-keyword retrieval within a single table; XSet contains all combinations of record identifier / join attribute value pairs, used to verify whether a pair of records satisfies the join condition in join queries. The basic idea of ​​the query phase is as follows: First, the system retrieves all record identifiers matching the query keyword from both tables; then, the server pairs these identifiers with their corresponding join attribute values ​​and checks if each combination exists in the XSet. Although JXT can implement two-table join queries without pre-computation, it requires both tables to have JOIN-compatible attributes with the same attribute name (i.e., natural joins). Furthermore, JXT cannot be easily extended to three or more tables.

[0006] Building upon JXT, scholars from Xi'an University of Electronic Science and Technology proposed the JXT+ query protocol in their paper "Scalable Equi-JoinQueries over Encrypted Database." This protocol incorporates an XOR filter and a CSet data structure, aiming to address the limitation of JXT in not allowing arbitrary names for join attributes on two tables. Furthermore, in terms of performance, JXT+ modifies the JOIN checking method, reducing the need for JXT to enumerate all candidate matching pairs in both tables (forming...) Possible combinations of levels, among which and The approach of checking the XSet (representing the number of matching records in the two tables respectively) is replaced by performing a single scan only on the matching records in the first table, reducing query complexity from... Reduce to In addition, they proposed the JXT++ query protocol, which, by redesigning the generation method of join tags, extends JOIN join queries from two tables to multiple tables without pre-computation.

[0007] However, the above studies all focus on equality queries and cannot support multi-table join range queries, i.e., join range queries targeting multiple tables. Although it is possible to achieve range queries by using existing work to implement privacy-preserving encrypted database JOIN and then performing range queries based on the JOIN database, the query efficiency is low. Summary of the Invention

[0008] This invention provides a secure and efficient joint range query method for encrypted databases, which solves the problem of low query efficiency in the prior art and enables joint range queries of encrypted databases while ensuring data security.

[0009] This invention provides a secure and efficient joint range query method for dense databases, the method comprising: During the data initialization phase, the data owner performs system initialization operations, generating a finite field. Poseidon hash function First pseudo-random function Second pseudo-random function and the three parties secretly shared parameters ; During the data outsourcing phase, the data owner constructs JQR and XQR indexes for each table in the database, and uses the Poseidon hash function as the basis for these indexes. With shared keys The JQR index and the XQR index are encrypted into a secret index using a three-party secret sharing method, and the secret index is then combined with the shared key. Distribute to Cloud Server 1, Cloud Server 2, and Cloud Server 3; During the query credential generation phase, the querying user, based on the query request, utilizes the finite field... The operation generates a query token, and the query token is sent to cloud server one, cloud server two, and cloud server three; During the query processing phase, cloud server one, cloud server two, and cloud server three utilize their respective query tokens and shared keys. Based on the aforementioned three-party secret shared parameters The collaborative computing and secret welding protocol is used to perform a multi-table joint query on the secret state index to obtain the joint query result; During the random permutation phase, cloud servers one, two, and three jointly rearrange the positions of the secret index by performing an unintentional permutation based on secret sharing, and based on the first pseudo-random function. and the second pseudo-random function Collaborative generation of the first shared key To update the dense state index.

[0010] One or more technical solutions provided in this invention have at least the following technical effects or advantages: This invention selects a finite field during the data initialization phase. This provides a rigorous mathematical foundation for all subsequent cryptographic operations, ensuring the correctness and controllable range of calculations; the Poseidon hash function balances zero-knowledge proof friendliness with high computational efficiency, and reserves interfaces for advanced functions such as verifiable queries; two different pseudo-random functions are designed. and This provides an independent source of materials for subsequent key updates and security enhancements, avoiding the risk of reusing key materials. Pre-setting the three-party secret sharing parameter N clarifies the security model, laying the foundation for building a distributed outsourcing system that is not based on a single server and is resistant to collusion attacks. During the data outsourcing phase, building JQR and XQR indexes enables efficient support for complex multi-table join queries, optimizing query performance at the data structure level. Using secret sharing to encrypt and fragment the index ensures that no single cloud server holds only meaningless index fragments, fundamentally protecting the confidentiality of data content and index structure, achieving data usability without visibility. Distributing the shared key K in fragments eliminates the risk of a single point of complete key storage, requiring all subsequent operations involving the key to be completed collaboratively by all three parties, greatly enhancing the overall system security. In the query credential generation phase, query token generation is based on cryptographically secure finite-field operations, ensuring that the token itself is unforgeable and valid only once, preventing replay attacks on query credentials. The same token is sent to all... The server enables three parties to collaborate on computations based on the same query intent. However, because each party holds different key fragments, they cannot independently interpret the true meaning of the tokens, thus protecting user query privacy while supporting query functionality. During the query processing phase, through a multi-party secure computation protocol, the three servers can secretly share index data, intermediate states, and final results throughout the entire query process. No server can directly obtain plaintext information, achieving computable privacy protection during the query process. In particular, advanced protocols such as "secret welding" enable cross-table join queries to be completed efficiently in a encrypted state, solving the key problem of encrypted database join queries and providing practical join query functionality while ensuring data privacy. During the random permutation phase, unintentional permutations through secret sharing allow the three parties to collaboratively rearrange data positions, and no party can know the complete permutation trajectory, effectively disrupting the correlation between query access patterns and the true data position, and defending against inference attacks based on access pattern analysis. The first shared key is periodically generated and replaced collaboratively. This achieves forward security of the key, ensuring that even if the long-term key K is accidentally leaked, the historical key index will not be decrypted, and the process of generating a new key is also privacy-preserving, further enhancing the system's long-term security and dynamic update capabilities. Attached Figure Description

[0011] Figure 1 A flowchart illustrating the steps of a secure and efficient joint range query method for dense databases provided in this embodiment of the invention; Figure 2 This is a flowchart of the steps in the data initialization stage provided in an embodiment of the present invention; Figure 3This is a flowchart of the steps in the data outsourcing stage provided in an embodiment of the present invention; Figure 4 This is a flowchart of the steps in the query credential generation stage provided in an embodiment of the present invention; Figure 5 This is a flowchart of the steps in the query processing stage provided in an embodiment of the present invention; Figure 6 This is a flowchart of the steps in the random permutation stage provided in an embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0014] This invention provides a secure and efficient joint range query method for dense databases, see [link to relevant documentation]. Figure 1 The method includes the following steps S101 to S105.

[0015] S101, During the data initialization phase, the data owner performs system initialization operations to generate a finite field. Poseidon hash function First pseudo-random function Second pseudo-random function and the three parties secretly shared parameters ; Specifically, in step S101, during the data initialization phase, the data owner performs an initialization operation on the system to generate a finite field. Poseidon hash function First pseudo-random function Second pseudo-random function and the three parties secretly shared parameters This includes the following steps S1011 to S1013.

[0016] S1011, Data owner generates finite field and Poseidon hash function and initialize the parameters of the TPSS scheme. ; S1012, The data owner generates the first pseudo-random function. Second pseudo-random function and the first pseudo-random function Second pseudo-random function Send to cloud server 1, cloud server 2, and cloud server 3; S1013, generated through negotiation between Cloud Server 1 and Cloud Server 2. Symmetric key of bits Cloud server one and cloud server three negotiated and generated Symmetric key of bits Cloud server 2 and cloud server 3 negotiated and generated Symmetric key of bits Cloud server 1, cloud server 2, and cloud server 3 negotiated and generated Symmetric key of bits .

[0017] For example, see Figure 2 Phase 1: Initialization.

[0018] Given security parameters The data owner, query user, cloud server 1 (CS1), cloud server 2 (CS2), and cloud server 3 (CS3) shall collaboratively initialize the entire system according to the following steps.

[0019] Step 1: The data owner generates a finite field and Poseidon hash function and initialize the parameters of the TPSS scheme. .

[0020] Step 2: The data owner generates two pseudo-random functions. and And send it to CS1, CS2, and CS3.

[0021] Step 3: CS1 and CS2 negotiate a... Symmetric key of bits CS1 and CS3 negotiate a Symmetric key of bits CS2 and CS3 negotiate a Symmetric key of bits CS1, CS2, and CS3 negotiate a Symmetric key of bits .

[0022] S102, During the data outsourcing phase, the data owner constructs JQR and XQR indexes for each table in the database, and uses the Poseidon hash function. With shared keys The JQR and XQR indices are encrypted into a secret index using a three-party secret sharing method. The secret index is then combined with the shared key. Distribute to Cloud Server 1, Cloud Server 2, and Cloud Server 3; Specifically, in step S102, the data owner constructs JQR indexes and XQR indexes for each table in the database, including the following steps S1021 to S1025.

[0023] S1021, in the database Each table ; S1022, if the number of connection attributes Then for the table Build an XQR index; S1023, if the number of connection attributes Then for the table Construct JQR and XQR indexes, where, .

[0024] Here, regarding the table Building a JQR index includes: (1) Based on the various tables in the database Medium attributes The corresponding set of values Construct a maximum bit length of prefix tree Among them, the prefix tree leaf nodes and complete binary strings Association; Prefix Tree Internal nodes and value prefixes Related; (2) Traversing the prefix tree Each node performs the following operations: (2.1) If the current node is an internal node, then prefix the value corresponding to the current node. ,property Combine the first keyword with at least one join attribute of the current table. and as the first keyword Construct the first inverted index item Among them, the first inverted index item Used to associate with attributes The record identifier that matches the value prefix of the current node and the corresponding connection attribute value; (2.2) If the current node is a leaf node, then the complete binary string corresponding to the current node is... ,property Combine with at least one join attribute of the current table to generate a second keyword. And for the second keyword Construct the second inverted index item ; where the second inverted index item Used to associate with attributes The value above equals the record identifier and the corresponding connection attribute value of the complete binary string corresponding to the current node; (3) The first inverted index item Second inverted index item Merge to form a table The corresponding JQR index.

[0025] Here, regarding the table Building an XQR index includes: (1) Based on the various tables in the database Medium attributes The corresponding set of values Construct a maximum bit length of prefix tree Among them, the prefix tree leaf nodes and complete binary strings Association; Prefix Tree Internal nodes and value prefixes Related; (2) Traversing the prefix tree Each node performs the following operations: (2.1) If the current node is an internal node, then prefix the value corresponding to the current node. ,surface For each record in the database, generate a third keyword. and construct including properties upper matching value prefix And with the corresponding connection attribute value The third inverted index entry of the associated record identifier ; (2.2) If the current node is a leaf node, then the complete binary string corresponding to the current node is... and table For each record in the database, generate a fourth keyword. and construct including properties The above equals the complete binary string. And with the corresponding connection attribute value The fourth inverted index entry of the associated record identifier ; (3) Composed of all third inverted index entries and the fourth inverted index item This forms the XQR index.

[0026] Specifically, in step S102, based on the Poseidon hash function With shared keys The JQR and XQR indices are encrypted into a secret index using a three-party secret sharing method. The secret index is then combined with the shared key. Distributed to Cloud Server 1, Cloud Server 2, and Cloud Server 3, including: (1) Data is populated into each inverted index item in the JQR and XQR indexes to ensure that all index items have a uniform preset length; (2) The data owner uses the shared key K and the Poseidon hash function. For the first inverted index entry in the filled JQR index Second inverted index item and the third inverted index entry in the filled XQR index and the fourth inverted index item The corresponding index identifier Perform hash calculation; (3) Using the calculated encrypted hash result as the storage address, based on the shared key K, the hash value is encrypted into an arithmetic shared form using the three-party secret sharing method to generate a secret index; (4) Divide the encrypted index into three shares and send them to cloud server one, cloud server two and cloud server three respectively; (5) At the same time, the shared key K is distributed to the three cloud servers through a secret sharing scheme to ensure that each server holds only a share of the key.

[0027] For example, see Figure 3 Phase Two: Data Outsourcing.

[0028] The data owner owns a... A relational database with 1 table, denoted as The database was outsourced to CS1, CS2, and CS3 following these steps. It should be noted that the outsourced data uses different sharing methods: some data is... Shared on (denoted as) The other part is in Domain sharing (denoted as) If the data simultaneously satisfy and Then it is uniformly recorded as .

[0029] Step 1: In order to improve The efficiency of join range queries on a single table, where the data owner is the database. Build the index. If There is only one connection attribute, namely We will Build an XQR index ,in Otherwise, that is We will Build JQR indexes separately and XQR index ,in Ultimately, the database index is... .

[0030] Step 2: To protect the privacy of data access and search patterns, it is necessary to... Fill in the records to make the number of records equal. For example, specifically, the data owner first defines... The maximum number of records in is and fill all Until it contains One record. Then fill in the records using the same method. The filled index still uses express.

[0031] Step 3: The data owner selects a key. Based on the TPSS scheme Encryption .

[0032] (1) Each Encrypted as ,in and .

[0033] (2) Each Encrypted as ,in and .

[0034] Step 4: The data owner will Shared with CS1, CS2, and CS3, among which It was sent to CS1, and It is shared by CS1, CS2 and CS3.

[0035] Step 5: The data owner will Shared with CS1, CS2, and CS3, and made .

[0036] Furthermore, the generation in the first step of the second stage of The steps are as follows: (1) For Attributes in The set of corresponding values We define The maximum bit length is and establish Prefix tree of layers We number each level in a top-down manner: the root node is assigned level 0, and all other nodes are assigned level numbers incrementally based on their relationship to the root node. Each internal node and prefix in the tree... Associated, each leaf node and the complete binary string Related.

[0037] (2) Definition Every one in the tree Internal nodes of the layer or lower are Next, order Representative tuple ,in Then, we can construct the inverted index in the following form:

[0038]

[0039] in Please note that we only cover... Central Each internal node at or below the hierarchy is constructed This is because the number of data records associated with the upper-level internal nodes is greater, but the access probability of these nodes is low, so storing this type of data is unnecessary.

[0040] definition Each leaf node in the tree is Next, order Representative tuple ,in Then, we can construct the inverted index in the following form:

[0041]

[0042] in If there is no value satisfy in We must build .

[0043] definition The JQR index is .

[0044] Furthermore, the generation in the first step of the second stage of The steps are as follows: (1) For Attributes in The set of corresponding values We define The maximum bit length is and establish Prefix tree of layers Each internal node and prefix in the tree Associated, each leaf node and the complete binary string Related.

[0045] (2) Definition Each internal node in the tree is Next, order Representative tuple ,in , Then, we can construct the inverted index in the following form:

[0046]

[0047] in .

[0048] definition Each leaf node in the tree is Next, order Representative tuple ,in Then, we can construct the inverted index in the following form:

[0049]

[0050] in, If there is no value satisfy in We must build .

[0051] definition The XQR index is .

[0052] Furthermore, the method for generating prefixes in the above index generation is as follows. Prefix encoding is a data compression method that minimizes the number of bits required to represent a set of strings by using a shared prefix. For example, binary strings... Compressible to The first two strings share a prefix. , represented as Here, " The ">" character represents a wildcard, which can represent either 0 or 1. This technique allows for access via the minimum prefix set. To represent intervals Its union exactly covers For example, range It can be represented as Its minimum prefix set is .

[0053] Furthermore, the TPSS scheme used in the third step of the second phase is described below. Note that... and The secret-sharing schemes for the two domains are consistent.

[0054] A message Shared as and Two forms. Among them... ,in yes The above satisfies The random value. ,in yes The above satisfies The random value.

[0055] (1) Data owners share data by following these steps : Offline phase: CS1 and CS2 generate a random value and enable data owners to obtain .

[0056] Online Phase: Data Owner Computation and send Give it to CS1 and CS3.

[0057] (2) Data owners share data according to the following steps. : Offline phase: CS1 and CS2 generate a random value CS1 and CS3 generate a random value ,in Data owner acquisition .

[0058] Online Phase: Data Owner Computation and send Give it to CS2 and CS3.

[0059] :have ,any Able to recover . In a ring topology, each participant sends its share to the next participant, and then calculates... .

[0060] :have ,in Known to all participants, participants CS1, CS2, and CS3 can calculate according to the following steps. : Offline phase: CS1 and CS2 calculations CS1 and CS3 calculations .

[0061] Online phase: CS2 and CS computation . yes Sharing.

[0062] We built a secure computing system using TPSS. The protocol is defined as follows: This protocol input ,lose .make ,and It can be generated without interaction. After that, the key is computation. Based on secret sharing We have .

[0063] To improve efficiency in the online phase, participants perform calculations in the offline phase. Specifically, The protocol operates according to the following steps.

[0064] Offline phase: CS1 computation After that, with The format is shared among participants CS1, CS2, and CS3. Additionally, participant generation... .

[0065] Online phase: CS2 computation Send to CS3. CS3 calculates. Send to CS2. Then, CS2 and CS3 calculate... . yes Sharing.

[0066] Furthermore, the hash function in the third step of the second stage. The Poseidon hash function. The Poseidon hash function works in a finite field. Poseidon hashing is more suitable for arithmetic-based encryption protocols than traditional bit-oriented hash functions like SHA-256, especially for zero-knowledge proofs and secure multi-party computation scenarios. This is because it natively supports field operations and has fewer restrictions in arithmetic circuits.

[0067] Specifically, Poseidon hash employs a sponge-like structural design, combining a carefully crafted S-box layer with a linear hybrid layer to achieve both diffusion and non-linear effects. The S-box layer is defined as... The power mapping on is usually as follows: or (in (For a small odd exponent) to ensure efficient computation over the domain. The linear layer is based on the maximum distance separable (MDS) matrix, which ensures optimal mixing of state elements. By adjusting the domain size... Status width And the number of full S-box wheels and partial S-box wheels ( and With parameters such as [parameter 1], Poseidon hashing can be flexibly configured for different application scenarios, thus achieving a dynamic balance between security and efficiency. In our solution, [parameter 2]... Define a Poseidon hash function.

[0068] In our approach, we compute the Poseidon hash over the BLS12-381 domain. We then set the state width. Absorption rate ,capacity S-box layer uses The number of S-box wheels The number of S-box wheels Security level This ensures 128-bit security. The Poseidon hash input can be any number of bits. Output one field element. Calculate the Poseidon hash using the following steps: Absorption phase: Initial state is ,in All zeros. Input message Divided into several blocks If the last piece is insufficient, fill it with 1: .make , For each even-numbered message block Calculate the first One state: That is, after absorbing every 2 messages, an internal replacement is performed to obtain the next state. Follow these steps.

[0069] (1) Each state element in Addition constant.

[0070]

[0071] (2) S-box layer.

[0072] If it's a full round, perform an S-box operation on all state elements:

[0073] If it is a partial round, S-box is performed only on the first state element:

[0074] (3) Linear hybrid layer.

[0075]

[0076] in It is The MDS matrix.

[0077] Extrusion stage: Filling ,right Application of permutation ,at this time Output This is the final hash result.

[0078] S103, in the query credential generation stage, the querying user, based on the query request, utilizes a finite field... The operation generates a query token and sends the query token to cloud server 1, cloud server 2 and cloud server 3; Specifically, in step S103, the querying user, based on the query request, utilizes a finite field The operation generates a query token and sends the query token to cloud server 1, cloud server 2 and cloud server 3, including the following steps S1031 to S1034.

[0079] S1031, query request Scope predicate in Convert to the corresponding minimum prefix set ; S1032, for each prefix Generate corresponding query keywords Based on a tripartite secret sharing scheme, the query keywords will be shared. Transformation in a finite field Arithmetic sharing form ; S1034, All query keywords Arithmetic sharing form The tokens are combined to form a query token, which is then sent to cloud server 1, cloud server 2, and cloud server 3.

[0080] For example, see Figure 4 The third stage: generating query vouchers.

[0081] A JOIN equi-join query with a range predicate can be represented as: .in:

[0082] The user prepares a query request and generates a query token by encrypting it according to the following steps.

[0083] Step 1: Represented as a prefix set ,in .

[0084] Step 2: For each prefix , build ,in .

[0085] Step 3: Send the query credentials Cloud servers CS1, CS2, and CS3, among which .

[0086] S104, During the query processing phase, Cloud Server 1, Cloud Server 2, and Cloud Server 3 utilize their respective query tokens and shared keys. Based on the secret shared parameters of the three parties The collaborative computing and secret welding protocol is used to perform multi-table joint queries on the secret index to obtain the joint query results; Specifically, in step S104, cloud server one, cloud server two, and cloud server three utilize their respective query tokens and shared keys. Based on the secret shared parameters of the three parties The collaborative computing and secret welding protocol performs multi-table joint queries on the secret state index to obtain the joint query results, including the following steps S1041 to S1045.

[0087] S1041, Cloud Server 1, Cloud Server 2, and Cloud Server 3 are responding to the query request. Determine the starting table and target join table for the query; S1042, Query keywords corresponding to the starting table of collaborative computing queries for Cloud Server 1, Cloud Server 2, and Cloud Server 3. Hash value sharing The plaintext hash value is then restored by the cloud server. To retrieve the first intermediate result set, the dense index corresponding to the starting table of the query is retrieved. ; Here, cloud server 1, cloud server 2, and cloud server 3 share the connection attribute values ​​from the first intermediate result set. Through a secret welding protocol, the target join table is collaboratively generated to share the corresponding query keywords. Shared with hash ,include: (1) Cloud Server 1, Cloud Server 2 and Cloud Server 3 are shared for keyword querying. Input lines of the generation circuit The first random number share is preset and used as the first intermediate result set. Shared connection attribute values A pre-set second random number share; wherein, the second random number share includes: Quantity; (2) During the online query phase, cloud server 2 calculates the first difference between the first random number share and the second random number share. And send it to cloud server three; cloud server three calculates the second difference between the first random number share and the second random number share. And send it to cloud server two; (3) Cloud Server 2 and Cloud Server 3 respectively utilize Components, second difference and the first difference The input line is obtained by performing collaborative computation. The third random number share ; (4) Based on the third random number share , obtain input line The shared value, and the input line The shared value is equivalent to the shared connection attribute value. This is to complete the embedding of shared connection attribute values; (5) Cloud Server 2 and Cloud Server 3 share based on the third random number Commonly defined input lines The shared value is set to be shared with the connection attribute value. Equal to complete the embedding of shared connection attribute values.

[0088] S1043, for each element in the first intermediate result set, cloud server 1, cloud server 2, and cloud server 3 share the connection attribute values ​​from the first intermediate result set. Through a secret welding protocol, the target join table is collaboratively generated to share the corresponding query keywords. Shared with hash ; S1044, Cloud Server One Hash Sharing Restore to plaintext hash value And based on the plaintext hash value The second intermediate result set is obtained by using the dense index corresponding to the target join table. ; S1045, Merge the first intermediate result set With the second intermediate result set By sharing the identifiers of the matching records, the results of the joint query are obtained. .

[0089] For example, see Figure 5 The fourth stage: query processing.

[0090] Cloud servers CS1, CS2, and CS3 receive query credentials and use the query credentials and Query processing. Since the TPSS scheme operates in an online-offline paradigm, the retrieval process also operates in an online-offline paradigm. This means that before a user initiates a query request, CS1, CS2, and CS3 first undergo an offline phase to complete some preparatory work. During this phase, random numbers are generated on each line of the query retrieval circuit. This will be generated. When a user initiates a query request, CS1, CS2, and CS3 first send the user a random number related to the query request input line, and then the user generates the corresponding... For ease of description, we will focus on the complete query and retrieval process. The initial query results on the cloud server are... And update according to the following steps .

[0091] Step 1: Without loss of generality, we assume .if CS1, CS2, and CS3 then swapped. and Make After that, regarding CS1, CS2 and CS3 according to and calculate and restore CS1 .

[0092] Step 2: For CS1 search .make .

[0093] Step 3: For each pair For cloud servers CS1, CS2, and CS3, follow these steps: (1) For ,calculate and For ease of explanation, we let .exist In the calculation, the input includes Its shared value This was already configured during data outsourcing. However, the query retrieval circuitry settings during the offline phase... The input line is a random value. For complete online circuit calculations, we use Soldering the input lines .

[0094] (2) For CS1 recovery and search .

[0095] make .

[0096] (3) Update .

[0097] Furthermore, the secret welding protocol in the third step of the fourth phase is as follows. In the TPSS scheme, all algorithms are executed in an online-offline paradigm, which means that the evaluation of each line in the circuit... The value needs to be calculated in advance, and Then according to Update accordingly. However, in some cases, on specific lines... It has already been configured, but the cloud server only has shared values. Cloud servers need to be configured. For this purpose, we devised a secret welding protocol, Welding to On the line. The protocol is represented as .

[0098] Step 1: CS2 Calculation And send it to CS3. CS3 calculates. And send it to CS2.

[0099] Step 2: Receive Then, CS3 calculates Upon receiving the data, CS2 performs the calculation. .final, for Shared values.

[0100] S105, in the random permutation phase, cloud server one, cloud server two, and cloud server three jointly rearrange the positions of the secret index by performing an unintentional permutation based on secret sharing, and based on the first pseudo-random function. Second pseudo-random function Collaborative generation of the first shared key To update the dense state index.

[0101] Specifically, in step S105, cloud server one, cloud server two, and cloud server three jointly rearrange the positions of the secret index by performing an unintentional permutation based on secret sharing, and based on the first pseudo-random function. Second pseudo-random function Collaborative generation of the first shared key To update the secret state index, steps S1051 to S1056 are included.

[0102] S1051, Cloud Server 1, Cloud Server 2, and Cloud Server 3 define the index array in the encrypted index as the first array. And collaboratively execute an unintentional substitution protocol based on secret sharing. , the first array Randomly rearrange to obtain the second array. ; S1052, Cloud Server 1, Cloud Server 2, and Cloud Server 3 are based on the first pseudo-random function. Second pseudo-random function Interactively and collaboratively generate a new random hash key Second form of arithmetic sharing ; S1053, Cloud Server 1, Cloud Server 2, and Cloud Server 3 use the second arithmetic sharing method. and Poseidon hash function For the second array The new hash shared value corresponding to each inverted index item in the middle ; S1054, Cloud Server 1 will share a new hash value Restore to plaintext hash value ; S1055, according to the second array and plaintext hash value Update the dense state index.

[0103] For example, see Figure 6 Fifth stage: random permutation.

[0104] To protect the privacy of data access and search patterns, CS1, CS2, and CS3 will process data after several queries. To make an unintentional substitution. We use Let's take an example to illustrate the substitution steps. The same steps can be followed for replacement.

[0105] First step, let: Given an array, CS1, CS2, and CS3 are accidentally swapped. get .

[0106] Step 2: CS1, CS2, and CS3 generate a new random hash key without interaction. For each calculate And CS1 recovered Ultimately obtained . For the replacement .

[0107] This invention proposes a secure and efficient method for equi-join range queries in outsourced encrypted databases. Based on three-party secret sharing, this method efficiently supports equi-joins and range filtering on encrypted data. This invention uses binary encoding for all record values ​​and a prefix tree system to systematically process all numerical values, unifying the numerical representation and laying the foundation for scalable range queries. This invention constructs an inverted index JQR for range filtering and an inverted index XQR for equi-joins on a table-by-table basis. These are outsourced to the cloud server in a three-party secret sharing manner, significantly reducing the complexity of range queries compared to JXT+-like solutions. The invention uses the Poseidon hash function, which is highly arithmetic-friendly, to implement three-party secret sharing. This technology concentrates a large portion of the overhead in the preprocessing stage. Simultaneously, random seed synchronization technology allows cloud servers to synchronize partial data without communication, greatly reducing communication overhead. Based on a three-party secret sharing computation model, this invention does not expose any join attribute names or bind join and non-join attribute values ​​like JXT+. Instead, it concatenates attributes and prefixes, calculates hashes, and stores the data in a secret sharing manner. The cloud server only obtains the shared share and cannot access the plaintext information of the data. Furthermore, this invention hides the data access pattern through random permutation and re-sharing techniques based on secret sharing, ensuring strong privacy protection for data security. JXT+-type solutions based on searchable encryption technology adopt a client-server model, with the query key centralized in a single client, providing only single-user query functionality. In contrast, this invention, based on three-party secret sharing technology, distributes query requests to multiple participating parties for collaborative processing, supporting multiple users to independently initiate query requests without leaking data or query privacy.

[0108] The various embodiments described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. All or part of this invention can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, mobile communication terminals, multiprocessor systems, microprocessor-based systems, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

[0109] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the present invention.

Claims

1. A secure and efficient joint range query method for dense databases, characterized in that, include: During the data initialization phase, the data owner performs system initialization operations, generating a finite field. Poseidon hash function The first pseudo-random function Second pseudo-random function and the three parties secretly shared parameters ; During the data outsourcing phase, the data owner constructs JQR and XQR indexes for each table in the database, and uses the Poseidon hash function as the basis for these indexes. With shared keys The JQR index and the XQR index are encrypted into a secret index using a three-party secret sharing method, and the secret index is then combined with the shared key. Distribute to Cloud Server 1, Cloud Server 2, and Cloud Server 3; During the query credential generation phase, the querying user, based on the query request, utilizes the finite field... The operation generates a query token, and the query token is sent to cloud server one, cloud server two, and cloud server three; During the query processing phase, cloud server one, cloud server two, and cloud server three utilize their respective query tokens and shared keys. Based on the aforementioned three-party secret shared parameters The collaborative computing and secret welding protocol is used to perform a multi-table joint query on the secret state index to obtain the joint query result; During the random permutation phase, cloud servers one, two, and three jointly rearrange the positions of the secret index by performing an unintentional permutation based on secret sharing, and based on the first pseudo-random function. and the second pseudo-random function Collaborative generation of the first shared key To update the dense state index.

2. The secure and efficient joint range query method for dense databases according to claim 1, characterized in that, During the data initialization phase, the data owner performs system initialization operations to generate a finite field. Poseidon hash function The first pseudo-random function Second pseudo-random function and the three parties secretly shared parameters ,include: Data owner generates finite field and Poseidon hash function and initialize the parameters of the TPSS scheme. ; The data owner generates the first pseudo-random function. Second pseudo-random function and the first pseudo-random function and the second pseudo-random function Send to cloud server 1, cloud server 2, and cloud server 3; The cloud server one and the cloud server two negotiate to generate Symmetric key of bits The cloud server one and the cloud server three negotiate to generate Symmetric key of bits The cloud server two and the cloud server three negotiate to generate Symmetric key of bits The cloud server one, the cloud server two, and the cloud server three negotiate to generate Symmetric key of bits .

3. The secure and efficient joint range query method for dense databases according to claim 1, characterized in that, The data owner constructs JQR and XQR indexes for each table in the database, including: In the database Each table ; If the number of connection attributes Then for the table Build an XQR index; If the number of connection attributes Then for the table Construct JQR and XQR indexes, where, .

4. The secure and efficient joint range query method for dense databases according to claim 3, characterized in that, Table Building a JQR index includes: Based on the various tables in the database Medium attributes The corresponding set of values Construct a maximum bit length of prefix tree ; wherein, the prefix tree leaf nodes and complete binary strings Association; the prefix tree Internal nodes and value prefixes Related; Traverse the prefix tree Each node performs the following operations: If the current node is an internal node, then prefix the value corresponding to the current node. The aforementioned attributes Combine the first keyword with at least one join attribute of the current table. and for the first keyword Construct the first inverted index item ; where the first inverted index item Used to associate with the attribute The record identifier that matches the value prefix of the current node and the corresponding connection attribute value; If the current node is a leaf node, then the complete binary string corresponding to the current node will be displayed. The aforementioned attributes Combine with at least one join attribute of the current table to generate a second keyword. And for the second keyword Construct the second inverted index item ; where the second inverted index item Used to associate with the attribute The value above equals the record identifier and the corresponding connection attribute value of the complete binary string corresponding to the current node; The first inverted index item and the second inverted index item Merge to form a table The corresponding JQR index.

5. The secure and efficient joint range query method for dense databases according to claim 3, characterized in that, Table Building an XQR index includes: Based on the various tables in the database Medium attributes The corresponding set of values Construct a maximum bit length of prefix tree ; wherein, the prefix tree leaf nodes and complete binary strings Association; the prefix tree Internal nodes and value prefixes Related; Traverse the prefix tree Each node performs the following operations: If the current node is an internal node, then prefix the value corresponding to the current node. ,surface For each record in the database, generate a third keyword. and construct including the properties mentioned above. The above matches the value prefix. And with the corresponding connection attribute value The third inverted index entry of the associated record identifier ; If the current node is a leaf node, then the complete binary string corresponding to the current node will be displayed. and table For each record in the database, generate a fourth keyword. and construct including the properties mentioned above. The above is equal to the complete binary string. And with the corresponding connection attribute value The fourth inverted index entry of the associated record identifier ; Consisting of all the aforementioned third inverted index entries and the fourth inverted index item This constitutes the XQR index.

6. The secure and efficient joint range query method for dense databases according to claim 1, characterized in that, The hash function based on the Poseidon hash function With shared keys The JQR index and the XQR index are encrypted into a secret index using a three-party secret sharing method, and the secret index is then combined with the shared key. Distributed to Cloud Server 1, Cloud Server 2, and Cloud Server 3, including: Data is populated into each inverted index entry in the JQR and XQR indices to ensure that all index entries have a uniform preset length; The data owner uses the shared key K and the Poseidon hash function as a basis. For the first inverted index entry in the filled JQR index Second inverted index item and the third inverted index entry in the filled XQR index and the fourth inverted index item The corresponding index identifier Perform hash calculation; The calculated encrypted hash result is used as the storage address. Based on the shared key K, the hash value is encrypted into an arithmetic shared form using the three-party secret sharing method to generate a secret index. The encrypted index is divided into three shares and sent to cloud server one, cloud server two, and cloud server three respectively. At the same time, the shared key K is distributed to the three cloud servers through a secret sharing scheme to ensure that each server holds only a share of the key.

7. The secure and efficient joint range query method for dense databases according to claim 1, characterized in that, The querying user, based on the query request, utilizes the finite field The operation generates a query token, and the query token is sent to cloud server one, cloud server two, and cloud server three, including: query request Scope predicate in Convert to the corresponding minimum prefix set ; For each prefix Generate corresponding query keywords Based on a tripartite secret sharing scheme, the query keywords will be shared. Transformation in a finite field Arithmetic sharing form ; All query keywords Arithmetic sharing form The query token is formed by combining the data, and then sent to cloud server 1, cloud server 2, and cloud server 3.

8. The secure and efficient joint range query method for dense databases according to claim 1, characterized in that, Cloud server one, cloud server two, and cloud server three utilize their respective query tokens and shared keys. Based on the aforementioned three-party secret shared parameters The collaborative computing and secret welding protocol performs a multi-table joint query on the secret state index to obtain the joint query result, including: Cloud Server 1, Cloud Server 2, and Cloud Server 3 based on the query request Determine the starting table and target join table for the query; Cloud server 1, cloud server 2, and cloud server 3 collaboratively calculate the query keywords corresponding to the query starting table. Hash value sharing The plaintext hash value is then recovered by the cloud server. To retrieve the dense index corresponding to the query starting table, a first intermediate result set is obtained. ; For each element in the first intermediate result set, cloud server 1, cloud server 2, and cloud server 3 share the connection attribute values ​​from the first intermediate result set. Through a secret welding protocol, the target join table is collaboratively generated to share query keywords. Shared with hash ; The cloud server will share the hash. Restore to plaintext hash value And based on the plaintext hash value The second intermediate result set is obtained by using the dense index corresponding to the target join table. ; Merge the first intermediate result set With the second intermediate result set By sharing the identifiers of the matching records, the results of the joint query are obtained. .

9. The secure and efficient joint range query method for dense databases according to claim 8, characterized in that, Cloud Server 1, Cloud Server 2, and Cloud Server 3 share connection attribute values ​​using the first intermediate result set. Through a secret welding protocol, the target join table is collaboratively generated to share query keywords. Shared with hash ,include: Cloud Server 1, Cloud Server 2, and Cloud Server 3 are shared for the query keywords. Input lines of the generation circuit A first random number share is preset and used for the first intermediate result set. Shared connection attribute values A second random number share is preset; wherein, the second random number share includes: Quantity; During the online query phase, cloud server 2 calculates the first difference between the first random number share and the second random number share. And send it to cloud server three; cloud server three calculates the second difference between the first random number share and the second random number share. And send it to cloud server two; Cloud server two and cloud server three respectively utilize the aforementioned Components, the second difference and the first difference The input line is obtained by performing collaborative computation. The third random number share ; According to the third random number share , obtain input line The shared value, and the input line The shared value is equivalent to the shared connection attribute value. This completes the embedding of the shared connection attribute values; Cloud server two and cloud server three according to the third random number share Commonly defined input lines The shared value is set to be shared with the connection attribute value. Equal to complete the embedding of the shared connection attribute values.

10. The secure and efficient joint range query method for dense databases according to claim 1, characterized in that, Cloud server one, cloud server two, and cloud server three jointly rearrange the positions of the secret index by performing an unintentional permutation based on secret sharing, and based on the first pseudo-random function. and the second pseudo-random function Collaborative generation of the first shared key To update the dense state index, including: Cloud Server 1, Cloud Server 2, and Cloud Server 3 define the index array in the dense index as the first array. And collaboratively execute an unintentional substitution protocol based on secret sharing. , the first array Randomly rearrange to obtain the second array. ; Cloud server 1, cloud server 2, and cloud server 3 are based on the first pseudo-random function and the second pseudo-random function Interactively and collaboratively generate a new random hash key Second form of arithmetic sharing ; Cloud Server 1, Cloud Server 2, and Cloud Server 3 use the second arithmetic sharing method. and the Poseidon hash function For the second array The new hash shared value corresponding to each inverted index item in the middle ; The cloud server will share the new hash value. Restore to plaintext hash value ; According to the second array and the plaintext hash value Update the dense state index.

Images