Using blockchain and tor-like data sharing is a robust and reliable way for e2e secure and anonymous communication between nodes. However, it is also very slow and inefficient, especially if we want to implement a kind of lightweight RPC, e.g. for DHT implementation. Not using any security layer represents a high risk for a subscriber’s anonymity, since the nodes may transfer data that either reveals their identity or their activity. An example is a torrent based on a magnet link where the attacker may realize the intention of a user to download a specific file by intercepting his DHT communication.
In order to prevent these kinds of attacks, we have to implement flexible and efficient mechanism for inter-node communication that provides anonymity, privacy and plausible deniability. The mechanisms chosen are dynamic encrypted UDP tunnels (DEUT) described below.
Dynamic Encrypted UDP Tunnels
All nodes in DECENT network. They can act either as a sender, a, tunnel endpoint, a relayer or a receiver.
Tunnel – a secure channel between a master node and an endpoint, optionally relayed with one or more relayers.
Master node – a node initiating and owning the specific tunnel, and the final destination and the source of all messages passing through the tunnel.
Endpoint – a node that acts as a gateway for communication with another node (master node), allocates the specific listening port and sends under this port.
Relayer – a node relaying messages inside the tunnel between a master node, an endpoint and optionally other relayers. The order relayers are fixed in the given tunnel.
The node is identified by its IP and the port pair. Tunnels can be established either for senders as well as for receivers. In such case both sender and receiver have own sets of tunnels, with their endpoints and relayers. The master node initializes the tunnel with TunnelContolRequest primitive, sends to an arbitrary node in its list. The receiving node is either relayer, and in such case it selects random nodes from own list of known nodes as a next hop, or an endpoint, which opens the listening port and is ready to send and listen on behalf of the master node. The gateway then answers with TunnelControlResponse message. During this handshake, the master node and the endpoint exchange their RSA public keys and the further communication is then encrypted with these keys.
When the master node wants to send some data to a given node, it randomly selects two tunnels from its list, encrypts the message with the associated public key (i.e. the public keys of the given endpoints) and sends it to the first relayer. The relayer forwards the message, until it reaches the endpoint. The endpoint then decrypts the message and sends it to the intended recipient as it was originated by itself.
The recipient learns the IP address and the port pair of the master node and further can share the address with its peers (e.g. via kademlia FIND_NODE primitive).
When the sender wants to contact the master node and has learnt the address of one of its endpoints, it sends the message to this endpoint. The endpoint learns by the receiving port which tunnel the message belongs to, encrypts it with the master node’s private key and forwards it to the first relayer.
All tunnel communication is UDP, and is thus very fast and efficient, suitable as a transport for various RPCs. Depending on the application the master node will have hundredths of tunnels open, and since it will randomly select new ones for each message, it allows the high level of anonymity, privacy and deniability. As a consequence, the sender must expect the successful communication to come from anywhere on the Internet, not necessarily (and not probably) from the address it sends it to. For these reasons, the DEUT implements a message ID, matching request and response pair.
The RSA keys used are short-lived and are recreated after every restart of the application.