In my blog post, Blockchain as a cross-domain security solution, I described at a high level how the security controls inherent to blockchain make it ideal as a cross-domain solution. In this article, I describe in slightly more detail how the security controls required in a cross-domain solution map to their implementation within a Hyperledger Fabric blockchain.
The big idea
Because the purpose of a blockchain business network aligns so closely with the purpose of a cross-domain solution (both are designed for sharing discrete sets of information between organizations and networks that don’t trust each other), blockchain business network security controls map closely to the controls required in a traditional accredited cross-domain solution. Thus, when hosted on a high assurance (HA) platform, a blockchain-based cross-domain solution should be able to receive government security accreditation.
Cross-domain security controls mapped to Hyperledger Fabric blockchain
Below is a list of security controls that are typically implemented in traditional cross-domain solutions, along with descriptions of how Hyperledger Fabric blockchain capabilities map to them.
Source and destination address authentication and address allowlisting
This control ensures that only authorized endpoints can send and receive information across the domain boundaries. The scope of a Fabric business network and its security controls extends far beyond than that of a traditional point-to-point cross-domain guard. Fabric is by design a permissioned network that requires x509-certified, identity-based access controls for each participating network node and user, specified per private members-only channel. Changes to the configuration of blockchain security controls are implemented in the same manner as any other transaction in the network — digitally endorsed as compliant with pre-existing, element-level change policy, distributed as digitally signed transactions, and immutably committed to a distributed system ledger. Finally, Fabric business network nodes actively maintain their channel membership by continually broadcasting digitally signed “alive” messages to prevent malicious nodes from impersonating other nodes.
Detailed content checking to prevent the passing of unauthorized data
Examples of this include:
- Security label checks against source and destination clearances to prevent leakage of sensitive data
- Data format allowlisting, data format consistency and validity checking, checking text against a blocklist of phrases
Since Fabric is designed as a secure system of record for conducting asset-specific business transactions between parties that don’t fully trust each other, all data sharing on each Fabric network channel is pre-defined and strictly controlled on a need-to-know basis. Only the specific data elements and accompanying business logic required to conduct the pre-agreed-upon set of asset-related transactions between specific participating parties are shared and are defined in the form of executable programming language in a Fabric channel’s chaincode (“smart contract”). Interactions with a channel’s shared ledger are only possible via this pre-defined, digitally endorsed, immutably configured, access controlled, and programmatically executed chaincode. Therefore, the only content that can make its way into the ledger is that which conforms to the mutually agreed-upon and programmatically applied business and security policies executed in the form of chaincode.
In a cross-domain blockchain scenario, it’s possible that the organization(s) responsible for the security of the cross-domain transfer could be included among the parties defining and endorsing the allowable sharing policies that become instantiated, distributed, and executed in the form of a channel’s chaincode.
Scanning data for known malware
Virus scanning is performed by the HA hosting environment, but a Fabric blockchain network is not generally intended as a file-distribution platform. See my blog Securing Your Cross-Domain File Transfers with Blockchain to learn how files can be handled in a cross-domain blockchain scenario.
Validation of digital signatures
In a Fabric business network, all network communications and content payloads are validated using x509 certificates. Network communication occurs through mutually-authenticated (client and server-side) Transport Layer Security (TLS). All message content payloads are digitally signed and validated using separate (non-TLS) x509 certificates, and Fabric can be configured to store private keys in a Hardware Security Module (HSM).
Inspection of encrypted content to ensure that validation checks can be performed on all content
Fabric includes an entities extension package that implements a Blockchain Crypto Service Provider package interface capable of performing cryptographic standard key lifecycle, sign/verify operations, and encrypt/decrypt operations. Using this package, chaincode can perform any required decryption and encryption operations in conjunction with writing to and reading from the ledger. For example, chaincode can decrypt encrypted transaction proposal values, inspect and validate them, and write the encrypted values to the ledger. Any required cryptographic key(s) and initialization vectors are passed within the transient field of the chaincode’s invoke method; transient field data is not written to the ledger.
Removal of redundant data to improve security (replay-attack protection) and performance
Fabric goes beyond merely preventing or providing for the removal of redundant data. A central design feature of the Fabric is that distributed ledgers are all maintained identically by each peer node using deterministic methods that prevent proposing, distributing, and committing redundant data to the ledger.
Generation of logs that record relevant security events
Fabric provides for extensive logging both on- and off-ledger, and the HA hosting platform provides protection for all generated logs. As briefly described above, all Fabric configuration changes are immutably committed as transactions on the system blockchain and available for auditing. Additionally, the level of logging by network nodes is configurable and chaincode logic can include logging.
HA platform for a Hyperledger Fabric blockchain
As briefly described above, the security controls that are built into Hyperledger Fabric map very nicely to controls typically required in a cross-domain solution. But equally important is an underlying HA platform to host and protect these security controls — providing assurance that the Fabric-provided security controls are not intentionally or accidentally overridden or disabled. An HA platform such as IBM z Systems® LinuxOne provides:
- Protection from system administrators
- Tamper protection
- Pervasive encryption of all code and data stored on disk
- Key safety with a FIPS 140-2 Level 4 service to ensure that private keys are safe
- Malware protection
- Hardware and firmware audit logs to supplement the Fabric-generated logs
- Formally assessed IAW-accepted evaluation criteria (such as Evaluation Assurance Level or EAL 5 for IBM z Systems).
Because the security controls that are built into open source Fabric align so closely with those found in traditional cross-domain solutions, a Fabric-based design should be capable of receiving government security accreditation as a cross-domain solution. This open source approach is likely to be less complex, more effective, and less expensive than traditional, special-purpose cross-domain guards when mitigating the high-stakes security risks of cross-domain information sharing.
Explore more about how blockchain can be deployed as a cross-domain solution through the IBM Developer Blockchain hub.
I look forward to more great conversations on the advantages of blockchain as a cross-domain solution.