Maintaining Location Privacy and Anonymity for Vehicle's Drivers in

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012)

Maintaining Location Privacy and Anonymity for Vehicle’s Drivers in VANET Eng. Marvy Mansour1, Prof. Ahmed Fahmy 2, Prof. Mohammed Hashem3 1, 2

Computer Engineering Department, Arab Academy for Science and Technology and Maritime Transport, Egypt 3 Vice Dean, College of Computing and Information Technology, Ain Shams University, Cairo, Egypt

Abstract — Vehicular Ad-hoc Network (VANET) is an emerging technology that aims at providing both safety and comfort for drivers. One of the most important evolving VANET applications is Location-Based Services (LBS). These applications require providing continuous user location updates to untrusted Location-Based Service Providers (SPs), in order to provide real-time services. However, this leads to tracking and identification of users, and thus breaching privacy of vehicle drivers. In this paper, we propose a solution that maintains location privacy of a user and anonymity when using real-time applications, while taking into consideration constraints posed by VANET. Our scheme uses group navigation combined with the use of mobility prediction and prospective path confusion, in order to mitigate tracking of vehicles and provide real-time anonymization for drivers. Besides that, we propose an “n-1 key forwarding mechanism” that is used for secure and private renewal of vehicle's key pairs. In addition, we provide a “Blind LBS Provider” in our approach that has zero-information about a vehicle and blindly provides a service to a vehicle. In our solution, we also provide a variety of techniques to enhance security and privacy of vehicle’s driver that include: timestamps, Reqmask, message signing and encryption. Moreover, our scheme offers additional benefits to vehicles, and provides a variety of security services while avoids well-known attacks in VANET. Our approach provides protection against both internal and external adversaries. Finally in this paper, we analytically evaluated our work using different location privacy metrics and simulated our scheme. Results showed that our solution is applicable and capable of providing realtime location privacy for vehicle drivers without loss of availability or accuracy of LBS applications. Thus, breaking the zero-sum game between privacy and Quality-of-Service (QoS).

In addition, vehicles can access location-based services LBSs used for driver's comfort via Roadside infrastructure (RSU). For example, the service may be a query by a vehicle to find the nearest gas station to its location. Despite that these applications facilitate driving to users; however they directly threaten user's privacy [1]. This is because these applications are untrusted while require accurate, continuous and real-time stream of user’s location data to provide real-time service availability and accuracy without delay [3]. Therefore, these applications can continuously monitor the user's locations [2]. In addition, in the presence of a global passive adversary, this may lead to tracking of vehicle and identification of its driver. Thus, strong privacy protection mechanisms [4, 5, 6, 7, 8, 9] are needed to be implemented in order to overcome these privacy risks [39]. Most of the previous approaches focus either on maximizing the user’s location privacy and anonymity, or on providing real-time services to users. On the other hand, some works takes into consideration these issues but they either rely on a third party that could be untrusted or put more burden on vehicles and system [10, 11]. While others do not take into account VANET constraints [38], such as: dynamic network topology and sporadic relation between vehicles, a rotating role of group leader, and variable vehicle’s address (pseudonym) [12]. Thus, there is no applicable way to our knowledge so far that provides real-time location privacy to users of real-time applications, while taking into consideration the tripod of constraints that is: (1) maintaining user real-time location privacy and anonymity, (2) providing real-time services with continuous service availability, (3) taking into account VANET constraints. In this paper, we studied the problem of preserving location privacy and anonymity for a vehicle user while using LBS applications in the presence of a global passive adversary. We propose a solution that maintains the user’s location privacy and anonymity when accessing real-time applications. For developing a suitable solution, unlike existing approaches for location privacy in VANET, our approach accounts for the previous tripod of constraints.

Keywords — Location Privacy; Anonymity; Location-Based Services; Real-time Applications; Quality-of-Service (QoS); Group Navigation; Mobility Prediction; Path Confusion; Location Privacy Metrics; Entropy.

I. INTRODUCTION Vehicular ad-hoc networks contribute to both safer driving conditions and more efficient traffic management. They allow vehicles to share safety-related information with each other, e.g.: safety warnings which are referred to as safety applications. 8

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) Contributions of this paper are as follows. Our Location Privacy Protocol is divided into 3 Phases: First, Phase I of our protocol is Initialization Phase: which is divided into 3 main parts. Part A is Vehicle Registration: that shows how a vehicle can register in Governmental Authority GA in order to obtain its key pairs. Then, Part B is Key Renewal: that shows using an “n-1 key forwarding mechanism” how vehicle's key pairs are being renewed in a secure and private way. While Part C: explains how a vehicle can obtain historical matrix needed for path prediction process and application address range used to select an application by a vehicle. Second, Phase II of our protocol is Sending an Application Request by a vehicle to service provider of needed application, in Steps (1-4). In this phase we use group navigation combined with the use of mobility prediction and prospective path confusion. A vehicle in a group does mobility prediction, and then sends an application request along with its predicted path to its group leader using the application address as its source address. Later, the group leader does prospective form of paths intersection to create prospective path confusion, and then forwards via RSU and location server the series of posteriori intersected paths to LBS provider of needed application. Third, Phase III of our protocol is Receiving a Reply to a Request: explains how a reply to request sent is received by a vehicle from LBS provider, in Steps (5-7). In this phase, we provide a “Blind LBS Provider” that has zero-information about a vehicle and provides a service blindly to vehicle. In addition, throughout all phases of our protocol, we have used a variety of techniques to enhance the secure and privacy of a vehicle’s driver such as: timestamps, Reqmask, message signing and encryption. Finally, we show by means of simulation that our solution is capable of achieving location privacy and anonymity to drivers; while using real-time applications without degradation in QoS. The rest of the paper is organized as follows. In Section II, we describe VANET System Model and Threat Model considered in our work. Then, in Section III, we present previous location privacy techniques in VANET. While in Section IV, we demonstrate the 3 phases of our proposed location privacy approach. Whereas in Section V, we analyze the security and privacy achieved by our solution.

In Section VI, we analytically evaluate performance of our proposed solution and simulated our work, then discussed results obtained. Finally, we concluded the paper in Section VII. II. VANET SYSTEM MODEL AND THREAT MODEL In this section, we describe the system model and threat model in VANET, which we are going to consider throughout the paper. A. VANET System Model Vehicular ad-hoc networks allow vehicles to communicate with each other known as Vehicle-to-Vehicle (V2V) communications. Also, VANETs allow vehicles to communicate with road-side infrastructure known as Vehicle-to-Infrastructure (V2I) communications. VANET uses Dedicated Short Range Communications (DSRC) [13] for V2V and V2I communications, which are illustrated in Fig. 1. Fig. 1 illustrates a typical VANET system model that consists of: vehicles, access points, location servers, and other backbone servers. Vehicles are enabled with: on-board communication unit known as OBU for V2V & V2I communications, a Global Positioning System GPS device for providing accurate location information, and database units to store environmental information such as: location and speed. In addition, vehicles are equipped with a Tamper Proof Device TPD which is responsible for performing all cryptographic operations such as signing outgoing messages, and also the storage and non-disclosure of cryptographic materials e.g.: private keys. TPD has restricted access and come with its own battery and clock [14, 15]. Moreover, each vehicle has its own unique identifier, such as: Electronic License Plate (ELP) that is issued by an authority [16, 17]. Access points are placed on road sides and their communication unit is called Road Side Units (RSU). Location servers record all location data forwarded by the RSUs, and process all data together received from other data sources, e.g. police and traffic management center. Also, location servers provide an interface for the location-based Service Providers (SPs). All servers are accessible by vehicles via RSUs, where RSUs are connected to servers by a wired network.

9

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) In addition, before joining VANET, each vehicle, RSU & LBS provider have to register with Governmental

LBS could be either considered trusted LBS & untrusted LBS [10]. Trusted LBSs require that the user identity to be revealed, e.g.: banking applications. While, untrusted LBSs could be used without revealing user identity. In this work, we present a scheme that reserves the user’s location privacy and anonymity against untrusted LBS. Furthermore, we consider using location-only service structure [10] in this paper, which is a method to structure services such that only the user’s location is needed to be sent to the desired LBSs. This is an effective way as the user doesn’t need to reveal any other private information to the untrusted LBS other than the GPS coordinates. 2. Group Navigation: Applying Group Concept in our Scheme: In VANET, the mobility of vehicles is spatially restricted and spatially dependent. Therefore, vehicles in geographical proximity move with the same average velocity due to the spatial dependency, and also move with similar direction due to the spatial restrictions, over a period of time. Thus, vehicles in geographical proximity can navigate as a group, which is referred to as Group Navigation. For a vehicle to be in a group, we restrict that each group member should hear broadcasts of every other group member. Moreover, since vehicles in a group move relative to each other and on average have the same velocity, a group can be represented by a single vehicle called the Group Leader GL, as shown in Fig. 2. Note that every group leader broadcasts its current public key PuGL received from GA, as will be shown in Part A of Phase I in Section IV, to all its group members. For more details about Group Navigation protocols refer to [12] as they are out of scope of this paper. However, protocols in [12] may not be applicable in real situations as mentioned in [22]. Benefits of using Group Navigation in our Protocol: By using vehicular groups, we offer the following benefits that are clarified in Phase II in Section IV of our protocol. (1) Group leader (e.g. GLx) is used to intersect together the received predicted paths of vehicles in its group, before sending them to RSU. (2) The series of posteriori intersected paths will create prospective form of path confusion to both internal and external adversaries. (3) Prospective Path confusion will mitigate tracking of a vehicle by an adversary and reserves both driver’s location privacy and anonymity. (4) No direct communication between vehicle that requested the application and RSU as GL acts as an intermediate entity, which increases privacy and anonymity of driver.

Fig.1. Illustration of a typical VANET System Model.

Transportation Authority (GA). GAs are fully trusted third parties operated by governmental organizations that apply privacy policies. They provide authentication and authorization services to registering entities, as will be shown in Section IV. Similarly as previous works in [4, 5, 6, 8, 18, 15], we assume that a suitable Public Key Infrastructure PKI is available in VANETs. VANETs are a challenging application of ad-hoc networks due to the presence of a highly dynamic mobile environment. In addition to the VANET constraints that are mentioned in Section I, the mobility of vehicles also poses other challenges due to its unique characteristics. This is because the movement of vehicles is spatially restricted i.e. vehicles are restricted to move in lanes and have no free random motion. Also, vehicles are spatially dependant on each other in movement, i.e. must keep a minimum safety distance from each other. Moreover, vehicles while moving on roads, share collective environmental information with each other and with servers via RSUs. VANETs present various functionalities in terms of vehicular safety; traffic congestion reduction and LBS applications. We consider LBS applications, a typical class of VANET applications in this paper, which will be discussed below. 1. Location-based Applications: LBS applications deliver information to users based on their current location. Examples of LBS applications include: MicroBlog, where users exchange location-based queries and answers about surrounding conditions [19]. Geolife is another example, that provides a location-based to-do system, e.g. when a user passes by a shopping mall, Geolife displays the user’s “shopping list” in real-time for the user [20]. 2. 10

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) Moreover, these trails could connect specific locations to specific individuals, which may lead to real identity of user known as user identification that will be discussed in Part B.2 of this section. On the other hand, an external adversary installs its own radio receivers near the road network, in order to overhear the vehicle’s transmissions [5]. A global passive adversary (e.g. “Big Brother” surveillance [15, 33]) is an adversary that is able to overhear all the transmissions of all the vehicles and other network entities, and so could estimate vehicle’s locations. Thus, this may lead to tracking of the vehicle, which can also reveal private information of the driver. In this paper, unlike previous works, we are concerned with achieving location privacy against both an internal adversary and an external adversary. This is in order to mitigate vehicle tracking and user identification, and thus preserving user’s location privacy and anonymity as well. 1. Privacy and Security Requirements in VANET: Privacy requirements [23, 38] are essential in order to establish a suitable privacy protection mechanism in VANET. In this paper, we are going to mention some of these requirements, which are:

Fig.2. Illustration of Group Navigation in VANET.

B. Threat Model VANETs allow the tracking of vehicles for different reasons. First, vehicle transceivers cannot be switched off [7] unlike mobile phones and wireless adapters, so vehicles could be monitored all times. Second, an eavesdropper could obtain private information such as user’s location and other data contained in messages sent by vehicles. Thus, an adversary could estimate from mobility traces obtained significant information about driver, such as: driver’s activity, workplace and home, which leads to revealing his real world identity [21]. An adversary could either be internal or external. An internal adversary uses devices of legitimate members of VANET [4, 8] as will be discussed. RSUs and location servers are semi-trusted entities as shown in Fig. 3, because they could be used to passively monitor locations of a vehicle. Since an adversary may deploy compromised vehicles in the network, therefore vehicles are untrusted entities [22]. In addition, LBS providers are untrusted entities that continuously monitor vehicle’s locations. This is because frequent location updates sent to LBS provider creates trails of transmitted locations that allows untrusted LBS to easily follow the user’s path and hence tracking the user.

1) Anonymity: A sender of a message should be anonymous or indistinguishable within a set of potential senders, in order to create uncertainty for any adversary that tries to determine message’s origin. In addition, it should not be possible to link a message to a sender based on message content, known as sender anonymity. Moreover, an anonymity set of a message m contains all vehicles that are equally likely to have sent m. While in our work, an anonymity set of a user path p contains all vehicles that are equally likely to have path p, which is equal to (size of an anonymity set) the total number of intersected paths as will be clarified in Section IV. 2) Unlinkability: It includes: (a) Unlinkability of a sender to a message which is equivalent to sender anonymity. (b) Unlinkability of a message to its originator which is referred to as untraceability. (c) Unlinkability of consecutive messages sent from the same vehicle which is the ability to avoid tracking. 3) Minimum disclosure: The amount of information that a user reveals during communication should be kept to

11

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) While in identification attack, the adversary wants to discover the real identity of a user, based on the adversary's knowledge of the linkability of the user to sensitive areas such as home or work place [21, 25, 26]. The success of each of these two attacks paves the way for the other, that is tracking a user may lead to its identification and viceversa. Generally, users aim to prevent other entities from making an identity-location binding that is the ability to tell that a specific user has been to a specific location. Moreover, location tracking of a vehicle enables the identification of the LBS application accessed at any location, which results in profiling of the LBS applications visited by a vehicle user [22]. Thus, inferring of personal interests of a vehicle user, which breaches the user’s privacy. 3. Macroscopic and Microscopic Location Privacy: In order to develop a suitable location-privacy preserving mechanism, we should go through the levels of location privacy that are present, which are: macro and micro levels [24]. Microscopic location privacy is the user's privacy on a small scale, for example at the time an event is related to a given user is observed. While macroscopic location privacy is the user's privacy level throughout his trajectory or followed path. In this paper, we focus on providing macroscopic location privacy for a user throughout his followed path. We use uncertainty-based metrics such as entropy-based metrics [24] to measure how accurately the adversary can track a user throughout his path (i.e. tracking attack), as will be shown in Section V.

