IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, MANUSCRIPT ID 1

Footprint: Detecting Sybil Attacks in Urban

Private Vehicular Networks Shan Chang, Yong Qi, Member, IEEE, Hongzi Zhu, Member, IEEE,

Jizhong Zhao, Member, IEEE, and Sherman Shen, Fellow, IEEE

Abstract— In private vehicular networks, where privacy, especially the location privacy of anonymous vehicles is highly

concerned, anonymous verification of vehicles is indispensable. Consequently, an attacker who succeeds in forging multiple

hostile identifies can easily launch a Sybil attack, gaining a disproportionately large influence. In this paper, we propose a novel

Sybil attack detection mechanism Footprint using the trajectories of vehicles for identification while still preserving their location

privacy. More specifically, when a vehicle approaches a road-side unit (RSU), it actively demands an authorized message from

the RSU as the proof of appearance at this RSU and time. We design a location-hidden authorized message generation

scheme for two objectives: first, RSU signatures on messages are signer-ambiguous so that the RSU location information is

concealed from the resulted authorized message; second, two authorized messages signed by the same RSU within the same

given period of time (temporarily linkable) are recognizable so that they can be used for identification. With the temporal

limitation on the linkability of two authorized messages, authorized messages used for long-term identification is prohibited. With

this scheme, vehicles can generate a location-hidden trajectory for location-privacy-preserved identification by collecting a

consecutive series of authorized messages. Utilizing social relationship among trajectories according to the similarity definition

of two trajectories, Footprint can recognize and therefore dismiss “communities” of Sybil trajectories. Rigorous security analysis

and extensive trace-driven simulations demonstrate the efficacy of Footprint.

Index Terms— Sybil attack, location privacy, signer-ambiguous signature, private vehicular networks, location-hidden trajectory.

—————————— ——————————

1 INTRODUCTION

ver the past two decades, vehicular networks have been emerging as a cornerstone of the next-generation Intelligent Transportation Systems

(ITSs), contributing to safer and more efficient roads by providing timely information to drivers and concerned authorities. In vehicular networks, moving vehicles are enabled to communicate with each other via inter-vehicle communications as well as with road-side units (RSUs) in vicinity via roadside-to-vehicle communications. In pri-vate vehicular networks where the privacy, especially the location privacy of vehicles should be guaranteed [1], [2], vehicles need to be verified in an anonymous manner. A wide spectrum of applications in such a network relies on collaboration and information aggregation among partic-ipating vehicles. Without identities of participants, such applications are vulnerable to the Sybil attack where a malicious vehicle masquerades as multiple identities [3], overwhelmingly influencing the result. The consequence can be vital. For example, in safety-related applications such as hazard warning, collision avoidance and passing assistance, biased results caused by a Sybil attack can lead to severe car accidents.

Detecting Sybil attacks in private vehicular networks, however, is very challenging. First, vehicles are anonym-ous. There are no chains of trust linking claimed identities to real vehicles. Second, location privacy of vehicles is of great concern. Location information of vehicles can be very confidential. For example, it can be inferred that the driver of a vehicle may be sick from knowing the vehicle is parking at a hospital. It is inhibitive to enforce a one-to-one correspondence between claimed identities to real vehicles by verifying the physical presence of a vehicle at a particular place and time. Third, conversations between vehicles are very short. Due to high mobility of vehicles, a moving vehicle can have only several seconds [4] to communicate with another occasionally encountered ve-hicle. It is difficult to establish certain trustworthiness among communicating vehicles in such a short time. This makes it easy for a malicious vehicle to generate a hostile identity but very hard for others to validate. Furthermore, short conversations among vehicles call for online Sybil attack detection. The detection scheme fails if a Sybil at-tack is detected after the attack has terminated.

To eliminate the threat of Sybil attacks, it is straightforward to explicitly bind a distinct authorized identity (e.g., PKI-based signatures) [6], [7], [9] to each vehicle so that each participating vehicle can represent itself only once during all communications. Using explicit identities of vehicles has the potential to completely avoid Sybil attacks but violates the anonymity concern in pri-vate vehicular networks. As an alternative scheme, re-source testing [10], [11], [12] can be conducted to differen-tiate between malicious and normal vehicles, where the

xxxx-xxxx/0x/$xx.00 © 200x IEEE

————————————————

Shan Chang，Yong Qi and Jizhong Zhao are with the Department of Computer Science and Technology, Xi'an Jiaotong University, Xi’an 710049, P.R.China. E-mail: changshan.07@stu.xjtu.edu.cn, {qiy, zjz}@mail.xjtu.edu.cn.

Hongzi Zhu and Sherman Shen are with the Department of Electrical and Computer Engineering, University of Waterloo, Canada N2L 3G1. E-mail: {hongzi, xshen}@bbcr.uwaterloo.ca.

Manuscript received (insert date of submission if desired). Please note that all acknowledgments should be placed at the end of the paper, before the bibliography.

O

2 IEEE TRANSACTIONS ON XXXXXXXXXXXXXXXXXXXX, VOL. #, NO. #, MMMMMMMM 1996

judgment is made whether a number of identities possess fewer resources (e.g., computational and storage ability) than would be expected if they were distinct. This scheme fails in heterogeneous environments where malicious vehicles can easily have more resources than normal ones. Considering the fact that a vehicle can present itself at only one location at a time, localization techniques or oth-er schemes like the Global Positioning System (GPS) aim-ing to provide location information of vehicles can be exploited to detect hostile identities. However, these schemes often fail in complicated urban settings (e.g., bad GPS signals due to urban canyons, inaccurate localization due to highly dynamic wireless signal quality). Recently, two group-signature-based schemes [17], [18] have been proposed, where a message received from multiple dis-tinct vehicles is considered to be trustworthy. Using group-signatures can provide anonymity of vehicles and suppress Sybil attacks by restrain duplicated signatures signed by the same vehicles. One practical issue of these schemes is that different messages with similar semantics may be ignored from making the decision, which leads to a biased or no final result. As a result, there is no existing successful solution, to the best of our knowledge, to tack-ling the online Sybil attack detection problem in private vehicular networks.

In this paper, we propose a novel Sybil attack detection scheme Footprint, using the trajectories of vehicles for identification while still preserving the anonymity and location privacy of vehicles. Specifically, in Footprint, when a vehicle encounters an RSU, upon request, the RSU issues an authorized message for this vehicle as the proof of its presence at this RSU and time. Intuitively, authorized messages can be utilized to identify vehicles since vehicles located at different areas can get different authorized messages. However, directly using authorized messages will leak location privacy of vehicles because knowing an authorized message of a vehicle signed by a particular RSU is equivalent to knowing the fact that the vehicle has been showed up near that RSU at that time. In Footprint, we design a location-hidden authorized message generation scheme for two purposes. First, RSU signa-tures on messages are signer-ambiguous which means an RSU is anonymous when signing a message. In this way, the RSU location information is concealed from the final authorized message. Second, authorized messages are temporarily linkable which means two authorized messages are recognizable if and only if they are issued by the same RSU within the same given period of time. Thus, autho-rized messages can be used for identification of vehicles even without knowing the specific RSUs who signed these messages. With the temporal limitation on the lin-kability of two authorized messages, authorized messages used for long-term identification is prohibited. Therefore, using authorized messages for identification of vehicles will not harm anonymity of vehicles.

To be uniquely identified, a vehicle collects a consecu-tive series of authorized messages as it keeps traveling. Such a sequence of authorized messages constitutes a trajectory of this vehicle. In Footprint, a vehicle is free to start a new trajectory by using a new temporary public

