A privacy protection aggregation query method for multi-party data collaboration

Abstract

The present application belongs to the technical field of privacy calculation, cryptography and data security, and particularly relates to a privacy protection aggregation query method for multi-party data cooperation, comprising the following steps: electing two collaborative role servers in multiple participating servers; a client respectively performs an oblivious pseudo-random function with each server in a first round to obtain a pseudo-random representation of a query identifier; each server performs secret sharing splitting on an associated value corresponding to a local record, and sends the value to the two collaborative role servers respectively; the client further performs an interaction of subsequent oblivious pseudo-random functions with the two collaborative role servers respectively, and cooperates to shuffle a share set; the two collaborative role servers respectively complete matching and share aggregation, and return aggregated shares to the client; and the client reconstructs to obtain a final aggregation query result. The present application can adapt to the data cooperation demand between multiple independent data sources, and overcome the dependence of the existing scheme on full staff hits.

Description

Technical Field

[0001] This invention belongs to the fields of privacy computing, cryptography and data security technology, and specifically relates to a privacy-preserving aggregation query method for multi-party data collaboration. It is applicable to application scenarios where multiple independent data holders can conduct joint statistics, collaborative analysis and secure queries without sharing the original data. Background Technology

[0002] With the development of scenarios such as healthcare, supply chain collaboration, platform governance, government governance, and cross-institutional business cooperation, an increasing amount of data is held by multiple independent institutions. Each data holder typically possesses identifying information related to a specific object and its corresponding numerical information, such as service frequency, statistical indicators, business amount, risk score, or inventory quantity. Querying parties often seek aggregated results across multiple parties around a specific target identifier to support joint analysis and business decision-making.

[0003] However, in multi-party data collaboration scenarios, the raw data often contains sensitive personal information, institutional proprietary information, or data subject to regulatory constraints, making it difficult for participating parties to directly share local plaintext data. Centralizing all data for unified querying on a single platform not only amplifies the risk of centralized data leakage but also weakens each participating party's autonomy over their local data. Existing privacy computing technologies, such as Private Set Intersection (PSI) and its variants, primarily address the intersection discovery problem. However, traditional solutions typically only output the intersection elements themselves or the intersection size, making it difficult to directly support multi-party aggregation queries targeting related numerical values. While some PSI-SUM solutions can achieve summation, they often require all participating parties to simultaneously hit the same identifier, making them unsuitable for situations where multiple independent data sources partially overlap or are even sparsely distributed.

[0004] Private information retrieval (PIR) and its extended solutions mainly address the privacy retrieval problem without exposing the query content. However, most solutions assume that the data to be queried is located in a single database or a unified server, making it difficult to directly cover collaborative aggregation query scenarios in which multiple independent data holders participate and need to hide the hit situation and intermediate aggregation information.

[0005] Therefore, how to achieve secure aggregated queries for multiple independent data sources while protecting the privacy of query identifiers, the original data privacy of each participant, the privacy of hit relationships, and the privacy of intermediate information in the final result has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] To address the problems existing in the prior art, this invention proposes a privacy-preserving aggregate query method for multi-party data collaboration, specifically including the following steps:

[0007] S1. Set up a client and multiple servers to participate in the query. Each server stores a local dataset, which consists of an identifier and associated values.

[0008] S2. Elect two cooperative role servers from multiple servers using a verifiable pseudo-random function;

[0009] S3. The client obtains the pseudo-random result of the target query identifier under the corresponding key of each server. Each server obtains the corresponding key and calculates the result of the local identifier's unintentional pseudo-random function. Then, the value associated with each identifier is split into two additive secret shared shares.

[0010] S4. Each server sends the first secret shared share to the first collaborative role server and the second secret shared share to the second collaborative role server.

[0011] S5. The client takes the first round of pseudo-random results as input and performs the second and third rounds of unintentional pseudo-random function interactions with the two collaborative role servers respectively, so that the pseudo-random results corresponding to the client's query identifier are in a matching state with the pseudo-random results of the identifier held by the two collaborative role servers.

[0012] S6. The two collaborative role servers respectively perform shuffling, matching, and share aggregation on their respective share sets to obtain the first aggregated share and the second aggregated share;

