# Blockchain-Enabled Privacy-Preserving Location Sharing Scheme for LBSNs

Authors: Liang Zhu; Xiaowei Liu; Liping Yu; Zengyu Cai; Jianwei Zhang
Journal: Mobile Information Systems
 (2021)

---

## Abstract

The rise of Internet of Things (IoT) technology promotes the rapid development of location services industry. The idea of smart connectivity also provides a new direction for Location-Based Social Networks (LBSNs). However, due to limited calculate ability and internal storage space of IoT devices, historical location data of users is generally stored in the central server, which is likely to cause the disclosure of users’ private data. In this paper, we propose a Blockchain-enabled Privacy-Preserving Location Sharing (B-PPLS) scheme, which is a new framework that not only protects user location privacy but also provides effective location sharing services for users. For B-PPLS, location data owners can share the location area instead of location coordinates to Requesters, in order to realize the location privacy preserving. Also, the Merkle hash tree is utilized to divide the location area, so as to realize the multilevel privacy preserving. Furthermore, four algorithms are proposed to achieve the four stages of initialization, location record, location sharing, and location verification, respectively. Finally, we analyze the security of the proposed B-PPLS scheme and compare the performance with other related location privacy-preserving schemes by experimental evaluation.


---

## Body

## 1. Introduction

The characteristic of Location-Based Social Networks (i.e., LBSNs) is that people can make use of “check-in” to achieve the sharing and propagation of location-based services in the virtual world [1]. With the incredible development of IoT technology and the growing popularity of mobile devices, there is a widespread need for LBSNs in social life, medical, military, and other areas [2]. Large numbers of applications are also developed, such as route navigation, friend discovery, and POI recommendation. However, it usually requires the real-time location data sharing between devices for IoT technology and LBSNs, which could potentially lead to serious breaches of users’ privacy. In order to achieve location privacy preserving and provide personalized services for users, the architecture of Blockchain-enabled LBSNs (i.e., B-LBSNs) is designed in this paper.As shown in Figure1, three relational graphs (i.e., ① user-location, ② user-user, and ③ location-location) are generated in B-LBSNs. The user-location graph reflects the relation between the user and location, in which different locations are visited by different users. The user-user graph represents the relationship among users, which is built by utilizing Blockchain technology. Therefore, the identity of users is authentic, and the information interaction between users is secure. The location-location graph represents the relationship among geographical locations according to semantical information.Figure 1
The architecture of B-LBSNs.LBSNs refer to obtaining location information of terminal equipment through a variety of external positioning technologies, such as Global System for Mobile Communications (i.e., GSM), Code Division Multiple Access (i.e., CDMA), or Global Positioning System (i.e., GPS), which enable users to share location information and provide users with location-related services. The commonly used location information sharing mechanism is implemented through a third-party central server, which also means that a large amount of user privacy location information is received and managed by the central server. Firstly, it is difficult for the regulatory technique to access the centrally managed location data, and the lack of openness of location data leads to the security threats of illegal use and disclosure of location data because location information consists of a massive quantity of private information, such as work location, family information, and behavioral preferences. Once location information is obtained illegally, users’ privacy and even personal safety will be seriously threatened. Secondly, the management approach makes it difficult to share location data between different third-party service requests. As the benefits of information sharing rapidly emerge, the phenomenon that various application services are allowed to access information between each other is becoming more and more common. For example, the location information of users is uploaded to LBSNs’ server. Because the LBSNs’ server has full control over the location information of the mobile users, the server may tamper with the data without the users’ authorization. Various application servers cannot distinguish the authenticity of the location data returned by the LBSNs’ server. Once the tampered information is received, the output results will be biased. If there is an issue of illegal manipulation of location data in the emergency first aid or defense, it is bound to have unimaginable consequences for people’s physical health, daily life, or national security. As a result, the central server collects a huge amount of user-sensitive data, and users lose control over the location data stored in the centralized server.Blockchain is a new application model of distributed data storage, which is essentially the decentralized distributed database [3]. If the Blockchain is applied to the location record storage of users, its distributed and decentralized characteristics can ensure that the user’s location will not be stored and recorded separately by the third party’s centralized service nodes. At the same time, Blockchain can ensure the immutability and nonrepudiation of the recorded location data by making use of the cryptographic mechanism. If the location information is safely stored in the Blockchain, it can eliminate the problems of illegal location tampering, illegal use, and illegal leakage caused by the centralized management of the third party. Also, it facilitates the secure location sharing among different nodes in the LBSNs. If necessary access control, privacy protection, and other measures are taken for the location information in the Blockchain, the location data can be controlled by the users. Therefore, the inherent characteristics of Blockchain technology enable it to store location data and realize the possibility of secure location sharing.Blockchain technology not only realizes the safe sharing of location data but also increases the controllability of users to their own location data. Although its inherent characteristics can eliminate the security problems caused by centralized storage of location data, there are still some security threats described as following:(1)
Due to the open characteristics of Blockchain, any node in the LBSNs can have unauthorized access to the location data stored on the Blockchain if the confidentiality cannot be guaranteed. At this time, it will cause the user’s location information to be fully disclosed, so as to bring huge security risks to the user.(2)
If the privacy protection of location information cannot be provided in the location sharing scheme, the malicious location requestor will infer the user’s behavior habits and lifestyle based on the location information requested for many times [4]. It may cause the user to be tracked maliciously and personal attacked and other serious consequences.(3)
The malicious user may return fake location information to the location Requester. If the location requester cannot verify the authenticity of the user’s location data, the forged location information will be regarded as the user’s real location. It may lead to varying degrees of location-based analysis bias, service bias, and other problems.(4)
Once the content is uploaded to the Blockchain, it cannot be modified due to the immutability of the Blockchain. After the location information is uploaded with privacy protection, if the original location information cannot be completely recovered, the quality of the original location information will be permanently lost. In the cases where precise location is needed, such as medical institutions or police agencies, the user’s original location cannot be obtained through Blockchain.In this paper, we focus on Blockchain-enabled Privacy-Preserving Location Sharing (B-PPLS), which is a new framework that not only protects user location privacy but also provides effective location sharing services for users. The contributions of our work can be divided into three aspects as follows:(1)
We propose a Blockchain-enabled Privacy-Preserving Location Sharing scheme, named B-PPLS. In B-PPLS, users are able to share the location area instead of location coordinates to location Requesters, in order to realize the location privacy preserving. Also, the Merkle hash tree is utilized to divide the location area, so as to realize the multilevel privacy preserving.(2)
We present four algorithms to complete the processes of initialization, location record, location sharing, and location verification. Furthermore, we make the security analysis of the B-PPLS scheme according to the proposed security objectives.(3)
We implement the designed algorithms and through the experiments to verify the safety and feasibility of B-PPLS.The framework of this paper is organized as follows. Section2 discusses the related work. Section 3 provides the overview of the B-PPLS scheme. In Section 4, we present the scheme designs of B-PPLS including initialization, location record, location sharing, and location verification. In Section 5, we give the security analysis of the B-PPLS scheme. Experiments and evaluations are discussed in Section 6. Finally, we conclude the paper and give future research directions in Section 7.


## 2. Related Work

In this section, the related research is conducted in three aspects. Firstly, the development process about location privacy preserving is explained. The second, the references about Blockchain-based location privacy preserving are described. At last, the works on encryption algorithms are researched.


### 2.1. Location Privacy Preserving

It involves the research on location privacy preserving when users share their location information to location requesters. The main methods of location privacy preserving are false location,k-anonymity, differential privacy, and cryptography. The method of false location is to realize the location privacy preserving by returning false location. The method of false location which owns high cost is not suitable for mobile devices because of the constrained resource. In order to reduce the cost, Liu et al. [5] utilized the Bayesian games to improve the dummy generation. It can help users achieve optimized payoffs. The two-tier schema based on k-anonymity was proposed by Fei et al. [6] to reduce the privacy-preserving cost. Pingley et al. [7] proposed a disturbance method based on the Hibert curve, in which the user added noise to the real position to get the false position. This solution is the first end-to-end solution that considers the quality of communication service while protecting location privacy and improving LBS accuracy. k-anonymity is the popular technique for location privacy preserving. Also, the incremental clique-based cloaking algorithm, which considered k-anonymity and cloaking granularity, was proposed by Pan et al. [8]. In order to achieve the personalized privacy preserving, Gedik and Liu [9] proposed a flexible privacy-preserving framework based on location k-anonymity. Although the location obfuscation method can protect location privacy, the data utility was lower. The differential-and-distortion framework was designed by Wang et al. [10] to reduce the data loss during the process of location obfuscation. The differential privacy model can achieve the higher data utility for privacy preserving. Xu et al. [11] proposed the DP-LTOD scheme, which obfuscated original trajectory sequences into differential privacy-guaranteed trajectory sequences for privacy preserving. Cryptography is to protect location privacy by encrypting location points. The method of proxy re-encryption was proposed by Shao et al. [12] for location privacy preserving. Li et al. [13] applied homomorphic cryptography technology to location privacy preserving. Except cryptography, other privacy-preserving technologies are unable to realize the recovery of original information after privacy protection. At the same time, the above methods do not consider the authenticity verification of user’s location information.


### 2.2. Blockchain-Based Location Privacy Preserving

In the current research, Blockchain-based location privacy-preserving schemes all have different degrees of security threats. The decentralized personal data management system was proposed by Li et al. [13], so as to protect user data security. Also, the Blockchain technology was utilized to achieve the automated access control. In VANETs, Li et al. [14] proposed the Blockchain-based trust management algorithm to control the movement behavior of vehicle nodes and achieve the privacy preserving of vehicles. Also, Luo et al. [15] proposed the Blockchain-based location privacy-preserving method by considering the trust mechanism to protect the location privacy of vehicles. The decentralized location privacy-preserving method was proposed by Zhang et al. [16] to protect the location privacy of task and achieve the multilevel location privacy preserving of workers. By making use of the decentralized structure and consensus approach of Blockchain, Zou et al. [17] proposed the two-stage approach realize the nonrepudiation and nontampering of data. Also, it enhanced the sensing quality and protected the data privacy of workers. Most of existing Blockchain-based location privacy-preserving technologies assume that the user who sends the location in the process of location sharing is honest and cannot verify whether the location information after privacy protection is true and credible.


### 2.3. Encryption Algorithms

Order Preserving Encryption (i.e., OPE) [18–20] was first proposed by Agrawal [18] in 2004. After OPE, the ciphertext retains the original order of the plaintext. Therefore, the size relation of plaintext data can be obtained by comparing the ciphertext directly. For plaintext x<y, the OPE ciphertext of x is smaller than the OPE ciphertext of y. For protecting the confidentiality of the data stored in the database, if the traditional encryption method was used, the performance of the data query should be reduced. OPE was a deterministic encryption mechanism, which not only guaranteed the confidentiality of data but also realized the efficient query of data. Initially, OPE was used in databases to perform scoped queries. Then, Boldyreva et al. [19] proposed a security concept based on Pseudorandom Function (PRF), which required the OPE scheme to be as random as possible while preserving the constraints of order. This algorithm was based on the natural relationship between random OPE and hypergeometric probability distribution. And, a kind of order-preserving symmetric encryption was designed by using the black box sampling algorithm of hypergeometric probability distribution. Meanwhile, Boldyreva et al. [19] demonstrated that, for any x∈m, the ciphertext Em,nx,k of the constructed OPE symmetric encryption mechanism was computationally indistinguishable from the ciphertext Em,n∗x,k of the ideal encryption object. Thus, the OPE symmetric encryption mechanism is secure. The OPE in the B-PPLS scheme proposed in this paper all represent the OPE symmetric encryption mechanism in literature [19].Xiao and Yen [21] proved that when the attacker has m known OPE plaintext and ciphertext combinations, for the OPE ciphertext Em,nx,k, the attacker is trying to recover the plaintext information x. If it satisfies h=ome,0<e<1, and m3≤n, the probability that the attacker restores plaintext x is a negligible function of security parameter logm. These results not only improve the understanding of OPE security but also provide theoretical guidance for the selection of OPE parameters in different application scenarios.Merkle et al. first proposed the Merkle hash tree [22–24] and designed a data structure to support the verification of retrieval results. The Merkle hash tree is used to verify the integrity of data, and the core idea is to construct the binary tree by using the one-way hash function. The leaf node of the Merkle hash tree is the hash value of the data, and the value of each nonleaf node is the hash value of its two children combined.Sahai and Waters [25] first mentioned the concept of Attribute-Based Encryption (i.e., ABE) in 2005. In ABE [26–28], the user’s identity is described by a series of attributes. When the data Owner encrypts the message, the relevant property access structure is formulated on the property. Only when the attributes owned by the data requester satisfy the attribute access structure set in advance by the encrypter, it can correctly decrypt the ciphertext through the private key.


## 2.1. Location Privacy Preserving