key. Furthermore, a malicious vehicle can abuse this free-dom to elaborately generate multiple trajectories, trying to launch a Sybil attack. Based on the observation that Sybil trajectories generated by a malicious vehicle are very alike, Footprint establishes the relationship between a pair of trajectories according to our definition of similar-ity. With this relationship, Sybil trajectories generated by the same malicious vehicle form a ―community‖. By find-ing and eliminate ―communities‖ of Sybil trajectories, Footprint can detect and defend against Sybil attacks. We verify that Footprint can achieve all design objectives through both security and privacy analysis and extensive trace-driven simulations which involve 2,100 taxies in Shanghai city.

The remainder of this paper is organized as follows. Section 2 introduces previous work on the Sybil attack detection problem. In Section 3, we describe the system and attack models in vehicular networks, pointing out the requirements for designing Sybil attack detection schemes in private vehicular networks. Section 4 elaborates the design of Footprint. In Section 5, we present the security analysis of Footprint. Several design issues that may be encountered in practice are discussed in Section 6. In Sec-tion 7, we conduct trace-driven simulations to evaluate the performance of Footprint and present the results. Fi-nally, we give concluding remarks and outline the direc-tions for future work in Section 8.

2 RELATED WORK

While it was first described and formalized by Douceur [3], the Sybil attack has been a severe and pervasive prob-lem in many forms. In a Sybil attack, an attacker can launch a Sybil attack by forging multiple identifies, gain-ing a disproportionately large influence. In the literature, there have been many different approaches proposed to detect or mitigate the attack.

Many studies have followed Douceur’s approach, fo-cusing on how to establish trustworthy between partici-pating entities based on trusted public key cryptogra-phies or certificates in distributed systems, for example, P2P systems [3] [6], sensor networks [7] [8] and mobile ad hoc networks [9]. Although deploying trusted certificates is the only approach that has the potential to completely eliminate Sybil attacks, it also violates both anonymity and location privacy of entities. In addition, most of these schemes rely on a centralized authority that must ensure each entity is assigned exactly one identity. Moreover, it is possible for an attacker to violate the assumption, get-ting more than one identities. This mechanism also has the problem of key revocation which is challenging, par-ticularly in wireless mobile networks.

Another category of Sybil attack detection schemes is based on resource testing [10] [11] [12]. The goal of re-source testing is to determine if a number of identities possess fewer resources than would be expected if they were independent. The resources being tested can be computing ability, storage ability, and network band-width, as well as IP addresses. These schemes assume that entities have homogeneous hardware configurations. In vehicular networks, this assumption cannot hold since

AUTHOR: TITLE 3

malicious vehicles can easily have more powerful re-sources than the normal vehicles.

SybilGuard [13] is an interesting scheme studying the social network among entities. In this scheme, human-established real-world trust relationship among users is used for detecting Sybil attacks. Since even the attacker can generate as many as Sybil identities, building rela-tionship between honest users and Sybil identities is much harder. Thus there exists a small ―cut‖ on the graph of trust relationship between the forged identities and the real ones. However, this scheme cannot be used in vehi-cular networks, since it is very challenging to establish such trust relationship among vehicles. This is because vehicles are highly mobile. Communications often hap-pen among temporarily-met and unfamiliar vehicles.

To exploit the fact that one single vehicle cannot present at multiple locations at the same time, Bouassida et al [14] have proposed a detection mechanism utilizing localization technique based on Received Signal Strength Indication (RSSI). In this scheme, by successively measur-ing the RSSI variations, the relative locations among ve-hicles in vicinity can be estimated. Identities with the same estimated locations are considered as Sybil vehicles. In practice, the complicated outdoor environments can dramatically affect the wireless signal propagation so that RSSI measurements are highly time-variant even meas-ured at the same location. Xiao et al [15] have proposed a Sybil attack detection scheme where the location of a par-ticular vehicle can be determined by the RSSI measure-ments taken at other participating vehicles. In addition to the inaccuracy of RSSI measurements, this scheme also needs all neighboring vehicles to collaborate which may suffer a Sybil attack against the detection scheme itself. Zhou et al [16] have proposed a privacy-preserving Sybil attack detection scheme using pseudonyms. In the scheme, the trust authority distributes a number of pseu-donyms for each vehicle. Abused pseudonyms can be detected by RSUs. Since RSUs are heavily involved in the detection process, this scheme requires the full coverage of RSUs in the field. It is infeasible in practice due to the prohibitive cost. Furthermore, in such a scheme vehicles should managed by a centralized trusted center. Each time RSU detects suspicious pseudonyms, it should send all the pseudonyms to the trust center for further deci-sion, which makes the trust center be the bottleneck of the

detection. Recently, two group-signature-based schemes [17] [18]

have been proposed, ensuring that a verifier vehicle can identify trustworthy messages from messages sent from neighboring vehicles. A trustworthy message refers to a message that is sent by at least a certain number of dis-tinct vehicles. To suppress duplicated messages from the same vehicle, particular group signature schemes are adopted for vehicles to sign on messages so that the ano-nymity of each vehicle can be achieved. Meanwhile, if a vehicle generates two signatures on the same message, these two signatures can be recognized by the verifier vehicle. One practical issue of these schemes is that they cannot handle similar but different messages. It is often the case that multiple vehicles observing the same driving environment will generate different messages with very similar semantics. In this case, the resolved trustworthy messages might be a minority of all observations which results in a biased or no final decision.

The most relevant work to Footprint is the Sybil attack detection schemes proposed in [19] [20]. In these schemes, a number of location information reports about a vehicle are required for identification. In [19], an RSU periodical-ly broadcasts an authorized timestamp to vehicles in its vicinity as the proof of appearance at this location. Ve-hicles collect these authorized timestamps which can be used for future identity verification. In [20], trajectories made up of consecutive timestamps and the correspond-ing public keys of RSUs are used for identification. How-ever, these schemes did not take location privacy into consideration since RSUs use long-term identities to gen-erate signatures. Therefore, the location information of a vehicle can be inferred from the RSU signatures it collects.

3 MODELS AND DESIGN GOALS

3.1 System Model

In vehicular networks, a moving vehicle can talk with other neighboring vehicles or RSUs via inter-vehicle communications and roadside-to-vehicle communica-tions. Fig. 1 illustrates the architecture of the system mod-el, which consists of three interactive components:

RSUs: can be deployed at intersections or any area of interest (e.g., bus stations and parking lot en-trances). They are interconnected by a dedicated backbone network or through the Internet via cheap ADSL connections. A typical RSU also functions as a wireless AP (e.g., IEEE 802.11x) which provides wireless access to users within its coverage. In Foot-print, we assume that a small fraction of RSUs might be compromised by an attacker.

On-Board Units (OBUs): are installed on vehicles. A typical OBU can equip with a cheap GPS receiver and a short-range wireless communication module (e.g., DSRC [21]). A vehicle equipped with an OBU can communicate with an RSU or with other ve-hicles in vicinity via wireless connections. For sim-plicity, we simply refer to a vehicle as a vehicle equipped with an OBU in the rest of this paper. A vehicle can be malicious if it is an attacker or com-

Fig. 1. An illustration of the system model, where the dash line indi-cates the travel route of a vehicle. As the vehicle traverses the area, it will encounter multiple RSUs, typically deployed at intersections.

RSU

OBU

TA

4 IEEE TRANSACTIONS ON XXXXXXXXXXXXXXXXXXXX, VOL. #, NO. #, MMMMMMMM 1996

promised by an attacker.

Trust Authority (TA): is responsible for the system initialization and RSU management. Note that the TA does not serve vehicles for any certification pur-pose in Footprint. A vehicle can claim as many arbi-trary identities as it needs. We assume that TA is fully trustworthy.

In Footprint, we assume that the mobility of vehicles is independent. This means individual vehicles should move on their own purposes and therefore would not travel together for a long period of time. This assumption is reasonable because most of vehicles have different des-tinations. Even though two vehicles share the same desti-nation, they may choose two distinct paths based on their own driving experiences.

3.2 Attack Model

In order to launch a Sybil attack, a malicious vehicle must try to present multiple distinct identities. This can be achieved by either generating legal identities or by imper-sonating other normal vehicles. With the following capa-bilities, an attacker may succeed to launch a Sybil attack in vehicular networks:

Heterogeneous configuration: malicious vehicles can have more communication and computation re-sources than other vehicles. For example, a mali-cious vehicle can mount multiple wireless cards, physically representing different communication entities. Furthermore, having more powerful re-sources can also fail those resource testing schemes for detecting Sybil attacks.

Message manipulation: due to the nature of open wireless channels, the attacker can eavesdrop on nearby communications of other parties. Thus, it is possible that the attacker gets and interpolates criti-cal information needed to impersonate others.

3.3 Design Goals

The design of a Sybil attack detection scheme in private vehicular networks should achieve three goals:

1) Location privacy preservation: a particular vehicle would not like to expose its location information to other vehicles and RSUs as well since such information can be confidential. The detection scheme should prevent the location information of vehicles from being leaked.

2) Online detection: when a Sybil attack is launched, the detection scheme should react before the attack has terminated. Otherwise, the attacker could already achieve its purpose.

3) Independent detection: the essence of Sybil attack happening is that the decision is made based on group negotiations. To eliminate the possibility that a Sybil at-tack is launched again the detection itself, the detection should be conducted independently by the verifier with-out collaboration with others.

4 SYSTEM DESIGN

In this section, we describe the design of Footprint. We first briefly introduce the main idea of the design. Then

we elaborate the three technical components integrated in Footprint.

4.1 Overview

In general, Footprint integrates three elegant techniques namely, infrastructure deployment, location-hidden trajectory generation and trajectory verification. Specifically, we adopt an incremental methodology to deploy RSUs. In the end, a limited number of available RSUs can achieve the max-imum service coverage in terms of served traffic amount as well as good fairness in terms of geographical distribu-tion. Given the deployment of RSUs, we adopt an event-oriented linkable ring signature scheme [25] for RSUs to sign messages. Such authorized messages are location-hidden which refers to that RSU signatures are signer-ambiguous and the authorized messages are temporarily linkable. Furthermore, consecutive authorized messages are tightly chained together to form a location-hidden trajectory. After getting a set of trajectories sent from neighboring vehicles, a verifying vehicle establishes the relationship between each pair of trajectories according to our defini-tion of similarity. Among all trajectories, Sybil trajectories forged from the same attacker are bound to gather and fall into the same ―community‖. By treating each ―com-munity‖ as one single vehicle, Sybil trajectories can be largely eliminated.

In the following subsections, we present the challenges encountered in the design of each technique and the cor-responding solutions.

4.2 Infrastructure Deployment

In Footprint, vehicles require authorized messages issued from RSUs to form trajectories, which should be statically installed as the infrastructure. When considering the dep-loyment of RSUs, two practical questions are essential, i.e., where to install RSUs in the city and how many of them are sufficient?

A simple solution is to deploy RSUs at all intersections. This can result fine trajectories with a sufficient number of authorized messages which will facilitate the recogni-tion of a vehicle. However, deploying such a huge num-ber of RSUs in one time is prohibitive due to the high cost. An alternative solution is to consider the underlying road networks as a graph where intersections and roads are treated as vertices and edges, respectively and deploy RSUs on these intersections which correspondingly forms the minimum vertex cover on the graph. The appealing feature of this deployment scheme is that a vehicle can be guaranteed to get an authorized message when travelling between any two intersections at about the half cost of deploying RSUs at all intersections. The problem with the minimum-vertex-cover-deployment scheme is that the final deployment of RSUs is likely to be geographically uneven, due to the particular topology of underlying road networks, providing poor coverage of traffic. For exam-ple, there are more densely distributed intersections in certain areas than other areas in the city. In this case, more RSUs than necessary are wasted in those are with high density of intersections.

We take an incremental deployment strategy in Foot-

AUTHOR: TITLE 5

print, considering the tradeoff between minimizing the number of RSUs and maximizing the coverage of traffic. Specifically, in the early developing stage with limited number of RSUs available, an intersection is chosen if it satisfies two requirements: first, it is geographically at least certain distance far away from all other RSU-equipped in-tersections; second, it has the maximum traffic volume in terms of the number of traversing vehicles within a time unit among all rest intersections without RSUs. The reason for requiring two RSUs at least certain distance far away is to avoid uneven deployment where RSUs are consecutive-ly deployed along a high-traffic-volume road. As more RSUs are available to install, a smaller distance can be used to deploy RSUs according to the above strategy.

Given an RSU deployment, two RSUs are said to be neighbors if there exists a path in the underlying road net-works along which no other RSUs are installed. Fig. 2 illu-strates an example of RSU deployment layout based on the digital map of Yangpu District in Shanghai. In this area, there are 659 intersections and 1,004 road segments in total. Three hundred RSUs are installed at a distance of 250 me-ters. It can be seen from the figure that there are some areas where RSUs have much more neighbors than others. This is due to the dense distribution of road segments in these areas. Since RSUs are not installed on all the intersections in these areas, it is easy to find a path connecting two RSUs.

4.3 Generating Location-hidden Trajectory

4.3.1 Location-hidden Authorized Message Generation

In order to be location-hidden, authorized messages should possess two properties, i.e., anonymous and tem-porarily linkable. The anonymous property means an RSU should not use a dedicated identity to sign messages. The temporarily linkable property requires two autho-rized messages are recognizable if and only if they are generated by the same RSU within the same given period of time. Otherwise, a long-term linkability of authorized messages used for identification eventually has the same effect as using a dedicated identity for vehicles.

To implement the temporarily linkable property, there are two methods. One is to insert a certain link tag into each message. Link tags can be recognized if and only if they are generated by the same RSU within the same pe-

riod of time. The other one is to insert such link tags into signer-ambiguous signatures of RSUs. The advantage of this scheme is that, since a link tag is embedded in a sig-nature of an RSU and related to the private key of the RSU, a compromised RSU cannot forge link tags generat-ed by other RSUs. Moreover, an RSU cannot repudiate a link tag generated by itself. In addition, there is no coor-dination needed to avoid the collisions for choosing dif-ferent link tags as in the first method.

In this paper, we demonstrate the feasibility of the second method by implementing a location-hidden au-thorized message generation scheme using linkable ring signature [22]. Note that other implementations are poss-ible. Linkable ring signature is signer-ambiguous and signatures are linkable (i.e., two signatures can be linked if and only if they are issued by the same signer) as well. Particularly, we choose the linkable ring signature scheme introduced by Y. Dodis et al [23] and Patrick P. Tsang et al [24] for two reasons: first, it has been proved to be secure; second, it has constant signature size. To meet the requirement of temporarily linkable property, we extend the scheme to support the event-orient linkabili-ty property [25] which guarantees that any two signatures are linkable if and only if they are signed based on the same event by the same RSU. The detailed signature gen-eration and verification algorithms can be found in the Appendix.

Specifically, when a new RSU is installed in the sys-tem, the TA initializes the new RSU by registering this RSU in the RSU group. The new RSU is assigned its own pair of public/private keys. Then, the up-to-date list of public keys of all RSUs is broadcasted to all vehicles and RSUs in the system (See Appendix B for the detailed in-itialization process). After the initialization, the new RSU is ready to serve.

An intuitive way to generate authorized messages for vehicles is that an RSU periodically broadcasts authorized timestamps to the vehicles in its vicinity. This method is simple but not secure. Since a timestamp is not specially generated for a particular vehicle, any other vehicle get-ting such a timestamp by eavesdropping on the wireless channels can claim its presence at this RSU even though it has never been there at that time. Therefore, timestamps should be generated for individual vehicles. In Footprint, when a vehicle vi approaches an RSU Rk, it demands a timestamp from the Rk, using a jth temporarily generated

key pair (

). Upon request, the RSU Rk generates

a message for vi, which includes the public key of vi,

, and a timestamp indicating the time when this mes-

