Abstract

The crowdsourcing-based parking reservation system is a new computing paradigm, where private owners can rent their parking spots out. Security is the main concern for parking reservation systems. However, current schemes cannot provide user privacy protection for drivers and have no key agreement functions, resulting in a lot of security problems. Moreover, current schemes are typically based on the time-consuming bilinear pairing and not suitable for real-time applications. To solve these security and efficiency problems, we present a novel security protocol with user privacy called SCPR. Similar to protocols of this field, SCPR can authenticate drivers involved in the parking reservation system. However, different from other well-known approaches, SCPR uses pseudonyms instead of real identities for providing user privacy protection for drivers and designs a novel pseudonym-based key agreement protocol. Finally, to reduce the time cost, SCPR designs several novel cryptographic algorithms based on the algebraic signature technique. By doing so, SCPR can satisfy a number of security requirements and enjoy high efficiency. Experimental results show SCPR is feasible for real world applications.

1. Introduction

As the amount of cars increases explosively, parking is becoming a precious resource in crowded urban areas such as New York and San Francisco [1]. To fully use parking spots that belong to “private owners (PO),” crowdsourcing-based parking reservation systems have been proposed [2, 3], where private owners can publish rental information to the “Service Provider (SP),” while other “Tenant Drivers (TD)” can download rental information from SP and make a reservation.

User privacy [4] is the basic concern for the above parking reservation system. Due to the openness of the website of SP, it is easy for malicious advertisers to download PO’s private information (e.g., real identities such as user name or driver license) and annoy him by keeping on sending cheating advertisements. Moreover, during the reservation process, a terrorist may even trace the PO or the TD and establish a serious terrorist attack. Therefore, it is important to use pseudonyms instead of users’ real identities in this parking reservation system, so that both cheating advertisements and terrorist attacks can be avoided. However, current crowdsourcing-based security protocols (i.e., [530]) are still based on real identities of PO and TD. So, to provide user privacy protection, it is urgent to develop a pseudonym-based security protocol for crowdsourcing-based parking reservation systems.

On the other hand, time cost is another serious concern for parking reservation systems. Due to the high speed of cars, the parking reservation system is a real-time application [11]. So the PO and the TD are seriously concerned about high time cost arising from running cryptographic operations. Therefore, to reduce time cost, it is desirable to use highly efficient cryptographic operations for designing security protocols for parking reservation systems. Unfortunately, current crowdsourcing-based security protocols are mainly based on the time-consuming bilinear pairing operations [5, 6]. So, to reduce time cost, it is important to develop a security protocol for crowdsourcing-based parking reservation systems without bilinear pairing.

Taking both user privacy and time cost into account, we shall design a pseudonym-based security protocol for crowdsourcing-based parking reservation systems without bilinear pairing. This security protocol should satisfy the following requirements.

(1) User Privacy. It should be guaranteed that real identities of the PO and the TD (e.g., user name or driver license) will not be extracted by an adversary. Without user privacy, the adversary may send cheating advertisements to the PO and the TD and trace them.

(2) Integrity of Rental Information. It should be guaranteed that the rental information will not be tampered by an adversary. Without integrity of rental information, the TD may download wrong rental information, resulting in parking failure.

(3) Authentication. It should be guaranteed that the PO and the TD are authenticated. Without authentication, an adversary may impersonate the TD or the PO, resulting in economic losses of the PO or the TD.

(4) Key Agreement. It should be guaranteed that the PO and the TD can negotiate a shared key for protecting subsequent transactions. Specifically, it should be guaranteed that the shared key will not be tampered or extracted by an adversary. Without key agreement, the subsequent transactions may be compromised by an adversary, resulting in reservation failure.

(5) Time Costs. It should be guaranteed that the time cost between the PO and the TD is low. Time cost is comprised of computation and communication costs. Computation cost is mainly consumed by cryptographic algorithms on the PO and the TD, while communication cost is mainly consumed by message-transmitting processes between the PO and the TD.

