Internet friends who would like to connect with each other (e.g., VoIP, chat) use point-to-point communication applications such as Skype or WhatsApp. Apart from providing the necessary communication channel, these applications also facilitate contact discovery, where users upload their address-book and learn the network address of their friends. Although handy, this discovery process comes with a significant privacy cost: users are forced to reveal to the service provider every person they are socially connected with, even if they do not ever communicate with them through the app. In this paper, we show that it is possible to implement a scalable User Discovery service, without requiring any centralized entity that users have to blindly trust. Specifically, we distribute the maintenance of the users’ contact information, and allow their friends to query for it, just as they normally query the network for machine services. We implement our approach in PROUD: a distributed privacy-preserving User Discovery service, which capitalizes on DNS. The prevalence of DNS makes PROUD immediately applicable, able to scale to millions of users. Preliminary evaluation shows that PROUD provides competitive performance for all practical purposes, imposing an overhead of less than 0.3 sec per operation.

1. Where’s Wally? How to Privately
Discover your Friends on the Internet
Panagiotis Papadopoulos
University of Crete
& FORTH-ICS, Greece
Antonios A. Chariton University of Crete
Elias Athanasopoulos University of Cyprus
Evangelos P. Markatos FORTH-ICS

2. Real-time communication

3. The growth of real-time communication
Source: visualcapitalist.com

4. How does it work?
Step 1: User Discovery
Alice wants to
talk to Bob
Central Directory
Server

5. How does it work?
Step 2: Point-to-point secure
connection establishment
Alice wants to
talk to Bob
Central Directory
Server
"No Woman, No Cry"
"Hello Bob"

6. Hey! Wait a minute!

7. Mobile Instant Messaging (MIM) apps
• All contemporary MIM applications
leverage the phone’s address-book
• Frequently checks for newly registered
with the app friends

8. Privacy of the social graph
Step 1: User Discovery
Alice wants to
talk to Bob
Central Directory
Server
Bob +82-2-312-3456
Charlie +82-2-378-9012
David +82-2-334-5678
Alice is friend
with Bob, Charlie
and David
But, I am not
even a
WhatsApp user!
Bob
Charlie
David
Charlie gets his telephone number and his social connection
with Alice leaked to an app that he does not use!

9. The cost of “free” MIM apps (1/2)
Contact list Tel. number Current IP
Bob +82-2-312-3456 216.3.128.12
Charlie +82-2-378-9012 (not a WhatsApp user)
David +82-2-334-5678 136.79.128.22
Alice’s friends:
Cost:
• Relinquish the privacy of your social graph
App provider can
- reconstruct a global social topology (i.e., who is socially associated with whom)
- Infer interests, political beliefs, sexual preferences*
Such user info can then be sold to advertisers or handed over to agencies
* C. Jernigan and B. F. Mistree. Gaydar: Facebook friendships expose sexual orientation. First Monday, 14(10), 2009.

10. The cost of “free” MIM apps (2/2)
Even if service provider is benign:
• Concentration of important data lures attackers,
resulting in data breaches
• Bad design or bad maintenance may leak information
(e.g., Skype’s famous user IP leak*)
*R. Naraine, “Skype leaking user IP addresses, TCP ports”, https://www.zdnet.com/article/skype-leaking-user-
ip-addresses-tcp-ports/, 2012

11. Is it possible to build a User
Discovery service, without
revealing the user’s social graph?

12. In this paper
• We decouple the User Discovery operation from
the communication app.
• 1 User Discovery service to cover all related needs of user
(VoIP app, file sharing app, etc.)
• Users maintain their own User-to-IP mappings
• Delegate trust among users
(only friends can read these mappings)
App 2
Directory Server
App 1

13. Objectives
• A key-value datastore
• Existing system Immediately applicable
• Scalable Support increased load
• Distributed management No single maintaining entity

14. Don’t we use such a discovery
system on the web too?
How do you know the Network Address of www.cnn.com before fetching it?
The DNS!

15. Our Approach:
PROUD (PRivacy-preservation Of User Discovery)

16. Our Approach: PROUD
• PROUD: a scalable privacy-preserving user discovery service
1. enables users to control their current network address
without relying on any centralized infrastructure
2. allows users to find the network addresses of their friends
without revealing their social associations.
3. Thus goals are:
a. protect both data (user’s current IP address)
b. and metadata (who queries for whom).

17. PROUD in a nutshell
• Distributed directory service
• One dead-drop (key-value) per friendship
• Alice does not query for the entire address book but
for the particular user’s dead-drop
• Simple Set/Get operations
• 2 non-colluding nodes Resolvers and Registration nodes

18. Dead-drop
• DNS type TXT record
• Index:
o R: pseudorandom number generator
(Periodic change -> Forward Secrecy to Alice’s queries)
o SE: seed that Alice and Bob know
üR(SE).example.com
• Payload:
a) EpubA(K): Session key
b) EK(IPB): IP of Bob encrypted with the Session key
c) SprivB(H(EK(IPBT))): Timestamped and Signed payload
üEpubA(K) | EK(IPB) | SprivB(H(EK(IPBT)))

19. App 2
PROUD example
"No Woman, No Cry"
"Hello Bob"
Set friendship
dead-drop
Get friendship
dead-drop
Authoritative
Nameserver
(Registration node)
Local DNS Resolver
(Resolver node)

20. Performance Evaluation

21. Performance Evaluation: Latency
• Execution time per set
friendship operations
• Latency overhead <0.35 sec on
average per operation due to
cryptographic computations

22. Performance Evaluation: Scalability
It takes <3.5 seconds and around 0.3 KBps for Bob
to update a large address book of 500 users.

23. Conclusion
• We decouple User Discovery from MIM applications
• PROUD: a scalable privacy-preserving user discovery service
• protects both
üdata (user’s current IP address)
üand metadata (who queries for whom).
• Leverage existing DNS network
• minimal bandwidth requirements
• practically negligible latency to the user experience
(<0.35sec/operation)

24. Backup slides

25. Users behind NAT?
• NAT hole punching
• Like what Skype was doing back in its p2p days
• IPv6
• Current metrics put IPv6 at a minimum of 20% global adoption, and
local uses (within a country) to over 50%.
http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.htm

26. Client Server model
vIn some apps, users may communicate through an intermediate
server with their friends
vUser Discovery is still needed:
• In iMessage a user has to first retrieve friend’s public key from Apple’s
Directory Server
• In WhatsApp and Messenger, the client uploads at registration time
ütheir public Identity key and
üa batch of public One-Time Pre keys to a centralized server in order for any friend to
initiate a secure conversation.