Security Model

ZKVAULT's security model encompasses cryptographic guarantees, threat modeling, and defense-in-depth strategies to ensure the integrity and confidentiality of zero-knowledge proofs.

Cryptographic Security Guarantees

Soundness

Definition: A malicious prover cannot convince a verifier of a false statement.

Soundness Error: ε ≤ 2^-128

Meaning: The probability of accepting an invalid proof is negligible
• Computational assumption: Discrete logarithm problem hardness on BN254
• Security parameter: 128-bit security level
• Trusted setup: Powers of tau ceremony with 100+ participants

Attack scenario prevented:
• Attacker cannot forge proof for "x = 5" when actual value is "x = 7"
• Invalid witness rejection: 100% (deterministic)
• Malformed proof detection: 100% (structural validation)

Zero-Knowledge Property

Definition: Proofs reveal nothing about private inputs beyond statement validity.

Zero-Knowledge Guarantee:
• Simulator S can produce indistinguishable proofs without witness
• No information leakage: I(proof; private_inputs) = 0 bits
• Perfect zero-knowledge: Statistical indistinguishability

Proof:
Given proof π, public inputs x, and statement "∃w: C(x,w) = true"
• Simulator generates π' without knowing w
• π and π' are computationally indistinguishable
• Therefore, π reveals nothing about w

Protected information:
✓ Vote choices in private voting
✓ Account balances in private DeFi
✓ Secret keys and credentials
✓ Intermediate computation values

Completeness

Definition: Valid proofs from honest provers always verify.

Completeness Error: ε ≤ 2^-256

• Honest proofs never falsely rejected
• Deterministic verification (no randomness)
• Only exceptions: corrupted proof bytes, network errors

Failure modes (non-cryptographic):
• Transmission errors: Use checksums, retransmission
• Storage corruption: Use redundancy, backups
• BPF runtime errors: Proper error handling, gas limits

Threat Model

Adversary Capabilities

We model attackers with the following capabilities:

1. Computational Power
   • Can perform 2^80 operations (modern cloud infrastructure)
   • Cannot solve discrete log problem in BN254 (2^128 operations required)
   • Can attempt to forge proofs, find hash collisions, etc.
2. Network Access
   • Can intercept and analyze all on-chain transactions
   • Can submit arbitrary transactions to Solana
   • Cannot compromise Solana validators (assumed secure)
3. Code Access
   • Full access to ZKVAULT open-source code
   • Can analyze circuits, proof generation, verification logic
   • Cannot access user private keys or witness data

Attack Vectors and Mitigations

1. Proof Forgery Attack

Attack: Generate proof for false statement
Example: Prove "I have 1000 SOL" when balance is 10 SOL

Mitigation:
• Groth16 soundness: 2^-128 forgery probability
• Verification key integrity: Hash checked on-chain
• Public input validation: Range checks, format validation

Status: ✓ MITIGATED (cryptographically impossible)

2. Replay Attack

Attack: Reuse valid proof multiple times
Example: Vote twice with same eligibility proof

Mitigation:
• Unique nonce per proof (part of public inputs)
• On-chain nonce tracking in PDA state
• Timestamp validation (optional, application-level)

Implementation:
struct VaultState {
  used_nonces: BTreeSet<u64>,
  nonce_counter: u64,
}

fn verify_proof(proof: &Proof, state: &mut VaultState) {
  if state.used_nonces.contains(&proof.nonce) {
    return Err(ErrorCode::NonceReused);
  }
  state.used_nonces.insert(proof.nonce);
}

Status: ✓ MITIGATED (enforced on-chain)

3. Front-Running Attack

Attack: Observe pending proof, submit it first
Example: Steal voting proof from mempool

Mitigation:
• Proof tied to submitter's signature
• PDA derivation includes user pubkey
• MEV protection via private RPC endpoints (Jito, etc.)

Additional protection:
• Encrypt proof in transaction until inclusion
• Use commit-reveal schemes for sensitive operations
• Add submitter pubkey to public inputs

Status: ✓ MITIGATED (application can enforce)

4. Circuit Extraction Attack

Attack: Reverse-engineer circuit from proofs
Example: Deduce voting eligibility criteria

Mitigation:
• Zero-knowledge property prevents extraction
• Only public inputs and verification result visible
• Private inputs computationally hidden

Limitation:
• Circuit structure is public (by design)
• Applications should not rely on "security through obscurity"

Status: ✓ NOT APPLICABLE (zero-knowledge guarantee)

5. Denial of Service (DoS)

Attack: Spam invalid proofs to exhaust resources
Example: Submit 1M invalid proofs to congest network

