# Lightweight Privacy Preservation for Securing Large-Scale Database-Driven Cognitive Radio Networks with Location Verification

Authors: Rui Zhu; Li Xu; Yali Zeng; Xun Yi
Journal: Security and Communication Networks
 (2019)

---

## 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.


---

## Body

## 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 Section2. 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.


## 2. Related Work

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, 22–25]. 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.


## 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, 22–25]. 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 Figure1, 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.Figure 1
Network model.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.


## 3.1. System Model

Our network model is shown in Figure1, 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.Figure 1
Network model.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 Table1.Table 1
Notations in the protocol.
Notation Description ∥ Concatenation symbol  I D U Identity of entity U  P I D U The pseudo-ID of entity U  N1 The number of BSs  N2 The number of SUs  PKU The public key of entity U  SKU The secret key of entity U  EKU(m) Encryption of message m using key of entity U  MACKU(m) Message authentication code of message m using key of entity U  RepU The reputation value of entity U  L o c U The location of entity U  ti The time stamp  C L i A channel list  C h i An available channel  kU1,U2 The session key between entityU1 and U2  ri A random number  H A secure hash function


### 4.1. System Initialization Phase

We assume that a network is composed ofN1 BSs and N2 SUs. Each BS and SU send their real identities to the TA in a secure channel for registration.For eachBSi(i∈N1) whose real identity is IDBSi, the TA generates the secret key SKBSi and public key PKBSi. The TA also generates a unique session key kDB,BSi between the DB and the BSi. Then TA sends SKBSi and kDB,BSi to BSi in a secure channel and publishes PKBSi. The TA sends kDB,BSi to the DB. Upon receiving SKBSi and kDB,BSi, BSi stores these keys securely.For eachSUj(j∈N2) whose real identity is IDSUj, the TA chooses X distinct pseudo-IDs (PIDs) PIDSUj,1,PIDSUj,2,…,PIDSUj,X and sends them to SUj. The TA initializes the reputation value RepSUj=0. Upon receiving PIDs, SUj stores the PIDs securely and uses one PID for each request. After all PIDs are allocated, SUj asks for another X 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,BSi sends a request to the DB for enabling channel preallocation. This phase includes the following steps.( 1 )   B S i sends the following message m1 to the DB for enabling channel preallocation.(1)m1=IDBSi∥t1∥EkDB,BSiIDBSi∥LocBSi∥t1∥MACkDB,BSim1′,where m1′=(IDBSi∥LocBSi∥t1), LocBSi is the location of BSi, and MACkDB,BSi(m1′) is message authentication code of m1′ using the key kDB,BSi.( 2 ) After receiving the message from BSi, the DB decrypts the message with the key kDB,BSi that matches BSi and checks whether t1 is a valid time stamp. Then the DB computes MACkDB,BSi(m1′) and verifies that it is the same as MACkDB,BSi(m1′) received through m1. If one or both of the verifications do not hold, the DB drops this message. Otherwise, BSi is authenticated by the DB. The DB chooses a channel list ChBSi based on LocBSi and sends the message m2 to the BSi using a secure channel.(2)m2=IDBSi∥t2∥EkDB,BSiChBSi∥t2∥MACkDB,BSim2′,where m2′=(ChBSi∥t2).( 3 ) Upon receiving the message m2 from the DB, BSi checks whether the IDBSi is its identity. Then BSi uses its secret key SKBSi to decrypt the message m2 and verifies MACkDB,BSi(m2′). If these verifications do not hold, BSi drops this message. Otherwise, BSi obtains the channel list CLBSi. Then the BSi 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.( 1 )   S U j randomly selects a PID from PIDSUj,1,PIDSUj,2,…,PIDSUj,X, generates a unique session key kSUj,BSi between himself/herself and the BSi, and sends a location verification request m3 to BSi.(3)m3=EPKBSiPIDSUj∥LocSUj∥kSUj,BSi∥t3∥MACkSUj,BSim3′,where m3′=(PIDSUj∥LocSUj∥kSUj,BSi∥t3).( 2 ) Upon receiving the message m3 from SUj, BSi uses its secret key SKBSi to decrypt the message m3. BS first checks whether the location of SUj has the available channels. If not, BSi responds with the following message m4 to reject the request. Otherwise, BSi executes the location proof generation steps described in Section 4.4.(4)m4=EkSUj,BSiPIDSUj∥LocSUj∥t4∥null∥MACkSUj,BSim4′,where m4′=(PIDSUj∥LocSUj∥t4∥null).


### 4.4. Location Proof Generation Phase

