Threat Model

Date: 2026-02-09 Version: 1.0.0 Status: Production

1. System Overview

zk-id is a zero-knowledge proof system for selective disclosure of identity credentials. The system operates across three roles:

┌─────────┐           ┌─────────┐           ┌──────────┐
│ Issuer  │──(sign)──>│ Holder  │──(prove)─>│ Verifier │
└─────────┘           └─────────┘           └──────────┘

Issuer → Issues signed credentials containing birth year, nationality, and a random salt bound by Poseidon hash commitment.

Holder → Stores credentials locally, generates zero-knowledge proofs using Groth16 SNARKs to prove properties (e.g., age ≥ 18) without revealing the underlying data.

Verifier → Validates proofs cryptographically, enforces server-side policies, and maintains replay/revocation protection.

2. Trust Assumptions

The security of zk-id depends on the following trust assumptions:

2.1 Cryptographic Assumptions

• Circuit correctness: The circom circuits (age-verify, nationality-verify, etc.) correctly encode the intended constraints. Malformed circuits could allow proof forgery.
• Trusted setup integrity: The Groth16 Powers of Tau ceremony (Hermez, 177 participants) generated proving/verification keys without toxic waste retention. Compromised setup keys enable arbitrary proof generation.
• Poseidon collision resistance: The Poseidon hash (BN128, t=3/4) is collision-resistant. Collisions would allow credential forgery.
• EdDSA signature security: BabyJubJub EdDSA (in-circuit) and Ed25519 (off-chain) are unforgeable under chosen-message attacks.
• BN128 discrete log hardness: The elliptic curve discrete logarithm problem on BN128 is computationally infeasible (~128-bit security).

2.2 System Assumptions

• Issuer key security: Issuer private keys are stored securely (HSM recommended). Compromised keys allow arbitrary credential issuance.
• Verification key distribution: Verification keys (.zkey) are distributed through trusted channels. Tampered keys could validate invalid proofs.
• CSPRNG quality: crypto.randomBytes() (Node.js) provides cryptographically secure randomness for salts, nonces, and keys on all platforms (Linux: /dev/urandom, macOS: arc4random_buf, Windows: BCryptGenRandom).
• Circuit artifact integrity: SHA-256 hashes in docs/circuit-hashes.json match deployed artifacts. Hash mismatches indicate tampering or build drift.

2.3 Operational Assumptions

• Holder environment: Proofs are generated in a trusted client environment. Malware on the prover’s device could exfiltrate credentials.
• Server time synchronization: Verifiers maintain accurate clocks. Large clock skew enables time-shifted proof attacks (mitigated by maxFutureSkewMs).
• Audit log integrity: Audit logs are tamper-evident or write-only (e.g., append-only S3, Elasticsearch with WORM). Log deletion could hide attacks.

3. Threat Actors

4. Attack Surface

4.1 Malicious Prover Attacks

4.2 Malicious Verifier Attacks

4.3 Compromised Issuer Attacks

4.4 Network Attacker Attacks

4.5 Colluding Parties

5. Cryptographic Assumptions

6. Metadata Leakage

6.1 What a Verifier Learns

Even with zero-knowledge proofs, verifiers inevitably learn:

6.2 Pseudonymity via Nullifiers

• Nullifiers (Poseidon(commitment, scopeHash)) create per-scope pseudonyms.
• Example: Alice proves age ≥18 at example.com twice → same nullifier both times.
• Cross-site tracking requires colluding verifiers sharing nullifiers (not prevented).

7. Known Limitations

8. Mitigations Summary

9. Recommendations for Deployment

9.1 Mandatory Security Controls

1. Use TLS 1.3+ for all API endpoints (reverse proxy termination recommended).
2. Persistent nonce store (Redis with TTL) to prevent replay across restarts.
3. Authenticated rate limiting (token bucket per session ID, not IP).
4. Set verboseErrors: false to prevent information leakage to attackers.
5. Configure maxRequestAgeMs (e.g., 5 minutes) to reject stale proofs.
6. Enable audit logging with tamper-evident storage (write-only S3, Elasticsearch WORM).

9.2 Recommended Security Controls

1. HSM/KMS for issuer keys (AWS KMS, Azure Key Vault, HashiCorp Vault).
2. Strict protocol version enforcement (protocolVersionPolicy: 'strict').
3. Revocation root staleness checks (maxRevocationRootAgeMs: 300000 = 5 minutes).
4. NTP clock synchronization for accurate timestamp validation.
5. Circuit artifact verification (npm run verify-circuits) in CI/CD pipeline.

10. Out of Scope

The following are explicitly not addressed by this system and require external controls:

• Secure key management (HSM/KMS integration)
• Full anonymity network protections (Tor, VPN, traffic obfuscation)
• Side-channel resistance in client environments (timing attacks, memory scraping)
• Data retention and GDPR compliance (log lifecycle policies)
• Physical security of issuer infrastructure
• Social engineering (phishing for credentials)

11. Audit Recommendations

For third-party security audits, prioritize:

1. Circuit constraint completeness — verify all signals used in output are properly constrained (no under-constrained paths).
2. Poseidon parameter verification — confirm canonical parameters for BN128.
3. Nonce/timestamp binding — ensure proof public signals match request nonce/timestamp.
4. Replay protection robustness — test nonce store persistence, TTL expiry, and cross-instance synchronization.
5. Error sanitization — verify verboseErrors: false does not leak internal state.
6. Rate limiting bypass — test IP rotation, proxy evasion, and session forgery.

12. References

• Protocol documentation: docs/PROTOCOL.md
• Circuit complexity metrics: docs/CIRCUIT-COMPLEXITY.md
• Cryptographic parameters: docs/CRYPTOGRAPHIC-PARAMETERS.md
• Trusted setup ceremony: docs/TRUSTED-SETUP.md
• Security policy: SECURITY.md
• Audit checklist: docs/AUDIT.md

Last updated: 2026-02-09 Reviewed by: Claude Sonnet 4.5 (zk-id v1.0.0 release preparation)