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

Sovereign Joins

Rakesh Agrawal Dmitri Asonov Murat Kantarcioglu Yaping LiIBM Almaden Research Center

The University of Texas at DallasUniversity of California, Berkeley

Abstract

We present a secure network service for sovereign infor-mation sharing whose only trusted component is an off-the-shelf secure coprocessor. The participating data providerssend encrypted relations to the service that sends the en-crypted results to the recipients. The technical challenge inimplementing such a service arises from the limited capa-bility of the secure coprocessors: they have small memory,no attached disk, and no facility for communicating directlywith other machines in the network. The internal state of anongoing computation within the secure coprocessor cannotbe seen from outside, but its interactions with the server canbe exploited by an adversary.

We formulate the problem of computing join in thissetting where the goal is to prevent information leakagethrough patterns in I/O while maximizing performance. Wespecify criteria for proving the security of a join algorithmand provide provably safe algorithms. These algorithmscan be used to compute general joins involving arbitrarypredicates and multiple sovereign databases. We thus en-able a new class of applications requiring query processingacross sovereign entities such that nothing apart from theresult is revealed to the recipients.

1 Introduction

Conventional information integration approaches, as ex-emplified by centralized data warehouses and mediator-based data federations, assume that the data in eachdatabase can be revealed completely to the other databases.Consequently, information sharing across autonomous enti-ties is inhibited due to confidentiality and privacy concerns.The goal of sovereign information sharing [2, 3, 8] is to en-able such sharing by allowing queries to be computed acrosssovereign databases such that nothing apart from the resultis revealed. The computation of join of sovereign databasesin such a manner is referred to as sovereign join. We citebelow two motivating applications of sovereign joins [3]:

Security For national security, it might be necessary tocheck if any of the airline passengers is on the watchlist of a federal agency [21]. Sovereign join may beused to find only those passengers who are on the list,without obtaining information about all the passengersfrom the airline or revealing the watch list.

Healthcare In epidemiological research, it might be ofinterest to ascertain whether there is a correlation be-tween a reaction to a drug and some DNA sequence,which may require joining DNA information from agene bank with patient records from various hospi-tals. However, a hospital disclosing patient informa-tion could be in violation of privacy protection laws,and it may be desirable to access only the matchingsequences from the gene bank.

1.1 Desiderata

A system offering sovereign join service has the follow-ing desirable attributes:

The system should be able to handle general joins in-volving arbitrary predicates. The national security ap-plication cited above requires a fuzzy match on pro-files. Similarly, the patient records spread across hos-pitals may require complex matching in the healthcareapplication.

The system should be able to handle multi-party joins.The recipient of the join result can be a party differentfrom one of the data providers.

The recipient should only be able to learn the result ofthe join computation. No other party should be able tolearn the result values or the data values in someoneelse’s input.

The system should be provably secure. The trustedcomponent should be small, simple, and isolated [4].

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

1.2 Problem Addressed

We present a secure network service for sovereign in-formation sharing whose only trusted component is a se-cure coprocessor [15, 26, 32]. IBM 4758 cryptographic co-processor [17] is an example of a commercially available,tamper-responding secure coprocessor.

The technical challenge in implementing such a servicearises from the following:

Secure coprocessors have limited capabilities. Theyrely on the server to which they are attached for diskstorage or communication with other machines. Theyalso have small memory (e.g. 4MB in IBM 4758).The factors constraining the memory size are cost andheat dispensation. The trend towards consolidating thesecure coprocessor functionality on a single chip alsoconstrains the amount of memory as larger memoriesreduce the yield.

While the internal state of a computation within thesecure coprocessor cannot be seen from outside, theinteractions between the server and the secure copro-cessor can be observed.

Simply encrypting communication between the dataproviders and the secure processor is, therefore, insuffi-cient. The join computation needs to be carefully orches-trated such that the read and write accesses made by thesecure coprocessor cannot be exploited to make unwantedinferences.

Careful orchestration of join computation in the face oflimited memory has been a staple of database research for along time. The goal in the past, however, has been the mini-mization of I/O to maximize performance. While the I/Ominimization is still important, avoiding leakage throughpatterns in I/O accesses now becomes paramount.

1.3 Related Work

In principle, sovereign information sharing can be imple-mented by using techniques for secure function evaluation(SFE) [13, 31]. Given two parties with inputs and re-spectively, SFE computes a function such that theparties learn only the result. SFE techniques are consideredto have mostly theoretic significance and have been rarelyapplied in practice, although some effort is afoot to changethe situation [22].

To avoid the high cost of SFE, the approach taken in [3]was to develop specialized protocols for intersection, inter-section size, equijoin, and equijoin size. Similar protocolsfor intersection have been proposed in [8, 16]. A new inter-section protocol has been recently proposed in [10]. How-ever, the protocols provided in [3] have the following short-comings: (1) It is not clear how to extend them to operations

involving general predicates as they are hash-based. (2) Itis not obvious how to extend them to efficiently handle alarge number of parties. (3) They leak information. For ex-ample, the equijoin size protocol leaks the distribution ofduplicates; if no two values have the same number of dupli-cates, it can also leak the intersection.

