Toward Secure and Scalable Digital Evidence Preservation: A Blockchain-Driven Framework

Abstract

Digital evidence management systems are designed to ensure that the digital evidence is genuine and effectively handle its complexity. In this work, blockchain technology is applied to handle the digital evidence by introducing several layers of security to ensure its protection, data integrity, and confidentiality, as well as trace the evidence throughout all its phases. To store the evidence files and their metadata, the proposed system uses a decentralized storage architecture that utilizes the InterPlanetary File System (IPFS) and Google Drive. Moreover, the proposed system ensures the chain of custody of the digital evidence through the use of Hyperledger Fabric technology. In addition, smart contracts (chaincode) are used in this work to validate the digital evidence, enforce strong access controls, and protect evidence metadata integrity. To ensure reliable transaction sequencing and consistency across the distributed ledger, an ordering service is used. At last, we combine two hash algorithms, symmetric encryption, file fragmentation, and metadata logging to protect the digital evidence from unauthorized access. The proposed framework is integrated with modern forensic tools, including Autopsy. The procedure of acquiring and analyzing digital evidence is made straightforward by the application of a set of forensic procedures. Moreover, the system’s modular design allows users to perform preprocessing operations, administer the decentralized storage, administer the evidence retrieval, test system performance, and enhance the system scalability. Moreover, we implemented secure coding practices and applied large language models to mitigate identified vulnerabilities, including weak system input validation, concurrent access to the system, and an insecure logging system. The experimental results indicate that the proposed framework preserves the digital evidence’s integrity, ensures chain of custody, and records all transactions. Results also indicate that the digital evidence is protected from unauthorized access and change attempts. Finally, by following local relevant regulations and established standards, the digital evidence should be admissible in court.

1. Introduction

During the last two decades, criminal investigations and legal proceedings have increasingly utilized digital evidence stored on electronic devices [1,2]. Practitioner reports suggest that digital evidence plays a central role in the majority of criminal proceedings [1]. While this figure is derived from practitioner reporting rather than peer-reviewed research, the central importance of digital evidence to modern criminal justice is supported by forensic science literature [2,3,4]. The rapid evolution of forensic investigation methods highlights the need to protect evidence authenticity and key information characteristics, such as integrity and availability. However, standard evidence-handling protocols often fail to ensure evidence safety and traceability. Thus, digital evidence preservation requires approaches that differ from traditional processes. Cybercrime investigations rely on digital evidence that must be kept unaltered and accessible, including files, emails, pictures, videos, log files, and device records [2].

Despite its importance, digital evidence remains vulnerable to unauthorized changes, unauthorized access, and destruction. Courts accept digital evidence only when it can be safeguarded and proven not to have been altered. In many cybercrime investigations, the digital evidence is stored and managed using a centralized management system with a manual documentation workflow. This process may increase insider risks related to misuse, decrease transparency when the digital evidence is transferred between different entities, and result in an inconsistent digital evidence handling process [4]. Alteration or destruction of evidence reduces its investigative value and can threaten ongoing cases. Therefore, under chain-of-custody requirements, digital evidence must remain under continuous control throughout its entire lifecycle, from collection to court proceedings; otherwise, it may become non-transparent and non-accountable. Risks of intentional or accidental manipulation can lead to inadmissibility in court, driven by unauthorized changes, human error, or loss.

Conventional evidence preservation strategies struggle to handle the complexity of digital evidence since the number of devices, platforms, and types of data is increasing. As such, law enforcement agencies and forensic laboratories struggle to meet the requirements for safe storage, protection, and management, which the conventional evidence preservation techniques demand [3]. These limitations highlight why blockchain technology should be employed to improve existing evidence preservation techniques and their reliability in modern society. The blockchain technology is dependable, since it prevents unauthorized persons from changing the evidence without permission [5]. A major challenge is scalability because, to be capable of managing large amounts of evidence, the blockchain network should be able to handle high transaction volumes and accommodate them efficiently [6]. As an example, Hyperledger Fabric is a permissioned blockchain system that can be used by enterprises with its modular consensus protocols, channel-based privacy models, and efficient transaction-batching capabilities. Accordingly, this study is oriented around three research objectives: (1) to design and evaluate a blockchain-based evidence management framework that safeguards data integrity and system security; (2) to demonstrate how the integration of blockchain technology with established digital forensic tools can improve evidence collection, analysis, and validation efficiency; and (3) to validate that the proposed framework can process realistic digital evidence collections using measurable scalability metrics. Each objective is directly addressed in Section 2 and Section 3.

The research gap addressed by this paper is the lack of an integrated, scalable, and legally defensible blockchain-based framework for digital evidence preservation. Several approaches have been proposed to apply blockchain for forensic logging, distributed storage, and access control. However, these approaches lack end-to-end integration of blockchain-based systems with forensic tools to effectively manage digital evidence. This requires a solution that supports scalability, automates the chain of custody, ensures legal compliance, and supports digital evidence of diverse types and formats. While each of the mentioned approaches addresses one or two of these limitations, this paper presents a complete solution in the form of a framework that addresses all the mentioned limitations. The framework is then evaluated through the experiments reported in Section 3.

Blockchain technology is a suitable solution to address the previously mentioned gaps because it provides tamper-evident, distributed, and auditable evidence records. First, it detects and prevents unauthorized changes to digital evidence once committed to the immutable distributed ledger. Second, the single point of trust and failure is eliminated due to the distributed multi-party endorsement model. This requires all authorized peers to independently agree on every evidence record before it is committed to the ledger. Finally, the blockchain framework utilizes smart contracts to automate the logging of the chain of custody. This provides an immutable and timestamped transaction on the ledger for every evidence access, registration, transfer, and verification.

Background and Related Work