Obviously, designing a security protocol for crowdsourcing-based parking reservation systems is a nontrivial task, due to its complicated security and efficiency requirements as discussed above. Currently, requirement (3) has been well addressed in the literature. But, the other requirements (i.e., user privacy, integrity of rental information, key agreement, and time cost) have been largely neglected. More importantly, when considering this research topic, we find that there is no security primitive which can be directly deployed for satisfying all the above requirements. The detailed analysis for drawing this conclusion will be given in Section 2. This becomes a more urgent problem, with the deployment of parking reservation systems in real world. Motivated by this observation, we make three contributions, as described below.(1)We discuss some security and efficiency issues in crowdsourcing-based parking reservation systems and then list a set of important requirements.(2)We present a novel security protocol called SCPR that can fulfill all the above requirements. However, different from current crowdsourcing-based security protocols built on real identities, SCPR is based on pseudonyms. By doing so, the user privacy requirement can be fulfilled. Then, observing that the key agreement requirement is not fulfilled by current security protocols, we design a novel pseudonym-based key agreement protocol that can generate a shared key for protecting subsequent reservation transactions. Finally, observing that bilinear pairing operation is low efficient, we shall use algebraic signature [31] for designing the above security protocol. By doing so, the time cost of SCPR can be significantly reduced.(3)We analyze the security of SCPR, showing it can fulfill requirements (1), (2), (3), and (4). And we evaluate the efficiency of SCPR, showing it can fulfill requirement (5).

The remainder of this paper is organized below. In Section 2, we discuss the related work. Then, in Section 3, we propose the SCPR protocol, followed by security analysis and efficiency evaluation in Sections 4 and 5, respectively. Finally, we draw our conclusions in Section 6.

Due to its convenience, crowdsourcing has become more and more popular. For instance, [5] designed a crowdsourcing-based mobile-healthcare system. The paper [12] is a crowdsourcing-based city governance system. The paper [20] is a crowdsourcing-based system for enterprises. DYSWIS [25] introduced a crowdsourcing-based home network system. The papers [6, 21, 26] combined the cloud computing technique with crowdsourcing-based systems. The paper [27] introduced a location-based crowdsourcing scheme. The papers [18, 22] discussed the deployment of crowdsourcing technique in parking systems.

Security is the main concern for crowdsourcing-based systems. Recently, a lot of works have been focusing on this topic. For instance, [4, 7, 15, 29] analyzed the privacy-preserving and integrity of transmitted data. The paper [14] discussed the establishment of trust relationships in crowdsourcing-based systems. However, there are three issues with current works as shown below.

First, various applications may have different security requirements. For instance, in mobile-healthcare systems [5], privacy of transmitted data (personal health information) is the most important requirement, while in city governance systems [12], access control has vital significance. The security requirements of parking reservation systems are different from those of other crowdsourcing-based systems too, as discussed in Section 1. Therefore, it is desired to classify the security requirements for parking reservation systems.

Second, parking reservation systems have some special security requirements that have not been discussed by current works. For instance, in most of current protocols [5, 12, 20], real identities are used directly. However, for parking reservation systems, this may lead to a variety of security issues as discussed in Section 1. Therefore, it is desired to design a new security protocol for fulfilling those security requirements.

Third, current crowdsourcing-based parking reservation systems [18, 22] mainly focused on the data transmitting model and did not provide security protocols. For instance, [18] discussed the detailed transactions of parking reservation without designing security protocols for protecting the transactions, while [22] discussed several security issues of parking reservation systems without corresponding solutions. Therefore, it is desired to design security protocols for parking reservation systems.

At the same time, time cost is another serious concern for crowdsourcing-based systems [11, 28]. For instance, the crowdsourcing-based parking systems [18, 22] required the parking reservation protocols being executed quickly due to the high speed of cars, while the crowdsourcing-based video systems [9] required the time cost to be low due to the large amount of video data to be processed. However, current security protocols for crowdsourcing systems are mainly built on time-consuming bilinear maps. For instance, in [5, 6], both the TD and the PO have to run the pairing algorithm several times, resulting in high time cost. In Section 5, we will show that the pairing algorithm consumes much more time than other cryptographic algorithms. Therefore, it is desired to design security protocols for parking reservation systems using efficient cryptographic algorithms.

3. SCPR: The Protocol

3.1. Preliminaries

The algebraic signature [31] technique includes two processes.

The Signing Process. Given a set of secret keys , the algebraic signature for a binary string , where , is generated as .

