Hyperledger Fabric and IBM Blockchain — privacy and security strategies for the enterprise

It’s a fantasy to imagine that any system will ever be 100% safe. The fear of cyberattacks, theft and hacks is always going to be very real, especially when you’re dealing with super sensitive data — personal medical data or product cost, volumes and markups.

One way to prevent anyone interfering with your data is to store it on an immutable blockchain, like Hyperledger Fabric (HLF). You can build private permissioned blockchains with the framework, where data is tamper-proof, secure, and visible only to explicit organization in its network.

HLF is a highly modular blockchain system. It has been designed to allow a known set of entities or businesses to participate in and perform certain actions in the network. This modularity and flexible configuration mean that two different instances of HLF may present two very different security postures. Here are some key areas to consider when designing and deploying a safe and private HLF system.

Consult with security experts
Before you begin to design your particular HLF architecture, consult with the best security experts you can afford and don’t trust anything you read or hear on the internet. There is no one checklist to follow, however there are some best practices and fundamental principles to consider when planning, designing and implementing a secure HLF blockchain.

Plan Membership and their responsibilities carefully
Existing members should determine how to add new or remove other members in the network, in addition to reviewing, testing and updating chaincode ( SmartContracts in HLF). Members must also agree on a data model that will be stored in a blockchain, which in turn is mapped out by the SmartContract. The data model should be useful for the business functions required between members and should be future proof and not inadvertently leak information.

Create channels control visibility of privileged information
To maintain confidentiality and scoping, you should create groups of peers that store the ledger data associated with their transactions using Channels. These Channels need to be used carefully as a network topology can quickly get out of hand.

Use Private Data Collections for finer control of data access
To avoid complications, Peers can also selectively share private data in a channel or state database also known as a “sideDB”. Which one you use is up to you. Securing data in the off-chain database needs to be taken into consideration and will be only as secure as the database you choose. Supersensitive data, like medical records or financial transactions, can be set to expire after a certain number of transactions have been completed.

Use encryption to ensure data privacy
In some scenarios the data can be encrypted by the application. Or take a hash of the sensitive data, for example x-ray images. Store the hash on the blockchain, and the sensitive data off chain. If the off chain data is tampered with, the hashes will no longer match and this can trigger a warning during an audit. Also you can use Secure Containers on LinuxONE or OS/Z to further ensure privacy.

Embrace public key infrastructure
At its core, HLF is a public key infrastructure (PKI) system. It’s important to leverage industry standards — for example choosing X.509 certificates to secure communication between peers. In addition the majority of component require username and password access to manage configurations, so secure password policies need to be enforced.

Ensure SmartContracts use Certficate Attribues for access control
Certificate Attributes can be used to enforce access control for authorized users and grant permissions in SmartContracts and client applications. You can choose crypto algorithms and use hardware security modules (HSMs) to manage your keys.’

Conclusion
I’ve just highlighted some of the best practices to follow when securing your blockchain implementation. The modularity of HLF while very useful, can be an Achilles heel — even the most careful and informed design can contain security holes. If possible always run HLF in trusted and secure cloud environments like IBM Cloud or AWS Cloud. To ensure SmartContracts are safe and protected from vulnerabilities always use Peer code review and encourage “bug bounties”.

Please take a look at the resources below to learn more about securing HLF. Thanks for reading and feedback in the comments section below is always welcome!

Resources

Attribute support in HLF — Hyperledger fabric documentation

Secure your blockchain solutions — Article by Saritha Arunkumar and Sridhar Muppidi on IBM Developer

Blockchain security, privacy and confidentiality — Video by Monu Pradhan on IBM Devloper

Store private healthcare data off-chain and manage medical data using blockchain — IBM code pattern

X-Force Red Penetration Testing — IBM Security Services

Hands-On Blockchain with Hyperledger — book by Nitin Gaur

Data and Goliath — The Hidden Battles to Collect Your Data and Control Your World by Bruce Schneier