Hashing, logging and chain of custody

The chain of custody is the documented, unbroken record of who held an exhibit, when, where and why, from seizure to court. In crypto cases it has to cover two kinds of exhibit at once: data, whose integrity a hash can prove, and secrets such as seed phrases and private keys, which are evidence and also give control of money. A gap in either record invites the question every examiner dreads: "How do you know this is the same thing you seized?"

Cryptographic hashes for evidence

A cryptographic hash function turns any input into a fixed-length digest. The same input always gives the same digest, and changing a single bit of the input changes the digest beyond recognition. For evidence the important properties are second-preimage resistance (given a file, no one can make a different file with the same digest) and collision resistance (no one can make any two different files with the same digest).

SHA-256, defined in the Secure Hash Standard (FIPS 180-4), is the usual choice today. Older algorithms are still common in legacy tools and older cases. Researchers demonstrated practical collisions for MD5 in 2004 and for SHA-1 in 2017, and NIST announced in December 2022 that it would phase out SHA-1 completely by 31 December 2030. A collision attack lets someone prepare two different files in advance with the same digest; it does not let them forge a match for an exhibit that was hashed honestly at seizure. Still, use SHA-256 or stronger for new work, and if your tools also record MD5 or SHA-1 for compatibility, treat SHA-256 as the value that counts.

Input (UTF-8, no trailing newline): abc
SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Input: Exhibit CF-2026-041-03: hardware wallet, seal 0048213
SHA-256: eaa2d8a848521b2018364712b541d338781444a09a8b5f5778566057ea3ee481

Input: Exhibit CF-2026-041-03: hardware wallet, seal 0048218
SHA-256: 236a8c2809dedff8531466512bff46cd9ac8c59f5c7f7e31e28277735323e675

Input: the line above ending in 0048213, followed by one line feed
SHA-256: 0e8e8fe57a4425e010f8e399d1aba1ce793951c1cc8095569819ef54e3202ed6

The first digest is the standard test value for "abc", which you can use to check any hashing tool. The next two inputs differ in one digit and their digests share nothing. The last shows that an invisible line feed is enough to change the digest. In practice this means: hash the file exactly as received, never a copy that a spreadsheet or text editor has opened and saved, because re-saving can change line endings, encoding or date formats.

A matching hash proves that a copy is bit-for-bit identical to what was hashed earlier. It does not prove that the content is authentic, complete or correctly interpreted. A provider export with a perfect hash can still contain the provider's errors, which is why the lesson Exchange and cloud accounts as evidence treats authentication as a separate step.

When to hash

Hash at every point where integrity could later be questioned:

1. At acquisition: hash the source where possible and the copy, and confirm they match. For a raw (bit-stream) image of a drive the two values are identical; container formats store the source hash inside the container.
2. On receipt: hash files received from providers, colleagues or other agencies as soon as they arrive, and record how they arrived (portal, encrypted transfer, physical media).
3. Before and after analysis: confirm the working copy still matches the master.
4. At export and disclosure: hash the evidence package you hand over (see the lesson Preserving on-chain evidence).
5. Periodically in storage: fixity checks detect silent corruption of archives and backups.

The evidence log

Each exhibit gets one record in the evidence log, which grows as the exhibit moves and is examined. A JSON record keeps it structured and machine-checkable.

{
  "exhibit_id": "CF-2026-041-01",
  "description": "Laptop, silver, serial ending 7Q2M",
  "authority_ref": "AUTH-2026-118",
  "seized": {"by": "Officer B", "utc": "2026-10-09T06:40:00Z", "seal": "0048211"},
  "acquisition": {
    "by": "Examiner E", "utc": "2026-10-11T08:12:00Z",
    "method": "SOP-IMG-02 v3, hardware write blocker WB-04",
    "tool": "imaging tool v4.2, validation record VAL-07",
    "image_file": "CF-2026-041-01.dd",
    "source_sha256": "1d89…ab85", "image_sha256": "1d89…ab85", "match": true
  },
  "custody": [
    {"utc": "2026-10-09T09:15:00Z", "from": "Officer B", "to": "Custodian D",
     "reason": "booked in", "seal_intact": true, "location": "Store 1, shelf 4"}
  ]
}

