Self-Controllable Secure Location Sharing for Trajectory-Based Message Delivery on Cloud-Assisted VANETs.

In vehicular ad hoc networks, trajectory-based message delivery is a message forwarding strategy that utilizes the vehicle’s preferred driving routes information to deliver messages to the moving vehicles with the help of roadside units. For the purpose of supporting trajectory-based message delivery to a moving vehicle, the driving locations of the vehicle need to be shared with message senders. However, from a security perspective, vehicle users do not want their driving locations to be exposed to others except their desired senders for location privacy preservation. Therefore, in this paper, we propose a secure location-sharing system to allow a vehicle user (or driver) to share his/her driving trajectory information with roadside units authorized by the user. To design the proposed system, we put a central service manager which maintains vehicle trajectory data and acts as a broker between vehicles and roadside units to share the trajectory data on the cloud. Nevertheless, we make the trajectory data be hidden from not only unauthorized entities but also the service manager by taking advantage of a proxy re-encryption scheme. Hence, a vehicle can control that only the roadside units designated by the vehicle can access the trajectory data of the vehicle.

1. Introduction

For the last decade, vehicular ad hoc networks (VANETs) have attracted a great deal of attentions due to the development of vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication technologies. It is a trend of modern vehicles to equip on-board unit (OBU) devices which allow vehicles to communicate with each other as well as roadside units (RSUs) [1]. As a result, up to date, various VANET applications using V2V and V2I communications have been presented to realize not only comfortable driving conditions but also valuable infotainment services on the road. Furthermore, recently, the concept of vehicular networking is extended to vehicular cloud computing by integrating vehicular communications with cloud computing to provide vehicles with pervasive services on the road [2,3,4].

One of the promising applications is a location-aware service [5] which provides vehicles with useful information for a certain geographic area of interest by taking advantage of vehicular cloud computing. Based on vehicular cloud computing technologies, RSUs deployed on the certain areas can collect and provide local-interesting information to vehicles such as traffic conditions and available facilities. However, it is challenging on the VANET how we can effectively deliver such service messages to vehicles which are continuously moving on the road. Due to the dynamic mobility and opportunistic connectivity in VANETs, the probability of successful hop-by-hop (among neighboring vehicles) message forwarding to a destination vehicle at a long distance is low and it would result in high message loss. As a solution to this challenge, trajectory-based message delivery with the help of RSUs in VANETs have been researched [6,7].

For example, let us consider a scenario as shown in Figure 1 in which the area around is an interested spot (named socialspot) of a vehicle and provides location-aware service around its local area to . By using trajectory-based message delivery, it would be possible that can efficiently disseminate the service messages to through and acting as relay nodes along ’s trajectory assuming that knows the driving path of .

Figure 1

Service scenario of trajectory-based message delivery.

On the other hand, driving route or location information of a vehicle is regarded as personal data of the driver, so location privacy is one of the critical security requirements for VANETs as well as identity privacy preservation. In the above trajectory-based message delivery environment, if a vehicle needs to share its driving route with message senders (sRSUs) deployed on some socialspots in which the vehicle is interested for location-aware service, how to share vehicle’s trajectory securely with the sRSUs in the system for privacy preservation is required. In other words, the system must be carefully designed not to expose the driving locations of a vehicle to other entities except the sRSUs designated by the vehicle.

1.1. Related Work

While various VANET applications have been emerging, studies on secure vehicular communications have also been widely performed [4,8,9,10,11,12,13,14,15,16]. One of the challenging issues is privacy-preserving vehicular communications for protecting location privacy of vehicles in VANETs. To prevent a global eavesdropping attacker from tracking a target vehicle, most privacy-preserving secure vehicular communications recommend using anonymous authentication schemes based on a group signature or pseudonymous credentials of vehicles when exchanging messages [17]. In addition to sender’s anonymity, to achieve message receiver’s location privacy preservation in VANETs, Lu et al. [18] and Lin et al. [19] proposed secure RSU-assisted message delivery protocols from a source vehicle to a destination vehicle, respectively. However, their work assumes that a receiver vehicle is stationary at a fixed location [18] and the location of a receiver is already known to senders beforehand [19].

