Abstract

The database-driven cognitive radio networks (CRNs) are regarded as a promising approach to utilizing limited spectrum resources in large-scale Internet of Things (IoT). However, database-driven CRNs face some security and privacy threats. Firstly, secondary users (SUs) should send identity and location information to the database (DB) to obtain a list of available channels, such that the curious DB might easily misuse and threaten the privacy of SUs. Secondly, malicious SUs might send fake location information to the DB in order to occupy channels with better quantity in advance and so gain benefits. This might also cause serious interference to primary users (PUs). In this paper, we propose a lightweight privacy-preserving location verification protocol to protect the identity and location privacy of each SU and to verify the location of SUs. In the proposed protocol, the SU does not need to provide location information to request an available channel from the DB. Therefore, the DB cannot get the location information of any SU. In the proposed protocol, the base station (BS) selects some SUs as witnesses to generate location proofs for each other in a distributed fashion. This new witness selection mechanism makes the proposed protocol reliable when a malicious SU generates fake location information to cheat the BS and also prevents SU-Witness collusion attacks. The results also show that the proposed protocol can provide strong privacy preservation for SUs and can effectively verify the location of the SUs. The security analysis shows that the proposed protocol can resist various types of attacks. Moreover, compared with previous protocols, the proposed protocol is lightweight because it relies on symmetric cryptography and it is unaffected by the area covered by the DB.

1. Introduction

The explosive growth of wireless devices and services has exacerbated the spectrum scarcity problem in large-scale Internet of Things (IoT) [1]. Database-driven CRNs are regarded as a promising approach that allows the dynamic spectrum sharing in many large-scale IoT applications [2]. In cognitive radio networks (CRNs), primary users (PUs) have exclusive privilege to access the licensed channels, while secondary users (SUs) are allowed to access the licensed channels when the PUs are off-line or at a lower power without causing interference to the PUs. Through spectrum sharing between PUs and SUs, CRNs can effectively improve the spectrum utilization and alleviate the spectrum scarcity crisis.

CRNs have many potential applications including IoT [3], smart cities [4], and vehicular networks [5]. For example, a large number of connected devices will create a major challenge in terms of spectrum scarcity in large-scale IoT. Through dynamic spectrum access capabilities, large-scale IoT not only improves spectrum utilization but also exploits alternate spectrum opportunities. In addition, cognitive IoT is inherently equipped to address the challenges of interference management, energy efficiency, and device heterogeneity.

In CRNs, two main approaches can be used by SUs to obtain channel availability information [6]: the spectrum sensing approach and the geolocation database-driven approach. In the sensing approach [7], several SUs cooperatively sense the idle channels and report these channels to the fusion center; the latter will then decide whether a channel is available prior to its use so as to avoid interfering with PUs. In the database-driven approach [7, 8], the database (DB) that is administered by some commercial entities (e.g., Microsoft, Google Inc., and Cellular South) stores the spectrum available information (SAI). SUs are required to send their locations to the DB in order to obtain channel availability information. After receiving a query, the DB returns a list of available channels and some transmission parameters to the SU at its location.

In 2012, database-driven CRNs were specified as the primary approach by the Federal Communications Commission (FCC) [8] because the geolocation database-driven approach has more advantages, especially in large-scale CRNs. On the one hand, it pushes the responsibility and complexity spectrum policies conformity from SUs to DBs. On the other hand, it only updates a handful of DB when policy changes, instead of updating large number of devices [9]. However, SUs have to send location information to the DB to obtain the list of available channels. Through this location information, the DB might reveal SUs’ critical information such as habits, shopping preferences, behavior, and commuter routes [10]. Therefore, it is urgent to protect the location privacy of the SU during the spectrum query in CRNs. Some protocols based on private information retrieval (PIR) [11, 12] or k-anonymity [13, 14] have been proposed to protect the location privacy of SUs. However, these protocols might cause high computation or communication overheads or cannot provide enough safeguards for location privacy of SUs.

