💻 computer science

Tamper-Evident Incident Response and Digital Evidence Management for Connected Vehicles Using Permissioned Blockchain

This paper proposes a permissioned-blockchain architecture for connected vehicles that ensures forensic integrity and secure incident recovery by storing detailed evidence in a local tamper-evident journal while committing compact cryptographic checkpoints to a distributed ledger, thereby achieving high-performance verification and significant data volume reduction without compromising privacy or safety.

Original authors: Md Shahanur Islam Shagor

Published 2026-09-18

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Md Shahanur Islam Shagor

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Modern cars are no longer just machines of metal and rubber; they are rolling networks of computers that constantly talk to each other, to traffic lights, and to cloud services. This constant conversation, known as the Internet of Vehicles, helps drivers avoid accidents and navigate traffic more smoothly. However, this connectivity creates a new kind of vulnerability. When a hacker or a malfunction disrupts a vehicle's systems, the evidence of what happened is scattered across dozens of digital logs. If the system that recorded the event is the same one the hacker has compromised, the records can be quietly altered or deleted, leaving investigators with a false story. The challenge for security experts is not just to catch the crime, but to prove that the story they are telling about the crime is the true one, and to ensure the car does not start moving again until it is absolutely safe.

A recent study by Md Shahanur Islam Shagor addresses this dual problem by creating a system that treats the safety of the car and the truth of its records as a single, locked package. The research proposes a method for connected vehicles to keep a detailed, unchangeable history of security events without flooding the network with massive amounts of data. Instead of sending every single piece of evidence to a central, shared ledger, the vehicle keeps a local journal of events. This journal is constructed like a chain of sealed envelopes, where each new entry is mathematically linked to the one before it. If an attacker tries to swap a page, delete a line, or change a number in the middle of the history, the link breaks, and the tampering becomes immediately obvious. To ensure this local history cannot be faked after the fact, the vehicle periodically sends a tiny, compact summary of its current state to a trusted group of validators. This summary acts as a timestamped anchor, proving that the local records existed at a specific moment in time.

The core innovation of this work is how it connects the act of investigating a breach with the act of recovering from it. In many current systems, a car might be taken offline for safety, and then automatically brought back online once a timer runs out, or based on a simple command from a human operator. This paper argues that such automatic recovery is dangerous if the evidence of the attack has been tampered with. The proposed system uses a "latched" state machine, a digital logic gate that refuses to let the car return to normal operation unless a strict set of conditions are met. The car cannot recover just because time has passed. It requires a human operator to explicitly acknowledge the incident, followed by a period where the vehicle's sensors confirm that everything is healthy. Crucially, if any new evidence of an attack appears during this recovery window, the system resets, locking the car out again. For safety-critical situations, an additional physical or digital confirmation is required before the car is allowed to move.

To test this design, the researchers built a software simulation running on a standard computer processor. They measured how long it took to create and verify these secure records. The results showed that the system is fast enough for real-world use. Creating a single authenticated record took an average of 19.15 microseconds, a fraction of the time it takes for a human to blink. Verifying a massive log of 50,000 records took less than 700 milliseconds. Perhaps most importantly, the study demonstrated that this approach drastically reduces the amount of data that needs to be stored on the shared network. By sending only a small checkpoint every 64 records instead of every single record, the system reduced the data volume on the shared ledger by approximately 99.5 percent. This means the network remains fast and efficient while still providing a high level of security.

The researchers also subjected their system to a series of simulated attacks to see if it would hold up. They tested scenarios where an attacker tried to modify a record, delete a log entry, reorder the sequence of events, or forge a command from a human operator. In every case, the system detected the foul play and rejected the action. It successfully identified when an old command was being replayed to trick the system into thinking a new authorization had just been given. It also prevented the car from recovering if the safety interlock was missing or if new evidence of a threat appeared after the recovery process had started. The study concludes that by tying the integrity of the evidence directly to the safety of the vehicle's recovery, security teams can ensure that a car is not just restored to operation, but restored to a state that is genuinely safe and verified.

This work does not claim to be a finished product ready for every car on the road today. The tests were conducted in a controlled software environment, not on actual vehicles with specialized hardware. The researchers acknowledge that real-world deployment would require further testing on embedded automotive chips and with actual network delays. However, the findings provide a clear blueprint for how to build a system where the truth of the past and the safety of the future are inextricably linked. By ensuring that a vehicle cannot be turned back on until its own digital history has been verified as untampered, this approach offers a robust way to handle the complex security challenges of the connected car era.

Technical Summary: Tamper-Evident Incident Response and Digital Evidence Management for Connected Vehicles Using Permissioned Blockchain

