Every single discussion of blockchain seems to start with some variant of the phrase “secure, distributed hyperledger.” I take no issue with the fact that it’s a hyperledger—in other words, a continuously growing list of linked records. And I have no problem describing it as distributed—in this case, across a peer-to-peer network communicating over a protocol that describes how to validate new records being added to the chain.
But it seems to me we’re jumping the gun on describing blockchain as “secure.” That’s a high-bar claim for any system, which must be proved again and again in various levels, scenarios, applications, and other contexts. It would be more accurate to describe the technology as a cryptographically secured distributed hyperledger. This definition that leaves open the crucial question of whether that tactic alone is sufficient to reduce a blockchain’s vulnerability to tampering, password theft, malware-borne denial of service, and other attacks.
In fact, you don’t need to wade out too far into the growing blockchain literature before the security vulnerabilities just jump out at you. In fact, the security issues with blockchain seem to form a chain of their own, in which the weak links start to overwhelm the strengths conveyed by the technology’s underlying reliance on strong public key cryptography. As you contemplate the fact that more the world’s stored wealth and commercial exchange value is starting to ride on blockchains of one sort of another, the security vulnerabilities of this technology start to loom larger in your consciousness.
Blockchain is more than a distributed database—it’s a growing system of record on which the global economy will rely intimately. So how secure is it, in reality? And how much cost, time, and trouble should any of us be spending to put our blockchain implementations into a secure-enough form before we can justify putting mission-critical assets on a distributed hyperledger?
What’s clear is that, more often than not, we users are blockchain’s weakest link. Attackers will continue to exploit endpoint vulnerabilities—in other words, our own inability to secure the blockchain identities, keys, credentials, and software that we install on our PCs, mobile phones, and other systems. In practice, that could expose us to phishing, malware, password dictionary attacks, and other attack vectors that leave our chain-based assets—such as cryptocurrency—wide open for the taking.
When it supports complex commercial transactions, blockchain will often execute what’s known as “smart contracts,” which themselves could pose a serious security vulnerability. Smart contracts, which are written to a blockchain, can encode complex business, financial, and legal arrangements. If they have access to the keys of an administrator of a permissioned blockchain, criminals might be able to introduce bogus smart contracts that let them surreptitiously access confidential information, steal cryptographic keys, launch unauthorized funds transfers, and engage in other attacks on your business assets.
The complexity of a fully built out blockchain ecosystem is also a vulnerability to which the average user may be oblivious. In addition to needing to secure endpoints and the systems that manage smart contracts, you’ll also need assurance on the security of the cryptocurrency payment processors and of the solutions that integrate blockchains into your enterprise application systems. That, in turn, requires intensive vetting of the trustworthiness of the vendors of blockchain systems, which you may be challenged to do, considering how few IT professionals have experience with this immature technology.
Unfortunately, with new blockchain solution vendors are coming online every day, many of them may lack a track record, reference customers, or case studies that you can rely on to ascertain their trustworthiness.
Even with established providers, commercial blockchain solutions may be new to market, or being released in alpha or beta versions long before they’re ready for enterprise primetime, so you run the risk of running your blockchain on untested, buggy, insecure code that hasn’t yet been field-hardened and hasn’t been proven to scale.
Furthermore, there are many blockchain protocols, smart contract mechanisms, gateways, and exchanges in deployment, each with its own bugs and security vulnerabilities. Your enterprise may be implementing heterogeneous blockchains—permissioned and permissionless, internal and B2B—into siloes supporting diverse applications. You will need to address the vulnerabilities of each environment in isolation, and, should you try to bridge them to each other or into a larger big-data ecosystem, mitigate whatever security issues rear their ugly heads in the complex interactions amongst these environments.
If one of the blockchain in which you’re participating is managed by a consortium, you will need to vet that organization’s operating procedures in detail before trusting that it is managing the environment from end to end with tight security. Given that there are no universal regulations that these consortia must conform to, you will have to evaluate each consortium’s security practices separately, without assurance that any one blockchain’s security level is directly comparable to another’s. The anonymity that some blockchain consortia allow blockchain participants to maintain may provide cover for fraud and make it difficult for the authorities to finger perpetrators.
Even more worrisome is the fact that the mining farms on which blockchains are built are hosted all over the world. Though this may give the blockchain in question some degree of redundancy and resilience, it could expose it to depredations of shady operators who collusively defraud unwitting blockchain participants through what’s often called a “51 percent attack.” If one party or a cabal of conspirators controls more than half of the computing nodes currently being used for mining on a given blockchain, it can achieve the consensus “proof of work” needed to surreptitiously write fraudulent transactions to that chain that benefit itself at the expense of other participants.
This threat is especially acute as a blockchain is being started, when the number of mining nodes is small and it’s therefore easier for one individual or collusive group to acquire at least half of the available computing power. It may become even more serious as crypto mining operations are offshored to nations and regions where electric power is cheap, regulatory oversight nonexistent, and criminals and terrorists abundant.
How will the blockchain industry address these vulnerabilities in a comprehensive fashion? For starters, Wikibon (the research firm I work for) urges the Linux Foundation to kickstart a hyperledger project dedicated to establishing an open, flexible framework for securing blockchains end-to-end security, encompassing application endpoints, enterprise gateways, and so on. Wikibon also calls on enterprise software vendors to incorporate strong security into their blockchain deployment accelerators.
Don’t get carried away by the utopian hype surrounding blockchain. These open source hyperledgers are just more threads in the hybrid cloud data environments on which more enterprises are deploying mission-critical applications.
You should only implement blockchain if you’ve vetted its vulnerabilities, instituted necessary technical and procedural safeguards, and determined that the potential business value outweighs the risks.