DECENT data publishing technology: secure inter-node communication

Using blockchain and data sharing like tor is a powerful and reliable way to achieve end-to-end security and anonymous communication between nodes . However, it is also slow and inefficient, especially if we want to implement a lightweight RPC, for example, over a distributed hash table (DHT). Not using any security layer represents a high risk to user anonymity, as nodes transferring data may reveal their identity or their activities. An example is a torrent file based on a magnet link , where an attacker may learn about a user's intention to download a specific file by intercepting his distributed hash table ( DHT) communication.

To prevent these types of attacks, we must implement a flexible, efficient mechanism for inter-node communication that can provide anonymity, confidentiality, and plausible deniability. The chosen mechanism is the Dynamic Encrypted UDP Tunnel ( DEUT) as described below .

Dynamically encrypted UDP channel

Actors: All nodes in the DECENT network. They can act as a sender, a channel endpoint, a relay or a receiver.

Channel: A secure channel between a master node and an end node, which can be connected to one or more repeaters.

Master Node: The node that initiates and owns a specific channel, and through which the final destination and source of all messages pass.

Endpoint: A node that acts as a gateway for communicating with another node (the master), assigning a specific listening port and sending under this port.

Relay: A node that forwards messages between master nodes, endpoints, and other optional relays within a channel. The order of relays within a given channel is fixed.

A node is identified by its IP and port pair. Channels can be established for senders or receivers . In this case, both senders and receivers have their own set of channels, as well as their endpoints and relays. The master node initializes the channel with a raw channel control request, sent to any node in its list. The receiving node is either a relay, in which case it randomly selects a node from its list as the next hop, or an endpoint, opens a listening port and is ready to send and listen on behalf of the master node. The gateway then responds with a channel control response message. In this handshake, the master node and the endpoint exchange their RSA public keys and then use these public keys to encrypt the communication.

When the master wants to send some data to a given node, it randomly selects two channels from its list, encrypts the message with the associated public key (i.e., the public key of a given endpoint), and sends it to the first relay. The relays forward the message until it reaches the endpoint. The endpoint then decrypts the message and sends it to the intended recipient, since it originated from itself.

The recipient knows the IP address and port pair of the master node , and can then further share the address with its peers (e.g., via the kademlia FIND_NODE primitive message).

When the sender wants to contact the master node and has learned the address of one of its endpoints, it sends a message to this endpoint. The endpoint learns the channel to which the message belongs from the receiving port, encrypts it with the master node's private key and then forwards it to the first relay.

All channel communications are based on UDP , so it is very fast and efficient, suitable as a transport for all kinds of RPC messages. Depending on the application, the master node will have a few hundredths of channels open, and since it randomly chooses a new channel for each message, it allows a high level of anonymity, confidentiality and non-repudiation. Therefore, the sender must expect successful communication to come from anywhere on the Internet and not necessarily (unlikely) from the address it sent from. For these reasons, DEUT implements message IDs, matching request and response pairs.

The RSA keys used are ephemeral and are recreated after each application restart.