The Verification Process. Given a binary string , where , and the corresponding algebraic signature , the verifier computes and checks to determine whether is tampered by an attacker.

The above algebraic signature employs only several addition and modular multiplication operations. Therefore, it is highly efficient.

3.2. System Model

The system model of SCPR is shown in Figure 1, which includes three phases as illustrated below, and the notations in this paper are listed in Notations.

3.2.1. The Key-Distributing Phase

During the key-distributing phase, the SP first initializes SCPR by generating public and private system parameters. The public system parameters will be distributed to the PO and the TD, while the private system parameters will be hold by the SP. The initialization algorithm is illustrated below.

. This algorithm is run by the SP for initializing system parameters for SCPR. It takes as input the parameter of security level (i.e., ) and outputs a set of private system parameters (i.e., ) and the corresponding set of public system parameters (i.e., ).

Before publishing rental information, the PO sends a request to the SP. Upon receiving the request, the SP generates a pseudonym and a private key and distributes them to the PO over their preestablished secure channel, using the following algorithm.

. This algorithm is run by the SP for generating a pseudonym and a private key for the PO. It takes as inputs PO’s real identity (i.e., ), the set of private system parameters (i.e., ), and the set of public system parameters (i.e., ) and outputs PO’s pseudonym (i.e., ) and a private key (i.e., ).

Before making a parking reservation, the TD sends a request to the SP. Upon receiving the request, the SP generates a pseudonym and a private key and distributes them to the TD over their preestablished secure channel, using the following algorithm.

. This algorithm is run by the SP for generating a pseudonym and a private key for the TD. It takes as inputs TD’s real identity (i.e., ), the set of private system parameters (i.e., ), and the set of public system parameters (i.e., ) and outputs TD’s pseudonym (i.e., ) and a private key (i.e., ).

After the key-distributing phase, the PO holds the tuple , and the TD holds the tuple .

3.2.2. The Publishing Phase

When the PO wants to publish its rental information, it randomly generates a secret key (i.e., ) and signs the rental information using . The signing algorithm is illustrated below.

. This algorithm is run by the SP for signing the rental information (i.e., ). It takes as inputs and the secret key (i.e., ) and outputs a signature (i.e., ) for .

After the publishing phase, the PO holds , and the SP gets the rental information (i.e., ) and the signature (i.e., ).

3.2.3. The Authentication and Key Agreement Phase

The authentication and key agreement phase is carried out between the PO and the TD. During this phase, the TD and the PO authenticate each other and negotiate a shared key for protecting subsequent transactions. Then the PO sends to the TD for checking the integrity of the rental information. The authentication and key agreement phase includes three steps as illustrated below.

Step 1. The TD establishes the authentication and key agreement phase by generating a nonce (i.e., ) and the corresponding signature (i.e., ) using its own private key (i.e., ). Then, the TD sends and to the PO for authentication. The signing algorithm for is illustrated below.
. This algorithm is run by the TD for generating a signature for the nonce. It takes as inputs the nonce (i.e., ), the PO’s pseudonym (i.e., ), the set of public system parameters (i.e., ), and the TD’s private key (i.e., ) and outputs a signature (i.e., ).

Step 2. When receiving and from the TD, the PO checks them to authenticate the TD, using its private key (i.e., ) and the following algorithm. If the verification succeeds, the PO generates the shared key (i.e., ) from using the following algorithm. Finally, the PO signs and encrypts using and the following algorithm and sends the signed and encrypted message to the TD. The , , and algorithms are illustrated below.
. This algorithm is run by the PO for authenticating the TD. It takes as inputs the nonce (i.e., ), the signature (i.e., ), PO’s private key (i.e., ), TD’s pseudonym (i.e., ), and the set of public system parameters (i.e., ) and outputs if the verification succeeds, or otherwise.
. This algorithm is run by the PO for generating the shared key. It takes as inputs the nonce (i.e., ), PO’s private key (i.e., ), TD’s pseudonym (i.e., ), and the set of public system parameters (i.e., ) and outputs the shared key (i.e., ).
. This algorithm is run by the PO for signing and encrypting . It takes as inputs the set of public system parameters (i.e., ), the shared key (i.e., ), and the publishing key (i.e., ) and outputs a signed and encrypted message (i.e., ).

