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?
Blockchain-enabled self-sovereign identity (SSI) facilitates and secures all IT service management (ITSM) processes by providing assured, trusted identity and credentials for all configuration items (CIs) throughout their entire lifecycle. With SSI, every ITSM-applicable entity — every participating organization, person, and managed CI (network device, software instance, and others) — can be identified, identifiable, credentialed and […]
About a year ago, I wrote a blog post on my New Year’s resolutions for 2018 blockchain success. They were lead with business, understand the network type, understand the path to productive use, know why you are choosing blockchain, and make sure your architecture is ready. I tried to stick to these resolutions in 2018 […]
We’re living in a multicloud world. Today, 85 percent of businesses rely on multiple clouds to meet their IT needs, with 71 percent using more than three. What this means in practice for enterprise clients is that they have multiple architectures in place. This may be fine for “tried and true” workloads — like credit […]