🎓 Lesson 19
D5
Building a Chain-of-Custody Log Using Embedded Hashes & Timestamps
A chain-of-custody log with embedded hashes and timestamps is like a tamper-proof digital notebook that proves exactly who handled drone survey data, when they did it, and that nothing was changed along the way.
🎯 Learning Objectives
- ✓ Explain how cryptographic hashing ensures data integrity in drone survey logs
- ✓ Design a minimal viable CoC log structure incorporating hash chaining and timestamped custody events
- ✓ Apply RFC 3161 timestamping principles to validate the temporal authenticity of a drone-derived point cloud file
- ✓ Analyze a sample CoC log to identify integrity violations or custody gaps using hash verification
📖 Why This Matters
In modern mines, drone-based surveys feed critical decisions—from slope stability analysis to regulatory compliance reports. If a survey dataset is altered—intentionally or accidentally—after collection, it could lead to unsafe design assumptions, failed audits, or legal liability. Regulatory bodies like MSHA, ICMM, and ISO/IEC 27001 now require demonstrable data provenance. A properly engineered CoC log isn’t just paperwork—it’s your forensic evidence that the LiDAR scan you submitted to regulators is identical to what the drone captured at 10:23:47 AM on May 12, 2024.
📘 Core Principles
Chain-of-custody relies on three interlocking pillars: (1) Identity — unambiguous identification of actors (e.g., drone operator, GIS analyst, QA reviewer) via digital signatures or PKI certificates; (2) Integrity — use of collision-resistant cryptographic hashes (e.g., SHA-256) to generate unique, deterministic fingerprints of data states; (3) Temporality — binding each custody event to a trusted, verifiable time source via RFC 3161 timestamp tokens, preventing backdating or time manipulation. Hash chaining (where each entry includes the hash of the prior entry) creates an append-only ledger effect: altering any earlier entry invalidates all subsequent hashes. This transforms the log from a simple list into a cryptographically linked timeline.
📐 Hash Chaining & Timestamp Binding
The core operation combines hash derivation and timestamp token generation. For each custody event i, the log entry includes H_i = SHA-256( H_{i−1} || Data_ID || Actor_ID || Timestamp_Token ). The timestamp token itself is generated by submitting H_i to a trusted Time Stamping Authority (TSA), yielding a cryptographically signed token proving H_i existed *at or before* the issued time. This dual-layer binding ensures both content integrity and temporal authenticity.
Cryptographic Chain Link
H_i = SHA-256( H_{i−1} || Data_ID || Actor_ID || TS_{i−1} )Computes the hash for custody event i, ensuring linkage to prior state, actor identity, and verified timestamp.
Variables:
| Symbol | Name | Unit | Description |
|---|---|---|---|
| H_i | Current custody hash | hex string (64 chars) | SHA-256 output for event i; serves as integrity anchor and input to next link. |
| H_{i−1} | Previous custody hash | hex string (64 chars) | Hash from prior verified custody event; establishes cryptographic continuity. |
| Data_ID | Unique data identifier | string | Persistent, immutable ID for the dataset (e.g., UUIDv4 + sensor serial). |
| Actor_ID | Custodian identifier | string | Cryptographically verified identity (e.g., X.509 certificate subject DN or DID). |
| TS_{i−1} | RFC 3161 timestamp token | ASN.1 DER binary | Time-stamping authority-signed token asserting existence of H_{i−1} at or before its embedded time. |
Typical Ranges:
SHA-256 output: 64-character hexadecimal string
💡 Worked Example
Problem: A drone captures a 2.4 GB LAS point cloud (file hash = f3a8c9d2...). Operator Alice signs and submits it to the mine’s internal TSA. The TSA returns RFC 3161 token TS₁ with timestamp '2024-05-12T10:23:47.123Z'. Later, analyst Bob applies classification filters and generates new file hash = e1b7f4a5.... He computes H₂ = SHA-256( f3a8c9d2... || 'LAS_2024-05-12_Alice' || 'Bob' || TS₁ ).
1.
Step 1: Compute SHA-256 of concatenated string: previous hash + actor IDs + timestamp token (not just time string — the full ASN.1-encoded RFC 3161 token).
2.
Step 2: Use a FIPS 140-2 validated crypto library (e.g., OpenSSL 3.0+) to ensure algorithmic compliance and avoid weak hashing.
3.
Step 3: Store H₂ alongside TS₂ (a new timestamp token issued for H₂), completing the link. Verification requires replaying the hash and validating both TS₁ and TS₂ against the TSA’s public key.
Answer:
The result is H₂ = 9d1e7c4a..., which serves as the immutable anchor for Bob’s processed dataset. Its validity depends on both correct hash computation and successful TSA signature verification — failure in either step breaks the chain.
🏗️ Real-World Application
At Newmont’s Boddington Mine (Western Australia), drone survey teams use a custom CoC module integrated into their DroneDeploy-to-ArcGIS workflow. Each raw GeoTIFF and LAS file auto-generates a JSON-LD CoC log containing: (1) drone serial + GPS time-stamped acquisition metadata, (2) SHA-256 of raw file, (3) RFC 3161 token from NIST’s Internet Time Service, (4) analyst ID and role, (5) hash of processed DEM, and (6) final sign-off hash. This log is archived in an immutable IPFS cluster and cross-referenced in quarterly MSHA Part 46 compliance reports — reducing audit preparation time by 70% and eliminating disputes over data versioning during tailings dam inspections.