-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
b123aab
commit 0ddc605
Showing
4 changed files
with
127 additions
and
109 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,115 +1,12 @@ | ||
| --- | ||
| slug: /accounts/ | ||
| description: Passport-derived profiles turn biometric passports into zero-knowledge identity credentials for Web3. | ||
| slug: /accounts | ||
| description: Own and control your identity with our self-sovereign protocol. | ||
| # TODO: add an illustration? | ||
| --- | ||
| import OutLink from "@site/src/components/OutLink"; | ||
| import IdealImage from '@site/src/components/IdealImage'; | ||
|
|
||
| # Passport-derived profiles | ||
| # Accounts | ||
|
|
||
| Rarimo has developed a novel solution that turns a regular biometric passport into a flexible digital identity credential for Web3. Importantly, this is done without compromising the security of your sensitive data by using zero-knowledge proofs. | ||
| Rarimo is a self-sovereign protocol, meaning the user fully owns and controls her identity. To create an account, the user generates and stores a Baby Jubjub keypair `(sk, PK)` locally on the device. The keypair manages the user's identity and authenticates the public records of associations between the account, credentials, external documents, and social graph artifacts. It is also used to derive the hierarchical randomness(so-called "salt") necessary for cryptographic commitments. | ||
|
|
||
| DApp developers can use the passport-derived profiles to: | ||
| - Restrict access for risky countries | ||
| - Set minimum age requirements | ||
| - Create provable social graph attestations | ||
| - Prevent Sybil attacks | ||
| - Verify personhood | ||
| - Any other use cases with selective disclosure of the passport data. | ||
|
|
||
| ## Biometric passports 101 | ||
|
|
||
| Biometric passports are familiar to any traveler. Currently, 172 nations issue ID documents compatible with the ICAO Machine Readable Travel Documents standard, making them one of the most widely used identity credentials worldwide. | ||
|
|
||
| Each biometric passport contains a *MRZ(Machine-Readable Zone)*. The MRZ includes an RFID chip that contains data for biometric verification, personal details, an expiration date, and the issuer's digital signature. | ||
|
|
||
| <IdealImage img={require('/img/biometric-passport-data.jpg')} alt="Biometric Passport Data Layout" /> | ||
|
|
||
| To check the validity of a passport, the verifier has to read the MRZ using an NFC scanner, verify the issuer's digital signature, and check the expiration date. | ||
|
|
||
| ## How it works | ||
|
|
||
| The passport-derived profiles solution consists of the following components: | ||
| - RariMe mobile apps are available for Android and iOS. They scan passports, securely store the passport data, and generate ZK proofs. | ||
| - A <OutLink href="https://github.com/rarimo/passport-zk-circuits/">set of Circom circuits</OutLink> designed to generate and verify zero-knowledge proofs of identity. | ||
| - A <OutLink href="https://github.com/rarimo/passport-contracts">set of smart contracts</OutLink> for managing the identity profile states. | ||
| - Rarimo's cross-chain messaging protocol propagates the identity states to other chains on demand. | ||
|
|
||
| Let's walk through the user flow and explore the inner workings of this solution. | ||
|
|
||
| <IdealImage img={require('/img/passport-full-flow.png')} alt="Passport-derived profiles flow" /> | ||
|
|
||
| ### Scanning the passport | ||
|
|
||
| To get started, the user must read the passport information using NFC. Under the hood, the reading process consists of the following steps: | ||
| 1. Receive the basic passport data from MRZ and generate authentication keys. | ||
| 1. Scan the data from the passport in encrypted form | ||
| 1. Decrypt and verify the data locally. | ||
| 1. Store the relevant passport data locally on the device. | ||
|
|
||
| <IdealImage img={require('/img/passport-scanning.png')} alt="Scanning the passport" /> | ||
|
|
||
| After verifying the passport validity, the device securely stores the following data locally: | ||
| - *DG1 Personal Details*. This section includes the passport holder's primary identity information, such as name, date of birth, nationality, and passport number. It reflects much of the information printed on the passport's data page. | ||
| - *DG2 Facial photograph*. This section contains the passport holder's portrait. In the future, the protection method based on it will be possible to extend with face recognition and ZKML proofs. | ||
| - *DG15: Active Authentication Public Key*. This includes the public key used for *Active Authentication(AA)*, a security feature preventing unauthorized copying of passport data. | ||
| - Hash values of other DGs. | ||
| - Issuer's signature. | ||
| - *Document Signer Certificate (CDS)*. | ||
|
|
||
| Let's note that the list of biometric data groups can be extended in the future (or for some countries). *DG2(Portrait)* is currently the most widespread biometrics in passports. | ||
|
|
||
| All actions within this process are performed locally, without access to the Internet. The certificate path can also be verified on the device if the application stores a set of valid certificates for Trust Anchors. No personal data is shared anywhere or accessible to outside parties. | ||
|
|
||
| ### Creating a passport-derived profile | ||
|
|
||
| Next, we create a passport-derived profile by following this protocol: | ||
| 1. The user generates the keypair `<sk, pk>` for identity management and `β = Hash(sk)` to blind personal data. | ||
| 1. The user signs `pk` with the passport signature `sig = sign(challenge, sk_pass)` by using passport active authentication and providing `Hash(pk)[:64]` as a challenge. | ||
| 1. The user generates a ZK `reg_proof` that `pk_pass` is a public key belonging to the passport (signed by a key from the ICAO list, without revealing the exact passport's issuer). | ||
| 1. The circuit calculates a commitment `DG_commit = Hash(DG1 || β)`. | ||
| 1. The user submits the registration data `<pk, pk_pass, sig, reg_proof>` to the registration relayer service, which then submits to the identity state contract on the Rarimo chain. | ||
|
|
||
| :::info | ||
| We use the registration relayer service instead of submitting the transaction directly to subsidize the gas fees for new users. | ||
| ::: | ||
|
|
||
| A link between the `pk` and `pk_pass` is saved in a leaf of a Sparse Merkle Tree in the identity state contract on the Rarimo chain. The leaf position and value are derived like this: | ||
| - Leaf position: `id_pos ← Hash(pk ∥ pk_pass)` | ||
| - Leaf value: `v ← Hash(id_pos, DG_commit)` | ||
|
|
||
| The user may try to create several profiles using different `pk` for the same passport, but the smart contract will reject these attempts. | ||
|
|
||
| <IdealImage img={require('/img/passport-profile-creation.png')} alt="Passport-derived profile creation" /> | ||
|
|
||
| Users may revoke or change the identity management keypair, but this operation requires a passport signature. | ||
|
|
||
| Additionally, the protocol allows the creation of periodic passport liveness commitments to prove passport ownership over a period of time. This is useful in use cases like voting, where a corrupt government may try to skew the results by issuing fake passports. The verifier application can set the time threshold to limit the impact of freshly printed documents on the final use case. | ||
|
|
||
| ### Generating zero-knowledge proofs of identity | ||
|
|
||
| The Passport Validity Circom circuit enables proving that the user owned a valid passport-derived profile at the specified time. Additionally, the circuit allows the user to prove that: | ||
| - The citizenship matches the provided allowlist. | ||
| - The expiration date of their passport is within some time bounds. | ||
| - The date of their birth is within some time bounds. | ||
| - Selectively disclose personal data from DG1 using a selector `Sel`. | ||
|
|
||
| When generating proof, the prover requests the historical state of the Identity Smart Contract. | ||
|
|
||
| <IdealImage img={require('/img/passport-proof-flow.png')} alt="Generating a proof of identity" /> | ||
|
|
||
| Selector `Sel` is used to selectively disclose personal information from a passport. Each private data signal is multiplied by a corresponding Sel bit. If the bit is 0, the data is blinded by multiplying it with 0. If the bit is 1, data is sent to the output signal without modifications. | ||
|
|
||
| <IdealImage img={require('/img/passport-proof-selector.png')} alt="Passport proof selector" /> | ||
|
|
||
| DApps can verify the proofs both on-chain and off-chain. Rarimo's on-demand identity state replication technology scales the usage of on-chain proofs to any EVM-compatible network. | ||
|
|
||
| ## Challenges and limitations | ||
|
|
||
| The first implementation of passport-derived profiles comes with some limitations: | ||
|
|
||
| - No biometric checks are included, meaning someone may scan a stolen or borrowed passport. ZKML solutions may alleviate this in the future. | ||
| - There's no way to prevent a holder of multiple passports from onboarding multiple times. | ||
| - Only passports that support Active Authentication are supported now. We're working on an MPC-based solution to circumvent this limitation. | ||
|
|
||
| <!-- Supported hashing algorithms? --> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,115 @@ | ||
| --- | ||
| slug: /accounts/zk-passport | ||
| description: ZK passport technology turn biometric passports into zero-knowledge identity credentials for Web3. | ||
| --- | ||
| import OutLink from "@site/src/components/OutLink"; | ||
| import IdealImage from '@site/src/components/IdealImage'; | ||
|
|
||
| # ZK Passport | ||
|
|
||
| Rarimo has developed a novel solution that turns a regular biometric passport into a flexible digital identity credential for Web3. Importantly, this is done without compromising the security of your sensitive data by using zero-knowledge proofs. | ||
|
|
||
| DApp developers can use the passport-derived profiles to: | ||
| - Restrict access for risky countries | ||
| - Set minimum age requirements | ||
| - Create provable social graph attestations | ||
| - Prevent Sybil attacks | ||
| - Verify personhood | ||
| - Any other use cases with selective disclosure of the passport data. | ||
|
|
||
| ## Biometric passports 101 | ||
|
|
||
| Biometric passports are familiar to any traveler. Currently, 172 nations issue ID documents compatible with the ICAO Machine Readable Travel Documents standard, making them one of the most widely used identity credentials worldwide. | ||
|
|
||
| Each biometric passport contains a *MRZ(Machine-Readable Zone)*. The MRZ includes an RFID chip that contains data for biometric verification, personal details, an expiration date, and the issuer's digital signature. | ||
|
|
||
| <IdealImage img={require('/img/biometric-passport-data.jpg')} alt="Biometric Passport Data Layout" /> | ||
|
|
||
| To check the validity of a passport, the verifier has to read the MRZ using an NFC scanner, verify the issuer's digital signature, and check the expiration date. | ||
|
|
||
| ## How it works | ||
|
|
||
| The passport-derived profiles solution consists of the following components: | ||
| - RariMe mobile apps are available for Android and iOS. They scan passports, securely store the passport data, and generate ZK proofs. | ||
| - A <OutLink href="https://github.com/rarimo/passport-zk-circuits/">set of Circom circuits</OutLink> designed to generate and verify zero-knowledge proofs of identity. | ||
| - A <OutLink href="https://github.com/rarimo/passport-contracts">set of smart contracts</OutLink> for managing the identity profile states. | ||
| - Rarimo's cross-chain messaging protocol propagates the identity states to other chains on demand. | ||
|
|
||
| Let's walk through the user flow and explore the inner workings of this solution. | ||
|
|
||
| <IdealImage img={require('/img/passport-full-flow.png')} alt="Passport-derived profiles flow" /> | ||
|
|
||
| ### Scanning the passport | ||
|
|
||
| To get started, the user must read the passport information using NFC. Under the hood, the reading process consists of the following steps: | ||
| 1. Receive the basic passport data from MRZ and generate authentication keys. | ||
| 1. Scan the data from the passport in encrypted form | ||
| 1. Decrypt and verify the data locally. | ||
| 1. Store the relevant passport data locally on the device. | ||
|
|
||
| <IdealImage img={require('/img/passport-scanning.png')} alt="Scanning the passport" /> | ||
|
|
||
| After verifying the passport validity, the device securely stores the following data locally: | ||
| - *DG1 Personal Details*. This section includes the passport holder's primary identity information, such as name, date of birth, nationality, and passport number. It reflects much of the information printed on the passport's data page. | ||
| - *DG2 Facial photograph*. This section contains the passport holder's portrait. In the future, the protection method based on it will be possible to extend with face recognition and ZKML proofs. | ||
| - *DG15: Active Authentication Public Key*. This includes the public key used for *Active Authentication(AA)*, a security feature preventing unauthorized copying of passport data. | ||
| - Hash values of other DGs. | ||
| - Issuer's signature. | ||
| - *Document Signer Certificate (CDS)*. | ||
|
|
||
| Let's note that the list of biometric data groups can be extended in the future (or for some countries). *DG2(Portrait)* is currently the most widespread biometrics in passports. | ||
|
|
||
| All actions within this process are performed locally, without access to the Internet. The certificate path can also be verified on the device if the application stores a set of valid certificates for Trust Anchors. No personal data is shared anywhere or accessible to outside parties. | ||
|
|
||
| ### Creating a passport-derived profile | ||
|
|
||
| Next, we create a passport-derived profile by following this protocol: | ||
| 1. The user generates the keypair `<sk, pk>` for identity management and `β = Hash(sk)` to blind personal data. | ||
| 1. The user signs `pk` with the passport signature `sig = sign(challenge, sk_pass)` by using passport active authentication and providing `Hash(pk)[:64]` as a challenge. | ||
| 1. The user generates a ZK `reg_proof` that `pk_pass` is a public key belonging to the passport (signed by a key from the ICAO list, without revealing the exact passport's issuer). | ||
| 1. The circuit calculates a commitment `DG_commit = Hash(DG1 || β)`. | ||
| 1. The user submits the registration data `<pk, pk_pass, sig, reg_proof>` to the registration relayer service, which then submits to the identity state contract on the Rarimo chain. | ||
|
|
||
| :::info | ||
| We use the registration relayer service instead of submitting the transaction directly to subsidize the gas fees for new users. | ||
| ::: | ||
|
|
||
| A link between the `pk` and `pk_pass` is saved in a leaf of a Sparse Merkle Tree in the identity state contract on the Rarimo chain. The leaf position and value are derived like this: | ||
| - Leaf position: `id_pos ← Hash(pk ∥ pk_pass)` | ||
| - Leaf value: `v ← Hash(id_pos, DG_commit)` | ||
|
|
||
| The user may try to create several profiles using different `pk` for the same passport, but the smart contract will reject these attempts. | ||
|
|
||
| <IdealImage img={require('/img/passport-profile-creation.png')} alt="Passport-derived profile creation" /> | ||
|
|
||
| Users may revoke or change the identity management keypair, but this operation requires a passport signature. | ||
|
|
||
| Additionally, the protocol allows the creation of periodic passport liveness commitments to prove passport ownership over a period of time. This is useful in use cases like voting, where a corrupt government may try to skew the results by issuing fake passports. The verifier application can set the time threshold to limit the impact of freshly printed documents on the final use case. | ||
|
|
||
| ### Generating zero-knowledge proofs of identity | ||
|
|
||
| The Passport Validity Circom circuit enables proving that the user owned a valid passport-derived profile at the specified time. Additionally, the circuit allows the user to prove that: | ||
| - The citizenship matches the provided allowlist. | ||
| - The expiration date of their passport is within some time bounds. | ||
| - The date of their birth is within some time bounds. | ||
| - Selectively disclose personal data from DG1 using a selector `Sel`. | ||
|
|
||
| When generating proof, the prover requests the historical state of the Identity Smart Contract. | ||
|
|
||
| <IdealImage img={require('/img/passport-proof-flow.png')} alt="Generating a proof of identity" /> | ||
|
|
||
| Selector `Sel` is used to selectively disclose personal information from a passport. Each private data signal is multiplied by a corresponding Sel bit. If the bit is 0, the data is blinded by multiplying it with 0. If the bit is 1, data is sent to the output signal without modifications. | ||
|
|
||
| <IdealImage img={require('/img/passport-proof-selector.png')} alt="Passport proof selector" /> | ||
|
|
||
| DApps can verify the proofs both on-chain and off-chain. Rarimo's on-demand identity state replication technology scales the usage of on-chain proofs to any EVM-compatible network. | ||
|
|
||
| ## Challenges and limitations | ||
|
|
||
| The first implementation of passport-derived profiles comes with some limitations: | ||
|
|
||
| - No biometric checks are included, meaning someone may scan a stolen or borrowed passport. ZKML solutions may alleviate this in the future. | ||
| - There's no way to prevent a holder of multiple passports from onboarding multiple times. | ||
| - Only passports that support Active Authentication are supported now. We're working on an MPC-based solution to circumvent this limitation. | ||
|
|
||
| <!-- Supported hashing algorithms? --> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters