Hashing, logging, chain of custody and quality management

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 covers 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?" Behind each exhibit sits a second question: do the unit's results depend on luck or on one person? Quality management answers it with validated methods, tested staff, review, error correction and written records, which courts and defense experts increasingly ask to see. Lesson 8.1 introduces the ISO/IEC standards family and Lesson 3.6 the testing of individual tools; this lesson covers the records that make both hold up.

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 one bit 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. Practical collisions were demonstrated for MD5 in 2004 and 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 hashed honestly at seizure. Still, use SHA-256 or stronger for new work, and if 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 0048212
SHA-256: 65c7617d568df1b7356261ba71c236e0ab488bf248e9647e335420c0fd82c7cc

Input: Exhibit CF-2026-041-03: hardware wallet, seal 0048217
SHA-256: 6f6f9af5cad09aa305273d9f214476f35336d839a08fbab33dce7edac5a3f051

Input: the line above ending in 0048212, followed by one line feed
SHA-256: 888e31c4c49eadae5afe51cec975ea78356ea105c5c9a239c0dd83d94c6ca62d

The first digest is the standard test value for "abc", useful for checking any tool; one changed digit or an invisible line feed gives an unrecognizable digest. Hash a 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 Lesson 7.5 treats authentication as a separate step.

Hash wherever integrity could later be questioned: at acquisition (source and copy, confirming they match; for a raw bit-stream image the two values are identical, and container formats store the source hash inside); on receipt of files from providers, colleagues or agencies, recording how they arrived; before and after analysis, checking the working copy against the master; at export and disclosure (Lessons 8.2 and 8.4); and periodically in storage, as fixity checks against silent corruption.

The evidence log and custody transfers

Each exhibit gets one record in the evidence log, which grows as the exhibit moves and is examined. A structured record is 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 tool entry points to a validation record: that is where custody meets quality management. Keep the master image on write-once storage and analyze only working copies.

A custody entry answers 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 minimum documentation for transfers. Both parties sign. Digital exhibits can be copied, so record which copy moved: master, working copy or export. For electronic transfers, use an encrypted channel, send the hash separately, and have the receiver hash on arrival. A copy that arrives with a different hash is not "nearly the same"; it is a different file until explained.

Physical exhibits go into a controlled store with a booking register and tamper-evident bags whose seal numbers appear in the log. Digital storage needs the equivalent: a dedicated store with role-based access, write-once masters and logged reads, encryption with keys held by the unit rather than one person, hash-checked backups in a second location, and recorded disposal.

Seed phrases and keys as evidence

A seed card, a private key file or a hardware wallet is both an exhibit and a bearer instrument: whoever reads it can move the funds.

• Secure the funds first, under the authority you hold, by moving them to an agency-controlled wallet (Lesson 10.2).
• Never copy the words or keys into notes, logs, reports or photographs. Photograph the sealed bag, not the card. Record a non-secret identifier, such as the first receiving address at a stated derivation path or the master key fingerprint (Lesson 7.4).
• Dual control: two named people present whenever a seal is broken, both recorded, and a new seal applied.
• Store it like cash, in a safe with its own access log. After the move, the secret keeps evidential value (it shows who could control the wallet) but is treated as compromised.

A worked custody log for seed card CF-2026-041-04:

Entries 1 to 3 are complete. Entry 4 breaks dual control (one signature on a broken seal), and for more than two days afterwards the card's location is unrecorded. The fix is not to rewrite the log. The examiner adds a dated supplementary entry naming anyone else present at 14:05 (with that person's statement), where the card was kept until 12 October, and the safe's access record. The report states the gap and its explanation, and the txid lets anyone confirm on chain when the funds moved. A gap disclosed and explained is usually survivable; one the defense finds first is far more damaging.

The quality framework

ISO/IEC 17025:2017 specifies "the general requirements for the competence, impartiality and consistent operation of laboratories"; digital forensic units are commonly accredited against it. International accreditation guidance, Modules in a Forensic Science Process, explains how it applies to forensic work, digital evidence included (and ISO/IEC 17020 to inspection-type work such as scene examination).

ISO/IEC 27041:2015 guides showing that methods are "fit for purpose"; ISO/IEC 27042:2015 covers analysis and interpretation, including recording enough for "independent scrutiny" and demonstrating team competence. The ISO 21043 forensic science series gained parts on analysis, interpretation and reporting in 2025.

