Abstract
In the past few years, ride-hailing platforms such as Uber, Waymo, and Baidu have built their own autonomous taxi system. Unlike public transit services, ride-hailing platforms raise severe privacy issues. To provide excellent autonomous taxi service, some significant security and privacy problems must be addressed. In this study, we present the security and privacy threats and first proposed blockchain-based anonymous ride-hailing scheme (BBARHS) for autonomous taxi network. We give the formal system model and security model of BBARHS. Then, we outline the concrete BBARHS scheme by making use of Monero and some efficient crypto tools. Through security analysis and performance analysis, the designed scheme is provably secure and efficient. The analysis results also show the designed BBARHS scheme is practical for autonomous taxi network.
1. Introduction
With the development of information technology and AI, autonomous vehicles (AVs) come true. One of the most discussed potential use cases of AVs is RHS (ride-hailing service). AVs and public transit would cut traffic by 90%. It could be 10 times cheaper to take E-AVs taxi than to own a car by 2030 [1]. Waymo, a company owned by Google, officially obtained the first commercial automatic driving taxi service license and took the lead in launching relevant services in Phoenix, the United States [2]. Autonomous Lexus has been tested in California, Michigan, and Japan and preparing for real-world use during the 2020 Tokyo Olympics. Chinese ride-hailing giant Didi expects at least 10% of vehicles to be highly autonomous by 2025, and fully autonomous by 2030 [3]. But in fact, under the existing technical conditions, there are still many challenges and difficulties for the autonomous taxi to achieve commercial scale on the actual road. Without the passengers’ knowledge, Uber collected information including passengers’ names, e-mails, boarding locations, spending amounts, etc. Autonomous taxi network consists of riders, RHS, and AVs. An autonomous taxi system needs to meet various indicators, for example, performance, safety, and stability [4, 5].
Over the past decade, blockchain as the backbone of bitcoin has experienced a rapid development [6]. Many researchers explore blockchain application scenarios [7–9]. A blockchain is essentially a distributed database of records, or public ledger of all transactions or digital events that have been executed and shared among participating parties. Each transaction in the public ledger is verified by the consensus of a majority of the participants in the system. Once entered, information can never be erased. The blockchain contains a certain and verifiable record of every single transaction ever made [10]. The basic structure of blockchain is shown in Figure 1.
The blockchain uses digital signatures to determine the identity of the sender of information. A digital signature is a digital string that can only be generated by the sender of the message, and this digital string is also an effective proof of the authenticity of the message sent by the sender. It is a kind of ordinary physical signature similar to that written on paper, but it is realized by the technology in the field of public key encryption, which is used to authenticate digital information. Bitcoin uses an elliptic curve digital signature algorithm (ECDSA) to generate public and private keys for accounts and to verify transactions and blocks. The ECDSA is an analog of the digital signature algorithm (DSA) using elliptic curve cryptography (ECC).
The cryptographic hash function is a type of hash function. An arbitrary amount of data input of this hash function is usually called a message, and its fixed-size output result is often called a hash value. The secure hash algorithm (SHA) is a series of cryptographic hash functions designed by the National Security Agency (NSA) and published by the National Institute of Standards and Technology (NIST), including SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 variants. Bitcoin uses SHA-256. That is, no matter how many bits the original data have; as long as the hash operation is passed, the length of the result is fixed as 256 bits.
Representative projects of public chains such as bitcoin and ethereum use POW and POS consensus algorithms. Miners use SHA-256 to calculate the hash value that meets the difficulty target value (starting with N zeros). Representative projects of the alliance chain such as hyperledger fabric use PBFT as the consensus calculation method. Nodes use digital signatures to directly exchange information to reach a consensus. Blockchain guarantees the authenticity, privacy, and security of information through cryptographic tools and consensus algorithms.
Riders need to exchange information between multiple participants, and privacy protection and the authenticity of information are extremely important. This article aims to use the characteristics of blockchain technology to solve these problems in the field of autonomous taxi.
1.1. Motivation
Security and privacy problems are the two major problems that need to be solved urgently for autonomous taxi network. In order to be able to provide services, the system needs to manage the location information of autonomous taxi, rider standards, service scenarios, how much fuel there is, and so on. After that, an autonomous taxi is allocated based on the service information requested by the rider. Finally, the rider needs to pay for the service. In these processes, how to protect the privacy of rider and how to ensure the safety of autonomous taxi are very important. If privacy of rider and autonomous taxi is leaked or autonomous taxi has service standards mismatch or safety issues, then it can cause reputation and economic loss and increase the difficulty for the autonomous taxi to be accepted by the market. For example, several employees of Didi used their authority to check user travel records and make illegal profits [11]. Thus, blockchain-based anonymous ride-hailing services are of great significance to the development of RHS.
In real life, there may be problems such as overloading of autonomous taxi to get more fees and mismatches in many service standards. This will cause safety issues and disputes between the rider and the platform. How to achieve transparent and credible management is a problem that the platform has been solving. In addition, autonomous taxi platforms may collect riders’ data. How to ensure the privacy of riders while providing services is also worthy of attention.
In order to resolve the privacy issues between the rider and autonomous taxi, as well as disputes over autonomous service standards, we propose a blockchain-based anonymous ride-hailing scheme (BBARHS) for autonomous taxi network.
1.2. Related Works
Autonomous vehicles are one of the most anticipated technological developments of our time, and they have potential wide-ranging social influence [12]. However, there are serious privacy issues when users leak location information to the taxi server.
In 2019, Yu et al. proposed a lightweight and privacy-preserving ride-matching scheme, called lpRide, to address the issue of protecting rider’s location privacy during ride matching [13]. In 2017, Zhang et al. used a third-party database and data interactive review platform to protect personal privacy. Online taxi service software platforms and other profit-making organizations can rent data interactive review platforms to announce to the public their improvements in personal privacy protection. However, this article does not provide a specific implementation and simulation of the system [11]. In 2018, Khazbak et al. proposed an enhanced solution that relies on enhanced driving matching and temporary stealth algorithms. The enhanced solution provides riders with personalized location privacy while limiting the loss of matching accuracy [14]. In 2017, Pham et al. proposed Private Ride, a practical solution that uses well-established privacy and cryptographic tools to enhance location privacy for the participants, while preserving the convenience and functionality offered by the current system [15]. In 2017, Pham et al. proposed ORide (Oblivious Ride), a privacy protection RHS based on somewhat-homomorphic encryption and with optimized functions such as ciphertext packaging and conversion processing, to address privacy issues in ride-hailing service [16].
Many researchers have proposed different privacy-enhancing solutions for taxi service. However, according to our literature review, little work exists in the area of privacy and security for autonomous taxi network. Thus, we propose a blockchain-based anonymous ride-hailing service scheme in autonomous taxi network.
Based on the summary of previous research, this study studied privacy and safety issues in autonomous taxi network. Our contributions are listed as follows:(1)For the first time, we propose anonymous ride-hailing service for autonomous taxi network by making use of blockchain. We give a formal system model and security model. Our system can protect rider’s privacy and platform’s privacy simultaneously.(2)The unlinkability between the payer address and the payee address is satisfied. Nontraceability is also satisfied. When the payment is executed, no one can find the relationship between them. No one can find the address of the payer.(3)We first propose the blockchain-based anonymous ride-hailing service scheme (BBARHS). The proposed BBARHS scheme can be proved to be secure in the random oracle model. The analysis and the simulation show that the scheme is effective and practical for secure ride-hailing service of autonomous taxi network.
1.3. Organization
The rest is organized as follows: Section 2gives some cryptographic background, which includes PKCs in PKI, blockchain, etc. The system model and the security model of the BBARHS scheme are introduced in Section 3. Our scheme is presented in Section 4. The analysis and the simulation are in Section 5. Finally, this study is concluded in Section 6.
2. Background
This section will briefly explain the cryptographic background involved in the application of this article, the application of PKI and its PKCs and PKCs on the blockchain, ECC encryption algorithms and bilinear pairs, ring signatures, group signatures, and Monero.
2.1. PKCs on PKI and PKCs on Blockchain
PKCs are a set of public key cryptography standards developed by RSA data security company and its partners, which promote secure transaction and data transmission on the network, such as e-commerce and confidential mail [17]. It includes a series of related protocols, such as certificate application, certificate renewal, certificate revocation form release, certificate content extension, digital signature, and digital envelope format. PKC is a cryptosystem with a pair of keys, a widely spread public key and a private key known only by itself. The essence of blockchain is a decentralized database. It has no trusted third party. Therefore, there is no organization like CA (certificate authority) and PKI involved in the blockchain [18]. In the PKCs of blockchain, we use public key encryption to create a key pair to control the acquisition of assets. The key pair includes a private key and a unique public key derived from it. The public key corresponds to the address on the blockchain, in which the assets are stored, while the private key is used to sign transactions of the assets [19].
2.2. ECC and Bilinear Pairings
ECC (elliptic curve cryptosystem) is a public key cryptosystem with shorter key length than RSA. It is realized by special multiplication of a specific point on an elliptic curve. It takes advantage of the fact that the inverse operation of this multiplication operation is very difficult to achieve a good effect of encryption.
Elliptic Curve on the Finite Field . For fixed and , all points satisfying the shape of the equation are set, plus a zero point and an infinite point , where a, b, x, and y are all take a value on the finite field , that is, take a value on . is a prime number.
The discrete logarithm problem in the elliptic curve group refers to the problem of knowing and in the group to solve the equation in the value of . It is easy to find from and , but it is difficult to find from and . This is the discrete logarithm problem on the elliptic curve, which can be applied to public key cryptosystems.
In addition, the elliptic curve can be used to realize the Diffie–Hellman key exchange. By selecting a base field and two parameters , , the points on the elliptic curve and the infinity points form the Abel group .
Taking a generator of , the order of is prime number . , , and are public parameters. User A and B start to exchange keys. A randomly selects an integer , keeps , calculates to generate , and sends a point on to B. B similarly selects the secret and calculates and sends it to A. A and B generate the shared secret key of both parties by and respectively, in fact . If the attacker wants to obtain , then he must find from and , or find from and ; that is, the discrete logarithm on the elliptic curve is required. Thus, it is not feasible.
In 1983, Menezes et al. defined a special elliptic curve on a finite field, that is, a supersingular curve, and pointed out that these elliptic curves use the elliptic curve discrete logarithm problem to construct a more standard discrete logarithm of the cryptosystem [20]. The problem of using smaller finite fields does not exist. In the supersingular curve, there is an effective algorithm that maps two points on the curve (on a finite field) to an element in the base field. In the supersingular curve, the typical representatives are the Weil pair and Tate pair. These two supersingular elliptic curve pair transformations can be used to construct a bilinear pair. The basic concept of bilinear pairing is as follows:
Let and be the additive group and multiplicative group of order respectively and is the generator of . Suppose that in the groups , , the discrete logarithm problem is difficult to solve. The bilinear mapping pair can be defined as : and meet the following characteristics:(1)Bilinear. For all , and , .(2)Nondegenerate. There is one , which satisfies .(3)Computability. For , there is an effective algorithm to calculate .
A bilinear map can be constructed using the modified Weil [21] or Tate pairings [22] on supersingular elliptic curve . A group with such a map is called a bilinear group, on which the CDHP is assumed hard, while the DDHP (decisional Diffie–Hellman problem) is easy [23]. Namely, given unknown and , it is known that there exists an efficient algorithm to determine whether by verifying in polynomial time (DDHP), while there exist no efficient algorithms to compute with non-negligible probability within polynomial time (CDHP).
2.3. Ring Signature, Aggregate Signature, and Monero Blockchain
Ring signature is a kind of digital signature scheme, which was first proposed by Kim [24]. Ring signature has only ring members, no manager and no cooperation between ring members. Ring signature refers to hiding the public key with private key among n public keys, which supports hiding transaction sender (address/public key) on blockchain. Suppose there are n users, and each user has a public key and its corresponding private key. Ring signature is a signature scheme, which can realize the signer’s unconditional anonymity, which is mainly composed of the following algorithms:(1)Generate Gen. It is a probabilistic polynomial-time (PPT) algorithm. The input is security parameter K, and the output is public key and private key. It is assumed that Gen generates a public key and private key for each user, and the public and private keys of different users may come from different public key systems, such as RSA and DL.(2)Sign. It is a PPT algorithm. After inputting the message m and the public key of n ring members and the private key information of one of the members, a signature R is generated for the message m. The parameters are in a ring shape according to certain rules.(3)Verify. It is a deterministic algorithm. After inputting , if R is the ring signature of M, then it will output “true”; otherwise, it will be “false.” Aggregate signature is a variant signature scheme used to aggregate any number of signatures into a single signature [25]. It can merge the public key and signature of each participant in a multisignature transaction into one public key and signature. The whole merging process is invisible, and the information before merging cannot be deduced from the combined public key and signature; only one verification is needed during verification. At present, the Schnorr signature algorithm is usually used to implement signature aggregation [26]. Monero is a cryptocurrency for the connected world [27]. It is fast, private, and secure. Monero has the following three characteristics:(1)Anonymity. Monero achieves anonymity by using ring confidential transactions (a combination of ring signature and anonymous transactions) and anonymous addresses. In addition, Kovri is used to confuse point-to-point communication. Due to the use of ring signature, at least six bait coins are added to each transaction, and each currency seems to be the actual amount spent in the transaction, making the actual source and target almost impossible to trace.(2)Scalability. Due to the use of ring signature, each transaction is attached with additional data, which greatly increases the size of the blockchain. At the time of writing, the Monero blockchain is about 48 GB in size and will continue to grow with wider adoption, placing a burden on scalability. We estimate that the average transaction size in the Monero network is about 14 KB, almost 25 times the size of bitcoin. Simply put, when Monero reaches bitcoin’s current volume of transactions, its blockchain will be about 5 TB—almost unbearable for ordinary PCs, let alone on small devices. It is worth noting that the Monero team is currently implementing a bulletproof protocol that can increase scalability by up to 80 (still about five times that of bitcoin).(3)Auditing. Monero provides the viewkey function to allow a third party to audit users’ transactions. However, it only allows you to view the input transactions, not the output transactions, making it less friendly to auditors. In addition, there seems to be no way to prove that the incoming transaction list is complete.
3. System Model and Security Model
In this section, we describe the system model and security model for the BBARHS scheme. It contains the participating entities and the security requirements of the scheme.
3.1. System Model
In the BBARHS scheme for autonomous taxi network, there are four participating entities, namely, RHS, LAV (local autonomous vehicles), rider, and the blockchain. The detailed description is as follows:(1)RHS. It is a ride-hiding service platform. It authorizes the legal riders and receives payment from riders. Considering management and performance bottlenecks, RHS does not provide direct services and LAVs added to autonomous taxi network.(2)LAV. It is a local AVs provider. LAV provides ride-hiding service directly to local riders. When the ride-hiding service is completed, it sends the certificate to RHS and the receipt to the rider, respectively. Receipt and certificate are used to prove its service.(3)Rider. Before requesting service, the rider needs to obtain RHS certification. Rider accepts LAV’s service and makes the payment through the blockchain.(4)Blockchain. Rider and RHS have digital currency on the blockchain. Riders pay for service through the blockchain and RHS receives the digital coins sent by the rider.
3.2. Security Model
In the BARHS for autonomous taxi network, we consider four privacy issues. The privacy issues include the identity of the rider, payer address of the rider, payee address of RHS, and the unlinkability between payer address and payee address. In order to protect the above privacy, our BBARHS scheme must satisfy the following goals:(1)Mutual Identification among Rider, RHS, and LAV. When the rider needs ride-hailing service, he must get the authorization from RHS. By verifying the validity of the authorization from RHS, LAV chooses whether to provide service. RHS and LAV interact to get the detailed information of rider.(2)Anonymity for Rider. In the process of receiving LAV’s service, LAV cannot identify the identity of rider. In the process of authorization and payment, RHS cannot identify the identity of rider.(3)Anonymity for RHS. Although RHS receives payment from the rider, RHS cannot identify rider’s address on the blockchain.(4)Unlinkability between payer address (for the rider) and payee address (for RHS) on blockchain.
This study uses many notations. These notations and the corresponding descriptions are listed in Table 1.
According to the above security requirements, we give the formal security definitions as follows:
Definition 1. Unforgeability: RHS’s authentication protocol satisfies the unforgeability if the probability that A wins the following game is negligible where A is PPT (probabilistic polynomial time) adversary.(1)Setup. The system parameters are created and RHS’s private/public key pair is generated. At the same time, rider’s private/public key pair is also generated. For RHS, its private/public key pair is generated in PKI (public key infrastructure). For the rider, its private/public key pairs are generated by the rider itself where there is no trusted third party. System parameters, RHS’s public key, and rider’s public key are sent to A. We denote the public parameters as params.(2)Interaction between A and the Challenger C. In the interaction, A adaptively queries C and gets C’s responses. The queries and responses are listed as follows:(a)Hash Query. A sends the hash queries to C. C creates the hash function value and sends it to A (random Oracle model). C accesses the hash function and responds A with the real hash value (standard model).(b)Authentication Query. A makes the authentication query on the different public key with the corresponding message, which are denoted as . C creates the authentication and sends it to A. In the process, we denote the query set as and the response set as .(3)Forgery. A can forge a valid authentication on a new public key with the corresponding message, which is denote as . The forged public key and metadata are different from the queried public keys with the corresponding messages, that is, .We say that A wins the above game between A and C if is a polynomial of the security parameter k. In other words, we say that A wins if A’s success probability is non-negligible.
Note 1. The above definition gives the formal definition of unforgeability for RHS authentication. For LAV authentication and ring signature for transaction, the formal definitions of their unforgeability are similar to the above definition. Due to the page limits, we omit the corresponding definitions.
Definition 2. Anonymity for the Rider: in the BBARHS scheme, RHS is unconditionally anonymous. In other words, the adversary cannot identify the rider’s real identity even if the adversary’s computing power is infinite.
Definition 3. Anonymity for RHS: when the rider has output addresses, if all the output addresses do not belong to the adversary, then the probability that RHS’s address can be identified is not more than .
Definition 4. Untraceability: for each incoming transaction, all possible senders are equiprobable.
Definition 5. Unlinkability: for any two outgoing transactions, it is impossible to prove they were sent to the same person.
4. An Efficient BBARHS Scheme
According to the system model and security model proposed in the previous section, we design a BBARHS scheme for autonomous taxi network. To satisfy the security model and transparent management, the proposed scheme takes use of some cryptographic techniques, which include PKI, digital signature, elliptic curve cryptography, and Monero. The proposed scheme consists of seven procedures: (i) initialization, (ii) contract-based authorization, (iii) anonymous service provision, (iv) pay for services, (v) verification and gain, (vi) solving the dispute, and (vii) rider revocation. The detailed procedures are given below.
In order to show the intuition of the scheme, the structure of our scheme is shown in Figure 2. There are four entities, that is, blockchain, RHS, LAV, and rider. We give the description of their interactions. (1) Riders and RHS generate the private key and public key respectively. The public key is the address on blockchain. RHS and LAVs also generate private key and public key pairs in PKI. (2) By making use of rider’s public key, the rider registers himself at RHS. (3) RHS has a table to record which riders are valid or invalid. RHS authorizes LAV to provide service for valid riders. (4) LAV provides service for the rider and sends the receipt to the rider. At the same time, LAV sends certificate to RHS. (5) Rider pays for the service through blockchain.
4.1. Initialization
In our proposed system, we use two types of system parameters. One type of parameter is used for blockchain. Other types of parameters are used for registration, receipt, certificate, authorization, and revocation. The detailed generated procedures are given below. Figure 3 shows the process of contract-base authorization, anonymous service and receipt, pay for the service, and verification and gain.
4.2. Contract-Based Authorization
In order to get the service from LAV, the ith rider, that is, , needs RHS’s agreement. First, RHS needs to get ’s status information. Based on this information, the agreed contract is created. contains rider’s status information, pay for the service, service standards, etc. In order to protect rider’s privacy, does not contains rider’s identity information. is contained into to get the authorization from RHS. At the same time, RHS records a table, which lists the valid rider. The authorization procedures are as follows:(1)RHS generates the signature for below: .(2)RHS adds the address into the table .(3)RHS sends to rider.(4)RHS sends the updated table to all the LAVs.
4.3. Anonymous Service and Receipt
When accesses the anonymous taxi network and requests the service from RHS, it presents to the in the local area, where . ’s private/public key pair is , where . can be verified as follows:(1)At some moment, receives a lot of pairs , where .(2)For every , extracts ’s public keys from . If belongs to , then provide service for ; otherwise, rejects ’s request.(3) picks the random numbers , and verifies whether the following formula holds: If the formula does not hold, then finds out the invalid pairs and rejects them, and then go to the following procedure.(4)When receives service from , generates the receipt as follows:(a)Denote ’s service information as the message . computes .(b) sends to RHS and , respectively.
For , is the receipt for its service. For RHS, is the certificate of the service for .
4.4. Pay for the Service
Suppose that there are many LAVs. We denote them as . For , the corresponding private/public key pair is , where . RHS receives the certificate from , where . RHS picks the random numbers and verifies them by checking whether the following formula holds:
By checking the correctness of the above formula, RHS can determine whether the service is complete.
In order to pay for the service, performs the following procedures:(1)For the where , unpacks the received messages and gets RHS’s address . generates a random number , and then it gets a one-time public key for RHS.(2)For the messages , where , can unpack it and get the balance to be paid. Suppose that has the balance on the blockchain. Concretely, for RHS whose one-time public key (account address) is , the output corresponds to the rewarding balance . Besides them, the additional output corresponds to the change . In order to simply the symbols, we denote the outputs and some metadata as the message . For example, contains and for RHS, where .(3) calculates where is the signature on the message by making use of ’s private key .(4) selects a random subset of the other users’ public key , has the cardinality , and his own private/public key pair is , where . It also computes the image . It picks the random numbers and from . Then, it computes the following points:
Then, computes
The following values
The resulting signature is as follows:
When finished the above procedures, it sends the balance to and to with the signature , where is selected by . is used to store the change .
Note 2. To avoid double-spending, the private key can be used only one time on the Monero. Thus, the change must be moved to new address , which is chosen by on the Monero.
4.5. Verification and Gain
When RHS receives the signature and the message , RHS performs the following procedures to check the validity of the signature :(1)RHS computes F2 in Table 2.(2)RHS checks whether F3 in Table 2 holds. If the formula does not hold, the signature is rejected.(3)RHS checks whether has been used in past signatures. If it appeared in the past signatures, then the signature is rejected; otherwise, RHS accepts .
In other words, the coin is moved to and is moved to from the address .
RHS checks rider’s payment . From , RHS extracts and where . RHS computes . If , then there exists , which satisfies . In order to gain the reward , RHS computes , which satisfies . Thus, RHS gains the reward . Since RHS knows the private key of the address , RHS gains the reward .
Notes. In the initialization procedure, RHS can generate a lots of account address, which are used for receiving coins from different transactions.
4.6. Solve the Dispute
When RHS cannot find its , it sends its certification to rider. Rider checks RHS’s certification, and if it is valid, then rider tells RHS the transaction information with the ring signature. If RHS thinks rider is not the real signer, then rider performs the following procedure to prove he is the real signer:(1)Rider shows RHS the preimage of the hash function on the image .(2)RHS verifies whether is the preimage of and whether is a valid signature signed by rider’s public key . If it is valid, then RHS admits that rider is the real signer; otherwise, RHS denies that rider is the real signer.
4.7. Rider Revocation
Rider revocation schemes from two cases are as follows:(1)Case 1. When RHS wants to reject rider’s service, RHS updates the table . RHS adds the revocation information to the table and sends it to LAVs.(2)Case 2. When the rider would like to be revoked, the rider can inform the revocation information to RHS. RHS updates the table and sends it to LAVs.
5. Security and Performance Analysis
The security and performance of our scheme are given in this section. According to security analysis, performance analysis, and the simulation result, our BBARS scheme is secure and practical.
5.1. Security Analysis
Theorem 1. Authorization Correctness: if RHS and LAV are honest and follow the proposed BBARS scheme, then rider’s authorization from RHS can pass LAV’s verification.
Proof. According to the generation procedures of ’s authorization, we get(1)Correctness for ’s authorization:(2)Correctness for ’s certificates:
Theorem 2. Verification Correctness: if the rider and RHS are honest and follow the proposed scheme, then rider’s signature can pass RHS’s verification.
Proof. From the generation process of rider’s signature, we get(1)When , we get(2)When , we getBased on equations (1) and (2), we get
Theorem 3. Unforgeability: In our BBARHS scheme, ’s authorization from RHS, the receipt and certificate from LAV, and the ring signature from rider satisfy the unforgeability.
Proof. In our BBARHS scheme, we take use of BLS short signature scheme in PKI. BLS short signature scheme is provably secure, and the detailed proof process has been given in the reference. For the ring signature from rider, we take use of Saberhagen’s transaction scheme. The detailed proof process is similar to Saberhagen’s proof process, which can get in the reference. [28] Due to page limitations, we omit the proof process.
Theorem 4. Anonymity for Rider: in our BBARHS scheme, the rider is unconditionally anonymous. We prove this theorem from the following two parts:(1)In the phase of contract-based authorization, rider’s contract does not include its identity information. The chosen public keys have nothing to do with ’s identity. In the phase anonymous service and receipt, submits to . The message does not include ’s identity. Thus, our BBARHS scheme does not need ’s identity. The scheme satisfies the anonymity for rider.(2)Our phase pay for the service takes use of the ring signature to realize the anonymity of rider. From the final signature we know that . On the other hand, both . Thus, if rider generates a transaction on behalf of a ring of addresses, then rider’s anonymity can be satisfied.
Theorem 5. Anonymity for RHS: our BBARHS scheme satisfies anonymity for RHS.
Proof. When there are output addresses and all the output addresses do not belong to the adversary, all the one-time public key is random due to the property of the hash function . Thus, all the output addresses are random for the adversary.
In the following part, we show why our BBARHS scheme can satisfy the unlinkability and solve the dispute:(1)From the phase pay for the service, the outgoing transaction addresses are one-time public key for RHS, where . Thus, for any two outgoing transactions, it is impossible to prove they are sent to the same person.(2)From the phase pay for the service, we know that . Based on the security properties of hash function , only rider know ’s preimage . Thus, by showing , rider can prove he is the real signer. If RHS still does not believe rider is the real signer because A’s preimage may be come from others, then RHS verifies by making use of rider’s public key .(3)If rider and RHS are honest and follow the above process, then they can resolve dispute.
5.2. Performance Analysis
Our BBARHS scheme must be efficient in terms of computation cost and communication cost. In our BBARHS scheme, two different PKCs are used: PKCs in PKI and PKCs on the blockchain. For PKCs on the blockchain, on the elliptic curve , the point addition cost is denoted as and the scalar multiplication cost is denoted as . On the bilinear group pair , the bilinear pairing cost is denoted as , the scalar multiplication cost is denoted as , and the point addition cost is denoted as . Comparing to the above computation cost, the other computation cost is smaller. For the above denotations, is the abbreviation of scalar multiplication and is the abbreviation of point addition on . On the other hand, is the abbreviation of bilinear pairing, is the abbreviation of scalar multiplication, and is the abbreviation of point addition on .
5.3. Theoretical Performance Analysis
For the performance of our scheme, the theoretical analysis is given in Table 3. In Table 3, denotes the entity does not take part in the procedure. “Small” denotes the computation cost is less than the five operations , , , , and . denotes the ring size of the ring signature. The procedure contract-based authorization is performed between the rider and RHS. Rider’s computation cost is small and RHS’s computation cost is , where is the number of riders. The procedure anonymous service and receipt is performed between rider and LAV. Rider’s computation cost is small and LAV’s computation cost is . The procedure pay for the service is performed by rider and RHS. Rider’s computation cost is , where is the number of services to be paid. denotes the number of transactions needed to pay. RHS’s computation cost is . The procedure verification and gain is performed by RHS and blockchain. RHS’s computation cost is and blockchain’s computation cost is .
According to the above two PKCs, we analyze our BBARHS scheme’s communication cost, as listed in Table 4. The PKC on the blockchain is the elliptic curve over the finite field , where bits. In the bilinear group , is the supersingular elliptic curve over the finite field , where bits. In the procedure contract-based optimization, rider sends to RHS. RHS sends bits to and sends bits to LAV. ’s size is a constant 1024. is the size of the contract. At the same time, the communication cost of LAV only comes from the size . Thus, has the linear relation with . In the procedure anonymous service and receipt, sends to RHS and , respectively. The corresponding communication cost is bits. For the communication cost , , , and are the same constant, which are 1024 bits. On the other hand, has the linear relation with . In the procedure pay for the service, the final signature size is bits for per service. For the communication cost , the sizes of , , , and are different constants. They are 512 bits, 512 bits, 253 bits, and 253 bits, respectively. At last, has the linear relation with , which is the number of the ring users.
5.4. Implementation
In order to demonstrate our BBARHS scheme’s effectiveness, we implemented it by making use of the GMP (GMP-5.0.5), Miracl, and PBC (pbc-0.5.13) libraries. In our simulation, both RHS and LAV ran on a computer, which has the following features:(i)CPU: Intel Core i5-8500 @ 3.0 GHz(ii)Physical memory: 8 Gb(iii)OS: Ubuntu 18.04 Rider ran on a laptop, which has the following features:(i)CPU: Intel Core i5-8500 @ 3.0 GHz(ii)Physical memory: 8 Gb(iii)OS: Ubuntu 18.04
Besides the above simulation environment, we take use of the Monero blockchain. For the PKCs in PKI, we take use of the bilinear group , where is defined on the finite field with bits. At the same time, is a supersingular elliptic curve with 160 bits group order. Figure 4 depicts the time cost of RHS and LAV in the procedures contract-based authorization and anonymous service and receipt, respectively. In the figure, X-axis represents the number of riders. The Y-axis represents RHS and LAV’s computing time in ms (i.e., milliseconds). Because RHS authorizes rider independently, CAG’s time cost increases along with the increasing of rider number. On the other hand, LAV’s time cost increases fastly along with the increasing of rider number, which we can get the corroboration from Table 3. Figure 5 depicts the time cost of RHS in the procedure pay for the service. The Y-axis represents RHS’s computing time in ms (i.e., milliseconds). RHS’s time cost increases fastly along with the increasing of receipt number. TPS refers to the number of orders processed per second. In the procedure contract-based authorization, the average consumption time of RHS is about 10 ms and TPS is 100. RHS’s time cost in verifying receipt is about 8 ms and TPS is 125. LAG’s average consumption time in anonymous service and receipt is about 3 ms and TPS is 333. According to Uber’s published travel data for the third quarter of 2021, the number of orders processed per second was 206. The impact of performance is limited. The payment from the rider in the procedure pay for the service and the verification in the procedure verification are implemented by making use of Monero blockchain, which is effective and secure since 2014. Due to the page limits, we omit the corresponding simulation.
6. Conclusion
In this study, we studied the privacy protection and anonymous ride-hailing service for autonomous taxi networks. By taking use of blockchain, we present the security and privacy threats and first proposed blockchain-based anonymous ride-hailing scheme for autonomous taxi network. We give the formal system model and security model. Based on the aggregated signature, ring signature, and Monero, we design the first BBARHS scheme. The analysis and implementation show that our BBARHS scheme is provably secure and practical.
In the future, we will further study the system model and security model for different application scenarios, for example, how to solve the privacy threats in multiperson carpooling.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This research was supported by the National Natural Science Foundation of China (nos: U19A2086 and SKLGP2019Z014).