How Membership Service Providers Govern Hyperledger Fabric

This article continues our discussions on the Hyperledger Fabric project. It is aimed at open source technology enthusiasts who are interested in blockchain technologies and have a working knowledge of the Hyperledger Fabric project.

A Hyperledger Fabric blockchain network can be governed by one or more membership service providers (MSPs). This provides modularity of membership operations, and interoperability across different membership standards and architectures. An MSP is a component that aims to offer an abstraction of the membership operations architecture.

In particular, the MSP abstracts away all the cryptographic mechanisms and protocols behind issuing and validating certificates and user authentication. An MSP may define its own notions of identity and the rules by which those identities are governed (by identity validation and authenticated by signature generation and verification).

MSP configuration
To set up an instance of the MSP, its configuration needs to be specified locally at each peer and orderer (to enable peer and orderer signing), and on the channels to enable peer, orderer, client identity validation and respective signature verification (authentication) by, and for all channel members.

First, a name needs to be specified for each MSP, in order to refer to it in the network (e.g., msp1, org2 and org3.divA). This is the name under which the membership rules of an MSP, representing a consortium, organisation or division within a larger firm, are to be referred to in a channel. This is also referred to as the MSP identifier or MSP ID. The MSP identifiers are required to be unique for each MSP instance.

In the case of default implementations of an MSP, a set of parameters needs to be specified to allow for identity (certificate) validation and signature verification. These parameters are deduced by RFC5280 and include the following:

• A list of self-signed (X.509) certificates to constitute the root of trust.
• A list of X.509 certificates to represent the intermediate CAs (certificate authorities) that this provider considers for certificate validation. These certificates ought to be certified by exactly one of the certificates in the root of trust; intermediate CAs are optional parameters.
• A list of X.509 certificates with a verifiable certificate path to exactly one of the certificates of the root of trust to represent the administrators of this MSP; owners of these certificates are authorised to request changes to this MSP configuration (e.g., root CAs and intermediate Cas).
• A list of organisational units that valid members of this MSP should include in their X.509 certificate; this is an optional configuration parameter, used when multiple organisations leverage the same root of trust and intermediate CAs, and have reserved an Organisational unit (OU) field for their members.
• A list of certificate revocation lists (CRLs), each corresponding to exactly one of the listed (intermediate or root) MSP certificate authorities; this is an optional parameter.
• A list of self-signed (X.509) certificates to constitute the Transport Layer Security (TLS) root of trust for the TLS certificate.
• A list of X.509 certificates to represent intermediate TLS CAs that this provider considers. These certificates ought to be certified by exactly one of the certificates in the TLS root of trust; intermediate CAs are optional parameters.

Valid identities for this MSP instance are required to satisfy the following conditions:

• They are in the form of X.509 certificates with a verifiable certificate path to exactly one of the root of trust certificates.
• They are not included in any CRL.
• And they list one or more of the organisational units of the MSP configuration in the OU field of their X.509 certificate structure.

In addition to verification related parameters, for the MSP to enable the node on which it is instantiated to sign or authenticate, one needs to specify the following:

• The signing key used for signing by the node (currently only ECDSA keys are supported), and
• The node’s X.509 certificate, which is a valid identity under the verification parameters of this MSP.

How to generate MSP certificates and their signing keys
To generate X.509 certificates to feed its MSP configuration, the application can use Openssl. I’d like to emphasise that in Hyperledger Fabric there is no support for certificates including RSA keys. Alternatively, one can use the cryptogen tool, provided by Hyperledger Fabric. The Hyperledger Fabric CA can also be used to generate the keys and certificates needed to configure an MSP.

Setting up MSP on the peer and orderer side
To set up a local MSP (for either a peer or an orderer), the administrator should create a folder; e.g., $MY_PATH/mspconfig that contains the following six sub-folders and a file:

• The folder admincerts to include PEM files, each corresponding to an administrator certificate.
• The folder cacerts to include PEM files, each corresponding to a root CA’s certificate.
• Optionally, the folder intermediatecerts to include PEM files, each corresponding to an intermediate CA’s certificate.
• This too is optional — the file config.yaml to configure the supported organisational units and identity classifications (see the respective sections below).
• Optionally, the folder crls to include the considered CRLs.
• The folder keystore to include a PEM file with the node’s signing key; let me emphasise that currently, RSA keys are not supported.
• The folder signcerts to include a PEM file with the node’s X.509 certificate.
• Optionally, the folder tlscacerts to include PEM files, each corresponding to a TLS root CA’s certificate.
• Optionally, a folder tlsintermediatecerts to include PEM files, each corresponding to an intermediate TLS CA’s certificate.

In the configuration file of the node (the core.yaml file for the peer and orderer.yaml for the orderer), one needs to specify the path to the mspconfig folder and the MSP identifier of the node’s MSP. The path to the mspconfig folder is expected to be relative to FABRIC_CFG_PATH and is provided as the value of the parameter mspConfigPath for the peer and LocalMSPDir for the orderer. The identifier of the node’s MSP is provided as a value of the parameter localMspId for the peer and LocalMSPID for the orderer. These variables can be overridden via the environment using the CORE prefix for the peer, e.g., CORE_PEER_LOCALMSPID, and the ORDERER prefix for the orderer, e.g., ORDERER_GENERAL_LOCALMSPID.

Note: For the orderer setup, one needs to generate and provide the genesis block of the system channel to the orderer.