It involves the research on location privacy preserving when users share their location information to location requesters. The main methods of location privacy preserving are false location,k-anonymity, differential privacy, and cryptography. The method of false location is to realize the location privacy preserving by returning false location. The method of false location which owns high cost is not suitable for mobile devices because of the constrained resource. In order to reduce the cost, Liu et al. [5] utilized the Bayesian games to improve the dummy generation. It can help users achieve optimized payoffs. The two-tier schema based on k-anonymity was proposed by Fei et al. [6] to reduce the privacy-preserving cost. Pingley et al. [7] proposed a disturbance method based on the Hibert curve, in which the user added noise to the real position to get the false position. This solution is the first end-to-end solution that considers the quality of communication service while protecting location privacy and improving LBS accuracy. k-anonymity is the popular technique for location privacy preserving. Also, the incremental clique-based cloaking algorithm, which considered k-anonymity and cloaking granularity, was proposed by Pan et al. [8]. In order to achieve the personalized privacy preserving, Gedik and Liu [9] proposed a flexible privacy-preserving framework based on location k-anonymity. Although the location obfuscation method can protect location privacy, the data utility was lower. The differential-and-distortion framework was designed by Wang et al. [10] to reduce the data loss during the process of location obfuscation. The differential privacy model can achieve the higher data utility for privacy preserving. Xu et al. [11] proposed the DP-LTOD scheme, which obfuscated original trajectory sequences into differential privacy-guaranteed trajectory sequences for privacy preserving. Cryptography is to protect location privacy by encrypting location points. The method of proxy re-encryption was proposed by Shao et al. [12] for location privacy preserving. Li et al. [13] applied homomorphic cryptography technology to location privacy preserving. Except cryptography, other privacy-preserving technologies are unable to realize the recovery of original information after privacy protection. At the same time, the above methods do not consider the authenticity verification of user’s location information.


## 2.2. Blockchain-Based Location Privacy Preserving

In the current research, Blockchain-based location privacy-preserving schemes all have different degrees of security threats. The decentralized personal data management system was proposed by Li et al. [13], so as to protect user data security. Also, the Blockchain technology was utilized to achieve the automated access control. In VANETs, Li et al. [14] proposed the Blockchain-based trust management algorithm to control the movement behavior of vehicle nodes and achieve the privacy preserving of vehicles. Also, Luo et al. [15] proposed the Blockchain-based location privacy-preserving method by considering the trust mechanism to protect the location privacy of vehicles. The decentralized location privacy-preserving method was proposed by Zhang et al. [16] to protect the location privacy of task and achieve the multilevel location privacy preserving of workers. By making use of the decentralized structure and consensus approach of Blockchain, Zou et al. [17] proposed the two-stage approach realize the nonrepudiation and nontampering of data. Also, it enhanced the sensing quality and protected the data privacy of workers. Most of existing Blockchain-based location privacy-preserving technologies assume that the user who sends the location in the process of location sharing is honest and cannot verify whether the location information after privacy protection is true and credible.


## 2.3. Encryption Algorithms

Order Preserving Encryption (i.e., OPE) [18–20] was first proposed by Agrawal [18] in 2004. After OPE, the ciphertext retains the original order of the plaintext. Therefore, the size relation of plaintext data can be obtained by comparing the ciphertext directly. For plaintext x<y, the OPE ciphertext of x is smaller than the OPE ciphertext of y. For protecting the confidentiality of the data stored in the database, if the traditional encryption method was used, the performance of the data query should be reduced. OPE was a deterministic encryption mechanism, which not only guaranteed the confidentiality of data but also realized the efficient query of data. Initially, OPE was used in databases to perform scoped queries. Then, Boldyreva et al. [19] proposed a security concept based on Pseudorandom Function (PRF), which required the OPE scheme to be as random as possible while preserving the constraints of order. This algorithm was based on the natural relationship between random OPE and hypergeometric probability distribution. And, a kind of order-preserving symmetric encryption was designed by using the black box sampling algorithm of hypergeometric probability distribution. Meanwhile, Boldyreva et al. [19] demonstrated that, for any x∈m, the ciphertext Em,nx,k of the constructed OPE symmetric encryption mechanism was computationally indistinguishable from the ciphertext Em,n∗x,k of the ideal encryption object. Thus, the OPE symmetric encryption mechanism is secure. The OPE in the B-PPLS scheme proposed in this paper all represent the OPE symmetric encryption mechanism in literature [19].Xiao and Yen [21] proved that when the attacker has m known OPE plaintext and ciphertext combinations, for the OPE ciphertext Em,nx,k, the attacker is trying to recover the plaintext information x. If it satisfies h=ome,0<e<1, and m3≤n, the probability that the attacker restores plaintext x is a negligible function of security parameter logm. These results not only improve the understanding of OPE security but also provide theoretical guidance for the selection of OPE parameters in different application scenarios.Merkle et al. first proposed the Merkle hash tree [22–24] and designed a data structure to support the verification of retrieval results. The Merkle hash tree is used to verify the integrity of data, and the core idea is to construct the binary tree by using the one-way hash function. The leaf node of the Merkle hash tree is the hash value of the data, and the value of each nonleaf node is the hash value of its two children combined.Sahai and Waters [25] first mentioned the concept of Attribute-Based Encryption (i.e., ABE) in 2005. In ABE [26–28], the user’s identity is described by a series of attributes. When the data Owner encrypts the message, the relevant property access structure is formulated on the property. Only when the attributes owned by the data requester satisfy the attribute access structure set in advance by the encrypter, it can correctly decrypt the ciphertext through the private key.


## 3. Overview of B-PPLS Scheme

In this section, we introduce the system model, attack model, and security objectives of our proposed B-PPLS.


### 3.1. System Model

Figure2 shows the system model of B-PPLS. In B-PPLS, it mainly includes three roles, i.e., Owners, Requesters, and Miners. Owners publish the location data on the Blockchain. In this case, the data recorded on each block of Blockchain is not the transaction in Bitcoin (BTC). It records different Owners’ location data arranged in the chronological order. However, the location data is not necessarily continuously recorded on the Blockchain. The Requesters and Owners can share the location data with each other according to the “dual-channel” interaction. If Requester B requests the location data of Owner A at a time, the location data can be requested and verified by the “dual-channel” interaction on and off the chain. The detailed division of each role is summarized as follows.Figure 2
The system model of B-PPLS.


#### 3.1.1. Owners

The location data can be generated and published by Owners. Miners record the location data on the Blockchain, so as to conduct the further location data requesting and location data validation for requesters. When the location data is requested at a time, the Owners can implement different levels of location privacy protection according to different identities of requesters. For the multilevel privacy protection, different levels of location privacy protection are represented by different sizes of anonymous regions or original location coordinates. In LBSNs, if the relationship between OwnerA and requester B is completely trusted, the precise location data of Owner A can be shared to requester B. However, if the relationship between Owner A and requester B is not completely trusted, the anonymous location region can be shared to requester B in order to protect the personal privacy of Owner A.


#### 3.1.2. Requesters

Requesters send the location data request to the Owners. Different requesters have the different need for the accuracy of location data. For example, the precise location data is needed for positioning service, in order to acquire the real location information of users in LBSNs. However, it is not necessary to provide the precise location data for recommendation service. It can recommend the suitable location-based service for target users according to the location region. Under the condition of “dual-channel” interaction, requesters request the location data of Owners through the interaction off the Blockchain. The strength of privacy protection is determined by the location data Owners. If the Owners provide the location region to the Requesters, the integrity and authenticity of the location region can be verified by the requesters through the interaction on the Blockchain. Also, if the Owners provide the precise location data to the Requesters, the integrity and authenticity of precise location data can be verified.


#### 3.1.3. Miners

Any user in the B-PPLS system can act as a miner. The job of Miners is to collect and check the location information published by the Owners. Miners add new blocks to the Blockchain through the consensus mechanism, e.g., Proof of Work (PoW). That is to say, Miners are responsible for maintaining the steady growth of the Blockchain and ensuring the safety of the B-PPLS system.B-PPLS can protect the location privacy of users without disclosure in the process of location sharing for LBSNs. It provides better user preference when the shared location may not be precise. Besides, the Blockchain technology is taken into account in B-PPLS, which can well verify the authenticity and integrity of location data.


### 3.2. Attack Model

In the B-PPLS system, all three roles have potential attack activity. For Owners, the fake locations are shared to the requesters off the Blockchain. Even the Owners deny or falsify the published location record on the Blockchain. For Requesters, the scope of the shared location region is reduced, in order to deduce the precise location of Owners. For Miners, the location data on the Blockchain may be compromised or unauthorizedly accessed. The detailed explanation is as follows.


#### 3.2.1. The Attack on Owners

For the Owners, there are two reasonable assumptions. The one is to assume that the registration information in the Blockchain uploaded by Owners is real. Since each Owner only needs to register the information once before participating in the recording location, this process can be ensured by adding the necessary regulatory means, such as binding with a personal identity. The other one is to assume that the location coordinate information in the Blockchain uploaded by Owners is real. Existing location verification schemes, such as location cryptography secure location protocol [29] and location proof mechanism based on Blockchain [30], can effectively prevent Owners from forging the location coordinate information. Therefore, the above two assumptions are reasonable.The potential attack behavior of Owners can be divided into two conditions according to different application scenarios. On the one hand, the malicious Owners can send fake location data to the Requesters without Blockchain. On the other hand, malicious Owners can modify the location data and send to the Blockchain.


#### 3.2.2. The Attack on Requesters

Because of multilevel privacy preserving for the B-PPLS scheme, the Requester may obtain the area instead of the exact location of the Owner. At the same time, Requesters with different trust levels can obtain location regions of different sizes. In order to provide more accurate location service, there are two attack behaviors for Requests which are not fully trusted. One is that the Requester attempts to narrow the range of the location area returned by the Owner, that is, to obtain the location area with the low privacy protection level. The other one is that the malicious Requester tries to deduce the exact location coordinates of the Owner.


#### 3.2.3. The Attack on Miners

Because Miners are not involved in the exchange of location information between the Owners and Requesters, they do not have any location information about the Owners. However, the location information of the Owners is recorded in the Blockchain. Due to the characteristics of openness of the Blockchain, malicious Miners may attempt to gain unauthorized access to location information in the Blockchain or cause a leak of location information. That is, without Owners’ authorization, malicious Miners may access the personal location information recorded by Owners in the Blockchain.


### 3.3. Security Objectives

For the traditional location data sharing scheme, as the location data is centrally managed, Owners are not controllable to the location data, and there are risks of malicious disclosure and illegal use. To solve these problems, this paper first proposed a decentralized scheme, that is, the scheme in this paper realized the decentralized management of Owners’ location data. Secondly, according to the security threats and the security requirements mentioned in the attack model, the security location sharing scheme should meet the following security attributes.(1)
Immutability. The scheme needs to ensure the immutability of Owners on location records. The tampering or falsification of location data will bring many unpredictable security risks.(2)
Confidentiality. Attacks can infer the movement trajectories of victims according to the obtained location data. Due to the openness of Blockchain, location sharing using Blockchain will make the location information face the risk of unauthorized access. The scheme should ensure the confidentiality of location data. Specifically, in addition to the requesters authorized by Owners, no other identity can obtain the location information of Owners through the content on the Blockchain.(3)
Multilevel Privacy-Preserving. As more and more services use location data, requesters can be users of a variety of identities. However, Owners have different degrees of trust for requesters with different identities. In order to increase the controllability and flexibility of location privacy protection, Owners implement different levels of privacy protection for requesters with different levels of trust. The scheme needs to set up different levels of location information privacy protection.(4)
Verifiability. Because of multilevel privacy protection of location information, the fully trusted requesters will obtain the original location coordinates of Owners. Requesters that are not fully trusted will get the privacy-preserving location area of the Owners. In both cases, in order to prevent Owners from deceiving or falsifying the shared location data, requesters need to verify the integrity and authenticity of the obtained location coordinates or location regions.(5)
Restorability. Due to the immutability of Blockchain, if other noncryptographic schemes such as k-anonymity and other privacy protection technologies are used, uploading the privacy-preserving location data to the Blockchain will lead to permanent loss of data quality. The adoption of the cryptography method can meet the needs of completely restoring the location information to the original location after privacy protection.


## 3.1. System Model

Figure2 shows the system model of B-PPLS. In B-PPLS, it mainly includes three roles, i.e., Owners, Requesters, and Miners. Owners publish the location data on the Blockchain. In this case, the data recorded on each block of Blockchain is not the transaction in Bitcoin (BTC). It records different Owners’ location data arranged in the chronological order. However, the location data is not necessarily continuously recorded on the Blockchain. The Requesters and Owners can share the location data with each other according to the “dual-channel” interaction. If Requester B requests the location data of Owner A at a time, the location data can be requested and verified by the “dual-channel” interaction on and off the chain. The detailed division of each role is summarized as follows.Figure 2
The system model of B-PPLS.