On the other hand, malicious SUs may falsify their locations when querying the DB for the list of available channels [15]. Because there is no location proof and verification when SUs query channels in database-driven CRNs, a malicious SU might send fake location information to the DB in order to occupy channels with better quantity in advance and gain benefits. Besides, if a malicious SU chooses channels that are not in his/her real location, it may cause interference to PUs. Only a few protocols based on private information retrieval [16] or cryptography [2] focus on the location verification: most existing protocols achieve location verification by employing a large number of access points (APs) to be witnesses. It might be too expensive and be inapplicable in some scenarios where no fixed wireless infrastructures are accessible [17]. Moreover, these protocols do not consider collusion between SUs and witnesses.

Noting all these concerns, we propose a lightweight privacy-preserving location verification protocol (LPPLV) for large-scale database-driven CRNs. The proposed protocol aims to guarantee the privacy of SUs to avoid inference by PUs during spectrum queries in database-driven CRNs. To prevent malicious SUs from reporting fake location information, SUs are required to provide location proofs for the DB indicating that they are at the places where they claim to be.

The contributions of this paper are summarized as follows.(1)We propose a secure and privacy-aware protocol that can protect the identity and location privacy of SUs. In our protocol, the DB has no knowledge about the location information of SUs, and this can prevent the DB from obtaining the real identity and location information of SUs.(2)Our proposed protocol has a distributed architecture in which SUs generate location proofs for each other instead of employing expensive APs to provide the location proof for SUs in existing protocols. The new witness selection mechanism allows malicious SUs to be discovered by the BS when malicious SUs generate fake location information. Our new witness selection mechanism also reduces the possibility of SU-Witness collusion.(3)Security analysis is presented to prove that our protocol resists various types of attacks in database-driven CRNs, such as replaying attack, Man-in-the-Middle attack, and eavesdropping attack.(4)Channel allocation is implemented locally in our protocol, and we use the symmetric encryption operation in the communication of database-driven CRNs. Therefore, our protocol improves the efficiency of obtaining available channels for SUs. Experiments’ results indicate the efficiency of our privacy-preserving location proof protocol.

The rest of this paper is organized as follows. We first discuss related work in Section 2. Section 3 presents the preliminaries. Then we introduce our proposed protocol in Section 4, which is followed by security and privacy analysis in Section 5. Section 6 analyzes the performance of the proposed protocol. Finally, Section 7 concludes the paper.

Most of the existing protocols that are related to this work focus on privacy preservation of SUs while some protocols focus on location verification of SUs. In this section, we give a brief overview of these protocols.

2.1. Privacy Preservation Protocols

PIR [18], k-anonymity [19], and cuckoo filter [11] are three techniques that can be used to protect the privacy of SUs. Gao et al. [20] proposed a PIR-based protocol, in which SUs can obtain available spectrum information from the DB without sending geographic location information. They also pointed out that if the SUs switch channels frequently, the DB can locate the SUs according to the channel requesting messages, which can cause user privacy leakage. Troja et al. [12] proposed another PIR-based protocol that allows SUs to share information in a peer-to-peer manner. PIR technology can protect the privacy of SUs’ locations well, but it also causes high communication and computational overheads. Grissa et al. [21] proposed a cuckoo filter-based protocol: the DB uses a cuckoo filter to compress the spectrum information and send it to the query server. The SUs then obtain the available channels through the query server. However, in this protocol, SUs query efficiency and spectrum accuracy are affected by cuckoo filters false positive and negative rates. Petrov et al. [13] proposed a privacy protection protocol based on k-anonymity. In this protocol, SUs select k-1 volunteers to form a link forwarding query message, so that the DB cannot distinguish the true identity of the user who sent the query, achieving the purpose of privacy protection. However, this method creates high communication overheads, and when the number of volunteers is too small, SUs can easily expose their true identities and cannot achieve good privacy protection.

