how certificates get derived from the real fabric-ca-server certificate in hfc-key-store in hyperledger?

Question

I'd like to explain what I understand correctly first and if I'm right, please tell me the truth and if I'm mistaken, tell me also that I'm mistaken. My explanation is about how hyperledger network and node sdk works together and how node sdk connects to hyperledger network.

Let's start. When I start hyperledger network, what it does is creates fabric-ca-server docker image and container on port 7054. On that port, it registered an user "admin with the password : "adminpwd". Which means there have also been certificates made for this user. Now let's say I want to create a new user from node sdk. I guess what I need to do is to have the certificate for Admin so that I can sign my request and network knows I'm admin and part of the network. What the code does is it firsts writes getUserContext("admin") and if it doesn't find, then it tries to enroll with the username and password (admin and adminpwd). My understanding is that getUserContext goes to hfc-key-store folder and tries to find the certificate for admin. if it doesn't find it, there happens enrolling and then happens createUser function, which puts certificate derived from fabric-ca-server docker image into hfc-key-store, so that when admin tries to enroll again, it doesn't have to go to fabric-ca-server docker image. Am I right so far? I'll ask my questions now.

Questions :

1. I understand that when trying to enroll, it doesn't fetch the original certificate for admin from fabric-ca-server docker image, because if it gets stolen, whole network gets screwed up. so what It does is derives some kind of public/private and certificate from the original one with what I can make other operations. Question is : what If someone stole my hfc-key-store folder in which there's admins certificates. he can do operations without enrolling,because getUserContext("admin") would return true and it would let it do anything. What if someone steals that folder? isn't it dangerous?

2. I don't understand what getUserContext() and setUserContext() and what createUser() functions mean at all. PLease if you can do, just describe them in a very understandable language, because It's been a long time since I've been trying to wrap my head around this but with no luck. Why do we need these functions, what they help us with and so on.

3. Why is cryptogen tool not used in production but fabric-ca-server usable in production?

Answer 1

It seems a lot of questions there. Let me explain it step to step. Please give your comments if something is wrong or not clear.

Fabric is designed as a Consortium Blockchain System and is widely used in enterprise business scenarios. In a Fabric business network, each org usually contains at least one peer, and optional one ca.

Think of a business scenario like this. Several companies want to do business together. However, they don't trust each other enough. So they decide to use Fabric to solve their pain point. Suppose this network contains 3 companies (orgs) and each company (org) have one peer and one ca.

Now the business network is already setup.

First, let me explain the concept of enroll.

1. Each org's ca has a bootstrap user, this comes by the username and password, usually the samples would use admin/adminpw. During the ca server setup time, this bootstrap user was write to the CA's db. After setup, the bootstrap user is registered. but not enrolled.
2. The next thing is enroll the bootstrap user. In this step, fabric-sdk (I will use sdk later) will first, generate a private/public key pairs, then generate a csr (certificate signing request), at last use the private key to sign the csr and send the signed csr to fabric-ca server.
3. When fabric-ca server received the signed csr. It generate a certificate for this user. The certificate contains the user's public key. Fabric-ca will use its private key to sign this request and append it's signature at the certificate.
4. The sdk get response (the certificate from 3) from fabric-ca server. fabric-sdk put the certificate and user's private key together (we call it enrollment) as the response of method enroll().
5. Now the bootstrap user has its enrollment, and can visit fabric network using this enrollment.

We can use the bootstrap user to register and enroll new users in this org. This is why we call the consortium blockchain system as permissioned blockchain system.

Second, let me explain the concepts for sdk KVS (key-value-store).

We already get the user's privateKey and certificate From above steps. So how do we persist these data? There are several choices, store it in a Application layer database, some hardware encrypted wallet, some cloud based HSM, etc.

Fabric-sdk provides a KVS to do this. This is an optional choice, you may choose to use it or not. Frankly speaking, I don't recommend to use this at production system. If you just want to try something or test something, this is good because it is quite simple.

By default, fabirc-sdk-node will use a filesystem KVS. It store the credentials in disk, this is what you mentioned hfc-key-store folder.

So what will happened if the KVS was stolen?

All the enrollments are stolen. All the certificates and privateKeys are stolen. The attacker can use these certificates and privateKeys to visit the blockchain system with the identity in these certificates. It's a disaster.

What is the createUser() used for?

Instead of store these enrollments in filesystem. A better choice to store it in an Application layer database. Each time we want to visit the blockchain system, we can query from the db first and get the certificate and privateKey. Then use the createUser() interface to create a new User instance. This User instance is used as the identity to visit the blockchain system.

At last, let me explain the transaction flow in fabric

We not have a valid user certificate and privateKey. How do we send transaction to fabric network? How does fabric-peer verify the transaction and know who am I?

1. Each transaction contains the user's identity. If you want to submit a transaction by userA, then you should call setUserContext(userA) before further endorse call.
2. The transaction proposal contains the user's certificate at message header. And before the transaction was send to fabric-peer, sdk will use the current user's private key to sign this transaction proposal.
3. At peer side. when peer receives the endorse request, peer will use the root cert of the fabric-ca to verify the certificate in this request, so that peer knows this request is from an identity issued by a known CA, now the certificate is credible. Then the peer will parse the certificate and get the identity's public key, and then use this public key the verify the signature of the transaction (I described above the tx was signed by the private key and now it is verified by the public key), now the transaction is trustable.

From the transaction flow, we learned that a transaction must be send with the user's certificate and signed by the user's private key. This is why we designed the setUserContext() interface at fabirc-sdk.

cryptogen tool

This tool is used to generate private/public key pairs and the corresponding certificates at system setup. After that we need a dynamic add/remove identity mechanism. And the solution is Fabric-ca.

Note, fabric-ca is optional, you may use any other CA.