The Linux Foundation’sHyperledger Fabric is one of the various Hyperledger projects and represents a blockchain for business framework implementation. It’s a permissioned distributed ledger that supports desired enterprise capabilities such as smart contracts, consensus, confidentiality, resiliency and scalability. In this article I will focus on confidentiality, defined as the ability to control access to sensitive data. Confidentiality enables life changing applications of the blockchain technology such as medical records management, real-time settlement of financial transactions and personal identity management.
Now, in every blockchain discussion there is a business side and a technical side, and both go hand in hand. Let’s discuss confidentiality on each of these areas:
The business side of confidentiality
Let’s be clear, these business concepts apply not only to Hyperledger Fabric but to any underlying blockchain platform or technology. From a business point of view, confidentiality is a key feature. Participants in a Business-to-Business (B2B) network might be extremely sensitive about how much information they share. We should design the blockchain business network in a way that supports the confidentiality requirements of the use case at hand. Which means that we need to understand at a very deep level which network participant have access to what data under which conditions. These are a few key points for you to keep in mind during the business network design:
For each transaction supported by the smart contract, which participants should be able to see all, a subset or none of the transaction data including who submitted?
Is there a participant with the role of regulator? If so, what data needs to be accessed by the regulator?
Is your business network design flexible enough? Confidentiality rules could change in the future as the business network grows by adding new participants with different confidentiality needs.
On the technical side, let’s see what features in Hyperledger Fabric support confidentiality. For the sake of completeness, some recommendations related to data security are also included here. The following list shows an increasing level of sophistication around confidentiality control and data security:
Let’s start with the basics. The data at-rest from the ledger or the state database should rely on an encrypted highly available file system. Hyperledger Fabric can secure data in-transit by enabling two-way Transport Layer Security (TLS).
Next stop is to leverage Hyperledger Fabric Attribute-Based Access Control. This means that access control decisions regarding which user can execute which transactions, are based upon the user’s identity attributes. For example, the “changeMedicalRecord” operation exposed by a smart contract is only available to the record owner.
Next is to encrypt sensitive data using the Hyperledger Fabric encryption library. For example, a smart contract transaction can encrypt a person’s Social Security number when its written to the ledger. Only key participants in the network (for example, the regulator) should have access to the decryption keys. Note that the management of the encryption/decryption keys should be done outside HL Fabric.
Up to now, all organizations in the business network will receive all transaction data, although a subset may be encrypted per the previous point. What about not sending the sensitive data altogether to those organizations that don’t need to have it in the first place. This can be done by leveraging a Hyperledger Fabric feature called “Private channel data”. Here, the sensitive data is only shared with those organizations that need to have access to it. For example, all organizations in the network can see that a person has health insurance, but the insurance coverage details is only available to the medical provider organizations in the network. Note that “Private channel data” is an experimental feature in HL Fabric v1.1
So far, all organizations in the business network join the same common distributed ledger. The next level of confidentiality supported by Hyperledger Fabric is about having separate ledgers or “channels”. In Hyperledger Fabric, each distributed ledger in the network lives only within the context of a channel. Therefore, total data confidentiality across organizations that don’t need to share any data can be achieved by assigning these organizations to separate channels. For example, a major hotel chain could define two channels: one channel where the hotel chain sub-brands can publish empty rooms and another channel where these empty rooms are auctioned across travel agencies. In this example, there is total isolation between the two channels except that the major hotel chain as the founder of this business network can connect and transact in both.
What confidentiality features require your blockchain use case?
In this article, you have seen a high-level overview of the business and technical side of confidentiality for blockchain networks. Now that you know how Hyperledger Fabric supports confidentiality in multiple ways. Which particular use cases in your industry can be enabled by this capability?
One area of supply chain management that I have not seen much written about in terms of blockchain and have been focused on is supplier information management. Many other areas that have been written about ad nauseum include transaction settlement, audit transparency, ethical sourcing, shipping data, compliance management, provenance, automation, food safety, and brand protection. […]
Blockchain makes it possible to securely and at-scale identify and label any subject and object entity with cryptographically verifiable security credentials. When literally everything is labeled with verifiable, authoritative, machine-readable security credentials (such as classification level, access category and others), multi-level security (MLS) systems can enforce mandatory and discretionary access controls and other MLS-specific isolation. […]
Today we further enhance your ability to build blockchain networks anywhere. We are announcing a new version of the IBM Blockchain Platform software which is optimized to deploy on Red Hat OpenShift, Red Hat’s state-of-the-art enterprise Kubernetes platform. This means you now have even more flexibility when choosing where to deploy your blockchain network components, […]