Security Model

Threat model, cryptographic primitives, and security properties of the VDI protocol.

Cryptographic Primitives

Primitive	Usage	Implementation
Groth16	Zero-knowledge proofs	snarkjs (bn128 / bn254 curve naming)
Ed25519	Digital signatures	@noble/ed25519
SHA-256	Hashing (pipeline, manifest, key, attestation)	Node.js crypto / Web Crypto API
Merkle Tree	Transparency log	Custom implementation
Canonical JSON	Deterministic serialization	RFC 8785-aligned fail-closed implementation

Proof backends and manifest identity

VDI ships multiple Groth16 relations behind one attestation envelope. The security statement is always relation-specific (mode terms aligned to VDI-SPEC.md §0.6):

1. causal (causalProof, zk-cp), Proves statements defined by the zk-cp causal circuit for a declared DAG and execution path. The JavaScript DAG builder may attach stub edge/constraint callbacks ({ valid: true }) for wiring only; they are not a second enforcement layer. Do not treat JS callbacks as authoritative policy evaluation.
2. enforced-policy (Circom), Proves statements defined by named policy circuits (fairLending, hipaaAccess, …). Here “policy in circuit” is literal: constraints are encoded in R1CS for that circuit build.
3. compliance, Separate circuit family for compliance-certificate attestations.

Authoritative manifest digest: Published registry manifests are identified by protocol/lib/registryManifestDigest.js (SHA-256 over canonical JSON of id, version, constraints, pipeline). Attestations that claim binding to a registry manifest should set policy.manifest_hash to that digest. A separate enforcement_parameters_digest (where present) fingerprints compiled public parameters for enforced-policy mode (policyHash() in policyCompiler.js).

Artifact integrity: Pin WASM/zkey/vkey for every deployed relation (zk-cp and Circom). Use ARTIFACT_MANIFEST.json and verifier circuitRegistry options where applicable.

Threat Model

Formal Adversary Model

We model a probabilistic polynomial-time (PPT) adversary $\mathcal{A}$ with full visibility into attestation/receipt artifacts, verifier code, and network traffic, with adaptive access to proving and verification interfaces.

Adversary capabilities:

• Construct arbitrary attestation objects (well-formed or malformed).
• Modify attestation fields in transit.
• Replay attestations and receipts.
• Attempt proof forgery and manifest/pipeline substitution.
• Attempt attacks after observing chosen-message signatures.

Adversary limitations (assumptions):

• Cannot forge Ed25519 signatures in the EUF-CMA setting, except with probability negligible in security parameter $\lambda$.
• Cannot break Groth16 soundness/knowledge-soundness, except with probability negligible in $\lambda$.
• Cannot produce a valid witness for invalid constraints under correct constraint encoding.
• Cannot invert SHA-256/Poseidon or find preimage/second-preimage/collision attacks that break protocol bindings, except with negligible probability in $\lambda$.

Threats and Mitigations

1. Forged Attestation

Threat: An attacker creates a fake attestation that claims a decision followed rules it didn't.

Mitigation:

• The Groth16 ZK proof is computationally infeasible to forge without the witness (private inputs)
• The Ed25519 signature ensures the attestation was produced by the holder of the signing key
• Verification step 5 (ZK proof) catches any forged proof with overwhelming probability

2. Tampered Attestation

Threat: An attacker modifies a valid attestation (e.g., changes the pipeline name or outcome).

Mitigation:

• The Ed25519 signature covers the entire canonical JSON payload (everything except signature.value)
• Any modification invalidates the signature (verification step 6)
• The pipeline hash and manifest hash are independently verifiable (steps 3-4)

3. Expired Attestation Replay

Threat: An attacker presents an expired attestation as current.

Mitigation:

• Verification step 2 checks expires_at against the current time
• Attestations have a configurable TTL (default: 1 year)

4. Fraudulent Receipts

Threat: A verifier issues a PASS receipt for an attestation it didn't actually verify, or that actually fails verification.

Mitigation:

