Today I would like to highlight a post from the website Hacker, Distributed (run by Computer Scientist Emin Gün Sirer) I recently have the luck to catch on by a friend of mine. It concerns a research paper and effort to disclose the vulnerabilities in the Bitcoin network to Internet routing attacks. The conclusions in the paper apply also to other cryptocurrencies, and represents efforts to enhance the research base in the broader security and network robustness of Blockchain technology space.
The problem that the authors diagnosed as pertaining to the vulnerabilities Bitcoin and cryptocurrencies might face isn’t to do with cryptography and the inherent quality of crypto protocols or crypto software libraries. It is instead about the Internet routing infrastructure, which happens to be insecure:
As an attacker, being able to prevent the spread of information in such a network seems unrealistic, if not impossible.
Yet, this apparently sensible observation does not take into account that the Internet routing infrastructure (i.e., the set of protocols that govern how Internet traffic flows) is notoriously insecure and can easily be manipulated by attackers to intercept Bitcoin traffic. It also does not consider that large Internet Service Providers (ISPs), such as the ones sitting in the core of the Internet, might be naturally crossed by a large fraction of Bitcoin traffic already.
The other important point made by the authors of this paper – a group of Computer Science and Computer security researchers from the Zürich’s ETH of indisputable scientific and technological quality -, is the fact that although vented as a decentralised network, Bitcoin reveals to be increasingly a centralised network, where a small percentage of participant nodes control the majority of the network, and especially so from an Internet routing perspective:
- Bitcoin is surprisingly centralized from an Internet routing perspective: 20% of the Bitcoin nodes are hosted in less than 100 IP prefixes. To put this in perspective, there are close to 600,000 IP prefixes advertised in the Internet today. At the same time, few well-established ISPs (e.g. Hurricane Electric) naturally see a large fraction of the Bitcoin traffic. Together, these two characteristics make large-scale routing attacks surprisingly practical.
- Because of its centralization, partitioning the Bitcoin network and isolate 50% of its mining power only requires a small routing attack, one which is orders of magnitude smaller than the attacks routinely seen in the Internet today. Any malicious ISP with access to the Internet routing infrastructure can perform this attack which starts to be effective after only few minutes (according to our own measurements on the live network).
- While multi-homing and end-to-end encryption (BIP 151) reduce the risks of network attacks, they do not prevent them. Our results show that even heavily multi-homed mining pools are vulnerable to routing attacks. Further, end-to-end encryption do not prevent an attacker from dropping Bitcoin connections.
This seems to call for an overhauling of the security of the current Internet routing infrastructure, something that hints at stumble blocks from a more institutional or technological governance bureaucracy slow to change and without a culture of rapid change and innovation… next the author explain more neatly what partitioning attacks are:
With partitioning attacks, an attacker aims at splitting the Bitcoin network into (at least) two disjoint components such that no information (e.g. transaction) can be exchanged between them. To partition the network into two components, a network attacker intercepts all the traffic destined to all the Bitcoin nodes contained within one of the component and drops any connection to the other component. To intercept traffic, a network attacker relies on vulnerabilities in the Border Gateway Protocol (BGP), the only Internet routing protocol used today, which does not validate the origin of routing announcements. These attacks, commonly referred to as BGP hijacks, involve getting a router to falsely announce that it has a better route to some IP prefix.
By hijacking all the IP prefixes pertaining to the nodes in one component, the attacker can effectively intercept all the traffic exchanged between the two components. Once on path, the attacker can sever all these connections effectively disconnecting the two components. An animation of the attacks can be found on our website.
The extreme centralization of Bitcoin from an Internet viewpoint makes partition attacks particularly effective as few IP prefixes need to be hijacked. Indeed, our measurements show that 50% of Bitcoin mining power is hosted in only 39 prefixes (i.e., in 0.007% of all Internet prefixes). This allows an attacker to isolate ~50% of the mining power by hijacking only these 39 prefixes. Much larger BGP hijacks (involving orders of magnitude more IP prefixes) are routinely seen in the Internet today.
The paper by these researchers is an example of how good computer security research should be done. They present the possible attack that could be made to a network of nodes in a cryptocurrency from the perspective of what realistically can be done with what is out there in the open. That is, in spite of the costs of setting up or the uncertainty about if an attack is actually going to happen, the researchers pose the possibility the attack would happen under the appropriate circumstances:
While intercepting Bitcoin traffic using BGP hijacking is effective, any un-intercepted Bitcoin connection bridging the two components would quickly render the partition ineffective. Due to factors such as multi-homing, some nodes cannot be prevented from exchanging information, forming some kind of persistent connections. The presence of such connections makes partitioning attacks more challenging for the attacker, but not impossible. In our paper, we elaborate on how an attacker can provably identify and mitigate these persistent rogue connections by reducing the size of the partition she is trying to achieve.
By partitioning the network, the attacker forces the creation of two parallel blockchains. After the attack, all the blocks mined by the side with the shorter chain will be discarded together with all included transactions and the corresponding miners’ revenues. Moreover, discarded transactions will be irrecoverably canceled if there exist other transactions in the prevailing branch of the chain which spent the exact same Bitcoins (conflicting transactions).
Bitcoin nodes are designed to request blocks from only a single peer to avoid overtaxing the network with excessive block transmissions. The block is requested again (from another peer) only if the request is not answered after 20 minutes. This design decision, coupled with the fact that Bitcoin traffic is unencrypted, allows for a powerful attack in which anyone intercepting Bitcoin traffic can delay block propagation on the corresponding connections. To do so, the attacker performs simple modification to the content of the Bitcoin messages she intercepts. As Bitcoin messages are not protected against tampering, neither the receiver nor the sender have any indication that the message has been modified, allowing the attacker to stay under the radar. The actual impact of such an attack depends on the victim and ranges from double spending (for merchant nodes) to wasted computation power (for miners). An animation of the attack can be found here.
Like for partition attacks, the centralization of Bitcoin nodes in few networks and prefixes, combined with the centralization of mining power in few pools, make delay attacks practical. We found that three ISPs together see 60% of all Bitcoin traffic. If malicious, these ISPs could therefore effectively and invisibly keep many bitcoin nodes uninformed. Unlike partitioning attacks though, we also found that even these powerful attackers could not disrupt the entire cryptocurrency. So, even though many nodes would be slowed down, Bitcoin, as a whole, would still function.
This is one of those important papers to read for anyone that implemented or ois thinking to implement Blockchain technology within their businesses or as a personal financial alternative investment. Surely this technology and Bitcoin in particular are deeply elegant and interesting feats by their own, but the current vulnerabilities shouldn’t be underestimated. Research efforts such as these are indeed good contributions for possible improvements forward. The authors concluded and summarized their paper on the optimistic tone side, providing possible solutions to overcome possible attacks to the Bitcoin network:
Fortunately, there are both short- and long-term countermeasures against network attacks. First, peer selections could be made routing-aware. Bitcoin nodes could, for example, aim at maximizing the diversity of the Internet paths seen by their connections to minimize the risk that an attacker can intercept all of them. Moreover, nodes could monitor the behavior of their connections to detect events like abrupt disconnection from multiple peers or unusual delays in block delivery. These events could serve as an early indicator of a routing attack and could, for instance, trigger the establishment of extra randomly selected connections. Finally, solutions like end-to-end encryption would also help (especially against delay attacks). Yet, encryption alone would not be sufficient to protect against partitioning attacks as an attacker can still drop encrypted Bitcoin connections.
The purpose of our research is to raise the awareness of the Bitcoin community on the need to prevent routing attacks from disrupting the cryptocurrency. While we have no evidence that large-scale routing attacks against Bitcoin have already been performed in the wild, we believe few key characteristics make these attacks practical and potentially highly disruptive. These characteristics include: the high centralization of Bitcoin (from a mining and routing perspective), the lack of authentication and integrity checks, and some design choices pertaining, for instance, to how a node requests a block. We are currently in the process of implementing some of the countermeasures highlighted above. Clearly, we wouldn’t mind some help in doing so!