PaperlayerView exact revision on arXiv

Source-linked AI summary

B-FERL: Blockchain based Framework for Securing Smart Vehicles

Chuka Oham, Regio Michelin, Salil S. Kanhere, Raja Jurdak, Sanjay Jha

arXiv:2007.10528v1cs.CRcs.DC

TL;DR

Connected vehicles’ electronics can be compromised, creating risks for vehicle operation and network messages. B-FERL combines permissioned blockchain records with RSU challenge-response checks of ECU integrity. The paper reports resilience to a broad range of attacks and simulation results indicating practical applicability.

  • Problem

    Compromised ECUs can threaten vehicle operation and vehicular-network data, while prior monitoring approaches leave data-reliability challenges.

    Source: §I · pp. 1–2

  • Method

    B-FERL uses a permissioned, two-tier blockchain and RSU challenge-response checks to validate vehicle records and monitor ECU integrity.

    Source: A. Contributions and Paper Layout · p. 2, A. Architecture overview · p. 3, B. Operation · p. 6

  • Results

    Security analysis reports resilience to a broad range of attacks, and simulation results indicate practical applicability in realistic scenarios.

    Source: §VII · p. 10

  • Takeaways & Limitations

    B-FERL identifies vehicle compromise and escalates it to authorities, serving as a detection and reaction mechanism for vehicle and network security.

    Source: §VII · p. 10

    The experiments are initial viability evaluations intended to inform later real-world scenario experimentation.

    Source: §V · p. 7

Abstract

from arXiv · show

The ubiquity of connecting technologies in smart vehicles and the incremental automation of its functionalities promise significant benefits, including a significant decline in congestion and road fatalities. However, increasing automation and connectedness broadens the attack surface and heightens the likelihood of a malicious entity successfully executing an attack. In this paper, we propose a Blockchain based Framework for sEcuring smaRt vehicLes (B-FERL). B-FERL uses permissioned blockchain technology to tailor information access to restricted entities in the connected vehicle ecosystem. It also uses a challenge-response data exchange between the vehicles and roadside units to monitor the internal state of the vehicle to identify cases of in-vehicle network compromise. In order to enable authentic and valid communication in the vehicular network, only vehicles with a verifiable record in the blockchain can exchange messages. Through qualitative arguments, we show that B-FERL is resilient to identified attacks. Also, quantitative evaluations in an emulated scenario show that B-FERL ensures a suitable response time and required storage size compatible with realistic scenarios. Finally, we demonstrate how B-FERL achieves various important functions relevant to the automotive ecosystem such as trust management, vehicular forensics and secure vehicular networks.

I. INTRODUCTION

Connected vehicles’ increasingly complex electronics can be remotely exploited, and compromising an ECU can threaten both the vehicle and the wider vehicular network. B-FERL proposes decentralized blockchain-based integrity monitoring, with evaluations and automotive use cases described as contributions.

I. INTRODUCTION

  • Compromised ECUs can enable remote vehicle control or false network broadcasts, motivating monitoring of the in-vehicle network to detect compromise.The paper also identifies centralized verification and subset-based monitoring as challenges for prior approaches.Source: §I · pp. 1–2

A. Contributions and Paper Layout

  • B-FERL uses a two-tier blockchain architecture and challenge-response checks at RSU connections to authenticate vehicles and query ECU integrity.Vehicle records support authentication; the paper also describes permissioned access and distributed tracking of ECU state changes.Source: A. Contributions and Paper Layout · p. 2
  • The paper reports qualitative attack-resilience evaluation, simulation of time and storage overheads, and applicability to forensics, secure communication, and trust management.It presents this work as an extension of preliminary ideas in [1].Source: A. Contributions and Paper Layout · p. 2

II. RELATED WORK

Prior blockchain proposals for vehicular security address communication, reputation, or accountability, but the reviewed works leave in-vehicle network security and ECU compromise concerns unresolved.

II. RELATED WORK

  • The reviewed blockchain proposals do not address in-vehicle network security, including the risk that compromised ECUs undermine vehicle data reliability.The paper also identifies gaps in insider-attack protection, veracity of vehicle data, and practical architecture detail across specific proposals.Source: §II · pp. 2–3
  • CreditCoin uses vehicle threshold authentication for reputation and incentives, but vehicle-held blockchain copies create storage and scalability constraints.The passage also notes possible collusion attacks.Source: §II · p. 2
  • Other reviewed schemes target reputation or collusion but omit in-vehicle network security or leave reputation construction and evaluation parameters unexplained.These limitations are reported for BARS and the enhanced DPoS proposal.Source: §II · p. 3

III. B-FERL OVERVIEW AND THREAT MODEL

B-FERL divides blockchain functions into upper and lower tiers to track ECU-state changes and monitor vehicles in operation. Vehicle records support validation, while RSUs challenge vehicles to report ECU integrity.