### 3.1.1. Owners

The location data can be generated and published by Owners. Miners record the location data on the Blockchain, so as to conduct the further location data requesting and location data validation for requesters. When the location data is requested at a time, the Owners can implement different levels of location privacy protection according to different identities of requesters. For the multilevel privacy protection, different levels of location privacy protection are represented by different sizes of anonymous regions or original location coordinates. In LBSNs, if the relationship between OwnerA and requester B is completely trusted, the precise location data of Owner A can be shared to requester B. However, if the relationship between Owner A and requester B is not completely trusted, the anonymous location region can be shared to requester B in order to protect the personal privacy of Owner A.


### 3.1.2. Requesters

Requesters send the location data request to the Owners. Different requesters have the different need for the accuracy of location data. For example, the precise location data is needed for positioning service, in order to acquire the real location information of users in LBSNs. However, it is not necessary to provide the precise location data for recommendation service. It can recommend the suitable location-based service for target users according to the location region. Under the condition of “dual-channel” interaction, requesters request the location data of Owners through the interaction off the Blockchain. The strength of privacy protection is determined by the location data Owners. If the Owners provide the location region to the Requesters, the integrity and authenticity of the location region can be verified by the requesters through the interaction on the Blockchain. Also, if the Owners provide the precise location data to the Requesters, the integrity and authenticity of precise location data can be verified.


### 3.1.3. Miners

Any user in the B-PPLS system can act as a miner. The job of Miners is to collect and check the location information published by the Owners. Miners add new blocks to the Blockchain through the consensus mechanism, e.g., Proof of Work (PoW). That is to say, Miners are responsible for maintaining the steady growth of the Blockchain and ensuring the safety of the B-PPLS system.B-PPLS can protect the location privacy of users without disclosure in the process of location sharing for LBSNs. It provides better user preference when the shared location may not be precise. Besides, the Blockchain technology is taken into account in B-PPLS, which can well verify the authenticity and integrity of location data.


## 3.1.1. Owners

The location data can be generated and published by Owners. Miners record the location data on the Blockchain, so as to conduct the further location data requesting and location data validation for requesters. When the location data is requested at a time, the Owners can implement different levels of location privacy protection according to different identities of requesters. For the multilevel privacy protection, different levels of location privacy protection are represented by different sizes of anonymous regions or original location coordinates. In LBSNs, if the relationship between OwnerA and requester B is completely trusted, the precise location data of Owner A can be shared to requester B. However, if the relationship between Owner A and requester B is not completely trusted, the anonymous location region can be shared to requester B in order to protect the personal privacy of Owner A.


## 3.1.2. Requesters

Requesters send the location data request to the Owners. Different requesters have the different need for the accuracy of location data. For example, the precise location data is needed for positioning service, in order to acquire the real location information of users in LBSNs. However, it is not necessary to provide the precise location data for recommendation service. It can recommend the suitable location-based service for target users according to the location region. Under the condition of “dual-channel” interaction, requesters request the location data of Owners through the interaction off the Blockchain. The strength of privacy protection is determined by the location data Owners. If the Owners provide the location region to the Requesters, the integrity and authenticity of the location region can be verified by the requesters through the interaction on the Blockchain. Also, if the Owners provide the precise location data to the Requesters, the integrity and authenticity of precise location data can be verified.


## 3.1.3. Miners

Any user in the B-PPLS system can act as a miner. The job of Miners is to collect and check the location information published by the Owners. Miners add new blocks to the Blockchain through the consensus mechanism, e.g., Proof of Work (PoW). That is to say, Miners are responsible for maintaining the steady growth of the Blockchain and ensuring the safety of the B-PPLS system.B-PPLS can protect the location privacy of users without disclosure in the process of location sharing for LBSNs. It provides better user preference when the shared location may not be precise. Besides, the Blockchain technology is taken into account in B-PPLS, which can well verify the authenticity and integrity of location data.


## 3.2. Attack Model

In the B-PPLS system, all three roles have potential attack activity. For Owners, the fake locations are shared to the requesters off the Blockchain. Even the Owners deny or falsify the published location record on the Blockchain. For Requesters, the scope of the shared location region is reduced, in order to deduce the precise location of Owners. For Miners, the location data on the Blockchain may be compromised or unauthorizedly accessed. The detailed explanation is as follows.


### 3.2.1. The Attack on Owners

For the Owners, there are two reasonable assumptions. The one is to assume that the registration information in the Blockchain uploaded by Owners is real. Since each Owner only needs to register the information once before participating in the recording location, this process can be ensured by adding the necessary regulatory means, such as binding with a personal identity. The other one is to assume that the location coordinate information in the Blockchain uploaded by Owners is real. Existing location verification schemes, such as location cryptography secure location protocol [29] and location proof mechanism based on Blockchain [30], can effectively prevent Owners from forging the location coordinate information. Therefore, the above two assumptions are reasonable.The potential attack behavior of Owners can be divided into two conditions according to different application scenarios. On the one hand, the malicious Owners can send fake location data to the Requesters without Blockchain. On the other hand, malicious Owners can modify the location data and send to the Blockchain.


### 3.2.2. The Attack on Requesters

Because of multilevel privacy preserving for the B-PPLS scheme, the Requester may obtain the area instead of the exact location of the Owner. At the same time, Requesters with different trust levels can obtain location regions of different sizes. In order to provide more accurate location service, there are two attack behaviors for Requests which are not fully trusted. One is that the Requester attempts to narrow the range of the location area returned by the Owner, that is, to obtain the location area with the low privacy protection level. The other one is that the malicious Requester tries to deduce the exact location coordinates of the Owner.


### 3.2.3. The Attack on Miners

Because Miners are not involved in the exchange of location information between the Owners and Requesters, they do not have any location information about the Owners. However, the location information of the Owners is recorded in the Blockchain. Due to the characteristics of openness of the Blockchain, malicious Miners may attempt to gain unauthorized access to location information in the Blockchain or cause a leak of location information. That is, without Owners’ authorization, malicious Miners may access the personal location information recorded by Owners in the Blockchain.


## 3.2.1. The Attack on Owners

For the Owners, there are two reasonable assumptions. The one is to assume that the registration information in the Blockchain uploaded by Owners is real. Since each Owner only needs to register the information once before participating in the recording location, this process can be ensured by adding the necessary regulatory means, such as binding with a personal identity. The other one is to assume that the location coordinate information in the Blockchain uploaded by Owners is real. Existing location verification schemes, such as location cryptography secure location protocol [29] and location proof mechanism based on Blockchain [30], can effectively prevent Owners from forging the location coordinate information. Therefore, the above two assumptions are reasonable.The potential attack behavior of Owners can be divided into two conditions according to different application scenarios. On the one hand, the malicious Owners can send fake location data to the Requesters without Blockchain. On the other hand, malicious Owners can modify the location data and send to the Blockchain.


## 3.2.2. The Attack on Requesters

Because of multilevel privacy preserving for the B-PPLS scheme, the Requester may obtain the area instead of the exact location of the Owner. At the same time, Requesters with different trust levels can obtain location regions of different sizes. In order to provide more accurate location service, there are two attack behaviors for Requests which are not fully trusted. One is that the Requester attempts to narrow the range of the location area returned by the Owner, that is, to obtain the location area with the low privacy protection level. The other one is that the malicious Requester tries to deduce the exact location coordinates of the Owner.


## 3.2.3. The Attack on Miners

Because Miners are not involved in the exchange of location information between the Owners and Requesters, they do not have any location information about the Owners. However, the location information of the Owners is recorded in the Blockchain. Due to the characteristics of openness of the Blockchain, malicious Miners may attempt to gain unauthorized access to location information in the Blockchain or cause a leak of location information. That is, without Owners’ authorization, malicious Miners may access the personal location information recorded by Owners in the Blockchain.


## 3.3. Security Objectives

For the traditional location data sharing scheme, as the location data is centrally managed, Owners are not controllable to the location data, and there are risks of malicious disclosure and illegal use. To solve these problems, this paper first proposed a decentralized scheme, that is, the scheme in this paper realized the decentralized management of Owners’ location data. Secondly, according to the security threats and the security requirements mentioned in the attack model, the security location sharing scheme should meet the following security attributes.(1)
Immutability. The scheme needs to ensure the immutability of Owners on location records. The tampering or falsification of location data will bring many unpredictable security risks.(2)
Confidentiality. Attacks can infer the movement trajectories of victims according to the obtained location data. Due to the openness of Blockchain, location sharing using Blockchain will make the location information face the risk of unauthorized access. The scheme should ensure the confidentiality of location data. Specifically, in addition to the requesters authorized by Owners, no other identity can obtain the location information of Owners through the content on the Blockchain.(3)
Multilevel Privacy-Preserving. As more and more services use location data, requesters can be users of a variety of identities. However, Owners have different degrees of trust for requesters with different identities. In order to increase the controllability and flexibility of location privacy protection, Owners implement different levels of privacy protection for requesters with different levels of trust. The scheme needs to set up different levels of location information privacy protection.(4)
Verifiability. Because of multilevel privacy protection of location information, the fully trusted requesters will obtain the original location coordinates of Owners. Requesters that are not fully trusted will get the privacy-preserving location area of the Owners. In both cases, in order to prevent Owners from deceiving or falsifying the shared location data, requesters need to verify the integrity and authenticity of the obtained location coordinates or location regions.(5)
Restorability. Due to the immutability of Blockchain, if other noncryptographic schemes such as k-anonymity and other privacy protection technologies are used, uploading the privacy-preserving location data to the Blockchain will lead to permanent loss of data quality. The adoption of the cryptography method can meet the needs of completely restoring the location information to the original location after privacy protection.


## 4. B-PPLS Scheme Designs

In this section, we elaborate the B-PPLS scheme designs. Figure3 shows the total flowchart of B-PPLS, which can be divided into four stages, i.e., initialization, location record, location sharing, and location verification according to different functions. The B-PPLS scheme ensures that the Owners can only pass the location verification if the real location coordinates and the real location region are shared in the stage of location sharing. The detailed process is described as following.Figure 3
The total flowchart of B-PPLS.


### 4.1. Initialization

Algorithm1 shows the pseudocode of B-PPLS initialization. The main idea of this algorithm is to generate the Merkle hash tree. The Owners specify the geographically rectangular areas to represent the maximum range of activity which can be accessed. The rectangular area R is transformed in Cartesian coordinates, i.e., R=x,y|0≤x≤X,0≤y≤Y. The areas R are iteratively partitioned in the quadtree manner as follows:(1)xi|1≤i≤2N∧xi=i∗X2N∪yi|1≤i≤2N∧yi=i∗Y2N←PartiR,N,where N not only denotes the maximum number of partitions but also denotes the different levels of location privacy protection. Since Algorithm 1 needs to perform OPE operation on all dividing lines, the selection of N should meet the following formula:(2)2N=ominX,Ye,0<e<1.Algorithm 1: B-PPLS initialization.
Input: Region R=x,y|0≤x≤X,0≤y≤Y; Maximum level of location partition N; Owner’s secret key ko=kox‖koy; Owner’s private key PrioOutput: Registration record Reg(1)
x1,x2,…,x2N∪y1,y2,…,y2N←PartiR,N(2)
Fori⟶1,2,…,2Ndo(3)
ciphix=EX,X′kox,xi;(4)
ciphiy=EY,Y′koy,yi;(5)
nodeix=Hashixiciphix;(6)
nodeiy=Hashiyiciphiy;(7)
End for(8)
xTree←genMTnode1x,node2x,…,node2Nx;(9)
yTree←genMTnode1y,node2y,…,node2Ny;(10)
R←idoxTreerootyTreerootsignaturereg(11)
ReturnRegOwners perform OPE operations one by one along the divider lines perpendicular to thex-axis, i.e., ciph←OPEX,X′kox,xi, 1≤i≤2N. OPE stands for order-preserving encryption, X and X′ are the plaintext space and cryptogram space, respectively, kox is the secret key of Owners, and X3≤X′ according to the security requirements of OPE. The operation perpendicular to the y-axis is similar to the operation perpendicular to the x-axis, and koy≠kox.All the splitter plaintext perpendicularx1,x2,…,x2N to the x-axis is bound one by one with the order-preserving encrypted splitter ciphertext ciph1x,ciph2x,…,ciph2Nx by Owners. It generates nodeix←Hashixiciphix, 1≤i≤2N, by the hash algorithm, and the Merkle hash tree xTree is generated as xTree←genMTnode1x,node2x,…,node2Nx. In a similar way, the Merkle hash tree yTree is generated as yTree←genMTnode1y,node2y,…,node2Ny.Finally, the registration recordReg←idoxTreerootxTreerootsignaturereg is generated by signing the root node of the Merkle hash tree xTree and yTree. Thereinto, signaturereg←ASEPrio,HashidoxTreerootyTreeroot, ASE is the asymmetric encryption algorithm, and Prio is the private key of the Owners. Thus, the operation of the initialization phase is completed.


