Detecting Sybil Attacks using Proofs of Work and Location in VANETs

TL;DR

This paper introduces a novel scheme for detecting Sybil attacks in VANETs by combining proofs of work with location-based trajectory analysis, effectively preventing fake identities with high detection accuracy.

Contribution

The scheme uniquely integrates proofs of work with location-based trajectory verification, requiring multiple RSUs for trajectory creation, enhancing Sybil attack detection in VANETs.

Findings

High detection rate for Sybil attacks

Low false negative rate

Acceptable communication and computation overhead

Abstract

In this paper, we propose a Sybil attack detection scheme using proofs of work and location. The idea is that each road side unit (RSU) issues a signed time-stamped tag as a proof for the vehicle's anonymous location. Proofs sent from multiple consecutive RSUs is used to create vehicle trajectory which is used as vehicle anonymous identity. Also, one RSU is not able to issue trajectories for vehicles, rather the contributions of several RSUs are needed. By this way, attackers need to compromise an infeasible number of RSUs to create fake trajectories. Moreover, upon receiving the proof of location from an RSU, the vehicle should solve a computational puzzle by running proof of work (PoW) algorithm. So, it should provide a valid solution (proof of work) to the next RSU before it can obtain a proof of location. Using the PoW can prevent the vehicles from creating multiple trajectories in case of low-dense RSUs. Then, during any reported event, e.g., road congestion, the event manager uses a matching technique to identify the trajectories sent from Sybil vehicles. The scheme depends on the fact that the Sybil trajectories are bounded physically to one vehicle; therefore, their trajectories should overlap. Extensive experiments and simulations demonstrate that our scheme achieves high detection rate to Sybil attacks with low false negative and acceptable communication and computation overhead.

Tables

Table 1. Table I: System Notations.

Symbol	Description
$t$	The threshold of $(t,n)-$threshold signature protocol.
$S{K}_{R_i}$	The partial private key assigned to the RSU $R_i$
$P{K}_{v_i}/S{K}_{v_i}$	Public/ Private key pair for vehicle $V_i$.
${\sigma }_{R_i}$	A partial signature from RSU $R_i$.
$C_{TA}\left(P{K}_{v_i}^j\right)$	A certificate from the TA on $P{K}_{v_i}^j$
$T$	A target from solving the PoW puzzle.
${𝒯}_i$	The trajectory of a vehicle.
$l$	Number of RSUs that a vehicle encounters.

Table 2. Table II: Overall computation and communication overhead comparison.

	Footprint [4]	Our scheme
Computation overhead ($ms$)	27 Exp	$\left(1\cdot \text{Exp}+2\cdot \text{Pairing}\right)\times t$
Communication overhead (Bytes)	$24\cdot l+372$	$24\cdot l+20\cdot t$

Equations

$$q(x)=d+\sum _{j=1}^{t-1}{a}_j{x}^j$$

$$d=\sum _{P_i\in A}{d}_i{\delta }_i^A=\sum _{P_i\in A}{d}_i(\prod _{P_j\in (A\text{textbackslash}{P}_i)}\frac{-{\alpha }_j}{{\alpha }_i-{\alpha }_j})$$

$${\sigma }_{S{K}_i}(m)=\mathcal{H}(m{)}^{S{K}_i}$$

$${\sigma }_{SK}(m)=\prod _{i\in \mathcal{A}}{\sigma }_{S{K}_i}(m{)}^{{\delta }_i^A}=\mathcal{H}(m{)}^{{\sum }_{i\in \mathcal{A}}{\delta }_i^{A}S{K}_i}=\mathcal{H}(m{)}^{SK}$$

$$H(n||H({\mathcal{T}}_{R_1}))<T$$