For efficient message delivery from an RSU to moving vehicles in VANETS, Jeong et al. proposed an architecture for trajectory-based data delivery [7]. Their work was not focused on security mechanisms for protecting location privacy of vehicles. Instead, they just assume that a control center maintains vehicle trajectories and will not expose the trajectory data to others. In their system, we cannot help but rely on the control center that the center will carry out its role faithfully. However, from user’s viewpoint, the control center may be also a source of concern and users want to control who can access their trajectory data by themselves with a proper security mechanism.

With regard to secure location-sharing in mobile environments, the works in [20,21,22,23,24] proposed some methods to protect user’s privacy for location-sharing in mobile online social network services. They are mainly focused on a proximity application to find a nearby friend whose current location is within some distance. Some previous work did not consider preventing a service provider from accessing user’s locations data except the work of [20,24]. Even though a service provider is usually involved in location sharing services to distribute the location data of one user to other authorized users, the provider does not need to know the data content. Freudiger et al. [20] and Li et al. [24] proposed a system for protecting user location data from the provider by using data encryption, respectively. However, if a user wants to share his/her location data with multiple friends, the user has to generate multiple encrypted data for the same location data under a different key of each friend or needs interactions to establish a shared secret key with his friends. It burdens the user with computation and communication overheads proportional to the number of friends.

Dong et al. introduced a concept of secure location-sharing based on a proxy re-encryption scheme for mobile applications [25]. Proxy re-encryption is a cryptographic technique to allow a semi-trusted proxy to convert a ciphertext under one party’s public key (e.g., in our scenario) into a new ciphertext under another party’s public key (e.g., designated by ). While the proxy uses re-encryption keys to perform the conversion, the proxy cannot learn any information about the underlying plaintext. Dong et al. presented an idea that a user can efficiently share its location data with other users as shifting computational overheads for distributing encrypted location data to a proxy, and their idea motivated our work. However, if we adopt an ordinary public key based proxy re-encryption scheme, has to be involved in generating a re-encryption key to be used for converting a ciphertext by giving its public key certificate to . Moreover, to revoke a re-encryption key of an unwanted and update re-encryption keys of other valid parties, must change its public key and obtain a new public key certificate. Such interactions are not always available in VANET environments due to the occasional connectivity. Therefore, we need to devise a more flexible and practical method to manage the keys for proxy re-encryption scheme in our VANET service scenario.

In our previous work [26], we presented a secure location sharing based on an id-based proxy re-encryption scheme as considering the non-interactive property of id-based public key cryptography. However, to revoke or update re-encryption keys in the previous work, this system needs to renew user’s identity functioning as a public key but it may be impractical to change the identity used in the system. As an alternative, in this paper, we employ a certificateless proxy re-encryption scheme which can provide more flexible key management to our self-controllable secure location-sharing system.

1.2. Our Contribution

Based on the above considerations, in this paper, we propose a secure driving location (trajectory) data sharing system for trajectory-based message delivery in VANETs which can prevent the shared location data on the cloud from being illegitimately exposed to others. We consider a location-aware service scenario in which a vehicle allows some socialspot RSUs designated by the vehicle to access its preferred driving trajectory data stored on the cloud. For secure vehicular communications, group signatures or pseudonymous credentials have been used for anonymous authentication so that the identity and location of a vehicle cannot be linked and tracked on VANETs. However, the main goal of our work is to securely share the trajectory data of a vehicle with only authorized entities from confidentiality view point and to control who can access the location data by vehicle itself. To achieve our goal, we present a system architecture for sharing the trajectory data of vehicles with the help of a service manager acting as a broker between vehicles and socialspot RSUs, then design a secure location-sharing and authenticated message delivery protocols by making use of a certificateless proxy re-encryption scheme and an id-based signature scheme with pseudonymous identities.

In our proposed system, a vehicle can upload driving trajectory data encrypted under its own public key to a semi-trusted service manager on the cloud. The uploaded trajectory data are coupled with re-encryption keys associated with the designated socialspot RSUs so that the manager re-encrypts vehicle’s trajectory data and distributes to the intended socialspot RSUs. Then, the socialspot RSUs can send service messages to the vehicle by way of some RSUs along the driving route of the vehicle. We make the vehicle revoke the access rights of unwanted socialspot RSUs by changing vehicle’s public key and re-encryption keys but the vehicle does not need to obtain a certificate for the new public key. Therefore, the proposed system can be self-controllable and more flexible.

