Hail the Closest Driver on Roads: Privacy-Preserving Ride Matching in Online Ride Hailing Services

Online ride hailing (ORH) services enable a rider to request a driver to take him wherever he wants through a smartphone app on short notice. To use ORH services, users have to submit their ride information to the ORH service provider to make ride matching, such as pick-up/drop-off location. However, the submission of ride information may lead to the leakages of users’ privacy. In this paper, we focus on the issue of protecting the location information of both riders and drivers during ride matching and propose a privacy-preserving online ride matching scheme, called pRMatch. It enables an ORH service provider to find the closest available driver for an incoming rider over a city-scale road network, while protecting the location privacy of both riders and drivers against the ORH service provider and other unauthorized participants. In pRMatch, we compute the shortest road distance over encrypted data by using road network embedding and partially homomorphic encryption and further efficiently compare encrypted distances by using ciphertext packing and shuffling. *e theoretical analysis and experimental results demonstrate that pRMatch is accurate and efficient, yet preserving users’ location privacy.


Introduction
e widespread adoption of smartphones embedded with GPS, combined with the availability of digital road maps, provides the necessary enabling technologies for online ride hailing (ORH) services, such as Uber (http://www.uber. com), Lyft (http://www.lyft.com), and DiDi Chuxing (http://www.didiglobal.com). As reported in [1], 30% urban American adults had used ORH services, which have already far out-paced the growth of traditional carsharing services of the past. e general feature of ORH services is the ability for a rider to request a driver to take him exactly where he needs to go, via his ORH app. Upon receiving a rider's request, the ORH service provider makes ride matching between the rider and available drivers and forwards the request to the closest driver.
Unfortunately, along with the high convenience of ORH services come some important privacy concerns [2,3]. To provide better services, ORH services require users to submit ride information to make ride matching, such as riders' pickup and drop-off locations. is private information is usually sensitive and can be used to identify an individual or infer his/her daily activity. For example, if a driver Bob accepts a ride request: picking up a rider Alice at a particular location l at time t, it reveals that both Bob and Alice will be at location l at time t. Actually, an ORH service provider is not always fully trusted, it might collect users' ride information to profile them or infer additional sensitive information from harvested data for purpose of economic benefit. Furthermore, even if an ORH service provider is honest, it may be attacked by other adversaries. Nowadays, risks of data leakage happen more frequently than ever before. e leakages of users' ride information may pose threats on users' financial or personal safety. erefore, it is a major technical challenge to enable ORH services while protecting users' privacy.
Many privacy-enhanced solutions for ORH services are proposed to protect users' privacy during ride matching. ese solutions are based on either nonencryption or encryption. Nonencryption solutions usually employ spatial cloaking [4], geographic masking [5], mix-zone [6], and differential privacy [7] to trade-off between the level of privacy preserving and the quality of ORH service. ese solutions are of high-efficiency, but provide limited privacy preservation and suffer from distortion of location information. To improve quality of services, encryption solutions are proposed, which provide strong privacy preservation at the cost of heavy computation and communication cost. ese encryption-based solutions integrate well-established cryptographic tools, such as private information retrieval (PIR) [8], secure multiparty computation (SMC) [9], private set intersection (PSI) [10], somewhat homomorphic encryption (SHE) [11], and partially homomorphic encryption (PHE) [12] to accomplish private distance measurements for ride matching. For efficiency, most existing encryptionbased solutions use Euclidean distance as the travel cost metric, such as PrivateRide [4], ORide [13], and TRACE [14]. However, Euclidean distance may lead to false hits, because drivers always travel along road network. As evaluated in our experiments, roughly 15% false hits exist when using Euclidean distance to make ride matching. Actually, road distance should be used to evaluate the travel cost between riders and drivers, which can achieve a higher accuracy. As studied in [15,16], it is a complex problem to compute the shortest road distance under city-scale road networks in the encrypted form. Existing secure shortest road distance approaches are not efficient enough to support online ride matching, which requires heavy cost on shortest road distance computation in real time. It is desired that there exists an encryption-based scheme to efficiently make ride matching for ORH services by using road distance.
In this paper, we focus on the issue of the leakage of user's location privacy during ride matching and propose a privacy-preserving online ride matching scheme, called pRMatch. It enables an ORH service provider to find the closest available driver for an incoming rider over a cityscale road network, while protecting the location privacy of both riders and drivers against the ORH service provider and other unauthorized participants. We summarize the following main contributions: (i) We propose a privacy-preserving ride matching scheme for ORH services (pRMatch), which enables an ORH service provider to select the closest driver for an incoming rider by using approximate road distance, while preventing users' location privacy from disclosing to the ORH service provider and other curious participants.
(ii) We propose an efficient shortest road distance computation approach, which computes the shortest road distance over encrypted data by using road network embedding and partially homomorphic encryption.
(iii) We design a secure comparison protocol, which efficiently compares encrypted distances by using ciphertext packing and shuffling.
(iv) We implement pRMatch and perform extensive experiments to validate its accuracy and efficiency. Experimental results demonstrate that pRMatch is secure without hampering the functionality of ORH services. e remainder of this paper is structured as follows: in Section 2, we describe the system model and give the problem definition; in Section 3, we list necessary preliminaries; in Section 4, we describe pRMatch scheme in details; in Section 5, we discuss theoretical analysis of pRMatch; in Section 6, we present the evaluation; in Section 7, we review the related literature. Finally, we summarize this paper.

Models and Problem Definition
Over a city-scale road network, pRMatch provides strong privacy guarantees to both drivers and riders during ride matching, without sacrificing the usability of the ORH services. As shown in Figure 1, pRMatch involves four participants: e ORH service provider (SP) handles incoming ride hailing requests and matches riders with available drivers, based primarily on their encrypted locations.
(ii) Proxy. e proxy is a third party that offers efficient key management. With the proxy, heavy cryptographic operations can be relieved from users. (iii) Rider. A rider u is the user who submits his encrypted pick-up location l u to the SP to request a nearby available driver. (iv) Driver. A driver d is the user who updates his encrypted current location l d to the SP and waits for a new rider to serve.
Here, we assume a ride/driver has a smartphone embedded with GPS to obtain own location at anytime and anywhere, and he also installs and registers to an ORH App offered by the SP.
In our system model, we consider single-rider multidriver ride matching, which prefers instant feedback to the users without batch processing requests at a fixed time interval. e batch processing may achieve better system optimization but sacrifice the user experience, e.g., a rider may wait for a while to retrieve the matching result. is single-rider multidriver ride matching is widely practised in user-centered services, such as [4,13,14,17], which do not try to violate user experience to improve the overall system optimization.

reat Model.
e threat model of pRMatch is assumed as follows: (i) e SP and the proxy are honest-but-curious, which try to learn additional information from received message and intermediate information during the scheme execution. (ii) Users (including riders and drivers) are also honestbut-curious. at is, riders submit valid request and drivers update correct locations, but they try to harvest other unmatched users' location information. (iii) ere is no collude among the participants, including the SP and the proxy, the SP and users, the proxy and users. In practice, the SP and the proxy are usually a large service provider (e.g., Uber and Google) which understand the importance of reputation. Active attacks like collusion are easy to detect and will seriously damage their reputation once caught. (iv) Drivers are independent contractors rather than the SP's employees; thus, the SP has no authority to access to the location information they hold. (v) No external adversary can truncate or tamper the communications among the participants.

Problem Definition.
e problem that we focus on is defined as follows: given a set of drivers D that travel along the road network and an incoming rider u, to find the driver with minimum road distance to serve the rider, while preserving the location privacy of both the rider and the drivers. e problem is represented as where l u is the pick-up location, l d k is the current location of driver d k , and dist R (·, ·) represents the shortest road distance between two locations. Our design goals contain the following three-fold: (i) Accuracy. pRMatch should provide accurate ride matching results. at is, the matched driver is the closest one to serve the given request with a high probability. (ii) Efficiency. pRMatch should be efficient to support large-scale ORH services. at is, the computation and communication cost should be low enough to make ride matching over large-scale users. (iii) Privacy Preservation. In pRMatch, the location privacy of both riders and drivers should be secret to the SP, the proxy, and other users beyond authorization.

Paillier
Cryptosystem. e Paillier cryptosystem [12] is a widely used PHE that supports additive homomorphic encryption. We brief it to help illustrate and understand our scheme as follows: (i) Key Generation ((pk, sk) ← KeyGen(1 λ )). Choose two primes p, q and compute N � p × q and λ � l cm(p − 1, q − 1). en, select a random g ∈ Z * N 2 such that gcd(L(g λ mod N 2 ), N) � 1, where L(x) � (x − 1)/N. e public key and private key are pk � (N, g) and sk � λ, respectively. (ii) Encryption (c ← E(m, pk)). Let m ∈ Z N be a plaintext and r ∈ Z N be a random number. e ciphertext is given by . Given a ciphertext c ∈ Z N 2 , the corresponding plaintext can be derived as e Paillier cryptosystem has homomorphism properties: for any m 1 , m 2 , r 1 , r 2 ∈ Z N , we have

Road Network Embedding.
e road network embedding (RNE) technique [18] is used to convert the road network into a high-dimensional space, where complex shortest road distance computation can be converted to simple computation supported by existing cryptographic primitives.
A road network can be modeled as a weighted graph G � (V, E, W). Let |V| be the number of vertices in G (i.e., road intersections) and |E| be the number of edges in G (i.e., road segments). Define R as a set of O(log 2 |V|) subsets of V, i.e., where α � β � O(log|V|) and V i,j is a subset composed of 2 i random vertices of V. Given a vertex v and a subset V i,j , the shortest road distance between them is defined as where R defines a high-dimensional embedding space, where the coordinate of a vertex v ∈ V is a O(log 2 |V|)-dimensional vector: e embedded road network of G is represented as For a location l on the road segment (v s , v d ) ∈ E, its coordinate can be represented as where Without loss of generality, we assume the dimension of the embedded network is ω, s.t., ω ≤ log 2 |V| . Given two locations l s and l d , the shortest distance between them can be approximated through computing the chessboard distance between c l s and c l d , denoted by where dist C (·, ·) represents the chessboard distance between two coordinates.

pRMatch Scheme
In this section, we present our pRMatch scheme. We begin with an overview of the scheme and then detail its operations. Figure 1, the proxy generates keys and broadcasts the public key to other participants. Drivers periodically report to the SP the geographical zones where they are located. ese zones are defined by the SP to prefilter drivers quickly. When a rider wants to hail a driver, he generates the encrypted request and sends it to the SP. en, the SP prefilters all drivers on the basis of zone information and obtains candidate drivers. All candidate drivers send their encrypted locations to the SP. Upon received above ciphertexts, the SP computes all shortest road distances from the candidate drivers to the rider in encrypted form.

Overview. As shown in
e SP and the proxy perform secure comparison protocol to select the driver with the minimum road distance to serve the rider. Finally, the ride matching result is sent to the matched rider and driver.

Ride Prerequisites.
Given the road network G � (V, E, W) and the dimension ω of the embedded road network, several offline initialization works need to be executed: (i) e proxy generates a pair of keys (pk, sk). e public key pk is open to other participants, and the secret key sk is kept by itself.
(ii) e SP computes the coordinate of each vertex in G to generate the embedded road network where each coordinate is represented as a ω-dimensional vector. To support drivers prefiltering, the SP partitions the road network G into the set of zones G � z i 1≤ i≤ n . Note that Ω and G are public to all users. (iii) A driver d k periodically reports to the SP the geographical zone z d k where he is located.

Ride Matching.
When a rider hails a driver using the ORH service, the operations performed by the rider, the drivers, the SP, and the proxy are as follows ( Figure 2): (1) e rider u first computes the coordinate of his pickup location l u in the embedded road network Ω according to equation (7), denoted as c u � (c u [1], . . . , c u [ω]), and the zone where he is located, denoted as z u . en, the rider encrypts each element in c u with the public key pk using Paillier cryptosystem, denoted as Finally, the rider u sends his request R u � (⟦c u ⟧, z u ) to the SP. (2) Upon receiving the request R u , the SP selects the candidate drivers D * that is located in the zone z u and the adjacent zones of z u . en, the SP asks the candidate drivers to update their encrypted current locations. (3) For d k ∈ D * , the driver d k computes the coordinate of his current location l d k in the embedded road network Ω according to equation (7), denoted as ). en, the driver encrypts each element in c d k with the public key pk using Paillier cryptosystem, denoted as Finally, the driver d k sends his encrypted current location ⟦c d k ⟧ to the SP. (4) Upon receiving ⟦c d k ⟧ d k ∈D * , the SP computes the shortest road distances from all candidate drivers D * to the rider u in ciphertext domain. Assume the upper bound of road distance in the road network is a ℓ-bit integer. Given d k ∈ D * , the SP computes the shortest road distance between l d k and l u according to equation (8). Concretely, the SP computes the following vector ⟦dist(d k , u)⟧ over ciphertexts ⟦c d k ⟧ and ⟦c u ⟧ based on homomorphism properties of the Paillier cryptosystem: Note that E(2 ℓ ) is used to ensure all elements in ⟦dist(d k , u)⟧ are positive. To prevent the proxy from inferring the locations of u and d k , the SP shuffles these encrypted values in ⟦dist(d k , u)⟧. For every element in the new vector, no one knows its position in the original vector. Consequently, the release of the index of the minimum in a shuffled vector is meaningless and does not reveal any private information. With the random permutation function π, the original vector ⟦dist(d k , u)⟧ is permuted into the shuffled vector: It is worth noting that this permutation prevents the proxy from knowing the original position of any element in ⟦dist(d k , u)⟧. To improve the efficiency, the SP uses ciphertext packing technique to pack multiple ciphertexts into one single ciphertext, because the plaintext space of the Paillier cryptosystem is much greater than that of the upper bound of road distance. In the Paillier cryptosystem, the number of slots in a Security and Communication Networks packed ciphertext is p � [N/(ℓ + 1)], that is, we can pack p ciphertexts into one single packed ciphertext. e basic idea of ciphertext packing is introduced as follows. Suppose a 1 , · · · , a l are ℓ-bit integers (1 ≤ l ≤ p), their corresponding ciphertexts are ⟦a 1 ⟧, · · · , ⟦a l ⟧. We construct the packed ciphertext by We only need one decryption to obtain the packed plaintext and then recover a 1 , · · · , a l . Based on above ciphertexts packing, the SP packs all encrypted elements of ⟦dist(d k , u)⟧ into one single packed ciphertext: s.t., p ≥ ω. To protect the real identifiers of drivers against the proxy, the SP generates an one-time pseudonym for each driver d k ∈ D * , denoted as d k � π ′ (d k ), and we have Finally, the SP sends a set of packed ciphertexts ⟦dist(d k , u)⟧ d k ∈D * to the proxy. (5) Upon receiving these packed ciphertexts, the proxy decrypts each ciphertext in ⟦dist(d k , u)⟧ d k ∈D * with its secret key sk and then unpacks them to obtain en, the proxy runs Algorithm 1 to obtain the shortest road distances between the candidate drivers D * and the rider u and then selects the driver with the minimum road distance as the matched driver, denoted as d * . Finally, the proxy sends d * to the SP. (6) When receiving d * , the SP can learn the real identifier of d * is d * . en, the match result is sent to the driver d * and the rider u.

