pShare: Privacy-Preserving Ride-Sharing System with Minimum-Detouring Route

Abstract

Online ride-hailing (ORH) services allow people to enjoy on-demand transportation services through their mobile devices in a short responding time. Despite the great convenience, users need to submit their location information to the ORH service provider, which may incur unexpected privacy problems. In this paper, we mainly study the privacy and utility of the ride-sharing system, which enables multiple riders to share one driver. To solve the privacy problem and reduce the ride-sharing detouring waste, we propose a privacy-preserving ride-sharing system named pShare. To hide users’ precise locations from the service provider, we apply a zone-based travel time estimation approach to privately compute over sensitive data while cloaking each rider’s location in a zone area. To compute the matching results along with the least-detouring route, the service provider first computes the shortest path for each eligible rider combination, then compares the additional traveling time (ATT) of all combinations, and finally selects the combination with minimum ATT. We designed a secure comparing protocol by utilizing the garbled circuit, which enables the ORH server to execute the protocol with a crypto server without privacy leakage. Moreover, we apply the data packing technique, by which multiple data can be packed as one to reduce the communication and computation overhead. Through the theoretical analysis and evaluation results, we prove that pShare is a practical ride-sharing scheme that can find out the sharing riders with minimum ATT in acceptable accuracy while protecting users’ privacy.

1. Introduction

With the advent of GPS-embedded mobile devices and digital maps, Online Ride-Hailing (ORH) services have gained much popularity and have seen remarkable development in the past decade. Unlike traditional taxi services, ORH companies such as Uber and Didi provide a platform for riders to request a ride using few operations through their mobile devices, which has had a revolutionary impact on the ride-hailing industry [1]. According to the statistics of Didi Chuxing, they have completed over 10 billion ride-hailing orders [2].

Ride-matching is the primary function of ORH service, and it usually matches the nearest driver for any rider who starts a ride-matching request. To request the ride-matching service, the rider needs to submit his location information to the ORH service provider (i.e., the ORH company) through the ride-hailing application on their smartphone. Then the service provider matches the nearby drivers who update their locations in real time.

In order to improve the traffic utilization and the matching success rate, some ORH services also provide an enhanced function, i.e., ride-sharing service, which enables several riders with similar traveling routes to share one driver. Ride-sharing is in the broad category of the sharing economy [3], which is environmentally friendly and beneficial to all participant entities of the service. For riders, it provides a financial and efficient alternative. Moreover, it enables drivers to cut down their traveling costs and improve the revenue with payment from several passengers. Besides, it reduces the emissions of CO${}_2$ [4].

However, despite the convenience the ORH service brings, the privacy concern is also highly raised. For example, the largest Chinese ORH company, Didi Chuxing, was recently demanded to take off all applications from app stores due to a serious violation of data and privacy laws [5]. To request a ride, the rider must submit his ride information, which usually includes some private information on riders such as pick-up and drop-off locations and times. The submitted data can be analyzed for one’s mobility patterns or can even be exploited to deduce one’s home or working address. The leakage of users’ private information invades their rights and sometimes even threatens their security.

It is necessary to preserve the privacy of users, whether riders or drivers. To achieve that, many encryption techniques and privacy-enhanced solutions are designed for ride-hailing services [6,7,8,9,10,11], which provide private ride-matching schemes but do not support ride-sharing. There are also a few privacy-preserving ride-sharing schemes including SRide [12], PRIS [13], and PrivatePool [14], but they can only enable ride-sharing matches over fixed locations. PSRide is a flexible ride-sharing matching scheme, but it does not support ride-sharing between multiple riders. PGRide supports group ride-sharing matching. However, it cannot find the shortest path to pick up and drop off all riders.

Considering the issues stated above, we are motivated to research how to construct a private and practical ride-sharing mechanism, which supports flexible ride-sharing matching over multiple riders and meanwhile finds the shortest path with minimum detouring distance. However, we cannot compute the shortest path over plaintext precise locations of users due to the consideration of efficiency and privacy; thus, a zone-based method is applied to trade off between these factors. By hiding all users’ locations in distinct zones, a user’s privacy is well protected since enemies cannot distinguish from hundreds of points of interest in one zone. It is noteworthy that the matching is also computed over discretized zones, so the matching results are not necessarily optimal on a non-discretized map. In the following paper, expressions such as “minimum detouring” indicate the computing results over the zones. In Section 6, we implement pShare under zone-based estimation data and non-discretized ground-truth map data to evaluate the real accuracy of the scheme.

The ride-sharing service is an optional ride-hailing service since it can be replaced by ride-matching if there are no suitable sharing riders. Therefore, we apply the ride-sharing from the perspective of drivers and match several riders for each driver. For an available driver, the ORH server first searches his surrounding requested riders, then computes for the best matching riders with minimum detouring time. More specifically, our main contributions can be summarized as follows:

• We propose a flexible, privacy-preserving online ride-sharing matching scheme pShare, which performs matching between a shared driver and group riders with minimum detouring distance, while protecting their location privacy against the ORH service provider.
• We propose a zone-based riders-filtering approach, which can divide surrounding requested riders on the similarity of their traveling routes. Meanwhile, we have designed a secure comparing protocol, which computes users’ encrypted data and outputs the ride-sharing results along with the minimum-detouring route.
• We evaluate the scheme using generated user datasets which obey real-world distribution. The experimental results demonstrate that pShare can achieve the functionality with high accuracy and practical efficiency.

The rest of the paper is organized as follows: In Section 2, we formalize the problem and introduce the system model and the threat model. In Section 3, we present some preliminaries of the paper. Then we present the specific construction of pShare in Section 4 and the privacy analysis in Section 5, followed by performance evaluation in Section 6. Finally, we conclude our work in Section 7.

2. Model and Problem Definitions

2.1. Problem Definition

Given a driver d, supposing the passenger capacity of d is $CA{P}_d$ and the current number of onboard riders is $OB{R}_d$, we define that d could be at one of three possible situations: idle, full, and not-full, which represent $OB{R}_d=0$, $OB{R}_d=CA{P}_d$, and $0<OB{R}_d<CA{P}_d$, respectively.

The problem of our concern is, for the driver d and the riders set $\mathcal{R}$, to find the best match between the driver and v riders along with the optimal route to pick up and drop off all riders while protecting users’ privacy, in which $v⩽CA{P}_d-OB{R}_d$. The additional travel time ($ATT$) of the matching result should be minimal, and the schedule will miss no deadlines of the riders.