sage is generated. Then Rk signs on the message and send together with the signature, denoted as

, back to vi. In future verification, vi will sign on

using

and send

to a verifier. In this way, an authorized message cannot be misused by other vehicles since during the verification,

Fig. 2. An illustration of RSU deployment in Yangpu District, Shanghai. The dots denote RSUs and the dash lines denote the defined neigh-boring relations between RSUs.

6 IEEE TRANSACTIONS ON XXXXXXXXXXXXXXXXXXXX, VOL. #, NO. #, MMMMMMMM 1996

In our signature scheme, we define an event as a period of time within which two signatures issued from the same RSU are linkable. Thus, an RSU signature consists of three parts: proof of knowledge (pok), event-id and link-tag. The pok is a proof that the signature on the message is legiti-mate. The event-id is a fixed-size bit string derived by a secure cryptographic hash function on an event (i.e., a period of time). The link-tag is generated based on the event-id and the private key of an RSU. When an event has expired, an RSU computes a new event-id and link-tag for the next period of time. We assume that RSUs are syn-chronized and can simultaneous update their link-tags. This is easy to achieve since RSUs are interconnected. With time variant link-tags, the RSU signatures can meet the temporarily linkable requirement.

4.3.2 Location-hidden Authorized Message Generation

With authorized messages, a straightforward method for a vehicle to present its trajectory is to sort the authorized messages into a sequence according to the time when these messages are generated. This method is simple but inefficient because each time when vi needs to be identi-fied, all the separate messages in the sequence should be sent for verification. This will cost tremendous wireless bandwidth and computational resources. Furthermore, a malicious vehicle can easily forge a huge number of fake trajectories by arbitrarily picking a subset of authorized messages as long as these messages are in increasing or-der of time. Since authorized messages are location-hidden, a verifying vehicle cannot tell whether a pro-vided trajectory is an actual one or a forged one. Consi-dering the powerful capability of RSUs in contrast to mo-bile devices, it is more feasible to put the signature verifi-cation workload on the RSU side.

In Footprint, we integrate the message issuance and the construction of trajectory as one incorporated process. Specifically, every time when an event expires, besides computing the new link-tag for the next event, an RSU also informs all its neighboring RSUs with this new link-tag. When a vehicle first meets an RSU since the starting of an event, it requests a message from the RSU with a temporarily generated public key. The RSU issues an au-thorized message to this vehicle following the procedure as described in the above subsection. As this vehicle en-counters the second RSU, it first signs on a new tempo-rary public key and the latest authorized message re-ceived from the last RSU, using the private key which matches the corresponding public key included in the message. Then it sends the new temporary public key, the latest authorized message and the signature to the RSU. The RSU first verifies whether the vehicle is legitimate to possess the provided message using the previous public key of the vehicle contained in the message. If yes, the RSU further check whether the link-tag contained in the signature belongs to one of its neighbors. If yes, the RSU contributes to the construction of trajectory by signing with its own link-tag on a new message. In this new mes-sage, besides the new temporary public key of the vehicle and a timestamp, the previous link-tag and timestamp are also preserved. Otherwise, the RSU treats itself as the first

RSU of this vehicle since the starting of this event and sign accordingly. This procedure repeats at all RSUs this vehicle encounters within the same event. As a result, a trajectory is embedded within a single authorized mes-sage.

Within an event, a vehicle can terminate the current trajectory, starting a new trajectory at any RSU by send-ing only a new temporary public key to an RSU. When an event expires, all RSUs will simultaneously change their link tags. In this case, the system forces all vehicles to start new trajectories.

We demonstrate an example of trajectory generation as shown in Fig. 3. Suppose a vehicle v1 travels along the path within an event e1. While encountering the first RSU R1, it demands a message from R1 as the proof of its pres-ence. In order to do this, v1 generates a new pair of public

and private keys (

). It then sends a request for

an authorized message with

to R1. Upon request, R1

sends

and

,

denoted as , back to v1, where t1 is the cur-

rent time, is the proof of the signature, is the

event-id derived from e1, and is the link-tag gen-

erated based on and the private key of R1. As v1 meets

R2, it generates another new pair of public and private

keys (

). To build its trajectory, v1 sends

to R2. R2

uses

contained in to verify whether

is signed by v1 using

. If R2 succeeds,

R2 further checks whether is a link-tag belonging

to one of its neighbors. If yes, R2 generates a new message

, signs on ,

and sends back to v1.

With , v1 is authenticated by R2 that {R1, R2}

is the current trajectory of v1. The authorized message generation process at R3 is similar. Vehicle v1 sends

to

R3 and gets in return. In the end, v1 gets an

RSU-authorized trajectory {R1, R2, R3} encoded in a single authorized message.

With trajectory-encoded messages, each time when a

Fig. 3. Integration of authorized message issuance and trajectory generation, where a vehicle moves meeting RSUs R1, R2 and R3 in turn.

(1)

(3) (4)

pub

