Multi-party data joint security query method
Through the multi-party data joint security query method, secret sharing and arithmetic sharing protocols are used to support common database function operations of multiple participants, solving the problems of data leakage and insufficient security in the existing technology, and achieving efficient and secure database query functions.
Patent Information
- Application Number
- CN202411256454.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-09
- Publication Date
- 2024-12-27
AI Technical Summary
The prior art cannot achieve a variety of efficient and secure common database function operations that support any multiple participants, especially in joint data queries, there is a risk of data leakage, especially the security of the aggregate function SUM is not effectively guaranteed.
Through secret sharing, we realize the joint security query method of multi-party data, including querying the client to receive and parse SQL query statements, generating multi-party security calculation tasks, and each participant performs permission checks and security calculations locally, and supports common database functions such as equivalent connections , group sum, count and aggregate the most value operations, and use arithmetic sharing protocol and OPPRF protocol to ensure data privacy.
It supports common database query functions to ensure the security and efficiency of joint query of any multiple participants, avoid data privacy leakage, and solves the problem of efficient and secure database function operation in the existing technology.
Smart Images

Figure CN119201988A_ABST
Abstract
Description
Technical Field
[0001] The invention relates to a multi-party data joint security query method, belonging to the technical field of multi-party data query. Background Art
[0002] Joint query of multi-party data can significantly improve the quality of data analysis. However, due to the provisions of data confidentiality regulations, how to securely conduct joint query of multi-party cross-domain data has become an important application field. An important application of PSI is joint query of multi-party data. However, existing research mainly focuses on how to apply PSI to data table connection operations, but ignores the data leakage risks that may be caused by some commonly used clauses or functions in the database. For example, the aggregate function SUM in the database currently does not have a reliable and secure function implementation. Attackers can obtain the data of each participant before the aggregate function is performed by attacking the querying party, thereby obtaining information about the input content of each party.
[0003] At present, most of the research on data joint security query is based on data privacy intersection technology. With the development of multi-party secure computing frameworks, many frameworks have implemented multi-party secure computing technology that supports multiple participants. The existing multi-party data joint query system realizes the table connection operation of multiple participants through the PSI protocol based on key exchange or oblivious transmission, ensuring that the data tables of multiple participants can be securely queried. In a common multi-party data joint query system, each participant agrees on the various parameters required by PSI, and shares the data they hold through the PSI protocol. Each participant executes the PSI protocol and understands the data held by each participant. However, due to the limitations of PSI technology, it does not support other common operations in data query, such as aggregate functions. Therefore, the present invention realizes a variety of fast and secure common database functions through secret sharing. Summary of the invention
[0004] A brief overview of the present invention is provided below in order to provide a basic understanding of certain aspects of the present invention. It should be understood that this overview is not an exhaustive overview of the present invention. It is not intended to identify key or important parts of the present invention, nor is it intended to limit the scope of the present invention. Its purpose is merely to present certain concepts in a simplified form as a prelude to a more detailed description discussed later.
[0005] In view of this, in order to solve the technical problem that the prior art cannot realize multiple common database function operations that are efficient and secure and support any number of participants, the present invention provides a multi-party data joint security query method;
[0006] Solution 1: A multi-party data joint secure query method, comprising:
[0007] Step 1: The query client receives and parses the SQL query statement entered by the user, and performs a permission check on the query statement to verify whether the SQL statement is allowed to be executed by each data holder;
[0008] Step 2: The query client generates a multi-party secure computing task for each participant according to the query statement and sends it to each participant;
[0009] Step 3: Each participant performs permission check locally and executes the subquery part and multi-party secure computing tasks;
[0010] Step 4: Obtain the execution results of each participant, and query the client to schedule each participant to execute the multi-party secure computing task.
[0011] Preferably, the method for the query client to parse the SQL query statement input by the user is:
[0012] Use the parser to parse the user's query statement, detect the SQL keywords in the query statement, and split the query statement according to the SQL keywords. The SQL statement will be split into the query part, the connection condition part and the query condition part;
[0013] The parser checks whether the query statement is allowed to be executed according to the user's permission configuration. The permission configuration includes: can be transmitted in plain text, can be transmitted after encryption calculation, and cannot be transmitted;
[0014] The parser merges the locally executed queries and extracts the query statements that do not require ciphertext calculation into plaintext query plans according to the rules;
[0015] If the query statement entered by the user contains data attributes that are prohibited from being transmitted, the query statement as a whole will not work; if all data attributes contained in the SQL query statement can be transmitted in plain text, the plain text query will be executed directly.
[0016] Preferably, step 2 specifically includes the following steps:
[0017] Step 21: The query client checks the SQL keywords and data attributes in the statement, and generates a SQL query tree for the SQL statement based on the SQL keywords. The leaf nodes at the end of the tree are data attribute nodes, and the connection nodes of the tree are SQL keyword nodes.
[0018] Step 22: According to the generated SQL query tree, the query client marks the leaf nodes whose data attribute is "encrypted calculation and then transmitted";
[0019] Step 23: traverse the entire SQL query tree, mark all SQL keyword nodes that are connected to the marked leaf nodes, and mark all data attribute leaf nodes that are connected to the marked SQL keyword nodes;
[0020] Step 24: traverse the entire SQL query tree, generate subquery plans for SQL keyword nodes that are directly connected to leaf nodes and are not marked, and generate a multi-party secure computing plan containing subquery plans for marked SQL keyword nodes.
[0021] Preferably, step 24 specifically includes:
[0022] If the SQL keyword node keyword is a simple operation type: each data holder will directly encrypt the involved data through the arithmetic sharing protocol and execute the basic security calculation protocol;
[0023] If the SQL keyword node keyword is EQUAL JOIN, that is, an equi-join operation: the relevant data holders execute the multi-participant secure equi-join algorithm;
[0024] If the SQL keyword node keyword is the sum group sum keyword, the relevant data holders perform a privacy-safe group sum operation;
[0025] If the SQL keyword node keyword is COUNT, the data quantity is calculated by grouping: each relevant data holder executes the privacy-safe count operator;
[0026] If the SQL keyword node keyword is MIN / MAX, the aggregation maximum value operator is used, and each related data holder executes the safe aggregation maximum value algorithm for traversable attributes.
[0027] Preferably, the secure computing protocol is a private addition protocol, a private multiplication protocol and a private comparison protocol based on integer arithmetic sharing, floating point arithmetic sharing and binary sharing;
[0028] Private addition protocol: Floating point arithmetic sharing and integer arithmetic sharing support addition protocol. Arithmetic sharing has the property of addition homomorphism. For [z] = [x] + [y], to calculate the arithmetic sharing of [z], for each participant p∈P, p holds [x] p , [y] p , due to the properties of arithmetic shared addition homomorphism, party p locally computes [z] p =[x] p +[y] p , [z] p That is, additive sharing;
[0029] Private multiplication protocol: Both floating point arithmetic sharing and integer arithmetic sharing support private multiplication protocol; use Beaver triples protocol for multiplication under arithmetic sharing. The protocol uses a trusted third party to generate a triple ([a], [b], [c]), c = a*b, and each participant calculates [alpha] p =[x] p-[a] p ,[β] p =[y] p -[b] p , α and β are calculated without causing information leakage using the mask form, and each participant calculates [x*y] p =[c] p +β*[b] p +α*[a] p +α*β;
[0030] Private comparison protocol: Both floating-point arithmetic sharing and integer arithmetic sharing support private comparison protocol; arithmetic sharing comparison protocol is performed by converting arithmetic sharing and binary sharing. If you want to calculate [z<0], convert arithmetic sharing [z] into binary sharing. <z>, then calculate the binary sharing <z>The flag bit = <z>>>(L-1), then share the binary Convert it to arithmetic sharing [b], and [b] is the arithmetic sharing result of [z < 0]. If you want to calculate [x < y], then convert the problem to [z] = [x] - [y], [z < 0].
[0031] Preferably, a secure equi-join algorithm, specifically:
[0032] Execute a conditional secret sharing protocol among data holders:
[0033] Each data holder performs a local query based on the query plan to obtain a data set;
[0034] Each data holder executes a zero-sharing generation protocol for each data to generate zero-shares for other data holders;
[0035] Other data holders initiate inquiries to the data holder for each of their own data through the OPPRF protocol;
[0036] If the data held by the data holder is the same as that of other data holders, other data holders hold the zero-shares generated by the data holder, otherwise they hold random values;
[0037] Execute a conditional secret sharing decryption protocol among data holders:
[0038] Each data holder queries other data holders for data through the OPPRF protocol to determine whether the data it holds exists in the intersection of the data of other data holders;
[0039] If other data holders hold the same data as the data holder, return the zero-shares generated by the data holder through the OPPRF protocol, otherwise hold random values;
[0040] The response result of the data holder's inquiry to other data holders for the same data is through the OPPRF protocol. If other data holders contain the same data as the data holder, return the data holder's zero-shares, otherwise return random numbers;
[0041] The data holder verifies the inquiry results and accumulates all the query results. When the accumulated result is 0, it means that other data holders have all returned zero-share values for this inquiry, that is, the data held by the data holder exists in the intersection of other data holders; when the accumulated result is other, it means that at least one data holder has returned a random number for this inquiry, that is, the data held by the data holder does not exist in the intersection of other data holders.
[0042] Preferably, a privacy-safe grouped summation operation, specifically:
[0043] The data holder performs a local query and generates a query view (sum(data i ),id i ), where id i It is the base attribute for grouping operation;
[0044] The data holder shares the query view through the arithmetic sharing protocol;
[0045] Data holders receive the arithmetic share (sum (data j ),id j );
[0046] Data holder calculation
[0047] [sum(data i )]+[id1]==[id i ]*[sum(data1)]+...+([id n ]==[id i ])*[sum(data n )];
[0048] The querying party decrypts and removes duplicates from the protocol calculation results;
[0049] The privacy-safe count operator is as follows:
[0050] The data holder executes a local query and generates a query view (count(*), id i );
[0051] The data holder shares the query view through the arithmetic sharing protocol;
[0052] Data holders receive arithmetic shares from other data holders (count(*), id j );
[0053] The data holder calculates [count(*)]+[id1]==[id i ]*[count(*)]+...+([id n ]==[id i ])*[count(*)];
[0054] The querying party decrypts and removes duplicates from the protocol calculation results;
[0055] Security aggregation maximum value algorithm:
[0056] The data holder executes a local query and generates a query view (MAX(data i ),id i );
[0057] The data holder constructs the arithmetic shared set s i ={[0],[0],...[random i ],...,[0],[id i ]}, where random i i is MAX(data i );
[0058] Data holders share arithmetic shared sets and accept arithmetic shared sets from other data holders;
[0059] {[0],[0],...[random i ],...,[0]+[0],[0],...,[random i ],...,
[0060] Data holder calculation [0]}*([id i ]==[id1]+...+[0],[0],...,;
[0061] [random n ],...,[0]}*([id i ]==[id n ])
[0062] The querying party decrypts the arithmetic sharing and obtains the actual content
[0063] {0,random i ,...,random j ,...,random m +random n ,...0,id}
[0064] The query side searches in reverse order for the subscript k of the first element that is not 0 except id, where k is the maximum value of the set.
[0065] Preferably, step three specifically includes:
[0066] Each participant performs a local permission check. If the permission is prohibited from being transferred, a query prohibition message is returned to the query client, and the task process is terminated.
[0067] Each participant first executes the subquery task, caches the query results in the specified format, and notifies the query client that the query is ready;
[0068] When the query client perceives that all participants have completed the sub-query task and are ready to meet to perform the multi-party secure computing task, it notifies all participants to start performing the multi-party secure computing task;
[0069] Each participant executes the protocol in sequence according to the multi-party secure computing task sequence.
[0070] Solution 2: An electronic device includes a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the steps of a multi-party data joint security query method described in Solution 1 are implemented.
[0071] Solution three: A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a multi-party data joint secure query method as described in Solution one.
[0072] The beneficial effects of the present invention are as follows: the present invention supports common database query functions and supports joint queries by any number of participants. It has excellent query efficiency in most query scenarios and big data query scenarios, and does not cause leakage of data privacy information of any participant. It solves the technical problem that the prior art cannot realize multiple common database function operations that are efficient and secure and support any number of participants. BRIEF DESCRIPTION OF THE DRAWINGS
[0073] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:
[0074] Figure 1 The present invention is a flow chart of a multi-party data joint security query method. DETAILED DESCRIPTION
[0075] In order to make the technical solutions and advantages of the embodiments of the present invention more clearly understood, the exemplary embodiments of the present invention are further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than an exhaustive list of all the embodiments. It should be noted that the embodiments of the present invention and the features in the embodiments can be combined with each other without conflict.
[0076] Example 1: Reference Figure 1 This embodiment describes a multi-party data joint secure query method, including:
[0077] Step 1: The query client receives and parses the SQL query statement entered by the user, and performs a permission check on the query statement to verify whether the SQL statement is allowed to be executed by each data holder;
[0078] Each data holder configures the security permissions for a data attribute in the table that he or she allows to be queried, that is, the configuration granularity is {database, table, column_name}. The configured permissions include: clear text transmission, encrypted transmission, and prohibited transmission. The query client will perform a permission check on the user's query statement. If a data attribute is prohibited from transmission, the client will directly reject the query request and return the query rejection information to the user.
[0079] The method for querying the client to parse the SQL query statement entered by the user is:
[0080] Use the parser to parse the user's query statement and detect the SQL keywords in the query statement, such as "SELECT", "WHERE", "JOIN", etc. Split the query statement according to the SQL keywords, and the SQL statement will be split into the query part, the connection condition part and the query condition part;
[0081] The parser checks whether the query statement is allowed to be executed according to the user permission configuration;
[0082] The parser merges the locally executed queries and extracts the query statements that do not require ciphertext calculation into plaintext query plans according to the rules;
[0083] If the query statement entered by the user contains data attributes that are prohibited from being transmitted, the query statement as a whole will not work; if all data attributes contained in the SQL query statement can be transmitted in plain text, the plain text query will be executed directly.
[0084] When the parser parses SQL keywords, it builds a query graph whose nodes are SQL keywords and query contents. If the query content is marked by the data holder as being transmitted after encrypted calculation, the connected SQL keyword nodes will be marked as requiring secure calculation. The parser generates a multi-party secure calculation plan for all keyword nodes marked as requiring secure calculation. The plaintext part will use the plaintext to build the query plan. The secure multi-party calculation plan will be built using the equi-join operation operator and the secure aggregation query operator.
[0085] Step 2: The query client generates a multi-party secure computing task for each participant according to the query statement and sends it to each participant;
[0086] Step 21: The query client checks the SQL keywords and data attributes in the statement, and generates a SQL query tree for the SQL statement based on the SQL keywords. The leaf nodes at the end of the tree are data attribute nodes, and the connection nodes of the tree are SQL keyword nodes.
[0087] Step 22: According to the generated SQL query tree, the query client marks the leaf nodes whose data attribute is "encrypted calculation and then transmitted";
[0088] Step 23: traverse the entire SQL query tree, mark all SQL keyword nodes that are connected to the marked leaf nodes, and mark all data attribute leaf nodes that are connected to the marked SQL keyword nodes;
[0089] Step 24: traverse the entire SQL query tree, generate subquery plans for SQL keyword nodes that are directly connected to leaf nodes and are not marked, and generate a multi-party secure computing plan containing subquery plans for marked SQL keyword nodes;
[0090] If the SQL keyword node keyword is a simple operation type: each data holder will directly encrypt the involved data through the arithmetic sharing protocol and execute the basic security calculation protocol;
[0091] The secure computing protocol is based on integer arithmetic sharing, floating point arithmetic sharing and binary sharing to perform private addition protocol, private multiplication protocol and private comparison protocol;
[0092] Integer arithmetic sharing: The party holding x generates a pseudo-random zeroshare for each party, and the sum of zeroshares is 0; the party that actually holds x adds x to its own zeroshare and then discards x; thus, every party shares x; for each party p∈P, p holds [x] p , we have x=∑ p∈P [x] p ;
[0093] Floating-point arithmetic sharing: Floating-point arithmetic sharing establishes a mapping between floating-point numbers and integers. For a floating-point number x R , the data holder generates a scaling factor B, x = nearest (B*x R ), that is, x is the distance B*x R The nearest integer; the data holder shares x according to the integer arithmetic sharing operation; B = 2 L , L is the corresponding bit length; if you need to decode x, x R ≈x / B;
[0094] Binary sharing: Binary sharing is a special form of arithmetic sharing; all operations under binary sharing are performed under the ring Z / 2Z; for a scalar x, its binary sharing <x>is the arithmetic sharing value of all its bits under Q = 2; for each participant p∈P, p holds <x> p ,have
[0095] Private addition protocol: Floating point arithmetic sharing and integer arithmetic sharing support addition protocol. Arithmetic sharing has the property of addition homomorphism. For [z] = [x] + [y], to calculate the arithmetic sharing of [z], for each participant p∈P, p holds [x] p , [y] p , due to the properties of arithmetic shared addition homomorphism, party p locally computes [z] p =[x] p +[y] p , [z] p That is, additive sharing;
[0096] Private multiplication protocol: Both floating-point arithmetic sharing and integer arithmetic sharing support private multiplication protocol; Beaver triples protocol is used for multiplication under arithmetic sharing. The protocol uses a trusted third party to generate a triple ([a], [b], [c]), c = a*b, and each participant calculates [a] p =[x] p -[a] p ,[β] p =[y] p -[b] p , α and β are calculated without causing information leakage using the mask form, and each participant calculates [x*y] p =[c] p +β*[b] p +α*[a] p +α*β;
[0097] Private comparison protocol: Both floating-point arithmetic sharing and integer arithmetic sharing support private comparison protocol; arithmetic sharing comparison protocol is performed by converting arithmetic sharing and binary sharing. If you want to calculate [z<0], convert arithmetic sharing [z] into binary sharing. <z>, then calculate the binary sharing <z>The flag bit = <z>>>(L - 1), and then convert the binary sharing b> into arithmetic sharing [b], [b] is the arithmetic sharing result of [z<0]. If you want to calculate [x<y], then transform the problem into z] = [x] - [y], [z<0].
[0098] If the SQL keyword node keyword is "EQUAL JOIN", that is, an equi-join operation: each relevant data holder executes a multi-party secure equi-join algorithm;
[0099] The equi-join is based on the private set intersection protocol of the OPPRF protocol. The OPPRF protocol means that for two parties a and b, if b holds a certain element in a, then b can obtain a value specified by a, otherwise it can only obtain a random number. The OPPRF protocol can be implemented through the OPRF protocol. OPRF is a two-party protocol, where one party (the sender) holds the key k of a pseudo-random function (PRF), and the other party (the receiver) holds an input x. The goal of the protocol is for the receiver to obtain the output f(k, x) of the PRF on k and x, while the sender does not obtain any information. The OPPRF protocol satisfies that for (x, y) belonging to P, F(k, hint, x) = y must hold. Therefore, each data holder generates zero-knowledge sharing pairs for the data {x1, x2,... xn} it holds and constructs them into P. Each data holder will call the OPPRF protocol to other holders. Only when it holds the same data as other data holders, will it obtain zero sharing, otherwise it will obtain a random value. Each relevant data holder executes a multi-party secure equi-join algorithm, which is further manifested as:
[0100] Execute a conditional secret sharing protocol among data holders:
[0101] Each data holder performs a local query based on the query plan to obtain a data set;
[0102] Each data holder executes a zero-sharing generation protocol for each data to generate zero sharing for other data holders;
[0103] Other data holders initiate inquiries to the data holder for each of their own data through the OPPRF protocol;
[0104] If the data held by the data holder is the same as that of other data holders, other data holders hold the zero sharing generated by the data holder, otherwise they hold a random value;
[0105] Execute a conditional secret sharing decryption protocol among data holders:
[0106] Each data holder queries other data holders for data through the OPPRF protocol to determine whether the data it holds exists in the intersection of other data holders’ data;
[0107] If other data holders hold the same data as the data holder, they return the zero share generated by the data holder through the OPPRF protocol, otherwise they hold a random value;
[0108] The data holder's query response to other data holders for the same data is through the OPPRF protocol. If other data holders have the same data as the data holder, zero sharing is returned to the data holder, otherwise a random number is returned;
[0109] The data holder verifies the query result and accumulates all query results. When the accumulated result is 0, it means that other data holders have returned zero shared values for this query, that is, the data held by the data holder exists in the intersection of other data holders; when the accumulated result is other, it means that at least one data holder has returned a random number for this query, that is, the data held by the data holder does not exist in the intersection of other data holders.
[0110] If the SQL keyword node keyword is the sum group sum keyword, the relevant data holders perform a privacy-safe group sum operation;
[0111] Privacy-safe group sum operation:
[0112] The data holder executes a local query and generates a query view (sum(data i ),id i ), where id i It is the base attribute for grouping operation;
[0113] The data holder shares the query view through the arithmetic sharing protocol;
[0114] Data holders receive the arithmetic share (sum (data j ),id j );
[0115] Data holder calculation
[0116] [sum(data i )]+[id1]==[id i ]*[sum(data1)]+...+([id n ]==[id i ])*[sum(data n )];
[0117] The querying party decrypts and removes duplicates from the protocol calculation results;
[0118] If the SQL keyword node keyword is COUNT, the data quantity is calculated by grouping: each relevant data holder executes the privacy-safe count operator;
[0119] Privacy-safe count operator:
[0120] The data holder executes a local query and generates a query view (count(*), id i );
[0121] The data holder shares the query view through the arithmetic sharing protocol;
[0122] Data holders receive arithmetic shares from other data holders (count(*), id j );
[0123] The data holder calculates [count(*)]+[id1]==[id i ]*[count(*)]+...+([id n ]==[id i ])*[count(*)];
[0124] The querying party decrypts and removes duplicates from the protocol calculation results;
[0125] If the SQL keyword node keyword is MIN / MAX, the aggregation maximum value operator, each related data holder executes the safe aggregation maximum value algorithm of the traversable attribute;
[0126] Security aggregation maximum value algorithm:
[0127] The data holder executes a local query and generates a query view (MAX(data i ),id i );
[0128] The data holder constructs the arithmetic shared set s i ={[0],[0],...[random i ],...,[0],[id i ]}, where random i i is MAX(data i );
[0129] Data holders share arithmetic shared sets and accept arithmetic shared sets from other data holders;
[0130] Data holder calculation
[0131] The querying party decrypts the arithmetic sharing and obtains the actual content
[0132] {0,random i ,...,random j ,...,random m +random n ,...0,id}
[0133] The querying party searches in reverse order for the first non-zero element subscript k, except for id, where k is the maximum value of the set;
[0134] Step 3: Each participant performs permission check locally and executes the subquery part and multi-party secure computing tasks;
[0135] Each participant performs a local permission check. If the permission is prohibited from being transferred, a query prohibition message is returned to the query client, and the task process is terminated.
[0136] Each participant first executes the subquery task, caches the query results in the specified format, and notifies the query client that the query is ready;
[0137] When the query client perceives that all participants have completed the sub-query task and are ready to meet to perform the multi-party secure computing task, it notifies all participants to start performing the multi-party secure computing task;
[0138] Each participant executes the protocol in order according to the multi-party secure computing task sequence;
[0139] Step 4: Obtain the execution results of each participant, query the client to schedule each participant to execute the multi-party secure computing task;
[0140] For some multi-party secure computing protocols that require a trusted third party, the query client acts as a trusted third party during the protocol runtime and obtains query results from it. For multi-party secure computing protocols that do not require a trusted third party, the query client obtains query results directly from the participants.
[0141] This embodiment can be applied to hospitals and video companies; hospitals store certain private information of patients, which should not be leaked. In order to conduct a health survey on people in a certain area, the present invention can conduct a secure joint query on the patient information in the area without leaking the patient's private information. The data privacy information of each hospital is not leaked to other hospitals, and the querying party can only learn the minimum set of information that can meet the query conditions.
[0142] Video application companies store users' video viewing information, including browsing interests, video viewing time, etc., which should not be leaked to the companies. The present invention can perform a secure joint query on various video application customer information without leaking user privacy information. The user data of each video application company will not be leaked to other video application companies, and the querying party can only learn the minimum set information that can meet the query conditions.
[0143] Embodiment 2: The computer device of the present invention may be a device including a processor and a memory, such as a single chip microcomputer including a central processing unit, etc. Moreover, the processor is used to implement the steps of the above-mentioned method for three-dimensional visualization processing of pipe network data when executing the computer program stored in the memory.
[0144] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.
[0145] The memory may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.
[0146] Embodiment 3, computer readable storage medium embodiment.
[0147] The computer-readable storage medium of the present invention can be any form of storage medium that can be read by the processor of a computer device, including but not limited to non-volatile memory, volatile memory, ferroelectric memory, etc. A computer program is stored on the computer-readable storage medium. When the processor of the computer device reads and executes the computer program stored in the memory, the steps of the above-mentioned method for predicting traffic congestion status can be implemented.
[0148] The computer program includes computer program code, which may be in source code form, object code form, executable file or some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer readable media do not include electric carrier signals and telecommunication signals.
[0149] Although the present invention has been described according to a limited number of embodiments, it will be apparent to those skilled in the art, with the benefit of the above description, that other embodiments may be envisioned within the scope of the invention thus described. In addition, it should be noted that the language used in this specification is selected primarily for readability and teaching purposes, rather than for explaining or defining the subject matter of the present invention. Therefore, many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the appended claims. The disclosure of the present invention is illustrative, not restrictive, with respect to the scope of the present invention, which is defined by the appended claims.< / z> < / z> < / z> < / x> < / x> < / z> < / z> < / z>
Claims
1. A multi-party data joint security query method, characterized in that: include: Step 1: The query client receives and parses the SQL query statement entered by the user, and performs a permission check on the query statement to verify whether the SQL statement is allowed to be executed by each data holder; Step 2: The query client generates a multi-party secure computing task for each participant according to the query statement and sends it to each participant; Step 3: Each participant performs permission check locally and executes the subquery part and multi-party secure computing tasks; Step 4: Obtain the execution results of each participant, and query the client to schedule each participant to execute the multi-party secure computing task.
2. A multi-party data joint security query method according to claim 1, characterized in that: The method for querying the client to parse the SQL query statement entered by the user is: Use the parser to parse the user's query statement, detect the SQL keywords in the query statement, and split the query statement according to the SQL keywords. The SQL statement will be split into the query part, the connection condition part and the query condition part; The parser checks whether the query statement is allowed to be executed according to the user's permission configuration. The permission configuration includes: can be transmitted in plain text, can be transmitted after encryption calculation, and cannot be transmitted; The parser merges the locally executed queries and extracts the query statements that do not require ciphertext calculation into plaintext query plans according to the rules; If the query statement entered by the user contains data attributes that are prohibited from being transmitted, the query statement as a whole will not work; if all data attributes contained in the SQL query statement can be transmitted in plain text, the plain text query will be executed directly.
3. A multi-party data joint security query method according to claim 1, characterized in that: Step 2 specifically includes the following steps: Step 21: The query client checks the SQL keywords and data attributes in the statement, and generates a SQL query tree for the SQL statement based on the SQL keywords. The leaf nodes at the end of the tree are data attribute nodes, and the connection nodes of the tree are SQL keyword nodes. Step 22: According to the generated SQL query tree, the query client marks the leaf nodes whose data attribute is "encrypted calculation and then transmitted"; Step 23: traverse the entire SQL query tree, mark all SQL keyword nodes that are connected to the marked leaf nodes, and mark all data attribute leaf nodes that are connected to the marked SQL keyword nodes; Step 24: traverse the entire SQL query tree, generate subquery plans for SQL keyword nodes that are directly connected to leaf nodes and are not marked, and generate a multi-party secure computing plan containing subquery plans for marked SQL keyword nodes.
4. A multi-party data joint secure query method according to claim 3, characterized in that: Step 24 is specifically: If the SQL keyword node keyword is a simple operation type: each data holder will directly encrypt the involved data through the arithmetic sharing protocol and execute the basic security calculation protocol; If the SQL keyword node keyword is EQUAL JOIN, that is, an equi-join operation: the relevant data holders execute the multi-participant secure equi-join algorithm; If the SQL keyword node keyword is the sum group sum keyword, the relevant data holders perform a privacy-safe group sum operation; If the SQL keyword node keyword is COUNT, the data quantity is calculated by grouping: each relevant data holder executes the privacy-safe count operator; When the keyword of the SQL keyword node is MIN / MAX, the relevant data holders execute the secure aggregation maximum / minimum algorithm for traversable attributes.
5. A multi-party data joint secure query method according to claim 4, characterized in that: The secure computing protocol is based on integer arithmetic sharing, floating-point arithmetic sharing, and binary sharing for private addition protocol, private multiplication protocol, and private comparison protocol; Private addition protocol: Floating point arithmetic sharing and integer arithmetic sharing support addition protocol. Arithmetic sharing has the property of addition homomorphism. For [z] = [x] + [y], to calculate the arithmetic sharing of [z], for each participant p∈P, p holds [x] p , [y] p , due to the properties of arithmetic shared addition homomorphism, party p locally computes [z] p =[x] p +[y] p , [z] p That is, additive sharing; Private multiplication protocol: Both floating-point arithmetic sharing and integer arithmetic sharing support private multiplication protocol; the Beavertriples protocol is used for multiplication under arithmetic sharing. The protocol uses a trusted third party to generate a triple ([a], [b], [c]), c = a*b, and each participant calculates [a] p =[x] p -[a] p , [β] p =[y] p -[b] p , α and β are calculated without causing information leakage using the mask form, and each participant calculates [x*y] p =[c] p +β*[b] p +α*[a] p +α*β; Private comparison protocol: Both floating-point arithmetic sharing and integer arithmetic sharing support private comparison protocol; arithmetic sharing comparison protocol is performed by converting arithmetic sharing and binary sharing. If you want to calculate [z<0], convert arithmetic sharing [z] into binary sharing. <z>, then calculate the binary sharing <z>The flag bit = <z>>>(L - 1), and then convert the binary sharing (b) to arithmetic sharing [b], [b] is the arithmetic sharing result of [z < 0]. If you want to calculate [x < y], then convert the problem to [z] = [x] - [y], [z < 0]. < / z> < / z> < / z> 6. A multi-party data joint security query method according to claim 4, characterized in that: Secure equijoin algorithm, specifically: Execute the conditional secret sharing protocol among the data holders: Each data holder performs a local query based on the query plan to obtain a data set; Each data holder executes the zero-sharing generation protocol for each data to generate zero-sharing for other data holders; Other data holders initiate queries to the data holder for each of their own data through the OPPRF protocol; If the data held by the data holder and other data holders is the same, other data holders hold the zero-sharing generated by the data holder, otherwise they hold random values; Execute the conditional secret sharing decryption protocol among the data holders: Each data holder queries other data holders through the OPPRF protocol to determine whether the data it holds exists in the intersection of the data of other data holders; If other data holders hold the same data as the data holder, they return the zero-sharing generated by the data holder through the OPPRF protocol, otherwise they hold random values; The response result of the data holder's inquiry to other data holders for the same data is through the OPPRF protocol. If other data holders contain the same data as the data holder, they return the data holder's zero-sharing, otherwise they return random numbers; The data holder verifies the inquiry result and accumulates all the query results. When the accumulated result is 0, it means that other data holders have returned zero-sharing values for this inquiry, that is, the data held by the data holder exists in the intersection of other data holders; when the accumulated result is other, it means that at least one data holder has returned a random number for this inquiry, that is, the data held by the data holder does not exist in the intersection of other data holders.
7. A multi-party data joint secure query method according to claim 4, characterized in that: Privacy-secure grouped summation operation, specifically: The data holder executes a local query and generates a query view (sum(data i ),id i ), where id i It is the base attribute for grouping operation; The data holder shares the query view through the arithmetic sharing protocol; Data holders receive the arithmetic share (sum (data j ),id j ); The data holder calculates [sum(data i )]+[id1]==[id i ]*[sum(data1)]+...+([id n ]==[id i ])*[sum(data n )]; The query party decrypts and deduplicates the protocol calculation result; Privacy-secure count operator is specifically: The data holder executes a local query and generates a query view (count(*), id i ); The data holder shares the query view through the arithmetic sharing protocol; Data holders receive arithmetic shares from other data holders (count(*), id j ); The data holder calculates [count(*)]+[id1]==[id i ]*[count(*)]+...+([id n ]==[id i ])*[count(*)]; The query party decrypts and deduplicates the protocol calculation result; Secure aggregation maximum / minimum algorithm: The data holder executes a local query and generates a query view (MAX(data i ),id i ); The data holder constructs the arithmetic shared set s i ={[0],[0],...[random i ],...,[0],[id i ]}, where random i i is MAX(data i ); The data holder shares the arithmetic sharing set and accepts the arithmetic sharing sets of other data holders; {[0],[0],...[random i ],...,[0]+[0],[0],...,[random i , Data holder calculation [0]}*([id i ]==[id1]+...+[0],[0],...,; [random n ],...,[0]}*([id i ]==[id n ]) The querying party decrypts the arithmetic sharing and obtains the actual content {0,random i ,...,random j ,...,random m +random n ,...0,id} The query party reversely searches for the subscript k of the first non-zero element except id, and k is the set maximum result.
8. A multi-party data joint secure query method according to claim 1, characterized in that: Step three is specifically: Each participant performs a permission check locally. If the permission is prohibited from passing, it returns prohibited query information to the query client and the task process terminates; Each participant first executes the subquery task, caches the query results in the specified format, and notifies the query client that the query is ready; When the query client perceives that all participants have completed the sub-query task and are ready to meet to perform the multi-party secure computing task, it notifies all participants to start performing the multi-party secure computing task; Each participant executes the protocol in sequence according to the multi-party secure computing task sequence.
9. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of a multi-party data joint security query method as described in any one of claims 1 to 8 when executing the computer program.
10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor, the method for joint secure query of multi-party data as described in any one of claims 1 to 8 is implemented.