[0013] S7. The client receives the first aggregation share and the second aggregation share, and obtains the final aggregation query result through reconstruction operation.

[0014] Compared with existing technologies, this invention has at least the following advantages: First, it is designed for collaborative scenarios with multiple independent data holders, without relying on the premise of a perfect hit for all participants, and can more naturally adapt to partially overlapping and sparsely distributed data; Second, by using multiple rounds of Oblivious Pseudorandom Function (OPRF) and set shuffling, it can simultaneously hide the query identifier, local hit relationship, and specific data source; Third, by using additive secret sharing to distribute associated values ​​to servers of different collaborative roles, it avoids any single party directly knowing the original associated values ​​and the complete aggregation path, thereby improving the overall privacy protection capability. Attached Figure Description

[0015] Figure 1 This is a flowchart of a privacy-preserving aggregated query method for multi-party data collaboration according to the present invention. Detailed Implementation

[0016] 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 embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] This invention proposes a privacy-preserving aggregate query method for multi-party data collaboration, such as... Figure 1 Specifically, it includes the following steps:

[0018] S1. Set up a client and multiple servers to participate in the query. Each server stores a local dataset, which consists of an identifier and associated values.

[0019] S2. Elect two cooperative role servers from multiple servers using a verifiable pseudo-random function;

[0020] S3. The client obtains the pseudo-random result of the target query identifier under the corresponding key of each server. Each server obtains the corresponding key and calculates the result of the local identifier's unintentional pseudo-random function. Then, the value associated with each identifier is split into two additive secret shared shares.

[0021] S4. Each server sends the first secret shared share to the first collaborative role server and the second secret shared share to the second collaborative role server.

[0022] S5. The client takes the first round of pseudo-random results as input and performs the second and third rounds of unintentional pseudo-random function interactions with the two collaborative role servers respectively, so that the pseudo-random results corresponding to the client's query identifier are in a matching state with the pseudo-random results of the identifier held by the two collaborative role servers.

[0023] S6. The two collaborative role servers respectively perform shuffling, matching, and share aggregation on their respective share sets to obtain the first aggregated share and the second aggregated share;

[0024] S7. The client receives the first aggregation share and the second aggregation share, and obtains the final aggregation query result through reconstruction operation.

[0025] This invention combines a verifiable random function (VRF), an unintentional pseudo-random function, and additive secret sharing (ASS). Through multiple rounds of pseudo-random mapping, role separation, share splitting, and set obfuscation, it enables secure aggregated queries among multiple independent data holders.

[0026] This invention selects two collaborative role servers from multiple participating servers using VRF (Virtual Randomization), designated as the first collaborative role server and the second collaborative role server. This design avoids the long-term fixation of a single server in key roles, thereby reducing the risk of information leakage caused by role rigidity.

[0027] In this invention, the client performs a first round of OPRF interaction with each server to obtain the first round of pseudo-random results for the target query identifier under the corresponding keys of each server. Simultaneously, each server performs the same round of OPRF mapping on the identifier of each record in its local dataset to obtain the first round of pseudo-random labels corresponding to the local records. Each server further splits the associated value corresponding to each record into two additive secret shared shares and sends them to two cooperating role servers respectively.

[0028] In this invention, the client performs subsequent rounds of OPRF interactions with the first and second collaborative role servers, respectively, so that the query tags on the client side and the share tags held by the two collaborative role servers enter a matching state. To further hide the hit relationship and source relationship, the two collaborative role servers shuffle and obfuscate the set of tags and shares before matching.

[0029] In the aggregation phase of this invention, the first collaborative role server sums its own first secret sharing shares based on the matching relationship to obtain the first aggregated share; the second collaborative role server sums its own second secret sharing shares based on the matching relationship to obtain the second aggregated share. Both collaborative role servers return their corresponding aggregated shares to the client. The client reconstructs the two aggregated shares to obtain the final aggregated query result.

[0030] The aggregation operation in this invention is a summation operation. When the associated values ​​of all records are uniformly set to 1, this invention can be used to count the number of hit records; when the associated values ​​represent business volume, amount, score, inventory, or other values ​​that can be associated, multi-party secure aggregation of corresponding attributes can be achieved.

