8 blockchain security risks to weigh before adoption
Why is enterprise blockchain so hot right now? It boils down to two main reasons: existing multi-party data sharing and processing is beyond disastrous, and everyone wants to force other people to use their own homegrown system and data format.
Enterprise blockchains address these issues in two ways. First and foremost, the blockchain and smart contracts force everyone to agree on data formats and processing rules and, more importantly, these rules are enforced But with new technology comes new risks — often, risks that are not well understood, if they’re known at all. Right now, there are three major new risks for enterprise blockchain and smart contract deployments: old software, software flaws and operational flaws.
Hang on a minute. These are the same risks we’ve been dealing with in computing for 50 years. At the meta level they are, but when you get down to the details, like any technology, blockchains and smart contracts have found new and creative ways to create security risks.
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. From its initial release in May 2016 to May 2021 (version 4.8), 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, since doing so could break things.
The lesson here: Make sure your software is up to date and can be kept updated, but if it can’t, why not?
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, won’t be aware of security updates. This lack of coverage, especially The lesson: Make sure you have the resources to monitor for security vulnerabilities and updates in the blockchain and smart contract software you are using.
3. Lack of security vulnerability knowledge
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 will try to detect.
Kurt Seifried
However, as of May 2021, CWE doesn’t cover blockchain or smart contracts, specifically. The good news is there are two efforts to document these issues, the SWC Registry (with 30-plus entries on the Solidity smart contract language used The lesson to be learned: Ask which vulnerabilities your code auditors or tooling will be looking for; they should be able to clearly articulate and explain it.
4. Lack of code scanning and security testing
The current crop of blockchain and smart contract code-scanning tools is not very 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 there have been numerous security incidents that taught people 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 (dApps) 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 they would have assumed Paid Network would replace it with a securely generated key, which it did not.
Lesson learned: Ensure 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 that don’t have any security flaws. You still have to run the blockchain and smart contract code on something, preferably, well connected and reliable. If you pick the cloud or third-party hosting, you will need to ensure they are also secure.
Look for honesty and transparency beyond the usual statements of SOC 2 compliance. One resource for this is the Cloud Security Alliance’s Security, Trust, Assurance and Risk (STAR) registry, which allows you to directly compare providers’ answers.
The lesson here: Ask questions. Vendors and service providers that care about security will answer them and not be 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 with an HSM. This is critical because if your network is compromised, you’ll be 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 won’t do.
7. Phishing, SIM swap and other shenanigans
Enterprise blockchains are generally not as widely attacked using techniques such as phishing or SIM swaps, which are typically reserved for attacking customers of cryptocurrencies. However, ransomware and related attacks are increasingly turning to phishing and spear phishing for one simple reason: it works. The general answer to these types of attacks is to use strong multifactor authentication, ideally based off hardware tokens that will prevent users from giving information to the bad guys, even if they are fooled.
Lesson to be learned: Humans will make mistakes. You need to create both business and technical processes to catch mistakes and malicious behavior.
8. 51% attacks
Finally, some encouraging news. In most enterprise blockchain deployments, the consensus mechanism used is not proof of work (PoW). More commonly, proof of stake or more traditional voting mechanisms such as a majority vote are used.
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 a 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 would be 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
I have good news and bad news. The bad news is blockchain and smart contract software is more complicated and difficult to secure than virtually anything else. The good news is the problem they are trying to solve is really hard.
We want to build information processing systems knowing that malicious actors are participating maliciously but not allow them to compromise the system. Solving this problem will open up all sorts of new markets and opportunities.
Based on the progress since Bitcoin came on the scene in 2009, we’re getting there steadily, with systems already in production that can withstand high levels of attack and abuse. But like any new technology, it will still require a lot of expertise to build and deploy blockchain securely and operate it securely.
About the author
Kurt Seifried is chief blockchain officer and director of special projects at the Cloud Security Alliance.