Sarah Jamie Lewis
||4 months ago|
|.idea||4 months ago|
|niwl||4 months ago|
|niwl-client||4 months ago|
|niwl-rem||4 months ago|
|niwl-server||4 months ago|
|references||4 months ago|
|.gitignore||4 months ago|
|Cargo.lock||4 months ago|
|Cargo.toml||4 months ago|
|LICENSE||4 months ago|
|README.md||4 months ago|
niwl - a prototype system for open, decentralized, metadata resistant communication
niwl (/nɪu̯l/) - fog, mist or haze (Welsh).
niwl is an experimental bandwidth efficient anonymous communication system based on fuzzytags in combination with untrusted mixing nodes and an additional untrusted routing server.
This workspace provides a prototype set of libraries, clients and servers.
Security (hic sunt dracones)
This crate workspace provides and documents a novel and highly experimental metadata resistant communication system.
The code has not undergone any significant review.
Further, it is based on an experimental implementation (fuzzytags), of an experimental cryptographic scheme (FMD2) which also has a large list of security warnings.
I urge you to not rely on this code or derivative systems until it has been reviewed and given considerable thought.
Instead of placing messages into deterministic buckets based on the recipient, Fuzzy Message Detection
allows each message to probabilistically address itself to several parties in addition to the intended party - utilizing the anonymity of the whole set of participants, instead of the ones who happen to share a bucket for a given round.
Unfortunately, naive deployments are vulnerable to intersection attacks and statistical analysis which forces a requirement an additional layer of sender anonymity is necessary to prevent metadata analysis.
In order to obtain sender anonymity without introducing an external mix network or anonymizing overlay network such as tor or i2p, we can observe that clients are free to implement any behaviour they want directly on top of the fuzzy message detection system - and that includes mixing.
How niwl Works
A niwl system relies on a single, untrusted routing server that acts as a bulletin board. We assume that clients communicate with this server via https such that network adversaries are unable to determine the exact messages sent and received by each client.
niwl clients can post and fetch messages to and from the server. When posting a message a client attaches a fuzzytag generated for the receiver that allows the receiver to not only identify the message, but also to restrict the number of other messages they have to download (see Fuzzytags and Fuzzy Message Detection)
In order to provide statistical anonymity , the above base functionality is extended by a special class of client
random ejection mixers or
REMs for short.
REMs reinforce the anonymity of the system in two ways:
REMsdownload all the of messages from the server. Thus providing cover for receivers who download only a fraction of the messages. A niwl server cannot distinguish between a message intended for a REM from a message intended for an ordinary client.
Clients can wrap messages to other clients in a message that is first forwarded to a
REMthen decrypts the message and adds it to a store of messages - ejecting a previously stored message (at random) first to make space.
Note: This comes at the cost of doubling the traffic in the system (1 message to the REM and another message to the end client). Fuzzy message detection allows clients to reduce the amount of messages they have to download.
Random Ejection Mixers (REMs)
A REM starts with a store of
n randomly generated messages with randomly generated fuzzytags. These messages are
for all intents and purposes "noise". Each REM also generates a TaggingKey that it can provide (publicly or privately)
to other clients who wish to use the REMs services.
Each REM constantly checks the niwl Server for messages. It checks each message it downloads against its RootSecret and if the FuzzyTag verifies then it proceeds to decrypt the message.
The primary service a REM provides is anonymous mixing. A decrypted mixpacket contains 2 fields:
- The fuzzytag of the message to forward.
- The message itself, which we will assume to be encrypted by some out-of-scope process.
Once a message is decrypted, an existing message from the store is randomly chosen to be ejected by the mix - and is posted to the niwl Server. The new decrypted message takes its place in the message store.
On the Privacy of REMs
Fuzzytags themselves can only be linked to receivers via those in position of a RootSecret or niwl Servers who
DetectionKey - as such, assuming that there is no collusion between a particular REM and a niwl Server
there is no mechanism through which a REM can associate message with a (set of) receiver(s).
Further, (again assuming no collusion between a particular REM and a niwl Server), there is no mechanism for a REM to associate a message with a particular sender.
Finally, and perhaps most importantly, there is no limit on the number of REMs permitted in a particular system. Different parties can select different REMs with different trust valuations. REMs can join the system at any time without permission from any other entity. In other words, unlike traditional mixnets or onion routing, the system does not rely on consensus regarding the mixing entities to ensure privacy.
On the Security of REMS
n-1 attacks /
flooding attacks and other active attacks on mixers are a valid concern with any mixing strategy.
This broad genre of attacks can be generalized as follows:
- REMs start with a pool of randomly generated messages, this protected initial messages sent to the REM.
- Over time this pool is probabilistically replaced by messages from the network.
- A malicious niwl server, having identified a REM, can flood the REM with its own messages.
- At a certain number of messages, the probability that a REM store contains only messages from the niwl server approaches 1.0.
- A niwl server can then delay every other message sent to it by other clients one-by-one.
- If the message isn't for the REM then nothing will happen.
- If the message is for the REM then the REM will either eject a message known to the niwl Server, or it will eject an unknown message than the niwl Server can then correlate with a Sender and a set of Receivers.
Before diving into mitigation strategies it is worth outlining a few properties of niwl that differ from other mixing-based anonymity systems.
- Using REMs are not mandatory; parties may exchange messages with each other directly. Doing so does introduce a vulnerability to statistical analysis.
- Different parties can rely on different REMs without compromising metadata privacy, and without negotiation.
- If a REM becomes slow to respond or sends out and error alert, parties may choose to move to a different REM.
- Different REMs can adopt different mixing strategies, and may be selective about what traffic they mix.
Additionally, we should also enumerate what could go wrong, in addition to an active attack on a particular mix.
The niwl server may deliberately drop or delay packets arbitrarily. Beyond this prototype it is worth considering incentive mechanisms such as (token-based services) to mitigate this.
niwl may attempt to perform a "tagging attack" however there is nothing within the structure of niwl packets that allows a tag to be placed on a message. The fuzzytags themselves will fail to verify if they are modified in any way, and the ciphertext itself is bound to the fuzzytag both through the derived encryption key, and the nonce. And interference with a packet is equivalent to dropping a packet.
Malicious entities can only tag their own message through the system (something that requires collusion to take advantage of). (NOTE: this is functionally equivalent to Sphinx, and it might be worth just converting this over to use Sphinx)
niwl servers may attempt to passively profile traffic originating from clients in an attempt to determine mixing nodes. REMs always download all messages from the niwl server and so the only available metadata exposed is the rate at which a REM sends messages. This can be partially mitigated by introducing random delays between individual sends, and between syncing periods.
REMs employ heartbeat messages (messages periodically sent to the niwl server addressed to the REM) to detect such attacks. If a REM does not receive its own heartbeat message shortly after it is sent, it begins injecting random messages into its pool to thwart mixers. It can also display this status publicly and/or include the status in legitimate messages alerting other clients to the malicious niwl Server.
The rate at which a niwl sends out a heartbeat message is also a vector for passive profiling. Heartbeats must not be distinguishable from other niwl traffic through their rate.
Finally, the fact that a REM operates 24/7 will make it stand out from a party that only uses the system for part of the day (or week...etc.) - the only practical defense to this is to have more services and bots make use of the niwl system other than mixers - as traffic diversity increases, the less utility tells like frequency of message sends ultimately have.
For the purposes of this prototype message are encrypted using a simple one-use, unidirectional diffie-hellman derived key, where the sending party generates an ephemeral keypair (which then uses libsodiums secretbox to perform the actual encryption). This key binds the message to a particular fuzzytag (which prevents tampering) but does nothing else to certify the authenticity of the message.
Because of this only confidentiality and integrity of the message contents is asserted - no authentication mechanisms is provided.
Any party that knows the
PublicKey and the public
TaggingKey of another party can encrypt and send messages to them,
and the recipient party has no mechanism to certify the origin of these messages.
Any applications built on top of niwl need to provide an additional encryption layer that provides authenticity (e.g. a complete diffie-hellman key exchange involving pre=exchanged long term identity public keys).
Notes on IP and other networking Metadata.
niwl is designed to provide metadata security when operated over an unprotected network. Ideally, a niwl server should learn nothing about the habits of a particular IP address other than they are using niwl. In practice, as discussed above a server can likely distinguish between automated services and manual clients.
Clients may wish to hide their use of niwl from a network adversary (at a risk of revealing that they are using another anonymizing network). This will also further reduce the ability of niwl to correlate senders with specific behaviour and can be seen as complimentary, but optional.
Notes on future work and expansions
There is no reason that a client could chain a sequence of mixers together via onion encrypted their original message to multiple mix nodes. In that sense we can treat the system as a superposition of free-route mix networks.
Analysis should be done to determine the anonymity of this system and the impact of added more mixers to the overall anonymity of the fuzzy message detection.
niwl provides common library functions useful to all other packages.
niwl-server provides a web server with a json API for posting new tags and querying the tags database.
niwl-client provides a command-line application for managing secrets, tagging keys of parties and posting / querying for new tags.
niwl-rem provides an implementation of the random ejection mixer.
For a more detailed overview please check out each individual crate.
Mix and Send
- Thanks to Erinn Atwater for helpful discussions.
- FuzzyTags is based on Fuzzy Message Detection by Gabrielle Beck and Julia Len and Ian Miers and Matthew Green
Beck, Gabrielle, et al. "Fuzzy Message Detection."
Danezis, George, and Len Sassaman. "Heartbeat traffic to counter (n-1) attacks: red-green-black mixes." Proceedings of the 2003 ACM workshop on Privacy in the electronic society. 2003.
Sampigethaya, Krishna, and Radha Poovendran. "A survey on mix networks and their secure applications." Proceedings of the IEEE 94.12 (2006): 2142-2181.