Privacy-preserving Navigation Supporting Similar Queries

1545-5971 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2020.3017534, IEEETransactions on Dependable and Secure Computing

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. YY, AUGUST 2020 1

Privacy-preserving Navigation SupportingSimilar Queries in Vehicular Networks

Meng Li, Member, IEEE , Yifei Chen, Student Member, IEEE , Shuli Zheng*, Donghui Hu*, Member, IEEE ,Chhagan Lal, Member, IEEE , Mauro Conti, Senior Member, IEEE

Abstract—Traffic-sensitive navigation systems in vehicular networks help drivers avoid traffic jams by providing several realtimenavigation routes. However, drivers still encounter privacy concerns because their sensitive locations, i.e., their start point andendpoint, are submitted to an honest-but-curious navigation service provider (NSP). Previous privacy-preserving studies exhibitserious deficiencies under similar queries: if a driver makes several similar queries, i.e., periodically makes requests for the same startpoint and endpoint to the NSP, these requests will eventually reveal the areas of the two points as well as the route. In this paper, wepresent a novel privacy-preserving navigation scheme PiSim, which supports similar queries in navigation services. Intuitively, wetransform the typical navigation approach into a traffic congestion querying approach. Instead of sending two locations to the NSP andawaiting a navigation route, drivers query the traffic congestion along the navigation route. Specifically, PiSim is characterized byextending anonymous authentication, facilitating privacy-preserving multi-keyword fuzzy search, and constructing weighted proximitygraphs. Our scheme protects location privacy and route privacy, and defends against multiple requesting, spurious reporting, andcollusion attacks from malicious drivers. Finally, a detailed analysis confirms the privacy and security properties of PiSim. Extensiveexperiments are conducted to demonstrate the feasibility, performance, and privacy protection level.

Index Terms—Vehicular Networks, Navigation Services, Similar Queries, Location Privacy, Privacy Measurement.

F

1 INTRODUCTION

V EHICULAR networks [1], [2], [3] have been gaininggreat momentum by providing popular vehicular ap-

plications such as ride-hailing [4], [5], [6], [7], road mon-itoring [8], parking spot finding [9], and parking naviga-tion [10]. Most applications require realtime traffic conges-tion information to provide location-based services. Withthe growth in the number of vehicles and traffic accidents,the delay in obtaining traffic congestion has become anadverse factor in the realization of modern transportation.

Traffic congestion incurs negative impacts on drivers,transportation, and society, leading to serious consequences,such as delayed appointments, traffic accidents, and airpollution. It is reported that drivers waste approximately 42hours in traffic delays each year and spend approximately$121 billion in time and fuel in the top 10 congested cities inthe US [11]. Another record shows that Washington driversspend 102 hours each year in traffic jams [12]. Therefore,realtime traffic information is essential to provide optimalnavigation routes.

Currently, traffic-sensitive navigation systems [13], [14]in vehicular networks [9], [15] can provide requesting

• Meng Li, Yifei Chen, Shuli Zheng, and Donghui Hu are with the KeyLaboratory of Knowledge Engineering with Big Data (Hefei University ofTechnology), Ministry of Education; and with the School of Computer Sci-ence and Information Engineering, Hefei University of Technology, Hefei230601, China. (Email: [email protected], [email protected],{zhengsl, hudh}@hfut.edu.cn) Corresponding authors: Shuli Zheng andDonghui Hu.

• Chhagan Lal is with Simula Research Laboratory, Norway (Email: [email protected]).

• Mauro Conti is with the Department of Mathematics, University ofPadua, 35131 Padua, Italy (Email: [email protected]).

drivers with several realtime navigation routes to avoid on-going traffic congestion. Contributing drivers upload theirdriving reports, i.e., their current location as enabled byGPS/WiFi positioning technology and their driving speed-s [16], [17], to a navigation service provider (NSP). The NSPprocesses this information and assigns roads different colorsindicating their level of traffic congestion. Then, a request-ing driver submits a navigation query including a pair ofmanually-set start point and endpoint to the NSP. Finally,the NSP retrieves the corresponding traffic information andreturns the optimal navigation routes to the requesting driv-er. For example, Google Maps [18] and Waze [19] are twosuch popular navigation applications attracting more than 1billion and 100 million active users worldwide, respectively.

While navigation systems offer appealing advantages,drivers still encounter various privacy concerns becausesuch systems are faced with various threats [17], [20], [21].Specifically, requesting drivers have to input their exact startpoint and endpoint, for a navigation route. Revealing adriver’s location raises critical privacy issues [22]. For ex-ample, locations themselves may be deemed sensitive, e.g.,home addresses and workplaces. In addition, some locationsmay reveal private information or activities of the driver,e.g., indicating diet preferences from a frequently visitedrestaurant, or inferring a driver’s medical condition due toseveral trips to a cancer hospital. The continuous collectionof locations can also help an adversary link an anonymoususer with a specific record in a separate database [23].

Several location privacy protection schemes have beenproposed in the literature [22], [24], [25]. Such schemesare primarily designed to substitute the true location witha different one. For example, Andres et al. [22] proposedthe concept of geo-indistinguishability to protect users’ true

Authorized licensed use limited to: Cornell University Library. Downloaded on August 20,2020 at 00:09:50 UTC from IEEE Xplore. Restrictions apply.




X

Y

[M. E. Andrés et al. 2013]

True

Start Point

False

Start Point

True

Endpoint

False

Endpoint

[Y. Xiao et al. 2017] [P. Zhang et al. 2018]

Navigation

Route

DriverDriver

Honest-but-curious

NSP

Route

Start point

Endpoint

RSURSU NSPNSP

Traditional approach

New approach

Start point

Endpoint

Route

Traffic

condition

Processed query

locations

RSURSU NSPNSP

Processed set of

query locations

Traffic

condition

Driver

Driver

Straight Route Navigation

Traffic Congestion Querying

(A) Existing Work Cannot Work Under Similar Queries. (B) Approach Transformation.

Locations

and route

are leaked!

Fig. 1. Problem demonstration and our motivation. (The threat to privacy and security is the malicious behavior of the NSP which snoops on themessages and the personal information about drivers. The threat is raised from three facts: (1) The NSP is honest-but-curious. (2) Drivers submitsimilar queries to the NSP. (3) Existing works based on perturbation and noise reveal the area of the start point/endpoint and eventually the routeunder similar queries.)

locations by adding noise. Xiao et al. [24] considered tem-poral correlations of moving users’ locations, which werereflected by a Markov model, and perturbed users’ true lo-cations using a planar isotropic mechanism. Zhang et al. [25]shifted users’ endpoints to nearby points while changingthe semantic meanings of the locations and making thereturned routes differ a little. However, we find that thesemethods face protection deficiencies when applied to navigationservices under the scenarios of similar queries. In particular,we consider a common scenario where a driver periodicitymakes a request for the same start point and endpoint tothe NSP. For example, a driver always turns on a navigationapplication and query a route from home to work everyworkday. This happens quite often because using navigationapplications helps drivers obtain realtime traffic congestionconditions on the returned navigation route and such behav-ior becomes habitual for drivers as an auxiliary measure forsafe driving. Given such similar queries, existing methodscannot fully protect a driver’s location privacy because theyall eventually reveal the areas of the two points as well asthe route. As depicted in Fig. 1 (A), the red circles are theareas of the start points and endpoints. The dashed linesoutline the routes of the drivers. The route is leaked because(1) the rough start point and endpoint are reveled whensimilar queries are submitted, and (2) anyone can obtainthe driver’s route by submitting a normal query to theNSP using the two points. A recent study [26] addresseda similar issue of protecting a spatiotemporal event basedon differential privacy; however, their method does notwork well with respect to location privacy in our problemsettings. It is because (1) their focus is on protecting lo-cations in continuous data releasing while we protect thestart point and endpoint in navigation services; and (2)their approach perturbs the true location with some noisesto achieve differential privacy which still exposes the startpoint and endpoint in navigation services under similarqueries. Therefore, a method is required to allow driversto request similar queries while maintaining their privacy.

To solve this problem, we put forward a novel privacy-preserving navigation scheme PiSim to support similar

queries. We foster our heuristics around an intuitive so-cial/behavioral norm, i.e., drivers are familiar with theirfrequently traveled routes1, and then reap the nature ofrealtime navigation as acquiring the traffic congestion alongthe requested route. Then, we convert the straight routenavigation approach, i.e., the start point/endpoint submis-sion approach, into a traffic congestion querying approach.Instead of inputting two locations into the application andawaiting a navigation route from the NSP, we require driver-s to query the traffic congestion at several locations alongthe navigation route as displayed in Fig. 1 (B). In otherwords, PiSim is also motivated by offline route selection,i.e., it is built upon a route plan scheme. Requesting usershave to input some passing locations (e.g., main crossingsand turning points) or use the PiSim app to automaticallyselect locations as we explained in Section 5.3 later. In thisway, we eradicate the privacy concern raised by utilizingperturbation-based methods in navigation services. How-ever, this results in new problems and challenges. First,it is a common practice to protect users’ identity privacyvia anonymous authentication; however, malicious driverscould misuse the technique to mount multiple requestingattacks, which the existing method [27] cannot defend a-gainst. Next, a malicious contributing driver could colludeto launch spurious reporting attacks, i.e., send false trafficcongestion reports to the NSP, just to circumvent detectionmechanisms and sabotage the navigation system.

The contributions of this work are listed as follows.

• We address both location privacy and route privacyunder the condition of similar queries in navigationservices. We aim to protect the locations and routesof drivers who continuously submit the same startpoint and endpoint to the service provider over time.We build upon a stronger threat model for naviga-tion services, where we adopt the honest-but-curioussecurity assumption for most entities and consider

1. https://www.theguardian.com/lifeandstyle/2012/jan/14/how-i-remember-taxi-driver





malicious drivers who launch multiple requestingand collude to initiate spurious reporting.

• We present PiSim, a novel privacy-preserving nav-igation scheme, to further protect driver privacy.Specifically, we extend the anonymous authentica-tion [27] to support a request-limiting property [28],i.e., defend against multiple requesting attacks. Wefacilitate privacy-preserving multi-keyword fuzzysearch [29] to protect the locations and routes of thedrivers. Further, we defend against spurious report-ing attacks by conducting WiFi handshake challengesand constructing weighted proximity graphs [17].

• A formal analysis is given to show that the pri-vacy and security of PiSim rely on standard hardproblems. To show the deployment feasibility andefficiency of PiSim, we implement it and evaluateits performance on a laptop, two desktops, and twosmartphones running an Android application, More-over, we compare it to existing methods with respectto computational cost, communication overhead, andprivacy protection level.