The rest of this paper is organized as follows: We first present a system architecture and security considerations in Section 2 and cryptographic building blocks to design the proposed system in Section 3. Then, we describe our proposed secure location-sharing and authenticated message delivery protocols in Section 4. We discuss the security and performance of our protocol in Section 5, and finally conclude this paper in Section 6.

2. System Architecture

2.1. Architecture

To design a secure location-sharing system for trajectory-based message delivery on VANETs, we consider the system architecture shown in Figure 2 which consists of trusted authority (TA), service manager (SM), roadside units, and vehicles.

Figure 2

System Architecture.

TA is a fully trusted entity responsible for managing security parameters for the system and issues id-based key pairs to the registered RSUs and vehicles denoted as and , respectively. TA also manages pseudonymous identities for the vehicles to guarantee anonymity of vehicles on VANET communications.

SM is a manager which provides storage service on the cloud. To support secure trajectory data sharing, SM maintains encrypted trajectory data of vehicles and acts as a broker which handles to distribute re-encrypted trajectory data to RSUs authorized by the vehicle of the trajectory owner.

RSUs are subordinated to the TA and sparsely deployed on the roads such as main intersections, and their geographical location information are available through the system. The roles of RSUs in are divided into socialspot RSUs and relaying RSUs. Socialspot RSUs (sRSUs), denoted as , are deployed on the specific locations of interest. A set of RSUs establish a local cloud with dedicated servers so that they collect and provide location-aware information to vehicles by means of trajectory-based message delivery. On the other hand, a relaying node RSU equips storage for temporarily holding messages to support message forwarding to the destination vehicles passing by its coverage.

Vehicles are equipped with OBU and GPS-based navigation system with digital maps. A registering vehicle selects sRSUs among in which is interested and generates a re-encryption key for the selected sRSUs to share its driving trajectory data through the cloud storage under the control of SM. Whenever changes its preferred driving route, uploads its encrypted driving route data to SM.

Moreover, to clarify the proposed system, we also make the following assumptions.

Public security parameters of TA are already known to all entities in the system.

SM and socialspot RSUs are interconnected to each other through a secure and reliable channel.

Locations and identities of RSUs are publicly available to the system so that vehicles can know which RSUs are deployed at which locations.

2.2. Threat Model and Security Considerations

In our system architecture, we consider two types of attack. One is an attack by a compromised SM. In other words, we assume that SM is a honest-but-curious entity that will follow the protocol but may try to extract vehicle’s driving trajectory data stored on the cloud for the purpose of collecting and profiling driver’s preferences. The other is an attack by an outside attacker which has no access privilege to the cloud but try to learn vehicle’s driving locations over VANET communications. However, when we assume that SM and RSUs are interconnected through a secure channel, it is hard for an outsider attacker to control the communications between SM and an RSU. In addition, we assume that all RSUs are trusted under the control of the TA so that SM is not allowed to collude with any RSU. Thus, it is assumed that TA can inspect all RSUs subordinated to it and the collusion or compromise of an RSU is detectable by the TA.

Under the threat model and assumptions, we consider the following security requirements to design a secure vehicle trajectory data sharing system and message delivery protocol to guarantee the location privacy of vehicles in VANETs.

Authorized access to trajectory data: Access to driving trajectory data of a vehicle on the cloud must be restricted to only the RSUs authorized by the owner vehicle of the trajectory data. Even though vehicle’s trajectory data are managed under the control of SM, driving trajectory data must be hidden from SM as well as unauthorized entities.

Self-control: When a vehicle uploads its trajectory data to SM, it should be possible for the vehicle to control that which RSUs can or cannot access its trajectory data by the vehicle itself.

Authenticated communications: For secure message delivery on VANETs, vehicles and RSUs involved in message delivery must be authenticated to each others. In message forwarding, a relaying RSU must authenticate a vehicle to check if the vehicle is a valid destination specified in the message. Besides, a vehicle must be convinced that the received message originated from a valid source claimed in the message.

Avoiding location tracking: While a vehicle connects to RSUs on its driving routes to receive messages, driving trajectory of the vehicle must not be tracked by an outside attacker on VANETs. That is, it must be hard for an outside attacker to learn that a vehicle has moved from and to which of RSUs by overhearing vehicle-to-RSU communications.

3. Preliminaries