Complexity Analysis.
We analyze the online computation (comp.) cost and communication (comm.) cost for different participants in pRMatch. For the Paillier cryptosystem, we set N and g to 1024 bits and 160 bits, respectively. Under this assumption, one encryption (Enc) needs two 1024-bit exponentiations and one 2048-bit multiplication, and one decryption (Dec) costs essentially one 2048-bit multiplication, and a ciphertext is 2048 bits. Let mul and exp denote one 2048-bit multiplication and one 2048-bit exponentiation, respectively. At the user side, a rider (resp. driver) needs to perform ω Enc to obtain the encrypted request (resp. current location). Accordingly, ω ciphertexts need to be transferred to the SP. us, the comm. cost between the SP and a user is roughly 2048ω bits.
At the SP side, the SP performs 2ω mul and ω exp to compute one shortest road distance. e total cost of the shortest road distance computation is 2ω|D * | mul and ω|D * | exp. Besides, the SP packs ω|D * | ciphertexts into ω|D * |/p packed ciphertexts, where p � ⌊1024/(ℓ + 1)⌋. e comp. cost of above packing is ω|D * | mul and ω|D * | exp. e SP sends ω|D * |/p packed ciphertexts to the proxy, thus the comm. cost between the SP and the proxy is roughly 2048ω|D * |/p bits.
At the proxy side, the proxy primarily performs ω|D * |/p Dec to decrypt receiving ciphertexts. Afterwards, it returns one plaintext to the SP.

