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.
Related
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 saw a number of articles talking about HL and ZKP but I was unsure if that is planned or actually implemented. I saw in the docs that version 1.4 is current but AWS has 1.2 implemented. Articles did not always state the versions and it was not that clear.
Has anyone the current status of ZKP and HL Fabric?
Fabric 1.3 and later have limited support for ZKP; it is only use for anonymous / unlinkable credentials when using Identity Mixer credentials. This allow clients to submit unlinkable transactions from an identity perspective.
There has been research into using ZKP for other types of transactions, but no concrete release plans.
Hyperledger Fabric 1.3 and later versions are providing privacy preserving attribute based authentication through Identity Mixer components. It is integrated into the Membership Service Provider (MSP) services. Identity Mixer is a cryptographic protocol suite for strong privacy-preserving authentication, signatures, and transfer of certified attributes.
Identity Mixer system allow for efficient zero-knowledge proofs (ZKP) of possession of a signature and the corresponding attributes. It does not reveal the signature and (selected) attribute values themselves, but only prove that the signature on some attributes is valid.
There are three actors involved in an Identity Mixer flow: user, issuer, and verifier. Following are the components in the implemented approach.
The Fabric SDK is the API for the user.
Fabric provides two possible Identity Mixer issuers:
Fabric CA for production environments or development, and the 'idemixgen' tool for development environments.
The verifier is an Idemix MSP in Fabric.
The Identity Mixer implementation in the Fabric SDK can be found in the following GitHub repository.
Identity Mixer in Fabric SDK
There is a stand alone implementations of Identity Mixer in the following GitHub repository.
IBM Cloud Identity Mixer Issuer Verifier
I am trying to design a Hyperledger Fabric solution with following requirements
The users are signed-up with an organization
The user should however have their individual identities on Blockchain
The users would interact with Blockchain through a web application
The users should store their own private keys / certificates
Individual user's key / certificate should be used to sign the transaction going to Blockchain. The organization however should not have access to user's private key / certificate
Instead the web application should merely transfer the signed content of the transaction to Blockchain, making it tamper-proof
Are there any solutions available that would cater to these requirements, so that the users continue to work through the web application only?
Can node.js SDK for Fabric be used on the client side to sign the transaction using the locally stored private key / certificate on user's desktop / laptop?
As of right now, no, there are no solutions available to cater to these requirements as the node SDK does not currently support a separation of logic between signing transaction proposals and sending transaction proposals. Step 6 is not possible with the 1.2 SDK.
Separating that logic is slated for the 1.3 release.
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.
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