Trust & honesty
Threat model
The guiding invariant: every failure mode degrades to “we couldn’t confirm,” never to a false confirmation. No adversary below can make tampered or unsigned content read as verified.
The core property
tampered, provenance_present_untrusted, or no_provenance. The dangerous direction, manufacturing a false verified, is what the cryptography prevents.Adversaries & mitigations
Re-encode / crop / resize
Vector. Modify a credentialed asset, then redistribute it.
Outcome. The bytes change, so the hard binding no longer matches.
Mitigation. The hard binding is a hash over the asset bytes. Any pixel-level change breaks it, never producing a false `verified`. If the manifest is also lost, it degrades to no_provenance, not a false positive.
Strip metadata
Vector. Remove the embedded manifest (often automatic on upload).
Outcome. No embedded credential is found.
Mitigation. Reported honestly as no_provenance (unknown, not fake). Soft-binding recovery by content hash from the transparency log is attempted, best-effort, when the bytes are unchanged.
Swap manifest onto another asset
Vector. Attach a valid manifest from asset A to a different asset B.
Outcome. The transplanted binding hash does not match B's bytes.
Mitigation. The binding is computed over the asset's own bytes, so a manifest only validates against the exact asset it was signed for. A transplant fails the binding check.
Re-sign with an untrusted key
Vector. Strip the original credential and re-sign with the attacker's own key.
Outcome. A new, cryptographically valid signature from an untrusted signer.
Mitigation. Trust is bound to a key thumbprint, not a display name. The attacker cannot impersonate a trusted issuer. The result is reported as provenance present, untrusted signer.
Hash-collision attempt
Vector. Forge different bytes that hash to a signed asset's binding.
Outcome. Infeasible.
Mitigation. Bindings and the transparency chain use SHA-256; a second-preimage attack is computationally infeasible. A mismatch surfaces as tampered.
Replay a request
Vector. Resend a captured sign/verify request to duplicate effects.
Outcome. Duplicate processing is suppressed.
Mitigation. POSTs accept an idempotency-key; a repeated key returns the original result instead of re-processing. The transparency log's unique seq prevents a forked chain under concurrency.
Cross-tenant access
Vector. Use one workspace's key to read another's data.
Outcome. Denied.
Mitigation. Every resource is scoped to a workspace and every query is filtered by the authenticated key's workspace. Trust lists, policies, events, and audit records never leak across tenants.
Append data after a signed image
Vector. Attach a trailing payload after a signed PNG's IEND (or a JPEG's scan).
Outcome. The appended bytes are part of the binding, so the hash no longer matches.
Mitigation. The hard binding covers the whole asset, including any bytes past the last chunk, so a polyglot or trailing payload can never ride on a verified result.
Embed two manifests
Vector. Attach more than one Signata manifest so a reader picks the attacker-favorable one.
Outcome. Ambiguous provenance is refused, not silently resolved.
Mitigation. An asset carrying more than one Signata manifest is rejected. Which one “wins” must never be decided by byte position.
Spoof a C2PA issuer name
Vector. Sign with any certificate whose name resembles a trusted issuer (e.g. “OpenAI”).
Outcome. A display-name match is advisory only and cannot grant trust.
Mitigation. C2PA trust requires a certificate chain validated against a configured anchor, never a match on the issuer's display name. An unverified signer reads as provenance present, untrusted.
Out of scope
Signata is narrow by design. It explicitly does not:
- Detect unsigned manipulation. If media carries no credential, Signata cannot tell whether it was edited. It reports
no_provenance: unknown, not fake. - Adjudicate truth. A valid signature attests origin and integrity, not whether the depicted claim is accurate. A trusted signer can still sign a misleading image.
- Guard a signer’s private key for them. If a trusted signer’s key is compromised, the attacker can produce genuinely-valid credentials until that key is removed from your trust list. Key custody is the signer’s responsibility; see Production hardening for how Signata protects its own issuer keys.