Secure coprocessors have been earlier used in a vari-ety of applications, including secure e-commerce [33], au-ditable digital time stamping [30], secure fine-grained ac-cess control [12], secure data mining [1], and private in-formation retrieval [5, 28]. See [27] for a taxonomy of se-cure coprocessing applications. The techniques developedtherein though are quite different. Note that the capabilitiesprovided in the architectures such as Trusted ComputingGroup’s trusted platform module [29], while complemen-tary, do not solve our problem.

1.4 Paper Layout

The rest of the paper is organized as follows. In Sec-tion 2, we specify the adversarial model and give the sim-plifying assumptions and notations. In Section 3, we illus-trate using classical nested loop some of the subtleties of theproblem. This investigation enables us to distill the designprinciples underlying the proposed algorithms. We also de-fine the correctness criteria for proving the safety of the joinalgorithms.

In Section 4, we provide two provably safe algorithmsfor general join in which the matching predicate can be anarbitrary function. They offer a range of performance trade-offs under different operating parameters.

Section 5 is devoted to the study of equijoins. Surpris-ingly, adaptations of classical sort-merge join or hash jointurn out to be unsafe. We then provide a safe algorithm.

In Section 6, we analyze the performance characteristicsof the proposed algorithms. We conclude with a summaryand directions for future work in Section 7.

2 Preliminaries

This section specifies the adversarial model and our sim-plifying assumptions and notations.

2.1 Adversarial Model

Our computing model admits any number of dataproviders and result recipients. Without loss of generality,we will consider the case where two parties andthat have private relations and are participating in thesovereign join operation and the result is sent to the party

, which is not or . We assume that the join algo-rithms and the join predicates are known to the parties.


The server , offering sovereign information sharing, isa general purpose computer. A secure coprocessor isattached to . The only trusted component is the securecoprocessor. All other components, including , are un-trusted. We assume that no party (including ) can observethe state of the computation inside or tamper with thecode loaded into it.

Communication between and , , or is en-crypted. Similarly, any temporary value output by to isalso encrypted.

2.2 Authenticated Computation

Given that nothing but is trusted, we have the chal-lenge of validating the authenticity and protecting the se-crecy of the computation done by .

We use the remote attestation mechanism provided bythe secure coprocessor to ensure that it is indeed executinga known, trusted version of the application code, runningunder a known, trusted version of the OS, and loaded by aknown, trusted version of the bootstrap code [12].

We assume that and have signed a digital con-tract [12] prescribing what data can be shared and whichcomputations are permissible. holds a copy of the con-tract and serves as an arbiter of it. Contracts are kept en-crypted at the server. At the start of a join computation,

authenticates the identities of and to ensure thatthe parties it is interacting with are indeed the ones listedin the contract. Then sets up the symmetric keys to beused with and respectively. Each party prepends itsrelation with the contract ID and encrypts the two togetheras one message.

We require an encryption scheme that provides bothmessage privacy and message authenticity. Such schemesare called authenticated encryption and include XCBC,IAPM, and OCB [11, 19, 24]. We choose OCB (whichstands for “offset codebook”) over the other two, as it re-quires the least number of block cipher operations (block cipher operations to encrypt (resp. decrypt) plain-text (resp. ciphertext) blocks). It is also provably secure:(a) an adversary is unable to distinguish OCB-outputs froman equal number of random bits (privacy) and an adversaryis unable to generate any valid Nonce, Ciphertext, Authen-tication Tag triple (authenticity). The indistinguishabilityfrom random strings implies that OCB is semantically se-cure [24], which ensures with high probability that dupli-cate tuples will be encrypted differently.

Encryption under OCB [24] requires an -bit noncewhere is the block size. The nonce would typically be anidentifier selected by the sender. In OCB, two states, Offsetand Checksum, are computed accumulatively as blocks aresequentially encrypted. The offset is used in encrypt-ing and decrypting block where ,

for and some easily computablefunction . When encrypting a plaintext block , theciphertext forwhere is the total number of message blocks. The fi-nal cipher block first bitswhere len ,len ) the length of the final message block, andsome easily computable function. The state Checksum =

and the tagChecksum [first bits] where

represents padding the last cipher block to the block size.The first bits are the authentication tag . The nonceand the ciphertext are transferredto the recipient.

When decrypting a ciphertext block , the plaintextfor where

is computed from the received nonce. Letlen .

[first bit]. Checksum =. Let Checksum [first

bits]. If , then accept the message, otherwise reject.Since we use authenticated encryption, an adversary who

does not know the key cannot impersonate or , norcan it tamper with the encrypted tuples in any way thatwill not be detected. Similarly, for communication of re-sult from to .

Thus, the only vulnerability that an adversary can hopeto exploit is the pattern in the interactions between and .Our algorithms are designed to thwart the adversary fromlearning anything by observing this interaction.

2.3 Assumptions and Notations

To simplify exposition, we will assume that the tuples of, , and are of the same size and that free memory of

the secure processor can hold at most such tuples.Note that we need to be able to hold at least two input tu-ples in memory during the join processing and expressingmemory size as simplifies cost expressions. is themaximum number of tuples from that match a tuple from

. Our algorithms have been designed to handle the gen-eral case where . We also assume that is muchsmaller than or .

