Let's Not Make the Distributed Internet Insecure

Written by

We built the internet to be fast and efficient, but made mistakes that have led to the security problems we see today: DDoS attacks, massive breaches, thefts of huge amounts of data, and tampering with systems for either profit or political gain. In building the internet, we prioritized performance, and built the infrastructure assuming people would use it for good. Now we know better. The next generation of internet infrastructure needs to be built assuming that everything can and will be attacked. 

A key piece of the next-generation internet will be Distributed Ledger technologies (DLTs) like blockchain. DLTs allow a network of actors who don’t necessarily need to know or trust each other to nevertheless come to agreement on the order of some set of transactions - without some specially empowered and trusted third party. This holds value not only for the cryptocurrencies that have rapidly gained popularity, but also for markets, stock exchanges, games, or any other kind of distributed community you want to participate in without having to trust everyone in the community. 

Clearly, if DLTs are going to be used for real-world and meaningful use cases, then they must be protected against all sorts of possible malicious activity, as well as the likelihood of network faults. If DLTs are used to track the ownership of valuable resources (whether currency, diamonds, or real estate) then we have to expect them to be targeted - and need to prepare for that.

Two security risks to DLTs arguably do not receive their fair amount of attention: Distributed Denial of Service (DDoS) attacks, and state manipulation. Both attacks ultimately derive from consolidating the nodes that determine consensus - specifically two different types - that of control and location.

Distributed Denial of Service
A Distributed Denial of Service (DDoS) attack occurs when an attacker is able to flood an honest node on a network with meaningless messages, preventing that node from performing other (valid) duties and roles. In a DLT, those other duties would be the processing required to achieve consensus.

Consensus protocols are the engine of DLTs, and all rely on nodes sending & receiving messages, and processing and validating of those messages. In some DLTs, one or some set of nodes are ‘special’ compared to the rest. If an attacker is able to prevent such a special node from performing those consensus operations with a targeted DDoS, then consensus could be inhibited. 

Consensus models fall along a spectrum of how much they empower nodes with special privileges. A single central database is at one extreme, and a DLT where no nodes are special is at the other. DLTs that give some special privileges to some nodes sit in the middle of the continuum. Generally, the more privileges a DLT assigns to a particular node, the more vulnerable it will be to DDoS - because a DDoS against a special node will be more damaging than a DDoS against any normal node. It is consolidation of control over consensus that makes a DLT vulnerable to DDoS.

Leader-based DLTs (such as Paxos, Raft, PBFT, and dPOS) elect a leader from amongst the community of nodes. This leader plays a special role in enabling consensus (for the duration of their turn). Because the normal nodes need to know which of them is the current leader to send messages there, that knowledge could be abused by a DDoS attack against that current leader. As the leader changes, the attacker simply adjusts their target in real time, in a ‘follow the leader’ pattern. If the leader can be tied up by the DDoS, they may be unable to play their key role in enabling consensus for the other nodes.

While proof-of-work DLTs, like Bitcoin and Ethereum, also grant particular nodes special privileges, they guard against DDoS by randomizing the selection of that privileged node via the mining process (and the underlying hashing puzzle). If an attacker hoped to target miners with a DDoS to prevent a new block being added to the chain, they would be unlikely to know *which* miner would win the crypto puzzle and be granted the ability to add the block.

Consequently, the attacker wouldn’t be able to target the miner selected until after the fact. However, while proof-of-work provides DDoS resistance, the mining process introduces inefficiency and slowness, leading to expenses that cause consolidation in location.

Other consensus models guard against DDoS by using a more egalitarian distribution of the burden of determining consensus. When all nodes contribute to consensus, then knocking one out with a DDoS will not stop consensus.

DDoS attacks and the risk of government interference both highlight a fundamental reality - when more nodes secure a network, the network is less dependent on any particular nodes, and that makes it more robust. Prioritizing a few nodes to help reach consensus runs the risk of DDoS attacks, while prioritizing one location runs the risk of government interference.

If blockchain and other distributed ledger technologies are to become ubiquitous, we must understand their limitations, evaluate their security risks, and make choices on our architecture, assuming that the bad guys will be looking for ways to ‘break’ these powerful systems to their advantage as soon as we build them. 

What’s hot on Infosecurity Magazine?