Blockchain technology has evolved well beyond its initial application in cryptocurrency and has since been adopted across a wide range of domains. In the energy and sustainability sector, it has been explored for managing electricity and water consumption [6,7]. In the food and agriculture industry, blockchain has been applied to strengthen supply chain traceability and food security [8]. In healthcare, it supports secure data sharing, supply chain integrity, and organ transplantation workflows [9,10]. The financial services sector has investigated blockchain for user acceptance and transaction security [11]. Furthermore, blockchain has been applied in logistics management [12], educational credentialing and digital identity verification [13], and electronic voting systems [14]. A broad cross-sector review has further documented its deployment across IoT environments, vehicular networks, and enterprise systems [15]. This broad range of applications demonstrates that blockchain’s core properties (immutability, decentralization, and cryptographic auditability) generalize across sectors, motivating its deployment in digital evidence management, which motivates the framework proposed in this paper.

Under chain-of-custody requirements, the digital evidence must be subject to constant control during its entire lifecycle, beginning with its collection and ending with court proceedings. Digital evidence is not preserved by many systems in a manner that maintains its original state from the time the evidence was collected, including storage, until the evidence is utilized in court [2,3]. Current digital evidence management systems use centralized storage that requires parties to handle the evidence chain of custody (CoC) and protect the evidence’s integrity. Current digital evidence management systems rely on documentation and procedural controls [16]. Manual documentation and procedural controls may introduce system vulnerabilities that affect evidence accessibility during court proceedings [2,3]. Blockchain technology can also enhance accountability and reduce the chances of tampering with the evidence due to its decentralized nature.

A blockchain-based forensic system was built on Ethereum and relied on smart contracts to monitor forensic activities during evidence acquisition and transfer in a public blockchain network. The proposed framework safeguarded against unauthorized changes to evidence transactions using a logging platform based on Ethereum’s immutable infrastructure [17]. The system has two significant limitations: high gas fees, which inhibit widespread implementation, and privacy risks due to evidence metadata disclosure on a public registry. Lone and Mir [18] stated that the design stores the evidence files off the blockchain but fails to provide a cryptographic connection that ensures the safety of the external components of data. Another paper proposed a permissioned chain-of-custody framework that utilized Hyperledger Fabric to record all digital evidence transactions as immutable ledger entries [19]. However, a secure off-chain repository was used to store evidence artifacts. Fabric Chaincode was used to encode chain-of-custody workflows. Furthermore, role-based authorization was used to protect the workflows. However, the work was limited to a prototype setting and lacked large-scale forensic deployment.

Beyond general CoC logging, several domain-specific frameworks tailor blockchain designs to particular evidence sources. In connected-vehicle investigations, Block4Forensic proposed a lightweight integrated blockchain framework for vehicular forensic applications, emphasizing practicality for connected environments [20]. Similarly, Eunomia targeted vehicular digital forensics with anonymity and policy-driven access using blockchain, while employing advanced cryptographic mechanisms to strengthen privacy, at the cost of heavier computation and operational complexity [21]. In IoT settings, Blockchain-Based Logging Framework for Forensics (BLOFF) presented a blockchain-based forensic model aimed at improving the admissibility and integrity of IoT logs, but it was limited by a narrow scope and reduced analytics depth in large-scale deployments [22]. Additionally, Software-Defined Networking (SDN)-IoT forensic architecture uses blockchain to register network traffic artifacts, aiming for efficient evidence handling under programmable network control [23]. Another work proposed a framework that utilized Hyperledger Fabric to preserve IoT forensic evidence [24]. The proposed work relied on integrity verification and immutable logging. However, the framework was tested in a small-scale environment and raised privacy concerns during the user certificate linking step.

Another study introduced a blockchain-based digital classified forensic image preservation framework and reported an accuracy of 98% [25]. Nevertheless, the image data limited its use in various forensic processes. Moreover, it failed to discuss the integration of blockchain with existing forensic tools of different evidence forms, such as documents, videos, and chain-of-custody records. Similarly, another work discussed the significance of blockchain in enhancing the security of the evidence by utilizing a tamper-resistant ledger that guarantees authenticity and integrity [26]. The system had challenges in handling large amounts of evidence or simultaneous user access, which made it limited in the context of real-world investigations. Another study proposed a monitoring system based on the Hyperledger Fabric, which allows transparent preservation of forensic transactions without tampering. The study employed Hyperledger Fabric with permissioned peer participation and Hyperledger Caliper to quantify performance under different workload configurations, which supports full forensic processes from acquisition to preservation and documentation [27]. The ForensicTransMonitor framework could only be used to support a limited set of evidence-type testing, was not well integrated with the existing forensic toolchains, and did not provide more sophisticated access-control capabilities, including role-based or attribute-based policies. A forensic framework was suggested in [28] in order to offer an acceptable and unchangeable framework of blockchain technology to handle financial crime investigations, in particular, embezzlement. The framework incorporated forensics flow and chain of custody. This aimed to preserve the evidence in its original form during the investigation process.

In summary, prior work highlights several limitations and gaps that remain unresolved. Forensic chain (Ethereum) was associated with additional costs, metadata exposure, weak binding to off-chain stores, and poor tool integration, indicating the need for privacy-preserving and cost-aware recording on the blockchain with strong secure linkage to off-chain storage and appropriate integration components for forensic tools. Hyperledger CoC exhibits governance centralization, limited scale validation, weak forensic tool support, and volatile evidence support. BLOFF (IoT) is limited by static logging, limited details, and untested scalability, pointing to the need for scalable and adaptable, high-throughput multi-format anchoring beyond IoT. ForensicTransMonitor introduced strong privacy and anonymity but had heavy complexity and domain-bound scaling, suggesting the need for lighter-weight privacy and access control that scales across enterprise evidence.

For the rest of this paper, Section 2 explores the proposed framework architecture, digital evidence preprocessing, blockchain registration, and access control. Section 3 reports the experimental results. Section 4 discusses findings from this work, while Section 5 concludes the paper.

2. Materials and Methods

This paper proposes a scalable framework for secure digital evidence preservation that addresses the main gaps identified in prior work, especially handling large volumes of evidence, achieving higher transaction throughput, and improving memory efficiency. The framework is built on decentralized storage, optimized blockchain operations, and data segmentation. It integrates blockchain into forensic workflows to automate evidence handling and maintain a secure chain of custody. It also supports legal and standards alignment (e.g., ISO/IEC 27037 and ISO/IEC 27001) and maps technical controls to regulatory requirements to keep the preserved evidence defensible and admissible [29,30].