The remaining of this paper is organized as below. Weanalyze related work in Section 2. We introduce our systemmodel, threat model, and design objectives in Section 3.Some preliminaries are revisited in Section 4, prior to pre-senting the PiSim scheme in Section 5. We also analyze theprivacy and security of the proposed PiSim in Section 6. InSection 7, we implement the navigation system and evaluateits performance regarding computational cost, communi-cation overhead, and privacy leakage. Lastly, we providesome discussions in Section 8, and we conclude our work inSection 9.

2 RELATED WORK

2.1 Location privacy-preserving mechanisms based ondifferential privacy

The first subsection contains some typical privacy-preserving mechanisms built upon differential privacy. Welook into these works since differential privacy is nowa widely acknowledged privacy standard for designingprivacy-preserving systems. Our motivation originates fromnavigation systems leveraging these mechanisms.

Andres et al. [22] proposed geo-indistinguishability, aformal definition of location privacy, to protect users’ truelocations, while enabling approximate information to be col-lected for obtaining location-based services, such as pointsof interest retrieval, mapping applications, and navigation.Such definition elegantly formalizes the concept of preserv-ing users’ locations within a radius r with a privacy levellev relying on r, and accords to a generalized notion ofdifferential privacy. For two points p1 and p2, a mechanismA satisfies ε-geo-indistinguishability iff for all p1 and p2,dp(A(p1), A(p2)) ≤ εd(p1, p2) where ε = lev/r. They alsodesigned a mechanism to achieve geo-indistinguishabilityby adding random noise to the users’ locations in a control-lable manner.

Xiao et al. [24] considered temporal correlations of mov-ing users’ locations. They claimed that the static noisylocation could be easily revealed to adversaries which had

acquired the knowledge of temporal correlations. First, theydetermine location changes between two time points bytemporal correlations modeled through a Markov chain andthen hide the true location in a δ-location set [30] whereitems are not differentiable. Then, they perturbed users’true location with a differentially private method, namedplanar isotropic mechanism (PIM). Next, they introduce acontinuous location sharing system by cooperating hiddenMarkov model and PIM.

Zhang et al. [25] designed a location privacy protectionscheme ShiftRoute for navigation services. ShiftRoute al-lows users to query a route between a start point and anendpoint, without disclosing any meaningful location infor-mation. Its main idea is to selectively shift the two points tothe ones close-by and guarantee that: the semantic meaningsof the two points change much in order to preserve locationprivacy but preserve service usability.

Cao et al. [26] proposed a privacy metric ε-spatiotemporal event privacy. They presented a frameworkto transform a location privacy protection mechanism intoone preserving the privacy based on differential privacyand Markov model. Specifically, the proposed privacy isdefined as for a set of locations {l1, l2, · · ·, lt}, Pr[l1, l2, · ··, lt|Event] ≤ eεPr[l1, l2, · · ·, lt|¬Event]. They modeled aprivacy-preserving mechanism as a matrix perturbing truepositions. However, their focus is on protecting locations incontinuous data releasing while we emphasize the impor-tance of protecting start point and endpoint in navigationservices.

All of the schemes above show enormous efficacy inlocation protection, but fail to deal with privacy protec-tion under similar queries. This is because all of them areperturbation-based methods and similar queries still reveala bounded area encircling the perturbed locations underperturbation-based approaches. Since submitting similarqueries is a common practice for most drivers, we believethat our work serves as a significant supplement to privacy-preserving navigation.

2.2 Privacy-preserving vehicular systems based oncryptography

Besides the mechanisms mentioned above, there are manyworks providing vehicular services aiming to protect users’locations based on cryptographic primitives. We also surveysome typical works for comparison later.

Ni et al. [4] presented an anonymous mutual authentica-tion protocol AMA by leveraging the BBS+ signature. Pas-sengers and drivers send carpooling queries and carpoolingreports to road-side units (RSUs), respectively. They haveto authenticate each other before a ride. However, RSUscan decrypt users’ plaintext information including meetingtime, pickup locations and dropoff locations, which is adirect privacy violation of users’ location privacy and routeprivacy.

Basudan et al. [8] road monitoring proposed a roadsurface condition monitoring scheme RSCM by proposing acertificateless aggregate signcryption algorithm. Each driverwith a mobile sensor collects road event data including atime point and a location, and submits a secure road eventreport SRER to an RSU. The RSU performs aggregated





verification on a batch of SRERs and then unsigncrypts theSRERs to obtain plaintext road event data. Unfortunately,RSUs can decrypt drivers’ time points and locations, whichfurther violates drivers’ locations and route privacy.

Zhu et al. [9] parking spot finding presented a privacy-preserving smart parking scheme ASAP that utilized privateparking spots to relieve public traffic congestion. Passengersand drivers first transform their real locations, e.g., a streetor a district, into a wide area via cloaking technique, andthen encrypt the hashed location. Although the cloaked areahides the real locations, still it reveals location and routeunder similar queries.

Ni et al. [10] parking navigation proposed a privacy-preserving smart parking navigation scheme P-SPAN thatefficiently retrieved navigation results. Each driver gener-ates a parking navigation query based on his pickup loca-tion and destination, and sends it to an RSU which relaysit to a parking navigation service provider. Same as AMA,P-SPAN still reveals drivers’ time points, current locations,and destinations to the service provider.

Pham et al. [31] presented a privacy-preserving andaccountable ride-hailing service ORide to enable efficientmatching of riders and drivers without leaking identitiesor locations. ORide used a homomorphic encryption sys-tem and applied optimizations for ciphertext packing andtransformed processing. Certificates issued by the serviceprovider are used by the riders and drivers to identify eachother before a ride.

Luo et al. [32] proposed a privacy-preserving ride match-ing scheme to allow the ride-hailing service provider toefficiently and accurately match riders and drivers whileprotecting their locations from the service provider. Theirmatching rationale is based on a shortest distance estimationmechanism, i.e., they transform the road network into ahigher dimensional space using a road network embeddingtechnique such that ride matching can be done efficiently.

3 PROBLEM STATEMENT

3.1 System Model

The system model of PiSim consists of requesting drivers,contributing drivers, RSUs, navigation service provider (N-SP), and a trusted authority (TA) as demonstrated in Fig. 2.

• Requesting drivers have a vehicle that is equippedwith a computation and communication device, e.g.,on-board unit (OBU) and smartphone. They use thedevices to submit a navigation query including a setof processed locations (i.e., queried locations) to anNSP via an RSU. Based on the returned result, theylocally form a navigation route. Here, we assumethere is one optimal route and we will discuss morein Section 8.1.

• Contributing drivers use the aforementioned de-vices to first undergo a WiFi handshake challengewith nearby contributing drivers, and then submit adriving report to the NSP with a processed location(i.e., reported location) and an indicator of the trafficcongestion. Indicators are classified into four types:I1 for smooth, I2 for slightly congested, I3 forcongested, and I4 for highly congested. Instead of

uploading locations and speeds as in [17], we ask thecontributing drivers to only send such an indicator.

• RSUs. An RSU collects navigation queries and driv-ing reports from local drivers, authenticates driver-s’ identities, verifies data integrity, pre-processesqueries and reports, and uploads them to the NSP.Then it sends query results to requesting drivers.There are two reasons for utilizing RSUs. (1) Im-proving performance. RSUs are fog nodes [33], [34]with enhanced computing and communicating ca-pabilities. They ease the computation burden of thecloud service provider by extending parts of theNSP’s tasks to the network edge and processing datalocally [35], [36]. Utilizing RSUs offers low-latency re-sponses and low communication overhead, thus im-proving system performance. (2) Enhancing security.RSUs are frontline guards defending the spuriousreporting attacks from colluding drivers [17]. Theyfilter the driving reports from contributing driversby constructing a weighted proximity graph andcutting off nodes with low trust values, i.e., maliciousdrivers. Utilizing RSUs provides data authenticity,thus enhancing system security.

• NSP. The NSP is a cloud service provider that offersnavigation services to drivers. It first collects real-time driving data from the contributing drivers viaRSUs and constructs a traffic congestion databaseregarding the whole service area, e.g., a city. Then,it responds to requesting driver’s navigation queriesby searching the traffic congestion database to returnquery results to the requesting drivers via RSUs.

• TA. The TA governs initializing the whole navigationsystem and registering entities, i.e., drivers, RSUs,and the NSP. It does not remain online after systeminitialization and entity registration. When misbe-havior is detected (e.g., a malicious requesting driverhas submitted 100 different queries at one time using100 anonymous credentials) and the real identity of adriver has to be revealed, the TA can disclose the realidentity of the targeted driver based on the driver’sanonymous credential.

Navigation

Queries

RSU NSPRequesting

Driver

Contributing

DriverTA

User Tracking

Entity Registration

Driving Reports

Navigation

Queries

Results

Fig. 2. System model of PiSim.





3.2 Threat Model

Internal adversaries, including drivers and RSUs, may havedifferent incentives to mask their malicious acts and cir-cumvent detection mechanisms. Most drivers are honestand they submit navigation queries and driving informa-tion faithfully. A small number of requesting drivers aremalicious and they can mount a multiple requesting attack:submitting multiple queries with different anonymous iden-tities to the navigation system. Such an attack significantlyincreases the verification time for RSUs and the responsedelay for other honest requesting drivers. A small partof contributing drivers is malicious and they collude andperform spurious reporting attack: submitting false drivingreports to the navigation system [17]. Such an attack de-grades the system performance by misleading RSUs/NSP toconstruct a falsified database resulting in providing wrongdirections for the requesting drivers. The collusion attackbetween the driver and the RSU/NSP is not consideredin this paper, and we will discuss this issue in Section 9.RSUs and the NSP are honest-but-curious. They are alsointerested in drivers’ privacy, e.g., identity, location, androute. The TA is trusted and it cannot be compromised [6].External adversaries eavesdrop on communication channelsand launch impersonation attacks in order to disclose thestart points and endpoints of drivers, acquire the movingpatterns of drivers, predict drivers’ locations at a specifictime, and acquire private inclinations of drivers from theirvisited locations.

This paper focuses on the core problem, i.e., privacy leak-age problem, under the case of similar queries in navigationservices. We solve this problem by transferring the tradition-al start point/endpoint submission approach into the newtraffic congestion querying approach. But doing so bringsup new challenges and problems, i.e., multiple requestingattack initiated by malicious requesting drivers and spu-rious reporting attack launched by colluding contributingdrivers. These two attacks are foreseeable and typical attacksas they motivate malicious drivers to gain excessive servicesand sabotage the navigation system, respectively.

3.3 Privacy and Security Objectives

Privacy. (1) Identity Privacy. When drivers join the navi-gation system and submit a navigation query (driving re-port), their identities should be anonymous to other drivers,RSUs, the NSP, and external entities. (2) Location Privacy.Drivers’ location and location area must be protected fromother entities. These locations include requesting drivers’start points, endpoints, and queried locations, as well ascontributing drivers’ reported locations. (3) Route Privacy.Requesting drivers’ routes should be preserved when theysubmit a navigation query to the NSP. (4) Unlinkability. Giv-en two navigation queries (driving reports), any adversarycannot identify whether they are generated from the samerequesting driver (contributing driver).

