1 Introduction
Ride sharing, also known as carpooling, is a service that enables multiple persons who have similar trips at the same time to travel together in one vehicle instead of using multiple vehicles. It can reduce air pollution and traffic congestion by reducing the number of vehicles traveling on the roads. In addition, it can reduce the trip cost by splitting the cost among several persons. Recently, the popularity of ride sharing has significantly increased, providing services to passengers at various locations [1, 2, 3]. As of 2010, there were at least 613 ride sharing platforms in North America mostly based on the internet [4, 5, 6]. Furthermore, government policies have also been made in many countries to encourage citizens to share rides. Making High Occupancy Vehicle (HOV) lanes are one of such strategies. It allows to vehicles with more than two persons onboard to use a privileged lane [7, 8, 9]. Another strategy to motivate sharing rides is providing toll discounts and reimbursements [10].
By means of smart phones, GPS systems, and Internet connectivity, the process of organizing shared rides is greatly facilitated. The idea is that users are required to register with an online platform that organizes shared rides, and then a user having a vehicle (driver) and seeking to share ride with other users (riders) sends a ride sharing offer to a Trip Organizing Server (TOS). This offer should include the trip data, such as the starting location, destination, trip time and route. Also, riders looking for shared rides should first send ride sharing requests with similar information to the TOS. The TOS then matches the drivers’ offers with riders’ requests to assign one or multiple riders to each driver. Nevertheless, the TOS is run and operated by private company that may be interested to collect information about the users’ locations and activities.
Different privacypreserving ride sharing schemes are proposed in the literature [11, 12, 13, 14, 15, 16, 17]. However, existing schemes lack or do not consider the following issues. First, some schemes [16] and [17] are not efficient when applied to large geographic maps, which restrains them to small ride sharing area, this because each users needs to report an encryption that encompasses all the city subregions to report his/her location. Second, the schemes [11, 12, 13, 14, 15, 16, 17] are not flexible in the way that they do not allow the riders to prescribe their ride sharing preferences such as the trip length, if they are willing to transfer between different drivers to reach their destination (transferable ride), the maximum number of transfers, etc. Finally, existing schemes [11, 12, 13, 14, 15, 16, 17] can not be used to organize transferable rides. As will be demonstrated in the performance analysis, transferable rides can increase the number of served riders, and thus increase each vehicle occupancy, enhance the ride sharing utilization, reduce traffic congestion, and reduce air pollution. Compared to the existing schemes, efficiency, flexibility, and transferable rides were taken into consideration in our schemes by allowing the rider to select his pickup, dropoff, and his preferences, while the TOS can fulfill the rider request efficiently. Although the focus of our schemes is on organizing shared rides (carpooling), the proposed schemes can also be adapted to work with ridehailing services [18] and [19], such as Uber and Lyft. This can be achieved in the proposed schemes by only reporting the rider pickup location.
In this paper, we aim to address the aforementioned issues by proposing two schemes for the organization of shared rides, namely, non transferable ride sharing service (NRS) and transferable ride sharing service (TRS). Both schemes enable the TOS to organize shared rides without knowing any private information about the users’ locations and activities. In the NRS scheme, a rider can share a ride with only one driver, while in TRS, the rider needs to take multiple vehicles to reach his destination. In latter case, the rider has to switch between multiple drivers during his trip. The users can select the type of service they need, e.g., NRS is more preferable to elderly and disabled people. They can also limit the trip length and the number of transfers of the trip that is returned by the TOS. In both schemes, the ride sharing area is divided into cells (geographic areas) and each cell is assigned a unique identifier. To the best of our knowledge, this is the first work that address the privacy preserving two cases of ride sharing organization, NRS and TRS.
For NRS organization, riders and drivers should submit to the TOS encrypted binary vectors representing their trip information. Then, the TOS uses our modified kNN encryption
[20, 21, 22] to perform similarity measurement on the encrypted trip vectors to organize shared rides without learning any sensitive location information to preserve users’ privacy. A Bloom filter [23] is used to compactly store the trip data to reduce the communication overhead and create the binary vector needed for the kNN similarity measurement. On the other hand, in TRS, drivers should report the encryption of the individual cells on their routes. Then, the TOS builds a directed graph for all the drivers individual cells using the measured similarity between the encrypted individual cells. After that, a modified Dijkstra’s searching algorithm [24] is used to search through this graph to determine the route that can achieve the rider’s preferences, constrains, and requirements. For example, a rider can request a minimum number of cells ride sharing which means the shortest path between his location and his destination despite the number of transfers required. In another case, a rider can request the minimum number of transfers ride sharing which could be preferred especially by elderly and disabled people.Our formal proof demonstrates that the proposed schemes can organize shared rides without disclosing private information. In addition, both schemes were implemented with MATLAB using real map and routes. The experimental results demonstrate that the communication and storage overheads are acceptable, and our schemes are scalable and can be used in cases of small and large cities. Although TRS can be used to organize both transferable and nontransferable, The NRS provides better efficiency in terms of the communication overhead for nontransferable services.
The remainder of this paper is organized as follows. The network and threat models are introduced in sec:system_model. Preliminaries and design goals are given in sec:prel. The proposed schemes are presented in sec:ProposedScheme. Security and Privacy analysis are discussed in sec:privacy_analysis. performance evaluations are given in sec:performance. The related works are presented in sec:related Work. Finally, conclusions are drawn in sec:conclusion.
2 Network and Threat Models
2.1 Network Model
As shown in Figure 2, the considered network model consists of an offline Trusted Authority (TA), drivers, riders and a TOS. The TA is responsible for generating and distributing unique secret keys to each driver, rider and the TOS. Drivers and riders can use a smartphone application to send their encrypted trip information to the TOS through the internet. The TOS should execute one of the proposed schemes based on the drivers ’and riders’ preferences and send the results back to the drivers and riders. Figure 1 shows the ride sharing area considered in our simulation. As shown is the figure, the ride sharing area is divided into cells and each cell has a unique identification number (ID). To achieve forward and backward privacy as discussed in section 5, we propose permuting the distribution of the cells identifiers in the city every day, so that the TOS cannot link old trips’ information to the new one. The basic structure of the pseudorandom generation + can be used [25], where and are shared secrets between the users, is the cell identifier, and is the number of cells in the city. All the users can compute shared secrets and by hashing two shared seeds with the current date.
2.2 Threat Model
We consider that the drivers, the riders, and the TOS are "honestbutcurious", i.e., they follow the proposed schemes and do not aim to disrupt their operation, however, they are curious to learn location information about any user in the system such as the trip’s pickup/dropoff locations and times. The attackers are also interested in knowing the identities of users who share rides with each other. In addition, we assume that the attackers can be internal or external. The TOS and legitimate users can be internal attacker. The external attacker can eavesdrop on all the communications in the system and match eavesdropped offers and requests to learn sensitive information on the users’ locations and identities.
3 Preliminaries and Design Goals
3.1 Bloom Filter
Bloom filter is a spaceefficient probabilistic data structure that can reduce the overhead of storing and searching a set of elements [23]. The Bloom filter algorithm takes items and uses different hash functions to compute a bit vector of length bits that stores the items. The hash functions are defined as , where and . Initially, all the Bloom filter bits are set to zero. To add an element to the filter, is hashed using the hash functions and the bit locations resulted from each hash function is set to one. Figure 3 shows an example to a bit Bloom filter using three hash functions.
Assume a set of elements stored in the Bloom filter. To check whether a given element belongs to , a Bloom filter query algorithm computes the hash values of to get locations in the vector. If any of the bits of these location is zero,
is definitely not in the set, but if all the bits are ones, then there is a high probability that
is in the set. It is possible that an element does not belong to the Bloom filter and the corresponding bit locations are set to ones by other elements in the Bloom filter which is called false positive. The falsepositive probability of a Bloom filter can be computed by [23]. Given the number of different hash functions and the number of elements , the size of the Bloom filter such that the false positive probability is very small and can be determined.3.2 Design Goals
Our goal is to develop two privacypreserving ride sharing organization schemes for NRS and TRS with the following objectives.