2.2. Location Verification Protocols

Another focus of this paper is the problem of location verification of SUs in database-driven CRNs. Numerous protocols have been proposed to achieve the location verification [17, 2225]. SUs need to provide location proofs before obtaining the available channel in order to secure the communication in database-driven CRNs. Xin et al. [16] provide a PIR-based protocol for the server to verify whether the query SU is located where it claims to be. It uses WiFi access points (APs) to provide location proofs. In particular, if an AP can communicate directly with an SU, it considers this SU to be at the same location as itself. Then it generates a signature as the location proof for this SU. Li et al. [2] proposed a protocol based on the public key cryptographic algorithm. That protocol also relies on APs to provide location proofs. The two protocols have high computation and communication overheads. Moreover, it might be too expensive and is inapplicable to some scenarios in which no fixed wireless infrastructure is accessible.

In our previous work, we mainly focus on the privacy preservation and authentication of SUs. Zeng et al. [9, 26], respectively, utilize elliptic curve cryptography (ECC) and modular square root techniques to achieve privacy preservation and authentication of SUs in database-driven CRN. However, we did not take into account the problem of location verification of SUs.

From the above discussion, we can see that these protocols either incur high communication and computation overheads or rely on existing WiFi AP networks for reporting location-based activity summaries, which means that these existing protocols cannot provide a satisfactory privacy preservation and location proof protocol for SUs in database-driven CRNs.

3. Preliminaries

3.1. System Model

Our network model is shown in Figure 1, which involves four types of entities: the database (DB), multiple based stations (BSs), numerous secondary users (SUs), and the trust authority (TA). Their functions and interactions are described as follows.

DB. The DB is an entity which stores the spectrum available information and makes this information available to SUs.

BSs. In our network model, BSs provide location verification and channel allocation in our system. Each BS requests some channels from the DB. If an SU wants to obtain available channels, it should send a request including its location information to the BS. The BS first verifies its location proof, i.e., this SU is where it claims to be. Then, the BS calculates and allocates a channel based on the SU’s location.

SUs. The SUs are those who do not have a licensed spectrum in CRNs. There are three types of SUs: one who wants to obtain an available channel, one who is selected to be a witness to provide location proofs for the SU, and one who is nonselected to be witness. Multiple SUs will be selected as witnesses after an SU sends a request to the BS. Meanwhile, that SU does not want to disclose its location. Besides, SUs and witnesses send their messages to each other through their predefined short-range communication interfaces (e.g., Bluetooth and WiFi).

TA. The TA can be served by federal technical centers (e.g., FCC and NTIA). In this paper, each BS and SU are required to be registered in the TA. The TA stores the reputation of each SU and updates it for a period of time.

A typical process of our protocol can be described as follows. BSs first obtain the list of available channels from the DB. An SU should ask the BS to obtain a channel with its current location. Then the BS chooses some SUs who are using the channels and are near the SU as witnesses. After obtaining the location proofs for the SU from witnesses, the BS verifies the location proof. If it is valid, the BS chooses a channel and returns the channel to the SU.

3.2. Security and Privacy Requirements

The TA in our system is a fully trusted entity which has the knowledge of the mappings between the pseudo-ID and the real identity of each SU. We also assume that BSs are supposed to be trusted entities. Neither the TA nor the BS publishes SUs’ identity and data. However, the DB is honest but curious, which means the DB will honestly execute the protocol but is very curious about the identity and location information of the SUs. Hence, our first goal is to prevent the DB from obtaining any SU’s identity and location information. Meanwhile, malicious SU might provide witnesses with fake information about his/her location or change contents of a location proof generated for him/her or another SU. They might also collude with witnesses to cheat the BS and obtain the available channels. It is also assumed that both the DB and BSs will not modify the communication data between them and legitimate SUs. No entity ever shares its private keys with another.

