Hyperledger Development with in 10 days — Day 8

We have seen the structuring and running the sample apps. In this part we can do a deep dive into some important modules of the Hyperledger Fabric.

We are going to see about MSP(Membership service providers)

In Hyperledger Fabric, blockchain is considered as permissioned. So it conveys that, only approved users will be allowed to be the part of Blockchain network. How to give access to any specific members in blockchain is very important.

In Hyperledger network, there is a possiblity of having multiple Organisations/parties/businesses involved. So we need to have a mechanism for each organisation to create users for it cryptographically and validate the user transactions.

Blockchain’s main dependency is cryptography. All members/users are created with cryptographically encrypted key which will be validated by the blockchain network to participate in the network.

So the complete membership providing architecture is abstracted as a separate module called Membership service providers.

A Hyperledger Fabric blockchain network can be governed by one or more MSPs.

How to setup a MSP in Hyperledger Fabric network

To setup an MSP in the blockchain network, its configuration needs to be specified in below places

• locally in each peer in organisation
• orderer (peer enabling, signing)
• on channels to enable peer, orderer, client validation and member validations.

Each MSP should have a name so that it can be referenced in the network.(e.g. msp1, org2, and org3.divA)

This is the name under which membership rules of an MSP representing a consortium, organization or organization division is to be referenced in a channel.

“This is also called MSP ID or MSP identifier. It needs to be unique. Two same MSP initialisation in the orderer of the channel will fail”

In simple implementation of MSP, default parameters needs to be specified for client validation and transaction signature verification.

1. List of X.509 self signed certificate, that is the root of the trust (root CA)for the MSP
2. Intermedicate CA, which is certificed by any one of root certificate — optional
3. From the list of root of the trust certificates, one certificate will be chosen as administrator of the MSP. It has the privileges to change the MSP configuration.
4. A list of Organizational Units that valid are members of this MSP should include in their X.509 certificate.
5. A list of self-signed (X.509) certificates to constitute the TLS root of trustfor TLS certificate. — for (https connectivity).

Valid identity of MSP should satisfy below,

• 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 Organizational Units of the MSP configuration in the OUfield of their X.509 certificate structure.

It is important to note that MSP identities never expire; they can only be revoked by adding them to the appropriate CRLs. Additionally, there is currently no support for enforcing revocation of TLS certificates.

Generate MSP certificates and signing keys

Three ways we can create the certificates for the MSP configuration.

1. Using Openssl, generate X.509 standard certificates.
2. Using cryptogen tool given in fabric tools, using that we can create the certificates.
3. Hyperledger Fabric CA can also be used to generate the keys and certificates needed to configure an MSP.

Once you generated the certificates we need to do the MSP configuration on the peer as well as orderer for transaction validation and verification.

MSP setup on the peer & 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 six subfolders and a file:

1. a folder admincerts to include PEM files each corresponding to an administrator certificate
2. a folder cacerts to include PEM files each corresponding to a root CA’s certificate
3. (optional) a folder intermediatecerts to include PEM files each corresponding to an intermediate CA’s certificate
4. (optional) a file config.yaml to include information on the considered OUs; the latter are defined as pairs of  entries of a yaml array called OrganizationalUnitIdentifiers, where Certificate represents the relative path to the certificate of the certificate authority (root or intermediate) that should be considered for certifying members of this organizational unit (e.g. ./cacerts/cacert.pem), andOrganizationalUnitIdentifier represents the actual string as expected to appear in X.509 certificate OU-field (e.g. “COP”)
5. (optional) a folder crls to include the considered CRLs
6. a folder keystore to include a PEM file with the node’s signing key; we emphasise that currently RSA keys are not supported
7. a folder signcerts to include a PEM file with the node’s X.509 certificate
8. (optional) a folder tlscacerts to include PEM files each corresponding to a TLS root CA’s certificate
9. (optional) a folder tlsintermediatecerts to include PEM files each corresponding to an intermediate TLS CA’s certificate

Channel MSP setup

The genesis of the channel needs to be setup with the MSP. For the validation of peers/members involved in doing transactions. After creating the genesis block it is given to orderer to validate the channel creation. Orderer rejects the channel creation if two MSP uses same MSP ID.

For application channels, the verification components of only the MSPs that govern a channel need to reside in the channel’s genesis block. We emphasise that it is the responsibility of the application to ensure that correct MSP configuration information is included in the genesis blocks (or the most recent configuration block) of a channel prior to instructing one or more of their peers to join the channel.

When bootstrapping a channel with the help of the configtxgen tool, one can configure the channel MSPs by including the verification parameters of MSP in the mspconfig folder, and setting that path in the relevant section in configtx.yaml.

Reconfiguration of an MSP on the channel, including announcements of the certificate revocation lists associated to the CAs of that MSP is achieved through the creation of a config_updateobject by the owner of one of the administrator certificates of the MSP. The client application managed by the admin would then announce this update to the channels in which this MSP appears.

Best Practices of MSP’s

1. Mapping between organisations and MSP’s.

Recommended way is to have one to one mapping. Others are

• One Organisation — Multiple MSP’s
• Multiple Organisation — One MSP.

2. One organisation has different divisions (say organisational units), to which it wants to grant access to different channels.

• All members — One MSP
• Each Division — One MSP

3. Separating clients from peers of the same organisation.

4. Admin and CA certificates — Create different cerificates for different levels of MSP (eg- trust of root, intermediate CA’s)

5. Blacklisting an intermediate CA — Do blacklisting whenever needed.

6. CAs and TLS CAs

• Keep different folders for CA certificates and TLS certificates.

Some references are taken from official hyperledger-fabric docs.

---

Please find the other days of Hyperledger fabric

Day1 — What is Hyperledger and Fabric

Day2 — Concepts of Hyperledger Fabric

Day3 — Running the sample app

Day4 — How to start and configure network

Day5 — Manual, step by step for sample application building

Day6 — What is chaincode

Day7 — Chaincode for Developers