article in press - ایران عرضهiranarze.ir/wp-content/uploads/2016/11/e661.pdf · article in...

ARTICLE IN PRESS

JID: COMCOM [m5G; April 6, 2016;13:52 ]

Computer Communications xxx (2016) xxx–xxx

Contents lists available at ScienceDirect

Computer Communications

journal homepage: www.elsevier.com/locate/comcom

ABAKA: A novel attribute- based k- anonymous collaborative

solution for LBSs

Tooska Dargahi a , Moreno Ambrosin

b , Mauro Conti b , ∗, N. Asokan

c Q1

a Department of Computer Engineering, West Tehran Branch, Islamic Azad University, Tehran, Iran b Department of Mathematics, University of Padua, Padua, Italy c Department of Computer Science, Aalto University and University of Helsinki, Finland

a r t i c l e i n f o

Article history:

Received 19 August 2015

Revised 17 February 2016

Accepted 7 March 2016

Available online xxx

Keywords:

Location- based services

Privacy

k -anonymity

p -sensitivity

Ciphertext- policy attribute- based encryption

a b s t r a c t

The increasing use of mobile devices, along with advances in telecommunication systems, increased the

popularity of Location-Based Services (LBSs). In LBSs, users share their exact location with a potentially

untrusted Location-Based Service Provider (LBSP). In such a scenario, user privacy becomes a major con-

cern: the knowledge about user location may lead to her identification as well as a continuous tracing

of her position. Researchers proposed several approaches to preserve users’ location privacy. They also

showed that hiding the location of an LBS user is not enough to guarantee her privacy, i.e., user’s pro-

file attributes or background knowledge of an attacker may reveal the user’s identity. In this paper we

propose ABAKA, a novel collaborative approach that provides identity privacy for LBS users considering

users’ profile attributes. In particular, our solution guarantees p -sensitive k -anonymity for the user that

sends an LBS request to the LBSP. ABAKA computes a cloaked area by collaborative multi-hop forwarding

of the LBS query, and using Ciphertext-Policy Attribute-Based Encryption (CP-ABE). We ran a thorough set

of experiments to evaluate our solution: the results confirm the feasibility and efficiency of our proposal.

© 2016 Elsevier B.V. All rights reserved.

1. Introduction 1

With the rapid development of mobile devices and advances 2

of telecommunications, mobile users tend to have ubiquitous ac-

Q2

3

cess to information such as traffic prediction or location map data. 4

Location-Based Services (LBSs) are the best examples of this new 5

trend, allowing mobile users to receive information based on their 6

geographical position [1] . Based on their location, mobile users can 7

access several types of information and services, e.g., getting the 8

position of the nearest gas station, restaurant or hospital. 9

An LBS consists of two major entities: a user (from now on 10

referred also as issuer of a query) who is interested in acquir- 11

ing location-based service, and a Location-Based Service Provider 12

(LBSP) which provides the desired location-based service to the is- 13

suer. To obtain such a service, the issuer sends her geographical 14

location, along with her identity and the query to the LBSP. Unfor- 15

tunately, some queries (such as searching for the nearest hospital 16

specialized in a particular disease) may reveal privacy-sensitive in- 17

formation about the issuer. 18

The growing interest of smartphone users in using LBSs leads

Q3

19

to two major privacy concerns: location privacy and identity privacy 20

∗ Corresponding author. Tel.: +3904 982714 88.

E-mail address: [email protected] (M. Conti).

(also known as query privacy ). The former refers to preventing the 21

disclosure of the exact location of an issuer, while the latter is the 22

ability of concealing the link between her identity and her query. 23

These two concepts are complementary, and therefore, guarantee- 24

ing both location and identity privacy for an issuer becomes a chal- 25

lenging task. Researchers proposed several solutions providing lo- 26

cation and identity privacy in the context of LBSs (examples can 27

be found in [2] ). The location privacy problem has also been stud- 28

ied extensively in other contexts such as sensor networks [3] , and 29

cloud computing [4] . 30

A popular tool used in the literature to guarantee user’s iden- 31

tity privacy, in the context of LBSs, is the concept of k -anonymity 32

[5] . This concept refers to a set of k users in which a target 33

user is indistinguishable (with respect to her location) from the 34

other k − 1 individuals in the set. However, according to [6] , in 35

the presence of an attacker with background knowledge about a 36

user’s profile attributes, we can only guarantee k -anonymity by 37

considering anonymity sets in which all the users have the same 38

profile attributes. Furthermore, the authors in [7] proved that k - 39

anonymity is not sufficient to protect the privacy of an individual’s 40

attributes in a dataset, and might not prevent the disclosure of 41

sensitive attributes for the user. With respect to sensitive attributes , 42

we refer to a precise definition in [8] : “an attribute whose values 43

may be confidential for an individual (subject to her/his preferences) ”. 44

http://dx.doi.org/10.1016/j.comcom.2016.03.002

0140-3664/© 2016 Elsevier B.V. All rights reserved.

Please cite this article as: T. Dargahi et al., ABAKA: A novel attribute-based k-anonymous collaborative solution for LBSs, Computer

Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.03.002


http://www.ScienceDirect.com

http://www.elsevier.com/locate/comcom

mailto:[email protected]



2 T. Dargahi et al. / Computer Communications xxx (2016) xxx–xxx

ARTICLE IN PRESS


Indeed, in the context of LBSs, the semantics of an issued query 45

might allow the LBSP to infer sensitive attributes of an issuer’s pro- 46

file, or even her identity [9] . 47

In order to address this problem, researchers proposed a solu- 48

tion called p -sensitive k -anonymity [7,9,10] , in which at least p dif- 49

ferent values for each group of sensitive attributes are used. In the 50

context of LBSs, this translates in ensuring that the anonymity set 51

for an issuer contains individuals with diverse values for a spe- 52

cific set of privacy-sensitive attributes. In this paper, inspired by 53

the concept of “personalized privacy preservation” by Xiao and Tao 54

in [8] , we give the opportunity to the issuer of a query to decide 55

her preferences in sensitive attributes, based on her query content 56

and physical location. We provided this feature for the issuer, due 57

to the fact that an attribute could be sensitive for a query in special 58

location, and insensitive for another query in another location- (we 59

will further clarify this matter in the following). Before introducing 60

the key contribution of the paper, we present a running example. 61

Medical help example. Consider a set of smartphone users in a 62

geographical area. We assume that each user is assigned a pro- 63

file that consists of five attributes: { Gender , Age , Nationality , Job , 64

Zip - code }. Suppose a user u 1 is a 19-year-old Finnish girl living in 65

Italy. She is looking for a pregnancy help center near her house, 66

where the doctors are able to speak English. She sends an LBS 67

query Q = “where is the nearest pregnancy help center with English 68

speaking doctors?” and wants to cloak her location while being 9- 69

anonymous. In this example, based on the content of the query, 70

the attributes Gender and Zip - code should be identical between all 71

the users in the anonymity set (i.e., providing profile k -anonymity). 72

Moreover, based on the semantics of the issued query, Age and Na- 73

tionality are sensitive attributes of u 1 . It should be noted that age 74

and nationality are not sensitive attributes per se, but due to the 75

fact that the issuer is in Italy, her nationality could reveal her iden- 76

tity. Moreover, her query semantics (i.e., being pregnant) strongly 77

relates to her age. Therefore, we consider these two attributes to 78

be her sensitive attributes. Assume that she computes a cloaked 79

area using one of the existing k -anonymity preserving methods, 80

and81

ing82

the83

for84

oth85

kno86

am87

con88

cou89

the90

acc91

the92

in 93

ano94

pro95

bei96

Con97

An98

pro99

acc100

exi101

pri102

sur103

[6]104

app105

as 106

Fig. 1. Example of CP-ABE encryption and decryption.

In this paper, we make the following contributions: 107

• We propose ABAKA, the first privacy-preserving LBS system that 108

guarantees p-sensitive k-anonymity running a TTP-free protocol 109

between participating users ( Section 4 ). In particular, ABAKA 110

has the following features: 111

– It cloaks the exact location of a user into a cloaked area of 112

arbitrary size, by ensuring that (at least) k − 1 collaborat- 113

ing users will forward a query in a random multi-hop path 114

within the cloaked area. 115

– ABAKA guarantees p -sensitivity by ensuring that the collab- 116

orating users in the anonymity set, which will forward the 117

query, have specific attributes selected by the issuer. Each 118

issuer can select a desired set of attributes based on the se- 119

mantics of the query she wants to send. In particular, with 120

ABAKA she can decide: (i) which attributes need to be iden- 121

tical within an anonymity set; and (ii) which attributes are 122

sensitive, and thus need to have p different values within 123

the anonymity set. 124

– ABAKA adopts Ciphertext-Policy Attribute-Based Encryption 125

(CP-ABE) [12] , in order to apply fine-grained access control 126

over encrypted data, by defining high-level access policies 127

as a combination of attributes. CP-ABE allows the issuer to 128

specify attribute-based policies on the query; in this way, 129

she ensures that other k − 1 collaborative users have the de- 130

31

32

33

• 34

35

36

37

38

39

2. 40

41

Att 42

Bas 43

int 44

AB 45

enc 46

In 47

der 48

wa 49

Pl

Co

sends her query to the LBSP. Given the fact that she is look-

for an English speaking doctor, a malicious LBSP can infer that

issuer is foreigner. Moreover, suppose that there are only two

eign users in her cloaked area: one 19 years old ( u 1 ) and the

er 50 years old. In such case, if the attacker has this background

wledge, he can infer that the issuer is likely to be u 1 . This ex-

ple emphasizes the fact that, based on the query semantics and