An efficient privacy-preserving location verification protocol for the large-scale database-driven CRNs should have the following desirable properties.

Privacy preservation: The privacy we want to preserve is the identity and location information of SUs. That is, except the TA, other entities including the DB, the BSs, and other SUs will never get the knowledge of the SU’s real identity. On the other hand, our protocol should prevent the DB from obtaining the location information from the channel query of the SUs, even if the DB colludes with all BSs and other SUs.

Location verification: Malicious SUs might send fake location information to the DB and obtain the channels that are not available in their real locations, so as to infer operational patterns of PUs and other SUs. Therefore, the proposed protocol should verify the SUs’ current locations and prevent the SUs from obtaining any available channels at other locations.

Attack resistance: There are various types of attacks in CRNs, such as replaying attack, Man-in-the-Middle attack, and eavesdropping attack. The security of our protocol will not be compromised under these attacks.

SU-Witness collusion: Malicious SU might collude with malicious witnesses by creating a location proof for him/her even though the SU is not at the location claimed, in order to deceive the BS and the DB. We call this collusion SU-Witness collusion. To the best of our knowledge, there is no protocol to consider SU-Witness collusion in CRNs.

4. The Proposed Protocol

In this section we describe the details of the proposed protocol. It consists of seven phases: system initialization, channel preallocation, channel query, location proof generation, location verification, channel allocation, and reputation update. Notations used in the protocol are defined in Table 1.

4.1. System Initialization Phase

We assume that a network is composed of BSs and SUs. Each BS and SU send their real identities to the TA in a secure channel for registration.

For each whose real identity is , the TA generates the secret key and public key . The TA also generates a unique session key between the DB and the . Then TA sends and to in a secure channel and publishes . The TA sends to the DB. Upon receiving and , stores these keys securely.

For each whose real identity is , the TA chooses distinct pseudo-IDs (PIDs) and sends them to . The TA initializes the reputation value . Upon receiving PIDs, stores the PIDs securely and uses one PID for each request. After all PIDs are allocated, asks for another PIDs from the TA.

At the outset of a new system, there are not enough SUs in the network that can be selected as witnesses. At this time, the BS presets some trusted fixed devices (e.g., the roadside units and cellular tower) distributed in its coverage area. However, it might be too expensive to employ the trusted fixed devices all the time. We will reduce the employed fixed devices when the number of SUs in the network increases to a more practical number.

4.2. Channel Preallocation Phase

After registration, sends a request to the DB for enabling channel preallocation. This phase includes the following steps.

sends the following message to the DB for enabling channel preallocation.where , is the location of , and is message authentication code of using the key .

After receiving the message from , the DB decrypts the message with the key that matches and checks whether is a valid time stamp. Then the DB computes and verifies that it is the same as received through . If one or both of the verifications do not hold, the DB drops this message. Otherwise, is authenticated by the DB. The DB chooses a channel list based on and sends the message to the using a secure channel.where .

Upon receiving the message from the DB, checks whether the is its identity. Then uses its secret key to decrypt the message and verifies . If these verifications do not hold, drops this message. Otherwise, obtains the channel list . Then the stores the channel list securely.

4.3. Channel Query Phase

Before an SU accesses the channel, the SU sends a request to the BS and informs the BS that he/she wants to get the location verification. This phase includes the following steps.

randomly selects a from , generates a unique session key between himself/herself and the , and sends a location verification request to .where .

Upon receiving the message from , uses its secret key to decrypt the message . BS first checks whether the location of has the available channels. If not, responds with the following message to reject the request. Otherwise, executes the location proof generation steps described in Section 4.4.where .

4.4. Location Proof Generation Phase

Since each SU has to request location verification and available channels from , stores PIDs, locations of the SUs who have requested the channels, and the unique session keys between these SUs and . is the key generated by these SUs in their channel query phase, which is similar to . This phase includes the following steps.