2.1. Implementation Environment and Software

A local Hyperledger Fabric, version 3.0.0, test network was used to implement the blockchain network [31]. The open-source programming language Go, version 1.24.3, was used to implement the chaincode [32]. Python, version 3.11.9, was used to develop the preprocessing and various performance testing scripts [33]. Autopsy, version 4.22.1, was used for digital evidence acquisition and analysis [34]. The FTK Imager, version 4.7, was used for digital evidence acquisition and analysis [35]. The IPFS/Kubo, version 0.35.0, was used for the off-chain storage [36]. For the secondary storage that was used for testing, Google Drive was used [37]. Finally, Docker, version 28.1.1, was used to run and manage the blockchain framework’s containerized services, including Hyperledger Fabric peers, ordering service, and related network components [38].

2.2. Framework Architecture and End-to-End Workflow

Figure 1 shows the proposed blockchain-based framework for scalable and secure digital evidence preservation. The framework workflow follows a sequential process for forensic case analysis, starting with evidence acquisition and continuing through preprocessing, encryption, IPFS upload, and blockchain submission. First, the digital evidence is acquired from a device or cloud source. Next, forensic tools, such as Autopsy and FTK Imager, are used to process the evidence. During data preprocessing and segmentation, the format and evidence category (image, video, or document) are determined, evidence is hashed, and its metadata is extracted and then encrypted. After that, the processed digital evidence is recorded on the Hyperledger Fabric blockchain. Next, decentralized storage is used to provide redundancy and secure storage. After that, two access control methods and multi-signature authentication are applied. Finally, the digital evidence is validated and verified and followed by secure evidence retrieval for analysis and legal use.

The process of handling digital evidence is shown in Figure 2. The digital evidence is displayed visually on the dashboard and has complete traceability and end-to-end automation.

The framework is implemented as modular components under a single evidence-processing pipeline that supports single-file processing, batch processing for directories containing file sets, and evidence retrieval by ID or hash. In practice, this renders the system usable for both small investigations and large case workloads while preserving consistent handling steps across evidence types.

2.3. Evidence Preprocessing and Secure Off-Chain Storage

Before evidence is stored, the preprocessing module prepares raw files for secure storage and blockchain registration. The proposed framework includes four core steps: (i) generating a secondary Argon2 verification value from the SHA-256 evidence hash, (ii) encrypting files with AES-256 (Fernet symmetric encryption), (iii) extracting metadata, such as filename, creation time, hash, and size, and (iv) splitting large files when needed through chunking or segmentation. This design generates blockchain-ready metadata, protects evidence confidentiality, and simplifies integrity verification.

For storage, the framework uses a hybrid storage approach. Encrypted and segmented evidence files are uploaded to IPFS as the primary decentralized storage, and a copy is simultaneously uploaded to a configurable secondary storage backend, implemented using Google Drive for prototype testing and accessibility. This hybrid storage approach provides redundancy and availability. In operational deployments, the secondary backend should be replaced by a self-managed, on-premises, or jurisdictionally controlled cloud service governed by the same chain-of-custody policies as the primary storage.

To ensure that all saved files on IPFS are available for authorized users, the ipfs pin add command is used to keep each uploaded segment available on IPFS. This prevents garbage collection from removing the uploaded file segments. Content addressing and integrity linkage are provided by the IPFS Content Identifiers (CIDs). However, CIDs alone do not ensure long-term availability of uploaded files. To achieve long-term availability of uploaded files, remote pinning services (e.g., Pinata or web3.storage) and replication across multiple IPFS nodes are required. Another option is to use a one-time payment model, such as Arweave, that offers long-term decentralized storage. In this work, Google Drive is used only as a prototype secondary backend for evaluation convenience, not as a recommended forensic storage component. It raises forensic and legal issues that limit its production deployment, including (i) as the files may be stored in jurisdictions subject to different legal requirements, it is difficult to ensure data residency; (ii) Google’s retention and deletion policies are not necessarily governed by forensic evidence retention requirements, as they are governed by Google’s terms of service; (iii) access logs do not provide a tamper-evident audit trail as required by chain-of-custody compliance, which means they are not suitable for forensic use; and (iv) account control can be terminated or reassigned independently of the investigation case. All production deployments must replace Google Drive with a self-managed object storage service controlled by jurisdiction and subject to the same evidence-handling policies as the blockchain layer.

The integrity anchor for each evidence item is the IPFS Content Identifier (CID) registered on the blockchain ledger, rather than the secondary copy. Google Drive serves only as an availability layer and cannot be used to alter or substitute a committed evidence record. The IPFS uploader generates a CID for each uploaded object, and that CID is captured for blockchain registration and later integrity verification. The IPFS module also maintains an upload log with timestamp and CID information to support auditing.

2.4. Blockchain Registration and Chain-of-Custody Preservation

Blockchain registration stores the evidence hash value and metadata in a private blockchain network implemented using Hyperledger Fabric. The system submits evidence hashes to Hyperledger Fabric and logs evidence metadata (generated hash values, IPFS CIDs, and timestamps) using a Fabric Software Development Kit (SDK)-based interaction layer version 0.9.0 [39]. Experimental results indicate that the Hyperledger Fabric blockchain protects the integrity and authenticity of evidence using immutable ledger entries and hash-based verification. In addition, the framework records each evidence file’s transactions, metadata, timestamps, and transaction endorsement records. Figure 3 illustrates a transaction lifecycle in Hyperledger Fabric within the proposed framework. As the figure shows, evidence metadata and chain-of-custody records are stored as tamper-evident ledger entries. For each incoming transaction, the client submits a proposal, peer nodes endorse it, the ordering service sequences transactions into a block, and peers commit the resulting block to the ledger. This authorization and validation process protects evidence integrity and enables participants to track the chain-of-custody status.

