diff --git a/informational/adversarial-models.md b/informational/adversarial-models.md new file mode 100644 index 0000000..c55467c --- /dev/null +++ b/informational/adversarial-models.md @@ -0,0 +1,335 @@ +--- +title: ADVERSARIAL-MODELS +name: Waku v2 Adversarial Models and Attack-based Threat List +category: Informational +tags: +editor: Daniel Kaiser +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)