We are planning to write a research log post introducing a Waku threat model,
and future privacy and anonymity goals.
This will not (yet) be part of a thorough scientific security analysis, and more along the lines of the ProtonMail threat model.
This forum post comprises a non-comprehensive list of aspects the Waku v2 threat model should cover,
and also touches on possible countermeasures, with a focus on Waku’s request response protocols.
(For now, it is just a braindump; I will add more, foremost a list of attacks, after finishing current prio tasks.)
The purpose of this post is starting a discussion and filling in the gaps.
The post on the research log should provide readers with
- a definition of relevant terms
- adversarial model(s),
- a threat model,
- a list of threats Waku v2 protects against,
- an explanation of how Waku protects against these threats, and
- what is out of scope.
The list of attack based threats (detailed in the threat model) should be analyzed in (various) adversarial models. (This can be done informally at first, giving an overview over existing attacks and reasoning as to why we expect these attacks to be thwarted in specific adversarial models.)
Edit: As comments suggest, it makes sense to keep a complete threat model / security analysis as a future goal while having a series of posts on parts, e.g. a post on security / anonymity relay protocol.
Also see @sanaz post on the anonymity of Waku-Relay.
Adversarial models describe the power of an attacker.
Power in this context includes but is not limited to
- access to resources (e.g. nodes controlled in a network)
- passive vs active: while passive attackers just listen to traffic, active attackers might inject, alter, and drop messages
- position in the network
- internal vs external (access to a network link or not)
- being able to see ingress and/or egress traffic
In the Dolev-Yao model the attacker has full control over the whole network and is only limited by the employed cryptographic measures.
Ideally, Waku v2 would provide all of privacy, anonymity, and censorship resistance in this model.
(However, this model is unrealistically strong, and even when introducing some select relaxations, we still have a very strong model.)
Tor research typically models the attacker as either
- an AS-level attacker that has full access over the infrastructure of an autonomous system, or
- an attacker that controls p% (often 20%) of the Tor nodes
Tor does not protect against an attacker that can observe both entry and exit node.
A thorough comparison with Tor seems out of scope because Tor’s main application area is web traffic while Waku’s application area is messaging.
For messaging, Waku will have superior anonymity properties: Waku does not depend on low latency and can leverage mix-nets (see below).
A short comparison seems useful though, because many readers will be familiar with Tor and seek an answer to the question how Tor compares to Waku.
Guaranteeing Properties like privacy, anonymity, and censorship resistance only makes sense
when these properties are clearly defined, and when stating under which adversarial model they are guaranteed.
The Waku security analysis should define these properties; the following gives some first impression / basis for discussion.
Waku does not involve any trusted third party that has access to user’s private data.
Thus, Waku v2 avoids typical privacy issues by design.
Privacy issues we should investigate in the Waku v2 threat model are security threats that impact the user’s privacy.
Any attack breaching confidentiality would effect the user’s privacy.
Waku v2 provides confidentiality via noise.
However, anonymity can be seen as a part of privacy, too.
Attacks involving meta-data analysis effect the user’s privacy.
Open question: How should we define privacy?
An (incomplete) suggestion:
We define privacy as keeping private information about users and generated by users private, i.e. not disclosing this information to entities the user did not agree to.
In the context of Waku v2, this private information comprises:
- message content (only disclosed to intended recipients)
- usage patterns
This information must also be protected from inference attacks.
With the above definition of privacy, anonymity is a part of privacy.
- hiding the interest in certain topics
- for any given message, it must be impossible to infer receivers
(Receiver anonymity for 1:1 communication is out of scope for now, because 1:1 communication is not part of Waku.
1:1 communication protocols can be designed on top of Waku v2.
If such a protocol should become part of Waku in the future, it will be included in the Waku threat model.)
It must be impossible to infer the original sender of a message on the Waku v2 layer (and ideally on deeper layers, too).
Protocols running on top of Waku v2, e.g. a 1:1 messaging protocol, can relax this: the receiver is allowed to know who the sender is.
Censorship resistance is a property the threat model has to cover separately.
Even with privacy and anonymity protected, censorship resistance is not guaranteed.
Censorship resistance requires Waku v2 traffic not to be fingerprintable.
(Focus on attack-based threats.)
- Collusion of a set of (relay) nodes
- homomorphous to an attacker controlling a set of nodes
Attacks against discv5 comprise
- Sybil attacks (a general problem)
- eclipse attacks
- sender timestamp allows fingerprinting / tracking
- static PeerID allows tracking and identifying peers
We could introduce pluggable anonymity in Waku v2, which allows using one of the following mechanisms
Because Waku does not require low latency, we can leverage mix-nets like Nym and achieve stronger anonymity guarantees than Tor.
Even with an attacker observing the whole network, mix-nets can protect anonymity.
The pluggable anonymity method could be plugged in between the sender node and the indented receiver peer.
For the relay protocol, the indented receiver would be the first relay node.
All further relay hops would not require any further anonymity methods.
For these mechanisms to work, messages are not allowed to contain identifiers like the PeerID.
Instead of setting a sender timestamp, the first relay that sees a message could set the timestamp
- the message might come directly from the sender in case identity protection is off
- the message might come from a mixnet (with a slight delay) in case protection is on
However, as @s1fr0 pointed out, an attacker could use the timestamp field to encode and transport information along the relay path.
(To protect anonymity, the timestamp field cannot be authenticated.)
A possible countermeasure against fingerprinting is pluggable transports.