Blockchain- Hyperledger Fabric — Part 2
by Abhishek VT
We have covered the fundamental introduction to blockchain in our previous session (https://medium.com/@abhishek.talakeriv/blockchain-introduction-50ac59e38b96) , and in the upcoming sessions, we will delve into the details of Hyperledger Fabric and its implementation.
Hyperledger Fabric, a permissioned/private distributed ledger technology (DLT) platform, is an open-source enterprise-grade solution specifically tailored for enterprise environments. It offers several distinctive features that set it apart from other well-known blockchain platforms or distributed ledgers.
A significant factor that sets Hyperledger apart is its establishment under the Linux Foundation. The Linux Foundation has a proven track record of fostering open-source projects through open governance, resulting in the development of robust communities and flourishing ecosystems.
Fabric stands out as the pioneering distributed ledger platform that enables the creation of smart contracts using widely-used general-purpose programming languages like Java, Go, and Node.js, rather than being limited to domain-specific languages (DSLs). This significant advantage implies that most enterprises possess the requisite skills for developing smart contracts, eliminating the need for additional training or acquiring proficiency in a new language or DSL.
Key concepts
We will explore the following essential notions to gain an understanding of the Hyperledger Fabric network and architecture.
- Identity Management
- MSP — Membership service provider
- Policies
- Ledger
- Peers
- Channel
- Chain code
- Smart Contracts
Identity Management
CAs (Certificate Authorities) are really important in the Fabric blockchain networks. That’s why Fabric has a special CA component built-in, which helps you create CAs. This component is called Fabric CA. It acts as a private root CA provider and takes care of managing the digital identities of the participants in the Fabric network using special certificates.
However, Fabric CA is designed specifically for the root CA needs of Fabric and cannot provide SSL certificates that work automatically in web browsers. But don’t worry, even in a test environment, you still need a CA to manage identity. That’s where Fabric CA comes in handy. It can provide and handle the certificates you need.
If you prefer, you can also use a public or commercial root or intermediate CA to handle identification tasks. It’s perfectly fine and suitable to do so.
Let us understand the key Concepts which are related to Identity management.
Imagine you and your friends are part of a special club where you play games and have fun together. In order to make sure only club members can join and play, we need a way to identify and manage everyone’s membership.
In Hyperledger Fabric, each person in the club gets a special digital card that proves they are a member. This digital card is like a secret code that only they know. It has their name, picture, and other important information.
To make these digital cards, we have a special person called the Certificate Authority (CA). The CA is like the club’s ID card maker. They check that each person is really a member and create a digital card for them.
Once you have your digital card, you can use it to do things in the club. It’s like showing your membership card to enter a special room or join a game. The digital card helps prove that you’re a real member and lets you participate.
But wait, there’s more! In our club, we have different roles and responsibilities. Some members are game leaders, while others are scorekeepers or helpers. Hyperledger Fabric helps manage these roles too.
With Hyperledger Fabric, the digital cards have different levels of access. It means that some members can do certain things while others have different abilities. For example, shopkeepers might have the power to start games, while scorekeepers can keep track of scores.
This way, everyone has their special role and can contribute to the club’s activities. It helps keep everything organised and fair.
Identity management in Hyperledger Fabric is like having special digital cards that prove you’re a member of a club. These digital cards are made by the Certificate Authority and have important information about each member. They help you join activities and show what you can do in the club based on your role.
Let us know exactly what the digital certificate is?
In the above example, we used a word called Digital card which is nothing but Digital certificate
A digital certificate is a special electronic document that helps verify the authenticity and identity of someone or something in the digital world. It is like a digital ID card or a virtual passport.
A digital certificate contains important information, such as the name of the person or organisation it belongs to, a unique identification number, and a special code called a digital signature. This digital signature is like a secret code that proves the certificate is genuine and hasn’t been tampered with.
Just as a passport is issued by a trusted authority, a digital certificate is issued by a trusted organisation called a Certificate Authority (CA). The CA verifies the identity of the person or organisation and signs the digital certificate with their own digital signature, confirming its authenticity.
In simpler terms, a digital certificate is like a virtual ID card that proves who or what it claims to be and helps protect your online interactions. It helps establish trust and security in the digital world.
X.509 certificate
X.509 is a widely used standard for digital certificates. It defines the format and structure of certificates used in various systems, including web-based communication, email encryption, and secure network communication.
An X.509 certificate is a digital document that contains information about an entity, such as a person, organisation, or device, and is used to verify their identity in the digital world. It follows the X.509 standard, which outlines the specific format and fields that a certificate should include.
- Version : Which X.509 version applies to the certificate, indicating what data the certificate must include.
- Certificate Serial number: The CA creating the certificate must assign it a serial number that distinguishes the CA certificate from other certificates.
- Algorithm information. The signature algorithm the issuer uses to sign the certificate.
- Issuer Unique Identifier: The name of the entity issuing the certificate. usually, the CA.
- Validity Period : The start and end date, as well as the time the certificate is valid and can be trusted.
- Subject Unique Identifier: The name to which the certificate is issued.
- Subject public — key information : The public key associated with the identity.
- Extensions : Extensions have their own unique IDs, expressed as a set of values called an object identifier. An extension can be rejected if it is not recognized or if the extension has information that can’t be processed.
Public and Private keys
Think of private and public keys like a lock and key system. The private key is like a special key that you keep secret and never share with anyone else. It’s called “private” because only you have access to it.
The public key, on the other hand, is like a lock that is created based on your private key. You can freely share the public key with others. It’s called “public” because you can give it to anyone who wants to send you encrypted messages or verify your digital signatures.
Here’s how they work together:
1. Encryption: If someone wants to send you a secret message, they use your public key to encrypt it. This process scrambles the message so that only your private key can decrypt and read it. It’s like putting the message in a locked box that only your private key can open.
2. Digital Signatures: Let’s say you want to prove that a message or a digital document comes from you and hasn’t been tampered with. You can use your private key to create a digital signature, which is like a unique electronic stamp. Others can use your public key to verify that the signature matches the message and ensure its authenticity.
Remember, it’s crucial to keep your private key safe and secure because if someone else gets hold of it, they could potentially impersonate you or gain unauthorised access to your encrypted information.
Private and public keys are widely used in secure communication systems, such as secure messaging apps, online transactions, and digital certificates, to protect sensitive information and ensure trust between parties.
Certificate Authorities(CA)
A Certificate Authority is a special organisation that checks and confirms the identities of people or computers in the online world. They act as a trusted third party that vouches for someone’s digital identity, just like a referee vouches for a player’s fairness in a game.
When you want to create a digital certificate (like a special code that proves your identity online), you go to a Certificate Authority. The CA carefully verifies your identity using different methods, such as checking your personal information or asking you to prove who you are.
Once the CA is confident that you are who you say you are, they issue a digital certificate specifically for you. It’s like receiving a stamp of approval from the referee that confirms you’re a legitimate player in the digital world.
Types of Certificate Authorities
There are primarily three types of Certificate Authorities (CAs) based on their relationship and trust levels:
1. Root Certificate Authorities: Root CAs are the highest level of authority in a public key infrastructure (PKI) system. They are responsible for issuing and signing their own self-signed root certificates. Root CAs are inherently trusted by default as they are pre-installed in operating systems and web browsers. Their certificates are used to sign and validate certificates issued by subordinate CAs.
2. Intermediate Certificate Authorities: Intermediate CAs are subordinate to the root CAs. They are authorised by root CAs to issue and sign certificates on their behalf. Intermediate CAs help in creating a hierarchical chain of trust. Their certificates are signed by the root CA and can be used to sign and validate certificates issued by other intermediate or end-entity CAs.
3. End-Entity Certificate Authorities: End-entity CAs, also known as subordinate CAs or entity CAs, are at the lowest level of the PKI hierarchy. They obtain their certificates from intermediate CAs and are responsible for issuing certificates to end entities such as individuals, organisations, or devices. End-entity CAs are trusted based on the chain of trust established through the intermediate and root CAs.
It’s important to note that these types of CAs are based on the hierarchical structure of a traditional PKI system. However, there are also other types of CAs, such as cross-certification CAs and policy CAs, that may be used in specific scenarios or customized PKI setups.
Folder structure for operating the Fabric CA client in the Blockchain network
In the upcoming practical sessions, when we build the blockchain network and develop web3 applications, we will delve into FABRIC-CA, which is all about managing identities. This was just an introduction to give you an idea, but we will explore it further with hands-on activities.
