Define privacy threat model for DHTs (and other overlay P2P networks)

[gpestana]

The idea here is to define a comprehensive privacy threat model for distributed hash tables and similar P2P overlay networks. Focusing on privacy attack surface and metadata leaks of networks that rely on collaboration between peers to resolve and request content in a P2P network. The main goal is to lay the foundation for thinking and designing privacy preserving P2P networks.

It would be interesting to consider a layered threat model. I imagine a world where P2P networks will be the scaffolding for not only for sharing cat pics but also for secure messaging/ secure peer discovery, etc. This means that use cases and users will have different concerns and a different threat model.

scope/ideas to consider:

• what can an overlay neighbour learn about my behaviour on the network?
• what can a local neighbour learn about my behaviour on the network?
• given a set of network requests by the same peer, is it possible to link them together?
• given a network request, is it possible to derive who's behind it?
• global adversaries vs local adversaries
• "disgruntled former colleague" and "celebrity stalker" (Tracking protection libp2p/libp2p#67)

[gpestana]

References to read

[1] Cwtch: Privacy Preserving Infrastructure for Asynchronous, Decentralized, Multi-Party and Metadata Resistant Applications

[2] Talek: a Private Publish-Subscribe Protocol

[3] Ricochet protocol

[4] SoK - Secure messaging

---

[1] Cwtch: Privacy Preserving Infrastructure for Asynchronous, Decentralized, Multi-Party and Metadata Resistant Applications

[1] builds on top of the Ricochet protocol to create an asynchronous, metadata resistant group chat protocol. Moreover, it aims at providing a framework to build metadata-resistant applications, which generalises group chat use case.

[1] defines a metadata resistant application one which do not disclose any information about Who is involved in the communication; Where the participants are communicating from; When did the communication take place; How was did the communication take place; What was the communication about; Apart from these properties, a metadata resistant application should also not leak information about relationships and behavioural patterns of its users.

---

[4] SoK - Secure messaging

[4] evaluates current secure messaging solution and proposes an evaluation and threat model considering 1) security 2) usability and 3) ease-of-adoption properties.

the authors consider the key challenges for secure messaging protocols to be: a) trust establishment, b) conversation privacy c) transport privacy, and studies several protocols in terms of those challenges. Trust establishment consists of ensuring secure distribution of secrets. Conversation security consists of securing communication while it is occurring. Transport privacy consists of hiding communication metadata. Transport privacy is seen as the most difficult problem to solve.

[4] threat modelling includes 3 types of attackers: 1) local adversaries, who are attackers controlling the local network; 2) global adversaries: attacker controlling large segments of the internet (e.g. governments); and 3) service providers: in the case when the services are centralised to some extent, the service providers are considered potential attackers. These categories of attackers are not mutually exclusive.

[4] studies several chat protocols and applications security based on the 3 main problem areas when creating a secure chat system: trust establishment and communication and transport privacy. We will focus more on the 3rd problem area, transport privacy, since it is essential for metadata resistance protocols.

[gpestana]

Threat model of DHTs - user cases

We can start by defining the threat model from a bird's-eye viewpoint, considering a user perspective and based on hypothetical uses cases. Considering that a user is running a full DHT node capable of routing, requesting and storing data:

Case 1: User wants to download data with id = X and performs a DHT lookup using its unique ID.

Potential privacy risks:

• adversaries serving the content of data with id = X may eventually learn that user is interesting in it;
• adversaries in the lookup/routing path may be learn about who is interested in the data with id = X

Case 2: User is interested in serving a certain data and "pins" it.

Potential privacy risks:

• storing and serving particular data leaks information about user interests;
• explicit and implicit pinning/replication reveal similar information about the user who's doing it. In both cases there is a clear and public statement about the user's interest in the data;

Case 3: User is serving (pinning) its own data.

Potential privacy risks

• adversary may easily deduce the peer network identity (e.g. IP) by simply requesting it. A good example by @pvh is a case when a well known personality pins her own about.me webpage. The adversary can deduce with high probability that the node pinning the content is its owner.
• the attack surface increases with the amount of personal data pinned by a user, which makes it easier to remove "false positives" (ie. nodes pinning the content which are not its owner).
• few resources are needed to perform this attack (only few DHT lookups are required) and it is potentially very hard to detect it.

The use cases above are abstracted and general to how DHTs work. Those are the intrinsic privacy leaks in vanilla DHT implementations. In addition to those, some implementations have network specific "sub-protocols" and "sub-systems" that aim at improving scalability, fairness, (etc..) of the network. Unfortunately, those may increase the privacy attack surface. One example is bitswap, which is a data trading protocol that controls how to request and send data blocks between peers (I'm not sure if that's the case for bitswap though, but it is a good example of an addition that may increase the attack surface).