What happens between the shutter press and a defensible record
Every Captilo capture runs through nine independent, cryptographically-linked steps before the file is ever exported. Each step exists to answer a specific question a claims adjuster, auditor, or opposing counsel will ask: who captured this, when, and has it been altered since.
Nine steps, one continuous record
Biometric authentication
Face ID or fingerprint via the device’s Secure Enclave gates the camera before capture. A one-way SHA-256 commitment (binding an anonymous user ID, a single-use nonce, and the photo hash) is generated locally afterward as proof authentication occurred. Biometric data never leaves the device’s secure hardware.
Binds a specific authenticated person to a specific capture, without transmitting any biometric data.
Local cryptographic hashing
SHA-256 hash of the raw photo bytes, plus a separate SHA-256 hash of canonicalized metadata (RFC 8785) — the split V2 hashing scheme.
Any change to a single pixel or metadata field produces a completely different hash — independently recomputable by anyone.
Cryptographic signature
A secp256k1 signature is generated over the exact signed payload, tied to a device-held private key.
Proves the proof was produced by the holder of a specific key — it cannot be plausibly denied after the fact.
Single-use nonce
A device-bound, single-use nonce with a 60-second TTL is issued before capture and consumed on submission.
Prevents a previously-generated proof from being resubmitted or reused to backdate a new capture.
Blockchain anchoring
Both hashes are submitted to the Sonic blockchain (EVM-compatible, sub-1-second finality) via the CaptiloProofRegistryV2 / CaptiloUnifiedRegistry contracts.
Creates a permanent, third-party-verifiable record that cannot be altered or deleted after the fact by Captilo or anyone else.
eIDAS qualified timestamp
An RFC 3161 timestamp from a certified Greek APED Trust Service Provider, submitted in parallel with the blockchain transaction.
Qualified timestamps carry legal weight under the EU eIDAS regulation. (In rare cases the TSA response is delayed or empty — the blockchain anchor still provides an independent timestamp in that event.)
Fraud detection screening
A battery of on-device checks runs before submission — swap/substitution detection, screen and print detection, geolocation-integrity checks, and device and emulator attestation. See the attack-by-attack breakdown below.
Produces a confidence score attached to the proof. Like any automated screening, it reduces risk but is not a guarantee — see the note below.
Offline captures (when applicable)
If a device is offline at capture time, the proof is time-stamped from the device clock only, with no nonce-based replay protection until it later syncs.
Offline proofs are explicitly flagged as reduced-trust in the proof record itself — nothing is hidden from a reviewer.
Independent verification
Anyone can re-upload a certificate or photo to the public verifier and have its hashes recomputed and checked against the blockchain record.
No Captilo account, no proprietary software — the proof stands on public cryptography and a public ledger.
Try it yourself
Upload any Captilo certificate and watch each of these checks run in real time.
What each attack looks like — and what actually stops it
Not every signal blocks a submission — and it shouldn't. A system that hard-rejects every imperfect signal generates false rejections in the field. Below, each defense is labeled for what it actually does: reject outright, or lower the trust score.
Swap & substitution attacks
Scenario: Swapping in a gallery photo, intercepting the file before it’s hashed, or routing a virtual/injected image into the pipeline.
- ·Capture-timing window: camera-open to photo-return must land inside ~0.5s–5min
- ·A single-use nonce, generated before the camera opens, is bound into the photo hash
- ·EXIF Make/Model must match the attested device; editing-software tags and EXIF timestamp/GPS drift are checked
- ·Sensor-noise fingerprinting, file-size/aspect-ratio checks, and device-fingerprint pinning
- ·A fresh, per-capture hardware attestation (see Jailbreak & Attestation) bound to that exact photo
Capture-timing failure or an EXIF device mismatch rejects the capture outright. Every other signal above lowers the trust score instead.
Screen & print attacks
Scenario: Photographing a screen or a printed image to produce a fake "authentic" capture.
- ·FFT moiré analysis across sampled patches — detects the interference pattern displays and dot-screen prints produce
- ·Pixel-grid autocorrelation — detects sub-pixel RGB striping typical of digital displays
- ·Accelerometer + gyroscope cross-correlation — a motionless mount reads very differently from natural hand tremor
A high-confidence moiré detection blocks submission outright — the one screen-specific hard stop in the system. The other two checks feed the combined score.
Geolocation spoofing
Scenario: Using a fake-GPS / mock-location app to misrepresent where a photo was taken.
- ·Android exposes an OS-level "mock location" flag; Captilo reads and records it on every capture
Not blocked. A flagged location sharply discounts the location component of the trust score. Android-only: iOS does not expose an equivalent signal to any third-party app, so there is no spoof flag on iOS captures today.
Jailbreak, root & device attestation
Scenario: Running Captilo on a modified OS, or using tooling to inject a fabricated image into a compromised device.
- ·Root/jailbreak status is detected and factored into the device-security score
- ·One-time device registration binds Captilo’s signing key to a hardware attestation — Apple App Attest (Secure Enclave) on iOS, Google Play Integrity on Android — verified server-side
- ·A fresh, live per-capture attestation assertion is bound to that capture’s nonce and photo hash
A root/jailbreak signal alone never blocks capture — many legitimate users run modified devices. The real defense is live, per-capture hardware attestation, which a compromised device cannot fabricate.
Emulators & virtual cameras
Scenario: Running the app in a simulator, or routing a virtual/fake camera source into the capture pipeline.
- ·A physical-device check confirms the app isn’t running in a simulator
- ·A cryptographic timing baseline flags implausibly fast (virtualized) or slow (debugger-attached) hardware
- ·Android camera enumeration flags externally-routed or virtual camera sources
Blocked outright only when a virtual camera is the sole camera present on Android with no genuine built-in camera to fall back on — a narrow condition chosen to avoid rejecting legitimate accessory cameras.
A trust score you can see
Every proof is scored on a weighted 0–100 scale, shown in the app itself rather than reduced to a pass/fail flag. Offline captures take a flat deduction. Scores fall into four bands: High, Medium, Low, and Minimal.
Honest ceiling: under normal operation today, the achievable band is Medium. The High band is reserved for a depth-sensing (LiDAR) capture mode that has not yet shipped. We'd rather state the real ceiling than round up.
What this record supports
- A mathematically verifiable statement of what the file's bytes and metadata were at the moment of anchoring.
- An immutable, third-party-checkable timestamp and blockchain record no single party can quietly alter.
- A documented, reproducible technical chain you can hand to an insurer, auditor, or your own counsel to build a chain-of-custody argument.
- An EU-qualified eIDAS timestamp recognized as legal proof of time across EU member states.
What it does not do
- It does not guarantee that any specific court, arbitrator, or insurer will admit or accept the record — admissibility depends on jurisdiction, the rules of the proceeding, and the discretion of the deciding body.
- It does not guarantee that fraud detection catches every manipulated or AI-generated image — confidence scores are a screening signal, not a verdict.
- It is not a replacement for expert witness testimony, formal forensic examination, or advice from qualified legal counsel.
See the full Disclaimer and Privacy Policy & Terms for the binding legal language.
Will this be admissible in court?
Captilo produces cryptographic integrity, timestamping, and provenance evidence that supports a chain-of-custody argument and can be submitted to a court, insurer, or auditor — not a guarantee that any specific body will admit it. Admissibility is ultimately a legal determination made by the deciding body under the rules that govern that proceeding, not something any technology vendor can promise.
What Captilo can do is make the underlying technical record as strong and as independently verifiable as possible — so that when your counsel lays the evidentiary foundation, they have real cryptography, a real blockchain record, and a real qualified timestamp to point to, not just a claim.
Evaluating Captilo for your organization?
Talk to us about standards compliance and integration details for your procurement or compliance review.