vK 1,1)(|| 11 1

MSM R2RL(2)

)(|| 22 2MSM R1RL

)(|| 33 3MSM R

(5) (6)

1v

1R

2R

3R

},{ 1,11 1

pub

vKtM

},,{)(1111 ,1 RheR e

taghpokMS

),),((||||||)( 2,112,11 111,1

111

pub

vRK

pub

vRR KMMSSKMMSL priv

}},{,,{111 ,12,22 Rh

pub

v etagtKtM

},,{)(2112 ,2 RheR e

taghpokMS

),),((||||||)( 3,223,22 122,1

122

pub

vRK

pub

vRR KMMSSKMMSL priv

}},{},,{,,{21111 ,2,13,33 RhRh

pub

v eetagttagtKtM

},,{)(3113 ,3 RheR e

taghpokMS

AUTHOR: TITLE 7

vehicle needs to be identified using a trajectory, the ve-hicle only needs to send a single authorized message to a verifier which extremely reduces the number of verifica-tion from to , l is the length of the trajectory (i.e., the number of involved RSUs). Moreover, the trajectory encoded in an authorized message is verified and con-structed by neighboring RSUs, which largely limits the ability of a malicious vehicle to arbitrarily forge fake tra-jectories.

4.4 Trajectory Verification

4.4.1 Problem Definition

With the independent mobility assumption made in Sec-tion 3, as two vehicles moves along, the probability for the pair of vehicles having exactly the same trajectories is slim. Therefore, it is feasible to use trajectories to exclu-sively represent their corresponding vehicles as long as those trajectories are sufficiently long. How to utilize tra-jectories for identification, however, is not trivial due to three factors.

First, authorized messages generated for different ve-hicles are asynchronous. The rationale of using trajecto-ries to represent vehicles is based on the fact that a vehicle cannot present itself at different locations at the same time. However, authorized messages are generated upon individual requests at different time which makes the judgment directly based on this fact impractical.

Second, authorized messages are location-hidden, which means there is no connection between knowing an RSU signature and knowing the geographical location of the RSU who signed this signature. Thus, there is no dis-tance information available between two RSUs enclosed in any two signatures. This makes the problem even harder since one cannot utilize the time difference be-tween two authorized messages and the distance between the pair of corresponding RSUs to infer whether two tra-jectories belong to two distinct vehicles.

Last, a malicious vehicle can leverage the freedom of trajectory generation and the neighboring relationship among RSUs to generate elaborate trajectories. As a ve-

hicle can use new generated public key to request an au-thorized message, it can generate multiple trajectories as it needs. For example in Fig. 4, an attacker can legally generate multiple trajectories which appear different from each other even with a very simple RSU topology. As-sume the attacker actually see R1, R2, R3 and R4 in turn (indicated by solid arrows). It can start a new trajectory at each RSU by using a different temporary public key. Therefore, besides the trajectory {R1, R2, R3, R4}, trajecto-ries like {R1, R2, R3}, {R2, R3, R4}, {R1, R2}, {R2, R3}, {R3, R4}, {R1}, {R2}, {R3} and {R4} are all legitimate. In addition, knowing the neighboring relationship of R2 and R4, the attacker can generate forged trajectories like {R1, R2, R4} and {R2, R4} as though it meets R4 right after seeing R2 (indicated by the dash arrow). Another example is {R1, R4}. Note that the attacker cannot generate a trajectory like {R1, R3} because our authorized trajectory-encoded message scheme forbids an RSU serving an authorized message issued by non-neighboring RSUs. In the case of this example, R3 only expects signatures signed by R2 and R4.

Since a malicious vehicle can try to launch a Sybil at-tack by creating multiple trajectories, we define the trajec-tory verification problem as: Given a set of trajectories with-in an event, how many real vehicles can they represent?

We thoroughly examine the characteristics of forged trajectories and the behavior difference between normal vehicles and malicious ones. In the following subsection, we first present the social relationship among forged tra-jectories according to our definition of similarity and then introduce how to find Sybil communities.

4.4.2 Social Relationship among Trajectories

Features of forged trajectories: Although a malicious vehicle can submit multiple forged trajectories to a verify-ing vehicle, these trajectories comply with two facts. First, a forged trajectory is a proper subset of the actual trajec-tory. For example, in Fig. 4, the three forged trajectories are contained in the actual trajectory. Second, any two forged trajectories cannot have two distinct RSUs at the same time. Either they contain a common RSU at the same time or certain RSUs contained in one forged trajec-tory is absent in the other. It is true because otherwise the malicious vehicle would appear at two locations at the same time. For example, both the first and the third forged trajectories have R1 and R2. The difference between these two trajectories is R4 contained in the third forged trajectory but it is absent in the first one.

Features of actual trajectories: Because actual trajecto-ries are provided by different honest vehicles, there are two main features that can be exploited for trajectory ve-rification. First, despite the asynchronism of authorized message generation and location-hidden property of au-thorized messages, it is possible to distinguish two actual trajectories by using a sliding time window (called check window). Given an RSU deployment, the size of the check window can be established as the shortest time for a ve-hicle to travel between any pair of RSUs. If there are two distinct RSUs found in two trajectories within this check window, it is safe to say that these two trajectories belong

Fig. 4. RSU neighboring relationship and the freedom of trajectory generation can facilitate Sybil trajectory generation. In the above figure, neighboring RSUs (denoted by dots) are connected with dash line. The solid arrows indicate the actual sequence of RSUs a malicious meet and the dash arrow presents a possible forged trajectory.

R2

R1

R3

R4

Actualt

R1 R2 R3 R4

Forged 1t

R1 R2

Forged 2t

R3 R4

Forged 3t

R1 R2 R4

8 IEEE TRANSACTIONS ON XXXXXXXXXXXXXXXXXXXX, VOL. #, NO. #, MMMMMMMM 1996

to two different vehicles. Second, within a certain period of time, two distinct trajectories can be identified if the sum of the length of each trajectory is larger than a limit (called trajectory length limit). In particular, consecutive identical RSUs in a trajectory are counted as one single RSU. Given an RSU deployment, this limit can be deter-mined as the maximum number of different RSUs in-volved in a trajectory within an event (a trajectory is forced to terminate at the end of an event). This is true because if the two trajectories come from a single vehicle, it is very hard, if not impossible, for this vehicle to obtain more authorized messages than the trajectory length limit within an event.

Based on these features, we first conduct an exclusion test, verifying whether two trajectories can be confirmed that they come from two distinct vehicles. There are two cases that this pair of trajectories can pass the test (positive test). In the first case, during the move of the check win-dow, there are two distinct RSUs appearing in the check window. In the second case, the sum of the length of the pair of trajectories is larger than the trajectory length limit if the check window fails to find identical RSUs. In all other cases, the pair of trajectories fails in the test (negative test). For trajectories which are negative to the test, they are treated as suspicious or supplied with insufficient information. For example, in Fig. 5, the box of dash line denotes the check window and the trajectory length limit is assumed to be five. Trajectories and are distinct since there exists a pair of different RSUs within the check window, i.e., R2 and R3. Though no different pair of RSUs within the check window can be found between trajecto-ries and , they are distinct because the total number of different RSUs contained in this pair of trajectories is six which is larger than the trajectory length limit. Notice that and cannot prove that they are mutually exclu-sive.

According to the result to the exclusion test, we refine the relationship between a pair of trajectories by introduc-ing the definition of similarity of a trajectory pair and ,

where minus one represents that and are distinct, denotes the set of common RSUs found within the check window and represents the size of a set or the length of a trajectory. For example, the similarity of and in Fig. 5 is minus one and that of and is 0.5. We use the above definition of similarity based on two

following considerations. First, any two forged trajecto-ries issued from the same malicious vehicle will have a non-negative similarity value. That is to say that all forged trajectories from a malicious vehicle form a social ―community‖ within which any two members have a re-lation in terms of similarity. Second, a trajectory provided by an honest vehicle may have connections with several other trajectories but the probability for this trajectory to form a large ―community‖ is small. This is because an actual trajectory is supposed to contain a sufficient num-ber of RSUs which increases the probability to exclusively differ from others through the exclusion test.

4.4.2 Eliminating Sybil Communities

With the observation in the above subsection, the trajecto-ry verification problem can be well solved by finding an efficient algorithm to eliminate all possible ―communi-ties‖ of Sybil trajectories. However, the problem of find-ing all Sybil ―communities‖ within a given set of trajecto-ries is very hard. We have the following Theorem.

Theorem. With the definition of relationship between two tra-jectories in terms of similarity, the problem of finding all “communities” of Sybil trajectories within a given set of tra-jectories is NP-complete.

Proof: Assume each trajectory in the set is a vertex in an undirected graph. We define an edge between two vertices if the corresponding trajectories have a non-negative simi-larity value. To find all ―communities‖ in the trajectory set is equal to find all complete subgraphs (called cliques). Finding all cliques in a graph is a well-known NP-complete problem. This completes the proof. ■

In Footprint, we take an iterative procedure to get all Sybil ―communities‖. Specifically, we first generate a cor-responding graph according to the procedure described in the Theorem proof. Then, each time, we pick a maximum clique in the graph and delete all vertices in the clique and all corresponding edges from the graph until there are no more vertices left in the graph. The reason that we pick the maximum clique each time is that, in order to launch a Sy-bil attack, a malicious vehicle expects to achieve multiple identifications, which requires the attacker to issue a suffi-cient number of forged trajectories. This will form a big sized clique in contrast to those cliques made up of honest vehicles. With each picked maximum clique, we choose the trajectory with the longest length as a legal trajectory and discard all other members in the clique. In this way, a mali-cious vehicle is allowed to represent itself once no matter how many forged trajectories it has generated.

To pick a maximum clique from the graph, we adopt a heuristic branch-and-bound algorithm [26]. Each time the vertices are first sorted by a greedy vertex coloring algo-rithm. Then the search starts from the first vertex. The worst-case running time complexity is , where n is the number of vertices in the graph. Considering the vehi-cular application scenario where conversations among ve-hicles are supposed to be short, we restrict the time for searching the maximum clique. When time expires, the currently found clique is returned. If there are multiple maximum cliques found to have the same number of ver-tices, we choose the one with the smallest sum of similarity

Fig. 5 Checking for distinct trajectories by using a check window (denoted as the box of dotted line) and counting the total number of different RSUs contained in a pair of trajectories.

Actual 1

Actual 2

Actual 3

t

R1 R2 R3

R5 R6t

R4

R4t

R2

AUTHOR: TITLE 9

associated with edges. The reason is that a smaller similari-ty means two trajectories are more alike, which are more likely generated by a malicious vehicle.

5 SECURITY AND PRIVACY ANALYSIS

As we described in Section 3, leveraging the open broad-casting nature of wireless signal, a malicious vehicle can easily obtain messages between two other communicating entities by eavesdropping on the wireless channels. In Footprint, the trajectory information and authorized mes-sages are delivered via wireless communication. If a mali-cious vehicle can succeed in using the trajectories of other vehicles, it can masquerade as multiple identities and therefore launch a Sybil attack. The Footprint design is secure in terms of defending

Against the message replay attacks: In Footprint, any attempt to misuse authorized trajectory-encoded messag-es stolen from other vehicles fails. This is because every time a trajectory is required for identification, only the original vehicle to which the RSU authorizes has the tem-porary private key matching the public key embedded in the authorized message. An attacker misusing a stolen trajectory will fail during the signature verification since it does not know the original private key.

Against the integrity attack: In Footprint, the attacker cannot interpolate the content of a trajectory either. This is because the integrity of a trajectory is guaranteed by the signature of neighboring RSUs which are trustworthy.

In Footprint, a malicious vehicle can combine the free-dom of trajectory generation and RSU topology informa-tion to forge a large number of fake trajectories. Then it can try to launch Sybil attacks by supply a verifying ve-hicle with multiple forged trajectories. We will extensive-ly evaluate the performance of Footprint in distinguishing honest vehicles from malicious ones in Section 7.

In addition to security concerns, Footprint can meet the requirement for location privacy preservation of ve-hicles. Specifically, while running on the road, a vehicle can construct a series of trajectories for future identifica-tion. In a conversation where a verifying vehicle needs to verify its neighboring vehicles, the verifying vehicle ran-domly chooses an event and requests each of its neighbor-ing vehicles to provide a trajectory generated in this event. Accordingly, each participating vehicle will pro-vide a trajectory generated in the required event. Because it is very hard, if not impossible, for an attacker to infer the relationship between different trajectories generated in different events, the attacker cannot distinguish ve-hicles by their trajectories. In addition, since a trajectory is composed of location-hidden authorized message, no location information can be inferred on the base of know-ing the link-tags of RSUs contained in the trajectory. Fur-thermore, RSUs change their link-tags on every new event which means remembering a previous link-tag of a RSU does not help an attacker identify this RSU in present event. Therefore, even if an attacker conducts a field testing by recoding the locations of RSUs and their corresponding link tags, it can only log a small number of RSUs for a short period of time.

6 DESIGN ISSUES

This section discusses some design issues that Footprint may encounter in practice.

Scalability in terms of the number of verification: In Footprint, authorized trajectory-encoded messages are used for identification of vehicles. Due to the high mobili-ty of vehicles, the duration of interactions between RSUs and vehicles and between inter-vehicles are very short. This may arouse the scalability concern that how many vehicles a particular RSU or a vehicle is able to interact in a short period of time like seconds. If the generation or verification of signatures is not very efficient, it is possible that a vehicle fails to obtain an authorized message from an RSU before it runs out of the communication range of the RSU. In our signature scheme, to sign a message, RSUs only need to compute the hash value of the message with the pre-computed values. For the trajectory verifica-tion, only one signature should be verified by either a vehicle or an RSU, which contains a computation of 27 modular exponentiations. With a 512-bit security parame-ter, it takes roughly 52.38ms (i.e., 19 vehicles/second) for a 3GHz processor to complete the whole verification. At a busy intersection in metropolises like Shanghai, the traffic amount can reach less than 0.55 vehicle/second [27]. The average contact time for two vehicles in urban settings is about ten seconds [4], which is sufficient long for verify-ing hundreds of signatures. Therefore, our signature scheme is practical in vehicular scenario.

Compromised RSUs: In Footprint, we allow a small fraction of RSUs being compromised. In that case, a com-promised RSU can collude with a malicious vehicle to launch a Sybil attack by generating fake trajectories con-sisting of a set of arbitrary link tags and timestamps pairs for the malicious vehicle. This will deceive our Sybil at-tack detection scheme. In Footprint, we require a RSU to insert link tag into its signature so that any RSU cannot forge link tags generated by other RSUs. In this way, by examining the consistence of all sub-trajectory generated at each RSU on a suspicious trajectory, TA can detect those compromised RSUs who generate arbitrary trajecto-ries on the fly. To realize the detection of compromised RSUs, there are several possible strategies. For example, TA can examine all trajectories within a given period of time. This requires each RSU stores all generated trajecto-ries during this period of time for check, which causes huge storage and communication costs. Another possible solution is that TA can randomly spot check certain trajec-tories generated in the system from time to time or check particular trajectories on request of certain vehicles or RSUs.

Increasing message length: In Footprint, the current trajectory information is required both for an RSU to sign a new message and for other vehicles to verify. As the trajectory continues to grow, the message size is also li-nearly increasing which consumes more communication bandwidth. Furthermore, in vehicular scenario, where the wireless link quality is very dynamic, long messages may suffer failures. In our scheme, a trajectory is composed of consecutive pairs of RSU link-tags and timestamps. The typical length of a message is 68∙n bytes, where n is the

10 IEEE TRANSACTIONS ON XXXXXXXXXXXXXXXXXXXX, VOL. #, NO. #, MMMMMMMM 1996

length of the trajectory contained in the message. In Foot-print, in order to satisfy the temporary linkable property, a short period of time should be chosen as an event. In this case, the n is relatively small (e.g., several tens). This also helps to limit the size of a message.

7 PERFORMANCE EVALUATION

7.1 Methodology

In this section, we examine the performance of Footprint in recognizing forged trajectories (issued by malicious vehicles) and actual ones (provided by honest vehicles) through trace-driven simulations. We consider two key metrics:

1).False positive error: is the proportion of all actual trajectories that are incorrectly identified as forged trajec-tories.

2) False negative error: is the proportion of all forged trajectories that are falsely identified as actual trajectories.