### 4.2. Location Record

Each location record of the Owners is generated according to the information of the last uploaded location record. Although the location record of the Owners is not continuously stored in the Blockchain, it can be traced forward based on the address of the previous location record in the current location record. Algorithm2 shows the pseudocode of the location record generation algorithm.Algorithm 2: Location record generation.
Input: Owner’s ith location xi,yi; Owner’s secret keys ko=kox‖koy,ksymOutput: Location record LR(1)
Owners execute:(2)
ciphix=EX,X′kox,xi(3)
ciphiy=EY,Y′koy,yi;(4)
ciphi←ciphixciphiy;(5)
OpeHashi←Hashciphi;(6)
LHi←Hashxiyi;(7)
SymCiphi←Encksym,xiyi;(8)
LIi←OpeHashiLHiSymCiphitimestampi;(9)
LRi←PuboLIirecIdi−1osignatureo;(10)
ReturnLRThe main idea of this algorithm is to generate the location record for Owners. Suppose that the Owner generates theith location coordinate li=xi,yi and uploads the location information to the Blockchain. The order-preserving encryption of li is operated by Owners, i.e., ciphix←OPEX,X′kox,xi and ciphiy←OPEY,Y′koy,yi. Also, the OPE cipher of location li is generated as ciphi←ciphixciphiy. The hash algorithms OpeHashi←Hashciphi and LHi←Hashxiyi are operated for the cipher and plaintext of location li=xi,yi, respectively. The symmetric encryption of location li plaintext is computed as SymCiphi←SEksym,xiyi. The location information of the Owner at the ith location is denoted as LIi←OpeHashiLHiSymCiphiTimestampi. The location record of the Owner is generated as LRi←PuboLIirecIdj−1osignatureLoc. Thereinto, signatureLoc←ASEPrio,HashPuboLIirecIdj−1o is the signature of the location record for the Owner.Finally, the location recordLi is broadcasted by the Owner and uploaded to the Blockchain by Miners according to the consensus mechanism. Thus, the operation of location record generation is completed.


### 4.3. Location Sharing

Suppose that the Requester requests theith location information of the Owner; the location sharing phase can be divided into two categories. One is that the Owner has full confidence in the Requester; then, the Owner returns the exact location coordinates xi,yi. The other one is that the Owner has no full confidence in the Requester; then, the Owner returns the rectangular location area containing location coordinates xi,yi. Algorithm 3 shows the pseudocode of the location sharing algorithm.Algorithm 3: Location sharing.
Input: Privacy-preserving level n; Owner’s public key Pubo; Owner’s location li=xi,yiOutput: Shared location information LS(1)
Owners execute:(2)
Ifn = 0 then(3)
conRes←SEksession,xiyi;(4)
Res←conResASEPubo,ksession;(5)
Else If1≤n≤Nthen(6)
find the borderxid1,xid2,yid3,yid4 in level n;(7)
borInfoid1←id1xid1ciphid1x;(8)
borInfoid2←id2xid2ciphid2x;(9)
borInfoid3←id3yid3ciphid3y;(10)
borInfoid4←id4yid4ciphid4y;(11)
borInfo←borInfoid1borInfoid2borInfoid3borInfoid4;(12)
nodex←nodex1x,nodex2x,…;(13)
nodey←nodey1y,nodey2y,…;(14)
fuzRes←Encksession,ciphiborInfonodesx‖nodesy;(15)
Res←fuzResASEPubr,ksession;(16)
End If(17)
Requesters execute:(18)
Ifn = 0 then(19)
xi′yi′←SDksession,conRes;(20)
LS←xi′yi′;(21)
Else If1≤n≤Nthen(22)
ciphi′borInfo′nodes′xnodes′y←SDksession,fuzRes;(23)
LS←ciphi′borInf′nodes′xnodes′y;(24)
End If(25)
Return LSWhen the Owner has full confidence in the Requester, the privacy-preserving level isn=0. It means that the operation of privacy preserving is not performed. Firstly, Owners compute conRes←SEksession,xi‖yi in order to encrypt the exact location. Then, Owners send Res←conRes‖ASEPubo,ksession to Requesters. Finally, the session key ksession is obtained by making use of the private key of the Requester, in order to decrypt the location coordinates of the Owner, i.e., xi′yi′←SDksession,conRes.When the Owner has no full confidence in the Requester, the operation of privacy preserving is necessary for location coordinatesxi,yi. Firstly, the Owner computes the privacy-preserving level n1≤n≤N of the Requester and finds the privacy zone boundary xid1,xid2,yid3,yid4 surrounding location li under the privacy protection level n in region R. The zone divider information can be generated as borInfo←borInfoid1‖borInfoid2borInfoid3borInfoid4; thereinto,(3)borInfoid1←id1xid1ciphid1x,borInfoid2←id2xid2ciphid2x,borInfoid3←id3yid3ciphid3y,borInfoid4←id4xid4ciphid4x.In order to realize the integrity verification of the location frame for the Requester during the stage of location verification, the Owner should return the Merkle hash treexTree and yTree, i.e., nodesx←nodex1x,nodex2x,… and nodesy←nodesy1y,nodesy2y,…. The Owner computes fuzRes←Encksession,ciphiborInfonodesx‖nodesy and returns Res←fuzResASEPubr,ksession to the Requester through the underchain channel. Finally, the location information of the Owner is decrypted by making use of the session key ksession generated by the private key Prir of the Requester. Because the border plaintext information xid1′,xid2′,yid3′,yid4′ is contained in borInfo′, the privacy-preserving location area is obtained by the Requester. The rest part of fuzRes is used to the location verification stage for the Requester. Thus, the operation of location sharing for the Owner and Requester is completed.


### 4.4. Location Verification

Suppose that the Requester verifies theith location information of the Owner during the location sharing; the location verification phase can be divided into two categories corresponding to the location sharing phase. Algorithm 4 shows the pseudocode of the location verification algorithm.Algorithm 4: Location verification.
Input: Location sharing information LS; Location record in the Blockchain LR; session key ksessionOutput: Boolean variable LV(1)
InitializeLV←False(2)
Ifn = 0 then(3)
xi′yi′←LS;(4)
IfHashxi′yi′LRi⋅LIi⋅LHithen(5)
LV←True;(6)
End If(7)
Else If1≤n≤Nthen(8)
ciphi′borInfo′nodes′xnodes′y←LS;(9)
borInfoid1′borInfoid2′borInfoid3′borInfoid4′←borInfo′;(10)
xTreeroot′←genMTHashborInfoid1′,HashborInfoid2′,nodes′x;(11)
yTreeroot′←genMTHashborInfoid1′,HashborInfoid2′,nodes′y;(12)
IfxTreeroot′=xTreeroot and yTreeroot′=yTreerootthen(13)
IfHashciphi′=LRi⋅LIi⋅OpeHashi and borInfoid1′⋅ciphid1x<ciphi′⋅ciphix<borInfoid2′⋅ciphid2x and borInfoid3′⋅ciphid3y<ciphi′⋅ciphiy<borInfoid4′⋅ciphid4ythen(14)
LV←True;(15)
End If(16)
End If(17)
End If(18)
Return LVWhen the Owner has full confidence in the Requester, the precise location coordinatesli′=xi′,yi′ of the Owner can be acquired after conRes is decoded by the Requester. Then, the Requester retrieves the location record LRi on the Blockchain generated during the location record phase. If Hashxi′yi′=LRi⋅LIi⋅LHi, it shows that xi′=xi and yi′=yi; the Requester gets the correct location coordinate information of the Owner. Otherwise, the validation fails.When the Owner has no full confidence in the Requester,ciphi′borInfo′nodes′xnodes′y←SDksession,fuzRes is acquired after fuzRes is decoded by the Requester. nodes′x and nodes′y are the required nodes on the root node authentication path for recovering xTree and yTree. Firstly, the Requester verifies the integrity of the received region boundary information borInfo′. If genMTHashborInfoid1′,HashborInfoid2′,nodes′x=xTreeroot′ and genMTHashborInfoid1′,HashborInfoid2′,nodes′y=yTreeroot′, the regional integrity verification is successful; it shows that the correct region information borInfo′=borInfo is returned by the Owner. Otherwise, the region verification fails. Then, the Requester verifies the authenticity of the received region boundary information borInfo′. If Hashciphi′=LRi⋅LIi⋅OpeHashi, borInfoid1′⋅ciphid1x≤ciphi′⋅ciphix≤borInfoid2′⋅ciphid2x, and borInfoid3′⋅ciphid3y≤ciphi′⋅ciphiy≤borInfoid4′⋅ciphid4y, it shows that xid1≤xi≤xid2 and yid3≤yi≤yid4; location li is in the region surrounded by xid1,xid2,yid3,yid4 that the Requester receives. At this point, the region verification is successful. Otherwise, the region verification fails. Finally, the operation of location verification for the Owner and Requester is completed.The computational complexity of the above four algorithms are O (n), O (1), O (1), and O (1), respectively. The computation overhead of Algorithm 1 increases exponentially with the increase of N. Although large plaintext space brings high computation overhead, it can be realized offline in the initialization phase. Furthermore, Algorithm 1 is executed only one time during the total process. The computation overhead of Algorithm 2 increases with the increase of plaintext space, which is almost unaffected by the value of N. Also, it has small computation overhead in the location record phase. The computation overhead of Algorithm 3 is almost unaffected by the two factors of N and plaintext space. It takes less time at the location sharing phase for Owners. The computation overhead of Algorithm 4 is approximately linear with the size of N. It is not affected by the size of the plaintext space. Since only hash operation is involved in the location verification phase, the computation overhead is very small.


## 4.1. Initialization

Algorithm1 shows the pseudocode of B-PPLS initialization. The main idea of this algorithm is to generate the Merkle hash tree. The Owners specify the geographically rectangular areas to represent the maximum range of activity which can be accessed. The rectangular area R is transformed in Cartesian coordinates, i.e., R=x,y|0≤x≤X,0≤y≤Y. The areas R are iteratively partitioned in the quadtree manner as follows:(1)xi|1≤i≤2N∧xi=i∗X2N∪yi|1≤i≤2N∧yi=i∗Y2N←PartiR,N,where N not only denotes the maximum number of partitions but also denotes the different levels of location privacy protection. Since Algorithm 1 needs to perform OPE operation on all dividing lines, the selection of N should meet the following formula:(2)2N=ominX,Ye,0<e<1.Algorithm 1: B-PPLS initialization.
Input: Region R=x,y|0≤x≤X,0≤y≤Y; Maximum level of location partition N; Owner’s secret key ko=kox‖koy; Owner’s private key PrioOutput: Registration record Reg(1)
x1,x2,…,x2N∪y1,y2,…,y2N←PartiR,N(2)
Fori⟶1,2,…,2Ndo(3)
ciphix=EX,X′kox,xi;(4)
ciphiy=EY,Y′koy,yi;(5)
nodeix=Hashixiciphix;(6)
nodeiy=Hashiyiciphiy;(7)
End for(8)
xTree←genMTnode1x,node2x,…,node2Nx;(9)
yTree←genMTnode1y,node2y,…,node2Ny;(10)
R←idoxTreerootyTreerootsignaturereg(11)
ReturnRegOwners perform OPE operations one by one along the divider lines perpendicular to thex-axis, i.e., ciph←OPEX,X′kox,xi, 1≤i≤2N. OPE stands for order-preserving encryption, X and X′ are the plaintext space and cryptogram space, respectively, kox is the secret key of Owners, and X3≤X′ according to the security requirements of OPE. The operation perpendicular to the y-axis is similar to the operation perpendicular to the x-axis, and koy≠kox.All the splitter plaintext perpendicularx1,x2,…,x2N to the x-axis is bound one by one with the order-preserving encrypted splitter ciphertext ciph1x,ciph2x,…,ciph2Nx by Owners. It generates nodeix←Hashixiciphix, 1≤i≤2N, by the hash algorithm, and the Merkle hash tree xTree is generated as xTree←genMTnode1x,node2x,…,node2Nx. In a similar way, the Merkle hash tree yTree is generated as yTree←genMTnode1y,node2y,…,node2Ny.Finally, the registration recordReg←idoxTreerootxTreerootsignaturereg is generated by signing the root node of the Merkle hash tree xTree and yTree. Thereinto, signaturereg←ASEPrio,HashidoxTreerootyTreeroot, ASE is the asymmetric encryption algorithm, and Prio is the private key of the Owners. Thus, the operation of the initialization phase is completed.


## 4.2. Location Record