Since each SU has to request location verification and available channels fromBSi, BSi stores PIDs, locations of the SUs who have requested the channels, and the unique session keys kWj,BSi between these SUs and BSi. kWj,BSi is the key generated by these SUs in their channel query phase, which is similar to kSUj,BSi. This phase includes the following steps.( 1 ) Upon receiving the message m3, BSi searches for K SUs who are using the channel and are near SUj. Then, BSi sends a list of the PIDs of these SUs and PIDSUj to the TA. After receiving the list and PIDSUj from BSi, the TA first searches for the real identity of SUj and verifies whether SUj has registered with it. Then the TA responds with the reputation values of these SUs to BSi according to the PIDs. If SUj has not registered in the TA, the TA rejects BSi.( 2 ) We assume RepT is the threshold of reputation value. If RepSUj<RepT, that means SUj has a high probability of being dishonest. BSi sorts K SUs according to their reputation values and checks the top N(N≤K) SUs’ reputation values. We assume NH is the threshold number of location proofs that BSi will receive. If the number of dishonest SUs is more than threshold NH, BSi will remove some SUs who have lower reputation values. BSi then chooses some preset trusted fixed devices as a supplement to ensure that the number of dishonest selected witnesses is less than NH. At the beginning of the system, there are not enough SUs in the network that can be selected as witnesses. At this time, BSi selects some preset trusted fixed devices as witnesses.After selectingN witnesses, BSi generates a unique index (INDP) for this location proof, numbers selected witnesses to ni, and generates the session keys kWk,SUj(k∈N) for his/her communication process. Then BSi sends the following message m5 to SUj and sends the message m6 to each witness.(5)m5=EkSUj,BSiINDP∥kW1,SUj∥kW2,SUj∥…∥kWN,SUj∥t5∥MACkSUj,BSim5′,(6)m6=EkWk,BSiINDP∥ni∥kWk,SUj∥t6∥MACkWk,BSim6′,where m5′=(INDP∥kW1,SUj∥kW2,SUj∥…∥kWN,SUj∥t5) and m6′=(INDP∥ni∥kWk,SUj∥t6). BSi generates a table for this location proof and verification, as shown in Table 2.Table 2
The information of this location proof and verification.
IND P I D S U k S U , B S P I D W k W , B S k W , S U t INDP P I D S U j k S U j , B S i P I D W 1 ∥ … ∥ P I D W N k W 1 , B S i ∥ . . ∥ k W N , B S i k W 1 , S U j ∥ … ∥ k W N , S U j t 5( 3 ) After receiving the message m6, a selected witness generates a random number ri and broadcasts the following message m7 through its predefined short-range communication interface for a period of time T.(7)m7=ni∥INDP∥t7∥EkWk,SUjni∥INDP∥ri∥t7∥MACkWk,SUjm7′,where m7′=(ni∥INDP∥ri∥t7). Another ri is generated and broadcast in a similar way. This process is repeated until the witness receives a response from SUj.( 4 )   S U j first ensures that the INDP is the same as the one already received from the BS when the SU receives the message m7. Then, SUj checks whether t7 is fresh and verifies MACkWk,SUj(m7′). If these verifications are not sustained, SUj drops this message and waits for the next message. Otherwise, SUj decrypts the message with the key kWk,SUj that matches ni, and verifies whether or not the message has been tampered with. If the message cannot be decrypted by the corresponding key, SUj discards this message. If all the verifications are successful, SUj must immediately send message m8 to Wk:(8)m8=INDP∥t8∥EkWk,SUjINDP∥ri∥t8∥HPIDSUi∥ri∥MACkWk,SUjm8′,where m8′=(INDP∥ri∥t8∥H(PIDSUi∥ri)).( 5 ) Upon receiving m8, Wk first checks whether INDP in m8 is the same as the IND in m6. Then, Wk verifies MACkWk,SUj(m8′) and checks whether ri in m8 is the last random number that had been broadcast by itself. If so, Wk generates the following location proof LP and sends it to BSi.(9)LP=ni∥INDP∥t9∥EkWk,BSiINDP∥PIDWk∥LocWk∥ri∥t9∥HPIDSUj∥ri∥MACkWk,BSiLP′,where LP′=(INDP∥PIDWk∥LocWk∥ri∥t9∥H(PIDSUj∥ri)). Otherwise, the following nullLP is sent to BSi:(10)nLP=ni∥INDP∥t10∥EkWk,BSiINDP∥PIDWk∥null∥t10∥MACkWk,BSinLP′,where nLP′=(INDP∥PIDWk∥null∥t10).


### 4.5. Location Verification Phase

For eachnon-nullLP that has been received before the time threshold, BSi checks non-nullLPs as follows.( 1 ) Checking whether INDP is the unique IND for this location proof, and finding out PIDSUj in the message m3 according to INDP.( 2 ) Checking whether the time stamp t9 is fresh.( 3 ) According to ni, trying to find the unique session key kWk,BSi, and using kWk,BSi to decrypt LP. Then, BSi checks whether PIDWk is the selected witness.( 4 ) Computing MACkWk,BSi(LP′) and verifying it is the same as MACkWk,BSi(LP′) received through LP.(5) Verifying whetherLocSUj is in an acceptable range of LocWk.( 6 ) Computing H(PIDSUj∥ri) and verifying it is the same as H(PIDSUj∥ri) received through LP.( 7 ) Checking whether the number of non-nullLPs is greater than a predefined threshold NH.If all the above checks are successful,BSi accepts SUj, which means that SUj is legitimate. Otherwise, SUj’s request is rejected.


### 4.6. Channel Allocation Phase

