Blockchain-Enabled Privacy-Preserving Location Sharing Scheme for LBSNs

,


Introduction
e 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 Figure 1, three relational graphs (i.e., ① user-location, ② user-user, and ③ location-location) are generated in B-LBSNs. e user-location graph reflects the relation between the user and location, in which different locations are visited by different users. e user-user graph represents the relationship among users, which is built by utilizing Blockchain technology. erefore, the identity of users is authentic, and the information interaction between users is secure. e location-location graph represents the relationship among geographical locations according to semantical information.
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. e 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. erefore, 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) e 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. e 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 e framework of this paper is organized as follows. Section 2 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.

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

Location Privacy Preserving.
It involves the research on location privacy preserving when users share their location information to location requesters. e main methods of location privacy preserving are false location, k-anonymity, differential privacy, and cryptography. e method of false location is to realize the location privacy preserving by returning false location. e 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. e 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. is 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. e differential-and-distortion framework was designed by Wang et al. [10] to reduce the data loss during the process of location obfuscation. e 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. e 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.

Blockchain-Based Location Privacy
Preserving. In the current research, Blockchain-based location privacy-preserving schemes all have different degrees of security threats. e 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. e decentralized location privacypreserving 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.

Encryption Algorithms.
Order Preserving Encryption (i.e., OPE) [18][19][20] was first proposed by Agrawal [18] in 2004. After OPE, the ciphertext retains the original order of the plaintext. erefore, 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. en, 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. is 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, Mobile Information Systems 3 for any x ∈ [m], the ciphertext E m,n (x, k) of the constructed OPE symmetric encryption mechanism was computationally indistinguishable from the ciphertext E * m,n (x, k) of the ideal encryption object. us, the OPE symmetric encryption mechanism is secure. e 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 E m,n (x, k), the attacker is trying to recover the plaintext information x. If it satisfies h � o(m e ), 0 < e < 1, and m 3 ≤ n, the probability that the attacker restores plaintext x is a negligible function of security parameter logm. ese 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][23][24] and designed a data structure to support the verification of retrieval results. e 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. e 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][27][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.

Overview of B-PPLS Scheme
In this section, we introduce the system model, attack model, and security objectives of our proposed B-PPLS. Figure 2 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. e 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 "dualchannel" interaction on and off the chain. e detailed division of each role is summarized as follows.

Owners.
e 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 Owner A 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.

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

Miners.
Any user in the B-PPLS system can act as a miner. e 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). at 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.

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. e detailed explanation is as follows.

e Attack on Owners.
For the Owners, there are two reasonable assumptions. e 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. e 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. erefore, the above two assumptions are reasonable.
e 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.

e 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. e other one is that the malicious Requester tries to deduce the exact location coordinates of the Owner.

e 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. at is, without Owners' authorization, malicious Miners may access the personal location information recorded by Owners in the Blockchain.

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. e scheme needs to ensure the immutability of Owners on location records. e 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. e 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. e 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 Mobile Information Systems 5 quality. e adoption of the cryptography method can meet the needs of completely restoring the location information to the original location after privacy protection.

B-PPLS Scheme Designs
In this section, we elaborate the B-PPLS scheme designs. Figure 3 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. e 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. e detailed process is described as following.

4.1.
Initialization. Algorithm 1 shows the pseudocode of B-PPLS initialization. e main idea of this algorithm is to generate the Merkle hash tree. e Owners specify the geographically rectangular areas to represent the maximum range of activity which can be accessed. e rectangular area R is transformed in Cartesian coordinates, i.e., R � (x, y)|0 ≤ x ≤ X, 0 ≤ y ≤ Y . e areas R are iteratively partitioned in the quadtree manner as follows: 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: Owners perform OPE operations one by one along the divider lines perpendicular to the x-axis, i.e., ciph←OPE X,X′ (k x o , x i ), 1 ≤ i ≤ 2 N . OPE stands for orderpreserving encryption, X and X ′ are the plaintext space and cryptogram space, respectively, k x o is the secret key of Owners, and X 3 ≤ X ′ according to the security requirements of OPE. e operation perpendicular to the y-axis is similar to the operation perpendicular to the x-axis, and k y o ≠ k x o . All the splitter plaintext perpendicular x 1 , x 2 , . . . , x 2 N to the x-axis is bound one by one with the order-preserving encrypted splitter ciphertext ciph x 1 , ciph x 2 , . . . , ciph x 2 N by Owners. It generates node x i ←Hash(i‖x i ‖ciph x i ), 1 ≤ i ≤ 2 N , by the hash algorithm, and the Merkle hash tree xTree is generated as xTree←genMT(node x 1 , node x 2 , . . . , node x 2 N ). In a similar way, the Merkle hash tree yTree is generated as yTree←genMT(node y 1 , node y 2 , . . . , node y 2 N ). Finally, the registration record Reg←id o ‖xTree root ‖xTree root ‖signature reg is generated by signing the root node of the Merkle hash tree xTree and yTree. ereinto, signature reg ←ASE(Pri o , Hash(id o ‖xTree root ‖ yTree root )), ASE is the asymmetric encryption algorithm, and Pri o is the private key of the Owners. us, the operation of the initialization phase is completed.

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. Algorithm 2 shows the pseudocode of the location record generation algorithm.
e main idea of this algorithm is to generate the location record for Owners. Suppose that the Owner generates the ith location coordinate l i � (x i , y i ) and uploads the location information to the Blockchain. e order-preserving encryption of l i is operated by Owners, i.e., ciph x i ←OPE X,X′ (k x o , x i ) and ciph e location information of the Owner at the ith location is denoted as LI i ←OpeHash i ‖LH i ‖SymCiph i ‖Timestamp i . e location record of the Owner is generated as ) is the signature of the location record for the Owner.
Finally, the location record L i is broadcasted by the Owner and uploaded to the Blockchain by Miners according to the consensus mechanism. us, the operation of location record generation is completed.

