There are a set of entities in the distributed fabric network, and each entity must be associated with a unique identity. These identities can be issued by Fabric Certificate Authority (Fabric-CA) or an external CA, and the Membership Service Provider (MSP) manages these identities across the entire network. The identities are issued by the CA, along with the CA signature on it, is called a certificate, and one of the predominated certificate formats is x.509.
The benefits of having all these identities are to use for authentication, validation, signing, and issuance.
- Whenever two entities initiate a communication, there should be proper authentication, and usually, it is done based on the identity. However, malicious entities can impersonate someone else identity. That the reason the entities trust on root CA. Whenever someone claims their identity, another party verifies the certificate to ensure whether an entity is claiming the correct identity or not.
- Every time a user transacts on the blockchain, they authenticate themselves by signing the transaction. The signature is verified by the peer or any other receiving entity on the blockchain network. It means any entity that is not a registered user cannot perform transactions, read blockchain, or channels, etc., so none of this information will be available to that entity.
These are various entities such as peers, orderers, client applications, and administrators in the blockchain network, and only the authorized entities can perform the operations. For example, the user will sign a transaction send it to the peer, and the peer will execute the transaction, and when it endorses, it is actually signed the endorsement. In the same way, the ordering service when it creates a block and sends it to the peers. Each block is going to be signed by the ordering service.
The MSP can support different crypto standards, and it is a pluggable interface. Different applications might need different security properties provided by the different CAs or different crypto standards.
A network can have multiple MSPs; however, it is recommended to have one MSP per organization. So based on the number of organizations, the entire network have that many MSPs.
Each entity must have a local MSP, and it is used to store credentials, such as private keys, securely using hardware modules provided by hardware platforms.
The entire communications among the different entities are secured through TLS (Transport Layer Security). TLS provides the following:
- Cryptographic protocols that provide communications security over a computer network.
- Provides privacy and data integrity
- Symmetric cryptography is used to encrypt the data transmitted (privacy)
- Public-key cryptography is used to authenticate the identities of the communicating parties.
- Include message integrity check to prevent loss or alteration of the data.
- All component communication is Fabric secured using TLS (client-peer,peer-peer, peer-orderer, and orderer-orderer)
User Identities
Every user in the network received an identity and an enrollment certificate. The enrollment certificate has two parts, one is a private key, and the private key is private to a particular user and used for digitally signing the transactions that will submit onto the network. The private key is stored securely using a hardware security module provided by the computer hardware platform. The second part is a signcert, which is a public x.509 certificate in the fabric implementation. The public key includes a public key and other attributes provided by the certificate authority (CA). However, other crypto standards can also be used.
A signcert includes various attributes, including organization details, certain roles, authorization, and other information. For instance, if this is a user’s certification from the supply chain blockchain network, the user role may be an exporter or trader. So these kinds of attributes can also be embedded within a certificate, and these attributes can be used to authorized transactions on the network.
Peer and Orderer Identities
Each peer and ordered are having a private, public key, and sign certificate from CA. A local MSP is attached to the peer who holds these identities. In addition, the peer and MSPs can identify authorized administrators. So it can have one or more administrators. Each administrator has the following artifacts:
- admincert: A list of administrator certificates.
- cacerts: The CA public cert for verification. As peers and orderers deal with transactions and transactions are generated and signed by different users from different organizations. So it includes multiple CA public certificates for verification of requests.
- crls: List of revoked certificates.
For instance, an organization running the peer can designate one of its users as an administrator. The administrator will be included in the admincerts, and there will specific functions defined that only the administrator can do.
The peer and orderers receive channel MSP information since the channel also has an MSP. The peers and orderers will know which channels they are connected to.
Channels MSP
Channels include additional organizational MSP information, such as which peers and orderers are joining or leaving the channel, and these are dynamic in nature. For instance, some peers may join the channel later in time, and other peers might leave the channel. All this information will be dynamically configured in the channel MSP, and this information is queryable.
So a new peer joining the channel can query the channel MSP to find out which other peers are participating in this channel. It also determines which client applications can connect to this channel and can perform transactions on this channel. It also stores all the configuration blocks in the ledger like any new peers or orderers joining the channel are configured as transactions on the blockchain. The channel MSP includes:
- admincerts: Any public certificates for administrators.
- cacerts: The CA public certificate for this MSP.
- crls: List of revoked certificates.
It does not include any private keys for identity. The channel information is all public. For example, who are the administrators, peers, and orderers. However, the channel does not hold any private information.
Example: New User Registration and Enrollment
Let us consider an example where a new user wants to get register to the network. In this case, the user needs to communicate with the administrator. The administrator calls the registration function using fabric-ca-client, with an identity called enrollment Id and other attributes. As a response, the Fabric-CA returns a secret. The administrator forwards the enrollment id and secret to the requested user over a secure channel.
The user performs enrollment using the received enrollment Id and secret and sends it to the Fabric-CA over a secure channel. Seeing these credentials, Fabric-CA ensures that the enrollment request is valid. It generates public and private key pairs for the user, generates an x.509 certificate for its identity, and sends it back to the user. This will be the long-term certificate, and the user uses it to sign all the transactions and stores it securely in the local MSP.
Example: Transaction Management
Permission users sign all transactions within a Hyperledger Fabric network, and the receiving entities validate those signatures. The user signs transactions with their private key, which are securely stored in their local MSP. In contrast, the receiving entities such as peers must have the public key of that particular user and the CA certificates to validate transactions.
The entire transaction goes like this, the user signs the proposal and submits it to the peer. The peer validates the signature, executes the transaction, signs the response, and sends it back to the user. The user receives the response, validates the endorser signature. Then, the client signs the entire endorsed transaction and sends it to the ordering service. The ordering service validated the client signature, ordered the transactions received from multiple clients, constructed a block, signed the block, sent it to peers, etc.
References
- NPTEL lecture series on Blockchains Architecture, Design and Use Cases by Prof. Sandip Chakraborty, IIT Kharagpur.
710 total views, 1 views today