Fig.3. Illustration of a VANET System Model with Threat Model considered.

The minimum that is no more information than required for normal functionality of applications is revealed. In this paper we use Location privacy which is defined as: a particular type of information privacy that refers to as the ability to prevent other entities from learning one’s current or past location [31], which could be used to track a vehicle. In addition to privacy requirements that are mentioned above, there are also security requirements [41] that should be taken into consideration in VANET. Some of these include:

III. BACKGROUND AND RELATED WORK

1) Authentication: It includes both sender authentication and message integrity. It establishes a degree of trust between entities via sender authentication. Also, it facilitates the establishment of trust in received information through message integrity.

There have been many different existing approaches [39, 40] that are proposed for achieving location privacy. We will discuss some of them in this section, and identify the benefits and consequences of each approach. First, we will discuss K-Anonymity approach [27]. This technique ensures that the user cannot be individually identified from a group of k users. This can be achieved by reporting k users, forming k-anonymous region, instead of sending a single user location. However, this technique forces some users to wait until at least k different users are available to achieve enough anonymity [28]. Therefore, this delay reduces the quality of the user’s localization in time and space which compromises real-time service availability and accuracy. Thus, this approach doesn’t protect location privacy of users in case of real-time services [36] and also in low user density areas.

2) Accountability : It is required for holding individuals accountable and assigning liability. It implies nonrepudiation of sender that is sender of a message cannot deny having sending it. 3. Tracking versus Identification Attacks: The two main well-known attacks on user’s location privacy are tracking and identification [24]. In tracking attack, the adversary goal is to reconstruct the user’s actual trajectories to identify the locations that the user has visited and also to predict the future locations of user, in order to discover the whole path followed by a user from origin to destination.

12

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) Using Pseudonyms or changing identifiers [15, 44] is another approach, which has been proposed to decorrelate the identity of a vehicle from its locations, as each new location is sent with a new pseudonym. Also, its purpose is to achieve unlinkability between the vehicle and its pseudonyms. On the other hand, updating vehicle pseudonym is not effective as location information included in some messages can be still used for tracking [37]. In case of real-time services, frequent updating of pseudonyms is needed that creates a trail of transmitted locations, and thus allowing an SP to monitor user’s locations [29, 30]. One of the well known schemes is Mix-Zones [31]. A mix zone, as shown in Fig. 4a, takes place when two or more users are present on the same place called an intersection and at the same time [10]. Anonymization only occurs after users enter an intersection, where their paths intersect with each other. This is because at an intersection, paths are coincided with each other in space and time. Thus, the users’ paths become indistinguishable to external adversary, as adversary cannot determine where the users have gone after exiting the point of intersection and so cannot follow them. Despite that, this scheme doesn’t provide anonymity in practical situations, as it is very common that users’ paths intersect at different times rather than at the same time. Thus, it cannot be used in sparse systems for this reason. An extension of Mix-Zones is Path Confusion [32], which resolves the same-place same-time problem of Mix-Zones. In this method, if a user passes through an intersection, a delay happens until at least one other user passes through the same point of intersection as shown in Fig. 4b. After that, users’ locations can be sent to SP after ensuring confusion at SP [10]. Similarly as k-anonymity, this delay compromises real-time services. Another similar idea to Path Confusion called CacheCloak [10] was proposed to solve the delay problem caused by path confusion and other approaches. This technique relies on a trusted server that generates mobility predictions from historical data. By using mobility prediction, this approach can do a prospective form of path confusion. Each new predicted path is extended until it intersects with other predicted paths which create a series of intersected paths that are sent to an SP and thus creating confusion at SP.

Fig.4a. A Mix-Zone where two (or more) users will meet on the same place called an intersection and at the same time t0.

Fig.4b. A user passes an intersection at time t0 waits for tdelay until another user passes at the same place at time t, after which Path Confusion is created.

Therefore, this scheme doesn’t incur any delay in order to provide anonymity for users, and so can be used for realtime services. However, this technique relies on a central server which may imply many consequences. One of the most drawbacks is that the server is a single point of failure and so if it crashes, all users wouldn’t be able to access any service. Also, if this server could fail to be trusted, all users would be easily monitored through it. Thus despite the benefits of this approach, yet it has many consequences that renders its applicability in real situations. In addition to all of the above approaches, there are some other approaches that use Group Navigation [34, 35, 38] to provide anonymous access to LBS applications [12, 22]. However, these techniques exhibit alot of drawbacks as will be discussed. First, these techniques rely on a single group leader that presents a single point-of-failure for group members to access services. Second, the use of group leader (GL) as a proxy for LBS access presents lack of end-to-end connectivity between the LBS provider and group members due to high mobility of vehicles.

13

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) Third, the GL waits till it receives enough requests from group members needed for mixing before forwarding them, which incurs latency in LBS access and compromises realtime services. Besides, the same GL must be available at the time the service reply arrives as it only knows the order of mixing of requests. From the previous drawbacks, it is clearly noticed that these techniques mainly assume that the same GL would still exist at the time the service reply comes, which is not realistic. This is due to high mobility of vehicles and rapidly changing network topology that causes this GL to become out of range of other group members before receiving the reply. Moreover, the role of GL is rotated among all group members and so GL of a certain group is frequently changed. To sum up, it is clear that these approaches take the perspective that privacy and functionality compromise a zero-sum game, where one is traded for the other. This causes reduced functionality such as degraded spatial accuracy or increased delay in reporting the user’s locations. Unlike the previously discussed approaches, our work accounts for all of the above challenges. First, we provide in our solution real-time location privacy and anonymity for vehicle drivers which mitigate tracking of a vehicle, when using real-time LBS applications without compromising real-time service availability and accuracy. Second, we apply group navigation in our work, while taking into consideration VANET constraints, such as: dynamic network topology and sporadic relation between vehicles, a rotating role of group leader, and variable vehicle’s address (pseudonym). Third, as will be clarified in the next section, we propose a protocol that creates a prospective form of path confusion without incurring any delay or other previously discussed limitations. Finally, unlike previously discussed approaches, we have used a variety of techniques that offer additional benefits to vehicles and provide a variety of security services, while avoid well-known attacks in VANET.

While Phase II: Sending an Application Request, Steps (1-4) in Fig. 5, gives the details of sending an application request by a vehicle to service provider of needed application. Then Phase III: Receiving a Reply to a Request, Steps (5-7) in Fig. 5, explains how the reply to request sent is received by a vehicle from service provider of needed application. Finally, after explaining all 3 phases in details, we will give a short summary of Steps in Phases II and III. A. Phase I: Initialization Phase The primary phase of our protocol is the Initialization Phase, which is divided into 3 main parts. First, Part A of this phase is Vehicle Registration that shows how a vehicle can register in GA in order to obtain its key pairs. While Part B of this phase is Key Renewal that consists of 4 steps, shows using an “n-1 key forwarding mechanism” how vehicle’s key pairs are being updated. Finally, Part C of this phase consists of 4 steps, which shows how a vehicle can obtain historical matrix needed for Path Prediction Process and application address range used by vehicle to select an application as will be shown in Phase II. 1. Part A: Vehicle Registration: In this part, each vehicle should register with a trusted Governmental transportation Authority (GA), before joining VANET [12]. During registration, vehicle i is preloaded with a set of n pseudonyms Psi, j 1 ≤ j ≤ n, a public/ private key pair PuPs(i, j) / PrPs(i, j) and a corresponding public key certificate signGA(PuPs(i, j)) for each pseudonym j, as well as public key of GA PuGA. Only trusted GA knows link between the real identity of a vehicle and its associated set of pseudonyms. A vehicle uses its pseudonyms as its source address, when sending messages for V2V or V2I communication. While, a vehicle uses its public key for encrypting messages, its private key for signing messages and its public key certificate for sender authentication. Furthermore, for each new message a vehicle changes its source address by using a new pseudonym. This is done in order to provide unlinkability of consecutive messages sent from the same vehicle, which mitigates tracking of a vehicle as discussed in Section II.B.1. Note that each RSU and LBS provider should also register with trusted GA before joining VANET [22], in order to obtain their own public/ private key pair and public key of GA PuGA. Moreover, RSU broadcasts its current public key PuRSU received from GA to all vehicles (including vehicle i) within its transmission range.

IV. PROPOSED LOCATION PRIVACY APPROACH In this section, we will discuss our Proposed Location Privacy Approach, which is divided into 3 phases. Phase I: is the Initialization Phase that is needed before performing the other 2 phases. It is divided into 3 main parts, which are: Part A: Vehicle Registration, Part B: Key Renewal via an “n-1 key forwarding mechanism” that consists of 4 steps, and Part C: Obtaining Historical Matrix/ Application Address Range by a vehicle that contains 4 steps.

14

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) 2. Part B: Key Renewal via an “n-1 key forwarding mechanism”: In this part, vehicle’s key pairs are renewed after all the keys have been used or their lifetime have expired [15]. We require that at least one of the stored n key pairs should be still valid so that it can be used in the key renewal process. These key pairs are renewed by GA via RSU using an “n-1 key forwarding mechanism”, that will be explained in details in the steps below:

In Step 1 as shown in (1), vehicle i sends an encrypted message to RSU, that contains identityi, PuPs(i, j), signGA(PuPs(i, j)), key_reqi, Reqmask and T1 along with Reqmask. This message indicates the time at which the key request message has been sent from vehicle i to RSU. The purpose of this message is to enable vehicle i to obtain 1

||: concatenation

a new set of key pairs from GA via RSU. Since it is required that only GA sees the identity of vehicle i identityi, PuPs(i, j) and signGA(PuPs(i, j)), they are all encrypted with public key of GA PuGA. This is done to avoid identification of vehicle's driver, as only GA knows link between identityi and new set of key pairs issued by GA to vehicle i (as will be shown in (a) (3)). Thus, preserving driver's privacy, while avoiding masquerade and replay attacks [15] as well as limiting traffic analysis [17]. Not only that, but also preventing identification of driver that may lead to tracking of a vehicle (as discussed in Section II.B) and so maintaining location privacy and anonymity for vehicle’s driver. Timestamps are used here to provide a variety of security services that include: (1) ensuring non-repudiation of sender or receiver, (2) providing accountability in some cases, (3) avoiding replay attacks. On the other hand, Reqmask is used to hide key_req i as it masks key_reqi when sending it from vehicle i to RSU, and also in case of denying key_reqi. In case of sending key_reqi, key_reqi is encrypted with public key of receiver, while Reqmask is sent along with message without encryption. Therefore, any adversary or observer of message can only see Reqmask and will not be able to see the encrypted key_reqi. While in case of sending a deny of key_reqi, key_reqi is not sent and instead Reqmask is only sent in a signed message by sender. Only vehicle i that generated Reqmask knows the link between key_req i and the corresponding Reqmask. Therefore, an adversary cannot identify the type of request since it is contained only in key_reqi, which conserves user's privacy. In addition, Reqmask can be used to provide a variety of security services (as will be clarified in the following steps), which include: (1) ensuring integrity of received message, (2) increasing confidence of sender that message was sent to correct recipient, (3) increasing trust in received message by ensuring that it was sent from the correct entity that is sender authentication, (4) providing a challenge/ response means between communicating entities and thus avoiding replay attacks [35].

Step 1: In Step 1 of this part, vehicle i sends a key request message to RSU in order to obtain a new set of key pairs from GA via RSU. The request message is sent using one of the valid pseudonyms of vehicle i numbered j Psi, j that was obtained during Vehicle Registration in Part A of this phase as a source address. Vehicle i needs to send one of its valid PuPs(i, j) to GA via RSU as shown below in (1), so that GA can send privately the new set of key pairs to vehicle i by encrypting them with received PuPs(i, j) as will be shown later in (3). Therefore, this request message should include: PuPs(i, j) and signGA(PuPs(i, j)) for Psi, j, which is used as vehicle’s source address as shown in (1). Benefits of using this mechanism include: (1) increasing driver's privacy, (2) preventing masquerade and replay attacks as well as may limit traffic analysis, (3) avoiding disclosure of pseudonyms of a vehicle, (4) preventing linkability of consecutive messages sent from the same vehicle (using the disclosed pseudonyms), (5) preventing tracking of a vehicle, (6) preserving driver's location privacy and anonymity. Vehicle i generates the key request message that includes the following: Vehicle i RSU: EPu(GA)[identityi PuPs (i, j) 1

signGA(PuPs(i,j) )

key reqi]

EPu(RSU)[key reqi Reqmask T1] Reqmask (1) Identityi: a unique identifier of vehicle i (as discussed in Section II.A). PuPs(i, j): public key of one of pseudonyms of vehicle i, numbered j Psi, j. signGA(PuPs(i, j)): a public key certificate from GA which is public key PuPs(i, j) signed by GA to indicate that PuPs(i, j) was issued by GA. key_reqi: a key request sent by vehicle i in order to obtain a new set of key pairs. Reqmask: a random number that corresponds to key_reqi that is used to hide key_reqi. T1: a timestamp that indicates the time at which key request message is sent from vehicle i to RSU. identityi, PuPs(i, j) and signGA(PuPs(i, j)) are all encrypted with public key of GA PuGA. While key_reqi, Reqmask and T1 are all encrypted with public key of RSU PuRSU.

15

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) Step 2: In Step 2, RSU decrypts the received message from vehicle i with its private key corresponding to public key PuRSU that was used by vehicle i to encrypt message. Then, RSU checks the validity of T1 and that Reqmask sent along with message is same as decrypted Reqmask, in order to verify security services provided by Reqmask and timestamps (T1) that are explained in Step 1. If decrypt and checks are valid, RSU will generate the following message, which includes:

Any other vehicle will discard the received message, since it doesn't know Reqmask included in message is for which request as it didn't generate this Reqmask. Here, there is an interesting issue that needs to be highlighted. The issue is that broadcasting deny message to all vehicles within RSU transmission range including vehicle i, rather than sending it specifically to vehicle i is very beneficial. This is because vehicle i changes its address (pseudonym), for example when sending other requests or broadcasting safety messages needed for safety applications. So, RSU needs to be updated with the recent address of vehicle i that has sent the key request message in (1). Thus, using this method, we can cope with VANET challenges such as: variable vehicle address (pseudonym).

RSU  GA: EPu(GA) [ identityi PuPs (i, j) signGA(PuPs (i, j)) key reqi ] Reqmask T2 signRSU(Reqmask,T2) (2) T2: a timestamp that indicates the time at which message is sent from RSU. signRSU(M): the whole message M is signed by RSU. Other components of above message in (2) are same as those used in message in (1). In this step as shown in (2), RSU forwards to GA the encrypted message (with PuGA) which includes key_reqi, that it has received from vehicle i in (1). In addition, RSU sends a signed message to GA that contains Reqmask and T 2. On the other hand, if decrypt or check performed by RSU on the received message from vehicle i is not valid, RSU will generate the following deny message instead of the above message in (2): RSU  Vehicleall: deny reqi Reqmask T2 signRSU(deny reqi, Reqmask, T2)

