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.


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 sRSU 1 is an interested spot (named socialspot) of a vehicle V d and sRSU 1 provides location-aware service around its local area to V d . By using trajectory-based message delivery, it would be possible that sRSU 1 can efficiently disseminate the service messages to V d through RSU 1 and RSU 2 acting as relay nodes along V d 's trajectory assuming that sRSU 1 knows the driving path of V d .
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.

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., V d in our scenario) into a new ciphertext under another party's public key (e.g., sRSU designated by V d ). 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, sRSU has to be involved in generating a re-encryption key to be used for converting a ciphertext by giving its public key certificate to V d . Moreover, to revoke a re-encryption key of an unwanted sRSU and update re-encryption keys of other valid parties, V d 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.

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.

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.

•
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 R = {RSU 1 , ..., RSU m } and V = {V 1 , ..., V n }, 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 R are divided into socialspot RSUs and relaying RSUs. Socialspot RSUs (sRSUs), denoted as SR = {sRSU 1 , ..., sRSU l } ⊆ R, 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 V d ∈ V selects sRSUs among SR in which V d 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 V d changes its preferred driving route, V d 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.

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.

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.

Bilinear Map
Let G 1 and G 2 be two cyclic groups of the same prime order q. There is a bilinear map e : G 1 × G 1 → G 2 satisfying the following properties.
is efficiently computable for any g, h ∈ G 1 .

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 (G 1 , G 2 ) of the same prime order q, random generators g, h ∈ G 1 , and hash functions It also chooses a random s ∈ Z * q as a master secret then computes g 1 = g s , g 2 =ê(g, g), g 3 =ê(g, h). Public system parameters are set as idKeyGen(s, id): Given an identity id, this algorithm outputs an id-based private key d id = g 1/(s+H 2 (id)) under the master secret key s of a private key generator. • SetPrvKey(d id ): Given a d id generated by idKeyGen for an id, this algorithm chooses random values a, b ∈ Z * q and sets sk id = (d id , a, b) as a private key for CL-PRE for a user of the id. • SetPubKey(sk id ): This algorithm returns a public key pk id = (g a 3 , g b ) corresponding to sk id for CL-PRE.
• clEnc(m, id, pk id ): Certificateless encryption algorithm generates a ciphertext for a given message m under the id and pk id as follows: 1. Choose a random α ∈ {0, 1} κ 0 for a security parameter κ 0 .
• clReKeyGen(sk id i , id i , id j , pk id i , pk id j ): Re-encryption key generation algorithm returns a proxy re-encryption key rk id i →id j as follows: 1.
Choose a random γ ∈ Z * q and compute µ = H 2 (g γ 2 |id i |pk id i |id j |pk id j ).

2.
Compute rk (1) where a i ∈ sk id i and g b j ∈ pk id j , respectively.
• clReEnc(id i , pk id i , C, rk i→j ): Given a ciphertext C under the identity id i and public key pk id i , this algorithm outputs a re-encrypted ciphertext C j delegated to id j under the rk id i →id j as follows: 1.
• clReDec(sk id j , C j ): Given a re-encrypted ciphertext C j delegated to id j from id i , decryption algorithm outputs the message m as follows: 1.
On input an id-based secret key d id and a message m, this algorithm computes a signature S for the m as follows: 1.
Pick a random x ∈ Z * q and compute θ = g x 2 .
• idVrf (id, m, S): ID-based signature verification algorithm accepts the message m if σ 1

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. TA first picks a random s ∈ Z * q as its master secret and runs Setup() algorithm to generate public system parameters params := G 1 , G 2 , q,ê, g, h, g 1 , g 2 , g 3 , H 1 , H 2 , H 3 . 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 R = {RSU 1 , ..., RSU m } be the RSUs subordinated by the TA and V = {V 1 , ..., V n } be the registering vehicles. For each RSU j ∈ R, TA generates RSU j 's id-based secret key rsk j ← idKeyGen(s, RSU j ) and preloads rsk j to each RSU j securely. Then, RSU j sets its private key as sk RSU j = (rsk j , a j , b j ) ← SetPrvKey(rsk j ) and public key pk RSU j = (g a j 3 , g b j ) ← SetPubKey(sk RSU j ) for CL-PRE.
On the other hand, for a vehicle V d ∈ V, TA chooses w + 1 pseudonymous identities PID d = {pid di |0 ≤ i ≤ w} for V d after checking the eligibility of V d . TA issues V d 's id-based secret keys vsk di ← idKeyGen(s, pid di ) for each pid di ∈ PID d . In our system, pid d0 is used for re-encryption procedure while {pid d1 , ..., pid dw } are used for VANET communications. When obtaining id-based keys for the pseudonyms, V d sets its private key and public key for proxy re-encryption procedure as sk V d = (vsk d0 , a d , b d ) ← SetPrvKey(vsk d0 ) and public key pk V d = (g a d 3 , g b d ) ← SetPubKey(sk V d ) for CL-PRE. Then, each V d and each RSU j , respectively, store (pid d0 , pk V d ) and (RSU j , pk RSU j ) to the cloud storage so as for them to retrieve the public key of each others.

