The Problem

Surveillance video has been treated as reliable evidence for decades. Three converging threats are undermining that assumption:

1. AI-Generated Deepfakes

Generative AI can produce photorealistic video of events that never happened. The technology is accessible, improving rapidly, and the output is increasingly hard to distinguish from genuine footage.

2. Unencrypted Camera Streams

The majority of IP cameras transmit video over RTSP — an unencrypted protocol. Man-in-the-middle attacks can intercept and replace live camera feeds. Over 4.6 million cameras expose RTSP streams on the public internet.

3. Export-Time Watermarking

Major NVR manufacturers market proprietary formats as "tamper-proof." These formats have been reverse-engineered. Their watermarking typically applies checksums at export time — not during recording. Modifications before export bypass the watermark.

How Our System Responds to Each Threat

Deepfakes — SHA-256 hashing at recording time with blockchain-anchored timestamps. We can prove a specific recording existed in a specific form by a specific time. We cannot prove the camera captured reality truthfully — that remains a limitation (see Threat Model).

Unencrypted Streams — RTSPS (RTSP over TLS) with auto-detection during camera provisioning and trust-on-first-use certificate pinning. Encrypts the stream between camera and NVR. Note: TOFU pinning trusts the first connection — a first-connection interception remains a risk.

Export-Time Watermarking — Inline hashing during recording via our HashingFileStream wrapper. Every byte is hashed as it's written to disk. The hash, ECDSA signature, and blockchain proof are committed before anyone can tamper with the recording.

Threat Model: What We Protect Against — and What We Don't

