I found following in the Composer docs. Is it ok? I thought that CA is for storing certificates/public keys but not private keys. Is it possible to sign messages on a client-side?
The Hyperledger Fabric certificate authority generates an enrollment secret that can be given to the participant, who can then use the enrollment secret to request their enrollment certificate and private keys from the Hyperledger Fabric certificate authority.
Yes its possible. Composer stores the key/certificate in a wallet accessible by the client application user, so the user can sign transactions on the business network (using a Composer business network card to connect to it and which has the user's blockchain identity). This transaction is therefore signed by a certificate to say which identity is being used to submit the transaction.
Related
what i see from the hyper-ledger fabric CA setup and user registration is that, when i enroll the user the private key is generated on the server side with certificate after which CA will sign the user will get certificate with private key. Generating user private key on server side is security issue. Is there way so i can create the private key offline and generate certificate. Correct me if i am wrong
The private key is generated by the client instead of the CA. When the enrollment is called by the client (either the Hyperledger Fabric SDK or the fabric-ca-client client command), it will automatically:
Generate the key pair of private key and public key.
Use the key pair to generate a certificate signing request (CSR).
Send the CSR, enrollment ID, enrollment secret and other attributes to the CA to enroll the secret.
The CA will then return a signed certificate to the client.
As the private key is generated and stored by the client, there is no such security issue for leaking the private key by signing the certificate online.
You may take a look at the official document of Hyperledger Fabric and the Wikipedia about PKI for the detail process of the certificate signing.
In Hyperledger Fabric when identity is issued the certificate and Key is shared by the admin unlike in multichain where the user receives the key as response and it is not shared with anyone not even admin.
Is it possible in some way in Fabric? If not then Hyperledger is not decentralized it is only distributed.
It is possible. An admin registers a new user by the certificate authority and gets a "secret" back.
This secret is then used by the client to enroll directly by the certificate authority and get his own key/certs, with nobody in between.
What exactly is difference between enrolling and registering a certificate in Hyperledger Fabric CA. I am new to cryptography and i am really confused about the working of Fabric CA. Also how are certificates generated via cryptogen is diffrent from certificates generated via Fabric CA.
So from what i understand when you "enrol" an identity you get the certificates and private keys for it. When you "register" the identity, you are simply creating the user name and password for that identity with the CA server.
The certificates that the cryptogen tool generate are not any different to the ones generated by the Fabric CA, the cryptogen tool is there for convenience in development. It should not be used in a live / production environment. Under the hood the cryptogen tool actually spins up a fabric ca server locally.
Here is a link to the latest documentation for Fabric CA:
https://hyperledger-fabric-ca.readthedocs.io/en/latest/
"Registration" is done by the CA admin. A username and password is assigned to an identity, along with attributes (will the identity be an admin or a node, for example?). This registration places the username and password, along with the relevant other information about the identity, in the database of the CA. No certificates have been generated at this point. The identity has simply been registered.
"Enrollment" is the process where certificates are created and given to the user of the identity. The username and password is given to this user out of band, and they use the name and password as part of a fabric-ca-client call to the CA. The public and private keys --- encoded with the relevant attributes registered with the CA --- are then generated.
The reason for the separate between registration and enrollment is to ensure that only the user of an identity receives their private key.
The certificates created by a CA are identical to those created by cryptogen --- an x.509 certificate is an x.509 certificate --- but cryptogen is a tool for quickly creating certs in a test environment, not a true method for creating certificates for anything resembling production.
Registering identity means adding its details in Fabric CA.
Enrolling means process when registered identity connects to CA and sends Certificate Signing Request (CSR) to it. CA checks if the identity is registered and performs some other validations, if checks are successful then it returns signed certificate to the identity. Since the certificate is signed by CA trusted by blockchain network, the identity has now means to interact with the network using this certificate.
So, to make the identity being able to interact with the network it must pass two steps in this particular sequence:
Be registered on CA
Be enrolled
Admin is preregistered in CA using when it is started
fabric-ca-server start -b admin:adminpw
The details are here:
https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html
also you can refer to source
The concept of first register(Saving username,password and other attributes in CA's DB) then registered identity can enroll to get certificates is the same in the latest version of Fabric CA as it was previously.
Refer to the latest link:
https://hyperledger-fabric.readthedocs.io/en/latest/deployment_guide_overview.html#step-four-use-the-ca-to-create-identities-and-msps
"Register and enroll an admin identity and create an MSP. After the CA that will be associated with an organization has been created, it can be used to first register a user and then enroll an identity (producing the certificate pair used by all entities on the network). In the first step, a username and password for the identity is assigned by the admin of the CA."
When following the documentation at here in order to issue identities in Hyperledger Composer, they say that:
The Hyperledger Fabric certificate authority generates an enrollment secret that can be given to the participant, who can then use the enrollment secret to request their enrollment certificate and private keys from the Hyperledger Fabric certificate authority.
I have successfully issued an identity and got the enrollment secret. However, it is not clear how to request the certificates from the CA.
Could anyone help?
that instruction is not entirely clear, will need to get this changed.
A Business Network Card is the definitive means to connect to a Composer business network, and a constituent part of that is identity that you issued (and which was mapped to a participant in Composer) - it is only possible to access a Composer business network through a valid Business Network Card. It consists of a connection profile, some metadata for the identity using it, and ultimately, a set of credentials (certificate/private key which get populated automatically to the user's wallet from where it is used to 'connect' - a 'ping' is also a connect). FYI an identity (linked to a participant in Composer) can have one or more cards (each to connect to one or more business networks).
The document you need to read to do that is https://hyperledger.github.io/composer/latest/reference/composer.identity.issue.html
you'll see it has a -f flag to create a card file - that is the file you import (eg using Composer Playground to import or composer card import -f ). If you've done that import from the CLI, do a composer network ping so that it will use the one-time enrolment secret to request the certificate/key from the CA server and then store it in the user's wallet under $HOME/.composer - the card should be listable using the command composer card list
i'm currently working on a POC application using hyperledger composer. I'm creating a mobile app which uses the client-SDK for interacting with my hyperledger network. I'm wondering how authentication works. Enrolling a new user works fine, i can enroll a new user being an admin and i receive the enrollmentID and enrollmentSecret. The documentation tells me the enrollmentSecret is used as confirmation for the CA to generate a certificate and corresponding keys.
The SDK gives me the idea that i'm authenticating by using only the enrollmentID and enrollmentSecret instead of the certificate and keys.
Quoting another answer i found:
When a participant enrols using the enrolment ID and secret, an enrolment certificate is generated and placed into their wallet (configured using the keyValStore property in the connection profile). Once the enrolment certificate has been generated, the enrolment secret is made invalid. The secret can be only used one time - it is not a password.
However what i want to do is give the "identity" total ownership of the certificate and keys so they can use it to authenticate on the network (maybe turn it into physical form / paper wallet). Looking at the SDK documentation this doesn't seem possible and i currently have no idea how it works if the only way to connect to the network is supplying the enrollmentId and secret.
Or does the SDK automatically store and use the certificate in the stored in keyValStore(connection profile) to authenticate? If so is it possible to manage this programmatically?
Thanks in advance
Hyperledger Composer issues new identities by using the Hyperledger Fabric certificate authority (CA) to register new enrollment certificates. The Hyperledger Fabric certificate authority generates an enrollment secret that can be given to the participating identity, who can then use the enrollment secret to request their enrollment certificate and private keys from the Hyperledger Fabric certificate authority.
See https://hyperledger.github.io/composer/unstable/managing/identity-issue.html
You then bind a participant (added to your business network) to that identity and that identity is used to submit transactions to the Fabric blockchain. So the authority to do so is via the metadata in the connection profile (pointer to the KeyValStore for the user in question) and the id's certificate in that KeyValStore.
Check out the Hyperledger Composer docs.
https://hyperledger.github.io/composer/unstable/managing/identity-bind.html