Hyperledger Fabric security and privacy protection mechanisms
Outline
Hyperledger is a block chain to promote cross-industry application of technology open source project, led by the Linux Foundation, launched in 2016. Hyperledger Fabric is one of the two projects originally introduced, is currently the most widely used enterprise-class alliance chain technology. The block chain is essentially a distributed shared books, in practical application, it usually carries sensitive data such as assets and transactions and the like, so security and privacy protection are two very important issues. Fabric Solutions Technology Alliance as a representative of the chain is given as follows:
Measures in terms of security are:
■ ensuring communication security between the communication node with TLS support to ensure the security of the transport layer.
■ isolation of books, so books shared only between organizations involved in co-billing, and other organizations have no access to books.
■ distinguish the role of entities involved (node and application clients), in order to access the resources of the operation setting strict access control.
In terms of privacy protection measures are:
■ implement private data (Private Data) mechanism to solve allow certain private data in a ledger with more participating organizations shared among only a small part of the organization's problems.
■ The identity confusion (Identity Mixer) mechanism to achieve the anonymity of the originator of the transaction and the impossibility of tracing (unlinkability).
"Untraceable" means: When a user sends multiple transactions, these transactions are not sent from the same user from revealing.
The use of any technology is used to solve practical problems of some kind, I feel those trying to jump and obscure technical points explain the study's official website information, but also do know these know why. Due to space limitations, this paper analyzes in depth security solutions, content to stay on the protection of privacy in the next article will be explained. In addition, the text will inevitably be omissions and errors, welcome to correct me readers.
01
Security of communication
Fabric example of a block chain network as shown in FIG. The block chain and a node Org1 Org2 two organizations. Orderer organization has two nodes, and provides a sorting block services. Peer node has a variety of responsibilities, assumed the Endorser, Leader, Committer and Anchor these four responsibilities Peer1 figure Org1 of the Peer1 and Org2, Peer2 and Org2 of Org1 of Peer2 only Committer assume responsibility. The following occurs in the communication between the nodes:
1. The client application when initiating the transaction to access a number of Endorser Peer nodes do endorsements.
2. The client application then packaged into a transaction endorsement results submitted to any sort Orderer transaction, the block.
Leader 3. Peer retrieve blocks of each organization node from the Orderer, written after verification of local books.
Other Peer node (commiter) books in synchronization with the tissue 4. Leader Peer node, but also to verify the local write books.
Data synchronization (including books information, node information, private data, etc.) through inter-organizational 5. Achor peer.
1-4 above processing step is a step of the transaction. Wherein the step is performed based on 1,2,3 gRPC communication protocol; Step 4,5 Gossip protocol is based on that underlying protocol or go gRPC protocol. Fabric using TLS (Transport Layer Security) protocol to ensure the security of communication when gRPC transport layer. Specific works as follows:
■ Each organization has its own TLS Root CA certificate, which with its data-tier organization Root CA certificate to open an independent.
■ Each node (Orderer and Peer) has its own server TLS certificates issued by it out of the organization TLS Root CA.
So the question is, Org1 of participating entities (node or application clients) how to complete the TLS handshake with the node Org2 it? When Org2 node sends its server TLS certificate to the entity Org1 how the recipient to verify the certificate?
The answer is: Fabric will make all entities involved in the channel, the channel can be shared to all members of the organization TLS Root CA Certificate (and Intermediate CA certificate). This is called Channel MSPs mechanism (see Channel MSPs section). Therefore, Org1 entity acquired Org2 organization TLS Root CA certificates, so you can verify the TLS certificate server Org2 the node.
In addition, the careful reader may find in the above figure not shown Kafka and Zookeeper node. This is because they do not belong to the block chain node, but only sort implementation services. But in order to improve the security of the communication between the Orderer to Kafka can be configured TLS, but this certificate can not be issued by TLS Root CA organization. In addition spoilers about, Fabric Raft future intends to use to replace Kafka, currently under development. This is undoubtedly a good thing, because at least four Kafka and three Zookeeper in production-level deployment, which is a bit heavier.
Fabric single node can support TLS authentication and mutual authentication, the specific method please refer to the following link https://hyperledger-fabric.readthedocs.io/en/release-1.3/enable_tls.html
02
Books isolation
Books with a channel to isolate
Fabric block chain is a chain of coalition composed of different organizations. Fabric on one strand in a plurality of books can be isolated. So how is it done?
, As shown below a Fabric in a plurality of different block chain organizations alliances. Under the alliance a number of different organizations have established a one channel, each channel has an independent books, books can only be shared among channel member organizations. From this perspective, the channel mechanism can ensure the formation of a proprietary private networks between member organizations, trading in a confidential manner to perform on it, and has nothing to do with external organizations or individuals to isolate.
MSP
Let us now think about "channel can only be shared among member organizations books" mean what specific? Its essence is an application that the client can access any member organization Peer nodes and node Orderer any member of the organization to execute trades; and, the books can be synchronized between nodes channel member organizations.
In addition, when accessing different services provided by Peer node or Orderer, although visitors belong to a channel member organizations, but should be different access restrictions for different roles (for example: Only organization administrators are allowed to modify the channel configuration). Therefore, Fabric requires the ability to membership of a management channel, including the following:
1. capable of authentication and identification of participants.
2. channel set up trust (Trust Domain) for the border. So that all channels between the individual members of the organization participating entities (Principal, i.e. client nodes or applications) may communicate with each other and access services.
3. be able to identify the role of entities involved. This will make the appropriate permissions for access control request.
Fabric achieve the MSP (Membership Service Provider) modules to support more than the capacity. This is done, MSP entity created based on the PKI system as a channel member organizations and individual involved in the organization and management of a set of X.509 certificates and private keys (as shown below), use them to authenticate identities and roles, as well as members of the verification qualifications. From this perspective, MSP is the meaning of this group of certificates and private keys in lieu of that.
Fabric implemented support cryptographic algorithms BCCSP pluggable module (blockchain crypto service provider). MSP asymmetric encryption algorithm using the elliptic curve digital signature algorithm (ECDSA), hash algorithm SHA-256.
■ the left in FIG Root CAs Itermediate CAs and organizational data layer represents CA certificate used to authenticate the signer of a message body, which with the transport layer and tissue TLS CAs open to independent TLS Itermediate CAs.
■ Administrators is the user's credentials with Administrator role in the organization.
■ Keystore (Private Key) and Signing Certificate is issued by the organization Root CA certificates and private entities involved issued, found only in Local MSP entity in such information.
■ For other elements, please refer to the following link https://hyperledger-fabric.readthedocs.io/en/release-1.3/enable_tls.html
Local MSP
Local MSP refers to the organization of the participating entities (Peer node, Orderer nodes and application clients) exist in the local MSP information. It contains at least Root CAs certificate of the organization, the organization TLS Root CAs, the entity its own certificate and private key, certificate and Administrators organization. When communicating with other nodes, entities can be used by Local MSP private messages sent to the node signature to identify themselves to each other; can also be used to authenticate a message other members of the organizational entities sent, and some operation to do access control. For example: Peer node Local MSP can be used in response to the private key of the results endorsement signatures. As another example, the client application can install a smart contract Peer node on his organization's identity with the organization administrator.
Channel MSPs
So how do you build trust domain boundary of the channel it through the MSP?
The answer is: Fabric nodes and let the application client end of each channel member organizations share a global Channel MSPs, MSP which is a collection of all channel members of the organization. MSP each channel member organization include: the organization of Root CAs, TLS CAs and Administrators certificate. By Channel MSPs, the participating entity can verify the identity and role of organizations involved entities other members, and verify that the tunnel membership.
Channel MSPs sharing mechanism is as follows:
When the channel is successfully created, Channel MSPs write channel is configured (i.e. books founding block). When Peer node channel member organizations to join the channel will be channel configuration, thereby gaining a Channel MSPs. As shown below.
Peer process is actually added to the channel as an administrator to start Orderer achieved by the application client books channel configuration, and then passed to the Peer node.
FIG not mentioned in the application client is obtaining Channel MSPs, when in fact a local initialization Channel instance, to be connected via a Fabric SDK Peer node acquisition channel configured to extract Channel MSPs.
Authentication
By Local MSP and Channel MSPs, each node and the client application in the channel in the transport layer and the data layer may authenticate each other. The other access channel request from the outside, but were turned away because the channel can not be verified by the membership. In the application client request Endoser Peer node endorsement process example (shown below), it sends the message structure GRPC a SignedProposal type, comprising a signature for the message payload (i.e. ProposalBytes) (i.e. the Signature), in Proposal-> Header-> SignatureHeader contains the user certificate information. Endoser Peer with Root Channel MSPs in an organization's CA certificate to verify the signature of the head of the user certificate, and then use the user credentials to verify the signature of the message to determine its identity and whether the user has a passage membership.
03
Access Control
Access control is a very important function Fabric, mainly to solve the problem is who is allowed in a scene from accessing certain resources. When the user interacts with the Fabric, in fact intelligent user access contract, intelligent systems contract or Event Stream Source (Event Eventing Peer service provided) and other services that are considered resources. Fabric mainly to control various permissions to restrict access to these resources through policy scenario (Policy). Fabric implemented two types of Policy to meet the needs of different scenarios:
■ Signature Policy: to explicitly specify which participating entities (Principal) must be signed in order to meet the policy. It supports AND, OR, and combinations of such strategies NOutOf. For example: "Must Org1 and members Org2 are signature," or "signature of at least 11 people in 20 organizations Administrator."
Scenarios are: endorsement strategy, smart contract instantiation strategy.
■ ImplicitMeta Policy: It is not as flexible Signature Policy, but rather the result of a combination of multi-note policy evaluation, found that only the combination satisfies a given rule (Rule), in order to meet the policy. This strategy is described in the form: "<rule> <sub_policy>". There are supported by default Rule: ANY, ALL, MAJORITY. For example: "More than half of the organization's administrator within the channel signature" (Rule is: more than half of the sub-strategy: Organization administrator signature).
Scenarios are: for related operations such as configuration management: Create a channel strategy, channel configuration strategies, and tactics channel configuration is read from the Orderer, or get access to Peer block strategies and so on.
Policy on Official description please refer to the following link
https://hyperledger-fabric.readthedocs.io/en/release-1.3/policies.html
Now get endorsement strategies and policies to channel configurations are illustrated.
Endorsement Policy
Endorsement Policy (Endorsement Policy) is a typical Signature Policy, intelligent systems contract VSCC Peer node use it to check the endorsement signatures included in the deal whether meet the requirements of the policy.
VSCC (Verification System Chaincode) In addition to verifying endorsement strategy, it also a version of each data Key-Value Pair of transaction information to check whether the collection of reading has changed.
An example endorsement policy is as follows:
OR(AND('Org1MSP.peer', 'Org2MSP.peer'), 'Org3MSP.peer')
The implication is that only when Org1 and Org2 have been signing endorsement, endorsement or Org3 had signed the deal in order to be considered valid.
There is a easy to overlook the endorsement strategy places : signer identity (Identity) representation is "MSP.ROLE", such as: 'Org1.peer'. It is not meant only recognized organization Endorser Peer node Org1 signature on the endorsement of the results, but not other types of entities recognized organization Org1 (such as: application clients) sign the endorsement of the results of it?
The answer is: Yes, 'Org1.peer' represents the only recognized organization Endorser Peer node Org1 of endorsement signatures.
Based on OUs property x.509 certificates, Fabric identity of the signer's certificate is further divided into two types of client and peer. Those can initiate a transaction, a query Peer node take part in the operation of the identity of the entity classified as client type, such as user certificate application client; the identity of those involved entities can endorse or submit books and other operations classified as peer type, For example Endorser Peer node and Committer Peer node.
OU attribute type of client certificate is equal to 'client', and the type of peer OU attribute certificate is equal to 'peer'. The following Endorser Peer node certificate intercepted fragment of Org1.
Certificate:
... content ommited ...
Subject: C = CN = ST Shanghai, Shanghai L = OR = peer, CN = peer1.org1.aaa.com
... content ommited ...
■ Fabric v1.3 supports generation of client and peer types of certificates by configuring config.yaml, details, please refer to the following link
https://hyperledger-fabric.readthedocs.io/en/release-1.3/msp.html
. Of course, if you are to achieve your own certificate generation functionality and want classified identity, please set their own OU certificate for the peer or client.
■ Fabric v1.3 also supports key-level endorsement of the strategy, it will cover intelligent contract-level endorsement strategies. For more information, please refer to the following link
https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html
Channel allocation strategy
When an existing channel to the new organization, need to comply with the policy set by the channel configuration, which is located in the books of the channel configuration block.
Channel configuration is a typical policy of the Policy ImplicitMeta , this type of strategy does not directly signature check, but be checked by the policy (i.e., sub-strategy) combinations of sub-elements disposed in the hierarchy, and the policy is determined according to Rule meets. Configuration hierarchy mentioned herein may be confusing, go straight to the right channel configuration data structure, it constitutes a tree structure, as shown below. The so-called "configuration hierarchy" refers to the hierarchical tree structure.
Currently the channel has been a three organizations: Org1, Org2, Org3. The position of the channel configuration policy is: / Channel / Application / Admins. It is a type of ImplicitMeta Policy strategy, Rule is "MAJORITY", sub_policy is "Admins". It expressed the need to check the child policy named "Admins" in all organizations, and more than half of sub-strategies are required to meet. The position of "Admins" policies of the organization is (to Org1 for example): / Channel / Application / Org1 / Admins. It is a type of policy Policy Signature, indicates that the requested administrator role Org1 signature. At this point, if Org4 to join the channel, then the required three organizations, there are at least two organizations signed administrator job.
Farbic v1.3 has been supported by the access authority in configtx.yaml in. For more information, please refer to the following link
https://hyperledger-fabric.readthedocs.io/en/release-1.3/access_control.html
04
to sum up
Through in-depth understanding, it can be seen in the communication transport layer Fabric, books isolation and control authority has a very rigorous design and implementation. However, if you want to fully support the real business needs, solve the problem of privacy protection is also very important, this section will introduce in the next article. Glad to learn and communicate with everyone. Thanks:)