Problem Statement
Connected vehicles generate high-volume, privacy-sensitive telemetry across distributed networks (V2X, in-vehicle, and backend). When a cyber incident occurs, reconstructing the event requires evidence that is both trustworthy and available. Traditional centralized logging relies on the host's integrity, which is compromised if the attacker gains system access. While existing blockchain-based forensic solutions (e.g., Block4Forensic, smart-contract frameworks) address distributed evidence integrity, they often treat evidence preservation and operational recovery as separate concerns. This separation creates a critical gap: a system may produce an immutable audit record yet automatically recover from containment even when evidence is inconsistent, new threats are pending, or operator commands are replayed. There is a lack of a unified protocol that couples evidence preservation with fail-closed recovery authorization.

Methodology
The proposed architecture decouples detailed evidence storage from distributed integrity assurance using a hybrid approach:

Local Tamper-Evident Journal: Normalized, value-minimized evidence records are stored locally. Raw payloads, passwords, and full sensor streams are excluded to preserve privacy. Records are canonicalized, sequence-linked via SHA3-256 hashing ( $h_i = \text{SHA3-256}(C(r_i))$ ), and authenticated using HMAC-SHA-256 with a dedicated evidence key ( $K_e$ ) separated from operator keys.
Permissioned Blockchain Checkpoints: Instead of replicating every record on-chain, the system commits compact integrity checkpoints to a permissioned validator ledger. A checkpoint ( $c_j$ ) is generated every $B$ records (e.g., 64) or at lifecycle transitions, binding the local journal tail to the distributed ledger. This reduces ledger volume while maintaining an externally witnessed anchor.
Latched Incident State Machine: The system enforces a strict lifecycle (CLEAR $\to$ $\to$ OPEN $\to$ $\to$ ACKNOWLEDGED $\to$ $\to$ RECOVERY_PENDING $\to$ $\to$ NORMAL).
- Latching: An incident cannot transition to recovery automatically. It requires explicit operator acknowledgement.
- Recovery Gate: Recovery is permitted only if: (a) local and monitor evidence chains verify, (b) no new containment evidence has appeared, (c) a healthy observation window (e.g., 3 consecutive healthy states) is met, (d) a fresh, nonce-protected operator authorization is present, and (e) safety-interlock confirmation is provided for critical incidents.
Replay-Resistant Authorization: Operator actions (acknowledge/recover) are signed with a separate key ( $K_o$ ) and bound to the incident ID, action type, timestamp, and a unique nonce. This prevents replay attacks and ensures actions are not reused outside their freshness window.

Key Contributions
The paper defines four primary contributions:

Chain-of-Custody Construction: A deterministic method for vehicle-security evidence using canonicalization, SHA3-256 linking, and HMAC authentication, excluding raw sensitive data.
Hybrid Integrity Architecture: A design that uses compact permissioned-ledger checkpoints to bind local journals, reducing ledger growth by ~99.5% compared to full-record replication while preserving external auditability.
Key Separation and Binding: Distinct cryptographic domains for evidence authentication and operator authorization, with operator actions cryptographically bound to specific incidents and nonces to resist forgery and replay.
Fail-Closed Recovery Formalization: A state machine that treats evidence integrity as a precondition for recovery. If evidence is tampered with, deleted, or if new containment evidence appears, the system forces a fail-closed state rather than allowing silent recovery.

Experimental Results
Evaluated in a controlled Linux x86-64 environment (AMD EPYC, Python 3.13.5):

Performance: The mean latency for constructing an authenticated record (canonicalization + SHA3 + HMAC) is 19.15 microseconds. Full verification of 50,000 records takes 693.89 ms (approx. 13.88 $\mu$ s/record).
Storage Efficiency: Storing checkpoints (192 bytes) every 64 records instead of full normalized records (620 bytes) reduces modeled ledger payload by 99.5% (e.g., 150.1 kB vs. 31.0 MB for 50,000 records).
Security Efficacy: Adversarial tests confirmed the system detects field modifications, deletions, reordering, and forged authentication tags. It successfully rejects replayed operator commands, stale authorizations, and recovery attempts lacking safety-interlock confirmation or occurring after new containment evidence.

Significance and Claims
The paper claims that its primary significance lies in shifting the role of distributed integrity from a passive archive to an active precondition for safe cyber-incident recovery. Unlike previous works that focus solely on forensic preservation or privacy, this architecture ensures that a vehicle cannot return to normal operation unless the evidence chain is intact and the threat context has cleared. The design couples chain-of-custody preservation with operational recovery, ensuring that "fail-closed" decisions are driven by cryptographic verification rather than just policy. The author explicitly states that the results support a practical separation between local evidentiary detail, distributed integrity assurance, and fail-closed incident recovery, but they do not claim automotive functional-safety certification or validation on production hardware.

Technical Summary: Tamper-Evident Incident Response and Digital Evidence Management for Connected Vehicles Using Permissioned Blockchain

More like this