owned this note
owned this note
Published
Linked with GitHub
# [WIP] Waku v2 Privacy/Anonymity: Questions and Answers
[tracking issue](https://github.com/vacp2p/research/issues/106)
(For some of these questions and answers,
backup slides could be prepared which helps answering questions in a satisfying way.)
## What Privacy Guarantees does Waku Offer?
Privacy allows users to choose which data and information
* they want to share
* and with whom they want to share it.
This includes data and information that is associated with and/or generated by users.
Protected data also comprises metadata that might be generated without users being aware of it.
Waku is privacy-preserving. It offers:
* confidentiality
- message content is only disclosed to the indented receivers
- we have various mechanisms in pace to guarantee this, the strongest one being the [Noise Protocol Framework](https://noiseprotocol.org/).
* meta-data protection
- todo: what meta-data (outside of anonymity related) has to be protected by the privacy-preserving property
## What Anonymity Guarantees Does Waku Offer?
We subdivide anonymity into receiver anonymity and sender anonymity. (add unlinkability later; overlaps with current definition)
Waku comprises many protocols that can be combined in a modular way.
The following focuses on the relay protocol, which is at the core of Waku.
Waku relay is responsible for the propagation of messages through the network.
We are working on a series of articles that eventually will cover anonymity aspects of all Waku protocols, leading to a comprehensive privacy/anonymity analysis of Waku v2.
### receiver anonymity
* summary :: Waku offers k-anonymity regarding content topic interest in the global adversary model
We focus on receiver anonymity with respect to interest in specific content topics.
So, in the context of Waku, receiver anonymity is subscriber-topic unlinkability.
For now, Waku uses a single libp2p pubsub topic, which means messages are propagated via a single mesh of peers.
On the gossipsub layer the receiver discloses its participation in Waku.
Waku features another layer of topics: content topics for messages.
Assuming there are $n$ Waku content topics, a receiver has $n$-anonymity with respect to association to a specific content topic.
If we would introduce several pubsub topics, assuming a specific pubsub topic (WLOG) has $k$ content topics,
a receiver would have k-anonymity with respect to this content topic.
Note regarding gossipsub receiver anonymity in general: nodes disclose their interest in pubsub topics, which might already be critical.
Countermeasure: merge pubsub topics to gain k-anonymity. Risk: efficiency loss.
Waku is not directly concerned with 1:1 communication, which can be build on top of Waku.
For now, 1:1 communication is out of scope.
#### Waku protocols that compromise receiver anonymity
* store protocol
- allows filtering by content topic
- countermeasure: use content topic exclusively for local filters
* filter protocol
- discloses nodes' interest in topics
* lightpush
- discloses nodes' interest in topics
* ftstore
- discloses nodes' interest in specific time ranges
- this might allow inferring information like online times...
* ...
Generally nodes should either
* never communicate their interest in a specific content topic
* specifically address receiver anonymity with respect to content topics
An example for specifically addressing receiver anonymity on a layer above Waku:
partitioning a single actual content topic into $l$ virtual topics.
This could be used for [receiver anonymous 1:1 messaging](https://specs.status.im/spec/10#partitioned-topic).
### sender anonymity
* summary :: Waku offers weak sender anonymity in the local attacker model.
Waku does not offer sender anonymity in stronger attacker models.
We focus on sender anonymity with respect to having sent specific messages.
So, in the context of Waku, sender anonymity is sender-message unlinkability.
Guarantees with respect to various adversarial models:
* (passive) global adversary model :: *no* (see below)
- in practice: can most likely also run attacks of the botnet class
* (passive) AS attacker :: *no* (see below)
- in practice: can most likely also run attacks of the botnet class
* linearly scaling botnet :: *no* TODO
* (passive) local two nodes attacker :: limited protection
* (passive) single node local attacker :: yes in most cases, but no if the attacker node manages to share the same peers
Also consider: Sender anonymity with respect to topics.
The sender should be unlinkable to topics it sends messages to.
This is included in message-sender unlinkability and can be seen as a weaker property.
Note: fan-out relaying provides some level of anonymity here.
## Why do we need Waku if we have Tor? (Waku vs Tor)
Waku and Tor where designed for different purposes:
the main propose for Tor is anonymous web browsing, the Waku's main purpose is messaging.
Tor and Waku are actually orthogonal.
Waku can employ onion routing, e.g. Tor, for anonymizing the step from a sender to the first relay node.
Waku is not depended on onion routing to achieve this,
and will be able to employ various further pluggable anonymizing techniques among them mix-nets like Nym and more ligh-weight solutions like Dandilion++.
This does not mean that Waku has to offload anonymity protections to other existing systems: we also plan to integrate comparable mechanisms into the modular Waku v2 protocol family.
That said, there are messaging apps that use Tor as a transport for messages: [briar](https://briarproject.org/how-it-works/).
See section [How does Waku compare to Briar](#how-does-waku-compare-to-briar).
## What are Tor's Anonymity Guarantees?
Tor offers anonymity in the local attacker model.
Onion routing protects against malicious Tor nodes as long as nodes associated with a single circuit do not collude.
Tor protects anonymity in the AS attacker model, given the onion routers associated with a circuit are in different (non colluding) ASes.
In the linearly scaling botnet model ($p\%$ of the nodes are malicious), the attacker nodes are expected to be evenly distributed (assuming they are evenly distributed in the network and the directory nodes are not corrupted).
This means, an attacker cannot make it more likely for compromised nodes to be chosen by the path selection algorithm (there might be subtleties and attacks I am not aware of).
[Tor does not offer anonymity](https://support.torproject.org/about/attacks-on-onion-routing/) in the global on-net attacker model.
This attacker can monitor both the entry and the exit node.
If at least two nodes on a circuit are in the same AS, the AS level attacker can perform a correlation attack, too.
Simply put, correlation attacks correlate the ingress traffic on the entry node with the egress traffic on the exit node.
Volume of traffic and timing are indicators of traffic belonging to a single stream.
If ingress and egress traffic streams can be correlated, the client has been (partly) deanonymized: the attacker knows with whom the client established a connection.
Tor can achieve receiver anonymity via onion services (formerly known as hidden services).
Tor offers mitigation against censorship with [bridge nodes](https://community.torproject.org/relay/types-of-relays/) and [Pluggable Transports](https://www.pluggabletransports.info/about/).
However, Tor is still far from being fully censorship resistant. For instance (many) exit nodes are known and can be blocked.
## How do Waku's Anonymity Guarantees compare to Tor?
Currently, Waku offers k-anonymity with respect to receiver anonymity.
Waku offers weak sender anonymity in the local attacker model.
Waku does not offer sender anonymity in the stronger attacker models.
However with integrating pluggable anonymity, which is part of our roadmap,
Waku can offer stronger anonymity guarantees up to protection within the global adversary model.
This highest protection level can be achieved with mix-nets and is feasible if latency is not an issue.
[Tor does not protect](https://support.torproject.org/about/attacks-on-onion-routing/) against an attacker that can observe both entry and exit node.
So, for non-latency-critical messaging, Waku will have superior anonymity properties.
## How does Waku compare to Briar
[Briar](https://briarproject.org/how-it-works/) is a Tor based messaging app.
The following information on Briar is based on a first superficial study of Briar. There might be inaccuracies.
### How does Briar work?
* can sync messages in local networks via bluetooth or spanning a WIFI ad-hoc network
- Tor, Bluetooth, WiFi are referred to as Briar transports (plan to add more transports)
- only the Tor transport offers anonymity
* supports 1:1 chats
* supports forums
- forums are basically group chats
- creator invites contacts to join
- the creator sends messages to all members
- when joining a forum, you only directly communicate with the creator who broadcasts to other members
* supports blogs: blog messages are shared with all your contacts
- contacts can also share these posts to their contacts (like retweet)
* RSS reader featuring sharing
* does not route messages over a mesh network (for now; might support this optionally in the future)
* uses single-hop social mesh
- social mesh means: you build a p2p network with only your contacts
- send messages directly (wrt the overlay network) to the intended receiver
- good for meta-data protection
- bad for connectivity
* Briar team is also researching multi-hop social meshes and public meshes
- multi-hop social mesh: send messages to all contacts, who then route them
- plans: selectable anonymity: users can select which mesh to use
- anonymity vs availability trade-off
* Layered architecture: Bramble protocols
- the Bramble transport protocol BTP (on top of transports like TCP), and on top of BTP:
- contact establishment
- communication
- synchronous (duplex): ask peer what messages they have and get missing messages
- batch (one-way): push all available messages
* Pairing with peers
- e.g. QR codes
- bramble rendezvous via Tor network via `briar://` link
- similar to .onion but
- does not contain network address, only the public key
- both use information in the link to generate new key pairs for the Tor network
- both parties now know each others hidden service ID within Tor and can connect to each other
* Uses Tor hidden service mechanism for peers to connect to each other
- Bramble handshake after connection
- DH: establish ephemeral connection keys
* Bramble Transport protocol:
- keys rotate time-based to provide forward secrecy
- time-based because Briar supports simplex links, and keys should be rotated without contact
- intervals, still there might be time sync problems...
- pseudo random tag to avoid trial encryptions
* Bramble Sync protocol
- messages are synced in groups (Not clear how that works: Maybe swarm based sharing like Bittorrent?)
### Comparison with Waku
#### conceptual
* sender anonymity with respect to other group members
- Briar trusts intended receivers (authentication)
- Waku will allow sender-anonymous broadcasts into a "public" group (not yet, see above; but it is on the roadmap -> Tor / own onion routing / mix-nets)
- Waku uses RLN to protect against spam from anonymous entities
* message store
- Waku: general store, store messages are available for the whole topic mesh
- Briar default: no store, Briar only gets messages when online
- Briar store (planned feature): only for your own messages, maybe your contacts will be able to use it, too
- maybe support a "store server" in the future if public mesh is selected?
- how does this influence anonymity?
* P2P network
- Briar uses single-hop social mesh (similar to swarms in Bittorrent?)
- seems less stable/available compared to libp2p's gossipsub
- does it scale?
- Waku's uses a resilient public mesh
- [libp2p gossipsub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub)
- mesh links are limited
- gossip mesh and fan-out provide further stability
* main application (group chat vs 1:1 chat)
- Briar is 1:1 messages first
- still, Briar offers group message features list forums, blogs (see above)
- Briar offers end-to-end forward secret messaging channels
- Briar offers authenticated messages for 1:1
- Briar offers group messages on top of 1:1
- Waku is group messages first
- Waku could offer 1:1 on top of group messages
* Authentication
- Briar authenticates messages
- anonymity is still guaranteed, because only intended recipient learn the information
- Waku does not
* Protocol set/stack vs. App
- Waku is a set of protocols that can be used to build a messaging app
- Briar is a messaging app
- However, Briar consists of layers, and further apps could be build on the Bramble layers
- Bramble for Briar roughly corresponds to libp2p for Waku (some higher layer Bramble functionality corresponds to Waku protocols on top of libp2p)
* Security protocol framework
- Waku uses Noise
- Briar uses their own setup (like Waku, offers forward secrecy)
- Waku's security is easier to proof because it builds on Noise
#### implementation / current state
* Briar does not yet offer a message store
- store is WIP
* Briar can use existing infrastructure: the Tor network.
- Roll-out is easier (there are enough stable nodes)
- in the roll-out phase with only a few clients, traffic hides within the large Tor network
* Waku features adaptive nodes, for Briar, all nodes are the same
- a set of strong Waku nodes can help a lot in the bootstrap phase
- this might be optimal for decentralization, but greatly boosts usability in the early phase
- running briar on weak devices seams not feasible -> high energy consumption
- however, Waku protocols that allow weak Waku nodes to participate, e.g. filter, lightpush, are not anonymity-preserving in their current state
* Briar can share itself as an app locally
- Apps using Waku could offer this
### When to choose Waku / Briar
* Wakus strongest application
- "semi-public" groups, where members do not have to authenticate
- spam protection via RLN
* choose Waku over Briar for these reasons
- in its current version, users have to be constantly online to receive messages
- but working on mailbox (not as generaly useable as waku store node though)
- energy consumption very high, because you need to be part of Tor etc
- devices (also weak nodes) have to offer a hidden service per peer.
- Waku has (works on) several solutions agains [Briar fundatmental Problems](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems)
* Briar's strongest application
- anonymity-preserving 1:1 chat
* choose Briar over Waku
- Briar's anonymity properties are currently better
- exception: hiding your identity from other group members
* [Briar fundatmental Problems](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems)
### Briar features Waku could add in the future
* a protocol for 1:1 messages on top of Waku relay
* local network support
* sender anonymity in stronger attacker model
## Attacker Types
The following lists various attacker types of increasing power.
The greater the power, the more difficult it is to gain the respective attacker position.
Each attacker level comes in a passive and an active variant.
While the passive can stay hidden and is not suspicious,
the respective active attacker has more (or at least the same) deanonymization power.
We also distinguish between internal an external attackers.
With respect to Waku relay, an internal attacker participates in the same pubsub topic as its victims.
An external attacker, on the other hand, can only see encrypted traffic (protected by Noise).
### Local single node
This attacker controls a single node.
Subcategories comprise:
* mesh connection to victim node
* fan-out connection to victim node
* maintenance-only connection to victim node
* targeted: attacker can control where in the network this node is placed.
- the section on attacks comprises a subsection listing methods to get into desired positions
### Local >= two nodes
This attacker controls two or more peers connected to the same victim node.
This attacker has the same subcategories as the local single peer attacker.
### Smaller Botnet
This attacker controls a fixed number of nodes (not depended on the number of total nodes in the network).
(We will cover this attacker type in the future.)
### AS (ISP)
An AS attacker controls a single AS (autonomous system).
A passive AS attacker can listen to traffic on arbitrary links within the AS,
an active AS attacker can drop, inject, and alter traffic on arbitrary links within the AS.
An AS attacker is external to Waku relay.
While the attacker can see all traffic, it is external in the sense that it only sees Noise sessions.
In practice, a malicious ISP would be considered as AS attacker.
A malicious ISP could also easily setup a set of nodes at specific points in the network,
gaining attack power similar to a targeted botnet.
### Linearly Scaling Botnet
This attacker controls a bot net of nodes. The number of nodes scales linearly with the number of nodes in the network.
This attacker is especially interesting to investigate in the context of DHT security,
which Waku uses for ambient peer discovery.
### Global On-Net
A global on-net attacker has complete overview over the whole network.
A passive global attacker can listen to traffic on all links,
while the active global attacker basically carries the traffic: it can freely drop, inject, and alter traffic at all positions in the network.
This basically corresponds to the [Dolev-Yao](https://en.wikipedia.org/wiki/Dolev%E2%80%93Yao_model) model.
Like the AS attacker, the global on-net attacker is external to Waku relay.
Also, an entity with this power would, in practice, also have the power of a targeted linearly scaling botnet attacker.
## Attacks
The following lists various attacks including the weakest attacker model in which it can be successfully performed.
The respective attack can be performed in all stronger attacker models as well.
An attack is considered more powerful if it can be successfully performed in a weaker attacker model.
If not stated otherwise, we look at these attacks with respect to their capability to deanonymize the message sender.
### prerequisite: get a specific position in the network
Some attacks require the attacker node(s) to be in a specific position in the network.
In most cases, this corresponds to trying to get into the mesh peer list for the desired pubsub topic of the victim node.
In libp2p gossipsub, and by extension Waku v2 relay, nodes can simply send a graft message for the desired topic to the victim node.
If the victim node still has open slots, the attacker gets the desired position.
This only requires the attacker to know the gossipsub multiaddress of the victim node.
A linearly scaling botnet attacker can leverage DHT based discovery systems to boost the probability of evil nodes being returned, which in turn significantly increased the probability of evil nodes ending up in the peer lists of victim nodes.
[Waku v2 discv5](https://vac.dev/wakuv2-apd) will employ countermeasures that reduce amplifying effect this attacker type can achieve.
### replay attack
attacker: does not work, protection in place
GossipSub nodes, and by extension Waku relay nodes, feature a `seen` cache, and only relay message they have not seen before.
* will be punished by [RLN](https://rfc.vac.dev/spec/17/) and [SWAP](https://rfc.vac.dev/spec/18/)
### message injection
TODO
* will be punished by [RLN](https://rfc.vac.dev/spec/17/) and [SWAP](https://rfc.vac.dev/spec/18/)
### neighbourhood surveillance
attacker: local, requires targeting
This attack can be successfully performed by a local attacker that is connected to all peers of the victim node $v$ with respect to a topic mesh.
An attacker in this position can monitor the set of messages transmitted by the peers of $v$, and all messages transmitted by $v$.
Messages that are only transmitted by $v$ but not by its peers must have originated in $v$.
Even with partial surveillance, meaning the attacker is only connected to a subset of $v$'s peers, the attacker could identify messages that are (very likely) sent by $v$.
Because the attacker will receive same messages from both $v$ and its peers, it can leverage timing information.
Messages that are received significantly faster from $v$ are more likely messages that $v$ sent.
The attacker can (periodically) measure latency between itself and $v$, and between itself and the peers of $v$ to get a more accurate estimates for the expected timings.
(An AS attacker could also learn the latency between $v$ and its well-behaving peers.)
### controlled neighbourhood
attacker: local, requires targeting
If an attacker manages to control all peers of the victim node, it can trivially tell which messages originated from $v$.
### observing messages
If Waku relay is not protected with Noise, the AS attacker can simply check for messages leaving $v$ which have not been relayed to $v$.
These are the messages sent by $v$.
Waku relay protects against this attack by employing Noise.
### correlation
attacker: passive AS (external)
Monitoring all traffic (in an AS or globally), allows the attacker to identify traffic correlated with messages originating from $v$.
This (alone) does not allow an external attacker to learn which message $v$ sent, but it allows identifying the respective traffic propagating through the network.
The more traffic in the network, the lower the success rate of this attack.
Combined with just a few nodes controlled by the attacker, the actual message associated with the correlated traffic can eventually be identified.
### DoS
attacker: AS (active local attacker can only disrupt)
An active local attacker could run a disruption attack by
* (1) dropping message that should be relayed
* (2) flooding neighbours with bogus messages
While (1) has a negative effect on availability, the impact is not significant.
A linearly scaling botnet attacker, however, could significantly disrupt the network with such an attacks.
(2) is thwarted by [RLN](https://rfc.vac.dev/spec/17/).
Also [SWAP](https://rfc.vac.dev/spec/18/) helps mitigating DoS attacks.
An AS attacker can DoS by dropping all Waku traffic within its authority, while a global attacker can DoS the whole network.
A countermeasure are censorship resistance techniques like [Pluggable Transports](https://www.pluggabletransports.info/about/).
## Further Info
* [Sanaz' Comparison of Tor vs Waku](https://github.com/vacp2p/research/tree/master/Tor-vs-Waku)
* [Forum: Towards a Waku v2 Security Analysis](https://forum.vac.dev/t/towards-a-waku-v2-security-analysis/134)
* [Forum: On the anonymity of Waku-Relay](https://forum.vac.dev/t/on-the-anonymity-of-waku-relay/135)
* [Issue tracking research log post](https://github.com/vacp2p/research/issues/104)