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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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)

10. 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)

11. 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)

12. 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

13. 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

14. 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

15. 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

16. Thanks for listening!
Questions?