sidering the attacker’s background knowledge, some attributes

ld be sensitive in specific scenarios and reveal the identity of

issuer. A proper privacy preserving solution should take into

ount sensitive attributes of u 1 , according to the semantics of

query. For example, a solution could provide an anonymity set

which all the k users are non-Italian (i.e., providing profile k -

nymity) and there are enough diversity in age attribute (i.e.,

viding p -sensitivity considering the more probable values for

ng pregnant).

tribution. In this paper, we propose ABAKA (Attribute-Based k -

onymous collaborative solution for LBSs), a novel solution to

vide both identity, and location privacy for LBS users taking into

ount the profile attributes of the users. Our motivation is the

sting limitations of the prior research in the area of LBS users’

vacy: on the one hand, those researches which attempt to en-

e k-anonymity considering the profile of the users (such as in

) are centralized; and on the other hand, the existing distributed

roaches do not consider profile attributes of the LBS users (such

in [11] ).

be 50

the 51

the 52

as

( Ag

set

ease cite this article as: T. Dargahi et al., ABAKA: A novel attribute-b

mmunications (2016), http://dx.doi.org/10.1016/j.comcom.2016.03.002

sired attributes. 1

– ABAKA ensures the confidentiality of the query, by using 1

public key encryption. 1

We run a systematic performance evaluation of ABAKA using 1

two different datasets ( Section 5.1 ) and a thorough evalua- 1

tion of the computational overhead imposed by cryptographic 1

processing required by ABAKA ( Section 5.2 ). Our evaluation 1

demonstrates that ABAKA is feasible on both smartphone and 1

PC platforms. 1

Background on attribute- based encryption 1

In what follows, we introduce the fundamental concepts about 1

ribute-Based Encryption (ABE), and Ciphertext-Policy Attribute- 1

ed Encryption (CP-ABE) in particular. In 2005, Sahai and Waters 1

roduced a Fuzzy Identity-Based Encryption scheme [13] , called 1

E. This scheme is a public key encryption protocol that allows an 1

ryptor to specify fine-grained access control policies over data. 1

this scheme, each user is assigned a set of attributes (e.g., Gen- 1

, Age , or Job ). The data owner encrypts a plaintext in such a 1

y that all the users that have a specific set of attributes will 1

able to decrypt the ciphertext (i.e., if user’s attributes satisfy 1

policy over the data). CP-ABE [12] is a type of ABE in which 1

access policy is included into the ciphertext, and expressed 1

a combination of attributes. An example of such a policy is: 153

e = 19 ∧ Gender = f emale ) ∨ ( Nat ionalit y = Italian ) (see Fig. 1 ). 154

Each user has a private decryption key, which represents the 155

of attributes she owns. She will be able to decrypt a ciphertext 156

ased k-anonymous collaborative solution for LBSs, Computer


T. Dargahi et al. / Computer Communications xxx (2016) xxx–xxx 3

ARTICLE IN PRESS


cy 157

ey 158

te 159

160

: 161

t- 162

163

A , 164

r- 165

166

n } , 167

p- 168

169

ed 170

a 171

s- 172

173

er 174

al. 175

is- 176

to 177

to 178

n- 179

a 180

es. 181

ng 182

ed 183

ct 184

rs. 185

BE 186

ur 187

ell 188

189

190

ns 191

rts 192

193

194

cal 195

is 196

ne 197

its 198

he 199

he 200

i- 201

ia 202

WiFi) via a single-hop or a multi-hop route. Moreover, we assume 203

that users ignore received packets that are not intended for them 204

(which they could receive due to the broadcast nature of the wire- 205

less communication). We consider the ad hoc model due to the 206

increasing trend in opportunistic networks and device-to-device 207

communications, where several mobile devices (e.g., smartphones) 208

collaborate in order to forward messages using wireless technolo- 209

gies, such as Bluetooth or WiFi [15,16] . This model has been exten- 210

sively used and analyzed in several works in the literature, such 211

as [15,17–20] . 212

We assume that each user is assigned a profile which consists 213

of a set of attributes A = { A 1 , A 2 , . . . , A n } . These attributes can be 214

of different types: personal information (e.g., gender), employment 215

In 216

t- 217

e }. 218

on 219

t- 220

at 221

n- 222

st 223

on 224

in 225

t- 226

er 227

ch 228

he 229

in 230

e. 231

es 232

le- 233

he 234

a 235

g- 236

al 237

e 238

239

k L , 240

nd 241

er, 242

ies 243

h- 244

rs 245

is 246

te 247

lo- 248

of 249

ty. 250

er 251

o- 252

er 253

te 254

ur 255

u i , 256

ill 257

ng 258

a 259

260

e- 261

rs 262

ll- 263

ot 264

ti- 265

se 266

ch 267

268

Table 1

Notation table.

Notation Description

Q , R Location-based query and response,

respectively

s , r Issuer-generated random numbers

pk L , sk L Respectively, public and private key pair of the

LBSP

k u , sk u Respectively, symmetric key and private

CP-ABE key of u

k r Symmetric key of collaborating users

pk Public CP-ABE key

CpabeEnc pk ( ptxt , p ) Encryption of a plaintext ptxt applying a policy

p , with CP-ABE

Enc k ( ptxt ) Symmetric encryption of a plaintext ptxt , using

key k

if and only if a subset of her attributes satisfies the access poli

on the data. By construction, in the CP-ABE scheme only the k

issuer (i.e., a Certificate Authority) is able to generate new priva

keys, therefore preventing collusion attacks [12] .

In general, a CP-ABE scheme provides the following functions

• Setup. It takes as input an implicit security parameter, and ou

puts the public key pk , and the master key MK .

• Encryption. It takes as input a message M , an access policy

and the public key pk , and outputs the corresponding ciphe

text E .