Enrolment
For a vehicle to receive location-aware service messages by means of trajectory-based message delivery, V d configures desired socialspots in which V d is interested for receiving the service messages and selects sRSUs installed at the socialspots denoted as SR d = {sRSU j |1 ≤ j ≤ k} ⊆ SR. Then, to allow each sRSU j ∈ SR d to access V d 's trajectory data under the control of SM using a proxy re-encryption scheme, V d generates the re-encryption key rk V d →sRSU j for each sRSU j as follows:

1.
Retrieve sRSU j 's public key pk sRSU j from the cloud storage.

3.
Compose V d entrusts RSM d , consisting of sRSUs list and re-encryption keys, to SM so as for SM to re-encrypt V d 's trajectory data and delegate decryption right to each sRSU j when V d uploads its encrypted trajectory data to SM.

Trajectory Sharing on the Cloud
Let T d = {loc 1 → ... → loc t } be the driving trajectory of a vehicle V d consisting of some specific locations such as main roads or intersections on V d 's preference driving routes. When V d participates in VANETs, V d will expects to receive service messages provided by the socialspot RSUs (SR d ) of V d 's interest through some contact point RSUs deployed on V d 's driving trajectory T d . To securely share V d 's trajectory data and pseudonyms used for message delivery in VANETs with the socialspot RSUs in SR d through the cloud storage, V d uploads encrypted trajectory data and pseudonyms to SM as follows:

1.
Choose a pseudonym pid di ∈ PID d to be used for connecting to a contact point RSU i .

3.
Generate a ciphertext C for trj d as C ← clEnc(trj d , pid d0 , pk V d ) under V d 's own public key.
Once V d uploads its trajectory sharing message TM d to the cloud storage, SM controls to transform and provide V d 's encrypted trajectory to the sRSUs in SR d specified by V d as follows: 1.
Parse TM d as {pid d0 , C, ts, S d } and verify the signature S d as idVrf (pid d0 , pid d0 |C|ts, S d ) under the given pid d0 .

2.
Retrieve RSM d = {pid d0 , pk V d , SR d , RK d } for the given pid d0 from SM's storage.

3.
For each sRSU j ∈ SR d , extract rk V d →sRSU j ∈ RK d and transform the ciphertext C to C j as C j ← clReEnc (pid d0 , pk V d , C, rk V d →sRSU j ).

4.
Store {C j , ts} to sRSU j 's directory on the cloud.
While SM maintains vehicles encrypted trajectory information, each socialspot RSU, sRSU j , periodically access its directory to get the updated trajectory of V d as follows: 1.
Downloads {C j , ts} from its directory on the cloud.

2.
Decrypt C j to get trj d as Add (pid di , loc i ) pairs to the vehicle list VList.

Trajectory-based Message Delivery
Suppose that sRSU j collects and provides location-aware service information, such as traffic condition, gas station, and so on. Once trj d = {(pid di , loc i )} of V d is loaded, sRSU j can disseminate location-aware service messages for V d through an RSU i deployed on around loc i . Message delivery from sRSU j to V d can be subdivided into three phases: (1) message distribution of sRSU j to RSU i ;