[0031] This method integrates Verifiable Random Function (VRF), Unintentional Pseudorandom Function (OPRF), and Additive Secret Sharing (ASS) cryptographic primitives to enable client-side identifier lookup. For example, user identifiers, device identifiers, etc.; server Dataset (Here, i represents different data participants, and j represents the data indexes owned by different data participants.) This indicates the object corresponding to the target identifier. This ensures comprehensive privacy protection for query results (representing the associated numerical values ​​of each participant and the target identifier) ​​and guarantees that neither the client nor the servers can infer the query hit rate.

[0032] For ease of understanding, the main symbols in this invention are uniformly explained as follows:

[0033] Indicates the client; Indicates the i-th participating server, where , This indicates the total number of participating servers. Two servers are selected from all servers in the parameter as collaborating servers. This indicates the server that received the first cooperative role through election; This indicates the second collaborative role server selected through election; This indicates the target query identifier input by the client; This represents the dataset held by the i-th server; dataset The j-th data is written as ,in , This indicates the number of records in a single server. This represents the object identifier corresponding to the data of the j-th record on the i-th server. Representation and object identifier The associated numerical value, for example, if a message is "(Business volume, 1234)", then its object identifier is "Business volume", which represents the associated numerical value "1234". That is, in this application, the object identifier and its associated numerical value are used to form a tuple; the symbol ∈ indicates belonging, and the notation is... [1, m] and [m] represent the corresponding integer index ranges, respectively;

[0034] In the first round of interaction, F represents the pseudo-random function (PRF). , and These represent the pseudo-random function keys used by the i-th server in the first, second, and third rounds of unintentional pseudo-random function interactions, respectively. This represents the first round of pseudo-random results obtained by the client from the i-th server. The representation is the set consisting of the first round of pseudo-random results from all servers; the object identifier formed by the first round of OPRF mapping performed by the i-th server on the j-th record data, and the value associated with this representation, form a tuple. A tuple of all records on a server constitutes ;

[0035] During the secret sharing phase and Representing the object identifier respectively Related values The first and second secret-sharing shares obtained by splitting the data, and satisfying that the sum of the two modulo q, can be restored to the original state. Where q indicates that the modular arithmetic uses the prime order of the group, Represents modulo operation; and These represent the tuples carrying the first and second secret share shares, respectively; that is, the associated values ​​in these two tuples are respectively... and ; and These represent the messages sent by the i-th server to the first collaborative role server. Second Collaborative Role Server Two sets, where set is a set Store all tuples based on the first secret share in the i-th server, using a set Store all tuples based on the second secret share in the i-th server;

[0036] In the second and third rounds of interaction, This indicates the pseudo-random result obtained by the client in the second round. Indicates that it is composed of all The set that constitutes; Indicates the first collaborative role server Matchable pairs formed on the side Indicates that it is composed of all The set that constitutes; This represents the pseudo-random result obtained by the client in the third round. Indicates that it is composed of all The set that constitutes; Indicates the second collaborative role server Matchable pairs formed on the side Indicates that it is composed of all The set that constitutes;

[0037] During the aggregation phase, This indicates the first aggregate share received by the client. This indicates the second aggregate share received by the client. The final aggregate query result is represented by Σ; the symbol Σ represents the summation of the secret shared shares that meet the matching conditions; the symbol mn represents the total number of candidate elements participating in the matching comparison after scrambling and obfuscation.

[0038] In multiple servers participating in the query (For example, among the various data participants) two special roles are elected fairly and randomly through VRF, namely the first collaborative role server. Second Collaborative Role Server This election mechanism ensures the randomness and fairness of role allocation.

[0039] In this embodiment, the first OPRF call mainly includes the following steps:

[0040] Client By query identifier For input, the i-th server The first time the OPRF protocol is invoked, the client Obtain pseudo-randomization results Where F is the PRF function, It is the key for the first PRF function. It is a PRF function with a key exist The evaluation output is then displayed on the client side; Initialize an empty collection And order ;

