72 lines
3.5 KiB
Markdown
72 lines
3.5 KiB
Markdown
# Security model (ZKAC 0.7.1)
|
|
|
|
This document summarizes the direct peer-to-peer grant model, with transcript-bound BBS+ authorization.
|
|
|
|
## 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.
|
|
- The issuance envelope format is `nonce || ciphertext` where `nonce` is a random 96-bit value generated per message.
|
|
- KDF context is direction-separated (`user->admin` vs `admin->user`) to avoid cross-direction key reuse.
|
|
|
|
## 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,
|
|
- restored registry ID matches the announced outer `registry_id`,
|
|
- admin proof bound to current session transcript.
|
|
5. Recipient decrypts payload and enforces binding checks:
|
|
- payload `registry_id` equals authenticated outer `registry_id`,
|
|
- payload role matches announced role metadata,
|
|
- reconstructed credential verifies against the certified registry state (`verify_presentation`) before storage.
|
|
6. Recipient stores credential only after all checks pass.
|
|
|
|
## 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.
|
|
- Grant-context binding:
|
|
- Recipient rejects grants where outer authenticated context and inner decrypted payload disagree.
|
|
- Recipient rejects credential material that does not verify against the supplied certified registry state.
|
|
- 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.
|