A. Architecture overview

  • The two blockchain tiers separate information by entity role while supporting both ECU-state history and operational vehicle monitoring.The framework assigns the upper tier to vehicle lifecycle activity and the lower tier to vehicle checks at RSUs.Source: A. Architecture overview · p. 3
  • The upper tier records vehicle state and ECU firmware hashes, along with maintenance or diagnostic actions by manufacturers and technicians.The record is used for lower-tier validation and can support liability decisions.Source: A. Architecture overview · p. 3
  • At RSU contact, a vehicle returns its cumulative ECU hash for comparison with its recorded state; timestamps help detect replay, while older transactions move to cloud storage.The lower tier retains the previous and current ECU firmware states; cloud storage can add latency and RSU computing and bandwidth requirements.Source: A. Architecture overview · p. 3

B. Network model

B-FERL uses a two-tier network to restrict information access to authorized entities. The upper tier handles vehicle-related records and maintenance activity, while the lower tier connects vehicles and RSUs for integrity checks.

B. Network model

  • The two tiers distinguish vehicle-record and maintenance activity from operational monitoring of vehicles through RSUs.The framework describes the tiers as limiting entities to information they need to know.Source: B. Network model · p. 3
  • The upper tier includes transport and legal authorities, manufacturers, technicians, and potentially insurers; the lower tier includes CAVs and RSUs.RSUs are installed by the road transport authority to manage and monitor traffic.Source: B. Network model · pp. 3–4
  • RSUs challenge vehicles for current ECU state; a valid response makes the vehicle trustworthy until another challenge-response check.The network model uses PKI for identifiable digital identities and secure communication between permissible entities.Source: B. Network model · p. 4

C. Threat Model

The paper considers attacks that can undermine vehicle data and the framework, then describes a two-tier blockchain design and its transaction mechanisms. Transactions record vehicle initialization and maintenance, while challenge-response exchanges check ECU integrity.

C. Threat Model

  • The threat model includes fake data, code injection, Sybil, masquerade, and ECU state reversal attacks.Examples include false traffic reports, fake vehicle identities, and installing malicious ECU firmware before reverting it for verification.Source: C. Threat Model · pp. 4–5

IV. BLOCKCHAIN BASED FRAMEWORK FOR SECURING SMART VEHICLES (B-FERL)

  • B-FERL uses per-vehicle blockchain blocks keyed by public keys, with linked transactions that can be appended to existing blocks.The architecture adopts appendable blocks to support transactions from multiple CAVs being appended at the same time.Source: §IV · p. 5

A. Transactions

  • Transactions use hashes, digital signatures, and asymmetric encryption to secure exchanges, including vehicle genesis, maintenance updates, insurance requests, and RSU challenge-responses.Genesis records include the initial SSID and ECU firmware hashes; challenge-responses ask the vehicle to compute its SSID and hashes of randomly selected ECUs.Source: A. Transactions · pp. 5–6

B. Operation

B-FERL operates as a permissioned framework: authorities manage the blockchain tiers, while manufacturers, technicians, and CAVs contribute records or state-integrity data.

B. Operation

  • Road transport and legal authorities have rights to manage the blockchain in the upper and lower tiers.Source: B. Operation · p. 6
  • Manufacturers and service technicians generate data when actions alter a CAV’s internal state.Source: B. Operation · p. 6
  • CAVs prove ECU integrity when they connect to an RSU, and the framework defines initialization and update operations.Source: B. Operation · p. 6

1) Initialization:

Initialization creates a blockchain record for a CAV through a genesis transaction and verification. The process includes creating a record block for the vehicle.

1) Initialization:

2) Update:

B-FERL updates CAV records after maintenance or diagnostics and during RSU challenge-response checks. The RSU validates vehicle identity and ECU state, while later checks also use timestamps and limit each lower-tier block to two transactions.

2) Update:

  • Manufacturer diagnostics or technician maintenance updates the upper-tier record with a new ECU Merkle root and a signed, timestamped transaction describing the work.Verifiers validate the proposer’s signature before creating an update block and broadcasting it to the lower tier.Source: 2) Update · p. 6
  • An RSU challenges an approaching CAV to prove its current sensor state; the CAV returns its SSID and selected ECU hashes with a signature, timestamp, and public key.Source: 2) Update · p. 7
  • The RSU checks that the CAV has a blockchain record, validates the response signature, and compares reported hashes with the recorded firmware hash.A missing record or hash mismatch is reported to the road transport and legal authorities; matching hashes allow the RSU to update the lower-tier record.Source: 2) Update · p. 7
  • At a subsequent RSU, the timestamp is compared with the previous lower-tier record; each CAV block retains two transactions, with the genesis transaction moved to cloud storage after a successful check.The authors also describe reliance on SSID mismatch or comparison with other vehicles’ timestamps as alternatives when assessing a maliciously advanced timestamp.Source: 2) Update · p. 7
  • The challenge-response process builds a CAV behaviour profile and records vehicle and service-entity actions as historical evidence for liability decisions.Source: 2) Update · p. 7