Step 3. Upon getting from the PO, the TD first generates the shared key (i.e., ) using the following algorithm. Then, it decrypts and verifies to extract and to authenticate the PO, using the following algorithm. Finally, the TD verifies and downloaded from the SP to make sure it is not tamped by an adversary, using and the following algorithm. The , , and algorithms are illustrated below.
. This algorithm is run by the TD for generating the shared key. It takes as inputs the nonce (i.e., ), TD’s private key (i.e., ), PO’s pseudonym (i.e., ), and the set of public system parameters (i.e., ) and outputs the shared key (i.e., ).
. This algorithm is run by the TD for decrypting and verifying the publishing key and authenticating PO. It takes as inputs the data to be decrypted and verified (i.e., ), the shared key (i.e., ), and the set of public system parameters (i.e., ) and outputs the publishing key (i.e., ). Then, it outputs if can pass the verification and the PO is authenticated, or otherwise.
. This algorithm is run by the TD for verifying the rental information downloaded from the SP. It takes as inputs the rental information (i.e., ), the signature (i.e., ), the publishing key (i.e., ), and the set of public system parameters (i.e., ) and outputs if can pass the verification, or otherwise.

After the above three phases, the PO and the TD are both authenticated and a shared key (i.e., ) is generated for protecting the subsequent transactions between them.

From this system model, it can be seen that the PO and the TD use pseudonyms instead of their real identities. Therefore, SCPR can satisfy requirement (1) described in Section 1 (i.e., user privacy). In Section 4, we will further analyze requirement (1).

From this system model, it can be seen that the rental information (i.e., ) is signed. Therefore, SCPR can satisfy requirement (2) described in Section 1 (i.e., integrity of rental information). In Section 4, we will further analyze requirement (2).

From this system model, it can be seen that both the PO and the TD are authenticated, and a shared key is generated between them. Therefore, SCPR can satisfy requirements (3) and (4) described in Section 1 (i.e., authentication and key agreement). In Section 4, we will further analyze requirements (3) and (4).

3.3. Construction

The construction of SCPR is a tuple (, , , , , , , , , , and ) of probabilistic polynomial time algorithms as illustrated below.

. The SP runs this algorithm for generating system parameters for SCPR as follows. First, the SP generates a group with a prime order and a generator , where is the security level determining the key length in bit, the length of is -bit, and is a randomly picked element in . Second, the SP randomly generates a set of private keys . Third, for each and , the SP computes and and gets the set of public system parameters .

. The SP runs this algorithm for generating a pseudonym and a private key for the PO as follows. First, the SP generates PO’s pseudonym as , where is a hash function. Second, the SP computes and takes the algebraic signature as the PO’s private key, where is a hash function, and .

. The SP runs this algorithm for generating a pseudonym and a private key for the TD as follows. First, the SP generates TD’s pseudonym as , where is a hash function. Second, the SP computes and takes the algebraic signature as the TD’s private key, where is a hash function, and .

. The PO runs this algorithm for generating a signature for the rental information as , where is a hash function.

. The TD runs this algorithm for generating a signature for the nonce as follows. First, the TD computes , where . Second, the TD computes , where , , and are hash functions.

. The PO runs this algorithm for authenticating the TD as follows. First, the PO computes , where . Second, the PO computes and checks . If this equation holds, PO returns . Otherwise, it returns .

. The PO runs this algorithm for generating the shared key as follows. First, the PO computes , where , is the pseudonym of TD, and are distributed from the SP during the initialization phase. Second, the PO computes .

. The PO runs this algorithm for signing and encrypting as follows. First, the PO encrypts as , where is a hash function. Second, the PO signs as , where and are hash functions. Finally, the PO gets .

. The TD runs this algorithm for generating the shared key as follows. First, the TD computes , where , is the pseudonym of PO, and are distributed from the SP during the initialization phase. Second, the TD computes .

. The TD runs this algorithm for decrypting and verifying the publishing key as follows. First, the TD decrypts as , where is a hash function. Second, the TD computes and checks , where and are hash functions. If , the TD returns . Otherwise, it returns .

. The TD runs this algorithm for verifying the rental information as follows. First, the TD computes , where is a hash function. Second, the TD checks . If this equation holds, TD returns . Otherwise, it returns .