We will omit from the algorithms the details of the com-munication between , , , and . Assume thatand have sent their encrypted relations and respec-tively to , who has stored them on its local disk. Similarly,

writes the encrypted join result to ’s disk (invoking theserver process running on ), which then sends to .The algorithms will describe the code executed by .

We will indicate a transfer of data from to byprepending the operation with the keyword ; the key-word will indicate a transfer from to . We will use


and to denote the encryption and de-cryption functions respectively. We will ignore the use ofkeys in these functions. We assume fixed size tuples andthat the server knows their size.

We do not discuss issues such as schema discovery andschema mappings. We assume schemas can be shared. Thedesign presented in [2] can be used for this purpose.

3 Design Principles

We first present two straightforward, but unsafe, adapta-tions of the classical nested loop join algorithm. We discussthem as they help derive the design principles underlyingour proposed algorithms.

3.1 A Straightforward, but Unsafe Algorithm

Here is a straightforward adaptation of the classicalnested loop join algorithm. first obtains an encryptedtuple of by sending a read request to and decrypts thetuple inside its memory. then reads a tuple of , decryptsit, and compares it with the decrypted tuple of . If thematch succeeds, encrypts the result tuple and outputs itto to write to disk. The above step is repeated for the restof the tuples of and then the procedure is repeated for therest of the tuples of .

Unfortunately, this straightforward adaptation is notsafe, although the input as well as output values remain en-crypted outside of . An adversary (e.g., colluding with

who does not receive the join result) can easily deter-mine which encrypted tuples of joined with which tuplesof , simply by observing whether outputted a result tu-ple before the read request for the next tuple. If this in-formation becomes available to , then can determinewhich of its tuples have a match with a tuple of .

3.2 An Incorrect Fix

What if waits for tuples (or a random number of tu-ples ) to be created and then outputs them in a block?Unfortunately, the adversary can still estimate the distribu-tion of matches. In addition, the adversary can also launchtiming attacks; since encryption takes significant time, itcan determine whether there was a match by monitoringinter-request times for tuples.

3.3 Principles

We can derive two important principles from the abovediscussion:

1. Fixed Time The evaluation of the join predicate and thecomposition of tuples should take same time irrespec-tive of whether the comparison yields a match.

2. Fixed Size There should not be any difference in theamount of output produced irrespective of whether thecomparison yields a match.

3.4 Correctness Criteria

We discussed earlier that an adversary can only inferinformation from the pattern of interactions between theserver and the secure coprocessor. Therefore, for an algo-rithm running on a secure coprocessor to be safe, it mustnot reveal any information from its accesses to the server.Building upon the definitions in [14], we formalize this in-tuition as follows:

Definition 1 (Safety of a Join Algorithm) Assume wehave database relations , , and , where ,

, and have identical schema, as do and .For any given (Section 2.3), let (respectively, )be the ordered list of server locations read and written bythe secure coprocessor during the join of (resp. ) and

(resp. ). The join algorithm is safe if andare identically distributed.

If the access pattern is independent of the underlyingdata then the access pattern will be identical for all the rela-tions that satisfy the conditions given in Definition 1. There-fore, to prove that an algorithm is safe, we will show that theaccess pattern does not depend on the data in the underlyingrelations.

3.5 Observations

The following remarks apply to all the proposed algo-rithms.

Safeguarding Against Timing Attacks The standard ap-proach for avoiding timing attacks is to pad the variance inprocessing steps to constant time by burning CPU cycles asneeded [12]. To keep the algorithm descriptions simple, wewill not show the steps that burn CPU cycles in any of thealgorithms.

Decoys Our algorithms encrypt a decoy plaintext and out-put it if necessary to prevent information leakage. Decoysare decrypted and filtered out by the recipient. They maytake the form of a fixed string pattern. The semanticallysecure encryption generates indistinguishable cipher textsfrom multiple encryptions of the same plain text, which canbe recovered from any one of them at the time of decryp-tion [24].


Setting In some applications, might be known apri-ori. A safe estimate for would be but it can hurt per-formance, particularly if the actual value is much smaller.Guessing too small and rerunning the algorithm if theactual value happens to be larger leaks information. A safeway to compute exact would be to run a nested loop join,but without outputting any result tuple. Note that this pre-processing step does not leak information.

Cost Analysis We will compare the cost of our algorithmsin terms of the number of tuple transfers between the se-cure processor and the server, assuming disk I/Os can bepipelined with the transfers between the server and the se-cure coprocessor. Every time the secure processor gets atuple from the server, it is decrypted. Similarly, a tuple isencrypted before the secure coprocessor outputs it to theserver. Thus, the number of transfers between the coproces-sor and server also reflects the total number of encryptionand decryption operations.

4 General Join Algorithms

We present two algorithms for general joins in which thejoin predicate is specified through an arbitrary match() func-tion. A join in this general setting requires every tuple of theouter relation to be compared with every tuple in the innerrelation [7].

4.1 Algorithm 1

Algorithm 1 has been designed for secure coprocessorswith small memories. It outputs an encrypted join tuple ifthere is a match and an encrypted decoy of the same sizeotherwise. Because of semantically secure encryption, allthe decoy tuples will look different and an adversary cannotdecipher whether there was a match or not.