Evidence is first preprocessed through hashing, encryption, and metadata creation. Then, it is submitted to the evidence channel, validated through endorsement and access-control policies, and finally committed. Thus, records become permanent and tamper-evident. This distributed and policy-based approval process is used to verify evidence registration rather than relying on a single central authority. Figure 4 summarizes the multi-organization endorsement and access-control workflow used in the proposed framework.

To provide additional application-layer control and improve endorsement-layer robustness, application-layer controls are added to improve evidence registration and retrieval requests. Specifically, RBAC utilizes X.509 certificate attributes, while ABAC utilizes access-time conditions. The chaincode write function for evidence registration is made more robust by requiring a minimum application-layer stake and reputation score linked to the MSP ID of the requester. The chaincode read function for evidence retrieval is also made more robust by requiring approval from distinct roles for high-sensitivity evidence. Hyperledger Fabric mitigates Sybil attacks by verifying the identity of each peer node before allowing it to participate in the blockchain network. This requires each node to hold a valid X.509 digital certificate issued by a trusted certificate authority (CA) before it can participate in transaction endorsement. Thus, no anonymous or unverified nodes are allowed to participate in the network. In the proposed framework, hashing is implemented using SHA-256, password hashing is implemented using Argon2, encryption is implemented using AES-256 in Cipher Block Chaining (CBC) mode, and transaction digital signatures are implemented using the Elliptic Curve Digital Signature Algorithm (ECDSA). Every action taken on evidence, such as submitting or accessing evidence, includes a timestamp and is recorded in the permanent blockchain ledger, providing a clear, tamper-evident chain of custody for investigators and courts.

A threat analysis is conducted to improve the security level of the proposed framework against threats and security incidents, including unauthorized access, data tampering, Sybil attacks, and man-in-the-middle (MITM) attacks. The analysis prioritizes threats with high likelihood and severe impact. The proposed framework uses multi-signature authentication, role- and attribute-based access controls, strong encryption for data at rest and in transit, blockchain-based evidence metadata storage, and Fabric’s permissioned identity model to reduce these risks. AES-256 symmetric encryption protects evidence confidentiality and integrity against interception, data breaches, and unauthorized modification across the evidence lifecycle.

During digital forensic investigations, the proposed system addresses key security threats. Suitable countermeasures are implemented for each likely threat category. SHA-256 is used as the main hash method to detect any changes to digital evidence. Argon2id is used as a secondary verification method, where its input is derived from the SHA-256 output using fixed parameters. The parameters, time cost = 2, memory cost = 65,536 KB, parallelism = 1, and a deterministic zero-length salt, are recorded in the evidence metadata JSON committed to the ledger, giving full reproducibility. This setup allows authorized users, such as a court, forensic laboratory, or external examiner, to reproduce and verify the Argon2id output using three steps: (i) re-hash the retrieved evidence file using SHA-256; (ii) use the stored parameters and SHA-256 hash value as input to compute Argon2id; and (iii) compare the SHA-256 and Argon2id outputs against the committed ledger record. This means that the SHA-256 hash is the canonical integrity value under the chain-of-custody verification process. In addition, ABAC, RBAC, and multi-signature authentication are utilized to enforce defense-in-depth, which aids in detecting and preventing unauthorized access attempts to digital evidence. ABAC utilizes access time, access location, approved devices, device type, and other security conditions. On the other hand, the risk of evidence loss or corruption is mitigated through segmenting the encrypted files and then storing them in a distributed hash table (e.g., IPFS) and cloud storage services (e.g., Google Drive). To mitigate Distributed Denial of Service (DDoS) and Sybil attacks, the permissioned identity model of Fabric is used. Chain-of-custody proof of digital evidence is maintained through blockchain-based timestamping and an audit trail for access, registration, and modification of digital evidence.

Table 1. STRIDE-based threat analysis of the proposed framework.

STRIDE Category	Threat	Proposed Framework Countermeasures
Spoofing	Impersonation of investigators or legal nodes	X.509 certificate-based identity via Fabric CA and multi-signature authentication
Tampering	Unauthorized modification of evidence files or metadata	SHA-256 hashing and Argon2id-derived verification value, immutable ledger entries, verify evidence chaincode function
Repudiation	Denial of evidence submission or access events	Blockchain audit trail, timestamped and signed transaction records, ABAC logs
Information Disclosure	Unauthorized access to evidence metadata or content	AES-256 encryption of files, RBAC/ABAC access policies, off-chain storage with CID references only on-chain
Denial of Service	Flooding the endorsement layer or the IPFS upload pipeline	Transaction batching, policy-based endorsement validation, randomized endorser selection
Elevation of Privilege	Unauthorized role assumption (e.g., analyst acting as admin)	Role extraction from X.509 certificates, chaincode endorsement policies enforce write/read separation

illustrates the STRIDE-based threat analysis and how the proposed framework handles each threat.

2.5. Access, Auditing, and Compliance

To meet legal and technical requirements, the framework combines hashing, encryption, blockchain logging, and multi-signature methods to protect evidence integrity and provide tamper-resistant and time-stamped records that maintain the chain of custody. The system applies multi-signature authentication and audit records to track legal evidence and monitor activities such as access and modification, supporting transparency and accountability. In addition to the laws, evidence collection methods (autopsy tool integration), hash functions, and encryption (in addition to the framework components previously discussed), other important components of the framework were mapped to existing standards and local solutions. Distributed storage was implemented using IPFS and Google Drive.

Figure 5 illustrates the evidence access decision flow in the proposed framework. A user request is approved only after the RBAC check (role-based permissions and multi-signature approval) and the ABAC check (case, time, and location-based attributes) are satisfied; otherwise, the system denies access.

Many digital evidence management systems still use centralized storage, manual documentation, and procedural controls [4]. These practices create gaps in integrity tracking and weaken reliability during court proceedings. The proposed framework moves integrity checks and chain of custody records to a permissioned blockchain. It keeps encrypted evidence off-chain with redundant storage to mitigate these weaknesses and support defensibility in real investigations.

Table 2. Compliance mapping: framework components to standards and legal requirements.