TRS and NRS: As mentioned earlier, the TRS and NRS are both needed to the users, and thus, the proposed schemes should be able to organize the two services efficiently.

Efficiency and scalability. The schemes should be efficient in case of a large ride sharing region (i.e. big cities) and serve a large number of ride sharing requests.

User requirements and preferences. Users should be able to select the type of service (NRS or TRS) and their search preference such as trip length, maximum number of transfers, etc.

Trip data privacy. The TOS should be able to organize shared rides without knowing the pickup/dropoff locations and times or even any road segment in users trips. Eavesdroppers and malicious users should not be able to learn any sensitive information about other users’ trip data.

Forward and backward privacy: To prevent the TOS from inferring incremental side information over time, the TOS should not be able to match the encrypted trip information sent in one day to the information that sent earlier or will be sent in the future.

Data Linkability: (1) Requestsuser unlinkability: Given different ride sharing requests sent from a user, the TOS should not learn if these requests are sent from the same user or not; (2) Driverrider pair unlinkability: If a driverrider pair shares a ride, the TOS should not identify the same pair when they share rides in the future; (3) Same requests unlinkability: The TOS should not link the ride sharing requests (or offers) of the same trip at different times.

Users’ anonimity: The TOS must ensure that the received requests/offers are coming from legitimate users. However, it should not be able to reveal the real identity of the users from the credentials they use for authentication or the locations they visit.
Notation  Description 