Validated methods

ISO/IEC 17025 distinguishes verification (the unit can perform an established method correctly) from validation (a method the unit developed, adapted or uses outside its scope is fit for purpose). Much of crypto forensics needs validation, because tools and heuristics change faster than any standard method. Define each method at the level a report relies on, such as "extracting ERC-20 transfers for an address from a node". Its validation record states requirements, ground-truth test data (the unit's own test transactions, a public dataset, a second method), acceptance criteria set before testing, results and limitations, and re-validation triggers: a new tool version, a protocol upgrade, a new token type.

A common test compares a tool's output with a reference extracted directly from a node. Both tables follow the token_transfers layout of Lesson 2.7:

-- Transfers the tool missed (tool side null) or invented (reference side null)
SELECT COALESCE(r.transaction_hash, t.transaction_hash) AS transaction_hash,
       COALESCE(r.log_index, t.log_index)               AS log_index,
       CASE WHEN t.transaction_hash IS NULL THEN 'missing in tool'
            WHEN r.transaction_hash IS NULL THEN 'extra in tool'
            ELSE 'amount differs' END                   AS finding
FROM reference_transfers r
FULL OUTER JOIN tool_transfers t
  ON t.transaction_hash = r.transaction_hash AND t.log_index = r.log_index
WHERE t.transaction_hash IS NULL OR r.transaction_hash IS NULL
   OR t.amount_raw <> r.amount_raw;

The full outer join keeps rows that appear on either side only, so the query lists every transfer the tool missed, every transfer it reported that the node does not contain, and every amount mismatch. Suppose the reference holds 1,284 transfers and three rows come back, all from a fee-on-transfer token where the tool reports the amount sent rather than received. The record states that limitation, and examiners check that token type by hand.

Review, competence and error management

Before a report leaves the unit, technical review by a second qualified examiner checks that data supports each finding, the method was right and correctly applied, alternatives were considered and confidence language goes no further than the evidence. Administrative review checks txids, exhibit numbers, units and dates. For findings a case turns on, blind verification has a second examiner repeat the key step without seeing the first conclusion. Disagreements are resolved and recorded, never erased.

Competence is documented per person and per method: training, supervised casework, a competence test and formal authorization. Results are monitored through proficiency tests (a known-answer case from an external provider; ISO/IEC 17043 governs providers) and interlaboratory comparisons. External crypto schemes are scarce, so units build known-answer cases from their own test transactions, with a CoinJoin decoy and a bridge hop, or swap anonymized cases with a partner unit. Record failures and act on them.

SWGDE's Establishing Confidence in Digital and Multimedia Evidence Forensic Results by Error Mitigation Analysis (version 2.0, 2018) argues that a single error rate often misleads, because digital tool errors are mostly systematic, not random. Its error mitigation analysis identifies likely error sources per task, applies and documents controls, and quotes rates where measurable. NISTIR 8354 (2022) adds that artifact meanings change as software changes, which applies directly to labels and wallets.

A found error is nonconforming work (clause 7.10) followed by corrective action (clause 8.7): stop affected work, assess impact on past cases (if a cluster label proves wrong, find every report that relied on it), notify those who need to know, possibly including prosecutors in closed cases, fix the root cause and confirm the fix worked.

Documents are controlled: versioned procedures, templates, validation and competence records and a tool register. Superseded versions are archived, because an old report must be read against the procedure then in force. The test of the whole system follows from ISO/IEC 27042: could another competent examiner, given only the case file, reach the same results and understand every judgment?

Exam focus: what chain of custody must show; second-preimage and collision resistance, SHA-256 under FIPS 180-4, MD5 and SHA-1 collisions and SHA-1's retirement by 2030; why one changed byte or line ending changes a digest, and hashing files as received; what a matching hash does not prove; when to hash; evidence log fields and the six questions of a custody transfer; seed phrases as bearer instruments (secure funds first, never record the secret, dual control, non-secret identifiers); remedying a custody gap with a supplementary entry, not a rewrite; ISO/IEC 17025 scope and key clauses, 27041 and 27042; verification versus validation and the contents of a validation record; technical, administrative and blind review; proficiency tests; SWGDE error mitigation and systematic errors; stopping work, assessing past cases and notifying after an error.