Privacy in Mobile Systems Karthik Dantu and Steve Ko

πBox: A Platform for Privacy-Preserving Apps Most mobile apps have access to a lot of sensitive information such as passwords, sensor information, and user inputs Applications therefore come with an implicit tradeoff between privacy and functionality Current confinement mechanisms are very coarse- grained and request more permissions than required Sensitive information is also sent to the cloud in many cases

πBox Architecture Move trust to the platform; do not trust user apps or rely on users for fine-grained privacy decisions Sandbox confines user app and associated execution in the cloud Able to provide differential privacy guarantees

πBox Architecture Apps running within πBox cannot write to the device or establish network connections outside of the sandbox Five restricted storage and communication channels Private Vault: App specific Content Storage: Per-publisher storage Aggregate Channel: Channel to collect per-app statistics Inbox: Storage for user of the app to receive info from app’s publisher and other users Sharing channel: To share content with other users of the same app

Advertising on πBox Typical ads in Mobile Apps Advertisers provide ad networks ads to display Specify per-impression price Ad networks organize ads into lists based on numerous factors When app wants to display an ad, the ad network provides the ad based on perceived user interest Ads in πBox Ad network stores its ads in content storage on πBox Information released to ad network via aggregate channel Ad logic to be implemented in the app Publishers can share content storage across apps

Differential Privacy Computation F satisfies ε-differential privacy iff Pr[F(D) \in S] <= e ε.Pr[F(D’) \in S] where {D – D’} is an individual user’s input Laplacian mechanism: Add white noise to obfuscate each user’s contribution Delayed output counters Supports ranked top-K lists

Implementation Client isolation Android UIDs Cannot write world-readable files No IPC No communication Cloud isolation Servlet container implementation using Jetty Local intents for authentication via πBox local trusted authentication service

Koi: Location Privacy for Apps Most mobile apps require access to location information Invariably this involves tradeoff between accuracy and privacy Koi proposes a privacy-preserving location matching service Key idea: Switch to location matching instead of location lookups Koi design: Callback-based matching API Privacy-preserving cloud-based matching service Rich, semantically-meaningful, multi-attribute matching to satisfy diverse app requirements

Koi Architecture

Koi Platform API Service model similar to a database trigger Items: Users or content Attributes: Locations, keywords, arbitrary data Triggers: Specify one or more attributes that must match When item matches a trigger, app registering the trigger is notified via the specified callback

Koi Example

Registration R1: Client encrypts attribute first with matcher’s public key, and then combiner’s public key, and sends it to matcher R2: Matcher picks random ID (rid), and sends double encrypted data to combiner. Matcher has rid to user table R3: Combiner decrypts data to get data encrypted by matcher’s public key. It picks a random attribute ID (aid) for each attribute. Sends each encrypted attribute with aid to matcher Combiner has aid to rid table Matcher decrypts and builds attribute to aid table

Attribute Matching M1: Matcher returns set of attributes matching given attribute k M2: Combiner looks up all rid’s corresponding to the attribute set returned by M1

Combining C1: Matcher looks up users corresponding to rid for callback Returns user data for the callback handle and user data for matched item content

Mobile Social Network Each user adds location attribute (line 5) Also adds application attribute with

Example: Turn-by-turn Directions