Security Analysis.
e SP cannot harvest any rider's pick-up location c u from ⟦c u ⟧, and any driver's current location c d k from ⟦c d k ⟧, because they are encrypted by the Paillier cryptosystem that has semantic security. e SP only learns the zone information of users and the match result, rather than the exact locations of users. e proxy also cannot learn any rider's pick-up location c u and any driver's current location c d k from dist(d k , u) d k ∈D * , because each location coordinate in the road network embedded space has been shuffled and the real identifiers of drivers have been replaced by pseudonyms. Given dist(d k , u), the proxy infers dist(d k , u) with the probability (1/ω!).
Next, we present an attack analysis to demonstrate that pRMatch effectively addresses the attacks described in Section 2.2.
(i) Against A1. To launch a daily routines tracking attack to a user, the SP/proxy needs to know his exact pick-up/drop-off location and time. In pRMatch, the drop-off event is not reported to the SP/proxy. As aforementioned, the SP cannot learn any rider's pick-up location or any driver's current location from the received ciphertext. Moreover, the SP only knows the rough pick-up time and the zone information, which is not enough to track the user. e proxy knows nothing about a ride, because each location coordinate have been shuffled. Above analysis indicates that pRMatch can tackle daily routines tracking attacks. (ii) Against A2. To launch a large-scale inference attack to a user, the SP/proxy needs to learn his identity and at least his pick-up location and time. We have analyzed that the pick-up location of a rider and the current location of a driver are never exposed to the SP or the proxy. e proxy does not even know the user's identity, because it is replaced by pseudonyms. Note that the zone size should be well-defined, because unreasonable zone size cannot protect users' location privacy against known background knowledge attack. For instance, if there is only one semantic location in a zone, then the SP will learn riders in the zone are likely to be picked up at this semantic location. From the above analysis, it is clear that it is difficult for the SP and the proxy to profile riders' and drivers' activities. (iii) Against A3. A driver can learn a rider's ride information if and only if he is matched to the rider; otherwise, the driver harvests nothing. Likewise, a rider only receives the information of his matched driver. Obviously, unauthorized ride harvesting attacks are hard to be launched.