Standard/Law	Control/Requirement	Framework Component
ISO/IEC 27037:2012 [29]	Identification and acquisition of digital evidence (s.7)	File-based preprocessing pipeline compatible with Autopsy and FTK Imager exports (hashing, encryption, segmentation)
ISO/IEC 27037:2012	Preservation of digital evidence integrity (s.8)	SHA-256, Argon2 hashing, AES-256 encryption, immutable Fabric ledger entries
ISO/IEC 27037:2012	Chain of custody documentation (s.9)	Blockchain timestamped audit trail, RegisterEvidence and GetEvidence chaincode functions (smart contract)
ISO/IEC 27001:2022 [30]	Access control policy (A.5.15)	RBAC, ABAC enforced via X.509 certificates and chaincode endorsement policies
ISO/IEC 27001:2022	Cryptography policy (A.8.24)	AES-256 symmetric encryption, SHA-256 and Argon2 hashing, ECDSA signing via Fabric

demonstrates how the proposed framework complies with the relevant standards and legal requirements.

2.6. Smart Contract Design and Chaincode Implementation

The business logic layer of the blockchain is implemented using chaincode, which represents the smart contract. Once a transaction is submitted, it is validated by rules set by the chaincode. These smart contract rules govern how data is read from and written to the distributed ledger. Public blockchain platforms, such as Ethereum, rely on account-based smart contracts written in Solidity. On the other hand, Hyperledger Fabric relies on chaincode, which is written in the Go, Java, and Node.js programming languages. In this work, we implemented chaincode using the Fabric Go contract API. Go, the primary chaincode runtime in Hyperledger Fabric, provides efficient execution and is supported by a well-established Software Development Kit (SDK) [39]. In Hyperledger Fabric, parallel endorsement across peer nodes, ordering services, and multiple chaincode containers are utilized to achieve high throughput. Each chaincode container processes one request at a time. This setup makes Go a suitable and efficient choice for handling forensic transaction workloads in this framework.

The chaincode is designed to only record metadata of the digital evidence. This means that the digital evidence files are not written to the blockchain ledger. Instead, only a lightweight JSON metadata object is committed per evidence record, containing the case identifier, SHA-256 hash value, Argon2id hash value, IPFS Content Identifier (CID), storage location reference, and a tamper-evident timestamp. This object is written to the Fabric ledger state using the native PutState() function, which keys each record by its evidence hash and permanently commits it to the immutable ledger once the transaction has been endorsed and ordered. This design keeps the ledger lightweight while preserving full traceability of every evidence item.

The chaincode includes four core functions that together cover the full evidence lifecycle. The RegisterEvidence() function is invoked after the application layer completes preprocessing that includes hashing, encrypting, and segmentation of the evidence file. This function submits a signed transaction that stores the evidence metadata to the ledger. The GetEvidence() function retrieves a stored metadata record using the GetState() call, verifies the requesting user’s access permissions, and returns the storage details needed for the application layer to retrieve and decrypt the evidence file. The QueryEvidenceByCase() function allows forensic investigators to retrieve all evidence records associated with a specific case ID. Finally, the VerifyEvidence() function enables integrity auditing by comparing the SHA-256 hash of a locally held evidence file against the hash committed on the ledger, providing cryptographically verifiable proof that the file has not been altered since its original registration.

Access control across all chaincode functions is enforced using RBAC access control policies based on the X.509 certificates issued by Fabric’s certificate authorities. Each transaction request carries the submitter’s certificate, from which the chaincode extracts the assigned role, such as administrator, forensic investigator, or legal analyst. Endorsement policies then determine which roles may invoke write operations, such as RegisterEvidence(), and which only invoke read operations, such as GetEvidence() or VerifyEvidence(). This role-driven and certificate-backed access model ensures that the audit trail recorded on the blockchain remains tamper-proof and that all evidence interactions are attributable to a verified and authorized participant, satisfying both chain-of-custody requirements and the access-control policies described in Section 2.4.

The three access-control mechanisms described in this section form a layered model. First, X.509 certificates issued by Fabric’s certificate authorities establish authenticated identity for every participant. Second, the participant’s role is extracted by the chaincode from the digital certificate. It then sets access permissions to invoke relevant functions. Third, operation-level constraints at the application layer are enforced using the RBAC and ABAC access control policies. These constraints include time-of-day restrictions, case assignment, and geographic restrictions. A further constraint is enforced at the chaincode layer, in which any write operation requires majority endorsement from all authorized peers before a transaction is committed to the evidence ledger. This additional constraint prevents malicious and compromised nodes from introducing false or altered evidence entries. This four-layer model provides defense-in-depth that prevents a compromised peer from granting unauthorized evidence access without the endorsement of the remaining peers.

3. Results

This section evaluates how the proposed framework answers the research questions and fills the gaps in previous work by demonstrating secure digital evidence preservation, scalability, and legal compliance. This study is quantitative in evaluating the feasibility of the blockchain-based digital evidence preservation framework. The framework is tested in terms of scalability, security, and efficiency through performance testing, experimental validation, and data analysis. Performance testing evaluates scalability in terms of throughput, storage performance, and system responsiveness. It evaluates security through verification of evidence authenticity, evidence traceability, and multiple endorsements. Regression analysis is used to study the relationship between transaction load and the number of simultaneous users, based on the collected performance data. Experimental testing simulates realistic forensic cases with different investigation complexities to evaluate chain-of-custody compliance, interoperability with forensic tools, and different evidence types.

The Hyperledger Fabric network is deployed and configured in a local development setup, as shown in Figure 6. We used the deployment and configuration step to validate the proposed digital evidence preservation framework. The test network includes two organizations (Org1 and Org2), two peers per organization (peer0 and peer1), and a single ordering service (orderer.example.com). A certificate authority is set up for each organization for identity management and credential issuance. A system channel (mychannel) is initialized and joined by all peers, which enables shared ledger access. The Fabric test network scripts are used to initialize the network. The configuration files (crypto-config.yaml, configtx.yaml) and the connection configuration files are used to generate the required digital certificates, private keys, MSP configuration, and the genesis block. The Transport Layer Security (TLS) certificates, including the ca.crt for the orderer, are correctly configured and referenced to enable secure communication between the peers and the ordering service.

