Eclipse Attacks on Bitcoin’s Peer-to-Peer Network
This is part of a week(-ish) blog series where I deep-dive on a cool technology. I am an investor at Dell Technologies Capital in Silicon Valley, and occasionally reminisce about my previous life in academia. Follow me on Twitter and LinkedIn.
This week’s post is the summary of Ethan Heilman’s talk at the MIT security seminar in October 2015.
Ethan Heilman from Boston University gave a talk at the security seminar on his recent Usenix Security paper. This is very interesting work demonstrating some worrying attacks on the Bitcoin network. I will briefly highlight some ideas from his talk. If you want more details, I would refer you to his paper.
People often think that Bitcoin is secure if at least 51 percent of the mining power is honest, but this assurance relies on an assumption that all parties see valid blocks/transactions. However, Bitcoin relies on its own peer-to-peer network to deliver its information. Consequently, if you control the peer-to-peer network, you control the information flow, and subsequently, can control the blockchain. The paper attacks the Bitcoin peer-to-peer network and uses information eclipsing to subvert Bitcoin’s security.
For some background, a Bitcoin node has 117 incoming TCP connections by default, and has a maximum of 8 outgoing TCP connections. These connections form the gossip network to propagate Bitcoin transactions and blocks. The attack targets only the Bitcoin nodes that accept incoming connections because not all nodes accept incoming connections.
What is an information eclipse attack? An information eclipse attack is an attack that gains control over a node’s access to information in the peer-to-peer network. With proper manipulation of the peer-to-peer network, an adversary can eclipse a node so that it is only communicating with malicious nodes.
What can an attacker do with an eclipse attack? It allows the attacker to launch a 51 percent attack with 40 percent mining power. Suppose the network contains 3 large mining nodes. Two control 30 percent of the mining power, and one controls 40 percent. If the attack owns the 40 percent mining power node, it can partition the other 2 miners so that they cannot build off of each other’s blocks, and can outcompete each partitioned miner. As a result, the attacker’s blockchain becomes the consensus block chain. Another attack is the n-confirmation double spending attack. This attack is more complex and is described in more detail in the paper.
How does an attacker eclipse a node? To do this, an attacker can manipulate the node so that all its outgoing connections are to attacker IPs. This can be done simply. First, fill the node’s peer tables with attacker IPs. Then, the node restarts and loses its current outgoing connections. Finally, the node makes new connections only to the attacker IPs. The image below represents a more detailed description on how to carry out the attack.
One question is how easy are restarts? The attack requires the users’ nodes to restart. However, this occurs fairly frequently because of software updates, packets of death/DoS attacks, and power/network failures. As a result, Bitcoin assumes that the uptime of the node is 100%, which seems unreasonable.
How many nodes does an attacker need? With simulations, Ethan used a botnet of 4600 IPs, 2 IPs per group, and 5 hours of time to artificially fill a node’s tried IP table successfully. This is relatively small given that Walowadac Botnet has 160,000 IPs and 25,000 groups, which shows this attack is in the realm of possibility. Then, he performed a live experiment. He used 400 IPs = 400 groups and 1 IP per group with 1 hour, and populated 57 percent of the tried table with attacker IPs.
He provides some countermeasures against this attack. To prevent the attacker ensuring its IPs are fresher so they are more likely to be selected, Bitcoin should randomly select IPs with no bias toward fresher timestamps. The attacker exploited eviction bias toward older IPs and exploited the randomness in the eviction process to improve the odds of filling tried table by running the attack multiple times. To prevent this, we deterministically map IPs to buckets and positions in buckets, evicting whatever happens to be in that position.
Another problem is that the tried table fills up very slowly and contains mostly dead IPs. To prevent this, Bitcoin should make test connections to IPs to fill tried tables faster. Finally, good IP addresses from tried table gets evicted. To prevent this, Bitcoin should test IPs in the tried table and should not evict them if they are still online.
Some of these countermeasures have been included and patched. This work demonstrates that Bitcoin’s security model, like any other security model, is flawed and requires further investigation.
If you have questions, comments, future topic suggestions, or just want to say hi, please send me a note at frank.y.wang@dell.com.
