The Very First Challenge to Adopt Blockchain for Enterprises: key Management!
What are so tricky about the key management of consortium chain? Can we find a best practice?
Foreword
According to the latest IDC Worldwide Semiannual Blockchain Spending Guide, the Asia-Pacific region’s spending on blockchain solutions reached US$522.7 million in 2019, an increase of 81% compared to 2018. It is expected that the demand for enterprises to adopt blockchain will rapidly grow in the next 5 years, with a compound annual growth rate of 59.8%.
Although more and more enterprises seek to adopt blockchain, blockchain is different from the previous enterprise IT technology. Most enterprises or manufacturers still lack systematic knowledge of implementation — for example, enterprises participating in the consortium chain must first facing one problem: How should an enterprise manage the private key used on the consortium chain?
In this article, we will go through the considerations, challenges and solutions for enterprise key management, as well as specific solutions.
The “key” mentioned below, unless otherwise specified, refers to the “private key” used on consortium chain
*Daniel Huang is the co-author of this article, and specially thanks to 李彥寬 Kevin Lee and Frank Yang for their revision and feedback.
Special Considerations for Key Management
The private key is like a seal, it can be used to “sign” on a “message”, and the result of the signing is called “digital signature”, which can be verified by the public key paired with the private key. Based on the principles of cryptography, the digital signature is almost impossible to be forged, so it makes the signature unrepudiated. As a result, the signature can be used to prove the identity of the signer.
In the enterprise blockchain, i.e. the consortium chain, the key used on the consortium chain is not a “personal seal”, but a “company seal” that is used on behalf of the enterprise and cannot be reproduced on will.
The consortium chain can allow enterprises to know “which public key represents which company” through the process of governance. The credibility of the signature is not only backed by the signing enterprise itself, but is endowed by all participants of the consortium chain. That is to say: the key used on consortium chain can not be changed on will by the enterprise since the entire consortium has to know and agree it — Just as it is impossible for an enterprise to reproduce the company seal frequently.
As a result, the key used on consortium chain should not be kept directly by individuals, otherwise the security of the key cannot be ensured with the change of the custodians in the company.
Next, let’s take a look at the challenges that enterprise will encounter in key management.
Challenges of Key Management
What is Key Management?
If the key used on consortium chain is like the company’s company seal, then the management of the key is actually like the “seal management” used by the enterprise when managing the company seal. Seal management is a set of rules of “custody” and “invocation” of company seal. When an employee needs to use the company seal, they need to invoke the seal from the custodian according to the seal management process; similarly, the key Management refers to the “custody” and “invocation” of the key.
Difficulties in Key Management
Based on the above special considerations for key management, we will suggest to separate the roles who are responsible for “custody” and “invocation” of the key in the design. First, since the key represents the enterprise, it should not be kept by individuals. Second, the responsibility for custody should not fall on company decision makers. Company decision makers should bear the responsibility for the decision making rather than worrying about the custody. To perfectly achieve the above scheme of separating “custody” and “invocation”, we must design to:
- To find a way to store the key, and the custodian must keep the key safe and not have the power to use the key;
- The key cannot be disclosed to the invoker while the key is invoked.
Key Management Scheme with Separate “Custody” and “Invocation”
Here is what we designed for the above requirements:
- The “invoker” will first hand over the “order” — the message required to be signed and the signing method, to the “keeper”;
- The “keeper” will decide whether the invoker and the order meet the “authentication policy”, and if it is satisfied, put the “order” into the “vault”;
- The signing action is performed in the “vault”, and finally the “order” that has been signed is returned to the “invoker”. The “vault” behaves like a black box, and its details will not be seen from the outside, including the key itself.
These operations are quite intuitive. In fact, we think it is one of the best practices for key management of consortium chain. So how to implement this scheme exactly? Can we actually find such a “vault” and “keeper”? You bet! We can leverage Hashicorp Vault to do the work.
Hashicorp Vault: an Open-sourced Secret Management Solution
Hashicorp Vault is a fully open-sourced secret management system developed by Hashicorp, a well-known company providing devops tools. According to Vault’s official website, its value is to “Manage Secrets and Protect Sensitive Data”. Its design goal is to mitigate “secret sprawl” through centralized management in software development.
Hashicorp Vault encrypts and stores secrets such as API credentials, passwords, certificates, etc. and provides a unified interface for them. Meanchile, it provides strict access control and records a detailed audit log.
In addition to storing static secrets, Vault provides dynamic secret so that applications can only access sensitive data for a period of time. This greatly reduces the risk of theft if the secret is stolen.
In the era of cloud-native computing, every step needs to be authenticated and verified from user to service and from service to service. Hashicorp Vault has become an increasingly popular “Encryption as a Service” (EaaS) technology, not only cloud service platforms AWS, GCP, Azure provide integration solutions, but well-known software such as Kubernetes, MySQL, etc. have integrated Vault as a way to replace the original direct access to secret operations.
Why Can Hashicorp Vault be Used for Key Management?
Returning to our needs above:
- To find a way to store the key, and the custodian must keep the key safe and not have the power to use the key;
- The key cannot be disclosed to the invoker while the key is invoked.
First, Hashicorp Vault is quite safe — it is inherently designed to keep secrets. According to the architecture of Vault, we can even make sure that no “single system administrator” can decrypt and view its contents. Therefore, Hashicorp Vault’s role as a “vault” is well deserved.
The next question is: what can be the “keeper”? This depends on another clever design of Vault: plug-in. Developers are able to develop plug-ins for different needs. Using plug-ins, we can easily expand Vault’s API, so that it can provide corresponding functions for different scenarios. You can refer to this article to know more about how Vault achieves such flexibility.
The plug-in can act as a “keeper”. To deliver the “order” to the “vault” through the plug-in, we need to implement “authentication policy” and “signing method” in the plug-in and mount it with the Vault. In this way, the “invoker” can retrieve the signature without exposing the key while invoking the key.
Finally, we are about to complete the last mile: find a suitable “keeper”.
Vault-BX: a plug-in for key management
Vault-Ethereum is the most well-known plug-in among the Vault plug-ins related to blockchain key management.
The Vault-Ethereum plug-in, developed by Immutability, is a blockchain wallet implementation. This plug-in can directly sign the blockchain transaction and send the transaction on chain. However, Vault-Ethereum is only designed for personal usage and only supports a single off-chain user, which cannot meet the key management requirement of consortium chain such as sopporting multiple users to access the same key.
We Need a Stronger “Keeper”
Since there is no Vault plug-in designed for consortium chain, Vault-BX came into being. Vault-BX is a Vault plug-in developed by the BSOS. It is completely designed for the consortium chain scenario and supplements the deficiencies of other Vault blockchain key management plug-ins. Its important functions are as follows:
- Many-to-one key invocation: Although Vault-Ethereum has authentication for the key invocation, it only supports single user. Anyone who knows the user ID can invoke the key directly wihtout authentication. Vault-BX can achieve “multiple sign-off permissions”, which allows multiple users to invoke the same key, meeting the needs of many-to-one support.
- Support of various signing methods: different consortium chain has different transaction formats, for example: in the enterprise Ethereum transaction, “nonce” needs to be part of the signature message; while the signature message in Fabric needs other information such as “channelID” and “chaincodeID”. Vault-BX currently supports a variety of enterprise Ethereum clients such as Quorum / Besu, Hyperledger Fabric, and R3 Corda, which are more versatile in function.
- Support of private transaction signatures: The private transaction, which is unique to the consortium chain, requires additional parameters when signing, such as “privateFrom”, “privateFor” and “restriction” defined in EE. If the plug-in does not support these functions, even if the enterprise is connected to a consortium chain, it cannot execute the private transactions of the consortium chain. Vault-BX not only supports the signature of different consortium chains, but also provides corresponding support for its private transactions to meet the needs of private transactions between enterprises.
Let’s recap this scheme. Now the “vault” is the Hashicorp Vault, which is responsible for the custody and invoking of the key. For the “keeper”, we have Vault-BX plug-in to authenticate and provide the correct signing method for Vault to operate.
Summary
Although The demand for enterprises to adopt blockchain technology is increasing, they often lack awareness of key management and systematic knowledge of implementation. Key management is different from the password management — passwords can be reset and redistributed at any time, the key, on the other hand, represents the company and it needs to obtain confirmation and approval from other members for every update. Therefore, a set of separation of invocation and custody, and a well-conceived key management mechanism are necessary.
In this article, we first introduces the special considerations for key management of the consortium chain, and explains the challenges and solutions. We also see that: using Hashicorp Vault and Vault-BX together with the internal responsibility-sharing and authorization mechanism of the enterprise can form a complete key management solution. Of course, BSOS has been fully considered, and integrated into our core blockchain technology: BridgeX.
Finally, remind that for the security of private keys, the invoke authority management is equally important. This article does not mention the management of the invoke authority within the enterprise. For example, a series of sign-off procedures must be completed before the key can be invoked by the “keeper”. In practice, companies can choose to connect to existing sign-off systems, or they can also import mature multi-layered, multi-signed management on the market, such as the CYBAVO key management that has been integrated into BSOS BridgeX.
