docs.waku.org/docs/overview/reference/security-features.md

32 lines
3.6 KiB
Markdown
Raw Normal View History

---
title: Security Features
---
2023-05-16 21:45:00 +00:00
Waku's protocol layers offer different services and security considerations, shaping the overall security of Waku. We document the security models in the [RFCs of the protocols](https://rfc.vac.dev/), aiming to provide transparent and open-source references. This empowers Waku users to understand each protocol's security guarantees and limitations.
2023-05-16 21:45:00 +00:00
Some of the Waku's security features include the following:
2023-05-16 21:45:00 +00:00
## [Pseudonymity](https://rfc.vac.dev/spec/10/#pseudonymity)
2023-05-16 21:45:00 +00:00
Waku ensures pseudonymity across its protocol layers, using libp2p `PeerID` as identifiers instead of disclosing true identities. However, it's important to note that pseudonymity doesn't provide complete anonymity. Actions performed under the same pseudonym (`PeerID`) can be linked, leading to the potential re-identification of the actual actor.
2023-05-16 21:45:00 +00:00
## [Anonymity/Unlinkability](https://rfc.vac.dev/spec/10/#anonymity--unlinkability)
2023-05-16 21:45:00 +00:00
Anonymity means an adversary cannot connect an actor to their actions or data. To achieve anonymity, avoiding linking activities with actors or their Personally Identifiable Information (PII) is crucial. In Waku, the following anonymity features are provided:
2023-05-16 21:45:00 +00:00
- [Publisher-Message Unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the publisher of messages in the `Waku Relay` protocol cannot be linked to their published messages.
- [Subscriber-Topic Unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the subscriber of topics in the `Waku Relay` protocol cannot be linked to the topics they have subscribed to.
2023-05-14 20:34:45 +00:00
2023-05-16 21:45:00 +00:00
## [Spam Protection](https://rfc.vac.dev/spec/10/#spam-protection)
2023-05-14 20:34:45 +00:00
2023-05-17 11:37:21 +00:00
The spam protection feature in `Waku Relay` ensures that no adversary can flood the system with many messages, intentionally or not, regardless of the content's validity or usefulness. This protection is achieved through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) of `GossipSub v1.1`. Peers assign scores to their connections based on their behavior and remove peers with low scores.
2023-05-19 23:35:51 +00:00
Ongoing research is being conducted, including developing [Rate Limiting Nullifiers (RLN)](/overview/concepts/protocols#waku-rln-relay), which can be explored further at: <https://github.com/vacp2p/research/issues/148>.
2023-05-16 21:45:00 +00:00
## [Data Confidentiality, Integrity, and Authenticity](https://rfc.vac.dev/spec/10/#data-confidentiality-integrity-and-authenticity)
2023-05-18 13:16:04 +00:00
Confidentiality in Waku is ensured through data encryption, while integrity and authenticity are achieved through digital signatures. These security measures are available in [Waku Message (version 1)](https://rfc.vac.dev/spec/14#version-1) and [Waku Noise](https://rfc.vac.dev/spec/35/) protocols, which offer payload encryption and encrypted signatures. [Waku Noise](https://rfc.vac.dev/spec/35/) also facilitates secure channel negotiation within the Waku network.
2023-05-14 20:34:45 +00:00
2023-05-16 21:45:00 +00:00
## [Security Considerations](https://rfc.vac.dev/spec/10/#security-considerations)
2023-05-16 21:45:00 +00:00
In protocols like `Waku Store` and `Waku Filter`, where direct connections are required for the designated service, anonymity or unlinkability is not guaranteed. This is because peers use their `PeerID` to identify each other during direct connections, making the service obtained in these protocols linkable to the beneficiary's `PeerID`, considered Personally Identifiable Information (PII). In `Waku Store`, the queried node can link the querying node's `PeerID` to the topics being queried. Similarly, in `Waku Filter`, a full node can link the `PeerID` of a light node to its content filter.