Using the above strategy, a straightforward algorithmwill generate an output of size . Algorithm 1 gen-erates output tuples by cleverly using ar-ray of size allocated in s memory. In a pass over

, after processing every tuples (a round), oblivi-ously sorts giving lower priority to decoy tuples.Consequently, any joined tuples in the last location of

will be moved to the first locations of .However, because of sorting being oblivious, an adversarycannot know the boundary. After the last round, the first

locations of will contain only the result tuplesand possibly some decoy tuples and the server writes themto disk.

Oblivious Sorting An oblivious sorting algorithm sortsa list of encrypted elements such that no observer learns

Algorithm 1 For Secure Coprocessors with Small Memoryfor each tuple do

encrypted decoy tuples to ;;

;for each tuple do

;if thenput

;elseput

;end if

if thenObliviously sort giving lower priorityto decoy tuples;

end ifend forif then

Obliviously sort giving lower priority todecoy tuples;

end ifRequest to write first of to disk;

end for

the relationship between the position of any element in theoriginal list and the output list. Oblivious sorting of a listof elements using the Bitonic sort algorithm proceeds instages [6]. Assuming is a power of 2, at each stage, theelements are divided into sequential groups of size where

depends on the stage. Within each group, an element iscompared with one that is elements away. Each pairof the encrypted elements is brought into the secure copro-cessor, decrypted, compared, and re-encrypted before theyare written out to their original positions possibly swapped.There are a total of approximately stages and

comparisons at each stage. Therefore, the cost of oblivi-ous Bitonic sort is comparisons andelement transfers between the secure coprocessor and theserver.

Encryption Since both and are accessed sequen-tially, they can be encrypted using the procedure describedin Section 2.2. However, oblivious sorting of re-quires non-sequential access to its tuples. We next describethe encryption of tuples in in the OCB mode. Forsimplicity, assume that the size of a tuple is the same as thelength of one cipher block.

After an oblivious sort, the first locations of the ar-ray contain the joined tuples that has seen so


far and possibly some decoy tuples; the last locationscontain decoy tuples. Conceptually, the first tuples in

and the output tuples from the next round willbe treated as one message.

At the end of the last stage of an oblivious sort, keepsthe following two states for continuing encryption in thenext round: an offset and a Checksum

where are the plaintext of tuples in the firstlocations in . In the next round, encrypts theoutput tuples as message blocks throughand computes a tag for the entire message.

We next describe how to perform encryption and de-cryption when obliviously sorting . generatesa fresh nonce for re-encrypting output tuples at each stageof the Bitonic sort. When comparing a pair of tuples,decrypts and , compares them, thenre-encrypts them with offsets and computed fromthe fresh nonce for the current stage. then computesChecksum Checksum . At the end of a stage,if accepts the tuples it just decrypted, it continues tothe next step, otherwise, it terminates the computation. Af-ter re-encrypting the last tuple for a stage, computes thetag for the tuples it just encrypted and keeps this tag inthe memory for the authentication check at the next stage.

We next investigate the extra cost of encrypting tuples(elements) non-sequentially. As before, the size of a tuple isthe same as the length of one cipher block. In Bitonic sort,an element is compared with one that is half the distanceaway in the same group. In order to decrypt theelement without sequentially decrypting every tuple beforeit, we apply the function times to obtain

. Then the sec-ond element is compared with the element and

and , andso on. Thus, within the same group, no additional applica-tion of is required except for the first pair. Hence, ata stage in which there are groups of size where ,the total additional applications is . Sincethere are stages in Bitonic sort, a total of addi-tional applications of are needed for sort-ing a set of elements compared to sequentially encrypting

elements at each stage.

4.1.1 Correctness (Proof Sketch)

For every tuple of , the algorithm goes through the samenumber of rounds ( ). In every round, outputs thesame amount ( tuples) to the same locations of .After all the rounds are over, obliviously sorts ,which accesses independent of the underlyingdata. Finally, always the first locations of areaccessed for writing the result tuples to disk. Thus, Defini-tion 1 is satisfied.

4.1.2 Cost Analysis

During the execution of Algorithm 1, gets tuples fromand tuples from . It outputs decoy tuples for

each , for a total of decoy tuples. For eachcomparison of and , outputs a result tuple,for a total of output tuples. For every andevery block of tuples in , obliviously sorts tuples,which leads to transferring a total oftuples into and out of ’s memory. Finally, the server writes

tuples to disk.Thus, in terms of the number of tuple transfers in and out

of ’s memory, the complexity of Algorithm 1 is:

4.2 A Variant of Algorithm 1

Consider a variant of Algorithm 1 that also matches ev-ery tuple of with every tuple of , but does not use

. Instead, for a given tuple of , it writestuples, result or decoys, to the memory of . At the endof the pass, output tuples are obliviously sorted givinglower priority to decoy tuples and only the first tuples aresaved.

The number of tuple transfers in and out of ’s memorywill now be . Assume

, and define to be . Clearly, Algorithm 1outperforms this variant for small values of ; we do notdiscuss it further.

4.3 Algorithm 2

