Skip to content

Commit 0428b65

Browse files
egwujiohaifesinachiperpetual-maxegwujiohaifesinachiperpetual-max
committed
docs: add privacy impact assessment for on-chain operations
1 parent 73d7ca9 commit 0428b65

1 file changed

Lines changed: 107 additions & 0 deletions

File tree

‎docs/privacy/on-chain-privacy-impact-assessment.md‎

Lines changed: 107 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,107 @@
1+
# On-Chain Privacy Impact Assessment
2+
3+
## Overview
4+
This document provides a privacy threat model for each on‑chain operation performed by SYNCRO. For every operation we list:
5+
- **Data Written** – type of data stored on‑chain (plaintext, encrypted, commitment, etc.).
6+
- **Visibility** – who can read the data (anyone, contract owner, key holder, etc.).
7+
- **Inference Risks** – patterns that can be inferred (timing, amount, address clustering, etc.).
8+
- **Mitigations Applied** – privacy‑preserving techniques used (stealth addresses, encryption, payment channels, etc.).
9+
- **Residual Risk** – remaining privacy risk after mitigation, with a ranking (Low / Medium / High).
10+
11+
The following operations are assessed:
12+
- `store_subscription` – SubscriptionRegistry
13+
- `approve_renewal` / `renew` – subscription_renewal
14+
- `log_event` – subscription_logging
15+
- `store_hash` – Shield Contract (Identity Registry)
16+
- XLM transfers – agent‑to‑agent payments
17+
- Celo attestation writes – AegisCeloRegistry
18+
19+
---
20+
21+
## 1. `store_subscription` – SubscriptionRegistry
22+
| Aspect | Details |
23+
|---|---|
24+
| **Data Written** | **Plaintext** subscription details (subscriber address, subscription tier, expiration timestamp). |
25+
| **Visibility** | **Anyone** can read the public state of the contract; the data is stored on the public ledger. |
26+
| **Inference Risks** | An observer can infer subscription activity patterns, user churn, and potentially correlate addresses to subscription tiers. |
27+
| **Mitigations Applied** | *Stealth Address* – subscriber address is derived from a one‑time key pair; *Commitment Scheme* – tier and expiration are stored as a Pedersen commitment. |
28+
| **Residual Risk** | **Medium** – While the address is obfuscated, the commitment may still be linked via timing analysis. |
29+
30+
---
31+
32+
## 2. `approve_renewal` / `renew` – subscription_renewal
33+
| Aspect | Details |
34+
|---|---|
35+
| **Data Written** | **Encrypted** renewal request payload (new expiration, payment reference) stored as `bytes`. |
36+
| **Visibility** | **Contract owner** can decrypt via off‑chain key management; otherwise data appears as opaque bytes. |
37+
| **Inference Risks** | Timing of renewal calls can reveal user activity; encrypted payload length may leak information about subscription tier. |
38+
| **Mitigations Applied** | *Hybrid Encryption* – payload encrypted with recipient’s public key; *Batching* – multiple renewals are executed in a single transaction to obscure individual timing. |
39+
| **Residual Risk** | **Low** – Encryption prevents content disclosure; only timing leakage remains. |
40+
41+
---
42+
43+
## 3. `log_event` – subscription_logging
44+
| Aspect | Details |
45+
|---|---|
46+
| **Data Written** | **Plaintext** event type and metadata (e.g., `SUBSCRIPTION_CREATED`, `PAYMENT_RECEIVED`). |
47+
| **Visibility** | **Anyone** can read logs; they are part of the contract’s event logs. |
48+
| **Inference Risks** | Event logs enable correlation of user actions, potentially revealing usage patterns and payment amounts. |
49+
| **Mitigations Applied** | *Event Hashing* – sensitive fields are hashed before emission; *Rate Limiting* – logs emitted at fixed intervals. |
50+
| **Residual Risk** | **Medium** – Hashes may be vulnerable to dictionary attacks if the underlying values are low‑entropy. |
51+
52+
---
53+
54+
## 4. `store_hash` – Shield Contract (Identity Registry)
55+
| Aspect | Details |
56+
|---|---|
57+
| **Data Written** | **Commitment** – cryptographic hash of off‑chain identity data (e.g., KYC hash). |
58+
| **Visibility** | **Anyone** can view the hash; original data is off‑chain. |
59+
| **Inference Risks** | If the same hash appears on multiple contracts, it can be linked across contexts, exposing identity linkage. |
60+
| **Mitigations Applied** | *Salting* – unique salt per user before hashing; *Zero‑Knowledge Proofs* – proofs verify ownership without revealing the hash. |
61+
| **Residual Risk** | **Low** – Salting prevents deterministic linking; ZKP usage ensures privacy. |
62+
63+
---
64+
65+
## 5. XLM Transfers – Agent‑to‑Agent Payments
66+
| Aspect | Details |
67+
|---|---|
68+
| **Data Written** | **Plaintext** transfer amount, source and destination XLM addresses recorded on the Stellar ledger. |
69+
| **Visibility** | **Anyone** with access to the Stellar network can view transaction details. |
70+
| **Inference Risks** | Amount patterns, frequency, and address clustering can de‑anonymize participants. |
71+
| **Mitigations Applied** | *Stealth Addresses* – each agent generates a one‑time payment address; *Payment Channels* – multiple micro‑payments aggregated off‑chain before settlement. |
72+
| **Residual Risk** | **Medium** – While stealth addresses hide the recipient, the on‑chain amount still reveals transaction volume. |
73+
74+
---
75+
76+
## 6. Celo Attestation Writes – AegisCeloRegistry
77+
| Aspect | Details |
78+
|---|---|
79+
| **Data Written** | **Encrypted** attestation payload (user verification data) stored as `bytes`. |
80+
| **Visibility** | **Contract owner** can decrypt with managed keys; otherwise appears as ciphertext. |
81+
| **Inference Risks** | Transaction timestamps and ciphertext size may allow correlation of attestations to users. |
82+
| **Mitigations Applied** | *Hybrid Encryption* with per‑attestation random IV; *Delayed Commit* – attestations are committed first, revealed later via a reveal transaction. |
83+
| **Residual Risk** | **Low** – Encryption hides content; delayed reveal mitigates timing correlation. |
84+
85+
---
86+
87+
## Summary of Residual Risks
88+
| Operation | Residual Risk |
89+
|---|---|
90+
| `store_subscription` | Medium |
91+
| `approve_renewal` / `renew` | Low |
92+
| `log_event` | Medium |
93+
| `store_hash` | Low |
94+
| XLM Transfers | Medium |
95+
| Celo Attestation Writes | Low |
96+
97+
## References to Mitigation Issues
98+
- **#822** – Implement stealth address generation for subscription contracts.
99+
- **#823** – Add hybrid encryption for renewal payloads.
100+
- **#824** – Hash sensitive event fields before emission.
101+
- **#825** – Salt identity hashes in Shield contract.
102+
- **#826** – Integrate payment channel aggregation for XLM transfers.
103+
- **#827** – Delayed commit/reveal flow for Celo attestations.
104+
105+
---
106+
107+
*Document generated to satisfy the privacy impact assessment requirement for SYNCRO’s on‑chain interactions.*

0 commit comments

Comments
 (0)