If the above location verification is successful, which meansSUj is where he/she claims to be, BSi 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.( 1 ) All PUs operating on these channels are on-line but close to SUj. The BS should choose the channel with the higher power for the SU, so that the SU can obtain the best quality of service.( 2 ) Some PUs in this case might be off-line. BSi chooses the channel with the highest power, but not the maximum power, and long usage time for SUj. Although in this case, SUj 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 SUj to go off-line and switch channels. Therefore, SUj may be caught in frequent channel switching.( 3 ) All PUs operating on these channels are on-line but far away from SUj. This kind of channel is preferred to be used, so BSi chooses this channel for SUj. When SUj accesses such channel, SUj can work at the maximum power regardless of whether the PU is on-line or off-line, so that SUj can use the channel with the best quality of service and avoid the privacy leaking that can be caused by channel switching.( 4 ) Some PUs might be off-line while other PUs are on-line but might be far away from SUj. BSi should choose the channel with the highest (but not the maximum) power and long usage time for SUj, ensuring that SUj can get the best quality channel.As analyzed above, the power and the channel usage time are determined by the channel quality of service.BSi should choose the channel with the best quality of service for SUj according to the power and the channel usage time. After choosing the best channel, BSi sends the message Quc to SUj.(11)Quc=EkSUj,BSiChi∥t11∥MACkSUj,BSiQuc′,where Quc′=(Chi∥t11). 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.WhenSUj plans to go off-line, SUj sends the message Bye to BSi.(12)Bye=EkSUj,BSi0∥t12∥PIDSUj∥MACkSUj,BSiBye′,where Bye′=(0∥t12∥PIDSUj). After receiving the message Bye, the BS reports to the TA, and the TA deletes PIDSUj that SUj 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 Table3. In Table 3, RSUj indicates whether BSi accepts SUj; 0/1 means BSi rejects/accepts SUj. In addition, WRSUj indicates whether SUj provides an effective location proof as a selected witness; 0/1 means SUj has provided an effective/invalid location proof as a selected witness.Table 3
The information of each SU in the TA.
IDSU P I D S U R S U j W R S U j Record time IDSU1 P I D S U 1,1 , … , P I D S U 1 , x 1 ∥ 1 ∥ … 1 ∥ 1 ∥ … t1  IDSU2 PIDSU2,1,…,PIDSU2,x 1∥0∥… 1 ∥ 1 ∥ … t 2  … … … … …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 valueRepSUj of SUj in Table 4 as(13)RepSUj=CRSUj=1+WRSUj=1CSUj,where RSUj=1 means RSUj’s value that is equal to 1 and WRSUj=1 means WRSUj’s value that is equal to 1 in Table 3. And CRSUj=1+WRSUj=1 is the sum of the numbers of RSUj=1 and WRSUj=1, and CSUj is the sum of the numbers of RSUj and WRSUj. There are three cases.Table 4
The reputation value of each SU.
IDSU P I D S U Reputation Update time IDSU1 P I D S U 1,1 , … , P I D S U 1 , x R e p S U 1 t 1  IDSU2 PIDSU2,1,…,PIDSU2,x RepSU2 t 1  … … … …( 1 )   R e p S U j = C R S U j = 1 + W R S U j = 1 + 1 / C S U j + 1: SUj has honestly claimed his/her location or SUj has provided the effective location proof for the surrounding SUs as witness.( 2 )   R e p S U j = C R S U j = 1 + W R S U j = 1 - 1 / C S U j + 1: SUj has been rejected by the BS or SUj has not provided the effective location proof for the surrounding SUs as a witness.( 3 )   R e p S U j = R e p S U j: During this update period, SUj has not sent the channel request to the BS or SUj has not been selected as a witness.


## 4.1. System Initialization Phase

We assume that a network is composed ofN1 BSs and N2 SUs. Each BS and SU send their real identities to the TA in a secure channel for registration.For eachBSi(i∈N1) whose real identity is IDBSi, the TA generates the secret key SKBSi and public key PKBSi. The TA also generates a unique session key kDB,BSi between the DB and the BSi. Then TA sends SKBSi and kDB,BSi to BSi in a secure channel and publishes PKBSi. The TA sends kDB,BSi to the DB. Upon receiving SKBSi and kDB,BSi, BSi stores these keys securely.For eachSUj(j∈N2) whose real identity is IDSUj, the TA chooses X distinct pseudo-IDs (PIDs) PIDSUj,1,PIDSUj,2,…,PIDSUj,X and sends them to SUj. The TA initializes the reputation value RepSUj=0. Upon receiving PIDs, SUj stores the PIDs securely and uses one PID for each request. After all PIDs are allocated, SUj asks for another X 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,BSi sends a request to the DB for enabling channel preallocation. This phase includes the following steps.( 1 )   B S i sends the following message m1 to the DB for enabling channel preallocation.(1)m1=IDBSi∥t1∥EkDB,BSiIDBSi∥LocBSi∥t1∥MACkDB,BSim1′,where m1′=(IDBSi∥LocBSi∥t1), LocBSi is the location of BSi, and MACkDB,BSi(m1′) is message authentication code of m1′ using the key kDB,BSi.( 2 ) After receiving the message from BSi, the DB decrypts the message with the key kDB,BSi that matches BSi and checks whether t1 is a valid time stamp. Then the DB computes MACkDB,BSi(m1′) and verifies that it is the same as MACkDB,BSi(m1′) received through m1. If one or both of the verifications do not hold, the DB drops this message. Otherwise, BSi is authenticated by the DB. The DB chooses a channel list ChBSi based on LocBSi and sends the message m2 to the BSi using a secure channel.(2)m2=IDBSi∥t2∥EkDB,BSiChBSi∥t2∥MACkDB,BSim2′,where m2′=(ChBSi∥t2).( 3 ) Upon receiving the message m2 from the DB, BSi checks whether the IDBSi is its identity. Then BSi uses its secret key SKBSi to decrypt the message m2 and verifies MACkDB,BSi(m2′). If these verifications do not hold, BSi drops this message. Otherwise, BSi obtains the channel list CLBSi. Then the BSi 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.( 1 )   S U j randomly selects a PID from PIDSUj,1,PIDSUj,2,…,PIDSUj,X, generates a unique session key kSUj,BSi between himself/herself and the BSi, and sends a location verification request m3 to BSi.(3)m3=EPKBSiPIDSUj∥LocSUj∥kSUj,BSi∥t3∥MACkSUj,BSim3′,where m3′=(PIDSUj∥LocSUj∥kSUj,BSi∥t3).( 2 ) Upon receiving the message m3 from SUj, BSi uses its secret key SKBSi to decrypt the message m3. BS first checks whether the location of SUj has the available channels. If not, BSi responds with the following message m4 to reject the request. Otherwise, BSi executes the location proof generation steps described in Section 4.4.(4)m4=EkSUj,BSiPIDSUj∥LocSUj∥t4∥null∥MACkSUj,BSim4′,where m4′=(PIDSUj∥LocSUj∥t4∥null).


## 4.4. Location Proof Generation Phase