2.2. System Model and Threat Model

As shown in Figure 1, the system consists of four entities: an ORH server, a crypto server, the riders, and the drivers. We use the RS to represent the ORH server and the CS to represent the crypto server in the following paper. Drivers start ride-sharing queries and submit their current status when they are idle or not-full. Riders submit ride requests when they need a ride-sharing service. The RS finds the optimal riders for the driver with minimum average $ATT$. Besides, we introduce the CS to set up the cryptographic parameters and enable the matching computation. Based on the system model, we make the following assumptions:

• In our system, all entities are semi-honest. That means they always honestly follow the scheme but are curious about the information of users. So the goal of privacy is to prevent the RS or the CS from learning about users’ sensitive infomation, which includes precise locations and appointed time.
• There is no collusion between the RS and the CS because they are managed by different parties. Nor will the RS collude with the drivers because the RS is always a big company and takes much attention to the reputation.
• The communication channel between two entities is secure, which means no man-in-the-middle attack will be launched. Nobody can utilize channel information to locate users.

2.3. Design Goals

Under the proposed system model and threat model stated above, pShare system should satisfy the following design objectives:

• Accuracy. The RS should perform matching over ride-requests and drivers’ status accurately. However, there exists a trade-off between accuracy and privacy level with different zone scales. Thus, under a proper privacy level, our goal of accuracy is that the RS should be able to find riders with minimum ATT in a big probability.
• Efficiency. The system should be efficient such that the responding time for riders and drivers is all acceptable in a real-time ride-matching scenario.
• Privacy. During the whole process of the scheme, the RS and CS should be prevented from learning the precise location information of users. Riders and drivers should likewise not learn each other’s information unless they are matched.

3. Preliminaries

3.1. Paillier Cryptosystem

The Paillier cryptosystem [15] is a public-key cryptosystem with the property of additive homomorphism based on the composite residuosity assumption [1]. We briefly describe it as follows:

$\mathit{KeyGen}\to \left(pk,sk\right):$ Choose two large primes p and q, and let $n=pq$. Then compute the least common multiple $\lambda =lcm\left(p-1,q-1\right)$ and select $g\in Z_{n^2}^{\ast }$, ensuring the greatest common divisor $gcd\left(L\left(g^{\lambda }\left(mod{n}^2\right)\right),n\right)=1$, in which $L\left(x\right)=\left(x-1\right)/n$. Then the public key is $pk=\left(n,g\right)$ and the secret key $sk=\lambda$.

$\mathit{Encryption}$$:E\left(m,pk\right)\to c.$ Given a plaintext $m\in Z_n^{\ast }$, randomly select $r\in Z_n^{\ast }$ and compute the ciphertext as follows:

$$c=g^m{r}^n\left(mod{n}^2\right)$$

(1)

$\mathit{Decryption}$: $D\left(c,sk\right)\to m$. Given a ciphertext $c\in Z_{n^2}$, the corresponding plaintext can be computed as follows:

$$m=\frac{L\left(c^{\lambda }mod{n}^2\right)}{L\left(g^{\lambda }mod{n}^2\right)}modn$$

(2)

The Paillier cryptosystem described above is semantically secure. Besides, it has the following homomorphism properties:

$$E\left(m_1\right)E\left(m_2\right)=E\left(m_1+m_2\right)$$

(3)

$$E\left(m_1\right)g^{m_2}=E\left(m_1+m_2\right)$$

(4)

3.2. Garbled Circuit

Garbled circuit was first introduced by Yao [16] to solve the millionaire’s problem. It enables two parties to evaluate any function jointly such that nothing can be learned from the evaluation but their outputs. Specifically, one party first generates a garbled version of function $f\left(x,y\right)$ as the generator and obtains the garbled circuit $\widehat{f}$. Then the generator sends $\widehat{f}$ together with his garbled input $\widehat{x}$ to the other party, which is the evaluator. Then they execute a 1-out-of-2 Oblivious Transfer (OT) protocol jointly, in which the evaluator can obtain his garbled input $\widehat{y}$ without any information leakage to the generator. Then the evaluator can evaluate the garbled circuit to obtain the result of $f\left(x,y\right)$. Several optimizations have been proposed to construct Yao’s GC, such as [17,18].

3.3. Data Packing

Let $\left(t_1,t_2,\cdots ,t_n\right)$ be an n-dimensional vector. We can pack it in the following form:

$$S\left(t\right)=\sum _{j=1}^n{t}_1{x}^{j-1}$$

(5)

where $x^{j-1}$ is the parameter which is big enough to separate two values at the bit level. Similarly, for data encrypted in paillier cryptosystem $\left(⟦t_1⟧,⟦t_2⟧,\cdots ,⟦t_n⟧\right)$, we can pack it as:

$$S\left(⟦t⟧\right)=\prod _{j=1}^n{⟦t_i⟧}^{x^{j-1}}$$

(6)

By applying the data packing technique, we can use just one decryption to the packed ciphertext or one encryption to the packed plaintext.

3.4. Road Travel Time Estimation

Our approach to compute the best matching results for ride-sharing service consists of shortest road traveling time computation. Traditional methods compute it directly in large-scale road networks, which will cause an expensive computation cost and cannot be applied with cryptographic primitives. To solve this, a zone-based method could be used to estimate the road traveling time [19]

First, the road network is partitioned into $m\times n$ zones ${\left\{z\left(i,j\right)\right\}}_{{}_{\left(i,j\right)=\left(1,1\right)}}^{\left(m,n\right)}$. For each grid, we set an anchor point for travel time estimation between zones. All anchor points are selected considering the number of its adjacent edges (namely the degrees) and the geographical distance to the center of its located zone. We use ${\left\{AP\left(i,j\right)\right\}}_{{}_{\left(i,j\right)=\left(1,1\right)}}^{\left(m,n\right)}$ to represent the anchor point of each zone.

Once the process of anchor setting is finished, the travel time between zones can be estimated and precomputed with the distance between anchor points as follows:

$$t_{z\left(i,j\right)\to z\left(x,y\right)}=t_{AP\left(i,j\right)\to AP\left(x,y\right)}\left(1⩽i,x⩽m,1⩽j,y⩽n\right)$$

(7)

For any two points in the road network, we denote as s and d, respectively. The travel time between s and d can be estimated with the following expression:

