Building an Evidence Chain That Holds Up in Court

Digital evidence is fragile in a way that physical evidence is not. A photograph can be edited without visible traces. A database export can be modified before submission. A web page can be altered or deleted after you screenshot it. When digital evidence enters a legal proceeding — whether a local environmental lawsuit, an international human rights tribunal, or a regulatory enforcement action — the opposing party will challenge its authenticity. Without a rigorous evidence chain, even genuine evidence can be excluded. This guide explains the technical and procedural foundations of digital evidence integrity.

Chain of Custody: The Legal Framework

Chain of custody is the documentation that tracks every person who handled a piece of evidence, when they handled it, and what they did with it. In U.S. federal courts, the Federal Rules of Evidence (FRE 901(a)) require that evidence be authenticated — the proponent must produce evidence "sufficient to support a finding that the item is what the proponent claims it is." For digital evidence, this means demonstrating that the file presented in court is identical to the file that was originally collected, and that no unauthorized modifications occurred in between.

The Berkeley Protocol on Digital Open Source Investigations, published by the UN Human Rights Office and UC Berkeley's Human Rights Center in 2022, establishes the standard for OSINT evidence handling. Its key requirements:

• Record the source URL, access timestamp, and collection method at the moment of acquisition.
• Create a cryptographic hash of the file immediately upon download, before any processing.
• Store the original file in a write-once repository — the original must never be modified.
• All subsequent analysis should be performed on working copies, never the original.
• Document every access to the original in a custody log with who, when, and why.

SHA-256 Hashing: The Integrity Foundation

SHA-256 (Secure Hash Algorithm, 256-bit) produces a 64-character hexadecimal string that serves as a unique fingerprint for any file. The properties that make it suitable for evidence integrity are:

Deterministic: The same file always produces the same hash. If you hash a file today and hash the identical file in 10 years, the output will be the same.

Collision-resistant: It is computationally infeasible to find two different files that produce the same hash. The probability is approximately 1 in 2^128 — a number larger than the estimated atoms in the observable universe.

Avalanche effect: Changing a single bit of the input file produces a completely different hash. There is no way to make a "small" change that produces a "similar" hash.

# Hash a file immediately upon collection
$ sha256sum evidence_photo.jpg
a7f9e3b2c4d8f1a2e5b7c9d0f3a6e8b1c4d7f0a3e6b9c2d5f8a1...  evidence_photo.jpg

# Verify the file has not been altered
$ sha256sum evidence_photo.jpg
a7f9e3b2c4d8f1a2e5b7c9d0f3a6e8b1c4d7f0a3e6b9c2d5f8a1...  evidence_photo.jpg
# Hashes match — file integrity confirmed

# If the file were modified (even one pixel changed):
$ sha256sum evidence_photo_modified.jpg
3c1f8a2b9e4d7c0a6f3b8e1d5c2a9f7e4b0d3a6c9f2e5b8a1d4...  evidence_photo_modified.jpg
# Completely different hash — modification detected

For legal purposes, you should hash every evidence file at three stages: (1) immediately upon collection, (2) upon ingestion into your evidence management system, and (3) upon export for submission. If all three hashes match, you have demonstrated integrity across the entire custody chain.

HMAC Signing: Proving Who Hashed It

A plain SHA-256 hash proves that a file has not been altered, but it does not prove who computed the hash or when. Anyone can compute the SHA-256 hash of any file. To establish attribution, use HMAC (Hash-based Message Authentication Code), which combines the hash with a secret key:

HMAC-SHA256(key, message) = SHA256((key XOR opad) ||
                             SHA256((key XOR ipad) || message))

The key is known only to the signer. If you publish the HMAC value, anyone with the key can verify it, but no one without the key could have produced it. In an organizational context, the HMAC key is held by the evidence custodian and used to sign each evidence file upon intake. This creates a cryptographic proof that a specific organization's custodian acknowledged possession of the file at a specific state.

For higher-assurance scenarios, asymmetric cryptographic signatures (RSA, ECDSA) provide non-repudiation: the signer cannot later deny having signed. PGP/GPG signatures are widely accepted in investigative journalism for this purpose.

RFC 3161 Timestamping: Proving When

A hash proves the file has not been modified. An HMAC proves who signed it. But neither proves when the hash was computed. This is where trusted timestamping enters the picture.

RFC 3161 defines a protocol where a client sends a hash to a Time Stamping Authority (TSA), and the TSA returns a signed timestamp token that binds the hash to a specific time. The TSA does not see the original file — only the hash — preserving confidentiality.

# Generate a timestamp request
$ openssl ts -query -data evidence_photo.jpg \
    -sha256 -no_nonce -out request.tsq

# Submit to a free TSA (FreeTSA.org)
$ curl -H "Content-Type: application/timestamp-query" \
    --data-binary @request.tsq \
    https://freetsa.org/tsr \
    -o response.tsr

# Verify the timestamp
$ openssl ts -verify -data evidence_photo.jpg \
    -in response.tsr -CAfile cacert.pem