Experimental Evaluation
Our experiments are performed on the real road network of California (http://www.cs.utah.edu/lifeifei/SpatialDataset. htm) (Figure 3(a)), which contains 21048 vertices and 21693 edges. We generate riders and drivers on the edges in a random fashion (Figure 3(b)) and set the bit length of the upper bound of road distance to 16, i.e., ℓ � 16. We implement a proof-of-concept pRMatch in C++, by relying on the Paillier cryptosystem library (http://acsc.cs.utexas.edu/ libpaillier). All our experiments are conducted and executed on a PC running Ubuntu 18.04 LTS, with an Intel i7 processor at 3.4 GHz and 16 GB RAM. pRMatch is compared with the state-of-the-art privacypreserving schemes ORide [13] and pRide [17] under the same road network. ORide utilizes the Euclidean distance metric for ride matching, and pRide is the first privacypreserving ride matching scheme using road distance metric. We build ORide on FV scheme [11] inspired from NFLlib (github.com/quarkslab/NFLlib) and FV-NFLlib (github.com/CryptoExperts/FV-NFLlib) and implement pRide on the same Paillier cryptosystem library and Obliv-C [19]. For pRide, the length of a wire in Yao's garbled circuits [9] is set to 80 bits, and the security parameter for blindness is set to 32 bits to achieve statistical security roughly 2 − 15 .
We evaluate the accuracy and the efficiency of pRMatch by varying the dimension of the embedded road network or driver scale, where the dimension ω is the element number of a coordinate in the embedded road network, as defined in equation (8), and driver scale |D| is the total number of available drivers on road.
Accuracy: we use the matching success rate (MSR) to evaluate the accuracy. A matching is successful if the matched driver is the actual driver with the minimum road distance. We define MSR � N suc /N all , where N all is the total number of matchings and N suc is the number of success matchings. Figure 4(a) depicts the MSRs of pRMatch, pRide, and ORide by varying the dimension ω from 4 to 32. We can see the MSRs of pRMatch and pRide raise steadily as the dimension of the embedded road network increases, which is more than 95% if the dimension is higher than 24.
at is because higher dimension means higher accuracy of shortest road distance computation. In contrast, Euclidean distance computation in ORide is irrelevant to the dimension, thus the MSR of ORide always stays around 85%. When the dimension is higher than 8, pRMatch and pRide outperform ORide in the terms of accuracy. is is of no surprise because both pRMatch and pRide choose road distance to make ride matching, which is more accurate than Euclidean distance. Figure 4(b) depicts u); (10) end if (11) end for (12) if k � 1 or dist * > dist do (13) dist * ← dist; (14) d * ← d k ; (15) end if (16) end for (17) return d * ; ALGORITHM 1: Best driver selection (BDS).

