GhostDB: Hiding Data from Prying Eyes Technology

1
GhostDB Hiding Data from Prying Eyes (Technology)

• Christophe Salperwyck, Nicolas Anciaux, Mehdi
  Benzine, Luc Bouganim, Philippe Pucheral,
  Dennis Shasha
• SMIS Project (INRIA-UVSQ), New York University

2
Outline

• Scenario problem
• Hardware solution
• Database solution

3
Scenario

• You have been entrusted with private data
• e.g., corporate, medical, or government data
• You want to issue queries combining private and
  public data
• Private data must never be revealed
• Private data can be accessed from any computing
  system (also untrusted computing environments)

4
GhostDB Approach

• Pro security
• A spy can only see the user query and visible
  data
• Cons efficiency
• Part of the processing done by a low power device
  
• Useless visible data may be transmitted to the
  secure USB token

5
Unsafe optimization

• Visible data flow reduction using hidden
  computation knowledge
• Pro efficiency
• Visible data transmitted can be reduced to a
  minimum
• Cons security
• A spy can deduce hidden information from the
  query sent to the server

6
Hidden / Visible Data definition

• Create table command changes slightly
• Some columns are declared Hidden
• never seen outside the secure USB token
• Create table Patients (
• PatID int primary key,
• Name char(200) hidden,
• Age int,
• BodyMassIndex float hidden,
• Country char(100))
• Standard SQL queries

7
Hidden / Visible Data definition (2)

• Rules of Thumb
• Primary keys are both hidden and visible
• Foreign keys are hidden to eraseconnections
• Status of other fields depends on application

8
The secure USB token

• Secure USB token
• A secure chip (similar to smart card chip) with a
  powerful CPU
• Some GB of NAND Flash memory
• Hardware constraints
• Small RAM (tens of KB). VERY SMALL!
• Asymmetric costs for reads and writes in flash
• Page read time ? 25 ?s ( 50ns/byte)
• Writes are 3 to 12 times slower than reads.

9
Problem formulation

• How to deal with large tables under the secure
  USB token hardware constraints ?
• How to mix visible and hidden computations
  efficiently and without information leak ?

10
How to deal with large tables under the secure
USB token hardware constraints?
11
The case for a fully indexed model

• Classical join algorithms need a large RAM
• HashJoin, SortMergeJoin
• Join indices could be a solution but consecutive
  joins incur random access or a RAM-hungry sort

Goal multi-join queries with restrictions on a
large hidden database while satisfying the RAM
constraint
12
GhostDB indexing model

• Assumption
• Traditional database schema, organized as a tree
• Root table refers to the largest central table
• Node table refers to any table connected to the
  root
• Two index structures
• Subtree Key Table (SKT)
• Precomputation of all foreign-key based joins
• Climbing Index
• Allow selecting tuples in any node table and
  reaching tuples connected to them in any ancestor
  table in a single step
• Lets assume all hidden attributes be indexed

13
SKT Climbing Index
14
Query plan (on hidden attributes)

• SELECT Med.Name, Pre.Quantity, Vis.Date
• FROM Medicine Med, Prescription Pre, Visit Vis
• WHERE Vis.Date gt 11/2006
• AND Vis.Purpose Sclerosis
• AND Med.Type Antibiotic
• AND Med.MedID Pre.MedID
• AND Vis.VisID Pre.VisID

15
How to mix visible and hidden computations
efficiently and without information leak?
16
Query example

• The query considered in the next slides is
• SELECT Med.Name, Pre.Quantity, Vis.Date
• FROM Medicine Med, Prescription Pre, Visit Vis
• WHERE Vis.Date gt 11/2006 /VISIBLE/AND
  Vis.Purpose Sclerosis /HIDDEN/AND
  Med.Type Antibiotic /VISIBLE/AND
  Med.MedID Pre.MedID
• AND Vis.VisID Pre.VisID

17
Naive Strategy

• Strategy
• Hidden selections and joins on secure
• Visible selections on untrusted
• Join the results on secure
• Drawbacks
• Hidden joins done before Visible selections
• No index for final joins
• ? classical join algorithm

18
Pre-filtering Strategy

• Strategy
• Do all selections first (hidden and visible)
• Use climbing Indexeson ID for visible
• Join using SKT
• Grab atts for projections
• Pros
• Avoid regular joins
• Take advantage of selectivity of visible
  selections
• Cons (if low selectivity)
• Many Index lookups
• Expensive merge operation

19
Post-filtering Strategy

• Strategy
• Do hidden selections
• Join using SKT
• Fuzzy filtering for visible selections using
  Bloom filters
• False positives are eliminated during projection
• Pros
• Still avoids regular joins
• Robust to low selectivity of visible selections
• Cons (if high visible selectivity)
• Increases the join cost
• Induces false positives