[0041] The i-th server Then obtain the corresponding OPRF key. And for the i-th server dataset The pseudo-randomization result of the j-th record data It is generated by the client. Obtain pseudo-randomization results The object identifier corresponding to the j-th record in the i-th server. Composition, represented as , This is the specific numerical value of the object identifier corresponding to the j-th record in the i-th server;

[0042] The i-th server Values ​​that need to be kept confidential Divided into two secret shares and sent to the first collaborative role server respectively. Second Collaborative Role Server It mainly includes the following steps:

[0043] First of all, for The i-th server Data that needs to be kept confidential Divided into the first secret shared share Second secret shared share And satisfy them , where mod is the modulo operation and q is the prime order of the group;

[0044] Then, the i-th server Find the pseudo-randomization result of the j-th record data when the first and second secret shared shares are used as the object identifiers. The results of the interaction of these two first-round unintentional pseudo-randomization functions can be represented as two tuples, i.e. as well as ,in, , ,for and Do the same operation. , This means that two data items have the same object identifier, but the associated values ​​are different;

[0045] for The i-th server Initialize two empty sets and And respectively ordered and That is, set Store all tuples based on the first secret share in the i-th server, using a set Store all tuples based on the second secret share in the i-th server; the i-th server The set will contain the OPRF results and the first secret-sharing share. Send to the first collaborative role server This will include the OPRF results and the second secret-sharing share. Send to the second collaborative role server During this process, the i-th server It will not send its own secret share to itself (i.e., if the i-th server) The first collaborative role server is exactly... Or a second collaborative role server (Then it will not send its own secret share to itself).

[0046] First Collaborative Role Server Receive from other servers The first set of secret shared shares was sent, and its own data was integrated with the client. Perform a second OPRF call. The process of executing the second OPRF call specifically includes:

[0047] Client The pseudo-randomization result of the first round of OPRF obtained from the i-th server As input, with the first collaborative role server Perform a second round of OPRF interaction to obtain the second round of pseudo-randomization results for the i-th server. , represented as ,in It is the key for the second PRF function. It is a PRF function with a key exist Evaluation output;

[0048] Client Initialize collection And order That is, set This includes the second round of pseudo-randomization results from all servers; simultaneously, with the first cooperating role server... Obtain OPRF key And for the data received from the i-th server The j-th element in the set is the object identifier of the first round of pseudo-randomization result of the j-th record data from the i-th server. The second round of pseudo-randomization results were obtained through calculation. , A tuple consisting of an object identifier and its associated numerical value is represented as: The object identifier of the second round of pseudo-randomization result of the j-th record data from the i-th server is represented as: The object identifier is associated with the numerical value represented as follows: ,in The pseudo-random function is represented by a key. exist The evaluation output above, the second round of pseudo-randomization results include the first secret share;

[0049] for First Collaborative Role Server Initialize collection And order That is, using sets Store the second round of pseudo-randomization results for all data across all servers, including the first secret share;

[0050] Then, the client and the first collaborative role server Sets and set After the elements are scrambled and confused, they are sent to the second and collaborative role servers. .

[0051] Second Collaboration Role Server Receive from all other servers The second set of secret shared shares was sent, and its own data was integrated with the client's. Perform the third OPRF call. The process of executing the third OPRF call specifically includes:

[0052] Client The pseudo-randomization result obtained from the first round of OPRF by each server is used as input, and combined with the second collaborative role server. The third OPRF interaction was performed to obtain the third round of pseudo-randomization results from each server, as well as the first round of pseudo-randomization results from the client. The corresponding third round pseudo-randomization result, i.e., the third round pseudo-randomization result of the i-th server, is represented as: ,in It is the third PRF function key. It is a PRF function with a key exist Evaluation output;

[0053] Client Initialize collection And order That is, set This includes the results of the third round of pseudo-randomization for all servers;

[0054] Meanwhile, the second collaborative role server Obtain the key to execute the third round of the unintentional pseudo-random function and the second secret share received A binary identifier Based on key Execute a pseudo-random function and match it with the corresponding associated value. Combining the results to form the third round of pseudo-randomization , A tuple consisting of an object identifier and its associated numerical value is represented as: The object identifier of the third round of pseudo-randomization results is represented as: The object identifier associated numerical value of the third round of pseudo-randomization results is represented as follows: ,in, The pseudo-random function is represented by a key. exist Evaluation output;

