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.

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.