Message Distribution to RSUs
Let msg be a content of location-aware service provided by sRSU j . In this phase, sRSU j compose a message package M jd for V d and distributes M jd to V d 's contact point RSU i as follows:

1.
Extract pid di corresponding to loc i from VList.

2.
Set a message M jd = {pid di , sRSU j , msg, ts , S j , ttl} where S j ← idSig(rsk j , pid di |sRSU j |msg|ts ) is sRSU j 's signature and ttl is the message lifetime.

3.
Distribute M jd to RSU i nearby loc i .
When we assume that RSUs are inter-connected, a message M jd can be easily distributed to other RSUs. During the message delivery, a message bundle has a certain lifetime specified as ttl 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 V d is not met on the roads.

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 ttl is expired. Suppose that a vehicle V d enters RSU i 's coverage and M jd sent from sRSU j for V d is kept by RSU i . The followings describe message forwarding protocol from RSU i to V d .

1.
RSU i periodically broadcasts beacon message containing pid di specified as a destination of M jd .

2.
If pid di is found in the beacon message, V d sends a message request {req, pid di , S d } to RSU i , where req is a metadata for message requesting and S d ← idSig(vsk di , req|pid di ).

3.
Upon receiving the request message, RSU i authenticates V d by verifying S d as idVrf (pid di , req|pid di , S d ). If it holds, RSU i sends M jd to V d .
When M jd is downloaded, V d checks the authenticity of the received message msg to be convinced whether the message actually originated from V d 's desired sRSU j as follows:
Accept msg as a valid message from sRSU j .

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 M jd on VANET, RSU i requests and finds a volunteer vehicle which willingly joins carrying and forwarding the message. Suppose that a vehicle V c within RSU i 's range is a volunteer vehicle. For RSU i 's request, V c responds acceptance message {acc, pid ci , S c } to RSU i to obtain M jd , where acc is a metadata and S c ← idSig(pid ci , acc|pid ci ). RSU i authenticates V c by verifying the signature S c under pid ci , if it holds, provides V c with M jd .
Once M jd is stored in V c 's storage, V c carries M jd by itself until V c runs into the target vehicle V d of pid di on the road before ttl is expired, or V c forwards M jd to a next-hop vehicle in accordance with VANET routing protocol. For the former case, if V c detects V d on driving, V c sends notification message to V d to inform that V c has a message M dj for V d . Then, V d requests the message to V c in authenticated manner as follows:

1.
V d requests the message to V c by sending {req, pid di , S d }.

2.
V c verifies the signature S d and forwards M jd attached with its signature as {res, pid ci , M jd , S c ← idSig(vsk ci , res|pid ci |M jd )}, where res is a metadata for the response.

