Privacy-Preserving Location- Dependent Query Processing Mikhail J. Atallah and Keith B. Frikken Purdue University

Framework Mobile device queries remote database Queries depend on geographic location –“Get address of nearest gas station” –“Is there a restaurant from here to destination” Much previous work –Caching and performance issues, updating strategies for dealing with rapid change, continuous motion models, etc.

Our Framework Our focus is on privacy of client’s location Proximity queries (“nearest site”) Query contains client’s precise location Answer reveals client’s rough location Goal is to avoid revealing precise location –OK to reveal answer and rough location –Hiding answer from server ? Not in this work

Approach 1: Perturbation Random perturbation of client’s location –Chosen by client –Variable, and not known to server Large enough to “hide” exact location (privacy) Small enough to avoid “too much damage” to quality of answer Issue: Quantifying the damage to answer

Perturbation Results Add to query position a vector of length L and of random direction Worst-case damage to answer is 2L –The bound is tight Average-case damage to answer is L –Probabilistic model: Independent and uniformly distributed queries, sites, perturbation angles

Approach 2: Grid Method The plane is covered with squares tiles Client sends as “query” the tile that contains the true query point –Hence tile size known to both client and server Large tiles imply better privacy, but also a cost –Cost in efficiency (if exact answer) –Cost in quality of answer (if most efficient)

Grid Method Variants Variant 1: Server returns all sites nearest to query tile’s points –Returned sites can be outside the query tile –Client chooses the best site among them –Costly in communication, but no sacrifice in answer quality Variant 2: Server itself chooses 1 to return –Return the site with the most “votes”

Grid Method Results (Variant 2) Quantifying the damage from “gridding” in terms of D = tile diameter Worst-case damage to answer is D –The bound is tight Average-case damage to answer is 0.27D –Probabilistic model: Independent and uniformly distributed queries and sites, fixed tiling

Approach 3: Crypto Protocol Client gets correct answer –Learns nothing else about the database Server learns nothing other than the answer to the query “As if” server knew query (even though doesn’t)

Protocol-Based Solution (1) Server builds hierarchical search DAG (a “Kirkpatrick” structure) on top of a Voronoi Diagram of the n sites –Height h of DAG = O( log n ), size O(n) –Each node of DAG = a geometric triangle A query is processed by tracing a root-to- leaf path in the DAG –Leaf contains 1 site -- the answer

Protocol-Based Solution (2) “Is query point in or out of triangle v” –Up to d such comparisons at a node of the DAG –Must be done without revealing the query point to the server (and, if required, without the server sending the triangles to the client) Search steps down the DAG can be thought of as successive geometric refinements –Opens way for “excessive refinement” attack

Protocol-Based Solution (3) Excessive refinement: Server continues querying even after a leaf is reached To mitigate, client can store or receive a “certified” d*h and refuse to engage in more than d*h point-triangle comparisons But: d*h is only an upper bound –# comparisons needed can be less than d*h –Discovery, by server, of a more efficient search structure increases ability to refine

Future Work (in Progress) Computing proximity between routes –Whether planned route gets near (or avoids) another party’s own planned route –Whether route is within (or avoids by at least) a distance of d another party’s set of points Do so without either party revealing their data to the other, and without using a third party (even an untrusted one)