Algorithm 2 has been designed for secure coprocessorswith larger memories. It optimizes the use of the memory ofthe secure processor to reduce the number of output tuples,while not leaking any information in the process.

Define . Here representsthe small amount of memory needed for data structuresother than those needed for holding the input and result tu-ples (e.g. counters). For every tuple of , reads entire

a total of times to find all the matches for . Concep-tually, imagine partitioning the tuples from that matchinto groups of tuples each. During pass over ,

computes the group of the matched tuples and outputsthem to at the end of the pass. Note that unlike the stan-dard blocked nested loop join in which the input relationsare partitioned in chunks of fixed size, the partitioning hereis over the matched tuples.

Recall that is the maximum number of tuples thatmatch with any of the tuples in . Clearly, there may betuples in that match with less than tuples of . Inthat case, when runs out of real join tuples, it outputs anappropriate number of decoy tuples.


Since both and are accessed sequentially and theoutput tuples are also produced sequentially, they can beencrypted using the procedure described in Section 2.2.

Algorithm 2 For Secure Coprocessors with Larger Memo-ries

; passes over for everytuple

; output tuples in a passfor each tuple do

;; position of the last matched tuple

for to do; matches in the current pass

; position of the current tuplefor each tuple do

;if and then

if then

;;

;end if

end if;

end forappend ( ) encrypted decoy tuples to

;to ;

Request to write to disk;end for

end for


Every tuple of causes passes over . After every passover , sends an output of fixed size to . Thus, the ac-cess pattern is independent of the underlying data and Defi-nition 1 is satisfied.

4.3.2 Cost Analysis

During the execution of Algorithm 2, gets tuples from, tuples from , and outputs tuples. Fi-

nally, the server writes tuples to disk.Therefore, in terms of the number of tuple transfers in

and out of ’s memory, the complexity of Algorithm 2 is:

4.3.3 Parameter Selection

We now discuss how to partition ’s memory between theinput and the result tuples to minimize the number of trans-fers between and . Define where

represents the small amount of memory needed for datastructures other than the input and result tuples. We con-sider separately the following two cases: (1) , and(2) .

For Case (1), blocking of is not helpful as we willexplain momentarily in Section 4.3.4. So, we keep onlyone tuple of in memory and our problem reduces to oneof optimally partitioning between the tuples from andthe joined tuples. Let where denotes thenumber of tuples and represents the number of joinedtuples. The goal is to find and such that the numberof transfers for joining an tuple with is minimized.

Observe that for each , it is optimal to scan atotal of times. For each scan of ,outputs joined tuples where . Weallocate tuples for tuples. So the partition is

and .For Case (2), we partition the free memory of among

the tuples in , , and the joined tuples. Let, where denotes the number of tuples from ,

the number of tuples from , and the number of joinedtuples. The goal is to find , , and such that thenumber of transfers for joining with is minimized.

Observe that when can hold more than tuples, it isoptimal if scans at most once for each . Define

to be the largest integer such that , i.e.,can hold tuples in and all of their up to matchingtuples. Then the optimal way to partition the memory is

, , and .

4.3.4 Understanding Blocking of

We next discuss why blocking of does not result in anyperformance gain.

Assume that we partition into blocks of size . Foreach tuple in a block, allocates a piece of memory tohold a maximum of joined tuples. reads into itsmemory one block of at a time. For each , scansthe entire table a total of times to find amaximum of matching tuples for each tuple in . Padthe matching tuples for each to a total of tu-ples. Conceptually, imagine partitioning these tuples intogroups. During each pass of , retains the group ofthe matching tuples for each element in and outputsto the matching tuples at the end of each pass.

The complexity of this algorithm iswhere represents the number of blocks in and

the number of scans of per block. Assume thatis an integer multiple of , and is an integer multiple


of and respectively. Recall that the complexity forAlgorithm 2 is . Since , blocking Ais computationally more expensive than the non-blockingcase. In terms of transfers between and , Algorithm 2does tuple transfers while the blockingversion does transfers.The non-blocking version performs less transfers.

4.4 Parallelism

Consider a server in which more than one secure copro-cessor is attached to the server. It is readily apparent thatboth the above algorithms (as well as the upcoming Algo-rithm 3) are easy to parallelize with a linear speed-up in thenumber of processors.

5 Equijoin Algorithms

We now investigate the special, but important case ofequijoins. This study turned out to be quite instructive, aswe could not enhance some well known algorithms with se-curity features. We first report those false starts and thenpresent a safe algorithm.

5.1 False Starts

We explore the adaptation of classical sort-merge join,grace hash join, and the idea of commutative encryptionfrom [3, 8, 16].

5.1.1 Sort-Merge Join (Unsafe)

Assume and for a particular tuple there are3 matches in . After the third match, when reads thenext tuple from , it realizes that there is no more matchesin for . Therefore, will read the next tuple from .Such an execution will reveal the number of matches foreach tuple.

5.1.2 Hash-based Join (Unsafe)

We consider the family of grace hash join algorithms[9, 20]. They begin by partitioning and into disjointsubsets called buckets, which have the property that all tu-ples with the same hash of the join attribute value share thesame bucket. The corresponding buckets are then joined toproduce the result.