Step 3: In Step 3, GA verifies signature of received message in (2) to make sure that it was sent by RSU. Also, it checks the validity of T2 to verify security services provided by timestamps (T2) discussed in Step 1. Then, GA decrypts the received message from RSU with its private key corresponding to public key PuGA, that was used by vehicle i in (1) to encrypt message. After that, GA verifies identity of vehicle i identityi and also checks that PuPs(i, j) was issued by it to vehicle i through verifying its own signature signGA(PuPs(i, j)) included in received message in (2). If decrypt and checks are valid, GA will generate the following message: GA  RSU: Replyi { EPu

(2)

Ps(i, j)

[ ( Psi, j PuPs(i, j) PrPs(i, j)

signGA(PuPs(i, j)) )j= 1 to n lifetime ] Reqmask } T3 signGA(Reqmask, T3) (a) (3)

Vehicleall: all vehicles that are within RSU transmission range. deny_reqi: deny of request message that was sent by vehicle i in (1). Other components of above message are same as those used before. In the above case, RSU broadcasts a signed message to all vehicles that are within its transmission range including vehicle i, which contains deny_reqi, Reqmask and T2. The purpose of this message is to inform requestor (vehicle i) that its request message has been denied, so that it can send another key request message as shown in (1). When vehicle i receives the above message, it verifies signature of message to make sure that it was sent by RSU. Also, it checks the validity of T2 in order to verify security services provided by timestamps (T 2) that were discussed in Step 1. Only vehicle i that knows the relation between Reqmask sent in deny message and key request. Therefore, despite that message is broadcasted to all vehicles within RSU transmission range, only vehicle i can know deny sent in message is for which request. Thus, hiding key request of vehicle i with Reqmask which preserves driver's privacy.

Replyi: a reply from GA to key_reqi that was sent by vehicle i to RSU in (1), and forwarded to GA via RSU in (2). Psi, j= 1 to n: n pseudonyms of vehicle i, from j= 1 to n. (PuPs(i, j) / PrPs(i, j) and signGA(PuPs(i, j)))j= 1 to n: public/ private key pair and the corresponding public key certificate for each pseudonym of vehicle i, from j =1 to n pseudonyms. lifetime: indicates lifetime of each of: n pseudonyms, public/ private key pairs and their corresponding public key certificates. T3: a timestamp that indicates the time at which message is sent from GA to RSU. signGA(M): the whole message M is signed by GA. (Psi, j, PuPs(i, j) / PrPs(i, j) and signGA(PuPs(i, j)))j= 1 to n and lifetime are all encrypted with public key PuPs (i, j) of one of pseudonyms of vehicle i numbered j Psi, j. While Reqmask and T3 are signed by GA. Other components of above message are same as those used before.

16

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) In Step 3 as shown in (3), GA sends an encrypted message to RSU, that contains (Psi, j, PuPs(i, j)/ PrPs(i, j) and signGA(PuPs(i, j) ))j= 1 to n and lifetime. The purpose of this message is to issue vehicle i a new set of key pairs from GA via RSU. Since it is required that only vehicle i sees the previous content of message as it contains very private information of vehicle i, GA encrypts the message with public key PuPs (i, j); that was included in the received message by GA in (2). As discussed before in Step 1, there are many advantages gained when sending privately the new set of key pairs to vehicle i using the previous method. In addition, GA sends a signed message to RSU that contains Reqmask and T3. On the other hand, if decrypt or check performed by GA on the received message from RSU is not valid, GA will generate the following deny message instead of the above message in (3): GA  RSU : Replyi { deny reqi Reqmask } T3 signGA(deny reqi, Reqmask, T3)

Also, it checks the validity of T4 in order to verify security services provided by timestamps (T 4) that were discussed before. Only vehicle i that know the relation between Reqmask included in Replyi and key request. Therefore, despite that message is broadcasted to all vehicles within RSU transmission range, only vehicle i can know the Replyi is for which request. Thus, hiding key request of vehicle i with Reqmask, which preserves user’s privacy. Any other vehicle will discard the received message, since it doesn't know Reqmask in message belongs to which request as it didn't generate this Reqmask. In addition, broadcasting reply message to all vehicles (including vehicle i) within RSU transmission range, rather than sending it specifically to vehicle i is very effective as indicated before in Step 2. Then, if previous checks are valid, only vehicle i can decrypt the received message using its private key corresponding to PuPs (i, j); that was used by GA to encrypt message included in Replyi as shown in (a) (3). If decrypt is valid, vehicle i will store all the components of the decrypted message in its TPD that were received from GA via RSU, which are: (Psi, j, PuPs(i, j)/ PrPs(i, j) and signGA(PuPs(i, j) ))j= 1 to n and lifetime. On the other hand, if Replyi includes a deny message as shown in (b) (3), vehicle i can send another key request message as in (1). Moreover, if vehicle i didn't receive a Replyi from GA via RSU within Treply, it can resend another key request message as in (1).

(3)

Deny_reqi: deny of request message that was sent by vehicle i to RSU in (1), and forwarded to GA via RSU in (2). Other components of above message are same as those used before. In the above case, GA sends a signed deny message to RSU that contains deny_reqi, Reqmask and T3. The purpose of the above message is to inform vehicle i (as will be shown in Step 4) that its request has been denied, so that it can send another request message as in (1).

3. Part C: Obtaining Historical Matrix/ Application Address Range: In this part, we will show in the following steps how a vehicle can obtain historical matrix from location server, which contains vehicular traces that represents users’ behaviour on road. Historical matrix is needed by vehicle i for path prediction process [10] as will be shown in Phase II. In addition, we will show how a vehicle can obtain application address range from GA, which is used by vehicle i to select an application as will be clarified in Phase II.

Step 4: In Step 4, which is the last step in Part B of Phase I, RSU verifies signature of the received message in (3) to make sure that it was sent by GA. Then, RSU checks the validity of T3 to verify security services provided by timestamps (T3) that were mentioned in Step 1. If checks are valid, RSU will generate the following message: RSU  Vehicleall: Replyi T4

signRSU(Replyi, T4)

(4)

T4: a timestamp that indicates the time at which message is broadcasted from RSU. Other components of above message are same as those used before. In this step, RSU broadcasts a signed message to all vehicles that are within its transmission range including vehicle i that contains Replyi and T4. The purpose of this message is to forward Replyi to vehicle i, which includes the new set of key pairs for vehicle i that RSU has received from GA in (a) (3). When vehicle i receives the message in (4), it verifies the signature of message to make sure that it was sent by RSU.

Step 1: In Step 1 of this phase, vehicle i sends a historical matrix request and application address range request in a message to RSU, as shown in (1). The request message is sent using one of pseudonyms of vehicle i numbered j Psi, j as a source address. Vehicle i generates the request message that contains the following: Vehicle i  RSU: Historicalmatrix Reqi Appaddressrange Reqi Reqmask1 Reqmask2 EPu(RSU)[ Reqmask1 Reqmask2 ] T1 17

(1)

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) RSU  GA: Appaddressrange Reqi Reqmask2 T2 signRSU(Appaddressrange Reqi, Reqmask2, T2) (b) (2)

Historicalmatrix_Reqi: a historical matrix request sent by vehicle i. Appaddressrange_Reqi: an application address range request sent by vehicle i. Reqmask1: a random number that corresponds to Historicalmatrix_Req i which is used to hide Historicalmatrix_Reqi. Reqmask2: a random number that corresponds to Appaddressrange_Req i which is used to hide Appaddressrange_Reqi. T1: a timestamp that indicates the time at which request message is sent from vehicle i to RSU. Reqmask1 and Reqmask2 are encrypted with public key of RSU PuRSU. In Step 1 as shown in (1), vehicle i sends a request message that contains Historicalmatrix_Reqi, Appaddressrange_Reqi, Reqmask1, Reqmask2 and T1 along with encrypted Reqmask1 and Reqmask2. This message indicates the time at which request message is sent from vehicle i to RSU. The purpose of this message is to enable vehicle i to obtain both historical matrix from location server and application address range from GA via RSU. Timestamps are used here similarly as Part B, to provide a variety of security services that will be clarified in the following steps. On the other hand, Reqmask1 and Reqmask2 are used to hide (mask) Historicalmatrix_Reqi and Appaddressrange_Reqi respectively. In case of sending a deny of Historicalmatrix_Reqi or Appaddressrange_Reqi, these 2 components are not sent and instead Reqmask1 or Remask2 is only sent in a signed message by sender. Only vehicle i that generated Reqmask1 and Reqmask2 knows the link between Historicalmatrix_Reqi and Reqmask1 or Appaddressrange_Reqi and Reqmask2. Therefore, any adversary would not be able to identify the type of request from message, which increases user's privacy. In addition, similarly as Part B, Reqmask1 and Reqmask2 can be used to provide a variety of security services, which will be clarified in the following steps. Step 2: In Step 2, RSU decrypts the received message from vehicle i with its private key corresponding to public key PuRSU that was used by vehicle i to encrypt message. Then, RSU checks the validity of T 1, and that Reqmask1 and Reqmask2 sent along with message are same as decrypted ones; in order to verify security services provided by Reqmask1, Reqmask2 and timestamps (T1) explained in Step 1. If decrypt and checks are valid, RSU will generate the following messages:

Location_server: location server that stores historical matrix needed by vehicle i. T2: a timestamp that indicates the time at which message is sent from RSU. signRSU(M): the whole message M is signed by RSU. Other components of above 2 messages are same as those used in message in (1). In this step as shown in (a) (2), RSU forwards to location server a signed message that includes Historicalmatrix_Reqi, Reqmask1 and T2, which RSU has received from vehicle i in (1). In addition, as shown in (b) (2), RSU forwards to GA a signed message that includes Appaddressrange_Reqi, Reqmask2 and T2, which RSU has received from vehicle i in (1). On the other hand, if decrypt or check performed by RSU on the received message from vehicle i is not valid, RSU will generate the following deny message instead of the above 2 messages: RSU  Vehicleall: Deny Reqi Reqmask1 Reqmask2 T2 signRSU(Deny Reqi, Reqmask1, Reqmask2, T2) (2) Vehicleall: all vehicles that are within RSU transmission range. Deny_Reqi: deny of request message that was sent by vehicle i in (1). Other components of above message are same as those used before. In the above case, RSU broadcasts a signed deny message to all vehicles that are within its transmission range including vehicle i, which contains Deny_Reqi, Reqmask1, Reqmask2 and T2. This message informs vehicle i that its request message has been denied, so that it can send another request message as in Step 1. When vehicle i receives the above message, it verifies signature of message to make sure that it was sent by RSU, and also it checks the validity of T2 in order to verify security services provided by timestamps (T 2) discussed in Step 1. Only vehicle i that knows the relation between Reqmask1 and Reqmask2 sent in deny message and the requests sent before in message in (1). Thus, despite broadcasting the message to all vehicles (within RSU transmission range), only vehicle i can know deny sent in message belongs to which request. Therefore, this method hides requests of vehicle i in (1) with Reqmask1 and Reqmask2, which reserves driver's privacy. Any other vehicle will discard the received message, since it doesn't know Reqmask1 and Reqmask2 included in message are for which requests.

RSULocation server: Historicalmatrix Reqi Reqmask1 T2 signRSU(Historicalmatrix Reqi, Reqmask1,T2) (a) (2) 18

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) GA  RSU: Reply2i { Appaddressrange

Moreover, broadcasting deny message to all vehicles within RSU transmission range including vehicle i, rather than sending it specifically to vehicle i is very beneficial as explained before in Step 2 of Part B. Step 3: In Step 3, location server verifies signature of received message in (a) (2) to make sure that it was sent by RSU. Also, it checks the validity of T 2 in order to verify security services provided by timestamps (T2) that were mentioned in Step 1. If checks are valid, location server will generate the following message, which contains:

signGA(Appaddressrange) } T3

Reply2i: a reply from GA to Appaddressrange_Reqi that was received in (b) (2) from vehicle i via RSU. Appaddressrange: application address range which is used by vehicle i to select an application. signGA(M): the whole message M is signed by GA. Other components of above message are same as those used before. In Step 3, as shown above in (b) (3), GA sends a signed reply message to RSU that contains Appaddressrange and T3. The purpose of this message is to send to vehicle i the requested application address range obtained from GA via RSU, as will be shown in the next step. On the other hand, if checks performed by GA on the received message from RSU are not valid, GA will generate the following deny message instead of the above message in (b) (3):

Location server  RSU: Reply1i {Historicalmatrix} T3 (a) (3) Reply1i: a reply from location server to Historicalmatrix_Reqi that was received in (a) (2) from vehicle i via RSU. Historicalmatrix: historical matrix that contains vehicular traces that represents users’ behaviour on road, which is needed by vehicle i for path prediction process. T3: a timestamp that indicates the time at which message is sent from location server/ GA. In Step 3, as shown in (a) (3), location server sends a reply message to RSU that contains Historicalmatrix and T3. The purpose of this message is to send to vehicle i the requested historical matrix obtained from location server via RSU, as will be shown in the next step. Since the message doesn't contain any private information of vehicle i, there is no need to encrypt it. On the other hand, if checks performed by location server on the received message from RSU are not valid, location server will generate the following deny message instead of the above message in (a) (3):

GA  RSU: Reply2i { Deny Reqi Reqmask2 signGA(Deny Reqi, Reqmask2) } T3 (b) (3) Deny_Reqi: deny of request message that was sent by vehicle i to RSU in (1), and forwarded by RSU to GA in (b) (2). Other components of above message are same as those used before. In the above case, GA sends a signed deny message to RSU that contains Deny_Reqi, Reqmask2 and T3. The purpose of the above message is to inform vehicle i that its request has been denied, so that it can send another request message as in Step 1. Step 4: In this step, RSU verifies signature of the received message of (b) (3) to make sure that it was sent by GA. Then, RSU checks the validity of T 3 sent in messages of (a) (3) and (b) (3), in order verify security services provided by timestamps (T3) (discussed in Step 1). If checks are valid, RSU will generate the following message, which includes:

Location server  RSU: Reply1i {Deny Reqi Remask1} T3

(b) (3)

(a) (3)

Deny_Reqi: deny of request message that was sent by vehicle i to RSU in (1), and forwarded by RSU to location server in (a) (2). Other components of above message are same as those used before. In the above case, location server sends a deny message to RSU that contains Deny_Reqi, Reqmask1 and T3. This message is to inform vehicle i that its request has been denied, so that it can send another request message as in Step 1. On the other side, in Step 3, GA verifies signature of received message in (b) (2) to make sure that it was sent by RSU. Also, it checks the validity of T 2 in order to verify security services provided by timestamps (T 2) that were explained in Step 1. If checks are valid, GA will generate the following message that includes:

RSU  Vehicleall: Reply1i Reply2i T4 signRSU(Reply1i, T4)

