BARS: a Blockchain-based Anonymous Reputation System for Trust Management in VANETs

Motivation

• VANETs remain vulnerable to forged messages from authenticated vehicles and tracking of vehicles or drivers.These threats can reduce transportation efficiency, cause accidents, and expose driving behavior.Source: §I · p. 1

Requirements

• Effective VANET trust models should evaluate messages using direct historical interactions and indirect opinions while supporting efficiency, privacy, and robustness.The model should work in congested and sparse situations without revealing senders’ real identities or being disabled by attacks.Source: §I · p. 1

Design challenge

• Blockchain provides immutable, publicly verifiable records but its transparency can make actions associated with a public key traceable to a real identity.BARS must therefore combine blockchain’s auditability with privacy protection.Source: §I · p. 1

BARS

• BARS establishes distributed trust management while protecting vehicle privacy through blockchain-based anonymous reputation and authentication.The system extends PKI so public keys can serve as authenticated pseudonyms without remaining linkable to real identities.Source: §I · pp. 1–2
• BARS evaluates vehicle trustworthiness from message authenticity and other vehicles’ opinions, recording messages as persistent evidence for reputation assessment.The reputation score is intended to incentivize vehicles to prevent misbehavior and mitigate forged-message distribution.Source: §I · p. 2

Overview

• State-of-the-art VANET trust models are classified as entity-centric, data-centric, or combined, but none meets all desirable requirements.The classification is presented as a comparison of recent trust models.Source: §II · p. 2

Entity-centric Trust Models

• Entity-centric models evaluate vehicle trustworthiness using reputation systems or neighbors’ opinions.Examples include multifaceted trust incorporating role, experience, priority, and majority information for real-time decisions.Source: A. Entity-centric Trust Models · p. 2

Data-centric Trust Models

• Data-centric models evaluate received-data trustworthiness using cooperative information from neighbor vehicles or roadside units.Reported approaches use content similarity, conflict, route similarity, voting weights, signal strength, geolocation, or social trust.Source: B. Data-centric Trust Models · p. 2

C. Combined Trust Models

• Combined trust models evaluate vehicle trust and data trust together.They inherit the benefits and drawbacks of both entity-centric and data-centric models.Source: C. Combined Trust Models · p. 2
• ART resists malicious attacks by evaluating data from multiple vehicles and determining node trust from functional and recommendation trust.The cited scheme combines data-level evidence with node-level trust factors.Source: C. Combined Trust Models · p. 2

Background

• The paper introduces blockchain operation, conventional PKI problems, certificate transparency, BARS components, and necessary assumptions before presenting the system.This background frames the later anonymous-authentication and reputation mechanisms.Source: §III · p. 2

A. Blockchain

• Blockchain is a cryptographically enforced distributed ledger carried out collectively in a peer-to-peer network.The paper presents it as decentralized infrastructure for storing, tracking, monitoring, managing, and sharing data.Source: A. Blockchain · p. 3

B. Certificate Transparency

• Certificate transparency maintains a public append-only log of issued certificates and supports proofs of certificate inclusion and append-only extension.Auditors can verify that a certificate is present and that one log snapshot extends another.Source: B. Certificate Transparency · p. 3

Authorities

• CA issues and revokes certificates only with LEA authorization, while recording its actions transparently on the blockchain.Every VANET entity can verify these recorded actions.Source: C. Components of BARS · p. 3
• LEA registers and monitors vehicles, evaluates reputation scores, authorizes certificate operations, and securely stores public-key–identity correlations.This preserves a controlled capability to correlate pseudonyms with real identities.Source: C. Components of BARS · p. 3

Certificate

• BARS certificates contain a public key, expiration date, and reputation score but omit the vehicle’s real identity.The certificate design supports privacy-preserving vehicle authentication.Source: C. Components of BARS · p. 3

Blockchains

• CerBC records issued certificates and provides proof of presence, while RevBC records revoked public keys and provides proof of absence.The two ledgers support certificate and revocation checks during authentication.Source: C. Components of BARS · p. 3
• MesBC records all broadcast messages as persistent evidence for disputes and reputation evaluation.This ledger supports later assessment of vehicle behavior.Source: C. Components of BARS · p. 3

Network roles

• RSUs provide proof-of-work consensus, with BARS security guaranteed under the assumption that more than half of RSUs are uncompromised.Vehicles verify blockchain records and monitor one another to detect misbehavior and forged messages.Source: C. Components of BARS · p. 3

• PKI provides secure communication between entities as long as secret keys remain uncompromised.Source: D. Assumptions · p. 3
• LEA is assumed to protect the dataset linking vehicles’ public keys with their real identities using sufficient security levels.Source: D. Assumptions · p. 3
• Blockchain security requires adversaries to be unable to compromise more than half of the RSUs.This condition is identified as a prerequisite for securing the blockchain itself.Source: D. Assumptions · p. 3
• Anonymous authentication is supported by CA and LEA functions covering system initialization, certificate update, and public-key revocation.Source: §IV · p. 3
• During enrollment, LEA validates legal-identity materials and sends a signed warrant to CA, which issues the vehicle’s initial certificate.Source: A. System Initialization · p. 3
• LEA alone retains submitted private information in a high-security database for tracking a vehicle’s real identity during disputes.Source: A. System Initialization · p. 3

