8 Blockchain Security Risks to Weigh Before Adoption

Enterprise blockchain has gained attention in recent years primarily because it addresses long-standing challenges in sharing multi-party data that are made difficult in part because companies try to force others to adopt their own data formats.

Enterprise blockchains address these issues in two ways. First of all, a blockchain and the smart contracts that run on it require everyone to agree on data formats and processing rules. Most 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, this is essentially a greenfield deployment for everyone. Chances are, no one has a system that they try to force on everyone else.

With new technology comes new risks that are often poorly understood. Right now, there are three major new risks to enterprise blockchain and smart contract deployments: old software, software bugs, and operational bugs.

But wait a minute. These are the same risks we’ve faced in computing for 50 years. This is 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 I’ve identified.

1. Old software

While enterprise blockchain software is rarely “old,” anything that’s been around for more than a year or two is basically a Stone Age tool in terms of speed of change and improvements.

R3’s open source Corda blockchain platform is a good example. In the five years since its initial release in May 2016, Corda has had 182 releases, or roughly one every 10 days. Many of them were not small releases either. Major new capabilities and refactoring or removing code were commonplace. There’s no good way to say it: In most enterprise projects, there’s a real tendency to pick a software version and never upgrade because it can break things.

The lesson here: Make sure your software is up to date and can be updated.

2. Lack of security vulnerability coverage

Enterprise blockchain software has little to no coverage in security vulnerability databases. This means that most users are not aware of security updates unless they specifically check for vendor release notes. This lack of coverage, especially in the Common Vulnerabilities and Exposures (CVE) database and the US National Vulnerability Database (NVD), is a major problem because if the vulnerabilities are not officially recognized, they do not exist for very large organizations do not. . I’m not sure why CVE and NVD coverage of blockchains is so weak, but one possible culprit is the lack of official documentation of specific blockchain vulnerabilities.

The lesson: Make sure you have the resources to monitor for security vulnerabilities and updates in your blockchain and smart contract software.

3. Insufficient 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 this as the basis for the types of vulnerabilities they try to detect.

Kurt Seifreid

However, CWE does not 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 over 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 lists some common vulnerabilities.

The lesson to learn: Ask what vulnerabilities your code auditors or tools are looking for. They must be able to articulate and explain it clearly.

4. Lack of code scanning and security testing

The current crop of blockchain and smart contract code-scanning tools are 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 before deployment.

I’m not making up the last one. Paid Network, a provider of blockchain decentralized applications for financial transactions, was breached when it deployed a smart contract that it paid a developer to create, but it never removed the developer’s secret key. When the developer key was later disclosed in a Git commit—a process of saving program code to a repository—an attack drained the Paid Network contract.

The contract passed a security audit. An auditor cannot audit the production secret key, which would expose it, so he would have assumed that Paid Network would replace it with a securely generated key, which it did not.

Lesson Learned: Make sure all smart contract codes are scanned and audited and all cryptographic material is securely generated and inserted correctly.

5. Operational risks

Let’s assume you have a secure blockchain and well-formed smart contracts without any security flaws. You should still use the blockchain and smart contract code on something well-connected and reliable, preferably. If you choose cloud or third-party hosting, make sure it’s secure as well.

Look for honesty and transparency beyond the usual statements of SOC 2 compliance. One source for this is the CSA’s Security, Trust, Insurance and Risk Register, where you can directly compare providers’ responses.

The lesson here: Ask questions. Vendors and service providers who care about security answer them and are not evasive.

6. Cryptographic keys and HSM

At the heart 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.

Use a hardware security module (HSM) instead. An HSM basically provides two things that a regular computer cannot. First, the keys can be configured so that they cannot be exported or copied from the HSM. Second, you can record the use of the keys more reliably. This is critical because if your network is compromised, you can determine what the attacker used your key for, instead of speculating that they may have done bad things.

The lesson: Crypto material for sensitive operations must be stored and backed up in an HSM. General-purpose computers or servers – even air-gapped (physically separated) ones – are not enough.

7. Phishing, SIM swapping and other scams

Enterprise blockchains are generally not as widely attacked with techniques such as phishing or SIM swaps, which are typically reserved for attacking cryptocurrency users. However, ransomware and related attacks are increasingly turning to phishing and phishing for a simple reason: it works. The common answer to these types of attacks is to use strong multi-factor authentication, ideally based on hardware tokens that prevent users from giving information to the bad guys.

Lesson to learn: People make mistakes. You need both business and technical processes to catch errors and malicious behavior.

8. 51% attacks

Finally, there is some encouraging news. Most enterprise blockchain deployments do not use the proof of work (PoW) consensus mechanism. Proof of interest 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 best against a PoW-based system. Even with a simple consensus mechanism, such as majority voting, an attacker would need to hijack 51% of the organizations – a much more difficult task than simply marshaling computing resources, which can often be rented.

Lesson Learned: Make sure you understand the blockchain consensus mechanisms used and under what circumstances an attacker can subvert them. Building a system that requires over half of all the organizations to be undermined, for example, is probably an acceptable risk.

Closure

Blockchain and smart contract software are more complicated and difficult to secure than almost anything else.

We want to build such systems knowing that malicious actors will maliciously participate, but not allow them to compromise the systems. Solving this problem opens up all kinds of new markets and opportunities.

Since Bitcoin came on the scene in 2009, we have gradually gotten there with systems already in production that can withstand high levels of attacks 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.