Since each SU has to request location verification and available channels fromBSi, BSi stores PIDs, locations of the SUs who have requested the channels, and the unique session keys kWj,BSi between these SUs and BSi. kWj,BSi is the key generated by these SUs in their channel query phase, which is similar to kSUj,BSi. This phase includes the following steps.( 1 ) Upon receiving the message m3, BSi searches for K SUs who are using the channel and are near SUj. Then, BSi sends a list of the PIDs of these SUs and PIDSUj to the TA. After receiving the list and PIDSUj from BSi, the TA first searches for the real identity of SUj and verifies whether SUj has registered with it. Then the TA responds with the reputation values of these SUs to BSi according to the PIDs. If SUj has not registered in the TA, the TA rejects BSi.( 2 ) We assume RepT is the threshold of reputation value. If RepSUj<RepT, that means SUj has a high probability of being dishonest. BSi sorts K SUs according to their reputation values and checks the top N(N≤K) SUs’ reputation values. We assume NH is the threshold number of location proofs that BSi will receive. If the number of dishonest SUs is more than threshold NH, BSi will remove some SUs who have lower reputation values. BSi then chooses some preset trusted fixed devices as a supplement to ensure that the number of dishonest selected witnesses is less than NH. At the beginning of the system, there are not enough SUs in the network that can be selected as witnesses. At this time, BSi selects some preset trusted fixed devices as witnesses.After selectingN witnesses, BSi generates a unique index (INDP) for this location proof, numbers selected witnesses to ni, and generates the session keys kWk,SUj(k∈N) for his/her communication process. Then BSi sends the following message m5 to SUj and sends the message m6 to each witness.(5)m5=EkSUj,BSiINDP∥kW1,SUj∥kW2,SUj∥…∥kWN,SUj∥t5∥MACkSUj,BSim5′,(6)m6=EkWk,BSiINDP∥ni∥kWk,SUj∥t6∥MACkWk,BSim6′,where m5′=(INDP∥kW1,SUj∥kW2,SUj∥…∥kWN,SUj∥t5) and m6′=(INDP∥ni∥kWk,SUj∥t6). BSi generates a table for this location proof and verification, as shown in Table 2.Table 2
The information of this location proof and verification.
IND P I D S U k S U , B S P I D W k W , B S k W , S U t INDP P I D S U j k S U j , B S i P I D W 1 ∥ … ∥ P I D W N k W 1 , B S i ∥ . . ∥ k W N , B S i k W 1 , S U j ∥ … ∥ k W N , S U j t 5( 3 ) After receiving the message m6, a selected witness generates a random number ri and broadcasts the following message m7 through its predefined short-range communication interface for a period of time T.(7)m7=ni∥INDP∥t7∥EkWk,SUjni∥INDP∥ri∥t7∥MACkWk,SUjm7′,where m7′=(ni∥INDP∥ri∥t7). Another ri is generated and broadcast in a similar way. This process is repeated until the witness receives a response from SUj.( 4 )   S U j first ensures that the INDP is the same as the one already received from the BS when the SU receives the message m7. Then, SUj checks whether t7 is fresh and verifies MACkWk,SUj(m7′). If these verifications are not sustained, SUj drops this message and waits for the next message. Otherwise, SUj decrypts the message with the key kWk,SUj that matches ni, and verifies whether or not the message has been tampered with. If the message cannot be decrypted by the corresponding key, SUj discards this message. If all the verifications are successful, SUj must immediately send message m8 to Wk:(8)m8=INDP∥t8∥EkWk,SUjINDP∥ri∥t8∥HPIDSUi∥ri∥MACkWk,SUjm8′,where m8′=(INDP∥ri∥t8∥H(PIDSUi∥ri)).( 5 ) Upon receiving m8, Wk first checks whether INDP in m8 is the same as the IND in m6. Then, Wk verifies MACkWk,SUj(m8′) and checks whether ri in m8 is the last random number that had been broadcast by itself. If so, Wk generates the following location proof LP and sends it to BSi.(9)LP=ni∥INDP∥t9∥EkWk,BSiINDP∥PIDWk∥LocWk∥ri∥t9∥HPIDSUj∥ri∥MACkWk,BSiLP′,where LP′=(INDP∥PIDWk∥LocWk∥ri∥t9∥H(PIDSUj∥ri)). Otherwise, the following nullLP is sent to BSi:(10)nLP=ni∥INDP∥t10∥EkWk,BSiINDP∥PIDWk∥null∥t10∥MACkWk,BSinLP′,where nLP′=(INDP∥PIDWk∥null∥t10).


## 4.5. Location Verification Phase

For eachnon-nullLP that has been received before the time threshold, BSi checks non-nullLPs as follows.( 1 ) Checking whether INDP is the unique IND for this location proof, and finding out PIDSUj in the message m3 according to INDP.( 2 ) Checking whether the time stamp t9 is fresh.( 3 ) According to ni, trying to find the unique session key kWk,BSi, and using kWk,BSi to decrypt LP. Then, BSi checks whether PIDWk is the selected witness.( 4 ) Computing MACkWk,BSi(LP′) and verifying it is the same as MACkWk,BSi(LP′) received through LP.(5) Verifying whetherLocSUj is in an acceptable range of LocWk.( 6 ) Computing H(PIDSUj∥ri) and verifying it is the same as H(PIDSUj∥ri) received through LP.( 7 ) Checking whether the number of non-nullLPs is greater than a predefined threshold NH.If all the above checks are successful,BSi accepts SUj, which means that SUj is legitimate. Otherwise, SUj’s request is rejected.


## 4.6. Channel Allocation Phase