In the following simulations, we use the digital map of Yangpu District in Shanghai where there are 659 intersec-tions and 1,004 road segments. We use the 300-RSU dep-loyment as described in Subsection 4.2 (See Fig. 2). Then we record the actual trajectories of 521 taxies according to the RSU deployment and the GPS reports of these taxies collected on Feb 1, 2007. A trajectory of a vehicle is represented as a sequence of (Intersection ID, timestamp), where Intersection ID is the ID of an intersection in the map and timestamp is the moment when the vehicle ar-rives at this intersection. We define an event as a period of one hour and cut the trajectories into 24 subsets. Both honest vehicles and malicious vehicles are randomly cho-sen from a subset. According to our strategies to measure similarity of two trajectories and to eliminate Sybil ―communities‖, the longer a forged trajectory is the high-er probability the forged trajectory can be regarded as an actual one. Therefore, based on the RSU neighboring rela-tionship as described in Subsection 4.4, forged trajectories are generated as long as possible. For each subset and each simulation configuration, we run the simulation 20 times and get the average.

7.2 Effect of the Check Window Size

In this simulation, we examine the effect of the check window size to the system performance. We randomly choose 60 actual trajectories representing honest vehicles

and 40 actual trajectories representing malicious vehicles. Each malicious vehicle randomly generates ten forged trajectories. The trajectory length limit is set to 20 RSUs. We vary the check window size from two seconds to 50 seconds with an interval of four seconds.

Fig. 6 plots the false positive error and false negative error as functions of the check window size. It can be seen that the false positive error decreases as the size of check window increases whereas the false negative error in-creases. This is because, with a larger check window, two actual trajectories have more opportunities to distinguish each other by having a negative similarity. Due to the same reason, two forged trajectories can also be falsely identified as two distinct trajectories as long as the check window is larger than the time period for a malicious vehicle to traverse any pair of RSUs contained in its actual trajectory.

Notice that if the check window is set no larger than the safe size of ten seconds (i.e., the shortest time to travel between any pair of RSUs in this RSU deployment) marked as ―safe‖ in Fig. 6, the false negative error can reach the minimum level. Nevertheless, if a properly larger check window is adopted, the system can achieve the best performance in terms of minimizing the sum of the false positive error and the false negative error (de-noted as ―best‖ in Fig. 6).