Before presenting our proposed system, in this section, we briefly outline the properties of a bilinear map and introduce some cryptographic schemes using a bilinear map which serve as the basis of the proposed system. More specifically, we design the proposed system using certificateless proxy re-encryption and id-based signature schemes with pseudonymous identities of vehicles.

3.1. Bilinear Map

Let and be two cyclic groups of the same prime order q. There is a bilinear map satisfying the following properties.

Bilinear: , for all and .

Non-degenerate: If g is a generator of , then is a generator of .

Computable: is efficiently computable for any .

3.2. Cryptographic Building Blocks

As our building blocks, we adopt a certificateless proxy re-encryption (CL-PRE) scheme [27] and an id-based signature (ID-SIG) scheme [28] described in the followings.

Setup(): A private key generator chooses bilinear map groups of the same prime order q, random generators , and hash functions , , . It also chooses a random as a master secret then computes , , . Public system parameters are set as .

idKeyGen(s, ): Given an identity , this algorithm outputs an id-based private key under the master secret key s of a private key generator.

SetPrvKey(): Given a generated by idKeyGen for an , this algorithm chooses random values and sets as a private key for CL-PRE for a user of the .

SetPubKey(): This algorithm returns a public key corresponding to for CL-PRE.

clEnc(m, , ): Certificateless encryption algorithm generates a ciphertext for a given message m under the and as follows:

Choose a random for a security parameter .

Compute .

Compute , , , and where .

Output the ciphertext .

clReKeyGen(, , , , ): Re-encryption key generation algorithm returns a proxy re-encryption key as follows:

Choose a random and compute .

Compute , , and where and , respectively.

Output the re-encryption key .

clReEnc(, , C, ): Given a ciphertext C under the identity and public key , this algorithm outputs a re-encrypted ciphertext delegated to under the as follows:

Parse C as

Compute and .

If and holds,

Set the re-encrypted ciphertext , where , , , and .

clReDec(, ): Given a re-encrypted ciphertext delegated to from , decryption algorithm outputs the message m as follows:

Parse as .

Compute where , and .

Compute .

Compute .

If and holds, return m. Otherwise output ⊥.

idSig(, m): On input an id-based secret key and a message m, this algorithm computes a signature S for the m as follows:

Pick a random and compute .

Set the signature , where and .

idVrf(, m, S): ID-based signature verification algorithm accepts the message m if holds, where .

4. Proposed System

In this section, we describe the proposed secure trajectory data sharing system for supporting trajectory-based message delivery protocol on VANETs by making use of cryptographic techniques presented in Section 3. The proposed system consists of setup, enrolment, trajectory sharing, and message delivery phases. Table 1 shows the notations used to describe the proposed protocol.

Table 1

Notations and descriptions.

Notation	Description
G_1, G_2	bilinear map groups of a prime order q
e:G_1×G_1→G_2	bilinear map
g,h∈G_1	generators of G_1
s∈Zq∗	master secret key of TA
g^s	public key of TA corresponding to s
RSU_i	identity of a roadside unit
sRSU_j	identity of a socialspot RSU
rsk_j	id-based secret key for an RSU_j
pid_di	i-th pseudonym of a vehicle V_d
vsk_di	id-based private key of a vehicle V_d for pid_di
sk_X, pk_X	private and public key of X for CL-PRE
rk_V_d→sRSU_j	re-encryption key of V_d to sRSU_j
ts	current timestamp
Enc_k()	symmetric encryption under the key k
Dec_k()	symmetric decryption under the key k
MAC_k()	message authentication code under the key k

4.1. Setup

TA first picks a random as its master secret and runs Setup() algorithm to generate public system parameters . TA also issues id-based secret keys to RSUs and vehicles registered to the system. Note, at this phase, we assume that id-based secret keys can be issued to RSUs and vehicles through an out-of-band secure channel before they participate in VANETs. Let be the RSUs subordinated by the TA and be the registering vehicles. For each , TA generates ’s id-based secret key idKeyGen(s, ) and preloads to each securely. Then, sets its private key as SetPrvKey() and public key SetPubKey() for CL-PRE.

On the other hand, for a vehicle , TA chooses pseudonymous identities for after checking the eligibility of . TA issues ’s id-based secret keys idKeyGen(s, ) for each . In our system, is used for re-encryption procedure while are used for VANET communications. When obtaining id-based keys for the pseudonyms, sets its private key and public key for proxy re-encryption procedure as SetPrvKey() and public key SetPubKey() for CL-PRE. Then, each and each , respectively, store and to the cloud storage so as for them to retrieve the public key of each others.