(4)

Vehicleall: are all vehicles that are within RSU transmission range. T4: a timestamp that indicates the time at which message is broadcasted from RSU. Other components of above message are same as those used before. In Step 4, which is the last step in Part C of Phase I, RSU broadcasts a signed message to all vehicles that are within its transmission range including vehicle i, which contains Reply1i, Reply2i and T4.

19

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) The purpose of this message is to forward Reply1 i to vehicle i, which includes the requested historical matrix that RSU has received from location server in (a) (3). In addition, this message is used to forward Reply2 i to vehicle i, which includes the requested application address range that RSU has received from GA in (b) (3). When vehicle i receives the above message in (4), it verifies the signature of message to make sure that it was sent by RSU. Also, it checks the validity of T 4, in order to verify security services provided by timestamps (T 4) (explained in Step 1). Then, if previous checks are valid, vehicle i will store the received historical matrix included in Reply1i in its TPD. Also, vehicle i will verify the signature of Reply2i in (4) to make sure that it was sent by GA. If check is valid, vehicle i will store the received application address range included in Reply2i in its TPD. Now, let us focus on an interesting point. The point is that broadcasting the reply message in (4) to all vehicles within RSU transmission range, rather than sending it specifically to vehicle i is very efficient. The reason is that not only vehicle i will receive the reply message, but also other vehicles. Therefore, any other vehicle that needs the same data requested by vehicle i, can receive that data without sending a request or waiting for a response to come. This way is very effective as it: (1) leads to faster response to a request, (2) saves pseudonyms of other vehicles, (3) keeps other vehicles silent, (4) avoids linking of other vehicle’s pseudonyms, (5) mitigates tracking of a vehicle, (6) maintains driver’s location privacy. Furthermore, as discussed before in Step 2 of Part B, broadcasting the reply message to all vehicles rather than sending it to a specific vehicle allows us to cope with VANET constraints such as: variable vehicle address. On the other hand, if Reply1i or Reply2i includes a deny message as shown in (a) (3) and (b) (3), vehicle i can send another request message that includes type of needed data as in Step 1. Moreover, as discussed in Step 2, despite that message is broadcasted to all vehicles within RSU transmission range, only vehicle i can know deny sent in message is for which request which reserves driver's

privacy. Any other vehicle will discard the received message. In addition, if vehicle i didn't receive reply from RSU within Treply, it can resend another request message as shown in Step 1. Finally, it is important to notice that the application address range includes Aapp which is an application address selected by vehicle i, that will be used by vehicle i as its source address when sending an application request. Also, Aapp maybe used by GLx, group leader of group x where vehicle i is one of group members, as its source address as will be shown in Step 2 of Phase II. While, the historical matrix is used by vehicle i to perform Path Prediction. Also, the historical matrix maybe needed by GLx to perform Paths Intersection that will be given below in Step 2 of Phase II. Note that, in this part we treat vehicle i and GLx as the same entity, since the role of group leader rotates among all members of group x [12]. B. Phase II: Sending an Application Request In this phase of our protocol, we will explain how an application request is sent securely from a vehicle to the service provider of needed application. We provide this in a way that avoids tracking of a vehicle, while maintaining location privacy and anonymity of vehicle’s driver as well as offering other security services that will be shown below. This phase is mainly divided into 4 main steps Steps (1-4) as shown in Fig. 5, each will be explained in details. Prior to Step 1 of this phase, a vehicle does mobility prediction that will be briefly discussed below. Path Prediction: If a vehicle wants to send an application request, it does a mobility prediction using historical matrix (obtained in Part C in Initialization Phase) in order to predict the path that it will follow during its trip. Details of the path prediction are out of scope of this paper, for more details refer to [10]. The LBS Provider needs to have knowledge about all locations of the vehicle in order to provide real-time service. Therefore, a vehicle instead of sending every new location while moving, it can send its whole path only once.

20

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012)

Phase II Phase III

: Request Steps: (1-4). : Deny of request. : Acknowledgement of request. : Reply Steps: (5-7).

   

Gx: Group x, GLx: Group leader of Group x. G1: Group 1, GL1: Group Leader of Group 1. Gn: Group n, GLn: Group Leader of Group n. G1, GL1 Gn, GLn: Assuming there are n Group Leaders of n Groups within RSU transmission range.

    

Vi (G x): Vehicle i in Group x. V1(G 1): Vehicle 1 in Group 1, Vm(G1): Vehicle m in Group 1. V1(G1) Vm(G1): Assuming there are m members in G1. V1(Gn): Vehicle 1 in Group n, Vm(Gn): Vehicle m in Group n. V1(Gn) Vm(Gn): Assuming there are m members in Gn.

Fig. 5. Illustration of Steps involved in Protocol Phases II and III.

Thus, predicted path of vehicle is needed by service provider of requested application for real-time service. Note that, if vehicle i changes its followed path, a new path prediction process should take place that is needed to be sent to SP for ensuring accurate service availability. Benefits of performing Path Prediction are: (1) reserving pseudonyms of a vehicle that are needed to be changed with every new location sent, (2) keeping the vehicle silent during the time between sending an application request and receiving a reply, since no location updates are needed to be sent as whole path is sent, (3) preventing linking of pseudonyms of a vehicle by avoiding frequently sent messages from a vehicle, (4) mitigating tracking of a vehicle by an adversary, (5) preserving location privacy of a user. In addition to all of these benefits, the predicted path of vehicle i is used to generate a prospective form of path confusion as will be clarified in the next step. Step 1: In Step 1 of this phase, vehicle i which is a member in group x Vi(Gx) sends an application request message to group leader of group x GLx. The request message is sent using the needed application address Aapp (included in application address range obtained in Part C of Initialization Phase) as the vehicle’s source address, instead of using one of vehicle’s pseudonyms.

Advantages of using Aapp as vehicle’s source address include: (1) preserving the vehicle’s pseudonyms, (2) keeping vehicle silent, (3) prevent linking of pseudonyms of a vehicle, (4) avoids tracking of a vehicle by an adversary, (5) increasing driver’s location privacy, (6) prevents linking of a vehicle to a specific application request thus reserving the user’s privacy and anonymity as well as may limit traffic analysis. Vehicle i generates the request message as shown in Fig. 5, which includes the following: Vi(Gx)  GLx: EPu(GLx)[ predicted pathi App Reqi Reqmask T1 ] Reqmask

(1)

Predicted_pathi: predicted path of vehicle i is needed by LBS provider of desired application to provide real-time service to vehicle i. App_Reqi: an application request which includes the type of desired application needed by vehicle i. T1: a timestamp that indicates the time at which message is sent from vehicle i to GLx. Reqmask: a random number that corresponds to App_Req i that is used to hide App_Reqi. The entire message is encrypted with public key of GLx PuGLx (that was obtained in Section II.A.2).

21

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) In Step 1, as shown above in (1), vehicle i sends an encrypted message to GLx, that contains predicted_pathi, App_Reqi, Reqmask and T1 along with Reqmask. This message indicates the type of application needed by vehicle i and the time at which this request has been sent by vehicle i to GLx. Since it is required that only GLx sees this message, the message is encrypted with public key of GLx. Timestamps are used here as will be shown in the following steps to provide a variety of security services such as: (1) To ensure message integrity. (2) To increase confidence of sender that message has been sent to correct recipient. (3) To increase trust in the received message by ensuring that it has been sent from the correct entity (sender authentication). (4) To avoid replay attacks. (5) In addition to all this, timestamps are used to ensure non-repudiation of sender or receiver and to provide accountability in some cases. While, Reqmask is used to hide App_Reqi as will be clarified in the next steps. Reqmask masks App_Req i while sending App_Reqi from vehicle i to RSU, and also in cases of denying or acknowledging App_Req i. In case of sending App_Reqi, App_Reqi is encrypted with public key of receiver, while Reqmask is sent along with message without encryption. Consequently, any adversary or observer of message can only see Reqmask and will not be able to see the encrypted App_Reqi. While in case of sending a deny or acknowledgment of App_Req i, App_Reqi is not sent and instead Reqmask is only sent in a signed message by sender. Moreover, only vehicle i that generated Reqmask know the link between App_Req i and corresponding Reqmask. Therefore, any adversary cannot identify the type of application requested from Reqmask, since type is only contained in App_Reqi and so conserving user’s privacy. In addition, Reqmask could be used similarly as timestamps to provide a variety of security services. It can be used to ensure message integrity, to increase both confidence of sender that message has been sent to correct recipient and trust in the received message by ensuring that it has been sent from the correct entity. Note that Reqmask is used here to provide a challenge/ response means between communicating entities in order to avoid replay attacks [35].

Then, GLx checks the validity of T1 and that Reqmask sent along with message is same as decrypted Reqmask, in order to verify security services provided by Reqmask and timestamps (T1) that were explained in Step 1. If decrypt and checks are valid, GLx will perform paths intersection as will be briefly discussed below. Paths Intersection: GLx intersects together predicted path of vehicle i received in (1) with other previously received predicted paths of other vehicles in group x. The predicted path of vehicle i is extrapolated until it intersects with other predicted paths at both ends. This is done to create a series of posteriori intersected paths, so that the predicted path of vehicle i will be camouflaged with other paths and becomes indistinguishable among other paths. Note that, if GLx has no other predicted paths available for paths intersection, GLx will do its own path prediction and intersects its predicted path with received path of vehicle i. Thus, combined usage of path prediction (given in Step 1 of this phase) and paths intersection creates a series of posteriori intersected paths that provides a prospective form of path confusion. Benefits of making Paths Intersection are: (1) Creating prospective path confusion to an adversary. (2) Mitigating tracking by both external and internal adversaries that were discussed in Section II.B. (3) Reserving both user's location privacy and anonymity. Note that, an anonymity set of a user path p contains all vehicles that are equally likely to have path p which is equal to (size of an anonymity set) the total number of posteriori intersected paths (that will be given in Section VI). (4) Protecting against semi-trusted entities (are internal adversaries as mentioned in Section II.B) because: GLx will forward the received request message of vehicle i to RSU, with the created intersected paths instead of predicted path of vehicle i. After that, RSU will forward the received intersected paths to location sever, which will in turn forward these intersected paths to LBS provider of desired application, as will be shown in the following steps. Therefore, neither RSU nor location server will be able to see the predicted path of vehicle i and so protecting against semi-trusted entities. (5) Protecting against untrusted entities (are internal adversaries as discussed in Section II.B) since: untrusted LBS provider of needed application will not be able to see predicted path of vehicle i or any other information of vehicle i, and will blindly provide needed service to vehicle i.

Step 2: In Step 2 of this phase, GLx decrypts the received message from vehicle i with its private key corresponding to public key PuGLx that was used by vehicle i to encrypt message.

22

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) GLx will generate the following message as shown in Fig. 5, which includes the following:

Also, it checks the validity of T 2 in order to verify security services provided by timestamps (T 2) that were discussed in Step 1. Only vehicle i that knows the relation between Reqmask sent in deny message and needed application. Therefore, despite that message is broadcasted to all group members, only vehicle i can know the deny sent in message is for which application. Thus, hiding application request of vehicle i with Reqmask and so reserving user’s privacy. Any other vehicle will discard the received message, since it doesn’t know Reqmask included in message is for which application request as it didn’t generate this Reqmask. Now, we need to highlight some interesting issues. One issue is that broadcasting deny message to whole group including vehicle i, rather than sending it specifically to vehicle i is very effective for 2 reasons. First reason, GL x doesn’t know address of vehicle i as indicated in Step 1, because vehicle i uses Aapp as its source address rather than using one of its pseudonyms. Second reason, vehicle i changes its address (pseudonym) while sending other types of requests (such as those sent in Phase I), or when using other applications; for example in safety message broadcasts needed for safety applications. So, GLx needs to be updated with the recent address of vehicle i that has sent the request message. Thus, using this way, we can cope with VANET challenges as: dynamic vehicle address. Another issue is that vehicle i after sending request message to GLx, may not be currently in transmission range of GLx, or may have left group x (due to high mobility of vehicles). If this occurs, vehicle i will not be able to receive the deny message. In this case, vehicle i could wait for Tack till it receives an acknowledgement of sent request, after that it can send another request message to its current group leader GL as in (1). This will be clarified in the next step. Furthermore, in Step 2 above, we can apply the real life concept (to an old group leader) that says: “Finish all your received jobs then you can go on a holiday.” Due to high mobility of vehicles, after receiving request message of vehicle i, GLx could be no longer within range of other group members of group x and so is not the current GL of group x. Moreover, due to group leader role rotation protocol [12, 22], GLx may not be the current GL of group x as instead a new GL would have been elected for group x. Despite that, GLx can still forward request message of vehicle i to RSU, as RSU can be still within GLx transmission range.

GLx  RSU: EPu(RSU)[ intersected paths App Reqi Reqmask T1 T2 ] Reqmask

(2)

Intersected_paths: posteriori intersected paths generated by GLx that will be forwarded to LBS provider of desired application, which is needed to provide real-time service to vehicle i. T2: a timestamp that indicates the time at which message is sent from GLx. Other components of above message in (2) are same as those used in message in (1). The entire message is encrypted with public key of RSU PuRSU (obtained in Part A in Initialization Phase). In this step as shown in (2), GLx sends an encrypted message to RSU that contains intersected_paths, App_Req i, Reqmask, T1 and T2 along with Reqmask. Similarly as in Step 1, this message is sent using Aapp (obtained in Part C in Initialization Phase) as GLx source address instead of using one of pseudonyms of GLx, which is very beneficial as indicated in Step 1. This message indicates the type of application needed to be provided to a series of posteriori intersected paths rather than to a specific path of a specific entity. Also, this message includes both time at which original request has been sent by requestor (vehicle i) (i.e. T1) and the time at which this request has been forwarded by GLx to RSU (i.e. T2). Since it is required that only RSU sees this message, it is encrypted with public key of RSU. On the other hand, if decrypt or check performed by GL x on the received message from vehicle i is not valid, GLx will generate the following deny message as shown in Fig. 5 instead of the above message in (2): GLx  Gx: Deny Reqi Reqmask T2 signGLx (Deny Reqi, Reqmask, T2)

(2)

Gx: vehicles in group x. Deny_Reqi: deny of request message that was sent by vehicle i in (1). signGLx (M): the whole message M is signed by GLx. Other components of above message are same as those used before. In the above case, GLx broadcasts a signed message to all members including vehicle i in group x that contains Deny_Reqi , Reqmask and T2. The purpose of this message is to inform requestor (vehicle i) that its request message has been denied. So, if vehicle i still needs the application, it can send another request message to GLx or its current group leader as in (1). When vehicle i receives the deny message, it verifies signature of message to make sure that it was sent by GLx.