Verification: OK

The timestamp token is signed by the TSA's certificate, which chains to a trusted root CA. This means a third party (the TSA) has attested that the hash existed at the stated time. FreeTSA.org provides free RFC 3161 timestamps suitable for most purposes. For high-stakes legal proceedings, use a TSA accredited under eIDAS (in the EU) or operated by a recognized institution.

OpenTimestamps: Bitcoin-Anchored Proof

RFC 3161 timestamps depend on trusting the TSA. If the TSA is compromised, its timestamps can be forged. OpenTimestamps removes this trust dependency by anchoring proofs in the Bitcoin blockchain.

The protocol works by aggregating many timestamp requests into a Merkle tree, computing the root hash, and embedding that root hash in a Bitcoin transaction. Because the Bitcoin blockchain is append-only and maintained by a decentralized network, the timestamp is as durable and tamper-proof as Bitcoin itself.

# Create an OpenTimestamps proof
$ ots stamp evidence_photo.jpg
# Creates evidence_photo.jpg.ots

# Wait for Bitcoin confirmation (typically 1-2 hours)

# Verify the timestamp
$ ots verify evidence_photo.jpg.ots
Success! Bitcoin block 875234 attests data existed
as of 2026-02-14T15:23:00Z

The practical advantage of OpenTimestamps is permanence. An RFC 3161 TSA might go out of business, lose its keys, or be compelled to falsify timestamps. The Bitcoin blockchain will exist as long as the Bitcoin network exists, and the timestamp proof is independently verifiable by anyone who has a copy of the blockchain. The ICC's Office of the Prosecutor has accepted OpenTimestamps-anchored evidence in preliminary examinations.

Metadata Stripping for Source Protection

Evidence integrity and source protection are sometimes in tension. A photograph's EXIF metadata contains the camera model, serial number, GPS coordinates, and timestamp — all valuable for evidence authentication but potentially dangerous for source identification. If the source is a whistleblower who took the photo with their personal phone, the EXIF data can identify them.

The resolution is to maintain two versions of each evidence file: the original (with full metadata, stored in your sealed evidence archive) and a redacted version (with identifying metadata stripped, used for publication and sharing). The hash chain covers both:

Evidence Record:
  Original file:    evidence_photo.jpg
  Original SHA-256: a7f9e3b2c4d8...
  Redacted file:    evidence_photo_redacted.jpg
  Redacted SHA-256: 5c2a9f7e4b0d...
  Redaction method: exiftool -all= (EXIF stripped)
  Redacted by:      J. Reporter
  Redaction date:   2026-02-14T16:00:00Z
  Note: Original preserved under seal; redacted version
        for public filing. Court may inspect original
        in camera upon request.

Use exiftool -all= photo.jpg to strip all EXIF data, or MAT2 (Metadata Anonymisation Toolkit) for comprehensive metadata removal across file types including PDFs, Office documents, and audio files.

Submission Formats for International Courts

Different legal venues have different requirements for digital evidence submission:

International Criminal Court (ICC): The Office of the Prosecutor accepts digital evidence through its portal. The expected format includes the evidence file, a SHA-256 hash, a chain of custody declaration, and a provenance statement describing the collection methodology. The Berkeley Protocol is explicitly referenced in ICC guidance documents.

European Court of Human Rights (ECHR): Digital evidence is submitted as annexes to written observations. The Court accepts PDF, JPEG, and common video formats. Evidence should be accompanied by a declaration of authenticity from the submitting party. While the ECHR does not mandate specific hash algorithms, providing SHA-256 hashes strengthens the submission.

U.S. Federal Courts: Under FRE 902(14), added in 2017, electronically stored information authenticated by a qualified person's certification can be self-authenticating. The certification must describe the hash algorithm, the hash value, and the circumstances of collection. Many federal judges now accept SHA-256 hashes as sufficient authentication for digital files.

Domestic regulatory proceedings: EPA enforcement actions, SEC investigations, and state environmental proceedings generally have less formal requirements but benefit from the same evidence discipline. An EPA administrative law judge is more likely to credit evidence presented with hashes and timestamps than bare screenshots.

Putting It All Together

A complete evidence integrity pipeline for a single file looks like this:

1. Collect the evidence. Record the source URL, access timestamp, and your identity as collector.
2. Hash the file immediately with SHA-256.
3. Timestamp the hash using both RFC 3161 (for immediate verification) and OpenTimestamps (for long-term durability).
4. Sign the hash with HMAC or GPG to bind it to your identity.
5. Store the original in a write-once archive (WORM storage, or at minimum an append-only directory with restricted write access).
6. Log every subsequent access in a custody register.
7. Redact identifying metadata for any publicly shared version, preserving the original under seal.
8. Export with a verification package: the file, its hash, the timestamp proof, and a custody declaration.

This process adds perhaps five minutes per evidence item. But it transforms a digital file from something that a defense attorney can dismiss as "possibly manipulated" into something that carries cryptographic proof of its integrity from the moment of collection to the moment of submission. That distinction has decided cases.