Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

2/28/2018
10:30 AM
Duncan Jones
Duncan Jones
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

How to Secure 'Permissioned' Blockchains

At the heart of every blockchain is a protocol that agrees to the order and security of transactions in the next block. Here's how to maintain the integrity of the chain.

Permissioned blockchains are growing in popularity as businesses attempt to cash in on the blockchain trend while keeping a firm hand on the tiller. Contrary to their non-permissioned cousins (such as bitcoin or Ethereum), permissioned blockchains are controlled by an authority that grants permission to every node that participates.

If you've read news stories recently about innovative uses of blockchain, the chances are they were based on permissioned blockchains. In these cases, the authority figure was probably a consortium of companies or a single organization.

This article considers the security challenges of deploying a small blockchain with authorized participants and provides advice for secure deployment. But before jumping into the finer details, let's discuss the characteristics of a permissioned blockchain and its terminology.

Permissioned versus Non-permissioned Blockchains
At the heart of every blockchain is a protocol that agrees to the order of new transactions in the next block. It is called "consensus" because it is a binding agreement between all the validating nodes. It's critical this process is kept secure as it maintains the integrity of the chain.

In non-permissioned blockchains, consensus is typically a race to solve a hard mathematical problem in exchange for a small financial reward. Validating nodes collect all the transactions they know about, choose an order, and begin solving the block's challenge. Sheer luck determines who wins the race, although those with more computational power are likelier to succeed. These consensus protocols can withstand significant attacks on the chain (up to 50% of nodes can be malicious), but at the cost of transaction speed and finality. For instance, bitcoin achieves single-digit transactions per second and finality can take over an hour.

In permissioned blockchains, consensus is more orderly and validators take turns to propose a block for the others to approve. It's a much faster process, meaning permissioned chains achieve high transaction throughput and often instant finality. This type of consensus generally requires over two-thirds of nodes to be trustworthy.

Security Challenges Faced by Permissioned Blockchains
The term "blockchain" triggers a certain image — one of decentralized control and security through scale. The properties of large non-permissioned chains, such as bitcoin and Ethereum, are well known by the public and occasionally influence those choosing them to deploy permissioned chains for enterprise purposes. It's important to realize when you shrink the number of participants and rely on trusted validators, the security challenges closely resemble traditional IT systems rather than the trendy nature of large blockchains.

Let's imagine a permissioned blockchain established between five major banks. In a five-node chain, this means that four nodes (two-thirds) must be behaving correctly for consensus to succeed.

Nodes misbehave for two main reasons: their legitimate owners have ill intent or they have been compromised by an attacker. The former challenge is about preventing collusion (a topic for another day), while the latter is about securing the private keys of the nodes and ensuring they are used only for signing messages in accordance with the consensus protocol.

Of equal importance is the protection of the private keys that control the blockchain accounts. Keys sign transactions and permit the flow of funds out of a particular account. Unauthorized access to these keys could result in an unwarranted transfer of value between the banks, which would be costly to resolve and could doom the entire project.

Finally, the linchpin of the entire system is the set of keys that authorized the participants in the first place. Access to these keys could allow an attacker to commission new validating nodes, which would make it easier to control enough voting power to corrupt the chain.

Responding to the Threat
While public blockchains rely on the sheer number of nodes for security, permissioned chains have to turn to traditional methods of hardening, including protected environments for private keys and processes and procedures for securely operating the chain.

The private keys used by validating nodes should be physically protected, using technology such as hardware security modules (HSMs). The use of HSMs ensures that the private keys cannot be read from server memory in the case that a validating node is compromised. It's even possible to protect the consensus logic using an HSM, ensuring the data complies with the consensus protocol before signing it with the key. A classic example is preventing double-signing (i.e., forking) by refusing to sign two blocks at the same height. My research team has released an open source example of this technique, using a popular permissioned consensus engine.

Protecting the private keys used by the blockchain accounts should follow a risk-based approach. For wallets holding small amounts of value, the protection could be as simple as a USB-stick HSM with a button to authorize transfers. In enterprise scenarios, the value involved will likely demand the use of commercial HSMs, and perhaps the sharing of signing duties between multiple signatories.

Protecting the heart of the blockchain — the private keys that grant access to play — is rather similar to protecting any other public key infrastructure (PKI). After all, it is a PKI. Contrary to the common perception of blockchains, permissioned chains rely on a PKI that issues credentials to its members, and every transaction can eventually be validated with reference to a root of trust. Consequently, the keys involved must be protected in a similar manner to any other root of trust — with HSMs, separation of duty, auditing, and so on.

The Future of Permissioned Chains
The hype surround blockchain shows no sign of abating, so I expect to see permissioned blockchain projects championed in the news for some time. Designing a permissioned blockchain should include security from day one, a step many projects will miss as they rush into this new market. I anticipate a steady increase of news stories relating to flaws in consortium blockchain implementations.

As the hype dies away, fewer projects will be commissioned, but by that time we should have some good advice available to blockchain owners through bodies such as the Accredited Standards Committee X9 and ISO/TC 307.

Related Content:

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

 

Duncan Jones leads the research and innovation team at Thales e-Security, focusing on emerging security threats and tomorrow's cyber technologies. He studied computer science at the University of Cambridge, before spending ten years working in security and payments. Duncan ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Microsoft to Officially End Support for Windows 7, Server 2008
Kelly Sheridan, Staff Editor, Dark Reading,  1/13/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7227
PUBLISHED: 2020-01-18
Westermo MRD-315 1.7.3 and 1.7.4 devices have an information disclosure vulnerability that allows an authenticated remote attacker to retrieve the source code of different functions of the web application via requests that lack certain mandatory parameters. This affects ifaces-diag.asp, system.asp, ...
CVE-2019-15625
PUBLISHED: 2020-01-18
A memory usage vulnerability exists in Trend Micro Password Manager 3.8 that could allow an attacker with access and permissions to the victim's memory processes to extract sensitive information.
CVE-2019-19696
PUBLISHED: 2020-01-18
A RootCA vulnerability found in Trend Micro Password Manager for Windows and macOS exists where the localhost.key of RootCA.crt might be improperly accessed by an unauthorized party and could be used to create malicious self-signed SSL certificates, allowing an attacker to misdirect a user to phishi...
CVE-2019-19697
PUBLISHED: 2020-01-18
An arbitrary code execution vulnerability exists in the Trend Micro Security 2019 (v15) consumer family of products which could allow an attacker to gain elevated privileges and tamper with protected services by disabling or otherwise preventing them to start. An attacker must already have administr...
CVE-2019-20357
PUBLISHED: 2020-01-18
A Persistent Arbitrary Code Execution vulnerability exists in the Trend Micro Security 2020 (v160 and 2019 (v15) consumer familiy of products which could potentially allow an attacker the ability to create a malicious program to escalate privileges and attain persistence on a vulnerable system.