TA Master Secret Matrices for NRS scheme 

TA Master Secret Matrices for TRS scheme 

Splitting Vector for NRS and TRS 

TOS secrets for NRS 

TOS secrets for TRS 

Driver Secret key in NRS 

Rider Secret key in NRS 

Driver Secret key in TRS 

Rider Secret key in TRS 

Number of bits needed for the Bloom filter 

Number of bits needed to represent an NRS cell 

Number of bits needed to represent time 

Number of bits needed for an NRS vector 

Pickup cell, dropoff cell, route, time 

Driver D: pickup, dropoff, route and time indices 

Rider R: pickup, dropoff, route and time indices 
4 Proposed Scheme
This section presents the details of the proposed schemes. For better readability, the main notations used throughout this section are given in Table I
4.1 System Bootstrap
The TA chooses two sets of keys as master secret keys, for NRS and for TRS, where and . and are binary vectors used as splitting indicators during the encryption process, as will be explained later in this section. The size of is , where is the size of the binary vector to be encrypted in NRS scheme. All other elements in the set are invertible matrices. Similarly, the size of is , where is the size of the binary vector to be encrypted in TRS scheme and all other elements in the set, , are invertible matrices of random secret numbers.
Then, the TA generates the TOS secret keys. The keys consist of four random matrices , and . The two matrices and are to be used in NRS while and are to be used in TRS. Note that, and are of size , while and are of size .
Each user in the system can play the role of a driver or a rider. Also, each user can offer/request nontransferable or transferable service. Using the master secret sets and the TOS secrets, the TA computes unique secret keys for each user in the system as follows.

[leftmargin=5mm]

Driver in NRS Secret Key:
where , , and are random and invertible matrices of size , such that , and . Note that, key set has eight elements where each element is a matrix of size .

Rider in NRS Secret Key:
where , and are random and invertible matrices of size , such that , and . Note that, key set has eight elements where each element is a matrix of size .

Driver in TRS Secret Key:
where , and are random and invertible matrices of size , such that , and . Note that, key set has eight elements where each element is a matrix of size .

Rider in TRS mode Secret Key:
where , and are random and invertible matrices of size , such that , and . Note that, key set has eight elements where each element is a matrix of size .
In addition to the four key sets, each user receives from the TA a set of certified pseudonymous that are used for authentication with the TOS. In addition, each user should receive the two vectors and .
4.2 Nontransferable ride sharing organization
4.2.1 Overview
The proposed privacypreserving NRS scheme uses a modified version of the kNN encryption scheme [26] and Bloom filters. In the proposed scheme, each driver creates an encrypted ride sharing offer, and each rider creates an encrypted ride sharing request. The TOS receives these offers and requests and computes their similarity to organize nontransferable shared rides without revealing any location information. Finally, the TOS notifies the drivers and riders that can share rides.
4.2.2 RideSharing Cases
Three different ride sharing cases are considered for the NRS scheme as shown in Figure 4. In all cases, the driver chooses a pickup area around his trip’s start location where he can pickup riders. If the rider’s start location lies outside the driver’s pickup area, then ride sharing is impossible. For the dropoff area, there are three possibilities, as follows.

[leftmargin=5mm]