4.2. Enrolment

For a vehicle to receive location-aware service messages by means of trajectory-based message delivery, configures desired socialspots in which is interested for receiving the service messages and selects sRSUs installed at the socialspots denoted as . Then, to allow each to access ’s trajectory data under the control of SM using a proxy re-encryption scheme, generates the re-encryption key for each as follows:

Retrieve ’s public key from the cloud storage.

Set a re-encryption key as clReKeyGen(, , , , ).

Compose a message , , where .

entrusts , consisting of sRSUs list and re-encryption keys, to SM so as for SM to re-encrypt ’s trajectory data and delegate decryption right to each when uploads its encrypted trajectory data to SM.

4.3. Trajectory Sharing on the Cloud

Let be the driving trajectory of a vehicle consisting of some specific locations such as main roads or intersections on ’s preference driving routes. When participates in VANETs, will expects to receive service messages provided by the socialspot RSUs () of ’s interest through some contact point RSUs deployed on ’s driving trajectory . To securely share ’s trajectory data and pseudonyms used for message delivery in VANETs with the socialspot RSUs in through the cloud storage, uploads encrypted trajectory data and pseudonyms to SM as follows:

Choose a pseudonym to be used for connecting to a contact point .

Compose a pseudonym-location pair message .

Generate a ciphertext C for as clEnc(, , ) under ’s own public key.

Upload to SM, where idSig(, ) is ’s signature under the id-based secret key of .

Once uploads its trajectory sharing message to the cloud storage, SM controls to transform and provide ’s encrypted trajectory to the sRSUs in specified by as follows:

Parse as and verify the signature as idVrf(, , ) under the given .

Retrieve for the given from SM’s storage.

For each , extract and transform the ciphertext C to as clReEnc (, , C, ).

Store to ’s directory on the cloud.

While SM maintains vehicles encrypted trajectory information, each socialspot RSU, , periodically access its directory to get the updated trajectory of as follows:

Downloads from its directory on the cloud.

Decrypt to get as clReDec(, ).

Add pairs to the vehicle list .

4.4. Trajectory-based Message Delivery

Suppose that collects and provides location-aware service information, such as traffic condition, gas station, and so on. Once of is loaded, can disseminate location-aware service messages for through an deployed on around . Message delivery from to can be subdivided into three phases: (1) message distribution of to ; (2) immediate message forwarding by to if is within ’s transmission coverage; and (3) message carry-and-forwarding by other vehicles to if is out of ’s transmission coverage, as shown in the Figure 3.

Figure 3

Message forwarding from an RSU to a destination vehicle.

4.4.1. Message Distribution to RSUs

Let be a content of location-aware service provided by . In this phase, compose a message package for and distributes to ’s contact point as follows:

Extract corresponding to from .

Set a message where is ’s signature and is the message lifetime.

Distribute to nearby .

When we assume that RSUs are inter-connected, a message can be easily distributed to other RSUs. During the message delivery, a message bundle has a certain lifetime specified as so that an expired message bundle is discarded. This is for RSUs or carrying vehicles to avoid consuming their storage excessively for a long time even if a target vehicle is not met on the roads.

4.4.2. Immediate Message Forwarding

If a message is distributed to contact point RSUs, each RSU stores the received messages and forwards them when a target vehicles for the message passes by RSU’s coverage before is expired. Suppose that a vehicle enters ’s coverage and sent from for is kept by . The followings describe message forwarding protocol from to .

periodically broadcasts beacon message containing specified as a destination of .

If is found in the beacon message, sends a message request to , where is a metadata for message requesting and idSig(, ).

Upon receiving the request message, authenticates by verifying as idVrf(, , ). If it holds, sends to .

When is downloaded, checks the authenticity of the received message to be convinced whether the message actually originated from ’s desired as follows:

Parse .

Verify the signature as ; and, if it holds,

Accept as a valid message from .

4.4.3. Message Carry-and-Forwarding

If we consider that a target vehicle drives beyond contact point RSU’s transmission coverage, another strategy to deliver a message is to rely on VANET routing by means of carry-and-forwarding among neighboring vehicles on the road. For instance, to deliver a message on VANET, requests and finds a volunteer vehicle which willingly joins carrying and forwarding the message. Suppose that a vehicle within ’s range is a volunteer vehicle. For ’s request, responds acceptance message to to obtain , where is a metadata and idSig(, ). authenticates by verifying the signature under , if it holds, provides with .