[0055] for Second collaborative role server Initialize collection And order That is, using sets The third round of second secret share stores all data across all servers;

[0056] Then, the client Second Collaborative Role Server Sets and set After the elements are scrambled and confused, they are sent to the first collaborative role server. .

[0057] Secret share aggregation mainly includes the following steps:

[0058] First, the second collaborative role server Aggregate the first share: Second collaborative role server Receive from client and the first collaborative role server Confused set and set Afterwards, due to the set The set contains m×n elements (where m is the total number of elements per server and n is the number of servers), and after shuffling, the concepts of i and j are no longer present. Therefore, let the set... The elements in the middle are expressed as ,for each , Each Second collaborative role server For each tuple calculation Soon to gather Data pairs with the same identifier are grouped together, and then the sum of all related values ​​in that group is calculated. Then calculate the results Send to the client ;

[0059] Secondly, the first collaborative role server Aggregate the second share: Second collaborative role server Receive from client and the first collaborative role server Confused set and set Afterwards, due to the set The set contains m×n elements (where m is the total number of elements per server and n is the number of servers), and after shuffling, the concepts of i and j are no longer present. Therefore, let the set... The elements in the middle are expressed as ,for each , each First Collaborative Role Server For each tuple calculation Soon to gather Data pairs with the same identifier are grouped together, and then the sum of all related values ​​in that group is calculated. Then calculate the results Send to .

[0060] The calculation of aggregate query results mainly includes the following steps:

[0061] Client Received from the second collaborative role server and the first collaborative role server Secret aggregation share and Then, local calculation The final aggregate query result can then be reconstructed. (For example, the sum of the associated values ​​of the target identifier across all participants).

[0062] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A privacy-preserving aggregate query method for multi-party data collaboration, characterized in that, Specifically, the following steps are included: S1. Set up a client and multiple servers to participate in the query. Each server stores a local dataset, which consists of an identifier and associated values. S2. Elect two cooperative role servers from multiple servers using a verifiable pseudo-random function; S3. The client obtains the pseudo-random result of the target query identifier under the corresponding key of each server. Each server obtains the corresponding key and calculates the result of the local identifier's unintentional pseudo-random function. Then, the value associated with each identifier is split into two additive secret shared shares. S4. Each server sends the first secret shared share to the first collaborative role server and the second secret shared share to the second collaborative role server. S5. The client takes the first round of pseudo-random results as input and performs the second and third rounds of unintentional pseudo-random function interactions with the two collaborative role servers respectively, so that the pseudo-random results corresponding to the client's query identifier are in a matching state with the pseudo-random results of the identifier held by the two collaborative role servers. S6. The two collaborative role servers respectively perform shuffling, matching, and share aggregation on their respective share sets to obtain the first aggregated share and the second aggregated share; S7. The client receives the first aggregation share and the second aggregation share, and obtains the final aggregation query result through reconstruction operation.

2. The privacy-preserving aggregate query method for multi-party data collaboration according to claim 1, characterized in that, The first round of unintentional pseudo-random function interaction includes the following steps: Client By query identifier For input, and the i-th server The first time the pseudo-random function is called, the client... Obtain the results of the first round of pseudo-randomization Where F is a pseudo-random function, It is the key for the first pseudo-random function. It is a pseudo-random function with a key exist Evaluation output; Client Initialize an empty collection And order That is, set It includes the first round of pseudo-randomization results from all servers; The i-th server Obtain the corresponding unintentional pseudo-random function key And for their own dataset The pseudo-randomization result is calculated for each target identifier. , The pseudo-random function is represented by a key. exist The evaluation output on the above, For dataset The identifier of the j-th data in the data. For identification The numerical value associated with the item.