Location Sharing.
Suppose that the Requester requests the ith 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 (x i , y i ). e other one is that the Owner has no full confidence in the Requester; then, the Owner returns the rectangular location area containing location coordinates (x i , y i ). Algorithm 3 shows the pseudocode of the location sharing algorithm.
When the Owner has full confidence in the Requester, the privacy-preserving level is n � 0. It means that the operation of privacy preserving is not performed. Firstly, Owners compute conRes←SE(k session , x i � � � �y i ) in order to encrypt the exact location. en, Owners send Res←conRes‖ASE(Pub o , k session ) to Requesters. Finally, the session key k session is obtained by making use of the private key of the Requester, in order to decrypt the location coordinates of the Owner, i.e., x i ′ ‖y i ′ ←SD(k session , conRes). When the Owner has no full confidence in the Requester, the operation of privacy preserving is necessary for location coordinates (x i , y i ). Firstly, the Owner computes the privacypreserving level n(1 ≤ n ≤ N) of the Requester and finds the privacy zone boundary x id1 , x id2 , y id3 , y id4 surrounding location l i under the privacy protection level n in region R. e zone divider information can be generated as borInfo← borInfo id1 � � � �borInfo id2 ‖borInfo id3 ‖borInfo id4 ; thereinto, 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 tree xTree and yTree, i.e., nodes x ← node x x1 , node x x2 , . . . and nodes y ← nodes y y1 , nodes y y2 , . . . . e Owner computes fuzRes←Enc(k session , ciph i ‖borInfo‖nodes x � � � nodes y ) and returns Res← fuzRes‖ASE(Pub r , k session ) to the Requester through the underchain channel. Finally, the location information of the Owner is decrypted by making use of the session key k session generated by the private key Pri r of the Requester. Because the border plaintext information x id1 ′ , x id2 ′ , y id3 ′ , y id4 ′ } is contained in borInfo ′ , the privacy-preserving location area is obtained by the Requester. e rest part of fuzRes is used to the location verification stage for the Requester. us, the operation of location sharing for the Owner and Requester is completed.   When the Owner has full confidence in the Requester, the precise location coordinates l i ′ � (x i ′ , y i ′ ) of the Owner can be acquired after conRes is decoded by the Requester. en, the Requester retrieves the location record LR i on the Blockchain generated during the location record phase. If , it shows that x id1 ≤ x i ≤ x id2 and y id 3 ≤ y i ≤ y id 4 ; location l i is in the region surrounded by x id1 , x id2 , y id3 , y id4 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. e computational complexity of the above four algorithms are O (n), O (1), O (1), and O (1), respectively. e 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. e 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. e 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. e 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.

