11 KiB

Raw Blame History

title	version	status	authors
Waku Relay	2.0.0-beta2	Draft	Oskar Thorén <oskar@status.im>, Sanaz Taheri <sanaz@status.im>

Abstract
Security Requirements
- Terminology
Adversarial Model
Wire Specification
- Protobuf
- RPC
- Message
- SubOpts
- Signature Policy
Security Analysis
Future work
Changelog
Copyright
References

Abstract

WakuRelay is part of the gossip domain for Waku. It is a thin layer on top of GossipSub.

Protocol identifier*: /vac/waku/relay/2.0.0-beta2

Security Requirements

The WakuRelay protocol is designed to provide the following security properties under a static Adversarial Model. Note that data confidentiality, integrity, and authenticity are currently considered out of the scope of the WakuRelay protocol and must be handled by the upper-level protocols such as WakuMessage.

Publisher-Message Unlinkability: This property indicates that no adversarial entity can link a published Message to its publisher. This feature also implies the unlinkability of the publisher to its published topic ID as the Message embodies the topic IDs.
Subscriber-Topic Unlinkability: This feature stands for the inability of any adversarial entity from linking a subscriber to its subscribed topic IDs.

Terminology

The term Personally identifiable information (PII) refers to any piece of data that can be used to uniquely identify a user. For example, the signature verification key, and the hash of one's static IP address are unique for each user and hence count as PII.

Adversarial Model

Any entity running the WakuRelay protocol is considered an adversary. This includes publishers, subscribers, and all the peers' direct connections. Furthermore, we consider the adversary as a passive entity that attempts to collect information from others to conduct an attack but it does so without violating protocol definitions and instructions. For example, under the passive adversarial model, no malicious subscriber hides the messages it receives from other subscribers as it is against the description of the WakuRelay protocol. However, a malicious subscriber may learn which topics are subscribed to by which peers.
The following are not considered as part of the adversarial model:
- An adversary with a global view of all the peers and their connections.
- An adversary that can eavesdrop on communication links between arbitrary pairs of peers (unless the adversary is one end of the communication). In specific, the communication channels are assumed to be secure.

Wire Specification

We are using protobuf RPC messages between peers. Here's what the protobuf messages look like, as defined in the PubSub interface. Please see PubSub interface spec for more details.

In this section, we specify two things how WakuSub is using these messages.

Protobuf

message RPC {
  repeated SubOpts subscriptions = 1;
  repeated Message publish = 2;

  message SubOpts {
    optional bool subscribe = 1;
    optional string topicid = 2;
  }

  message Message {
    optional string from = 1;
    optional bytes data = 2;
    optional bytes seqno = 3;
    repeated string topicIDs = 4;
    optional bytes signature = 5;
    optional bytes key = 6;
  }
}

WakuRelay does not currently use the ControlMessage defined in GossipSub. However, later versions will add likely add this capability.

TopicDescriptor as defined in the PubSub interface spec is not currently used.

RPC

These are messages sent to directly connected peers. They SHOULD NOT be gossiped. See section below on how the fields work.

Message

The from field MAY indicate which peer is publishing the message.

The data field MUST be filled out with a WakuMessage. See the Waku Message spec for more details.

The seqno field MAY be used to provide a linearly increasing number. See PubSub spec for more details.

The topicIDs field MUST contain the topics that a message is being published on.

The signature field MAY contain the signature of the message, thus providing authentication of the message. See PubSub spec for more details.

The key field MAY be present and relates to signing. See PubSub spec for more details.

SubOpts

To do topic subscription management, we MAY send updates using SubOpts to our peers. If we do so, then:

The subscribe field MUST contain a boolean, where 1 means subscribe and 0 means unsubscribe to a topic.

The topicid field MUST contain the topic.

Signature Policy

The StrictNoSign option MUST be used.

Security Analysis

Publisher-Message Unlinkability: To address publisher-message unlinkability, one should remove any PII from the published message. As such, WakuRelay protocol follows the StrictNoSign policy as described in libp2p PubSub specs. As the result of the StrictNoSign policy, Messages should be built without the from, signature and key fields since each of these three fields individually counts as PII for the author of the message (one can link the creation of the message with libp2p peerId and thus indirectly with the IP address of the publisher). Note that removing identifiable information from messages cannot lead to perfect unlinkability. The direct connections of a publisher might be able to figure out which Messages belong to that publisher by analyzing its traffic. The possibility of such inference may get higher when the data field is also not encrypted by the upper-level protocols.
Subscriber-Topic Unlinkability: To preserve subscriber-topic unlinkability, it is recommended by Waku v2 specs to use a single PubSub topic in the WakuRelay protocol. This allows an immediate subscriber-topic unlinkability where subscribers are not re-identifiable from their subscribed topic IDs as the entire network is linked to the same topic ID. This level of unlinkability / anonymity is known as k-anonymity where k is proportional to the system size (number of subscribers). However, note that the WakuRelay supports the use of more than one topic. In that case, the unlinkability should be addressed by the upper-level protocols through e.g., Partitioned topics technique which enables K-anonymity for the peers' subscribed topic ids.

Future work

Economic Spam resistant: In the spam-protected WakuRelay protocol, no adversary can flood the system with spam messages (i.e., publishing a large number of messages in a short amount of time). Spam protection is partly provided by GossipSub v1.1 through scoring mechansim. At a high level, peers utilize a scoring function to locally score the behavior of their connections and remove peers with a low score. The WakuRelay protocol aims at enabling an advanced spam protection mechanism with economic disincentives by utilizing Rate Limiting Nullifiers. In a nutshell, peers must conform to a certain message publishing rate per a system-defined epoch, otherwise, they get financially penalized for exceeding the rate. More details on this new technique can be found in Waku RLN Relay.
Providing Unlinkability, Integrity and Authenticity simultaneously: Integrity and authenticity are typically addressed through digital signatures and Message Authentication Code (MAC) schemes, however, the usage of digital signatures (where each signature is bound to a particular peer) contradicts with the unlinkability requirement (messages signed under a certain signature key are verifiable by a verification key that is bound to a particular publisher). As such, integrity and authenticity are missing features in the WakuRelay protocol in the interest of unlinkability. In future work, advanced signature schemes like group signatures can be utilized to enable authenticity, integrity, and unlinkability simultaneously. In a group signature scheme, a member of a group can anonymously sign a message on behalf of the group as such the true signer is indistinguishable from other group members.

Changelog

Added initial threat model and security analysis

2.0.0-beta2

Next version. Changes:

Moved WakuMessage to separate spec and made it mandatory
StrictNoSign

2.0.0-beta1

Initial draft version. Released 2020-09-17

Copyright

References

Re topicid: NOTE: This doesn't appear to be documented in PubSub spec, upstream? -->

11 KiB Raw Blame History

Table of Contents