# Rarimo Audit

Original checklist link: https://hackmd.io/2IRrRsLcQyKo1XOwAFABBA
Rarimo github: https://github.com/rarimo
Contact peers: @kitty_jenny_h (TG)

Existing security audits: https://docs.rarimo.com/resources/audits/

Inscope applications/servers:

- FreedomTool
- ZK Passport
- ZK Registry
- Front-end ([rarimo.com](https://rarimo.com))
- 
- Hosted by google
- 
- Analytics by google analytics
- Docs ([docs.rarimo.com](https://docs.rarimo.com)))
-

- Android application: [RariMe](https://play.google.com/store/apps/developer?id=Rarilabs&hl=en)
- ios Application: [Rarime](https://apps.apple.com/us/developer/rarilabs-inc/id1748828640)
- [Email server (Google Suite](https://www.whatsmydns.net/dns-lookup?query=rarimo.com&server=opendns))
- 

## Report outline

Introduction
Conclusion
Summary of information
Recommendations
Data obtained through checklist

## Questions asked and waiting for feedback:

- Internal policies in place to deal with privacy or data breaches (data leaks, hacks, etc.)
- Contact with your DPO
- Contact with (if any) compliance team
- Server locations, labeled with what kind of data is stored (ex: CRM system, salesforce, hosted in NA, b2b client information)
- List of analytical tooling used and where (front-end, mobile app, etc,)
- Data governance structure
- Your privacy policy
- (if any) Types of sensitive data that might be processed (KYC, passport data, biometrics, health, financial,..)
- 3rd party systems your system interacts with

# Research

### 1.1 Data Collection and Processing (Answered by Rarimo)

- [x] What types of personal data are collected (both off-chain and on-chain)?
- All personal data remains solely on the user's device. The passport hash and public key are published on-chain. Off-chain processing involves the verification of ZKP in the following cases: proof of citizenship (indicating that citizenship information is shared) and proof of adulthood (indicating only that the individual is 18+ without disclosing the actual age).
- We may process, and do process, only the data that the user voluntarily provides in communications with us (for example, when the user ask some assistance or support). We do not have any access to the personal data of the user, contained in their passport or other identification documents.
This is explicitly outlined in our Privacy Notice: https://rarime.com/privacy-notice.html
- [x] Is the collection of each data point necessary and justified?
- **yes**
- [x] How is data collected? (e.g., forms, cookies, logs, third-party sources, blockchain transactions)
- In the case of data processed within the application, the user explicitly approves their registration in the RariMe app and consents to each proof request (such as proof of adulthood).
- In the case of data processed by us, the user voluntarily provides their data as part of their request.
- [x] Is there a clear and accessible privacy policy?

- yes, the link is provided above. 

- [x] Are data subjects informed about the collection and its purposes?

- yes, in the Privacy Notice. 

- [x] Is consent obtained where necessary, and is it specific and informed for both off-chain and on-chain data processing?
- yes
- [x] Are there mechanisms in place to minimize on-chain data storage?

It should be stressed that the user's personal data is stored on the user's device off-chain, but the general mechanism of minimalization is described in Section 2 of the Privacy Policy.

*note by mf: section 2 below*
> 2. PERSONAL INFORMATION PROCESSED IN
> APPLICATION AND PERSONAL INFORMATION WE COLLECT OR PROCESS.
>
> The categories of personal information we collect depend on
> how you interact with us,
> our Services,
> and requirements of applicable law.
>
> We collect and process information that you provide to us
> and information from other sources, as described below.

- [x] How is data collected through smart contract interactions handled and processed?
- to verify such proofs as proof-of-citizenship or  proof-of-adultness we need only SMT root from on-chain.

---
*Review of Mf*

There seems toe somehow google analytics also involved in their main website. I still need to double check how far their privacy policy has been transparent with that.
- 
- Analytics by google analytics

### 1.2 Data Storage and Security (answered by rarimo)

- [x] Where and how is personal data stored (including on-chain, off-chain, and hybrid approaches)?

Off-chain data is stored on the user’s device, and no data is stored on-chain.

- [x] What security measures are in place to protect the data in all storage locations?

data is encrypted on user’s device

- [x] Is data encrypted at rest and in transit?

yes

- [x] Are there access controls and authentication mechanisms in place for both traditional systems and blockchain nodes?

yes

- [x] Is there a data retention policy is it enforced?

yes

- [x] Are there procedures for secure data destruction or obfuscation, considering the immutability of blockchain data?

yes

- [x] How is off-chain data secured and linked to on-chain identifiers?

Only the passport hash and public key are on-chain, which may not be linked to a specific user. Off-chain data, as mentioned above, exists only on the user’s device.

- [x] What measures are in place to protect private keys and other cryptographic materials?

private key is stored in secure keychain on chip

### 1.3 User Rights and Control

- [x] Can users access their personal data easily?

As you may remember, the data is stored only on the user's device. In the case of data provided in communication with us, users have the right to access it as per our privacy policy.

- [x] Is there a process for users to request data correction or deletion?

As you may remember, the data is stored only on the user's device. In the case of data provided in communication with us, users have the right to request the correction deletion as per our privacy policy.

- [x] Can users opt-out of certain data processing activities?

As mentioned above, the only data we may theoretically process is the data provided in communication with us (all other data is stored on the user’s device). In the case of data provided in communication with us, users have the right to opt out of certain processing activities.

- [x] How are data subject requests handled and tracked across all systems?

The largest and most crucial part of the data is stored on the user’s device. In the case of data provided in communication with us (the only data which we may process), users have the right to request any information using the contact details provided in the privacy policy.

- [x] Are there options for users to participate in the network without revealing personal information?

No personal data is revealed except in cases of communication with us. Yes, the user may choose not to communicate with us or may refrain from providing any personal data in communication. In such a case, the user can participate in the network without revealing any personal data.

### 1.4 Data Breach Response

- [x] Is there a data breach response plan in place?

The largest and most crucial part of the data is stored on the user’s device. But regarding the data provided by the user in communication with us, yes, we have such plan.

- [x] Are there procedures for detecting and reporting breaches, including smart contract vulnerabilities?

Yes, but the largest and most crucial part of the data is stored on the user’s device.

- [x] Is there a process for notifying affected individuals and authorities in case of a breach?

Yes, but the largest and most crucial part of the data is stored on the user’s device.

- [x] Are post-breach reviews conducted to prevent future incidents?

Yes, but the largest and most crucial part of the data is stored on the user’s device.

### 1.5 Employee Training and Awareness

- [x] Are employees trained on privacy policies and procedures, including blockchain-specific privacy considerations?

Yes, we have knowledge sharing and extensive code reviews in place

- [x] Is there regular privacy awareness training that covers both traditional and blockchain-related privacy issues?

Yes, we have weekly knowledge sharing sessions focusing on blockchain privacy, cryptography, ZK proofs, and more

- [x] Are there consequences for privacy policy violations by employees?

Yes, disciplinary actions may be taken in cases of malicious behavior or negligence that result in privacy policy violations.

- [x] Do developers receive specialized training on privacy-preserving development practices?

Yes, have internal courses focusing on cryptography and ZK proofs

### 1.6 Special Categories of Data

- [x] Is any sensitive data (e.g., KYC, health, biometric, financial) collected or processed?

Biometric passport data is collected by the RariMe App but never leaves user’s device.

- [x] Are there additional safeguards in place for sensitive data across all systems?

This question is non-applicable to us.

- [x] Is the processing of sensitive data compliant with relevant regulations, considering both traditional and blockchain contexts?

Only ZK Proofs and highly anonymized identifiers(nullifiers) are shared with the outside world to ensure compliance with GDPR and similar laws.

- [x] Are there specific measures to protect sensitive data in smart contract interactions?

Use of ZK proofs

### 1.7 International Data Transfers

- [x] Are there any cross-border data transfers?

As per our practice - we do not share the personal data with third parties. Even if the user provides us with its personal data in communication with us, such data is stored on our side. As an example, we may share the user's feedback with third party (our service provider), but such feedback will be anonymized and, therefore, will not contain personal data.

- [x] What mechanisms are in place to ensure compliance with international data transfer regulations for both traditional and blockchain-based transfers?

As per our practice - we do not share the personal data with third parties. Even if the user provides us with its personal data in communication with us, such data is stored on our side. As an example, we may share the user's feedback with third party (our service provider), but such feedback will be anonymized and, therefore, will not contain personal data.

- [x] Are data subjects informed about international transfers, including those inherent in blockchain operations?

Not applicable since there are no such transfers

- [x] How is compliance ensured when node operators are located in different jurisdictions?

No private data leaves user’s device by design

### 1.8 Privacy by Design and Default

- [x] Is privacy considered in the early stages of product/service development, including blockchain implementations?

Yes, privacy is the main focus of the project

- [x] Are data minimization principles applied across all systems?

Yes

- [x] Are privacy-enhancing technologies utilized where appropriate, including blockchain-specific solutions (e.g., zero-knowledge proofs, ring signatures)?

Yes, client side proving is the only supported way of interacting with external systems

- [x] How is privacy incorporated into the design of smart contracts and decentralized applications (dApps)?

No private data is handled on smart contracts or off-chain(outside of user’s device). Only a Sparse Merkle Tree of highly anonymized identifiers(hashes) and nullifiers are stored on-chain.

### 1.9 Ongoing Compliance and Monitoring

- [x] Is there a process for staying updated on privacy laws and regulations?

Yes, our legal team monitors the regulations on an ongoing basis and regularly updates our processes accordingly.

- [x] Are regular privacy impact assessments conducted?

Yes, this is responsibility of our legal team

- [x] Is there a system for monitoring and auditing privacy practices across all platforms?

Not applicable because only ZK proofs are shared with the external parties

## Blockchain-Specific Privacy Considerations

### 2.1 Smart Contracts

- [x] Do smart contracts handle personal data?

**No**

- [x] Are there privacy-preserving computation methods implemented (e.g., ZKPs, MPC)?

**Yes, ZKP**

- [x] How are smart contract upgrades managed to address privacy concerns?

As you may remember, the smart contract does not handle personal data, but we use Gnosis Safe to monitor upgradability.

- [x] Is there a process for auditing smart contracts for privacy vulnerabilities?

**Yes, we are requesting an audit from companies (such as Halborn) when releasing a major version**

- [x] How is data access controlled within smart contracts?

ZK Registry is permissionless and data control is managed by users via self attestation via ZKP, but smart contract itself does not handle with personal data

### 2.2 Node Operations

- [x] What data is collected and stored by nodes?

EVM transactions and state of the ZK Rollup

- [x] How is node communication secured?

Traffic between the nodes is public because we rely on ZK proofs for privacy

- [x] Are there privacy-preserving networking protocols in use (e.g., Tor, I2P)?

There is no need to use such instruments in our case

- [x] How are node operators vetted and monitored for compliance with privacy standards?

There is no need to monitor them because they do not handle with personal data

- [x] What measures are in place to prevent deanonymization through network analysis?

Traffic between the nodes is public because we rely on ZK proofs for privacy

### 2.3 Blockchain-Specific User Identity and Authentication

- [x] How are user identities managed on the blockchain?

We want to emphasize that, in fact, identities are not managed on the blockchain; they are managed by the user on their device. We implement a permissionless self-issuance process, where users manage their identity by submitting a client-side generated ZK proof of identity (e.g., proof of biometric passport validity).

- [x] What KYC/AML processes are in place, and how is this data handled in the blockchain context?

We don’t have KYC/AML in place because we don’t deal with financial transactions

- [x] Are there decentralized identity solutions implemented?

Yes, Rarimo’s core product are permissionless ZK Identity Registries: https://docs.rarimo.com/zk-registry/

- [x] How is the principle of pseudonymity balanced with regulatory requirements?

Rarimo uses highly anonymized nullifiers to implement uniqueness checks, there are no other instances of pseudonymous data used

- [x] What measures are in place to prevent the linking of multiple addresses to a single identity?

Once an identity is added to a ZK Registry, it’s impossible to track it’s uses because we utilize SMT inclusion proofs

### 2.4 Cross-chain Interactions

- [x] How is privacy maintained in cross-chain transactions or data sharing?

No private data exchanged on or offchain, only privacy preserving ZK Proofs

- [x] Are there privacy risks in bridge protocols or layer-2 solutions?

No

- [x] What measures are in place to ensure consistent privacy standards across different chains?

No special measures needed by design

- [x] How are privacy policies communicated and enforced in cross-chain operations?

Not necessary because only ZK Proofs shared

### 2.5 Blockchain Governance and Transparency

- [x] How are privacy-related decisions made in the blockchain ecosystem?

Privacy and permissionlessness are core values of our project that govern all our decisions

- [x] Is there transparency in the handling of privacy issues and upgrades specific to the blockchain implementation?

Rationale behind all the privacy-related decisions is clearly communicated in the documents of the relevant project

- [x] How are conflicts between transparency and privacy resolved in the governance process?

Privacy is always the top priority

- [x] What role do token holders or other stakeholders play in privacy-related decision making?

There’s no governance mechanism at the moment in this specific case, but we’re planning to employ Gnosis Safe in the future

- [x] How are privacy considerations incorporated into the consensus mechanism?

There’s no private data on-chain, but we went with a ZK Rollup design because it resonates with our values.

### 2.6 Scalability and Privacy

- [x] How do scalability solutions (e.g., sharding, sidechains) impact privacy?

They have no effect since only SMT roots of the ZK Registries are replicated across the chains

- [x] Are there trade-offs between transaction throughput and privacy preservation?

There are no such trade-offs

- [x] How is data privacy maintained in layer-2 scaling solutions?

Through the use of ZK proofs, same as for the L1s

### 2.7 Interoperability and Privacy

- [x] How is privacy preserved when interacting with traditional financial systems or other blockchains?

Only ZK proofs of identity are shared with external systems

- [x] What standards or protocols are used to ensure privacy in interoperable systems?

ZK-SNARKs using Groth16 proving system

- [x] How are privacy policies aligned across different interoperable platforms?

Not necessary, because only ZK proofs of identity are shared with external systems

## by ngerarld (to be merged with rarimo notes)

### 1.1 Data Collection and Processing

- [ ] What types of personal data are collected (both off-chain and on-chain)?

Personal information stays on your phone only. The system only puts a passport hash and a public key on the blockchain. When verification happens off the blockchain, it only confirms two things:

- Whether you're a citizen (if you choose to share this)
- Whether you're over 18 (without revealing your exact age)

Rarimo only processes information you voluntarily share with them. And do not have any access to the personal date of the user, contained in their passport or other identification documents.

Off-Chain Data Collection
Provided Information (collected by Rarilabs directly, according to privacy policy)

* Contact information when communicating with Rarilabs (email, phone number, mailing address)
* Information submitted through surveys
* Information shared through interactive features, forums, blogs, or social media
* Information provided for sweepstakes/contests participation
* Information collected at conferences, trade shows, and events
* Business development and partnership-related information

Automatically Collected Information

* IP address
* User settings
* MAC address
* Cookie identifiers
* Mobile carrier
* Unique identifiers
* Browser/device information
* Approximate location (derived from IP address)
* Analytics data through tools like Google Analytics

Information From Other Sources

* Contact information from referral services

Information Collected When Downloading the Application
Collected by app store providers (Google Play or App Store):

* Username
* Email address
* Customer number
* Time of download
* Payment information (if applicable)
* Individual device identification number

On-Chain/Application Data (Eligibility Information)
The policy emphasizes that this information is processed solely on users' devices and not accessed by Rarilabs:
* Digital Identity Components

The policy strongly emphasizes that the Eligibility Information is only processed on users' devices, with Rarilabs having no access to this information. It states: "IN NO EVENT DOES RARILABS COLLECT, PROCESS, USE, SHARE OR STORE ANY ELIGIBILITY INFORMATION."

- Anonymized verifiable credential containing hashed versions of:
(hash of the user's Identifying Document)

* Full name
* Citizenship
* Sex
* Date of birth
* Number of the Identifying Document
* Date of expiry of the Identifying Document

Blockchain Information

* Digital Assets Wallet address
* On-chain activities
* Interactions with the Services

- [x] Is the collection of each data point necessary and justified?
- No, Although Rarime’s data collection aligns with standard practices for SaaS platforms, with purposes tied to security, functionality, and service improvement. Users should remain vigilant about optional data sharing and utilize provided controls to manage preferences.

**Potential Concerns:**
If geolocation or other sensitive data is collected without a clear need, it would lack justification. The notice does not explicitly mention this, suggesting compliance.

Third-Party Risks: While sharing data with partners is common, audits or disclosures about vendor compliance would strengthen justification.

Data Minimization: The service should collect only what is strictly necessary for decentralized identity management, avoiding excessive or irrelevant data. They could and should offer anonymous options whenever possible (e.g., aggregating IP addresses).

- [x] How is data collected? (e.g., forms, cookies, logs, third-party sources, blockchain transactions)

- In the case of data processed within their application, the user explicitly approves their registration in the RariMe app and consents to each proof request (such as proof of adulthood).

- In the case of data processed by Rarimo, the user voluntarily provides their data as part of their request.

- [x] Is there a clear and accessible privacy policy?
- Not really only its only stated for Rarime privacy policy(https://rarime.com/privacy-notice.html)

- [x] Are data subjects informed about the collection and its purposes?
- Data subjects (users) are well-informed about data collection and its purposes in the RariMe privacy policy:

Clear Collection Notification: The policy explicitly states what personal information is collected, including:

* Information processed in the Application (Eligibility Information)
* Information provided directly by users (Provided Information)
* Information collected automatically
* Information from other sources
*

Purpose Specification: The policy details how personal information is used, including:

* To provide services
* For administrative purposes
* With user consent for other disclosed purpose

- [x] Is consent obtained where necessary, and is it specific and informed for both off-chain and on-chain data processing?

For off-chain data:

The policy states: "With Your Consent. We may use personal information for other purposes that are clearly disclosed to you at the time you provide personal information or with your consent."
It outlines users' "Right to withdraw consent: you have the right to withdraw your consent at any time."
For email communications, text messages, and phone calls, the policy explains opt-out mechanisms.

For on-chain data and Application processing:

The policy explains that users' Digital Identity includes anonymized identifiers and credentials.
It clearly states that "THE ELIGIBILITY INFORMATION IS COLLECTED, PROCESSED, USED AND STORED SOLELY ON THE USER'S DEVICES... WITHOUT ANY INVOLVEMENT OF RARILABS."
The policy explains that when users create a Digital Identity, they are voluntarily providing their information within the application.
When users choose to prove statements about their identity to third parties, the policy explains exactly what limited data is shared through zero-knowledge proofs.

The policy makes clear distinctions between different types of data processing:

Eligibility Information processed solely on user devices
Provided Information that users actively share
Automatically collected information (like IP addresses)

For each category, the policy explains the legal basis for processing, which includes:

Consent (Article 6(1)(a) GDPR)
Performance of a contract (Article 6(1)(b) GDPR)
Legitimate interests (Article 6(1)(f) GDPR)

- [ ] Are there mechanisms in place to minimize on-chain data storage?

For third-party verification processes, the application generates a new ZKP proving the user has the Digital Identity, disclosing only the proof to the verifier without revealing personal information.

Zero-Knowledge Proofs (ZKPs) – The application uses zero-knowledge cryptography to verify identity-related claims without exposing the underlying data. This ensures that personal data is not stored on-chain, only anonymized proofs.

Processing on User’s Device – Eligibility Information (e.g., identifying documents) is collected, processed, used, and stored solely on the user’s device and is not shared with Rarilabs or third parties.

Anonymized Identifiers – The Digital Identity (DI) is created using hashed versions of identifying documents and credentials, which are further anonymized through cryptographic methods, preventing direct association with an individual.

Metadata Exposure Only – Third parties can only access limited metadata (e.g., proof-of-citizenship, proof-of-adultness) through verifiable credentials but not the original personal data.

Minimal Collection Policy – Rarilabs explicitly states that it collects and stores only the minimum personal information necessary to provide services, avoiding direct storage of sensitive user data.

- [ ] How is data collected through smart contract interactions handled and processed?

State Management: The StateKeeper contract acts as a singleton state instance, storing and managing critical data. It maintains

* A Sparse Merkle Tree with registered identities

* A Sparse Merkle Tree with registered certificates of ICAO members

* Passport and identity information

* "Passport <> Identity" bonds

In order to verify proofs as proof-of-citizenship or proof-of-adultness they would need only SMT root from on-chain.

### 1.2 Data Sharing and Third Parties

- [ ] Is personal data shared with third parties? If so, with whom and for what purposes?

Since all personal data is stored on user device hence Rarilabs dun even have user personal data to begin with

As per Rarilabs practice - they do not share the personal data with third parties. Even if the user provides them with its personal data in communication with us, such data is stored on our side. As an example, they may share the user's feedback with third party (our service provider), but such feedback will be anonymized and, therefore, will not contain personal data.

According to their privacy policy
Only shared to the extent necessary for optimal service provision

Sharing with Business Partners

Purpose:

* Provide requested products or services
* Jointly offer products or services

Specific Disclosure Scenarios:

* To comply with law enforcement or legal requests
* Protect rights, property, or safety
* In event of merger, acquisition, or asset transfers
* To enforce policies or contracts
* Assist with investigations

Rarilabs emphasizes that they collect and processes the minimum amount of personal information needed to provide services. The company is particularly careful about "Eligibility Information", which is processed solely on the user's device using zero-knowledge proofs and is not accessible to Rarilabs.

The legal basis for these data sharing activities is typically:

* Performance of a contract
* Legitimate business interests
* Compliance with legal obligations

- [ ] Are there data processing agreements in place with third parties, including smart contract interactions?

The document states that for data transfers to third parties, Rarilabs ensures compliance with legal requirements through:

Choosing companies certified under Privacy Framework agreements
Using standard contractual clauses (as referenced in Article 46(2)(c) of the GDPR)

Specifically for international data transfers (especially to the United States), the notice indicates that Rarilabs will:

Ensure adequate data protection through:

* Companies certified under Privacy Framework agreements
* Contractual arrangements with third-party service providers
* Additional appropriate safeguards if necessary

- [ ] How is data protected during transfer to third parties?

As mentioned above, they do not share personal data with third parties.

---
*NOTE
**note mf: This is false by the logic of google analytics being there. Needs further research in other claims***

---

- [ ] Is there a process for vetting and auditing third-party data handlers?

Team confirms that there are no such third-party data handlers in their case.

- [ ] How is privacy maintained in cross-chain transactions or data sharing?

The Privacy Notice does not provide specific details about privacy maintenance in cross-chain transactions or data sharing. However according to the team, all data sharing is done using privacy preserving ZK Proofs

Privacy Mechanisms:

Zero-knowledge cryptography is used to prove identity statements without exposing personal information
Digital Identity (DI) is anonymized using zero-knowledge proofs
Users can prove specific statements about their identity without revealing underlying personal details

Specific Provable Statements Include:

* Proof-of-citizenship (country of citizenship)
* Proof-of-adultness (over 18 or age of majority)
* Proof-of-uniqueness (using an anonymized distinguisher)

While these mechanisms suggest a privacy-focused approach, the document does not explicitly address cross-chain transaction privacy or elaborate on data sharing across blockchain networks.

### 2.1 Smart Contracts

- [x] Do smart contracts handle personal data?

Encryption: Rarimo encrypts personal data on-chain using industry-standard algorithms, ensuring that only authorized participants can access the data with decryption keys provided through off-chain channels.

- [x] Are there privacy-preserving computation methods implemented (e.g., ZKPs, MPC)?

Zero-Knowledge Proofs (ZKPs): The system utilizes ZKPs during the registration process to validate user-provided data without compromising privacy.

- [x] How are smart contract upgrades managed to address privacy concerns?
Gnosis safe is used to manage upgradability.

- [x] Is there a process for auditing smart contracts for privacy vulnerabilities?
Yes, they requested an audit from companies (such as Halborn) when releasing a major version

- [x] How is data access controlled within smart contracts?
Zk registry is permissionless and data control is managed by users via self attestation via ZKP

## Out of scope information

### ~~2.2 Node Operations~~

- [ ] What data is collected and stored by nodes?
- [ ] How is node communication secured?
- [ ] Are there privacy-preserving networking protocols in use (e.g., Tor, I2P)?
- [ ] How are node operators vetted and monitored for compliance with privacy standards?
- [ ] What measures are in place to prevent deanonymization through network analysis?