If the above location verification is successful, which meansSUj is where he/she claims to be, BSi 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.( 1 ) All PUs operating on these channels are on-line but close to SUj. The BS should choose the channel with the higher power for the SU, so that the SU can obtain the best quality of service.( 2 ) Some PUs in this case might be off-line. BSi chooses the channel with the highest power, but not the maximum power, and long usage time for SUj. Although in this case, SUj 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 SUj to go off-line and switch channels. Therefore, SUj may be caught in frequent channel switching.( 3 ) All PUs operating on these channels are on-line but far away from SUj. This kind of channel is preferred to be used, so BSi chooses this channel for SUj. When SUj accesses such channel, SUj can work at the maximum power regardless of whether the PU is on-line or off-line, so that SUj can use the channel with the best quality of service and avoid the privacy leaking that can be caused by channel switching.( 4 ) Some PUs might be off-line while other PUs are on-line but might be far away from SUj. BSi should choose the channel with the highest (but not the maximum) power and long usage time for SUj, ensuring that SUj can get the best quality channel.As analyzed above, the power and the channel usage time are determined by the channel quality of service.BSi should choose the channel with the best quality of service for SUj according to the power and the channel usage time. After choosing the best channel, BSi sends the message Quc to SUj.(11)Quc=EkSUj,BSiChi∥t11∥MACkSUj,BSiQuc′,where Quc′=(Chi∥t11). 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.WhenSUj plans to go off-line, SUj sends the message Bye to BSi.(12)Bye=EkSUj,BSi0∥t12∥PIDSUj∥MACkSUj,BSiBye′,where Bye′=(0∥t12∥PIDSUj). After receiving the message Bye, the BS reports to the TA, and the TA deletes PIDSUj that SUj 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 Table3. In Table 3, RSUj indicates whether BSi accepts SUj; 0/1 means BSi rejects/accepts SUj. In addition, WRSUj indicates whether SUj provides an effective location proof as a selected witness; 0/1 means SUj has provided an effective/invalid location proof as a selected witness.Table 3
The information of each SU in the TA.
IDSU P I D S U R S U j W R S U j Record time IDSU1 P I D S U 1,1 , … , P I D S U 1 , x 1 ∥ 1 ∥ … 1 ∥ 1 ∥ … t1  IDSU2 PIDSU2,1,…,PIDSU2,x 1∥0∥… 1 ∥ 1 ∥ … t 2  … … … … …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 valueRepSUj of SUj in Table 4 as(13)RepSUj=CRSUj=1+WRSUj=1CSUj,where RSUj=1 means RSUj’s value that is equal to 1 and WRSUj=1 means WRSUj’s value that is equal to 1 in Table 3. And CRSUj=1+WRSUj=1 is the sum of the numbers of RSUj=1 and WRSUj=1, and CSUj is the sum of the numbers of RSUj and WRSUj. There are three cases.Table 4
The reputation value of each SU.
IDSU P I D S U Reputation Update time IDSU1 P I D S U 1,1 , … , P I D S U 1 , x R e p S U 1 t 1  IDSU2 PIDSU2,1,…,PIDSU2,x RepSU2 t 1  … … … …( 1 )   R e p S U j = C R S U j = 1 + W R S U j = 1 + 1 / C S U j + 1: SUj has honestly claimed his/her location or SUj has provided the effective location proof for the surrounding SUs as witness.( 2 )   R e p S U j = C R S U j = 1 + W R S U j = 1 - 1 / C S U j + 1: SUj has been rejected by the BS or SUj has not provided the effective location proof for the surrounding SUs as a witness.( 3 )   R e p S U j = R e p S U j: During this update period, SUj has not sent the channel request to the BS or SUj 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 Section3.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 LPs and decrypts the LPs by the unique session key kWk,BS. Since any entity does not share his/her private key, this SU cannot generate a LP 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 LPs and rejects any LP which is not generated by selected witnesses. Thus, a malicious SU cannot generate a LP 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 LPs 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 LPs should be greater than a predefined threshold NT. It means unless an SU colludes with at least NT 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 NT. 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.Table 5
Comparison of existing privacy-preserving and location verification protocols in CRNs.
Protocol Technique Privacy protection Location verification Collusion resistant Gao et al. [20] PIR √ × ×  Troja et al. [12] PIR √ × ×  Grissa et al. [21] Cuckoo Filter √ × ×  Petrov et al. [13] k-anonymity √ × ×  Xin et al. [16] PIR and APs-based √ √ ×  Li et al. [4] Cryptography and APs-based √ √ ×  Our protocol Cryptography and distributed √ √ √


## 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 m1 with AES with 256-bit key size (AES-256) and the TA also encrypts m2 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 intom×m cells; the output of hash function is 160 bits; IDBSi,PIDSUj, PIDWk, timestamp, and channel list are 32 bits, respectively; a random number ri is 128 bits; and LocBSi, LocSUj, and LocWk are 40 bits, respectively. Further, let TEC,TDC,TEA,TDA,TH, and TMAC 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 TEC,TDC,TEA,TDA,TH, and TMAC is 3.124ms, 2.926ms, 0.006ms, 0.006ms, 0.001ms, and 0.003ms, 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 Table6.Table 6
Computation and communication costs of our protocol.
Phase Entity Computation cost Communication cost (bits) CPAP DB TEA+TDA+2TMAC 288 BS T E A + T D A + 2 T M A C 328  CQP BS T D C + T M A C 0 SU T E C + T M A C 1440  LPGP TA 0 ( K + 1 ) ⋅ 34 BS ( N + 1 ) ⋅ ( T E A + T M A C ) ( K + 1 ) ⋅ 32 + 738 N + 224 SU N ⋅ T E A + ( N + 1 ) ⋅ T D A 608N + ( 2 N + 1 ) ⋅ T M A C + N ⋅ T H Witnesses ( n + 1 ) ⋅ N ⋅ T E A + 2 N ⋅ T D A + ( n + 3 ) ⋅ N ⋅ T M A C 452 ⋅ n ⋅ N + 682 N b i t s  LVP BS N ⋅ ( T D A + T M A C + T H ) 0  CAP BS T E A + T M A C. 224 SU T D A + T M A C 0