23

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) Therefore, by doing so, vehicle i can receive reply to its request, without having to resend another request message to its current GL. Advantages of applying the above concept include: (1) Vehicle i can receive faster response to its request while saving its computation time and effort. (2) Vehicle i will save its pseudonyms and stays silent. (3) Decreasing the possibility of linking of pseudonyms of vehicle i. (4) Mitigating tracking of vehicle i. (5) Increasing user’s location privacy. Furthermore, by applying the above concept, GLx can process all received requests from group members that do not need group communication, while not being current GL of group x. Thus, allowing us to cope with VANET constraints (given in Section I), such as: dynamic network topology and sporadic relation between vehicles, as well as rotating role of a group leader. Step 3: In Step 3, RSU decrypts the received message from GLx with its private key corresponding to public key Pu RSU that was used by GLx to encrypt message. Then, RSU checks the validity of T2 and that Reqmask sent along with message is same as decrypted Reqmask, in order to verify security services provided by timestamps (T2) and Reqmask that were explained in Step 1. If decrypt and checks are valid, RSU will generate the following 2 messages as shown in Fig. 5:

This will be justified as follows. Due to high mobility of vehicles and other VANET challenges, by the time of sending this message; many different scenarios could have been occurred. First scenario, GLx may not be the current GL of group x. This is because GLx could have become out of range its group members, or its role could have been changed due to group leader role rotation protocol; and so a new GL would have been elected for group x. Second scenario, GLx could have changed its address while using applications; for example safety applications that need safety message broadcasts, or when sending other types of request messages (e.g. those sent in Phase I). So, RSU needs to be updated with recent address of GLx. Another scenario is that, vehicle i could have left group x and joined another group within RSU transmission range. Taking into consideration all these scenarios, it is effective that RSU broadcasts message to all existing group leaders GLs of groups (where GLx may still exist) that are known to RSU and are within its transmission range. Thus, using this method allows us to cope with the challenging constraints of VANET (explained in Section I). However, only GLx in case it receives message, can compare T 1, T2 and Reqmask included in received message with the ones used before in (2), in order to verify security services provided by timestamps (T2) and Reqmask (that were explained in Step 1). Also, only Glx (along with vehicle i) can know Ack_Reqi in received message is for which application from App_Reqi received before in (1) and so preserving user’s privacy. Any other GL will discard T 2 included in received message. Then, each GL received message from RSU will verify signature of message to make sure that it was sent by RSU. Also, each GL will check the validity of T 3 in order to verify security services provided by timestamps (T 3) that were discussed in Step 1. Then, if checks are valid, each GL will generate the following message as shown in Fig. 5:

RSU  GL1→ : Ack Reqi Reqmask T1 T2 T3 →n signRSU(Ack Reqi, Reqmask, T1, T2, T3) (3.1) RSU  Location_server: intersected_paths App Reqi Reqmask T3 (3.2) (3) GL1→n: Assuming there are n group leaders of n groups within RSU transmission range. Ack_Reqi: Acknowledgement by RSU of reception of the request message, that was sent by vehicle i and forwarded via GLx to RSU. T3 : a timestamp that indicates the time at which message is sent by RSU. signRSU(M): the whole message M is signed by RSU. Location_server: location server that provides an interface for LBS provider as mentioned in Section II.A. Other components of above 2 messages (3.1) and (3.2) are same as those used before. In Step 3 as shown above, RSU generates 2 different messages. The first message, as shown in (3.1), is a signed acknowledgement message that contains Ack_Reqi, Reqmask, T1, T2 and T3; which is broadcasted to all group leaders of groups within RSU transmission range. Now, let us focus now on an important issue. As shown above in (3.1), RSU broadcasts acknowledgment message to all group leaders of groups within its transmission range, rather than sending it specifically to GLx of group x.

GL  Vehicle1 m : Ack Reqi Reqmask T1 Ts signGL(Ack Reqi, Reqmask T1, Ts) (3.1.1) GL: Group leader of a certain group. Vehicle1→m: Assuming there are m vehicles that are members in a certain group where GL is its group leader. Ts: a timestamp that indicates the time at which message is broadcasted from GL. signGL(M): the whole message M is signed with GL. Other components of above message are same as those used before. Now, each GL will broadcast the above signed message in (3.1.1) that contains Ack_Reqi, Reqmask, T1 and Ts to all its group members where vehicle i may currently exist. 24

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) RSU  GL1

Therefore, using this way, we neither depend on a dynamic network topology, nor on existence of a variable GL (GLx) to forward message to vehicle i, or on a variable vehicle address. Thus, this way is suitable to apply in a real VANET environment. As discussed before in Step 2, despite that message is broadcasted and so many vehicles can receive it, only vehicle i can compare both T1 and Reqmask included in received message with the ones that it has generated before in (1). This comparison is performed in order to verify security services provided by Reqmask and timestamps (T1) (that were explained before in Step 1). Also, only vehicle i can know the Ack_Reqi in received message belongs to which application via Reqmask included in message, which vehicle i has generated before along with App_Reqi in (1) and therefore conserving user’s privacy. Any other vehicle will discard received message since it doesn’t know Reqmask included in message belongs to which application as it didn’t generate this Reqmask. The purpose of acknowledgment message is to inform requestor (vehicle i) that its request message has been successfully forwarded to RSU, which has forwarded request to location server. As will be shown in the next step, location server will forward received request to LBS provider of needed application. If vehicle i didn’t receive an acknowledgment message within T ack and still needs the application, it can send another request message to its current GL as in (1) and so avoiding any delay to receive a reply. When vehicle i receives the acknowledgement message, it verifies signature of message to make sure that message was sent by its current GL. Then, it checks the validity of Ts included in received message in order to verify security services provided by timestamps (T s) (previously mentioned in Step 1). The second message sent by RSU, as shown in (3.2) contains App_Reqi, Reqmask and T3. The message indicates the type of application needed to be provided to a series of posteriori intersected paths. Recall from what was discussed before in Step 2, by this way location server will not be able to see predicted path of vehicle i. Thus, protecting against a semi-trusted location server (internal adversary as indicated in Section II.B), and preserving both user’s location privacy and anonymity as well. The message is sent to the location server that provides an interface for LBS provider, via a wired network as discussed before in Section II.B. On the other hand, if decrypt or check preformed by RSU on the received message from GLx is not valid, RSU will generate the following deny message, as shown in Fig. 5, instead of the above 2 messages (3.1) and (3.2):

: Deny Reqi Reqmask T3 n signRSU(Deny Reqi, Reqmask, T3)

(a) (3)

Components of above message in (a) (3) are same as those used before. In the above case, RSU broadcast the above signed message in (a) (3) that contains Deny_Req i, Reqmask and T3 to all group leaders of groups within RSU transmission range. As discussed before, similarly as (3.1), it is effective that RSU broadcasts deny message to all group leaders of groups (where GLx may still exist) within its transmission range, rather than sending it specifically to GLx of group x. However, only GLx in case it receives above message in (a) (3) can compare Reqmask in received message with the one received before in (1). This comparison is done to verify security services provided by Reqmask that were mentioned in Step 1. Also, only GLx (along with vehicle i) can know Deny_Reqi in received message belongs to which application via App_Reqi received before in (1), which increases user’s privacy. Then, each GL received message from RSU will verify signature of message to make sure that it was sent by RSU. Also, each GL will check the validity of T 3 in order to verify security services provided by timestamps (T3) that were discussed in Step 1. If checks are valid, each GL will generate the following message, as shown in Fig. 5: GL  Vehicle1 m: Deny Reqi Reqmask Ts signGL( Deny Reqi, Reqmask, Ts)

(b) (3)

Ts: a timestamp that indicates the time at which message is broadcasted from GL. Other components of above message in (b) (3) are same as those used before. At this moment, each GL will broadcast the above signed message in (b) (3) that contains Deny_Req i, Reqmask and Ts to all its group members. As discussed before, similarly as (3.1.1), it is efficient that each GL broadcasts deny message to all its group members (where vehicle i may currently exist), rather than sending it specifically to vehicle i. However, as previously mentioned, only vehicle i can compare Reqmask included in received message with the one that it has generated in (1) (to verify security services provided by Reqmask given in Step 1). Also, only vehicle i can know the Deny_Reqi in received message is for which application via Reqmask included in message, which vehicle i has generated along with App_Reqi in (1) and so enhancing driver’s privacy. Any other vehicle will discard the received message, since it doesn't know Reqmask included in message is for which application as it didn't generate this Reqmask. 25

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) The purpose of this message is to inform vehicle i that its request message has been denied. So, if vehicle i still needs the application, it can send another request message to its current GL as in (1). When vehicle i receives the deny message, it verifies the signature of message to make sure that message was sent by its current GL. Then, it checks the validity of Ts included in received message to verify security services provided by timestamps (T s) (mentioned in Step 1).

When RSU receives the above message in (a) (4) from location server, it checks the validity of T 4, as well as compares T3 and Reqmask included in received message with the ones that it has used in (3.2). This is done in order to verify security services provided by timestamps (T 3, T4) and Reqmask (given in Step 1). If checks are valid, RSU will generate the following message as shown in Fig. 5: RSU  GL1→ : Deny Reqi Reqmask T1 T2 Ts →n signRSU(Deny Reqi, Reqmask, T1, T2, Ts) (b) (4)

Step 4: In Step 4, which is the last step in Phase II, location server checks the validity of T 3 in order to verify security services provided by timestamps (T 3) (discussed in Step 1). Also, it checks that App_Reqi included in received message from RSU is valid. After that, location server checks that application needed by vehicle i included in App_Reqi has no restricted access. If checks are valid, location server will generate the following message as shown in Fig. 5:

Ts: a timestamp that indicates the time at which message is broadcasted from RSU. Other components of above message in (b) (4) are same as those used before. As shown above, RSU broadcasts the above signed message in (b) (4) that contains Deny_Req i, Reqmask, T1, T2 and Ts to all group leaders of groups within RSU transmission range. As indicated before, similarly as (3.1), it is efficient that RSU broadcasts deny message to all group leaders of groups (where GLx may still exist) within its transmission range, rather than sending message specifically to GLx of group x. Despite that, only GLx in case it receives above message in (b) (4) can compare Reqmask, T1 and T2 in received message with the ones that it has used before in (2). This comparison is made to verify security services provided by Reqmask and timestamps (T 1, T2) (explained in Step 1). In addition, only GLx (along with vehicle i) can know Deny_Reqi in received message is for which application from App_Reqi received before in (1) and therefore reserving user’s privacy. Any other GL will discard T2 included in received message. After that, each GL received message from RSU will verify signature of message to make sure that it was sent by RSU. Besides that, each GL will check the validity of T s included in received message to verify security services provided by timestamps (Ts) (given in Step 1). If checks are valid, each GL will generate the following message as shown in Fig. 5:

Location_server SPx: intersected paths App Reqi T4 (4) SPx: LBS Provider of application x needed by vehicle i. T4: a timestamp that indicates the time at which message is sent from Location_server. Other components of above message in (4) are same as those used before. In this step, as shown in (4), location server sends a message that contains intersected_paths, App_Reqi and T4 to LBS provider of application x (requested by vehicle i in (1)). This message indicates the type of application needed to be provided by LBS provider, to a series of posteriori intersected paths. As discussed before in Step 2, by this way LBS provider of application x will not be able to see predicted path of vehicle i and so will blindly provide desired service to vehicle i. Thus, protecting against an untrusted LBS provider, which is an internal adversary (as mentioned in Section II.B), and so preserving both user's location privacy and anonymity. On the other hand, if above checks performed by location server on the received message from RSU are not valid, location server will generate the following deny message as shown in Fig. 5 instead of the above message:

GL  Vehicle1→ : Deny Reqi Reqmask T1 Ts →m signGL(Deny Reqi, Reqmask, T1, Ts) (c) (4)

Location server  RSU: Deny Reqi Reqmask T3 T4 (a)(4)

Ts: a timestamp that indicates the time at which message is broadcasted from GL. Other components of above message in (c) (4) are same as those used before. Currently, each GL will broadcast the above signed message in (c) (4) that contains Deny_Reqi, Reqmask, T1 and Ts to all its group members where vehicle i may currently exist.

Components of above message in (a) (4) are same as those used before. In the above case, location server sends the above deny message in (a) (4) to RSU that contains Deny_Reqi, Reqmask, T3 and T4. 26

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) Despite that, as explained in (3.1.1), only vehicle i can compare both Reqmask and T1 included in received message with the ones that it has generated in (1) (to verify security services provided by Reqmask and timestamps (T1) discussed in Step 1). Moreover, only vehicle i can know the Deny_Reqi in received message belongs to which application via Reqmask included in message (that vehicle i has generated along with App_Reqi in (1)), which increases driver’s privacy. Any other vehicle will discard the received message, since it doesn't know Reqmask included in message is for which application as it didn't generate this Reqmask. The purpose of the above message is to inform vehicle i that its request message has been denied. Therefore, if vehicle i still needs the application, it can send another request message to its current GL as in (1). When vehicle i receives the above message, it verifies signature of message to ensure that it was sent by its current GL. After that, it checks the validity of Ts included in received message to verify security services provided by timestamps (Ts) (mentioned in Step 1).

T5: a timestamp that indicates the time at which message is sent from SPx to location server. Other components of above message in (5) are same as those used before. As shown in (5), LBS provider of application x sends a reply message to location server that contains responses_paths, Reply, T4 and T5. In this step, SPx generates needed responses of requested application, which are provided to a series of posteriori intersected paths rather than to a specific path (i.e. predicted path of vehicle i). This message is a reply from LBS provider to the message that it has received before from location server in (4). As indicated in Step 2 of Phase II, using this way LBS provider of needed application will blindly provide desired service to vehicle i. This is because SPx is not able to see predicted path of vehicle i or any other information (i.e. zero-information) of vehicle i. Advantages of using Blind LBS provider are: (1) Avoiding disclosure of private information of vehicle, such as: identity and locations of a vehicle. (2) Preventing identification of driver. (3) Preventing linking of a vehicle to a specific application request and so maintaining the user’s anonymity as well as may limit traffic analysis. (4) Increasing privacy of driver. (5) Mitigating tracking of a vehicle. (6) Preserving location privacy and anonymity for vehicle’s driver. (7) Protecting against untrusted LBS provider (which is an internal adversary as mentioned in Section II.B).

C. Phase III: Receiving a Reply to a Request In Phase III of our protocol, we will briefly discuss how a reply is securely received by a vehicle from service provider of needed application. We use a method that mitigates tracking of a vehicle and provides both location privacy and anonymity to vehicle’s driver. This phase is mainly divided into 3 steps Steps (5-7) as shown in Fig. 5, each will be explained below in details.

Step 6: In Step 6, location server checks the validity of T 5 and compares T4 included in received message in (5) with the one that it has used before in (4) (in Phase II). This comparison is performed to verify security services provided by timestamps (T4, T5) (discussed in Step 1 of Phase II). If checks are valid, location server will generate the following message as shown in Fig. 5:

Step 5: In Step 5, which is the first step of Phase III, LBS provider of application x checks the validity of T4 included in received message in (4) (in Phase II) to verify security services provided by timestamps (T 4) (mentioned in Step 1 of Phase II). If check is valid and LBS provider is available i.e. able to provide requested service, it will generate the following message as shown in Fig. 5:

Location_serverRSU:responses_paths Reply T3 T6 (6) T6: a timestamp that indicates the time at which message has been sent from location_server to RSU. Other components of above message in (6) are same as those used before. In this step as shown in (6), location server sends a message to RSU that contains responses_paths, Reply, T 3 and T6. The message includes the responses to a series of posteriori intersected paths which were generated by SPx in the previous step. This message is a reply from location server to the message that it has received before from RSU in (3.2) (in Phase II).

SPxLocation server: responses paths Reply T4 T5 (5) Responses_paths: responses generated by SPx of the needed application included in App_Reqi, which are provided to a series of posteriori intersected paths included in intersected_paths. Note that, App_Reqi and intersected_paths were received by SPx from location server in Step 4 of Phase II. Reply: reply that includes the type of application that was provided by SP x after receiving App_Reqi.

27

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) Step 7: In Step 7 which is the last step in Phase III, RSU checks the validity of T6 and compares T3 included in received message in (6) with the one that it has used in (3.2) (in Phase II). This comparison is done to verify security services provided by timestamps (T 3, T6) (given in Step 1 of Phase II). If checks are valid, RSU will generate the following message as shown in Fig. 5:

At this time, each vehicle (including vehicle i) that received the above message in (7.1) from its GL, will verify signature of message to ensure that it was sent by its GL. Then, each vehicle will check the validity of T s included in received message to verify security services provided by timestamps (Ts) (mentioned in Step 1 of Phase II). If checks are valid and the vehicle needs the application included in received message, it can filter the received responses according to its own predicted path in order to store only the needed responses of its own path. While unwanted responses of other paths can be discarded by the vehicle. If vehicle i or any other vehicle that has sent an application request didn't receive a reply message within Treply and still needs the application, it can send another request message to its current group leader as in (1). Furthermore, the above message in (7.1) is a reply from LBS provider to the request message that was sent before from vehicle i in (1). Despite that, not only vehicle i that has received the reply included in (7.1), but also other vehicles. This is very beneficial as any other vehicle that needs the same application requested by vehicle i, will receive some responses till its own responses arrive. Therefore, this way increases the speed at which a vehicle can receive a response to its application request while allows for more tolerance to network delays and so is suitable to use in real-time applications. It is noticed that Reqmask has not been used throughout Phase III, since it is not desired to hide the Reply, so that all vehicles can see it and use it. This is unlike Phase II, where it was desired to hide App_Reqi by Reqmask to preserve the user's privacy.

RSU  GL1→ : responses paths Reply T1 T2 T7 →n signRSU(responses paths, Reply, T1, T2, T7) (7) T7: a timestamp that indicates the time at which message is broadcasted from RSU. Other components of above message in (7) are same as those used before. In this step, RSU broadcasts the above signed message in (7) that contains responses_paths, Reply, T 1, T2, and T7 to all group leaders within RSU transmission range. As discussed in (3.1) (in Phase II), it is effective that RSU broadcasts the above message to all group leaders of groups (where GLx may still exist) within its transmission range, rather than sending it specifically to GLx of group x. However, only GLx in case it receives above message in (7) can compare T1 and T2 in the received message with the ones it has used in (2) (in Phase II). This comparison is made to verify security services provided by timestamps (T1, T2) (mentioned in Step 1 of Phase II). Any other GL will discard T2 included in received message. Now, each GL received message from RSU will verify signature of message to ensure that it was sent by RSU. In addition, each GL will check the validity of T 7 included in received message, in order to verify security services provided by timestamps (T 7) (given in Step 1 of Phase II). If checks are valid, each GL will generate the following message as shown in Fig. 5:

D. Summary of Phases II and III In this part, we are going to give a short summary of all the steps Steps (1-7) involved in Phases II and III of our proposed Location Privacy Approach. At the beginning, we will summarize the steps explained in Phase II, Steps (1-4). Then, we will move to the steps involved in Phase III, Steps (5-7). As shown in the previous steps of Phase II, request of vehicle i is not directly sent to LBS provider of needed application as it passes through intermediate nodes, which are: GLx, RSU and location server. First in Step 1, vehicle i in group x uses address of desired application as its source address to send an encrypted message to its group leader GLx, containing an application request and its predicted path as shown in (1). Then in Step 2, GLx sends an encrypted message to RSU that includes request of vehicle i and a series of posteriori intersected paths, rather than predicted path of vehicle i (received by GLx in (1)) as shown in (2).

GL  Vehicle1→ : responses paths Reply T1 Ts →m signGL(responses paths Reply T1 Ts) (7.1) Ts: a timestamp that indicates the time at which message is broadcasted from GL. Other components of above message in (7.1) are same as those used before. Then, each GL will broadcast the above signed message in (7.1) that contains responses_paths, Reply, T1 and Ts to all its group members where vehicle i may currently exist. However, as indicated before in (3.1.1) (in Phase II), only vehicle i can compare T1 included in the received message with the one that it has generated in (1) (in Phase II). This comparison is done to verify security services provided by timestamps (T1) (discussed in Step 1 of Phase II).

28

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) After that in Step 3, RSU forwards to location server the request of vehicle i and the series of posteriori intersected paths, as shown in (3.2). Finally in Step 4, location server forwards to LBS provider of requested application the request of vehicle i and the series of posteriori intersected paths as shown in (4). Moreover, as shown in steps of Phase III, the reply to request sent by vehicle i is received by vehicle i from LBS provider of requested application via intermediate nodes, which are: location server, RSU and current GL of vehicle i. First in Step 5, SPx sends a reply message to location server containing the needed responses of requested application, that are provided to the series of posteriori intersected paths as shown in (5). Later in Step 6, location server forwards the reply message to RSU as shown in (6). Afterwards in Step 7, RSU broadcasts a signed message containing the received reply to all group leaders of groups (where GLx may still exist) within its transmission range as shown in (7). Finally, each GL received the signed reply message in (7) will broadcast a signed message that contains the received reply to all its group members, where vehicle i may currently exist as shown in (7.1).

While in Part C: Obtaining Historical Matrix/ Application Address Range, only vehicle i sends a request message containing requests for historical matrix and application address range that are needed to send an application request as explained in Phase II. Despite that, the reply to this request is broadcasted via RSU to all vehicles (including vehicle i) that are within its transmission range. Therefore, not only vehicle i could use this information for requesting an application but also other vehicles. This way has many benefits that include: (1) leading to faster response to a request, (2) preserving other vehicle’s pseudonyms, (3) keeping rest of vehicles silent, (4) preventing linking of other vehicle’s pseudonyms, (5) mitigating tracking of a vehicle, (6) preserving driver's location privacy, (7) coping with VANET constraints such as: variable vehicle address (pseudonym). Second in Phase II: Sending an Application Request, we have used a variety of techniques to enhance security and privacy in VANET, that include the following: (1) Path Prediction: Advantages of performing Path Prediction are: (a) saving pseudonyms of a vehicle that are needed to be changed with every new location sent, (b) keeping vehicle silent during the time between sending an application request and receiving a reply, (c) preventing linking of pseudonyms of a vehicle by avoiding frequently sent messages from a vehicle, (d) preventing tracking of a vehicle, (e) maintaining user’s location privacy, (f) helping in providing a prospective form of path confusion. (2) Application address Aapp as vehicle’s source address: Benefits of using Aapp as a source address include: (a) prevents linking of a vehicle to a specific application request and so reserving the user’s anonymity as well as may limit traffic analysis, (b) preserving vehicle’s pseudonyms, (c) keeping vehicle silent, (d) preventing linking of vehicle’s pseudonyms, (e) mitigating tracking of a vehicle, (f) increasing location privacy of a user. (3) Group Navigation: Benefits of using Group Navigation include: (1) The group leader is used to intersect together the received predicted paths of its group members, before sending them to RSU. (2) The series of posteriori intersected paths will generate a prospective form of path confusion (to both internal and external adversaries). (3) Path confusion will prevent tracking of a vehicle by an adversary and increases both location privacy and anonymity of a user. (4) No direct communication between requestor (vehicle i) of application and RSU as GL acts as an intermediate entity, and so enhancing user’s privacy and anonymity.

V. ANALYSIS OF SECURITY AND PRIVACY PROVIDED BY OUR PROPOSED LOCATION PRIVACY APPROACH In this section, we will give analysis of the security and privacy achieved by using our location privacy scheme. We will go through the 3 phases of our protocol and highlight the main benefits gained when using our solution. In addition, we are going to show how our approach can really provide location privacy and anonymity as well as major security services for vehicles’ drivers. First in Phase I: Initialization Phase, which is divided into 3 parts, we use an "n-1 key forwarding mechanism” for the Key Renewal in Part B. In this method, we require that at least one of the vehicle’s n key pairs should be valid, so that the new set of key pairs are encrypted by GA using the public key of the valid key pair. Thus, the new set of key pairs could be send privately to vehicle i from GA. Advantages of applying this mechanism are: (1) preserving driver's privacy, (2) avoiding masquerade and replay attacks as well as may limit traffic analysis, (3) preventing disclosure of vehicle’s pseudonyms, (4) avoiding linkability of consecutive messages sent from the same vehicle (using the disclosed pseudonyms), (5) avoiding tracking of a vehicle, (6) maintaining location privacy and anonymity for vehicle’s driver.

29

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) (4) Paths Intersection: Advantages of performing Paths Intersection are: (a) creating a prospective form of Path Confusion to an adversary, (b) mitigating tracking of a vehicle by both internal and external adversaries, (c) reserving both user’s location privacy and anonymity (where an anonymity set of a user path p contains all vehicles that are equally likely to have path p which is equal to, size of an anonymity set, the total number of posteriori intersected paths), (d) protecting against both semi-trusted and untrusted entities (internal adversaries). (5) Timestamps: Security services provided by timestamps are: (a) ensuring message integrity, (b) increasing confidence of sender that message has been sent to correct recipient, (c) increasing trust in the received message by ensuring that it has been sent from the correct entity (sender authentication), (d) avoiding replay attacks, (e) ensuring non-repudiation of sender or receiver and providing accountability. (6) Reqmask: Benefits of using Reqmask include: (a) hiding an application request sent by a vehicle which conserves user’s privacy, (b) providing a variety of security services, similarly as timestamps, including: i) message integrity, ii) sender authentication, iii) increasing confidence of sender that message has been sent to correct recipient, iv) providing a challenge/ response means between communicating entities in order to avoid replay attacks. (7) Message Encryption: messages are encrypted with public key of receiver, in order to provide confidentiality and privacy security services, so that only authorized (wanted) recipient would be able to see the message content. (8) Message Signing: messages are signed by sender to ensure both sender authentication and message integrity security services. (9) Blind LBS Provider: LBS provider of needed application blindly provides service to a vehicle without being able to know any information i.e. zero-information of vehicle. Benefits of using Blind LBS Provider include: (a) preventing disclosure of private information of vehicle; such as: identity and locations of a vehicle, (b) avoiding identification of driver, (c) avoids linking of a vehicle to a specific application request and so preserving the user’s anonymity as well as may limit traffic analysis, (d) preserving privacy of driver, (e) preventing tracking of a vehicle, (f) maintaining location privacy for a user.

(g) protecting against untrusted LBS provider (internal adversary). In addition to all of the techniques applied, we have used Tack so that if vehicle didn’t receive any acknowledgement message of its sent request within T ack, it can send another request message and so avoiding any delay to receive a reply. Besides that, in our protocol both of acknowledgement and deny messages of sent requests are broadcasted to all vehicles within range, rather than sending them to a specific vehicle. While at the same time, we preserve driver’s privacy using Reqmask that is used to hide the sent requests. This way allows us to cope with VANET constraints, such as: (a) a dynamic network topology and sporadic relation between vehicles, (b) a rotating role of group leader, which is due to frequently changing network connection between vehicles, (c) a variable vehicle’s address. Furthermore, we have applied the real life concept (to an old group leader) that sates: “Finish all your received jobs then you can go on a holiday.” This concept allows the old group leader to process all the requests that it has already received from its group members, even if it is not currently the GL. As a result, this concept allows us not only to cope with a dynamic network topology and frequently changing group leader role, but also: (a) allows vehicle to receive faster response to its request, (b) saves both pseudonyms and computation effort of a vehicle that are needed to resend another request, (c) keeps the vehicle silent, (d) prevents linking of pseudonyms of a vehicle, (e) prevents tracking of a vehicle, (f) increases driver’s location privacy. Finally in Phase III: Receiving a Reply to a Request, we have made the reply message (that contains needed responses of requested application by a certain vehicle) to be broadcasted to all vehicles within range, rather than sending reply to a specific vehicle. This method allows us not only to cope with VANET constraints, but also: (a) allows other vehicles to receive some responses till their own response arrives, (b) receiving faster response to an application request sent by other vehicles, (c) more tolerance to network delays, (d) suitable to use in real-time applications.

30

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) 100 10 9

Total number of Origins / Destinations

81

Total number of O/D combinations 64

8 49 7 36 6 25 5 16 4 9

3 4 2 1 0

O

D 2

O

D 3

O

D 4

O

D

O

5

D 6

O

D 7

O

D 8

O

D 9

O

D 10

Total number of intersected paths

Fig. 6. Total number of Origins No Destinations Nd and Total number of Origin Destination O/D combinations for each number of intersected paths from 2 to 10.

VI. SIMULATION AND RESULTS

Where m > 2, as minimum total number of posteriori intersected paths Np is 2. Moreover, from the point of view of an adversary (external or internal adversary) each origin of each intersected path p, its destination may be one of destinations that have a total number equal to total number of intersected paths as shown in equality (1) above. For example, if you have 2 intersected paths, origin 1 (o1) will either go to destination 1 (d1) or destination 2 (d2), and origin 2 (o2) will either go to destination 1 (d1) or destination 2 (d2), so giving 4 possible Origin//Destination O//D combinations. Similarly, if you have 3 intersected paths, o1 will either go to d1 or d2 or d3, and o2 will either go to d1 or d2 or d3, and o3 will either go to d1 or d2 or d3, so giving 9 possible O//D combinations. Therefore, for each 2 number of posteriori intersected paths Np, we will have Np possible O//D combinations as shown in Fig. 6. Thus, we will have the following equation:

In our simulation, we have used Matlab to obtain results as shown below [14, 34, 35]. This section is divided into 3 parts. First in Part I, we will explain how we have measured location privacy achieved by using our approach. Then in Part II, we will show the results obtained from our simulation and analyze each of them. Finally, in Part III, we will discuss the results obtained. A. Part I: Simulation 1. Part A: Location Privacy Measurement: In this part, we will explain how we have measured location privacy achieved when using our scheme. First, we have tried in our simulation different number of posteriori intersected paths. As shown in Fig. 6, we have used from 2 posteriori intersected paths to 10 posteriori intersected paths. Each intersected path (p) has its start called origin (o) and end called destination (d), as shown in Fig. 6. O is the set of all origins, where o Є O. D is the set of all destinations, where d Є D. For example, 2 intersected paths will have 2 origins o and 2 destinations d, 3 intersected paths will have 3 origins o and 3 destinations d and so on. Therefore, total number of posteriori intersected paths Np is equal to total number of origins No which is equal to total number of destinations Nd, as clearly shown in Fig. 6. Besides that, the size of an anonymity set of a user path p (that includes all vehicles that are equally likely to have path p) is equal to the total number of posteriori intersected paths. So, we will have the following equality: | Np | = | No | = | Nd | = m

Total number of O//D combinations for Np = Np

2

(2)

Furthermore, the probability of each O//D combination for each number of intersected paths Np, is randomly generated from a normal distribution. Fig. 7a shows the probability of each of 9 O/D combinations for 3 intersected paths, which are randomly generated from a normal distribution. While Fig. 7b shows the probability of each of 16 O//D combinations for 4 intersected paths. Then, each probability generated is normalized to 1 [42].

(1)

31

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) 0.45 o1 to d1, d2, d3 o2 to d1, d2, d3 o3 to d1, d2, d3

0.4 0.35

Probability

0.3 0.25 0.2 0.15 0.1 0.05 0

o1 d1 o1 d2 o1 d3 o2 d1 o2 d2 o2 d3 o3 d1 o3 d2 o3 d3

O/D combinations Fig. 7a. Probability of each of 9 O D combinations for 3 intersected paths, which is randomly generated from a normal distribution. 0.45 o1 to d1, d2, d3, d4 o2 to d1, d2, d3, d4 o3 to d1, d2, d3, d4 o4 to d1, d2, d3, d4

0.4 0.35

Probability

0.3 0.25 0.2 0.15 0.1 0.05 0

o1 d1

o1 d2

o1 d3

o1 d4

o2 d1

o2 d2

o2 d3

o2 d4

o3 d1

o3 d2

o3 d3

o3 d4

o4 d1

o4 d2

o4 d3

o4 d4

O/D combinations Fig. 7b. Probability of each of 16 O/D combinations for 4 intersected paths, which is randomly generated from a normal distribution. th Where pi is the i element of the probability distribution. H is the entropy over a probability distribution, where its unit in bits. The logarithm in (3) above is taken to base 2 to have a unit of bit, in order to indicate how many bits are needed to represent a piece of information. Moreover, we focus on the information of from where to where a user moves. The information is expressed as the probabilities of a user within the system to take a certain path p from origin o to destination d. In our work, we are interested in the entropy related to a user path p. Based on (3) and using the notation specified before; we define and calculate the Path Entropy for a user path p as:

2. Part B: Location Privacy Metrics: We have mainly used Entropy and Tracking Success Ratio as our location privacy metrics, in order to measure the location privacy achieved by our approach. First, we have used Entropy developed by Shannon [43] for measuring the location privacy provided by our scheme. By definition, Entropy is a quantitative measure of information content and uncertainty of an adversary over a probability distribution. For a probability distribution with values pi, the Entropy is given by the equation: H =

∑ pi log pi

(3)

32

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) No

H( p)   

i 1

Now, we are going to show how we calculated the entropy in case of presence of a weak adversary with limited computation power and capabilities. A user in the system can achieve the maximum possible entropy that is given in (7) below; only in case of the presence of a weak adversary. Thus, the weak adversary provides an upperbound to the achievable location privacy. In addition, the maximum entropy for a user is reached if all the participants in the system have equiprobable paths. We define and calculate the maximum Path Entropy for a user path p as:

Nd



j 1

pi , j log ( pi , j )

(4)

Where + pi , j is the normalized probability of a user to take a certain path p from origin o to destination d. The value of + pi , j is given as: pi , j 

p ( oi , d j ) No



i 1

Nd



j 1

(5 5)

p ( oi , d j )

Where p(oi , dj) is the probability of a user to take a certain path p from o to d. For both equations of (4) and (5), No = Nd = m as given before in equality (1) in this section. In addition, we define the sum of the probability for each value of i, where 1 < i < No, as: Nd



j 1

p( oi , d j )  1

MaxH(p) = Log2 m2

(7 7)

From (7), it is clear that the maximum theoretical entropy for a user path p depends only on the total number of posteriori intersected paths in the system (that was given before in (1)). Given the maximum entropy, the level of location privacy of a user can also be expressed as the ratio of the current entropy H(p) obtained in (4) to the maximum entropy MaxH(p) obtained in (7) above. Therefore, we have:

(6 6)

The above equation in (6) means, if we know that origin of a user path p is at e.g. o1, then the sum of all possible destinations related to o1 should be equal 1. For example by referring to Fig. 7a, p(o1 , d1) + p(o1 , d2) + p(o1 , d3)= 1 , and p(o2 , d1) + p(o2, d2) + p(o2 , d3)= 1 and p(o3 , d1) + p(o3 , d2) + p(o3 , d3)= 1. Similarly by referring to Fig. 7b, p(o1 , d1) + p(o1 , d2) + p(o1 , d3) + p(o1 , d4)= 1, and p(o2 , d1) + p(o2 , d2) + p(o2 , d3) + p(o2 , d4)= 1, and p(o3 , d1) + p(o3 , d2)+ p(o3 , d3) + p(o3 , d4)= 1, and p(o4 , d1) + p(o4 , d2) + p(o4 , d3) + p(o4 , d4)= 1.

H(p)% % = ( H(p) / MaxH(p) ) * 100 %

(8)

As shown in (8) above, we use the Percentage Entropy H(p)% to express the ratio of a user’s location privacy level to the maximum possible level. Therefore, H(p)% gives an indication of how far a user is from the theoretical location privacy upperbound. Second, we have used Tracking Success Ratio for measuring location privacy achieved by our solution. The Tracking Success Ratio is the success probability of an adversary in tracking vehicles. We define and calculate the Tracking Success Ratio using (8) above as:

Recall from what was mentioned above in Part A of Part I; that all probabilities that belong to same origin are randomly generated from a normal distribution, and then are normalized to 1. For example, p(o1 , d1) to p(o1 , d3) are all randomly generated from a normal distribution and then are normalized to 1. Similarly, p(o2 , d1) to p(o2 , d3) and p(o3 , d1) to p(o3 , d3), as well as p(o1 , d1) to p(o1 , d4), and p(o2 , d1) to p(o2 , d4), and p(o3 , d1) to p(o3 , d4), and p(o4 , d1) to p(o4 , d4) are all randomly generated from a normal distribution, and then are normalized to 1. It is worthy to notice that, we have drawn Fig. 7a for 3 posteriori intersected paths and Fig. 7b for 4 posteriori intersected paths to help us in our explanation, yet similar graphs were generated for other number of posteriori intersected paths from 2 to 10. Equation (4) is used to calculate the entropy in case of presence of a strong adversary with high computation power and capabilities.

Tracking Success Ratio = 1

– H(p)% % / 100

(9)

Since H(p)% indicates the level of the user’s achieved location privacy, 100 - H (p)% gives the level of compromising the user’s location privacy through tracking a vehicle by identifying its followed path p. Furthermore as shown in (4), we have calculated entropy obtained at each point of posteriori intersection made, when 2 or more paths intersect together. Since paths could intersect with each other more than once as shown in Fig. 8, there will be entropy gained at each point of posteriori intersection. Therefore, using (4) above, we define and calculate the cumulative Path Entropy for a user path p as follows:

33

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) In our results, the achieved location privacy of a certain user is quantified as the Path Entropy H(p), while the theoretical location privacy upperbound is quantified as the maximum Path Entropy MaxH(p). First, Fig. 9 shows the user Path Entropy H(p) and maximum Path Entropy MaxH(p) for each number of posteriori intersected paths from 2 to 10. It is clearly shown in Fig. 9 that as the total number of posteriori intersected paths increases, the entropy H(p) significantly increases. For example, using 5 intersected paths gives an entropy H(p) of 3.4 bits, while using 8 intersected paths the entropy jumps by 54.07% to 5.23 bits. At 10 intersected paths, the entropy H(p) increases by 18.35% to reach 6.2 bits, meaning that the user path p is indistinguishable among 26.2 paths or 73.51 paths. In addition, Fig. 9 shows the maximum possible entropy MaxH(p) that could be achieved by a user in the presence of a weak adversary (that was given in equation (7) in Part B of Part I above). It is clearly shown in Fig. 9 that as the total number of intersected paths increases; the maximum theoretical entropy significantly rises. Also, MaxH(p) gives higher values of entropy than H(p) for all numbers of intersected paths. For example, using 5 intersected paths gives MaxH(p) of 4.64 bits, while using 8 intersected paths MaxH(p) rises by 29.2% to 6 bits. At 10 intersected paths, MaxH(p) increases by 10.73% to achieve 6.64 bits of entropy, which means that the user path p is indistinguishable among 26.64 paths or 99.73 paths. Moreover, as the total number of posteriori intersected paths increases, the Percentage Entropy H(p)% increases as shown in Fig. 10. Since both entropy H(p) and MaxH(p) rises as the total number of intersected paths increases as shown in Fig. 9, therefore H(p)% would also increase as it is the ratio between H(p) and MaxH(p). For example, using 5 intersected paths gives H(p)% of 73.21%, while using 8 intersected paths H(p)% rises by 19.25% to give 87.3%. At 10 intersected paths, H(p)% increases by 6.87% to provide 93.31%, which indicates that the user has successfully achieved a location privacy level which is very near to the maximum theoretical location privacy upperbound. Second, Fig. 11 shows the Tracking Success Ratio for each number of the posteriori intersected paths from 2 to 10.

Ni

CumH( p )   H ( p ) i 1

(10)

Where Ni is the total number of points of posteriori intersections between 2 or more posteriori intersected paths. As shown in (10), several points of intersections are used in chain to accumulate the unlinkability achieved by each point of intersection. Also, it is clear that the cumulative entropy depends on the total number of points of intersections. Points of intersections User C, pathC User A, pathA

User B, pathB

Fig.8. Points of intersections between 3 intersected paths of 3 users, where total number of points of intersections Ni is 3.

Finally, we have calculated the percentage increase in each of: the Path Entropy H(p), the maximum Entropy MaxH(p), and the percentage Entropy H(p)% for a user path p, using the following equation: Percentage Change % = (new Entropy – old Entropy) * 100% old Entropy (a) (11)

Besides that, we have calculated the percentage decrease in the Tracking Success Ratio for a user path p, using the following equation: Percentage Change % = (new ratio – old ratio) * 100% (b) (11) old ratio

It is worthy to notice that in case of Entropy, the percentage change gives positive values; while in case of Tracking Success Ratio, the percentage change gives negative values. Thus indicating that the Entropy continues to increase which causes a continuous decrease in the Tracking Success Ratio. B. Part II: Results In this part, we will show and analyze the results obtained from our simulation.

34

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) 7

6

Entropy (bits)

MaxH(p) 5

H(p) MaxH(p)

H(p) 4

3

2

1 2

3

4

5

6

7

8

9

10

Number of intersected paths

Fig. 9. User Path Entropy H(p) and maximum Path Entropy MaxH(p) for each number of intersected paths from 2 to 10. 95

Percentage Entropy (%)

90 85

H(p)% 80 75 70 65 60 55 50 2

3

4

5

6

7

8

9

10

Number of intersected paths

Fig. 10. User Percentage Entropy H(p)% for each number of intersected paths from 2 to 10.

As shown in Fig. 11, when the total number of posteriori intersected paths increases, the Tracking Success Ratio significantly decreases. This is because as shown in Fig. 9, as the total number of intersected paths increases, the entropy significantly increases. This causes a remarkable increase in the user’s location privacy level as shown is Fig. 10, which leads to a significant decrease in the Tracking Success Ratio. For example, using 5 intersected paths gives a tracking ratio of 0.26, while using 8 intersected paths the tracking ratio falls down by 52.63% to give 0.12. At 10 intersected paths, there is another remarkable decrease in the tracking ratio by 47.28% reaching 0.06, which implies that the probability of tracking a user path p by an adversary is very low that leads to a significant increase in the user’s location privacy. Finally, the Cumulative Entropy CumH(p) for each number of posteriori intersected paths from 2 to 10 is shown Fig. 12.

As the total number of points of posteriori intersections between posteriori intersected paths increases from 1 to 5, the Cumulative Entropy CumH(p) significantly rises as shown Fig. 12. For example in Fig. 12a with 5 intersected paths, 2 points of intersections provide CumH(p) of 6.8 bits, while using 5 points of intersections makes CumH(p) jumps to 17 bits. Also, as shown in Fig. 12b with 7 intersected paths, 2 points of intersections give CumH(p) of 9.3 bits, while using 5 points of intersections allows CumH(p) to significantly rise to 23.25 bits. Moreover, as shown in Fig. 12c with 10 intersected paths, 2 points of intersections achieve CumH(p) of 12.4 bits, while using 5 points of intersections leads CumH(p) to remarkably jump to 31 bits. This means that the user path p is indistinguishable among 231 paths, thus leading to a strong location privacy protection even in the presence of a strong adversary with high computation power and capabilities (as discussed in Section II.B).

35

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) 0.5

Tracking Success Ratio

0.45 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 2

3

4

5

6

7

8

9

10

Number of intersected paths

Fig. 11. Tracking Success Ratio for each number of intersected paths from 2 to 10

C. Part III: Discussion In this part, we will briefly discuss the results obtained from our simulation that were shown in Part II of this section. Our results showed that H(p), MaxH(p) and H(p)% increases as the total number of posteriori intersected paths increases. This is because when the total number of intersected paths increases, the prospective path confusion to an adversary increases as well. Thus, causing location privacy of a user to increase as shown by H(p), MaxH(p) and H(p)% in results. In addition, the size of an anonymity set of a user path p (that contains all vehicles that are equally likely to have path p) increases as the total number of intersected paths increases. On the other hand, the Tracking Success Ratio decreases as the total number of intersected paths increases. This is due to an increase in path confusion which makes it difficult for an adversary to track a vehicle. To sum up, as the total number of posteriori intersected paths increases, the prospective path confusion to an adversary increases; which causes an increase in the user’s location privacy (entropy), while a decrease in the tracking ratio of an adversary. Results showed that using our location privacy approach, a user becomes indistinguishable among 73.51 user paths and can achieve a location privacy level up to 93.31%. While, the probability of tracking a user path p by an adversary falls down to 0.06. Moreover, the Cumulative Entropy CumH(p) jumps as the total number of points of posteriori intersections between posteriori intersected paths increases. The reason is that as the total number of points of intersections between paths increases, the prospective path confusion to an adversary increases too, which results in an increase in the user’s location privacy.