Matched Pickup and Matched Dropoff (MP/MD). As shown in Figure 4(a), the destination of the rider lies within the dropoff area defined by the driver.

Matched Pickup and onRoute Dropoff (MP/RD). As shown in Figure 4(b), the destination of the rider lies on the driver’s route. Therefore, the driver drops the rider off at his destination and then continues his trip.

Matched Pickup and Extended Dropoff (MP/ED). As shown in Figure 4(c), the destination of the driver lies on the rider’s route. Therefore, the AV first drops the driver off, then it delivers the rider to his destination, and finally, it drives itself back to the driver’s location. This case is possible only in case of autonomous vehicles AVs.
Note that, these ride sharing cases considered in subsubsection 4.2.2 where the riders and drivers have the same pickup area can be easily extended so that the driver can pickup riders at any point on his route.
4.2.3 Driver’s Offer
Each driver should represent his pickup area, dropoff area, and his route by a list of cell IDs. For example, the figure shows a user’s route that can be represented as .
The driver creates a ride sharing offer that has four encrypted vectors referred to as indices. These indices contain driver’s trip data including pickup area index , dropoff area index , trip route index , and pickup time index .
Figure 5 shows the process of computing the trip route index by the driver. First, the route cells are passed to a Bloom filter building algorithm to generate a binary column vector of size . Note that, The algorithm is modified to guarantee that the hash values results by each hash function are distinct. For example, if , a counter is concatenated to such that , where is the first number that can make the two hash values different [23]. Then, the driver uses the key set , defined in subsection 4.1, to encrypt using modified kNN encryption scheme [26]. For encryption, the driver uses to split into two random column vectors and of the same size as . The splitting is done as follows. If the bit of is zero, then, and are set similar to , while if it is one, and are set to two random numbers such that their summation is equal to . After splitting , the encrypted index can be computed using the secret key and the vectors as follows
(1) 
where is a column vector of size elements, and each element is a column vector of size . Note that, every time the same vector is encrypted, the ciphertext looks different due to the random numbers used in creating and .
Using the same process, the pickup and dropoff indices, and , can be computed by passing the pickup cells and dropoff cells to the Bloom filter algorithm, and encrypting the Bloom filter vector. To generate the time index , we use a binary vector where each bit represents onetime slot in the day such that all the bit values are zeros except the bit corresponding to the trip start time. Then, this binary vector is encrypted in the same manner to obtain .
Along with the indices, the driver should send to the TOS the maximum number of riders with whom he can share rides. Also, the driver should encrypt his contact information and send it to the TOS along with his anonymous credentials and signature.
Moreover, the driver can select some of the preferred ride sharing cases. For example, he might prefer only MP/RD case so that riders can not know his final destination, or he might prefer only MP/MD case so that he never stops during the trip, or he can select more than one ride sharing case.
4.2.4 Rider’s Request
Each rider should generate a ride sharing request that has the pickup location index , dropoff location index , trip route index , and pickup time index . More specifically, to compute , the rider’s pickup location is passed to the Bloom filter building algorithm to generate a binary row vector . Since the rider’s pickup location is one cell, his Bloom filter contains exactly bits set to 1. Then, is used to split into two random row vectors and of the same size as . The splitting process of the rider data is opposite to that of the drivers. If the bit of is one, then, and are set similar to , while if it is zero, and are set to two random numbers such that their summation is equal to . Then, the rider can compute the encrypted index using the key set and the vectors and as follows
(2) 
where is a row vector size , and each element is a row vector of size . Using a similar process, the rider can generate , , and . Also, the rider should encrypt his contact information and send it to the TOS along with his anonymous credentials and signature.
4.2.5 Organizing Shared Rides
First, the TOS must ensure that the received offers and requests are coming from a legitimate user in the system. This can be achieved by verifying the received credentials associated with each offer/request. In addition, the TOS multiplies elements in all the received offer indices by and elements in all the received requests by to remove its secrets and from the offers and requests respectively. Thus, only the TOS can match drivers’ and riders’ indices because its secrets and are needed to match the indices.
After that, the TOS starts to organize the shared rides as follows. Based on the ride sharing cases presented in subsubsection 4.2.2, the driver’s offer and the rider’s request should match at the trip starting time and pickup location. Therefore, the TOS first measures the similarity between the time indices by computing a dot product operation between and . Since only one bit is set to 1 in the unencrypted time vectors, the dot product result is 1 if and only if the driver and the rider start their trips within the same time slot (See equation (4.2.5)). In this case, the TOS measures the similarity between the driver pickup area index and the rider pickup location. More specifically, based on equations 1 and 2, the result can be computed as follows.
(3)  
Since the rider’s pickup location index represents only one cell, his Bloom filter contains exactly bits set to 1, this bits corresponds to the locations pointed by the hash functions used by the Bloom filter. Therefore, if the measured similarity between and is exactly , then, the rider pickup location lies within the driver pickup area. On the other hand, if the measured similarity is less than , then the rider pickup location lies outside the driver pickup area and ride sharing is not possible between this driver and that rider. For the drivers’ offers and riders’ requests which are matched in trip start time and trip pickup locations, the TOS proceeds with the search process to find which ride sharing case can be organized.
Consider that the driver requests to share rides with riders with preferences sorted as follows: MP/MD, MP/RD, and MP/ED. Therefore, whenever the TOS finds requests that match the driver’s offer, it connects the matched driver and riders.

