Are there any existing methods for decentralized peer-to-peer identity verification without using any central entity for public-key signing. An example scenario is as follows.
We have a peer-to-peer system where each node has to verify the identity of another node. And the nodes won't use a central entity (like a Cert Authority for public-key signing). A simple solution would be to have all the nodes' public-keys baked in to every node during the creation/installation phase. But whenever new nodes are created or deleted, this has to be updated (which is an expensive step by the nature of the node's hardware/software design). Is there a better solution than this?
Related
In Hperledger caliper for benchmarking of fabric network, I have provided the connection profile with detail of CA. The transaction is successfully submitted to the network which is in the remote machine. I have checked the logs on peers, orderers, and CA. Only CA didn't have a log of requests to the CA server.
In my assumption, while submitting the transaction using fabric gateway the invoker identity must be verified by the CA. But this is not happing as a result of my configuration.
In which case CA server does not need to be enabled while submitting the transactions?
Edit: The question is edited to make the question specific to the involvement of CA while submitting the secure transaction on TLS enabled system.
Thank you!
It seems necessary to study the PKI and certificate(X.509) structure. Fabric-CA acts as an organization's CA and manages the identifiers of the each organization's member(orderer, peer, client...).
The authentication/authorization process for an identifier can be performed based on a certificate issued to a CA, but it does not need to be associated with a CA during the process.
In other words, during the P2P verification process, the CA is independent.
Taking the legacy system as an example, Facebook has issued a certificate from digicert, and the browser can verify the identifier through that certificate. (For Root CA verification, it is provided whitelisted at your browser or OS level level.)
It's like asking why you don't use digicert (Fabric-CA) when you say you do a transaction throughput benchmark for Facebook (peer/orderer).
Fabric-CA does not have a ledger and is not support for reading or storing transactions in the blockchain. it is just CA in Fabric Network, independent of the transaction processing benchmark.
If authentication/authorization for a resource has to be performed in the form of a live stream to a CA, it will have dependencies and cause big problems
(e.g. if digicert's system is paralyzed, Facebook will be paralyzed too)
in process, Fabric-CA issues an identifier on the network at the bootstrap stage before performing the benchmark, rather than verifying in the transaction processing process (if it has been created in advance through cryptogen, issuance. It can be seen as being.)
I have question related to cryptogen and hyperledger fabric network setup. I want to explain my workflow. I wanna know this procedure can be used for production
1. I have 2organisation org1,org2.In which each organisation consist two peers,only one ordered for
both organisation and 2 fabric-ca server.
2. Generating the all the key pairs using the cryptogen tool using the crypto-config.yaml.
3. Generating genesis block and channel transaction using the configtx tool with configtx.yaml.
4. (Important Note:)I am using the CA private key and certificate ca.org1.example.com-cert.pem, which is generated using the cryptogen tool in my network docker yaml file to setup the fabric ca.
5. After setup all i am running the network its works fine.
6. I am enrolling and registering the admin and user from the outside using the fabricnodesdk.
here its good practice to use the cryptogen generate ca private key and certificate to setup and run the CA server in production. If this not good practice, Is there any other way i can implement it. Please your suggestion would be helpful for me.
Hyperledger Fabric docs suggest not to use cryptogen tool for production environment
Reason: it’s a tool and all crypto materials are generated on the fly with 10 years validity and you cannot control further with fabric-CA like revoke, reenroll, etc because fabric-ca will not have a copy in the database
Traditional way: generating crypto material with fabric-CA by registering and enrolling an identity with 1-year validity
But if you take my opinion, I have used cryptogen tool 2 years back in one production environment. There is no harm to use cryptogen tool in production unless you will need to interact with CA to make changes to the identities. It depends on the use case in our usecase we do not need to keep changing the identities it was fixed forever it was a typical usecase
But later and now I have been using fabric-CA and custom CA to
generate crypto materials leveraging more possibilities
I find it a dirty way to do it. Your Fabric-CA is working and your orderers and peers are of course working because their certificates are correct and have been suitably signed by the CA. But the fact is that the identities corresponding to the orderers, peers and clients that you generated via cryptogen have not been registered in the Fabric-CA database, so you can neither manage nor revoke those identities and their corresponding certificates via your Fabric-CA in the future.
My advice (for production environments, of course): Don't be lazy; take care of a good proper fabric-ca-server-config.yaml and fabric-ca-client-config.yaml configuration; launch safely your Fabric-CA; and script your initial identity registration, certificate enrollment and MSP/TLS folder structure creation.
I am a newbie to Hyperledger Fabric. I came across a very confusing part of fabric.
Cryptogen is used to generate certs and keys for users and admin in an organisation.
Talking specifically about fabcar,
A very similar thing is the done by:
enrolling an admin
enrolling and registering a user identity using CA, in fabcar chaincode.
Things got more confusing when I saw CA server creating a bootstrap
'admin' identity while starting of the container itself.
So what exactly is happening?
What is the flow?
What is the difference between these admins created again and again?
I see, CA server container has a volume mounted, pointing back to the crypto-config folder which already have certs and keys generated by cryptogen.
Why are we again creating bootstrap identity on fabric-ca-server start using -b flag? We already have admin certs and keys generated for admin by cryptogen and those are already mounted on the fabric ca server container.
Why are we again enrolling an admin in fabcar chaincode, we already have certs and keys for admin, don't we(from the volumes mounted on fabric ca server container)?
Why are we both registering and enrolling a new user in fabcar chaincode, we already have certs and keys for one user(in fabcar), don't we(from the volumes mounted on fabric ca server container)?
Similar existing answers is not what I am looking for. I want an in-depth insight.
Thanks.
Okay, so after digging around for continuous 1 week I found exact answer to the question.
First, I would like to lay down exact flow and structure of fabric samples applications.
Fabcar and Commercial Paper are two different applications being
provided by fabric as a part of fabric sample.
Fabcar uses first-network and Commercial Paper uses basic-network.
Fabcar has its chaincodes in chaincode folder while Commercial Paper has its chaincodes in contract folder within the two organisations.
After chaincodes are installed by administrators (don't confuse this admin with CA admin, this is simply a developer who is managing channel) using peer chaincode install and peer chaincode instantiate the contract becomes available to all the components of the respective channels.
Now we need to have certain application that will be invoking contracts known to the channel. Both Fabcar and Commercial Paper have their different applications in their respective application folders.
Applications can interact with our channel or say underlying fabric layer through a gateway.
The Hyperledger Fabric SDK provides a gateway abstraction so that
applications can focus on application logic while delegating network
interaction to the gateway. Gateways and wallets make it
straightforward to write Hyperledger Fabric applications. Find here in the docs
Our applications require some identity to be able to use underlying fabric layer. This identity's authenticity is checked by gateway before allowing access to the network.
Fabric uses concept of keys and signed certificates to perform this authentication.
Diving into a different concept here, fabric provides two kind of certification architectures (architecture might not be the correct word),
cryptogen - generally used for developement or testing purposes to generate keys and certificates
Certificate Authority - not a new concept, used by fabric to generate certificates. Any CA server requires to have admin to allow generating certificates.
While bringing up the server itself, this bootstrap identity is created using fabric-ca-server start with a -b option with username:password parameter.
Coming back to fabric, before starting any network (basic-network or first-network) fabric asks us to generate cryto-config.
Commercial Paper uses certificates and keys generated by this previously generated crypto-config by cryptogen to generate identities for the application.
Fabcar uses CA to generate certificates and keys. Admin was registered already when we brought up our CA server container in Fabcar. We simply gave him certs and keys on enrollment. New user require both registration and enrollment (done using CA admin identity).
The private and public key are first generated locally and the public
key is then sent to the CA which returns an encoded certificate for
use by the application. These three credentials are then stored in the
wallet, allowing us to act as an administrator for the CA. Find here in the docs
So it's not by design of fabric why Fabcar used CA and why Commercial-Paper used cryptogen, it's simply by choice.
I'll end my answer, quoting exact statement from the fabric documentation.
When we created the network, an admin user literally called admin
was created as the registrar for the certificate authority (CA).
Our first step is to generate the private key, public key, and X.509
certificate for admin using the enroll.js program. This process uses
a Certificate Signing Request (CSR) — the private and public key are
first generated locally and the public key is then sent to the CA
which returns an encoded certificate for use by the application.
These three credentials are then stored in the wallet, allowing us
to act as an administrator for the CA. We will subsequently register
and enroll a new application user which will be used by our
application to interact with the blockchain. Find here in the docs
addToWallet.js is the program that Isabella is going to use to load
her identity into her wallet, and issue.js will use this identity to
create commercial paper 00001 on behalf of MagnetoCorp by invoking
papercontract. Find here in the docs
Any corrections from experts are very welcome. These are my deductions from code observation.
I don't know what fabcar does, but maybe I can clarify some Hyperledger Fabric concepts to you.
cryptogen is a development tool using for generating all the (MSP and TLS related) cryptographic stuff you need initially for your development Fabric network.
For more serious deployments, you use Fabric-CA instead. Fabric-CA is a Certification Authority that maintains a database of the identities registered for your organization and allow your registered actors to enroll their certificates. You can also update identities, revoke identities and certificates, etc.
And then you have to distinguish a CA administrator from a organization administrator. You first enroll the CA administrator, otherwise you cannot register identities. And a organization admin is simply an identity with role admin for the organization.
Normally, the enrolled CA administrator generates all the identities. After that, later, in other place, the organization administrator (or any other identity) enrolls its certificate by specifying the user and password declared during registration.
Some Theory: cryptogen is just a tool written in golang and what it does is it will create a self-signed root ca and some signed certificates(org admin, users, entities)
Now when you start CA, if you want to use the same cert and key generated by cryptogen then you will use below command
fabric-ca-server start -b myorgadmin:myorgpw -d
ELSE if you do not want to use cryptogen generated certificates then you can use below command and you should forget about cryptogen generated certificates because they no longer use and you have to generate by yourself
fabric-ca-server init -b myorgadmin:myorgpw
DIFFERENCE is init command
Bootstrap CA server credentials are in order to authenticate for future
purposes
Ex: If you want to register a new user then you need to authenticate
with credentials
In future, you can use cryptogen generated user certificates or you can register different users by authenticating CA server
I think Fabric CA is needed when client node has to enroll for using Node.js Application. So if I use Fabric-cli when I invoke or queries chaincode, does Fabric CA need?
-> I thinking Fabric CA only useful for enrolling client node. And If client node does not exist in a network, Fabric CA can be replaced with Cryptogen Tool.
To be able to do invokes and queries you need a user context. To get the user context you either need an user created by registering and enrolling an user via the CA server or you can use an already created user by the cryptogen tool.
So point is, once the user is created, you no longer need the CA Server or crytogen tool.
In fact cryptogen tool is used to generate the certs of the entire network when the network is not created in the first place.
Also, when T-Certs will be supported in the future, for each transaction that you make, you would be required to get a T-Cert from the CA server to proceed with the transaction.
I am new to hyperledger and I want to understand more on channel. I am working on POC, where I need to have private transaction between 2 parties,so I want to understand how should i configure my network.
Should I have different chaincode for each channel or one chaincode can be used across 2 channels.
It is multi user application and user coming across and can do transaction on any channel, how should the identity be configured. Should we have intermediate user or identity to communicate or is it good to use application user identity can be used.
If you are creating a network comprised many organizations, but want to design a means of preserving confidentiality of a transaction between two organizations A and B, then you would create a channel that has org A and B as participants, and deploy the chaincode(s) to the endorsing peer nodes for each org.
As for end-user identity, that would typically be designed such that the end-users were members of one or the other org, and their authentication and authorization would be somehow managed by each org. For instance, let's say that the end users are employees of org A and org B, then you could use your corporate LDAP as a means of authenticating and authorizing them to perform certain transactions.
Alternately, if they are customers of A and B, then whatever user authentication and authorization you have for managing end users could be used. Whatever authentication is used, the MSP (membership services provider) for each org would need to be adapted to support the means used when issuing identity certificates.
The Hyperledger Fabric CA Users Guide has specifics.