#### 6.1.1. Computation Cost

We analyze the computation cost of each phase.(  1) CPAP: At the channel preallocation phase, each BS encrypts m1′ and sends m1 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 m2′. After receiving m2, each BS also needs to execute one AES decryption operation to decrypt m2 and obtains the channel list. In this phase, the computation cost of the BS is TEA+TDA+2TMAC and the computation cost of the DB is TEA+TDA+2TMAC.(  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 TEC+TMAC. The computation cost of the BS is one elliptic curve decryption operation and one message authentication code operation, which is TDC+TMAC.(  3) LPGP: At the location proof generation phase, the computation cost of each BS is N+1 AES encryption operations and N+1 message authentication code operations, which is (N+1)·(TEA+TMAC). The computation cost of each SU consists of N AES encryption operations, N+1 AES decryption operations, 2N+1 message authentication code operations, and N hash function operations, which is N·TEA+(N+1)·TDA+(2N+1)·TMAC+N·TH (N denotes the number of selected witnesses). Similarly, the computation cost of witnesses consists of (n+1)·N AES encryption operations (n denotes the number of broadcasted rounds), 2N AES decryption operations, and (n+3)·N message authentication code operations, which is (n+1)·N·TEA+2N·TDA+(n+3)·N·TMAC.(  4) LVP and CAP: In the location verification phase and the channel allocation phase, the computation cost of each BS is N AES decryption operations, N+1 message authentication code operations, N hash function operations, and one AES encryption operation, which is N·(TDA+TH)+(N+1)·TMAC+TEA. The SU needs one AES decryption operation and one message authentication code operation, which is TDA+TMAC.


#### 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 m1=IDBSi∥t1∥EkDB,BSi(IDBSi∥LocBSi∥t1)∥MACkDB,BSi(m1′) to the DB, and the DB chooses a channel list and sends the message m2=IDBSi∥t2∥EkDB,BSi(ChBSi∥t2)∥MACkDB,BSi(m2′) to the BS. Hence, the communication cost of the BS is (32+32+32+40+32+160)=328bits, and the communication cost of the DB is (32+32+32+32+160)=288bits.(  2) CQP: At the channel query phase, each SU sends the channel request message m3=EPKBSi(PIDSUj∥LocSUj∥kSUj,BSi∥t3) to the BS. Therefore, the communication cost is (32+40+256+32)×4=1440bits.(  3) LPGP: At the location proof generation phase, the TA responds to the reputation value of the K SUs surrounding the SU, so that the communication cost is (K+1)·34. The BS sends the reputation value request message to the TA, m5=EkSUj,BSi(INDP∥kW1,SUj∥kW2,SUj∥⋯∥kWN,SUj∥t5)∥MACkSUj,BSi(m5′) to the SU, and Nm6=EkWk,BSi(INDP∥ni∥kWk,SUj∥t6)∥MACkWk,BSi(m6′) to each witness, respectively. The communication cost of the BS is (K+1)×32+32+256N+32+160+(32+32+2+256+160)×N=(K+1)·32+738N+224bits. The SU responds to the message m8=INDP∥t8∥EkWk,SUj(INDP∥ri∥t8∥H(PIDSUi∥ri))∥MACkWk,SUj(m8′) to each witness, so that the communication cost is N×(32+32+32+160+32+160+160)=608Nbits. Each witness broadcasts n rounds of the message m7=ni∥INDP∥t7∥EkWk,SUj(ni∥INDP∥ri∥t7)∥MACkWk,SUj(m7′) and sends LP=ni∥INDP∥t9∥EkWk,BSi(INDP∥PIDWk∥LocWk∥ri∥t9∥H(PIDSUj∥ri))∥MACkWk,BSi(LP′) to the BS, respectively. Hence, the communication cost of witnesses is (n×N×(2+32+32+32+32+2+160+160))+N×(2+32+32+32+32+40+160+32+160+160)=452·n·N+682Nbits.(  4) LVP and CAP: At the location verification phase and the channel allocation phase, the BS chooses a channel and sends the message Quc=EkSUj,BSi(Chi∥t11)∥MACkSUj,BSi(Quc′) to the SU, so that the communication cost is (32+32+160)=224bits.Moreover, the computation and communication cost of the different number of witnesses is shown in Figure2 using the expressions established in Table 6, wherein K is set to be 20 and n 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 ms; the running time of an SU obtaining the location proof at the location proof generation phase is less than 0.4 ms, 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 ms. 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 ms. 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 bytes, and the communication cost of an SU obtaining the location proof at the location proof generation phase is about 228 bytes; 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 bytes. 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 bytes.Figure 2
Computation cost and communication cost of our protocol.
(a)
Computation cost (b)
Communication cost


### 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.Table 7
Communication cost of different protocols.
Communication cost Gao et al. [20] 2 m + 3 ⋅ [ log ⁡ p ]  Grissa et al. [21] σquery+φ⋅s⋅m2⋅(log2⁡1/ϵ+log2(2δ))δ+s⋅σHMAC  Our protocol 2306+66K+1548N+292⋅n⋅NTable 8
Computation costs of different protocols.
Computation cost SU BS DB Gao et al. [20] 4 m ⋅ T M - O ( m 2 ) ⋅ T M  Grissa et al. [21] s⋅TH 3s⋅TH 3 φ ⋅ s ⋅ m 2 ⋅ T H  Our protocol T E C + ( N + 2 ) ⋅ T D A + N ⋅ T E A + N ⋅ T H (2N+3)⋅TMAC ( N + 3 ) ⋅ T E A + N ⋅ T H + ( N + 1 ) ⋅ T D A + T D C + ( 2 N + 5 ) ⋅ T M A C TEA+TDA+2TMACFigure 3
Comparison of computation cost and communication cost.
(a)
Communication cost (b)
Computation costIn summary, Figure3 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.


## 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 Table6.Table 6
Computation and communication costs of our protocol.
Phase Entity Computation cost Communication cost (bits) CPAP DB TEA+TDA+2TMAC 288 BS T E A + T D A + 2 T M A C 328  CQP BS T D C + T M A C 0 SU T E C + T M A C 1440  LPGP TA 0 ( K + 1 ) ⋅ 34 BS ( N + 1 ) ⋅ ( T E A + T M A C ) ( K + 1 ) ⋅ 32 + 738 N + 224 SU N ⋅ T E A + ( N + 1 ) ⋅ T D A 608N + ( 2 N + 1 ) ⋅ T M A C + N ⋅ T H Witnesses ( n + 1 ) ⋅ N ⋅ T E A + 2 N ⋅ T D A + ( n + 3 ) ⋅ N ⋅ T M A C 452 ⋅ n ⋅ N + 682 N b i t s  LVP BS N ⋅ ( T D A + T M A C + T H ) 0  CAP BS T E A + T M A C. 224 SU T D A + T M A C 0


### 6.1.1. Computation Cost

We analyze the computation cost of each phase.(  1) CPAP: At the channel preallocation phase, each BS encrypts m1′ and sends m1 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 m2′. After receiving m2, each BS also needs to execute one AES decryption operation to decrypt m2 and obtains the channel list. In this phase, the computation cost of the BS is TEA+TDA+2TMAC and the computation cost of the DB is TEA+TDA+2TMAC.(  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 TEC+TMAC. The computation cost of the BS is one elliptic curve decryption operation and one message authentication code operation, which is TDC+TMAC.(  3) LPGP: At the location proof generation phase, the computation cost of each BS is N+1 AES encryption operations and N+1 message authentication code operations, which is (N+1)·(TEA+TMAC). The computation cost of each SU consists of N AES encryption operations, N+1 AES decryption operations, 2N+1 message authentication code operations, and N hash function operations, which is N·TEA+(N+1)·TDA+(2N+1)·TMAC+N·TH (N denotes the number of selected witnesses). Similarly, the computation cost of witnesses consists of (n+1)·N AES encryption operations (n denotes the number of broadcasted rounds), 2N AES decryption operations, and (n+3)·N message authentication code operations, which is (n+1)·N·TEA+2N·TDA+(n+3)·N·TMAC.(  4) LVP and CAP: In the location verification phase and the channel allocation phase, the computation cost of each BS is N AES decryption operations, N+1 message authentication code operations, N hash function operations, and one AES encryption operation, which is N·(TDA+TH)+(N+1)·TMAC+TEA. The SU needs one AES decryption operation and one message authentication code operation, which is TDA+TMAC.


### 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 m1=IDBSi∥t1∥EkDB,BSi(IDBSi∥LocBSi∥t1)∥MACkDB,BSi(m1′) to the DB, and the DB chooses a channel list and sends the message m2=IDBSi∥t2∥EkDB,BSi(ChBSi∥t2)∥MACkDB,BSi(m2′) to the BS. Hence, the communication cost of the BS is (32+32+32+40+32+160)=328bits, and the communication cost of the DB is (32+32+32+32+160)=288bits.(  2) CQP: At the channel query phase, each SU sends the channel request message m3=EPKBSi(PIDSUj∥LocSUj∥kSUj,BSi∥t3) to the BS. Therefore, the communication cost is (32+40+256+32)×4=1440bits.(  3) LPGP: At the location proof generation phase, the TA responds to the reputation value of the K SUs surrounding the SU, so that the communication cost is (K+1)·34. The BS sends the reputation value request message to the TA, m5=EkSUj,BSi(INDP∥kW1,SUj∥kW2,SUj∥⋯∥kWN,SUj∥t5)∥MACkSUj,BSi(m5′) to the SU, and Nm6=EkWk,BSi(INDP∥ni∥kWk,SUj∥t6)∥MACkWk,BSi(m6′) to each witness, respectively. The communication cost of the BS is (K+1)×32+32+256N+32+160+(32+32+2+256+160)×N=(K+1)·32+738N+224bits. The SU responds to the message m8=INDP∥t8∥EkWk,SUj(INDP∥ri∥t8∥H(PIDSUi∥ri))∥MACkWk,SUj(m8′) to each witness, so that the communication cost is N×(32+32+32+160+32+160+160)=608Nbits. Each witness broadcasts n rounds of the message m7=ni∥INDP∥t7∥EkWk,SUj(ni∥INDP∥ri∥t7)∥MACkWk,SUj(m7′) and sends LP=ni∥INDP∥t9∥EkWk,BSi(INDP∥PIDWk∥LocWk∥ri∥t9∥H(PIDSUj∥ri))∥MACkWk,BSi(LP′) to the BS, respectively. Hence, the communication cost of witnesses is (n×N×(2+32+32+32+32+2+160+160))+N×(2+32+32+32+32+40+160+32+160+160)=452·n·N+682Nbits.(  4) LVP and CAP: At the location verification phase and the channel allocation phase, the BS chooses a channel and sends the message Quc=EkSUj,BSi(Chi∥t11)∥MACkSUj,BSi(Quc′) to the SU, so that the communication cost is (32+32+160)=224bits.Moreover, the computation and communication cost of the different number of witnesses is shown in Figure2 using the expressions established in Table 6, wherein K is set to be 20 and n 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 ms; the running time of an SU obtaining the location proof at the location proof generation phase is less than 0.4 ms, 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 ms. 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 ms. 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 bytes, and the communication cost of an SU obtaining the location proof at the location proof generation phase is about 228 bytes; 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 bytes. 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 bytes.Figure 2
Computation cost and communication cost of our protocol.
(a)
Computation cost (b)
Communication cost


## 6.1.1. Computation Cost

We analyze the computation cost of each phase.(  1) CPAP: At the channel preallocation phase, each BS encrypts m1′ and sends m1 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 m2′. After receiving m2, each BS also needs to execute one AES decryption operation to decrypt m2 and obtains the channel list. In this phase, the computation cost of the BS is TEA+TDA+2TMAC and the computation cost of the DB is TEA+TDA+2TMAC.(  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 TEC+TMAC. The computation cost of the BS is one elliptic curve decryption operation and one message authentication code operation, which is TDC+TMAC.(  3) LPGP: At the location proof generation phase, the computation cost of each BS is N+1 AES encryption operations and N+1 message authentication code operations, which is (N+1)·(TEA+TMAC). The computation cost of each SU consists of N AES encryption operations, N+1 AES decryption operations, 2N+1 message authentication code operations, and N hash function operations, which is N·TEA+(N+1)·TDA+(2N+1)·TMAC+N·TH (N denotes the number of selected witnesses). Similarly, the computation cost of witnesses consists of (n+1)·N AES encryption operations (n denotes the number of broadcasted rounds), 2N AES decryption operations, and (n+3)·N message authentication code operations, which is (n+1)·N·TEA+2N·TDA+(n+3)·N·TMAC.(  4) LVP and CAP: In the location verification phase and the channel allocation phase, the computation cost of each BS is N AES decryption operations, N+1 message authentication code operations, N hash function operations, and one AES encryption operation, which is N·(TDA+TH)+(N+1)·TMAC+TEA. The SU needs one AES decryption operation and one message authentication code operation, which is TDA+TMAC.


## 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 m1=IDBSi∥t1∥EkDB,BSi(IDBSi∥LocBSi∥t1)∥MACkDB,BSi(m1′) to the DB, and the DB chooses a channel list and sends the message m2=IDBSi∥t2∥EkDB,BSi(ChBSi∥t2)∥MACkDB,BSi(m2′) to the BS. Hence, the communication cost of the BS is (32+32+32+40+32+160)=328bits, and the communication cost of the DB is (32+32+32+32+160)=288bits.(  2) CQP: At the channel query phase, each SU sends the channel request message m3=EPKBSi(PIDSUj∥LocSUj∥kSUj,BSi∥t3) to the BS. Therefore, the communication cost is (32+40+256+32)×4=1440bits.(  3) LPGP: At the location proof generation phase, the TA responds to the reputation value of the K SUs surrounding the SU, so that the communication cost is (K+1)·34. The BS sends the reputation value request message to the TA, m5=EkSUj,BSi(INDP∥kW1,SUj∥kW2,SUj∥⋯∥kWN,SUj∥t5)∥MACkSUj,BSi(m5′) to the SU, and Nm6=EkWk,BSi(INDP∥ni∥kWk,SUj∥t6)∥MACkWk,BSi(m6′) to each witness, respectively. The communication cost of the BS is (K+1)×32+32+256N+32+160+(32+32+2+256+160)×N=(K+1)·32+738N+224bits. The SU responds to the message m8=INDP∥t8∥EkWk,SUj(INDP∥ri∥t8∥H(PIDSUi∥ri))∥MACkWk,SUj(m8′) to each witness, so that the communication cost is N×(32+32+32+160+32+160+160)=608Nbits. Each witness broadcasts n rounds of the message m7=ni∥INDP∥t7∥EkWk,SUj(ni∥INDP∥ri∥t7)∥MACkWk,SUj(m7′) and sends LP=ni∥INDP∥t9∥EkWk,BSi(INDP∥PIDWk∥LocWk∥ri∥t9∥H(PIDSUj∥ri))∥MACkWk,BSi(LP′) to the BS, respectively. Hence, the communication cost of witnesses is (n×N×(2+32+32+32+32+2+160+160))+N×(2+32+32+32+32+40+160+32+160+160)=452·n·N+682Nbits.(  4) LVP and CAP: At the location verification phase and the channel allocation phase, the BS chooses a channel and sends the message Quc=EkSUj,BSi(Chi∥t11)∥MACkSUj,BSi(Quc′) to the SU, so that the communication cost is (32+32+160)=224bits.Moreover, the computation and communication cost of the different number of witnesses is shown in Figure2 using the expressions established in Table 6, wherein K is set to be 20 and n 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 ms; the running time of an SU obtaining the location proof at the location proof generation phase is less than 0.4 ms, 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 ms. 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 ms. 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 bytes, and the communication cost of an SU obtaining the location proof at the location proof generation phase is about 228 bytes; 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 bytes. 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 bytes.Figure 2
Computation cost and communication cost of our protocol.
(a)
Computation cost (b)
Communication cost


## 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.Table 7
Communication cost of different protocols.
Communication cost Gao et al. [20] 2 m + 3 ⋅ [ log ⁡ p ]  Grissa et al. [21] σquery+φ⋅s⋅m2⋅(log2⁡1/ϵ+log2(2δ))δ+s⋅σHMAC  Our protocol 2306+66K+1548N+292⋅n⋅NTable 8
Computation costs of different protocols.
Computation cost SU BS DB Gao et al. [20] 4 m ⋅ T M - O ( m 2 ) ⋅ T M  Grissa et al. [21] s⋅TH 3s⋅TH 3 φ ⋅ s ⋅ m 2 ⋅ T H  Our protocol T E C + ( N + 2 ) ⋅ T D A + N ⋅ T E A + N ⋅ T H (2N+3)⋅TMAC ( N + 3 ) ⋅ T E A + N ⋅ T H + ( N + 1 ) ⋅ T D A + T D C + ( 2 N + 5 ) ⋅ T M A C TEA+TDA+2TMACFigure 3
Comparison of computation cost and communication cost.
(a)
Communication cost (b)
Computation costIn summary, Figure3 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.



---

*Source: 9126376-2019-05-06.xml*