From this construction, it can be seen that SCPR does not use bilinear map. In fact, it employs only a few modular exponentiations, which is quite efficient. We will further evaluate the efficiency of SCPR in Section 5. Note that, when computing and , there is no modular exponentiation, because and . So our construction is highly efficient.

4. Security Analysis

In this section, we show that SCPR can fulfill the security requirements described in Section 1 (i.e., user privacy, key agreement, integrity of rental information, and authentication).

4.1. User Privacy

In SCPR, as the PO and the TD use pseudonyms generated from their real identities such as user name or driver license, this requirement is to ensure that the adversary cannot extract real identities from pseudonyms. From Section 3.3, it can be seen that the SP generates pseudonyms using a one-way hash function (see equations and in the and algorithms for details). So it is straightforward that the adversary cannot extract and from and , and SCPR can provide user privacy protection for the PO and the TD.

4.2. Key Agreement

In Section 3.3, the PO generates as , and the TD generates as (see the and algorithms in Section 3.3 for details.). So if the PO and the TD run SCPR correctly, they both can get .

Then, we show that a potential adversary cannot extract in three steps. In Step  1, we describe a well-known mathematical problem that will not be efficiently solved. In Step  2, we describe the adversary. In Step  3, we show this potential adversary will not be able to extract efficiently. Otherwise, we will be able to use this adversary for solving the mathematical problem. So if this mathematical problem holds, the potential adversary does not exist. Our proof is described below.

Step 1 (the -CDH problem [32]). Given , where and are randomly distributed unknown numbers, there is no -time algorithm, which has the nonnegligible probability in computing .

Step 2 (the adversary). In the parking reservation system, the potential adversary is between the PO and the TD. It can compute public keys of the PO and the TD from pseudonyms: and , where and . Moreover, the adversary can get .

Step 3 (the proof). If this adversary can compute from , , and with the probability in time , we can run this potential adversary with the set of parameters to get . That is to say, we can use this potential adversary for solving the CDH problem [32] in time with the probability . As the CDH problem holds, this adversary does not exist. So the adversary cannot extract in SCPR.

Finally, we show that a potential adversary cannot tamper . Since is generated from , , and , to tamper , the adversary has to tamper the pseudonyms or the nonce. The detailed proof can be illustrated in three steps too. Here, we just give a summarized example: If the adversary can tamper to while still passing the algorithm, it must be able to compute the signature . Then, to compute , the adversary must be able to compute . As discussed above, since the adversary cannot compute from and , it cannot tamper to .

4.3. Integrity of Rental Information

In SCPR, as the rental information is signed using the symmetric key , this requirement is to ensure that the adversary cannot tamper transmitted in the authentication and key agreement phase. Moreover, from the and algorithms illustrated in Section 3.3, we can see that is signed and encrypted using the negotiated shared key . So the integrity of rental information is to ensure that is secure. Since is secure as discussed in Section 4.2, SCPR can provide integrity protection for rental information.

4.4. Authentication

In SCPR, as the PO and the TD communicate with each other using pseudonyms, authentication is to make sure that the pseudonyms are generated by the SP. Moreover, as and are algebraic signatures of pseudonyms (see the equations , , and in the and algorithms illustrated in Section 3.3 for details.), authentication is to prove that the PO and the TD really hold and , respectively.

The proof of authentication is similar to that in Section 4.2, as illustrated by the following example. In the and algorithms, only when the PO and the TD hold the algebraic signatures (i.e., and ), they can compute . Therefore, the authentication can be reduced to the CDH problem too.

5. Efficiency Evaluation

There are many crowdsourcing-based systems (i.e., [530]). But, only [5, 6] aimed to design complete cryptographic algorithms and protocols [4], while other systems mainly focused on deploying crowdsourcing-based systems in multiple real world applications. So, in this section, we mainly compare SCPR with [5, 6].

Time cost is the major efficiency issue for parking reservation systems, which is comprised of computation and communication costs as discussed in Section 1. So we will first compare the computation cost of SCPR with those of [5, 6] in Section 5.1. Then, we shall compare the communication costs in Section 5.2. Finally, in Section 5.3, we will show the implementation of SCPR to make sure the newly designed protocol works well.

5.1. Comparison of Computation Costs