Once is stored in ’s storage, carries by itself until runs into the target vehicle of on the road before is expired, or forwards to a next-hop vehicle in accordance with VANET routing protocol. For the former case, if detects on driving, sends notification message to to inform that has a message for . Then, requests the message to in authenticated manner as follows:

requests the message to by sending .

verifies the signature and forwards attached with its signature as idSig(, )}, where is a metadata for the response.

first verifies ’s signature and extracts . Then, checks if actually originated from by checking ’s signature in as described in step 2) of immediate forwarding.

On the other hand, if a message is delivered by hop-by-hop forwarding, each intermediary vehicle involved in VANET routing protocol must append its signature to the forwarded message. For instance, suppose that is a set of vehicles involved in message forwarding to the destination vehicle (Note, how to establish a route and forward a message to the destination node is beyond our scope. We can assume the existing VANET routing protocols such as [6,29]). The message arriving to consists of where is a metadata for message forwarding and is a signature of each . The last hop vehicle can forward to as described in the above. By verifying each signature under , can be convinced that the received message was forwarded via authenticated vehicles.

4.5. Trajectory Update and Sharing Revocation

After vehicles initially upload their trajectory data to SM, they can update their trajectory data whenever they want to change preference driving routes. Remind, in trajectory sharing phase in Section 4.3, ’s trajectory is uploaded to the cloud in the encrypted form of C in , and then C is transformed to a re-encrypted ciphertext by the SM to be shared with an . Suppose that ’s trajectory is changed to different driving locations but still wants to share the changed trajectory with the current sRSUs in . In this case, the operation required to is just to generate a ciphertext for the changed trajectory in accordance with the procedures of Section 4.3, and update to include on the cloud storage. Then, SM can transform to for each using the existing re-encryption keys in .

Sometimes, however, a vehicle will not wish to share the updated trajectory data with some sRSUs any more if the vehicle changes its interested socialspots. That is, a vehicle needs to revoke unwilling trajectory sharing. Suppose that does not want to share updated trajectory data with an . In the proposed system, can revoke trajectory sharing with by updating ’s private and public key pair and re-encryption keys for sRSUs except the as follows:

Renew its private key as SetPrvKey() and public key as SetPubKey() by choosing new random values .

Change the socialspot RSUs list as to by adding new sRSUs and deleting revoked sRSUs.

Set by running clReKeyGen(, , , , ) for each .

Replace the existing uploaded in enrolment phase of Section 4.2 with the updated including and .

5. Analysis

5.1. Security

5.1.1. Authorized Access to Trajectory Data

Since the locations of a vehicle can be regarded as personal information of a driver, driving trajectory data maintained on the cloud must not be exposed to not only outsiders but also SM illegally in the system. In our proposed system, a trajectory data consisting of pseudonym-location pairs of a vehicle is maintained by SM in the encrypted form under ’s public key as clEnc(, , ). Essentially, nobody can gain ’s trajectory data as trying to decrypt C without knowing ’s private key corresponding to . On the other hand, some sRSUs of ’s interested socialspots specified in need to know ’s driving trajectories for disseminating service messages through contact point RSUs along ’s driving routes. can allow an to get its trajectory data by giving a re-encryption key clReKeyGen(, , , , ) to SM instead of entrusting plaintext trajectory data. The encrypted trajectory data C are then re-encrypted to clReEnc (, , C, ) for under the key by SM. Hence, only a valid that possesses a private key corresponding to involved in can get by decrypting .

In addition to an outside attacker and unauthorized RSUs, another concern is the security threat of SM to the trajectory data managed on the cloud since a semi-honest SM may be curious to know vehicle’s driving locations for the purpose of collecting and profiling driver’s preferences. At this phase, even though the encrypted trajectory data and re-encryption keys are given to SM, it is hard for SM to deduce the private key of or for the purpose of recovering the trajectory data from C or if we assume the security properties of the underlying proxy re-encryption scheme [27]. Therefore, neither SM nor unauthorized RSUs can access vehicle’s trajectory data on the cloud unless the vehicle authorizes decryption rights for the encrypted trajectory data under re-encryption keys.

