ZKAC/docs/SECURITY.md

Security model (ZKAC 0.5.1)

This document summarizes the direct peer-to-peer grant model, with transcript-bound BBS+ authorization (Option C).

Goals

• MITM-safe transport using transcript-bound authentication.
• Anonymous-authorized grant sender: recipient verifies sender is a valid admin for the target registry, without requiring a stable sender identifier.
• End-to-end credential confidentiality from sender to recipient.
• Replay and downgrade resistance on the encrypted transport channel.

Cryptographic components

• Transport: X25519 ephemeral DH, HKDF-SHA256, ChaCha20-Poly1305.
• Identity proofing: Schnorr signatures on Ristretto255 over session transcript.
• Authorization proofs: BBS+ presentations over BLS12-381.
• Registry integrity: certified RegistryState with BBS+ admin proof checks.
• Grant payload encryption: X25519 + HKDF-SHA256 + ChaCha20-Poly1305 issuance envelope.

Direct p2p grant flow

1. Sender and recipient establish an encrypted peer session.
2. Sender prepares a blind-issued credential payload for recipient and encrypts it with recipient issuance key material.
3. Sender transmits:
   • encrypted payload,
   • certified registry state snapshot,
   • transcript-bound admin BBS+ proof.
4. Recipient verifies:
   • registry state certificate,
   • admin proof bound to current session transcript.
5. Recipient decrypts payload, validates credential data, and stores the credential locally.

Threat model

• Passive network attacker:
  • Cannot recover plaintext or keys without breaking X25519/ChaCha20-Poly1305 assumptions.
• Active MITM:
  • Cannot relay proofs across sessions because authorization proof nonce is session transcript hash.
  • Cannot impersonate peer without required long-term key/proof material.
• Malicious sender without admin credential:
  • Rejected during transcript-bound BBS+ admin verification.
• Malicious recipient:
  • Can only decrypt payloads addressed to its issuance key.
• Replay:
  • Rejected by session replay protections (monotonic counter + replay window).

Security properties and limits

• anonymous_authorized mode:
  • Recipient learns sender is authorized for the registry, not a mandatory stable real-world identity.
  • Network metadata (IP/endpoint timing) is still visible to direct peers.
• Registry freshness:
  • Recipient verifies cryptographic validity of received state; deployment policy should define freshness expectations.
• Key management remains operationally critical:
  • Protect admin/BBS+ secret material and transport keys.

Operational guidance

• Pin or verify peer transport keys out-of-band before first direct grant exchange.
• Rotate compromised keys and re-issue credentials with epoch/state updates.
• Do not log credential secrets, issuance secret keys, or raw proof material.