Hyperledger Fabric principle details and actual combat 5

The main content of this article is as follows

❝

“High-energy remind“

To understand this chapter, you must be familiar with asymmetric encryption and PKI (public key, private key, certificate, and CA). Otherwise, the learning behind will encounter great obstacles.

❞

Licensing access issues

We know that bitcoin wallets use key pairs to verify or sign transactions. Fabric uses certificates.

The certificate refers to the PKI certificate. Common PKI certificates are used on web servers to enable HTTPS. SSL certificate, for encrypted transmission.

But certificates have a very, very important application, which is digital signatures.

Certificates in Fabric serve the same purpose. Because certificates are essentially key pairs, but with a third party certification authority -CA.

Why not just use a key pair instead of a certificate?

Fabric is a chain of alliances.

Affiliate chains are also known as “permissives,” meaning that permission is required to access them.

A common method of authorization is account authentication, where the account password is used to determine whether the user is a legitimate user.

And Fabric does this:

All participants in the Fabric network (including the organization that manages the Orderer) are required to declare in advance which cas you trust.

Once trusted cas are identified, they are considered legitimate users as long as they access the network with valid certificates issued by these cas. This fulfils the need for licensing access.

Generate a certificate

There are two ways to obtain a certificate:

1. The first is CA issuance, which is commonly used in production environments. CA services can be deployed themselves, for example, Fabric CA. You can also use mainstream third-party organizations such as Symantec, Thawte, GeoTrust, GlobalSign, etc.

2. The second is generated using a tool that comes with the Fabric (Cryptogen).

We will start with tool generation and then add Fabric CA after we are more familiar with the concepts.

Generate certificates using cryptogen

Prepare a configuration file: crypto-config.yaml.

❝

“NOTE“

Configuration files are very long, and sticking them directly into the article makes reading experience worse. So I’m going to break them down into sections. The complete configuration files and operation commands are in a separate article called The Operation Guide.

❞

Segment 1. An Orderer cluster can be managed by multiple organizations, each of which contributes its own Orderer nodes, as shown in the following configuration

# crypto-config.yaml

OrdererOrgs:   The domain name and host name of the Orderer node are defined below

- Name: Orderer  # name = "#

Domain: mid.org  # the organization's domain name

Specs:   The Hostname of the orderer node is Hostname + Domain

- Hostname: order0  # order0.mid.org

- Hostname: order1

- Hostname: order2

Copy the code

Fragment 2. The peer node hostname and user of the participant organization are defined below

# crypto-config.yaml

PeerOrgs:   The domain name and host name of the peer node are defined below

- Name: Mcorp     # name = "#

Domain: m.com   # M Company domain name

EnableNodeOUs: true   # Set to true, more on that later

Specs:    The Hostname of the peer node is Hostname + Domain

- Hostname: peer0  # peer0.m.com

- Hostname: peer1

Users:  # specify the number of users in the organization, excluding administrators. This option is not valid under OrdererOrgs.

Count: 1

  

- Name: RateCorp

Domain: rate.com

EnableNodeOUs: true

Template:  The host name can also be automatically generated from the template by specifying the number of nodes

Count: 2 Peer0.rate.com, peer1.rate.com

Users:

Count: 1

  

- Name: DbCorp

Domain: db.com

EnableNodeOUs: true

Template:

Count: 2

Users:

Count: 1            

Copy the code

After saving the configuration file, run the following command:

cryptogen generate --config=./crypto-config.yaml --output="organizations"



# --config: Specifies the configuration file path

--output: specifies the directory to store the build files

Copy the code

❝

“TIPs“

For details about how to obtain Fabric programs, see the Operation Guide.

❞

When the command is executed successfully, a bewildering but clear structure is generated in the Organizations directory.

The most important files are only a few, and many others are duplicated.

Let’s look at the level by level:

The level 1 directory is clearly divided into Orderer correlation and peer correlation.

A secondary directory, a directory for each organization.