Security and Communication Networks
the MSRs of pRMatch, pRide, and ORide by varying the driver scale from 1000 to 4000. As shown in Figure 4(b), the MSRs of pRMatch and pRide are always high under any driver scale. is demonstrates the accuracy of pRMatch is not affected by big-scale drivers. e MSR of ORide gradually rises as the driver scale increases, because larger driver scale indicates there may exist closer drivers located around riders. However, the MSR of ORide is still less than 90%. Above experimental results demonstrate that pRMatch can reach a higher accuracy due to the choice of road distance.
Efficiency: we use average online comp. cost and comm. cost for per ride matching to evaluate the efficiency. of the embedded road network or driver scale. At the user (including riders and drivers) side, a user needs to encrypt its location coordinate in the embedded road network. As shown in Figure 5(a), the comp. cost of the rider (and the driver) in pRMatch raises with the dimension increases. e reason is that higher dimension requires more encryption operations over a location coordinate. Figure 5(b) shows the comp. cost of the rider (and the driver) stays steady under any driver scale. In addition, pRMatch costs more execution time at the user side, because it cannot pack encrypted coordinate into one single ciphertext. Nevertheless, pRMatch is still practical at the user side for resource-constrained devices. For instance, a user requires roughly 0.1 second to encrypt a 24-dimensional location coordinate. As shown in Figure 5(c) and 5(d), the comp. cost at the Security and Communication Networks server (including the SP and the proxy) side in pRMatch and pRide increases almost linearly as the dimension or the driver scale increases. It is obvious that the comp. cost at the server side in pRMatch is much lower than that in pRide. For instance, pRMatch requires about 1 second for per-matching when the dimension is 24 and the driver scale is 2000, but pRide requires more than 6 seconds. Moreover, we can see that the SP undertakes most comp. cost at the server side, and the proxy always has low comp. cost with big-scale drivers (less than 0.15 second). and 5(f ), pRMatch requires more comm. cost between the SP and the rider (and the driver) as the dimension increases, while the comm. cost is not affected by the driver scale. We can also see that the comm. cost between the SP and the rider (and the driver) in pRMatch is higher than that in pRide, but it is quite acceptable for resource-constrained devices. As shown in Figures 5(g) and 5(h), pRide requires very heavy comm. cost between the two servers, and it needs even more as the dimension or the driver scale increases. In contrast, the comm. cost between the SP and the proxy in pRMatch slowly grows with the increase of the dimension or driver scale, and it always stays low, about two orders of magnitude less than that in pRide. For instance, pRMatch requires less than 27 kBs comm. cost at the server side when the dimension is 24 and the driver scale is 2000, but pRide requires roughly 24 MBs.
Compared with ORide, pRMatch reaches higher accuracy. Compared with pRide, pRMatch achieves higher efficiency at the server side; especially, it brings an order-of-magnitude improvement in comm. cost. pRMatch requires more cost at the user side than pRide, but the cost is quite acceptable for resource-constrained devices.