$$t_{s\to d}\approx t_{s\to AP\left(s\right)}+t_{AP\left(s\right)\to AP\left(d\right)}+t_{AP\left(d\right)\to d}$$

(8)

where $AP\left(x\right)$ denotes the anchor point of the zone in which x is located. The information of road network and anchor points are public.

In our proposal scheme, for a ride request with start point s and destination d, the ride requester can easily compute $t_{s\to AP\left(s\right)}$ and $t_{AP\left(d\right)\to d}$ at the local mobile device. Then the rider can submit them after encryption to hide the precise locations s and d in two located zones.

4. Proposed Approach

In this section, we describe the architecture of pShare and the protocol details we apply to obtain the best matching results without privacy leakage of users.

4.1. System Overview

Given the locations of drivers and riders, the ride-sharing matching is to find the best combination of riders with minimum detouring time. The RS applies the matching between a driver and several riders who accept to share their ride with other passengers. Before the RS applies the ride-sharing matching, the system needs to finish the initialization. With the coarse locations of riders and drivers, the RS first executes a filtering algorithm and obtains several sets of nearby riders, which are divided in terms of the similarity of their trips. Then for each set, the RS traverses all feasible rider combinations of v riders and computes the encrypted $ATT$ of each rider combination. To compare the ciphertexts without leaking privacy, the RS and the CS execute comparing protocols using Yao’s GC together to compute the results securely. The combination with minimum $ATT$ will be selected and matched to the driver. Finally, a secure communication channel will be established between the driver and selected riders for pick-up details.

It is noteworthy that no precise locations are exposed to other entities except the user himself. All sensitive information such as location and time deadline are submitted in ciphertext form.

4.2. Protocol Details

We now describe the construction details of pShare scheme, which consists of the following five steps:

• Setup. In this procedure, the system needs to be initialized. First, the map is partitioned into zones, and the anchor point of each zone needs to be set up as described in III.D; the travel time between any two anchor points is precomputed. Then the CS generates the key pair $\left(pk,sk\right)$ and broadcasts $pk$ to other parties in the system.
• Ride Request Submit. When a rider needs the ride-sharing service, he will first compute the estimated travel time $t_{s\to AP\left(s\right)}$ and $t_{d\to AP\left(d\right)}$ using the public road network and navigation system in his mobile device, where s and d are the locations of his start point and destination point. Then he encrypts them with $pk$ and obtains $⟦t_{s\to AP\left(s\right)}⟧$ and $⟦t_{d\to AP\left(d\right)}⟧$, respectively, in which $⟦⟧$ represents the ciphertext form. After that, the rider selects the deadline of pick-up time $t_s$ and the deadline of drop-off time $t_d$ and encrypts them. Finally, the rider submits the ride-sharing request $R=\left(z\left(s\right),z\left(d\right),⟦t_{s\to AP\left(s\right)}⟧,⟦t_{d\to AP\left(d\right)}⟧,⟦t_s⟧,⟦t_d⟧\right)$.
• Driver Location Update. Similarly, the driver needs to submit his current status to finish the matching process. First, he computes $⟦t_{l\to AP\left(l\right)}⟧$ with his end device and $pk$, then submits his status $D=\left(CA{P}_d,OB{R}_d,z\left(l\right),⟦t_{l\to AP\left(l\right)}⟧\right)$, where l is the driver’s current location and v is the current vehicle load. If $OB{R}_d>0$, namely that the driver has existing riders, the schedule of driver ${\mathcal{S}}_d=\left({\left\{R_i\right\}}_{i=1}^{OB{R}_d},\mathcal{P}\right)$ should also be submitted to the RS, which include onboard riders’ encrypted requests and the existing path. The definition of path is described in the following paper.
• Riders Filtering. To mitigate the computation overhead, the RS needs to filter the riders on their coarse locations of start point and destination point (i.e., the corresponding zones) as Algorithm 1.
  On receiving from a driver’s status D, the RS first checks if there are any existing riders. If $OB{R}_d=0$, the RS searches the surrounding riders of $z\left(l\right)$ within a fixed-size region $SR$ and outputs the set ${\mathcal{R}}_{nearby}$. For each rider r of ${\mathcal{R}}_{nearby}$, the RS obtains the shortest route between $AP\left(r_i.z\left(s\right)\right)$ and $AP\left(r_i.z\left(d\right)\right)$ from precomputed data. Then the RS gets $r_i.Zpath=\left\{r_i.z\left(s\right),\cdots ,r_i.z\left(d\right)\right\}$, which represents the zones sequence the route passes through. The RS selects M riders ${\left\{{\ddot{r}}_i\right\}}_{i=1}^M$ with the longest length of $Zpath$ from ${\mathcal{R}}_{nearby}$ as the root riders, meanwhile M corresponding rider sets ${\left\{{\mathcal{R}}_i\right\}}_{i=1}^M$ are constructed. In addition, the RS computes the expanded path for each root rider of ${\left\{{\ddot{r}}_i\right\}}_{i=1}^M$. As Figure 2 indicates, $r.Zpath$ indicates the black area, and $r.EZpath$ is computed as the grey area and the black area in order to include more potential riders. For the rest of the riders, the RS compares their paths and the directions with the root riders as follows, and riders with similar traveling routes will be added to the corresponding set.

  Algorithm 1 Request Filtering Algorithm (RFA).

  Input: D, $\mathcal{R}$

  Output: ${\left\{{\mathcal{R}}_i\right\}}_{i=0}^M$

  1: for $r\in \mathcal{R}$ do 2:     if $r.z\left(s\right)\in SR$ then 3:        Add r into ${\mathcal{R}}_{nearby}$; 4:     end if 5: end for 6: Select M riders ${\left\{{\ddot{r}}_i\right\}}_{i=1}^M$ with max length of $Zpath$; 7: for 1 to M do 8:     Compute $R_i.EZpath$; 9:     Construct ${\left\{{\mathcal{R}}_i\right\}}_{i=1}^M$; 10:     Add ${\ddot{r}}_i$ to ${\mathcal{R}}_i$; 11: end for 12: for every $r\in {\mathcal{R}}_{near}$ do 13:     for 1 to M do 14:         if $r.z\left(s\right),r.z\left(d\right)\in {\ddot{r}}_i.EZpath$ and $Dir(r,{\mathcal{R}}_i)<0$ then 15:             Add r to ${\mathcal{R}}_i$; 16:         end if 17:     end for 18: end for 19: return ${\left\{{\mathcal{R}}_i\right\}}_{i=0}^M$

  For each rider $r_j\in {\mathcal{R}}_{nearby}$ except root riders, the RS judges if the following conditions are met:

  $$r_j.z\left(s\right),r_j.z\left(d\right)\in {\ddot{r}}_i.EZpathi\in \left[1,M\right]$$

  (9)

  $$\begin{array}{c}\hfill Dir\left(r_j,{\mathcal{R}}_i\right)={\ddot{r}}_i.EZpath.indexof\left(r_j.z\left(s\right)\right)-\\ \hfill {\ddot{r}}_i.EZpath.indexof\left(r_j.z\left(d\right)\right)\end{array}$$

  (10)

  where (9) indicates $r_j$ is in the path of $r_i$; when (9) is met, the RS judges if they have similar directions with the appearing order of the start point and the destination point in (10), if $r_j$. Once qualified, $r_j$ will be added to the set ${\mathcal{R}}_i$. Note that a rider could be added to more than one set.
  If $OB{R}_d>0$ and the driver has an existing schedule, the RS will refer the existing path $\mathcal{P}$ to add potential riders to just one set as the Algorithm 2 does.

  Algorithm 2 Filtering Algorithm with Existing Schedule (FAES).

  Input: D, R

  Output: $\mathcal{R}$

  1: Construct the rider set $\mathcal{R}$ 2: Compute $\mathcal{R}.EZpath$ with $\mathcal{P}$ 3: for every $r\in {\mathcal{R}}_{near}$ do 4:      if $r.z\left(s\right),r.z\left(d\right)\in \mathcal{R}.EZpath$ and $Dir(r,\mathcal{R})<0$ then 5:         Add r to $\mathcal{R}$; 6:      end if 7: end for 8: return $\mathcal{R}$

