The Fundamentals of Blockchain Security

Blockchain Technology is regularly in the news and has a certain marketing “buzz” with many promises about its security based on cryptography and its irrefutability.

In this article I aim to avoid the hype and instead wish to focus on some of the key security considerations for those deploying blockchain solutions.  Despite the headlines blockchain is not secure by default and like any other technology project security needs to be designed and integrated from the start if we are to reap the many benefits offered by this technology.

 All new technology projects should start off with some form of risk assessment or threat modelling exercises which informs the security requirements and leads to the development of the security architecture upon which the solution is built. In addition, all technologies need some form of management system and governance in place to ensure suitable control is maintained throughout the operation of the system. 

So, what specifically should be under consideration when designing and building a Blockchain solution?  Here are a some of the fundamental areas to focus upon.

Consensus Algorithm Analysis & Testing

Blockchains can implement a variety of different mechanisms to arrive at consensus (i.e. one version of the truth).  Those familiar with Blockchain concepts will understand these as  Proof of Work / Proof of Stake / Casper / Delegated Proof Of Stake / Transaction As Proof Of Stake or TAPOS / dBFT etc.

A key security aspect is to consider which consensus algorithm is most suitable for your solution.  Is this an open permissionless blockchain that allows any node to connect or a private controlled solution amongst specific stakeholders?   Key questions in making such a choice will be based around making judgements on which nodes should be able to approve transactions and the risk associated with the 51% attack – where 51% or more of the nodes can arrive at consensus thus taking control of the blockchain itself.

In addition to selecting a suitable approach various attack scenarios will need be modelled and tested to provide assurance surrounding this fundamental mechanism.

Keys and Wallets

Blockchain technology is underpinned by cryptographic keys and close attention to the security of the user’s wallets via the use of private keys and passwords is a fundamental priority. It is strongly recommended that before any launch into production penetration testing to ensure that the key storage and password management is conducted in as secure a manner as possible is carried out.

The focus should apply to:

Password Strength Assessment and Implementation:

Key Storage in particular the storage of private keys.  There are many choices such as Hot and multi-signature wallets which are live and online and the more secure option of cold wallets such as hardware wallets which are stored offline.  Again examining the risk scenarios and use cases for such key handling should be considered in the design of the solution.

Synchronisation Mechanisms and Testing

Since a blockchain’s network consists of peer-to-peer nodes, it is extremely important that they are able to synchronise between themselves. This is why it is fundamental to test synchronisation between nodes to make sure that the process is fast and efficient and to be able to deal with delays, and the potential action required to ensure data integrity when delays occur.

Redundancy Testing

It is often stated that blockchain is highly redundant due to the fact that are many nodes storing multiple copies of the data.  Whilst this is true scenarios of multiple node failures should be examined and tested to reveal any and all issues with redundancy around data sharing across nodes. Such tests reveal the impact of multiple nodes failing at the same time.

Timejacking Attack

Whenever a node joins a network, they need to keep track of time AND that time needs to be in synch with its other peer nodes. The way this is achieved is by keeping an internal clock system which happens to be same as the computed median clock time of all its peers. If this median time differs by a huge amount from its system time, then the internal clock readjusts and reverts to the system time.

So, if a malicious node does enter the network with an inaccurate timestamp, they will have the ability to alter the network time counter. This could lead to issues like double spending and mining resource wastage.

Blockchain API Testing

Application Programming Interfaces (APIs) are extremely important since they help users to interact with the blockchain through applications.  As with any system utilising APIs penetration testing should be performed to ensure that the API endpoints have vulnerabilities identified and addressed.

DDoS Attacks

DDos or Distributed denial of service attack includes sending a large number of similar requests to clog up the network and deny the network from conducting any form of operations. Designs and SecOps architectural reviews should be performed to identify and ensure that the applications and environment have potential DDos risks mitigated.

All of these areas should be subject to penetration testing prior to moving into production to allow vulnerabilities to be identified and addressed.  The following explains these penetration testing steps in more detail.

Penetration Testing methodology of a Blockchain implementation


  • Network Vulnerability Assessment
  • Build Review (SecOps / Cloud or Private infrastructure)
  • 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(s) (normal usage)

How it’s been used by normal users and admin functionality

  • API Testing
  • Web Application
  • Mobile Application


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 should be considered  when it comes to security:

Vulnerability Assessment and Build Review

This is nothing new and should be done by organisations for their servers, workstations and infrastructure regularly. All nodes hosting a private blockchain application should be vulnerability assessed to ensure that vulnerabilities which a malicious actor could exploit are identified and mitigated. Build reviews helps guard against vulnerabilities in the future and protects 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 serious application failures.

Synchronisation Testing

This testing ensures that the application will be running the absolute latest version of the ledger and is never behind. Any tester 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 incorrect functions resulting in significant data integrity and operational impacts.

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 tokens 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 tokens, 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 strongly recommended 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 the approach to storage security.

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 as standard application testing which we will focus on in other blogs.

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:

Governance of a Blockchain implementation

Whilst the article so far has focussed on the security aspects largely from a technical perspective any Blockchain solution should have a clear governance structure in place.  Key processes related to security management, access control decisions, scheduling of risk assessments and tests, business continuity, legal and regulatory compliance and third party management are also fundamental to managing risk and ensuring success.

Each of these areas are topics in their own right and are worthy of their own articles.  A blockchain project is no different to any other in terms of the need for governance and oversight.  There are many standards and guidelines that can be used to build such processes and ISO/IEC 27001 is one key framework.  I will not elaborate here as we have already produced several articles on this topic.

The main area of concern to consider here is stakeholder management.  Many blockchain solutions that address supply chain management such as Tradelens: have many stakeholders involved in a consortium.  When developing consortium based blockchain solutions close attention should be given to considering the role and permission of each consortium member.  How will this be addressed in the long term, how will decisions be made by the consortium in a fair and inclusive manner, how will risks be addressed and changes be managed?

Hopefully this article scratches the surface on some of the key areas when considering the security of blockchain solutions, essentially the message is whilst blockchain does indeed have the potential to live up to its expectations and to deliver the many benefits talked about it still needs to be treated, managed and handled like any other technology to really ensure that benefits are released whilst managing risk.

I would like to thank my colleague Pablo Sisca from our partner Dark Waves Infosec for the contribution to this article: For more information relating to blockchain security please contact us