$$S({\mathcal{T}}_i,{\mathcal{T}}_j)=\{\begin{array}{ll}\frac{|{\mathcal{T}}_i\cap {\mathcal{T}}_j|}{Min\{|{\mathcal{T}}_i|,|{\mathcal{T}}_j|\}}& negative\text{leavevmode}test\\ -1& positive\text{leavevmode}test,\end{array}$$

$$Pr[T<t]={\int }_{-\infty }^{t}pmf(t)dt$$

$$P(k)=\frac{\left(\genfrac{}{}{0ex}{}{K}{k}\right)\left(\genfrac{}{}{0ex}{}{N-K}{n-k}\right)}{\left(\genfrac{}{}{0ex}{}{N}{n}\right)}$$

$$F(k)=\frac{{\lambda }^k{\exp }^{-\lambda }}{k!}$$

$$S(i)=Pr(X\ge i)=\sum _{k=i}^{\text{rotatebox}90.08}F(k)$$

$$Pr(X\ge i{)}^j={\left(\sum _{k=i}^{\text{rotatebox}90.08}F(k)\right)}^j\approx {\left(\sum _{k=i}^{\text{rotatebox}90.08}\frac{{\lambda }^k{\exp }^{-\lambda }}{k!}\right)}^j$$

$$FPR=\frac{FP}{FP+TN}$$

$$FNR=\frac{FN}{FN+TP}$$

$$DR=\frac{TP}{TP+FN}$$

Full text

I Introduction

Over the last two decades, Vehicular Ad Hoc Networks (VANETs) have been emerging as a cornerstone to the next generation Intelligent Transportation Systems (ITSs), contributing to safer and more efficient roads. In VANETs, moving vehicles are enabled to communicate with each other via intervehicle communications as well as with road-side units (RSUs) in vicinity via RSU-to-vehicle communications. As a result, a wide spectrum of applications have been emerged as promising solutions [1] to enable new forms of ubiquitous traffic management applications that are not possible with our current traditional transportation system. The core idea of these applications is to enable vehicles to contribute with data and feedback to an event manager which can build a spatiotemporal view of the traffic state and also to extract important jam statistics [2]. These applications have the potential to contribute to safer and more efficient roads by enabling a wide range of applications such as pre-crash sensing and warning, traffic flow control, local hazard notification, and enhanced route guidance and navigation [3].

However, the aforementioned applications depend on information sent from participating vehicles. Therefore, it is required to preserve drivers privacy especially location privacy while still verifying their identities in an anonymous manner [4, 5]. A naive solution is to allow each vehicle to have a list of pseudonyms to be authenticated anonymously. However, a malicious vehicle may abuse this privacy protection to launch Sybil attack [6]. In Sybil attacks, a malicious vehicle uses its pseudonyms to pretend as multiple fake (or Sybil) nodes [7]. The consequences of a Sybil attack in VANETs can be disastrous. For example, a malicious vehicle can launch the attack to create an illusion of traffic congestion. Consequently, other vehicles will choose an alternative route and evacuate the road for the malicious vehicle. Another potential consequence of a Sybil attack is in safety-related applications such as collision avoidance and hazard warnings where a Sybil attack can lead to biased results that may result in car accidents [3]. Hence, it is of great importance to detect Sybil attacks in VANETs.

Existing works of detecting Sybil attacks can be categorized into three categories, namely, identity registration, position verification and trajectory-based approaches. The ultimate goal of these detection mechanisms is to ensure each physical node is bounded with a valid unique identity. Firstly, identity registration approaches [8, 7, 9] require a dedicated vehicular public key infrastructure to certify individual vehicles with multiple pseudonyms to ensure each physical node is bounded with a valid unique identity. However, identity registration alone cannot prevent Sybil attacks, because a malicious node may get multiple identities by non-technical means such as stealing or even collusion between vehicles [10]. Secondly, position verification approaches depend on the fact that individual vehicle can present at only one location at a time. In [11], [3], localization techniques such as Global Positioning System (GPS) are used to provide location information of vehicles to detect Sybil nodes. However, these schemes fail due to the highly mobile context of vehicular networks [12]. Thirdly, trajectory-based approaches is based on the fact that individual vehicles move independently, and therefore they should travel along different routes. In [4], the vehicle obtains its trajectory by combining a consecutive tags from RSUs which it encounters. However, the scheme suffer RSU compromise attack in which if one RSU is compromised, a malicious vehicle can obtain infinite number of valid trajectories. Moreover, in case of rural areas (RSUs are not dense), attackers can create valid trajectories that look for different vehicles.

In this paper, we propose a novel Sybil attack detection scheme using proofs of work and location. The main idea is that when a vehicle encounters an RSU, the RSU should issue authorized time-stamped tag which is a concatenation of time of appearance and anonymous location tag of that RSU. As the vehicle keeps moving, it creates its trajectory by combining a set of consecutive authorized time-stamped tags that are chronologically chained to each other. That trajectory is used as an anonymous identity of the vehicle. Since RSUs have the main responsibility to issue proof of location to vehicles, the scheme should resist against RSU compromise attack so we design the trajectory so that not only one RSU is capable of creating trajectories for the vehicles. To achieve this, threshold signature is adopted so that each RSU is only able to generate a partial signature on a set of time-stamped tags. Once a vehicle travels along a certain threshold number of RSUs, a standard signature representing a proof of location can be generated. Upon receiving an authorized message from an RSU, the vehicle should use it as a seed to solve a puzzle using a proof-of-work algorithm, similar to the one used in Bitcoin [13]. The core idea of PoW is to provide a proof to RSUs so they can ensure that the vehicle solved the puzzle correctly. Comparing to Footprint [4], using PoW limits the ability of a malicious vehicles to create multiple trajectories. To detect Sybil trajectories, upon receiving an event from other vehicles, the event manager first applies a set of heuristics to construct a connected graph of Sybil nodes, then it uses the maximum clique algorithm [14] to detect all Sybil nodes in that graph.

Our main contributions and the challenges the paper aims to address can be summarized as follows:

• •

We used threshold signatures to resist RSU compromise attacks. The attacker needs to compromise an infeasible number of RSUs to be able to create fake trajectories.

• •

We used the PoW algorithm to limit the ability of a malicious vehicle to create multiple forged trajectories, and more importantly, to reduce the detection time for detecting Sybil trajectories which is a critical concern in traffic management applications.

• •

We carefully analyzed the probabilistic nature of PoW based scheme by examining the affecting parameters (e.g travel time between two consecutive RSUs) experimentally, and then we developed a mathematical model that can be used for adjusting these parameters so that the ability of a malicious vehicle to create forged trajectories is reduced significantly.

• •

By experiments, we prove that using the proof of work algorithm reduces the ability of a malicious vehicle to maintain actual multiple trajectories simultaneously. Further simulations, analysis, and practical experiments are conducted to evaluate the proposed scheme and compare it with the Footprint [4], the results indicate that the proposed scheme can successfully detect and defend against Sybil attacks in VANETs and more efficiently compared to the Footprint.

The rest of the paper is organized as follows. We describe the network and threat models in VANETs, followed by the design goal of our Sybil detection scheme in Section II. In Section III, we discuss preliminaries used by this research work. Then, our proposed scheme is presented in Section IV. In Section V, we show the selection of PoW parameters values experimentally, and also we provide a mathematical proof of the experimental results. Detailed security and performance evaluations are provided in Section VI. We present the computation complexity analysis of our scheme in Section VII. Section VIII discusses the previous research work in Sybil detection in VANETs. Finally, we give concluding remarks in Section IX.

II Models And Design goals

In this section, we present the considered network model followed by the adversary and threat models, and then, we introduce the design goals of our scheme.

II-A Network Model

As depicted in Fig. 1, the considered network model has the following entities.

• •

Roadside units (RSUs): RSUs act as a typical wireless access points that can communicate with vehicles within its vicinity. They can communicate with each other via a dedicated network or the Internet [4].

• •

Vehicles: Vehicles are equipped with On-board units (OBUs) that have two main parts: a short-range wireless module (e.g., DSRC IEEE 802.11p [15]) and a GPS receiver. Vehicles communicate with each other and with RSUs that are deployed along the road.

• •

Offline Trusted Authority (TA): TA is responsible for vehicles registration, issuing digitally certified pseudonyms to vehicles, deployment of RSUs, and ensuring the security of VANETs. In practice, the TA can be the Department of motor vehicles (DMV).

• •

Event Manger (EM): EM is responsible for managing the traffic management applications and also detecting Sybil trajectories upon receiving a reported event from vehicles.

II-B Adversary and Threat Model

The TA is fully trusted because it is operated by the government which is interested in the security of the VANET. RSUs are honest-but-curious in running the scheme correctly but they are interested to collect the location information of the drivers. Also, attackers can compromise a number of RSUs. The vehicles are not trusted and may launch Sybil attacks by pretending as multiple fake identities. Attackers can collude with each other and share their pool of pseudonyms. The event manager is honest-but-curious in running the Sybil attack detection scheme, but it should not be able to reveal the actual identities of drivers.

II-C Design Goals

Our Sybil detecting scheme should achieve the following objectives:

Resisting RSU compromise. Since RSUs are the responsible for generating trajectories for vehicles, the scheme should be resistant to RSU compromise attack. 2. 2.

Short Sybil attack detection time. The time to detect Sybil attacks should be short. This objective is important in time-sensitive applications such as traffic management. 3. 3.

Location privacy preserving. The location privacy of vehicles’ drivers should be preserved while vehicles need to authenticate themselves anonymously. 4. 4.

Unlinkability. The message sent by a vehicle at different locations or times should not be linkable. Also the messages of the same vehicle should not be linkable over the time. This Unlinkability objective is important because $\displaystyle(i)$ by knowing the locations visited by anonymous drivers, the attacker can identify the driver; $\displaystyle(ii)$ by linking messages, too much location information can be exposed if the attackers manages to know the sender of the message.

III Preliminaries

In this section, we present the necessary background on secret sharing and threshold signatures that we will use in our scheme. The notation used in the paper are listed in Table. I

III-A Secret Sharing

In a secret sharing schemes, a trusted party distribute a secret key $\displaystyle d$ among a group $\displaystyle\mathcal{P}=\{P_{1},...,P_{n}\}$ of $\displaystyle n$ participants, each of which owns a share of the secret in such a way that at least any $\displaystyle t$ participants can use their secret shares to reconstruct the secret.

Shamir [16] have proposed a $\displaystyle(t,n)$-threshold secret sharing scheme in which at least $\displaystyle t$ participants are capable of recovering the secret. Indeed, let $\displaystyle\mathbb{Z}_{p}$ be a finite field with $\displaystyle p$ > $\displaystyle n$ and $\displaystyle d\in\mathbb{Z}_{p}$ is the secret key to be shared. The TA chooses a polynomial $\displaystyle q(x)$ of degree at most $\displaystyle t-1$ which can be written as:

[TABLE]

where $\displaystyle a_{j}\in\mathbb{Z}_{q}$ is randomly chosen. Each participant ($\displaystyle P_{i}$) is assigned a secret share $\displaystyle d_{i}=q(\alpha_{i})$. The set of shares yields a $\displaystyle(t,n)$ threshold access structure where at least a set $\displaystyle A\in\mathcal{P}$ can retrieve the secret key $\displaystyle d$ using Lagrange interpolation technique as follows:

[TABLE]

Values $\displaystyle\delta^{A}_{i}$ are known as Lagrange coefficients. It can be proven that less than $\displaystyle t$ participants cannot get the secret $\displaystyle d$.

III-B Threshold signatures

A regular signature generation algorithm takes as inputs message, $\displaystyle m$, and a sender’s private key $\displaystyle SK$ and output a digital signature $\displaystyle\sigma_{SK}(m)$. The receiver can verify the signature using the sender’s public key $\displaystyle PK$. A (t, n)-threshold signature is used to share the signing operation between a subset $\displaystyle t$ of $\displaystyle n$ participants rather than giving the power of signing to only one participant. The idea is that a secret key, $\displaystyle SK$, is divided into shares and each share ($\displaystyle SK_{i}$) is assigned to one of the group participants. To sign a message, a member can use his secret share of the secret key to generate a partial signature called signature share $\displaystyle\sigma_{i}$. Then, a subset of at least $\displaystyle t$ participants can compute a valid signature $\displaystyle\sigma_{SK}(m)$ on $\displaystyle m$ by combining their signature shares. This signature can be verified by anybody using a unique public key.

We adopt an efficient threshold signature scheme proposed by Alexandra [17] that is based on Gap Diffie-Hellman (GDH) groups [18] for forth reasons. First, it has proven to be secure. Second, anonymity is provided by unlinking the $\displaystyle SK_{i}$ with the identity of the signer. Third, generating a signature does not require any interaction or any zero-knowledge proofs with versifiers. Forth, the signature shares are short, and signature reconstruction requires only the multiplication of signature shares. Moreover, it imposes low computational overhead since the signing process only requires hash computations and modular exponentiation and the verification process requires two pairing operations.

A brief description to the threshold signature scheme is as follows. Let $\displaystyle\mathbb{G}$ be a GDH group of prime order $\displaystyle p$ and $\displaystyle g$ be a generator of $\displaystyle\mathbb{G}$ and $\displaystyle\mathcal{H}:\{0,1\}^{*}\rightarrow{\mathbb{G}}$ is a public one-way and collision-resistant hash function. Each participant $\displaystyle P_{i}$ should have a secret share $\displaystyle SK_{i}$ using methods described in [19]. A participant $\displaystyle P_{i}$ uses its secret share to compute the signature share on a message ($\displaystyle m$) as:

[TABLE]

After a set $\displaystyle A$ of at least $\displaystyle t$ participants compute their signature shares for message $\displaystyle m$, a standard signature for the message can be calculated as:

[TABLE]

Where $\displaystyle\delta^{A}_{i}$ are Lagrange coefficients.

IV Proposed scheme

In this section, we present our Sybil detection scheme. We first start with system initialization, then we show how vehicles obtains proof-of-location messages. Then, we describe the role of the PoW followed by an illustrative example of trajectory creation in our scheme. Finally, we describe the how the event manager can detect Sybil trajectories.

IV-A Overview

In our scheme, vehicles should request proof of location form each RSU it encounters as a proof of its presence there. The issued proof of location message should be temporarily linkable to preserve the drivers’ locations privacy.

In our scheme, we used threshold signatures to prevent such kind of attack. We introduce Proof-of-Work (PoW) algorithm as first layer of defence to Sybil attacks since it reduces the possibility of a malicious vehicle to obtain multiple trajectories successfully. The vehicle should solve a puzzle while moving to the next RSU. Then, an RSU can issue a proof of location to the vehicle but after verifying the puzzle solution. However, some malicious vehicles can create multiple trajectories to launch a Sybil attack. Therefore, we apply a second layer of defence using some heuristics that define forged trajectories (created by malicious vehicles). So, once a vehicle reports a particular event such as road congestion or accident, it should also submit its trajectory (A set of consecutive proof of locations issued for a vehicle by RSUs that are timely chained together) for identification. Then, a event manager conducts Sybil attack detection by first check the similarity relationship among each pair of trajectories. Then, Sybil trajectories from the same attacker are overlapped within the same "group". Finally, each group will be considered as one single physical vehicle. By this way, Sybil nodes can be eliminated. In the following sections, we describe our scheme in details.

IV-B System Initialization

During this stage, RSUs are divided into groups in such a way that each group cover a certain area or a road segment. Then, the TA sends to the RSUs within each group the credentials they need for a $\displaystyle(t,n)$ threshold signature, where $\displaystyle n$ is the number of RSUs deployed in the group. In order to do this, a polynomial of degree $\displaystyle t-1$ is calculated at different points $\displaystyle\alpha_{i}$, for $\displaystyle i=1$ to $\displaystyle n$. Then, the TA generates a public key $\displaystyle PK$ and a list of $\displaystyle n$ secret key shares $\displaystyle SK_{i}\,\forall\,i=\{1,\dots,n$} of the secret key ($\displaystyle SK$). After that, TA sends to each RSU via a secure channel a secret key share $\displaystyle(SK_{i})$ and the public key $\displaystyle(PK)$ as well as a list of public keys corresponding to the secret key shares of the neighbouring RSUs. To ensure RSUs are issuing trajectories for legitimate vehicles, each vehicle generates a set of public/private key pairs and obtain certificates for each public key from the TA so that vehicles can anonymously authenticate themselves to the RSUs. Getting these certificates from the TA can be done during vehicle registration from, e.g., the Department of motor vehicles (DMV).

IV-C Exchanged Messages

In this subsection, we illustrate by an example of how a vehicle can construct its trajectory through Fig. 2. Assume a threshold signature with $\displaystyle t=3$ and a vehicle $\displaystyle v_{1}$ is traveling along the following RSUs [$\displaystyle R_{1},R_{2},R_{3},R_{4}$]. To ensure anonymity, $\displaystyle v_{1}$ should in advance generate a list of temporary public/private keys. Then, $\displaystyle v_{1}$ starts creating its trajectory as follows:

When $\displaystyle v_{1}$ first encounters $\displaystyle R_{1}$, it can start its trajectory by simply sending a public key $\displaystyle PK^{1}_{v_{1}}$ from the temporary key pair $\displaystyle[PK^{1}_{v_{1}},SK^{1}_{v_{1}}]$ with the certificate of the TA $\displaystyle C_{TA}(PK^{1}_{v_{1}})$. 2. 2.

$\displaystyle R_{1}$ first authenticates the vehicle if it is legitimate to request a proof of location by checking the vehicle’s certificate. Then, it generates a proof of location message $\displaystyle m_{1}=\{PK^{1}_{v_{1}},(t_{1},Tag_{R_{1}})\}$ where $\displaystyle t_{1}$ is the current time stamp and $\displaystyle\sigma_{R_{1}}(m_{1})$ is signature share of $\displaystyle R_{1}$ on $\displaystyle m_{1}$. Then, $\displaystyle R_{1}$ sends $\displaystyle\mathcal{T}_{1}=m_{1}||\sigma_{R_{1}}$ back to the vehicle. 3. 3.

Upon receiving the message ($\displaystyle\mathcal{T}_{1}$) and to limit a malicious vehicle ability to generate multiple trajectories, the vehicle should use it as a seed to run the proof of work (PoW) algorithm. The idea of using Proof-of-work concept, was proposed in [20] to defend against denial-of-service attacks and email spams, and recently has become more popular for its use to secure bitcoin [13]. In PoW, a prover (i.e., a vehicle) before request a proof of location from an RSU, he/she should solve a certain computational challenging puzzle to prove that a certain amount of time has been taken to solve this puzzle. The verifier (i.e., an RSU) on the other side can verify that the proof is valid with a negligible computational cost. We adopt the Hashcash PoW technique used in Bitcoin [13] as follows:

[TABLE]

where $\displaystyle H$ is a secure hash function e.g. SHA-256, $\displaystyle\mathcal{T}_{R_{1}}$ is the authorized proof of location issued from an RSU $\displaystyle R_{1}$, $\displaystyle T$ is an expected target value and $\displaystyle n$ is a nonce value. The puzzle problem is to find the appropriate nonce value $\displaystyle n$ to make the hash value less than a certain target, $\displaystyle T$. Brute force is the only known way to solve the puzzle problem. The computational difficulty of problem solving depends on the value of $\displaystyle T$. The smaller the value $\displaystyle T$, the more difficult it is to generate the proper nonce value and more time is required to generate such nonce. Note that the longer it takes a vehicle to travel between two RSUs, the more time it has to solve the PoW puzzle and hence the lower the expected target value should become. Upon arriving at the next RSU, the vehicle should submit the lowest $\displaystyle T$ value resulted from running the PoW algorithm to the RSU. To illustrate, after a vehicle $\displaystyle v_{1}$ receives the authorized message $\displaystyle\mathcal{T}_{1}$ from $\displaystyle R_{1}$, it should use $\displaystyle\mathcal{T}_{1}$ as a seed value to run the PoW algorithm. Once $\displaystyle v_{1}$ encounters the next RSU (i.e., $\displaystyle R_{2}$), it should first generate a new temporary public/private key pair $\displaystyle PK^{2}_{v_{1}},SK^{2}_{v_{1}}$ and then sends the solution of solving the PoW puzzle denoted by $\displaystyle S_{\mathcal{T}_{1}}$ included in following message to $\displaystyle R_{2}$: $\displaystyle L_{R_{1}}=(\mathcal{T}_{1}||S_{\mathcal{T}_{1}}||PK^{2}_{v_{1}})||\sigma_{SK^{1}_{v_{1}}}(\mathcal{T}_{1},S_{\mathcal{T}_{1}},PK^{2}_{v_{1}})$ 4. 4.

Once $\displaystyle R_{2}$ receives $\displaystyle L_{R_{1}}$ from $\displaystyle v_{1}$, $\displaystyle R_{2}$ verifies the message $\displaystyle L_{R_{2}}$ in two steps:

1. (a)

Ownership verification: $\displaystyle R_{2}$ first take $\displaystyle PK^{1}_{v_{1}}$ from $\displaystyle\mathcal{T}_{1}$, and check whether $\displaystyle V_{PK^{1}_{v_{1}}}(\sigma_{{SK^{1}_{v_{1}}}}(\mathcal{T}_{R_{1}},S_{\mathcal{T}_{R_{1}}},PK^{2}_{v_{1}}))=\mathcal{T}_{R_{1}}||S_{\mathcal{T}_{R_{1}}}||PK^{2}_{v_{1}}$. This is mandatory so that authorized messages cannot be misused by other vehicles since only the vehicle $\displaystyle v_{1}$ knows $\displaystyle SK^{1}_{v_{1}}$ that corresponds to its pairwise $\displaystyle PK^{1}_{v_{1}}$. Furthermore, $\displaystyle R_{2}$ further examines whether the signature share contained in $\displaystyle\sigma_{R_{1}}$ is signed by one of its neighboring RSUs. 2. (b)

PoW puzzle verification: Once $\displaystyle L_{R_{1}}$ succeeds the ownership verification step, $\displaystyle R_{2}$ further check the validity of PoW puzzle solution ($\displaystyle S_{\mathcal{T}_{R_{1}}}$) by $\displaystyle(i)$ computing $\displaystyle H(S_{\mathcal{T}_{R_{1}}}||H(\mathcal{T}_{R_{1}}))$ $\displaystyle(ii)$ Determining the travel time of $\displaystyle v_{1}$:= $\displaystyle t_{2}-t_{1}$ where the time stamp $\displaystyle(t_{1})$ is taken from $\displaystyle\mathcal{T}_{R_{1}}$ and $\displaystyle t_{2}$ is the current time of receiving $\displaystyle L_{R_{1}}$. Thereafter, it uses a look up target table to check whether the target corresponding to the time taken by $\displaystyle v_{1}$ to travel between $\displaystyle R_{1}$ and $\displaystyle R_{2}$ is actually below a certain target value. If the verification of $\displaystyle S_{\mathcal{T}_{R_{1}}}$ does not meet the required difficulty, an $\displaystyle R_{2}$ refuses contributing by its signature share to the corresponding trajectory, forcing the vehicle to start over with a new trajectory.

Note that if a vehicle does not pass either the above steps, such a vehicle will be considered as a malicious vehicle, and the RSU will terminate any further communications with it. It is worth mentioning that even if a malicious vehicle passes the ownership verification step and due to the limitation of a vehicle’s computational resources, it would be difficult for it to generate multiple trajectories simultaneously because it would have to solve a separate puzzle for each authorized message it obtains from an RSU.

Then, $\displaystyle R_{2}$ generates $\displaystyle m_{2}=PK^{2}_{v_{1}}||(t_{1},Tag_{R_{1}})||(t_{2},Tag_{R_{2}})$ and sends $\displaystyle\mathcal{T}_{2}=\{m_{2}||\sigma_{R_{2}}(m_{1})||\sigma_{R_{2}}(m_{2})\}$ back to $\displaystyle v_{1}$. Note that $\displaystyle\sigma_{R_{2}}(m_{1})$ and $\displaystyle\sigma_{R_{2}}(m_{2})$ are signature shares of $\displaystyle R_{2}$ on $\displaystyle m_{1}$ and $\displaystyle m_{2}$ respectively. 5. 5.

As this vehicle moves on and encounters $\displaystyle R_{3}$, it sends $\displaystyle L_{R_{2}}$. The authorized message generation process at $\displaystyle R_{3}$ is similar to $\displaystyle R_{2}$ but $\displaystyle R_{3}$ further use the threshold signature scheme to compute a standard signature $\displaystyle\sigma({m_{{1}}})$ for $\displaystyle m_{1}$. Then, $\displaystyle R_{3}$ sends $\displaystyle\mathcal{T}_{3}={m}_{1}||\sigma({m_{{1}}})||m_{3}||\sigma_{R_{3}}(m_{2})||\sigma_{R_{3}}(m_{3})$ back to the vehicle, where $\displaystyle m_{3}=\{PK^{3}_{v_{1}}||(t_{1},Tag_{R_{1}})||(t_{2},Tag_{R_{2}})\\ ||(t_{3},Tag_{R_{3}})\}$.

Note that $\displaystyle m_{1}||\sigma({m_{{1}}})$ represents the proof of location for the appearance of the vehicle at $\displaystyle R_{1}$ at time $\displaystyle t_{1}$. Hereafter, the vehicle can start creating its trajectory.

IV-D Creating Trajectories and Reporting Events

The vehicle can start creating its own trajectory after she encounters $\displaystyle t$ RSUs. As in Fig. 2, upon $\displaystyle v_{1}$ reaches at $\displaystyle R_{4}$, after it checks whether the received message $\displaystyle L_{R_{3}}$ passes the ownership and PoW verification steps, it can generate a standard signature $\displaystyle\sigma({m_{2}})$ over $\displaystyle m_{2}$. Here, $\displaystyle m_{2}||\sigma({m_{2}})$ represents a proof of location of $\displaystyle v_{1}$ at both $\displaystyle R_{1}$ and $\displaystyle R_{2}$. The process is repeated such that $\displaystyle R_{4}$ sends $\displaystyle\mathcal{T}_{4}={M}_{2}||\sigma({m_{{2}}})||m_{4}||\sigma_{R_{4}}(m_{3})||\sigma_{R_{4}}(m_{4})$ back to the vehicle, where $\displaystyle m_{4}=\{PK^{4}_{v_{1}}||(t_{1},Tag_{R_{1}})||(t_{2},Tag_{R_{2}})||\\ (t_{3},Tag_{R_{3}}||(t_{4},Tag_{R_{4}})\}$.

As the vehicle moves on, a set of consecutive time stamped authorized location tags issued for a vehicle are tightly chained together to form a trajectory of a vehicle. That trajectory is used as the vehicle unique anonymous trajectory.

IV-E Detecting Sybil Attacks

In this subsection, we explain how the event manager can detect and eliminate Sybil attacks. When a vehicle reports an event (e.g. an accident or a traffic jam) to the event manager, the vehicle should send its trajectory with the event message. However, since the PoW algorithm limits (but not eliminate) the chance for a malicious vehicle to obtain multiple trajectories due to its probabilistic nature as will be discussed in details in Section. V, we use a set of heuristics and graph based representations as a second layer of defence to recognize and remove trajectories sent from Sybil nodes. Note that the use of PoW is the first line of defense. Basically, and similar to [4], there are two main heuristics that can be used to decide if two trajectories are distinct (created by real vehicles) or forged (created by a malicious vehicle):

Check window size/Traverse time limit is the time required for a vehicle to travel between two consecutive RSUs. This heuristic is used since a single vehicle should not be able to traverse two consecutive RSUs in a time shorter than a certain limit that is traverse time limit or check window size. 2. 2.

Trajectory length limit is defined as the maximum number of RSUs traversed by a single vehicle within a time period. This heuristic is used since in practice vehicle will not be able to exceed a certain limit of RSUs traversed in a particular time.

Based on these two heuristics, upon receiving a number of $\displaystyle N$ trajectories by event manger, he/she can conduct Sybil attack detection as shown in flow chart illustrated in Fig. 3 as follows:

Phase 1: Conducting exclusion test. In this phase, the event manger conduct an exclusion test for each pair of received trajectories. Mainly, there are two cases where a pair of trajectories can pass the test (positive test). First, if there are two distinct RSUs tags appearing in the same check window. Second, if the number of RSUs obtained by combining all distinct RSUs in two trajectories is greater than the trajectory length limit. In all other cases, the pair of trajectories fails in the test (negative test) and they are considered suspicious. Based on the exclusion test, similarity check $\displaystyle S(\mathcal{T}_{i},\mathcal{T}_{j})$ between the two trajectories can be defined as follows:

[TABLE]

where minus one represents that $\displaystyle\mathcal{T}_{i}$ and $\displaystyle\mathcal{T}_{j}$ are distinct, $\displaystyle\mathcal{T}_{i}\cap\mathcal{T}_{j}$ denotes the set of common RSUs found when checking $\displaystyle\mathcal{T}_{i}$ and $\displaystyle\mathcal{T}_{j}$ using the check window and $\displaystyle|.|$ represents the length of a trajectory.

Phase 2: Building graph and eliminate cliques. After conducting the similarity check phase, the Sybil detection problem can be transformed into finding all complete subgraghs (called cliques) in an undirected graph where graph vertices are the vehicles’ submitted trajectories and edges represents the negative result of the exclusion test. We adopt maximum clique algorithm named "MCS" proposed by Tomita et. al. in [14] since it is a simple and faster branch-and-bound algorithm that can efficiently find a maximum clique for large number of graphs. As illustrated in Fig. 4, the idea is to pick a maximum clique (fully connected graph) iteratively and to delete all vertices in that clique and all its corresponding edges from the graph till there are no more vertices left in the graph. In this way, a malicious vehicle is allowed to represent itself once to the event manger no matter how many forged trajectories it has generated.

V Selection of PoW targets

In this section, we discuss how to select PoW target values that should be previously loaded in the look-up target table. The table maintains two values: the expected target value and the corresponding traverse time of a vehicle between two neighboring RSUs. First, we compute the target values experimentally. Then, we provide a mathematical model and compare it with the experimental results. Finally, we evaluate how the use of PoW in our scheme limits a malicious vehicle’s ability to create multiple forged trajectories.

V-A Experimental Results

The steps to obtain the look up target table experimentally is as follows. First, using Raspberry Pi 3 devices, we compute the probability distribution function ($\displaystyle pmf$) of computing PoW target values by solving the PoW algorithm considering different values of traverse times, then we compute the cumulative distribution function (CDF) of solving the PoW target values. Finally, we used the CDF to obtain the look up target table. The details of our experiment is as follows;

to simulate a vehicle, we used Raspberry Pi 3 devices with 1.2 GHz Processor and 1 GB RAM. We selected four possible traverse times particularly 10, 30, 90 and 130 seconds. Note that these values represent the possible contact time between a moving vehicle and an RSU [21]. In addition, We ran the PoW algorithm 1000 times for each traverse time value. Then, we divided the obtained target values to equal ranges and then we estimated the probability of computing each of these target ranges.

Fig. 5 shows the $\displaystyle pmf$ of the obtained target values at different traverse times. Using probability mass function in Fig. 5, the cumulative distribution function of computing a target is shown in Fig. 6. Note that the CDF is the probability that a random variable ($\displaystyle T$, that is the target value in our case) takes a value less than $\displaystyle t$ [22] as follows:

[TABLE]

For instance, from Fig. 6, at traverse time $\displaystyle t=130sec$, the probability of computing a target lower than $\displaystyle T=2^{239}$ is $\displaystyle 0.98$. That is, $\displaystyle 98\%$ of vehicles are able to compute a target value equal or greater than $\displaystyle T=2^{239}$ at traverse time equal to $\displaystyle 130sec$.

Next, using the results shown in Fig. 6, we have estimated the expected targets at different traverse times as illustrated in Fig. 7 at different target success rate values. To illustrate, 95% target success rate indicates that $\displaystyle 95\%$ of vehicles are able to compute a certain target value. For example, at traverse time 50 seconds, 95% of vehicles are able to solve the PoW below a target of $\displaystyle 2\times 10^{71}$ while 80% of vehicles were able to compute a target below $\displaystyle 1\times 10^{71}$. As depicted in Fig. 7, as the traverse time of the vehicle increases, a lower target value is expected by the next RSU. This is because the vehicles have more time to solve the PoW algorithm. Now, the lookup table can be constructed and loaded to each RSU so that RSUs can use that table to verify whether a vehicle successfully solved a PoW puzzle.

V-B Mathematical Model

As discussed above, the experimental method can be used to determine the target look-up table. However, experimental method is complex due to many parameters involved such as the hardware used, the hash function used in the PoW algorithm, and the traverse times. Therefore, in this subsection, we aim to provide a mathematical model for the probability of computing targets and compare the model with our experimental results.

Successfully solving $\displaystyle k$ PoW puzzles by a vehicle during a specific traverse time between two RSUs can be modeled by a hypergeometric distribution [23] model. This model describes the probability of having $\displaystyle k$ successes in $\displaystyle n$ draws from a finite pool of size $\displaystyle N$ that contains $\displaystyle K$ objects that are successful. This model can be mapped to our PoW computation as follows: a vehicle’ hash rate during the traverse time is equivalent to the number of $\displaystyle n$ draws from a pool of hashes of size $\displaystyle N$ to get $\displaystyle k$ successful solutions that satisfy the target which is $\displaystyle K$ in that case. Therefore, we are looking for a probability of success in solving $\displaystyle k$ PoW puzzles using the following formula:

[TABLE]

We consider the following parameters:

• •

$\displaystyle N=2^{256}$ is the output space of the hash function SHA-256.

• •

$\displaystyle K$ is the target value with a certain success rate at a particular traverse time. For the value of $\displaystyle K$, we used results obtained in Fig. 7 to get the target values at the traverse time equal to $\displaystyle 90$ sec. Basically, we used two values, $\displaystyle 16.73\times 10^{70}$ and $\displaystyle 6.34\times 10^{70}$ which are the target values at target success rate 99% and 85% respectively.

• •

$\displaystyle n=3.5\times 10^{6}$ is the number of hashes per traverse time $\displaystyle t=90sec$. This value is estimated in python.

Using the aforementioned parameters, we are able to obtain the probability of finding $\displaystyle k$ PoW solutions within a certain traverse time $\displaystyle t$ [24]. However, due to large numbers in our case, it can be hard to compute the probability mass function using Eq. 3. Nevertheless, since the range of $\displaystyle k$ is small, we can approximate the hypergeometric distribution using the Poisson distribution according to [25] as follows:

[TABLE]

where $\displaystyle\lambda=\frac{nK}{N}$.

Both the experimental and theoretical results are shown in Fig. 8. As per Fig. 8, We can conclude that, our experimental results match the approximated hypergeometric distribution. In addition, by using Eq. 4, we can generate the target look up table in Fig. 7 mathematically by merely knowing the hash rate during a certain traverse time.

V-C Importance of using PoW

Now, we examine the effect of PoW algorithm for honest vehicles and malicious vehicles. As discussed earlier, benign vehicles should submit one valid PoW solution for every puzzle. However, in case of a malicious vehicle trying to get $\displaystyle i$ trajectories, each of length $\displaystyle j$, it should be able to solve the PoW puzzle at least $\displaystyle i$ times for every RSU it encounters. Failing to solve one puzzle at any RSU leads in failing to create one of the trajectories. The probability of creating $\displaystyle i$ trajectories of length $\displaystyle j$ RSUs can be obtained as follows: First, the probability of computing $\displaystyle i$ valid PoW puzzle solutions at an RSU can be obtained by applying the survival function to the formula in Eq. 4, where, the survival function means the probability that a random variable ($\displaystyle X$) takes a value greater than $\displaystyle i$ as follows,

[TABLE]

Then, the overall successful probability of creating $\displaystyle i$ trajectories of length $\displaystyle j$ is computed as $\displaystyle Pr(X\geq i)^{j}$ and can be expressed mathematically as follows:

[TABLE]

In order to evaluate the importance of using the PoW, we define the following two key metrics:

• •

One trajectory computation successful probability ($\displaystyle P_{O}$): is defined as the probability that an honest vehicle is able to compute one valid trajectory. This probability can be mathematically computed by using $\displaystyle i=1$ in Eq. 6 since to be able to create at least one trajectory, an honest vehicle should be able to compute the target at each RSU it encounters.

• •

Multiple trajectories computation successful probability ($\displaystyle P_{M}$): is defined as the probability that a malicious vehicle can compute multiple trajectories i.e., solving multiple puzzles and compute the expected targets at each RSU it encounters. This probability can be obtained by using $\displaystyle i>1$ in Eq. 6 since to create multiple trajectories, the malicious vehicle should be able to solve more than one puzzle at each RSU it encounters.

Considering the target values obtained in Fig. 7 at traverse time equal to $\displaystyle 90$ sec., Fig. 9 shows the one trajectory computation successful probability ($\displaystyle P_{O}$) in generating a trajectory with different trajectory lengths as well as at different target success rates namely, 99%, 98% and 97%. As shown in Fig. 9, The higher the target success rate, the higher the probability of honest vehicle is able to compute a valid longer trajectory. However, setting the expected target too low at certain traverse time results in that honest vehicle will slightly sacrifice the possibility of computing a valid trajectory. Fig. 10 shows the probability of creating $\displaystyle 2,3$ and $\displaystyle 4$ trajectories with a trajectory length up to 10 as well as at different target success rates namely, 99% and 98%. It is clearly seen from Fig. 10 that the probability of creating multiple trajectories decreases significantly with the increase of trajectory length which can reduce the success of Sybil attacks by making creating multiple trajectories difficult. It can be concluded that:

1. (i)

Increasing the difficulty level of PoW puzzle by lowering value significantly reduces the multiple trajectories computation successful probability ($\displaystyle P_{M}$). However, setting the target value too low can result in honest vehicles not being able to compute a successful trajectory. Therefore, a target value should be well chosen to enable honest vehicles to create trajectories with high probability while reducing the chance of the malicious vehicles to create many trajectories. 2. (ii)

As the trajectory length increases, the lower the multiple trajectories computation successful probability and it becomes difficult for an malicious vehicle to compute multiple trajectories.

VI Security and Evaluation Analysis

In this section, we evaluate our proposed scheme and compare it with the Footprint. We first start with performance evaluation of Sybil attack detection and show by simulations the efficiency of our scheme in terms of detecting Sybil attacks and the detection time. Then, we discuss the security and privacy analysis of our scheme.

VI-A Sybil Attack Detection

In this subsection, we discuss the performance of our proposed scheme by investigating different system parameters in recognizing forged trajectories (provided by a malicious vehicle) and actual ones (issued by honest vehicles).

VI-A1 Simulation Design

Our proposed scheme was implemented using Python, and trajectories were generated based on real roadmap data. First, using OpenStreetMap project [26], we extracted the roadmap shown in Fig. 11 for Nashville city, TN, USA. The dimensions of the map are 75.5 km $\displaystyle\times$ 33 km. Second, using SUMO [27], we generated random routes for about 160 vehicles. RSUs were deployed at the edges of routes produced by the SUMO. Then, we recorded the actual trajectories generated by vehicles and truncated each trajectory into subtrajectories of lengths varying between 10 and 15 RSU’s. We then assigned every trajectory with a random start time within a 5-second window and a traverse time between two RSUs, chosen at random between 10 and 130 seconds. Accordingly, our experiment simulates a large number of vehicles with random trajectories, all starting their route within a 5 seconds time window, and each travelling with random but constant speed. From all vehicles in our simulation, we arbitrarily chose 10 per cent to simulate malicious vehicles. For every malicious vehicle, we randomly created between 1 and 10 forged Sybil trajectories.

VI-A2 Considered key metrics

We first define the following terms regarding the classifications of output of running the detection algorithm:

• •

False positives ($\displaystyle FP$): Number of Actual trajectories that are incorrectly considered Sybil trajectories .

• •

True negatives ($\displaystyle TN$): Number of actual trajectories that are correctly considered actual trajectories.

• •

True positives ($\displaystyle TP$): Number of Sybil trajectories that correctly considered Sybil trajectories.

• •

False negatives ($\displaystyle FN$): Number of Sybil trajectories that are incorrectly considered actual trajectories.

Based on the previous classifications, we consider the following three key metrics in our performance evaluation:

False Positive Rate (FPR): The ratio of all actual trajectories that are falsely identified as Sybil trajectories. This metric can be expressed as:

[TABLE] 2. 2.

False Negative Rate (FNR): The ratio of all Sybil trajectories that are incorrectly identified as actual trajectories. This can be expressed as:

[TABLE] 3. 3.

Detection Rate (DR): The ratio of all Sybil trajectories that are correctly identified as Sybil trajectories. The detection rate is equal to $\displaystyle 1-FNR$, or alternatively:

[TABLE]

The abovementioned metrics are used to evaluate the performance of our proposed scheme in comparison with Footprint [4]. We show the simulation results considering the two heuristics namely check window size and trajectory length limit explained earlier in section IV-E. For each of the two heuristics and each simulation configuration, we ran the simulation 30 times and get the average of all runs.

VI-A3 Impact of the check window size

In this simulation, we considered a constant trajectory length limit of 15 RSUs. Then, we changed the check window size from 2 to 50 seconds with an interval of 2 seconds. Fig. 12a, Fig. 12b, and Fig. 12c shows the FPR, FNR, and DR respectively at variable check window sizes for our scheme and Footprint. In both schemes, as the check window size increases, the FPR decreases. This happens because as the check window size increases, two actual trajectories are more likely to distinguish each other by having a negative similarity. Similarly, the larger the check window, the higher the FNR, since it becomes more likely that two distinct RSUs are inside the same check window and hence malicious trajectories are being falsely identified as honest. Nevertheless, the results clearly show that our scheme is better than Footprint. While the FPR remains the same as in Footprint, the FNR was decreased and the DR was increased by up to 50% relative to Footprint, respectively. Moreover, increasing the check window size results in a lower detection rate in Footprint while in our scheme the DR is not affected by the same ratio. This is because our PoW-based approach that limits the possibility of a malicious vehicle to generate multiple trajectories simultaneously.

VI-A4 Impact of the trajectory length limit

In this simulation, we examine the effect of the trajectory length limit. We consider the check window equal to 17 seconds ("best" check window size that we obtained from previous simulation) and vary trajectory length limit from 2 to 24 with an interval of two. Fig. 12d, Fig. 12e, and Fig. 12f plots FPR, FNR, and DR respectively as functions of the trajectory length limit. Similar to the results shown in Section VI-A3, our scheme outperforms the performance of Footprint. Specifically, our proposed solution reduces the FPR by around 15% relative to Footprint. Also, the FNR was decreased and the DR was increased by up to 40% relative to Footprint. This is because our PoW-based approach makes it harder for a malicious vehicle to compute forged multiple trajectories simultaneously.

VI-A5 Detection time overhead of eliminating Sybil nodes

Finally, we consider the detection time required by the event manager to run the maximum clique algorithm and identify Sybil trajectories in our proposed scheme and Footprint [4] at different values of check window sizes and different trajectory length limit values. The results is shown in Fig. 13a and Fig. 13b respectively. Note that, the presented results represent the average of running the maximum clique algorithm $\displaystyle 30$ times at each value. It can be seen from both Fig.  13a, Fig. 13b that detection time is much less than the case in Footprint. This is because of our scheme leverage the PoW algorithm which limits the attacker’s capability to create multiple successful trajectories. And hence less number of forged trajectories should be eliminated by the clique algorithm.

In another part of our evaluation, we choose a safe check window size ($\displaystyle 17$ seconds) as well as a safe trajectory length limit ($\displaystyle 15$) in our scheme and Footprint. Then, using Poisson distribution, we changed the number of forged of trajectory that a vehicle can generate. Each malicious vehicle can generate up to 40 trajectories with mean 10. Then, we run the clique algorithm and take the average of all runs. The results are shown in Fig. 13c. Our PoW based scheme outperforms Footprint. In Footprint, as the number of Sybil trajectories a malicious vehicle can generate, the computation time to detect Sybil nodes increases and reaches several seconds. As an example, if malicious vehicles were able to generate $\displaystyle 28$ forged trajectories, Footprint takes a round $\displaystyle 26$ seconds. However, our scheme can detect them in milliseconds. Therefore, although Footprint can detect Sybil nodes, it suffers from high computation cost to detect Sybil trajectories making it not suitable in VANET especially in safety-related applications which require online detection of Sybil attacks in range of milliseconds which is the case in our scheme. In addition, an attacker may try to leverage the detection time burden of the clique algorithm performed by the event manger to launch denial of service attack. This attack is very hard in our scheme thanks to the PoW that we have used in our scheme.

VI-B Security/Privacy Analysis

Our scheme meet the following security and privacy features,

Resist to RSU compromise attack: Since RSUs are mainly responsible for issuing authorized messages for the vehicles. An attacker may try to compromise an RSU to issue forged trajectories that look like legitimate. But using threshold signatures, only one RSU cannot issue a proof of location for a specific vehicle. Alternatively, the contribution of at least $\displaystyle t$ RSUs are required. Therefore, our scheme mitigates any possibility of RSU compromise attack. 2. 2.

Resist to replay attacks: An attacker may try to eavesdrop any of authorized messages from other honest vehicles to misuse them to create Sybil nodes. However, such an attack is prohibited in our scheme since RSUs should first verify any received message before it can issue a proof of location to that vehicle. An attacker shall know the temporary private key of the message owner to pass the message verification step which is difficult to achieve. 3. 3.

Resist to DoS attacks: Although Footprint can detect Sybil nodes, vehicles are free to start creating its trajectory whenever it wants. Therefore, a Sybil node can cause a denial of service attack by overwhelming honest vehicles/RSUs by a flood of forged trajectories which may cause wrong decisions such as congestion, especially in dense areas. However, in our scheme, using the PoW approach limits the ability of a malicious vehicle to create forged trajectories as discussed in Sec. V. 4. 4.

Preserve vehicles’ location privacy: Our scheme preserve the privacy of vehicle locations since the signature contained in the message is anonymous and signed by a certain threshold number of RSUs which makes an attacker unable to decide which RSU signed a particular message. Thus, no information about the location can be inferred by having an RSU signature. Also, the authorized messages issued by RSUs contain temporary location tags that change over time, therefore, if an attacker tried to memorize such location tags, this would not help in future as the RSUs changes their location tags over time. 5. 5.

No need for a predefined design for RSUs: Due to design issues in the deployment of VANETs, there may be a coverage overlap between two neighbouring RSUs transmission power. This overlap can be a severe problem, for example, in [4], when a vehicle requests proof of location from an RSU, it is possible that multiple RSUs may simultaneously receive that request and issue a proof of location for this vehicle (especially in a dense deployment of RSUs). Therefore, the vehicle can obtain multiple trajectories from different RSUs that can be misused by a malicious vehicle to launch a Sybil attack. However, our scheme resists against such problem since the PoW algorithm limits a malicious vehicle from obtaining valid multiple proofs of locations since it should pass the PoW verification step for each received puzzle. Therefore, our scheme does not require a specific configuration or design for RSUs especially in the early deployment of VANETs.

VII Computation and Communication Overhead

To evaluate the communication and computation overheads of our scheme, we implemented the required cryptographic operations using Python charm cryptographic library [28] running on Raspberry Pi 3 devices with 1.2 GHz Processor and 1 GB RAM. We used supersingular elliptic curve with the asymmetric Type 3 pairing of size 160 bits (MNT159 curve) for bilinear pairing to estimate the BLS signature used by our underlying threshold signature scheme.

VII-1 Computation overhead

The computation overhead measures the time required to create trajectories for vehicles. Indead, the computation burden in creating trajectories lies on the RSUs since the vehicle is just need to generate a signature whenever it encounters an RSU which is cheap operation. The signing and verification operations takes $\displaystyle 0.39$ ms and $\displaystyle 6.27$ ms, respectively. In our scheme, when the vehicle requests a proof of location message, the RSU needs to generate only $\displaystyle t$ signature shares. Also, an RSU should verify $\displaystyle t$ signature shares to check whether a message received from a vehicle is authentic and signed by a neighboring RSU or not. Therefore, the overall computation cost by an RSU to issue a proof of location message for a vehicle as a function of $\displaystyle t$ is $\displaystyle 0.39\cdot t+6.27\cdot t=6.66\cdot t$ ms while in Footprint, is about 27 modular exponentiations, which takes roughly $\displaystyle 9.01$ ms (i.e., $\displaystyle 110$ vehicles/second). So, to achieve trade-off between the computation overhead and security (Resist against RSU compromise), it is important to choose suitable threshold value $\displaystyle t$ (for different areas in VANETs). As an example, if $\displaystyle t=4$, RSU needs $\displaystyle 24$ ms to issue a proof of location for a vehicle ( i.e., $\displaystyle 41$ vehicles/second) which is practical even in urban area settings (condense areas) where the traverse time is about $\displaystyle 20$ seconds [29] which is sufficiently long for issuing hundreds of proof of location messages for vehicles. Therefore, our scheme is practical in urban vehicular scenario.

VII-2 Communication overhead

The communication overhead is measured by the size of transmitted message between an RSU and a vehicle in bytes so a vehicle can have its own trajectory. A message issued by an RSU should issue 4-byte timestamp, 20-byte location tag, a 20-byte signature share size in our scheme while a 372-byte signature in Footprint. Therefore, in our scheme, the message size in bytes exchanged between an RSU and a vehicle can be approximated as $\displaystyle 24\cdot l+20\cdot t$ where $\displaystyle l$ is the number of RSUs that a vehicle encounters and $\displaystyle t$ is the threshold $\displaystyle t$ of underlying $\displaystyle(t,n)-$ threshold signature protocol. Also, the communication overhead in Footprint [4] is $\displaystyle 24\cdot l+372$ bytes. It can be noted that in both our scheme and Footprint, as the trajectory of a vehicle continues to grow, the message size is increasing which consumes more communication bandwidth. To limit the size of messages and also achieve the temporary linkable feature of location tags, an event with a short period of time should be chosen. As an example, for an event with $\displaystyle 30$ minuets with a mean of $\displaystyle 60$ seconds as the traverse time between RSUs, in this case, $\displaystyle l=30$ which is relatively small and hence the less the messages’ size.

VIII Related work

The detection of Sybil attacks relies on three categories, namely, identity registration, position verification and trajectory-based approaches.

Identity registration approaches aims to ensure the trustworthy of each vehicle by using public key cryptographies, certificates and digital signatures. Zhou et al. [8] proposed a privacy-preserving scheme based on certificates to detect Sybil nodes. The department of motor vehicle (DMV) represents the certificate authority, and is responsible for providing vehicles with a pool of pseudonyms to be used to hide the vehicle’s unique identity. The pseudonyms associated with each vehicle are hashed to a common value. An RSU determines whether the pseudonyms come from the same pool by calculating the hashed values of the received pseudonyms. RSUs can detect Sybil nodes and then report such suspected vehicles to DMV. To resist against RSU compromise, the paper suggests two-level hash functions with different keys (coarse-grained keys and fine-grained keys). RSU holds each valid coarse-grained key only for a short time which does not know whether the pseudonyms belong to one vehicle or not. If an RSU is compromised, the attacker only gets the coarse-grained hash key for the current time interval while DMV stores all keys and can detect Sybil nodes by two-level hashing. Although deploying trusted certificates is the most efficient approach that can completely eliminate Sybil attacks, it also violates both anonymity and location privacy of entities. Also, relying on a centralized authority to ensure each is assigned exactly one identity which becomes a bottleneck in the large-scale network such as VANETs. In [30], Chen et al. proposed a group signature-based approach that can be used to enable a member in the group to authenticate himself/ herself anonymously. Meanwhile, if a particular node generates multiple signatures on the same message, the verifier can recognize those signatures. As a result, detecting duplicated signatures signed by the same vehicles can eliminate Sybil attack. However, the malicious vehicle can launch Sybil attack, if he can generate different messages with similar meaning. Recently, Reddy et al. [7] proposed a cryptographic digital signature based method to establish the trust relationship among participating entities.

Location verification based approaches are another solution to detects Sybil nodes based on physical measurements such as Received Signal Strength Indicator (RSSI) and Time Difference of Arrival (TDoA). Bouassida et al. [11] proposed a detection mechanism utilizing localization technique based on RSSI. First, consecutive RSSI variations are checked if they fall into a reasonable period or not. Some nodes which fail the test are labeled as "suspected". Then, distinguishability degrees are calculated for each suspected node by estimating its geographical localizations. Identities with the same estimated location are judged as Sybil nodes. However, the proposed scheme was tested in a small-scale testbed where the distance between two adjacent nodes was only 10m. Moreover, the scheme assumes a predictable propagation model for position estimation that may fail to capture notorious variations of wireless channels. Recently, Jin. al [31] proposed a detection method based on TDoA to locate the source of a message. The authors suggest installing three or more receiving sensors on a vehicle. Then, using the arrival time of a beacon message on three time-synchronized sensors, the TDoA between the three receiving sensors can be calculated. If the location is different from the claimed location included in the beacon message, then the node will be considered as a Sybil node. However, extra expenses during vehicle manufacturing are needed to implement this method.

The most relevant approach to our work is using trajectories of vehicles as its identities to ensure trust between participating nodes. In [32], RSUs broadcasts digital signatures with a timestamp to vehicles which are under its coverage. Vehicles store the RSUs signatures which they gathered in motion. However, since the time stamp is not issued for a dedicated vehicle, a malicious vehicle may claim its presence at certain RSU by merely eavesdropping such broadcasted timestamp on a wireless channel although it may have never been there at that time. In [4], Footprint has been introduced to detect Sybil attack. When a vehicle passes by an RSU, it obtains a signed message as proof of presence at this location at a particular time. A trajectory of a vehicle is a consecutive series of authorized messages collected by the vehicle as it keeps traveling. Sybil attack can be detected using the fact that the trajectories generated by an attacker are very similar. However, Footprint has some critical issues. First, in Footprint, RSUs are assumed to be fully trustworthy. However, if an RSU is compromised, it can help a malicious vehicle generate fake legal trajectories by concatenating any valid tags and timestamps. In that case, Footprint cannot detect such trajectories. Second, since any vehicle is free to start its trajectory at any time, an attacker can construct multiple trajectories while moving, causing not only Sybil attacks, but also denial of service attack because of the complexity of finding similar Sybil trajectories is very high in terms of time which is a critical concern especially in safety-related applications in VANET [33]. Third, vehicles may obtain proof of appearance from multiple RSUs simultaneously (e.g., in a dense deployment). That can be used by a malicious vehicle to launch a Sybil attack . To tackle that problem, the paper suggests configuring the transmission power of RSUs properly so that there is no coverage overlap between two neighboring RSUs. That solution is hard to achieve due to wireless communication properties.

IX CONCLUSION

Sybil attacks can cause disastrous consequences in VANETS. In this paper, we have introduced a novel approach for detecting Sybil attacks using proofs of work and location. An anonymous trajectory of a vehicle is formed by obtaining a consecutive proof of locations from multiple RSUs which it encounters. Instead of allowing only one RSU to issue authorized messages for vehicles, at least $\displaystyle t$ RSUs are required for creating a proof of location message using threshold signature to mitigate the RSU compromise attack. Also, the use of proof-of-work algorithm can limit the ability of malicious vehicles to create forged trajectories. Our evaluations have demonstrated that our scheme can detect Sybil attacks with high rate and low false negative rate. Moreover, the communication and computation overhead of the exchanged packets are acceptable.