3. The privacy-preserving aggregate query method for multi-party data collaboration according to claim 1, characterized in that, The process of obtaining the first round of pseudo-random results and splitting the corresponding associated values ​​into two additive secret shared shares includes: The i-th server The numerical value associated with the object identifier Split into the first share Second share Splitting satisfies , where mod is the modulo operation and q is the prime order of the group; The i-th server Two pairs are defined based on the first share and the second share, namely, the pairs based on the first share. and binary pairs based on the second share ,in The pseudo-random function is represented by a key. exist Evaluation output; The i-th server Using sets Store all tuples based on the first share in the i-th server, using the set Store all tuples based on the second share in the i-th server; The i-th server This will contain the result of an unintentional pseudo-random function and a set as the first secret share. Send to a collaborative role server, containing the result of an unintentional pseudo-random function and a set as a second secret share. Send to another collaborative role server.

4. The privacy-preserving aggregate query method for multi-party data collaboration according to claim 3, characterized in that, If the i-th server If it is one of the cooperating role servers, it will not send a set containing the result of an unintentional pseudo-random function and the corresponding secret share.

5. A privacy-preserving aggregate query method for multi-party data collaboration according to claim 1 or 3, characterized in that, In step S5, when the first collaborative role server receives the first secret share sent by each server and integrates its own data with the client... The process of making a second unintentional pseudo-random function protocol call includes: Client The pseudo-randomized result obtained from the first round of unintentional pseudo-randomization function As input, a second round of unintentional pseudo-random function interaction is performed with the first collaborative role server to obtain... ,in Represents a pseudo-random function. It is the key for the second pseudo-random function. It is a pseudo-random function with a key exist Evaluation output; Client Initialize collection And order That is, set It includes the second round of pseudo-randomization results for all servers; At the same time, the first collaborative role server obtains the key to execute the second round of unintentional pseudo-random functions. And the identifiers of each tuple in the first received secret share are based on the key. Execute a pseudo-random function and combine it with the corresponding associated numerical value to form the first secret share of the second round; The first collaborative role server utilizes a collection The second round of the first secret share stores all data across all servers; Client The first collaborative role server will respectively collect and set After the elements are shuffled and confused, they are sent as the first share to the second collaborative role server.

6. The privacy-preserving aggregate query method for multi-party data collaboration according to claim 5, characterized in that, The process of the second collaborative role server aggregating the first share includes: The first collaborative role server receives data from the client. The first share after confusion of the second collaborative role server, which includes a set and set ; For sets Each element and set Each pair , , Each tuple calculation The first aggregate share Send to the client .

7. A privacy-preserving aggregate query method for multi-party data collaboration according to claim 1 or 3, characterized in that, In step S5, the second collaborative role server receives the second secret share from all other servers and integrates its own data with the client. The third unintentional pseudo-random function call includes: Client The pseudo-randomized result obtained from the first round of unintentional pseudo-randomization function As input, a third round of unintentional pseudo-random function interaction is performed with the second collaborative role server to obtain... ,in Represents a pseudo-random function. It is the third PRF function key. It is a PRF function with a key exist Evaluation output; Client Initialize collection And order That is, set This includes the results of the third round of pseudo-randomization for all servers; At the same time, the second collaborative server obtains the key to execute the second round of unintentional pseudo-random functions. And the identifiers of each tuple in the received second secret share are based on the key. Execute a pseudo-random function and combine it with the corresponding associated numerical value to form the first secret share of the third round; The second collaborative role server utilizes a set The third round of second secret share stores all data across all servers; Client The second collaborative role server will respectively set up and set The elements are shuffled and mixed up, and then sent as a second share to the first collaborative role server.

8. The privacy-preserving aggregate query method for multi-party data collaboration according to claim 7, characterized in that, The process of the first collaborative role server aggregating the second share includes: The first collaborative role server receives data from the client. The second share after confusion with the second collaborative role server, which includes a set and set ; For sets Each element and set Each pair , , Each tuple calculation The second aggregation share Send to the client .

9. A privacy-preserving aggregate query method for multi-party data collaboration according to claim 1, characterized in that, The client receives the first and second aggregation shares, and obtains the final aggregation query result through reconstruction operations, represented as follows: in, This is the final aggregated query result; It is the first aggregate share; q represents the second aggregation share; q is the prime order of the group.

Images