In Fabric Hyperledger, if we want to dynamically increase the user-issued certificate, we generally use Fabric CA or other CA. However, in the national secret transformation scenario, there is currently a lack of available open source Fabric CA national secret version. Therefore, the author did some research and found a way to directly use cryptogen to generate a new certificate without using a CA, temporarily reducing the demand for the national secret version of Fabric CA. At the same time, expand, because this method has no version limit, so I personally think that it can also be used for the transformation of the national secret of Fabric 2.0 and above.
One, the premise
Recently, due to work needs, I tried the National Secret Transformation Application of Fabric Hyperledger (only application, no underlying transformation involved). The current state secret transformation of the Fabric Hyperledger is actually divided into three parts: Fabric source code, Fabric SDK and Fabric CA. The open source version of the first two parts of the National Secret Reconstruction Internet is already available (at your own risk). For specific usage methods, see my other two articles:
- Fabric Hyperledger 1.4.1 National Secret Modification Version Centos Stand-alone Deployment and Test Process
- An application process of fabric-sdk-go, a fabric-sdk-go implementation based on the technology route of Tongji
The available open source Fabric CA national secret version has never been found. The open source Fabric CA national secret version on the Internet has problems of one kind or another. Either it cannot communicate with the certificate generated by the cryptogen tool, or there is a problem in using it. Of course, it is not ruled out that there is a non-open source available Fabric CA national secret version, but for me, I need a free and usable Fabric CA national secret version.
– Here is an advertisement. For the issue of cryptogen and Fabric CA certificate interoperability, see my other article: Cryptogen and Fabric CA certificate interoperability in Hyperledger
2. Demand
But why do we need to use the national secret version of the CA? fabric-samplesReaders who have used the test network know that, for example first-network, when the network starts, the cryptogencertificate is generated by default , but the number of certificates it generates is fixed. If you want to add a new user, you can change the number of certificates in the configuration and then regenerate. However, the new certificate is regenerated, and the original certificate cannot be used. It is more convenient to use CA here, you can add users at any time without affecting the entire network.
But the problem has arisen. Currently, in the demand for the transformation of the Fabric State Secret, no open source and usable Fabric CA State Secret version is found. Of course, we can also not use CA. For example, using a cryptogentool to issue 100 users directly when the network is started is enough. But this is always a bit low.
We know that whether a certificate issuing authority is a Fabric CA or cryptogen, as long as their private key and root certificate are the same, they are the same CA. Then, can we take advantage of this and do the opposite? Since Fabric CA is not available, then we do not use Fabric CA, why not try to use the cryptogengenerated private key and root certificate to issue certificates belonging to the same organization?
Three, realize
If you want to use it cryptogen, let's see what it can do. fabric-samples/binRun directly under the directory ./cryptogen help, you will get the following output:
usage: cryptogen [<flags>] <command> [<args> ...]
Utility for generating Hyperledger Fabric key material
Flags:
--help Show context-sensitive help (also try --help-long and --help-man).
Commands:
help [<command>...]
Show help.
generate [<flags>]
Generate key material
showtemplate
Show the default configuration template
version
Show version information
extend [<flags>]
Extend existing network
Hey, there is a extendsub-command, meaning to expand existing network, it seems Me. Go to the official document to see the detailed introduction of this command:
see the introduction that it is used to expand the network. Although an organization is added in the example, you have to try it.
Then enter the fabric-samples/first-networkdirectory, direct running ./byfn.sh up, start the test network. Note that the new users we generated here need to be tested, so you need to refer to my article on SDK usage, first start the national secret version of the test network and connect to the national secret SDK to pass the test.
Then because the byfn.shscript is to generate sub-commands: cryptogen generate --config=./crypto-config.yamlwe have to change to extendsub-commands. So according to the example in the above figure, first we have to create one new-org1-config.yaml, the content is crypto-config.yamlonly the part of org1, and the number of users is changed to 3 (except the administrator), as shown below:
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org1
# ---------------------------------------------------------------------------
- Name: Org1
Domain: org1.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 3
After saving and exiting, in the case of network startup, we first-networkrun in the directory
../bin/cryptogen extend --config=./new-org1-config.yaml
The screen will have similar output:
hehehehe &{
{
57896044551258231062740198220913455226441901632205615997740090104278065086466 0xc00007c140 [536870905 268435455 895 268428288 536870911 268435455 536870911 150994943 268435455] [394377860 220399154 355969936 163370829 236861671 88177300 303341152 24396229 75627569] [137364797 52992271 113266657 202339045 31563580 107393171 24488059 247693942 35835723] [408558522 55895443 311818945 254526569 75260154 203012265 258167614 151236203 209300666]} 93322454353996403820296961564506544728212789716739747136454365915828308484093 6966228001545439549108757395662279044399389641667730857900146482088229055896}
hehehehe &{
{
57896044551258231062740198220913455226441901632205615997740090104278065086466 0xc00007c140 [536870905 268435455 895 268428288 536870911 268435455 536870911 150994943 268435455] [394377860 220399154 355969936 163370829 236861671 88177300 303341152 24396229 75627569] [137364797 52992271 113266657 202339045 31563580 107393171 24488059 247693942 35835723] [408558522 55895443 311818945 254526569 75260154 203012265 258167614 151236203 209300666]} 30306800224514377016096554966983804996273193405862204168872079179630755829514 92380653969940809229613336050795378666932279691927801513843736432124786976274}
hehehehe &{
{
57896044551258231062740198220913455226441901632205615997740090104278065086466 0xc00007c140 [536870905 268435455 895 268428288 536870911 268435455 536870911 150994943 268435455] [394377860 220399154 355969936 163370829 236861671 88177300 303341152 24396229 75627569] [137364797 52992271 113266657 202339045 31563580 107393171 24488059 247693942 35835723] [408558522 55895443 311818945 254526569 75260154 203012265 258167614 151236203 209300666]} 4311683100071045748705022318436765074509955434317854120607477640429312740432 99882041785790063772976559666758032554047899796398476617595580203019199906461}
hehehehe &{
{
57896044551258231062740198220913455226441901632205615997740090104278065086466 0xc00007c140 [536870905 268435455 895 268428288 536870911 268435455 536870911 150994943 268435455] [394377860 220399154 355969936 163370829 236861671 88177300 303341152 24396229 75627569] [137364797 52992271 113266657 202339045 31563580 107393171 24488059 247693942 35835723] [408558522 55895443 311818945 254526569 75260154 203012265 258167614 151236203 209300666]} 18113313443822832374468548508152336351389244341164675859983815020626652461706 76852597410980258905261680766762896262700409724285143957744057129835174169268}
Ok, now check the corresponding user directory, as shown below:
Four, test
At this point, our new users are generated, and we can see that there are two more users. Let's test it:
- Whether the old user has been rewritten
- Is the new user valid
According to the article used by my country secret GO-SDK, open it main.goand you can see that the current user is User1, run go run main.goit directly , and the result will be 90, which proves that our old users are valid. Then we will User1change it User3and run it again go run main.go, and we will still get a result of 90, which proves that our new user is effective.
In fact, we can also compare users ../bin/cryptogen extend --config=./new-org1-config.yamlbefore Adminand after use with users, and we User1can find that they are exactly the same. It can be guessed from the previous output (it has four lines of output) that it should be a certificate generated according to a certain fixed rule, so the same certificate is generated by the repeated users in the previous section. I have done this comparison, so I won’t list it here.
Well, it 's that simple to issue new users with cryptogenalternatives Fabric CA. However, its application scenarios are far less widely used than CA, and it can only be used as an alternative method without CA.
Although we still have to continue to pursue the Fabric CA national secret version, we just have to use something, right... _
V. Outlook
Because this alternative method has no version restrictions, that is to say, it can be applied to the national secret transformation of Fabric 2.0 and above. Currently, Net Security has open sourced the national secret version of the Fabric 2.0 source code. If the corresponding Fabric CA or other CAs can be replaced according to this idea, then the national secret transformation of Fabric 2.0 will only have the national secret version of the SDK in terms of availability. The secret has been reformed.