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.
Related
I want to create an application with the Hyperledger fabric network and I'm unsure what the optimal way of processing and storing the clients information is. It is important for me that the personal information get stored off-chain to not slow down the network.
Right now this is the process I thought about:
Client fills out form in frontend
Application (backend) generates unique UUID
(registering enrolling UUID in the wallet) unsure about this step
Chaincode gets called which saves the UUID in the state database
The UUID and the personal information like Username, email, password get encrypted and saved in an off-chain database like postgreSQL.
That way the UUID can be connected to the personal information because the UUID is also stored off-chain and it is still totally anonymous.
But is it necessary to register and enroll the user through the Node SDK with the enroll and register function before being able to access the chaincode, because without the registration there would be no identity for the client in the network?
And I'm also cunfused if this function from the fabcar samples is the same as the enroll and register function from the node SDK?
Thanks for your efforts and helping me understand this matter.
The enroll code of fabcar is the enroll of node-sdk.
In other words, they are the same.
node-sdk/enroll
fabcar/enroll
const secret = await ca.register({
affiliation: 'org1.department1',
enrollmentID: 'appUser',
role: 'client'
}, adminUser);
const enrollment = await ca.enroll({
enrollmentID: 'appUser',
enrollmentSecret: secret
});
First, let's talk about fabric's SDK.
In general, in order to query/invoke chaincode on the fabric SDK, you need to obtain fabric client authority.
Suppose you register a specific user UUID as a Client of Fabric and call the chaincode through that Client.
In this case, the order you should perform is as follows.
enroll admin-client to Fabric-CA
register user-client by admin-client to Fabric-CA
chaincode invoke by admin-client or user-client to Fabric-Network(peers, orderers)
step 1, when Fabric-CA is first operated, the administrator ID and password can be specified through specified parameters. Based on the specified ID and password, a client key/certificate with admin authority is issued from Fabric-CA and stored.
(Fabric-CA is recommended to be operated in an organizational unit, and client authority is organization dependent.)
step 2, a new user can be registered through the admin-client key/certificate. Probably you would register the UUID as enrollmentID.
When the registration process is finished, the user-client's key/certificate is issued by enrolling in Fabric-CA, and it is stored.
step 3, the chaincode is query/invoke through the stored admin-client/user-client key/certificate. Of course, it can be performed only if the client is authorized, and this is defined in the genesis block of the channel in the blockchain network (that is, it must be set in the configtxgen process)
Overall, if you look at the scenario, you can see the two processes divided.
In case of separate authentication server
Build a new database(for off-chain).
When registering as a member, the user's information(UUID, password ...) is stored in the database
going through the fabric user-client registration process, the key and certificate are stored in the file system or database.
When logging in, based on the newly established database, authentication is performed.
When the chaincode of the fabric network is called while the user's validity is verified according to the authentication procedure, it operates based on the mapped key and certificate.
When using an organization as an authentication server within Hyperledger Fabric
User information is stored in the blockchain through PDC(Private Data Collection) provided by Fabric.
PDC is an off-chain technology, and only predefined organizations share data.
Through this function, validity of data can be performed by all organizations participating in the channel, but only organizations with permission can view/edit the actual sensitive information.
In the end, the process and procedure are the same, but all resources can be managed on the blockchain.
(Like all technologies, they have pros and cons, and trade-offs need to be taken care of.)
[NOTE]
If you are going to query/invoke the chaincode of the fabric network, fabric-client privileges are essential.
Of course, you can do some tricks.
for example)
register admin-client on the server.
After that, it operates the same as the existing authentication server/resource server.
If the chaincode of Fabric Network is called, and it is valid by the existing authentication server, the chaincode is executed through the admin-client authority issued in advance.
This does not require a separate user-client registration/management procedure.
However, the authority on the blockchain is all dependent on external certification authorities.
Basically trying to find resources to understand Sovereignty wrt to identities.
How Identities are maintained within Hyperledger Indy?
how can the decentralized digital nature of identities
benefit to avoid data and identity thefts?
How can the users own and control their identities ?
How to integrate SSIs with Hyperledger Fabric ?
Identities on Hyperledger Indy are Pairwise Pseudonymous Identifiers by default to prevent identity correlation. Decentralised Identifiers (DIDs) act as the primary keys on the ledger. DIDs on the ledger point to the DID Descriptor objects (DDOs), signed JSON objects that can contain Public Keys and Service Endpoints for a given identifier.
Decentralised Identifiers will help us to maintain an audit trail for identities. Decentralised identifiers will provide tamper evidence that makes identity theft quite difficult. The implementation approach also matters. In the Hyperledger Indy implementation, we get the ability to revoke credentials. If we can see any trace of an audit trail on a possible attempt of identity theft, we can revoke the identity and credentials.
When it is a self sovereign identity created by the user, there will be separate identity issuer, identity maintainer / ledger and identity verifier. Through pairwise identity architecture, identity issuer will always be able to control the identity records and identity workflows.
With regard to Hyperledger Fabric integration, a few possible options exist. All of them are in the research and experimentation phase. However it is worth exploring. Please let me list a few of them.
Hyperledger Foundation Projects for 2019 - HLD Fabric + HLD Indy
Stack Overflow - Communication between HLD Fabric - HLD Indy
Self-Sovereign Identity is a new decentralized identity where control of identity is not with the issuer but it is with citizens. e.g Currently your National ID is maintained and governed by an Issuer which is Government, but as per Self Sovereign Identity, it is you, who will manage your national ID and decide what to do with it. Now identity will be citizen-centric, not issuer-centric and that's how decentralize identity differ from normal identity services.
Now let me answer the following question:
1: How Identities are maintained within Hyperledger Indy?
Ans - Identities are maintained at two levels, public DID, schema, and other Public details are stored inside Hyperledger Indy ledger but Citizen's personal Information, Verifiable credentials (driving license, national id) are stored in a Hyperledger Aires-based Mobile Wallet app.
2: how can the decentralized digital nature of identities benefit to avoid data and identity thefts?
Ans - Now Identities are stored in users' own mobile wallets encrypted with keys that are far safer than identities that are getting stored with the issuer and act as a honey pot for attackers. Facebook, Twitter, Gmail data leaks are common nowadays.
Another good things are even if your identities are compromised, as long as attackers don't have a private key/master key, those identities can’t be utilized for any purpose.
if your master key is compromised, there is a way to recover the key as well as revocation of compromised identity is possible.
3: How can the users own and control their identities?
Ans - This is the basis of self-sovereign identity, Issuer will create verifiable credentials like your driving license, sign with its own Public Key which is embedded as part of DID in Hyperledger Indy ledger and issue it. The user will store that verifiable credential in a mobile wallet. Now User can decide to whom to share this verifiable credential. Now if the user went to a car rental company, the car rental company will create a presentation proof asking for driving license details, User mobile wallet will create a response of that presentation proof and sent it to the car rental company. Car rental company verify the proof by getting the public keys of the issuer DID from the Indy ledger. This is how identities will be issue, controlled by citizens and verification will be done without contacting Issue (Driving License Authority ) at all.
4: How to integrate SSIs with Hyperledger Fabric?
Ans - As of now, there are no such enterprise developments happening. SSI is a very generic term, SSI can be implemented using Ethereum which is uport/DAF Project, Hyperledger Aries, and other open-source DLTs. Integrating with Fabric depends on the use case and workflow.
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 am reading hyperledger fabric read the docs and I am confused how local MSPs of the users allow the user side to authenticate itself in its transactions.
explain the meaning of this paragraph
Node local MSPs define the permissions for that node (who the peer admins are, for example). The local MSPs of the users allow the user side to authenticate itself in its transactions as a member of a channel (e.g. in chaincode transactions), or as the owner of a specific role into the system (an org admin, for example, in configuration transactions).
but we use x.509 certificate to authenticate the users right ?
You bring up a very good point in terms of the overloaded use / meaning of the term MSP as well as the "file / folder" structure used to hold cryptographic material for the various entities in Fabric.
Fabric currently supports two types of MSP: X509 and Identity Mixer. The default is to use X509 which means that you validate that users are part of an organization by ensuring that their X509 certificates were issued by the root/intermediate CAs defined in the organization's MSP (which typically ends up stored as part of each channel's config).
So broadly speaking, an organization's MSP defines the mechanism for validating identities (based on the issuer present in the MSP definition) and defining how to determine the "role" of those identities (for example admins are explicitly defined by having their certs in the admins folder and in 1.4.3 and later optionally by a specific OU in the cert).
A "local" MSP holds the actual crypto material issued by an organization's MSP. In the case of a peer, this includes the key pair (found under keystore and signcerts) used to sign endorsements as well as the information needed to determine administrator's for the peer itself. In the case of ordering nodes, the key pair is used for signing blocks. For clients / users, the key pair is used to sign transactions.
To your point, a client really does not need the MSP structure ... you really just need the signing / enrollment key pair and the MSPID ... but unfortunately the MSP concept is also carried over to clients even though most of the material in an MSP structure is not required for signing transactions.
In all of the fabric examples and documentation, usually there is a unique private certificate authority issuing certificates for each organization.
However, playing around with the code base, I do not see a limitation that different orgs need to each have different Root CAs.
Is there an issue with having the same Root CA for multiple organizations? Can the subject fields in the certificates be sufficient to use for identity verification in different fabric workflows?
If you want to ensure that one organization does not masquerade as another, there must be something unique about the certificates that are issued by or for an organization. Of course the easiest way to handle this is to have a separate root CA per organization. It's also possible to have a common root but have different intermediate CAs for each organization.
But given your question is about basically using a single fabric-ca to issue certificates for multiple organizations, this is possible using the Organization Unit (OU) identifier feature introduced in v1.1 and later. Basically, you can differentiate organizations using an OU in the issued certificates. With Fabric CA v1.1 and later, you can create different affiliations for each organization and when certificates are issued, the OU will be set to the affiliation associated with the identity during the registration process. You can either trust a single admin to properly register identities for multiple organizations, or you can create an hierarchical set of admins (meaning create multiple CA admins but assign each a different affiliation as admins can only register users under their own affiliation).
Then within your MSP definitions, you can using the config.yaml file to specify the OU with which to associate the MSP. For example, if you look at https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/msp/config.yaml, then
OrganizationalUnitIdentifiers:
- Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "COP"
means that this org is identified by the root CA PLUS having OU=COP in the certificates. This would also mean that the affiliation within fabric-ca would be "COP" as well