Upon receiving the message , searches for SUs who are using the channel and are near . Then, sends a list of the PIDs of these SUs and to the TA. After receiving the list and from , the TA first searches for the real identity of and verifies whether has registered with it. Then the TA responds with the reputation values of these SUs to according to the PIDs. If has not registered in the TA, the TA rejects .

We assume is the threshold of reputation value. If , that means has a high probability of being dishonest. sorts SUs according to their reputation values and checks the top SUs’ reputation values. We assume is the threshold number of location proofs that will receive. If the number of dishonest SUs is more than threshold , will remove some SUs who have lower reputation values. then chooses some preset trusted fixed devices as a supplement to ensure that the number of dishonest selected witnesses is less than . At the beginning of the system, there are not enough SUs in the network that can be selected as witnesses. At this time, selects some preset trusted fixed devices as witnesses.

After selecting witnesses, generates a unique index () for this location proof, numbers selected witnesses to , and generates the session keys for his/her communication process. Then sends the following message to and sends the message to each witness.where and . generates a table for this location proof and verification, as shown in Table 2.

After receiving the message , a selected witness generates a random number and broadcasts the following message through its predefined short-range communication interface for a period of time .where . Another is generated and broadcast in a similar way. This process is repeated until the witness receives a response from .

first ensures that the is the same as the one already received from the BS when the SU receives the message . Then, checks whether is fresh and verifies . If these verifications are not sustained, drops this message and waits for the next message. Otherwise, decrypts the message with the key that matches , and verifies whether or not the message has been tampered with. If the message cannot be decrypted by the corresponding key, discards this message. If all the verifications are successful, must immediately send message to :where .

Upon receiving , first checks whether in is the same as the in . Then, verifies and checks whether in is the last random number that had been broadcast by itself. If so, generates the following location proof and sends it to .where . Otherwise, the following is sent to :where .

4.5. Location Verification Phase

For each that has been received before the time threshold, checks as follows.

Checking whether is the unique for this location proof, and finding out in the message according to .

Checking whether the time stamp is fresh.

According to , trying to find the unique session key , and using to decrypt . Then, checks whether is the selected witness.

Computing and verifying it is the same as received through .

(5) Verifying whether is in an acceptable range of .

Computing and verifying it is the same as received through .

Checking whether the number of is greater than a predefined threshold .

If all the above checks are successful, accepts , which means that is legitimate. Otherwise, ’s request is rejected.

4.6. Channel Allocation Phase

If the above location verification is successful, which means is where he/she claims to be, chooses a channel from the channel list, which is preallocated from the DB. One crucial step for an SU to protect location privacy and to get a better service quality, is to choose the most stable channel. The available channels in the channel list can be divided into four cases and are analyzed below.

All PUs operating on these channels are on-line but close to . The BS should choose the channel with the higher power for the SU, so that the SU can obtain the best quality of service.

Some PUs in this case might be off-line. chooses the channel with the highest power, but not the maximum power, and long usage time for . Although in this case, can obtain the channels where the PUs are off-line and get the best service quality, once the PU goes on-line, the DB will force to go off-line and switch channels. Therefore, may be caught in frequent channel switching.

All PUs operating on these channels are on-line but far away from . This kind of channel is preferred to be used, so chooses this channel for . When accesses such channel, can work at the maximum power regardless of whether the PU is on-line or off-line, so that can use the channel with the best quality of service and avoid the privacy leaking that can be caused by channel switching.

Some PUs might be off-line while other PUs are on-line but might be far away from . should choose the channel with the highest (but not the maximum) power and long usage time for , ensuring that can get the best quality channel.

As analyzed above, the power and the channel usage time are determined by the channel quality of service. should choose the channel with the best quality of service for according to the power and the channel usage time. After choosing the best channel, sends the message to .where . When multiple SUs need the same channel at the same time, the BS preferentially allocates this channel to the SU with a high reputation value.

When plans to go off-line, sends the message to .where . After receiving the message , the BS reports to the TA, and the TA deletes that has used.