V. PERFORMANCE EVALUATION

The emulated evaluation measures B-FERL’s processing times and RSU storage requirements as vehicle and ECU counts increase. Reported results include low challenge-validation times and storage needs considered feasible for New South Wales.

V. PERFORMANCE EVALUATION

  • Block creation time increases from 0.31 ms for 10 CAVs to 0.49 ms for 200 CAVs.The emulated scenario uses five lower-tier RSUs and averages ten runs; the reported standard deviations are 0.12 ms and 0.22 ms, respectively.Source: §V · p. 7, Figure 5 · p. 8
  • Challenge validation rises from 1.37 ms for 10 CAVs to 2.02 ms for 200 CAVs, while an RSU update takes 0.06 ms for 200 CAVs.The reported challenge-validation times are averages; the evaluation says they increase linearly with CAV count.Source: §V · p. 7, Figure 6 · p. 8
  • Computing a CAV’s Merkle tree root takes about 12 ms at 1,000 ECUs, with time growing linearly as ECU count increases.The experiment varies the number of ECUs from 10 to 1,000.Source: §V · pp. 7–8
  • Around 5 Gb of RSU storage is reported as sufficient for the blockchain structure in New South Wales.The authors describe this storage requirement as feasible for an RSU to maintain the state’s blockchain.Source: §V · p. 8

VI. DISCUSSION

The discussion section covers security, use cases, and comparison with related work. Its supplied figure captions identify Merkle-root computation time and blockchain size as topics.

VI. DISCUSSION

  • The discussion covers security, use cases, and a comparative evaluation of B-FERL against related work.The supplied passage gives the section’s scope but no comparative findings.Source: §VI · p. 8
  • Figure 7 is titled as measuring the time to calculate the Merkle tree root.The supplied material does not state the figure’s values or comparisons.Source: Figure 7 · p. 9
  • Figure 8 is titled as reporting blockchain size.The supplied material does not state the figure’s values or comparisons.Source: Figure 8 · p. 9

A. Security analysis

The paper argues that B-FERL’s challenge-response checks and blockchain records address several attack types and support forensic, trust-management, and communication-security use cases. It also notes a privacy trade-off from public-key identification.

A. Security analysis

  • Random ECU integrity challenges and blockchain timestamps are presented as defenses against state reversal, while challenge-response checks detect fake data and public-key records help identify valid vehicles.The security discussion also says upper-tier records can trace technician and manufacturer actions, and that creating multiple valid entities is infeasible in the approach.Source: A. Security analysis · p. 9
  • Public-key use introduces a privacy and anonymity trade-off, but the RSU uses the key to identify a vehicle without requiring transmission of sensitive privacy-related information.Source: A. Security analysis · p. 9

B. Use case

  • Forensics combines upper-tier records of authorized manufacturer and technician actions with lower-tier challenge-response history as evidence for liability decisions.The paper describes using pre-accident vehicle behavior together with accident data captured by the vehicle.Source: B. Use case · p. 9
  • Trust management relies on a CAV’s own historical challenge-response evidence rather than witness vehicles to assess the veracity of its data.The paper notes that witness-dependent approaches can make wrong decisions when witnesses are scarce and can facilitate collusion or badmouthing.Source: B. Use case · p. 9
  • Challenge-response checks can identify compromised CAVs for notification and allow authorities to revoke their communication rights.The stated purpose is to prevent other CAVs from communicating with a compromised vehicle and to prevent further compromise through false messages.Source: B. Use case · p. 10

C. Comparative evaluation

B-FERL is compared with prior in-vehicle security work across security requirements, and the conclusion reports resilience to attacks and practical applicability in simulated scenarios. The framework also supports compromise detection, response, and automotive applications including trust management and forensics.

C. Comparative evaluation

  • Against prior work, B-FERL addresses insider actions, decentralization, privacy, and safety through interaction records, ECU-state verification, and restricted information access.The comparison covers works,, and.Source: C. Comparative evaluation · p. 10

VII. CONCLUSION

  • B-FERL queries vehicle internal controls to identify ECU compromise and escalates detected cases to relevant authorities for action.The conclusion describes the framework as both a detection and reaction mechanism.Source: §VII · p. 10
  • The conclusion presents B-FERL for trust management, secure vehicular networks, and forensics, where it can provide non-repudiable, reliable evidence for liability attribution.Source: §VII · p. 10
  • Security analysis reports resilience to attacks, including those by supposedly benign internal entities, while simulation results indicate practical applicability in realistic scenarios.The conclusion identifies privacy implications as a future direction for vehicles traveling between roadside units.Source: §VII · p. 10
Loading 2007.10528v1…