• Ride-Sharing Matching. In this module, the RS performs the ride-sharing matching with the CS in two phases. In the first phase, the RS and CS jointly compute the shortest path for all rider combinations. Each combination consists of v riders, where we usually choose $v=CA{P}_d-OB{R}_d$. If there is no eligible combination of $CA{P}_d-OB{R}_d$ riders, the RS will try with smaller combinations. After that, a comparing phase is conducted to pick out the combination with minimum $ATT$ along with the shortest path.
  Phase 1 (Path Planning) For a rider combination C with v riders, the RS finds the shortest path as follows:
  For each rider $r_{i}i\in \left[1,v\right]$ in C, we regard $\mathcal{V}={\left\{V_i\right\}}_{i=0}^{2v}={\left\{d.x,r_i.s,r_i.d\right\}}_{i=1}^v$ as vertices of a graph, the travel time between $V_i$ and $V_j$ is the corresponding edge $t_{V_i\to V_j}$. Therefore, the path-planning problem is to find the shortest path on ciphertexts that passes through all vertices.

  Definition 1. 

  Given a rider combination C, the ride-sharing path $\mathcal{P}={\left[V_i\right]}_{i=0}^{2v}$ is a vector of vertices that indicates the pick-up or drop-off order. Each vertice represents a location point of $\left\{d.l,r.z\left(s\right),r.z\left(d\right)\right\}$ together with a time constraint $t_{V_i}$. The path should cover all nodes of the graph. A legal path $\mathcal{P}$ has to meet the following constraints:

  $$\mathcal{P}\left[0\right]=d.l$$

  (11)

  $$\mathcal{P}.indexof\left(r_i.s\right)<\mathcal{P}.indexof\left(r_i.d\right)$$

  (12)

  $$\left\{\begin{array}{c}{t}_1⩽t_{V_1}\hfill \\ t_1+t_2⩽t_{V_2}\hfill \\ \cdots \hfill \end{array}\right.$$

  (13)
  To find the shortest path, the RS needs to compare all practical paths with their total traveling time. As depicted in Figure 3, for all paths that meet (11) and (12), the RS checks and selects the driving path that would not fail any deadline in (13). To do this, the RS computes the encrypted travel time for all edges using (3) and (8) and gets ${\left[⟦t_i⟧\right]}_{i=1}^{2v}$. Then the RS computes $⟦\mathcal{T}\left(\mathcal{P}\right)⟧$ for each path $\mathcal{P}$ as follows:

  $$⟦\mathcal{T}\left(\mathcal{P}\right)⟧={\displaystyle {\left[\prod _{j=1}^i⟦t_i⟧\right]}_{i=1}^{2v}}={\displaystyle {\left[⟦T_i⟧\right]}_{i=1}^{2v}}$$

  (14)

  in which $T_i$ represents the total time consumption to reach the node $v_i$.
  For each path, the RS compares each point with its deadline time. Suppose $T_1,T_2,\cdots T_{2v}$ are p-bit integers. Then the RS randomly chooses $2v$$\left(k-1\right)$-bit length integers $\mathcal{A}=\left\{a_1,a_2,\cdots a_{2v}\right\}$ ($k-1>p$) and applies the following operations:

  $$S\left(⟦\mathcal{T}\left(\mathcal{P}\right)⟧\right)=\prod _{i=1}^{2v}{⟦T_i⟧}^{2^{k\left(2v-i\right)}}$$

  (15)

  $$S\left(\mathcal{A}\right)=S\left(a_1,a_{2,}\cdots a_{2v}\right)=\sum _{i=1}^{2v}{a}_i{2}^{k\left(2v-i\right)}$$

  (16)

  $$S\left(⟦\tilde{\mathcal{T}}\left(\mathcal{P}\right)⟧\right)=E\left(S\left(\mathcal{A}\right)\right)S\left(⟦\mathcal{T}\left(\mathcal{P}\right)⟧\right)$$

  (17)
  The RS first packs $⟦T_1⟧,⟦T_{2,}⟧\cdots ⟦T_{2v}⟧$ and $a_1,a_{2,}\cdots a_{2v}$ in (15), (16) and then adds the encrypted integers to each item of ${\left\{⟦T_i⟧\right\}}_{i=1}^{2v}$ in (17) and obtains $⟦\tilde{\mathcal{T}}\left(\mathcal{P}\right)⟧$, which is the packing ciphertexts after blinding operation. Similarly, for the deadline time of each point $⟦T_V\left(\mathcal{P}\right)⟧={\displaystyle {\left[⟦t_{V_i}⟧\right]}_{i=1}^{2V}}$, the RS generates random integers ${\mathcal{A}}^{\prime }=\left\{a_1^{\prime },a_{2,}^{\prime }\cdots a_{2V}^{\prime }\right\}$ and executes the same blinding operations in (15)–(17).
  Then the RS sends $⟦\tilde{\mathcal{T}}\left(\mathcal{P}\right)⟧$ and $⟦\widetilde{{\mathcal{T}}_V}\left(\mathcal{P}\right)⟧$ to the CS, and they jointly finish the judging for each path. On receiving $⟦\tilde{\mathcal{T}}\left(\mathcal{P}\right)⟧$ and $⟦\widetilde{{\mathcal{T}}_V}\left(\mathcal{P}\right)⟧$, the CS decrypts the ciphertext and unpacks the data. For each path ${\mathcal{P}}_j$, the RS holds $\mathcal{A}$ and ${\mathcal{A}}^{\prime }$; the CS holds $\tilde{\mathcal{T}}\left({\mathcal{P}}_j\right)$ and $\widetilde{{\mathcal{T}}_V}\left({\mathcal{P}}_j\right)$; and they execute the garbled circuit $TC$ as shown in Figure 4, in which the SCMP circuit is shown in Figure 5. CMP, MUX, SUB, and MIN denote a comparator circuit, a multiplexer circuit, a subtractor circuit, and a minimum circuit, respectively. We present the details of the circuit $TC$ in Algorithm 3. The circuit first restores the real values from blind values (1) and then compares the arriving time and the deadline time for each point (2–8). Only if all deadlines are satisfied will the circuit output the total time consumption of the ride-sharing process (9–10), or the circuit outputs a big enough integer ${\left\{1\right\}}^p$ (12).
  Then for all paths ${\mathcal{P}}_j$, the RS and CS jointly execute a path-planning circuit $C_{pp}$ to select the path with minimum traveling time. We present the circuit $C_{pp}$ in Figure 6.

  Algorithm 3 The time-comparing circuit $TC$.

  Input: $\tilde{\mathcal{T}}\left({\mathcal{P}}_1\right)$, $\widetilde{{\mathcal{T}}_V}\left({\mathcal{P}}_1\right)$, $\mathcal{A}$, ${\mathcal{A}}^{\prime }$

  Output: ${\left\{1\right\}}^p$ or $T_{2v}$

  1: Compute $T_i={\tilde{T}}_i-a_i$ and $t_{V_i}=\widetilde{t_{V_i}}-a_i^{\prime }$ 2: for $1⩽i⩽2v$ do 3:      if $T_i<=t_{V-i}$ then 4:          ${\gamma }_i=1$ 5:      else 6:          ${\gamma }_i=0$ 7:      end if 8: end for 9: if $AND\left({\left\{{\gamma }_i\right\}}_i^{2v}\right)=1$ then 10:      return $T_{2v}$ 11: else 12:      return ${\left\{1\right\}}^p$ 13: end if

  Phase 2. (Riders Selection) In this phase, for all rider combinations $\mathbb{C}={\left\{C_j\right\}}_{j=1}^{CN}$, the system compares their $ATT$ and outputs the best combination, in which $CN$ is the total number of combinations, and $ATT$ is the total detouring time of all riders. First, the RS computes the $⟦ATT⟧$ of each combination. For each rider $r_i$, the detouring time is the traveling time difference between the time consumption of driving in the current path and directly to the destination. The $ATT$ of $C_j$ is presented as the following equation:

  $$AT{T}_j=\sum _{i=1}^v\left(T_i^{real}-T_i^{direct}\right)$$

  (18)
  For example, the $ATT$ of the path in Figure 3 can be computed as:

  $$\begin{array}{c}\hfill ATT=\sum _{i=1}^3\left(T_i^{real}-T_i^{direct}\right)=\\ \hfill \left(t_3-t_3\right)+\left(t_5+t_6-t_{r_2.s\to r_2.d}\right)+\\ \hfill \left(t_2+t_3+t_4+t_5-t_{r_3.s\to r_3.d}\right)\end{array}$$

  (19)
  Moreover, we can obtain the corresponding ciphertext as:

  $$⟦AT{T}_j⟧=\prod _{i=1}^v\left(⟦T_i^{real}⟧⟦T_i^{direct}{⟧}^{-1}\right)$$

  (20)
  For each combination $C_j$, the RS computes the $⟦AT{T}_j⟧$, then packs them and obtains $S\left({\left[⟦AT{T}_j⟧\right]}_{j=1}^{CN}\right)$. As with the previous blinding operations, the RS generates $CN$ random integers $\left[a_1,a_2,\cdots a_{CN}\right]$, then computes the blinding ciphertexts $S\left({\left[⟦{\widetilde{ATT}}_j⟧\right]}_{j=1}^{CN}\right)$ and sends it to the CS. After decryption and unpacking operations, the RS and the CS execute the RCS algorithm to select out the best rider combination as Algorithm 4.
  Finally, the RS obtains the result and establishes a secure communication channel between the driver and the riders in combination so that they can communicate for pick-up details.

  Algorithm 4 Rider Combination Selection (RCS).

  Input: RS: ${\left[a_i\right]}_{i=1}^{CN}$; CS: ${\left[\widetilde{AT{T}_j}\right]}_{j=1}^{CN}$

  Output: The combination with minimum $ATT$

  1: $k\ast =-1$ 2: for $1⩽k⩽CN$ do 3:     if $k\ast =-1$ then 4:         $k\ast =k$ 5:     else 6:         if $SCMP\left(\widetilde{AT{T}_k},a_k,\widetilde{AT{T}_{k\ast }},a_{k\ast }\right)==0$ then 7:             $k\ast =k$ 8:         end if 9:     end if 10: end for

5. Privacy and Security Analysis

In this section, we present the analysis of security. Our goal is to ensure no entity could learn the precise location of users, but for the utility and efficiency, we allow the RS to access the zone-based location. We make more discussion about the balance of privacy and utility in the following section. In pShare, we mainly consider the security against the RS and the CS. We adopt and modify the notion of adaptive security from [8,19].

Leakage function $L_{access}$: Given the map of the city $\mathcal{M}$, a set of riders $\mathcal{R}=\left(r_1,\cdots ,r_n\right)$, and a set of drivers $\mathcal{D}=\left(d_1,\cdots d_n\right)$, we define the leakage function ${\mathcal{L}}_{access}=A{P}_{access}\left(\mathcal{M},d,\mathcal{R}\right)$, where $AP\left(\mathcal{M},d,\mathcal{R}\right)$ is the access pattern.

Definition 2

(Access Pattern). Given the map $\mathcal{M}$, a series of drivers $\mathcal{D}$ and a series of riders $\mathcal{R}$, we define the access pattern as $AP\left(\mathcal{M},\mathcal{D},\mathcal{R}\right)=\left(z\left(\mathcal{R}\right),z\left(d\right),{\left\{p{\ast }_x\right\}}_{C_x\in \mathbb{C}},C\ast \right)$, where $z\left(\mathcal{R}\right)$ and $z\left(d\right)$ are the zone information corresponding to $\mathcal{R}$ and d, respectively; $p{\ast }_x$ is the best path of the combination $C_x$; and $C\ast$ is the final selected combination with the minimum $ATT$.

Definition 3

(Adaptive Semantic Security). Let pShare = (RRS, DLU, RFA, PPA, RCS) be our privacy-preserving ride-sharing scheme, representing the process of Ride Request Submit, Driver Location Update, Request Filtering Algorithm, Path-Planning Algorithm, and Rider Combination Selection, respectively. We consider the following experiments with probabilistic polynomial time (PPT) adversary $\mathcal{A}$, a challenger $\mathcal{C}$, a simulator $\mathcal{S}$, and the leakage function ${\mathcal{L}}_{access}$.

${\mathrm{Real}}_{\mathcal{A},\mathcal{C}}\left(1^{\lambda }\right)$: Firstly, $\mathcal{C}$ runs the initialization to set the system parameters. Then $\mathcal{A}$ outputs a set of ride requests $\mathcal{R}$. For each rider $r_i\in \mathcal{R}$, $\mathcal{C}$ and $\mathcal{A}$ execute a simulation of RRS, with $\mathcal{C}$ acting as the rider and $\mathcal{A}$ acting as the RS. Then $\mathcal{A}$ generates a polynomial number of adaptively chosen drivers $\mathcal{D}$. For each driver $d_j\in \mathcal{D}$, $\mathcal{C}$ and $\mathcal{A}$ execute a simulation of DLU, in which $\mathcal{C}$ and $\mathcal{A}$ play the role of the driver and the RS, respectively. Afterward, $\mathcal{A}$ acts the RS and runs RFA, PPA, and RCS, and finally outputs $\gamma$ as the result of the experiments.

$Idea{l}_{\mathcal{A},\mathcal{S}}\left(1^{\lambda }\right)$: Firstly, $\mathcal{S}$ generates system parameters in the process initialization. Then $\mathcal{A}$ outputs a set of riders $\mathcal{R}$ for each rider $r_i\in \mathcal{R}$, and $\mathcal{A}$ executes a simulation of RRS, with $\mathcal{S}$ acting as the rider and $\mathcal{A}$ acting as the RS. Then $\mathcal{A}$ generates a polynomial number of adaptively chosen drivers $\mathcal{D}$. For each driver $d_j$, $\mathcal{S}$ is given the leakage function ${\mathcal{L}}_{access}=A{P}_{access}\left(\mathcal{M},d,\mathcal{R}\right)$ and executes a simulation of DLU with $\mathcal{A}$, in which $\mathcal{C}$ and $\mathcal{A}$ plays the role of the driver and the RS, respectively. Afterward, $\mathcal{A}$ acts as the RS and runs RFA, PPA, and RCS, and outputs ${\gamma }^{\prime }$ as the result of the experiment.

We define the advantage of $\mathcal{A}$ and in the experiment as $Adv\left(\lambda \right)=\left|Pr\left(\gamma ={\gamma }^{\prime }\right)-1/2\right|$. Then we say pShare is adaptively $L_{access}$-semantic secure if for all PPT adversaries $\mathcal{A}$, there exists a PPT simulator s.t. $Adv\left(\lambda \right)$ is negligible.

According to the above definitions, we analyze the user privacy of pShare as follows:

Theorem 1.

If Paillier cryptosystem is semantically secure, pShare has rider privacy in RRS algorithm.

Proof. 

Supposing pShare cannot satisfy user privacy in RRS and there is a PPT adversary who has a non-negligible advantage to distinguish the outputs of the ${\mathrm{Real}}_{\mathcal{A},\mathcal{C}}\left(1^{\lambda }\right)$ from the outputs of the $Idea{l}_{\mathcal{A},\mathcal{S}}\left(1^{\lambda }\right)$. We use $\mathcal{A}$ to break user privacy in RRS algorithm. First, we generate the public key $pk$ and randomly generate two plaintext ride-sharing requests

$$\left(z\left(s_1\right),z\left(d_1\right),t_{s_1\to AP\left(s_1\right)},t_{d_1\to AP\left(d_1\right)},t_{s_1},t_{d_1}\right)$$

and

$$\left(z\left(s_2\right),z\left(d_2\right),t_{s_2\to AP\left(s_2\right)},t_{d_2\to AP\left(d_2\right)},t_{s_2},t_{d_2}\right)$$

in which $z\left(s_1\right)=z\left(s_2\right)$, $z\left(d_1\right)=z\left(d_2\right)$. Then we send the requests to the challenger, and the challenger randomly chooses $b\in \left\{0,1\right\}$ and returns

$$R_b=\left(z\left(s_b\right),z\left(d_b\right),⟦t_{s_b\to AP\left(s_b\right)}⟧,⟦t_{d_b\to AP\left(d_b\right)}⟧,⟦t_{s_b}⟧,⟦t_{d_b}⟧\right)$$

with the RRS algorithm. We send $R_b$ to the adversary $\mathcal{A}$, who gives his guess $b^{\prime }$. So the advantage for $\mathcal{A}$ to distinguish two requests is $Adv\left(\lambda \right)=\left|Pr\left(b=b^{\prime }\right)-1/2\right|$, which is also non-negligible. Based on the non-negligible advantage to distinguish the ciphertext requests encrypted by Paillier cryptosystem, we break the semantic security of Paillier cryptosystem. It is contradictory to the assumption of the theorem. This completes the proof. □

Theorem 2.

If Paillier cryptosystem is semantically secure, pShare has user privacy in the DLU algorithm.

Similar to the proof of Theorem 1, we can prove Theorem 2 that there is no PPT adversary who has a non-negligible advantage to distinguish two outputs of DLU algorithm with drivers from the same zone.

Theorem 3.

If the garbled circuit $C_{pp}$ is secure under the semi-honest adversary model, then the PPA algorithm is secure under the semi-honest model.

Proof. 

During the PPA algorithm, we simulate the view of the RS and the CS, respectively. Let $S_{CS}$ simulate the view of the CS. The RS first blinds the ciphertexts by adding them with a set of randomly generated integers. Then the CS receives the blinded ciphertexts and decrypts them. Since the random integers are big enough, the CS cannot distinguish between two blinded values. That is to say, if $S_{CS}$ randomly picks an integer from the range $\left(2^{k-1}+1,2^k+2^{l+1}-2\right)$, encrypts it, and sends it to the CS, there is no PPT adversary who can distinguish the blinded plaintext from random integer with non-negligible probability. □

Then $C_{pp}$ outputs the path-planning results, which is an m-bits integer that indicates which path to choose. We use $S_{RS}$ to simulate the RS’s view. For each combination, $S_{RS}$ randomly chooses a path that meets Equations (11) and (12) and sends the number of the path as the result of PPA algorithm to the RS. There is no PPT adversary who can distinguish the best path, which is a sequence of encrypted location information, from the randomly chosen one.

The process of circuit execution is also secure. The security proof of $C_{pp}$ can be found in [20]. We complete the proof of the theorem.

Theorem 4.

If the garbled circuit SCMP is secure under the semi-honest adversary model, then the RCS algorithm is secure under the semi-honest model.

Proof. 

Similar to the proof of Theorem 3, from the view of the CS, the adversary $\mathcal{A}$ cannot distinguish the blinded plaintext from the random integer. Then $S_{RS}$ randomly selects a number from all eligible combinations as the result of combination selection. The randomly selected number is also indistinguishable from the real result. □

Theorem 5.

pShare is adaptively semantically secure against semi-honest adversaries.

Proof. 

We first describe a PPT simulator $\mathcal{S}$ to simulate the whole process of pShare such that any PPT adversary $\mathcal{A}$ cannot distinguish the results of ${\mathrm{Real}}_{\mathcal{A},\mathcal{C}}\left(1^{\lambda }\right)$ and $Idea{l}_{\mathcal{A},\mathcal{S}}\left(1^{\lambda }\right)$ with non-negligible advantages. Given ${\mathcal{L}}_{access}=A{P}_{access}\left(\mathcal{M},d,\mathcal{R}\right)$, $\mathcal{S}$ randomly generates a set of drivers $\widehat{\mathcal{D}}$, and for each $\widehat{d}\in \widehat{\mathcal{D}}$, $\mathcal{S}$ randomly generates a set of riders around the driver. Then $\mathcal{S}$ simulates riders to run RRS algorithm and drivers to run DLU algorithm with $\mathcal{A}$ acting as the RS, and then running RFA, PPA, and RCS algorithms. □

According to Theorems 1 and 2, $\mathcal{A}$ cannot distinguish $\widehat{d}\in \widehat{\mathcal{D}}$ from $d\in \mathcal{D}$ and $\widehat{r}\in \widehat{\mathcal{R}}$ from $r\in \mathcal{R}$ during RRS and DLU algorithm execution. Since there is no data transmission in RFA, $\mathcal{A}$ cannot obtain any useful information. According to Theorems 3 and 4, $\mathcal{A}$ still cannot distinguish $\widehat{d}\in \widehat{\mathcal{D}}$ from $d\in \mathcal{D}$ and $\widehat{r}\in \widehat{\mathcal{R}}$ from $r\in \mathcal{R}$ in PPA and RCS algorithms.

In summary, pShare is adaptively ${\mathcal{L}}_{access}$-semantic secure against semi-honest adversaries. We complete the proof.

6. Evaluation

We compare pShare with schemes [7,8,14,19,21] under the same threat model and summarize the differences between them in the

Table 1. Comparison with existing schemes.

Description	pShare	ORide [7]	pRide [8]	PSRide [19]	PrivatePool [14]	PGRide [21]
Ride-sharing	Yes	No	No	Yes	Yes	Yes
Traveling cost	Road traveling time	Euclidean distance	Road traveling time	Road traveling time	Euclidean distance	Euclidean distance
Group matching	Yes	No	No	No	No	Yes
Minimum ATT	Yes	∖	∖	Yes	Yes	No

. Compared to the other privacy-preserving ORH schemes, pShare is able to match the driver with a group of riders and computes for the least-detouring path while protecting users’ privacy. In this section, we design an experiment to show the utility and efficiency of pShare. We present the experimental setup in Section 6.1 and experiment results in Section 6.2.

6.1. Experimental Setup

In this section, we evaluate our experiments on the road network of an about 50 × 50 km map of Beijing, which is generated by OpenStreetMap [22]. Since the distribution of riders and drivers is always dynamic, we generate the ride-sharing requests and driver locations using the tool TaxiQueryGenerator [23], whose outputs conform to Beijing’s real spatio-temporal distribution. We implement Paillier cryptosystem by an open-source library, jpaillier [24], and Yao’s garbled circuits by Faster-GC [25]. During the experiment, we set the modulus of the Paillier cryptosystem to 1024 bits, the bit-length of a blinded value k to 32 bits, the bit-length of a domain value l to 16 bits, and the bit-length of a wire label to 80 bits. All our experiments are run on a PC with 8 GB memory and an Intel-8265U CPU of 1.8 GHz.

We divide the selected area of the map into grids and set up all the parameters of the pShare ride-sharing system. Then we randomly initialize the locations of the drivers and the riders in the selected area, meanwhile generating the corresponding pick-up time and drop-off time of the riders and the available time of the drivers. Then the pick-up deadline and drop-off deadline are computed as $t_s=t_{cur}+600$ s, $t_d=t_s+t_{s\to d}+600$ s.

The default patience time of a rider is 30 min, i.e., the rider will turn to other options for traveling rather than ride-sharing beyond this amount of time. We choose the generated requesting datasets of period 10:00–11:00 and the drivers’ datasets of period 10:30–11:00 as the experimental datasets. We first read all rider requesting data, and for each record of driver datasets, we read it sequentially and apply the ride-sharing matching between the driver and riders within the patience time. The result of the ride-sharing matching may be a failure or success. To evaluate the accuracy of pShare, we record the matched riders if matching successfully and compare the results to another experiment pShare-GT, which takes ground truth to replace the estimated traveling time. Besides, we also measure the overhead of the experiments and record it in the table.

6.2. Experiment Results

Accuracy: In the experiments, we use two metrics to evaluate the accuracy of the system, which are Successful Matching Rate (SMR) and Accurate Matching Rate (AMR), respectively. We compute SMR as $SMR=N_{suc}/N_{tot}$, in which $N_{suc}$ indicates the number of successful matching and $N_{tot}$ indicates the total number of matching. We compute AMR as $AMR=N_{acc}/N_{tot}$; $N_{acc}$ indicates the number of matches where the results of pShare are the same as the results of pShare-GT. We use the metric AMR to evaluate the accuracy of the scheme to find the minimum detouring route. Since there is a trade-off between the matching accuracy and the user privacy, we introduce the Average Number of POI ($ANP$) in one zone to represent the privacy level of current zone size, in which POI is point of interest, corresponding to the location points of the riders’ probable destinations. Therefore, the users’ precise locations are disclosed in the probability of $1/ANP$. We compute and compare the variants of SMR, AMR, and ANP by varying the zone scale and the number of riders to be searched ${\mathcal{R}}_{nearby}$. As shown in Figure 7, SMR has little association with the zone size, but AMR increases remarkably with zone getting smaller, which indicates the accuracy of the zone-based time estimation method is highly relevant to the zone scale. Besides, there is a drastic reduction in APN with smaller zone size, so it is necessary to properly set the zone scale considering protecting users’ privacy at an acceptable level. Furthermore, the rider number to be searched has an influence on SMR but has no evident impact on AMR/SMR.

Efficiency: We take communication and computation cost to evaluate the efficiency of pShare scheme. During the ride-sharing, the computation cost mainly includes the encryption of riders and drivers in the process of Request Submit and Location Submit, the packing/unpacking operations and the garbled circuit execution in the process of ride-sharing matching.

As shown in

Table 2. System overhead for per ride-sharing matching under different sizes of ${\mathcal{R}}_{nearby}$.

Size of (${\mathcal{R}}_{\mathcal{nearby}}$)	pShare Scheme
	Rider		Driver		Server
	Comm. (KBs)	Comp. (ms)	Comm. (KBs)	Comp. (ms)	Comm. (MBs)	Comp. (s)
25	0.51	26	0.13 + 0.52 * $OB{R}_d$	11	0.48	3.2
50	0.51	26	0.13 + 0.52 * $OB{R}_d$	11	1.64	10.1
75	0.51	26	0.13 + 0.52 * $OB{R}_d$	11	3.66	15.8
100	0.51	26	0.13 + 0.52 * $OB{R}_d$	11	6.25	23.3
125	0.51	26	0.13 + 0.52 * $OB{R}_d$	11	10.76	30.3
150	0.51	26	0.13 + 0.52 * $OB{R}_d$	11	18.48	39.4

, for the rider, the communication cost is always 0.51 KB, and the computation cost is 26 ms. For a driver with no onboard rider, the communication cost is 0.13 KB. For a driver with onboard riders, the submitted information should also contain the requests of riders onboard. As for the server (includes both the ride-sharing server and the crypto server), the communication cost and the computation cost are subject to the size of searched riders. The communication cost of the server is mainly from the packed ciphertexts the RS sends to the CS, and the computation cost mainly contains the cost of ciphertexts packing and computation of the RS, the ciphertexts unpacking of the CS, and the execution time of the garbled circuit. From the table, we can see that the total execution time of the server is about 30 s if the number of riders to be searched is 100. The responding time is acceptable for users with an appropriate searching scale. Moreover, we especially evaluate the computation cost of the garbled circuit with different searched riders and the number of available seats. From Figure 8, we can find the execution time of the garbled circuit takes up most of the total computation cost, and the cost rises faster as the size of ${\mathcal{R}}_{nearby}$ and v become bigger.

7. Related Work

7.1. Privacy-Preserving Ride-Matching

Many approaches have been proposed to preserve users’ privacy in location-based services. For the cryptographic primitives, there is homomorphic encryption, secure multi-party computation, and private set intersection. Besides, some non-encrypted techniques include location perturbation [26], dummy location generation [27], and spatial cloaking [28]. Based on these methods, a few privacy-preserving ride-matching schemes have been proposed. A privacy-enhanced scheme, PrivateRide [6], was proposed by Pham et al., which provides anonymity for users’ locations. Later, they extended it to ORide [7], which is based on somewhat homomorphic encryption and enables the matching more efficiently while protecting users’ privacy. Besides, Luo et al. proposed a privacy-preserving ride-matching scheme based on road networks [8], which can perform matching more accurately. Considering side-channel attacks, they also presented a private and efficient scheme with Intel SGX enclave, which provides a hardware-enforced Trusted Execution Environment [29]. However, all these schemes are ride-matching schemes, which do not support ride-sharing matching.

7.2. Privacy-Preserving Ride-Sharing

There are also some relevant schemes for ride-sharing. SRide is a privacy-preserving dynamic ride-sharing system, which computes the ride-sharing results based on users’ spatiotemporal data. PRIS [13] utilizes PHE [15] to find eligible matching between riders and drivers. Sherif et al. proposed a scheme [30] that computes the similarity of riders’ trips on ciphertexts to match riders. The FICA scheme [31] ensures data privacy and reliability using edge computation and blockchain techniques. PrivatePool [14] constructs a distributed and privacy-enhanced ride-sharing system with PSI [32] protocol and SHE [33] technique. PSRide [19] utilizes PHE [15] and the Garbled Circuit technique to build a privacy-preserving scheme that supports flexible ride-sharing matching. Yu et al. proposed PGRide [21], in which they designed an encrypted aggregate distance computation approach by using SHE and ciphertexts packing technique. Through the approach, the aggregate distances can be computed in encrypted form. Howerver, none of these schemes can support group matching and meanwhile find minimum detouring matching results over road traveling time.

8. Conclusions

In this paper, we propose a privacy-preserving ride-sharing scheme pShare for ORH service. pShare supports privacy-preserving ride-sharing between multiple riders, the matching results of which have a minimum ATT. To achieve this, the riders and drivers need to submit their encrypted location information to the ORH server, and the ORH server applies secure computing and compares matching protocols with the crypto server based on the garbled circuit and the data packing technique. They first compute the minimum path for each eligible rider combination, and finally, they compare and select the best combination with minimum ATT. We prove that pShare scheme achieves user privacy and is adaptively semantically secure under the random oracle model. The experimental results have shown that pShare achieves both accuracy and practical efficiency.