4.7. Reputation Update Phase

As each SU sends his/her real identity to the TA for registration, the TA stores the mappings between the pseudo-IDs and the real identity of each SU. After receiving messages from each BS, the TA constructs a table to record the location verification results of each SU, as shown in Table 3. In Table 3, indicates whether accepts ; 0/1 means rejects/accepts . In addition, indicates whether provides an effective location proof as a selected witness; 0/1 means has provided an effective/invalid location proof as a selected witness.

From this table, the TA can trace each SU and check the honesty of each SU, for instance, whether an SU is honest in claiming his/her location or has provided effective location proof for the surrounding SUs as witness.

After tracing each SU, the TA updates the reputation value of in Table 4 aswhere means ’s value that is equal to 1 and means ’s value that is equal to 1 in Table 3. And is the sum of the numbers of and , and is the sum of the numbers of and . There are three cases.

: has honestly claimed his/her location or has provided the effective location proof for the surrounding SUs as witness.

: has been rejected by the BS or has not provided the effective location proof for the surrounding SUs as a witness.

: During this update period, has not sent the channel request to the BS or has not been selected as a witness.

5. Security Analysis

In this section, we analyze the security of the proposed protocol with respect to the security requirements given in Section 3.2.

Privacy preservation: In our protocol, the SUs obtain pseudo-IDs in the system initialization phase. The SUs use these pseudo-IDs instead of real identities at the channel query phase. Except for the TA, anyone (including the DB, the BSs, and other SUs) cannot obtain the SUs’ real identities. However, in our protocol, the SUs do not provide their location information for the DB for a channel request, so that the DB has no knowledge about the location information of SUs. Further, since there are only pseudo-IDs stored in each BS, the BS can only obtain the current location of SUs. The pseudo-IDs will change at the next channel request. Therefore, the BS cannot obtain the trajectory of SUs. Even if all BSs have been attacked, the attacker cannot map between the real identity and the location information of SUs. That is, our protocol can prevent anyone from discovering the real identity and location information of SUs.

Location verification: Each SU who wants to obtain the available channels must be verified by the BS. The BS selects some surrounding SUs to be the witnesses to verify the SU’s location. The location proofs generated by the witness are unforgeable. We consider several scenarios. If a malicious SU wants to generate a location proof by himself, the BS will detect this: the BS receives location proofs from selected witnesses. The BS checks the received and decrypts the by the unique session key . Since any entity does not share his/her private key, this SU cannot generate a even if he knows the identity of each selected witness. Malicious SUs who try to send fake location information to the BS or to generate a location proof by himself will be rejected by BS.

Attack resistance: Since all messages have been encrypted and protected by secret keys, even though an attacker can capture all messages transmitted between each entity, it cannot acquire the content of messages. We use a message authentication code to prevent messages from being tampered with by attackers. Anyone who wants to change the information in these messages will first need to be verified, and fake messages will be removed. Meanwhile, we use time stamps to prevent the attack from being replayed, so such an attack is infeasible in our protocol.

Resistance to SU-Witness collusion: At the location verification phase, the BS checks all and rejects any which is not generated by selected witnesses. Thus, a malicious SU cannot generate a for himself or any other users. This makes it very difficult for a malicious SU to set up successful SU-Witness collusion. Each selected witness has a high reputation value, which means they have a high probability of being an honest SU and will not collude with a malicious SU. Reputation values motivate them to generate efficient since reputation values will affect the service quality of the channel they receive from the BS. However, we cannot altogether exclude the possibility of SU-Witness collusion. Any malicious SU needs to increase the size of his/her collusion group to improve his/her chances of success. In other words, the number of non-null should be greater than a predefined threshold . It means unless an SU colludes with at least selected witnesses, it cannot succeed. However, in our protocol the BS selects witnesses: this selection mechanism ensures that the number of dishonest witnesses is less than . Therefore, the possibility of SU-Witness collusion is minuscule in the proposed protocol.

