Ensuring Correctness over Untrusted Private Database Written by: Sarvjeet Singh Sunil Prabhakar

Meet Bob and Alice Bob owns a database Alice needs to query the database Bob wants to ensure that Alice only has access to the parts of the database she needs, and no more than this Alice wants to ensure that the query results or database itself were not altered by Bob before he returns the result to her

Background Info Possible solution: 3rd external, trusted entity Expensive in terms of traffic and storage Potential weakness/liability Freezing data Related work Too much trust in database owner

What is "correctness"? α-correctness β-correctness Correctness of result values Values returned match values frozen β-correctness Correctness of query execution Joins and selections done correctly Checks for missing valid tuples from result set Independent of each other Together imply correctness of query results

First you need to know... One way hashing Merkle trees Two important requirements Hard to work backwards Low probably that h(x) = h(y) and x≠y SHA-256 Merkle trees Binary tree with labeled notes Derivation of parent nodes Authentication path

About the solution Proof of integrity (PoI) Verification Shipped whenever Bob freezes the data Verification Only when Alice suspects foul play Public hash function h Focuses on α correctness

Solution 1 PoI: Bob computes hash of entire database, sends it to Alice Verification: Bob ships entire database contents, Alice computes hash and makes such it matches what Bob originally sent Pro: Bob only sends one number Con: Violates Bob's privacy

Solution 2 PoI: Strong hash function, Bob computes hash for each tuple and sends results to Alice Verification: Alice only needs this to verify results Pro: Respects privacy Con: Not practical - size of proof proportional to size of database PoI probably sent more often than verification done

Solution 3 PoI: Bob computes hash for each tuple, then computes hash of this result Results in hash-tree of height 1 Verification: Alice computes hash over 2 sets Pro: Respects privacy, proof size reduced to one number Con: Greatly increased verification size (okay if verification rare)

Solution 4 PoI: Bob computes Merkle tree, sends the hash of root as proof Verification: Bob sends authentication path, Alice computes hash over received result and the hash values along the given path Pro: Respects privacy, one single hash as PoI (like 3), verificaton reduced from O(N) to O(logN)

Solution 5α New way to define label of a leaf node Concatenate the labels of the attributes in a tuple and concatenate this with the label id, take the hash value of this With this finer granularity, have greater database privacy (don't need to reveal all attributes)

Solution 5α (continued) If hash function has a small domain, need to concatenate hash of data value with secret value, called "salt" Now the label for attributes is the hash of the attribute value concatenated with the salt The salt of the attribute is the hash of the attribute value concatenated with the tuple id and the table id

Solution 5β: β -correctness too Want to ensure all results of query sent Assume only equality joins For labeling the nodes: Attribute's salt is Bob's digital signature on the value with private key d (with public key e) The label of the attribute is the hash of the attribute value concatenated with last step's salt The label of a leaf is the hash of the tuple id concatenated with the labels of attributes from last step The label of the root is the hash of the concatenation of the last step's results

Solution 5β: β -correctness too (cont.) For the proof, Bob sends only the hash of the root for each table to Alice For verification, Bob also sends the hash of all attributes involved in the selection, with their salts She checks hash of root Checks that the hash of the attribute concatenated with its salt is a label in the tree Alice also uses Bob's public key e to verify that the tuples returned match Bob's signature

In the real world/wrap-up Implementation PostgreSQL-Hash function SHA-1 from crypto library Database commands: send_proof, send_verify Send_proof: DB sends single hash value Send_verify: DB returns authentication paths for all the tuples being verified Overhead is on the same order as the cost of inserting data Future work Will address β-correctness for general queries

Thanks for listening! Questions?