Each location record of the Owners is generated according to the information of the last uploaded location record. Although the location record of the Owners is not continuously stored in the Blockchain, it can be traced forward based on the address of the previous location record in the current location record. Algorithm2 shows the pseudocode of the location record generation algorithm.Algorithm 2: Location record generation.
Input: Owner’s ith location xi,yi; Owner’s secret keys ko=kox‖koy,ksymOutput: Location record LR(1)
Owners execute:(2)
ciphix=EX,X′kox,xi(3)
ciphiy=EY,Y′koy,yi;(4)
ciphi←ciphixciphiy;(5)
OpeHashi←Hashciphi;(6)
LHi←Hashxiyi;(7)
SymCiphi←Encksym,xiyi;(8)
LIi←OpeHashiLHiSymCiphitimestampi;(9)
LRi←PuboLIirecIdi−1osignatureo;(10)
ReturnLRThe main idea of this algorithm is to generate the location record for Owners. Suppose that the Owner generates theith location coordinate li=xi,yi and uploads the location information to the Blockchain. The order-preserving encryption of li is operated by Owners, i.e., ciphix←OPEX,X′kox,xi and ciphiy←OPEY,Y′koy,yi. Also, the OPE cipher of location li is generated as ciphi←ciphixciphiy. The hash algorithms OpeHashi←Hashciphi and LHi←Hashxiyi are operated for the cipher and plaintext of location li=xi,yi, respectively. The symmetric encryption of location li plaintext is computed as SymCiphi←SEksym,xiyi. The location information of the Owner at the ith location is denoted as LIi←OpeHashiLHiSymCiphiTimestampi. The location record of the Owner is generated as LRi←PuboLIirecIdj−1osignatureLoc. Thereinto, signatureLoc←ASEPrio,HashPuboLIirecIdj−1o is the signature of the location record for the Owner.Finally, the location recordLi is broadcasted by the Owner and uploaded to the Blockchain by Miners according to the consensus mechanism. Thus, the operation of location record generation is completed.


## 4.3. Location Sharing

Suppose that the Requester requests theith location information of the Owner; the location sharing phase can be divided into two categories. One is that the Owner has full confidence in the Requester; then, the Owner returns the exact location coordinates xi,yi. The other one is that the Owner has no full confidence in the Requester; then, the Owner returns the rectangular location area containing location coordinates xi,yi. Algorithm 3 shows the pseudocode of the location sharing algorithm.Algorithm 3: Location sharing.
Input: Privacy-preserving level n; Owner’s public key Pubo; Owner’s location li=xi,yiOutput: Shared location information LS(1)
Owners execute:(2)
Ifn = 0 then(3)
conRes←SEksession,xiyi;(4)
Res←conResASEPubo,ksession;(5)
Else If1≤n≤Nthen(6)
find the borderxid1,xid2,yid3,yid4 in level n;(7)
borInfoid1←id1xid1ciphid1x;(8)
borInfoid2←id2xid2ciphid2x;(9)
borInfoid3←id3yid3ciphid3y;(10)
borInfoid4←id4yid4ciphid4y;(11)
borInfo←borInfoid1borInfoid2borInfoid3borInfoid4;(12)
nodex←nodex1x,nodex2x,…;(13)
nodey←nodey1y,nodey2y,…;(14)
fuzRes←Encksession,ciphiborInfonodesx‖nodesy;(15)
Res←fuzResASEPubr,ksession;(16)
End If(17)
Requesters execute:(18)
Ifn = 0 then(19)
xi′yi′←SDksession,conRes;(20)
LS←xi′yi′;(21)
Else If1≤n≤Nthen(22)
ciphi′borInfo′nodes′xnodes′y←SDksession,fuzRes;(23)
LS←ciphi′borInf′nodes′xnodes′y;(24)
End If(25)
Return LSWhen the Owner has full confidence in the Requester, the privacy-preserving level isn=0. It means that the operation of privacy preserving is not performed. Firstly, Owners compute conRes←SEksession,xi‖yi in order to encrypt the exact location. Then, Owners send Res←conRes‖ASEPubo,ksession to Requesters. Finally, the session key ksession is obtained by making use of the private key of the Requester, in order to decrypt the location coordinates of the Owner, i.e., xi′yi′←SDksession,conRes.When the Owner has no full confidence in the Requester, the operation of privacy preserving is necessary for location coordinatesxi,yi. Firstly, the Owner computes the privacy-preserving level n1≤n≤N of the Requester and finds the privacy zone boundary xid1,xid2,yid3,yid4 surrounding location li under the privacy protection level n in region R. The zone divider information can be generated as borInfo←borInfoid1‖borInfoid2borInfoid3borInfoid4; thereinto,(3)borInfoid1←id1xid1ciphid1x,borInfoid2←id2xid2ciphid2x,borInfoid3←id3yid3ciphid3y,borInfoid4←id4xid4ciphid4x.In order to realize the integrity verification of the location frame for the Requester during the stage of location verification, the Owner should return the Merkle hash treexTree and yTree, i.e., nodesx←nodex1x,nodex2x,… and nodesy←nodesy1y,nodesy2y,…. The Owner computes fuzRes←Encksession,ciphiborInfonodesx‖nodesy and returns Res←fuzResASEPubr,ksession to the Requester through the underchain channel. Finally, the location information of the Owner is decrypted by making use of the session key ksession generated by the private key Prir of the Requester. Because the border plaintext information xid1′,xid2′,yid3′,yid4′ is contained in borInfo′, the privacy-preserving location area is obtained by the Requester. The rest part of fuzRes is used to the location verification stage for the Requester. Thus, the operation of location sharing for the Owner and Requester is completed.


## 4.4. Location Verification

Suppose that the Requester verifies theith location information of the Owner during the location sharing; the location verification phase can be divided into two categories corresponding to the location sharing phase. Algorithm 4 shows the pseudocode of the location verification algorithm.Algorithm 4: Location verification.
Input: Location sharing information LS; Location record in the Blockchain LR; session key ksessionOutput: Boolean variable LV(1)
InitializeLV←False(2)
Ifn = 0 then(3)
xi′yi′←LS;(4)
IfHashxi′yi′LRi⋅LIi⋅LHithen(5)
LV←True;(6)
End If(7)
Else If1≤n≤Nthen(8)
ciphi′borInfo′nodes′xnodes′y←LS;(9)
borInfoid1′borInfoid2′borInfoid3′borInfoid4′←borInfo′;(10)
xTreeroot′←genMTHashborInfoid1′,HashborInfoid2′,nodes′x;(11)
yTreeroot′←genMTHashborInfoid1′,HashborInfoid2′,nodes′y;(12)
IfxTreeroot′=xTreeroot and yTreeroot′=yTreerootthen(13)
IfHashciphi′=LRi⋅LIi⋅OpeHashi and borInfoid1′⋅ciphid1x<ciphi′⋅ciphix<borInfoid2′⋅ciphid2x and borInfoid3′⋅ciphid3y<ciphi′⋅ciphiy<borInfoid4′⋅ciphid4ythen(14)
LV←True;(15)
End If(16)
End If(17)
End If(18)
Return LVWhen the Owner has full confidence in the Requester, the precise location coordinatesli′=xi′,yi′ of the Owner can be acquired after conRes is decoded by the Requester. Then, the Requester retrieves the location record LRi on the Blockchain generated during the location record phase. If Hashxi′yi′=LRi⋅LIi⋅LHi, it shows that xi′=xi and yi′=yi; the Requester gets the correct location coordinate information of the Owner. Otherwise, the validation fails.When the Owner has no full confidence in the Requester,ciphi′borInfo′nodes′xnodes′y←SDksession,fuzRes is acquired after fuzRes is decoded by the Requester. nodes′x and nodes′y are the required nodes on the root node authentication path for recovering xTree and yTree. Firstly, the Requester verifies the integrity of the received region boundary information borInfo′. If genMTHashborInfoid1′,HashborInfoid2′,nodes′x=xTreeroot′ and genMTHashborInfoid1′,HashborInfoid2′,nodes′y=yTreeroot′, the regional integrity verification is successful; it shows that the correct region information borInfo′=borInfo is returned by the Owner. Otherwise, the region verification fails. Then, the Requester verifies the authenticity of the received region boundary information borInfo′. If Hashciphi′=LRi⋅LIi⋅OpeHashi, borInfoid1′⋅ciphid1x≤ciphi′⋅ciphix≤borInfoid2′⋅ciphid2x, and borInfoid3′⋅ciphid3y≤ciphi′⋅ciphiy≤borInfoid4′⋅ciphid4y, it shows that xid1≤xi≤xid2 and yid3≤yi≤yid4; location li is in the region surrounded by xid1,xid2,yid3,yid4 that the Requester receives. At this point, the region verification is successful. Otherwise, the region verification fails. Finally, the operation of location verification for the Owner and Requester is completed.The computational complexity of the above four algorithms are O (n), O (1), O (1), and O (1), respectively. The computation overhead of Algorithm 1 increases exponentially with the increase of N. Although large plaintext space brings high computation overhead, it can be realized offline in the initialization phase. Furthermore, Algorithm 1 is executed only one time during the total process. The computation overhead of Algorithm 2 increases with the increase of plaintext space, which is almost unaffected by the value of N. Also, it has small computation overhead in the location record phase. The computation overhead of Algorithm 3 is almost unaffected by the two factors of N and plaintext space. It takes less time at the location sharing phase for Owners. The computation overhead of Algorithm 4 is approximately linear with the size of N. It is not affected by the size of the plaintext space. Since only hash operation is involved in the location verification phase, the computation overhead is very small.


## 5. Security Analysis

In this section, the security analysis is given corresponding to the five security attributes in the security objectives of Section3, in order to prove the security of the B-PPLS scheme.


### 5.1. Immutability

According to the principle of Blockchain, all subsequent blocksblocki1<i are constructed from the hash value Hashblocki−1 of the previous block, with the exception of the creation block. According to the difficulty value set by the system, the correct random number is found first so that the hash value of the data in the block header is less than or equal to the target hash value. Miners who have been verified by the whole system get the accounting right and are connected after blocki−1. The attacker who tampers with a record in the block must recalculate the SHA256 puzzle for that block and all subsequent blocks. The computational force must make the forged bifurcated chain become longer than the main chain. If the Owner modifies the location record in blocki−1, the proof of work must be redone for all blocks blockjj>i linked after it. A new fork is created, in order to make the chain length of the fork larger than that of the main chain of original Blockchain. Since the computing power mastered by the Owner is less than 51% of the whole system, the cost required to master 51% of the computing power in the actual system far exceeds the benefits obtained after a successful attack; the probability of the Owner producing a longer fork than the original Blockchain is negligible. Thus, the probability ϵ1 of location repudiation is negligible, while Owners illegally modify the location information already uploaded to the Blockchain.


### 5.2. Confidentiality

There are two types of records in the Blockchain, namely, the location record and the registration record. For the location recordsLRi=PuboLIirecIdj−1osignatureLoc, thereinto LIi=OpeHashiLHiSymCiphiTimestampi. In LRi, the ones that contain the location information of Owners are OpeHashi, LHi, and SymCiphi. Firstly, OpeHashi=Hashciphi and LHi=Hashxi|yi; if Miners recover ciphi or xiyi with the nonnegligible probability ɛh, the unidirectivity of the unidirectional hash function is contradicted. Therefore, the probability ɛh is negligible. Second, SymCiphi=SEksym,xiyi; if Miners, with the nonnegligible probability ɛs, can successfully decrypt the symmetric encryption plaintext without having the private key ksym of the Owner, the confidentiality of the symmetric encryption would be contradicted. Therefore, the probability ɛl=ɛh+ɛs of Miners making unauthorized access based on location information LRi in the Blockchain is negligible.For the registration recordsReg=idoxTreerootyTreerootsignaturereg, thereinto xTreeroot and yTreeroot are both root nodes of the Merkle hash tree. The root nodes are generated by the one-way hash operation performed iteratively by the leaves of the Merkle hash tree. If Miners recover the root of the Merkle hash tree with nonnegligible probability ɛr, the unidirectivity of the hash function is contradicted. Therefore, the probability ɛr of Miners inferring the plaintext of location information from the root node of the Merkle hash tree is negligible.In conclusion, the probabilityɛ2=ɛl+ɛr that the attacker can access the location information of Owners according to the records in the Blockchain is negligible under the condition of no authorization.


### 5.3. Multilevel Privacy Preserving

