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.