The algorithm below depicts our attempt to ensure thatthe partitioning of a relation into bucket does not leak infor-mation. The basic idea is to fill any empty space in all otherbuckets with decoy tuples as soon as one of them becomesfull and output all of them to the server.

Unfortunately, the partitioning phase unavoidably leakspartial information. 1

Obliviously shuffle (see[18]);for each do

;Place into the bucket, where

;if the bucket is full then

Fill all other buckets with decoy tuples and outputall the buckets to ;

end ifend for

5.1.3 Commutative Encryption (Unsafe)

We now consider an algorithm inspired by the idea of com-mutative encryption used in [3, 8, 16].

The first encryption is done by the data providers beforesending their relations to . Now, executes the algorithmbelow. The key point is that employs symmetric encryp-tion [25] using the same key for re-encrypting the two rela-tions.

Obliviously shuffle ;for each do

;put symmetric encrypt( );

end forSimilarly re-encrypt using same key;Do sort-merge join on the encrypted relations; Can bedone by server

Unfortunately, this adaptation is also unsafe (leaks thedistribution of the duplicates).

5.2 Sovereign Sort-Based Join (Safe)

We now present a safe sort-based equijoin algorithm.This algorithm can be viewed as a specialization of Algo-rithm 1. Assume has obliviously sorted . The key in-sight is that the tuples that will join with an tuple willcome from at most consecutive positions in . This ob-servation is used to avoid the processing of in rounds and

1For example, an adversary can distinguish between a uniformly dis-tributed relation and a highly skewed one . Let the size of a bucket be

tuples and let the number of buckets be .When partitioning , all of the buckets will fill up at relatively the same

speed. will output the buckets after it has read and hashed abouttuples. On the other hand, when partitioning , one of the buckets will fillup much faster than the rest. will now output the buckets after readinga little more than tuples. By observing the difference in the number oftuples reads between writes, an adversary may learn partial informationabout the distribution of the values of the join attribute.


Algorithm 3 Sort-Based JoinObliviously sort on the join attribute;for each tuple do

;put encrypted decoy tuples;

;for each tuple in do

;

if thenput

;elseput ;

end if;

end forRequest to write to disk;

end for

obliviously sorting after each round. The size ofnow reduces to tuples.

For every tuple, Algorithm 3 initializes withdecoy tuples. Now, for every tuple that reads from ,also reads a specific location from in a circu-

lar fashion; for the tuple, reads .writes back to the same location either the value just

read (though encrypted differently so it is indistinguishableto the adversary) or the joined tuple if the tuple frommatches the tuple of . A logical concern is how to avoidoverwriting real result tuple from a previous match. Theoverwriting will never happen because all the real result tu-ples will be in at most consecutive positions in .

To ensure authenticated computation, both and re-lations need to be encrypted under OCB mode. Since isaccessed sequentially, it can be encrypted using the proce-dure described in Section 2.2. However, requires obliv-ious sorting. Hence, its encryption should use the strategydescribed for encrypting array in Section 4.1.

We now describe how to encrypt and decrypt tuples inin the OCB mode. We refer to reading tuples

from 0 to in as a round. In each round,treats the tuples written to and read from andas one message respectively. In each round, if acceptsthe tuples it decrypted, it continues to the next round;otherwise it terminates the computation. For the outputtuples in each round, encrypts them in the OCB modewith a fresh nonce and the same encryption key.


Since is sorted obliviously, this step is safe. After get-ting a tuple from , always reads a specific locationfrom and always writes something of the samesize back to the same location. These actions are executedregardless of the content of the underlying relations. There-fore, Definition 1 is satisfied.

5.2.2 Cost Analysis

first obliviously sorts leading to a total oftuple transfers. During the rest of the exe-

cution, gets tuples from and tuples from .For every tuple of , outputs decoy tuples, for a totalof decoy tuples. For every tuple of and , gets adecoy tuple from and outputs a result tuple, for a total of

gets of decoy tuples and puts of result tuples.Finally, the server writes tuples to disk.

Thus, in terms of transfers in and out of ’s memory, thecomplexity of Algorithm 3 is:

If the data providers can send sorted data to the service,the step of oblivious sorting can be avoided and the com-plexity becomes:

6 Performance Analysis

In this section, we study the performance characteristicsof the proposed algorithms. We identify two important pa-rameters:

(ignoring )

Note assuming there is at least one matchingtuple for every , and .

Two other parameters that merit consideration are: (i) thesize of the tuples, and (ii) the size of the relations. The firstplays an insignificant role in Algorithms 1 and 3.

For Algorithm 2, its effect can be understood by under-standing . The running time of the algorithms increasesquadratically in terms of the size of the relations, but that iswhat we expected. It is more interesting to study the perfor-mance with respect to and .

Taking , we rewrite the cost formulas for thethree algorithms as follows:

Algorithm 1

Algorithm 2

Algorithm 3


6.1

We find that Algorithm 2 dominates the other two algo-rithms. To see this, set to 1 (the largest value it can take)for Algorithm 2 and set it to (the smallest value) forAlgorithms 1 and 3 and examine the cost formulas.

Note is 1 when the maximum number of tuples thatjoin with any of the tuples can fit in the free memory of

