Security for Permissioned Blockchains

The heart of each blockchain is a protocol that agrees to the order and security of a transaction for the next block. The following article deals with how to preserve the integrity of this chain. So-called permissioned blockchains are growing in popularity.

All the more so as companies use the blockchain trend for themselves and at the same time want to keep the “lid on it”. Unlike the non-Permissioned site (such as Bitcoin or Ethereum), the permissioned blockchains are known to the participants and can be given specific privileges and privileges. Permissioned blockchains are controlled by an approval authority that grants permission to each of the participating nodes. Only those who are authorized can access the transaction network.

If you look for concrete examples in a hyped technology such as the Blockchain, they are mostly permissoned blockchains. The approving entity can be a consortium of companies, but also a single organization. The following article deals in particular with the security implications of providing authorized subscribers with a clear block chain and provides recommendations for secure provisioning.

For this it makes sense first to clarify what is meant by the permissioned blockchains and how the terminology is used.

What a permissioned blockchain is

At the heart of each blockchain is a protocol that agrees to the order of new transactions for the next block, the so-called consensus. Transactions can be any kind of information. The consensus is a binding agreement between all validated nodes. Every computer that connects to a blockchain network is called a node, or node. Within the blockchain, the consensus mechanisms ensure the integrity and consistency of the data. It is therefore crucial that this process runs safely.

In the so-called “non-permissive” blockchains, the consensus is typically the attempt to solve a difficult mathematical problem in exchange for a comparatively low financial wage. The validating nodes first collect all known transactions, select an order, and begin solving the task of the block. Without access restrictions, the consensus mechanism is correspondingly simple, which among other things increases the transaction speed. The downside: Basically it’s pure gambling who makes the race in the end. Although there is a certain probability that it will be those who have a higher computing power. The consensus protocol can withstand severe attacks on the chain (up to 50% of all nodes can be malicious). However, this is at the expense of transaction speed and confirmation.

For example, Bitcoin handles individual transactions within one second, but the confirmation can take more than an hour. In permissioned blockchains, the consensus runs more orderly, and the reviewers take turns suggesting a block, which the others subsequently release. So the process is much faster. Permissioned blockchains therefore achieve a high throughput rate for transactions, which are often confirmed immediately. This type of consensus is generally based on the belief that more than two-thirds of the nodes are trustworthy.

Security challenges with permissioned blockchains

The term blockchain immediately conjures up a certain image – that of decentralized control and added value through security. Large non-permissioned blockchains such as Bitcoin and Etherum are now well known to the public. And sometimes, this phenomenon also affects companies that plan to use permissioned blockchains.

One thing to understand is that by lowering the number of subscribers and relying on trusted auditors, the security requirements and challenges are more similar to those of traditional IT systems than those of large blockchains.

Imagine a permissioned blockchain being set up between five leading banks. In a five-node blockchain, this means that four of them (two-thirds of them) need to be trusted and behave correctly in order for the consensus to succeed.

Essentially there are two reasons when nodes do not behave the way they should behave. Their legitimate owners have dishonest intentions or the knots have been compromised by an attacker. The first case is about preventing price collusion and blackout. In the second case, protecting the nodes’ private keys and ensuring that they are only used to sign messages in line with the consensus protocol. It is equally important to protect the private keys of Blockchain accounts. These keys are used to sign a transaction and prevent unauthorized cash flow from the account in question. Unauthorized access to these keys would result in assets being unlawfully transferred between the participating banks. It can be costly to solve this problem and worse, unauthorized access can jeopardize the existence of the entire project.

Finally, there is the linchpin of the entire system, namely the bowl set, which authorizes the participants in the first place. If an attacker has access to these keys, for example, he is able to authorize new validating nodes. For example, an attacker controls enough voting rights to potentially damage or even destroy the entire chain.

What to do about the threats?

While public blockchains rely on the sheer number of nodes for their security, permissioned blockchains have to resort to other methods. These include methods of hardening blockchain, for example, through proprietary private key environments, and processes and methods for secure operation of the blockchain itself.

Private keys used by validating nodes should also be physically protected. This is done by technologies such as hardware security modules (HSMs). HSMs ensure that the private keys can not be read from server memory if the node has been compromised. It is even possible to protect the actual logic of consensus with HSMs. This method ensures that the data in question actually conforms to the consensus protocol before being signed with the key. A classic application example is to prevent double signing, such as forking. Our research team has published an open-source example of this technique using a popular permissioned consensus engine.

If you want to protect the private keys of the blockchain accounts, you should choose a potential risk based approach. For wallets (digital folders), which represent only small values, usually simple methods, such as an HSM USB stick with a switch, can be used to authorize transfers. In the corporate environment with corresponding values, it is advisable to use commercial HSMs and if necessary to distribute the subscription obligations to different authorized signatories.

Securing private keys within a blockchain is much easier than protecting any other type of public key infrastructure (PKI). In spite of everything, that is also a kind of PKI. Unlike the usual perception of blockchains, permissioned blockchains rely on a PKI that issues credentials to their respective participants. And every single transaction can be checked and confirmed immediately with reference to the corresponding trust anchor. It is obvious that the keys in question need to be protected like any other similar trust anchor – via HSMs, the distribution of drawing tasks, auditing and so on.

The future of the permissioned blockchains

At the moment, Blockchain’s hype is showing no sign of weakening. We can probably expect that projects using the permissioned blockchains will soon appear in the industry news. When it comes to developing and implementing such projects, safety should be taken into account from day one. As always, when a new technology is about to conquer the markets, safety is often postponed in favor of speed. So it is likely that not only will there be a rise in such projects, but also more vulnerabilities and vulnerabilities in consortium blockchain implementations.

If the hype has dropped a bit, fewer projects may be commissioned. But at this time, we have certainly already received good and workable recommendations for blockchain users from corporations such as Accredited Standards Committee X9 and ISO / TC 307.

from German: https://www.it-daily.net

image by shutterstock