Each organization will have several directories under the corresponding folder:

• Ca: stores the root certificate and private key of the CA of the organization.
• Tlsca: stores the root certificate and private key of the CA that issues TLS certificates.
• MSP: Key concepts, detailed in the next section.
• Peers or Orderers: Stores the certificate file associated with each orderer or peer node.
• Users: stores certificates related to each user in an organization.

As shown in the figure above, db.com is used as an example. Two peer nodes and one user are specified in the configuration file. The corresponding directories are displayed here.

The user also has an administrator, which every organization has.

Let’s see what’s in the peer and user directories.

Don’t look at the flowers! Look under the red line. The file structure of user and network node directories is the same, including MSP and TLS.

“Here comes the point!“

What is the MSP

If you’re new to reading official documentation from start to finish, the concept of an MSP will definitely confuse you.

In order to find out what this concept was, I read most of the documents on the official website intermittently before I basically understood it.

Now, of course, the latest documentation is a little clearer, but it still takes a grasp of the system to fully understand it.

Here’s a taste of the official definition:

❝

The Membership Service Provider (MSP) refers to an abstract component of the system that provides credentials to clients, and peers for them to participate in a Hyperledger Fabric network.

Membership Service Provider(MSP) refers to an abstract system component that provides credentials to clients and peers to participate in the Hyperledger Fabric network.

❞

After reading this definition, it feels like it should be a concrete service.

However, it is not, it just defines the interface, used to complete the authentication of participants, authorization and transaction signature, verification, etc.

The MSP contains a set of interface definitions and operation mechanisms that we only need to understand briefly here — it is the stack of certificate files we saw in the previous section. To be precise, it is the file in the folder MSP.

Let’s see what’s inside?

As shown below, MSP has a certain directory structure. The MSP directory structure we generated in the previous section is not comprehensive, and some folders are not available (because they are not required).

So I posted pictures from official documents. The names of the files inside are different from those we generated, but the names of the folders are the same.

• config.yamlYaml configuration file has EnableNodeOUs. If set to true, the file is generated. The content and meaning of the picture below, if you do not understand, then read the following content.To view the contents of the certificate, run this command:openssl x509 -noout -text -in ./organizations/peerOrganizations/m.com/peers/peer0.m.com/msp/signcerts/peer0.m.com-cert.pem

• Cacerts: stores multiple root CA certificates trusted by the organization.

  If you are careful, you will find that it is the same as the certificate in the CA directory under the corresponding organization domain name directory. This directory is important and is considered legitimate as long as the holder of a certificate issued by a CA trusted by the organization accesses the Fabric network.

  Of course, if you have permission to access resources on the network, you need to pass the corresponding policy verification.

• Intermediatecerts: This directory stores the certificates of intermediate cas. Setting up an intermediate CA allows for more flexibility in roles and user permissions.

• Admincerts: stores the administrator certificate. Fabric v1.4.3 has been deprecated. You are advised to use the Settings in config.yaml to distinguish certificates for the administrator role.

• Signcert: This directory stores CA issued certificates, including public keys used to verify signatures.

• Keystore: stores the private key file corresponding to the public key for signature.

• Tlscacerts: this directory stores multiple ROOT CA certificates trusted by the organization to issue TLS certificates. Similar cacerts. It just works differently. Signcert is used for signature and TLS is used for SSL secure communication.

• Tlsintermediatecacerts: This directory holds the certificate of the intermediary CA that the organization trusts to issue TLS certificates.

• Operationscerts: This directory stores certificate files needed to access Fabric operation services.

When talking about Channel MSP later, we will also refer to the configuration of reVOCation_list, which stores the list of revoked certificates.

How is an MSP used

Hello ~! Is anyone else there? I hope I didn’t scare you off. All this paperwork and instructions up there, I’m looking at

Fortunately, these things are not memorized, but understood. There is no knowledge that can’t be understood by a good example, and if there is, there are two.

Where MSP exists