Security. (1) Drivers’ identities are authenticated by R-SUs and any adversary cannot forge a valid group signature.(2) The navigation system must defend the “multiple re-questing attack”. In other words, the navigation system onlyallows requesting drivers to submit one navigation query at

one time and does not allow one requesting driver to sabo-tage the system by making multiple navigation queries. (3)The navigation system must defend the “spurious reportingattack”. The navigation system only accepts normal drivingreports from contributing drivers and does not allow themto mislead the system by uploading false driving reports.

Efficiency. The proposed scheme should achieve goodefficiency regarding computational costs and communica-tion overhead at the driver side, the RSU side, and the NSPside.

4 PRELIMINARIES

In this section, we briefly revisit elemental techniques thatare used to support the construction of PiSim. These in-clude bilinear pairing, zero-knowledge proofs, and privacy-preserving multi-keyword fuzzy search.

4.1 Bilinear PairingAssume G1, G2 and GT are cyclic groups of prime order p. Amapping function e: G1×G2 → GT is a type 3 bilinear pair-ing if the following conditions are satisfied [27]: (1) EfficientComputability: for any g1 ∈ G1, g2 ∈ G2, e(g1, g2) is effi-ciently computable. (2) Bilinearity: for any g1 ∈ G1, g2 ∈ G2

and a1, a2 ∈ Z∗p, e(ga11 , ga22 ) = e(g1, g2)a1·a2 . (3) Non-degeneracy: for any g1 ∈ G1\{1G1

} and g2 ∈ G2\{1G2},

e(g1, g2) 6= 1GT}.

4.2 Zero-Knowledge ProofsIn the model of a zero-knowledge proof of knowledge(ZKPK) [28], [37], there are two parties: a prover P and averifier V . P can convince V that he knows a x that has arelation R to a public y without revealing anything otherthan the relation (x, y) ∈ R. Concretely, assume a P with asecret x and a public key y = gx. V only knows (g, y). By aZKPK, P can convince V that P knows x satisfying y = gx

without disclosing x. This is denoted as PK{(x) : y = gx}.The parameters in the parentheses are the knowledge thatthe P wishes to prove. The parameters on the right arepublicly known. Furthermore, it can be transformed intoa noninteractive signature proof-of-knowledge (SPK) proto-col.

4.3 Privacy-Preserving Multi-Keyword Fuzzy SearchThe privacy-preserving multi-keyword fuzzy search schemeconsists of the following algorithms: KeyGen(b1, b2): giv-en a secure parameter b1, output a secret key SK =(SK1, SK2, V ); given a secure parameter b2, generate ahash key pool HKP = {ki}. Index Enc(SK,KI): splitthe keyword index KI into two vectors {KI ′,KI ′′}: foreach ij ∈ KI , ij = i′′j = ij if vj ∈ V is 1; ori′j = 1

2 ij + r, i′′j = 12 ij − r where r is randomly chosen.

Output a secure index: EncSK(KI). Query Enc(SK,QI):split the query index QI into two vectors {QI ′, QI ′′}:for each qj ∈ Q, q′j = q′′j = qj if vj ∈ V is 0;or q′j = 1

2qj + r′, q′′j = 12qj − r′. Output a trapdoor:

EncSK(QI). BuildIndex(F , SK,L): choose L location sen-sitive hashing (LSH) functions H = {hi} and one pseudo-random function (PRF) F . Extract keywords set from a





file dataset F and construct a Bloom filter BFF by hashfunctions {gi|gi = Fki ◦hi}. Output an indexEncSK(BFF ).Trapdoor(Q,SK): generate a Bloom filter QIQ for queryQ with the same hash functions. Output a trapdoorQuery EncSK(Q). Search(EncSK(Q), EncSK(QIF )): out-put the relevance score: (SKT

1 ·QI ′F )T ·SK−11 ·QI ′Q+(SKT

2 ·QI ′′F )T · SK−1

2 ·QI ′′Q.

5 PISIM: THE PROPOSED SCHEME

At a high level, PiSim contains six phases: system initial-ization, entity registration, navigation querying, navigationresponding, route retrieval, and driver tracking. Before wedive into the details of the above six phases, we providean overview of the PiSim by using Algorithm 1. It includesinput and output parameters, and the different steps thatare carried out during the execution of PiSim.

Algorithm 1: PiSim

Input: 1k, 1k1

, 1k2

, rd, cd, PS , PE , P .Output: p.p, sk, SK, HKP , gskrd, gskrd, (skru, pkru),

(sksp, pksp), NQ, DR, LDB, T DB, ID./*System Initialization*/1. TA generates secret keys sk, SK, and HKP givensecurity parameters 1k, 1k

1

, 1k2

;/*Entity Registration*/2. Requesting driver rd obtains a group secret keygskrd;3. Contributing driver cd obtains a similar gskrd;4. RSU ru registers to obtain a key pair (skru, pkru);5. NSP registers to obtain a key pair (sksp, pksp);/*Navigation Querying*/6. rd sends a navigation query NQ to an RSU fromstart point PS and endpoint PE ;/*Navigation Responding*/7. RSU verifies NQ, broadcasts a traffic congestiontask;8. cd sends RSU a driving report DR from location P ;/*Route Retrieval*/9. RSU verifies and filters a set of {DR}s, stores therest in local databaes LDB and sends them to NSP;10. RSU searches LDB (requests NSP if needed) andreturns a result to rd;11. NSP verifies the received reports and forms atraffic congestion database T DB;/*Driver Tracking*/12. RSU sends an NQ or DR to TA;13. TA reveals the real identity ID of the targeted user.14 Return p.p, sk, SK, HKP , gskrd, gskrd,(skru, pkru), (sksp, pksp), NQ, DR, LDB, T DB, ID.

5.1 System InitializationGiven a security parameter 1k, the TA generates publicparameters ← (p,G1,G2,GT , e,H) where G1,G2, and GTare three cyclic groups of prime order p, e is a bilinear map:G1 × G2 → GT , and H is a hash function. The TA setsgroup secret key gsk = (a, b)

$←− Z2p and group public key

as gpk = (g,A,B, g) where g $←− G2 and (A,B) ← (ga, gb)

and g is a generator in G1. Next, the TA generates pub-lic parameters (Υ, ρ, g, H) and a max requesting countMC indicating how many times any requesting driver cansubmit a navigation query during a time period (e.g., 10times in 1 minute). Υ − 1 is the order of an non-negativeintegers Z∗Υ. g is a generator and 〈g〉 is a subgroup of Z∗Υof prime order ρ. H : {0, 1}∗ → ZΥ is a hash function. TheTA sets a key pair (sk, pk) from the CL-signature schemepk = (n,D1, D2, D3) [38] where n is a RSA modulus andD1, D2, D3 are generators of QRn which is a group ofquadratic residues modulo n.

Given another two security parameters 1k1

, 1k2

, the TAgenerates another secret key SK = (SK1, SK2, V ) withinvertible matrices SK1, SK2 ∈ Rk

1×k1 and a vector V ∈{0, 1}k1 is a vector. The TA chooses L location sensitive hashfunctions H = {Hi : {0, 1}262 → {0, 1}k1} and generates ahash key pool HKP = {ki|ki

R←− {0, 1}k2 , 1 ≤ i ≤ L}and chooses one pseudo-random function f : {0, 1}∗ ×{0, 1}k2 → {0, 1}∗. Besides, the TA chooses another secretkey K ∈ Zp.

Finally, TA publishes public parameters p.p. = (p,G1,G2,GT , g, e,H,A,B, g,Υ, ρ, g, H,MC, n,D1, D2, D3,H, f).

5.2 Entity Registration

Each requesting driver has a unique identifier rdi, whichcan be license plate and social insurance number. rdi gener-ates a key pair (skrdi , pkrdi ), randomly chooses a secret si

$←−Zp, and sends (rdi, pkrdi ) and (ηi, ηi) ← (gsi , Bsi) withsignature σi to TA. The TA checks the validity of σi, checkse(ηi, B)

?= e(g, ηi), conducts an interactive proof of knowl-

edge of si with rdi. If the three steps above are correctlyexecuted, the TA generates a random t

$←− Zp to calculate asignature on si: Erdi ← (Ei1, Ei2)← (gt, (ga · (ηi)b)t). Next,the TA stores (rdi, ηi, σi, ηi) and sends (Erdi , SK,K,HKP)to rdi. rdi stores (Ecdi , SK,K), sets the group secret key asgskrdi = (si, E

cdi , e(Ei1, B)), and sets the initial requesting

count rci = 0.Each contributing driver cdi registers to the TA, re-

ceives (Ecdi , SK,K,HKP) and sets a group secret keygskcdi = (si, E

cdi , e(Ei1, B)). Each RSU ru registers to the

TA to receive a key pair (skru, pkru). Each ru initializesan empty mapping table T ru and a local database LDBru.The table is to record the mapping relation between therequesting drivers and their navigation queries and the localdatabase is to store navigation queries. The NSP registers tothe TA and receives a key pair (sksp, pksp) initializes a trafficcongestion database.

5.3 Navigation Querying

We assume that a requesting driver rdi holding a smart-phone is ready to begin a journey from start point PSto endpoint PE during a specific time period, e.g., from8:00 to 8:30. Instead of submitting PS and PE (after pos-sible location changing or shifting as in existing work) tothe NSP, rdi forms a driver-specific set of query locationsPi = {P1, P2, ..., PN} on the optimal route from PS to PE inthis time period. In particular, we provide three options forthe rdi to divide the route, i.e., select locations, as follows.





(1) Manual Selection. The rdi divides a route according toher/his memories built from daily location traces if she/heremembers the frequently traveled route and is careful withthe route choice. We also conducted a new questionnaire onthe crowdsourcing marketplace Mechanical Turk to supportthis assumption of route memory in Section 8.2. (2) SelectionHistory. The rdi divides the route by using the history onthe app. We enable the app to record the previously chosenlocations on the driver’s traveled routes on the smartphone.Then rdi can choose the locations conveniently in futurequeries. (3) Automatic Selection. If not familiar with theroute, the rdi inputs the start point and endpoint, and thenthe app utilizes the Dijkstra’s algorithm [39] to find theoptimal path based on the road map given that the city mapis already downloaded on the smartphone. Then, severalkey locations, such as main crossings and turning points,are chosen and recorded by the app. Afterward, the rd canquery the traffic information on these location from the NSP.

Each location is a short text consisting of several key-words, i.e., Time Square, ShakeShack on 8thAve, intersectionbetween ParkAve and E79thSt. rdi performs the followingoperations to form a navigation query NQi:

• Generate N k1-bit Bloom filters {KIi}Ni=1, and in-sert each Pi into a KIi using the hash functions{ui|ui = fki ◦Hi, Hi ∈ H, 1 ≤ i ≤ L}. For example,if N = 5, then rdi will have five Bloom filters. Wewill use one Bloom filter in the following descriptionfor simplicity.

