How it works

From capture to
cryptographic proof

Cyrify breaks the digital evidence infrastructure lifecycle into four steps. Each contributes to tamper-evident capture, device attestation, and structured digital provenance.

1. Capture

Capture is where media first enters your system. Clients capture photos, videos, or files with minimal structured context: timestamps, rough location, and app identifiers. Cyrify defines how the resulting event feeds into a tamper-evident capture process.

2. Sign

Bytes and metadata are hashed and signed—on-device, in a secure enclave, or server-side. When available, device attestation tokens are bound to the signing event, adding evidence around content authenticity.

3. Verify

The authenticity verification API recomputes hashes, checks signatures, evaluates attestation tokens, and returns a structured decision. Status values like VERIFIED, UNVERIFIABLE, or TAMPERED are about technical checks only.

4. Anchor optional

Proofs can be anchored to an append-only ledger or blockchain. Cyrify encourages anchoring only succinct summaries—Merkle roots—rather than raw media, to preserve privacy while strengthening chain of custody.

Data flow

Simplified architecture

Client

Capture app

Sign

Hash + attest

Cyrify

Store proof

Verifier

Review system

Verify API

Recompute

Decision

Status + risk

Your storage

Media archive / object store

Optional ledger

Merkle roots for chain of custody

Example

Proof object

Cyrify represents verification artifacts as structured JSON. Production schemas will be versioned as part of the authenticity verification API.

proof-object.json

{
  "proof_id": "prf_01hv2c9g4pwh9z2x6a",
  "created_at": "2026-03-05T10:15:43Z",
  "media": {
    "sha256": "bb9e...4fd2",
    "mime_type": "image/jpeg"
  },
  "integrity": {
    "signature": "MEUCIQD4xvGq...",
    "algorithm": "ecdsa-p256-sha256"
  },
  "attestation": {
    "present": true,
    "provider": "device-attestation",
    "risk": "LOW"
  },
  "verification": {
    "status": "VERIFIED",
    "checks": {
      "hash_match": true,
      "signature_valid": true,
      "attestation_valid": true
    }
  }
}

Failure modes

Explicit failure states

Cyrify makes failure states explicit so they can be interpreted correctly in your workflows.

Failure mode	Typical cause	Implication
Missing attestation	No attestation token provided.	Integrity checks still run, but device attestation guarantees unavailable.
Integrity mismatch	Hash doesn't match stored proof.	File changed since tamper-evident capture. Strong signal of compromise.
Unverifiable signature	Missing key, wrong algorithm, data drift.	Evidence is UNVERIFIABLE—distinct from "tampered".
Expired keys	Signing keys no longer trusted.	Historical proofs may still be useful with policy adjustments.
Anchoring gaps	Expected ledger record missing.	Chain of custody is weaker for multi-party disputes.

Even "VERIFIED" is about technical properties. Real decisions may require human review and domain-specific judgment.

From capture tocryptographic proof