1 Tryst: Making Local Service Discovery Confidential Jeffrey Pang Ben Greenstein Srinivasan Seshan David Wetherall

2 What is Local Service Discovery? Find an networkFind a local printer Authentication Setup encryption Find my friend’s PSPFind my friend’s iTunes Proceeds automatically, often without user’s knowledge

3 Method 1: Announcement Services broadcast their existence Interested clients discover them E.G., APs announce network names (SSIDs)

4 Privacy Threats: Inventory “The devices I have” –Example: cell phone pirates break into cars to steal phones that announce their presence [Cambridge Evening News 2005] “The applications I am running” –Example: Apple mDNS “announces” to hackers that they are vulnerable to a buffer overflow [CERT 2007] Phone Here! iTunes here! iChat here!

5 Method 2: Probing Clients broadcast queries for familiar services Present services respond E.G., clients probe for SSIDs they have associated with before

6 Privacy Threats: History “Where I have been before” –Example: Probing for SSIDs can expose where you live [WiGLE Wardriving Database] Is “Anna, Jeff, and Mark’s Net” here?

7 Privacy Threats: History “Where I have been before” –Example: Probing for SSIDs can expose where you live [WiGLE Wardriving Database] 23% of devices at SIGCOMM 2004 probed for an SSID that WiGLE isolates to one city

8 Privacy Threats: History “Where I have been before” –Example: Even opaque SSIDs can be correlated with other databases, such as Google’s business directory Is “Juvenile Detention Classroom” here? Is “ ” here?

9 Solution Requirement Security during discovery –Confidentiality: unlinkable discovery attempts –Authenticity: prevent masquerading –Departure from common practice –Clients and services want privacy from third parties Tryst –Access control for discovery messages

10 How to Provide Access Control Service Discovery Message Verify Source Identity Sender ApplicationReceiver Application Proof of Identity Identity-Hiding Encryption

11 Protocol Design Details Existing theoretical protocol [Abadi ’04] –Based on public key cryptography Problem 1: Message size scales linearly with number of intended recipients –Typically OK: 90% of clients probe for fewer than 12 unique SSIDs [OSDI 2006] Problem 2: Messages can’t be addressed  must try to decrypt every message –Decryption is 168x slower than line-rate –Opens up receivers to denial-of-service attacks

12 Protocol Design Details Observation 1: Common case is to rediscover known services –Can negotiate a secret symmetric key the first time –Symmetric key cryptography is fast Observation 2: Linkability at short timescales is usually OK –Compute temporary unlinkable addresses known only to a client and a service [similar to Cox ’07] –Messages not for me are discarded at line-rate Thus: –Prioritize symmetric key protocol –Use spare cycles for public key protocol

13 How Do I Obtain the Initial Keys? Existing key establishment is not enough –Pairing: E.G., Bluetooth peripherals Can not always physically identify service User must discover service before device discovers service! Discovery is also used to find new services –Goal: Automatically expand the trust horizon –E.G., new services in trusted domains –E.G., new services trusted transitively

14 New Services in Trusted Domains Bob Alice Trusted ? x x Strawman Solution x “Discover Alice’s iPhone”

15 ? New Services in Trusted Domains Bob “Discover Alice’s iPhone” Alice Trusted Trusts: “alice.ds” “alice.laptop” “bob.zune” “bob.psp” “bob.laptop” Anonymous Identity Based Encryption “alice.iphone”

16 Conclusion Local service discovery exposes sensitive info Tryst enables confidential service discovery Progress: –Implementation of Tryst access control –Integration with a real protocol stack Future Work: –Implement automated key establishment –Evaluate how people use Tryst in the wild

17 Questions?

18 Service Discovery is Widely Used Example 1: 85% devices send probes (SIGCOMM 2004) Example 2: Application Protocols (OSDI 2006)

19 Privacy Threats: Location “The fact that my service is present” –Example: Common practice to disable beacons to (try to) hide access points [O’Reilly Guide] “Where my service is located” –Example: Knowledge of SSID at one site can tell you where other sites are [WiGLE Wardriving Database] IR_Guest Pittsburgh Seattle Berkeley Cambridge x

20 Privacy Threats: Identity “Fingerprints who I am” –Example: Both and application level probes accurately identify a person [Our MobiCom 2007 Paper] “IR_Guest”, “djw”, “University of Washington” “IR_Guest”, “djw”, “University of Washington” == ………..

21 Privacy Threats: History “Where I have been before” –Example: Probing for SSIDs can expose where you live [SSID Lookup in WiGLE] Is the network “djw” here?

22 More Threats in the Future Emerging social devices also offer “services” –Microsoft Zune: music sharing service –PSP, Nintendo DS: multiplayer gaming service Service discovery exposes social contacts

23 Reasons for Privacy Threats Plug-and-Play  Automatic Infrastructure Independent  Broadcast Before Security Setup  No Authentication, Encryption We tackle this problem

24 New Services Transitively Trusted Alice Bob “Alice’s Home” Trust Transitive Trust Alice trusts bob.laptop Alice’s secret Alice trusts “Alice’s Home” Alice’s secret Find networks that Alice trusts Attestation