In the process of location sharing, the size of the location area obtained by the Requester that is not fully trusted is determined by the level of privacy protection. The privacy protection level corresponding to the Requester is set by the Owner according to the trust level. According to Algorithm1, the region R can be divided into the grid of different sizes at N levels. For the Requester, the Owner finds the location region partition line containing the original location point under the privacy-preserving level and returns the plaintext ciphertext combination of the four partition lines of the region to the Requester. The Requester determines the location of the region according to the plaintext xid1, xid2, yid3, and yid4 of the four dividing lines and verifies the integrity and authenticity of the dividing lines according to the ciphertext ciphid1x, ciphid2x, ciphid3y, and ciphid4y of the four dividing lines.If the Requester that is not fully trusted requests multiple locations from the Owners, each location region returned by the Owner consists of a combination of four split-line plaintext and order-preserving encrypted ciphertext, i.e.,borInfoid1=id1xid1ciphid1x. The Requester can obtain the plaintext and ciphertext combination of multiple dividing lines, including borInfoidx1,borInfoidx2,… and borInfoidy1,borInfoidy2,…. For the B-PPLS scheme, since the Requester is in the privacy-preserving level N, all the position areas generated by the divider line do not cross or overlap under the same privacy protection level. Therefore, it is completely unable to reduce the range of the received region by crossing and overlapping the divided regions for Requesters. There are two kinds of splitters in order-preserving encryption, kox≠koy, X≠Y, X′≠Y′; if the probability of the order-preserving cryptography association between borInfox and borInfoy is nonnegligible, it contradicts the security definition of OPE. Therefore, the probability ɛm of the attacker reducing the accepted region size through the association between borInfox and borInfoy’s OPE ciphertext is negligible.In a worst-case scenario, the Requester itself, or through collusion, knows all the split-line plaintext and ciphertext combinations of the Owner. The Requester has the same number of dividing lines perpendicular to thex-axis and the y-axis, all of which are 2N. In this case, we are just talking about the line that is perpendicular to the x-axis, and the same is true for the line that is perpendicular to the y-axis. According to reference [21], for any x∈m, its ciphertext Em,nx,k is computationally indistinguishable from Em,n∗x,f in the ideal OPE object. Thus, the OPE used in the B-PPLS scheme is safe. In the case of OPE security, for attackers with h combinations of plaintext and ciphertext, if h=ome,0<e<1, m3≤n. Then, the ciphertext Em,nx,k is given to the attacker; the probability that the attacker can completely recover the plaintext is negligible. Assume that the attacker has all the plaintext and ciphertext combinations of the dividing lines in the x-axis direction of the Owner after multiple location requests; the number of which is 2N. Because X3≤X′, thereinto X is the plaintext space of order-preserving encryption, X′ is the ciphertext space of order-preserving encryption, and 2N=ominX,Ye; it meets the security requirements. Suppose that the Requester knows all the plaintext and ciphertext combinations that are perpendicular to the x-axis. If the position coordinates li and abscess xi of the Owner are decrypted with a nonnegligible probability ɛx, it contradicts the definition of OPE security analysis. The same with the line that is perpendicular to the y-axis. Therefore, the probability ɛn=ɛx∗ɛy that the Requester can infer the exact position coordinates of the Owner is negligible.In conclusion, the probabilityɛ3=ɛm+ɛn that the Requester will violate the multilevel privacy preserving of the Owner by reducing the scope of the returned region or deducing the exact location coordinates of the Owner is negligible.


### 5.4. Verifiability

When the Requester is fully trusted by the Owner, the probability that the false location information returned by the Owner to the Requester can be verified by the Requester is negligible. That is to say,conRes′←SEksession,xi′yi′, xi≠xi′ and yi≠yi′; the probability of Requester validation is negligible. In the stage of location verification, it determines that whether Hashxi′yi′ is equal to the location record LRi⋅LIi⋅LHi that the Owner has uploaded on the Blockchain. If the Owner finds xi≠xi′ or yi≠yi′ with nonnegligible probability ϵv1 and makes Hashxi′yi′=LRi⋅LIi⋅LHi, it contradicts the collision resistance of the one-way hash function. Thus, the probability ϵv1 is negligible.When the Requester is not fully trusted by the Owner, the probability that the false privacy-preserving location information returned by the Owner to the Requester can be verified by the Requester is negligible. That is to say, if the Owner returnsfuzRes′=Encksession,ciphi′borInfo′nodes′xnodes′y to the Requester and ciphi′≠ciphi, borInfo′≠borInfo, nodes′x≠nodesx, and nodes′y≠nodesy, the probability of the returned location passing validation by the Requester is negligible. In the stage of location verification, the Requester verifies the integrity of ciphi′ and determines whether Hashciphi′ is equal to the location record LRi⋅LIi⋅LHi that the Owner has uploaded on the Blockchain. If the probability ϵv2 that the malicious Owner finds ciphi′≠ciphi and satisfies Hashciphi′=LRi⋅LIi⋅LHi is not negligible, it contradicts the collision resistance of the one-way hash function. Thus, the probability ɛv2 is negligible.In conclusion, the probabilityɛ4=ɛv1+ɛv2 that the attacker Owner returns the wrong location information to the Requester and implements the location deception is negligible.


### 5.5. Restorability

For theith location record LRi=PuboLIirecIdi−1osignatureo of the Owner in the Blockchain, the location information LIi=OpeHashiLHiSymCiphitimestampi, so the ones in LRi that contain the location information of the Owner are OpeHashi, LHi, and SymCiphi. Thereinto, SymCiphi=SEksym,xiyi, and key ksym is kept secret by the Owner. That is to say, the location record of the Blockchain contains the symmetric encrypted ciphertext of the coordinate xiyi of the specific location; only the Owner can decrypt the ciphertext SymCiphi to achieve recoverability of the original location.


## 5.1. Immutability

According to the principle of Blockchain, all subsequent blocksblocki1<i are constructed from the hash value Hashblocki−1 of the previous block, with the exception of the creation block. According to the difficulty value set by the system, the correct random number is found first so that the hash value of the data in the block header is less than or equal to the target hash value. Miners who have been verified by the whole system get the accounting right and are connected after blocki−1. The attacker who tampers with a record in the block must recalculate the SHA256 puzzle for that block and all subsequent blocks. The computational force must make the forged bifurcated chain become longer than the main chain. If the Owner modifies the location record in blocki−1, the proof of work must be redone for all blocks blockjj>i linked after it. A new fork is created, in order to make the chain length of the fork larger than that of the main chain of original Blockchain. Since the computing power mastered by the Owner is less than 51% of the whole system, the cost required to master 51% of the computing power in the actual system far exceeds the benefits obtained after a successful attack; the probability of the Owner producing a longer fork than the original Blockchain is negligible. Thus, the probability ϵ1 of location repudiation is negligible, while Owners illegally modify the location information already uploaded to the Blockchain.


## 5.2. Confidentiality

There are two types of records in the Blockchain, namely, the location record and the registration record. For the location recordsLRi=PuboLIirecIdj−1osignatureLoc, thereinto LIi=OpeHashiLHiSymCiphiTimestampi. In LRi, the ones that contain the location information of Owners are OpeHashi, LHi, and SymCiphi. Firstly, OpeHashi=Hashciphi and LHi=Hashxi|yi; if Miners recover ciphi or xiyi with the nonnegligible probability ɛh, the unidirectivity of the unidirectional hash function is contradicted. Therefore, the probability ɛh is negligible. Second, SymCiphi=SEksym,xiyi; if Miners, with the nonnegligible probability ɛs, can successfully decrypt the symmetric encryption plaintext without having the private key ksym of the Owner, the confidentiality of the symmetric encryption would be contradicted. Therefore, the probability ɛl=ɛh+ɛs of Miners making unauthorized access based on location information LRi in the Blockchain is negligible.For the registration recordsReg=idoxTreerootyTreerootsignaturereg, thereinto xTreeroot and yTreeroot are both root nodes of the Merkle hash tree. The root nodes are generated by the one-way hash operation performed iteratively by the leaves of the Merkle hash tree. If Miners recover the root of the Merkle hash tree with nonnegligible probability ɛr, the unidirectivity of the hash function is contradicted. Therefore, the probability ɛr of Miners inferring the plaintext of location information from the root node of the Merkle hash tree is negligible.In conclusion, the probabilityɛ2=ɛl+ɛr that the attacker can access the location information of Owners according to the records in the Blockchain is negligible under the condition of no authorization.


## 5.3. Multilevel Privacy Preserving

In the process of location sharing, the size of the location area obtained by the Requester that is not fully trusted is determined by the level of privacy protection. The privacy protection level corresponding to the Requester is set by the Owner according to the trust level. According to Algorithm1, the region R can be divided into the grid of different sizes at N levels. For the Requester, the Owner finds the location region partition line containing the original location point under the privacy-preserving level and returns the plaintext ciphertext combination of the four partition lines of the region to the Requester. The Requester determines the location of the region according to the plaintext xid1, xid2, yid3, and yid4 of the four dividing lines and verifies the integrity and authenticity of the dividing lines according to the ciphertext ciphid1x, ciphid2x, ciphid3y, and ciphid4y of the four dividing lines.If the Requester that is not fully trusted requests multiple locations from the Owners, each location region returned by the Owner consists of a combination of four split-line plaintext and order-preserving encrypted ciphertext, i.e.,borInfoid1=id1xid1ciphid1x. The Requester can obtain the plaintext and ciphertext combination of multiple dividing lines, including borInfoidx1,borInfoidx2,… and borInfoidy1,borInfoidy2,…. For the B-PPLS scheme, since the Requester is in the privacy-preserving level N, all the position areas generated by the divider line do not cross or overlap under the same privacy protection level. Therefore, it is completely unable to reduce the range of the received region by crossing and overlapping the divided regions for Requesters. There are two kinds of splitters in order-preserving encryption, kox≠koy, X≠Y, X′≠Y′; if the probability of the order-preserving cryptography association between borInfox and borInfoy is nonnegligible, it contradicts the security definition of OPE. Therefore, the probability ɛm of the attacker reducing the accepted region size through the association between borInfox and borInfoy’s OPE ciphertext is negligible.In a worst-case scenario, the Requester itself, or through collusion, knows all the split-line plaintext and ciphertext combinations of the Owner. The Requester has the same number of dividing lines perpendicular to thex-axis and the y-axis, all of which are 2N. In this case, we are just talking about the line that is perpendicular to the x-axis, and the same is true for the line that is perpendicular to the y-axis. According to reference [21], for any x∈m, its ciphertext Em,nx,k is computationally indistinguishable from Em,n∗x,f in the ideal OPE object. Thus, the OPE used in the B-PPLS scheme is safe. In the case of OPE security, for attackers with h combinations of plaintext and ciphertext, if h=ome,0<e<1, m3≤n. Then, the ciphertext Em,nx,k is given to the attacker; the probability that the attacker can completely recover the plaintext is negligible. Assume that the attacker has all the plaintext and ciphertext combinations of the dividing lines in the x-axis direction of the Owner after multiple location requests; the number of which is 2N. Because X3≤X′, thereinto X is the plaintext space of order-preserving encryption, X′ is the ciphertext space of order-preserving encryption, and 2N=ominX,Ye; it meets the security requirements. Suppose that the Requester knows all the plaintext and ciphertext combinations that are perpendicular to the x-axis. If the position coordinates li and abscess xi of the Owner are decrypted with a nonnegligible probability ɛx, it contradicts the definition of OPE security analysis. The same with the line that is perpendicular to the y-axis. Therefore, the probability ɛn=ɛx∗ɛy that the Requester can infer the exact position coordinates of the Owner is negligible.In conclusion, the probabilityɛ3=ɛm+ɛn that the Requester will violate the multilevel privacy preserving of the Owner by reducing the scope of the returned region or deducing the exact location coordinates of the Owner is negligible.


## 5.4. Verifiability

When the Requester is fully trusted by the Owner, the probability that the false location information returned by the Owner to the Requester can be verified by the Requester is negligible. That is to say,conRes′←SEksession,xi′yi′, xi≠xi′ and yi≠yi′; the probability of Requester validation is negligible. In the stage of location verification, it determines that whether Hashxi′yi′ is equal to the location record LRi⋅LIi⋅LHi that the Owner has uploaded on the Blockchain. If the Owner finds xi≠xi′ or yi≠yi′ with nonnegligible probability ϵv1 and makes Hashxi′yi′=LRi⋅LIi⋅LHi, it contradicts the collision resistance of the one-way hash function. Thus, the probability ϵv1 is negligible.When the Requester is not fully trusted by the Owner, the probability that the false privacy-preserving location information returned by the Owner to the Requester can be verified by the Requester is negligible. That is to say, if the Owner returnsfuzRes′=Encksession,ciphi′borInfo′nodes′xnodes′y to the Requester and ciphi′≠ciphi, borInfo′≠borInfo, nodes′x≠nodesx, and nodes′y≠nodesy, the probability of the returned location passing validation by the Requester is negligible. In the stage of location verification, the Requester verifies the integrity of ciphi′ and determines whether Hashciphi′ is equal to the location record LRi⋅LIi⋅LHi that the Owner has uploaded on the Blockchain. If the probability ϵv2 that the malicious Owner finds ciphi′≠ciphi and satisfies Hashciphi′=LRi⋅LIi⋅LHi is not negligible, it contradicts the collision resistance of the one-way hash function. Thus, the probability ɛv2 is negligible.In conclusion, the probabilityɛ4=ɛv1+ɛv2 that the attacker Owner returns the wrong location information to the Requester and implements the location deception is negligible.


