A group of hackers called, “51 Crew” attacked blockchain clones Shift and Krypton. The group took control of more than 51% of the network. Then there was the online theft of $65 million of the digital currency bitcoin from Hong Kong-based exchange Bitfinx.
Perhaps the most critical hacking incident was in May 2016, when the Decentralized Autonomous Organization (DAO), was attacked by a hacker exploiting a vulnerability in its smart contract code, dealing a blow of around $60 million.
It led to a forking of the Ethereum blockchain into Ethereum and Ethereum Classic. This was followed by a DNS attack on blockchain.info, which led to compromised passwords for bitcoin users.
All these incidents have raised doubts about the safety of blockchain, a technology known for its impenetrable information storage and sharing features.
Let us examine where the “secure” claim of blockchain technology comes from. In the diagram below, each block is stored with a link to the Secure Hash Encryption (SHA) of the previous block. Countless blocks, each with thousands of transactions, are thus linked to form a blockchain.
If any of these blocks change, the corresponding hash would change, and the change would be traced. Basis this, such a block would be rejected by the network.
The blockchain technology is based on strong, simple and effective security principles. A key component of technology maturity cycle is discovery of software defects, attempts to hack, leading to further robustness in the technology and maturity of best practices.
As blockchain evolves, law enforcement will need to have better skills and guidelines to investigate and prosecute security breaches. This should not deter firms and developers to adopt the technology and realise its benefits.
A key element of the adoption of any new technology is also the evolution of best practices around security management. We expect such best practices around private key management, data sharing, etc. will evolve over the next few years.
So, what makes such a network vulnerable to hacks? Broadly, there are three ways to all the blockchain hacking implementations. Below is a discussion in these, along with the corresponding mitigation strategies:
Stealing private key
This is the most direct way to hack into a blockchain network. Every user has a private key with which they sign transactions, and everyone on the network verifies the transaction using their public key, to assess if the original user signed it.
If a private key is stolen, all the digital currency associated with it can be compromised. The thief can sign a transaction to simply transfer all the bitcoins to his address.
To mitigate this, there are a lot of bitcoin wallets such as Blockchain.info. These wallets have security features to protect a user’s private key and can be accessed from multiple devices, including cloud-based one.
These also provide a range of services including distributing public keys, signing transactions, and broadcasting your transactions to peer-to-peer networks.
Acquiring/hacking into computing power in proof of work
In typical “proof of work” networks like bitcoin, a lot of computing power is spent to prove that a transaction is genuine. If more than 50% of the bitcoin network participants agree to a block, it is deemed as accepted.
In this situation, anyone who can hack into machines and divert the computing power to his own account can control large pieces of the network. This would allow the hacker to create a chain longer than the authentic chain, essentially allowing a dual transaction.
To mitigate this, many platforms are moving towards “proof of stake” consensus. That ensures that instead of computing power, the ability to ratify a transaction is dependent on the stake the participants have in the network. Clearly, people who are invested in a currency will not want its value crashing by ratifying rogue transactions.
For permissioned blockchains, since addition of nodes is a controlled activity, it would be difficult for a hacker to take over the network. Most enterprise applications are likely to use permissioned blockchains with some level of oversight from a governing body or participants themselves.
As the DAO example showed us, software is written by humans, and is always subject to human error. While most of the blockchain implementations done for bitcoin have been tested over the years and numerous vulnerabilities have been addressed, we cannot guarantee that there will be no more.
Further, most enterprises like the Ethereum platform, use it as a base and further customise it. They also give flexibility to developers to write their own smart contracts, thus opening more avenues for possible bugs.
Despite following all the precautions, a network can still be hacked.
To mitigate this, the software development and testing process needs to be a lot more robust. While a lot of attention is paid to functional testing, white-box security testing needs more emphasis.
We expect that many early platforms will provide limited functionality (such as asset issuance), limiting the scope for such attacks due to programmer errors.
One area in blockchain systems that has not attracted much attention so far is external system integration. These complex systems are built on blockchains requiring integration with external systems; these integration points are a weak link that hackers can target.
Many current solutions rely on “oracles”, where an oracle is a particular agent trusted by blockchain participants. Such reliance on an external agent poses many questions around system reliability and security.
We see development towards “smart oracles” that use a federation of external systems that would help reduce some of these risks.
Below is a summary of the possible threats and mitigation strategies
Despite following all the precautions, a network can still be hacked. The DAO hack shows one way hacks can be handled—by doing a hard fork of network and having participants ratify that fork instead of the longest chain prevailing.
This puts into question the principle that “blockchains are immutable”, and businesses need to have clear plans for handling situations where their network is compromised.