5.1.2. Self-Controllable Trajectory Sharing

In our proposed system, even though vehicle’s shared trajectory data are maintained and transferred by SM, it is the owner vehicle of the trajectory data that can decide what RSUs can access its trajectory data on the cloud. As mentioned before, distribution of the trajectory data of is performed by SM according to socialspot list and re-encryption keys generated by in the enrolment phase. If does not want an existing in to access its trajectory data any more, can revoke ’s decryption right by generating new re-encryption keys for sRSUs in except . Once uploads updated and for each sRSU in , SM will exclude and not provide with the re-encrypted trajectory data of . In our revocation procedure of Section 4.5, can generate re-encryption keys without involvement of SM and sRSUs, and it does not require renewing public keys of sRSUs due to the functionality of certificateless proxy re-encryption scheme. Therefore, our proposed system can provide a flexible and self-controllable trajectory data sharing mechanism.

5.1.3. Authenticated Vehicular Communications

To receive a service message in the form of served by sRSUs on VANETs, must be authenticated to a contact point or carrier vehicle as is the valid destination vehicle of specified in the message M. In message forwarding phase of Section 4.4, when requests a message M kept by a contact point or a carrying vehicle , must present its id-based signature idSig(, ) which is in turn verified under the given of the message M. If we assume the security of an id-based signature scheme, any vehicle which does not know the private key corresponding to except cannot forge the signature nor impersonate . Therefore, only the valid vehicle authenticated under the can receive the message M.

In addition, when receives a message M, also authenticates the message sender sRSU by verifying the attached id-based signature under the sRUS’s identity specified in M. That is, can be convinced that the message M was sent from the , in which is interested, if the signature is verified as valid under the id of .

5.1.4. Avoiding Location Tracking

Due to the access control to the trajectory data, we can prevent an outside attacker as well as any unauthorized entity from learning vehicle’s driving trajectory stored on the cloud. On the other hand, to prevent an outside attacker from tracking driving path of a vehicle by eavesdropping on the vehicle-to-RSU communications, it must be difficult for an outside attacker to guess that the observed vehicle at different RSU’s coverage is the same vehicle while a vehicle connects to contact point RSUs for receiving a message over VANET on its driving. In our proposed system, a vehicle has a set of pseudonyms , which can be independently generated random values, and it is recommended to use a different pseudonym for identification and authentication whenever connects to a different contact point deployed at the location of along ’s driving path. Therefore, we can make it hard for an outside attacker to track moving locations of a vehicle if any two pseudonyms , respectively, observed by the attacker at and are unlinkable to the same vehicle from attacker’s viewpoint.

Moreover, pairs are only known to the sRSUs authorized by by means of a re-encryption technique. Another possible attack for an outside attacker is to compromise an sRSU to extract ’s pseudonyms and driving trajectory data kept by the sRSU on the VANET. As a countermeasure to this threat, in this paper, we just assume that all RSUs are inspected by the TA and compromise of an RSU can be preventable and detectable by means of a security module such as tamper proof device. RSUs would not disclose any information without the authorization of the TA. Nevertheless, if an sRSU is detected as abused, TA can take an action to recover the sRSU and the vehicle can generate new re-encryption keys for sRSUs to protect the changed trajectory data after that.

5.2. Performance

We simulated the message delivery on VANETs to evaluate the impact of the proposed security protocol to the performance of message forwarding from RSUs to destination vehicles. We implemented the simulation by using NS-2 and SUMO [30] simulators as considering an urban road environment. Figure 4 and Table 2 show the 4600 m × 3800 m road configuration and simulation settings, respectively.

Figure 4

Road configuration for simulation.

Table 2

NS-2 simulation parameters.

Simulation Setting
road dimension	4600 m × 3800 m
# of vehicles	{30, 45, 60, 75, 90, 105, 120, 135, 150}
# of contact point RSUs	5
# of destination vehicles	15
moving speed	{40, 50, 60, 70} km/h
mobility model	Manhattan model
wireless/bandwidth	802.11 p/6 Mbps
radio coverage	250 m
message size	100 KB
message lifetime	500 s
simulation time	2000 s