## 5.5. Restorability

For theith location record LRi=PuboLIirecIdi−1osignatureo of the Owner in the Blockchain, the location information LIi=OpeHashiLHiSymCiphitimestampi, so the ones in LRi that contain the location information of the Owner are OpeHashi, LHi, and SymCiphi. Thereinto, SymCiphi=SEksym,xiyi, and key ksym is kept secret by the Owner. That is to say, the location record of the Blockchain contains the symmetric encrypted ciphertext of the coordinate xiyi of the specific location; only the Owner can decrypt the ciphertext SymCiphi to achieve recoverability of the original location.


## 6. Performance Evaluation

In this section, the performance of the proposed B-PPLS scheme is evaluated according to computation overhead. The experimental results can be divided into four parts, i.e., initialization, location record, location sharing, and location verification. Furthermore, the B-PPLS scheme is compared with other related schemes.


### 6.1. Datasets and Experimental Setup

#### 6.1.1. Datasets

We use the real datasets to verify the validity and efficiency of our methods. GeoLife datasets [35] have recorded the GPS trajectory of 182 users with 18670 trajectories in five years (from 2008/10 to 2012/8), which not only includes the daily activity (e.g., going home and working) but also includes the recreational activity (e.g., shopping, traveling, eating, and sports). Most of the data in GeoLife datasets lies in Beijing, and few of them in Europe or USA.


#### 6.1.2. Experimental Setup

All experiments are run on a computer with Intel i7-3770 3.40 GHz CPU and 8 GB RAM, 64 bit Windows 10 OS. The location data analysis and privacy-preserving algorithms of four stages are conducted on MATLAB 2014b. Because the trajectory data has been sampled by Geolife, the performance of initialization, location record, location sharing, and location verification in the B-PPLS scheme can be evaluated according to the Geolife datasets. The parameter setup of four stages is same. The hash function is SHA-256. The asymmetric cryptographic algorithm is RSA-1024. The OPE plaintext spaces are0−210, i.e., OPE (10), 0−220, i.e., OPE (20), and 0−230, i.e., OPE (30). According to the security requirements of OPE, the ciphertext space is set to the third power of the plaintext space.


### 6.2. Experimental Results on Computation Overhead

#### 6.2.1. Initialization

In the stage of initialization, the regionR is first iteratively partitioned N times by the Owner according to the quadtree. It represents that the initialization can achieve N different degrees of privacy preserving. Then, all the separators are performed with the OPE operation. Finally, two Merkle hash trees are generated by dividing lines perpendicular to the x-axis and perpendicular to the y-axis as leaf nodes.Figure4(a) shows that the overhead during the initial phase increases exponentially with the increase of N, in the case that the size of the plaintext space is constant. It exceeds 2500 ms, while N=8 and plaintext space is OPE (30). The reason is that the number of separators is 2N, so 2N OPE encryption operations are required during the initial phase. Because the overhead of calculating Merkle hash trees is lower than that of the OPE algorithm, the OPE algorithm occupies a large proportion during the initial stage of B-PPLS. Meanwhile, at the same privacy-preserving strength N, the different size of plaintext space for the OPE algorithm causes the difference of overhead. In this stage, the larger plaintext space can cause the slightly higher overhead and make OPE encryption operations less efficient.Figure 4
Computation overhead of four stages. (a) Initialization. (b) Location record. (c) Location sharing. (d) Location verification.
(a)(b)(c)(d)Therefore, the computation overhead of B-PPLS in the initialization stage increases exponentially with the increase ofN. The larger OPE plaintext space results in higher computation overhead. Although this phase is time-consuming, it can be implemented offline and only needs to be done once throughout the course of the solution.


#### 6.2.2. Location Record

As shown in Figure4(b), as the privacy protection level N increases, the computation overhead does not change significantly. That is to say, the privacy protection level N does not affect the computation overhead of Owners in the stage of location record. However, the increase of the OPE plaintext space will lead to the increase of computation overhead. When the plaintext space is OPE (10), the computation overhead in this stage is stable at around 24 ms. When the plaintext space is OPE (20), the computation overhead in this stage is stable at around 31 ms. When the plaintext space is OPE (10), the computation overhead in this stage is stable at around 37 ms. The reason is that the efficiency of the OPE algorithm can mainly affect the computation overhead at this stage, and the increase of the plaintext space will lead to the increase of the computation overhead.Therefore, the overhead of B-PPLS in the location record stage increases with the increase of OPE plaintext space. However, it is almost not affected by the privacy-preserving levelN, and the computation overhead of this stage is small overall.


#### 6.2.3. Location Sharing

In the stage of location sharing, the Requesters can be divided into full trust and incomplete trust according to the degree of trust by Owners. When the Requester is not fully trusted, the Owner selects the partition line surrounding its own location according to different privacy-preserving levels for the Requester. The plaintext of the partition line is returned to the Requester after combining it with OPE ciphertext. In this case, the computation overhead of Owners varies with privacy-preserving levelN in different plaintext spaces, i.e., OPE (10), OPE (20), and OPE (30). When the Requester is fully trusted, N=0 indicates that the Owner has no privacy preserving for the Requester, and the Owner will return its exact location information to the Requester.As shown in Figure4(c), regardless of whether the Requester is fully trusted or not, the broken lines of computation overhead under different parameters almost coincide. It is stable at about 12 ms and do not change with the increase of privacy-preserving level N. The reason is that the main operation performed at the stage of location sharing is symmetric encryption. The OPE ciphertext of the dividing line involved in this stage is generated during the stage of initialization, and the OPE ciphertext of the location information is generated in the stage of location record. If the operation of privacy preserving is conducted, the input length of symmetric encryption is affected by the size of the plaintext space and N. However, in this stage, the input length of symmetric encryption has little change under different parameters, which has almost no impact on the execution efficiency of symmetric encryption. All the parameters mentioned above have little influence on the computation overhead of this stage.Therefore, whether the Requester is fully trusted or not, the computation overhead of the B-PPLS location sharing phase is almost unaffected by privacy-preserving levelN and the OPE plaintext space, and the Owner takes less time in this stage.


#### 6.2.4. Location Verification

In the stage of location verification, the Requesters can also be divided into full trust and incomplete trust according to the degree of trust by Owners. When the Requester is not fully trusted, it verifies the integrity and authenticity of the received regional partition information through the location recordLRi and the registration record Regi on the Blockchain. When the Requester is fully trusted, i.e., N=0, it verifies the integrity of the location information only through the location record LRi of the Owners on the Blockchain.As shown in Figure4(d), the computation overhead of three curves corresponding to the different OPE plaintext spaces almost coincides when the Requester is not fully trusted. The reason is that the Requester only compares the results of OPE ciphertext and does not involve the operation of OPE encryption and decryption in the stage of location verification. Thus, the size of the plaintext space has no effect on this stage. The computation overhead increases linearly with the increase of privacy-preserving level N. The reason is that N is equal to the height of the Merkle hash tree in the registered record Regi. The height of the Merkle tree determines the length of the authentication path of the root node, that is, the number of hash operations.Therefore, when the Requester is not fully trusted, the computation overhead of the B-PPLS location verification phase is approximately linear with the size of the privacy-preserving levelN and is not affected by the size of the OPE plaintext space. When the Requester is fully trusted, the computational overhead of the Requester is less than that of the Requester that is not fully trusted and is not affected by N. Since only hash operation is involved in the location verification phase, the computational overhead in this stage is very small.


### 6.3. Scheme Comparison

The comparison of our proposed B-PPLS scheme with other location privacy-preserving schemes is shown in Table1. Our proposed B-PPLS scheme makes use of Blockchain and OPE technology to get good privacy preserving while also getting high data utility. Furthermore, the computation overhead of the proposed B-PPLS scheme is low. The scheme [31] relies on the third parties which cause the lower privacy preserving and data utility. The computation overhead of the scheme [31] is also high. Encryption-based technology is used by the scheme [32] in order to protect location privacy. However, the data utility is not guaranteed. The scheme [34] does not use the OPE technology, which leads to lower data utility. The differential privacy-based location privacy-preserving scheme [11] can provide the good privacy preserving and data utility, but the computation overhead is a little high.Table 1
Comparison with related schemes.
SchemesArchitecturesPrivacy-preserving technologiesPrivacy preserving and data utilityComputation overheadB-PPLSDecentralizedBlockchain and OPE technologyGood privacy preserving and high data utilityLow[31]CentralizedSpatial obfuscation technologyRelying on third parties while getting the lower data utilityHigh[32]DecentralizedEncryption-based technologyPrivacy preserving and data utility cannot be well balancedMedium[33]MultiserverUser collaborative-based technologyThe better the privacy preserving, the lower the data utilityMedium[34]DecentralizedBlockchain technologyGood privacy preserving, but low data utilityMedium[11]DecentralizedDifferential privacy-based technologyGood privacy preserving and data utilityMediumFigure5 shows the comparison on average computing delay. We can see that B-PPLS and scheme [34] have lower average computing delay with privacy-privacy level increase. Due to the characteristics of Blockchain technology, users’ location data can be protected effectively. However, the location privacy preserving of the scheme in [31] and [11] is achieved by location obfuscation, which causes the average computing delay increase with the privacy-privacy level increase. As shown in Figure 6, we can see that B-PPLS and scheme [11] have the better data utility than the other two schemes. The reason is that the OPE algorithm in B-PPLS can ensure that the order of the location is unchanged after encryption. Furthermore, because the differential privacy model can well ensure the consistency of the output results, the scheme [11] has the best data utility in four schemes. However, the computation overhead of the scheme [11] is higher than our proposed B-PPLS.Figure 5
Comparison on average computing delay.Figure 6
Comparison on data utility.


## 6.1. Datasets and Experimental Setup

### 6.1.1. Datasets

We use the real datasets to verify the validity and efficiency of our methods. GeoLife datasets [35] have recorded the GPS trajectory of 182 users with 18670 trajectories in five years (from 2008/10 to 2012/8), which not only includes the daily activity (e.g., going home and working) but also includes the recreational activity (e.g., shopping, traveling, eating, and sports). Most of the data in GeoLife datasets lies in Beijing, and few of them in Europe or USA.


### 6.1.2. Experimental Setup

All experiments are run on a computer with Intel i7-3770 3.40 GHz CPU and 8 GB RAM, 64 bit Windows 10 OS. The location data analysis and privacy-preserving algorithms of four stages are conducted on MATLAB 2014b. Because the trajectory data has been sampled by Geolife, the performance of initialization, location record, location sharing, and location verification in the B-PPLS scheme can be evaluated according to the Geolife datasets. The parameter setup of four stages is same. The hash function is SHA-256. The asymmetric cryptographic algorithm is RSA-1024. The OPE plaintext spaces are0−210, i.e., OPE (10), 0−220, i.e., OPE (20), and 0−230, i.e., OPE (30). According to the security requirements of OPE, the ciphertext space is set to the third power of the plaintext space.


## 6.1.1. Datasets

We use the real datasets to verify the validity and efficiency of our methods. GeoLife datasets [35] have recorded the GPS trajectory of 182 users with 18670 trajectories in five years (from 2008/10 to 2012/8), which not only includes the daily activity (e.g., going home and working) but also includes the recreational activity (e.g., shopping, traveling, eating, and sports). Most of the data in GeoLife datasets lies in Beijing, and few of them in Europe or USA.


## 6.1.2. Experimental Setup

All experiments are run on a computer with Intel i7-3770 3.40 GHz CPU and 8 GB RAM, 64 bit Windows 10 OS. The location data analysis and privacy-preserving algorithms of four stages are conducted on MATLAB 2014b. Because the trajectory data has been sampled by Geolife, the performance of initialization, location record, location sharing, and location verification in the B-PPLS scheme can be evaluated according to the Geolife datasets. The parameter setup of four stages is same. The hash function is SHA-256. The asymmetric cryptographic algorithm is RSA-1024. The OPE plaintext spaces are0−210, i.e., OPE (10), 0−220, i.e., OPE (20), and 0−230, i.e., OPE (30). According to the security requirements of OPE, the ciphertext space is set to the third power of the plaintext space.


## 6.2. Experimental Results on Computation Overhead

### 6.2.1. Initialization

