Security Model

Every system makes trust assumptions. This section states Apertrue's explicitly — what the system trusts, what it defends against, what cryptographic guarantees hold, and where the boundaries are. No system is unconditionally secure; the goal is to make the trust assumptions narrow, explicit, and auditable.

Trust assumptions

Apertrue's security rests on a small set of assumptions. If any assumption fails, the impact is contained — a compromised component weakens one guarantee without collapsing the entire system.

What the backend cannot do

The system is designed so that a compromised backend has limited impact:

• Cannot decrypt media. Images are encrypted with AES-256-GCM in the browser before upload. The encryption key is derived from the user's passkey PRF output, which never leaves the hardware authenticator.
• Cannot forge proofs. The verification key hash is stored as a PublicImmutable in the Aztec contract — immutable after deployment. Even if the backend substitutes a different verification key, the on-chain contract rejects it.
• Cannot replay proofs. Each proof produces a unique nullifier. The Aztec nullifier tree is append-only and immutable — a nullifier pushed once cannot be removed or reused.
• Cannot link uploads across batches. Each batch uses a diversified Aztec address derived from the user's master secret plus a per-batch nonce. The backend sees different addresses for each batch and cannot correlate them.
• Cannot recover metadata. Location and time commitments are Poseidon2 hashes with random salts. The salts are stored in the user's encrypted IndexedDB vault, not on the backend.

Threat model

Forged C2PA manifests

An attacker creates a fake C2PA manifest for an AI-generated image, attempting to make it appear camera-verified.

• Defence. The ZK circuit verifies the full certificate chain — the manifest must be signed by a leaf certificate issued by an intermediate CA in the Oracle's trust list. The attacker needs a valid certificate from a trusted CA.
• Residual risk. If the attacker compromises a trusted CA's signing key, they can issue certificates that pass verification. Mitigation: revoke the compromised intermediate from the trust list (propagates within 7 days).

Proof replay

An attacker intercepts a valid proof and resubmits it to claim someone else's verified content as their own.

• Defence. Two layers of replay prevention. The backend checks the used_proof_hashes table — if the proof bytes have been seen before, the submission is rejected. On-chain, the Aztec nullifier tree prevents the same nullifier from being pushed twice.
• Residual risk. None, assuming Pedersen hash collision resistance holds and the Aztec network operates correctly.

Metadata fabrication

An attacker claims a photo was taken in London when it was actually taken in Moscow, or claims it was taken yesterday when it was taken last year.

• Defence. The ZK circuit verifies metadata against the C2PA manifest's signed data. The prover cannot fabricate disclosed values — the circuit enforces that disclosed coordinates fall within the privacy circle, and the privacy circle centre is derived from the signed EXIF GPS data.
• Defence (commitment binding). Metadata commitments are Poseidon2 hashes. The binding property means the prover cannot open a commitment to a different value than what was originally committed — even if they control the proof generation.
• Residual risk. If the camera itself records wrong metadata (GPS spoofing at the hardware level, wrong system clock), the signed data is wrong from the source. The system verifies the signature, not the physical truth.

Database compromise

An attacker gains full read access to the PostgreSQL database.