Related Work
e rapid adoption of ORH services poses significant challenges for users' privacy disclosure, as there are a few studies that have emphasized the importance of privacypreserving solutions in ORH services [2]. PrivateRide [4] is the first system to enhance location privacy for riders in ORH services. It uses spatial cloaking regions to replace their actual locations. But obfuscate locations, instead of the actual locations, affect the accuracy of ride matching; the matched driver may not be the optimal one and has to drive extra distance to pick up the rider; meanwhile, the rider may wait extra time to get the ride. Moreover, PrivateRide only provides limited privacy guarantees for drivers and offers less accountability features. Later, ORide [13] is proposed to address these limitations, which provides stronger privacy and accountability guarantees for both riders and drivers based SHE and anonymous credentials. In addition, ORide applies optimizations for ciphertext packing and transformed processing, hence enabling a notable boost in performance and a reduction in overhead. TRACE [14] supports privacy-preserving spatial query based on random masking technique and point-in-polygon strategy. CoRide [20] is a blockchain-assisted system model for several SPs to establish private collaborative-rides. To achieve efficiency, these schemes utilize the Euclidean distance metric for ride matching, because it is easy to compute over encrypted data. But Euclidean distance may lead to false hits, because drivers always travel along road network. As evaluated in our experiments, it roughly 15% false hits exist when using  Euclidean distance to make ride matching. pRide [17] uses PHE and Yao's garbled circuits to compute road distance for ride matching, but its comp. cost and comm. cost at server side are very heavy. lpRide [21] adopts modified PHE and ciphertext blinding to compute the shortest road distance for ride matching without two noncollusion servers assumption. For both accuracy and efficiency, our pRMatch uses road distance as the travel cost metric to make ride matching over encrypted data without any heavy cost.
Also relevant are the works in privacy-enhanced ridesharing services. PrivatePool [22] is a privacy-preserving protocol allowing users to check their feasible ride matches through PSI and SHE. PRIS [23] is a privacy-preserving ride matching scheme for selecting feasible ridesharing partners based on PHE and bilinear pairing. SRide [24] is a privacypreserving ridesharing matching protocol based on users' spatial and temporal information, which employs SHE and SMC to compute feasible matches. Most of the previous studies have one limit that hampers their reuse in ORH service. at is, they require drivers offering ridesharing to riders along the route they had already planned to travel. It is impractical for ORH services, where riders can hail a driver to go wherever they want. To tackle this, PSRide [25] is proposed to make privacy-preserving ridesharing matching for ORH systems.
ere is a vast literature on protecting location privacy against service providers in LBSs; we summarize them into four fundamentally different ways: Location-Based k-Anonymity. It requires that the service provider cannot distinguish the request issuer from k − 1 other users such that the probability of identifying him is 1/k. To achieve this, one way is to enlarge the issuer's location to a cloaking region including k − 1 other users by using a hierarchical spatial partitioning [26,27] or space-filling curves [28]. Another way is to generate k − 1 dummies (fake locations) together with the actual request to perform k requests to the service provider [29,30]. Moreover, location l-diversity [31,32] is also introduced to enhance k-anonymity. e main drawback of k-anonymity-based solutions is the difficulty of providing provable privacy which guarantees to be independent of background knowledge. Location Obfuscation. It requires blurring or perturbing the location information contained in requests. As reviewed in [33], obfuscation techniques can be divided into three groups. Request enlargement techniques [34,35] create obfuscation areas for requests to hide users' locations. Dummy-based techniques [36,37] generate nonsensitive locations as the dummies without considering other potential users (unlike k-anonymity). Coordinate transformation techniques [38,39] change the complete coordinate reference system using geometric transformations to confuse adversaries. Generally, obfuscation cannot provide provable privacy guarantees without background knowledge, and may impact the quality of service (QoS) of LBSs. us, background knowledge is necessary for location obfuscation, e.g., PPCS [40] generates dummy locations based on entropy while considering semantic location information that might be used by attackers. Differential Privacy. Differential privacy [41] is proposed in statistical databases, which is independent of background knowledge. It can also be used for location privacy in LBSs, such as (D, ϵ)-location privacy [42] and ϵ-geo-indistinguishability [43]. e intuitive idea behind differential privacy is the following: the ratio between the probabilities of obtaining a certain output from two locations relies on their distance, that is, the privacy level increases with their distance. To achieve this, a fake location is probabilistically determined to replace the actual location in requests by running randomization functions. Differential privacy has to make a trade-off between privacy and QoS. Several studies focus on optimal trade-offs [44,45], but it still has no clear answer. Encryption-Based Solution. Many encryption-based solutions have been discussed above. Besides, cryptographic primitives have been explored in other LBSs, such as location-based kNN search [46,47] and friendfinder services [48]. Encryption-based solutions strive for stronger, provable privacy guarantees. e essential challenge is to allow for efficient responding to the requests, despite the computational complexity of the cryptographic primitives.

Conclusion and Future Work
In this paper, we focus on the issue of the preservation of location privacy of both riders and drivers during ride matching in ORH services and proposed a privacy-preserving ride matching scheme, namely, pRMatch. It enables an ORH service provider to find the closest available driver for an incoming rider over a city-scale road network, without leaking users' location privacy to the ORH service provider and other unauthorized users. In pRMatch, we proposed an efficient shortest road distance computation approach over encrypted data by using road network embedding and PHE and further designed a secure comparison protocol over encrypted data by using ciphertexts packing and shuffling. We also implement pRMatch and perform extensive experiments to validate its accuracy and efficiency. Experimental results demonstrate that pRMatch achieves about 95% accuracy and guarantees efficiency.
For future work, we will consider the safety issues during ride execution in privacy-enhanced ORH services. When the urgent safety threat happens, e.g., hijacks, a privacy-preserving scheme cannot break the safety protection.

Data Availability
e road network data of California used to support the findings of this study have been deposited in http://www.cs. utah.edu/lifeifei/SpatialDataset.htm.