The record links the exhibit to the legal authority under which it was seized, the seal applied at the scene, the method and validated tool used to image it, and the matching source and image hashes (shortened here for print). The custody array gains one entry per transfer. Keep the master image on write-once storage and analyze only working copies, re-hashing them against the master.

Custody transfers

A custody entry should answer six questions: who handed over, who received, when (UTC), where, why, and in what condition, including whether the seal was intact and its number. ISO/IEC 27037 includes an informative annex on the minimum documentation for evidence transfers. Both parties sign, on paper or electronically.

Digital exhibits complicate the picture because they can be copied. Record which copy moved: the master, a working copy or an export. When data travels electronically, use an encrypted channel, send the hash separately, and have the receiver hash on arrival and record the match. A copy that reaches its destination with a different hash is not "nearly the same". It is a different file until explained.

Storage and access control

Physical exhibits go into a controlled evidence store with a booking register, restricted keys or badges, and tamper-evident bags whose seal numbers appear in the log. Digital evidence needs the equivalent:

• a dedicated evidence store, separate from general office systems, with role-based access;
• write-once or immutable storage for masters, and access logging for every read;
• encryption at rest, with keys held by the unit rather than one person;
• backups in a second location, checked with the same hashes;
• retention and disposal rules, with each disposal recorded.

Seed phrases and keys as evidence

A seed phrase on a card, a private key in a file or a hardware wallet is both an exhibit and a bearer instrument: whoever reads it can move the funds. Handling rules follow from that dual nature.

• Secure the funds first, under the authority you hold, by moving them to an agency-controlled wallet (see the lesson Securing seized crypto-assets). Until then, every person who sees the secret is a risk to the assets and to the evidence.
• Never copy the words or keys into notes, logs, reports or case photographs. Photograph the sealed bag, not the card. Record a non-secret identifier instead: for example, the first receiving address at a stated derivation path, or the wallet's master key fingerprint (see the lesson Wallet recovery under lawful authority).
• Apply dual control: two named people present whenever a seal is broken, both recorded, and the exhibit resealed with a new seal number.
• Store it like cash: in a safe within the evidence store, with its own access log.
• After the funds are moved, the secret keeps its evidential value (it shows who could control the wallet) but should be treated as compromised.

A worked custody log

Exhibit CF-2026-041-04 is a seed card found with the hardware wallet.

Reading it as a reviewer would:

1. Entries 1 to 3 are complete: each transfer has two parties, a time and a seal check.
2. Entry 4 is the weak point. The seal was broken with only one signature, contrary to dual control. Either a second person was present and was not recorded, or nobody else was.
3. Between entries 4 and 5 the card spent more than two days with the examiner, with no location recorded.
4. The fix is not to rewrite the log. The examiner adds a dated supplementary entry: who else was present at 14:05 (if anyone, with that person's own statement), where the card was stored until 12 October, and the access record for that safe. The report states the gap and its explanation, and the transfer txid lets anyone confirm on-chain when the funds moved.

A gap that is disclosed and explained is usually survivable. A gap that the defense finds first is far more damaging.

Exam focus: what chain of custody must show; hash properties for evidence (second-preimage and collision resistance) and SHA-256 under FIPS 180-4; MD5 and SHA-1 collisions and the NIST plan to retire SHA-1 by 2030; why a single changed byte or line ending changes the digest, and hashing files as received; what a matching hash does and does not prove; when to hash; the fields of an evidence log record; the six questions of a custody transfer and hash checks for electronic transfers; seed phrases as bearer instruments (secure funds first, never record the secret, dual control, non-secret identifiers); spotting and remedying a custody gap without rewriting the record.