• KeyGen. It takes as input a set of attributes A = { A 1 , A 2 , . . . , A

the master key MK and the public key pk . It outputs a decry

tion key D reflecting the given attributes.

• Decryption. It takes as input the ciphertext E that is encrypt

under the access policy P ; the decryption key D representing

set of attributes γ ; and the public key pk . It outputs the me

sage M if and only if A “satisfies” the access policy P .

Several researches on LBS context adopt ABE to provide eith

access control or location privacy. For example, in [4] , Zhu et

used KP-ABE scheme in order to: (i) protect the privacy of the

suer against LBSP by enforcing the user authentication process

be accomplished on the client-side, and (ii) control the access

exchanged data between the issuer and the LBSP through defi

ing access policies. In another work, Yang et al. [14] proposed

privacy preserving method for vehicular location based servic

In this scheme, each user encrypts her location information usi

ABE, while defining desired access policy, and shares her encrypt

location in online social sites. Leveraging ABE, the authors prote

the location information of the users against third party attacke

Different from the state-of-the-art, for the first time, we adopt A

in ABAKA in order to find k − 1 collaborating users who have o

desired attributes in their profiles, to provide p -sensitivity as w

as k -anonymity.

3. Model and assumptions

In this section, we provide some definitions and assumptio

that will be used in the remainder of the paper. Table 1 repo

the used notation.

3.1. System model

We consider a set of users U = { u 1 , u 2 , . . . , u m

} in a geographi

area. Each user can be a potential LBS user (i.e., an issuer) and

equipped with a location-aware wireless device (e.g., smartpho

or tablet) that is able to retrieve the coordinates associated with

position. We assume the users to be mostly stationary (from t

time the issuer sends out the query until when she receives t

response back), or to have limited mobility. Users can commun

cate with their neighboring users over a wireless medium (e.g., v

Please cite this article as: T. Dargahi et al., ABAKA: A novel attrib


information (e.g., job), and contact information (e.g, Zip-code).

our medical help example, we consider the following profile a

tributes: { A 1 : Gender , A 2 : Age , A 3 : Nationality , A 4 : Job , A 5 : Zip - cod

We also assume that none of the users have exact informati

about the number of users in her vicinity, and their profile a

tributes. We consider the LBSP to be untrusted, and assume th

each LBS user does not want to share her exact location and ide

tity ( ID ) with the LBSP. In our model, the issuer sends her reque

to the LBSP through a multi-hop path, to anonymize her locati

and identity. Our multi-hop approach is similar to the work

[19,21] , however in ABAKA the issuer looks for a set of collabora

ing users having specific attributes, who cooperate with each oth

to anonymize the location of the issuer. We also assume that ea

user, based on its own policy, decides whether to participate in t

anonymizing process. One may think of an incentive mechanism

order to motivate users to participate in our collaborative schem

There are several monetary and non-monetary incentive schem

in the literature [22] , which could be considered to be a comp

ment for ABAKA. One possible approach, to be used, could be t

privacy-aware incentive mechanism proposed in [23] , which is

TTP-free scheme based on blind signature. However, an encoura

ing mechanism is out of the scope of this paper (and an orthogon

open research problem, as pointed out by Conti et al. [24] ), and w

leave it as future work.

We assume that the LBSP has a pair of keys: a public key p

and a private key sk L that are used to preserve confidentiality a

integrity of the message sent by the issuer to the LBSP. Moreov

we suppose that there could be multiple Certification Authorit

(CAs) [25] , each of which being responsible for a specific geograp

ical area (e.g., states or municipalities), to authenticate the use

and assign them CP-ABE private keys (users key management

out of the scope of this paper). Each user obtains a CP-ABE priva

key based on her profile attributes, from the CA nearest to her

cation. The CP-ABE private key will be used for authentication

collaborating users, and fulfilling the requirement of p -sensitivi

Furthermore, CAs provide the CP-ABE public key, that the issu

uses to encrypt her query specifying an access policy. In our s

lution, we assume each user to contact the nearest CA when h

profile attributes change, in order to retrieve a new CP-ABE priva

key. Note that this does not change the collaborative nature of o

approach. We also assume each user u i has a symmetric key, k

which can be a random number defined by u i . The user u i w

use this key to encrypt/decrypt a special field of the packet duri

the packet forwarding procedure. Moreover, the issuer generates

random group secret key, k r , for the collaborating users.

Finally, in our model each user can specify her privacy requir

ments in terms of size k of the anonymity set, number of use

with specific issuer-defined attributes p , and the largest and sma

est desired cloaked area size. Also, we assume the issuer to n

issue any query that the query content could lead to her iden

fication or reveal information about her exact location (otherwi

the use of anonymity preserving approaches would not make mu

sense).

ute-based k-anonymous collaborative solution for LBSs, Computer

02



ARTICLE IN PRESS


a rec

3.2269

270

siv271

(i) 272

suc273

(ii)274

is 275

(iii276

The277

be 278

sist279

[27280

the281

lea282

the283

era284

cre285

the286

vat287

288

wh289

(i.e290

is i291

or 292

at 293

ing294

ver295

Thi296

the297

son298

est299

sar300

of t301

col302

col303

con304

ine305

4. 306

307

pro308

gen309

as 10

ser 11

12

and 13

AB 14

mu 15

k − 16

cry 17

of 18

Fig 19

lab 20

in 21

defi 22

tan 23

• 24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

• 39

40

41

42

43

44

45

bet 46

fou 47

001 48

eig 49

the 50

15 ∼ 51

ide 52

Pl

Co

Fig. 2. Multi-hop CP-ABE based routing to form

. Adversary model

We consider two types of adversaries: passive and active. A pas-

e adversary can be one of the following three entities [11,26] :

the untrusted LBSP, which collects information about LBS users

h as their location, identity or activities, based on their queries;

an outsider eavesdropper on wireless communication, which

interested in identifying location and identity of the issuer;

) the users that collaborate in computing the k -anonymity set.

collaborating users are not fully trusted; we consider them to

honest-but-curious (we observed that this assumption is con-

ent with several works in the literature, such as the ones in

–29] ): i.e., users honestly follow the ABAKA protocol, and nei-

r drop nor modify the packets. However, they are curious to

rn location and identity of the issuer, or of the other users in

k -anonymity set. We assume that a malicious user cannot gen-

te fake profiles in order to participate in our protocol and de-

ase the privacy level of the issuer, since the CAs authenticate

users upon joining the network and assign them CP-ABE pri-

e keys (we found this assumption consistent with [30,31] ).

An active adversary can be one of the non-collaborating users

o is not able to satisfy the access policy on the encrypted packet

., the user who does not have the issuer-defined attributes). He

nterested in identifying the issuer, modifying the LBS request,

reducing the issuer’s privacy level. In the last case, he aims

reducing the number of users in the cloaked area (i.e., reduc-

the value of k ). We assume that both passive and active ad-

saries have some background knowledge about the users [26] .

s background information could be about profile attributes of

users, such as location information (e.g., office address), per-

al information (e.g., age or nationality), or even the exact or

imated number of users in a geographical location. The adver-

y aims at using his background knowledge to attack the privacy

he issuer. In our model, we address the collusion attack of non-

laborating users and we assume that collaborating users do not

lude (as they are semi-trusted). Finally, in this paper we do not

sider other types of attacks, such as, Denial of Service, which is

vitable in all the collaborative approaches in wireless networks.

Our solution: ABAKA

In this section, we present ABAKA, our TTP-free solution that

vides identity privacy for LBS users. ABAKA deals with both

erating and sending the LBS query to the LBSP ( Section 4.1 ),



tangle cloaked area, example with k = 3 .

well as generating and forwarding the requested location-based 3

vice to the issuer. 3

First, the issuer u i divides the encrypted query into k − 1 parts, 3

on each part enforces a specific access policy by means of CP- 3

E [12] . Then, the issuer sends the packet to the LBSP through a 3

lti-hop path. This way, she conceals her identity among other 3

1 neighboring users who are able to decrypt the CP-AB en- 3

pted parts of the packet. Fig. 2 provides a high-level example 3

our multi-hop attribute-based solution, considering k = 3 . As 3

. 2 shows, the protocol cloaks the position of the issuer (by col- 3

oration of both users with green tick icon and red cross icon 3

Fig. 2 ) and computes a k -anonymity set based on the issuer- 3

ned attributes. Using CP-ABE allows us to address two impor- 3

t issues: 3

Finding k − 1 collaborating users (users with green tick icon in 3

Fig. 2 ) having specific attributes, which could be issuer’s sensi- 3

tive attributes. Enforcing a policy on each of the k − 1 parts 3

of the message, the issuer will be sure that only the users 3

with attributes satisfying the policy, are able to decrypt one 3

part. Thus, we guarantee that the collaborating users in the 3

k -anonymity set satisfy p -sensitivity (recall that collaborating 3

users are honest-but-curious). We assume that each collaborat- 3

ing user uses her CP-ABE private key only one time for each re- 3

ceived packet. In other words, we assume that if she is able to 3

decrypt some of the CP-AB encrypted parts of the packet with 3

her private key (satisfying more than one policy), she will pro- 3

cess just one part. We consider this assumption to ensure that 3

all the k − 1 parts of the message will be processed by k − 1 dif- 3

ferent collaborating users and hence ensuring the k -anonymity. 3

Addressing privacy attack form non-collaborating users, i.e., users 3

outside the cloaked area in Fig. 2 . As non-collaborating users are 3

not able to satisfy any of the access policies, they will not be 3

able to decrypt any of the query parts. Therefore, they will not 3

be able to reduce the privacy level of the issuer by collaboration 3

in computing the cloaked area. 3

In our medical help example, user u 1 wants to be 9-anonymous 3

ween eight other users who are female and have the same 3

r digit prefix Zip-code, i.e., Gender = f emale and Zip - code = 3

9 . Moreover, due to her sensitive attributes, she is looking for 3

ht other users who are not Italian and have diverse values for 3

age attribute which fall in three different age categories, i.e., 3

24, 25 ∼34, and 35 ∼44. User u 1 uses ABAKA to conceal her 3

ntity. She encrypts the query Q with the public key of the LBSP, 3




ARTICLE IN PRESS


CPABEENCpk (MinArea||q1||kr ,Pi )

MessageHopCount MaxAreaDes�na�on

AddressEncrypted MinArea

OneHop Address

q1 q2 qk-1

ENCpk (Q||s||kr )k kL The query is then

split into k-1 parts

Each part is concatenated with a random key kr and the MinArea field; then, a policy p is applied with CP-ABE

The encrypted parts are concatenated and wri�en into the Message field

The query is encrypted with pkL

1

2

3

4

CPABEENCpk (MinArea||qk-1||kr ,Pj )

ENCk (MinArea)k (r

5 The MinArea field is encrypted with the random symmetric key kr

ABAKA Packet

ket fo

cy 353

∧ 354

ly 355

he 356

e 357

nd 358

2 ), 359

9- 360

es 361

an 362

363

o 364

te 365

t- 366

a. 367

k r 368

a, 369

er. 370

n- 371

se 372

ht 373

rs 374

to 375

i- 376

is- 377

es 378

ot 379

e 380

381

382

ng 383

BS 384

nd 385

386

s , 387

he 388

1 389

nd 390

m 391

rs. 392

es 393

a 394

or 395

ly. 396

ed 397

o 398

of 399

ed 400

ng 401

ed 402

he 403

is 404

is- 405

ts 406

ey 407

of 408

n- 409

410

411

1 , 412

413

- 414

ed 415

SP 416

417

rts 418

- 419

ze 420

5). 421

to 422

c- 423

1 , 424

rt 425

ng 426

he 427

es 428

429

1 , 430

1 431

ge 432

Fig. 3. LBS request pac

splits it into eight equally sized parts and applies an access poli

on each part using CP-ABE, such as ( A 1 = f emale ) ∧ ( A 5 = 0019)

( A 3 NOT Italian ) ∧ (15 ≤ A 2 < 25) . This way, she is sure that on

the user with the following attributes will be able to decrypt t

corresponding part: who is female, lives in an area with the sam

Zip-code prefix as u 1 , is not Italian, and her age is between 15 a

24. By defining three different categories for the age attribute ( A

the final 9-anonymity set will be 3-sensitive. As users in the

anonymity set have diverse values from three different categori

for sensitive attribute of u 1 , the probability that the attacker c

identify the issuer’s age category is 1 3 .

Upon receiving an LBS request packet (the packet with tw

green parts in Fig. 2 ), the LBSP decrypts the query with its priva

key ( sk L ) obtaining: Q ; a random number s , and random symme

ric key k r generated by the issuer; and the encrypted cloaked are

Then, the LBSP decrypts the cloaked area field by the obtained

and generates a response message R considering the cloaked are

which comprises the location information requested by the issu

To provide confidentiality of the response message, the LBSP e

crypts R with s . Finally, the LBSP sends the generated respon

packet back to the user that delivered the query (the user in rig

top corner of the cloaked area in Fig. 2 ). All the collaborating use

in the k -anonymity set use a semi-onion routing approach [32]

send the response packet back to the issuer. In particular, sem

onion routing allows us to deliver the response packet to the

suer, following the reverse path, without the need for all the nod

in the path to keep track of the path locally. This approach is n

intended to hide the path from the LBSP to the issuer; indeed, w

leave this as a future work.

4.1. Generate and forward a request

In this section, we describe how a query issuer, u i , is generati

and forwarding an LBS request to the LBSP. In particular, an L

request packet is composed of the six fields illustrated in Fig. 3 a

discussed in the following.

The Message field contains the query Q , a random number

and a randomly generated symmetric key k r encrypted with t

public key, pk L , of the LBSP. This message is then split into k −parts, each encrypted with CP-ABE applying a certain policy, a

finally recomposed. The HopCount field denotes the maximu

number of hops that the packet should pass through other use



rmat generated by the issuer.

Its value should be greater than k − 1 . The MaxArea field denot

the maximum size of the desired cloaked area in the form of

rectangle, which is defined by two points ( x l , y l ) and ( x r , y r ) f

bottom left and top right corners of the rectangle, respective

The MinArea field represents the minimum size of the desir

cloaked area in the form of a rectangle, which is defined by tw

points (x ′ l , y ′

l ) and (x ′ r , y ′ r ) for bottom left and top right corners

the rectangle, respectively. The content of this field is encrypt

with the randomly generated symmetric key k r . After completi

the cloaking procedure, this field represents the actual cloak

area dimensions. OneHopAddress is used for routing back t

LBSP response to the issuer of the query. The initial value of th

field is Enc k u i (r) , where r is a random number generated by the

suer u i . Upon receiving the LBS request packet, each user encryp

the address of the previous hop with her symmetric secret k

( k u i ) and appends this encrypted layer to the current content

the OneHopAddress field. Finally, DestinationAddress co

tains the address of the LBSP.

4.1.1. Packet generation

An issuer u i generates a packet executing the Algorithm

which comprises the following steps:

Step 1. The query issuer, u i , generates a Message which com

prises her query, Q , a random number, s , and a randomly generat

symmetric key k r encrypted with the public key, pk L , of the LB

( Algorithm 1 , lines 2–3).

Step 2. The issuer splits the encrypted Message into k − 1 pa

(e.g., in chunks of equal size), where k is the k -anonymity param

eter ( Algorithm 1 , line 4). Then, she defines the minimum si

of the desired cloaked area, MinArea field ( Algorithm 1 , line

She appends the MinArea field and also the symmetric key k r each part and encrypts that part with CP-ABE, specifying an a

cess policy, i.e., a combination of desired attributes ( Algorithm

lines 6-8). The reason behind including MinArea field in each pa

is to provide each collaborating user with the means of checki

whether the actual minimum desired cloaked area defined by t

issuer has been modified during the path by intermediate nod

(we will provide a further discussion in Section 4.2 ).

Step 3. The issuer creates an empty packet (Algorithm

line 9), as illustrated in Fig. 3 . Then, she concatenates the k −parts generated in the previous step to form a complete messa


02



ARTICLE IN PRESS


kr

Yes

kr

kr

No

arding

Alg

Inp

1:

2:

3:

4:

5:

6:

7:

8:

9:

10:

11:

12:

13:

14:

15:

16:

17:

18:

( Al433

me434

sag435

des436

of 437

Mi438

non439

ma440

441

a r442

tac443

the 4 4

nex 45

bas 46

47

int 48

are 49

ing 50

of 51

alo 52

tion 53

des 54

gle 55

of 56

ber 57

the 58

nei 59

4.1. 60

61

atio 62

Fig 63

64

clo 65

66

fiel 67

par 68

lab 69

per 70

• 71

72

73

74

75

76

77

78

79

80

Pl

Co

Fig. 4. Packet forw

orithm 1 LBS Packet Generation.

ut: The LBS query Q , the anonymity parameter k , an array

of policies, the maximum hop count max , the largest cloaked

area limits ((x l , y l ) , (x r , y r )) , the smallest cloaked area limits

((x ′ l , y ′

l ) , (x ′ r , y ′ r )) , and the Destination address Dest inat ion .

procedure GenerateRequest ( k, policies [] , Q, max, (x l , y l ) ,

(x r , y r ) , (x ′ l , y ′

l ) , (x ′ r , y ′ r ) )

k r ← RandomKey() ; s ← RandomNumber() ;Message ← Enc pk L

( Q|| s ) ;parts [] ← Split( Message enc , k − 1 ) ;minArea ← Area( (x ′

l , y ′

l ) , (x ′ r , y ′ r ) ) ;

for i ∈ [1 : k − 1] do

parts [ i ] ←

CpabeEnc pk ( minArea || parts [ i ] || k r , policies [ i ] ) ;end for

packet ← GenerateEmptyPacket() ;packet.Message ← Concatenate( parts [] ) ;packet.HopCount ← max ;packet.MaxArea ← Area( (x l , y l ) , (x r , y r ) ) ;packet.MinAr ea ← Enc k r ( minAr ea ) ;packet .Dest inat ionAd d ress ← Dest inat ion ;r ← Random() ;packet.OneHopAd d ress ← Enc k u i

( r) ;Forward( packet, neighbors [] ) ;

end procedure

gorithm 1 , line 10). Afterward, u i defines her privacy require-

nts in terms of maximum number of neighbors that the mes-

e should pass through, the maximum and minimum size of the

ired cloaked area, and the destination address, i.e., the address

the LBSP ( Algorithm 1 , lines 11 –14). The issuer u i encrypts the

nArea field of the header with k r , to avoid eavesdroppers or

-collaborating users to be able to read (or modify) such infor-

tion ( Algorithm 1 , line 13).

Step 4. Before sending the packet to a next hop, u i encrypts

andom number r with her symmetric secret key ( k u i ), and at-

hes it to the packet ( Algorithm 1 , lines 15 –16). Finally, u sends
i


flowchart.

generated packet to one of her neighbors. The choice of the 4

t-hop can be done in several ways, e.g., selecting randomly or 4

ed on the proximity with the issuer ( Algorithm 1 , line 17). 4

In the medical help example, user u 1 splits the encrypted query 4

o eight parts. Then, she defines her desired smallest cloaked 4

a ( MinArea ) which could be 100 m × 100 m rectangle includ- 4

her house (the house is not necessarily placed in the center 4

the defined area). She concatenates the MinArea to each part 4

ng with a random symmetric key k r , and applies the aforemen- 4

ed policies on each part. Afterward, she determines her largest 4

ired cloaked area, MaxArea , which is a 600 m × 600 m rectan- 4

including her geographical position and the maximum number 4

hops (e.g., HopCount = 15). Then she encrypts a random num- 4

r with her symmetric key ( k u 1 ) and specifies the address of 4

LBSP. Finally, she forwards the generated packet to one of her 4

ghbors. 4

2. Packet forwarding 4

Once received a packet, a user u j performs the following oper- 4

ns (the packet forwarding procedure’s flowchart is depicted in 4

. 4 ): 4

Step 1. User u j checks whether she resides in the largest desired 4

aked area defined in the MaxArea field of the packet. 4

Step 2. If u j resides in the defined area, she peruses the packet 4

ds to decide, based on her own policies, whether she wants to 4

ticipate in the cloaking algorithm. If she does not want to col- 4

orate, she forwards the packet to another user. Otherwise, she 4

forms the following actions: 4

Step 2.1: The user u j checks the Message field of the packet, to 4

verify whether there is any encrypted part, and if she is able to 4

decrypt one of them. User u j will be able to decrypt one part, if 4

and only if the attributes associated to her profile (i.e, attributes 4

associated to her private key sk u j ) satisfy the policy enforced on 4

that part. If able to decrypt, u j decrypts the MinArea field of 4

the packet header, i.e., Packet.MinArea , using the key k r ob- 4

tained from the CP-ABE decrypted part. Then, u j compares such 4

field with the Part.MinArea field: if Packet.MinArea < 4

Part.MinArea , it means that an attacker has decreased the 4




ARTICLE IN PRESS


original value defined by the issuer. In such a case, u j dis- 481

cards the packet. Otherwise, u j continues by checking whether 482

she resides in the area defined by the Packet.MinArea . If 483

not, u j enlarges the area to include also her location. Then, she 484

updates the part she is currently processing, by removing the 485

Part.MinArea field and k r and encrypting such part with k r . 486

• Step 2.2: The user u j updates the current value of the 487

OneHopAddress concatenating the address of the previous 488

hop, and encrypting the whole content of the field with 489

her symmetric secret key ( k u j ). This way she adds a new 490

“onion layer” that will be used to route the response mes- 491

sage back to the issuer. Then, u j decrements the value of the 492

HopCount field. If u j is the one who decrypted the last part 493

with her CP-ABE key, she decrypts all the previous parts with 494

the key k r . Then, if HopCount = 0 , u j removes the MaxArea 495

and HopCount fields of the packet header, and sends the 496

query to the LBSP. The coordinates (x ′ l , y ′

l ) and (x ′ r , y ′ r ) in the 497

Packet.MinArea field represent the actual cloaked area, i.e., 498

the smallest area covering the positions of all the collaborating 499

users. If HopCount > 0, u j continues forwarding the packet to 500

one of her neighbors. 501

• Step 2.3: If there are other encrypted parts (i.e., the packet did 502

not pass enough users to guarantee k -anonymity), or if the user 503

was not able to decrypt one of the parts of the message, u j 504

continues forwarding the packet to one of her neighbors. Be- 505

fore forwarding the packet, u j checks the HopCount value. If 506

HopCount = 0 , u j discards the packet. Otherwise, forwards the 507

packet again. 508

Step 3. If u j does not reside in the defined largest cloaked area, 509

she can perform one of the following actions: drop the packet, for- 510

ward it to a random neighbor, or send the packet back to the pre- 511

vious user. 512

The protocol explained in this section ensures that the query is 513

forwarded through, at least, k − 1 neighboring users having specific 514

attributes, ensuring k -anonymity and p -sensitivity. 515

4.2. Discussion 516

In this section we briefly discuss issues related to packet gen- 517

eration and forwarding, as well as the privacy level provided by 518

ABAKA. 519

4.2.1. Packet generation 520

To ensure that the smallest cloaked area specified by the issuer 521

will be respected, we introduced the MinArea field in the ABAKA 522

packet. This field is of extreme importance in order to guarantee 523

the desired privacy level for the query issuer. Indeed, on one hand, 524

an attacker might want to increase such area to reduce the quality 525

of service; and, on the other hand, the attacker might also want 526

to reduce the value of the MinArea field, in this case attempting 527

to reduce the privacy guarantees of the ABAKA. In order to pre- 528

vent these two attacks, we place the MinArea field inside each 529

of the CP-ABE encrypted parts of the query. We also encrypt the 530

MinArea field of the packet header with a secret symmetric key 531

( k r ), which can be accessed only by the collaborating users after 532

rs 533

a- 534

it. 535

r- 536

eir 537

of 538

539

540

n- 541

he 542

privacy of the collaborating users. Indeed, the issuer could infer 543

that there are people with specific attributes in the cloaked area, 544

simply by issuing several ABAKA messages adopting different poli- 545

cies. We addressed this concern by allowing each user who re- 546

ceives the packet to decide whether to participate in the protocol 547

or not. Therefore, if a user receives a packet, which has some parts 548

that specify her own sensitive attributes, she can decide to not de- 549

crypt such part and just forward the packet to a neighbor. Another 550

possible solution for this problem could be considering each col- 551

laborating user to be able to influence the packet, e.g., enlarging 552

the minimum cloaked area and then decrypting the packet. In this 553

way, she can cloak herself in a larger area. 554

The second concern is the participation of users with revoked 555

attributes. This issue is mainly related to the key revocation mech- 556

anisms for CP-ABE, and therefore is out of the scope of this paper. 557

We will leave such concern as a future work. 558

A third issue is the collusion of non-collaborating users, that 559

might want to send the packet to the LBSP when only a por- 560

tion of CP-ABE parts are already decrypted. In such a scenario, 561

the LBSP may be able to extract some useful information from the 562

currently decrypted parts. We addressed this issue introducing a 563

random symmetric key ( k r ) that each collaborating user will ob- 564

tain after decrypting a CP-ABE part; after processing the MinArea 565

field (as explained in Section 4.1.2 ), each collaborating user will en- 566

crypt with k r the part she decrypted with her CP-ABE private key. 567

In this way, even in case of collusion attack, the LBSP receives an 568

encrypted packet and cannot infer any useful information. 569

ng 570

in 571

a. 572

io, 573

t- 574

k- 575

t- 576

es 577

w- 578

a- 579

off 580

es 581

es, 582

a 583

584

a 585

he 586

r- 587

d, 588

e 589

a 590

e 591

e 592

nt, 593

e- 594

dy 595

596

r- 597

is 598

of 599

e 600

he 601

he 602

is- 603

c- 604

iv- 605

nd 606

he 607

he 608

decrypting a CP-ABE part. This way, only the collaborating use

are able to modify this field as well as verifying the possible m

licious modifications to the packet, and eventually discarding

Similarly, also the MaxArea and HopCount fields might be ta

geted by an attacker, who may want to enlarge or reduce th

values. However, such possible attacks would lead to a Denial

Service, that is out of the scope of this work.

4.2.2. Packet forwarding

During the packet forwarding process, we may have some co

cerns. First, participating in the ABAKA protocol may threaten t



Another privacy concern is the mobility of the collaborati

users which may lead to a reduction of the k -anonymity level,

a case that some of the collaborating users leave the cloaked are

Although we assumed users to be in a limited mobility scenar

we could integrate mobility and movement directions in compu

ing the cloaked area to support also dynamic networks (e.g., ta

ing into account the speed of the collaborating users, and compu

ing how much they could move by the time the response com

back, and computing whether they will still be reachable). Ho

ever, such integration is not trivial, since it depends on several p

rameters (e.g., its domain of application), and requires a trade-

between privacy level, overhead, and trust to some central entiti

(such a trade-off is a common issue in collaborative approach

such as in [33] ). We leave the management of nodes’ mobility as

future work.

The other issue could be continuous request of a same LBS by

user u in a cloaked area. In this case, the LBSP might identify t

user by correlation of the requests over time. In such case, ove

time if the other individuals in the anonymity set are change

then the user u could be the one who is requesting the sam

query. This attack can happen in two cases: (i) if the attacker has

general view over the path, which could be solved by using som

kind of anonymous routing, (ii) if the attacker has local real-tim

knowledge about the individuals in the set and the query conte

and also have historical information about the previous same r

quests and the individuals in that sets. We leave a thorough stu

of the latter attack as future work.

Finally, another issue is the delay imposed by the multi-hop fo

warding, and finding k − 1 users with specific attributes. ABAKA

most effective in dense environments (in which the probability

finding collaborating users in vicinity is high) and non real-tim

scenarios. It provides a strong privacy protection considering t

issuer profile attributes varying for each user and query, with t

cost of imposing delay to the system. In many applications, the

suer is willing to accept a trade-off between strong privacy prote

tion (by defining strict access policies) and latency (or not rece

ing response at all). We could also define a maximum time bou

for the reception of the response: if the issuer does not receive t

response within a certain time frame, she can decide to relax t


02



ARTICLE IN PRESS


pri609

tha610

vac611

of n612

be 613

but614

4.2615

616

sar617

dro618

tru619

tec620

621

622

623

624

625

626

627

628

(629

630

631

632

633

634

635

636

637

638

639

(i640

641

642

643

644

645

646

(647

648

649

650

651

652

653

654

5. 655

656

ABA657

for658

diff659

hea660

app661

5.1.662

663

cre664

pop665

hat666

ave667

(1)668

Tab

Sta

C

N

M

[34 69

the 70

a s 71

per 72

ins 73

eva 74

[38 75

in 76

sid 77

ing 78

Mil 79

age 80

for 81

sm 82

New 83

the 84

23. 85

sm 86

87

era 88

var 89

100 90

ma 91

92

two 93

i.e. 94

(2) 95

tha 96

larg 97

dro 98

tur 99

ano 00

per 01

the 02

03

ula 04

tion 05

Pl

Co

vacy constraints and re-issue the query. It is worth mentioning

t, as a design choice, we attributed higher priority to users’ pri-

y, with respect to the quality of service. Therefore, in the case

ot finding enough collaborating users, the issued query will not

submitted to the LBSP and the issuer will still be anonymous,

we do not ensure that she will receive her requested service.

.3. Privacy discussion

As introduced in Section 3.2 , we consider the following adver-

ies separately: (i) the untrusted LBSP; (ii) an outsider eaves-

pper; (iii) the semi-trusted collaborating users; (iv) the un-

sted non-collaborating users. We now discuss how ABAKA pro-

ts users against these adversaries.

(i) Consider the medical help example. Based on the content of

the query, the LBSP could infer that the sender is a foreign

woman, probably between 15 and 45 years old. However,

even with background knowledge about profile attributes

of women in that area, it could not infer which of these

women could be the issuer. In fact, there are at least nine

women in the age range between 15 and 44, with different

nationalities.

ii) The outsider eavesdropper observes the communication be-

tween the users. He is not able to access the content of the

packet since it is encrypted with CP-ABE, and with the pub-

lic key of the LBSP. If he can observe all the path, he can find

out the issuer and if he has background knowledge about

what could be the issuer’s query, he may only be able to

infer some attributes of the collaborating users; however, it

is a strong assumption about the adversary. One can think

about an on top anonymized routing layer which could be

an orthogonal solution to be used along with the ABAKA,

and we leave it as a future work.

ii) There is no useful information inside the LBS packet for

honest-but-curious collaborating users; the content of the

message is encrypted with the public key of the LBSP, and

both location and identity of the issuer are hidden. A cu-

rious collaborating user could obtain only knowledge about

attributes of all the collaborating users, or, at least, attributes

of a subset of collaborating users.

iv) Non-collaborating users may try to reduce the privacy level

of the issuer (e.g., in the previous example, a man could

try to collaborate in computing the cloaked area to de-

crease the value of k ) or to modify the packet. Using CP-

ABE, users without specific attributes are not able to decrypt

the packet. Therefore, they can neither modify the packet

nor collaborate in the k -anonymity set to reduce the privacy

level for the issuer.

Experimental results

In this section, we present an experimental evaluation of

KA, using two different datasets. In Section 5.1 we provide per-

mance evaluation of ABAKA in terms of success rate considering

erent scenarios; while in Section 5.2 we investigate the over-

d imposed by the cryptographic operations in our proposed

roach.

Performance evaluation

For the purpose of evaluating ABAKA in a realistic scenario, we

ated two synthetic datasets based on real world statistics of the

ulation of two cities: New York (USA), focusing on the Man-

tan island, and Milan (Italy). In particular, we estimated the

rage number of ABAKA users in an area of 1 km

2 , based on:

the average population density in such cities, obtained from



le 2

tistics on the considered datasets (data extracted from [34–37] ).

ity Inhabitants Smartphone ABAKA Neighboring users

per km

2 Users (%) Users (%) Average Std. Dev.

ew York 27,733 64 50 20 .00 4.82

60 23 .89 5.31

70 27 .85 5.79

ilan 7 382 41 50 2 .99 1.99

60 3 .37 2.08

70 4 .00 2.24

Table 3

Considered attributes and their distribution, according to

the data in [34] .

Attribute Attribute value Presence in the

population (%)

Sex ( S ) male ( m ) 47 .5

female ( f ) 52 .5

Race ( R ) white ( w ) 33

black ( b ) 25 .5

latino or hispanic ( h ) 28

asian ( s ) 12 .7

american indian ( a ) 0 .8

Origin ( O ) foreign born ( f ) 37

local born ( l ) 63

Age ( A ) < 18 21 .6

between 18 and 65 66 .3

≥65 12 .1

] and [35] ; (2) the statistics on the smartphone penetration in 6

state of belonging, i.e., the percentage of population owning 6

martphone, according to [36] and [37] ; and (3) a hypothetical 6

centage of the smartphone users with the ABAKA application 6

talled (50%, 60%, and 70% were considered). Moreover, in our 6

luation we assumed a WiFi range of 25 meters for each device 6

] . Table 2 shows some statistics about the considered datasets, 6

particular the number of users per km

2 , the percentage of con- 6

ered collaborating users, and the average number of neighbor- 6

collaborators for each user. As we can see form Table 2 , the 6

an dataset represents a non-dense scenario. Indeed, the aver- 6

collaborating neighbors per ABAKA user, spans, on average, 6

m 2.99 to only 4.00, with a percentage of ABAKA users in the 6

artphone-users population of 50% and 70%, respectively. The 6

York dataset, instead, represents a “best case” scenario, where 6

average connection degree per ABAKA user is high, e.g., some 6

89 neighbors on average, considering a 60% ABAKA users in the 6

artphone-users population. 6

To evaluate the performance of ABAKA, we measured the av- 6

ge success rate for a query packet to be received by the LBSP, 6

ying the maximum allowed size of the cloaked area, from 6

m

2 , to 600 m

2 , with steps increase of 100 m

2 , as well as the 6

ximum allowed hops number, i.e., 10, 15 and 20 hops. 6

In our evaluation, we performed our experiments considering 6

possibilities for a user to forward a message to a neighbor, 6

, she can forward the packet to: (1) the closest neighbor, or 6

a random one. We also considered different possible actions 6

t a user can perform when receiving a packet outside of the 6

est possible cloaked area. In this case, she can decide to: (i) 6

p the packet, (ii) forward it to a random neighbor, or (iii) re- 6

n the packet back to the previous user, which in turn will select 6

ther user to which forward the message. However, in our ex- 7

iments we did not consider option (i), since it would reduce 7

probability for a message to complete the protocol. 7

We considered four different types of attributes for the pop- 7

tion, reported in Table 3 . The table reports also the distribu- 7

of attribute values in the population, extracted from [34] . We 7




ARTICLE IN PRESS


ABAKA users. (c) 70% ABAKA users.

dataset. Each user forwards the message to its closest neighbor; outside the cloaked area,

ABAKA users. (c) 70% ABAKA users.

datas ea,

% A

datas ea,

ly 706

nd 707

708

nt 709

ed 710

th 711

712

713

714

715

nd 716

st 717

718

he 719

on 720

la- 721

ke 722

lts 723

xt 724

se. 725

726

rst 727

l- 728

es 729

n- 730

ve 731

0% 732

nd 733

er, 734

n- 735

is 736

x- 737

738

al- 739

an 740

v- 741

w 742

(a) 50% ABAKA users. (b) 60%

Fig. 5. Success rate of ABAKA simulating policies combination (a) on the Milan

user returns the message to previous user.

(a) 50% ABAKA users. (b) 60%


user forwards the message to a random neighbor.

(a) 50% ABAKA users. (b) 60



performed 10 0 0 runs of the ABAKA protocol, each time random

initializing the configuration according to the values in Table 3 , a

randomly selecting a different issuer.

Our evaluation of ABAKA considers the following two differe

policy combinations, where parentheses delimit a policy enforc

on a single message part (considered notation is consistent wi

the reported attributes in Table 3 ):

(a) [( A ≥ 18 ∧ S = f ) , ( A ≥ 18 ∧ S = f ) , ( A ≥ 18 ∧ S = f ) ,

( A ≥ 18 ∧ S = f )]

(b) [ ( A ≥ 18 ∧ O = l ) , ( A ≥ 18 ∧ R = h ) ]

Policies combination (a) provides at least 5-anonymity, a

1-sensitivity, while polcies combination (b) provides at lea

3-anonymity and 2-sensitivity.

Figs. 5–8 present the results of our simulation, adopting t

different strategies introduced above, with set of policies (a)

the Milan dataset; Figs. 9–12 presents the results of our simu

tion with set of policies (a) on the New York dataset. For the sa

of brevity, for policies combination (b) we report only the resu



et. Each user forwards the message to its closest neighbor; outside the cloaked ar

BAKA users. (c) 70% ABAKA users.

et. Each user forwards the message to a random neighbor; outside the cloaked ar

obtained on both datasets, with strategy (1) for selecting the ne

collaborating user, and strategy (iii) to handle the out-of-area ca

We report these results in Figs. 13 and 14 .

From our results, we can derive some useful observations. Fi

of all, we notice that, unsurprisingly, the average number of co

laborating neighbors per ABAKA user (listed in Table 2 ) influenc

the success rate of our proposal. This is more evident if we co

sider the Milan dataset. As an example, Fig. 5 shows a significati

increase of the success rate, i.e., from a maximum of some 6

to a maximum of some 70%, as the number of ABAKA users (a

consequently the number of neighbors per user) grows. Howev

note that even in non-dense scenarios, ABAKA achieves a reaso

able success rate, e.g., in Fig. 5 (c) we can observe that ABAKA

capable to achieve a success rate of some 70%, considering a ma

imum of 20 hops and a maximum cloaked area size of 200 m

2 .

Second, we can observe that both the maximum number of

lowed hops, as well as the maximum cloaked area size, play

important role. The effect of the maximum number of hops is e

ident from the results of the experiment performed on the Ne


02



ARTICLE IN PRESS


(a) 50% ABAKA users. (b) 60% ABAKA users. (c) 70% ABAKA users.

Fig. 8. Success rate of ABAKA simulating policies combination (a) on the Milan dataset. Each user forwards the message to a random neighbor; outside the cloaked area,

user forwards the message to a random neighbor.


Fig. 9. Success rate of ABAKA simulating policies combination (a) on the New York dataset. Each user forwards the message to its closest neighbor; outside the cloaked area,



Fig. datase

area

BAK

Fig. datase

area

Pl

Co

10. Success rate of ABAKA simulating policies combination (a) on the New York

, user forwards the message to a random neighbor.

(a) 50% ABAKA users. (b) 60% A

11. Success rate of ABAKA simulating policies combination (a) on the New York

, user returns the message to previous user.



t. Each user forwards the message to its closest neighbor; outside the cloaked

A users. (c) 70% ABAKA users.

t. Each user forwards the message to a random neighbor; outside the cloaked




ARTICLE IN PRESS



Fig. 12. Success rate of ABAKA simulating policies combination (a) on the New York dataset. Each user forwards the message to a random neighbor; outside the cloaked

area, user forwards the message to a random neighbor.


Fig. 13. Success rate of ABAKA simulating policies combination (b) on the Milan dataset. Each user forwards the message to its closest neighbor; outside the cloaked area,



Fig. 14. Success rate of ABAKA simulating policies combination (b) on the New York dataset. Each user forwards the message to its closest neighbor; outside the cloaked

area, user returns the message to previous user.

York dataset. For example, from Fig. 12 we can see that adopting 743

a maximum number of hops of 20, brings the success rate of the 744

protocol to greater than 90%, while a maximum of 10 hops leads 745

to a success rate lower than 60%. Analogously, the effect of the 746

adopted bigger maximum cloacked area size can be observed from 747

Fig. 5 to Fig. 12 ; as an example, Fig. 5 (a) shows that, with a max- 748

imum of 20 hops, a maximum cloacked area size of 100 m

2 leads 749

to an average success rate of some 50%, while when the maxi- 750

mum cloacked area size is 600 m

2 , the success rate is some 60% an 751

average. 752

5.2. Cryptographic overhead 753

For a thorough evaluation of ABAKA, we estimated the overhead 754

introduced by the cryptographic tools used in our protocol. In par- 755

ticular, we measured the average time required for encryption and 756

decryption with CP-ABE, RSA, and AES-CBC. We considered two 757

different platforms: a laptop equipped with 4x1.8 GHz Intel Core 758

i7-4500U processor, and 8 GB RAM, running Ubuntu 14.04; and 759

a smartphone equipped with a 1.2 GHz dual-core ARM Cortex-A9 760

CPU processor, and 1 GB RAM, running Android 4.3 “Jelly Bean”. 761

On both platforms, we evaluated CP-ABE using the ABE imple- 762

mentation for Android devices we proposed in [39] 1 . Fig. 15 shows 763

the results of our measurements on a 250 KB file (we believe that 764

this is a reasonable size assumption for a piece of query encrypted 765

in the protocol). Since the time required by CP-ABE mainly de- 766

pends on the number of attributes employed in the cryptographic 767

operations [12] , we considered a varying number of attributes for 768

policies and keys from one to 20. 769

As we can see from Fig. 15 , even adopting a large number of 770

attributes, the time required by CP-ABE implementation for en- 771

cryption and decryption is low, on both smartphone and laptop. 772

1 The code of the library is available at http://spritz.math.unipd.it/projects/

andraben/

Please cite this article as: T. Dargahi et al., ABAKA: A novel attribute-based k-anonymous collaborative solution for LBSs, Computer


http://spritz.math.unipd.it/projects/andraben/



ARTICLE IN PRESS


(a) Encryption (b) Decryption

Fig. 15. Average time required for encryption and decryption operations using CP-ABE on an Android smartphone and a Laptop device.

Table 4

Average encryption/decryption time for RSA/AES-CBC on Smartphone

and Laptop.

Scheme Smartphone Laptop

Encrypt Decrypt Encrypt Decrypt

RSA 7.5101 ms 0.0156 ms 0.153 ms 0.001 ms

AES-CBC ∗ 26.199 ms 26.517 ms 2.809 ms 3.953 ms

AES-CBC ∗∗ 110.179 ms 109.574 ms 11.072 ms 15.526 ms

∗ Encryption/decryption of a 250 KByte file. ∗∗ Encryption/decryption of a 1 MByte file.

For a more comprehensive overview of the performance of ABE on 773

smartphone devices, the reader may refer to our recent work [39] . 774

Additionally, we measured the average encryption and decryption 775

time for RSA, with key size of 4096 bits, and AES-CBC with key 776

size of 256 bits. On both platforms, we employed the openssl li- 777

brary [40] , that we cross compiled for Android. We measured RSA 778

encryption and decryption for a key of size 256 bits; while for AES- 779

CBC, we considered a file of size 1 MB. Table 4 shows the results 780

of our measurements. As we can see, for both RSA and AES-CBC, 781

the imposed overhead is very small. 782

The results we obtained confirm the applicability of ABAKA 783

not only on powerful devices such as laptops, but also on smart- 784

phone devices. As an example, consider an anonymity level k = 5 , 785

and policies composed by three attributes (which we believe are 786

expressive enough to successfully guarantee p -sensitivity). In this 787

case, the average overhead on an Android smartphone would be 788

approximately (0 . 27613 × 5) + 0 . 00751 + 0 . 11018 = 1 . 49834 s for 789

the issuer, who has to encrypt the query with a symmetric key, 790

that in turn is encrypted with LBSP’s public key (this is a com- 791

mon usage of public key encryption), and encrypt each part of the 792

split message with CP-ABE. Each collaborating user has to decrypt 793

a p794

ate795

wil796

ing797

wit798

of 799

6. 800

801

app802

use803

LBS804

has805

clo806

app807

que808

our809

mantics, and (ii) sensitive profile attributes of each user, at the 810

same time. 811

Bamba et al. [44] proposed an approach to provide k - 812

anonymity and location l -diversity for LBS users. In this scheme, 813

mobile users are not identifiable from k − 1 other users in a set of 814

l different physical locations such as hospitals, bars and university. 815

This scheme utilizes one or more anonymization servers between 816

users and LBSP to perform spatio-temporal cloaking. 817

In traditional approaches for k -anonymity in LBSs, the compu- 818

tation of the cloaked area is carried out by an anonymization server 819

to which the query is first forwarded. Such solutions are typically 820

referred as TTP-based schemes. However, the use of a centralized 821

anonymizer offers a single point of attack, and may represent a se- 822

rious bottleneck for the overall system. To overcome these limita- 823

tions, researchers proposed several distributed solutions that com- 824

pute the cloaked area in a collaborative way, referred to as TTP-free 825

solutions. For an overview of the main existing TTP-free solutions, 826

the reader can refer to [45] . 827

Unfortunately, most of the existing schemes (both TTP-free and 828

TTP-based) do not consider the background knowledge of the at- 829

tackers, except from only a few recently proposed approaches [11] . 830

However, an attacker with background information about a user’s 831

profile might be able to identify her, even if her location is hidden 832

[46] . k -anonymity preserving solutions try to overcome the above 833

issues, by considering user profiles information [6,47] . However, 834

unlike our work, all the aforementioned profile-based schemes are 835

centralized, and might be subject to the limitations introduced be- 836

fore. To the best of our knowledge, our proposal is the first TTP- 837

free approach for p -sensitive profile k -anonymity in LBS that con- 838

siders user’s profile attributes. 839

7. Conclusions 840

41

ma 42

ma 43

lut 44

lite 45

the 46

per 47

k -a 48

the 49

att 50

a C 51

sue 52

ABA 53

she wants to be anonymous, and to specify a list of k − 1 poli- 854

cies, i.e., attribute combinations, that users in the multi-hop path 855

must satisfy in order to forward the query message to the LBSP. 856

ABAKA provides the possibility of performing a trade-off between 857

Pl

Co

art of the query with her CP-ABE private key, and immedi-

ly encrypt it with AES-CBS. Therefore, the approximate overhead

l be 0 . 13275 + 0 . 26199 = 0 . 15894 s. Finally, the last collaborat-

user have to decrypt all the parts that are previously encrypted

h AES-CBC. Therefore, she will incur in an additional overhead

0 . 02651 × 5 = 0 . 13255 s.

Related work

The concept of k -anonymity was first introduced for databases

lications [41] , and later applied in the context of LBSs [5] : the

r’s position is translated into a cloaked area and provided to the

P along with the requested query. The concept of k -anonymity

been extended in several aspects, e.g., l - diversity [42] , and t -

seness [43] . Moreover, in [9] the authors proposed a p -sensitive

roach for LBSs, which provides query l -diversity by classifying

ries into sensitive and non-sensitive groups. However, unlike

work, none of these approaches considered both (i) query se-



Location and identity privacy in Location-Based Services are 8

jor concerns for users who want to protect their privacy from a 8

licious LBSP, as well as from an eavesdropper. While several so- 8

ions for guaranteeing privacy in LBSs have been proposed in the 8

rature, they are often centralized, or do not take into account 8

prior knowledge of the attacker about user profiles. In this pa- 8

we present ABAKA, our collaborative solution that guarantees 8

nonymity, as well as p -sensitivity in LBSs, taking into account 8

issued query semantics. In our approach, users have a set of 8

ributes associated to their profile. Their attributes are bound to 8

P-ABE private key. An LBS message is first processed by the is- 8

r, and then forwarded through a multi-hop route to the LBSP. 8

KA enables each issuer to delimit a cloaked area within which 8




ARTICLE IN PRESS


the stringency of privacy protection and quality of service for the 858

issuer in her current location, based on the query semantics. We 859

addressed the threat of active and passive adversaries by means of 860

CP-ABE and multi-hop routing approaches. We simulated our pro- 861

tocol on synthetic datasets derived from real population statistics 862

(considering two cities: New York (USA), and Milan (Italy)), and 863

demonstrated that our approach is feasible and efficient. 864

Acknowledgments 865

Mauro Conti is supported by a Marie Curie Fellowship 866

funded by the European Commission (agreement PCIG11-GA-2012- 867

321980 ). This work is also partially supported by the EU Tag- 868

ItSmart! Project (agreement H2020-ICT30-2015-688061), the EU- 869

India REACH Project (agreement ICI+/2014/342-896), the Italian 870

MIUR-PRIN TENACE Project (agreement 20103P34XC), and by the 871

projects “Tackling Mobile Malware with Innovative Machine Learn- 872

ing Techniques”, “Physical-Layer Security for Wireless Communica- 873

tion”, and “Content Centric Networking: Security and Privacy Is- 874

sues” funded by the University of Padua. 875

References 876

[1] H.A. Karimi, Advanced Location-based Technologies and Services, CRC Press, 877 2013. 878

[2] M. Wernke, P. Skvortsov, F. Dürr, K. Rothermel, A classification of location pri- 879 vacy attacks and approaches, Person. Ubiquitous Comput. 18 (1) (2014) 163–880

881 re- 882 8–883

884 o- 885 op 886

887 ces 888 nal 889 03, 890

891 sed 892

893 in: 894 ng, 895

896 CM 897 M, 898

899 for 900 er- 901 7–902

903 for 904 er- 905 08, 906

907 id- 908 ns. 909

910 yp- 911 ’07, 912

913 yp- 914 05, 915

916 ion 917 irst 918 m- 919

920 id- 921 5–922

923 ce- 924

925 et- 926

927 o- 928 gs 929

14, 930 931

[19] C.A. Ardagna, M. Conti, M. Leone, J. Stefa, An anonymous end-to-end commu- 932 nication protocol for mobile cloud environments, IEEE Transactions on Services 933 Computing 7 (3) (2014) 373–386. 934

[20] X. Bao, Y. Lin, U. Lee, I. Rimac, R.R. Choudhury, Dataspotting: Exploiting nat- 935 urally clustered mobile devices to offload cellular traffic, in: Proceedings of 936 the IEEE International Conference on Computer Communications, INFOCOM’13, 937 IEEE, 2013, pp. 420–424. 938

[21] M. Conti, L. Zhang, S. Roy, R. Di Pietro, S. Jajodia, L.V. Mancini, Privacy- 939 preserving robust data aggregation in wireless sensor networks, Secur. Com- 940 mun. Netw. 2 (2) (2009) 195–213. 941

[22] H. Gao, C.H. Liu, W. Wang, J. Zhao, Z. Song, X. Su, J. Crowcroft, K.K. Leung, 942 A survey of incentive mechanisms for participatory sensing, Commun. Surv. 943 Tutor., IEEE 17 (2) (2015) 918–943. 944

[23] Q. Li, G. Cao, Providing privacy-aware incentives for mobile sensing, in: Pro- 945 ceedings of the International Conference on Pervasive Computing and Com- 946 munications, PerCom’13, IEEE, 2013, pp. 76–84. 947

[24] M. Conti, C. Boldrini, S.S. Kanhere, E. Mingozzi, E. Pagani, P.M. Ruiz, M. You- 948 nis, From manet to people-centric networking: milestones and open research 949 challenges, Comput. Commun. 71 (2015) 1–21. 950

[25] J. Li, Q. Huang, X. Chen, S.S.M. Chow, D.S. Wong, D. Xie, Multi-authority 951 ciphertext-policy attribute-based encryption with accountability, in: Proceed- 952

ca- 953 954

cy, 955 956

ap- 957 the 958 08, 959

960 for 961 na- 962 nd 963

964 ion 965 ’15, 966

967 ca- 968 in 969

970 ri- 971 u- 972

973 ion 974

975 ate 976 m- 977

978 fd/ 979

980 ca/ 981

982 et. 983

984 tp: 985 l- 986

987 ew 988 on 989

990 en- 991 IoT 992 op, 993

994 995

k- 996 ch- 997

998 ity: 999

. 10 0 0 ity 1001 on 1002

1003 in 1004 na- 1005

1006 ion 1007 96. 1008 old 1009 ual 1010 5– 1011

1012 or- 1013

1014

175.

[3] M. Conti, J. Willemsen, B. Crispo, Providing source location privacy in wi

less sensor networks: a survey, IEEE Commun. Surv. Tutor. 15 (3) (2013) 1231280.

[4] Y. Zhu, D. Ma, D. Huang, C. Hu, Enabling secure location-based services in mbile cloud computing, in: Proceedings of the Second ACM SIGCOMM Worksh

on Mobile Cloud Computing, MCC’13, 2013, pp. 27–32. [5] M. Gruteser, D. Grunwald, Anonymous usage of location-based servi

through spatial and temporal cloaking, in: Proceedings of the 1st Internatio

Conference on Mobile Systems, Applications and Services, MobiSys’03, 20pp. 31–42.

[6] H. Shin, J. Vaidya, V. Atluri, A profile anonymization model for location-baservices, J. Comput. Secur. 19 (5) (2011) 795–833.

[7] T.M. Truta, B. Vinay, Privacy protection: p-sensitive k-anonymity property, Proceedings of the 22nd IEEE International Conference on Data Engineeri

ICDE’06, 2006, p. 94.

[8] X. Xiao, Y. Tao, Personalized privacy preservation, in: Proceedings of the ASIGMOD international conference on Management of data, SIGMOD’06, AC

2006, pp. 229–240. [9] Z. Xiao, J. Xu, X. Meng, p-sensitivity: A semantic privacy-protection model

location-based services, in: Proceedings of the 9th IEEE International Confence on Mobile Data Management Workshops, MDMW ’08, IEEE, 2008, pp. 4

54.

[10] A. Solanas, F. Sebé, J. Domingo-Ferrer, Micro-aggregation-based heuristics p-sensitive k-anonymity: one step beyond, in: Proceedings of the 2008 Int

national Workshop on Privacy and Anonymity in Information Society, PAIS’2008, pp. 61–69.

[11] R. Shokri, G. Theodorakopoulos, P. Papadimitratos, E. Kazemi, J.-P. Hubaux, Hing in the mobile crowd: location privacy through collaboration, IEEE Tra

Depend. Secure Comput. 11 (3) (2014) 266–279.

[12] J. Bethencourt, A. Sahai, B. Waters, Ciphertext-policy attribute-based encrtion, in: Proceedings of the IEEE Symposium on Security and Privacy, S&P

2007, pp. 321–334. [13] A. Sahai, B. Waters, Fuzzy identity-based encryption, in: Advances in Cr

tology – EUROCRYPT 2005, Lecture Notes in Computer Science, 3494, 20pp. 457–473.

[14] T. Yang, C. Tang, L. Yu, W. Xin, Y. Deng, J. Hu, Z. Chen, VLSP: enabling locat

privacy in vehicular location based services, in: Proceedings of the 2011 FInternational Conference on Instrumentation, Measurement, Computer, Co

munication and Control, MCCC’11, 2011, pp. 462–465. [15] C. Boldrini, M. Conti, F. Delmastro, A. Passarella, Context-and social-aware m

dleware for opportunistic networks, J. Netw. Comput. Appl. 33 (5) (2010) 52541.

[16] H. Nishiyama, M. Ito, N. Kato, Relay-by-smartphone: realizing multihop devito-device communications, IEEE Commun. Mag. 52 (4) (2014) 56–65.

[17] M. Conti, F. Delmastro, G. Minutiello, R. Paris, Experimenting opportunistic n

works with wifi direct, in: Wireless Days, WD’13, IEEE, 2013, pp. 1–6. [18] E. Biondi, C. Boldrini, A. Passarella, M. Conti, Optimal duty cycling in m

bile opportunistic networks with end-to-end delay guarantees, in: Proceedinof the 20th European Wireless Conference, European Wireless’14, VDE, 20

pp. 1–6.



ings of the 6th ACM Symposium on Information, Computer and Communi

tions Security, ASIACCS’11, 2011, pp. 386–390.

[26] R. Shokri, J. Freudiger, J.-P. Hubaux, A unified framework for location privaTechnical Report, 2010.

[27] C.A . Ardagna, A . Stavrou, S. Jajodia, P. Samarati, R. Martin, A multi-path proach for k-anonymity in mobile hybrid networks, in: Proceedings of

International Workshop on Privacy in Location-Based Applications, PILBA’2008, pp. 82–101.

[28] H. Takabi, J.B. Joshi, H. Karimi, et al., A collaborative k-anonymity approach

location privacy in location-based services, in: Proceedings of the 5th Intertional Conference on Collaborative Computing: Networking, Applications a

Worksharing, CollaborateCom’09, 2009, pp. 1–9. [29] X. Gong, X. Chen, K. Xing, D.-H. Shin, M. Zhang, J. Zhang, Personalized locat

privacy in mobile networks: a social group utility approach, in: INFOCOMIEEE, 2015, pp. 1008–1016.

[30] G. Zhong, U. Hengartner, Toward a distributed k-anonymity protocol for lo

tion privacy, in: Proceedings of the 9th Annual ACM Workshop on Privacythe Electronic Society, WPES’08, 2008, pp. 33–38.

[31] G. Zhong, U. Hengartner, A distributed k-anonymity protocol for location pvacy, in: IEEE International Conference on Pervasive Computing and Comm

nications, PerCom’09, 2009, pp. 1–10. [32] M.G. Reed, P.F. Syverson, D.M. Goldschlag, Anonymous connections and on

routing, IEEE J. Select. Areas Commun. 16 (4) (1998) 4 82–4 94.

[33] D. Rebollo-Monedero, J. Forné, A. Solanas, A. Martínez-Ballesté, Privlocation-based information retrieval through user collaboration, Comput. Co

mun. 33 (6) (2010) 762–774. [34] United states census bureau - quick facts, http://quickfacts.census.gov/q

states/36/36061.html . [35] Focus on milan, 2012, http://allegati.comune.milano.it/Statisti

AnnuariStatistici/MilanoInBreve2012/FocusOnMilano2012.pdf . [36] Pew Research Center – U.S. Smartphone Use in 2015, http://www.pewintern

org/2015/04/01/us- smartphone- use- in- 2015/ .

[37] Lo scenario social, digital e mobile in europa e in italia, ht//www.wired.it/internet/social-network/2014/02/17/lo-scenario-social-digita

e- mobile- europa- e- italia/ . [38] M. Gielen, Ad hoc networking using wi-fi during natural disasters: overvi

and improvements, in: Proceedings of the 17th Twente Student ConferenceIT, TSConIT ’12, Vol. 17, 2012.

[39] M. Ambrosin, M. Conti, T. Dargahi, On the feasibility of attribute-based

cryption on smartphone devices, in: Proceedings of the 2015 Workshop on Challenges in Mobile and Industrial Systems, IoT-Sys’15: MobiSys’15 worksh

2015, pp. 49–54. [40] OpenSSL library., https://www.openssl.org/ .

[41] P. Samarati, L. Sweeney, Protecting privacy when disclosing information:anonymity and its enforcement through generalization and suppression, Te

nical Report, SRI International, 1998.

[42] A. Machanavajjhala, D. Kifer, J. Gehrke, M. Venkitasubramaniam, L-diversprivacy beyond k-anonymity, ACM Trans. Knowl. Discov. Data 1 (1) (2007) 3

[43] N. Li, T. Li, S. Venkatasubramanian, t-closeness: privacy beyond k-anonymand l-diversity., in: Proceedings of the 23rd IEEE International Conference

Data Engineering, ICDE’07, 2007, pp. 106–115. [44] B. Bamba, L. Liu, P. Pesti, T. Wang, Supporting anonymous location queries

mobile environments with privacygrid, in: Proceedings of the 17th Inter

tional Conference on World Wide Web, WWW’08, 2008, pp. 237–246. [45] A. Khoshgozaran, C. Shahabi, A taxonomy of approaches to preserve locat

privacy in location-based services, Int. J. Comput. Sci. Eng. 5 (2) (2010) 86–[46] R. Shokri, C. Troncoso, C. Diaz, J. Freudiger, J.-P. Hubaux, Unraveling an

cloak: K-anonymity for location privacy, in: Proceedings of the 9th AnnACM Workshop on Privacy in the Electronic Society, WPES’10, 2010, pp. 11

118.

[47] X. Chen, J. Pang, Protecting query privacy in location-based services, GeoInfmatica 18 (1) (2014) 95–133.


02

http://dx.doi.org/10.13039/501100000780

http://quickfacts.census.gov/qfd/states/36/36061.html

http://allegati.comune.milano.it/Statistica/AnnuariStatistici/MilanoInBreve2012/FocusOnMilano2012.pdf

http://www.pewinternet.org/2015/04/01/us-smartphone-use-in-2015/

http://www.wired.it/internet/social-network/2014/02/17/lo-scenario-social-digital-e-mobile-europa-e-italia/

https://www.openssl.org/


article in press - ایران عرضهiranarze.ir/wp-content/uploads/2016/11/e661.pdf · article in...

Documents