7.3 Effect of the Trajectory Length Limit

In this simulation, we examine the effect of the trajectory length limit. We choose vehicles and generate forged tra-jectories in the same way as described in the above simu-lation. We set the check window equal to 14 seconds (―best‖ check window size) and vary trajectory length limit from two RSUs to 40 RSUs with an interval of four RSUs.

Fig. 7 plots the false positive error and false negative error as functions of the trajectory length limit. It can be seen that the false positive error increases as the trajectory length limit increases whereas the false negative error drops. The reason is obvious that a larger limit will treat two actual trajectories as two suspicious with an insuffi-cient number of authorized messages. Because of the same reason, two forged trajectories can hardly be direct-ly regarded as two actual trajectories during the exclusion testing as the condition is more difficult to reach.

Fig. 6 Check window size vs. false positive error and false negative error

Fig. 7. Trajectory length limit vs. false positive error and false nega-tive error

0 10 20 30 40 500

20%

40%

60%

80%

100%

Check window size (seconds)

Pe

rce

nta

ge

False Positive

False Negative

safe

best

0 10 20 30 400

10%

20%

30%

40%

50%

60%

70%

Trajectory length limit (# of RSUs)

Pe

rce

nta

ge

False Positive

False Negative

safe

best

AUTHOR: TITLE 11

We can also notice from the figure that setting a prop-erly smaller limit can achieve best performance rather than using the safe limit 40 RSUs (the maximum number of RSU signatures a vehicle can obtained). Using the best check window size together with the best trajectory length limit, we can achieve minimum false positive error and minimum false negative error of 3% and 1%, respec-tively.

7.4 Impact of Infrastructure Deployment

In this simulation, we examine the impact of the RSU deployment. We choose vehicles and generate forged tra-jectories in the same way as described in the first simula-tion. We vary the number of RSUs deployed in the area from 100 to 500 with an interval of 100. The check win-dow and the trajectory length limit are set to the corres-ponding safe values in each deployment. The results are shown in Fig. 8.

Since we take safe trajectory length and safe check window size for each RSU deployment, the false negative error is small for all RSU deployments whereas the false positive error is relatively large. This indicates that Foot-print can guarantee only a very small number of forged trajectories (less than 2%) can succeed at the cost of sacri-ficing a relatively number of honest vehicles (about 10% when the RSU deployment is dense).

From Fig. 8, we find that, in the early developing stage, deploying more RSUs can rapidly improve the system performance. As the distribution of RSUs is dense enough, putting more RSUs in the system will help but not that much. In this simulation setting, install RSUs at half intersections is most cost efficient.

8 CONCLUSION AND FUTURE WORK

In this paper, we have developed a Sybil attack detection scheme Footprint for private vehicular networks. Consec-utive authorized messages obtained by an anonymous vehicle from RSUs form a trajectory to identify the cor-responding vehicle. Location privacy of vehicles is pre-served by realizing a location-hidden signature scheme where the connecting between signatures of an RSU and the location information of this RSU is removed. Utilizing social relationship among trajectories, Footprint can find and eliminate Sybil trajectories. It is demonstrated by both analysis and extensive trace-driven simulations that

Footprint is secure and can achieve the requirement for location privacy preservation. The Footprint design can be incrementally implemented in a large city.

With the proposed detection mechanism having much space to extend, we will continue to work on several di-rections. First, in Footprint, we assume the majority of RSUs are trustworthy. When an RSU is compromised by a malicious vehicle, it can help the malicious vehicle to forge fake trajectories (e.g., insert link-tags of other RSUs into a forged trajectory). In consequence, the malicious vehicle can generate more powerful trajectories to launch a Sybil attack. We will develop cost-efficient techniques to fast detect the corruption of an RSU. Second, we will delve into designing better linkable signer-ambiguous signature schemes such that the computation overhead for signature verification and the communication over-head can be reduced as much as possible. Last, we will validate our design and study its performance under real complex environments based on our on-going realistic prototype test-bed built at Xi’an Jiao Tong University. Improvements will be made based on the realistic studies before it comes to be deployed in large-scale systems.

APPENDIX

A Notations and Preliminaries

We present some preliminaries basic to our signature scheme.

x : denotes choosing an element uniformly at ran-

dom from P. Safe-prime product: N is a safe-prime product if

for some primes such that and are of the same length. : denotes the group of quadratic residues mod-

ulo a safe prime product N. SPK: An Honest-Verifier Zero-knowledge (HVZK)

Proof can be turned into a signature scheme [28]. Such a scheme has been proven to be secure. This kind of signa-ture schemes is named ―Signatures based on Proofs of Knowledge‖, SPK for short.

Accumulator with one-way domain: An accumulator family is a pair where is a family of functions that is defined as for some

. For all ,

A collision resistant accumulator satisfies that it is hardly

to find two different value sets accumulated to the same value.

A quadruple such that is collision resistant and each is a relation over with properties: efficient verification, efficient sampling and one-wayness [23], is called Accu-mulator with one-way domain.

B System Initialization

System initialization procedure includes two parts: setup on TA and RSU registration.

Fig. 8 RSU deployment vs. false positive error and false negative error

100 200 300 400 5000

10%

20%

30%

40%

50%

Number of RSUs

Pe

rce

nta

ge

False Positive

False Negative

12 IEEE TRANSACTIONS ON XXXXXXXXXXXXXXXXXXXX, VOL. #, NO. #, MMMMMMMM 1996

1) Setup on TA

TA should instantiate the accumulator, prepare the keys assigning to RSUs and choose several common parame-ters in the system.

Accumulator Instantiation: an accumulator can ―accu-mulate‖ the public keys of RSUs into a short value, with each public key involved holding a witness that can be used to prove that it has indeed been accumulated. For a security parameter TA instantiates an accumulator with one-way domain ( , , , ) which is a fundamental building block of the signature scheme. consists of the exponentiation functions mod-ulo -bit safe-prime products such that each de-fined as:

QR N Z QR N

，

The accumulator domain , the pre-image do-main and the one-way relation are respec-tively defined as:

(1)

(2) (3)

where is the integer range that is

embedded within with and .

Several security parameters in the accumulator should be chosen, including , where is a -bit safe prime product, is a -bit prime, QR N , , is chosen according to methods in [29] to ensure security against coalition attacks and satisfying .

Additionally, TA has a polynomial-time KeyGen() func-tion for sampling pairs , which will distri-bute to RSUs as their public/private key pairs.

Security Functions: TA also chooses two secure crypto-graphic hash functions which satisfy strong collision re-sistant and , where means is a generator of . is used to generate the event-id of the signature.

Public Parameters: finally, the TA chooses five public parameters, .

After initialization, TA has a set of system parameters Para: .

2) RSU registration

To enroll in the system, an RSU should register to the TA. The TA runs KeyGen() to generate public/privacy key pair

for . The TA also keeps the information

of each RSU. After all RSUs have registered, the TA pub-lishes the Public Key List (PKL) of RSUs using TA’s pri-vate key SKTA. Suppose there are n RSUs in the system, the PKL is,

RSUs can obtain the PKL from the TA via wired com-munication. Upon a new RSU leaving and joining in the system, TA updates the PKL, and notifies other RSUs. Each vehicle can get the PKL from any RSU in the system

once the vehicle joins in the system.

C Signature Generation

An event is characterized by the beginning and the dura-tion of such a period of time. Since all the signatures within have the same event-id, any two signatures gen-erated by the same RSU in the same should have the same link tag.

For the k-th , the event-id can be computed by

. The link tag of in

can be denoted as

.

Given a message ,

being the pub-lic/private key pair of , the generation process of signa-ture by is as follows: 1. Generate current timestamp

2. Compute ,

3. Compute ,

4. Then choose

5. Compute the public values from T1 to T6

