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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25596
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. T...
CVE-2020-25597
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. Howeve...
CVE-2020-25598
PUBLISHED: 2020-09-23
An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar...
CVE-2020-25599
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory a...
CVE-2020-25600
PUBLISHED: 2020-09-23
An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86 domains. The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains...