In India, police forensic departments face major challenges in securing the chain of custody for evidence — a critical process that assures courts the evidence is authentic and untampered. It must remain under the control of authorized personnel at all times. However, current systems often fail to safeguard this trail, raising concerns about legitimacy and vulnerability to tampering. As a result, the reliability of forensic evidence in legal proceedings is frequently questioned, potentially impacting case outcomes. I will explain to you the principles of the Forensic Management System (FMS) from Trivolve, which was recently deployed for the Police in India, and which uses Cardano for ensuring data integrity. How FMS Works I'll walk through a concrete, simplified example, in which I will show the whole process and explain the important aspects of the system. Assume this is a murder investigation. A police officer at the station enters the following information into the FMS: victim John Doe, case ID_12345, evidence DNA ("dna_sample_1.pdf"). The system uses aliases to anonymize the data. A SHA-256 Hash is created from all aliases. Next, a Zero-Knowledge Proof, which says "I know data that matches this hash" without revealing the data. Original data is used to create the ZK Proof. The hash and ZKP Public Key are stored via a smart contract in the blockchain. To do this, you need to submit an on-chain transaction. All evidence (in our case, it is DNA) is physically sent to the laboratory for forensic analysis. The laboratory needs to write the results to the blockchain. FMS generates a new subalias and links it to the original ID. FMS re-computes the SHA-256 Hash on updated data and generates a new ZK Proof, including a new ZK PubKey. Raw data is stored in FMS, and a new on-chain transaction is submitted with a fresh Hash and ZK PubKey. This transaction will follow the previous transaction. This creates an immutable trail—each transaction references the prior hash, proving no gaps. Gradually, other records are entered into the system in a similar manner. In the proving process, the prosecution first prepares the proof privately by accessing the FMS with their credentials, inputting current data such as the Victim's name, Case ID, and Evidence. They compute a fresh SHA-256 Hash to ensure it matches the latest on-chain hash, confirming no tampering, then generate a tiny ZKP Proof token using the script to prove the linkages hash to the on-chain value, and the chain remains intact. They hand this token to the judge along with a verification request, such as "Does evidence A belong to Case B for Victim C?", without sending the hash since it's already public on-chain. The judge then runs the verification on their computer by loading the open-source verifier script and inputting the on-chain Hash, the corresponding ZKP PubKey, and the prosecution's proof token, optionally including the raw data for context but not for hashing. The judge performs no new hash computation themselves, as that would require undisclosed raw aliases (data); instead, the script executes elliptic curve checks (ZK math) to validate if the proof satisfies the public key for the hash, confirming the Victim's Name → Case ID → DNA evidence linkage without alteration. The output is a straightforward YES/NO: YES means "DNA evidence belongs to the Case for Victim John Doe; integrity intact since the given date," proving the full trail from upload through the Lab testing to court. NO indicates a mismatch, suggesting possible tampering if the data was altered. During this, the judge sees only the raw evidence file, such as viewing the PDF contents ("DNA profile matches victim sample"), with no raw aliases or internal mappings exposed. What Exactly Are ZK Proofs For? If only the SHA-256 Hash were stored on the blockchain (e.g., the hash of the Case ID + aliases/subaliases), a verifier (like a judge) would need the original/current data (e.g., the actual Case ID, aliases, and subaliases linking evidence) to recompute the Hash from that data. To perform this check, the data would need to be shared or exposed during verification—either by sending it to the verifier or logging it in a query. In a forensic context, this could leak sensitive information to unauthorized parties, auditors, or even publicly if mishandled. The ZKP makes verification private by allowing a "proof of knowledge" without disclosure. It's a cryptographic primitive (likely Groth16 or similar, supported on Cardano) that lets the prover (e.g., the police/lab presenting the evidence) convince the verifier (e.g., the judge) of a statement like: "I know data that hashes exactly to the on-chain value, and it hasn't been tampered with." The verifier gets a simple YES/NO (or "valid/invalid proof") without seeing the underlying data. No revelation needed—the proof is succinct and verifiable via math. The verifier has a minimal, controlled set of elements to enable the check without full exposure. In practice, for the forensic system: On-Chain Data, the SHA-256 hash + ZKP public key (stamped via the smart contract). Anyone can pull this from Cardano using the contract address. In short, the verifier has the "skeleton" (hash, ZKP PubKey, presented evidence files) but relies on the proof for the sensitive links. This keeps things compartmentalized—e.g., lab techs verify transfers without seeing victim details.