6.

Note that the free variables are , where

. The range of can be effective-

ly computed. For simplicity, they can be denoted as

and , respectively.

7. Then randomly select

8. Compute , ,

,

,

,

,

and

.

9. Compute challenger

10. Compute

,

,

, and

11. Combine the above values to form the signature

, where

.

D Signature Verification

Given a message with the ture

signed

on , knows the values of link tags of its neighbors.

Hence, it can compare , with the value of link tags

of its neighbors to decide if the is signed by one of its neighbors.

Then checks whether is an authorized signature:

1. Check if

，

and .

AUTHOR: TITLE 13

2. Compute

,

,

,

,

,

,

.

3. Compute .If , is

an authorized signature.

REFERENCES

[1] Y. Sun, R. Lu, X. Lin, X. Shen, and J. Su, "An Efficient Pseudo-

nymous Authentication Scheme with Strong Privacy Preserva-

tion for Vehicular Communications", IEEE Transactions on Ve-

hicular Technology, vol. 59, issue 7, pp. 3589-3603, 2010.

[2] R. Lu, X. Lin, H. Zhu, and X. Shen, "An Intelligent Secure and

Privacy-Preserving Parking Scheme through Vehicular Com-

munications", IEEE Transactions on Vehicular Technology, vol.

59, no. 6, pp. 2772-2785, 2010.

[3] J. R. Douceur, ―The sybil attack,‖ in proceeding of IPTPS 2002,

Cambrideg, MA, USA, Mar. 2002, pp. 251-260.

[4] J. Eriksson, H. Balakrishnan, and S. Madden, ―Cabernet: vehi-

cular content delivery using WiFi,‖ in proceeding of MOBI-

COM 2008, San Francisco, USA, Sep. 2008, pp. 199-210.

[5] M. Narasimha, G. Tsudik, and J. H. Yi. ―On the utility of distri-

buted cryptography in p2p and manets: the case of membership

control,‖ in proceeding of ICNP 2003, Atlanta, USA, Nov. 2003,

pp. 336 – 345

[6] M. Castro, P. Druschel, A. Ganesh, A. Rowstron, and D.

S.Wallach. ―Secure routing for structured peer-to-peer overlay

networks,‖ in proceeding of OSDI 2002, Boston, USA, Dec.

2002, pp. 299–314.

[7] B. Dutertre, S. Cheung, and J. Levy. ―Lightweight key man-

agement in wireless sensor networks by leveraging initial

trust,‖ Technical Report SRI-SDL-04-02, SRI International, Apr.

2002.

[8] J. Newsome, E. Shi, D. Song, and A. Perrig, ―The Sybil attack in

sensor networks: analysis & defenses,‖ in proceeding of IPSN

2004, Berkeley, USA, Apr.2004, pp. 259–268.

[9] S. Capkun, L. Buttya n, and J. Hubaux, ―Self-organized public-

key management for mobile ad hoc networks,‖ IEEE Transac-

tions on Mobile Computing, vol. 2, no. 1, pp. 52-64, 2003.

[10] C. Piro, C. Shields, and B. N. Levine, ―Detecting the sybil attack

in mobile ad hoc networks,‖ in proceeding of Securecomm

2006, Baltimore, USA, Aug. 2006, pp. 1-11.

[11] N. Borisov, ―Computational puzzles as sybil defenses,‖ in pro-

ceeding of P2P 2006, Cambridge, UK, Oct. 2006, pp.171-176.

[12] P. Maniatis, D. S. H. Rosenthal, M. Roussopoulos, M. Baker, T.

Giuli, and Y. Muliadi, ―Preserving peer replicas by rate-limited

sampled voting,‖ in proceeding of SOSP 2003, New York, USA,

Oct. 2003, pp 44–59.

[13] H. Yu, M. Kaminsky, P. B. Gibbons, and A. Flaxman, ―Sybil-

guard: defending against sybil attacks via social networks,‖ in

proceeding of. SIGCOMM 2006, Pisa, Italy, Sep. 2006, pp. 267-

278.

[14] M. S. Bouassida, G. Guette, M. Shawky, and B. Ducourthial,

"Sybil nodes detection based on received signal strength varia-

tions within vanet,‖ International Journal of Network Security,

vol. 9, no.1, pp. 22-32, 2009.

[15] B. Xiao, B. Yu, and C. Gao, ―Detection and localization of sybil

nodes in vanets,‖ in Proceeding of DIWANS 2006, Los Angeles,

USA, Sep. 2006, pp. 1-8.

[16] T. Zhou, R. R. Choudhury, P. Ning, and K. Chakrabarty, ―Pri-

vacy-preserving detection of sybil attacks in vehicular ad hoc

networks,‖ in proceeding of MobiQuitous 2007, Philadelphia,

USA, Aug. 2007, pp. 1-8.

[17] Q. Wu, J. Domingo-Ferrer, and U. Gonz alez-Nicol as, "Ba-

lanced trustworthiness, safety and privacy in vehicle-to-vehicle

communications", IEEE Transactions on Vehicular Technology,

vol. 59, no. 2, pp. 559-573, 2010

[18] L. Chen, S-L. Ng, and G. Wang, " Threshold anonymous an-

nouncement in VANETs", IEEE Journal on Selected Areas in

Communcations, vol. 29, no. 3, pp. 1-11, 2011

[19] C. Chen, X. Wang, W. Han, and B. Zang, ―A robust detection of

the sybil attack in urban vanets,‖ in proceeding of ICDCSW

2009, Montreal, Canada, Jun. 2009, pp. 270-276.

[20] S. Park, B. Aslam, D. Turgut, and C. C. Zou, ―Defense against

sybil attack in vehicular ad hoc network based on roadside unit

support,‖ in proceeding of MILCOM 2009, Boston, USA, Oct.

2009, pp. 1-7

[21] IEEE Vehicular Technology Society: 5.9 GHz Dedicated Short

Range Communications (DSRC) - Overview. [Online]. Availa-

ble: http://grouper.ieee.org.groups/scc32/dsrc/

[22] J. K. Liu, V. K. Wei, and D. S. Wong, ―Linkable spontaneous

anonymous group signature for Ad Hoc Groups (Extended Ab-

stract),‖ in proceeding of ACISP 2004, volume 3108 of LNCS,

pp. 325–335. Springer, 2004.

[23] Y. Dodis, A. Kiayias, A. Nicolosi, and V. Shoup, ―Anonymous

identification in ad hoc groups,‖ in proceeding of EUROCRYPT

2004, vol. 3027 of LNCS, pp. 609–626, Springer, 2004.

[24] P. P. Tsang, and V K. Wei, ―Short linkable ring signatures for e-

voting, e-cash and attestation,‖ in proceeding of ISPEC 2005,

vol. 3439 of LNCS, pp. 48–60, Springer, 2005.

[25] P. P. Tsang, V. K. Wei, T. K. Chan, M. H. Au, J. K. Liu, and D.

S.Wong, ―Separable linkable threshold ring signatures,‖ in pro-

ceeding of INDOCRYPT 2004, vol. 3348 of LNCS, pp. 384–398,

Springer, 2004.

[26] P. R. Östergård, ―A fast algorithm for the maximum clique

problem,‖ Discrete Applied Mathematics, vol. 120(1-3), pp. 197-

207, 2002.

[27] Shanghai City Comprehensive Transportation Planning Insti-

tute, http://www.scctpi.gov.cn/chn/chn.asp, 2006

[28] A. Fiat, and A. Shamir, ―How to prove yourself: practical solu-

tions to identification and signature problems,‖ in proceeding

of CRYPTO 1986, vol. 263 of LNCS, pp. 186–194, Springer, 1987.

[29] J. Camenisch, and A. Lysyanskaya, ―A signature scheme with

efficient protocols,‖ in proceeding of SCN 2003, vol. 2576 of

LNCS, pp. 268-289, Springer, 2003.