Yin Yang, Dimitris Papadias, Stavros Papadopoulos HKUST, Hong Kong Panos Kalnis KAUST, Saudi Arabia Providence, USA, 2009

 Advantages  The data owner does not need the hardware / software / personnel to run a DBMS  The service provider achieves economy of scale  The client enjoys better quality of service  A main challenge  The service provider is not trusted, and may return incorrect query results 2

 The owner signs its data with a digital signature scheme  Given a query, the service provider attaches a VO (Verification Object) to the results  The client verifies query results with the VO and the owner’s signature  soundness  completeness 3

Range: σ quantity>100 Purchase Join: Purchase cid Customer Range & Join :(σ quantity>100 Purchase) cid (σ city=“New York” Customer) 4

 Range authentication: many solutions  Join authentication: few proposals  Materializing join results into views  AINL (presented in detail later)  Joins are inherently more complex than ranges  A join combines information from multiple tables  Only individual tables are signed 5

 Multi-dimensional range authentication  Y. Yang, S. Papadopoulos, D. Papadias, G. Kollios (BU)  ICDE’08, VLDB J.  Continuous range authentication  S. Papadopoulos, Y. Yang, D. Papadias  VLDB’07, VLDB J.  Novel authentication framework  S. Papadopoulos, D. Saccharidis, D. Papadias  ICDE’09 6

 Concepts in Cryptography  Authenticated Data Structure (ADS)  Merkle Hash Tree  MB-Tree  AINL 7

 One-way, collision-resistant hash functions  h = H(m)  Computationally infeasible to infer m from h, or to find two m 1, m 2 with the same hash value h  Example: SHA1, SHA2, …  Public-key encryption  Two keys: private key sk, public key pk  Public key to encrypt, private key to decrypt  Example: RSA  Digital Signature  Hard to forge without the secret key  Signing: s = encrypt(H(m), sk)  Verifying: check if H(m) = decrypt(s, pk) 8

 A binary tree with hash values satisfying h n = H(h n.lc | h n.rc )  Authenticates 1D range queries  Example: a query Q retrieves d 4, d 5  VO(Q) = {s root, h 1-2, d 3, d 4, d 5, d 6, h 7-8 }  The client re-constructs h Root bottom-up, and verifies the signature 9

 Merkle Hash Tree + B-Tree  Conceptually, a Merkle Hash Tree with a large fanout (>2) 10

 For binary joins  Requires ADS on the join attribute of the inner relation  Reduces a join query into multiple ranges  Algorithm  For every tuple in the outer relation Perform an authenticated range on the inner relation 11

12 r1r1 1. r 1, h F, h 10, s 11, s 12, h E 2. r 2, h 1, s 2, s 3, s 4, h 5, h 6, h C, h G 3. … r2r2

 Large VO size  |R| records from R (outer relation)  2|R|+|RS| records from |S| (inner relation)  Numerous hash values  Often larger than the combined size of R and S  High computation overhead at the server and the client 13

 The server transmits all the data to the client  The client performs the join locally  NAI often outperforms AINL 14

 Binary join authentication  AISM: requires ADS on one relation  AIM: requires ADSs on both relations  ASM: requires no ADS  Complex join query authentication  Multi-way join  Select-project-join 15

 Sort the outer relation R on the join attribute  Transmit all tuples in R to the client in their verifiable order  Transmit the sort order  R of R tuples on the join attribute  Incrementally traverse the ADS on S once with the R records 16

17  R [2]=4 VO: signature of R, root signature of T S, r 1 -r 6 in their verifiable order 1.  R [1], h 1, s 2, s 3, s 4 ; 2.  R [2], h 5, h 6, h C, s 10, s 11, s 12 ; 3.  R [3]; 4.  R [4]; 5.  R [5], h 13, h 14, s 15 ; 6.  R [6];  R [1]=2  R [3]=6  R [4]=1  R [5]=3  R [6]=5 r2r2 r1r1 r3r3 r4r4 r6r6 r5r5

 The client checks  R records  correctness of the sort order  R of R  boundary records  whether the re-constructed root hash of T S matches its signature 18

 Query processing  Require ADSs on both relations  Start with one relation R, traverse its ADS T R down to the first tuple r 1  Traverse T S until reaching the right boundary record s of r 1  Traverse T R until reaching the right boundary record r of s  Alternatively traverse T S and T R similarly to the above  Verification: similar to AISM 19

20 VO: root signature of T S, root signature of T R, r 1 1. h s 1, s 2, s 3, s 4 ; 2. r 2 ; 3. h s 5, h s 6, h C, s 10, s 11, s 12 ; 4. r 3, r 4 ; 5. r 5 ; 6. h s 13, h s 14, s 15 ; 7. h r 6 ;

 Idea  Sort-Merge-Join, sort at the server, merge at the client  Query processing  Require no ADS  Transmit both R and S in their verifiable order  Sort R and S respectively on the join attribute  Transmit the sort orders of R and S to the client  Transmit bitmaps B R and B S to the client, indicating the tuples with join partners  Verification  correctness of the base relations / sort-orders / the bitmaps 21

 Multi-way joins  Selection-Projection-Join queries 22

 Build a tree of binary join operators  m-ASM / m-AISM / m-AIM optimized for multi-way joins  Example:  A specialized algorithm AST applies when all relations are joined on the same attribute  One single VO 23

VO(RS):{root signature of T R and T S, s 1, s 2 ; h A, r 4, r 5, r 6 ; s 3 ; s 4 ; s 5 ; h C } VO(RST):{root signature of T T,  [1], t 1, t 2 ;  [2];  [3];  [4]; h t3 } 24

25

26  Selection  Use the m- algorithms for joins  Projection  Build a Merkle Hash Tree for each record  Query optimization

27  Three synthetic relations  R(a 1, a 2 )  S(a 1, a 2, b 1, b 2 )  T(b 1, b 2 )  Queries  R a 1 S  R a 2 S  ( R a 1 S ) b 1 T  ( R a 2 S ) b 2 T  Foreign keys  S.a 1 references R.a 1  S.b 1 references T.b 1  Parameters  Tuple size  Cardinality of |S|

 We participated in the ACM SIGMOD 2009 Repeatability & Workability Evaluation (cf.,  The reviewers were able to  repeat all the experiments presented in our paper,  yielding results that match the ones published in our paper,  except from insignificant and to be expected variation due to randomness and/or hardware/software differences.  The detailed reports will shortly be made publicly available by ACM SIGMOD. 28

29

30

31

32

33

 Binary join authentication  AISM: authenticated structure on one relation  AIM: authenticated structures on both relations  ASM: no authenticated structure  Complex query authentication  Multi-way join: eliminate unnecessary intermediate VO elements  Selection-projection-join query  Future Work  Authenticated Structures specialized to joins  Hash join instead of SMJ 34

35