• Spot-check enforcement: At the critical acceptance level, the acceptance policy randomly re-runs full ZK verification
• Transparency log: If a verifier issues contradictory receipts, the log detects equivocation
• Revocation: Equivocating verifiers are revoked, invalidating all their receipts
• Trusted Verifier Sets: Only receipts from pre-approved verifiers are accepted

5. Verifier Equivocation

Threat: A verifier tells one agent the attestation is valid and another agent it's invalid.

Mitigation:

• All receipts are appended to the transparency log
• checkEquivocation() detects contradictory results from the same verifier for the same attestation
• Equivocating verifiers can be revoked from the registry

6. Key Compromise

Threat: A verifier's Ed25519 private key is compromised.

Mitigation:

• Key rotation with configurable grace periods allows smooth transitions
• Revocation immediately invalidates all current and future keys for a verifier
• Key IDs (kid) in attestations enable key rotation without breaking outstanding attestations

7. Circuit Substitution

Threat: An attacker substitutes the ZK circuit with one that proves different (weaker) properties.

Mitigation:

• Circuit governance metadata in every attestation includes circuit_hash (SHA-256 of WASM) and r1cs_hash
• Auditors can verify the circuit hasn't changed by comparing hashes
• compiler and compiler_version fields enable reproducible builds
• audit_reference links to external audit reports

8. Transparency Log Tampering

Threat: The transparency log operator modifies or removes entries.

Mitigation:

• Merkle tree structure ensures any modification changes the root hash
• Inclusion proofs allow independent verification that a receipt exists in the log
• Signed Log Entries (SLE) provide evidence of the log state at the time of append

Security Properties

Soundness

A valid attestation cannot be created without:

1. Knowledge of the private inputs that satisfy all constraints
2. A valid execution path through the pipeline DAG
3. The Ed25519 signing key

The Groth16 proof system provides computational soundness: for any PPT adversary and security parameter $\lambda$, producing a valid proof for a false statement succeeds with probability negligible in $\lambda$.

Reduction-style interpretation: If an adversary succeeds with non-negligible probability in producing accepting proofs for false statements, that adversary can be transformed into an algorithm that breaks Groth16 knowledge soundness, or (for payload/substitution attacks) Ed25519 EUF-CMA binding assumptions.

Formal Example ($x,w,C_M$)

Let $M$ be a policy manifest, $C_M$ the compiled constraint system, and:

• $x$: public statement data (pipeline hash, manifest hash, decision commitment, policy parameters)
• $w$: private witness data (sensitive attributes and execution-trace values)
• $R_M(x,w)=1 \iff C_M(x,w)$ is satisfied

Valid case: if $\exists w$ such that $C_M(x,w)=1$, completeness implies existence of a proof $\pi$ with Verify(vk, x, pi) = 1.

Invalid case: if for fixed $x$, $\forall w,\ C_M(x,w)=0$, then no PPT adversary can output accepting $\pi$ except with probability negligible in $\lambda$.

Security Game View (Enforcement Unforgeability)

Define $\mathsf{Game}_{\mathrm{enf}}^\mathcal{A}(\lambda)$:

1. Challenger samples setup/keys at security parameter $\lambda$.
2. Adversary $\mathcal{A}$ receives public parameters and adaptive oracle/interface access.
3. $\mathcal{A}$ outputs candidate $(x,\pi,\sigma)$.
4. Win condition: verification accepts while no witness $w$ exists such that $R_M(x,w)=1$.

Define advantage $\mathrm{Adv}{\mathrm{enf}}^\mathcal{A}(\lambda)=\Pr[\mathsf{Game}{\mathrm{enf}}^\mathcal{A}(\lambda)=1]$. Security requirement: $\mathrm{Adv}_{\mathrm{enf}}^\mathcal{A}(\lambda)$ is negligible in $\lambda$ for all PPT adversaries.

Zero-Knowledge

The attestation reveals nothing about:

• The private inputs to the decision
• The internal state of the decision pipeline
• How specific constraints were evaluated
• The decision-making algorithm or model weights

Only the proof, public signals, and pipeline/policy metadata are visible.

Non-Repudiation