• Certificates are updated before expiration, after private-key threats, or when vehicles replace public keys for privacy consideration.The new certificate updates the public key, reputation score, and expiration date.Source: B. Certificate Update · p. 3
• Vehicle A generates a new public-key and private-key pair for certificate updating.Source: B. Certificate Update · p. 3
• The encrypted update request includes current and updated public keys, real-identity proofs, and a signature using the current private key.Source: B. Certificate Update · p. 4
• After verification, LEA sends CA a signed warrant without revealing the link between the current and updated public keys to CA.Source: B. Certificate Update · p. 4
• CA issues an updated certificate containing the new public key, reputation score, and expiration time, then records it in CerBC.Source: B. Certificate Update · p. 4
• Public-key revocation instructions contain the revoked key and revocation time, after which CA broadcasts signed revocation messages.Source: C. Public Key Revocation · p. 4
• RSUs verify revocation messages, delete expired keys, and insert revoked keys lexicographically into RevBC’s Merkle tree for efficient absence proofs.Source: C. Public Key Revocation · p. 4

• A receiver accepts a certificate only after checking that it is unexpired, present in CerBC, and absent from RevBC.Source: D. Authentication Process · p. 4
• The presence proof reconstructs CerBC’s recorded root hash from direction and hash tuples; equality validates the certificate and associated public key.Source: 1) Proof of Presence · p. 4, Figure 3 · p. 4
• The absence proof uses adjacent revoked public keys and lexicographic ordering to show that the sender’s public key is not revoked.Source: 2) Proof of Absence · p. 4, Figure 4 · p. 4
• BARS uses vehicle reputation scores to determine the trust level of broadcast messages while protecting vehicle privacy.Source: §V · p. 4

• Beacon messages periodically report driving status, alert messages report emergencies, and disclosure messages report disputed authenticity or misbehavior to LEA.Source: A. Different Types of Messages · p. 4

Alert-message levels

• Level 1 alerts automatically warn of loss of vehicle control to help avoid collisions.Source: A. Different Types of Messages · p. 4
• Level 2 alerts forewarn nearby vehicles before braking, lane changes, or other driving-status changes.Source: A. Different Types of Messages · p. 4
• Level 3 alerts warn following vehicles about poor road conditions such as obstructions or road damage.Source: A. Different Types of Messages · p. 4

Reputation evaluation

• The reputation algorithm rewards honest, active alert broadcasting and disclosure of witnessed misbehavior or forged messages.Source: B. Reputation Evaluation Algorithm · pp. 4–5
• Reputation evaluation factors include alert level L, relative vehicle density Dr, and sender sequence S.The paper sets average density Daver to 20 vehicles per Km and assigns the first alert sender S = 0.Source: B. Reputation Evaluation Algorithm · p. 5
• Reward and penalty coefficients α and β implement the reward and punishment mechanisms.Source: B. Reputation Evaluation Algorithm · p. 5
• Forged alert messages receive heavy punishment, while vehicles abusing disclosure messages to slander others are also penalized and published.Source: B. Reputation Evaluation Algorithm · p. 5

• Blockchain satisfies the security requirement of certificates.Source: 1) Security of Certificates · p. 5
• Certificate security is implemented through the blockchain.Source: 1) Security of Certificates · p. 5
• The certificate system relies on blockchain technology to meet its security requirement.Source: 1) Security of Certificates · p. 5

Security of Certificates

• RSUs verify CA and LEA signatures and record certificate issuance or revocation messages in CerBC and RevBC.Source: 1) Security of Certificates · p. 5
• Proofs of presence in CerBC and absence in RevBC authenticate a vehicle’s public key, while MesBC stores broadcast messages as dispute evidence.Source: 2) Security of Broadcasted Messages · p. 5
• Using a public key as a pseudonym breaks its linkability with the vehicle’s real identity, while LEA retains the identity–key pairs for disputes.Source: 3) Privacy of Vehicles · p. 5
• Vehicle A and B gain reputation by broadcasting authentic messages, whereas forged or slanderous disclosures reduce vehicle B’s score.Source: B. Validity of Reputation Evaluation… · p. 5

Storage & Transmission Overhead

• 0.177 M/s is the reported total transmission overhead when i = 100, j = i * 10%, n = 1 000 000, and m = n * 10%.The paper describes the storage and transmission overhead of anonymous authentication as acceptable.Source: 1) Storage & Transmission Overhead · p. 6
• Authentication proofs based on SHA-256 require time and space O(logn), supporting efficient authentication in large-scale VANETs.Source: 2) Computation Overhead · p. 6
• BARS uses CerBC and RevBC proofs of presence and absence for authentication, while MesBC records broadcast messages for reputation evaluation.Source: §VII · p. 6