3.
V d first verifies V c 's signature S c and extracts M jd . Then, V d checks if M jd actually originated from sRSU j by checking sRSU j 's signature S j in M jd 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 hop = {V 1 → V 2 → ... → V l } is a set of vehicles involved in message forwarding to the destination vehicle V d (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 V d consists of { f wd, M jd , {pid hi |S h } V h ∈hop } where f wd is a metadata for message forwarding and S h is a signature of each V h . The last hop vehicle can forward M jd to V d as described in the above. By verifying each signature S h under pid hi , V d can be convinced that the received message M jd was forwarded via authenticated vehicles.

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, V d 's trajectory T d is uploaded to the cloud in the encrypted form of C in trj d , and then C is transformed to a re-encrypted ciphertext C j by the SM to be shared with an sRSU j ∈ SR d . Suppose that V d 's trajectory T d is changed to different driving locations T d = {loc 1 → ... → loc t } but V d still wants to share the changed trajectory with the current sRSUs in SR d . In this case, the operation required to V d is just to generate a ciphertext C for the changed trajectory T d in accordance with the procedures of Section 4.3, and update TM d to include C on the cloud storage. Then, SM can transform C to C j for each sRSU j using the existing re-encryption keys RK d in RSM d .
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 V d does not want to share updated trajectory data with an sRSU j . In the proposed system, V d can revoke trajectory sharing with sRSU j by updating V d 's private and public key pair and re-encryption keys for sRSUs except the sRSU j as follows: 1.
Renew its private key as sk V d = (vsk d0 , a d , b d ) ← SetPrvKey(vsk d0 ) and public key as Change the socialspot RSUs list as SR d to SR d by adding new sRSUs and deleting revoked sRSUs.

3.
Set Replace the existing RSM d uploaded in enrolment phase of Section 4.2 with the updated RSM d including RK d and SR d .

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 trj d consisting of pseudonym-location pairs of a vehicle V d is maintained by SM in the encrypted form under V d 's public key pk V d as C ← clEnc(trj d , pid d0 , pk V d ). Essentially, nobody can gain V d 's trajectory data as trying to decrypt C without knowing V d 's private key sk V d corresponding to pk V d . On the other hand, some sRSUs of V d 's interested socialspots specified in SR d need to know V d 's driving trajectories for disseminating service messages through contact point RSUs along V d 's driving routes. V d can allow an sRSU j ∈ SR d to get its trajectory data by giving a re-encryption key rk V d →sRSU j ← clReKeyGen(sk V d , pid d0 , sRSU j , pk V d , pk sRSU j ) to SM instead of entrusting plaintext trajectory data. The encrypted trajectory data C are then re-encrypted to C j ← clReEnc (pid d0 , pk V d , C, rk V d →sRSU j ) for sRSU j under the key rk V d →sRSU j by SM. Hence, only a valid sRSU j that possesses a private key sk sRSU j corresponding to pk sRSU j involved in rk V d →sRSU j can get trj d by decrypting C j .
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 V d or sRSU j for the purpose of recovering the trajectory data trj d from C or C j 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.

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 V d is performed by SM according to socialspot list SR d and re-encryption keys RK d = {rk V d →sRSU j |sRSU j ∈ SR d } generated by V d in the enrolment phase. If V d does not want an sRSU j existing in SR d to access its trajectory data any more, V d can revoke sRSU j 's decryption right by generating new re-encryption keys for sRSUs in SR d except sRSU j . Once V d uploads updated SR d \ {sRSU j } and RK d for each sRSU in SR d , SM will exclude sRSU j and not provide sRSU j with the re-encrypted trajectory data of V d . In our revocation procedure of Section 4.5, V d 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.

Authenticated Vehicular Communications
To receive a service message in the form of M = {pid di , sRSU j , msg, ts , S j , ttl} served by sRSUs on VANETs, V d must be authenticated to a contact point RSU i or carrier vehicle V c as V d is the valid destination vehicle of pid di specified in the message M. In message forwarding phase of Section 4.4, when V d requests a message M kept by a contact point RSU i or a carrying vehicle V c , V d must present its id-based signature S d ← idSig(vsk di , req|pid di ) which is in turn verified under the given pid di 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 pid di except V d cannot forge the signature nor impersonate V d . Therefore, only the valid vehicle V d authenticated under the pid di can receive the message M.
In addition, when V d receives a message M, V d also authenticates the message sender sRSU by verifying the attached id-based signature S j under the sRUS's identity sRSU j specified in M. That is, V d can be convinced that the message M was sent from the sRSU j , in which V d is interested, if the signature S j is verified as valid under the id of sRSU j .

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 V d has a set of pseudonyms {pid d1 , .., pid dw }, which can be independently generated random values, and it is recommended to use a different pseudonym for identification and authentication whenever V d connects to a different contact point RSU i deployed at the location of loc i along V d 's driving path. Therefore, we can make it hard for an outside attacker to track moving locations of a vehicle if any two pseudonyms pid di = pid dj , respectively, observed by the attacker at RSU i and RSU j are unlinkable to the same vehicle from attacker's viewpoint.
Moreover, pid di , loc i pairs are only known to the sRSUs authorized by V d by means of a re-encryption technique. Another possible attack for an outside attacker is to compromise an sRSU to extract V d 's pseudonyms and driving trajectory data pid di , loc i 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.

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.  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 y 2 = x 3 + x for the group G 1 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 D = D tr + D auth where D tr is the delay for message transmission and D auth is for authentication process resulting from signature generation and verification. Depending on message forwarding method, D auth can be classified as where l is the number of hops and T sig and T vr f are the times for signature generation and verification evaluated as T sig   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.

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.