62 lines
2.8 KiB
Markdown
62 lines
2.8 KiB
Markdown
# Security model (ZKAC 0.6.0)
|
|
|
|
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.
|