Computation cost is the major measure of time cost, which is mainly consumed by cryptographic algorithms. So we first tested computation costs of basic cryptographic algorithms. Then, we computed the computation costs of SCPR [5, 6].

To investigate the computation costs of basic cryptographic algorithms, we conducted the experiment on a computer with a CENTOS operating system and an Intel i7 processor. Cryptographic libraries used in this experiment include OPENSSL [33] and PBC [34]. Cryptographic group (i.e., in Section 3) used in this experiment is the 160-bit elliptic curve [33]. Finally, we used the SHA1 hash function [33] and type F bilinear pairing parameter [34] in this experiment.

Table 1 lists the computation costs of basic cryptographic algorithms, in which the values are means of running basic cryptographic algorithms for 10,000 times. From Table 1, we can see the following.

The computation costs of modular multiplication and hash function are much lower than those of modular exponentiation and bilinear pairing and can be omitted. This is because , , and . Therefore, in the following evaluation, we only take modular exponentiation and bilinear pairing into account.

The computation cost of modular exponentiation is much lower than that of bilinear pairing. This is because . Therefore, by avoiding using bilinear pairing, SCPR can reduce the computation cost significantly.

Then, from Table 1, we computed the total computation costs of SCPR [5, 6]. The results are shown in Table 2 and Figure 2, where the values are total computation costs of modular exponentiation and bilinear pairing executed during the publishing phase and the authentication and key agreement phase. From Table 2 and Figure 2, we can see the following.

On the PO’s side, the computation costs of [5, 6] are around to that of SCPR. This is because and .

On the TD’s side, the computation costs of [5, 6] are around to that of SCPR. This is because and .

The total computation costs of [5, 6] are around to that of SCPR. This is because and .

On the TD’s side, the computation cost of [6] will increase rapidly, when the number of attributes increases, as shown in Figure 2.

These three conclusions show that the computation cost of SCPR is much lower than those of [5, 6]. So SCPR can fulfill requirement listed in Section 1.

5.2. Comparison of Communication Costs

During the publishing phase, the number of messages is one in SCPR [5, 6]. During the authentication and key agreement phase, both SCPR and [6] contain two messages, while [5] contains four messages. That is to say, SCPR and [6] contain fewer messages than [5]. So SCPR can fulfill requirement listed in Section 1.

5.3. Implementation of SCPR

To make sure SCPR can work well, we implemented it. In the experiment, we use three computers, acting as the SP, the PO, and the TD, respectively. These three computers communicate with each other using Ethernet. All the three computers have Intel i7 CPUs and are installed with CENTOS operating system. The cryptographic libraries used in the experiment are OPENSSL and PBC [33, 34] with the same parameters as those in Section 5.1. The Language used in our experiment is C, and the protocol for transmitting SCPR messages is TCP. Then, we get the total executing time of SCPR . This is similar to the value computed in Table 2. Therefore, time cost is mainly consumed by cryptographic algorithms, and SCPR is feasible for real world applications.

6. Conclusion

In this paper, we have presented a security protocol for crowdsourcing-based parking reservation systems called SCPR. It can satisfy many security requirements that have not been addressed by current protocols, such as user privacy and key agreement. More importantly, to reduce the time cost, we designed several novel cryptographic algorithms for SCPR, which are quite light weight. Experimental results show SCPR is feasible for real world applications.

However, there are several more problems remaining to be solved. First, after the transaction is ended, the tenant driver and the private owner should be able to score the transaction. By doing so, the parking reservation system can provide differential services to users based on their reputation. Second, SCPR lacks a revocation method. These open issues are to be addressed in the future.

Notations

Real identities of the PO and the TD, respectively
Pseudonyms of the PO and the TD, respectively
Public and private system parameters of SCPR
Private keys of the PO and the TD, respectively
Rental information and its signature
Secret key for signing and verifying
Nonce and its signature
The shared key negotiated between the PO and the TD
The signed and encrypted data for
The cyclic group, its generator, and prime order
Hash functions.

Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this paper.

Acknowledgments

This paper is supported by the NSFC (nos. 61101088 and 71402070), the NSF of Jiangsu province (no. BK20161099), and the Opening Project of Key Lab of Information Network Security of Ministry of Public Security (no. C16604).