[ieee 22nd international conference on data engineering (icde'06) - atlanta, ga, usa...

Privacy Preserving Query Processing usingThird Parties

Fatih Emekci Divyakant Agrawal Amr El Abbadi Aziz GulbedenDepartment of Computer Science

University of California Santa BarbaraSanta Barbara, CA 93106, USA

fatih,agrawal,amr,gulbeden @cs.ucsb.edu

Abstract

Data integration from multiple autonomous data sourceshas emerged as an important practical problem. The key re-quirement for such data integration is that owners of suchdata need to cooperate in a competitive landscape in mostof the cases. The research challenge in developing a queryprocessing solution is that the answers to the queries needto be provided while preserving the privacy of the datasources. In general, allowing unrestricted read access tothe whole data may give rise to potential vulnerabilities aswell as may have legal implications. Therefore, there is aneed for privacy preserving database operations for query-ing data residing at different parties. In this paper, we pro-pose a new query processing technique using third parties ina peer-to-peer system. We propose and evaluate two differ-ent protocols for various database operations. Our schemeis able to answer queries without revealing any useful infor-mation to the data sources or to the third parties. Analyticalcomparison of the proposed approach with other recent pro-posals for privacy-preserving data integration establishesthe superiority of the proposed approach in terms of queryresponse times.

1 Introduction

With the ubiquitous availability of the Internet and allthe resources it provides, data integration has emerged asan important practical problem especially from a data man-agement point of view [11, 14]. Techniques used for thispurpose commonly assume that the data sources are willingto allow access to all their data without privacy concernsduring query processing. In real life, however, owners donot want to share all their data due to various reasons suchas competition among data owners or possible legal impli-cations requiring confidentiality of the data. For example,

This research was funded in parts by NSF grants IIS IIS 02-23022,and CNF-04-23336.

consider a community of medical professionals that needto share data without violating the privacy of either the pa-tients or the organizations. One possible collaboration insuch an environment is that a medical professional’s officemight be interested in all test results of its patients. The re-sults might be in some other medical facilities. For such aquery, the involved parties are only interested in finding thetest results of patients in the intersection of the different of-fices and nothing else. In fact, offices might not be allowedto share information about patients that are not in the in-tersection. Similarly, consider another type of data sharingwhere medical professionals want to classify the patientsaccording to their total number of visits to all the medicalprofessionals but do not want to violate patients’ or medi-cal offices’ privacy requirements (i.e., parties do not wantto reveal themselves or the total number of visits a patientmade to their office). As these examples illustrate, there isan increasing need for privacy preserving database opera-tions for these kinds of queries. Privacy preservation meansthat the data owner wants to restrict the extra information itprovides to other parties. In other words, data owners areonly willing to share the minimum information required forprocessing queries correctly.

The goal of privacy preserving query processing is to ex-ecute queries over multiple data sources without revealingany extra information to any of the involved data sources.At the end of the query processing, they will only acquirethe query result. For example, if the query is asking for theintersection of lists residing at different data sources, afterquery processing, the data owners will only know the queryresult (eg., the intersection of the lists but no informationabout the elements that are not in the intersection). In orderto prevent such privacy violations, any privacy preservingtechnique should provide a method to execute several cru-cial operations, in particular intersection, join and aggrega-tion which are all fundamental for general purpose queryprocessing.

Proceedings of the 22nd International Conference on Data Engineering (ICDE’06) 8-7695-2570-9/06 $20.00 © 2006 IEEE

Several techniques have been proposed to preserve theprivacy of data sources in the areas of databases and cryp-tography. In the trusted third parties approach, the dataowners hand over their data to a trusted third party andthe third party computes the results of the queries [1, 22].This level of trust is unacceptable for privacy preservingquery processing. Secure multi-party computation is an-other technique, where, given parties and their respectiveinputs , a function is com-puted such that all parties can only learnbut nothing else [17, 18, 23]. The computation and the com-munication complexity of this method makes it impracticalfor database operations working over a large number of ele-ments. For example, the communication needed to computethe intersection of two lists of size million takes around

days with this method [4]. Due to the extreme costof computation and communication, Agrawal et al. [4] pro-posed a minimal information sharing paradigm to performintersection and join operations. Their proposed solutionis based on using encryption/decryption without the needfor third parties. However, this technique has two short-comings: (1) Since encryption/decryption are costly oper-ations in terms of computation, the query response time isvery high (in fact, for some real world applications, this ap-proach may require as much as hours of computation);(2) It cannot be used to aggregate data residing at differentsites (i.e., it does not support aggregation queries).

Due to the high overhead of cryptographic operations,and in general, the large number of elements that need to beaccessed in database operations, cryptography-based tech-niques are impractical for query processing in a real envi-ronment. Therefore, we propose a new computationally ef-ficient approach that uses third parties to solve this problem.Our scheme does not reveal any extra useful information toany of the third parties used in the computation, nor do thedata sources get extra information regarding the other par-ties’ data.

In this paper, we use a hash based P2P system to selectthird parties that perform the computations required for pro-cessing privacy preserving queries. P2P systems are partic-ularly suitable for this task due to their self organizing andscalable structure. Furthermore, we exploit the fact that itis possible to perform anonymous communication in a P2Psystem using the overlay network. Combining these proper-ties, we propose a query processing technique over peer-to-peer systems to speed up query response time while preserv-ing the privacy of the data owners. We use P2P systems notas a data store, which has been the focus of most of the P2Psystems. Instead, we employ a P2P system for anonymouscommunication and computation. Analytical comparisonof the proposed method with existing methods shows thatour method is able to answer queries with a much lower re-sponse time, which in turn makes privacy preserving query

processing practical for real life applications.The rest of the paper is organized as follows. In Sec-

tion 2 we provide some background information. Section 3formulates the problem. Section 4 describes query process-ing in an honest-but-curious environment. The analysis ispresented in Section 5. The paper concludes with a discus-sion of future work.2 Background

In this section we first present some of the related workin privacy. Then we introduce Shamir’s secret sharingmethod [26] that will be used for sharing a secret with thirdparties securely.

2.1 Related Privacy Work

Naor et al. [24] proposed a scheme to process intersec-tion queries using oblivious transfer and polynomial evalu-ation based on cryptographic techniques. The scheme en-sures that data sources will only know the intersection butnothing else. Although this scheme can answer intersectionqueries involving two data sources the communication costrequired by this technique is where is the size ofthe databases. Therefore, it is impractical to apply in largedatabases. Hacigumus et al. [19], Hore et al. [20] and Ag-garwal et al. [2] propose using third parties as database ser-vice providers without the need for expensive cryptographicoperations. However the proposed schemes do not allowqueries to execute over the data of multiple providers, whichis the main focus of our work. Aggarwal et al. [3] show thechallenges in finding the th element in the union of morethan two databases while preserving privacy and propose anapproximate solution. In addition, several high level designefforts and requirement specifications have been made tosupport the privacy of individual information while still sup-porting some degree of sharing [1, 5, 6, 7, 10, 27, 28, 12].

Although related, our work is orthogonal or complemen-tary to privacy preserving data management in data miningand information retrieval. In data mining, several effortshave been made to either preserve the privacy of individu-als using randomized techniques [8, 9, 16, 25] or to preservethe privacy of the database while running data mining algo-rithms over multiple databases [13, 21] using cryptographictechniques such as secure multi-party computation and en-cryption.

2.2 Shamir’s Secret Sharing

Shamir’s secret sharing method [26] allows a dealerto distribute a secret value among peers

, such that knowledge of any ( )peers is required to reconstruct the secret. Since, even com-plete knowledge of peers cannot reveal any informa-tion about the secret, Shamir’s method is information the-oretically secure. Dealer chooses a random polynomial


of degree where the constant term is the secretvalue, , and a publicly known set of random points. Thedealer computes the share of each peer as and sends itto peer . The method is summarized in Algorithm 1.

Algorithm 1 Shamir’s Secret Sharing Algorithm1: Input:2: : Secret value;3: : Dealer of secret ;4: : set of peers to distribute secret;5: Output:6: : Shares of secret, , for each peer ;7: Procedure:8: creates a random polynomial with

degree and a constant term .9: chooses publicly known random points, , such that .

10: computes share, , of each peer, , where .

In order to construct the secret value , any set ofpeers will need to share the information they have re-

ceived. After finding the polynomial , the secret valuecan be reconstructed. can be found us-

ing Lagrange interpolation such that where. The key observation is that at least points and

shares are required in order to determine a unique polyno-mial of degree .

3 Problem FormulationThe problem of query processing across multiple private

databases is defined as follows:Let , , ..., be the databases of a set ofdata source peers , and be aquery spanning through . The problem isto compute the answer of without revealing anyadditional information to any of the data sourcepeers.

Intersection, join and aggregation operations are particu-larly challenging from a privacy preserving query process-ing point of view since to perform these operations, all ofthe data residing at different sites may need to be accessedto compute an answer. Therefore, we focus on these opera-tions.

Agrawal et al. [4] solved the intersection and equijoinproblem by restricting them to two data sources with somerelaxation in an honest-but-curious [17] environment. Therelaxation reveals the sizes of the tables or lists in thedatabases to the other party. The method is based on an en-cryption/decryption protocol, which requires an extensiveamount of computation, and cannot be used for more thantwo data sources.

To reduce the high computational cost due to encryption/decryption, and to speed up the query processing time, wepropose a solution in an honest-but-curious environment forintersection, equijoin and aggregation queries. Our solu-tion is similar to [15] which solves some of these problems(i.e., only sum and average query processing) over onlydatawarehouses and reveals more information about the un-derlying datawarehouse. In our scheme, we use third parties

located in a peer-to-peer system, namely Chord [29]. Al-though we use Chord in our system for the selection of thethird parties, our method can be adapted to any structuredpeer-to-peer system.

Similar to [4], we do not aim to solve the problem ofrevealing additional information to a peer which poses mul-tiple queries and combines their results in order to obtaininformation about the data. In addition, we do not solve theproblem of data discovery and schema mediation. Solutionsto these problems are discussed briefly in [4].

4 Query Processing in an Honest-but-curiousEnvironment

In this section, we introduce our query processing tech-nique and explain how it works in an honest-but-curiousenvironment. An honest-but-curious environment is onewhere the parties involved in a query follow the given pro-tocol; additionally they may keep any result or informationthey obtain during the course of the protocol. This settingis also known as semi-honest environment in the literature.In our scheme, queries are answered in a privacy preservingmanner using third parties. At the end of query processing,no additional useful information is revealed to any partiesinvolved in query processing but only the query answer isrevealed to the query posers.

One possible approach towards solving this problem isto use a one-way cryptographic hash function such as SHAor MD to find the intersection of two lists. In this scheme,data sources hash the secret values in their respective listsand send the hashed lists to a third party. Then, the thirdparty compares these hashed lists and sends the intersectionof two hashed lists to each of the data sources so that theycan figure out the intersection. Since the hash function isone-way and if the third party is not curious, the third partycannot learn the content of the lists from the hashed list andthe data sources cannot learn anything other than the inter-section. However, in practice, the number of one-way hashfunctions are limited, a curious third party may try all ofthem to extract the content of the hashed lists. Basically,the third party can check whether an element exists in theincoming hashed list or not, and thus, it might exhaustivelytry the entire domain to find out the data of the data source(Dictionary attack) if the domain size is small. Even if thethird party is not curious, only the equality check could bedone by the third party using this approach. Therefore, thissolution is inadequate to support aggregation queries (e.g.sum of values of specific keys without revealing values).

4.1 Intersection Queries

The intersection query processing problem is stated asfollows:


��

��

��

��

��

��

��

��

��

��

��

��

��

Figure 1. Basic scheme.Let , ,..., be the lists containing se-cret data stored by a set of data sources

respectively and a queryis posed by . Let

be a set of third parties. Theproblem is to obtain the answer to with the helpof the third parties in without revealing any ad-ditional information to any of the third parties inthe set , and by only providing the query resultto the providers in the set .

Our query processing technique consists of three phases:(1) Distribution phase; (2) Computation at the third parties;and (3) Final computation at the peers.

4.1.1 Distribution Phase

Basic Scheme: After peer poses the intersection query,decides on a random polynomial of degree , ,

and chooses random values (onefor each third party). Then sends and to theother data sources. Each data source has a list of se-cret elements, ; creates shares

, ... , one for each of the thirdparties through respectively. creates the sharesby applying Shamir’s secret sharing algorithm to each of theelements in . For every element in , computesthe share of third party , , using Algorithm 1with and (the constant term in will be replacedby the secret value, , to compute in Shamir’s secretsharing). Therefore, the list of shares of third party from

is .Then sends to the third party peer ,which is determined by hashing the value onto theChord ring. We call this phase the Distribution Phase. Af-ter this phase, the peers determine the intersection of thesets they received and send the results back as described inthe next section.

We illustrate the basic scheme of the distribution phaseusing an example of two data sources and (see Fig-ure 1). Each data source has a list of secrets. The datasources agree on the polynomial and on X values

4, 20 in order to distribute their shares to two third par-ties. For the first element with value in Peer ’s secretlist, it computes the share corresponding to this element tosend to (i.e. ) as follows:

The computation is performed similarly for all the se-crets using the different values corresponding to thepeers. The resulting shares are shown in Figure 1, whichare then sent to the third parties.

Improved Scheme: Although the basic distribution schemeis correct, it has two shortcomings. (1) If the same poly-nomial is applied on all of the elements in the list, for acurious peer that receives the data, this is equivalent to re-ceiving a list where every element in the list is incrementedby the same constant. For example, in Figure 1 the lists re-ceived by from the different peers are basically the orig-inal lists incremented by the constant . Consequently, thepeer may be able to guess that particular value depending onthe data semantics. If the third party can find out the min-imum or the maximum data value in the original list it canrecover the whole list in its original form. Furthermore, wehave to make sure that the same polynomial is applied onthe same elements residing at different parties so that theyare mapped to the same value. (2) The second shortcomingis that the third party peers used for computation are de-termined by hashing the values onto the Chord ring. Thehost choosing the set may try to influence the randomnessin the selection of these values in order to ensure that someparticular collaborating peers in Chord get the queries.

To solve the first problem, instead of choosing one poly-nomial with fixed coefficients, the peers agree on hashfunctions ,..., , which are used to determine differ-ent coefficients for the polynomial used to hide an element

in a list. The polynomial for element is constructed asfollows:

This modification in the calculation ensures that the samepolynomial is applied on the same elements residing at dif-ferent data sources, at the same time different polynomialsare applied to the different elements of the lists.

In order to address the second problem we should makesure that the data sources collectively create the same se-quence of values, while preventing them from cheatingby generating IDs that map to particular peers in the Chordring. To achieve this, every data source involved in thequery generates a vector consisting of random numbers.The final values of the values are obtained by adding upthese vectors and hashing them through a one way hashfunction. As a result, all the data sources obtain the samerandom vector and none of them can influence the result toselect particular peers from the Chord ring.


Algorithm 2 Distribution Phase1: Input:2: : Random Values ;3: : hash functions to be used in constructing the polynomial,

;4: : Secret list at data source ;5: Output:6: : Shares of secret list, , for each peer

;7: Procedure:8: for Each secret value do9: Find share of each peer for with Algorithm 1 using

where and addinto .

10: end for11: Locate on the Chord ring by hashing on to the

ring and send each to directly.

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

Figure 2. Illustration of distribution phaseThe resulting algorithm for the distribution phase is sum-

marized in Algorithm 2 and an example is illustrated inFigure 2 for two data sources and with two lists

and . To computeusing three third parties namely , and , and

decide on three hash functions, ,, . Also three values

are determined in order to randomly select peers from theChord ring. chooses the random vector [ ] andchooses the random vector [ ]; both peers add thesevalues up and produce the values .

The of for value that has,,is computed as follows:

does the same computation for the other secret valuesfor all the other third parties and sends the list 1575, 4053,5292 to , 184823, 513989, 678572 to , and 696,

1728, 2244 to . Similarly computes and sends thelist 4053, 5292, 5705 to 513989, 678572, 733433to , and 1728, 2244, 2416 to .

4.1.2 Computation Phase

After receiving their shares from the data sources,, every third party, , calculates bitmaps,,..., , corresponding to the lists

,..., respectively. Thesebitmaps are used to indicate which elements of a list arepresent in the intersection. traverses the lists that itreceived and if the th element of is foundin all of the lists, then the corresponding entry in thebitmap, , is set to . Formally,

if s.t.otherwise

Then sends these bitmaps to the corresponding datasources, i.e., is sent to . This phase is calledthe computation in the third parties and the computation in

is shown in Algorithm 3 and illustrated in Figure 3 forthe example scenario of Figure 2.

Algorithm 3 Computation in the third parties1: Input:2: : Set of share lists,

;3: Output:4: Set of bitmaps to send back to the data sources

respectively;5: Procedure:6: for each list do7: for ; do8: if then9:

10: end if11: end for12: end for13: Send to respectively

��

��

��

��

�

��

��

��

Figure 3. Illustration of computation in thirdparty phase

In Figure 3, after receiving the lists, discovers theidentical values, (e.g. and are shared but the firstvalue is not), and sends bitmap 0, 1, 1 to , andthe bitmap 1, 1, 0 to .

The time complexity of this algorithm is linearwith the size of the longest share received, i.e.

after sorting. However,for brevity we did not state that in Algorithm 3.


4.1.3 Final Computation Phase

After receiving the bitmaps from all the third parties, eachdata source determines which elements in its list arepresent in the result of the intersection query. Formally ifthe th element of all bitmaps coming from third parties isset to then, the corresponding element at entry in the listis added to the answer set. Each peer performs this com-putation with its list using the bitmaps to find the answer tothe query. This phase of final computation and processingin data source is summarized in Algorithm 4.

Algorithm 4 Final Computation1: Input:2: : List of data source3: : Set of bitmaps coming from the third parties such that is a bitmap

coming from peer , .4: Output:5: : Intersection of lists involved in the query.6: Procedure:7: for ; ; do8: if for all then9: add to

10: end if11: end for12: return

In order to decide whether an element is in the intersec-tion or not, all the bitmaps coming from all third party peersmust be for that element. This follows from Shamir’s se-cret sharing method and can be stated as:

Lemma 1 Given a polynomial of degree , a set ofrandom points , secrets , and shares forthird parties computed by Algorithm 2 for each of secret

values. if the shares coming fromare equal at all the third parties.

For the example in Figure 2, will receive the bitmap0, 1, 1 and will receive the bitmap 0, 1, 1, 0 from

all the third parties. Consequently peers and are ableto determine the result of the intersection query, which is

.

4.2 Equijoin

The equijoin query processing problem is defined as fol-lows:

Assume has a table and has a tableeach of which has a specific attribute . Then, thegoal is to compute such that both partiesdo not learn any extra information other than thequery result. Query poser will learn only thetuples such that for which .In other words, shares a list, , of tuples infor each value with if suchthat , and nothing else.

We also propose to solve the equijoin query processingproblem using third parties that are chosen from the P2Psystem. We describe and solve the problem for two peers,but the scheme can be generalized to peers in the sameway the intersection query is performed. At the end of queryprocessing, third parties will not be revealed any extra use-ful information. Both the peers, and , are only pro-vided with the answer to the query.

After peer poses a query, , to ,and decide on hash functions to generate a polyno-mial of degree for each element in the table; they alsoagree on random values as describedin Section 4.1.1. Initially constructs a list fromconsisting of every element in . Similarly, con-structs a list from . During the first phase and

find the intersection using the technique de-scribed in Section 4.1; then sends all tuples where

to . Therefore, our technique consists oftwo phases (1) Intersection phase and (2) Join computationphase. In the intersection phase and compute theintersection set of their values and after that sends alltuples which join with tuples in during the join compu-tation phase.

During the course of the query processing, no extra use-ful information gets revealed. First and compute theintersection of the two lists. In the join computation phase,

only sends information about the intersection of lists. Asa result, nobody gains extra useful information.

It can be argued that can cheat by sending incorrectvalues after the intersection is determined, however we donot target to overcome this problem since has completecontrol over its own data, and it can change the data as itwishes before or during query processing.

4.3 Aggregation

The traditional aggregation operation is usually used tofind the aggregate of a list of values such as SUM, AVER-AGE or MIN/ MAX. Therefore, one kind of privacy pre-serving aggregation can be thought of as computing the ag-gregate of values in the union of lists coming from differentdata sources such that data sources will only know the fi-nal aggregate but nothing else. To answer traditional aggre-gation queries, each data source can compute its local ag-gregate and the final aggregate can be computed such thatnone of the data sources will know the local aggregate ofeach other but the final aggregate value (Secure multipatrycomputation [17] or the technique described in this sectioncan be used to compute the final aggregate value). However,data sources may not be willing to execute aggregation op-erations over their whole data. For example, a companymay not be willing to share the expenditure of a customerif he/she is not a customer of the other companies involved


in the query. Similarly, consider a scenario where doctorswant to collaborate to classify their patients according tothe number of total visits per year, therefore they share thenumber of visits for a specific patient with another doctorif that patient is also in his/her database without revealingtheir identities. The traditional aggregation operation is notstrong enough to support these needs. Therefore, we definea new type of aggregation operation and develop a corre-sponding privacy preserving aggregation query processingmethod.

The privacy preserving aggregation query processingproblem is defined as follows:

Let , ,..., be the tables stored by a set ofsource peers ( ) re-spectively containing a key and a value field. Thepeers would like to learn the aggregation of thevalues in their databases that have the same key.Let be a set of third par-ties. Then the problem is to obtain the answerto the query with the help of the third parties in

without revealing any additional information tothe third party peers in the set , and by only pro-viding the aggregation result to the source peersin the set .

For example, suppose three peers, and , areinvolved in an aggregation SUM query. If and havevalues and for a particular key but does not havean entry for , then at the end of the query processing,and will learn that sum for is but they will notknow that the key is present in only two of the databases.

, on the other hand, will not learn anything at the end ofthe query processing. Similar to the protocols presented inthe previous sections, the third parties will also not be ableto derive any useful information, such as , , or ,from the messages exchanged during query processing.

This type of aggregation queries is specific to the privacypreserving query domain, and has not been proposed beforeto the best of our knowledge. It is impossible to executethis type of query with traditional cryptographic solutionssuch as secure multi-party computation without relaxing theprivacy requirements. Cryptographic techniques need to al-low data sources to know which of the data sources have aspecific Key, so that they could compute the aggregation us-ing secure multi-party computation for that Key. Even withthis relaxation, it is impractical to apply this technique overlarge tables.

Our solution, although privacy preserving does revealmore information if a specific exists in only one of thedata sources, , then would know it is the only owner of

(the problem definition implicitly states that none ofthe data sources would know how many of the data sourceshave a specific key). If exits only in andthe domain of is the nonnegative numbers, then the

sum for will be so that will know it is theonly owner of . The main observation behind our ag-gregation query processing is that Shamir’s secret sharingmethod allows one to compute any linear combination ofsecrets. We make use of this property to perform aggre-gation queries such as AVERAGE, and SUM queries overmultiple private databases. In addition, we propose anothertechnique using Shamir’s secret sharing method to supportMIN, MAX and MEDIAN queries. In our scheme, the datasources involved in the query will only learn the aggrega-tion query result while third parties will not be able to learnany useful information.

We first outline the general solution and then furtherdiscuss each of the aggregate functions separately. Af-ter the query is posed, the data sources decide onhash functions to determine the polynomials to apply onthe key values, and they also choose random values

as described in Section 4.1.1. Then, theyconstruct two polynomials named and for each

pair to hide and respectively.For each , the polynomials and areconstructed as follows for min/max/median queries:

For sum and average queries, is a randomly selectedpolynomial of degree selected by each data sourceindependently. Therefore, each data source has its own dif-ferent . The reason for this is to hide the number of datasources having the same which cannot be done usingthe same . Then, the share of each thirdparty is calculated using and such that the shareof the th party is .

��

��

��

��

��

��

��

��

��

��

��

Figure 4. Illustration of Aggregation

Figure 4 shows an example with three data sources, ,and . Data sources compute the shares for the third

party using the polynomials described above. Then each


share is sent to , which is determined by hashing thevalue onto the Chord ring.

After the distribution phase, the third party peers createtwo column tables, the first column for and the secondfor the aggregation result (i.e., aggregation of secret values),and they perform the aggregation operation on the valuesthey have received. At the end, they send the aggregationresult back to the corresponding data source. As shown inFigure 4, the aggregation for the tuples with the same keyis calculated by the third parties and sent back to the corre-sponding data sources. After this, the data sources computethe actual aggregation result.

During the third step, the data sources in set receivetheir results from the third parties. Since they know thevalues of , they can solve the equation set in order to ob-tain the aggregation query result.

Average/Sum operations: In this set of operations, everysingle secret that has the same key contributes to the ag-gregation result. The data source constructs a randompolynomial to hidethe secret values for each pair in addition topolynomial , which is used to hide . After gen-erating these polynomials, it sends the shares of the thirdparties by computing the share of as

for each secret key-value pair, whereand

. After receives the shares of datasources, it sends the sum of values which have the same key.Assume of the data sources have the same Key with se-cret values through correspondingly. Then the sum forthat Key is in the following form:

...

Therefore sends its results, where is the sum of secret

values ( ) for the values that havethe same key.

Each data source receives results from each of the thirdparties:

...

Since is known by the data source,there are a total of unknown coefficients includingand equations. Therefore, can be found byusing any of the above equations.

The random polynomial selection used to hide secret val-ues ensures that data sources cannot determine how manydata sources have the same key (i.e., ). They can only com-pute the sum of the coefficients of the sum of the random

polynomials without knowing the number of polynomialsincluded in that sum.

For the average query sendwhere

and. Therefore, each data source receives results

from each of the third parties:

...

Again since is known by the datasources, there are unknown coefficients includingand equations. Therefore, can be found by us-ing any of the above equations. Again data sources cannotdetermine how many of the data sources have the same key(i.e., ).

Min/Max/Median operations: For these operations, onlyone of the secret values is sought. The order of the secretvalues needs to remain the same in the shares of the thirdparties to be able to use third parties to compute Min/Max/Median. To hide the secret value of a pair,data source uses the following polynomial:

, where is itssecret .

The key observation for computing the answer to this setof operations is that if ..,are the pairs at data sourcesrespectively and ... , the shares of athird party, , coming from , ..,respectively preserve the order ( ... ).This result follows from the way shares are computed .The shares, and for two secret values, and ,are +... + and

+... + . There-fore, if then , i.e., the calculation is orderpreserving.

Depending on the query, a third party returns the min-imum/maximum/median of its shares for as the answerto the query. Without loss of generality, we can assume thatthe query asks for minimum. Each of the third parties re-ceives pairs from data sources. After that,they return the minimum value for the pairs that have thesame key.

After the third parties send in the results back, each datasource receives the results from all third parties associatedwith , and determines the value of the minimum byusing the result of a third party , . The result of thethird party is in the following form:


Since the data sources know all the functions, ,and the value they can determine the minimum,

MIN, from the above equation.One could argue that the difference between values are

revealed to the third party with this scheme. Although thisinformation is useless, this information leakage could beprevented. All data sources could divide their s bythe same random number so that the third party could notknow the exact difference between values (since it does notknow the random number).

5 Query Response Time Analysis

The cost of query processing in an honest-but-curiousenvironment for intersection queries is the sum of the costof the distribution phase, the cost of the computation in thirdparties phase, and the cost of the final computation phase.

Let be the lists of the data sources in-volved in the query. Without loss of generality, we canassume that the list has the maximum number of ele-ments. Therefore, the computation in the distribution phaserequires time. The computation in third partiesalso requires comparisons. Finally the cost of thecomputation in the final phase is also (these com-parisons are for checking if the bitmap entry is or not).Therefore, the total computation needed is with ap-proximately a total amount of operations being per-formed which will require seconds.

Communication contributes to most of the total timespent during the execution of the protocol, the sharesare first sent to the third parties and then the bitmapsare received from them. The cost of sending shares is

, where is the number of third partiesand denote the size of a share coming from a secret value.The cost of collecting the bitmaps is .Therefore, the total communication cost is:

Hence the query response time for intersection queries:

For the equijoin operation, first the peers need to findthe intersection and then they need to transfer the matchingelements. Let denote the size of the data associated witheach element. In the worst case the intersection may containall the elements, in which case the query response time is:

The cost of the aggregation operation is the same asthe intersection operation, with additional computation costthat is necessary to solve the linear system of the receivedvalues to determine the random polynomials used by eachhost.

6 Conclusion

In this paper, we proposed a solution for processingqueries across private databases while preserving the dataproviders’ privacy. Our scheme is able to compute the an-swers to queries without violating the privacy requirementsof the data sources in an honest but curious environment.Our approach uses third parties without revealing any in-formation to these parties. These third parties are selectedfrom a P2P system, Chord. The secrets are distributed tothe third parties using Shamir’s secret sharing method onevery element. Using Shamir’s secret sharing also enablesus to perform aggregation queries in addition to the inter-section and equijoin queries, where we introduced a noveltype of aggregation queries needed in privacy preservingdata sharing. The scheme we propose is practical for ex-ecuting queries over large databases as opposed to priorwork in this field. The analytical evaluation demonstratesthat our approach incurs significantly less communicationand computation costs when compared with cryptographicapproaches.

References

[1] G. Aggarwal, M. Bawa, P. Ganesan, H. Garcia-Molina, K. Kenthapadi, N. Mishra, R. Motwani,U. Srivastava, D. Thomas, J. Widom, and Y. Xu. En-abling privacy for the paranoids. In Proc. of the30th Int’l Conference on Very Large Databases VLDB,pages 708–719, Aug 2004.

[2] G. Aggarwal, M. Bawa, P. Ganesan, H. Garcia-Molina, K. Kenthapadi, R. Motwani, U. Srivastava,D. Thomas, and Y. Xu. Two can keep a secret: A dis-tributed architecture for secure database services. InCIDR, pages 186–199, 2005.

[3] G. Aggarwal, N. Mishra, and B. Pinkas. Privacy-preserving computation of the k’th-ranked element. InProc. of IACR Eurocrypt, pages 40–55, 2004.

[4] R. Agrawal, A. Evfimievski, and R. Srikant. Informa-tion sharing across private databases. In Proc. of the2003 ACM SIGMOD international conference on onManagement of data, pages 86–97, 2003.

[5] R. Agrawal, P. J. Haas, and J. Kiernan. A systemfor watermarking relational databases. In Proc. ofthe 2003 ACM SIGMOD international conference onManagement of data, pages 674–674. ACM Press,2003.

[6] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. Hip-pocratic databases. In 28th Int’l Conf. on Very LargeDatabases (VLDB), Hong Kong, Aug 2002.


[7] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. Imple-menting p3p using database technology. In In Proc. ofthe 19th Int’l Conference on Data Engineering, Ban-galore, India, Mar 2003.

[8] R. Agrawal and R. Srikant. Privacy-preserving datamining. In Proc. of the 2000 ACM SIGMOD interna-tional conference on Management of data, pages 439–450. ACM Press, 2000.

[9] S. Agrawal and J. R. Haritsa. A framework for high-accuracy privacy-preserving mining. In to appear inInternational Conference on Data Engineering 2005,2005.

[10] M. Bawa, R. Bayardo Jr., and R. Agrawal. Privacypreserving indexing of documents on the network.In Proc. of the 29th Int’l Conference on Very LargeDatabases VLDB, pages 922–933, Aug 2003.

[11] S. Bergamaschi, S. Castano, M. Vincini, and D. Ben-eventano. Semantic integration of heterogeneous in-formation sources. Data Knowl. Eng., 36(3):215–249,2001.

[12] E. Bertino, B. C. Ooi, Y. Yang, and R. H. Deng. Pri-vacy and ownership preserving of outsourced medicaldata. In ICDE, 2005.

[13] C. Clifton, M. Kantarcioglu, J. Vaidya, X. Lin, andM. Y. Zhu. Tools for privacy preserving distributeddata mining. SIGKDD Explor. Newsl., 4(2):28–34,2002.

[14] U. Dayal and H. Hwang. View definition and general-ization for database integration in a multidatabase sys-tem. In IEEE Transactions on Software Engineering,volume 10, pages 628–644, 1984.

[15] F. Emekci, D. Agrawal, and A. E. Abbadi. Aba-cus: A distributed middleware for privacy preserv-ing data sharing across private data warehouses.In ACM/IFIP/USENIX 6th International MiddlewareConference, 2005.

[16] A. Evfimievski, R. Srikant, R. Agrawal, and J. Gehrke.Privacy preserving mining of association rules. InProc. of the eighth ACM SIGKDD international con-ference on Knowledge discovery and data mining,pages 217–228. ACM Press, 2002.

[17] O. Goldreich. Secure multi-party computation. Work-ing Draft, jun 2001.

[18] L. M. Haas, R. J. Miller, B. Niswonger, M. T. Roth,P. M. Schwarz, and E. L. Wimmers. Transforming

heterogeneous data with database middleware: Be-yond integration. IEEE Data Engineering Bulletin,22(1):31–36, 1999.

[19] H. Hacigumus, B. R. Iyer, C. Li, and S. Mehrotra. Ex-ecuting SQL over encrypted data in the database ser-vice provider model. In SIGMOD Conference, 2002.

[20] B. Hore, S. Mehrotra, and G. Tsudik. A privacy-preserving index for range queries. In Proc. of the30th Int’l Conference on Very Large Databases VLDB,pages 720–731, 2004.

[21] Y. Lindell and B. Pinkas. Privacy preserving data min-ing. In Proc. of the 20th Annual International Cryp-tology Conference on Advances in Cryptology, pages36–54. Springer-Verlag, 2000.

[22] M. W. N. Jefferies, C. Mitchell. A proposed archi-tecture for trusted third party services. CryptographyPolicy and Algorithms Conference, July 1995.

[23] M. Naor and K. Nissim. Communication preserv-ing protocols for secure function evaluation. In ACMSymposium on Theory of Computing, pages 590–599,2001.

[24] M. Naor and B. Pinkas. Oblivious transfer and poly-nomial evaluation. In Proc. of the thirty-first annualACM symposium on Theory of computing, pages 245–254. ACM Press, 1999.

[25] S. Rizvi and J. R. Haritsa. Maintaining data privacyin association rule mining. In Proc. of the 28th Int’lConference on Very Large Databases, pages 682–693,Aug 2002.

[26] A. Shamir. How to share a secret. Commun. ACM,22(11):612–613, 1979.

[27] R. Sion, M. Atallah, and S. Prabhakar. Rights pro-tection for relational data. In Proc. of the 2003 ACMSIGMOD international conference on Management ofdata, pages 98–109. ACM Press, 2003.

[28] R. Sion, M. J. Atallah, and S. Prabhakar. Resilientrights protection for sensor streams. In Proc. of the30th Int’l Conference on Very Large Databases VLDB,pages 876–887, 2004.

[29] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, andH. Balakrishnan. Chord: A scalable peer-to-peerlookup service for internet applications. In Proc. ofthe ACM SIGCOMM, pages 149–160, 2001.


[ieee 22nd international conference on data engineering (icde'06) - atlanta, ga, usa...

Documents