• Encrypt KIi with SK and compute a location indexIndex EncSK(KIi) = {SKT

1 ·KI ′i, SKT2 ·KI ′′i }.

• Choose the current time epoch te, increase rci by1, and compute a valid request-limiting pseudonymrlpi:

grlpi = H(te||rci)(Υ−1)/ρ, (1)

rlpi = gsirlpi mod Υ. (2)

• Create a ZKPK of the si used to form rlpi:

Pi = SPK{(si) : gsirlpi mod Υ}. (3)

For example, if the NSP allows requesting driversonly 100 queries per hour, then MC = 1 and thetime period identifier te is updated every hour. Inthis way, PiSim ensures that a requesting driver canonly create 100 valid rlps per hour.

• Randomly select r1 ∈ Zp to randomize (Ei1, Ei2):

(E′i1, E′i2)← (Er1i1 , E

r1i2 ), (4)

• Randomly select r2 ∈ Zp and compute

e(E′i1, B)r2 ← e(Ei1, B)r1r2 , (5)

ci = H(E′i1, E′i2, e(E

′i1, B)r2 ,Mi), (6)

where Mi = Index EncSK(KIi)||rlpi||Pi.• Compute ssj = r2 + cisi and output a group signa-

ture (E′i1, E′i2, ci, ssi) on Mi.

• Form a navigation query:

NQi = (Mi, E′i1, E

′i2, ci, ssi). (7)

Finally, the rdi sends NQi to a local RSU ru. Here, wehave transformed the original route navigation approach,

i.e., start point/endpoint submission approach, into a trafficcongestion querying approach. Instead of sending the startpoint and endpoint to the NSP, drivers query the trafficcongestion along his/her frequently traveled route from theNSP. We show the process of a requesting driver queryingfor traffic congestion in Figure. 3. We note that it is commonfor a driver, especially an experienced one, to remember afrequently traveled route in the similar queries scenario.

Navigation

service

providerVerification

1st similar query

nth similar query

Result

Navigation

query

ith similar query

……

……

Result

Query’

……

Real-time

Traffic

database

……

……rn 0 0 rnrn

……0 0 0 rn0

……rn rn rn rnrn

VBF

QueryStore

Trusted

Authority

Initialization

Registration

RSURSU

RSURSU

Result

Query’

Result

Query’

Result

Navigation

query

Result

Retrieval

Fig. 3. A requesting driver queries for traffic congestion.

5.4 Navigation RespondingUpon receiving a navigation query NQi = (Mi, E

′i1, E

′i2,

ci, ssi) from a requesting driver within coverage, the localRSU ru performs the following operations to respond to theNQi:

• Verify the validity of (E′i1, E′i2, ci, ssi) by computing

Ei = e(E′i1, A)ci · e(E′i2, g)−ci · e(E′i1, B)ssi andchecking ci

?= H(E′i1, E

′i2, Ei,Mi). If it is not valid,

drop the corresponding query; otherwise, continue.• Verify Pi and check whether 1 ≤ num ≤ MC

and search its database during current time epochwhether rlpi has been used before. If the verificationfails, abort; otherwise, continue.

• Insert the mapping relation < rlpi, NQi > into theTru and store NQi in the LDBru. To ease the storageburden of the RSU, we could use distributed storageservers [40].

• Broadcast a traffic congestion task with a time-varying state information ∆ru within coverage toencourage nearby contributing drivers to upload re-altime driving reports from their current locations.

Upon receiving the traffic congestion task, each con-tributing driver cdj and nearby drivers respond as follows:

• Being at some location Pj , cdj forms an indicatorindj , starts WiFi tethering to broadcast a pseudo IDpidj and a hashed indicator hsvj so as to initiate aproximity challenge and pare with nearby contribut-ing drivers [16]:

pidj = H(r3||∆ru|te), (8)

hsvj = H(K||indj ||∆ru||te). (9)

• A receiving contributing driver cdo broadcasts a sim-ilar beacon with pido and havo, and checks whetherthe received havj is equal to havo. If so, the cdo stores(pidj , havj) and attests the proximity to the cdj by





including (pidj , hsvj) in the driving report (the cdjstores (pido, hsvo) and attests the proximity to thecdo by including (pido, havo) in the driving report),or she deems the handshake a failure.

• cdj generates Mj = (indj , {pidjz}numz=1 ,H(K||indj||∆ru),⊕numz=1 H(K||indjz||∆ru)||te). pidjz is pseudoID set of cdz which successfully handshaked with cdjand H(K||indjz||∆ru)||te) is the hashed indicator ofcdz . The ⊕numh=1H(K||indjz||∆ru) ⊕ H(K||indj ||∆j)is a hash proof in case any encountering driver ma-nipulates the indicator in uploading a driving reportlater.

• Generate a k1-bit Bloom filter QIj and insert thereported location into QIj using the same {ui}.

• Encrypt QIj with SK and compute a trapdoorQuery EncSK(QIj) = {SK−1

1 ·QI ′j , SK−12 ·QI ′′j }.

• Generate a group signature (E′j1, E′j2, cj , ssj) on

(Mj ,Query EncSK(QIj)) as the requesting driversdid.

• Send a driving report to the ru:

DRj = (Mj ,Query EncSK(QIj), E′j1, E

′j2, cj , ssj).

(10)By doing so, ru can build a weighted proximitygraph based on the successful encounters to filter outfalse driving reports and be assured of the indicatorsreported. We also note that cdj can select a set oflocations Pj according to his own will and pair withnearby contributing drivers at each location.

5.5 Route Retrieval

Upon receiving driving reports {DRj}, the ru retrieves atraffic congestion result for rdi:

• Verify the validity of group signatures on collecteddriving reports and drop invalid ones.

• Verify the validity of each indicator indj of cdj :compute a new hash proof ⊕numz=1 H(K||indz||∆ru)⊕H(K||indj ||∆ru||te)) for cdj , and compare it withthe ⊕numh=1H(K||indjz||∆ru) ⊕ H(K||indj ||∆j). Ifthey are equal, then cdj has behaved honestly in up-loading the same indicator as in previous handshakechallenges.

• Continue to verify the remaining driving report-s to form a set of location-indicator pairs <Query EncSK(QI), ind >.

• Construct a weight proximity graph WPG = (V, E)according to the valid driving reports as follows.Each node in the G stands for a contributing driver.Each edge in the E means its two connected drivershave a successful handshake and its edge weight wis the count of successful handshakes. Assign severalhonest nodes (public buses) to initialize trust valuesin theWPG.

• Filter out false driving reports as follows. The ru iter-atively computes the trust value of each node basedon the trust propagation. Specifically, we define TVas the trust seed that is assigned to honest nodesequally, TV ij as the trust value of node j after ithiteration. During ith iteration, the node j passes itstrust value to its neighboring nodes proportionally

based on the weights of edges and then gatherstrust values from its neighboring nodes, and then

computes: TV ij =∑

(o,j)∈ETV i−1

o ∗w(o,j)

wowhere w(o,j)

is the weight on the edge (o, j) and wo is the sum ofweights on the edges of o. In the end, the trust valueskeep stable and the ru compares the trust valueof each node with a preset cutoff threshold TH1

in order to mark nodes with lower trust values asmalicious nodes and drop the corresponding drivingreports.

• Store the remaining reports into LDBru and forwardthem to the NSP with a signature.