We have shown that the accumulation of location privacy and anonymity over points of intersections between paths increases almost linearly. Consequently, the Tracking Success Ratio of an adversary in tracking the vehicle’s path p correctly from source to destination becomes negligible. Furthermore, the achieved location privacy varies linearly in the number of bits, while exponentially in the number of paths. For example, a vehicle path p has made 5 points of intersections with other 9 user paths (i.e. a total of 10 intersected paths), gathers on average 31 bits of location privacy and becomes indistinguishable among 231 paths. Thus, from the results obtained, it is clear that our approach is capable of providing practical and strong location privacy and anonymity to vehicle users; in the presence of both weak adversary and strong adversary with unlimited capabilities. VII. CONCLUSION AND FUTURE WORK In this paper, we studied the problem of providing location privacy and anonymity while using LBS applications in VANET. We proposed a solution that maintains location privacy of a user while accessing real-time applications. Unlike existing works, we provide real-time location privacy and anonymization for drivers without compromising real-time service availability and accuracy. Our location privacy approach uses group navigation combined with the use of mobility prediction and prospective path confusion, in order to mitigate tracking of a vehicle. Combined usage of Path Prediction and Paths Intersection (performed by group leader) create a series of posteriori intersected paths, which provide a prospective form of path confusion.

36

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) 18

2 Paths 3 Paths 4 Paths 5 Paths

Cummulative Entropy (bits)

16 14 12

5 Paths

10

4 Paths 8

3 Paths 6

2 Paths

4 2 0 1

1.5

2

2.5

3

3.5

4

4.5

5

Total number of intersected points (a) 24

6 Paths 7 Paths

Cummulative Entropy (bits)

22 20 18 16

7 Paths

14 12

6 Paths

10 8 6 4 1

1.5

2

2.5

3

3.5

4

4.5

5

Total number of intersected points (b)

Cummulative Entropy (bits)

35

8 Paths 9 Paths 10 Paths

30

25

9 Paths 10 Paths

20

15

8 Paths 10

5 1

1.5

2

2.5

3

3.5

4

4.5

5

Total number of intersected points (c) Fig. 12. Cumulative Entropy CumH(p) for each number of intersected points from 1 to 5 between (a) 2, 3, 4 and 5 intersected paths, (b) 6 and 7 intersected paths, (c) 8, 9 and 10 intersected paths.

37

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) In our scheme, we have used group leader as an intermediate entity between requestor (i.e. vehicle) of application and RSU in order to enhance the user’s privacy and anonymity. Besides that, we have proposed an "n-1 key forwarding mechanism” for a secure and private key renewal of the vehicle's key pairs. Moreover, we have used a variety of techniques in our approach to increase the security and privacy of drivers such as: timestamps, Reqmask, message signing and encryption. Our solution provides a Blind LBS provider, that has zero-information about a vehicle and blindly provides a service to a vehicle. In our solution, we have applied the real life concept (to an old group leader) that sates: “Finish all your received jobs then you can go on a holiday.” This concept allows the old group leader to process all the requests (previously received while being the GL at that time) from its group members while not being the current GL. Moreover, our approach offers protection against both a n internal adversary (semi-trusted and untrusted entities) and an external adversary. In our solution, we prevent identification of driver and disclosure of private information of vehicle; such as: identity, locations and pseudonyms of a vehicle. Besides, we avoid linking of a vehicle to a specific application request (anonymity). In addition to all of the benefits mentioned, our scheme provides a variety of security services for vehicles in VANET, such as: sender authentication, message integrity, privacy and confidentiality, non-repudiation and accountability. Also, besides to the attacks mentioned, our solution gives a strong protection against other attacks such as: masquerade and replay attacks. Furthermore, our approach helps in saving both pseudonyms and computation effort (and time) of a vehicle and keeping it silent, which prevents linking of vehicle’s pseudonyms (i.e. tracking). We offer faster response to an application request sent by a vehicle and more tolerance to network delays, which is suitable for real-time applications. Unlike previous location privacy methods, our approach takes into consideration VANET constraints, such as: dynamic network topology, rotating role of group leader, and variable vehicle’s address (pseudonym). Thus, our solution is capable of achieving high quality-of-service for real-time applications in VANET, while enhancing the location privacy and anonymity of a vehicle’s driver. In our work, we have modeled analytically and evaluated by means of simulations the location privacy and anonymity achieved by our approach. We have measured the location privacy of a vehicle’s driver by the uncertainty of an adversary and quantified that as the Entropy of a given user.

The level of location privacy of a specific user can be determined by the ratio of the user’s current entropy and the maximum possible entropy within the given system. Besides that, we have provided that an anonymity set of a user path p contains all vehicles that are equally likely to have path p and is equal to (size of an anonymity set) the total number of posteriori intersected paths. In addition, we have used the Tracking Success Ratio to measure the success of an adversary to track the vehicle’s path p correctly from source o to destination d. The feasibility of our solution is supported by means of different simulations and results. Our results show that, as the total number of posteriori intersected paths increases, the prospective path confusion to an adversary increases. This leads to an increase in both the user’s location privacy (Entropy) and the size of an anonymity set, while a decrease in the tracking ratio of an adversary. We have shown that, although the location privacy of a user’s path p (for only one point of intersection with other user paths) can be relatively low in some cases, the accumulated location privacy and anonymity (for more than one point of intersection with other user paths) is generally very high. This causes the tracking ratio to become negligible. Finally, we believe that our approach paves the way to a practical implementation of VANET that accounts for VANET constraints while taking into consideration the privacy issues of vehicle drivers. Although there is a tradeoff between quality-of-service of real-time applications and location privacy of drivers, this study has shown that this relationship is not necessarily a zero-sum game. In our future work, we will extend our approach into different directions. First, we will investigate the interrelations among vehicles within a system in order to determine the location privacy of the whole system. Second, we are going to further evaluate our work on different scenarios. Finally, we will evaluate our solution under more realistic mobility for vehicles, combined with map data, and with communication traffic models. REFERENCES [1]

[2]

[3]

38

W. Karim, “Privacy Implications of Personal Locators: Why You Should Think Twice before Voluntarily Availing Yourself to GPS Monitoring,” Wash. U.J.L. & Pol’y, vol. 14, pp. 485, 2004. [Online]. Available: http://digitalcommons.law.wustl.edu/wujlp/vol14/iss1/16 L. Barkhuus and A. Dey, “Location-Based Services for Mobile Telephony: a study of users’ privacy concerns,” Proc. Interact, pp. 709–712, 2003. M. Gruteser and D. Grunwald, “Anonymous usage of location-based services through spatial and temporal cloaking,” in Proc. of the ACM MobiSys, pp. 31–42, 2003.

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) [4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13] [14]

[15] [16]

[17]

[18]

[19]

[20]

[21]

M. Raya, P. Papadimitratos and J.-P. Hubaux, “Securing vehicular communications,” in IEEE Wireles Communications Magazine, 2006. P. Papadimitratos, V. Gligor and J.-P. Hubaux, “Securing vehicular communications - assumptions, requirements, and principles,” in Proceedings of Workshop on Embedded Security in Cars, ESCAR, 2006. M. Raya and J.-P. Hubaux, “Securing Vehicular Ad Hoc Networks,” Journal of Computer Security, Special Issue on Security of Ad Hoc and Sensor Networks, vol. 15, no. 1, pp. 39-68, 2007. P. Papadimitratos, A. Kung, J.-P. Hubaux and F. Kargl, “Privacy and identity management for vehicular communication systems: A position paper,” in Proceedings of Workshop on Standards for Privacy in User-Centric Identity Management, 2006. P. Papadimitratos, L. Buttyan, J.-P. Hubaux, F. Kargl, A. Kung and M. Raya, “Architecture for secure and private vehicular communications,” in Proceedings of 7th IEEE International Conference on ITS Telecommunications ITST, 2007. G. Calandriello, P. Papadimitratos, A. Lloy and J.-P. Hubaux, “Efficient and robust pseudonymous authentication in vanets,” in The Fourth ACM International Workshop on Vehicular Ad Hoc Networks (VANET), 2007. J. Meyerowitz and R. Roy Choudhury, “Hiding Stars with Fireworks: Location Privacy through Camouflage,” in MobiCom’09, 2009. J. Meyerowitz and R. Roy Choudhury, “Realtime Location Privacy Via Mobility Prediction: Creating Confusion at Crossroads,” in Proceedings of ACM HotMobile, 2009. K. Sampigethaya, L. Huang, M. Li, R. Poovendran, K. Matsuura and K. Sezaki, “CARAVAN: Providing location privacy for VANET,” in Proceedings of Embedded Security in Cars, ESCAR, 2005. 5.9GHz DSRC. http://grouper.ieee.org/groups/scc32/dsrc/index.html J. Freudiger, M. Raya, M. Felegyhazi, P. Papadimitratos and J.-P. Hubaux, “Mix-zones for location privacy in vehicular networks,” in WiNITS, 2007. M. Raya and J.-P. Hubaux, “The security of vehicular ad hoc networks,” in SASN, 2005. J.-P. Hubaux, S. Capkun and J. Luo, “The security and privacy of smart vehicles,” IEEE Security and Privacy Magazine, vol. 2, no. 3, pp. 49-55, May-June 2004. M. Burmester, E. Magkos and V. Chrissikopoulos, “Strengthening Privacy Protection in VANETs,” IEEE International Conference on Wireless and Mobile Computing, WIMOB, pp. 508–513, October 2008. M. E. Zarki, S. Mehrotra, G. Tsudik and N. Venkatasubramanian, “Security issues in a future vehicular network,” in European Wireless, 2002. S. Gaonkar, J. Li, R. Roy Choudhury, L. Cox and A. Schmidt, “Micro-blog: Sharing and querying content through mobile phones and social participation,” in ACM MobiSys, 2008. B. Bergstein, “Mit students show power of open cellphone systems,” Associated Press, May 2008. [Online]. Available: http://www.usatoday.com/tech/products/2008-05-13-locale-mit N.htm J. Krumm, “Inference attacks on location tracks,” in Pervasive Computing, May 2007.

[22] K. Sampigethaya, M. Li, L. Huang and R. Poovendran, “AMOEBA: Robust Location Privacy Scheme for VANET,” IEEE Journal on Selected Areas in Communications, JSAC, Special issue on Vehicular Networks, 2007. [23] F. Schaub, Z. Ma and F. Kargl, “Privacy Requirements in Vehicular Communication Systems,” International Conference on Computational Science and Engineering, vol. 3, pp.139-145, 2009. [24] R. Shokri, J. Freudiger and J.-P. Hubaux, “A Unified Framework for Location Privacy,” Hot Topics in Privacy Enhancing Technologies, HotPETs, 2010. [25] P. Golle and K. Partridge, “On the anonymity of home/work location pairs,” in Pervasive '09: Proceedings of the 7th International Conference on Pervasive Computing, pp. 390-397, Berlin, Heidelberg, 2009. [26] B. Hoh, M. Gruteser, H. Xiong and A. Alrabady, “Enhancing security and privacy in traffic-monitoring systems,” IEEE Pervasive Computing, vol. 5, no. 4, pp. 38-46, 2006. [27] L. Sweeney, “k-anonymity: A model for protecting privacy,” International Journal on Uncertainty, Fuzziness and Knowledgebased Systems, vol. 10, no. 5, pp. 557–570, 2002. [28] B. Gedik, L. Liu and G. Tech, “Location Privacy in Mobile Systems: A Personalized Anonymization Model,” Proceedings of the 25th IEEE International Conference on Distributed Computing Systems, ICDCS, pp. 620–629, 2005. [29] M. Gruteser and X. Liu, “Protecting privacy in continuous locationtracking applications,” IEEE Security & Privacy Magazine, vol. 2, no. 2, pp. 28–34, 2004. [Online]. Available: http://ieeexplore.ieee.org/iel5/8013/28622/01281242.pdf?arnumber= 128124 [30] M. Gruteser and B. Hoh, “On the anonymity of periodic location samples,” Proceedings of the Second International Conference on Security in Pervasive Computing, 2005. [Online]. Available: http://www.winlab.rutgers.edu/gruteser/papers/gruteser_anonymityp eriodic.pdf [31] A. R. Beresford and F. Stajano, “Location Privacy in Pervasive Computing,” IEEE Pervasive Computing, vol. 2, no. 1, pp. 46–55, January 2003. [Online]. Available: http://www.csl.mtu.edu/cs6461/www/Reading/Beresford03.pdf [32] B. Hoh, M. Gruteser, H. Xiong and A. Alrabady, “Preserving privacy in gps traces via uncertainty-aware path cloaking,” in Proceedings of the 14th ACM conference on Computer and communications security, pp. 161–171, 2007. [33] P. Lewis, “Big Brother is watching: surveillance box to track drivers is backed,” The Guardian, 31 March 2009. [Online]. Available: http://www.guardian.co.uk/uk/2009/mar/31/surveillance-transportcommunication-box [34] H. Dok, H. Fu, R. Echevarria and H. Weerasinghe, “Privacy Issues of Vehicular Ad-Hoc Networks,” International Journal of Future Generation Communication and Networking, vol. 3, no. 1, March 2010. [35] A. Wasef and X. S. Shen, “REP: Location Privacy for VANETs Using Random Encryption Periods,” Mobile Netw Appl, pp. 172– 185, 2010. [36] R. Shokriy, C. Troncosoz, C. Diazz, J. Freudigery and J.-P. Hubaux, “Unraveling an Old Cloak: k-anonymity for Location Privacy,” WPES’10, 4 October 2010.

39

International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 11, November 2012) [37] B. Wiedersheim, Z. Ma, F. Kargl and P. Papadimitratos, “Privacy in Inter-Vehicular Networks: Why simple pseudonym change is not enough,” IEEE/IFIP WONS, 2010. [38] X. Xue and J. Ding, “LPA: a new location-based privacy-preserving authentication protocol in VANET,” Security Comm. Networks, pp. 69–78, 2012. [39] M. A. Moharrum and A. A. Al Daraiseh, “Toward Secure Vehicular Ad-hoc Networks: A Survey,” IETE Technical Review, vol. 29, 2012. [40] G. Calandriello, P. Papadimitratos, J.-P. Hubaux and A. Lioy, “On the Performance of Secure Vehicular Communication Systems,” IEEE Transactions on Dependable and Secure Computing, vol. 8, pp. 898-912, 2011.

[41] E. Magkos, “Cryptographic Approaches for Privacy Preservation in Location-Based Services: A Survey,” International Journal of Information Technologies and Systems, 2011. [42] Z. Ma, F. Kargl and M.Weber, “A location privacy metric for V2X communication systems,” in IEEE Sarnoff Symposium, Princeton, NJ, USA, March 2009. [43] C. E. Shannon, “A mathematical theory of communication,” Bell system technical journal, vol. 27, pp. 379–423, 623–656, July, October 1948. [44] L. Buttyan, T. Holczer and I. Vajda, “On the effectiveness of changing pseudonyms to provide location privacy in vanets,” in ESAS, pp.129-141, 2007.

40