Blog: Blockchain

Blockchain Implementation Security. A hardening how-to

Luke Turvey 22 Aug 2017

Many big organisations are now fully invested into the idea of blockchain and are creating their own solutions using this powerful technology. Microsoft, Amazon, Intel and banks like J.P Morgan Chase and Santander are just a few of the early adopters.

There is no doubt in my mind and clearly in the minds of tech giants that blockchain, although still in it’s infancy, will be the next big thing. But like any other technology, there needs to be testing to ensure the security of its implementation. Today, if you go on and try to find a detailed guide for securing your blockchain application and infrastructure, you will find a whole lot of nothing useful.

So, welcome to my guide on blockchain security: Blockchain Implementation Hardening.

This diagram describes a simple blockchain implementation, its infrastructure and user applications:

The main idea behind blockchain Technology is to provide security and redundancy through consensus to the applications in which it hosts. For example, if a blockchain is hosting a banking application and a node is hit with a DDoS, all other nodes would keep the application running.

If a node is hacked and an attacker tries to falsify the blockchain to show the attacker has more money in their account, it would not work as there would not be consensus. Security testing a blockchain starts with the nodes that run the blockchain and can be broken down to each individual part that provides the overall solution. Each function has its own role to play in the solution and needs to be tested to provide a secure implementation. The individual parts of the blockchain can be seen below:

The Blockchain implementation

  • Nodes
    • Vulnerability Assessment and Build Review
    • Redundancy Testing
    • Synchronisation Testing
    • Consensus Algorithm Testing
    • Private Keys (The Wallets)
      • Password Strength Review
      • Key Storage Review
  • Shared Ledger (The Storage)
    • Information Disclosure Checks
    • Smart Contracts (The Functionality)
      • Secure Code Review
  • The Application (The Usage)
    • API Testing
      • Web Application
        • OWASP Style Testing
      • Mobile Application
        • OWASP Style Testing

Nodes

The nodes on the blockchain are arguably the most important aspect to securing a network. They provide the redundancy, synchronisation and communication to the blockchain ledger and therefore really make up the network. The more nodes within a network the more secure and redundant the network becomes. There are a few aspects in which one should think about when it comes to security:

Vulnerability Assessment and Build Review

This is nothing new and should be done by organisations for their servers and workstations regularly. All nodes hosting a private blockchain application should be vulnerability assessed to ensure that no vulnerabilities exist which a malicious person could exploit. Build reviewing helps guard against vulnerabilities in the future and helps against privileged exploitation flaws. Which in this instance may lead to an attacker gaining access to a wallets private key, for example.

Redundancy Testing

This testing will show what happens if you take nodes off the network. A blockchain network needs to be fully redundant and therefore all nodes should be used to add to this redundancy. There should never be one or a few nodes in which the network solely relies on, it should rely on all nodes.

If you take many nodes off the network, the other nodes should kick in and provide the ledger for the application to continue running. If this does not happen, you could have the application failing.

Synchronisation Testing

This testing ensures that the application will be running the absolute latest version of the ledger and is never behind. The consultant testing should understand how synchronisation is working across the nodes and how the application is polling the blockchain for synchronisation updates. If the application does not synchronise, the application could be outdated and perform wrong functions.

Consensus Algorithm Testing

The algorithm of which the blockchain uses for its nodes to come to a consensus regarding if data in the blockchain is valid or not needs to be reviewed. There are several algorithms available to be used and also several attack vectors for each algorithm. For example:

Proof Of Work Algorithm: This is GPU mining and vulnerable to a 51% attack where an attacker gains access to 51%+ of the network nodes and is able to change the blockchain via majority consensus.

Proof Of Stake Algorithm: This is mining via stake power meaning the more crypto coin owned on a network the more staking power one has. The potential vulnerability here is that one user may gain access to a large amount of coin, gain a big staking power and attack the blockchain. This would be very expensive on a public blockchain, however not so on a private blockchain.

Private Keys (The Wallets)

Inside all nodes will be a program running which has access to each nodes individual wallet using its private key and password. The wallet can be used to gain a user’s blockchain “account” and any potential currency inside the wallet. Depending on the blockchains application, this could be the Holy Grail to controlling features and changing data. Two main security tests should be conducted here to ensure that the private key is hardened:

Password Strength Review

If an attacker was to find a wallets private key, to use it they should need a password if one has been set. A test needing to be conducted here is a brute force and dictionary attack upon the private key to try and crack the password. This is done with the aim of breaking the private keys password to allow access and therefore tests the password policy in use by the organisation on their blockchain private keys.

Key Storage Review

Of course, if the key is securely stored then the attacker cannot try and brute force the password in the first place. A review will need to be conducted to understand how organisations are storing their wallet private keys and look at the storage implementation basis to basis.

The Shared Ledger

The ledger is a very important part of blockchain and it is essentially the database which stores the data to be used by an application. It also has the power to store smart contracts which are pieces of code written to perform functionality in use by the application.

Testing the ledger really has two paths:

Information Disclosure

The blocks being stored on the blockchain can have data written into them which is then used by an application to perform functionality. The blockchain is a fully auditable solution and therefore all data written to the ledger will be able to be seen by all parties that use it. Therefore, it is very important that no sensitive information gets disclosed within its blocks.

Smart Contract Code Review

Some blocks may hold smart contracts which can be executed to provide full Turing complete functionality to an application. It can hold variables and do mostly anything any other coding language can do. Because of this, it also can implement logic flaws much like any other coding language and therefore a secure code review should be conducted to ensure its logic cannot be used maliciously. This is especially important due to the completely auditable nature of the ledger.

The Application

The application otherwise known as the “front end” is the purpose of a blockchain implementation. It is what gets used by the end users and is nothing overly different to what is used today, such as Web Applications, Mobile Applications, Desktop Applications and so on. Therefore, the testing methodologies here remain the same and I will not go into much detail here.

Blockchain API Testing

The application in which users will be interacting with will have an API in use to connect to the blockchain. For example, there are many web applications with APIs connecting into Bitcoin’s blockchain, to build the functionality to make Dice gambling websites for example. There are also various ‘dApps’ which exist in the Ethereum blockchain which hook this API.

Whichever API is in use, it will read and add data to the blockchain and its smart contracts. Like any other API it needs to be tested for any potential flaws such as Unauthorised Access, Rating Limiting, Encrypted data in transit, Cross Site Request Forgery and much more.

Web, Mobile and other Application Testing

When it comes to the application side of things, this will generally use the API to display data. This testing falls under the general OWASP recommendations, for example their TOP 10 series can help:

Final Comments

As stated previously, the inspiration for this blog and methodology was because a blockchain hardening guide was non-existent.

In no way is this a 100% fool proof methodology for blockchain security and like with any other new technology we will learn as we go on. Although, whether you have a custom written blockchain or use the Public/Private blockchain of Bitcoin, Ethereum, Waves or another, this should give some insight into what you should be looking at in a blockchain implementation, and hopefully help you secure it!

We would be more than happy to look at any blockchain implementations you have built and give a security minded opinion on them, just get in touch.