Figure 7 presents single-file processing in the framework. A Python script, preprocessing.py, is used to preprocess the input file dad.mp3 exported from Autopsy. The file is assigned case ID CASE12345. The pipeline applies hashing, AES-based encryption, and segmentation, and then writes the blockchain transaction for the file and its segments, along with the generated outputs.

Table 3. Performance Metrics snapshot during evidence processing.

Metric	Value
File Name	dad.mp3
File Size	1.8 MB
Hashing Time	0.03 s
Encryption Time (AES-256)	0.08 s
Segmentation Time	0.05 s
Blockchain Submission Time	1.12 s
Total Preprocessing Time	~1.3 s
JSON Output Size	~3 KB

presents the processing results of a single file. It is worth mentioning that no physical forensic acquisition device was used to acquire this case experiment. This case file was collected from publicly available forensic dataset sources. The performance metrics recorded during the evidence processing, which include file size, hashing time, encryption time, segmentation time, blockchain submission time, and overall processing time. It also presents the time taken for each stage for different evidence sizes. The system operates at high speed, since all processes are conducted simultaneously and without bottlenecks. The design reduces delays caused by high workloads, since it processes all tasks in parallel and it supports evidence segmentation. This guarantees consistency in the performance when handling large digital evidence files.

The experimental results confirmed that the implemented Fabric ledger preserved evidence integrity through immutable ledger entries and hash-based verification. File-level protection is achieved through the integration of Argon2id verification with AES-256 encryption. The integrity of digital evidence is enforced by comparing the hash values between the blockchain network ledger and IPFS storage. The endorsement policy implemented in this work requires multiple authorized peers to independently validate and sign each transaction before it is ordered and committed. Thus, multiple authorized peers validate each transaction, which protects the evidence from unauthorized changes and ensures data consistency. The endorsement and ordering workflow, therefore, provides a deterministic record of approved evidence transactions once they are ordered, validated, and committed to the ledger. This process ensures the immutability and forensic quality of stored blockchain transaction records.

For every evidence file, the blockchain system records its transactions, metadata, timestamps, and multi-signature approval records. The process starts with digital evidence preprocessing through hashing, encryption, and metadata creation. Then, the client application sends it to the Evidence Channel, where the Evidence_Contract chaincode operates, and the transaction proposal is shared with multiple organizations to validate the proposal through endorsement and access control policies before receiving approval responses from peers. The system uses distributed policy-based approval to verify evidence registration instead of depending on a single central authority.

This study utilizes data sets from the CFReDS Project, Digital Corpora, and GitHub repositories. These data sets are publicly available repository sources rather than software tools. The CFReDS Project [40] provides disk images, file systems, and memory dumps for validation of acquisition, hashing, and imaging. Digital Corpora [41] provides disk images, network logs, and mobile data for the evaluation of framework scalability across diverse forensic case types. GitHub repositories include open-source forensic projects and datasets, such as source code, logs, and case studies, to simulate real-world forensic workflows and support integration testing with tools.

To evaluate the scalability of our framework, we present both the blockchain-only and end-to-end pipeline benchmarks. In the blockchain-only testing environment, we set up a performance testing environment by submitting RegisterEvidence transactions to the Fabric blockchain environment. The number of transactions submitted per client instance is incremented. For each test case, the throughput, measured in transactions per second (TPS), and latency are recorded. Performance testing starts with 100 concurrent transactions and is then incrementally increased up to 500 concurrent transactions. A regression analysis is used to show the throughput of the measured load points by fitting a linear regression model. The throughput is defined as: throughput = 0.03 * × transaction load + 2. The measured throughput values were fitted to this model, with the resulting model delivering an R² score of 0.93. It is worth mentioning that the linear regression model is only presented to investigate the tested load points. Thus, for higher loads, it should not be used for throughput extrapolation. The conducted test of up to 500 concurrent transactions clearly indicates that transaction load and the throughput of blockchain transactions have a direct linear relationship under the tested environment. In addition, these findings indicate that the system can support horizontal scalability by adding more nodes. Under the tested conditions, the system supported a maximum tested concurrent load of 500 concurrent transactions with a peak blockchain-only throughput of 27 TPS. This TPS is higher than the linear regression estimate. This non-linear throughput is achieved because the Fabric transaction batching mechanism combines multiple concurrent transactions into a single block at high submission rates. This behavior is in agreement with the block-cutting policy of Fabric. Furthermore, this behavior is expected to hold as the number of peers and organizations increases horizontally.

End-to-end pipeline testing was also conducted. In the testing, the system processed a large amount of evidence through the full end-to-end pipeline. During this stage, after preprocessing the digital evidence, it was hashed and divided into segments. Next, each segment was encrypted. The encrypted evidence segments were stored in IPFS and in a secondary cloud storage backend. Next, the evidence was registered on Hyperledger Fabric. The evidence registration includes the system’s metadata related to the processed evidence. It also includes references (pointers) to where the processed evidence was stored. The end-to-end testbed includes digital evidence preprocessing, storing the evidence in different locations, and submitting its metadata to the Fabric blockchain. The throughput of the end-to-end testbed of the full evidence processing pipeline was less than that of the blockchain-only testbed. This was due in large part to the processing time for the system to perform the various functions (e.g., performing various types of cryptographic processing), the time spent by the system storing files in the various storage locations and then retrieving the files from storage, and the time spent by the system submitting evidence transactions to the blockchain in Fabric after the evidence had been processed. A full end-to-end test of 1000 evidence files took 181.97 s to process the evidence. Simulation results indicate 5.5 transactions per second (throughput) and an average latency of 0.906 s. Results also indicate that all of the 1000 evidence items were correctly registered in Hyperledger Fabric. Several areas for improvement were found in the testbed’s performance. Throughput can be improved by increasing parallel processing when performing the various types of cryptographic processing for the evidence, storing the processed evidence, and retrieving the stored evidence from different locations. Additionally, the testbed’s performance could be improved by using asynchronous blockchain commits instead of the current approach of committing transactions one at a time. Finally, improved throughput could also be achieved by using faster storage backends optimized for high-concurrency workloads.