. It is interesting that in this case, Algorithm 2 designedfor general joins beats a specialized algorithm that worksonly for equijoins. The relative performance gap increasesas the size of the relations increases.

6.2 General Joins,

Algorithm 1 outperforms Algorithm 2 when. Let’s substitute for (the smallest

value it can take). Algorithm 1 outperforms Algorithm 2when , i.e., is more than 4 times the free memoryof the secure coprocessor. For a fixed table size , asincreases, also increases.

6.3 Equijoins,

Both Algorithms 1 and 3 are insensitive to . For com-paring them, let us substitute in the last term in the costformula for Algorithm 1 with , the smallest value

takes. We rewrite the cost formula for Algorithm 1 asThen the comparison of Algo-

rithm 3 to Algorithm 1 reduces to comparingand . In this case, Algorithm 3 outperformsAlgorithm 1 for any value of and .

Finally, let us compare Algorithm 3 to Algorithm 2.Their cost comparison boils down to comparing

with . When , Algorithm 2 out-performs Algorithm 3 regardless of the value of . When

, Algorithm 3 outperforms Algorithm 2 for suf-ficiently large . When , Algorithm 3 outperformsAlgorithm 2 whenever .

6.4 Performance Relationship Summary

Figure 1 summarizes the performance relationshipamong the three algorithms. An unlabeled arrow pointingfrom Algorithm to denotes that dominates . Alabeled arrow from to indicates the condition underwhich outperforms ; the performance relationship isreversed if the condition is not satisfied. For simplicity, welabel the arrows with only the significant conditions.

6.5 Comparison with Secure Function Evaluation

We now compare the performance of the proposed al-gorithms to the technique for secure function evaluation

Figure 1. Performance Relationship

(SFE), based on secure circuit evaluation [13, 31]. SinceAlgorithm 2 performs better than Algorithm 1, we will con-servatively compare Algorithm 1 to the most recent (and tothe best of our knowledge, most efficient) technique, pro-vided in [22, 23].

We will compare the number of communications in thisanalysis. We are again being conservative; we are compar-ing communication between the secure coprocessor and theserver it is attached to in the case of Algorithm 1 to the com-munication across wide-area network in the case of SFE.

Assume and that each tuple is bits wide.Assume that the output has bits. Assume that thecircuit for matching two -bit tuples requires gates.Then a secure circuit for general join will have at least

gates. Note that in the simplecase that two tuples are matched if their Norm is smallerthan some threshold.

Assume is the number of bits in the supplemental keysused while building the circuit, the cheating probability of

is exponentially small in , and the cheating probabilityof is exponentially small in . In practice, and

.and need to make at least 1-out-of-2 obliv-

ious transfers where each oblivious transfer uses one pub-lic key encryption, pseudo-random functionevaluations, public key encryptions for partialproofs of knowledge and gradual opening of commitments,and public key encryptions for blind signatures.

needs to send copies of bit en-crypted circuit to and send at least bits foreach oblivious transfer. Here, is the security parame-ter for oblivious transfer; in practice. sends

bit commitments to .Total communication cost can thus be estimated as

To compare the communication cost of SFE and our solu-tions in bits, we multiply the cost formula for Algorithm 1with . Let , their mini-mum values suggested in [22], and take . For


low values of , it can be seen that SFE can be orders ofmagnitude slower.

7 Summary

We presented a secure information sharing service of-fering sovereign joins, built using off-the-shelf secure co-processors. Our design satisfies the desiderata for such aservice: we can do general joins involving arbitrary pred-icates across any number of sovereign databases; nothingapart from the result is revealed to the recipients; the onlytrusted component is the secure coprocessor; and the systemis provably secure. Our other contributions include:

Formulation of the problem of computing join inwhich the goal is to prevent information leakagethrough patterns in I/O while maximizing perfor-mance.

Articulation of the criteria for proving the security of ajoin algorithm in such an environment.

Development of safe algorithms for different opera-tional parameters and their cost analysis.

Directions for future work include developing algo-rithms for other database operations, particularly aggrega-tion.

Acknowledgements We wish to thank BishwaranjanBhattacharjee, Chris Karlof, Bruce Lindsay, Guy Lohman,Arnie Rosenthal, and Dan Shiffman for insightful com-ments and discussions.

This work was supported in part by TRUST (The Teamfor Research in Ubiquitous Secure Technology), which re-ceives support from the National Science Foundation (NSFaward number CCF-0424422) and the following organiza-tions: Cisco, ESCHER, HP, IBM, Intel, Microsoft, ORNL,Qualcomm, Sun and Symantec, and in part by the NastionalScience Foundation through ITR Award IIS-0205647. Theopinions in this paper are those of the authors and do notnecessarily reflect the opinions of any funding sponsor orthe US Government.

References

[1] N. Abe, C. Apte, B. Bhattacharjee, K. Goldman, J. Langford,and B. Zadrozny. Sampling approach to resource light datamining. In SIAM Workshop on Data Mining in ResourceConstrained Environments, 2004.

[2] R. Agrawal, D. Asonov, P. Baliga, L. Liang, B. Prost, andR. Srikant. A reusable platform for building sovereign infor-mation sharing applications. In 1st Workshop on Databasesin Virtual Organisations, June 2004.

