Chain of custody for photographic evidence

«Chain of custody» is one of those phrases everyone uses and few define. It does not mean filling in a form. It means one thing: being able to show that, between the moment of the event and the moment the evidence is examined, nobody could alter it without leaving a trace.

Why it is the decisive point

Digital evidence has an awkward property: it is perfectly copyable and perfectly modifiable. There is no digital equivalent of paper grain or fading ink. An altered file does not «look» altered.

It follows that trust cannot rest on the object, but on the path. If the path is documented and sealed, the file is credible; if the path has gaps, every gap is a handhold for the other side — and they need not prove tampering occurred, only show it would have been possible.

The question is not «was this photo altered?». It is «could someone have altered it without it showing?». If the answer is yes, the argument is already lost.

The reference: ISO/IEC 27037

ISO/IEC 27037:2012 sets out guidelines for identification, collection, acquisition and preservation of digital evidence. It is the international reference for the field, and its four phases map precisely onto what happens in a sealed capture.

The detail that makes the difference is how much time passes between collection and acquisition. In the traditional flow — shoot, then download, then «certify» — that window can last hours or days, and it is exactly the window a challenge leans on. Sealing at capture reduces it to fractions of a second, inside a single automated process.

The package: BagIt RFC 8493

Evidence is not just the file: it is the file plus everything documenting it. So a container is needed, and a standard one exists: BagIt, specified in RFC 8493 and originating at the Library of Congress for reliable transfer of digital archives.

The structure is simple and readable at a glance: a data/ folder holding the actual content, alongside a few supporting files declaring what the package contains and with which fingerprint. It is not a proprietary format: anyone can open it, ten years from now, without the software that created it.

Nested seals

The mechanism works in layers, each covering the one before:

The manifest lists every content file with its SHA-256 fingerprint. It verifies that no file has been modified. There is also the reverse check, less obvious and equally important: that no file has been added quietly, since everything in data/ must be declared.

The tagmanifest does the same for the supporting files — including the manifest itself and the forensic metadata. It covers, in short, everything outside the content. Worth being precise here, because this is a mistake LOCUS actually made and then fixed: in an earlier version the forensic metadata sidecar sat outside the seal. Today the tagmanifest is generated dynamically over every file present, so nothing can escape it. Bundles produced before the fix retain that limitation: there is no possible backwards compatibility on a seal.

The Ed25519 signature binds the manifest to a device key registered on first use. It prevents recombining pieces from different acquisitions.

The two timestamps close it: one on the media, one on the tagmanifest. The second is what fixes the whole package in time.

A note of transparency about the signature

The private signing key resides in the application's protected storage on the device. It is not held in a hardware vault — Secure Enclave or equivalent — and that is a real, declared limitation: migrating to hardware-backed keys is a goal, not the present state. Anyone assessing the tool should know it, and it is worth repeating here rather than leaving it to be discovered.

The mitigating point is that the signature is not the only guarantee: even granting a compromised key, the external authorities' timestamps remain, and nobody can backdate those. The guarantees are deliberately redundant precisely so that no single link is decisive.

Interoperability: CASE/UCO

A forensic package nobody can read is a problem deferred. That is why the bundle includes a metadata file in CASE/UCO format (Cyber-investigation Analysis Standard Expression), the standard adopted across international investigative practice and supported by the main forensic analysis tools.

It means the file can be imported into the tools an expert already uses, without manual conversion and without depending on us. It is also a guarantee against lock-in: the evidence stays yours, in a format that outlives the vendor.

The distinction that avoids embarrassment

A clarification often missing. There is a technical chain of custody — fingerprints, seals, timestamps — and a procedural chain of custody: who operated, with what standing, under which rules.

An impeccable cryptographic seal does not replace the second. If the acquisition breached procedural rules, or was carried out by someone without standing, technical soundness will not rescue it. Under Regulation (EU) 2016/679 (GDPR), moreover, capturing identifiable people or private premises engages obligations that no amount of sealing satisfies: lawfulness of processing is a separate question from integrity of the file.

The technical chain does one thing, and does it well: it supplies an object on which a check can actually be performed, instead of leaving integrity as a matter of assertion. It does not decide admissibility — courts assess that case by case, and no tool can guarantee it in advance.

How it is verified

The point of all this is that whoever checks should not have to trust whoever produced the evidence. The bundle carries the means to do so, and it is designed for two different readers.

A judge can check it unaided, with nothing to install: open the interactive verification file that sits inside the package in a browser, and see whether the fingerprints match.

A court-appointed expert goes much deeper: rebuild the bundle, recompute every file's fingerprint and compare it against the ones signed in the manifest, check the package for completeness, walk through the capture logs, and verify timestamps and signature with standard tools — shasum, openssl — that we did not write.

In both cases the outcome is binary: the fingerprints match or they do not. That is the difference between an expert report that concludes with a finding and one that concludes with «it cannot be established». The full path is on the how to validate a bundle page.

Continue with how to prove a photograph has not been edited and the date of a photo.