After receiving the driving reports from the RSUs, theNSP first verifies the signatures of RSUs and then constructsa traffic congestion database T DB of the traffic congestionin the whole service area. For each navigation query, theru first checks if the query has an answer in its localdatabase by computing a relevance score (i.e., inner product)RS = Search(EncSK(KI), EncSK(QI)). If RS is higherthan another threshold TH2, then the ru returns to therequesting driver the ind attached with the EncSK(KI) aswell as a signature using skru. Else, the ru inserts the queryinto a set {NQru} until all queries are processed, generatesa signature on {NQru}, and sends ({NQru}, σru) to theNSP. The NSP verifies σru, processes the same for ({NQru}in T DB, and returns the results to the ru with a signatureusing sksp. Then ru relays the results to correspondingrequesting drivers with a signature.

Finally, the requesting drivers can obtain the traffic con-gestion results for queried locations, form a colored routestringed by these locations, and begin their travel. Thecorrectness of the retrieved results for requesting drivers isguaranteed by the underlying multi-keyword fuzzy search.Because we use the same hash functions when building thequery index and the trapdoor, leading to the fact that theinner product of the query index and the trapdoor producesthe maximum value when they contain the same keywords.

5.6 Driver TrackingWhen a driver i is reported for some bad behavior, such assubmitting multiple requests or uploading a false drivingreport, an RSU sends the NQ or DR including signature(E′i1, E

′i2, ci, ssi) of the targeted driver to the TA. The

TA can reveal the real identity of i by testing whethere(E′i2, g) · e(E′i1, A)−1 = e(E′i2, ηi) for all registration items(i, ηi, σi, ηi) until a match is located. Last, the TA showsthe corresponding (i, ηi, σi) with a proof of knowledge of avalid ηi. The TA adds the targeted driver in the blacklist andpunishes the driver according to application-oriented rules.

6 PRIVACY AND SECURITY ANALYSIS

Privacy.(1) Identity Privacy. We designed anonymous authen-

tication with request-limiting property to protect the realidentity of requesting drivers. Each requesting driver rdihas to obtain a group signature on si: Ecdi ← (Ei1, Ei2)from the TA in registration phase. When rdi queries thesystem, rdi must use Erdi to prove that he is qualified, whileremaining anonymous. This is done by proving knowledge





TABLE 1Comparison of privacy and security properties

Property (under Similar Queries) [22] [24] [25] [26] [4] [8] [9] [10] PiSimIdentity Privacy n/a n/a n/a n/a

√ √ √ √ √

Location Privacy × × × × × × × ×√

Route Privacy × × × × × × × ×√

Unlinkability√ √ √ √

× × × ×√

Confidentiality√ √ √

n/a × ×√

×√

Integrity n/a n/a n/a n/a√ √ √ √ √

Authentication n/a n/a n/a n/a√ √ √ √ √

of a signature [38]. rdi randomizes (Ei1, Ei2) on a randomnumber r1 under g. The computed signature (E′i1, E

′i2) is

valid on (si, r1) and does not disclose any information onsi when proving to the RSU in a non-interactive manner.Meanwhile, rdi generates a request-limiting pseudonym rlpito prove that he does not create multiple queries at onetime, which is done via a count verification and a ZKPK ofthe si. Hence, when drivers join the navigation system andsubmit a navigation query (driving report), their identitiesare anonymous to other drivers, RSUs, the NSP, and externalentities.

(2) Location Privacy. Drivers’ location and location areashould be protected from other entities. These location-s include requesting drivers’ start points, endpoints, andqueried locations, as well as contributing drivers’ reportedlocations. We first prove that the location privacy is notleaked before transforming. The location privacy is notleaked when obtaining the route because this process is con-ducted solely on the driver side, i.e., local smartphone, with-out any interaction with the navigation service provider,RSUs, or other drivers.

Theorem 1. PiSim protects location privacy under the knownbackground model where RSUs and the NSP know somebackground information from other public traffic-relateddatabases, e.g., locations and their congestion degree.

We give the proof in the Appendix.(3) Route Privacy. Any requesting driver’s route must

be preserved when they submit a navigation query to theNSP. A route contains a set of locations. Given that locationprivacy is preserved (Theorem 1), we know that the adver-sary cannot know the real location by eavesdropping thecommunication channel. Also, since the drivers use differentrandom numbers to generate location index and trapdoor,the adversary cannot tell if two indexes or trapdoors aregenerated from the same location. In the end, the A cannotrequest a navigation route based on the start point andendpoint since they are also preserved. Therefore, the routeprivacy is well preserved.

(4) Unlinkability. As the CL-signatures, a signature Erdion a message si can be randomized by selecting a randomr

$←− Zp that is also a valid signature on si: it equalsto replace g with gr. Linking (Ei1, Ei2, e(Ei1, B)) with(Er1i1 , E

r1i2 , e(Ei1, B)r1r2) is equivalent to breaking the DDH

assumption.When generating a new request-limiting pseudonym

rlpi = gsirlpi where grlpi = H(te||rci)(Υ−1)/ρ, the requestingdriver rdi has to choose a new rci. This along with the

current time epoch te guarantee that any two pseudonymsfrom the same requesting driver are different.

Besides, two different pseudonyms with a same grlpmust indicate that they must come from two differen-t drivers. Concretely, say rd1 and rd2 are querying forthe first time, then grlp1 = H(te||1)(Υ−1)/ρ = grlp2 =H(te||1)(Υ−1)/ρ. But their pseudonyms rlp1 6= rlp2, sincetheir secrets s1 6= s2, and rlp1 = gs1rlp1 , rlp2 = gs2rlp2 . Further-more, every time a requesting driver (contributing driver)generates a location index (query index), a different numberis picked to split the index KI (QI), resulting in a com-pletely different Index EncSK(KI) (Query EncSK(QI)).To conclude, given two navigation queries (driving reports),any adversary cannot identify whether they are generatedfrom the same requesting driver (contributing driver).

Security.(1) We now prove that PiSim provides authentication.

Definition 1. (Assumption) Let (p,G1,G2,GT , e) be a type 3bilinear group setting, with g and g being a generatorof G1 and G2, respectively. For secret keys (a, b) andpublic keys (A,B)← (ga, gb), we define an oracleO(m)on an imput m ∈ Zp that randomly select a z ∈ G1

and returns a pair (z, za+mb) [27]. Given (g,A,B) andunlimited access toO, no PPT adversary can output sucha pair for a new m∗ that is not queried to O.

Theorem 2. PiSim provides authentication, i.e., drivers’ i-dentities are authenticated by RSUs and any adversaryA cannot forge a valid group signature if the assumptionabove holds in the generic bilinear group model.

We give the proof in the Appendix.(2) Given that PiSim requires the requesting drivers to

show the possession of a secret, then PiSim prevents arequesting driver from creating an unlimited number ofcredentials [28]. Meanwhile, the MC-setting authenticationprocess guarantees that a requesting driver can only pro-duce MC valid rlp for a certain time epoch. In this way, thenavigation system defends the “multiple requesting attack”.

(3) During the route retrieval phase, each RSU buildsa weighted proximity graph WPG [17] and conducts trustpropagation iteratively in WPG. Till the trust values ofall nodes stay the same after iterations, the RSU can cutoff nodes with a low trust value and then drop their cor-responding data, false driving reports. By doing so, thenavigation system defends the spurious reporting attack.If a node with a higher trust value is malicious due tomaloperations or some other temporary reasons, it will senda false driving report including an abnormal speed. Such areport will not be accepted by nearby drivers since it cannot





be verified during handshakes, regardless of the maliciousnode’s higher trust value. Therefore, the proposed schemecan defend such an attack.

We compare PiSim with existing work in Table 1. OnlyPiSim can provide all the design objectives, especially routeprivacy. To be specific, the first four studies [22], [24], [25],[26] are constructed on the geo-indistinguishability [22]that transforms a given location to a different but nearbylocation. Meanwhile, [24] considered the temporal correla-tions of a user’s continuous locations, and [25] changed thesemantic meanings of submitted locations. [26] consideredthe spatiotemporal event. Unfortunately, they still confinethe submitted locations in a certain area, thereby revealingthe driver’s location area and route to an NSP under similarqueries. This is because the NSP can obtain the roughstart location and end location of the driver, and calculatea navigation route based on the two locations. Further-more, any adversary eavesdropping on the communicationchannel can acquire the two locations and submit them tothe NSP for the navigation route. RSU in RSCM [8], andservice provider in AMA [4] and P-SPAN [10] can decryptrequesting users’ locations, thus leaking users’ locations androute. Although ASAP [9] used the cloaking technique tohide the real locations, still it reveals location area and routeunder similar queries.

7 PERFORMANCE ANALYSIS

7.1 Experiment SettingsWe instantiated n1 = 1000 rds, n2 = 1000 cds, 10 RSUs, 1NSP, and 1 TA on a laptop. We used Miracl [41] as crypto-graphic toolset and defined an elliptic curve as y2 = x3 + 1over Fp. The dataset was the real-world dataset T-Drivefrom Microsoft [42] that collected more than 10 thousandtaxi drivers’ trajectories and more than 15 million locationsin Beijing. We simulate the traffic flow by constructing theoverall traffic flow from all the geographical data on Feb. 2,2008. Then we simulate the vehicle’s mobility by randomlyselecting 1000 users as requesting drivers and 1000 users ascontributing drivers. Next, we evaluate the performance ofthe selected users (locations) based on their mobility. Thekey experimental parameters are listed in Table 2.

TABLE 2Key experimental parameters

Parameters ValueCPU/RAM Intel Core i7-7500, 2.70GHz/8192 MB

Operating system Windows 10|q|, |p|, k1, H 512, 160, 1000, SHA256N , L, num 5, 3, 3md; dis 1, 2, 3; [0, 30]

7.2 Computational CostsEntity Registration. Each driver generates a key pair andcomputes (η, η) and a signature σ. The TA mainly checksthe validity of σ and (η, η), generates a group signaturefor a driver; and creates a secret key and a public keyfor each RSU the NSP. We show the measured values forcomputational costs in Table 3. It costs the TA, a requesting

driver, and a contributing driver around 25.5 ms, 7.7 ms,and 7.7 ms.

Navigation Querying. A requesting driver computes N ∗Lhashes to form KI ; computes N ∗ 2 ∗ k1 ∗ k1 multipli-cations to form N Index EncSK(KI)s; increases rc by 1;conducts 1 subtraction and 1 division in Z∗q , 1 hash and 1exponentiation in Z∗Υ to form rlp; 1 exponentiation in Z∗Υ,1 multiplication and 1 addition in Zρ, and 1 hash to formP; and computes 2 exponentiations in G1, 1 addition and 2multiplications in Zp, 1 exponentiation in GT , and 1 hashto produce a group signature (1 bilinear pairing could beprecomputed). The time cost is approximately 6.3 ms.

Dividing Sub-routes. In the first case, i.e., manual selec-tion, we draw the number of intermediate locations (be-tween PS and PE) md from [1, 3] and draw the straight-line distance dis between PS and PE from [0, 30]. Then thedriver selects md locations along each route. In the secondcase, i.e., selection history, the driver only has to invoke thequeried locations which are recorded by the app in the firstcase. In the third case, i.e., automatic selection, the driverselects the start point and endpoint, the app automaticallycalculates a route. The experimental results in Fig. 4 indicatethat the operations in this step only bring less than 100ms to the requesting driver. Generally, the computationalcost increases with the dis and the number of intermediatelocations. Each line does not exhibit a strict linear trendbecause of the randomness in selecting locations.

Navigation Responding. An RSU verifies a navigationquery via 1 subtraction and 1 multiplication in Z∗q , 3 ex-ponentiations in GT , 3 bilinear pairings, and 1 hash; andverifies P via 1 hash, 2 exponentiations in G1, and 1 additionin G1. The time consumed is around 31.5 ms. A contributingdriver conducts 2 hashes to form pid and hsv; computesnum − 1 exclusive ORs; computes k1 ∗ k1 multiplicationsto form a QI ; and computes 2 exponentiations in G1, 1addition and 2 multiplications in Zp, 1 exponentiation inGT , and 1 hash to produce a group signature. The timeconsumed is around 5.9 ms.

Route Retrieval. An RSU verifies one driving report vianum − 1 exclusive ORs, 1 subtraction and 1 multiplicationin Z∗q , 3 exponentiations in GT , 3 bilinear pairings, and 1hash; computes 2 ∗ (k2

1 + k21 + k1) multiplications in one

Search; and computes 1 exponentiation in G1 to produce asignature with a total time of 29.1 ms. The NSP computes 1exponentiation in G1 to verify an RSU’s signature, 2 ∗ (k2

1 +k2

1 +k1) multiplications in one Search, and 1 exponentiationin G1 to produce a signature with a total time of 2.6 ms.A contributing driver computes 1 exponentiation in G1 toverify an RSU’s signature with a total time of 5.2 ms.

Driver Tracking. The TA conducts 1 exponentiation in GTand 3 bilinear pairings to search one registration item witha total time of around 10.2 ms.

7.3 Communication Overhead

In navigation querying, a requesting driver rdi submitsa navigation query NQi = (Mi, E

′i1, E

′i2, ci, ssi) with a

length of |Mi| + |E′i1| + |E′i2| + |ci| + |ssi| = 5 ∗ 1000 +160 + 160 + 256 + 1020 + 1020 + 256 + 160 = 0.98 K-Bytes. A contributing driver cdj submits a driving reportDRj = (Mj ,Query EncSK(QIj), E

′j1, E

′j2, cj , ssj) with a





TABLE 3Computational Costs

Phase Entity Registration Navigation Querying Navigation Responding Route Retrieval Driver TrackingEntity TA rd cd rd RSU cd RSU NSP rd TATime 25.2 7.7 7.7 6.3 31.5 5.9 29.1 5.2 2.6 10.1

0 5 1 0 1 5 2 0 2 5 3 0

5 0

6 0

7 0

8 0

9 0

1 0 0

Comp

utatio

nal C

osts

(ms)

D i s t a n c e b e t w e e n P S a n d P E

1 i n t e r m e d i a t e l o c a t i o n s 2 i n t e r m e d i a t e l o c a t i o n s 3 i n t e r m e d i a t e l o c a t i o n s

(a) Case 1: Manual Selection

0 5 1 0 1 5 2 0 2 5 3 00123456789

1 01 11 21 31 41 51 6

Comp

utatio

nal C

osts

(ms)

D i s t a n c e b e t w e e n P S a n d P E

1 i n t e r m e d i a t e l o c a t i o n s 2 i n t e r m e d i a t e l o c a t i o n s 3 i n t e r m e d i a t e l o c a t i o n s

(b) Case 2: Selection History

0 3 6 9 1 2 1 5 1 8 2 1 2 4 2 7 3 00

2 0

4 0

6 0

Comp

utatio

nal C

osts

(ms)

D i s t a n c e b e t w e e n P S a n d P E(c) Case 3: Automatic Selection

Fig. 4. Computational Costs of Dividing Sub-routes

length of 2+3∗256+256+256+1000+1020+1020+256+160 = 0.59 KBytes. An RSU broadcasts a traffic congestiontask and a state information, uploads n1 navigation queriesand n2 driving reports, relays n1 traffic congestion resultsand signatures to requesting drivers with a total lengthof 0.01 + n1 + 0.59n2 KBytes. The NSP returns n1 trafficcongestion results and signatures to an RSU with a totallength of 0.249n1 KBytes.

7.4 Defence EfficacyWe now evaluate the defense efficacy against spurious re-porting attack. As shown in Fig. 5(a), the time consumedin building a weight proximity graph is less than 10 mswhen there are 100 contributing drivers and they conductfive handshakes.

We use physical proximity between smartphones to setup edges which are secure attestations of nearby presence.Malicious nodes are identified by the few “attack edges”connecting them to the honest nodes, thus making themconspicuous. Trust values from honest nodes are veryunlikely to be passed to malicious nodes since the normalweight is in [2, 5] and the abnormal weight is 1. The trustpropagation is also referred to as random walks on thegraph which can be modeled as a Markov chain [43]. Thischain is guaranteed to converge to a stationary distribution.Here, the convergence does not mean the trust values staythe same, but it manifests that the trust values of eachnode in the following iterations change a little. We give anexample here, as shown in Fig. 5(b), the initial trust valuevector for ten nodes are [0, 0, 5, 0, 0, 5, 0, 0, 0, 0]. We set the9th node and 10th node as the two malicious nodes. Onlythe 9th node has one attack edge with the 3rd node. Afterseventeen iterations, the vector stays stable and it is around[1.538, 1.818, 0.944, 1.259, 1.538, 0.979, 0.909, 0.874, 0.105,0.035] in the following iterations with the fluctuation nomore than 1%. Meanwhile, the time consumed in reachinga convergence is less than 85 ms when there are 100contributing drivers and they conduct fifteen handshakes

as shown in Fig. 5(c). Next, we set 10% of total contributingdrivers as malicious and set five honest drivers as trustseeds with a trust value of 8. The trust threshold is 0.2. Asshown in Fig. 5(d), we can see that the screening accuracyincreases with the number of handshakes and number ofcontributing drivers. This is because as the handshakes andnumber of honest nodes increase, the trust value will belikely to stay in the trust zone, exposing malicious nodesmore efficiently.

The correctness of the driving reports has enabled thehonest reporting drivers to handshake and bridge near-by honest drivers who have a similar driving speed. Butmalicious reporting drivers who hold false reports cannotbridge or have fewer edges with the honest drivers whenthe honest drivers cannot acknowledge their location. Next,an RSU builds a weighted proximity graph to disseminatethe total trust value from the trust nodes to the rest of thegraph. Given that honest nodes are more connected thanthe malicious nodes, most of the total trust value will staywithin the honest zone, thus leaving the malicious node toreceive fewer trust value as validated in Fig. 5(b).

7.5 Comparison with Existing WorkNow we compare PiSim with existing work, namely A-MA [4], RSCM [8], ASAP [9], and P-SPAN [10], becausethey are adjoining works focusing on privacy-preservingvehicular LBSs and their core techniques are cryptographicprimitives.

First, we analyze the time cost for a requesting driverand a contributing driver. Concretely, an AMA passenger(i.e., requesting driver) spend 12 multiplications and 3 bilin-ear pairings, while an AMA driver (i.e., contributing driver)spends 8 multiplications and 1 bilinear pairing. RSCM doesnot have a requesting driver, but its contributing driverspends 5 exponentiations and 4 additions in G1 and 3 hash-es. An ASAP driver (i.e., requesting driver) and spot owner(i.e., contributing driver) conduct the same operations, i.e.,5 exponentiations and 1 addition in G1, 1 addition and 2





0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 1 0 04

5

6

7

8

9

1 0

5 h a n d s h a k e s 1 0 h a n d s h a k e s 1 5 h a n d s h a k e s

Comp

utatio

nal C

osts

(ms)

N u m b e r o f C o n t r i b u t i n g D r i v e r s

(a) Building A Graph

0 2 4 6 8 1 0 1 2 1 4 1 6 1 8 2 00 . 0

0 . 5

1 . 0

1 . 5

2 . 0

2 . 5

3 . 0T r u s t v a l u e v e c t o r : [ 0 , 0 , 5 , 0 , 0 , 5 , 0 , 0 , 0 , 0 ] - >

[ 1 . 6 7 8 , 0 . 9 0 9 , 0 . 8 6 5 , 2 . 0 9 8 , 0 . 7 6 9 , 1 . 8 8 8 , 0 . 7 6 9 , 1 . 0 2 3 , 0 , 0 ] - >· · · · · · - >

[ 1 . 5 3 8 , 1 . 8 1 8 , 0 . 9 4 4 , 1 . 2 5 9 , 1 . 5 3 8 , 0 . 9 7 9 , 0 . 9 0 9 , 0 . 8 7 4 , 0 . 1 0 5 , 0 . 0 3 5 ]

Trust

Value

I t e r a t i o n

V 1 V 2 V 3 V 4 V 5 V 6 V 7 V 8 V 9 V 1 0

(b) Trust Values After Iterations

0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 1 0 0

1 0

2 0

3 0

4 0

5 0

6 0

7 0

8 0

9 0


Comp

utatio

nal C

osts

(ms)


(c) Trust Convergence

0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 1 0 09 09 19 29 39 49 59 69 79 89 9

1 0 0


Scree

ning A

cccura

cy (%

)


(d) Screening Accuracy

Fig. 5. Defence Efficacy

0 1 0 0 2 0 0 3 0 0 4 0 0 5 0 0 6 0 0 7 0 0 8 0 0 9 0 0 1 0 0 00

1 0

2 0

3 0

4 0

5 0

Comp

utatio

nal C

osts

(s)

N u m b e r o f Q u e r i e s

A M A A S A P P - S P A N P i S i m

(a) Time cost of requesting driver

0 1 0 0 2 0 0 3 0 0 4 0 0 5 0 0 6 0 0 7 0 0 8 0 0 9 0 0 1 0 0 00

5

1 0

1 5

2 0

2 5

3 0 A M A R S C M A S A P P i S i m

Comp

utatio

nal C

osts

(s)

N u m b e r o f R e p o r t s

(b) Time cost of contributing driver

0 1 0 0 2 0 0 3 0 0 4 0 0 5 0 0 6 0 0 7 0 0 8 0 0 9 0 0 1 0 0 00

5 0

1 0 0

1 5 0

2 0 0

2 5 0

3 0 0

3 5 0

4 0 0

Comp

utatio

nal C

osts

(s)

N u m b e r o f Q u e r i e s ( R e p o r t s )

R S C M P - S P A N P i S i m

(c) Time cost of RSU

2 0 0 4 0 0 6 0 0 8 0 0 1 0 0 00

1 0

2 0

3 0

4 0

5 0

Comp

utatio

nal C

osts

(s)

N u m b e r o f Q u e r i e s ( R e p o r t s )

A M A A S A P P - S P A N P i S i m

(d) Time cost of NSP

Fig. 6. Comparison of Computational Costs

multiplications in Zp, 1 exponentiation in GT , and 1 hash. AP-SPAN driver (i.e., requesting driver) conducts 14 exponen-tiations and 2 addition in G1, 1 AES encryption, 3 hashes,2 additions and 4 multiplications in Zp. The comparisonresults in Fig. 6(a) and Fig. 6(b) show that PiSim outperformsother schemes.

Considered that AMA and ASAP do not have RSU, wepreclude them in comparison. An RSCM RSU aggregates,verifies, and then decrypts reports from contributing driver-s. A P-SPAN RSU verifies queries from requesting driversand retrieves navigation results. From the comparison re-sults in Fig. 6(c), we can see that the time cost of a PiSimRSU is a little over the one of P-SPAN because we haveallocated the verification task from the NSP to RSUs andused lightweight matrix operations to retrieve a navigationresult.

We exclude RSCM in NSP comparison for not possessinga service provider. An AMA service provider verifies zero-knowledge proofs and retrieves results. An ASAP serviceprovider verifies and decrypts the queries and reports fromdrivers. A P-SPAN service provider verifies and decryptsthe queries, and generates navigation results. From theFig. 6(d), the time cost of a PiSim service provider is thelowest.

Meanwhile, we show the comparison results of commu-nication overhead in Table 4. PiSim also exhibits moderateperformance. The RSCM RSU has 0 messages to send be-cause it acts as a service provider and does not have to sendit to another entity. The RSCM contributing driver has alower communication overhead due to the utilization of acertificateless aggregate signcryption scheme.

7.6 Experiments with Smartphone and Server

We also conduct experiments on an Android smartphoneand two desktops with detailed hardware parameters in

TABLE 4Comparison of Communication Overhead (Kbytes).

Entity AMA RSCM ASAP P-SPAN PiSimru 0.69 N/A 0.62 1.37 0.98cd 0.69 0.314 0.62 N/A 0.59RSU N/A 0 N/A 1.54n1 n1 + 0.59n2

SP 0.16n1 N/A 0.5n2 0.75n3 0.25n1

Table 5. We developed an Android application on a smart-phone, used the Springboot framework for the RSU andthe server, chose Java to write action logic, and enabledcommunications between the smartphone and the RSU viahttp post. The screenshots of the application are shown inFig. 7.

We choose the southwest gate of Beijing University ofTechnology as the start point, the Xizhimen as the endpoint.The five locations are the intersection of ZhongguancunSouth Street and Weigongcun Road, Minzu University ofChina, National Library, Baishi New Bridge, and BeijingZoo. The computational costs for rd, cd, RSU, and NSP are230 ms, 210 ms, 90 ms, and 8 ms, respectively.

TABLE 5Hardware Parameters

Smartphone (Google Pixel)CPU Qualcomm Snapdragon 821 2.15Ghz with 4 cores

Memory/OS 4096 MB/Android 9 “Pie”Desktop (Lenovo)

CPU Intel(R) Core(TM) i3-7100 3.90Ghz with 2 coresMemory/OS 8192 MB/Microsoft Windows 10





TABLE 6Location Privacy Analysis under Similar Queries

Measurement [22] [24] [25] [26] [4] [8] [9] [10] PiSimLevel of L.P.1 L1 L1 L1 L1 L0 L0 L1 L0 L2

Ns 3 10 100 3 10 100 3 10 100 3 10 1000 0 md

20 n/a

Dist 27.6 13.9 6.8 55.2 21.8 13.5 22.1 8.7 5.4 35.9 14.2 8.8L0: adversary knows real location; L1: adversary knows only location area; L2: adversary knows nothing. 1: Location Privacy.

(a) Login (b) Pick locations (c) Form a route

Fig. 7. Implementation of PiSim

7.7 Location Privacy Analysis under Similar Queries

We mainly protect location privacy under similar queries innavigation services. It is achieved by facilitating anonymousauthentication and privacy-preserving multi-keyword fuzzysearch. Our location privacy metric is twofold.

First, we measure the location privacy level by checkingwhat location information can be recovered by the adver-sary. level L0: adversary obtains the real location; level L1:adversary obtains location area but not the real location;level L2: adversary obtains neither the real location nor thelocation area. [22], [24], [25], and [26] achieve L1 since theyperturb the real locations with noises. The location privacylevel of AMA [4], RSCM [8], and P-SPAN [10] are L0 becausethe three schemes can decrypt the plaintexts of real locationsat server or RSU. ASAP [9] has a location privacy level ofL1 because it uses a cloaked area to hide the real location.

Second, we quantify the privacy leakage by measuringthe distance between the estimated location and the reallocation. This metric is mainly designed for the four above-mentioned differential privacy-based schemes. Intuitively,the more the driver submits similar queries, the more accu-rate the location area will be. Since the four schemes revealthe location area, we first start with a real location Pr , andthen delimit the location area center after Ns queries as wellas the center of the area. Next, we compute the distanceDist between the estimated location Pe and Pr. The finalresult is recorded in Table 6. We set ε = 0.5 as a moderatechoice. Specifically, [22] proposed geo-indistinguishabilityand used planar Laplace noises. [24] proposed δ-location setand used sensitivity hull to expand the candidate area. [25]shifted a location to a point-of-interest based on [22] whilepreserving service usability. [26] proposed ε-spatiotemporal

event privacy and leveraged Laplace mechanism. From theTable 6, the first four Dists decrease as Ns increases sincethe location area becomes more precise when a driver sub-mits more similar queries. For [4], [8], [10], Dist is 0 becausethe real location is disclosed to RSU or service provider.Dist of [9] is less than the md, i.e., the distance betweenthe center and the farthest location, because the distancebetween any location within the cloak and the center is lessthan md.

8 DISCUSSIONS

8.1 One Optimal Route Vs. Several Optional RoutesOur heuristics are based on a social behavioral norm, i.e.,drivers are familiar with most frequently traveled routes.In the description of PiSim, we assume there is one opti-mal route for each requesting driver. This assumption isreasonable for two reasons: (1) we aim to protect driverprivacy in navigation services under similar queries, so wehave to choose at least one route between the same startpoint and the endpoint; and (2) seasoned drivers have apreferential route between two frequently visited sites, e.g.,home and work, as it minimizes travel time. At all events,the requesting drivers can query the traffic congestion onany route. It means that we also consider the existenceof several optional routes and the requesting drivers canchoose different locations and different routes.

To support the second reason, we initiated a ques-tionnaire [44] on the crowdsourcing marketplace Mechan-ic Turk: “Do you have a preferential route between twofrequently visited locations (e.g., home, work)?” with threeanswers “Yes”, “No”, and “Not sure”. From Nov. 12, 2019 toJan. 20, 2020, we collected 1000 answers from 1000 workers(i.e., answerers) with 969 “Yes”, 18 “No”, and 13. “Notsure”, i.e., 96.9% of the workers agreed with our assump-tion. Some comments are “people are creatures of habits”and “Many people like routines and will stick to what theyare used to”. Therefore, we believe that our assumptionis reasonable. We put screenshots of the questionnaire onGithub because the questionnaire is completed thus notvisible from a public view on Mechanic Turk.

8.2 Route MemoryIt is understandable to say that PiSim is limited in somescenarios at first glance since our heuristic is based onthe assumption that “drivers are familiar with their trav-eled routes”. Therefore, to support the assumption of routememory and see how people respond to this assumption,we initiated a second questionnaire [45] “Do you thinkit is possible to remember the sub-routes of a frequentlytraveled route?” with “Yes”, “No”, and “Not sure” being





three answers. From February 17, 2020 to May 4, 2020, wecollected 1000 answers from 1000 workers with 916 “Yes”,43 “No”, and 41 “Not sure”, i.e., 91.6% of the workersagreed with our assumption. In addition, PiSim can beapplied to the scenario where drivers do not know how tomanually choose locations by automatically dividing a routeon the app.

8.3 New Driver In Town

For a requesting driver just arriving at a new town, it isdifficult to query the traffic congestion on certain locationsshe/he has never been to. We ask the driver to query anavigation route using existing methods, e.g., route exten-sion [25] and route dividing based on the Dijkstra algorithm.Meanwhile, if traveling the route for some time, she/he willbe acquainted with the route by memory and remindersfrom friends. Furthermore, we add a route-recording func-tion to record the frequently traveled routes and locations inthe app, making it more convenient for requesting driversto query traffic in future travels.

8.4 Route Adjustment

We acknowledge that traffic varies over time. Selectingand fixing a route is just one function of PiSim. It alsosupports adjustments during the travel. For example, Alicehas selected several locations and obtained their trafficinformation, and she starts driving toward her endpoint.But after traveling halfway, she noticed some traffic jamsahead of her on the fixed route, she can query traffic onother manually selected locations, or she can query trafficon the locations automatically selected by the app whichtakes the current location as the new start point.

8.5 Collusion Attack

Collusion attacks between drivers and RSUs or TMSP, i.e.,the malicious drivers share everything they have with RSUsor TMSP to infer the real identity and real location of honestdrivers. Under this attack, PiSim guarantees that the collud-ing parties only know some honest driver is driving withinthe proximity of the malicious driver, while not knowingher/his real identity or real location. This is because thehonest driver is hidden among the group of honest drivers.To strengthen the efficacy of privacy protection, we willfurther disassociate the pseudo-identity and the location ofhonest drivers by leveraging mix-zone techniques [46].

9 CONCLUSION

We have presented a novel privacy-preserving navigationsystem supporting similar queries for vehicular networks.PiSim protects location privacy and route privacy basedon location-sensitive hashing. Besides, to defend multiplerequesting attacks, PiSim enables the navigation system toprevent them from submitting more than one queries ata time. With PiSim, drivers can readily participate in thenavigation system without any privacy concerns on theirlocations or routes.

ACKNOWLEDGMENT

This work was supported by Anhui Provincial Natural Sci-ence Foundation under the grant No. 2008085MF196, AnhuiScience and Technology Key Special Program under thegrant No. 201903a05020016, and National Natural ScienceFoundation of China (NSFC) under the grant No. U1836102.It is partially supported by EU LOCARD Project underGrant H2020-SU-SEC-2018-832735. We also thank JingchengZhao and Kai Cui for their assistance in the node trustexperiment.

REFERENCES

[1] A. M. Vegni and V. Loscrı, “A survey on vehicular social net-works,” IEEE Communication Surveys & Tutorials, 2015, 17 (4): 2397-2419.

[2] Z. Ning, F. Xia, N. Ullah, X. Kong, and X. Hu, “Vehicular SocialNetworks: Enabling Smart Mobility,” IEEE Communications Maga-zine, 2017, 55(5): 49-55.

[3] X. Kong, F. Xia, Z. Ning, A. Rahim, Y. Cai, Z. Gao, and J. Ma,“Mobility dataset generation for vehicular social networks basedon floating car data,” IEEE Trans. Vehicular Technology (TVT), 2018,67 (5): 3847-3886.

[4] J. Ni, K. Zhang, X. Lin, H. Yang, and X. Shen, “AMA: Anonymousmutual authentication with traceability in carpooling systems,”Proc. IEEE International Conference on Communications, 2016: 1-6.

[5] Y. Luo, X. Jia, S. Fu, and M. Xu, “pRide: Privacy-preserving ridematching over road networks for online ride-hailing service,”IEEE Trans. Information Forensics and Security (TIFS), 2019, 14(7):1791-1802.

[6] M. Nabil, A. Sherif, M. Mahmoud, A. Alsharif, and M. Abdallah,“Efficient and privacy-preserving ridesharing organization fortransferable and non-transferable services,” IEEE Trans. Dependableand Secure Computing (TDSC), 2019, PP(99): 1-16.

[7] M. Li, L. Zhu, and X. Lin, “Efficient and privacy-preservingcarpooling using blockchain-assisted vehicular fog computing,”IEEE Internet of Things Journal, August 2018, PP (99): 1-13. DOI:10.1109/JIOT.2018.2868076.

[8] S. Basudan, X. Lin, and K. Sankaranarayanan, “A privacy-preserving vehicular crowdsensing based road surface conditionmonitoring system using fog computing,” IEEE Internet of ThingsJournal, 2017: 772-782.

[9] L. Zhu, M. Li, Z. Zhang, and Z. Qin, “ASAP: An anonymoussmart-parking and payment scheme in vehicular networks,” IEEETrans. Dependable and Secure Computing (TDSC), 2020, 17 (4): 703-715. DOI: 10.1109/TDSC.2018.2850780

[10] J. Ni, K. Zhang, Y. Yu, X. Lin, X. Shen, “Privacy-preservingsmart parking navigation supporting efficient driving guidanceretrieval,” IEEE Trans. on Vehicular Technology (TVT), 2018, 67 (7):6504-6517.

[11] K. Moskvitch, “Can a city every be traffic jam-free?” BBC News,2014. http://www.bbc.com/future/story/20140611-can-we-ever-end-traffic-jams.

[12] D. Hedgpeth, “It’s a waste of time: Washington is No. 3in traffic congestion, study says.” The Washington Post, 2019.https://www.washingtonpost.com/local/trafficandcommuting/its-a-waste-of-time-washington-is-no-3-in-traffic-congestion-study-says/2019/08/22/e6602e0e-c4d6-11e9-b72f-b31dfaa77212 story.html?noredirect=on.

[13] J. Ni, X. Lin, K. Zhang, and X. Shen, “Privacy-preserving real-time navigation system using vehicular crowdsourcing, Proc. IEEEVehicular Technology Conference (VTC-Fall), 2016: 1-5, Montreal,Canada.

[14] D. J. Wu, J. Zimmerman, J. Planul, and J. C. Mitchell, “Privacy-preserving shortest path computation”, Proc. 23rd Annual Networkand Distributed System Security Symposium (NDSS), 2016: 1-15.

[15] C. Huang, R. Lu, X. Lin, and X. Shen, “Secure automatedvalet parking: A privacy-preserving reservation scheme for au-tonomous vehicles,” IEEE Trans. Vehicular Technology (TVT), 2018,67 (11): 11169-11180.

[16] G. Wang, B. Wang, T. Wang, A. Nika, H. Zheng, and B. Y.Zhao, “Defending against sybil devices in crowdsourced mappingservices,” Proc. the 14th Annual International Conference on MobileSystems, Applications, and Services (MobiSys), 2016, pp. 179-191.





[17] M. Li, L. Zhu, and X. Lin, “Privacy-preserving traffic monitoringwith false report filtering via fog-assisted vehicular crowdsens-ing,” IEEE Trans. Services Computing (TSC), 2019, PP (99): 1-16. DOI:10.1109/TSC.2019.2903060.

[18] Google Maps. http://www.google.cn/maps.[19] Waze. https://www.waze.com.[20] Y. Zhang, C. Xu, X. Lin, and X. Shen, “Blockchain-based public

integrity verification for cloud storage against procrastinatingauditors,” IEEE Trans. Cloud Computing (TCC), 2019, PP (99): 1-15.DOI: 10.1109/TCC.2019.2908400.

[21] M. Li, L. Zhu, and X. Lin, “CoRide: A privacy-preservingcollaborative-ride hailing service using blockchain-assisted vehic-ular fog computing,” Proc. ACM 15th EAI International Conferenceon Security and Privacy in Communication Networks (SecureComm),2019: 408-422, Orlando, USA.

[22] M. E. Andres, N. E. Bordenabe, K. Chatzikokolakis, and C.Palamidessi, “Geo-indistinguishability: Differential privacy forlocation-based systems,” Proc. 20th ACM Conference on Comput-er and Communications Security (CCS), November 2013: 901-914,Berlin, Germany.

[23] S. B. Wicker, “The loss of location privacy in the cellular age,”Communications of the ACM, 2012, 55 (8): 60-68.

[24] Y. Xiao, L. Xiong, S. Zhang, and Y. Cao, “LocLok: Location cloakingwith differential privacy via hidden markov model,” Proc. Interna-tional Conference on Very Large Data Bases Endowment, 2017: 1901-1904.

[25] P. Zhang, C. Hu, D. Chen, H. Li, and Q. Li, “ShiftRoute: Achievinglocation privacy for map services on smartphones,” IEEE Trans.Vehicular Technology (TVT), 2018, 67 (5): 4527-4538.

[26] Y. Cao, Y. Xiao, L. Xiong, L. Bai, and M. Yoshikawa, “Protectingspatiotemporal event privacy in continuous location-based ser-vices,” IEEE Trans. Knowledge and Data Engineering (TKDE), 2019,PP (99): 1-13.

[27] D. Pointcheval and O. Sanders, “Short randomizable signatures,”Proc. Cryptographers’ Track at the RSA Conference (CT-RSA), 2016:111-126.

[28] G. Maganis, E. Shi, H. Chen, and D. Song, “Opaak: Using Mo-bile Phones to Limit Anonymous Identities Online,” Proc. 11thInternational Conference on Mobile Systems, Applications and Services(MobiSys), 2012: 295-308.

[29] B. Wang, S. C. Yu, W. J. Lou, and Y. T. Hou, “Privacy-preservingmulti-keyword fuzzy search over encrypted data in the cloud,”Proc. of IEEE International Conference on Computers (INFOCOM),2014: 2112-2120.

[30] Y. Xiao and L. Xiong, “Protecting locations with differential pri-vacy under temporal correlations,” Proc. 22th ACM Conferenceon Computer and Communications Security (CCS), 2015: 1298-1309,Denver, USA.

[31] A. Pham, I. Dacosta, G. Endignoux, J. R. Troncoso-Pastoriza,K. Huguenin, and J.-P. Hubaux, “ORide: A privacy-preservingyet accountable ride-hailing service,” Proc. 26th USENIX SecuritySymposium, August 2017: 1235-1252, Vancouver, Canada.

[32] Y. Luo, X. Jia, S. Fu, and M. Xu, “pRide: Privacy-preserving ridematching over road networks for online ride-hailing service,”IEEE Transactions on Information Forensics and Security (TIFS), 2019,14 (7): 1791-1802.

[33] F. Bonomi, R. A. Milito, J. Zhu, and S. Addepalli, “Fog computingand its role in the internet of things,” Proc. Workshop on MobileCloud Computing (MCC), 2012: 13-16.

[34] M. Chiang, S. Ha, C. I, F. Risso, and T. Zhang, “Clarifying fogcomputing and networking: 10 questions and answers,” IEEECommunications Magazine, 2017, 55 (4): 18-20.

[35] Q. Kong, R. Lu, M. Ma, and H. Bao, “A privacy-preserving andverifiable Querying scheme in vehicular fog data dissemination,”IEEE Trans. on Vehicular Technology (TVT), 2019, 68 (2): 1877-1887.

[36] J. Ni, K. Zhang, Y. Yu, X. Lin, and X. Shen, “Providing taskallocation and secure deduplication for mobile crowdsensing viafog computing,” IEEE Trans. Dependable and Secure Computing,2018, PP (99): 1-12.

[37] S. Goldwasser, S. Micali, and C. Rackoff, “The knowledge com-plexity of interactive proof systems,” SIAM J. Comput., 1989, 18(1): 186-208.

[38] J. Camenisch and A. Lysyanskaya, “A signature scheme withefficient protocols,” Security in Communication Networks, 2002: 269-289.

[39] D. B. Johnson, “A note on Dijkstra’s shortest path algorithm,”Journal of the ACM, 1973, 20 (3): 385-388.

[40] L. Xiao, K. Ren, Q. Zheng, and G. A. Gibson, “ShardFS vs. IndexFS:replication vs. caching strategies for distributed metadata manage-ment in cloud storage systems,” Proc. the 6th ACM Symposium onCloud Computing, 2015: 236-249.

[41] Miracl. https://miracl.com.[42] Y. Zheng, “T-Drive trajectory data sample”,

https://www.microsoft.com/en-us/research/publication/t-drive-trajectory-data-sample, 2011.

[43] E. Behrends, “Introduction to Markov chains with special empha-sis on rapid mixing,” Advanced Lectures in Mathematics, 2000.

[44] First Questionnaire on Frequently Traveled Route. http-s://github.com/cyfggnn22/Voting-Results.

[45] Second Questionnaire on Route Memory. https://worker.mturk.com/projects/3GCOF3W24N7EIK1W178OIA8Y0QR52L/tasks?ref=w pl prvw.

[46] R. Lu, X. Lin, T. H. Luan, X. Liang, and X. Shen, “Pseudonymchanging at social spots: An effective strategy for location privacyin VANETs,” IEEE Trans. Vehicular Technology (TVT), 2012, 61 (1):86-96.

Meng Li received the Ph.D. degree in ComputerScience and Technology from Beijing Instituteof Technology, Beijing, China in 2019, receivedthe B.E. degree in the Information Security fromHefei University of Technology, Hefei, China, in2010, and received the M.S. degree from Com-puter Science and Technology from Beijing In-stitute of Technology in 2013. He is now an As-sociate Researcher in the School of ComputerScience and Information Engineering, Hefei Uni-versity of Technology. He was sponsored by the

China Scholarship Council to study in the Broadband CommunicationsResearch (BBCR) Lab at University of Waterloo and Wilfrid LaurierUniversity from 2017 to 2018. His research interests include appliedcryptography, security and privacy, vehicular networks, smart grid, andedge computing.

Yifei Chen received the B.E. degree in fromHefei University of Technology, China, in 2019.He is working toward his M.S. degree in theSchool of Computer Science and InformationEngineering, Hefei University of Technology. Hisresearch interests include android application,applied cryptography, and vehicular networks.

Shuli Zheng received the BS degree from theDepartment of Electrical Engineering, and theMS and PhD degrees in computer applicationsfrom the School of Computer Science and In-formation Engineering, Hefei University of Tech-nology, in 1996, 1998, and 2003, respectively.She is an Associate Professor with the Schoolof Computer Science and Information Engineer-ing, Hefei University of Technology. Her researchinterests include information hiding and multime-dia content security.

Donghui Hu received the B.S. degree from An-hui Normal University, Wuhu, China, in 1995, theM.S. degree in computer science and technol-ogy from University of Science and Technolo-gy of China, Hefei, China, in 2004, and Ph.D.degree in information security from Wuhan Uni-versity, Wuhan, China, 2010. He was a VisitingResearcher with University of North Carolina atCharlotte from 2013 to 2014. Currently, he is aProfessor in the School of Computer Scienceand Information Engineering at the Hefei Univer-

sity of Technology. His research interests include information trustwor-thiness evaluation and privacy protection.





Chhagan Lal is currently working as a postdoc-toral research fellow at Simula Research Labo-ratory, Norway. Previously, he was a postdoctoralfellow at Department of Mathematics, Universityof Padua, Italy, where he was part of the SPRITZresearch group. He received his PhD in Comput-er Science and Engineering from the MalaviyaNational Institute of Technology, Jaipur, India, in2014. During his PhD, he has been awarded withthe Canadian Commonwealth Scholarship underthe Canadian Commonwealth Scholarship Pro-

gram to work in University of Saskatchewan, Saskatoon, SK, Canada.His current research areas include applications of blockchain technolo-gies, security in software-defined networking, and Internet of Thingsnetworks.

Mauro Conti is Full Professor at the Univer-sity of Padua, Italy, and Affiliate Professor atthe University of Washington, Seattle, USA. Heobtained his Ph.D. from Sapienza University ofRome, Italy, in 2009. After his Ph.D., he was aPost-Doc Researcher at Vrije Universiteit Am-sterdam, The Netherlands. In 2011 he joinedas Assistant Professor the University of Padua,where he became Associate Professor in 2015,and Full Professor in 2018. He has been VisitingResearcher at GMU, UCLA, UCI, TU Darmstadt,

UF, and FIU. He has been awarded with a Marie Curie Fellowship (2012)by the European Commission, and with a Fellowship by the GermanDAAD (2013). His research is also funded by companies, includingCisco, Intel, and Huawei. His main research interest is in the area ofSecurity and Privacy. In this area, he published more than 300 papersin topmost international peer-reviewed journals and conference. He isArea Editor-in-Chief for IEEE Communications Surveys & Tutorials, andAssociate Editor for several journals, including IEEE CommunicationsSurveys & Tutorials, IEEE Transactions on Information Forensics andSecurity, IEEE Transactions on Dependable and Secure Computing,and IEEE Transactions on Network and Service Management. He wasProgram Chair for TRUST 2015, ICISS 2016, WiSec 2017, ACNS 2020,and General Chair for SecureComm 2012 and ACM SACMAT 2013. Heis Senior Member of the IEEE.


Documents

Privacy-preserving Navigation Supporting Similar Queries