Security Analysis
In this section, the security analysis is given corresponding to the five security attributes in the security objectives of Section 3, in order to prove the security of the B-PPLS scheme. Input: Privacy-preserving level n; Owner's public key Pub o ; Owner's location l i � (x i , y i ) Output: Shared location information LS (1) Owners execute: (2) If n � 0 then (3) conRes←SE(k session , x i ‖y i ); (4) Res←conRes‖ASE(Pub o , k session ); (5) Else If 1 ≤ n ≤ N then (6) find the border x id1 , x id2 , y id3 , y id4 in level n; (7) borInfo id 1 ←id 1 ‖x id1 ‖ciph x id1 ; (8) borInfo id 2 ←id 2 ‖x id2 ‖ciph x id2 ; (9) borInfo id 3 ←id 3 ‖y id3 ‖ciph y id3 ; (10) borInfo id 4 ←id 4 ‖y id4 ‖ciph y id4 ; (11) borInfo←borInfo id 1 ‖borInfo id 2 ‖borInfo id 3 ‖borInfo id 4 ; (12) node x ← node x x1 , node x x2 , . . . ; (13) node y ← node y y1 , node y y2 , . . . ; (14) fuzRes←Enc(k session , ciph i ‖borInfo‖nodes x � � �nodes y ); (15) Res←fuzRes‖ASE(Pub r , k session ); (16) End If (17) Requesters execute: 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 block i−1 . e attacker who tampers with a record in the block must recalculate the SHA256 puzzle for that block and all subsequent blocks. e computational force must make the forged bifurcated chain become longer than the main chain. If the Owner modifies the location record in block i−1 , the proof of work must be redone for all blocks block j (j > 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. us, the probability ϵ 1 of location repudiation is negligible, while Owners illegally modify the location information already uploaded to the Blockchain.

Confidentiality.
ere are two types of records in the Blockchain, namely, the location record and the registration record. For the location records In LR i , the ones that contain the location information of Owners are OpeHash i , LH i , and SymCiph i .
Firstly, OpeHash i � Hash(ciph i ) and LH i � Hash(x i |y i ); if Miners recover ciph i or x i ‖y i with the nonnegligible probability ε h , the unidirectivity of the unidirectional hash function is contradicted. erefore, the probability ε h is negligible. Second, SymCiph i � SE(k sym , x i ‖y i ); if Miners, with the nonnegligible probability ε s , can successfully decrypt the symmetric encryption plaintext without having the private key k sym of the Owner, the confidentiality of the symmetric encryption would be contradicted. erefore, the probability ε l � ε h + ε s of Miners making unauthorized access based on location information LR i in the Blockchain is negligible.
For the registration records Reg � id o ‖xTree root ‖ yTree root ‖signature reg , thereinto xTree root and yTree root are both root nodes of the Merkle hash tree. e 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. erefore, 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.

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. e privacy protection level corresponding to the Requester is set by the Owner according to the trust level. According to Algorithm 1, 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-Input: Location sharing information LS; Location record in the Blockchain LR; session key k session Output: Boolean variable LV (1) Initialize LV←False (2) If n � 0 then (11) yTree root ′ ←genMT(Hash(borInfo id1 ′ ), Hash(borInfo id 2 ′ ), nodes′ y ); (12) If xTree root ′ � xTree root and yTree root ′ � yTree root then e Requester determines the location of the region according to the plaintext x id1 , x id2 , y id3 , and y id4 of the four dividing lines and verifies the integrity and authenticity of the dividing lines according to the ciphertext ciph x id1 , ciph x id2 , ciph y id3 , and ciph y id4 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., borInfo id 1 � id 1 ‖x id1 ‖ciph x id1 . e Requester can obtain the plaintext and ciphertext combination of multiple dividing lines, including borInfo i d x1 , borInfo i d x2 , . . . and borInfo i d y1 , borInfo i d y2 , . . . . 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. erefore, it is completely unable to reduce the range of the received region by crossing and overlapping the divided regions for Requesters. ere are two kinds of splitters in order-preserving encryption, k if the probability of the order-preserving cryptography association between borInfo x and borInfo y is nonnegligible, it contradicts the security definition of OPE. erefore, the probability ε m of the attacker reducing the accepted region size through the association between borInfo x and borInfo y '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.
e Requester has the same number of dividing lines perpendicular to the x-axis and the yaxis, all of which are 2 N . 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 E m,n (x, k) is computationally indistinguishable from E * m,n (x, f) in the ideal OPE object. us, 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 � o(m e ), (0 < e < 1), m 3 ≤ n.
en, the ciphertext E m,n (x, 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 2 N . Because X 3 ≤ X ′ , thereinto X is the plaintext space of order-preserving encryption, X ′ is the ciphertext space of order-preserving encryption, and 2 N � o(min(X, Y) e ); 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 l i and abscess x i of the Owner are decrypted with a nonnegligible probability ε x , it contradicts the definition of OPE security analysis. e same with the line that is perpendicular to the y-axis. erefore, 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.

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.
at is to say, conRes ′ ← SE(k session , x i ′ ‖y i ′ ), x i ≠ x i ′ and y i ≠ y i ′ ; the probability of Requester validation is negligible. In the stage of location verification, it determines that whether Hash(x i ′ ‖y i ′ ) is equal to the location record LR i · LI i · LH i that the Owner has uploaded on the Blockchain. If the Owner finds x i ≠ x i ′ or y i ≠ y i ′ with nonnegligible probability ϵ v1 and makes Hash(x i ′ ‖y i ′ ) � LR i · LI i · LH i , it contradicts the collision resistance of the one-way hash function. us, 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. at is to say, if the Owner returns fuzRes ′ � Enc(k session , ciph i ′ ‖borInfo ′ ‖ nodes ′ x ‖nodes ′ y ) to the Requester and ciph i ′ ≠ ciph i , borInfo ′ ≠ borInfo, nodes ′ x ≠ nodes x , and nodes ′ y ≠ nodes y , 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 ciph i ′ and determines whether Hash(ciph i ′ ) is equal to the location record LR i · LI i · LH i that the Owner has uploaded on the Blockchain. If the probability ϵ v2 that the malicious Owner finds ciph i ′ ≠ ciph i and satisfies Hash(ciph i ′ ) � LR i · LI i · LH i is not negligible, it contradicts the collision resistance of the oneway hash function. us, 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.

Restorability.
For the ith location record LR i � Pub o ‖LI i ‖recId o i−1 ‖signature o of the Owner in the Blockchain, the location information LI i � OpeHash i ‖LH i ‖ SymCiph i ‖timestamp i , so the ones in LR i that contain the location information of the Owner are OpeHash i , LH i , and SymCiph i . ereinto, SymCiph i � SE(k sym , x i ‖y i ), and key k sym is kept secret by the Owner. at is to say, the location record of the Blockchain contains the symmetric encrypted ciphertext of the coordinate (x i ‖y i ) of the specific location; only the Owner can decrypt the ciphertext SymCiph i to achieve recoverability of the original location.

Performance Evaluation
In this section, the performance of the proposed B-PPLS scheme is evaluated according to computation overhead. e 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.

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. e 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. e parameter setup of four stages is same. e hash function is SHA-256. e asymmetric cryptographic algorithm is RSA-1024. e OPE plaintext spaces are 0 − 2 10 , i.e., OPE (10), 0 − 2 20 , i.e., OPE (20), and 0 − 2 30 , i.e., OPE (30). According to the security requirements of OPE, the ciphertext space is set to the third power of the plaintext space.

Experimental Results on Computation Overhead
6.2.1. Initialization. In the stage of initialization, the region R 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. en, 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. Figure 4(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). e reason is that the number of separators is 2 N , so 2 N 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. erefore, the computation overhead of B-PPLS in the initialization stage increases exponentially with the increase of N. e 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. Figure 4(b), as the privacy protection level N increases, the computation overhead does not change significantly.

Location Record. As shown in
at 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. e 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. erefore, 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 level N, and the computation overhead of this stage is small overall.

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. e 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 level N 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 Figure 4(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. e reason is that the main operation performed at the stage of location sharing is symmetric encryption. e 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. erefore, whether the Requester is fully trusted or not, the computation overhead of the B-PPLS location sharing phase is almost unaffected by privacy-preserving level N and the OPE plaintext space, and the Owner takes less time in this stage.

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 record LR i and the registration record Reg i 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 LR i of the Owners on the Blockchain.
As shown in Figure 4(d), the computation overhead of three curves corresponding to the different OPE plaintext spaces almost coincides when the Requester is not fully trusted. e 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.
us, the size of the plaintext space has no effect on this stage. e computation overhead increases linearly with the increase of privacypreserving level N. e reason is that N is equal to the height of the Merkle hash tree in the registered record Reg i . e height of the Merkle tree determines the length of the authentication path of the root node, that is, the number of hash operations. erefore, 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 privacypreserving level N 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. e comparison of our proposed B-PPLS scheme with other location privacy-preserving schemes is shown in Table 1. 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. e scheme [31] relies on the third parties which cause the lower privacy preserving and data utility. e 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. e scheme [34] does not use the OPE technology, which leads to lower data utility. e 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. Figure 5 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. e 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.

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. e 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 Good privacy preserving and high data utility Low [31] Centralized Spatial obfuscation technology Relying on third parties while getting the lower data utility High [32] Decentralized Encryption-based technology Privacy preserving and data utility cannot be well balanced Medium [33] Multiserver User collaborative-based technology e better the privacy preserving, the lower the data utility Medium [34] Decentralized Blockchain technology Good privacy preserving, but low data utility Medium [11] Decentralized Differential privacy-based technology Good privacy preserving and data utility Medium

Data Availability
e data used to support the findings of the study are included within the article.

Conflicts of Interest
e authors declare that they have no conflicts of interest.