Keywords

1 Introduction

Social networks are widely used for various applications. With the ubiquitous use of mobile devices and a rapid shift of technology accessing to social networks, people are able to exchange real-time information such as idea, current status and location with their friends conveniently. With the wide spread of GPS and Mobile Internet, mobile social network applications such as Weibo and Twitter with location-based service (LBS) are very popular.

Location sharing services which helps people to share their locations with their nearby friends is one significant building block to implement LBSs over social networks. However, behind the convenience brought by location sharing in social networks, there comes an indispensable security risk of privacy. Most location sharing applications need update user location information to provide better services despite the possibility of user privacy violation [1]. The leak of user identity and location information will increase the risk of adversary tracking the daily life of the user or will receive customized advertisements which is unwilling or even revealing his private activities such as visiting a bank or going to a hospital [2].

Privacy protection for location sharing services over social network [3,4,5,6,7] has received much attention in recent years. However, they are not suitable for social network. Furthermore, little research so far can provide identity privacy, location privacy and user relationship privacy at the same time.

In order to deal with the above challenges, we propose a Privacy-preserving Protocol for location Sharing in social networks (PPS). Different from existing work, the proposed protocol can support perfect privacy for location sharing services in social networks.

The rest paper is organized as follows. Section 2 introduces the system. Section 3 proposes PPS, the privacy-preserving protocol in detail. The simulation results are given in Sect. 4. Finally, we conclude the paper in Sect. 5.

2 System Initialization

The system consists of Location Server (LS), mobile users and Social Network Server (SNS). In order to protect the user privacy, the user identities, relationship (also known as users friends list) and locations are separately stored in SNS and LS. Thus, LS cannot infer the users relationship and user identity while SNS cannot obtain the users current locations. Specifically, we make the following configuration of the three components.

  • Each user, say v generates his own public/private key pair (\(puk_v,prk_v\)). The public key \(puk_v\) is shared with LS and SNS. In addition, v shares its symmetric key \(sk_v\), named ‘friend key’ with his friends.

  • SNS is pre-loaded a hash function H, a public/private key pair (\(puk_S, prk_S\)) and a bloom filter BF. SNS shares its \(puk_S\) with all the registered users and LS. The hash function H is used to compute the real/fake location tags and fake IDs. We use BF to conceal the user relationship.

  • LS is pre-loaded its asymmetric key pair \((puk_L, prk_L)\). Then, LS shares its public key, say \(puk_L\) with SNS.

3 Privacy-Preserving Protocol

A privacy-preserving protocol, named PPS is presented for location sharing services in social network. The purpose of PPS are (a) to manage users’ relationships and user identities by SNS while proting users’ locations from; (b) to manage users’ locations by LS while preventing users’ identities and user relationships from inferring by LS. Specifically, PPS includes three processes: user registration, location management, nearby friends query.

3.1 User Registration

Before using the location sharing service, a mobile user, say v has to register at the SNS. Then, SNS stores vs personal profile and his friends’ information into SNS. The user registration process is as follows:

  1. (a)

    User v sends a registration request to SNS.

  2. (b)

    SNS replies a message \({<}MR, ID_v, puk_S{>}\) to v, where MR is the message type field, \(ID_v\) is the unique ID generated for v by SNS.

  3. (c)

    v sends the message \({<} MR, puk_v, FS, df_v, ds_v {>}\) to SNS, where \(FS=\{ID_{v,i}|1\le i\le M\}\) is the set of v’s friend. M is the total number of vs friends. \(ID_{v,i}\) denotes the ID of vs i-th friends. \(ds_v\) stands for the distance within which v would like to share his location with strangers. \(df_v\) is the distance within which v would like to share his location with his friends.

  4. (d)

    v exchanges his friend key with each of his friends.

  5. (e)

    SNS inserts v’s friend information FS and his personal profile into user information table (as can be seen in Fig. 1) and friend information table (as can be seen in Fig. 1) respectively.

Fig. 1.
figure 1

Data storage structure of SNS.

3.2 Location Management

Once a user moves to some new place, he has to submit his location into LS. Take note that the user doesnt want to send his real location directly to LS as LS can infer his identity through his sensitive location or his path.

