Security Policy
Security is foundational to Certivu. This document describes our security architecture, data handling practices, and how to responsibly disclose vulnerabilities.
Cryptographic Architecture
ML-DSA (Dilithium) — NIST FIPS 204
All provenance signatures use ML-DSA (Module Lattice-Based Digital Signature Algorithm), standardized by NIST as FIPS 204. ML-DSA is post-quantum resistant — it cannot be broken by quantum computers running Shor's algorithm, unlike RSA or ECC. Certivu does not use RSA or ECC anywhere in its signing infrastructure.
SHA-3 content hashing
Content is hashed using SHA-3-256 (FIPS 202) before signing. The hash is what is signed — not the raw content. This ensures tamper detection: if a single pixel changes, the hash changes, the signature fails verification.
Private key handling
Generator private keys are generated in the dashboard and displayed to you once. Certivu does not retain private keys after generation. You are responsible for securing your private key in a secrets manager or environment variable vault. If a key is compromised, revoke the generator immediately from the dashboard — all signatures from that generator will become invalid.
For server-managed generators, you can also rotate the signing key at any time. Rotation issues a fresh key for new content while everything signed earlier stays verifiable, so you can refresh keys on a schedule or after a suspected exposure without disrupting past provenance.
Infrastructure Security
- All traffic is encrypted with TLS 1.2+
- Passwords hashed with argon2id (memory-hard, resistant to GPU cracking)
- JWT sessions signed with HS256, 24-hour expiry
- API keys are hashed before storage — raw keys are never stored
- MongoDB Atlas with encryption at rest (AES-256) and IP allowlist
- Redis on Upstash with TLS (
rediss://) - HTTP security headers: HSTS, X-Frame-Options, X-Content-Type-Options, CSP
- CORS restricted to known origins
- Rate limiting on all endpoints via Redis sliding window
API Key Security
API keys (ctv_key_…) are the credential for programmatic access. Treat them
like passwords:
- Never commit API keys to source control
- Store them in environment variables or a secrets manager
- Use separate keys per environment (dev/staging/prod)
- Rotate keys immediately if you suspect exposure — revoke from the dashboard
Watermark Transparency
Certivu's watermarks are a resilience mechanism, not a security
guarantee. We do not claim they are unremovable. An adversary who knows the watermark
format may be able to remove or overwrite it. The ML-DSA signature — not the watermark
— is the authoritative trust signal. If a watermark is removed, the content is still
verifiable if the original ctv_ token is available.
The primary resilient mark is a neural watermark — TrustMark for images and WavMark for audio — designed to survive the regimes that defeat classical techniques, including heavy recompression, format transcode, and social-media re-encode. A DCT spread-spectrum watermark backs it up for images (each bit distributed across 4 independent mid-frequency DCT coefficients per 8×8 block, recovered via majority voting), with zero-width-character steganography for text. None of these change the security model — watermarks are a resilience layer, never cryptographic proof.
Certivu can additionally embed a real, embeddable C2PA manifest into JPEG and PNG, signed with post-quantum ML-DSA rather than the classical RSA/ECC the C2PA ecosystem uses today. The manifest is structurally interoperable with Content Credentials; the signature itself remains the authoritative trust signal.
Perceptual Fingerprinting
Certivu supports an optional 64-bit perceptual hash (pHash) submitted at sign time. At verification, if no watermark or token is found, a fuzzy lookup by Hamming distance can recover the original record for transformed images and video (first I-frame), and an acoustic fingerprint provides the equivalent fallback for WAV audio. pHash is a similarity signal only — it is not a cryptographic commitment. A pHash match triggers the same ML-DSA signature verification as any other path. A false pHash match would still fail the signature check.
Format Support
Tokens embed in format-native metadata across every supported type: images (JPEG APP1 XMP,
PNG tEXt chunk, WebP XMP RIFF chunk), audio (ID3v2 / VORBIS_COMMENT / CTV), text (PDF
/Metadata XMP, HTML meta, plain-text sidecar), and video (MP4/MOV cerv atom,
MKV/WebM sentinel trailer). Metadata embedding is not a security boundary — it is a
convenience fast path. Resilient fallbacks differ by type: a neural (TrustMark) plus DCT
spread-spectrum watermark for images, a neural (WavMark) plus DCT frame watermark for audio,
zero-width-character steganography for text/HTML, and perceptual-hash or acoustic-fingerprint
lookup for video and audio. In all cases, the ML-DSA signature over the content hash provides
the authoritative integrity check.
Vulnerability Disclosure
If you discover a security vulnerability in Certivu, please report it responsibly:
- Email: [email protected] with subject line
[SECURITY] - Include a description of the vulnerability, reproduction steps, and potential impact
- Do not publicly disclose the vulnerability until we have had 90 days to address it
- Do not access, modify, or delete data belonging to other users during research
We will acknowledge your report within 2 business days and aim to resolve critical vulnerabilities within 14 days. We do not currently offer a formal bug bounty program, but we recognize researchers who help us improve security.
Incident Response
In the event of a security incident affecting user data, we will notify affected users by email within 72 hours of becoming aware of the breach, in accordance with applicable data protection laws.
Compliance
- NIST FIPS 204 (ML-DSA)
- NIST FIPS 203 (ML-KEM — on the roadmap)
- NIST FIPS 202 (SHA-3)
- EU AI Act Article 50 — machine-readable provenance + compliance attestation export
- GDPR-aware data handling (see Privacy Policy)
Contact
Security issues: [email protected]
General inquiries: [email protected]