Organizing MP/MD shared ride. As shown in Figure 4(a), the TOS measures the similarity of the rider’s dropoff index and the driver’s dropoff index . If the result is , then an MP/MD ride sharing is possible, otherwise, the TOS checks the next ride sharing case.

Organizing MP/RD shared ride. As shown in Figure 4(b), the TOS measures the similarity of the rider’s dropoff index and the driver’s route index . If the result is , then an MP/RD ride sharing is possible, otherwise, the TOS checks the next ride sharing case.

Organizing MP/ED shared ride. As shown in Figure 4(b), the TOS measures the similarity of the driver’s dropoff index and the rider’s route index . If the result is , then an MP/ED ride sharing is possible, otherwise, it is not possible to organize a shared ride between this driver and that rider.
After TOS finds riders who can share ride with the driver, it should forward the encrypted contact information of the driver to the rider and vice versa.
4.3 Transferable ride sharing organization
4.3.1 Overview
The proposed privacypreserving TRS scheme uses a modified version of the kNN encryption scheme [26] and a modified version of Dijkstra shortest path algorithm. Figure 7 shows flowchart of the TRS scheme. First, each driver creates an encrypted ride sharing offer that includes the individual cells on his trip and sends the offer to the TOS. The TOS should first use the drivers’ trips’ data to build a directed graph required for organizing shared rides. Each rider creates an encrypted ride sharing request that includes the source and the destination of his route. In addition, the TOS determines the weights of the directed graph by using the ride sharing preferences sent by the rider. The TOS uses the riders’ requests to search the directed graph to find the path that can satisfy the drivers’ requirements. Finally, TOS sends back the results to the drivers and riders. In addition, TOS should make any necessary updates to the directed graph, e.g., if a vehicle reaches its maximum capacity, its nodes should be removed from the graph. The graph update step does not need much computations and does not require building the whole graph again.
4.3.2 Data Representation
As in NRS scheme, in TRS, the ride sharing area is divided into geographic regions, called cells each having a unique identifier as illustrated in Figure 1. Unlike NRS, each cell in the driver’s route is represented individually by a binary vector that has the location and time components as shown in Figure 6. The location is represented by the cell identifier while the time component is the expected time the user will be in the cell. We define as the number of bits that are needed to represent the cells of the whole ride sharing area in a binary format. For the location component, bits are used to represent the location cell identifier in binary and its complement. The complement value is used so that the number of common ones between any two spatially matched cell vectors is .
For the time component, bits are used to represent the whole day ( i.e., 24 hours), where each bit represents a specific time interval. Each user should set the bit corresponding to the time interval in which he/she will be in the cell. Hence, any two spatially and temporally matched cell vectors should give common ones.
4.3.3 Driver’s Offer
For each cell in a driver’s route, the driver creates a binary vector of length and encrypts it to get an index vector for each cell in his trip’s route. For each cell, the driver generates two indices ( and ). The first index is encrypted using and is used to enable riders’ requests to be matched with the driver cell data while the second index is encrypted using and is used to enable the TOS to match all the drivers’ trip data to generate a directed graph required for searching operations. For generating , the driver uses the binary vector to split each binary cell’s vector denoted as into two vectors and of the same size. If the bit of is zero, then, and are set similar to , while if it is one, and are set to two random numbers such that their summation is equal to . After splitting , the driver uses and the key set to compute the index as follows.
(4) 
where is a column vector of size , and each element is a column vector of size . For generating , the binary vector is used to split into two vectors and of the same size. Note that, for the same cell and are the same. Then, is used to split into two random binary row vectors and of the same size as . The splitting process of is opposite to that of . If the bit of is one, then, and are set similar to , while if it is zero, and are set to two random numbers such that their summation is equal to . Then, the driver can compute the encrypted index using the key set and the vectors and as follows
(5) 
where is a row vector of size elements, and each element is a row vector of size . Each driver should encrypt and send the indices of the individual cells of his route to the TOS. Other information such as the number of riders who can share the trip with, and his contact information should also be encrypted and sent to the TOS along with the his anonymous credentials and signature.
4.3.4 Building A Directed Graph
After TOS receives the cell indices of drivers’ routes, it constructs a graph that contains all the cells from all the drivers without knowing the exact spatial locations of the cells to preserve privacy.
Given driver route, where cell on his/her route is denoted as , the TOS builds the directed graph by measuring the similarity of cells indices from all drivers. To do this, two types of graph edges are used namely:

