Abstract
Ride-hailing service solves the issue of taking a taxi difficultly in rush hours. It is changing the way people travel and has had a rapid development in recent years. Since the service is offered over the Internet, there is a great deal of uncertainty about security and privacy. Focusing on the issue, we changed payment pattern of existing systems and designed a privacy protection ride-hailing scheme. E-cash was generated by a new partially blind signature protocol that achieves e-cash unforgeability and passenger privacy. Particularly, in the face of a service platform and a payment platform, a passenger is still anonymous. Additionally, a lightweight hash chain was constructed to keep e-cash divisible and reusable, which increases practicability of transaction systems. The analysis shows that the scheme has small communication and computation costs, and it can be effectively applied in the ride-hailing service with privacy protection.
1. Introduction
In recent years, more and more consumers use ride-hailing services with the rapid development of online transportation companies such as DiDi and Uber. Compared with a traditional taxi service, a ride-hailing service has the characteristics of convenience and efficiency. Nowadays, it plays an important role in people’s life [1]. On the other hand, since online service platform is easy to collect sensitive information such as user identities and trip paths, privacy disclosure issues are becoming serious with the expansion of ride-hailing services.
Current research on transportation privacy mainly focuses on public transportation. Radio frequency identification (RFID), as noncontact automatic identification technology, is widely used in transportation. Heydt-Benjamin et al. [2] suggested an encrypted RFID payment scheme. Arfaoui et al. [3] used near field communication technology to design an electronic traffic ticket scheme with privacy protection. Isern-Deya et al. [4] designed an anonymous automatic ticket checking system. Based on zero knowledge proof, a toll scheme is proposed to prevent a driver from cheating [5]. Troncoso et al. [6] designed a secure system to collect vehicle insurance fees, which relies on the security of vehicle equipment. Because pick-up points and drop-off points are relatively fixed in public transportation, a passenger is not easy to be distinguished from other passengers if their pick-up or drop-off points are the same.
Compared with public transportation, the privacy issues involved in online transportation services are different, and the related research is little. Friginal et al. [7] proposed a distributed solution using social networks and the solution requires users to conduct peer to peer communications. Pham et al. [8] presented a privacy-enhanced scheme. In the scheme, a driver and a passenger establish a secure channel to exchange messages with the help of online service platform; for a passenger, the platform cannot associate his identity with his location; but the paper did not provide specific communication details.
As for the security of mobile payment in general application scenarios, some methods have been provided [9]: password, symmetric and asymmetric cryptography, and certificateless digital signature. Abughazalah et al. [10] presented a mobile payment scheme based on one-time passwords and tamper-resistant keys. Qin et al. [11] provided a novel approach to secure a mobile wallet by incorporating digital signature and pseudoidentity techniques. But the payment platform in the schemes [10, 11] knows the relationship between the pseudonym and the real identity of a user. If he wants, he can track all the transactions.
In order to solve the above issues, based on anonymous e-cash, we designed an authenticated hash chain and further proposed a privacy protection scheme for the ride-hailing service. The main features are as follows: Payment pattern is transformed from third-party transfer payment to e-cash payment. E-cash is unforgeable and partially blinded, which makes payment secure and anonymous. A lightweight trusted hash chain is constructed to keep e-cash divisible and reusable, which enhances convenience and practicability of a payment system. The main process is similar to prevailing systems. Therefore, our scheme can be deployed on the existing platforms.
The remainder of this paper is organized as follows. Firstly, we introduce security requirements including security requirements and transaction framework in Section 2 and cryptographic preliminaries in Section 3. We describe the proposed scheme in detail in Section 4. We then analyze the security and performance in Sections 5 and 6, respectively. Finally, we conclude the paper in Section 7.
2. System Model
2.1. Security Requirements
There are some security threats to ride-hailing services. In order to get illegal profits, the service platform may infer private information from request messages and further track passengers. External attackers may eavesdrop on the communication channel or impersonate legal users. To resist the attacks, the security requirements are as follows:(i)Antieavesdropping: for external attackers, it is computationally infeasible to obtain privacy information of passengers(ii)Anonymity: it is computationally infeasible to infer the identity of a user from his service request(iii)Authenticity: it is computationally infeasible to impersonate others to apply for e-cash, make a payment, or deposit e-cash(iv)Unforgeability: for a passenger, a service platform, and a malicious user, it is computationally infeasible to forge e-cash(v)Nonlinkability: it is computationally infeasible to infer the relationship between trip trajectory and user identity from request messages(vi)Accountability: a service platform can revoke the anonymity of illegal passengers under certain conditions
Considering the practical environments, we assume that the platform is honest and curious, and the platform expects to obtain user privacy. From the perspective of the development of enterprise, the platform will not initiate active attacks. On the other hand, the driver has to share his location to pick up passengers, so he is not anonymous.
2.2. Transaction Framework
A ride-hailing system at least includes the following entities:1. Passenger : a passenger has a smartphone with Internet access. ’s identity, public key, private key, and public key certificates are IDP, PKP, SKP, and CertP, respectively2. Driver : if a driver wants to provide ride-hailing service, he should be online and send his location to the platform. His identity, public key, private key, and public key certificate are IDD, PKD, SKD, and CertD, respectively3. Online transportation network (OTN) platform: according to received data from passengers and drivers, OTN makes a match and returns nearby vehicle information to P. OTN is also responsible for calculation of trip fees. His identity, public key, private key, and public key certificate are , , , and , respectively4. Third-party payment (TPP) platform: TPP is an independent institution in transactions. Because the activities, such as withdraw and deposit, need to be carried out on the cash accounts, all trading entities should register on TPP. TPP’s identity, public key, private key, and public key certificate are , , , and , respectively
In the existing ride-hailing system, OTN sends ’s phone number to and sends ’s phone number to . At the end of the trip, OTN deposits money to OTN’s account and ’s account according to prearranged proportion. So TPP knows ’s cash account and trip fees. OTN knows ’s identity, location, and fees. When OTN and TPP are conspiring together, more privacy will be disclosed.
We adopt e-cash payment pattern, which includes the communications among , , OTN, and TPP:1. obtains enough e-cash from TPP.2. inputs his pick-up and drop-off points and sends them to OTN. OTN estimates trip fees and sends them to . If agrees, he accepts it. Otherwise, he quits.3.OTN confirms the vehicle and returns ’s identity, phone number, license plate number, possible arrival time, and other information to .4. contacts : once gets on the car, tells OTN and OTN starts billing. When arrives at the destination point, notices OTN.5.According to the actual trip and duration time, OTN returns the service price. P makes a payment using e-cash.6.Within the validity period of e-cash, OTN sends e-cash and ’s identity to TPP. TPP deposits money into ’s and OTN’s accounts.
In the above process, there are some security and privacy concerns (Figure 1). When withdraws e-cash from TPP, he may be worried about the disclosure of his identity and location. When makes a payment, he expects that TPP can provide a secure and convenient payment way. For OTN, he needs to determine whether the payment is effective. For , he expects to obtain service rewards successfully. For TPP, he expects that is credible when applies e-cash; meanwhile, he expects that OTN is credible when OTN deposits e-cash.
3. Preliminaries
3.1. Cryptographic Primitives
Smartphones has become mainstream mobile devices. As we know, since mobile devices are generally energy-intensive and computing-power-limited, complex algorithms and protocols are not suitable for them. Considering hash function with the features of low power consumption and being one way and collision-free [11], a trusted hash chain is constructed in our model. Let , , and be collision-free hash functions. Define as the result of executions of .
In general, encryption and signature methods are used to ensure secure transmission of messages. Compared with other public key cryptography algorithms, elliptic curve cryptography (ECC) requires smaller keys to provide equivalent security. So an elliptic curve Ep: y2 = x3 + ax + b on the finite field GF(p) is chosen, where 4a3 + 27b2 ≠ 0 . are common parameters, and is the point of order . On the elliptic curve, define as encryption function of message using the public key PK. Similarly, is a decryption function using the private key SK. is a signature function. is a signature verification function using the public key PK. Define the symbol ∥ as a string concatenation operation.
3.2. Divided e-Cash
When e-cash is divided, it can be reused. This brings convenience for payment. But a traditional divided e-cash scheme has large amount of calculation [12]. Based on hash authentication and partially blind signature, we combine hash chain with e-cash to make a practical payment. As long as e-cash does not run out, it can continue to be used.
First choose a random number and compute , , and , forming the hash chain . And then the root node , OTN’s identifier , the denomination , the expiry date , and TPP’s signature are embedded into e-cash.
The credential material for the first payment is e-cash , where is the trip expense and is the corresponding chain node. If , the node is effective. Second payment credential material is e-cash , where and is the second expense. If and , is the effective node. Later payment processes are done in a similar way.
To sum up, an effective payment requires the following: (i) E-cash is used within the validity period. In particular, payment and deposit time is not more than the deadline. (ii) TPP’s signature to e-cash is correct. (iii) The hash chain is trusted; that is, all nodes should pass validity check.
4. Proposed Scheme
The scheme includes nine protocols: initialization, withdrawal, ride, payment, deposit, repeated payment, refund, collaborative tracking, and high anonymous payment. Among them, repeated payment, refund, collaborative tracking, and high anonymous payment protocols are optional according to different consumption demands and privacy requirements. For example, if has surplus e-cash, he may use it once again (repeated payment) or refund his money (refund). When a malicious event happens, OTN may contact to track . Additionally, with high privacy requirements may choose the high anonymous payment protocol.
4.1. Initialization
, , and OTN need to register their cash accounts on the payment platform TPP, which works as a debit system. If the denomination of e-cash issued to is , ’s account will be reduced by . We assume that TPP is in the secure environment and all the accounts data stored in TPP will not be leaked illegally.
4.2. Withdrawal
When applies for e-cash, the withdrawal protocol is executed between TPP and . Using a partially blind signature method, TPP issues e-cash as follows:(1)TPP randomly chooses and computes and sends to .(2) sends a request for e-cash to TPP.(a)Choose randomly, and generate a hash chain .(b)Choose the blind factors and randomly and compute where and .(c)Compute where , , and is coordinate of point on the elliptic curve. In particular, is a common message negotiated by and TPP; and are the denomination and expiration date of e-cash, respectively.(d)Blind and obtain(e)Send and ’s signature and certificate(3)TPP verifies whether and are correct. If satisfied, TPP further confirms whether ’s account balance is greater than . If satisfied, TPP reduces from ’s account, and then he makes a partially blind signature, and sends it to . Otherwise, he aborts.(4) removes the blind factor from and obtains(5) checks the equation where , , and .(6)If (7) does not hold, aborts. Otherwise, obtains
4.3. Ride
(1) sends the pick-up point and drop-off points to OTN; OTN returns the estimated price to .(2)If accepts the price, then he confirms the service; otherwise, he aborts.(3)OTN selects the nearby vehicle and returns ’s contact information to .(4) calls . When gets on the car, notices OTN. When arrives at the destination, sends the actual arrival time and place to OTN.(5)OTN calculates the actual price and sends it to .
4.4. Payment
(1)P confirms payment and sends OTN(2)OTN decrypts and checks whether the date and signature of e-cash are valid. If they are valid, he further checks
If satisfied, he records (e-cash, , ). Otherwise, the payment has failed.
4.5. Deposit
(1)During the validity period of e-cash, OTN sends TPP where .(2)TPP decrypts and verifies whether e-cash is validated. If verification is passed, he records (e-cash, , ). Then TPP deposits money into OTN’s and D’s accounts according to the agreed proportion, respectively.
The above withdrawal, payment, and deposit protocols are shown in Figure 2.
4.6. Repeated Payment
When e-cash has not been used up, may spend the remainder. If the amount of another consumption is , the payment protocol is modified as follows: sends to the OTN, where and . When the conditionis satisfied, OTN updates (e-cash, , ) to (e-cash, , ). If , it indicates that e-cash is used up.
4.7. Refund
During the period from (deposit deadline) to (refund deadline), can refund his money. First, sends
After TPP confirms that e-cash is valid, he returns the money into ’s cash account and updates the record (e-cash, , ) to (e-cash, , ). When the time passes , TPP deletes the record.
4.8. Collaborative Tracking
When a malicious event occurs, ’s identity needs to be recovered. In the ride protocol, contacts , and thus knows ’s contact information. If TPP needs to obtain ’s identity, he will contact . Then TPP and track collaboratively.
4.9. High Anonymous Payment
TPP does not know ’s identity when e-cash is reused. But multiple trips are paid with the same e-cash, which give away the fact that the different routes belong to the same person.
For a passenger with high privacy requirements, he may choose alternative payment protocol, where e-cash can only be used once. If the ride price is N, the denomination of requested e-cash is also . makes the first payment with , and then e-cash runs out once.
5. Security Analysis
Proposition 1. Partially blind signature protocol is correct.
Proof. From the withdrawal protocol, we can see Then . Therefore, the blind signature can be verified by (7).
Proposition 2. E-cash can be divided.
Proof. sends to TPP for the first payment. And the remaining can be reused. For the second payment, shows . Similarly, e-cash can be used repeatedly until . Therefore, e-cash is divided.
On the other hand, cannot be reused because OTN searches for the last used hash node (e-cash, , ) to decide whether this payment is valid. If the share is reused, then . So is rejected.
Proposition 3. E-cash is unforgeable.
Malicious , OTN, or TPP may expect to forge e-cash. For example, wants to increase ; OTN wants to embed false . Our withdrawal protocol based on blind signature has the existential unforgeability under the random oracle model and the assumption of difficulty in solving the problem on an elliptic curve. Specific proof is as follows.
The challenger receives an instance of the discrete logarithm problem and his goal is to compute . Let be a probabilistic polynomial Turing machine to find a valid signature. calls to solve the discrete logarithm problem. If is a sufficiently efficient forger, then it follows from the forking lemma. obtains two distinct forgeries and with and . From the signature process, we can obtain that and . Thus . Then . Sois the solution to the discrete logarithm problem.
Proposition 4. It is difficult for an attacker to impersonate a legitimate user to obtain e-cash and further make a successful payment.
Proof. The request for e-cash is signed by , which ensures the authenticity of requester identity and unforgeability of request message.
Since a complete hash chain is only owned by a legitimate user, illegal passenger fails to offer correct node to make a successful payment.
During payment and deposit phases, e-cash and chain node are encrypted and transmitted, which prevents the leakage of credentials.
Proposition 5. In the face of OTN and TPP, is anonymous.
Proof.
(1) E-Cash Has Partial Blindness. Any legitimate signature and any of intermediate variables satisfy the following equations: From the withdrawal protocol, . Further, we determine the unique value from (18) and from (17). Thus, Since and satisfy (16), there must be blind factors between any of the intermediate variables and any legitimate signature. So TPP cannot associate the signature result with the specific signing process to obtain ’s identity.
(2) Anonymous Payment. withdraws e-cash from TPP and then pays e-cash to OTN. Because there is no identity in e-cash, a ride service cannot directly be associated with user’s identity. On the other hand, when e-cash is reused, OTN can associate the different ride routes with the same e-cash, and thus is not completely anonymous. Alternative protocol is provided to make use new e-cash in each ride service.
Proposition 6. A ride route cannot be linked with a certain passenger identity.
Proof. For a single trip, there is no identity information in the communications between and OTN and between OTN and TPP. Thus, it is difficult to associate ’s identity with one ride route.
For several trips under the high anonymous payment protocol, one e-cash can only be used once; OTN cannot infer whether several trips belong to a single passenger.
Proposition 7. can be tracked under certain conditions.
Proof. Because knows ’s contact information, OTN can track an illegal person through the collaborative tracking protocol with the help of . So ’s identity can be recoverable under certain conditions.
We compare our scheme with other schemes that are intended to ensure security and privacy of mobile payment. The results are shown in Table 1.
The schemes [7, 8] provide antieavesdropping, anonymity, and nonlinkability. Scheme [7] does not use e-cash, and it does not provide traceability. Scheme [8] and our scheme both track illegal passengers and use e-cash. But divided e-cash has not been mentioned in [8].
6. Evaluation
6.1. Performance of Our Scheme
Among the required protocols, the initialization protocol occurs in the registration phase; and the ride protocol is similar to existing services. So we mainly analyze the performance of withdrawal, payment, and deposit protocols.
Communication Cost. It concludes 5-step communications among three entities. TPP sends to . submits a request to TPP. TPP generates the blinded e-cash to . sends encrypted e-cash to OTN for payment. OTN sends encrypted e-cash to TPP for deposit.
Define the symbol as the length of a string. The communication cost of concern includes the withdrawal cost , the payment cost , and the deposit cost .
Computation Cost. For convenience, to evaluate the computation cost, we ignore some operations such as a hash function and a multiplication operation because they are quite light in terms of load. We focused on some time-consuming operations defined in the following notations. , , , , , , and denote the time of signature, verification, encryption, decryption, point multiplication, blind signature, and validation operations on the elliptic curve, respectively. The computation cost of concern can be broken up into 3 parts. During the withdrawal phase, computes and ; TPP checks and ; checks . The time of these operations is + 2 + 4. During the payment phase, computes , and OTN decrypts it and checks . The operations take . During the deposit phase, OTN computes ; TPP decrypts it. We assume that OTN will no longer need to check the effectiveness of blind signature after he makes the first confirmation. Then the time during the phase is . Therefore, the overall computation costs during the three phases are .
Performance Evaluation. In order to provide the precise comparisons of computation and communication costs, we use the experiment data in [13] to evaluate them. On the elliptic curve , 0.6 ms is required to perform scalar multiplications if bytes and bytes. For the elliptic curve digital signature algorithm (ECDSA), if the key is 28 bytes, the signature result is 53 bytes, and the public certificate is 84 bytes; 0.8 ms is required to perform signature and 4.2 ms is required to perform verification. Additionally, for the elliptic curve integrated encryption scheme (ECIES), the encryption time is approximately 2; the decryption time is approximately ; and the cipher text length is twice as large as the plaintext. Specifically, we assume , bytes, and bytes; then bytes and bytes. Therefore, the withdrawal cost is bytes; the payment cost is bytes; and the deposit cost is bytes.
Figures 3 and 4 show computation and communication costs during the three phases of withdrawal, payment, and deposit, respectively. It is seen that the computation cost during payment phase is the smallest among the three phases. Considering that payment occurs most frequently among three activities, it is beneficial to improve the overall performance of the ride-hailing system.
6.2. Performance Comparisons
E-cash is used in [8], whose system architecture is partly similar to ours. We shall compare the two schemes. Table 2 shows comparisons of computation and communication costs. In particular, the costs of the scheme in [8] are for the withdrawal and secure channel establishment phases; meanwhile, the costs of our scheme are for the withdrawal, payment, and deposit phases. In the table, , , , and represent the time of blind signature, blind verification, symmetric encryption, and symmetric decryption, respectively. From the overall performance, our scheme is better than the scheme in [8].
The scheme in [8] used DH key exchange protocol to establish secure channel between a passenger and a driver. Just the two phases of withdrawal and secure channel establishment require at least four steps. If payment and deposit are taken into account, the communication cost of the scheme in [8] is more than ours.
In the scheme in [8], a symmetric encryption method is used to prevent e-cash from being stolen. The computation cost of symmetric encryption is small relative to that of asymmetric encryption, but the key agreement protocol for distributing a session key increases the cost. Moreover, the scheme does not provide the specific description of blind signature. In our scheme, an authenticated hash and e-cash are used to design the repeated payment and refund protocols. It not only reduces costs but also improves practicability.
7. Conclusion
We construct a trusted hash chain with anonymous e-cash and then provide a privacy protection scheme for ride-hailing services. It consists of nine protocols: initialization, withdrawal, ride, payment, deposit, repeated payment, refund, collaborative tracking, and high anonymous payment. The latter four protocols are optional protocols. Security analysis shows that e-cash is divided and unforgeable; the scheme has antieavesdropping, anonymity, and nonlinkability. Performance analysis shows that the scheme has a small amount of communication and computation overhead because a lightweight hash chain is introduced. Moreover, its main business process is basically consistent with the prevailing services. Therefore, it can be deployed on the existing transaction systems.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This work was supported by the Natural Science Foundation of Anhui Province (Grant 1608085MF141), the Major Research Project for Social Science Innovation and Development of Anhui Province (Grant 2017ZD005), and the Visiting Scholar Projects of Anhui Province for Excellent Young and Middle-Aged Backbone Talents (Grant gxfxZD2016305).