Mitigation:
• Transaction fees deter spam (SOL cost per proof)
• Early rejection of malformed proofs (< 10k CU)
• Rate limiting at RPC level
• Account rent for vault creation

Gas costs:
• Invalid proof rejection: ~8k CU (~$0.00004)
• Valid proof verification: ~260k CU (~$0.0013)

Status: ✓ MITIGATED (economic incentives)

6. Key Compromise

Attack: Steal user's private key
Example: Phishing, malware, insecure storage

Mitigation:
• Hardware wallets (Ledger, etc.)
• Multi-signature schemes for critical operations
• Forward secrecy for vault encryption
• Time-delayed admin actions

Forward secrecy:
• Ephemeral keys for each encryption operation
• Past encrypted data remains secure even if key stolen
• Implemented via ECDH with x25519

Status: ⚠ USER RESPONSIBILITY (best practices enforced)

Trusted Setup Security

ZKVAULT uses a multi-party computation (MPC) ceremony for trusted setup:

Powers of Tau Ceremony:
• Participants: 100+ (diverse geographic/institutional distribution)
• Each contributes randomness to τ (toxic waste)
• Security: Only requires 1 honest participant
• Verification: All contributions publicly verifiable

Process:
1. Participant i receives [τ^j]G from participant i-1
2. Samples random rᵢ, computes [(τ·rᵢ)^j]G
3. Proves correctness via NIZK, publishes
4. Next participant receives [(τ·rᵢ)^j]G

Result:
• Final τ = r₁ · r₂ · ... · r₁₀₀ · τ₀
• As long as one rᵢ is secret and destroyed, setup is secure
• No single participant knows τ

Verification:
• All ceremony transcripts published
• Anyone can verify each step's correctness
• Pairing checks confirm sequential consistency

BPF Program Security

Memory Safety

Solana BPF enforces memory safety:
• Stack overflow: Prevented (4KB limit enforced by runtime)
• Heap overflow: Prevented (bounds checking on all accesses)
• Use-after-free: Impossible (no manual memory management)
• Buffer overflow: Caught at runtime (VM panics, TX fails)

Additional ZKVAULT protections:
• All array accesses bounds-checked
• Fixed-size buffers for proof deserialization
• No dynamic allocation in hot paths
• Panic-safe error handling (no unwrap() in production)

Re-entrancy Protection

Pattern: Lock-check-unlock
fn process_instruction(accounts, instruction_data) {
  let vault = &mut accounts.vault;
  
  // 1. Check lock
  require!(!vault.is_locked, ErrorCode::Locked);
  
  // 2. Acquire lock
  vault.is_locked = true;
  
  // 3. Execute (may call other programs)
  let result = execute_logic(vault, instruction_data)?;
  
  // 4. Release lock (always, even on error)
  vault.is_locked = false;
  
  Ok(result)
}

Protection against:
✓ Re-entrant calls to same vault
✓ Circular program invocations
✓ State corruption via nested calls

Encryption Security

Vault data encryption uses ChaCha20-Poly1305 AEAD:

Algorithm: ChaCha20-Poly1305
• Cipher: ChaCha20 (256-bit key, 96-bit nonce)
• MAC: Poly1305 (128-bit tag)
• Security: IND-CCA2 (authenticated encryption)

Key Derivation:
• Master key: 32 bytes (from wallet keypair)
• Per-message key: HKDF-SHA256(master_key, nonce)
• Ephemeral key (forward secrecy): ECDH(ephemeral_private, recipient_public)

Nonce handling:
• 96-bit random nonce per encryption
• Collision probability: 2^-96 (negligible)
• Never reuse nonce with same key

Authentication tag:
• Prevents tampering and forged ciphertexts
• Verifies both ciphertext and additional authenticated data (AAD)

Security Best Practices

For Developers

• Circuit Design
  • Minimize public inputs (reduce attack surface)
  • Validate all inputs at circuit boundary
  • Use well-audited circuit libraries
  • Test edge cases extensively
• Key Management
  • Never log private keys or witness data
  • Use hardware wallets for production
  • Implement key rotation policies
  • Encrypt sensitive data at rest
• Deployment
  • Audit circuits before mainnet deployment
  • Use Solana program upgradability carefully
  • Implement emergency pause mechanisms
  • Monitor vault activity for anomalies

For Users

• Use hardware wallets for high-value operations
• Verify verification key hashes before trusting vaults
• Never share private keys or seed phrases
• Be cautious of phishing attacks

Audit History

All audit reports are available at github.com/zkvault/audits.