Enterprise blockchain has attracted attention in recent years primarily because it addresses longstanding challenges in multiparty data sharing that are made difficult, in part, because companies try to force others to adopt their proprietary data formats.
Enterprise blockchains address these issues in two ways. First and foremost, a blockchain and the smart contracts that run on it require everyone to agree on data formats and processing rules. More importantly, the rules are enforced by the system, and no manual override is available unless everyone agrees to the change. Second, because blockchain and smart contracts are so new, they’re essentially a greenfield deployment for everyone. Chances are nobody has a system they’re trying to foist on everyone else.
With new technology comes new risks that often are poorly understood. Right now, there are three major new risks for enterprise blockchain and smart contract deployments: old software, software flaws and operational flaws.
But hang on a minute. Those are the same risks we’ve been dealing with in computing for 50 years. That’s true at the meta level, but when you get down to the details, blockchains and smart contracts have their own security issues.
Here are eight blockchain security risks that I’ve identified.
1. Old software
While enterprise blockchain software is rarely “old,” anything that’s been around more than a year or two is basically a Stone Age tool in terms of change velocity and improvements.
R3’s open source Corda blockchain platform is a good example. In the five years after its initial release in May 2016, Corda had 182 releases, or roughly one every 10 days. Many of them weren’t small releases either. Major new capabilities and refactoring or removal of code were commonplace. There’s no nice way to say it: In most enterprise projects, there is a real tendency to pick a software version and never upgrade because doing so could break things.
The lesson here: Make sure your software is up to date and can be kept updated.
2. Lack of security vulnerability coverage
Enterprise blockchain software has little to no coverage in security vulnerability databases. This means most users, unless they explicitly track vendor release notes, aren’t aware of security updates. This lack of coverage, especially in the Common Vulnerabilities and Exposures (CVE) database and the U.S. National Vulnerability Database (NVD), is a huge problem because, if the vulnerabilities aren’t officially recognized, they don’t exist for many large organizations. I’m not sure why CVE and NVD coverage of blockchains is so poor, but one possible culprit is the lack of official documentation of specific blockchains’ vulnerabilities.
The lesson: Make sure you have the resources to monitor for security vulnerabilities and updates in your blockchain and smart contract software.
3. Inadequate knowledge of security vulnerabilities
Traditional software has well-understood vulnerability types, many of which are documented in the online Common Weakness Enumeration (CWE) dictionary — for example, the difference between a buffer overflow and an integer overflow as popular weaknesses for hackers to exploit. CWE is a critical resource. Many code-scanning tools use it as the basis for the types of vulnerabilities they try to detect.
Kurt Seifreid
However, CWE doesn’t cover blockchain or smart contracts specifically. The good news is there are other efforts to document these issues, including the Blockchain DLT Attacks and Weaknesses Enumeration database from my organization, the Cloud Security Alliance (CSA), with more than 200 entries covering a variety of smart contract languages, blockchain technologies and general concepts. And the Enterprise Ethereum Alliance’s EthTrust Security Levels Specification defines requirements for smart contract security audits and names some common vulnerabilities.
The lesson to be learned: Ask which vulnerabilities your code auditors or tools are looking for. They should be able to clearly articulate and explain them.
4. Lack of code scanning and security testing
The current crop of blockchain and smart contract code-scanning tools is not particularly mature for the simple reason that the space is so new. To add insult to injury, many smart contracts are deployed without a security audit. This is starting to change, but numerous security incidents have highlighted the importance of auditing code and generating new secret keys prior to deployment.
I’m not making the last one up. Paid Network, a provider of blockchain decentralized applications for financial transactions, was breached when it deployed a smart contract it had paid a developer to create, but it never removed the developer’s secret key. When the developer key was later exposed publicly in a Git commit — a process for saving program code to a repository — an attack drained the Paid Network contract.
The contract had passed a security audit. An auditor can’t audit the production secret key, which would expose it, so it would have assumed Paid Network would replace it with a securely generated key, which it did not.
Lesson learned: Make sure all smart contract code is scanned and audited and all cryptographic material is generated securely and inserted correctly.
5. Operational risks
Let’s assume you have a secure blockchain and well-formed smart contracts without any security flaws. You still have to run the blockchain and smart contract code on something that’s well connected and reliable, preferably. If you pick the cloud or third-party hosting, you need to make sure they are also secure.
Look for honesty and transparency beyond the usual statements of SOC 2 compliance. One resource for this is the CSA’s Security, Trust, Assurance and Risk registry, where you can directly compare providers’ answers.
The lesson here: Ask questions. Vendors and service providers that care about security answer them and aren’t evasive.
6. Cryptographic keys and HSM
At the core of every blockchain service and client are cryptographic keys. Keeping important cryptographic keys on a computer is no longer good enough, even when using a dedicated system.
Instead, use a hardware security module (HSM). An HSM basically provides two things a regular computer can’t. First, the keys can be set up so they cannot be exported or copied off the HSM. Second, you can more reliably log usage of the keys. This is critical because, if your network is compromised, you are able to ascertain what the attacker used your key for, instead of speculating that they might have done bad things.
The lesson: Crypto-material for sensitive operations must be stored in an HSM and backed up. General-purpose computers or servers — even air-gapped (physically separated) ones — aren’t enough.
7. Phishing, SIM swap and other shenanigans
Enterprise blockchains are generally not as widely attacked with techniques such as phishing or SIM swaps, which are typically reserved for attacking users of cryptocurrencies. However, ransomware and related attacks are increasingly turning to phishing and spear phishing for a simple reason: They work. The general answer to these types of attacks is to use strong multifactor authentication, ideally based off hardware tokens that prevent users from giving information to the bad guys.
Lesson to be learned: Humans make mistakes. You need both business and technical processes to catch mistakes and malicious behavior.
8. 51% attacks
Finally, there is some encouraging news. Most enterprise blockchain deployments don’t use the proof of work (PoW) consensus mechanism. Proof of stake or more traditional voting mechanisms, such as a majority vote, are more common.
A 51% attack, where a single entity takes over a majority of the blockchain hash rate or computing resources in an attempt to disrupt the network, is most useful against a PoW-based system. Even with a simple consensus mechanism, such as majority vote, an attacker would need to hijack 51% of the organizations — a much harder task than simply marshalling compute resources, which can often be rented.
Lesson learned: Make sure you understand the blockchain consensus mechanisms being used and in what circumstances an attacker is able to subvert them. Building a system that requires more than half of all the organizations to be subverted, for example, is probably an acceptable risk.
Conclusion
Blockchain and smart contract software are more complicated and difficult to secure than virtually anything else.
We want to build such systems knowing that malicious actors are participating maliciously but not allow them to compromise the systems. Solving this problem opens up all sorts of new markets and opportunities.
Ever since Bitcoin came on the scene in 2009, we’ve been steadily getting there with systems already in production that can withstand high levels of attack and abuse. But, like any new technology, it still requires a lot of expertise to build, deploy and operate blockchain securely.
Kurt Seifried is chief innovation officer at the Cloud Security Alliance.
