[Waku v2](https://rfc.vac.dev/spec/10/) enables secure, privacy preserving communication using a set of modular P2P protocols.
Waku v2 also aims at protecting the user's anonymity.
This post is the first in a series about Waku v2 security, privacy, and anonymity.
The goal is to eventually have a full privacy and anonymity analysis for each of the Waku v2 protocols, as well as covering the interactions of various Waku v2 protocols.
This provides transparency with respect to Waku's current privacy and anonymity guarantees, and also identifies weak points that we have to address.
In this post, we first give an informal description of security, privacy and anonymity in the context of Waku v2.
For each definition, we summarize Waku's current guarantees regarding the respective property.
We also provide attacker models, an attack-based threat model, and a first anonymity analysis of [Waku v2 relay](https://rfc.vac.dev/spec/11/) within the respective models.
Waku comprises many protocols that can be combined in a modular way.
For our privacy and anonymity analysis, we start with the relay protocol because it is at the core of Waku v2 enabling Waku's publish subscribe approach to P2P messaging.
In its current form, Waku relay is a minor extension of [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
](/img/libp2p_gossipsub_types_of_peering.png)
An example for the "action" part of our receiver anonymity definition is subscribing to a specific topic.
The Waku message's content topic is not related to the libp2p pubsub topic.
For now, Waku uses a single libp2p pubsub topic, which means messages are propagated via a single mesh of peers.
With this, the receiver discloses its participation in Waku on the gossipsub layer.
We will leave the analysis of libp2p gossipsub to a future article within this series, and only provide a few hints and pointers here.
Waku offers k-anonymity regarding content topic interest in the global adversary model.
[K-anonymity](https://en.wikipedia.org/wiki/K-anonymity) in the context of Waku means an attacker can link receivers to content topics with a maximum certainty of $1/k$.
The larger $k$, the less certainty the attacker gains.
Receivers basically hide in a pool of $k$ content topics, any subset of which could be topics they subscribed to.
The attacker does not know which of those the receiver actually subscribed to,
and the receiver enjoys [plausible deniability](https://en.wikipedia.org/wiki/Plausible_deniability#Use_in_cryptography) regarding content topic subscription.
Assuming there are $n$ Waku content topics, a receiver has $n$-anonymity with respect to association to a specific content topic.
Technically, Waku allows distributing messages over several libp2p pubsub topics.
This yields $k$-anonymity, assuming $k$ content topics share the same pubsub topic.
However, if done wrongly, such sharding of pubsub topics can breach anonymity.
A formal specification of anonymity-preserving topic sharding building on the concepts of [partitioned topics](https://specs.status.im/spec/10#partitioned-topic) is part of our roadmap.
Also, Waku is not directly concerned with 1:1 communication, so for this post, 1:1 communication is out of scope.
Channels for 1:1 communication can be implemented on top of Waku relay.
In the future, a 1:1 communication protocol might be added to Waku.
Similar to topic sharding, it would maintain receiver anonymity leveraging [partitioned topics](https://specs.status.im/spec/10#partitioned-topic).
In summary, Waku offers weak sender anonymity because of [Waku's strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy),
which has its origins in the [Ethereum consensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#why-are-we-using-the-strictnosign-signature-policy).
[17/WAKU-RLN-RELAY](https://rfc.vac.dev/spec/17/) and [18/WAKU2-SWAP](https://rfc.vac.dev/spec/18/) mitigate replay and injection attacks.
Waku currently does not offer sender anonymity in stronger attacker models, as well as cannot protect against targeted attacks in weaker attacker models like the single or multi node attacker.
We will cover this in more detail in later sections.
[The Anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) states that only two out of _strong anonymity_, _low bandwidth_, and _low latency_ can be guaranteed in the global on-net attacker model.
Waku's goal, being a modular set of protocols, is to offer any combination of two out of these three properties, as well as blends.
An example for blending is an adjustable number of pubsub topics and peers in the respective pubsub topic mesh; this allows tuning the trade-off between anonymity and bandwidth.
A fourth factor that influences [the anonymity trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html) is _frequency and patterns_ of messages.
The more messages there are, and the more randomly distributed they are, the better the anonymity protection offered by a given anonymous communication protocol.
So, incentivising users to use the protocol, for instance by lowering entry barriers, helps protecting the anonymity of all users.
The frequency/patterns factor is also related to the above described k-anonymity.
### Censorship Resistance
Another security related property that Waku aims to offer is censorship resistance.
Censorship resistance guarantees that users can participate even if an attacker tries to deny them access.
So, censorship resistance ties into the availability aspect of security.
In the context of Waku that means users should be able to send messages as well as receive all messages they are interested in,
even if an attacker tries to prevent them from disseminating messages or tries to deny them access to messages.
Currently, Waku only guarantees censorship resistance in the weak single node attacker model.
While currently employed secure channels mitigate targeted censorship, e.g. blocking specific content topics,
general censorship resistance in strong attacker models is part of our roadmap.
Among other options, we will investigate [Pluggable Transports](https://www.pluggabletransports.info/about/) in future articles.
## Attacker Types
The following lists various attacker types with varying degrees of power.
The more power an attacker has, the more difficult it is to gain the respective attacker position.
Each attacker type comes in a passive and an active variant.
While a passive attacker can stay hidden and is not suspicious,
the respective active attacker has more (or at least the same) deanonymization power.
With respect to Waku relay, an internal attacker participates in the same pubsub topic as its victims.
Without additional measures on higher layer protocols, access to an internal position is easy to get.
#### Single Node
This attacker controls a single node.
Because this position corresponds to normal usage of Waku relay, it is trivial to obtain.
#### Multi Node
This attacker controls several nodes. We assume a smaller static number of controlled nodes.
The multi node position can be achieved relatively easily by setting up multiple nodes.
Botnets might be leveraged to increase the number of available hosts.
Multi node attackers could use [Sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack) to increase the number of controlled nodes.
A countermeasure is for nodes to only accept libp2p gossipsub graft requests from peers with different IP addresses, or even different subnets.
#### Linearly Scaling Nodes
This attacker controls a number of nodes that 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.
### External
An external attacker can only see encrypted traffic (protected by a secure channel set up with [Noise](https://rfc.vac.dev/spec/35/)).
Because an internal position can be easily obtained,
in practice external attackers would mount combined attacks that leverage both internal an external attacks.
We cover this more below when describing attacks.
#### Local
A local attacker has access to communication links in a local network segment.
This could be a rogue access point (with routing capability).
#### AS
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.
In practice, a malicious ISP would be considered as an AS attacker.
A malicious ISP could also easily setup a set of nodes at specific points in the network,
gaining internal attack power similar to a strong multi node attacker.
#### 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 model](https://en.wikipedia.org/wiki/Dolev%E2%80%93Yao_model).
An entity with this power would, in practice, also have the power of the internal linearly scaling nodes attacker.
## Attack-based Threat Analysis
The following lists various attacks including the weakest attacker model in which the attack 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.
### Scope
In this post, we introduce a simple tightly scoped threat model for Waku v2 Relay, which will be extended in the course of this article series.
In this first post, we will look at the relay protocol in isolation.
Even though many threats arise from layers Waku relay is based on, and layers that in turn live on top of relay,
we want to first look at relay in isolation because it is at the core of Waku v2.
Addressing and trying to solve all security issues of a complex system at once is an overwhelming task, which is why we focus on the soundness of relay first.
This also goes well with the modular design philosophy of Waku v2, as layers of varying levels of security guarantees can be built on top of relay, all of which can relay on the guarantees that Waku provides.
Instead of looking at a multiplicative explosion of possible interactions, we look at the core in this article, and cover the most relevant combinations in future posts.
Further restricting the scope, we will look at the data field of a relay message as a black box.
In a second article on Waku v2 relay, we will look into the data field, which according to the [specification of Waku v2 relay](https://rfc.vac.dev/spec/11/#message-fields) must be a [Waku v2 message](https://rfc.vac.dev/spec/14/).
We only consider messages with version field `2`, which indicates that the payload has to be encoded using [35/WAKU2-NOISE](https://rfc.vac.dev/spec/35/).
### 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 nodes attacker can leverage DHT based discovery systems to boost the probability of malicious nodes being returned, which in turn significantly increases the probability of attacker nodes ending up in the peer lists of victim nodes.
[Waku v2 discv5](https://vac.dev/wakuv2-apd) will employ countermeasures that mitigate the amplifying effect this attacker type can achieve.
### Replay Attack
In the scope we defined above, Waku v2 is resilient against replay attacks.
GossipSub nodes, and by extension Waku relay nodes, feature a `seen` cache, and only relay messages they have not seen before.
Further, replay attacks will be punished by [RLN](https://rfc.vac.dev/spec/17/) and [SWAP](https://rfc.vac.dev/spec/18/).
In this position, the attacker will receive messages $m_v$ sent by $v$ both on the direct path from $v$, and on indirect paths relayed by peers of $v$.
It will also receive messages $m_x$ that are not sent by $v$. These messages $m_x$ are relayed by both $v$ and the peers of $v$.
The attacker can (periodically) measure latency between itself and $v$, and between itself and the peers of $v$ to get more accurate estimates for the expected timings.
An AS attacker (and if the topology allows, even a local attacker) could also learn the latency between $v$ and its well-behaving peers.
An active AS attacker could also increase the latency between $v$ and its peers to make the timing differences more prominent.
This, however, might lead to $v$ switching to other peers.
If a multi node attacker manages to control all peers of the victim node, it can trivially tell which messages originated from $v$.
### Observing Messages
If Waku relay was not protected with Noise, the AS attacker could 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 secure channels setup using Noise.
### Correlation
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
An active single node attacker could run a disruption attack by
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 attack.
(2) is thwarted by [RLN](https://rfc.vac.dev/spec/17/).
Also [SWAP](https://rfc.vac.dev/spec/18/) helps mitigating DoS attacks.
A local attacker can DoS Waku by dropping all Waku traffic within its controlled network segment.
An AS attacker can DoS Waku 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/).
## Summary and Future Work
Currently, Waku v2 relay offers k-anonymity with respect to receiver anonymity.
This also includes k-anonymity towards legitimate members of the same topic.
Waku v2 relay offers sender anonymity in the single node attacker model with its [strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy).
Currently, Waku v2 does not guarantee sender anonymity in the multi node and stronger attacker models.
However, we are working on modular anonymity-preserving protocols and building blocks as part of our privacy/anonymity roadmap.
- [Dandelion++](https://arxiv.org/abs/1805.11060) for lightweight anonymity;
- [onion routing](https://en.wikipedia.org/wiki/Onion_routing) as a building block adding a low latency anonymization layer;
- [a mix network](https://en.wikipedia.org/wiki/Mix_network) for providing strong anonymity (on top of onion routing) even in the strongest attacker model at the cost of higher latency.
- [12/WAKU2-FILTER](https://rfc.vac.dev/spec/12/), which discloses nodes' interest in topics;
- [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/spec/19/), which also discloses nodes' interest in topics and links the lightpush client as the sender of a message to the lightpush service node;
- [21/WAKU2-FTSTORE](https://rfc.vac.dev/spec/21/), which discloses nodes' interest in specific time ranges allowing to infer information like online times.
- [strict no sign policy](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#why-are-we-using-the-strictnosign-signature-policy)
- [Waku v2 strict no sign policy](https://rfc.vac.dev/spec/11/#signature-policy)