In the stage of initialization, the regionR is first iteratively partitioned N times by the Owner according to the quadtree. It represents that the initialization can achieve N different degrees of privacy preserving. Then, all the separators are performed with the OPE operation. Finally, two Merkle hash trees are generated by dividing lines perpendicular to the x-axis and perpendicular to the y-axis as leaf nodes.Figure4(a) shows that the overhead during the initial phase increases exponentially with the increase of N, in the case that the size of the plaintext space is constant. It exceeds 2500 ms, while N=8 and plaintext space is OPE (30). The reason is that the number of separators is 2N, so 2N OPE encryption operations are required during the initial phase. Because the overhead of calculating Merkle hash trees is lower than that of the OPE algorithm, the OPE algorithm occupies a large proportion during the initial stage of B-PPLS. Meanwhile, at the same privacy-preserving strength N, the different size of plaintext space for the OPE algorithm causes the difference of overhead. In this stage, the larger plaintext space can cause the slightly higher overhead and make OPE encryption operations less efficient.Figure 4
Computation overhead of four stages. (a) Initialization. (b) Location record. (c) Location sharing. (d) Location verification.
(a)(b)(c)(d)Therefore, the computation overhead of B-PPLS in the initialization stage increases exponentially with the increase ofN. The larger OPE plaintext space results in higher computation overhead. Although this phase is time-consuming, it can be implemented offline and only needs to be done once throughout the course of the solution.


### 6.2.2. Location Record

As shown in Figure4(b), as the privacy protection level N increases, the computation overhead does not change significantly. That is to say, the privacy protection level N does not affect the computation overhead of Owners in the stage of location record. However, the increase of the OPE plaintext space will lead to the increase of computation overhead. When the plaintext space is OPE (10), the computation overhead in this stage is stable at around 24 ms. When the plaintext space is OPE (20), the computation overhead in this stage is stable at around 31 ms. When the plaintext space is OPE (10), the computation overhead in this stage is stable at around 37 ms. The reason is that the efficiency of the OPE algorithm can mainly affect the computation overhead at this stage, and the increase of the plaintext space will lead to the increase of the computation overhead.Therefore, the overhead of B-PPLS in the location record stage increases with the increase of OPE plaintext space. However, it is almost not affected by the privacy-preserving levelN, and the computation overhead of this stage is small overall.


### 6.2.3. Location Sharing

In the stage of location sharing, the Requesters can be divided into full trust and incomplete trust according to the degree of trust by Owners. When the Requester is not fully trusted, the Owner selects the partition line surrounding its own location according to different privacy-preserving levels for the Requester. The plaintext of the partition line is returned to the Requester after combining it with OPE ciphertext. In this case, the computation overhead of Owners varies with privacy-preserving levelN in different plaintext spaces, i.e., OPE (10), OPE (20), and OPE (30). When the Requester is fully trusted, N=0 indicates that the Owner has no privacy preserving for the Requester, and the Owner will return its exact location information to the Requester.As shown in Figure4(c), regardless of whether the Requester is fully trusted or not, the broken lines of computation overhead under different parameters almost coincide. It is stable at about 12 ms and do not change with the increase of privacy-preserving level N. The reason is that the main operation performed at the stage of location sharing is symmetric encryption. The OPE ciphertext of the dividing line involved in this stage is generated during the stage of initialization, and the OPE ciphertext of the location information is generated in the stage of location record. If the operation of privacy preserving is conducted, the input length of symmetric encryption is affected by the size of the plaintext space and N. However, in this stage, the input length of symmetric encryption has little change under different parameters, which has almost no impact on the execution efficiency of symmetric encryption. All the parameters mentioned above have little influence on the computation overhead of this stage.Therefore, whether the Requester is fully trusted or not, the computation overhead of the B-PPLS location sharing phase is almost unaffected by privacy-preserving levelN and the OPE plaintext space, and the Owner takes less time in this stage.


### 6.2.4. Location Verification

In the stage of location verification, the Requesters can also be divided into full trust and incomplete trust according to the degree of trust by Owners. When the Requester is not fully trusted, it verifies the integrity and authenticity of the received regional partition information through the location recordLRi and the registration record Regi on the Blockchain. When the Requester is fully trusted, i.e., N=0, it verifies the integrity of the location information only through the location record LRi of the Owners on the Blockchain.As shown in Figure4(d), the computation overhead of three curves corresponding to the different OPE plaintext spaces almost coincides when the Requester is not fully trusted. The reason is that the Requester only compares the results of OPE ciphertext and does not involve the operation of OPE encryption and decryption in the stage of location verification. Thus, the size of the plaintext space has no effect on this stage. The computation overhead increases linearly with the increase of privacy-preserving level N. The reason is that N is equal to the height of the Merkle hash tree in the registered record Regi. The height of the Merkle tree determines the length of the authentication path of the root node, that is, the number of hash operations.Therefore, when the Requester is not fully trusted, the computation overhead of the B-PPLS location verification phase is approximately linear with the size of the privacy-preserving levelN and is not affected by the size of the OPE plaintext space. When the Requester is fully trusted, the computational overhead of the Requester is less than that of the Requester that is not fully trusted and is not affected by N. Since only hash operation is involved in the location verification phase, the computational overhead in this stage is very small.


## 6.2.1. Initialization

In the stage of initialization, the regionR is first iteratively partitioned N times by the Owner according to the quadtree. It represents that the initialization can achieve N different degrees of privacy preserving. Then, all the separators are performed with the OPE operation. Finally, two Merkle hash trees are generated by dividing lines perpendicular to the x-axis and perpendicular to the y-axis as leaf nodes.Figure4(a) shows that the overhead during the initial phase increases exponentially with the increase of N, in the case that the size of the plaintext space is constant. It exceeds 2500 ms, while N=8 and plaintext space is OPE (30). The reason is that the number of separators is 2N, so 2N OPE encryption operations are required during the initial phase. Because the overhead of calculating Merkle hash trees is lower than that of the OPE algorithm, the OPE algorithm occupies a large proportion during the initial stage of B-PPLS. Meanwhile, at the same privacy-preserving strength N, the different size of plaintext space for the OPE algorithm causes the difference of overhead. In this stage, the larger plaintext space can cause the slightly higher overhead and make OPE encryption operations less efficient.Figure 4
Computation overhead of four stages. (a) Initialization. (b) Location record. (c) Location sharing. (d) Location verification.
(a)(b)(c)(d)Therefore, the computation overhead of B-PPLS in the initialization stage increases exponentially with the increase ofN. The larger OPE plaintext space results in higher computation overhead. Although this phase is time-consuming, it can be implemented offline and only needs to be done once throughout the course of the solution.


## 6.2.2. Location Record

As shown in Figure4(b), as the privacy protection level N increases, the computation overhead does not change significantly. That is to say, the privacy protection level N does not affect the computation overhead of Owners in the stage of location record. However, the increase of the OPE plaintext space will lead to the increase of computation overhead. When the plaintext space is OPE (10), the computation overhead in this stage is stable at around 24 ms. When the plaintext space is OPE (20), the computation overhead in this stage is stable at around 31 ms. When the plaintext space is OPE (10), the computation overhead in this stage is stable at around 37 ms. The reason is that the efficiency of the OPE algorithm can mainly affect the computation overhead at this stage, and the increase of the plaintext space will lead to the increase of the computation overhead.Therefore, the overhead of B-PPLS in the location record stage increases with the increase of OPE plaintext space. However, it is almost not affected by the privacy-preserving levelN, and the computation overhead of this stage is small overall.


## 6.2.3. Location Sharing

In the stage of location sharing, the Requesters can be divided into full trust and incomplete trust according to the degree of trust by Owners. When the Requester is not fully trusted, the Owner selects the partition line surrounding its own location according to different privacy-preserving levels for the Requester. The plaintext of the partition line is returned to the Requester after combining it with OPE ciphertext. In this case, the computation overhead of Owners varies with privacy-preserving levelN in different plaintext spaces, i.e., OPE (10), OPE (20), and OPE (30). When the Requester is fully trusted, N=0 indicates that the Owner has no privacy preserving for the Requester, and the Owner will return its exact location information to the Requester.As shown in Figure4(c), regardless of whether the Requester is fully trusted or not, the broken lines of computation overhead under different parameters almost coincide. It is stable at about 12 ms and do not change with the increase of privacy-preserving level N. The reason is that the main operation performed at the stage of location sharing is symmetric encryption. The OPE ciphertext of the dividing line involved in this stage is generated during the stage of initialization, and the OPE ciphertext of the location information is generated in the stage of location record. If the operation of privacy preserving is conducted, the input length of symmetric encryption is affected by the size of the plaintext space and N. However, in this stage, the input length of symmetric encryption has little change under different parameters, which has almost no impact on the execution efficiency of symmetric encryption. All the parameters mentioned above have little influence on the computation overhead of this stage.Therefore, whether the Requester is fully trusted or not, the computation overhead of the B-PPLS location sharing phase is almost unaffected by privacy-preserving levelN and the OPE plaintext space, and the Owner takes less time in this stage.


## 6.2.4. Location Verification

In the stage of location verification, the Requesters can also be divided into full trust and incomplete trust according to the degree of trust by Owners. When the Requester is not fully trusted, it verifies the integrity and authenticity of the received regional partition information through the location recordLRi and the registration record Regi on the Blockchain. When the Requester is fully trusted, i.e., N=0, it verifies the integrity of the location information only through the location record LRi of the Owners on the Blockchain.As shown in Figure4(d), the computation overhead of three curves corresponding to the different OPE plaintext spaces almost coincides when the Requester is not fully trusted. The reason is that the Requester only compares the results of OPE ciphertext and does not involve the operation of OPE encryption and decryption in the stage of location verification. Thus, the size of the plaintext space has no effect on this stage. The computation overhead increases linearly with the increase of privacy-preserving level N. The reason is that N is equal to the height of the Merkle hash tree in the registered record Regi. The height of the Merkle tree determines the length of the authentication path of the root node, that is, the number of hash operations.Therefore, when the Requester is not fully trusted, the computation overhead of the B-PPLS location verification phase is approximately linear with the size of the privacy-preserving levelN and is not affected by the size of the OPE plaintext space. When the Requester is fully trusted, the computational overhead of the Requester is less than that of the Requester that is not fully trusted and is not affected by N. Since only hash operation is involved in the location verification phase, the computational overhead in this stage is very small.


## 6.3. Scheme Comparison

The comparison of our proposed B-PPLS scheme with other location privacy-preserving schemes is shown in Table1. Our proposed B-PPLS scheme makes use of Blockchain and OPE technology to get good privacy preserving while also getting high data utility. Furthermore, the computation overhead of the proposed B-PPLS scheme is low. The scheme [31] relies on the third parties which cause the lower privacy preserving and data utility. The computation overhead of the scheme [31] is also high. Encryption-based technology is used by the scheme [32] in order to protect location privacy. However, the data utility is not guaranteed. The scheme [34] does not use the OPE technology, which leads to lower data utility. The differential privacy-based location privacy-preserving scheme [11] can provide the good privacy preserving and data utility, but the computation overhead is a little high.Table 1
Comparison with related schemes.
SchemesArchitecturesPrivacy-preserving technologiesPrivacy preserving and data utilityComputation overheadB-PPLSDecentralizedBlockchain and OPE technologyGood privacy preserving and high data utilityLow[31]CentralizedSpatial obfuscation technologyRelying on third parties while getting the lower data utilityHigh[32]DecentralizedEncryption-based technologyPrivacy preserving and data utility cannot be well balancedMedium[33]MultiserverUser collaborative-based technologyThe better the privacy preserving, the lower the data utilityMedium[34]DecentralizedBlockchain technologyGood privacy preserving, but low data utilityMedium[11]DecentralizedDifferential privacy-based technologyGood privacy preserving and data utilityMediumFigure5 shows the comparison on average computing delay. We can see that B-PPLS and scheme [34] have lower average computing delay with privacy-privacy level increase. Due to the characteristics of Blockchain technology, users’ location data can be protected effectively. However, the location privacy preserving of the scheme in [31] and [11] is achieved by location obfuscation, which causes the average computing delay increase with the privacy-privacy level increase. As shown in Figure 6, we can see that B-PPLS and scheme [11] have the better data utility than the other two schemes. The reason is that the OPE algorithm in B-PPLS can ensure that the order of the location is unchanged after encryption. Furthermore, because the differential privacy model can well ensure the consistency of the output results, the scheme [11] has the best data utility in four schemes. However, the computation overhead of the scheme [11] is higher than our proposed B-PPLS.Figure 5
Comparison on average computing delay.Figure 6
Comparison on data utility.


## 7. Conclusion

In this paper, we have proposed and implemented a Blockchain-enabled privacy-preserving location sharing (B-PPLS) scheme. To be specific, B-PPLS includes Owners, Requesters, and Miners. Owners share the location data to Requesters on the Blockchain. The data recorded on each block records different Owners’ location data arranged in the chronological order. Furthermore, four stages (i.e., initialization, location record, location sharing, and location verification) are designed to ensure the security of location sharing. Also, the algorithms corresponding to the stages are proposed, and the security analysis is given for the security objectives. Several simulations are carried out to evaluate the performance of our system. Analysis and evaluation show that our proposed scheme is effective and feasible for the sharing of location data. Further studies are still needed in the future. For example, how to mine the personalized features of Owners and Requesters in B-PPLS is an important problem to be further studied.



---

*Source: 9997887-2021-07-01.xml*