vacp2p/rfc
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc.git synced 2025-02-03 02:24:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

add(RFC): 45/WAKU2-ADVERSARIAL-MODELS (#545)

Browse Source
This commit is contained in:
kaiserd 2022-10-11 16:14:57 +02:00 committed by GitHub
parent aaa8d4fe70
commit b5ae2b1467
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 340 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

338
content/docs/rfcs/45/README.md Normal file
View File

@ -0,0 +1,338 @@
---
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)

3
content/menu/index.md
View File

@ -9,9 +9,11 @@ bookMenuLevels: 1
- [28/STATUS-FEATURING]({{< relref "/docs/rfcs/28/README.md" >}})
- [31/WAKU2-ENR]({{< relref "/docs/rfcs/31/README.md" >}})
- [32/RLN-SPEC]({{< relref "/docs/rfcs/32/README.md" >}})
- [34/WAKU2-PEER-EXCHANGE]({{< relref "/docs/rfcs/34/README.md" >}})
- [35/WAKU2-NOISE]({{< relref "/docs/rfcs/35/README.md" >}})
- [37/WAKU2-NOISE-SESSIONS]({{< relref "/docs/rfcs/37/README.md" >}})
- [43/WAKU2-NOISE-PAIRING]({{< relref "/docs/rfcs/43/README.md" >}})
- [45/WAKU2-ADVERSARIAL-MODELS]({{< relref "/docs/rfcs/45/README.md" >}})
- Draft
- [1/COSS]({{< relref "/docs/rfcs/1/README.md" >}})
- [3/REMOTE-LOG]({{< relref "/docs/rfcs/3/README.md" >}})
@ -33,7 +35,6 @@ bookMenuLevels: 1
- [29/WAKU2-CONFIG]({{< relref "/docs/rfcs/29/README.md" >}})
- [30/ADAPTIVE-NODES]({{< relref "/docs/rfcs/30/README.md" >}})
- [33/WAKU2-DISCV5]({{< relref "/docs/rfcs/33/README.md" >}})
- [34/WAKU2-PEER-EXCHANGE]({{< relref "/docs/rfcs/34/README.md" >}})
- [36/WAKU2-BINDINGS-API]({{< relref "/docs/rfcs/36/README.md" >}})
- Stable
- [2/MVDS]({{< relref "/docs/rfcs/2/README.md" >}})