Wireless Pers Commun DOI 10.1007/s11277-014-1659-5
On Secure and Privacy-Aware Sybil Attack Detection in Vehicular Communications Rasheed Hussain · Heekuck Oh
© Springer Science+Business Media New York 2014
Abstract The foreseen dream of Vehicular Ad Hoc NETwork (VANET) deployment is obstructed by long-chased security and privacy nightmares. Despite of the increasing demand for perfect privacy, it conflicts with rather more serious security threat called ‘Sybil Attack’ which refers to, impersonation of one physical entity for many, namely Sybil nodes. In such circumstances, data received from malicious Sybil attacker may seem as if it was received from many distinct physical nodes. Sybil nodes may deliberately mislead other neighbors, resulting in catastrophic situations like traffic jams or even deadly accidents. Preventing such attacks in a privacy-enabled environment is not a trivial task. In this paper, we aim at two conflicting goals, i.e. privacy and Sybil attack in VANET. We leverage pseudonymless beaconing in order to preserve privacy. To cope with Sybil attack, we put forth a twofold strategy. In order to avoid Sybil attack through scheduled beacons, we employ tamper resistant module (TRM) to carry out a pre-assembly data analysis on data that is used to assemble beacons whereas for event reporting message (ERM), we employ road side units (RSUs) to localize Sybil nodes in VANET and report them to the revocation authority(s). RSUs distribute authorized tokens among the benign vehicular nodes which in turn are consumed to report ERMs. RSUs collect ERMs for certain event and figures out if more than one ERM for the same event includes identical token or, if an ERM is sent more than once by the same source. Our proposed scheme preserves privacy in both beacons and ERMs, and provides conditional anonymity where in case of a dispute; malicious attackers are subject to revocation. We also show that our proposed scheme outperforms the previously proposed scheme from security and computational complexity standpoint. Keywords messages
VANET · Security · Privacy · Sybil attack · Beaconing · Event reporting
R. Hussain · H. Oh (B) Department of Computer Science and Engineering, Hanyang University, ERICA Campus, Sa 3-dong, Sangnok-gu, Ansan, Gyeonggi 426-791, South Korea e-mail:
[email protected] R. Hussain e-mail:
[email protected]
123
R. Hussain, H. Oh
1 Introduction Until fairly recently, the huge fleet of vehicles we drive or see floating on the road, were the realm of mechanical engineers. But “When Cars Start Gossiping”[3] is gradually becoming a reality since numerous vehicle manufacturers, government agencies, and standardization bodies around the globe have spawned their research resources to Vehicular Ad Hoc NETwork (VANET). However security is one of the crucial obstacles in full VANET deployment. Although VANET security has been given ample attention by the research community [15,18], but the interdependence of security aspects over each other makes it more critical. Strengthening one aspect of security may give room to adversaries to penetrate from the other end. For instance, in terms of ‘authentication and privacy’, we would like to bind each driver to a single identity in order to keep adversaries from playing multiple roles or spoofing with other legitimate identities. Additionally strong authentication would provide valuable forensic evidence and would allow us to use external mechanisms, such as traditional law enforcement, to deter attacks on VANET. But privacy is one of the most essential security requirements in VANET. The drivers value their privacy and are unlikely to adopt systems that require them to abandon their anonymity. For instance, if it is required to prevent the masquerade with identities in a manner that reveals each vehicle’s permanent identity, then we may violate drivers’ privacy expectations. However balancing privacy concerns with security requirements will require codifying legal, societal, and practical considerations. Nevertheless the divergent laws concerning privacy vary from country to country. On the other hand, the absence of privacy is the ideal condition for profile generation [19,21]. Without security and privacy guarantee, serious attacks may jeopardize the benefits by the improved driving safety since an attacker could track the locations of the interested onboard units (OBUs) and obtain their movement patterns. To date, extensive research efforts have been made by both industry and academia to investigate privacy issues in VANET which include temporary identities called pseudonyms [6,14,30]. In the recent past, identityless schemes have also been proposed for privacy enhancement in VANET [11]. These schemes somehow guarantee privacy in VANET and thereby reducing the possibility of profilation. But there are potential downsides of such strong privacy preserving schemes. In such case, the malicious node may forge a large number of fake identities or spoof legitimate ones, in order to create traffic illusions. Then the attacker may distribute wrong or false information about an un-occurred event. To this end, the malicious node makes the benign node to believe that an event has occurred and as if the event was reported by many physical nodes. Such attack is termed as Sybil attack and the virtual non-existent nodes created by malicious node are called Sybil nodes [9,31]. Sybil attacks in VANET are inherited from Wireless Sensor Networks (WSN) and in worst case, almost all kinds of attacks can be launched in the presence of Sybil attack [8]. Since most of the privacy-preserving schemes in VANET are based on pseudonyms and digital certificates, preventing Sybil attacks in such scenarios is a daunting challenge for VANET because the malicious node may use different pseudonyms to report the same event multiple times thereby creating illusions for benign nodes. These illusions may cause dire consequences such as traffic jams or even deadly accidents on freeways. In this paper, we consider a privacy-friendly pseudonymless scheme as baseline for our proposed Sybil attack detection and/or prevention [11]. We put forth a twofold strategy to detect and/or prevent Sybil attack in VANET. For high-frequency scheduled beacons (SB), we use tamper-resistant module (TRM) to perform a pre-assembly analysis on beacons and for event reporting message (ERM), we propose an RSU driven Sybil attack detection scheme. Vehicles receive tokens from nearby border RSU on the fly and consume them to report any event in the area that is
123
On Secure and Privacy-Aware Sybil Attack Detection
the jurisdiction of the domain where issuing border RSU (BRSU) is located. Vehicular node must report any event only once and consume one token per event. Lightweight pre-assembly analysis on beacons beforehand, reduces the threats of Sybil attacks launched by exploiting SB. The structure of the rest of the paper is further organized as follows. Section 2 summarizes state of the art about Sybil attack prevention in VANET. Network model, threat model, and our design objectives are outlined in Sect. 3. We briefly explain the baseline for our proposed scheme in Sect. 4. Section 5 presents our proposed tokenbased approach for detecting and/or preventing Sybil attacks in VANET. By evaluating and analyzing our proposed scheme in Sect. 6 with respect to other schemes, we outline our concluding remarks in Sect. 7.
2 State of the Art regarding Sybil Attacks in VANET To date, most of the schemes addressing Sybil attacks are based on public key infrastructure (PKI), because with public keys; certificates are issued to vehicles by an authenticated trusted authority which guarantees that the attack can be detected all the times in timely manner. Besides the fact that such schemes produce good results in terms of the attack prevention, the complexity and difficulty in implementation of such schemes is still questionable and do not make it a reasonable choice for VANET. Levine et al. [16] performed a thorough survey on Sybil attacks covering different aspects of Sybil attacks. Besides, received signal strength (RSS) can also be exploited to confirm the physical existence of vehicles and thereby checking for possible potential Sybil attack. Guette et al. [9] and Xiao et al. [29] proposed RSS-based Sybil attack detection schemes. Their schemes verify the claimed position of the neighbor vehicles through RSS. Nevertheless, intelligent attackers could manipulate the signal strength with likely probability as well. Martucci et al. [17] used self-certified pseudonyms created by vehicles themselves with the help of cryptographic long-term identities in order to counter the Sybil attacks in VANET. Another famous pseudonym-based Sybil attack detection scheme proposed by Zhou et al. [27] is named as privacy-preserving detection of abuses of pseudonyms (P2 DAP). In their scheme department of motor vehicles (DMV) creates enough pool of pseudonyms for each vehicle based on coarse-grained and fine-grained hash functions and road-side boxes (RSBs) are used to monitor the values as a result of aforementioned functions and (RSBs) check for possible potential Sybil attacks. Nevertheless the DMV may become a bottleneck to create enough pseudonyms for a large number of vehicles. There are also a number of Sybil attack detection schemes which work through vehicles’ trajectories. Chen et al.’s [1] proposed a scheme based on normal and abnormal motion trajectories of vehicles, and on the digital signature of authorized RSUs. Sybil attack is then detected by comparing and analyzing the difference of neighbor vehicles’ motion trajectories. However a vehicle being in urban localities may remain under the single RSU for relatively long time. Similarly Park et al. [26] proposed a similar RSU-assisted Sybil attack defense scheme where RSUs issue timestamp certificates to vehicles which are used to detect Sybil attacks. Grover et al. [7,8] used RSUs to calculate and store different parameter values (RSS, distance, angle) after receiving beacons from nearby vehicles and after significant observation period, RSUs exchange their records. The vehicles exchange their neighborhood information in order to check for potential Sybil attacks. Recently, Chang et al. [24] proposed a scheme named Footprint to detect Sybil attacks by using vehicular trajectories for identification in VANET where a vehicle actively demands an authorized message from an RSU as a proof of the appearance time. With their scheme, vehicles can generate a location-hidden
123
R. Hussain, H. Oh
trajectory for location-privacy-preserved identification by collecting a consecutive series of authorized messages. However contrary to authors’ claim; the location of vehicles might be jeopardized due to high frequency beacons and because of the fact that beacon data includes location information in plaintext. Moreover the location of RSUs may not need to be private information. Furthermore, Footprint is proactive in nature where the accused nodes provide the proof when they are asked for. Colluding malicious attackers may exploit this property to launch Sybil attacks. 2.1 Our Contributions After investigating previously proposed schemes as remedies for Sybil attacks in VANET, we put forth a new Sybil attack detection scheme for both SB and ERM. In case of SB, we extend our previously proposed privacy-preserved identityless beaconing mechanism [11] and propose a TRM-driven pre-assembly data analysis scheme. For ERM, every vehicle that reports any event must have obtained ‘tokens’ from RSU beforehand. The token must be used as ‘one token per event’ and ‘one report per event’. Additionally our proposed scheme does not require the vehicles to pass through a number of RSUs in order to detect the possible Sybil attack. Even if a vehicle remains under the jurisdiction of the same RSU, the Sybil attack can be detected. Our proposed scheme guarantees conditional anonymity in case of both SB and ERM.
3 System Model In this section we formally define our network model, threat model, security requirements, and design objectives. We assume Hussain et al. [10,11] and Sun et al.’s scheme [14] as baseline for our proposed model. 3.1 Network Model The typical VANET infrastructure consists of DMV [27], at the top of the hierarchy which can be split up into two functional bodies named revocation authority (RA) and regional certification authority (RCA). Due to seriousness of liability issues, the revocation functionality is handed over to a number of physical entities who then collaboratively revoke the node or message in case of a dispute. If a single entity (e.g. police department) is given the capability to revoke a message or vehicle, the privilege that a node can be revoked maybe abused [14]. By splitting the revocation functionality into several entities has two-fold advantages: it will keep corrupt authorities from abusing users’ privacy and will stop malicious authorities from framing benign nodes. We divide the hierarchy into managerial and functional units as shown in Fig. 1 and the proposed VANET infrastructure is illustrated in Fig. 2 [10]. Figure 1 illustrates management and functional hierarchy of VANET. There are 4 levels in the hierarchy and each level in management hierarchy is represented by a physical entity in the subsequent parallel functional part. • Entity registration, initialization, and overall management functionality is given to the root of the management hierarchy: DMV.1 DMV is supposed to be trusted body for all other entities in the network. It is mainly responsible for initialization and registration of vehicles and road-side infrastructure (RSI). 1 The notion of DMV might be different depending upon the government structure of the country.
123
On Secure and Privacy-Aware Sybil Attack Detection
Fig. 1 Managerial and functional hierarchy in VANET
Fig. 2 An illustration of baseline for proposed VANET architecture
• To distribute the certification function across the network physically, the physical roads divided into domains and each domain is supervised by a certain regional CA (RCA). Note that the notion ‘domain’ might be different in different countries and areas depending upon the volume of the network. Moreover two consecutive domains have some overlapping area between them and they are supervised by BRSUs in order to deliver the tokens and update the domain level common keys. • To provide intermediacy between vehicular nodes and RCAs and/or RAs, another level is added to the management called functional assistance level. The functional entities involved in this process are RSUs and BRSUs. These entities are assumed to be ‘semitrusted’ and provide means of communication between level 3 and level 4 entities in Fig. 1 as well as key updates. Moreover RSUs are connected to each other, to RCAs, and to RAs through high-speed backbone. We assume that RSUs are deployed at hotspots which are critical from traffic density standpoint and they are synchronized.
123
R. Hussain, H. Oh
Fig. 3 Functional entities hierarchy in VANET
• Vehicles and RSUs are equipped with OBU and TRM. With current technologies, OBUs are capable of carrying out necessary ordinary and cryptographic computations. Vehicles communicate with each other and with the stationary RSUs. • TRMs are assumed to be semi-trusted entities because recent researches have shown that side-channel attacks are possible to tamper with TRM. Nevertheless we assume that TRM will at least give a hard time to attacker if it is not impossible to tamper with and buy us some more time to take necessary actions. • All messages are assembled inside TRM, the secret keys and certificates are stored in TRM, and only authentic configuration of TRM is possible [19]. • According to DSRC standard, vehicles broadcast their current whereabouts information including position, speed, time, acceleration/deceleration, and direction etc. (hereafter called ‘beacons’ [22]) to other vehicles and RSUs in the vicinity. VANET security application formulates the traffic views based on the received information in the beacons. The management hierarchy is shown in Fig. 3 [10]. Figure 3 illustrates the functional entities hierarchy in VANET. It must be noted that each RCA is an autonomous certification authority and controls a specific domain under its jurisdiction. 3.2 Threat Model In order to launch a Sybil attack in VANET, we assume the attackers to be insiders and have more resources and capabilities than a common legitimate node. The aforementioned argument is justified because in order to launch a Sybil attack, the attacker has to delude the benign neighbors with presenting him/herself with multiple physical entities and/or multiple identities. One possible way is to install more than one physical wireless module on the system. The attacker capabilities in our threat model are partially alike with the models considered in [27] and [24]. However we cover more microscopic details such as message construction and beacons as well. We term any node as an ‘attacker’ if it deviates from normal VANET behavior or infringes with a user’s privacy. The attacker is also assumed to have capability to eavesdrop on wireless channel. Due to the openness of wireless channel and the excess of resources, the attacker may forge identities, spoof them, or impersonate other vehicles as a result of message manipulation. Moreover the attacker can track other nodes (profilation), and diffuse wrong information into the network. Since to date, many voting-based schemes have been proposed for decision-making processes in VANET, if the attacker succeeds in presenting multiple identities, the decision can easily be biased and affect the normal VANET behavior. Since independent modules are used to input the data for
123
On Secure and Privacy-Aware Sybil Attack Detection
message construction (for instance GPS and speedometer), we also assume that the attacker can manipulate the input data that is used for message construction. 3.3 Security Requirements • Authentication Since there is always threat from illegitimate users to inject bogus information into the network, user authentication becomes inevitable. Each entity after receiving any message must authenticate the source of the message. However the degree of sophistication in authentication might be different in case of SB and other critical messages (ERM). ERM needs more sophisticated authentication than that of SB because the former is mostly concerned with the life of the passengers. • Nonrepudiation Due to liability issues in VANET, the proposed scheme must ensure nonrepudiation on the part of nodes, where they must not deny the transmission or even the content of the messages. There are number of methods to check the liability. Most commonly used method is PCA (Post Crash Analysis) where the messages saved in vehicle are investigated. • Conditional Privacy Privacy is one of the prime concerns in VANET. The attacker resulting in violating user or location privacy is usually termed as observer. In order to preserve the privacy, message receiver must not be able to link more than one message to a particular user and must not be able to generate movement profiles. Nevertheless, conditional privacy is indispensable in VANET where the RAs must be able to revoke any entity in case of a dispute. • Sybil Attack Detection (SAD) Preventing and detecting Sybil attacks in ideal privacy preserving schemes is challenging, where the messages (both SB and ERM) are independent of the sender and un-linkable. The system must have a way to detect the possible Sybil attack and take the countermeasures accordingly. 3.4 Design Goals Our proposed scheme must achieve the following goals: • Privacy preserving beacons and warning messages We aim to provide a secure and privacy-aware way to broadcast beacons and alarm messages with conditional anonymity where aforementioned messages are subject to revocation in case of any dispute. We extend our previously proposed identityless beaconing mechanism [11] and the TRM performs light-weight pre-assembly analysis on beacons. • Sybil Attack Detection Our proposed scheme incorporates token-based scheme in order to detect the potential Sybil attack in case of ERM where vehicles include tokens in ERMs. In case of SB, TRM performs lightweight pre-assembly analysis on the data input to TRM in order to alleviate the possible creation of illusion where malicious nodes simulate virtual vehicles with different locations and other beacon statistics. Table 1 lists the notations that will be used throughout the paper.
123
R. Hussain, H. Oh Table 1 Notations 1
d
Physical domain in VANET
2
H M AC(M, K )
Hashed Message Authentication Code on message M with key K
3
H( )
Collision-free hash function
4
σ
Loose authentication and integrity factor for beacon message
5
δ
Beacon revocation factor
6
Kd
Domain level common key used by vehicles to calculate authentication and integrity factor (σ )
7
KV
Individual secret key used by vehicle to calculate beacon revocation factor (δ)
8
GID
Virtual Group ID of beacon message
9
Cer t Root
Root CA’s Certificate stored at TRM of Vehicles and RSUs
10
Cer tT R M
TRM’s Certificate stored in TRM at the time of initialization
11
Cer tT R Mm
13
Pr (K TPub RM , KT RM )
14
(K T R Mi
15
Pub , K Pr ) (K RSU RSU
A Public Private key pair of i-th RSU
16
Sig K Pr (M)
17
V eri f y K Pub (Sig K Pr (M))
Pr Signing the message M with key K TPrR M or K RSU Pub Verifying the signed message with K TPub R M or K RSU
18
RSU–ID
RSU ID
19
BRSU–ID
Border RSU ID
20
KT R
Session key established between TRM and RSU to deliver K d and tokens
21
T kT R M
m-th Token of the TRM issued by BRSU
22
||
Concatenation operation, which appends several message units
Pub
Short-lived certificate of T R Mm created by RSU j
j
A long-term Public, Private key pair of the TRM of a particular vehicle
Pr
mj
, K T Ri M
mj
x
x
(m)
x
)
Short-lived public, private key pair of the T R Mm issued by RSU j
4 Baseline According to DSRC standard [4], cooperative awareness among vehicles is realized by using SB. Besides SBs, vehicles also broadcast events and/or warning messages like traffic jam and accidents etc. However, since privacy is an essential parameter in VANET security, it must be given more attention explicitly in case of high-frequency SB; profilation may be possible, otherwise. We assume the pseudonymless beaconing scheme by Hussain et al. [11] as baseline. It is worth noting that currently there is no final recommendation for a particular beacon frequency, albeit a number of adaptive schemes have been proposed [23,25]. 4.1 Messages in VANET VANET messages can be divided into two basic forms; beacons (SB) and ERM. The format of identityless SB is given in Fig. 4.
123
On Secure and Privacy-Aware Sybil Attack Detection
Fig. 4 Identityless beacon format
Fig. 5 Warning message (ERM) format
Where Data is current beacon data including current position, speed, heading, and lane information etc., T represents timestamp for freshness. Due to high frequency of SB, we do not need any sophisticated authentication mechanism. Instead, we use loose authentication in SB using HMACs. Vehicles carry two types of keys for SB, K d and K V . K d is used by vehicles2 in a particular domain to check the integrity of entire message including σ while K V is the individual secret key, used by vehicle for liability reasons. In case of a dispute (for instance a deadly accident), this key is used to revoke a message and/or a node. It is worth noting that Kd is updated on a regular interval by RCAs and K V is updated when vehicles undergo regular inspection by DMV. RCAs divide the vehicles into virtual groups to reduce the effect of partial brute-force revocation; therefore group ID (GID) is included in SB. For more detail about grouping techniques and revocation process, we refer the readers to [11]. The second type of messages is ERM. In case of critical scenarios in VANET, for instance accident on the road, fog, traffic jam, and approaching ambulance, the observer reports the event to nearby vehicles to avoid any further hazard situation for the vehicles following the observer. The vehicles are supposed to append a token with the ERM while reporting an event. This token is issued by a BRSU in certain domain and serves as certificate of authenticity to the vehicle reporting ERM. More detail on tokens will be discussed in the following section. The format of warning message (ERM)3 is given in Fig. 5. Where Type is the type of warning (also indicating whether the message is relayed message and/or observed), Event information includes EID (event ID), Loc (location where the event occurred), GID (group ID from beacon message), T (timestamp), loci T (current location of (m) the immediate source of the warning message at time T ), and T k T R Mi is the m-th token issued by a BRSU to T R Mi . The contents of the token are discussed in the following section. The message is signed by the sender with its K TPrRi Mm (T R Mm ’s i-th short-lived private key and it j
is different from K V ) and it also includes Cer tT R Mm j . We assume Wasef et al.’s ECMV [28], where BRSU issues a set of anonymous certificates to the vehicle at the time of issuing tokens. i These certificates contain the public key K TPub R Mm which enables the receivers or ERM to j
verify the signature on ERM with the function V eri f y
(Sign
Pub
K T R Mi m
j
(E R M)) . The
Pr
K T RiMm
j
anonymous certificates preserve privacy efficiently and can be updated by any nearby RSU [28]. The second row in Figs. 3 and 4 shows the size of each field in the message in bytes [12,28]. Additionally, the warning message travels relatively farther than the normally sent 2 Terms ‘vehicles’, ‘vehicular nodes’, and ‘nodes’ are used in this paper interchangeably. 3 The terms ‘event reporting’ and ‘warning’ are used interchangeably in this paper because ERM serves as
warning to the receiver as well.
123
R. Hussain, H. Oh
Fig. 6 Relayed ERM format
beacons. Depending upon relaying mechanism (efficient flooding) in place, warning message must be relayed to reach a maximum distance to cover region of expected infection (REI). The format of relayed message is given in Fig. 6. Where λ = (E I D, Loc, SG I D, Δ Loc, Δ T ). Instead of using explicit location information and timestamp from original ERM, we use relative difference in location (ΔLoc) and time difference (ΔT ). SG I D is the group ID of the immediate source of ERM. The advantage of such approach is twofold: it will reduce the number of extra bytes needed; hence reducing communication overhead and the time difference will make sure that the message is not stale. We assume that different types of warning messages and their expected actions after warning are already stored in the OBUs beforehand. Upon receiving an ERM, the receiver first performs ownership verification by making i sure that the verification is sound with applying K TPub R Mm to the signed ERM, otherwise the j
i receiver will reject ERM. Since any K TPrR Mx other than the sender (K TPub R Mm ), would fail j
the verification: therefore the ERM cannot be misused by other vehicles. When ownership verification test is passed, then token legitimacy is checked. Details about token legitimacy are outlined in Sect. 5.3. 4.2 Sybil Attack in VANET In Sybil attack, an attacker forges its identity to masquerade as another node. The attacker creates multiple identities through forging, stealing, or by using any other means. The Sybil attacks were first described and formalized by Douceur et al. [5]. In VANET scenario, usually multiple nodes report certain events and at the receiver end, receivers accept the results based on the majority. Most of the schemes assume the fact from daily life that “Any news might be authentic if it is heard from a number of people rather than from only one person”. The Sybil attacker creates illusion by using multiple identities (non-physical nodes) thereby making other neighbors to think as if the report came from many physical nodes. The attacker may exploit multiple identities to report single event many times (for instance with multiple pseudonyms). Especially such situation is most likely in the strong privacy-preserving environment. We believe that the Sybil attack prevention in a privacy-preserving environment is an intimidating challenge for VANET. 5 Proposed Sybil Attack Detection Scheme 5.1 Design Rationale We assume multiple-lane roads and vehicles (more precisely their OBUs) broadcast two types of messages: SB and ERMs. It is worth mentioning that in worst case; almost all kinds of attacks can be launched in VANET in the presence of Sybil attack. For instance, an attacker might create an illusion of traffic jam or accident so that other vehicles change their scheduled path or in worst cases, leave the road for the benefit of the malicious attacker.
123
On Secure and Privacy-Aware Sybil Attack Detection
Additionally, Sybil attacker can also inject bogus information in VANET via some spoofed and fabricated non-existing identities. For example, in case of an icy road segment on the highway, the first vehicle observing that particular road segment sends change route or deceleration warning message to all others who are heading towards the affected area. Receivers may forward this message to warn followers, if there are any. In the presence of Sybil nodes, the forwarding process could be disrupted by not forwarding the warning message at all. This may even jeopardize the life of the passengers. Therefore the online detection of Sybil attack becomes essential. 5.2 Sybil Attack Detection in Scheduled Beacons (SB) We handle the Sybil attack through SB by manipulating TRM where TRM performs a lightweight pre-assembly analysis on the data that is input from outer modules such as GPS and speedometer etc. to TRM in order to construct beacon message. With the capabilities of TRM, we do not need to worry about the Sybil attack launched from beaconing because TRM will be configured to generate the beacons according to the specifications of DSRC standard. The only threat which can lead to Sybil attack is the outer modules that provide TRM with data for beacon assembly. To countermeasure this issue, the data may be processed before accepting by the TRM. The analysis includes position change, velocity change, timestamp change, and lane change. TRM enforces aforementioned checks on data incoming to TRM before assembling SB. In fact the current received information is compared with previous stored information to confirm consistency in the information. • Position Change (PC) Check Let suppose P O Scur be the current position from GPS and V elcur be the current velocity at current time tcur that was read by TRM and P O S pr ev , V el pr ev be the immediate previous position and velocity respectively at time t pr ev . TRM must check for the following condition before accepting the GPS coordinates. dist P O Scur , P O S pr ev ≤ (1) Where dist is the Euclidean distance between two coordinates and is the position threshold factor. is influenced by the velocity of the vehicle. More precisely, the change of the position between two consecutive beacons will depend upon the current speed that was recorded in the previous beacon. If the change is within the range (factor ), then TRM accepts the position otherwise it will reject the input. • Velocity Change (VC) Check Similarly TRM must also check for following condition before accepting the current velocity. ΔV el ≤ , ΔV el = |V elcur − V el pr ev |
(2)
Where ΔV el denotes the change in velocity between V el pr ev and V elcur , V el pr ev is the velocity at time t pr ev , V elcur is the velocity at time tcur , and is the threshold velocity factor which bounds the claim of change in velocity. TRM accepts the data only if it is in the specified range . • Time Change (TC) Check TRM must make sure that the timestamp of two consecutive beacons is sound according to the current frequency of the beacon. In case of dynamic beacon frequency, TRM must check
123
R. Hussain, H. Oh
for the immediate previous frequency. TRM compares current time with the timestamp of previous beacon and check for the following relation. Δt ≤ f b , Δt = |tcur − t pr ev |
(3)
In above equation, Δt is the change in time, tcur is the current time, and t pr ev is the time from previous beacon. f b is the beacon frequency according to DSRC standard. Nevertheless this frequency can be dynamic and may vary from beacon to beacon. The beacon frequency is measured in terms of time and usually it is in the order of milliseconds. • Lane Change (LC) Check Since the frequency of beacons is in the order of milliseconds, it is too short for vehicle to change from current lane to at least the immediate third lane (if there are more than three lanes). TRM must check for the following condition. Δl ≤ 1, Δl = |lcur − l pr ev |
(4)
l pr ev is the lane where vehicle was present at time t pr ev and lcur is the lane where vehicle is positioned at current time tcur . We formally define the above analysis and bind TRM to accept the data from outer modules if and only if it passes the aforementioned tests. T RU E if the acceptance test is passed baccepted = F AL S E Otherwise (5) baccepted⇔(dist ( P O Scur ,P O S prev )≤) (ΔV el≤) (Δt≤ f b ) (Δl≤1) baccepted is the candidate beacon which may pass or fail the acceptance test. Upon passing the analysis test, it means that the data input to the TRM is sound, consistent, and Sybil-free. Our argument is also supported by the fact that even if the Sybil attacker starts manipulating TRM, at some point in time it will become intermittent in consistency. The data will be rejected if any of the aforementioned tests fails. The TRM will assemble the beacon with received data if and only if the value calculated from baccepted is TRUE. To this end, we perform pre-assembly data analysis on the data that is used to form scheduled beacons. We consider the thorough analysis of the parameters in the acceptance test for our future work. 5.3 Token-Based Approach for Sybil Attack Detection In this sub-section, we put forth our token based approach to prevent Sybil attacks caused by ERMs. When a vehicle enters an overlapped area between the two domains, it initiates a request for domain level common key K d , a set of anonymous public key certificates, and tokens (see the protocol in next subsection). K d is used to calculate σ in the SB. The received token is consumed when reporting any ERM to other vehicles in the neighborhood. The process of using tokens in ERMs is depicted as follows. The reporting vehicle’s TRM generates an ERM, appends a legitimate token to the message, signs it and broadcasts it to its neighbors. The format of ERM including token is already illustrated in Figs. 5 and 6. The vehicles and RSUs upon receiving ERM, first check whether the ERM belongs to the legitimate owner (as outlined in previous section) followed by checking the legitimacy of token. For token legitimacy, the receiver checks if the legitimacy test is passed, then the receiver takes necessary actions as per the contents of ERM accordingly. Legitimacy test is executed by the receiver by verifying the token with K BPub RSU j by applying Sig K Pr the function as V eri f y K Pub (T k) , where K BPub RSU j is the public key of the B RSU j
123
B RSU j
On Secure and Privacy-Aware Sybil Attack Detection
border RSU that issued the token and we assume that the vehicles already know BRSU’s public key. Since any K BPrRSUx other than the border RSU (K BPrRSU j ) that issued the token, would fail the verification, therefore the ERM cannot be misused by other entities. The validity period of token is a prime parameter to keep the TRM from using token more than once. We use short lived tokens in order to avoid the tokens replay. With the capabilities of TRM, we argue that TRM can be tuned to use the token only once and remove it from the memory right after using it with ERM. However, accountability is still possible since RSU and RCA maintain a database where they store the backtrack information about the issued tokens. RSUs overhear the ERM either directly or through multi-hop communication. In either case RSUs gather the overheard ERMs for an event, save it in order to check for any attempt of Sybil attack. The relayed messages do not necessarily mean duplicate messages because RSU can figure it out from the type of the message (Figs. 5, 6) and the token which is used to sign ERM. Whenever an ERM is reported, RSU can check if the event is signed with more than one ) token from a single vehicle. Let suppose T k T(mR1M denotes the m 1 -th token corresponding i (m )
to T R Mi and T k T R2Mi denotes m 2 -th token corresponding to same T R Mi then a single (m )
(m )
ERM must not be signed with T k T R1Mi or T k T R2Mi at the same time. RSU, when analyzing the ERMs signed with token, if an event is signed with more than one token from the same (m ) (m ) vehicle (T k T R1Mi , T k T R2Mi ), RSU will accuse that vehicle to the revocation authority(s), more precisely RSU will send Cer tT R Mm j along with the signed tokens to RA(s). Same ERM can be relayed by more than one relayer. To this end, if a receiver is chosen to be a relayer for the received ERM, after checking for ownership and legitimacy tests, the relayer constructs its ERM for the same event as in Fig. 6 and relays it. RSU upon overhearing relayed ERM will not conclude that the same ERM is signed by more than one token because: (1) It will check for the type of the ERM (2) the immediate originator information is included in the relayed ERM. In case of any suspicion, both relayer and originator are subject to revocation, whoever caught guilty. Due to the fact that ERM must travel farther than one hop distance, it might be rebroadcasted to multi-hop neighbors as well. We presume that in order to rebroadcast ERM, probabilistic Inter-Vehicle Geocast (p-IVG) [13] is used. Note that TRM must make sure that a single token is consumed for only one ERM. If this assumption does not hold, then our scheme might not work. Figure 2 explains the scenario. In the figure, an accident occurred at some point in time at location l in domain 2. The effected vehicle initiates an ERM to its neighbor vehicles and RSU in its range. In order to report the event, the affected vehicle consumes its token. In the overlapped region, vehicle V1 and V2 initiate request to BRSU for domain level common key and tokens. There are two possible approaches for the token delivery. • The vehicle requests for a single token along with K d and consumes it in reporting an ERM. For subsequent events, vehicle (most precisely its OBU) requests to RSU for token and after receiving the token, it is consumed to report ERM. • The vehicle requests for a set of tokens, stores them in TRM and consumes them one at a time for ERM. We believe that the number of tokens received will vary depending upon the nature of domain, for example a vehicle may need more tokens in the urban area than on a freeway. Moreover certain domains might need more tokens than others depending upon the traffic density in domains. It is worth mentioning that if we use the ‘single token at a time’ strategy, then RSU may become a bottleneck because it will be more likely that every vehicle in the vicinity that
123
R. Hussain, H. Oh
Fig. 7 Illusion-based Sybil attack scenario
reports the event, will request RSU for token at the same time. That is why we propose that our scheme uses ‘set of tokens’ strategy. Note that the tokens are only applicable under the jurisdiction of certain RCA which covers a certain number of BRSUs that issued the tokens and the RSUs in between. TRM will automatically delete the tokens when the vehicle is out of the range of the tokens issuing domain. 5.3.1 Illusion-Based Sybil Attack Scenario Figure 7 illustrates an illusion-based Sybil attack scenario. Given a set of ERMs within a reasonable timespan of an event, we will explain that how does an RSU recognize distinct ERMs, from those which are duplicated and signed with multiple tokens? There could be many variations of Sybil attacks, but for the sake of understanding, we demonstrate an example of illusion creation. In Fig. 7, V1 requests BRSU for K d and tokens at timet1 . BRSU after verifying V1 ’s authenticity, issues a legitimate set of tokens to V1 . Let suppose V1 constructs an ERM, manipulates the originator information for ERM and pretends (m ) to be a non-existent V1,5 , signs it with a token T k T R1MV , and broadcasts it. RSU overhears the 1 ERM and saves it. Soon after, this malicious insider V1 again generates an ERM for the same event, manipulates the originator information and pretends to be V1,4 and so forth. Malicious V1 creates illusion by manipulating the originator information as if there were 5 distinct vehicles {V1,1 , V1,2 , V1,3 , V1,4 , V1,5 }. RSU saves all reported ERMs and analyzes the tokens (m ) (m ) (m ) in the ERMs, and checks for the tokens {T k T R1MV , T k T R2MV , . . . , T k T R5MV } against the (m )
1
(m )
1
(m )
1
(m
)
stored tokens and soon finds out that {T k T R1MV , T k T R2MV , . . . , T k T R5MV } ⊆ {T k T R1∼5 MV1 }, 1 1 1 which means that the tokens which were used to sign ERM, belong to same V1 . RSU accuses V1 to DMV and DMV can issue a warrant against V1 for revocation. It must be noted that tokens from other legitimate nodes are hard to forge because they are signed by BRSU and contains requester’s credentials. This argument holds as long as BRSU is not compromised.
123
On Secure and Privacy-Aware Sybil Attack Detection
Fig. 8 Tokens and domain level common key updating protocol
5.4 Token and Domain Key Updating Protocol Figure 8 depicts the token and domain level common key updating protocol. BRSUs broadcast their certificate Cer t B RSU and BRSU-ID periodically. When a vehicle enters the overlapped region its TRM initiates a request for K d , anonymous public key certificates, and tokens. The request contains TRM’s public key signed by RCA. After verifying legitimacy of the request, vehicle’s TRM and BRSU establish a secure session key K T R for the secure delivery of K d , anonymous public key certificates, and tokens. Secure ECHD (Elliptic Curve DiffieHellman) may be used as session key exchange protocol and we do not give the thorough details of the session key establishment here. Once the secure session key is established between the two parties, BRSU generates the signed tokens, appends these tokens along with the currently used domain key K d and sends them to the requesting vehicle. BRSU also stores information about these tokens in a local database. The contents of a single token include the timestamp T , the validity period, TRM’s public key K TPub R Mi hashed with a random number Rn and border BRSU-ID. We assume that the validity time factor depends upon the time that is taken to pass through the domain. If that domain is passed through, the tokens will be removed from TRM anyway, otherwise if somehow the vehicle does not pass through the issuing domain (like in urban areas), then the vehicle must get fresh tokens from the border through the currently available RSU. It could be easily done since we assume that RSUs are connected through high-speed backbone and synchronized. By including TRM’s long-term public key in the token, it is guaranteed that only that particular vehicle can use the token and nobody else (at least unless the vehicle is compromised), because the contents of the token are signed by BRSU. Note that the vehicle uses old K d and token in the overlapped region.
6 Analysis and Evaluation In this section, we evaluate our proposed scheme in the light of security analysis, privacy analysis, conditional anonymity, comparison with previously proposed schemes, and probabilistic analysis. 6.1 Security We consider the security of two kinds of messages in VANET: • Scheduled beacons
123
R. Hussain, H. Oh
• Token-contained ERM Due to the high ephemeral nature of VANET and application requirements, vehicles broadcast beacons with dynamically high frequency. This characteristic limits the degree of sophistication for beacon authentication. Instead, we use HMACs to perform loose authentication in case of SB. HMACs offer twofold advantages in case of beacons: they authenticate the sender and provide a mean for checking the integrity of the contents. In case of token-contained ERM, we use ECMV [28] for authentication. The reason for using ECMV is because it fits to the hierarchy of our proposed scheme. The security requirements in aforementioned two types of messages are authentication, message integrity, privacy protection, anonymity revocability, and non-frameability. Due to the application nature of beacon messages, confidentiality is not a concern in beacons. In other words, the information contained in beacon message is only used in safety application by the vehicles in vicinity; hence there is no reason to encrypt the information in the SB. Since the nature of wireless medium is open thereby giving the malicious nodes full access to the contents of the messages on the medium. They can manipulate the messages and use them for malicious purposes. In case of beacons and ERM, any attempt to masquerade with the contents would fail because in case of SB, K V would keep them from misusing the beacons whereas in case of ERM, first it has to be verified for the legitimate owner. The misuse would be only possible if the private key of the sender was compromised. The compromise of K d has severe consequences and affects the whole domain. Since SBs do not carry any identity information, the receiver of the beacon cannot bind the beacons to a particular vehicle. In such scenario, prevention of Sybil attack is more challenging. To this end, TRM copes with this issue. TRM of every vehicle is responsible for detecting any kind of attempt that may lead to a Sybil attack in which the malicious attacker may manipulate the outer modules to provide the TRM with wrong data to assemble wrong message thereby creating illusions. Every time TRM gets data from outer modules, it performs a test for a parameter baccepted and accepts the data if the value of baccepted is TRUE. This analysis is carried out by comparing the newly received data with the immediate previous stored data. To this end, every vehicle locally checks for Sybil attempt in the high frequency beaconing environment. In case of ERM, a distinct token is appended with each ERM. The nature of our proposed scheme is disposable, i.e. a token can be used only once. TRM makes sure that a token is not used twice. Immediately after using the token for an ERM, it is deleted from TRM and additionally, TRM also makes sure that an event is reported only once by a particular node. The deletion of tokens might not be an issue since they would be already saved in the database of BRSUs and RCAs, and can be revoked, if needed. However even in case of multiple uses of tokens, BRSUs will pin point the possible Sybil attacker because information about the issued tokens and backtrack information is already stored in the database. Additionally RSUs differentiate among direct and relayed ERMs. It is worth noting that if an attacker tries to manipulate the location information, TRM will figure that out and will not accept the information if it is not sound with the immediate previous information. One possibility is that the attacker manipulates the information from the very start of the vehicle’s journey. However, then the attacker must continue that manipulated location in order not to get caught. 6.2 Privacy and Conditional Anonymity Lemma 6.2.1 Our proposed scheme preserves conditional privacy and enables the revocation if needed with order O(g) and O(d · g) in case of SB and ERM respectively.
123
On Secure and Privacy-Aware Sybil Attack Detection
Proof Our proposed SB does not carry any identity information which could be used to link messages to the node, hence providing non-linkability. Vehicles anonymously broadcast SB and in case of any dispute (with warranty issued by DMV), they are subject to revocation. The same argument holds for token-contained ERM. The privacy is also preserved in case of ERM because the contents of the token are anonymous for the recipient of ERM. Only RSUs and RAs can trace back the source of ERM and recognize the owner of the token from the value H (Rn ||K TPub R Mi ). It is worth mentioning that the notion ‘revocation’ differs in case of message and user. Message revocation refers to linking a message to its sender whereas user revocation refers to abandon the revoked user from VANET functionality. In our proposed scheme, the SB and ERM provide conditional anonymity. Group information GID and individual secret key K V is exploited to revoke the culprit. To revoke an SB, RA extracts domain information from the beacon followed by group information and then a partial brute-force is applied on that group to revoke the message. Note that the security credentials are stored against each vehicle beforehand, at the time of issuing keys by the competent authorities. The order of revocation in case of beacon message is O(d + g) where d is the size of the domain and g is the size of the group. Since d g we can ignore d; hence the order of revocation in case of beacon message is O(g) . In case of ERM, GID is used to revoke the anonymity of the message. Nevertheless, the scope of the brute-force will be larger than in case of beacon messages. The order of revocation in case of ERM is O(d · g) because RAs must traverse through domains to find the group ID that was extracted from the warning message. 6.3 Computational and Communication Overhead In this sub-section we consider the computational overhead of our proposed scheme from both SB and ERM standpoint. Since we do not include any signatures or certificates in SB, the cost of verification for our beacon messages is only 2H where H denotes the hash operation. More precisely on average, the verification cost might approach to 1H because the revocation might be needed only in extreme conditions. In case of ERM, two signature verifications are performed in our proposed scheme. Upon receiving ERM, the receiver first checks for token legitimacy and then ERM itself. Tokens and ERM both carry signatures which cost the OBU equal to 2 × T p + 3Tm + 2TH , where T p denotes the time required to perform a pairing operation, Tm denotes the time required to perform a point multiplication and TH denotes the time of hash operations. According to [2], T p and Tm have been found for a supersingular curve with embedding degree k = 6 over F397 to be equal to 2.82 and 0.78 ms, respectively. Hence the time required to verify ERM denoted by TV eri f y E R M is given by. TVerify E R M = (4TH + 10.32) ms
(6)
The communication overhead incurred by our proposed scheme is fixed and can be examined from Figs. 5 and 6. We consider both one-hop ERM and relayed ERM, where the communication overhead is 251 and 256 bytes respectively. The communication overhead incurred by our scheme is better than Chang et al.’s scheme [24] where increase in trajectories result in drastic increase in communication overhead as well by factor of n, where n is the number of trajectories included in the message. Communication overhead in [24] is equal to 68×n bytes. We also consider the storage overhead incurred by our token-based Sybil attack detection. Since the tokens are issued to the vehicles by RSUs, if there are k tokens issued to the vehicles in a single run, then the OBU needs k × 44 bytes of memory. Keeping in mind the size of
123
R. Hussain, H. Oh
the area covered by the RSU and the zone size, the storage might not be a problem for our proposed scheme. The tokens are subject to refresh after the validity time is expired. 6.4 Comparison with Other Schemes We compare our proposed scheme with other RSU-assisted Sybil attack detection and prevention schemes. To the best of our knowledge, the other RSU-based Sybil attack detection and prevention schemes are Zhou et al. [27], Park et al. [26], Chen et al. [1], and Chang et al. [24] whereas Ruj et al. [20] proposed data-centric based Sybil attack detection scheme. We show that our proposed scheme is computationally efficient than the aforementioned schemes. Table 2 summarizes the comparison form different perspectives. The comparison metrics include signatures with beacons, # of RSUs traversed, need for aggregated signatures and timestamps, privacy, RSUs as bottleneck, profile generation, and computational complexity. In the last paragraph we also outline the model complexity incurred by our proposed scheme and compare it with Chang et al.’s scheme [24]. It can be argued from the comparison that our proposed scheme outperforms the previous schemes in terms of security aspects and computational complexity. Nevertheless our proposed scheme differs from the other schemes in certain aspects for instance, underlying network architecture but still the goal is almost identical. We do not include any signatures or certificates in SB whereas Chen et al. [1], Park et al. [26], and Ruj et al. [20] do. Their schemes use traditional signature-based beaconing mechanisms which is highly questionable in VANET. Particularly from Table 2 it can be observed that [1,26], and [20] use signatures in high frequency SB that require computationally expensive verification whereas our scheme does not use such signatures with SB. For ERMs, [1] and [26] need r and n number of signature verifications (VerifySig) and they do not take privacy into account. Moreover profile generation is possible in their scheme. On the other hand Zhou et al. only use n number of hashes for verification, however profile generation is still possible and the privacy in their scheme depends upon the change of pseudonyms. The verification cost of our proposed scheme is same as that of Ruj et al. scheme, however Ruj et al. did not countermeasure the profile generation and the privacy in their scheme depends upon the pseudonym change as that in Zhou et al.’s scheme. Our scheme is repellent to profile generation, however conditional privacy is still preserved where in case of a dispute, a user is subject to revocation. Whereas Chen et al. [1] and Park et al.’s [26] scheme do not take the privacy into account. The privacy of Zhou et al. [27] and Ruj et al.’s [20] schemes depend upon the rate of change of pseudonyms and Chang et al.’s [24] scheme is prone to colluding attacks. Chang et al.’s [24] scheme is passive in the sense that nobody would care for Sybil attack detection until somebody raises any concern about the messages which makes their scheme more vulnerable to colluding attacks. In contrast, our proposed scheme is active where RSUs upon receiving ERM, checks for duplicate tokens with the same ERM. Previously proposed schemes do not take beacons into account, especially Zhou et al. [27] and Chang et al. [24]. From computational complexity standpoint, our beacon messages are lightweight requiring only two hash computations and according to Table 2, our ERM messages require fewer computations than previous schemes. The model complexity incurred by our proposed scheme can be divided into two parts: in case of beacons, the complexity of localizing Sybil attack is O(1) whereas in case of ERM, the complexity is O( j × n), j is the number of ERMs and n is the number of vehicles in AoI. To be more precise, this is the upper bound and worst case, for average case scenario, the complexity is O( n2 × j) . The complexity incurred by our proposed scheme is better than that
123
≥2
×
VerifySig
(n + 1) × VerifySig
≥2
×
VerifySig
r × VerifySig
SB
ERM
Signatures/Certificates with beacons # of RSUs traversed for attack detection Need for Aggregated Timestamps Privacy
RSUs as bottleneck
Profile Generation
Computations (Verification) n × TH
N/A
Dependent on pseudonym change
N/A
N/A
×
Zhou et al.
n number of signatures collected in aggregated signature, r number of signature vectors ex p modular exponentiation, VerifySig signature verification
Park et al.
Chen et al.
Scheme/comparison metrics
Table 2 Comparison with other schemes
27ex p + TH
N/A
T p + 3Tm + 2TH 2T p + 6Tm + 4TH
N/A
Prone to Colluding attack ×
N/A
Single or more RSUs
N/A
Cheng et al.
Dependent on pseudonym change N/A
N/A
N/A
Ruj et al.
2T p + 6Tm + 4TH
2H
×
×
×
Single RSU
×
Our Scheme
On Secure and Privacy-Aware Sybil Attack Detection
123
R. Hussain, H. Oh
of [24] where given n trajectories, the complexity is O(n 2 ) and in worst case, the complexity n becomes O(3 2 ) . The proposed scheme in [27] cannot be directly compared to our scheme from complexity standpoint. By comparing with the previous schemes our proposed scheme have the following advantages: • We do not include the signatures, certificates and pseudonyms in our SB. • If a vehicle is traveling under only one domain and RSU, it is enough to detect Sybil attack. Unlike the Park et al. [26] and Chen et al.’s [1] schemes which need that a vehicle must have traversed certain number of RSUs. • Our scheme is active where online Sybil attack detection is possible and is repellent to colluding attacks. • Our proposed scheme preserves privacy in both SB and ERM, and provides conditional anonymity. 6.5 Probabilistic Analysis and Discussion In this sub-section, we analyze the nodes that broadcast ERMs by consuming tokens. We calculate the probability that the vehicles in the AoI (Area of Interest) broadcast ERMs and the vehicles that consume more than one tokens leading to Sybil attacks. It is worth noting that a malicious attacker could also plant non-existing vehicles by creating illusions. But we define a Sybil attack as, “a vehicle or a set of vehicles that report an ERM more than one time with distinct tokens”. Let d is the number of the vehicles in AoI, ρ be the probability that each vehicle (OBU) reports the event using its token and X is a random variable denoting the number of reporting OBUs among total d OBUs. Then X follows Binomial Distribution B(d, ρ) is given by: d P {X = i} = ρ i (1 − ρ)d−i , i = 0, 1, 2, 3, . . . , d (7) i i is the number of vehicles that reported the event by broadcasting ERM and consumed authorized token. The expectation E is given by the following formula: d d (8) ρ i (1 − ρ)d−i = d × ρ E (X ) = i i=0
E(X ) represents the average number of ERM reported to RSU, which is denoted by Rer m and given by: Rer m = E (X ) = d × ρ
(9)
In addition to vehicles, RSUs also overhear ERMs in its Transmission Range (T R RSU ). The estimation of RSU capability to process maximum ERMs and detect duplicate ERM signed with different tokens by the same vehicle (denoted by Rer m−max ) is given below: Rer m−max =
TR RSU vel × Tover head
(10)
vel is vehicle’s velocity and Tover head is the time overhead incurred by RSU to process an ERM. Now since we have both estimated number of ERMs and average number of ERMs processed, we can compute the actual processed ERMs by RSUs (denoted by Rer m−actual ) as given below: i f Rer m ≤ Rer m−max Rer m (11) Rer m−actual = Rer m−max otherwise
123
On Secure and Privacy-Aware Sybil Attack Detection
Now we define the probability of the vehicles that deny the ‘one ERM and one token per event’. Let Y be another random variable that represents the vehicle that deliberately reports the same event twice with different tokens, and Y ≤ X . It is worth noting that in order to find probability of Y ; we must keep in mind that the density space will be reduced to those vehicles that already reported ERM. i P {Y = j} = ρ j (1 − ρ)i− j , j = 0, 1, 2, 3, . . . , i (12) j The expectation of Y is given by the following formula. E (Y ) =
d d i=0
i
ρ i (1 − ρ)d−i ×
i i j=0
j
ρ j (1 − ρ)i− j
(13)
Y is the probability that the vehicles that violates the normal reporting strategy and are thus included in malicious category. It must be noted that the probability space for Sybil attackers is reduced to the set of nodes that reported ERM i.e. X . Moreover, the above E(Y ) will give us an idea about the probability of the vehicle that reports the ERM twice or more, but we argue that if a vehicle is malicious anyways, then it will report the ERM many times with probability 1. So in order to get a better estimation of the Sybil attack, we take the estimation on the number of tokens that are received by the RSU. E(X ) gives us a threshold which defines the possible Sybil attack. It must be noted that there could be two cases that would create Sybil attack. (1) The event has not occurred and only illusion has been created as in Fig. 7. In that case, the attacker must use its legitimate tokens to report an un-occurred event. In such case, Sybil attack will be detected by RSU with high probability after checking the tokens in reported ERMs. (2) The event has occurred but Sybil attacker deliberately does not forward ERMs to the following vehicles. Hence RSU has to decide the potential Sybil attack on a threshold that is defined upon the value of E(X ) . Nonetheless, this estimation of possible Sybil attack will also include the VANET penetration rate and underlying relaying mechanism. RSU estimates the potential Sybil attack as follows: α = E (X ) + Nr elay , Nr elay = d AoI × β
(14)
α is the estimation factor, d AoI is the number of vehicles in the AoI (Area of Interest), β represents re-broadcasting probability defined by p-IVG and Nr elay is the number of relayers. For example if d AoI = 50 then β = 0.5 means Nr elay = 25, more precisely among 50 vehicles in the vicinity, only 25 will re-broadcast the ERM with probability 1. If α = dAoI + Nrelay , it means that an event has occurred and it has been reported by dAoI vehicles and relayed by Nr elay number of relayers. Hence the RSU can conclude that the probability of Sybil nodes is very low. Nevertheless, in parallel, RSU must check for tokens as well. The aforementioned case defines an upper bound for the number of ERMs. If α (d AoI + Nr elay ), then the event can be suspicious and most likely Sybil attack might have been launched. Similarly, we can define a lower bound for α if α (d AoI + Nr elay ), it means that ERMs are deliberately blocked or dropped and not re-forwarded, which also leaves RSU with suspicion. In either case, RSU checks for Sybil attack by checking the legitimate tokens. For a clear understanding, we explain the scenario with the following example. Let suppose for the sake of understanding that the VANET penetration rate is 100 %, d AoI = 100, β = 0.6, ρ = 0.75 (probability of each vehicle in d AoI that it will report the event), 1 − ρ = 0.25 . Then we have:
123
R. Hussain, H. Oh
d AoI ρ i (1 − ρ)d AoI −i = 75, we can calculate the Nrelay = 45 and E (X ) = i=0 i estimation factor as: α =120, it means that RSU received 120 ERMs and it checks for tokens in ERMs. Note that the original number of ERMs is 75 and 45 of them have been re-broadcasted. With these values, if α is intermittent from this estimation, then RSU will conclude in possible launch of Sybil attack.
d
6.6 Technical Challenges In this sub-section we outline the technical challenges for our proposed scheme. • Storage Requirements Since our proposed scheme requires multiple tokens issued per domain, an efficient storage mechanism is essential for OBUs to store tokens. With current advancements in technologies, we argue that storage might not be much of the problem for our proposed scheme. Nevertheless, TRM must make sure that a token gets deleted after it is consumed with ERM. Additionally the credentials of the vehicular nodes and backtrack information about tokens need to be stored in both BRSUs and concerned RCA. • Number of tokens A deep insight is needed to make sure that the number of tokens does not exceed to be useless and waste the storage of OBU. Morevoer the number of tokens might be different depending upon the nature of domains. Some domains might need more tokens than others. • Validity Time The validity time for the token must be short enough to avoid replay attacks and long enough to single out the malicious attacker. Such tradeoff would help in token optimization and a deep analysis is needed to find an optimal value for the validity time factor which is considered for future study. • RSU placement Placement of RSUs inside the domain, BRSUs, and the size of domain are important factors because the number of tokens would depend upon the size of the domain. Additionally the traffic density plays an important role in utilizing the resources of border RSUs as well.
7 Conclusions Sybil attacks where a malicious node creates illusions about non-exisiting nodes through masquerading or forging identities, is a nightmare for privacy-preserving VANET (Vehicular Ad Hoc NETwork). In VANET, where privacy of anonymous legitimate nodes is of prime importance, anonymous verification of those legitimate nodes is also essential. But, unfortunately most privacy-preserving schemes are vulnerable to Sybil attacks. Preventing and detecting Sybil attacks in privacy-friendly VANET environment is a daunting challenge. In this paper, we aim at Sybil attack launched through scheduled beacons (SB) and event reporting message (ERM) and propose a Sybil attack prevention and/or detection scheme for both SB and ERM. For SB, we employ TRM to perform a pre-assembly analysis on the data received from outer modules in order to assemble beacons. Whereas in case of ERM, RSUs issue authenticated tokens to the vehicles which are consumed while reporting ERMs. Our
123
On Secure and Privacy-Aware Sybil Attack Detection
proposed scheme preserves user privacy in case of both beacons and ERM by omitting the identity information from aforementioned messages and yet revocable if needed. Additionally our proposed scheme is lightweight and computationally less expensive than previous schemes. Acknowledgments This work was supported by the National Research Foundation of Korea (NRF) Grant funded by the Ministry of Education, Science and Technology (No. 2012-R1A2A2A01046986). This work was supported by the National Research Foundation of Korea (NRF) Grant funded by the Korea government (MEST) (No. 2012-R1A1A2009152). This research was supported by the MSIP Ministry of Science, ICT & Future Planning, Korea, under the ITRC (Information Technology Research Center) support program (NIPA2013-H0301-13-1002) supervised by the NIPA(National IT Industry Promotion Agency).
References 1. Chen, C., Xin, W., Weili, H., & Binyu, Z. (2009). A robust detection of the sybil attack in urban VANETs. In 29th IEEE international conference on distributed computing systems workshops, ICDCS Workshops ’09 (pp. 270–276). 2. Chenxi, Z., Rongxing, L., Xiaodong, L., Pin-Han, H., & Xuemin, S. (2008). An efficient identity-based batch verification scheme for vehicular sensor networks. In IEEE INFOCOM, The 27th Conference on Computer Communications (pp. 246–250). 3. Costa, P., Gavidia, D., Koldehofe, B., Miranda, H., Musolesi, M., & Riva, O. (2008). When cars start gossiping. In Proceedings of the 6th workshop on Middleware for network eccentric and mobile applications, ACM, Glasgow, Scotland (pp. 1–4). 4. Delgrossi, L., & Zhang, T. (2009). Dedicated Short-Range Communications. Vehicle Safety Communications: Protocols, Security, and Privacy (pp. 44–51). 5. Douceur, J. R. (2002). The sybil attack. International Workship on Peer to Peer Systems (pp. 251–260). 6. Gerlach, M., & Guttler, F. (2007). Privacy in VANETs using changing pseudonyms—ideal and real. In IEEE 65th Vehicular Technology Conference, VTC2007-Spring (pp. 2521–2525). 7. Grover, J., Gaur, M. S., & Laxmi, V. (2010). A novel defense mechanism against sybil attacks in VANET. In Proceedings of the 3rd international conference on security of information and networks, ACM, Taganrog, Rostov-on-Don, Russian Federation (pp. 249–255). 8. Grover, J., Gaur, M. S., & Laxmi, V. (2011). Sybil Attack in VANETs- Detection and Prevention (pp. 269–294). Security of Self-Organizing Networks, Taylor and Francis Group, LLC. 9. Guette, G., & Ducourthial, B. (2007). On the Sybil attack detection in VANET. IEEE Internatonal Conference on Mobile Adhoc and Sensor Systems, MASS 2007 (pp. 1–6). 10. Hussain, R., Kim, S., & Oh, H. (2012). Privacy-aware VANET security: Putting data-centric misbehavior and sybil attack detection schemes into practice. Internet Security Applications, 2012 (WISA 2012) (pp. 296–311). 11. Hussain, R., Kim, S., & Oh, H. (2009). Information security applications. In H. Youm & M. Yung (Eds.), Towards privacy aware pseudonymless strategy for avoiding profile generation in VANET (pp. 268–280). Berlin/Heidelberg: Springer. 12. Ibrahim, K., & Weigle, M. C. (2008). CASCADE: Cluster-based accurate syntactic compression of aggregated data in VANETs. In IEEE GLOBECOM Workshops (pp. 1–10). 13. Ibrahim, K., Weigle, M. C., & Abuelela, M. (2009). p-IVG: Probabilistic inter-vehicle geocast for dense vehicular networks. In IEEE 69th Vehicular Technology Conference. VTC Spring (pp. 1–5). 14. Jinyuan, S., Chi, Z., Yanchao, Z., & Yuguang, F. (2010). An identity-based security system for user privacy in vehicular ad hoc networks. IEEE Transactions on Parallel and Distributed Systems, 21, 1227–1239. 15. Leinmuller, T., Schoch, E., & Maihofer, C. (2007). Security requirements and solution concepts in vehicular ad hoc networks. Wireless on demand network systems and services, WONS ’07. Fourth Annual Conference on (pp. 84–91). 16. Levine, A. N., Shields, C., & Margolin, N. B. (2006). A survey of solutions to the sybil attack. Amherst, MA: University of Massachusetts. 17. Martucci, L. A., Kohlweiss, M., Andersson, C., & Panchenko, A. (2008). Self-certified Sybil-free pseudonyms. In Proceedings of the first ACM conference on Wireless network security (pp. 154–159). ACM, Alexandria, VA, USA.
123
R. Hussain, H. Oh 18. Papadimitratos, P., Buttyan, L., Holczer, T., Schoch, E., Freudiger, J., Raya, M., et al. (2008). Secure vehicular communication systems: Design and architecture. IEEE Communications Magazine, 46, 100–109. 19. Plößl, K., & Federrath, H. (2008). A privacy aware and efficient security infrastructure for vehicular ad hoc networks. Computer Standards & Interfaces, 30, 390–397. 20. Ruj, S., Cavenaghi, M. A., Zhen, H., Nayak, A., & Stojmenovic, I. (2011). On data-centric misbehavior detection in VANETs. IEEE Vehicular Technology Conference (VTC Fall) (pp. 1–5). 21. Scheuer, F., Posse, K., & Federrath, H. (2008). Preventing profile generation in vehicular networks. networking and communications, WIMOB ’08. IEEE International Conference on Wireless and Mobile, Computing (pp. 520–525). 22. Schmidt, R. K., Leinmuller, T., Schoch, E., Held, A., & Schafer, G. (2008). Vehicle behavior analysis to enhance security in vanets. Fourth workshop on vehicle to vehicle, communications (V2VCOM 2008). 23. Schmidt, R., Leinmuller, T., Schoch, E., Kargl, F., & Schafer, G. (2010). Exploration of adaptive beaconing for efficient intervehicle safety communication. IEEE Network, 24, 14–19. 24. Shan, C., Yong, Q., Hongzi, Z., Jizhong, Z., & Xuemin, S. (2012). Footprint: Detecting sybil attacks in urban vehicular networks. IEEE Transactions on Parallel and Distributed Systems, 23, 1103–1114. 25. Sommer, C., Tonguz, O. K., & Dressler, F. (2011). Traffic information systems: Efficient message dissemination via adaptive beaconing. IEEE Communications Magazine, 49, 173–179. 26. Soyoung, P., Aslam, B., Turgut, D., & Zou, C. C. (2009). Defense against Sybil attack in vehicular ad hoc network based on roadside unit support. IEEE Military Communications Conference, MILCOM, 2009, 1–7. 27. Tong, Z., Choudhury, R. R., Peng, N., & Chakrabarty, K. (2011). P2DAP: Sybil attacks detection in vehicular ad hoc networks. IEEE Journal on Selected Areas in Communications, 29, 582–594. 28. Wasef, A., Yixin, J., & Xuemin, S. (2008). ECMV: Efficient certificate management scheme for vehicular networks. IEEE Global Telecommunications Conference, GLOBECOM, 2008, 1–5. 29. Xiao, B., Yu, B., & Gao, C. (2006). Detection and localization of sybil nodes in VANETs. In Proceedings of the 2006 workshop on Dependability issues in wireless ad hoc networks and sensor networks. (pp. 1–8). Los Angeles, CA, USA: ACM. 30. Yipin, S., Rongxing, L., Xiaodong, L., Xuemin, S., & Jinshu, S. (2010). An efficient pseudonymous authentication scheme with strong privacy preservation for vehicular communications. IEEE Transactions on Vehicular Technology, 59, 3589–3603. 31. Yong, H., Jin, T., & Yu, C. (2011). Cooperative sybil attack detection for position based applications in privacy preserved VANETs. In IEEE Global Telecommunications Conference (GLOBECOM 2011) (pp. 1–5).
Rasheed Hussain received his B.S. in Computer Software Engineering from N-W.F.P University of Engineering and Technology, Peshawar, Pakistan in 2007 and M.S. degree in Computer Engineering from Hanyang University, South Korea in 2010. Currently he is working toward the Ph.D. degree in Computer Engineering from Hanyang University, South Korea. His main research interests include information security and privacy issues in VANET (Vehicular Ad Hoc NETworks), information dissemination in VANET, VANET applications, cloud computing, and VANET-based clouds. He is currently working on emergent VANET-based clouds. He has published several papers on VANET-based clouds and has been actively involved in framework design, mitigating security challenges in VANET-based clouds, and introducing new services in VANET-based clouds.
123
On Secure and Privacy-Aware Sybil Attack Detection Heekuck Oh received his B.S. degree in Electronics Engineering from Hanyang University in 1983. He received his M.S. and Ph.D. degrees in Computer Science from Iowa State University in 1989 and 1992, respectively. In 1994, he joined the faculty of the Department of Computer Science and Engineering, Hanyang University, ERICA campus, where he is currently a professor. His current research interests include network security and cryptography. Prof. Oh is the president of Korea Institute of Information Security & Cryptology, and is a member of Advisory Committee for Digital Investigation in Supreme Prosecutors’ Office of the Republic of Korea. He is also a member of Advisory Committee for Internet Security under Korea Communications Commission.
123