[3] R. Agrawal, A. Evfimievski, and R. Srikant. Informationsharing across private databases. In Proc. of the 2003 ACMSIGMOD Int’l Conf. on Management of Data, San Diego,CA, June 2003.

[4] J. P. Anderson. Computer security technology planningstudy. Technical Report ESD-TR-73-51, Vol II, HQ Elec-tronic Systems Division (AFSC), L.G. Hanscom Field, Bed-ford, MA, Oct. 1972.

[5] D. Asonov. Querying Databases Privately. PhD thesis,Springer Verlag, June 2004.

[6] K. E. Batcher. Sorting networks and their applications. InProc. of AFIPS Spring Joint Comput. Conference, Vol. 32,1968.

[7] K. C. Chang and S. Hwang. Minimal probing: Supportingexpensive predicates for top-k queries. In Proc. of the 2002ACM SIGMOD Int’l Conf. on Management of Data, Madi-son, Wisconsin, June 2002.

[8] C. Clifton, M. Kantarcioglu, X. Lin, J. Vaidya, andM. Zhu. Tools for privacy preserving distributed data min-ing. SIGKDD Explorations, 4(2):28–34, Jan. 2003.

[9] D. J. DeWitt and R. Gerber. Multiprocessor hash-based joinalgorithms. In Proc. of the 11th Conference on Very LargeDatabases, Stockholm, 1985.

[10] M. J. Freedman, K. Nissim, and B. Pinkas. Efficient privatematching and set intersection. In Proc. Advances in Cryp-tology – EUROCRYPT 2004, Interlaken, Switzerland, May2004.

[11] V. Gligor and P. Donescu. Fast encryption and authentica-tion: XCBC encryption and XECB authentication modes,2000.

[12] K. Goldman and E. Valdez. Matchbox: Secure data sharing.IEEE Internet Computing, 8(6):18–24, 2004.

[13] O. Goldreich. Foundations of Cryptography, volume 2: Ba-sic Applications. Cambridge University Press, May 2004.

[14] O. Goldreich and R. Ostrovsky. Software protection and sim-ulation on oblivious RAMs. J. ACM, 43(3):431–473, May1996.

[15] P. Gutmann. An open-source cryptographic coprocessor. InUSENIX, 2000.

[16] B. A. Huberman, M. Franklin, and T. Hogg. Enhancing pri-vacy and trust in electronic communities. In Proc. of the1st ACM Conference on Electronic Commerce, pages 78–86,Denver, Colorado, November 1999.

[17] IBM Corporation. IBM 4758 Models 2 and 23 PCI crypto-graphic coprocessor, 2004.

[18] A. Iliev and S. Smith. Privacy-enhanced credential services.In 2nd Annual PKI Resarch Workshop, NIST, Gaithersburg,Apr. 2003.

[19] C. S. Jutla. Encryption modes with almost free message in-tegrity. Lecture Notes in Computer Science, 2045:529–544,2001.


[20] M. Kitsuregawa, H. Tanaka, and T. Moto-Oka. Applicationof hash to data base machine and its architecture. New Gen-eration Computing, 1(1), March 1983.

[21] T. Kontzer. Airlines and hotels face customer concerns aris-ing from anti-terrorism efforts. Information Week, March2004.

[22] D. Malkhi, N. Nisan, B. Pinkas, and Y. Sella. Fairplay -a secure two-party computation system. In Usenix Security’2004, Aug. 2004.

[23] B. Pinkas. Fair secure two-party computation. In Advancesin Cryptology – EUROCRYPT’2003, volume 2656 of Lec-ture Notes in Computer Science, pages 87–105. Springer-Verlag, May 2003.

[24] P. Rogaway, M. Bellare, and J. Black. OCB: A block-cipher mode of operation for efficient authenticated encryp-tion. ACM Transactions on Information and System Security,6(3):365–403, August 2003.

[25] B. Schneier. Applied Cryptography. John Wiley, second edi-tion, 1996.

[26] S. Smith and S. Weingart. Building a high-performance, pro-grammable secure coprocessor. Research Report RC 21102,IBM T.J. Watson Research Center, Yorktown Heights, NewYork, Feb. 1998.

[27] S. W. Smith. Secure coprocessing applications and researchissues. Los Alamos Unclassified Release RLA-UR-96-2805,Los Alamos National Laboratory, Los Alamos, NM, Aug.1996.

[28] S. W. Smith and D. Safford. Practical server privacy with se-cure coprocessors. IBM Systems Journal, 40(3), Sept. 2001.

[29] Trusted Computing Group. TCG specification architectureoverview, 2004.

[30] WetStone Technologies. TIMEMARK timestamp server,2003.

[31] A. C. Yao. How to generate and exchange secrets. In Proc.of the 27th Annual Symposium on Foundations of ComputerScience, pages 162–167, Toronto, Canada, October 1986.

[32] B. S. Yee. Using Secure Coprocessors. PhD thesis, CarnegieMellon Univerisity, May 1994.

[33] B. S. Yee and J. D. Tygar. Secure coprocessors in electroniccommerce applications. In The First USENIX Workshop onElectronic Commerce, July 1995.


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

Documents