• What they get. Encrypted image blobs (ciphertext), PDQ perceptual hashes, nullifiers (Pedersen hashes), verification index entries (PDQ hash + status, no user IDs), proof records, and PII fields encrypted with AES-256-GCM at the field level.
• What they cannot do. Decrypt images (keys are in users' browsers). Reverse PDQ hashes to images (perceptual hashes are one-way at this resolution). Link verification index entries to users (the table contains no user IDs, no upload timestamps beyond the verification date, no image URLs).
• What they could learn. Which PDQ hashes have been verified and when. This reveals the existence and rough volume of verified content, but not the content itself or who uploaded it.

Man-in-the-middle

An attacker intercepts traffic between the browser and the backend.

• Defence. All API calls use HTTPS (TLS 1.3). Media is encrypted before upload — even if TLS is broken, the attacker sees AES-256-GCM ciphertext. ZK proofs contain no private metadata (zero-knowledge property). Nullifiers are one-way hashes.
• Residual risk. If a TLS root CA is compromised and the attacker has an active MITM position, they could intercept API calls. They still cannot decrypt media or extract metadata from proofs, but they could observe traffic patterns (upload frequency, payload sizes).

Cryptographic guarantees

Privacy guarantees

Privacy is enforced at four layers, each independent of the others:

The full breakdown of what the backend receives versus what it never sees is in the Privacy Model section.

Revocation and recovery

Trust list revocation

If a certificate authority is compromised, the Oracle removes the intermediate from the trust list. The revocation flow:

1. Detection. Compromise reported by the CA, discovered through certificate transparency logs, or identified through anomalous proof patterns.
2. Revocation. Oracle keyholders sign a new bundle with the intermediate removed. Requires 2-of-3 Ed25519 signatures.
3. Propagation. Backend loads the new bundle. The 7-day bundle age limit ensures all clients pick up the revocation within a week.
4. Grace period. Proofs generated against the previous trust list version (one version behind current) are still accepted to avoid breaking in-flight uploads.

Cryptographic erasure

When a user deletes media, the encryption key is destroyed. Even if the encrypted blob persists in backups or CDN caches, it cannot be decrypted. This is cryptographic erasure — deletion of the key is equivalent to deletion of the data.

Account recovery

If a user loses their device, they can recover their account using their passkey (synced via iCloud Keychain, Google Password Manager, or similar). The PRF extension deterministically re-derives the Aztec secret key and encryption wrapping key from the passkey — no seed phrase or backup code required. For users whose authenticator does not support PRF, an encrypted wallet backup (password-protected, PBKDF2 with 310,000 iterations) can be stored on the backend as a fallback.

What the system does not protect against

These are honest limitations — scenarios where the system's guarantees do not hold:

Assurance levels

Not all guarantees carry equal weight. The system's properties can be ranked by the strength of the underlying assumption:

High assurance

These guarantees hold under standard cryptographic assumptions (discrete log, collision resistance, AES security). Breaking them requires a fundamental advance in cryptanalysis:

• Proof soundness — forging a proof requires breaking UltraHonk
• On-chain verification — Aztec contract checks proof independently of backend
• Commitment binding — fabricating metadata requires breaking Poseidon2 collision resistance
• Nullifier replay prevention — immutable on-chain nullifier tree
• Media encryption — decrypting without the key requires breaking AES-256-GCM

Medium assurance

These guarantees depend on operational security — correct key management, honest participants, or hardware tamper resistance:

• Trust list integrity — assumes 2-of-3 Oracle keyholders are honest
• Certificate validity — assumes CAs properly secure their signing keys
• Session key security — 30-minute window with biometric authorisation
• Client-side encryption — assumes no device malware intercepting keys

Lower assurance

These properties are best-effort and can be circumvented by determined adversaries:

• Trust list currency — 7-day revocation window means a compromised CA has up to a week before proofs against it are rejected
• Camera firmware integrity — system cannot verify firmware; assumes manufacturers maintain security
• Physical truth of metadata — GPS spoofing, wrong clocks, and screen photography all produce valid signatures over false data
• Rate limiting — per-IP limits can be circumvented with IP rotation

Design principles

The security model follows three guiding principles:

1. Minimise the trust set. Every component removed from the trust set is a component that cannot be compromised. The backend is not trusted. The network is not trusted. The viewer is not trusted. Only the cryptographic primitives, the hardware authenticator, the Oracle keyholders, and the camera manufacturers are in the trust set.
2. Fail narrow. When a component is compromised, the damage is contained. A compromised CA affects only images signed by that CA. A compromised Oracle keyholder (1 of 3) cannot modify the trust list. A compromised backend cannot decrypt media or forge proofs.
3. Make assumptions auditable. The trust list is public. The Merkle roots are published and signed. The Aztec contract is deployed on a public network. The verification circuits are open source. Anyone can verify any claim the system makes without trusting the system itself.

This concludes the technical documentation. The 20 sections cover the full system — from C2PA extraction through ZK proof generation, aggregation, on-chain verification, privacy, identity, media processing, content moderation, and the security model. The source code is the definitive reference for implementation details beyond what is documented here.