mirror of https://github.com/vacp2p/rfc.git
339 lines
18 KiB
Markdown
339 lines
18 KiB
Markdown
---
|
|
slug: 45
|
|
title: 45/WAKU2-ADVERSARIAL-MODELS
|
|
name: Waku v2 Adversarial Models and Attack-based Threat List
|
|
status: raw
|
|
category: Informational
|
|
tags:
|
|
editor: Daniel Kaiser <danielkaiser@status.im>
|
|
contributors:
|
|
---
|
|
|
|
# Abstract
|
|
|
|
This document lists adversarial models and attack-based threats relevant in the context of Waku v2.
|
|
|
|
# Motivation and Background
|
|
|
|
Future versions of this document will serve as a comprehensive list of adversarial models and attack based threats relevant for [Waku v2](/spec/10/).
|
|
The main purpose of this document is being a linkable resource for specifications that address protection as well as mitigation mechanisms within the listed models.
|
|
|
|
Discussing and introducing countermeasures to specific attacks in specific models is out of scope for this document.
|
|
Analyses and further information about Waku's properties within these models may be found in our *Waku v2 Anonymity Analysis* series of research log posts:
|
|
|
|
* [Part I: Definitions and Waku Relay](https://vac.dev/wakuv2-relay-anon)
|
|
|
|
Note: This document adds to the adversarial models and threat list discussed in our [research log post](https://vac.dev/wakuv2-relay-anon).
|
|
It does not cover analysis of Waku, as the research log post does.
|
|
Future versions of this document will extend the adversarial models and threat list.
|
|
|
|
# Informal Definitions: Security, Privacy, and Anonymity
|
|
|
|
The concepts of security, privacy, and anonymity are linked and have quite a bit of overlap.
|
|
|
|
## Security
|
|
|
|
Of the three, [Security](https://en.wikipedia.org/wiki/Information_security) has the clearest agreed upon definition,
|
|
at least regarding its key concepts: *confidentiality*, *integrity*, and *availability*.
|
|
|
|
* confidentiality: data is not disclosed to unauthorized entities.
|
|
* integrity: data is not modified by unauthorized entities.
|
|
* availability: data is available, i.e. accessible by authorized entities.
|
|
|
|
While these are the key concepts, the definition of information security has been extended over time including further concepts,
|
|
e.g. [authentication](https://en.wikipedia.org/wiki/Authentication) and [non-repudiation](https://en.wikipedia.org/wiki/Non-repudiation).
|
|
|
|
## Privacy
|
|
|
|
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.
|
|
This means, no further information about the sender or the message is leaked.
|
|
Metadata that is protected as part of the privacy-preserving property does not cover protecting the identities of sender and receiver.
|
|
Identities are protected by the [anonymity property](#anonymity).
|
|
|
|
Often privacy is realized by the confidentiality property of security.
|
|
This neither makes privacy and security the same, nor the one a sub category of the other.
|
|
While security is abstract itself (its properties can be realized in various ways), privacy lives on a more abstract level using security properties.
|
|
Privacy typically does not use integrity and availability.
|
|
An adversary who has no access to the private data, because the message has been encrypted, could still alter the message.
|
|
|
|
## Anonymity
|
|
|
|
Privacy and anonymity are closely linked.
|
|
Both the identity of a user and data that allows inferring a user's identity should be part of the privacy policy.
|
|
For the purpose of analysis, we want to have a clearer separation between these concepts.
|
|
|
|
We define anonymity as *unlinkablity of users' identities and their shared data and/or actions*.
|
|
|
|
We subdivide anonymity into *receiver anonymity* and *sender anonymity*.
|
|
|
|
### Receiver Anonymity
|
|
|
|
We define receiver anonymity as *unlinkability of users' identities and the data they receive and/or related actions*.
|
|
Because each [Waku message](/spec/14/) is associated with a content topic, and each receiver is interested in messages with specific content topics,
|
|
receiver anonymity in the context of Waku corresponds to *subscriber-topic unlinkability*.
|
|
An example for the "action" part of our receiver anonymity definition is subscribing to a specific topic.
|
|
|
|
### Sender Anonymity
|
|
|
|
We define sender anonymity as *unlinkability of users' identities and the data they send and/or related actions*.
|
|
Because the data in the context of Waku is Waku messages, sender anonymity corresponds to *sender-message unlinkability*.
|
|
|
|
## Anonymity Trilemma
|
|
|
|
[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 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.
|
|
|
|
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 [k-anonymity](https://en.wikipedia.org/wiki/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.
|
|
|
|
An example for a censorship resistance technique is Tor's [Pluggable Transports](https://www.pluggabletransports.info/about/).
|
|
|
|
# Adversarial Models
|
|
|
|
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.
|
|
|
|
We also distinguish between internal and external attackers.
|
|
Since in permissionless protocols it is easy to obtain an internal position,
|
|
in practice attackers are expected to mount combined attacks that leverage both internal and external attacks.
|
|
|
|
## Internal
|
|
|
|
In the passive variant, an internal attacker behaves like an honest node towards peers.
|
|
The passive internal attacker has the same access rights as any honest node.
|
|
In the active variant, an internal attacker can additionally drop, inject, and alter messages.
|
|
With respect to Waku relay, for example, an internal attacker participates in the same pubsub topic as its victims,
|
|
and can read messages related to that topic.
|
|
|
|
### Single Node
|
|
|
|
This attacker controls a single node.
|
|
|
|
### Multi Node
|
|
|
|
This attacker controls a fixed number of nodes (not scaling with the total number of nodes in the network).
|
|
The multi node position can be achieved 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.
|
|
|
|
Nodes controlled by the attacker can efficiently communicate out-of-band to coordinate.
|
|
|
|
### Scaling Multi Node
|
|
|
|
This attacker controls a number of nodes that scales linearly with the number of nodes in the network.
|
|
The attacker controls $p%$ of all nodes in the network.
|
|
|
|
Nodes controlled by the attacker can efficiently communicate out-of-band to coordinate.
|
|
|
|
## External
|
|
|
|
An external attacker can only see encrypted traffic.
|
|
Waku protocols are protected by a secure channel set up with [Noise](/spec/35/).
|
|
|
|
### 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, delay, 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* or even *scaling 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, delay, 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 *scaling multi node* attacker.
|
|
|
|
# Attack-based Threats
|
|
|
|
The following lists various attacks against [Waku v2](/spec/10/) protocols.
|
|
If not specifically mentioned, the attacks refer to [Waku relay](/spec/11) and the underlying [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
|
|
We also list the weakest attacker model in which the attack can be successfully performed against.
|
|
|
|
An attack is considered more powerful if it can be successfully performed in a weaker attacker model.
|
|
|
|
Note: This list is work in progress.
|
|
We will either expand this list adding more attacks in future versions of this document,
|
|
or remove it and point to the "Security Considerations" sections of respective RFCs.
|
|
|
|
## 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 *scaling multi node* 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.
|
|
|
|
## Sender Deanonymization
|
|
|
|
This section lists attacks that aim at deanonymizing a message sender.
|
|
|
|
We assume that protocol messages are transmitted within a secure channel set up using the [Noise Protocol Framework](https://noiseprotocol.org/).
|
|
For [Waku Relay](/spec/11) this means we only consider messages with version field `2`,
|
|
which indicates that the payload has to be encoded using [35/WAKU2-NOISE](/spec/35/).
|
|
|
|
Note: The currently listed attacks are against libp2p in general.
|
|
The [data field of Waku v2 relay](/spec/11/#message-fields) must be a [Waku v2 message](/spec/14/).
|
|
The attacks listed in the following do not leverage that fact.
|
|
|
|
### Replay Attack
|
|
|
|
In a replay attack, the attacker replays a valid message it received.
|
|
|
|
Waku relay is inherently safe against replay attack,
|
|
because 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 Relay](/spec/17/).
|
|
|
|
### 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.
|
|
|
|
### Neighbourhood Surveillance
|
|
|
|
This attack can be performed by a single node attacker that is connected to all peers of the victim node $v$ with respect to a specific topic mesh.
|
|
The attacker also has to be connected to $v$.
|
|
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$.
|
|
Messages that are received (significantly) faster from $v$ than from any other of $v$'s peers are very likely messages that $v$ sent,
|
|
because for these messages the attacker is one hop closer to the source.
|
|
|
|
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.
|
|
|
|
This attack cannot (reliably) distinguish messages $m_v$ sent by $v$ from messages $m_y$ relayed by peers of $v$ the attacker is not connected to.
|
|
Still, there are hop-count variations that can be leveraged.
|
|
Messages $m_v$ always have a hop-count of 1 on the path from $v$ to the attacker, while all other paths are longer.
|
|
Messages $m_y$ might have the same hop-count on the path from $v$ as well as on other paths.
|
|
Further techniques that are part of the *mass deanonymization* category, such as [bayesian analysis](#bayesian-analysis), can be used here as well.
|
|
|
|
### Controlled Neighbourhood
|
|
|
|
If a multi node attacker manages to control all peers of the victim node, it can trivially tell which messages originated from $v$.
|
|
|
|
### 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.
|
|
|
|
## Mass Deanonymization
|
|
|
|
While attacks in the *sender deanonymization* category target a set of either specific or arbitrary users,
|
|
attacks in the *mass deanonymization* category aim at deanonymizing (parts of) the whole network.
|
|
Mass deanonymization attacks do not necessarily link messages to senders.
|
|
They might only reduce the anonymity set in which senders hide,
|
|
or infer information about the network topology.
|
|
|
|
### Graph Learning
|
|
|
|
Graph learning attacks are a prerequisite for some mass deanonymization attacks,
|
|
in which the attacker learns the overlay network topology.
|
|
Graph learning attacks require a *scaling multinode* attacker
|
|
|
|
For gossipsub this means an attacker learns the topic mesh for specific pubsub topics.
|
|
[Dandelion++](https://arxiv.org/abs/1805.11060) describes ways to perform this attack.
|
|
|
|
### Bayesian Analysis
|
|
|
|
Bayesian analysis allows attackers to assign each node in the network a likelihood of having sent (originated) a specific message.
|
|
Bayesian analysis for mass deanonymization is detailed in [On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies](https://arxiv.org/pdf/2201.11860).
|
|
It requires a *scaling node* attacker as well as knowledge of the network topology,
|
|
which can be learned via *graph learning* attacks.
|
|
|
|
## Denial of Service (DoS)
|
|
|
|
### Flooding
|
|
|
|
In a flooding attack, attackers flood the network with bogus messages.
|
|
|
|
Waku employs [RLN Relay](/spec/17/) as the main countermeasure to flooding.
|
|
[SWAP](/spec/18/) also helps mitigating DoS attacks.
|
|
|
|
### Black Hole (internal)
|
|
|
|
In a black hole attack, the attacker does not relay messages it is supposed to relay.
|
|
Analogous to a black hole, attacker nodes do not allow messages to leave once they entered.
|
|
|
|
While *single node* and smaller *multi node* attackers can have a negative effect on availability, the impact is not significant.
|
|
A *scaling multi node* attacker, however, can significantly disrupt the network with such an attack.
|
|
|
|
The effects of this attack are especially severe in conjunction with deanonymization mitigation techniques that reduce the out-degree of the overlay,
|
|
such as [Waku Dandelion](/spec/44/).
|
|
([Waku Dandelion](/spec/44/) also discusses mitigation techniques compensating the amplified black hole potential.)
|
|
|
|
### Traffic Filtering (external)
|
|
|
|
A local attacker can filter and drop all Waku traffic within its controlled network segment.
|
|
An AS attacker can filter and drop all Waku traffic within its authority, while a global attacker can censor the whole network.
|
|
A countermeasure are censorship resistance techniques like [Pluggable Transports](https://www.pluggabletransports.info/about/).
|
|
|
|
An entity trying to censor Waku can employ both the *black hole* attack and *traffic filtering*;
|
|
the former is internal while the latter is external.
|
|
|
|
# Copyright
|
|
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
|
|
|
# References
|
|
|
|
* [10/WAKU2](/spec/10/)
|
|
* [11/WAKU2-RELAY](/spec/11/)
|
|
* [libp2p GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
|
|
* [Security](https://en.wikipedia.org/wiki/Information_security)
|
|
* [Authentication](https://en.wikipedia.org/wiki/Authentication)
|
|
* [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html)
|
|
* [Waku v2 message](/spec/14/)
|
|
* [Pluggable Transports](https://www.pluggabletransports.info/about/)
|
|
* [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack)
|
|
* [Dolev-Yao model](https://en.wikipedia.org/wiki/Dolev%E2%80%93Yao_model)
|
|
* [Noise Protocol Framework](https://noiseprotocol.org/)
|
|
* [35/WAKU2-NOISE](/spec/35/)
|
|
* [17/WAKU-RLN-RELAY](/spec/17/)
|
|
* [18/WAKU2-SWAP](/spec/18/)
|
|
* [Dandelion++](https://arxiv.org/abs/1805.11060)
|
|
* [On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies](https://arxiv.org/pdf/2201.11860)
|
|
|