In order to update the users location privately, v firstly sends his encrypted location spot other than his real location \(l_v\) to SNS, where \(spot= E_{puk_L} (l_v, E_{sk_v }(l_v))\). Then, SNS anonymizes the vs identity. Finally, in order to hide vs location, SNS generates k-1 fake locations and sends k locations to LS. Particularly, \(k-1\) fake locations are randomly generated which are far away from v and scattered throughout a large area, say the city. Take note that since each location update relates with a new and different fake ID, the location information table in LS cannot meet the storage requirement resulted by the infinitely increasing location updates. Thus, LS deletes old entries from the location information table after a period of time. Specifically, this sub-protocol performs the following seven steps.

  1. (a)

    Once v moves to a new place \(l_v\), v sends SNS a location update notification message \({<}MU, spot, t, sig_v{>}\), where MU, spot, t and \(sig_v\) stand for the message type, encrypted location, timestamp and signature respectively. Specifically, spot is of the form \(E_{puk_L}(l_v, E_{sk_v}(l_v))\). The timestamp is used to defend against replay attack. The signature is of the form \(E_{prk_v}(ID_v, t)\).

  2. (b)

    SNS verifies the signature \(sig_v\).

  3. (c)

    SNS generates a unique fake ID, \(FID_v=H(ID_v\oplus t_c)\) for user v, where \(t_c\) denotes the current time.

  4. (d)

    SNS generates \(k-1\) scattered fake locations randomly which are far away from v.

  5. (e)

    SNS generates k location tags, \(\{tag_i|1\le i\le k\}\) which is used to identify real location from fake ones. If \(tag_i=H(ID_v)\), the location related with \(tag_i\) is real. If \(tag_i=H(ID_v\oplus i)\), the related location is fake.

  6. (f)

    SNS sends the message \({<}MU, FID_v, \{spot_i, tag_i|1\!\le \! i\!\le \! k\}, df_v,ds_v, t, sig_S {>}\) including k locations to LS, where \(spot_i\) and \(tag_i\) are the i-th location and its corresponding location tag respectively. Specifically, \(spot_i= E_{puk_L}(loc_i, E_{sk_v}(loc_i))\) and \(sig_S=E_{prk_S}(FID_v, t)\).

  7. (g)

    By decrypting \(\{spot_i |1\le i\le k\}\) from the received message, LS obtains k locations \(\{(loc_i, E_{sk_v}(loc_i) |1\le i\le k\}\).

3.3 Nearby Friends Query

In order to query the users friends nearby in a privacy-preserving way, the following steps are performed.

  • v sends the request message \({<}MNFQ, ID_v, t, sig_v{>}\) to SNS, where MNQF denotes the message type field.

  • SNS verifies the signature \(sig_v\).

  • SNS generates the bloom filter BF including vs friends information.

  • SNS sends the query message \({<}MNFQ, FID_v, BF, t, sig_S{>}\) to LS.

  • LS retrieves k locations of \(FID_v\), say \(\{l_i|1\le i\le k\}\).

  • For each location, say \(l_i\), LS finds v’s friends around \(l_i\) through BF and obtains the set \(N_i\). Each element of \(N_i\) has the form \((FID_{v'}, E_{sk_{v'}}(l_{v'}), tag_{v'})\) satisfying that the distance between \(l_{v'}\) and \(l_i\) is no more than \(min\{df_v, df_{v'}\}\).

  • LS sends all its nearby friends \({<}MNFQ, FID_v, \{N_i^{}|1\le i\le k\}, t, sig_L {>}\) to SNS, where \(sig_L= E_{prk_L} (FID_v, t)\).

  • SNS removes the element with fake location from \(N_i^{}\).

  • Considering the false positive results resulted by the bloom filter, SNS has to remove the strangers from \(N_i^{}\) according to vs friend information table (see Fig. 1). Then, SNS can obtain the real friends set \(N_i^{''}\).

  • For \(\{N_i^{''}|1\le i\le k\}\), SNS replaces each fake ID with real ID and obtains \(N_v=\{ID_j, E_{sk_j}(l_j) |1\le j\le q\}\), where q is the number of vs nearby friends.

  • SNS sends \(N_v\) to v.

  • v decrypts \(N_v\) and obtains the real locations of vs nearby friends.

Fig. 2.
figure 2

Decryption by AES

Fig. 3.
figure 3

Decryption by RSA

4 Simulation

Since mobile devices are much more resource constrained compared with wired device, we examine the acceptability and feasibility of PPS on mobile devices. AES and RSA are chosen by us for symmetric cryptography and asymmetric cryptography respectively. All simulation is executed on Huawei NEM-AL10 smartphone running Android 6.0 operation system.

Figures 2 and 3 show the average execution time for data decryption by AES and RSA respectively. It is observed from Fig. 2 that AES takes more time for decryption as the users nearby friends increases. We can also observe that even though there are as many as 30 friends around the user, no more than 35 ms is needed by AES. Obviously, it is acceptable for current mobile devices. Similarly, we can see from Fig. 3 that the time RSA takes for decryption grows with the increasing number of the user’s nearby strangers. When the number of strangers around the user is as many as 30, the time cost for RSA is less than 300 ms which is acceptable.

5 Conclusion

In this paper, we firstly propose a privacy protection protocol for social network location sharing services (PPS). Extensive experimental results demonstrate that, different from previous research, not only execution is possible but also convenient on the mobile device that requests location sharing over social network.