Comparison with other protocols: We compare the security of the proposed protocol with protocols discussed in Section 2. We also give an overview of the related literature and summarize the comparison between these protocols and our protocol in Table 5. Table 5 shows that our protocol is more secure than other protocols.

6. Performance Evaluation

In this section, we evaluate the performance of our proposed protocol, by showing its computation and communication costs, and compare them with the protocols proposed by Grissa et al. [21] and Gao et al. [20]. All experiments have been conducted on a 64-bit computer with an Intel Core i7 CPU of 2.5 GHz and 16G memory. At the channel preallocation phase, a BS encrypted with AES with 256-bit key size (AES-256) and the TA also encrypts with AEC-256. At the channel query phase, the channel request message from an SU to a BS is also encrypted with ECC-256. In other phases, the messages transmitted between a BS and an SU, an SU and witnesses, and witnesses and a BS are encrypted with AES with 256-bit key size.

It is assumed that the network is divided into cells; the output of hash function is 160 bits; ,, , , and channel list are 32 bits, respectively; a random number is 128 bits; and , , and are 40 bits, respectively. Further, let , and denote the running time for one ECC-256 encryption operation, one ECC-256 decryption operation, one AES-256 encryption operation, one AES-256 decryption operation, one hash function operation (SHA1 on 512-bit block), and one message authentication code operation (SHA1 on 512-bit block), respectively. The running time of , and is , , , , , and , respectively.

6.1. The Performance Analysis of Our Protocol

In this subsection, we analyze the computation and communication cost of channel preallocation phase (CPAP), channel query phase (CQP), location proof generation phase (LPGP), location verification phase (LVP), and channel allocation phase (CAP) in our protocol in Table 6.

6.1.1. Computation Cost

We analyze the computation cost of each phase.

(1) CPAP: At the channel preallocation phase, each BS encrypts and sends to the DB. Each BS executes one AES encryption operation and one message authentication code operation. To allocate the channel list to the BS, the DB needs to execute one AES encryption operation to encrypt . After receiving , each BS also needs to execute one AES decryption operation to decrypt and obtains the channel list. In this phase, the computation cost of the BS is and the computation cost of the DB is .

(2) CQP: At the channel query phase, the computation cost of the SU is one elliptic curve encryption operation and one message authentication code operation, which is . The computation cost of the BS is one elliptic curve decryption operation and one message authentication code operation, which is .

(3) LPGP: At the location proof generation phase, the computation cost of each BS is AES encryption operations and message authentication code operations, which is . The computation cost of each SU consists of AES encryption operations, AES decryption operations, message authentication code operations, and hash function operations, which is ( denotes the number of selected witnesses). Similarly, the computation cost of witnesses consists of AES encryption operations ( denotes the number of broadcasted rounds), AES decryption operations, and message authentication code operations, which is .

(4) LVP and CAP: In the location verification phase and the channel allocation phase, the computation cost of each BS is AES decryption operations, message authentication code operations, hash function operations, and one AES encryption operation, which is . The SU needs one AES decryption operation and one message authentication code operation, which is .

6.1.2. Communication Cost

We analyze the communication cost of each phase.

(1) CPAP: At the channel preallocation phase, each BS sends the message to the DB, and the DB chooses a channel list and sends the message to the BS. Hence, the communication cost of the BS is , and the communication cost of the DB is .

(2) CQP: At the channel query phase, each SU sends the channel request message to the BS. Therefore, the communication cost is .

(3) LPGP: At the location proof generation phase, the TA responds to the reputation value of the SUs surrounding the SU, so that the communication cost is . The BS sends the reputation value request message to the TA, to the SU, and to each witness, respectively. The communication cost of the BS is . The SU responds to the message to each witness, so that the communication cost is . Each witness broadcasts rounds of the message and sends to the BS, respectively. Hence, the communication cost of witnesses is .