The experimental verification used a fraud detection case that followed the full forensic workflow of a law enforcement investigator. At the first stage of the work (evidence collection), a suspect’s laptop was seized and a disk image was created with the help of a write blocker to prevent any modifications to the initial evidence. The created disk image was then analyzed with the help of the platform for digital forensic analysis using Autopsy. During the analysis phase, the system detected relevant files, deleted data, user activity, and hidden data. The original disk image and its partitions were assigned hash values to support evidence integrity verification during the investigation. During the preprocessing stage, all of the evidence files were encrypted and divided into separate fragments, and the initial metadata was extracted from the evidence files. The obtained evidence files were uploaded to the InterPlanetary File System (IPFS) and to secondary storage. Corresponding metadata were registered on the Hyperledger Fabric-based blockchain ledger based on the endorsed blockchain transactions. All the processes of adding the evidence to the storage, as well as subsequent access to it, were registered in the framework of the chain of custody and recorded in the form of immutable entries. All stages of evidence registration and access required endorsement from participants with the appropriate roles: an investigator, a forensic expert, and a lawyer. During experimental verification, the full evidence-processing cycle for the fraud detection case was completed successfully. The evidence was processed correctly, and all stages were fully traceable. The integrity of the evidence and the access rights of the investigation participants were maintained throughout the complete evidence-processing cycle.

The results indicate that the system can handle multiple evidence files at the same time while maintaining consistent transaction performance and security robustness under the tested conditions. The early development phases revealed several security vulnerabilities through both manual code review and AI-assisted static analysis using a large language model (ChatGPT-4). Three categories of weakness were identified: (i) weak input validation in evidence submission endpoints, which could allow malformed metadata to be committed to the ledger; (ii) concurrency race conditions in the multi-threaded preprocessing pipeline, which could produce inconsistent hash values under high load; and (iii) insecure logging that exposed sensitive file paths and user identifiers in plaintext log entries. Each identified vulnerability was reviewed prior to remediation to confirm correctness and relevance. The applied fixes include parameterized input sanitization, mutex-protected critical sections in the hashing and encryption modules, and structured logging with automatic redaction of sensitive fields. Following these improvements, the system demonstrates improved resilience to cyberattacks and provides enhanced configuration practices, input validation, concurrency handling, error handling, and secure logging functionality. Overall, this study presents a fully operational system designed to support key requirements, including legal requirements, scalability, evidence authenticity, and maintaining an intact chain-of-custody record.

Initial integration results indicate a high performance and reliability of the system with a 100% transaction success rate under the tested conditions.

Table 4. Comparison between ForensicTransMonitor and the proposed framework.

Category	ForensicTransMonitor	Proposed Framework
Blockchain Platform	Hyperledger Fabric	Hyperledger Fabric
Forensic Scope	End-to-end coverage of preservation, acquisition, analysis, and documentation	Covers acquisition, hashing, encryption, file segmentation, evidence storage (IPFS + cloud), and blockchain-based preservation
Performance Tool	Hyperledger Caliper	Python-based benchmarking scripts (performance_testing.py, real_scalability_test.py)
Throughput	545.5 TPS	27 TPS (just blockchain), 5.50 TPS (1000 tx full pipeline, 181.97 s, 100% success)
Latency	0.01 s per transaction	Average 0.906 s per transaction (full pipeline)
Success Rate	99% or higher	100% success rate
Security and Auditability	Uses cryptographic hashing, smart contracts, and immutable blockchain logs	Dual hashing, encryption, file fragmentation, RBAC and ABAC access controls, multi-signature authentication, immutable blockchain logs, and chain-of-custody tracking with legal compliance mapping
Evidence Type	Supports real forensic cases with diverse evidence types (emails, logs, and digital files)	Supports PDF, DOCX, MP4, MP3, PNG, JPG, logs, integrated with forensic tools (e.g., Autopsy)
Authentication and Access	Basic identity management via Hyperledger Fabric	Role-Based and Attribute-Based Access Controls (RBAC + ABAC), multi-signature authentication
Scalability Strategy	Limited scalability; relies on on-chain processing	IPFS integration, evidence segmentation, concurrent client processing, and off-chain storage
Legal Compliance	Not explicitly addressed	Aligned with ISO/IEC 27037:2012, ISO/IEC 27001:2022, and Palestinian Electronic Transactions Law
Interoperability	Limited interoperability	File-based pipeline compatible with Autopsy export workflow and standard forensic toolchains

compares the proposed framework with ForensicTransMonitor by highlighting the security and workflow controls implemented in the proposed design.

4. Discussion

The ForensicTransMonitor model is a full-fledged blockchain framework that supports evidence protection, collection, analysis, and documentation processes [27]. Its framework architecture is powered by Hyperledger Fabric, which provides high-performance and dependable operation. ForensicTransMonitor uses Hyperledger Caliper for performance evaluation. The experimental evaluation of this system indicates relatively high transaction processing speed, low delay time, and a reliable transaction completion rate under the tested conditions.

The proposed framework hashes the evidence content using SHA-256, creates a secondary Argon2-based verification value, encrypts evidence segments before storing them externally, records IPFS content references on the ledger, and applies RBAC and ABAC checks in the chaincode for all evidence operations. It also requires threshold-based approval for access to highly sensitive evidence files and records all access attempts in an audit log. Performance comparisons clearly state benchmark scope; throughput and latency values are reported separately for blockchain transaction submission and for full pipeline execution. As reported in Section 4, the proposed framework achieved a throughput of 5.50 transactions per second with an average latency of 0.906 s for a 1000-transaction test with zero failures. ForensicTransMonitor achieved a higher blockchain-layer throughput because it does not apply symmetric encryption, file segmentation, RBAC and ABAC enforcement, or multi-signature authentication per transaction. The lower throughput of the proposed framework is therefore a consequence of the additional cryptographic processing required by the enhanced security model, not a deficiency in the underlying Fabric deployment. Importantly, the framework provides this level of security while still maintaining functionality through three efficiency mechanisms in its architecture. First, the framework uses off-chain storage. Evidence files are stored on IPFS instead of being stored directly on the ledger. Only small JSON metadata records, about 3 KB per record, are committed to the blockchain. This keeps the ledger lightweight and avoids the storage growth that would result from storing full files on-chain. Second, large evidence files are divided into segments and processed in parallel. This reduces the total time needed for cryptographic processing and improves throughput for large files. Third, the framework separates preprocessing, IPFS upload, and blockchain submission into distinct pipeline stages, which reduces workflow complexity and makes each stage easier to optimize independently. Together, these mechanisms show that the framework can provide strong security while still maintaining reasonable computational efficiency.