This system provides recording integrity (proving footage wasn't altered after capture) and provenance (proving when and where a recording was attested). It is not a complete proof that the camera captured reality truthfully.

What we protect against

Post-recording tampering (any byte change detected)
Export-time manipulation (hash committed during recording)
Insider alteration after recording (signed + on-chain)
Retroactive evidence replacement (blockchain timestamp)
Stream interception (RTSPS encryption, when enabled)
Silent file deletion (attested hashes survive on-chain)

What we do not fully solve

Camera sensor spoofing (e.g., pointing at a screen)
Compromised camera firmware (malicious encoder)
Compromised NVR before hashing begins
First-connection TOFU interception (RTSPS)
Staged scenes (genuine but misleading footage)
Camera identity without device-origin signing

Where we are vs where the industry is heading

Today, our NVR is the root of trust — it hashes whatever the camera sends. The ONVIF Media Signing Specification (December 2024) defines a stronger model: device-origin signing with camera-held certificates and signed media semantics. As cameras adopt this spec, the root of trust moves from the NVR to the camera hardware itself. Our architecture is designed to incorporate ONVIF media signing when cameras support it, strengthening the provenance chain from "NVR attests" to "camera attests."

Architecture

The system creates a verifiable record that a specific file existed in a specific form by a specific time. Each layer adds a property:

1. Camera captures video (any make, any model)
       |
2. NVR receives stream (RTSPS encrypted when supported)
   +-- Every byte hashed inline via HashingFileStream (SHA-256)
   +-- Every ~2 sec: GOP hash computed and chained
       |
3. Segment closes (~4 minutes)
   +-- ECDSA-P256 signature over segment hash
   +-- Forward hash chain computed from all GOPs
   +-- Hash + signature + chain stored in database
       |
4. Every 5 minutes: Merkle tree built from all new hashes
   +-- One root hash covers hundreds of segments
       |
5. Merkle root posted to Sui blockchain
   +-- Immutable frozen object
   +-- Cost: ~$0.003 per batch
       |
6. Proof bundle exported with recording
   +-- Self-contained: hash, signature, Merkle path, Sui object ID
   +-- Verifiable by anyone with a SHA-256 tool + Sui RPC access

Inline Hashing During Recording

SHA-256 hashing of every byte as it's written to disk — not after recording, not at export time. We use a composition wrapper around .NET's FileStream that feeds data to both the disk and an IncrementalHash simultaneously. When the file closes, the hash is already computed with zero extra I/O.

Zero extra I/O — hashing is a byproduct of writing
Works with any camera — the NVR does the hashing, not the camera
Negligible CPU cost — SHA-256 runs at 2-4 GB/s; 64 cameras at 4 Mbps = 32 MB/s, well under 2% of hash throughput

The result: a 32-byte hash that uniquely identifies the recording contents. Change any byte and the hash is completely different. This hash is the foundation for everything that follows.

GOP Hash Chains

A segment hash proves the whole file is intact. GOP-level hashing adds granularity — each Group of Pictures (~2 seconds) gets its own hash, linked in a forward chain:

GOP 1: hash_1 = SHA256(video_data_1)
GOP 2: chain_2 = SHA256(chain_1 || hash_2)
GOP 3: chain_3 = SHA256(chain_2 || hash_3)
  ...
GOP N: chain_N = SHA256(chain_{N-1} || hash_N)  -- ECDSA signed

If someone replaces GOP #5 with different footage, the chain breaks from #5 onward — pinpointing exactly which section was altered. This is structurally similar to how blocks in a blockchain reference their predecessors.

This aligns with the ONVIF Media Signing Specification, which defines per-GOP hashing with ECDSA signatures. Our signatures are currently stored in the recording index file; a future phase will embed them as SEI NAL units in the video stream for full ONVIF interoperability.

Merkle Tree Batching

Posting every segment hash individually to the blockchain would be expensive. Instead, we batch hashes into a Merkle tree every 5 minutes:

                    Merkle Root (32 bytes) -- posted to blockchain
                   /                      \
              Hash(AB)                Hash(CD)
             /        \              /        \
        Hash(A)    Hash(B)    Hash(C)    Hash(D)
          |          |          |          |
       Cam1-Seg1  Cam1-Seg2  Cam2-Seg1  Cam3-Seg1

One transaction covers hundreds of segments. To verify any individual segment, a verifier needs only the segment hash plus the sibling hashes along the path to the root (the "Merkle proof"). This is the same batching pattern used by Layer 2 rollups in blockchain systems.

Cost: ~$0.003 per batch. For 100 cameras recording 24/7 with 5-minute batches: ~$25/month.

Sui Blockchain Attestation

The Merkle root is posted to the Sui blockchain as a frozen object — an on-chain record that cannot be modified or deleted by anyone after creation.

Why Sui

Sub-second finality — proof is confirmed quickly
Low cost — ~$0.003 per transaction
freeze_object — a Sui primitive that makes an object permanently immutable
Publicly queryable — anyone with a Sui RPC endpoint can read the proof

Our attestation contract stores the Merkle root, leaf count, time range, and recorder address. The contract is currently deployed on Sui testnet at 0x4d7a82...b939a9 .

Note: This is a development demo on Sui testnet. Testnet data may be reset. For production evidence use, deployment to Sui mainnet with a documented retention policy is required.

Self-Contained Proof Bundles

When evidence is exported, it includes a JSON proof bundle containing everything needed for independent verification — no access to Video Armed systems required:

{
  "format": "video-armed-proof-v1",
  "file": {
    "sha256": "a1b2c3d4...",      // hash of the video file
    "codec": "h265"
  },
  "signing": {
    "algorithm": "ECDSA-P256-SHA256",
    "signature": "base64...",       // ECDSA signature over file.sha256
    "public_key_pem": "-----BEGIN PUBLIC KEY-----\n..."
  },
  "merkle_proof": {
    "leaf_hash": "a1b2c3d4...",
    "proof_path": [                 // sibling hashes to reconstruct root
      { "hash": "d4e5f6...", "position": "right" },
      { "hash": "a7b8c9...", "position": "left" }
    ],
    "root_hash": "m1n2o3p4..."
  },
  "blockchain": {
    "chain": "sui",
    "network": "testnet",
    "object_id": "0x006c08ee...",   // query any Sui RPC node
    "rpc_url": "https://fullnode.testnet.sui.io:443"
  },
  "verification_steps": [
    "1. Compute SHA-256 of the video file",
    "2. Verify ECDSA signature using the embedded public key",
    "3. Walk the Merkle proof path to reconstruct the root",
    "4. Query the Sui object and verify root_hash matches",
  ]
}

A verifier with this bundle and the video file can independently confirm integrity using any SHA-256 implementation, any ECDSA-P256 library, and any Sui RPC endpoint. No proprietary tools. No connection to our servers.

Camera name is included by default (useful context for the recipient) but can be omitted by the operator for privacy. No customer IPs, hostnames, or network information are included. The on-chain data contains only hashes and timestamps — no identifying information.

Encrypted Evidence Storage

Evidence clips can optionally be encrypted and stored on Walrus, a decentralized storage network. Files are encrypted with AES-256-GCM before upload. Access is controlled via RSA key wrapping (for internal operators) or Sui-based access policies (for external sharing).

Walrus storage is an optional layer — not required for the integrity/attestation features. Standard cloud storage (S3, etc.) continues to work. Walrus adds decentralized redundancy and eliminates single-point-of-failure risk for critical evidence.

Verification

Two verification paths:

Quick (API-assisted)

Upload a video file to the verification portal. The browser computes SHA-256, queries our attestation API for the matching proof, and displays the result with a Sui Explorer link.

Depends on our API being available.

Independent (proof bundle)

Given the video file and the proof JSON, verify entirely independently: compute the hash, check the ECDSA signature, walk the Merkle proof, query any Sui RPC node for the anchor object. No connection to Video Armed systems required.

Requires only standard crypto tools + Sui RPC.