It exists in two places:

1. Local MSP: There must be an MSP file system on each Orderer and peer node.

   As shown in the figure below, I have identified the path of the file generated in the previous section and the corresponding node on the figure. When these nodes are started, the corresponding files are copied to the node’s file system. The path to which the files are copied can be customized, depending on the configuration of the program.

2. Channel MSP (Channel MSP) : The configuration of each Channel has the MSP configuration of its constituent members.

   The configuration information is obtained from the MSP directory in the corresponding organization directory. Such as: M corresponds to the directory is: “peerOrganizations/m.com/msp”.

   This directory contains certificates of trusted cas (including root CA, intermediate CA, TLS root CA, and TLS intermediate CA) and node OU configurations (that is, config.yaml in the MSP directory).

   There are other extras as well, which we’ll see later.

   Oh, yes, this configuration exists in the block. When exported to JSON format, it looks like this.

When MSP is used

Which brings us back to the deal flow we talked about.

Refer to the MSP directory structure diagram in the previous section. (Sweet as I am, I posted the picture behind, no longer scroll forward to ☺)

1. The identity of the client to User1 initiated trade request, and the request message with the private key signature (the private key: peerOrganizations/m.com/users/[email protected]/msp/keystore/signer.key), at the same time also attach your certificate: peerOrganizations/m.com/users/[email protected]/msp/signcerts/signer.crt.

2. After receiving the request, the peer authenticates the requester certificate and determines its identity through the CA certificate (including the intermediate CA certificate and the root CA certificate) stored in the channel MSP.

   And then execute the smart contract and get the execution result. The result is signed with the private key of the local MSP (also using the private key and certificate: MSP /keystore/signer.key, MSP /signcerts/signer. CRT, similarly below), and finally returned to the client.

3. The client compares the results, passes them, encapsulates them into transactions and signs them. It is then sent to orderer.

4. After orderer receives the transaction, it verifies and determines the identity of the user through the CA certificate configured in the channel MSP.

   Transactions are then packaged into blocks, which are also signed using a local MSP. Finally, it is distributed to the peer.

5. After receiving the block, the peer verifies the block validity. Each transaction within the block is then verified by various means (through the channel MSP and the signatures of the parties involved in the transaction).

TLS

TLS is a communication protocol used to provide confidentiality and data integrity between two communication applications. HTTPS is the HTTP protocol built on top of TLS.

Encrypted transmission is recommended for communication between Fabric clients and nodes and between nodes.

To enable TLS on a node, a CERTIFICATE issued by the TLS CA and a private key are required. The two files are stored in the TLS directory parallel with the MSP, for example:

conclusion

This section covers a lot of content, although there is only one simple step, but it covers two topics -MSP and TLS.

MSP is a core concept that, like channels, runs through the entire Fabric transaction process. We’re going to come back to this again and again.

A Fabric is a chain of alliances and participates in an organization. However, it is the nodes and users (clients) in an organization that perform specific operations and transactions. How does the system distinguish which organization users or nodes belong to? What is the role of the user in the organization?

The MSP implemented by PKI not only solves the problem of identity authentication, but also distinguishes different roles by using the OU field in the certificate.

Remember, however, that MSP is just a set of interfaces, so there are other implementations besides PKI, such as Idemix.

TLS is recommended for communication between clients and nodes and between nodes. This requires a TLS certificate and the CA that issued it (which can be the same as the MSP’s CA).

Production environments recommend setting up a fixed CA service, which can be organizational or public trusted. Easy to add or remove users and nodes.

Of course, if you don’t use CA services, you can use tools like SSL.

It should be noted that once the network is up and running, you cannot use cryptogen to create new nodes or users, because every time cryptogen is executed, the content of the CA certificate private key will be changed, which is equivalent to changing a new CA.

❝

“Remember!! Cryptogen tools are only used in development or test environments.“

❞

I am a2Stream programmer, we next time again cheap!

This article is formatted using MDNICE