(4) LVP and CAP: At the location verification phase and the channel allocation phase, the BS chooses a channel and sends the message to the SU, so that the communication cost is .

Moreover, the computation and communication cost of the different number of witnesses is shown in Figure 2 using the expressions established in Table 6, wherein is set to be 20 and is set to be 10. In order to show our communication and computational costs clearly, we use a logarithmic way of drawing. As shown in Figure 2(a), when the number of witnesses is 3, the running time of the BS and that of the DB at the channel preallocation phase are less than 1 ; the running time of an SU obtaining the location proof at the location proof generation phase is less than 0.4 , and the running time of a BS to verify the location and to allocate a channel to an SU at the location verification and channel allocation phases is less than 0.05 . Even though the number of witnesses is 12, the running time of an SU obtaining the location proof at the location proof generation phase and obtaining a channel in location verification phase and channel allocation phase is less than 1.4 . As shown in Figure 2(b), when the number of witnesses is 3, the communication cost of the BS and that of the DB in channel preallocation phase are about 77 , and the communication cost of an SU obtaining the location proof at the location proof generation phase is about 228 ; the communication cost of a BS to verify the location and to allocate a channel to an SU at the location verification and channel allocation phases is about 8 . Although the number of witnesses is 12, the communication cost of an SU obtaining the location proof in that and the subsequent phases and obtaining a channel is about 912 .

6.2. Comparison with Other Protocols

In this subsection, we compare the performance of the proposed protocol with other protocols proposed by Gao et al. [20] and Grissa et al. [21], and we provide analytical expressions of the communication of these protocols in Table 7 and computation cost of these protocols in Table 8. We plot the comparison of computation and communication costs of these protocols in Figure 3 using the expressions established in Tables 7 and 8. Figure 3(a) shows that our protocol is superior to the protocols proposed by both Gao et al. [20] and Grissa et al. [21] in communication costs, because we used symmetric encryption operations in our protocol, while Figure 3(b) shows the comparison of the computation cost of these protocols. As shown in Figure 3(b), when the number of cells increases, our computation cost remains 1.4 ms, which proves our protocol is lightweight in computation cost and unaffected by of the number of cells.

In summary, Figure 3 shows the performance of our protocol is superior to that of the protocols proposed by Gao et al. [20] and Grissa et al. [21] and is unaffected by the number of cells. Meanwhile, the performance analysis also shows our protocol is lightweight in both computation and communication costs, which achieves a much better performance in comparison with other protocols.

7. Conclusion

In this paper, we propose a lightweight privacy-preserving location verification protocol (LPPLV) for large-scale database-driven CRNs. In LPPLV, the SU does not need to provide his/her real identity and location information for the DB, which prevents the DB from obtaining the real identity and location information of SUs. LPPLV has a distributed architecture in which SUs generate location proofs for each other. The new witness selection mechanism allows malicious SUs to be discovered by the BS when malicious SUs generate fake location information. This new witness selection mechanism also provides a solution for possible SU-Witness collusion, which has not been well solved in existing works. Further, by channel preallocation, LPPLV improves the efficiency of obtaining available channels for SUs. The results of security analysis prove that LPPLV resists various types of attacks in database-driven CRNs. Experimental results indicate the efficiency of LPPLV.

In future work, we will study how to improve the security and privacy of PUs. Because SUs can learn the state of PUs from the channel, this might be easily misused and threaten the privacy of PUs. Therefore, we will take the PUs’ privacy into account in our future work.

Data Availability

The data used to support the findings of this study are included within the article.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work was supported by National Natural Science Foundation of China [Grant No. 61771140, No.61841701], Major Program of Fuzhou Municipal Bureau of Science and Technology [Grant No. (2017)325], Major Science and Technology Project in Fujian Province [Grant No. 2017H6005], and Natural Science Foundation of Fujian Province (Grant No.2018J01560).