How CustodyLog Works
A complete guide to cryptographic chain-of-custody — what it proves, how it works, and why courts accept it.
Digital evidence is only admissible in court if you can prove it has not been altered since collection. CustodyLog answers that question with cryptographic certainty — not with a signature on a form, but with mathematics that cannot be forged.
Every digital file has a unique mathematical fingerprint called a SHA-256 hash — a 64-character string produced by a one-way cryptographic algorithm.
This string is computed from the entire contents of the file. Change a single byte anywhere — one character in a document, one pixel in a photo — and the hash changes completely. Two different files cannot produce the same hash. This is guaranteed by mathematics, not policy.
When you log a piece of evidence, you select the file on your local machine. CustodyLog uses the browser's built-in Web Crypto API to compute the SHA-256 hash locally.
The file never leaves your device. Only the 64-character hash string is sent to the server. This means CustodyLog itself cannot intercept, copy, or alter your evidence — a critical property for court defensibility.
Your device → [File itself] → Never leaves your machine
This is what makes CustodyLog a chain of custody, not just a log. Every time someone interacts with a piece of evidence — receiving it, transferring it, analysing it — a new entry is written to the audit log. Each entry contains a chain hash: a hash computed from all previous entries combined.
If anyone deletes or alters Entry 1, Entry 2's chain hash instantly becomes invalid. The chain breaks. Retrospective tampering is mathematically detectable — the same principle used by blockchain.
A company suspects a former finance director copied confidential client records before resigning. The hard drive from his company laptop is submitted as evidence.
DC Rachel Hammond delivers the hard drive sealed in an evidence bag. The investigator logs it in CustodyLog: item label, received from, notes on seal condition. The drive is placed in the browser file picker — SHA-256 computed locally in 4 seconds. Hash stored with timestamp.
The analyst creates a bit-for-bit forensic image using FTK Imager. The original drive is never touched again. The image is registered as a second evidence item with its own hash. A transfer log entry links the two, extending the chain.
Copies are provided to Williams & Co Solicitors. The transfer is logged in CustodyLog with the recipient name and timestamp. Chain hash updated to include this event.
The defence argues the evidence may have been altered after collection. The prosecution re-hashes the drive in court using any SHA-256 tool. Result:
The full chain audit trail — 3 entries, all chain hashes valid, no gaps — is presented to the court. The judge accepts the evidence.
Someone adds files to the drive after collection. Even one added byte changes thousands of hash positions. Re-hash in court produces a different result. MISMATCH. Evidence rejected.
Someone deletes the intake entry to hide access. Entry 2's chain hash no longer validates. Chain broken. Tampering detected.
| Standard | Requirement | CustodyLog |
|---|---|---|
| ACPO Good Practice Guide | Hash at collection, verified at each transfer | Automated |
| UK CPS Digital Evidence | Unbroken chain of custody with timestamps | Automated |
| NIST FIPS 180-4 | SHA-256 approved for security applications | SHA-256 |
| ISO 17025 / UKAS | Audit trail for all evidence handling | Full log |
| EnCase / FTK / Autopsy | Interoperable SHA-256 verification | Compatible |
SHA-256 is used by every major forensic tool. Any opposing expert can independently verify your hash using their own software — the result will be identical.
| Question | Evidence provided |
|---|---|
| Was this file altered after collection? | Hash at intake vs hash today — match or mismatch |
| Who had access to this evidence? | Full access log with names, timestamps, IP addresses |
| Was the log itself tampered with? | Chain hash sequence — any deletion breaks the chain |
| When exactly was evidence received? | UTC timestamp at intake, immutable |
| Who collected it and from whom? | Recorded at intake, linked to authenticated user account |