The proposed framework provides four improvements over prior work. Therefore, the main innovation of the proposed framework is not a single component but the integration of forensic-tool compatibility, off-chain evidence storage, segmented processing, cryptographic protection, and layered access control into one evidence-preservation pipeline. First, it provides better integration with forensic tools. The framework includes a file-based preprocessing pipeline that works directly with evidence exported from Autopsy and FTK Imager. The proposed preprocessing pipeline is different from the preprocessing step of ForensicTransMonitor, since it does not integrate with standard forensic tools. Second, it provides stronger security. ForensicTransMonitor uses basic cryptographic hashing and smart contracts. However, the proposed framework integrates two hashing methods, strong symmetric encryption, two access control methods, multi-signature authentication, and stake and reputation checks at the application level. Third, it achieved a 100% success rate using 1000 end-to-end evidence submissions, which supports scalability. On the other hand, BLOFF and Kusuma were tested in smaller environments and reported challenges when handling large volumes of evidence [26]. Fourth, the proposed framework provides clear compliance mapping to ISO/IEC 27037 [29], ISO/IEC 27001 [30], and the Palestinian Electronic Transactions Law, while the compared systems do not directly address admissibility requirements.

Current digital evidence management systems use centralized storage that requires parties to handle the evidence’s chain of custody and maintain its integrity. Also, current digital evidence management systems rely on documentation and procedural controls. Manual documentation and procedural controls may introduce system vulnerabilities that affect evidence accessibility during court proceedings and weaken system reliability [2,3]. Public or semi-public blockchain systems that implement transparency create privacy problems, and these systems also make it difficult to control access and maintain system performance [42,43]. Classical Byzantine fault-tolerance methods can usually tolerate fewer than one-third malicious nodes. However, quantum-based Byzantine agreement methods have shown that this limit can be increased to nearly one-half by using quantum digital signatures. This makes them a useful solution for improving blockchain security in future work [44,45,46]. The proposed framework indicates that permissioned blockchain systems provide access control and confidentiality protection while maintaining system integrity and traceability. According to the results, lightweight blockchain-based forensic tools minimize the encryption and segmentation time and enable faster verification of the transactions. However, systems that reduce processing time may introduce security vulnerabilities that diminish privacy, traceability, and preservation of evidence [18,20].

The proposed framework employs the SHA-256 method for hashing, AES-256 for symmetric encryption, Argon2id for encryption key derivation, and ECDSA to sign each transaction, which occurs at the Hyperledger Fabric’s identity layer. These methods do not face the same level of risk from quantum computing. The main concern is ECDSA, because Shor’s algorithm could break elliptic-curve signatures if a large enough fault-tolerant quantum computer becomes available. This would affect the certificates and signatures used by the framework. SHA-256 and AES-256 are less exposed to this type of attack. However, Grover’s algorithm can reduce their effective security strength to about 128 bits. This is still considered acceptable for current systems, but it should be considered in long-term deployments.

5. Conclusions

This work presented the design, implementation, and evaluation of a digital evidence management system that protects evidence confidentiality, integrity, and traceability. The proposed framework integrated Hyperledger Fabric, decentralized storage, IPFS-based content addressing, hashing, symmetric encryption, and RBAC and ABAC access control methods to securely manage evidence throughout its lifecycle. Iterative system testing and refinement addressed key security and performance issues, including weak input validation, concurrency vulnerabilities, and insecure logging, resulting in a more robust and reliable system under the tested conditions.

Overall, this work presents a fully operational system designed to support key requirements, including legal requirements, scalability, evidence authenticity, and intact chain-of-custody records. Simulation results showed that the proposed framework took 181.97 s to process 1000 evidence items through the full end-to-end pipeline. This resulted in a throughput of 5.50 transactions per second (TPS), an average end-to-end latency of 0.906 s, and a 100% transaction success rate. In the blockchain-only test, the framework reached 27 TPS and showed a near-linear scaling pattern across up to 500 concurrent transactions (R² = 0.93). For an evidence file with a size of 1.8 MB, the preprocessing steps took 1.3 s, and blockchain submission took 1.12 s. These results show that the framework can support realistic forensic workloads under the tested conditions.

However, several implementation challenges were encountered. The system testing was conducted on a small Hyperledger Fabric test network with two organizations, two peers per organization, a single channel, and a limited number of forensic cases. Although the results were encouraging, they may not fully represent system performance in real-world large-scale environments. Therefore, the framework should be tested using larger datasets, more forensic scenarios, and multiple blockchain network configurations to further demonstrate scalability, reliability, and interoperability in practical deployments.

Future enhancements to the proposed system include implementing secure identity and access management using OAuth2, multi-factor authentication (MFA), and biometric authentication. As quantum computing advances, the framework’s cryptographic stack, particularly its use of ECDSA for transaction signing, will require migration to post-quantum algorithms such as those standardized by NIST in 2024, including ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). A secure web interface will be developed to enable investigators to interact with forensic analysts and improve overall usability and interaction capabilities. Additional features will be integrated into the system, such as advanced search capabilities, semantic metadata classification, and intelligent indexing to improve evidence retrieval for complex and large datasets. Furthermore, the framework will be tested in different locations and conditions to demonstrate practicality and resilience, including operation under system failures. Finally, machine learning will be integrated to detect evidence tampering, suspicious user behavior, and unauthorized access. Future work will also examine quantum Byzantine consensus mechanisms to improve resilience in large-scale forensic blockchain deployments [46].