System architecture

Design principle: two integrity layers

Signatures and watermarks fail in opposite places, so the design uses both:

LayerProvesSurvives re-encoding?
Cryptographic signature over content hashesExact integrity, device identity, capture timeNo — any transcode invalidates it, by design
Robust invisible watermark (VideoSeal)Pointer to the registered proof (payload = proof id)Yes — measured ≥94.9% bit accuracy under aggressive transcodes
Your capture signed + watermarked shared as exact file (email, drive, download) Social platform re-encodes the pixels, strips all metadata Verified exact copy → signature social copy → watermark

Capture & signing pipeline

Camera photo / video file written to gallery SHA-256 32-byte fingerprint of the exact bytes 🔒 Secure element ECDSA P-256 — the private key never leaves the chip Proof registered hash + signature + attestation + timestamp
  1. Device enrollment: an ECDSA P-256 key pair is generated inside StrongBox (dedicated secure element; TEE fallback on devices without it — the level is recorded in every proof). Android Key Attestation produces an X.509 chain, rooted at Google's hardware attestation root, proving the key lives in hardware and the device passed verified boot.
  2. Capture: photo or video; the file's SHA-256 is computed over the final bytes.
  3. Signing: the 32 hash bytes are signed in the secure element (SHA256withECDSA). The private key never exists in application memory.
  4. Watermarking: the signed original is uploaded once; the watermark service embeds the proof id into the pixels and the watermarked copy replaces the file in the gallery. Media transits the service for embedding but is never stored — the registry keeps only hashes, signatures and metadata (~200 bytes per proof).

Signature convention

H   = SHA-256(file bytes)                    // 32 bytes
sig = ECDSA-P256( SHA-256(H) )               // Android SHA256withECDSA over H

The verifier recomputes H from the uploaded file and checks sig against the device's enrolled public key — the stored proof row is a claim, the signature is the evidence, and it is re-checked on every verification.

Watermark payload encoding

The watermark carries a 256-bit message decoded from the pixels. Robustness comes from structure, not secrecy:

proof id — 24 bit CRC-8 = one 32-bit block × 8 repetitions = 256 bits copies of each bit sit 32 positions apart — an error burst hits at most one copy per bit; decoding soft-combines all 8 copies and validates the CRC

Extraction averages the decoded signal across sampled frames, soft-combines the eight copies of each bit, and accepts the result only if the CRC validates and signal agreement exceeds a threshold. Measured end-to-end: full payload recovery after real YouTube and WhatsApp round-trips and 720p/2Mbps re-encodes (data).

Bitstream signatures for video (next iteration)

Whole-file signing is the MVP baseline. The validated upgrade path embeds a rolling signature per GOP (group of pictures) directly in the H.264/H.265 bitstream as SEI NAL units in the ONVIF Media Signing format: each GOP's hash chains the previous one, proving continuous, ordered, real-time capture, and making any cut or splice detectable at GOP granularity. Our device tests confirmed these SEI units pass through the hardware encoder and MP4 muxer untouched on consumer hardware (60/60 preserved, Qualcomm c2.qti.avc.encoder).

Verification service

Given any file, the verifier resolves in order — each level is weaker than the previous and the UI says so explicitly:

  1. Byte-exact original → hardware signature re-verified → Verified (original).
  2. Byte-exact watermarked copy → derived server-side from a signed original → Verified (watermarked copy).
  3. Watermark extraction on re-encoded copies → proof id recovered from the pixels → Provenance recovered: owner, device and capture time are known, but byte integrity of this specific copy is not verifiable.

Uploaded files are hashed and scanned in a stream and never stored.

Trust model and standards alignment

The design maps onto C2PA concepts (hard binding = content hash + signature; soft binding = watermark) and is built to become C2PA-conformant: proofs can be re-expressed as C2PA manifests, and the device keys/attestation flow matches the requirements of C2PA Conformance Level 2 (hardware-backed keys). Timestamping today relies on the registry's clock plus the device-claimed capture time; RFC 3161 tokens are the planned upgrade.