• Attestations are signed with Ed25519, the signer cannot deny producing them
• Receipts are signed, verifiers cannot deny issuing them
• The transparency log provides an immutable record

Offline Verifiability

• Verification requires only the attestation object (self-contained)
• The verification key is embedded in the attestation
• No network calls, APIs, or QuantZK servers needed
• Works forever, even if QuantZK ceases to exist

Forward Security

• Attestations remain verifiable after key rotation or revocation
• The verification key in the attestation is independent of the signing key lifecycle
• Expired attestations still verify (step 2 failure is a policy decision, not a cryptographic one)

Operational Security Recommendations

Key Management

1. Signing keys should be stored in HSMs or secure enclaves in production
2. Key rotation should be scheduled regularly (e.g., every 90 days)
3. Grace periods should be at least 24 hours to allow propagation
4. Key IDs should be used to track which key signed each attestation

Verifier Deployment

1. Run verifiers in isolated environments (containers, VMs)
2. Log all verification activity for audit trails
3. Monitor the transparency log for equivocation
4. Set up alerts for failed spot-checks

Circuit Governance

1. Pin circuit hashes in production configuration
2. Require audit references for circuits used in regulated contexts
3. Version circuits and maintain a changelog
4. Use reproducible builds (pin compiler version)

Artifact Lifecycle Semantics

1. Validate attestations against embedded verification.key + verification.key_hash; do not reinterpret old attestations against newly rotated keys by default.
2. Treat artifact rotation as a versioned governance event, never a silent overwrite.
3. Keep a documented compatibility/deprecation window for old vs new pins.
4. Enable pin enforcement intentionally via verifier circuitRegistry configuration.

Strict Verification Deployment (Regulated)

For regulated production decisions, deployments SHOULD enforce VDI_VERIFY_STRICT_V1 with explicit revocation and authority binding inputs.

1. Issue attestations with a published registry manifest block and trust_class: "published".
2. Bind manifest.authority_signature to policy.manifest_hash (Ed25519 over UTF-8 hash string).
3. Pass revocation data into verifyDecision(att, { revocation }) for each verification decision.
4. Optionally pass circuitRegistry pins and reject mismatches/deprecated circuits.
5. Fail closed on verifier code values in the VDI_ERR_* namespace.

Python verifier dependency policy

Production Python verifier deployments MUST install:

1. py_ecc for full bn128 Groth16 pairing verification
2. PyNaCl for Ed25519 signature verification

If either is missing, verification fails closed with deterministic codes (VDI_ERR_ZK_VERIFY, VDI_ERR_SIGNATURE_VERIFY) rather than downgraded structural/skip behavior.

Threat Model Annex (Protocol-Grade Additions)

9. Revocation Snapshot Downgrade

Threat: A stale or intentionally old revocation snapshot allows revoked attestations/keys to pass.

Mitigation:

• Include snapshotTime in revocation snapshots
• Enforce VDI_ERR_REVOCATION_STALE when issued_at > snapshotTime
• Treat missing revocation data as failure under strict profile (VDI_ERR_REVOCATION_DATA_REQUIRED)

10. Manifest Authority Spoofing

Threat: An attacker injects a fake manifest block with unsupported signing semantics.

Mitigation:

• Require manifest.authority_signature in strict profile
• Require authority_signature.signed_hash === policy.manifest_hash
• Verify Ed25519 over UTF-8 hash string; reject unsupported algorithms and malformed keys

11. Circuit Pin Evasion

Threat: An issuer swaps to a different circuit with weaker constraints while keeping surrounding metadata plausible.

Mitigation:

• Pin expected per-circuit WASM hash in verifier configuration (circuitRegistry)
• Reject hash mismatches (VDI_ERR_CIRCUIT_HASH_MISMATCH)
• Reject deprecated circuits (VDI_ERR_CIRCUIT_DEPRECATED)

Transparency Log

1. Back up the log regularly
2. Distribute inclusion proofs to receipients
3. Monitor for equivocation continuously
4. Consider gossip protocols for log distribution in decentralized deployments