For our simulation, we applied Manhattan mobility model in which each vehicle moves in horizontal or vertical direction on an urban road and the probability of going straight is 0.5 and taking a left or right is, respectively, 0.25 [31]. We varied the number of vehicles from 30 to 150 moving with 11.1 m/s (40 km/h) to 19.4 m/s (70 km/h) speed on average, and put five contact point RSUs relaying messages to 15 destination vehicles. For message carry-and-forwarding, we adopted the DTN routing protocol of [32] and adjusted message forwarding time to compensate for the delay caused by the authentication process. To measure the authentication overhead of message delivery, we used the benchmark results of pairing-based cryptography library [33] implemented on Intel Quad Core2 2.4 GHz machine by using the supersingular curve for the group with 512-bit base field size and 160-bit group order providing 1024-bit security. Then, we evaluated the performance in terms of message delivery delay and successful delivery ratio on average of 15 destination vehicles for each experiment by varying the number of vehicles and their moving speed.

Let D be the total message delay from a contact point RSU to a destination vehicle. The message delay can be estimated as where is the delay for message transmission and is for authentication process resulting from signature generation and verification. Depending on message forwarding method, can be classified as where l is the number of hops and and are the times for signature generation and verification evaluated as = 4.65 ms and = 10.93 ms, respectively. For immediate forwarding, it requires signature generation of the destination vehicle and verification of a contact point RSU before message forwarding. On the other hand, for carry-and-forwarding, authentication of the first carrier vehicle to a contact point RSU and authentication between the last hop vehicle and the destination vehicle are required while each intermediary vehicle only appends its signature to the forwarded message.

With regard to our experiments depending on the number of vehicles and the moving speed, the initial positions of vehicles are randomly generated and the distributions of vehicles on the road in each experiment are not consistent. Thus, those experiments are independent of each other and cause uneven variations in the results of Figure 5, Figure 6, Figure 7 and Figure 8. However, we would like to estimate the performance by observing the trend of changes through the experiment results.

Figure 5

Average number of hops for forwarding messages to the destination vehicles.

Figure 6

Average forwarding delay () to the number of hops burdened by authentication process.

Figure 7

Average message delivery delay (D) from contact point RSUs to the destination vehicles.

Figure 8

Successful message delivery ratio for the destination vehicles.

Figure 5 shows the average number of hops, and Figure 6 shows the average authentication delay evaluated by our simulations, respectively. We can observe that the number of intermediary vehicles participating in message forwarding is increased as the more vehicles are distributed on the road. It is obvious that the authentication delay gets longer as the number of hops are increased. However, it should be noted that the more vehicles participate in message forwarding the shorter message delay occurs, as shown in Figure 7, because the carry delay depending on the moving speed of vehicles is much longer than the communication delay. Therefore, the authentication delay is insignificant and has little effect on the total message delay.

We also evaluated the successful message delivery ratio for 500 s of message lifetime and Figure 8 shows the results. As aforementioned, if more vehicles are distributed on the VANET and move with high speed, vehicles can have more chance to meet other vehicles which results in higher possibility of message carrying-and-forwarding as well as shorter message delay. From our simulation results, we can see that almost all of the messages can be successfully delivered to the destination vehicles within 350 s when we put more than 135 vehicles moving with higher than 50 km/h speed.

6. Conclusions

Trajectory-based message delivery with the help of roadside units have been considered as an efficient message dissemination method on VANETs under the assumption that message senders know the driving routes of message receiver vehicles. However, from a security viewpoint of location privacy, users of VANETs want to limit sharing of their driving locations to the desired message senders by themselves to prevent the location information from being illegitimately exposed to others. Therefore, in this paper, we propose a secure location sharing system in which vehicles control what roadside units can access vehicles driving locations on their own decision for trajectory-based message delivery services. To effectively share vehicle’s trajectory data with the socialspot roadside units designated by the vehicle on the cloud, we devised a secure trajectory data sharing mechanism by taking advantage of a certificateless proxy re-encryption scheme in which the role of maintaining and distributing encrypted trajectory data can be delegated to a semi-trusted service manager but the access rights to the trajectory data are controlled by vehicles themselves. Therefore, even though vehicles trajectory data are managed by a service manager on the cloud, the trajectory data are hidden from not only unauthorized entities but also the service manager. In addition, whenever vehicles change their preferred driving routes, vehicles can efficiently revoke the access rights of unwanted roadside units to the updated trajectory data just by updating re-encryption keys without involvement of the service manager and roadside units. Consequently, we can design a more flexible and self-controllable secure trajectory data sharing system on VANETs.