To defeat “Five Eyes” Surveillance, you’ll need the Privacy Properties of the Nym mixnet
The Nym mixnet is the first open-source incentivized infrastructure for anonymous communication resistant to mass surveillance. But what does this mean? In this blog post, we analyze the Nym’s threat model and explain which anonymity properties it offers.
Nym’s mixnet architecture
Let’s start with a brief reminder of the Nym network architecture (for more details check our documentation.)
The Nym network acts as an infrastructure which adds “layer 0” privacy to privacy-enhancing applications and services, to which we refer as service providers. By “layer 0” we refer to the level of network packets (i.e., TCP/IP and UDP packets). The clients access the service providers via the Nym mixnet, instead of going via open internet.
The goal of the Nym mixnet is to protect both the content and metadata of users’ communication, thus ensuring that users are unlinkable to their transactions and access to services. In other words, Nym mixnet protects not only the confidentiality of your communication, but also hides the information who is communicating with whom, or how much data is being exchanged. If you’re not familiar with the concept of a mix network, you can find a detailed introduction in the previous blog posts here and here. In a nutshell, a mixnet is an overlay network that routes traffic via a set of mix nodes, where each node cryptographically processes the received packets and reorders them, making them untraceable not only based on content but also on timing, thus makes your communication untraceable.
The Nym mixnet is accessible via a set of gateways, which act as proxies. Gateways provide the clients access to the mixnet while protecting it from denial of service and Sybil attacks, including “free-riding”. Similarly, the service providers talk to the Nym mixnet by connecting to gateway nodes. Gateway nodes act also as message storage for clients and services who may go offline, thus allows unreachable participants to receive messages. This is especially useful if your Nym client is on a mobile device, which might often lose the network signal. The gateway shares a secure channel with each client or service provider. Participants may choose to always use the same gateway, or split their traffic over multiple gateways.
Nym’s threat model
Nym aims to provide privacy towards adversaries more powerful than those considered by the currently existing solutions like VPNs or Tor. In particular, Nym considers:
- a global network observer, i.e., an adversary who is able to monitor communications between all the participants and components of the network. In addition to passive monitoring, the attacker can also inject, modify, and drop packets.
- malicious node operators, i.e., the adversary can compromise a fraction of the network participants, including mixed nodes, gateways, service providers, and end-users.
Thus, Nym assumes an adversary with ANY combination of the mentioned capabilities.
Let’s now define the fundamental anonymity properties:
Third-party relationship anonymity
Relationship anonymity also referred to as relationship unlinkability, means that any unauthorized third party cannot infer whether two system participants are communicating. In other words, although the adversary might be able to tell who sends which packets, or who receives which packets, the adversary cannot link the sent and received packets, thus cannot link the communicating sender and receiver.
This property is considered with regards to outsiders only, i.e., the adversary being neither the sender nor a recipient of the data packet under consideration. The relationship anonymity assumes that the sender and receiver know each other’s identities. However, they might also want to hide it from each other. Thus, we also consider the following anonymity properties.
Sender anonymity means that the identity of the party who sent a message is hidden. This means that from the perspective of the receiver it is not possible to identify which user sends the particular packet, even if the malicious receiver colludes with the adversary.
This is the property that the original cypherpunks had with anonymous email.
Receiver anonymity means that the identity of the receiver is hidden, not only from communication outsiders but also from the sender, even if they are colluding. This is the property you want if you are running some sort of hidden service.
By combining sender and receiver anonymity, we obtain bi-directional anonymity, meaning that the sender and receiver can communicate without knowing each other’s identities.
Anonymity properties in practice
Various systems offer various anonymity properties under various threat models. Let’s take as an example VPN and Tor. Both VPN and TOR hide the IP address of the request sender from the accessed website, however, they assume different threat models. VPNs are designed to guard against malicious ISP providers, censorship, and snooping on your internet connection. However, the VPN provider always knows your IP and can see connection data and traffic passing through its servers. Hence, you and your communication are not anonymous vis a vis the VPN provider. Thus, as you see VPN offers sender anonymity only under the assumption that the VPN proxy is trusted!
Although VPNs shield our online activities, they are ineffective in the presence of network eavesdroppers, who can simply track the routed network traffic based on the size and timing of the data packets, and thus easily correlate our IP address with the services we are visiting. Hence, VPNs do not provide third-party relationship anonymity.
In contrast to single proxy VPNs, Tor builds upon a decentralized overlay network and thus avoids a single point of trust/failure. Tor assumes an adversary who “can observe some fraction of network traffic; who can generate, modify, delete, or delay traffic; who can operate onion routers of his own; and who can compromise some fraction of the onion routers”.
Tor routes the connection via a sequence of servers run by volunteers, so a single Tor relay cannot link both the sender and destination of the communication. Hence, as long as at least one node in the circuit is honest, Tor offers stronger sender anonymity than VPNs.
While VPNs do not offer receiver anonymity, Tor offers the option of hidden services, which run within the Tor network and allow you to register a Tor-only service that gets its own .onion address. Hidden services have receiver anonymity since the client doesn’t learn the IP of the anonymous server sitting behind the onion address. This combined with the fact that hidden service doesn’t learn the IP of the client gives the bi-directional anonymity.
Tor is defending the information who is communicating with whom only against attackers who can observe only a small part of the network. Thus, Tor does not provide strong third-party relationship anonymity against an adversary capable of watching all the traffic in the network, like the NSA and their friends in the “Five Eyes.”
What anonymity properties Nym aims to provide?
Let’s now look into the privacy properties which will be offered by Nym. Keep in mind that when we discuss those properties we assume the adversary with the capabilities described above (see Nym’s threat model), thus an adversary much stronger than the ones assumed by VPN and Tor.
First, the third-part relationship anonymity. In contrast to VPN, Tor or other currently existing solutions the Nym mixnet provides third-party relationship anonymity. Thus, even if the adversary has a global view of the network he cannot correlate the communicating clients and service providers. This property is provided even if the adversary controls the first and last mix node, or a fraction of gateways.
Nym mixnet offers also sender anonymity, meaning that from the perspective of the service provider, it is not possible to identify which Nym user initiated a specific request, even if a malicious service provider would collude with our adversary.
Finally, let’s talk about receiver anonymity, a property which means that the identity of the receiver of a request is hidden from an unauthorized party. Although by design the applications and services integrated with Nym are accessible via Nym mixnet, not via an open web, do not confuse them with Tor hidden services! Right now, Nym does not offer hidden services, so it does not provide receiver anonymity. However, this will change in the future!
Sender anonymity in v0.8.0
As Dave mentioned in his previous post, if you update your testnet Nym node to the recently released version 0.8.0 and look at the changes you probably noticed that…there is no sender anonymity!
But no worries, we didn’t forget about it! We decided to do it for a reason. Our dev team added to our Nym client the SOCKS5 integration to allow easy application integration, like for example cryptocurrency transactions. However, adding SOCKS5 raised a very important question regarding anonymous replies. In traditional communication systems, when Alice sends a request to a service provider, this service provider learns her IP address and thus knows where to send the response. But this is not a case in mixnets, since you want to hide your IP address from the service provider.
Single-Use Reply Blocks
Currently, the Nym mixnet implements the Sphinx Single Use Reply Blocks (SURBs), which make replies as secure as forwarding messages. In a nutshell, when Alice wraps her request for the service provider into the Sphinx packet format, she encapsulates in the most inner layer of the payload a new pre-computed Sphinx header and a set of keys. Once the service provider is ready to send the response, he uses the keys to layer encrypt the response and combines this newly computed Sphinx payload with the header obtained from Alice.
But what if the response is larger than what a SURB can accommodate? Or the SURB got dropped in the network? This would have a huge impact on the reliability of the network! One could suggest simply re-using the SURB, but this a really bad idea. If the adversary records the input and output packets of the mix nodes and you resend the same packet again, that packet decryption will remain the same. Thus, the attacker can completely break the security of the network.
In general, designing a schema which allows for multiple anonymous replies is not trivial, since various potential solutions have different security versus performance trade-offs. Therefore, for the time being of version 0.8.0 we “turned off” the sender anonymity (i.e., the receiver’s gateway is informed who is the sender), and we are currently getting ready for deploying a solution that combines sender anonymity with multiple replies, while of course maintaining the relationship anonymity we already have. This has never been done before by any system, but we have an initial design and we’re validating it right now. We are planning to get this into the next major mixnet release (0.9.0).
Hopefully, by now we dispelled all doubts about the adversarial model Nym is considering, and what basic anonymity properties Nym mixnet aims to provide. In addition to those anonymity properties Nym network is resistant to Sybil attacks, eclipse attacks and many more, but we will discuss them in detail in future blog posts.