Route Edges. These edges are unidirectional and connects different cells that belong to the same driver.

Transfer Edges. These edges are bidirectional and connects the matched cells of different drivers.
The TOS adds a route edge between any two consecutive cells and of driver . As shown in Figure 8(a), there are two drivers each having five nodes in his route and the route edges are added between the same driver cells. After adding route edges, TOS measures the similarity of every pair of cells for every pair of drivers in order to add transfer edges to the graph. Figure 8(b) shows that TOS measures the similarity of driver one cell three and all the indices of driver two. This is feasible because each driver sends two indices for each cell on his route, cell three indices are (). If any of the matching result is exactly equal to , it means that both drivers have been spatially and temporally matched, i.e. they will be in the same cell at the same time. In that case, TOS adds a bidirectional edge (transfer edge) between the two nodes. As shown in Figure 8(c), TOS finishes adding all the transfer edges to connect the two routes. After connecting the two routes, a new route can be added to Figure 8(c) graph using the same technique and the full graph is completed after connecting the routes from all drivers. Note that, even if a graph is constructed and a driver sent a route, it is easy to add this route to the constructed graph.
As an example for similarity matching, consider the TOS measures the similarity of an arbitrary cell encrypted using and has an index and another cell encrypted using and has an index . More specifically, based on Equations 4 and 5, the similarity measurement can be computed as follows
(6)  
4.3.5 Organization of Shared Rides
1 Rider’s data. For the rider, his trip data contains only two cells; one
cell for pickup and another cell for dropoff . Using the key set , the rider can compute two indices and and send them to the TOS.
Also, the rider should encrypt his contact information and sends it to the TOS along with his anonymous credentials and signature.
2 Graph Weights Based on Rider’s Preferences. Since riders have different requirements and needs, our scheme
allows them to prescribe their preferences in the shared rides. The riders’ preferences are used by the TOS to determine the graph’s weights so that the optimal search result is returned to the rider. The number of cells traveled by the rider and the number of transfers done by the rider are used to prescribe the rider’s preferences. Riders’ preferences are given as follows.

Minimum number of cells (). In this preference, rider can require the minimum distance to reach his destination (i.e. the number of cells). TOS should return the path to the destination that has the fewest number of cells. If TOS finds different paths that can satisfy , it returns the path that has the least number of transfers among these paths.

Maximum number of cells (). In this preference, rider requires TOS to return the path that has the number of cells less than a set threshold value. If TOS finds different paths that can satisfy , it returns the path that has the least number of transfers among these paths.

Minimum number of transfers (). In this preference, rider specifies the minimum number of transfers. This preference satisfies the requirements of the elder people or the people with disability as they can request for a route with without considering the number of cells. If TOS finds different paths that can satisfy , it returns the path that has the least number of cells.

Maximum number of transfers (). In this preference, the rider requires TOS to return only the route that satisfies a specific threshold for the number of transfers. If TOS finds multiple routes that can satisfy
Comments
There are no comments yet.