Editorial & Advertiser Disclosure Global Banking And Finance Review is an independent publisher which offers News, information, Analysis, Opinion, Press Releases, Reviews, Research reports covering various economies, industries, products, services and companies. The content available on globalbankingandfinance.com is sourced by a mixture of different methods which is not limited to content produced and supplied by various staff writers, journalists, freelancers, individuals, organizations, companies, PR agencies Sponsored Posts etc. The information available on this website is purely for educational and informational purposes only. We cannot guarantee the accuracy or applicability of any of the information provided at globalbankingandfinance.com with respect to your individual or personal circumstances. Please seek professional advice from a qualified professional before making any financial decisions. Globalbankingandfinance.com also links to various third party websites and we cannot guarantee the accuracy or applicability of the information provided by third party websites. Links from various articles on our site to third party websites are a mixture of non-sponsored links and sponsored links. Only a very small fraction of the links which point to external websites are affiliate links. Some of the links which you may click on our website may link to various products and services from our partners who may compensate us if you buy a service or product or fill a form or install an app. This will not incur additional cost to you. A very few articles on our website are sponsored posts or paid advertorials. These are marked as sponsored posts at the bottom of each post. For avoidance of any doubts and to make it easier for you to differentiate sponsored or non-sponsored articles or links, you may consider all articles on our site or all links to external websites as sponsored . Please note that some of the services or products which we talk about carry a high level of risk and may not be suitable for everyone. These may be complex services or products and we request the readers to consider this purely from an educational standpoint. The information provided on this website is general in nature. Global Banking & Finance Review expressly disclaims any liability without any limitation which may arise directly or indirectly from the use of such information.

Identity management for secure permissioned blockchains 

Mansoor Ahmed, research engineer, Thales eSecurity

From stock market trading to supply chain management, permissioned blockchains have a wide range of potential applications.

It’s little surprise, therefore, that their popularity is on the rise. The Hyperledger project, for example, currently has five different frameworks in active development, and high-profile names including Accenture, Microsoft, and JP Morgan are all taking tentative steps into the world of blockchain, and will most likely be joined by their peers in due course.

However, while the immense growth of these applications is undoubtedly exciting, it’s concerning that the aspect of identity management and associated operational security appears to have been somewhat overlooked.

A slice of the action

Consider a theoretical internal blockchain – Pizzensus – a consensus algorithm used to choose a pizza flavour and log which flavour was chosen and when. Every time a company goes for lunch, they run this consensual algorithm and log the result on the blockchain. All the nodes that participated in the consensus sign the block; these are the validators of the blockchain.

This is a neat example of the typical consensus paradigm permission that permissioned blockchains seek to address: a closed set of nodes agreeing on a shared state, with no untrusted entities. Imagine that every member of the company has been assigned an ECC cryptographic key pair which is used to validate and sign each block, and that each of them is diligent in keeping their private keys secure. Should one of them try to sign an invalid block, the attempt will be logged and they won’t get their slice of the pizza.  So far, so good.

Now imagine that an employee was to leave, to be replaced by someone new. We no longer want the ex-employee to have any influence on Pizzensus although, of course, the newcomer is welcome to. We could simply give the departing employee’s key to the new person and continue as we were. It’s possible, however, that they could have surreptitiously made a copy before they left, and could make the new employee miss out on pizza should they so choose. Now consider what might happened if more new employees were to join the company. We’d now have more people than registered keys, the majority of whom might now be unfamiliar with the system. This situation clearly needs to be addressed.

Coming and going

Organisational churn is, of course, fairly common among most industries. The average UK company experience employee churn of around 15 percent in a year, and in some cases, such as the grocery sector, the annual figure can be as high as 100 percent.

This is not an issue that be sidestepped with any short fixes, however. It must be a fundamental consideration when designing and organisational consensus algorithm and one currently lacking in existing solutions. Hyperledger Burrow, for example, has no way of changing the validator set once a blockchain has been initialised, and neither does Hyperledger Sawtooth unless the entire chain data is deleted first. Indeed, no lottery-based consensus algorithms yet appear to allow this and, if an organisation is looking to use a blockchain, whether for internal purposes or for inter-organisational trades, it needs to be addressed.

If we return to the example of Pizzensus, we can include two functions: AddValidator and RemoveValidator, both of which require a supermajority, or unanimity, to be executed. We may also want to introduce a new field called ValidatorSet into the block header, which lists all of the current validator’s public keys, and allows nodes to attest to the veracity of a block with having to parse the entire blockchain. The underlying Pizzensus algorithm will also need to be modified to account for changing sizes of the validator set, and we might also consider designating a nominator with the authority to issue these special transactions; in the real world this is likely to be an organisation’s HR manager. And for any of this to work, the validators must sign every block.

Multiple roles and identities

Every member of an organisation serves more than one role. In our example, one may be a participant in Pizzensus and a software developer, while another participant may be an accountant. The organisation might want to introduce a condition that each vote from a software developer counts double and can go about this one of two ways. Either two keys could be assigned to each developer, or a map could be implemented from public keys to voting power, with the consensus based on the latter. While the former is more simple, architecturally, the latter is more adaptable. That said, it’s too soon yet to tell which is the most effective approach.

More consideration must be given to identity management. Critical issues such as dealing with lost keys, mapping actions to individuals, and key rotation to maintain freshness, must all be addressed before a permissioned blockchain can be deployed. This is particularly important when designing a consensus mechanism for running smart contracts when it’s typically assumed that underlying consensus mechanism is trusted. As we’ve seen with the pizza example, however, while this assumption may be true initially, it may not be so further down the line.

Pizzensus is an example of a permissioned blockchain system, but it clearly illustrates the issues that must be addressed when the individuals involved are likely to change. As similar systems grow in popularity, it’s important that the developers behind them take a more holistic approach to how they interact with the real world. Only by doing so will we see secure and trusted blockchains being meaningfully used in day to day life.