How Zero-Knowledge Proofs work on Indy Network
Hyperledger Indy is a distributed ledger software to enable decentralized identity with transferable, private, secure and verifiable credentials by using anonymous credentials. Anonymous credentials enable identity owners to prove their identity in an unlinkable and unforgeable way.
The anonymous credential protocol includes multiple cryptographic techniques such as commitment schemes, signature schemes, zero-knowledge proofs, hash functions to provide resiliency and privacy to all relevant parties.
Protocol Details
In general, there exist three roles in the given protocol: issuer to issue credential, holder(identity owner) to store credentials and verifier to verify and use credential for some purposes. The credential is made up of integer-based attributes and each attribute is a 256-bit signed integer. The holder presents proofs relying on the credential to verifier, who can verify if the issuer attested the claims.
Step 1: Issuer Setup
A credential schema is chosen by issuer and issuer figures out how to map it to a flat array of integer values. A credential definition is also created which includes the public key of issuer, a proving key for set-memberships and a reference value to the schema. Then the credential schema is published on the ledger.
In each credential there exist three types of attributes:
- Issuer attributes which are the meta-data about issuer and credential, such as issuer identifier, a revocation reference, credential issuance date etc. Revocation reference is used by holder to prove that the credential has not been revoked by using Merkle trees.
- Subject attributes which are the claims about one or more credential subjects such as name, age etc.
- Blinded attributes which are known only by holder such as link secret, policy address etc.
Issuer defines generators for each attribute and blinding factor generator for holder to compute blinded attributes. Then issuer publishes public key and these generators on the ledger.
Step 2: Holder Setup
The credential definition is obtained from the ledger.
Holder generates a 256-bit random number as his/her link secret. The use of a link secret allows for credential chaining. One of the hidden attributes in the credential is the link secret, which is blinded. In all credentials, the holder has to use the same link secret.
Holder sets up a connection with issuer. A 128-bit nonce value is shared by issuer via this connection. Holder uses the issuer public key and blinding factor to generate blinded attributes. Hidden attributes are blinded and sent to the issuer. Holder agrees on the values of known attributes, and requests a credential from issuer.
Step 3: Credential Issuance
Issuer receives the blinded hidden attributes and the proof of the knowledge of hidden attributes. He/she verifies the correctness of holder and defines subject and issuer attributes. Then, issuer sends credential to holder.
The holder receives a credential from the issuer. The credential includes the requested attributes and declares non-revocation status of credential. It also has a partial signature on it. The attributes and signature are verified, and the signature is completed and credential is stored by holder. The non-revoked status of the credential is announced on the ledger by the issuer.
Step 4: Proof Presentation
There are two types of statements about credential attributes in a proof presentation:
- Hidden: fully hidden attributes - holder proves only knowledge of value, linked attributes -holder reveals that two attributes have the same value and partially disclosed attributes- holder reveals predicates(equal-to, not equal-to, greater-than, less-than, or set-membership can be used as predicates).
- Revealed: fully disclosed attributes
For each type of proof attributes, verifier creates a set of challenges. These challenges consist of terms and operations, the proving system, the parameters, attributes etc. needed to satisfy the challenge in terms of the type of proof attributes. This combined challenge set comprising a proof description as a presentation request is sent to holder. A list of requested attributes and disclosure predicates is included in the presentation request.
Holder sets up a connection with verifier. A 128-bit nonce value shared by verifier via this connection. Holder checks that the credential meets the requirements for the presentation. The set of credentials to use to match the proof description is selected and for each attributes random numbers are generated.
Holder also gathers the required data from the ledger to prove non-revocation and generates a proof about having a non-revoked credential satisfying the presentation request.
The attributes from each credential, random values about commitments and the predicate terms are the inputs of predicate proofs.
Then, proof of credentials issued by issuer, the set of commitments and the set of revealed attributes are sent to the verifier.
Step 5: Proof Verification
Verifier verifies the proof by using data received by holder. The commitments is used to check predicates. Verifiers should look for proof that each credential in a presentation contains the same link secret.
