privacy-preserving mobility-casting in opportunistic networks · section vii for details. finally,...

9
Privacy-Preserving Mobility-Casting in Opportunistic Networks Gianpiero Costantino, Fabio Martinelli, Paolo Santi IIT-CNR, Pisa, Italy Email: [email protected] Abstract—In this paper, we introduce the notion of mobility- cast in opportunistic networks, according to which a message sent by a node S is delivered to nodes with a mobility pattern similar to that of S – collectively named place-friends. The motivation for delivering a message to place-friends stems from the fact that current social acquaintances are likely to be place-friends. Most importantly, it has been recently found that a large fraction of new social contacts comes from place-friends. After introducing mobility-cast, we present a privacy- preserving mobility-cast protocol based on the MobileFairPlay platform for secure two-party computation in mobile environ- ments. The effectiveness of the protocol in delivering messages to place-friends is demonstrated by means of simulations based on a real-world GPS trace. Finally, in the last part of the paper we present an imple- mentation of mobility-cast on the Android platform, and test its computational performance on a number of different smart- phones. Overall, the results presented in this paper show that privacy-preserving mobility-cast can be effectively implemented with current mobile phone technology. I. I NTRODUCTION While mobile social networks have attracted considerable interest in the research and industrial community in recent years, some issues are still to be solved before they gain full acceptance in the user community. First, if opportunistic com- munications are used to drive the information dissemination process, forwarding mechanisms should be designed that are able to deliver information to all and only the interested users, so to reduce spamming of messages throughout the network. Furthermore, privacy issues should be carefully considered when designing a mobile social application. On the one hand, knowledge of private user information such as interest profile, mobility pattern, social ties, etc., has been proved very useful in improving the information propagation process within the network [5], [7], [9], [11]. On the other hand, users are increasingly reluctant in sharing such sensible information with strangers, which motivate the need for protocols that consider user privacy in the design cycle by exploiting the privacy-by-design concept. In this paper, we try to address the above described is- sues by introducing an innovative information dissemination mechanism, called mobility-cast, and by presenting a privacy- preserving implementation of a mobility-cast protocol. The idea at the core of mobility-cast is delivering a message M generated by a user U to users who display a mobility pattern similar to U ’s one. Following [12], in this paper we call such set of users the place-friends of user U . As described in greater detail in Section II, mobility-cast finds its motivation in the observation that not only current social acquaintances are likely to be place-friends, but also a large fraction of new social contacts comes from place-friends. The mobility-cast protocol that we introduce, which we call 2H since information is propagated only up to the second communication hop, is built upon a secure function to estimate place-friendships between two users. As carefully analyzed in Section VI, the function is secure in the sense that, after its execution, a party only acquires minimal information about the other party’s mobility profile. The amount of information disclosed to the other party can be controlled through a design parameter of the protocol. In this paper, we show 2H effectiveness not only in preserv- ing user privacy, but also in actually delivering information precisely to place-friends: the results of simulation experi- ments performed on a real data trace show that 2H strikes the best compromise between coverage, precision, and cost, amongst the protocols evaluated in the experiments – see Section VII for details. Finally, we report the results of measurements we have performed on different smartphones with the goal of estimating the running time of the secure place-friendship estimation function at the core of 2H. The results have shown that running times are acceptable (as low as 10 sec) even with current smartphone technology. II. MOTIVATION We want to implement a communication primitive for opportunistic networks which delivers a copy of message M generated by user A to all nodes in the network with a mobility pattern similar to A. In accordance with [12], we call the set of nodes with a mobility pattern similar to node A the place- friends of node A. How to formally define a user’s mobility pattern and a similarity metric between mobility patterns (and, hence, the set of place-friends) is deferred to later sections. We call the communication primitive that delivers a copy of the message to place-friends mobility-cast. Mobility-cast is motivated by the observation that social interactions often occur between individuals with similar mo- bility patterns: e.g., colleagues who work in the same place, friends attending the same fitness class, etc. This intuitive observation is quantitatively evaluated in [4], where the authors show that social ties between people can be inferred with a good accuracy from co-occurrence in time and space. Hence,

Upload: others

Post on 25-Sep-2020

0 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Privacy-Preserving Mobility-Casting in Opportunistic Networks · Section VII for details. Finally, ... preserving protocol for geo-casting a message to a specific 1Notice, though,

Privacy-Preserving Mobility-Casting inOpportunistic NetworksGianpiero Costantino, Fabio Martinelli, Paolo Santi

IIT-CNR, Pisa, ItalyEmail: [email protected]

Abstract—In this paper, we introduce the notion of mobility-

cast in opportunistic networks, according to which a message sentby a node S is delivered to nodes with a mobility pattern similarto that of S – collectively named place-friends. The motivationfor delivering a message to place-friends stems from the fact thatcurrent social acquaintances are likely to be place-friends. Mostimportantly, it has been recently found that a large fraction ofnew social contacts comes from place-friends.

After introducing mobility-cast, we present a privacy-preserving mobility-cast protocol based on the MobileFairPlayplatform for secure two-party computation in mobile environ-ments. The effectiveness of the protocol in delivering messagesto place-friends is demonstrated by means of simulations basedon a real-world GPS trace.

Finally, in the last part of the paper we present an imple-mentation of mobility-cast on the Android platform, and testits computational performance on a number of different smart-phones. Overall, the results presented in this paper show thatprivacy-preserving mobility-cast can be effectively implementedwith current mobile phone technology.

I. INTRODUCTION

While mobile social networks have attracted considerableinterest in the research and industrial community in recentyears, some issues are still to be solved before they gain fullacceptance in the user community. First, if opportunistic com-munications are used to drive the information disseminationprocess, forwarding mechanisms should be designed that areable to deliver information to all and only the interested users,so to reduce spamming of messages throughout the network.Furthermore, privacy issues should be carefully consideredwhen designing a mobile social application. On the one hand,knowledge of private user information such as interest profile,mobility pattern, social ties, etc., has been proved very usefulin improving the information propagation process within thenetwork [5], [7], [9], [11]. On the other hand, users areincreasingly reluctant in sharing such sensible informationwith strangers, which motivate the need for protocols thatconsider user privacy in the design cycle by exploiting theprivacy-by-design concept.

In this paper, we try to address the above described is-sues by introducing an innovative information disseminationmechanism, called mobility-cast, and by presenting a privacy-preserving implementation of a mobility-cast protocol. Theidea at the core of mobility-cast is delivering a message Mgenerated by a user U to users who display a mobility patternsimilar to U ’s one. Following [12], in this paper we call suchset of users the place-friends of user U . As described in

greater detail in Section II, mobility-cast finds its motivationin the observation that not only current social acquaintancesare likely to be place-friends, but also a large fraction of newsocial contacts comes from place-friends.

The mobility-cast protocol that we introduce, which we call2H since information is propagated only up to the secondcommunication hop, is built upon a secure function to estimateplace-friendships between two users. As carefully analyzed inSection VI, the function is secure in the sense that, after itsexecution, a party only acquires minimal information aboutthe other party’s mobility profile. The amount of informationdisclosed to the other party can be controlled through a designparameter of the protocol.

In this paper, we show 2H effectiveness not only in preserv-ing user privacy, but also in actually delivering informationprecisely to place-friends: the results of simulation experi-ments performed on a real data trace show that 2H strikesthe best compromise between coverage, precision, and cost,amongst the protocols evaluated in the experiments – seeSection VII for details.

Finally, we report the results of measurements we haveperformed on different smartphones with the goal of estimatingthe running time of the secure place-friendship estimationfunction at the core of 2H. The results have shown that runningtimes are acceptable (as low as 10 sec) even with currentsmartphone technology.

II. MOTIVATION

We want to implement a communication primitive foropportunistic networks which delivers a copy of message Mgenerated by user A to all nodes in the network with a mobilitypattern similar to A. In accordance with [12], we call the setof nodes with a mobility pattern similar to node A the place-friends of node A. How to formally define a user’s mobilitypattern and a similarity metric between mobility patterns (and,hence, the set of place-friends) is deferred to later sections. Wecall the communication primitive that delivers a copy of themessage to place-friends mobility-cast.

Mobility-cast is motivated by the observation that socialinteractions often occur between individuals with similar mo-bility patterns: e.g., colleagues who work in the same place,friends attending the same fitness class, etc. This intuitiveobservation is quantitatively evaluated in [4], where the authorsshow that social ties between people can be inferred with agood accuracy from co-occurrence in time and space. Hence,

Page 2: Privacy-Preserving Mobility-Casting in Opportunistic Networks · Section VII for details. Finally, ... preserving protocol for geo-casting a message to a specific 1Notice, though,

2

delivering a message to node A’s place-friends is likely toreach many relevant social ties of node A. More importantly, ithas been recently shown [12] that a large fraction (about 30%)of new social interactions arise between place-friends. Similarobservations have been done in [16], where it is shown thatindividuals with similar mobility patterns are likely to be closein the social network graph formed of the phone calls betweenusers. Thus, delivering a message to place-friends is useful notonly to reach current social ties, but also forthcoming socialties. Indeed, we can imagine that a mobility-cast primitivemight even increase the fraction of social interactions betweenplace-friends well beyond the 30% value observed in [12].Suppose individual B, who is a stranger but place-friend ofnode A, receives an interesting message M from A (e.g.,announcing a special event in which B is very interested);having received M , node B might be stimulated to initiate adirect, social interaction with node A.1

Since mobility-cast can be used to deliver messages tocurrent, as well as future, social ties, its possible uses inthe context of mobile social networking applications arenumerous. For instance, mobility-cast can be used by a fullydistributed, opportunistic mobile social networking applicationto effectively disseminate a message to friends without flood-ing the network. Even more importantly, mobility-cast canbe used to implement fully-distributed, opportunistic “friendrecommendation” services for social networking applications.

III. RELATED WORK

A number of recent studies have shown that the effective-ness of the information propagation process can be improvedby having users exchange some type of personal informationto drive the process. In [5], [7], the authors show that the ef-fectiveness of unicasting a message to destination is improvedby considering user social metrics (e.g., centrality in the socialnetwork graph) in the forwarding process. The authors of [11]instead proposed exchanging user interest profiles in order todeliver messages only to interested users. A work which iscloser in spirit to ours is [9], where the authors propose touse the user mobility profile to drive message forwarding.However, the focus in [9] is in unicasting a message to a spe-cific destination, while in this paper we aim at implementinga novel communication primitive, namely, mobility-casting.Furthermore, privacy issues are not considered in [9], andmobility profiles are exchanged in clear between users.

Another line of research which is related to our work isprivacy-preserving protocols for opportunistic networks. Mostof existing approaches focus only on securely computingwhether two mobile users are “friends”, where the specificdefinition of friendship depends on the approach at hand[6], [8], [22]. A few protocols consider network-wide infor-mation propagation protocols built on top privacy-preserving“friendship” estimation. In [1], the authors introduce a privacy-preserving protocol for geo-casting a message to a specific

1Notice, though, that this would require node A to include his/her identityin M , which might be at odds with the need of preserving privacy.

geographic location. In [2], the authors of this paper presenta privacy-preserving approach for implementing the interest-casting primitive introduced in [11], and analyze the privacy-preservation vs. forwarding accuracy tradeoff which is in-herent in the design. The interest-casting protocol has beenimplemented within the MobileFairPlay platform for securetwo-party computation in mobile devices [3]. While similarin spirit to the study presented herein, the works in [2], [3]consider an existing opportunistic communication primitive,namely, interest-casting [11]. On the contrary, in this work weintroduce the novel mobility-casting communication primitive,and present a privacy-preserving, effective implementation ofthe proposed primitive.

IV. DEFINING PLACE-FRIENDS

In order to define place-friends, we need to formally definea notion of individual mobility pattern, and a similarity metricbetween mobility patterns. Concerning definition of mobilitypattern, two approaches are typically used in the literature:a point-of-interest based approach, or a partition-based ap-proach. In the former approach, a number of points-of-interest(shopping centers, touristic attractions, public parks, etc.) areidentified within the area of interest (typically, a city). A user’smobility profile is then defined by the visiting frequency of thepoints-of-interest. This notion of mobility profile is used, e.g.,in [12]. In the partition-based approach, the area of interestis partitioned into a number of non-overlapping regions, anda user’s mobility profile is given by the visiting frequencyof each sub-region. Sub-regions typically are defined as thecoverage area of a cell-tower (see, e.g., [14]), or based on asquare cell partitioning (see, e.g., [1], [4], [9]).

While in principle our ideas can be applied to any defi-nition of mobility pattern, for the sake of definiteness in thefollowing we use a square grid partition-based approach. Morespecifically, we assume the mobility region R is a square ofside `, which is logically partitioned into m = h2 squarecells of side `

h

, where h is a tunable parameter. Assuming anarbitrary ordering of the m cells, the mobility pattern of a userA is defined as an m-dimensional vector M

A

= (xA

1 , . . . , xA

m

)

of real numbers xA

i

2 [0, 1], where xA

i

denotes the relativevisiting frequency for the i-th cell, and

Pi

xA

i

= 1.Given the above definition, and in accordance with [9], a

user’s mobility pattern can be represented as a vector (point)in an m-dimensional vectorial space. Different similarity met-rics can be used to compare two mobility patterns. In [9],the authors suggest to use Euclidean distance between thetwo points corresponding to the individual mobility patterns.Alternatively, one can use the cosine similarity metric usedin [11] to quantify similarity between user interests, whereinterest profiles are represented as points in a vectorial space aswell. However, we have to consider that vectors representingmobility patterns are likely to be highly skewed, with mostcells visited with near zero frequency, and only a few cellsvisited on a regular basis. This observation comes from recentstudies showing that individuals tend to spend most of the timein a few locations: more specifically, the visitation frequency

Page 3: Privacy-Preserving Mobility-Casting in Opportunistic Networks · Section VII for details. Finally, ... preserving protocol for geo-casting a message to a specific 1Notice, though,

3

of locations follows a Zipf’s law with exponent 1.2 [14],corresponding to having an individual spending about 60%of the time in the 5 most popular locations. Thus, similaritymetrics that consider all coordinates in the vectorial space suchas Euclidean distance and cosine metric tend to shallow therelative difference/similarity between mobility patterns, due tothe many close-to-zero coordinates which are present in theoverwhelming majority of mobility patterns.

To get around this problem, in this paper we use a similaritymetric based on comparing the k cells most frequently visitedby users. More specifically, let F

A

= {iA1 , . . . , iAk

} and FB

=

{iB1 , . . . , iBk

} be the set of most frequently visited cells of userA and B, respectively, where iX

j

denotes the ordinal numberin the cell ordering of the j-th most frequently visited cell ofuser X . We say that users A and B are place-friends if andonly if

|FA

\ FB

| � ˆ� ,

where ˆ�, with 1 ˆ� k, is a tunable integer parameterrepresenting the minimal degree of similarity needed to declaretwo users place-friends.

Notice that, differently from other metrics such as Euclideandistance and cosine metric, the notion of similarity definedabove is apt to a scenario in which most of the x

i

values in amobility profile are near-zero, since only the most frequentlyvisited cells are accounted for in the similarity metric. Fur-thermore, the notion of similarity defined above is apt to aprivacy-preserving implementation, using well-known securetwo-party protocols for secure set intersection computation(see below).

V. THE MOBILITY-CAST PROTOCOL

Participants in Mobility-Cast are users who have a GPS-equipped device, like smartphones or tablets, that can keeptrace of their mobility pattern during the daily life. In ourprotocol, we consider that the map of a zone, e.g., a city, is splitinto cells. Cells can assume different size, for instance theycan be represented by a square where each side is long 10, 100or 1000 meters. Clearly, there is a tradeoff between locationaccuracy (lower with larger cells), and memory requirementson the device (larger with smaller cells).

The current location of a user is collected at regular timeintervals (e.g., a few minutes), and it is stored in a file.At regular intervals (say, every few hours or a day), all thecollected data are processed to calculate the visiting frequencyfnew

(Ci

) for each cell Ci

in the map. The new frequencyvalues are combined with the previously stored frequencyvalue f

old

(Ci

) to compute the current mobility profile ofthe user. We use the typical exponentially weighted movingaverage (EWMA) to compute the mobility profile of the user,i.e., we update the frequency value f(C

i

) for cell Ci

asfollows:

fold

(Ci

) = f(Ci

), f(Ci

) = ↵fnew

(Ci

)+(1�↵)fold

(Ci

) ,

where 0 < ↵ < 1 is the degree of weighting decrease.

Starting from the vector f(Ci

) of frequency values foreach cell C

i

, our protocol builds the user mobility profile bymaintaining a list of the IDs of the k most visited cells, i.e.,the index set FA for user A. Notice that, since our protocol isbased on computing the set intersection between the F sets,elements in FA are not ordered.

In order to provide a privacy-preserving comparison be-tween user mobility profiles, we propose a solution based onSecure Two-party Computation functions [21]. We recall thatin secure two-party computation we have two parties (Aliceand Bob), each holding some private data x and y, respectively.The goal of secure two-party function computation is allowingAlice and Bob to jointly compute the outcome of a functiong(x, y), without disclosing to the other party the own input.The straightforward way to solve the above problem wouldbe to have a Trusted Third Tarty (TTP) to which Alice andBob securely send the data, and to have the TTP computeg(x, y) and separately send the outcome to Alice and Bob. Thebusiness in secure two-party computation amounts to securelycompute g(x, y) without the need of a TTP.

We adopt our recently developed MobileFairPlay framework[3], which is a Android-based implementation of the FairPlayframework to run secure functions [10]. FairPlay has beenproven to be secure against a malicious party; in particular i) amalicious party cannot learn more information about the otherparty’s input than it can learn from a TTP that computes thefunction; and ii) a malicious party cannot change the outputof the computed function [10]. Notice that, as customary insecure two-party computation, there is an asymmetry on theprovided security guarantees: in particular, there is no wayto prevent Alice from terminating the protocol prematurely,and not sending the outcome of the computation to Bob. Thissituation can be detected by Bob, but cannot be recoveredfrom.

In Fig. 1 we pictorially present our protocol, which makesuse of Secure-two party computation to compare Alice andBob mobility profiles. The protocol assume a threshold value� ˆ�, known to all participants, is used to control themessage forwarding process. The protocols starts when Aliceand Bob are in close proximity; for instance, using a Bluetoothconnection, when they are less than 20m apart. Initially, Alicestarts a connection to Bob; once received the connectionrequest from Alice, Bob starts the secure computation of thefunction:

g(FA, FB

) =

⇢True if |F

A

\ FB

| � �False otherwise . (1)

If the profiles are found to be similar, Alice and Bobare estimated as place-friends, and they start comparing thecontent of their buffers and exchange files. Otherwise, theconnection is terminated. Notice that, if � < ˆ�, functiong(FA, FB

) might evaluate at True even if Alice and Bobare not place-friends. This situation can be avoided by setting� =

ˆ�. However, as we shall see in the next section, increasingthe value of � is detrimental for privacy preservation sincemore information about the own mobility pattern is disclosed

Page 4: Privacy-Preserving Mobility-Casting in Opportunistic Networks · Section VII for details. Finally, ... preserving protocol for geo-casting a message to a specific 1Notice, though,

4

����� ���

������� ��

�������������������������������������

������

���������������������

!�

������� �������"���"���"������

��� ������#$!%�!&�$

'()''(�''('*+'('$)'('+!

��� ������#*!%�!,�

'()$,'(!*'('&$'('))'(',!

�� ��

-�� ���� �-.�������

-�� ���� �-.�

��������������������

Fig. 1. Protocol flow to discover similarity of mobility profiles.

to the other party during the computation. For this reason,using a value of � lower than ˆ� is often preferable in practice.

The message forwarding policy is as follows. If Alice isthe sender of a message M , or if Alice received the messagedirectly from the sender, M is delivered to Bob if Alice andBob are estimated to be place-friends according to function(1). In all other cases, including the case in which Alice andBob are estimated to be place-friends but Alice received Mfrom a node which is not the sender of M , M is not deliveredto Bob. Notice that this forwarding policy, which can easilybe implemented including an hop-count field in the message,ensures that any message travels at most two-hops to reacha place-friend. For this reason, we name our protocol 2-hopsmobility-cast (2H for short).

Restricting message forwarding to two hops finds its moti-vation in the fact that, due to the need of preserving privacy,Alice and Bob always use their own mobility profiles toestimate place-friendships. Hence, the decision on whether amessage M generated by node S and currently in Alice’sbuffer should be forwarded to Bob is not based on thesimilarity between Bob’s and S’s mobility profiles, but on thesimilarity between Alice’s and Bob’s profiles. This impliesthat the message M can be delivered to nodes that are notplace-friends of S, impacting the precision of the forwardingprocess. It is easy to see that the higher the hop distance fromS, the higher the likelihood of forwarding the message to afalse place-friend of S. On the other hand, message forwardingis useful to speed up the message propagation process andincrease coverage. Restricting forwarding up to the secondcommunication hop is a compromise that has been shown towork well in related work [2].

VI. PRIVACY ANALYSIS

While not disclosing user mobility profiles, a certain leakageof private information is unavoidable when using secure two-party computation. In particular, at the end of the protocolcomputation, the following information is leaked to the otherparty:

– if the outcome of g(FA, FB

) is True, the party (say, Bob)knows that at least � of his most popular locations arein common with Alice. However, he does not know theexact number of common locations (can be any numberin the [�, k] interval), nor which they are exactly. Only inthe case that � = k Bob knows that Alice has the sameexact mobility profile as the own profile.

– If the outcome of g(FA, FB

) is False, Bob knows onlythat less than � of his most popular locations are incommon with Alice. However, he does not know the exactnumber of common locations (can be any number in the[0,�� 1] interval), nor which they are exactly.

To quantitatively evaluate privacy leakage, we use theentropy-based privacy preservation metric introduced in [2].In particular, we want to quantify the privacy leakage causedby the protocol execution, under the assumption that theattacker’s goal is discovering the other party’s mobility profile,i.e., his/her k most frequent locations. Taking w.l.o.g. Alice’sperspective, Bob’s profile is a set of k cell IDs, which can bemodeled as a random variable Y = (y1, . . . , yk). Each specificrealization of r.v. Y is denoted Y

i

, and corresponds to a setof k cell IDs chosen amongst the m possible cell IDs. Hence,the number of possible values of r.v. Y is

�m

k

�.

The bit entropy of a random variable Y with possible values{y1, . . . , yn} is defined as [13]:

H[Y ] = �nX

i=1

p(Yi

) log2 p(Yi

) ,

where p(y) is the probability mass function of random variableY . The privacy preservation metric of a certain protocol P isdefined as

pp(P) =

H[Yafter

]

H[Yinitial

]

,

where Yinitial

and Yafter

are the r.v. modeling Alice’s un-certainty about Bob’s profile initially and after the executionof protocol P, respectively. The pp metric takes values in[0, 1], with 0 indicating that after P’s execution Alice knowsexactly Bob’s mobility profile (zero privacy preservation),and 1 indicating that after P’s execution Alice has the sameknowledge about Bob’s profile he had before executing theprotocol (maximal privacy preservation).

To quantify the pp metric, we need to make same as-sumptions about the distribution of r.v. Y . In the following,we quantify privacy leakage under the assumption that alllocations have the same probability of being included in anode’s mobility profile. In other words, we assume that all�m

k

�possible subsets of k out of m possible cell IDs are

equiprobable. Notice that this assumption is not necessarily incontrast with the observation made in [14] that people tend

Page 5: Privacy-Preserving Mobility-Casting in Opportunistic Networks · Section VII for details. Finally, ... preserving protocol for geo-casting a message to a specific 1Notice, though,

5

to frequently visit only a few locations. In fact, people ingeneral have different more frequently visited location, andthe resulting aggregate location popularity (which is the onethat determines the distribution of r.v. Y ) might be relativelyuniform. On the other hand, analyzing privacy leakage undera non-uniform location popularity assumption (e.g., assumingZipf’s law) is cumbersome, due to the need of computingeach single p(Y

i

) value in the definition of bit-entropy. Thisfurther justifies our working assumption of uniform locationpopularity.

Let us first compute H[Yinitial

]. If locations (cell IDs) haveuniform popularity, from Alice’s perspective any of the

�m

k

possible Bob’s mobility profiles has the same probability 1

(

mk )

of occurrence. Hence, we get:

H[Yinitial

] = �(

mk )X

i=1

p(Yi

) log2 p(Yi

) = �(

mk )X

i=1

1�m

k

�log2

1�m

k

�=

=

(

mk )X

i=1

1�m

k

�log2

✓m

k

◆= log2

✓m

k

◆.

Let us now compute H[Yafter

]. We recall that the value of� used to estimate place-friendship is fixed and know to bothparties. We distinguish the case of protocol execution withoutcome True or False.

If the outcome is True, after the protocol execution Aliceknows that Bob’s mobility profile has at least � k locationsin common with the own profile. Fixed a value h, with � h k, of possible common locations, the number of possiblechoices for Bob’s profile with h locations in common withAlice can be computed as follows:

✓k

h

◆·✓m� k

k � h

◆.

In fact, the first binomial coefficient accounts for all possiblechoices of the h locations in common with Alice’s profile,taken amongst the k locations in Alice’s profile. The secondbinomial coefficient accounts for all possible choices of theremaining k � h locations in Bob’s profile, which are takenamongst the m � k locations which are not in common withAlice’s profile.

Given the above, we can compute H[Yafter

] in case of Trueoutcome as follows:

H[Y T

after

] = log2

kX

h=�

✓k

h

◆·✓m� k

k � h

◆!.

If the outcome is False, Alice knows that all possibleBob’s profiles with at least � locations in common with theown profile should be excluded from the universe of possibleprofiles, i.e.,

H[Y F

after

] = log2

✓m

k

◆�

kX

h=�

✓k

h

◆·✓m� k

k � h

◆!.

The value of the pp metric for increasing values of k and� = 3 is reported in Figure 2. As expected, a True outcome

of the protocol’s execution discloses more information to theadversary. However, the amount of information disclosed tothe other party can be reduced by increasing the value of thenumber k of locations in the mobility profile. Notice, though,that increasing the value of k beyond a reasonable value has anegative effect on the accuracy of the mobility-cast operation,indicating a tradeoff between networking performance andprivacy already observed in [2] for the case of interest-cast.

Figure 3 reports the pp metric for increasing values of �,with parameter k = 10. In case of True protocol outcome (themost critical case for privacy leakage), we can reduce privacyleakage by reducing the value of �. Also in this case the needof privacy preservation is at odds with the accuracy of themobility-cast operation: with a lower value of �, relativelyless locations must be in common to estimate the two partiesas place-friends, thus potentially propagating a message M tousers who are not actual place-friends of the sender of M .

3 4 5 6 7 8 9 10k

0.2

0.4

0.6

0.8

1.0pp

False

True

Fig. 2. Value of the pp metric for increasing values of k, with parameter �fixed to 3.

2 4 6 8 10l

0.2

0.4

0.6

0.8

1.0pp

False

True

Fig. 3. Value of the pp metric for increasing values of �, with parameter kfixed to 10.

Finally, we briefly analyse the case in which an attackeruses his network interface to eavesdrop the channel trying toinfer whether Alice and Bob are place-friends. To this purpose,we split our protocol flow into two phases: i) the SecureComputation Set Intersection and ii) the Packet Forwarding.On the first phase, the attacker observes only parts of thesecure-two party protocol that are not significative for him, sohe is not able to read sensible data such us cells frequented,or common cells. On the second phase, which occurs onlyif Alice and Bob have common cells, the attacker may seethe file transferred from and, also, he may infer that they areplace-friends, although the attacker is not able to know theircommon cells. A solution for this kind of attack is the use of a

Page 6: Privacy-Preserving Mobility-Casting in Opportunistic Networks · Section VII for details. Finally, ... preserving protocol for geo-casting a message to a specific 1Notice, though,

6

cryptographic tunnel between Alice and Bob communications.in fact, the tunnel will hide the entire communication contentand, the attacker will not be able to deduce whether they areplace-friends.

VII. EXPERIMENTAL EVALUATION

In order to estimate the performance of 2H , we have usedthe real-world mobility trace available through the MicrosoftResearch GeoLife GPS Trajectories project [17][18][19]. Thedataset provides GPS trajectories of 182 people collected in aperiod of over five years (from April 2007 to August 2012). AGPS trajectory is represented by a sequence of time-stampedpoints stored every 1 to 5 seconds or every 5 to 10 meters.Each point contains the information of latitude, longitude andaltitude and majority of the data was collected in Beijing.

Since the original dataset is huge and covers a very longtime interval, we decided to consider only a time interval ofone year. More specifically, we used the trajectories saved in2008, which is the denser year with 77 active users in thetrace.

A. Data pre-processingIn order to derive user mobility profiles, we divided the

central area of the city of Bejing into square cells. Each cellis 1 Km wide, and in total we consider an area of 340 Km2,corresponding to 340 cells.

Fig. 4. In grey, the consiered area of Beijing

Preliminary to the experiments, we calculated the frequencywith which each user visits the 340 cells using the entire, one-year long data trace. We then recoded for each user her 10most visited cells, which forms her mobility profile. Then, inorder to set the value of ˆ� and � to reasonable values, wehave computed, for each user in the dataset, how many cellson average she has in common with each of the other 76 users.The results of this preliminary evaluation showed that, on theaverage, a user has 1.85 cells in common with another user, butthe variance is high (2.39). This indicates that mobility profileshave very different degrees of similarity between themselves,

which is a good scenario to evaluate the ability of protocol2H to deliver messages precisely to place-friends.

B. Simulation experiments

We implemented a Java simulator that uses the Bejingdata trace to estimate mobility-cast performance. During asimulation experiment, a user U is selected as the messagesender. For the given user U , the simulator identifies within theyear-long trace a two-months portion with the largest densityof encounters. The message M is then generated at node Uat the beginning of the identified two-months stretch of thetrace, and the forwarding process starts according to one ofthe forwarding policies described in the next section. At theend of the experiment, the ID of users that received M isrecorded, as well as the ID of U ’s place-friends (computedusing the mobility profiles). For each timestamp in the datasettrajectory, we consider all possible pairs of generic users Aliceand Bob. If they are within a distance of 1000 m, Alice checkswhether she has in her queue packets that she may forwardto Bob according to the chosen forwarding policy. If this isthe case, depending on whether place-friendship is requiredby the forwarding policy, Alice starts comparing the numberof cells in common with Bob’s mobility profile, and, in casethis number is larger than a threshold �, message forwardingtakes place. Notice that the large value of the transmissionrange of 1 Km – much larger than typical WiFi and Bluetoothcommunication ranges – has been chosen to cope with the verylow density of users per unit area in the data trace.

C. Forwarding protocols

Since 2H is the first mobility-cast protocol introduced in theliterature, there is no direct competitor to compare against.Nevertheless, we have included the following forwardingprotocols in the simulations:

– DD: strictly speaking, DD is not a real forwardingprotocol, since no packet forwarding takes place. In DD,it is only the sender (say, Alice) of a message M who candeliver it to other users. In particular, Alice delivers M toanother user (say, Bob) subject to the condition that Aliceand Bob have at least ˆ� common cells in their mobilityprofile. Since threshold ˆ� is used (instead of threshold �as in protocol 2H), only actual place-friends of Alice canreceive M under protocol DD.

– EP: it is the classical Epidemic forwarding protocol [20].Whenever Alice, who has a copy of M , meets anotheruser (say, Bob) who does not hold M , she forwards acopy of M to Bob. Forwarding occurs independently ofwhether Alice and Bob are place-friends.

– PF: it is a 2-hops probabilistic forwarding protocol.Whenever the sender of message M (say, Alice) en-counters another user (say, Bob), she forwards a copyof M to Bob with fixed probability p. Similarly to EP,forwarding occurs independently of whether Alice andBob are place-friends. The same forwarding rule is usedby any user who received M directly from Alice. No

Page 7: Privacy-Preserving Mobility-Casting in Opportunistic Networks · Section VII for details. Finally, ... preserving protocol for geo-casting a message to a specific 1Notice, though,

7

message forwarding is allowed beyond the second hopof communication.

D. ResultsThe results reported in this section are computed averaging

across 77 simulation experiments, one for each user in the datatrace. The following performance metrics have been estimated:

– Coverage: it is the ratio between the number of place-friends of the sender user U that received the messageM , and the total number of U ’s place-friends. Noticethat coverage is computed using threshold ˆ� to defineplace-friends. The coverage metric measures how good aprotocol is at delivering messages to U ’s place-friends.In a sense, coverage can be considered as the counterpartof packet delivery rate in unicast communication.

– Precision: it is the ratio between the number of U ’s place-friends that received M , and the total number of usersthat received M . Precision measures the accuracy of aprotocol in delivering messages only to U ’s place friends.

– Cost: it is the total number of copies of M circulatingin the network at the end of the protocol execution. Costmeasures the routing overhead of a protocol.

– Delay: it is the average time interval elapsing since thetime instant at which U generated M , and the time instantat which a place-friend V 6= U received M for the firsttime.

!"#$

%&#$

%"#$

'&#$

'"#$

(&#$

("#$

!$ %$ '$

!"#$%&'$()*

+(

,&-./&(

0"#$%&'$(#12(,&-./&(

%)$

**$

+,-$

./$

Fig. 5. Coverage of the various forwarding protocols as a function of �.

Figure 5 reports the coverage experienced by the variousforwarding protocols when ˆ� = 3 and � is varied from 1 to3. EP and DD performance is independent of the value of �,since place-friendships is not considered during EP forwardingprocess, while it is defined based on the fixed threshold ˆ�in the DD protocol. PF performance does depend on � forthe following reason. In order to understand whether 2Hforwarding strategy is actually superior to a random one, wehave set the parameter p in PF in such a way that the averagecost of PF is as close as possible to the cost of 2H for thecorresponding value of �. This resulted in setting p = 0.5when � = 1, p = 0.3 when � = 2, and p = 0.2 when� = 3. This explains why, in the plot reported in Figure 5,PF performance changes with �, despite the fact that place-friendship is not considered in the forwarding process.

!"

#"

$!"

$#"

%!"

%#"

$" %" &"

!"#$%&'

(#)#*%

+,(-.,%

!"#$%/#0%+,(-.,%

%'()*"

++"

,-."

Fig. 6. Cost of the various forwarding protocols as a function of �.

As expected, EP has the best coverage performance, dueto the epidemic forwarding process. However, EP pays thefee in terms of cost, which as much as 2.3 times higher thanthat of 2H – see Figure 6. EP performs poorly also in termsof precision, due to the fact that the forwarding process isoblivious to place-friendship – see Figure 7. DD is at theother end of the scale with respect to EP: it has poor coverageperformance but minimum cost due to the lack of forwarding,and it has optimal precision due to the fact that M is deliveredonly to place-friends of the sender node U .

!"#$

%"#$

&"#$

'"#$

("#$

)"#$

*""#$

*$ +$ ,$

!"#$%&%'()*+

,)

-./01.)

!"#$%&%'()2&3)-./01.)

+-$

..$

/01$

23$

Fig. 7. Precision of the various forwarding protocols as a function of �.

Protocols 2H and PF strike a compromise between coverageand cost, improving coverage performance considerably withrespect to DD, while considerably reducing the cost withrespect to EP. It is interesting to compare 2H and PF perfor-mance. While the two protocols display comparable coverageperformance, 2H achieves a much better precision than PF –see Figure 7. This is due to the fact that, while the averagecoverage performance of the two protocols is very similar,the variance in the achieved coverage is very different forthe two protocols – see Table I. The variability in coverageperformance displayed by randomized forwarding explains themuch better performance displayed by 2H with respect to PFin terms of precision.

In Fig. 8 we show the Delay result of all simulated protocol.Findings say that DD reaches the lowest delay value due toits low dissemination power. On the other side EP providesthe highest delay, for the opposite reason DD. However, both

Page 8: Privacy-Preserving Mobility-Casting in Opportunistic Networks · Section VII for details. Finally, ... preserving protocol for geo-casting a message to a specific 1Notice, though,

8

!"""""#

$"""""#

%"""""#

&""""""#

&&"""""#

&# '# (#

!"#$%&'(")*&

#$+,-$&

!"#$%&.(/&#$+,-$&

')#

**#

+,-#

./#

Fig. 8. Delay of the various forwarding protocols as a function of �.

protocols do not depends on � due to their nature. The protocolPF gives different results depending on the � value, reachingthe lowest value for � = 3 in which the probability set for theforwarding is equal to 0.2 . Finally, the 2H protocol results tobe less dependent on the � influence.

Protocol � Var (%) Protocol � Var (%)2H 1 5.3 PF 1 7.72H 2 5.3 PF 2 8.22H 3 5.4 PF 3 9.4

TABLE IVARIANCE IN COVERAGE PERFORMANCE OF PROTOCOLS 2H AND PF.

Summarizing, we can conclude that 2H proved effective indelivering messages only to place-friends, striking the bestcompromise between coverage, precision, cost, and delayamongst the considered protocols. The optimal setting of theparameter � in protocol 2H is a design choice that shouldaccount not only for the performance metrics consideredherein, but also for the privacy preservation properties of theprotocol as analyzed in Section VI.

VIII. PROTOTYPE IMPLEMENTATION OF 2H

In order to verify whether protocol 2H can be efficientlyexecuted with current smartphone technology, we have im-plemented the most computationally intensive task of theprotocol on the Android platform. More specifically, we haveimplemented the secure computation of function g(FA, FB

)

as defined in equation (1). Function g(FA, FB

) secure com-putation is implemented in MobileFairPlay [3], an Android-based implementation of FairPlay [10]. FairPlay functionsmust be written with the language Secure Function DefinitionLanguage (SFDL), which is a high level language that allowsdevelopers to write simple function that are then converted intogarbled boolean circuits. Only a limited number of commandsand operations are available in SFDL. For instance, it is notpossible to use text values in a function, but only integers orsimple types are allowed. MobileFairPlay then transforms anSFDL program into a Java program executable on Androidsmartphones.

The SFDL function that we have written to securely com-pute similarity between Alice’s and Bob’s mobility profiles isquite simple and works by comparing each cell ID in Alice’s

profile with those in Bob’s profile. If the same cell ID appearsin both profiles, then a counter is increased. At the end of thefunction, the value of the counter (common frequently visitedcells) is compared to the threshold � known to both parties. Ifthe comparison is positive, then the output for both Alice andBob is True (represented by integer 1), otherwise it is False(represented by integer 0).

The APP that we have built is a prototype of the 2Hprotocol including secure estimation of place-friendship. Usermobility is traced every minute. Once per day, the applicationtakes all saved GPS coordinates and calculates frequenciesper cells. When two users Alice and Bob meet each other,Alice starts challenging Bob on the number of common cellsthat they have in their profiles in a privacy-preserving manner.The current version of the APP considers mobility profilescomposed of the five most frequently visited cells. Once Alicestarts the connection with Bob through the Bluetooth interface,the devices are automatically paired for the first time. Then, theSecure-Two party computation of function g(FA, FB

) begins.At the end of the computation, both users know the valueof g(FA, FB

). Frequencies per cell used as input by bothparticipant can not be manually inserted, but they are directlyincluded by our APP into the Secure-two party procedure. Thisstep is required to avoid that Alice and Bob may manipulatetheir input guessing the same vector input of the other. Finally,if Alice and Bob recognise each other as place-friends, theystart an interaction phase consisting in sharing files (txt, pdf,jpg, etc.).

To evaluate the computational time of the application, wehave executed the APP on five smartphones, which are listedin Table II together with their technical specifications.

Fig. 9 reports the time needed to compute g(FA, FB

),including communication through the Bluetooth interface. Inthe reported results, the Samsung Galaxy S2 always playedAlice’s role, while the Bob’s role is played by the othersmartphones. We can see that running times range betweenless than 10 and 12.5 seconds, with the best running timeachieved by the fastest smartphone, i.e. Sony Xperia T. We canthen conclude that our proposed 2H protocol can be effectivelyexecuted also with current smartphone technology.

6000

7000

8000

9000

10000

11000

12000

13000

14000

Tim

e (m

s)

Smartphones

S Plus Nexus One HTC Desire Sony Xperia T

Fig. 9. Time needed to compute function g(FA, FB).

Page 9: Privacy-Preserving Mobility-Casting in Opportunistic Networks · Section VII for details. Finally, ... preserving protocol for geo-casting a message to a specific 1Notice, though,

9

Smartphone CPU RAM Bluetooth Ver. Android O.S.Samsung Galaxy S2 Dual-core 1228 MHz 1 GB 3.0 2.3.6

Samsung Galaxy S-Plus Single-core 1443 MHz 512 MB 3.0 2.3.5Samsung Galaxy Nexus One Dual-core 1200 MHz 1024 MB 3.0 4.0

Sony Xperia T Dual-core 1500 MHz 1024 MB 2.1 4.0HTC Desire Single-core 1024 MHz 576 MB 2.1 2.2.3

TABLE IISMARTPHONES USED FOR TESTING COMPUTATION OF FUNCTION g(FA, FB).

IX. CONCLUSIONS

In this paper, we have put forward the idea of deliveringmessages to place-friends in opportunistic networks. Deliver-ing messages to place-friends (which we called mobility-cast)has the potential to reach not only current social contacts of auser, but also forthcoming social contacts as observed in recentstudies. We have introduced a privacy-preserving design ofa mobility-cast protocol called 2H, and analyzed its privacy-preservation properties, as well as evaluated its performancethrough experiments based on a real-world mobility trace. Theresults of the experiments have shown that 2H strikes thebest balance between coverage, precision, and cost, amongstthe considered protocols. Finally, we have shown that secureplace-friendship estimation, which is at the core of 2H, can beeffectively implemented with current smartphone technology,experiencing running times below 10 seconds.

As directions for future work, we mention extending the ex-perimental evaluation using more data traces to better quantify2H benefits, and realizing a full-fledged mobility-cast APP tobe tested with real users.

ACKNOWLEDGMENT

Work partially supported by Tuscany region, program PORproject Secure!, by MIUR, program PRIN, project SecurityHorizon and by the EU project FP7-295354 SESAMO.

The work of P. Santi was partially supported by MIUR,program PRIN, project ArsTechnomedia.

REFERENCES

[1] A.J. Aviv, M. Sherr, M. Blaze, J.M. Smith, “Privacy-Aware MessageExchanges for Geographically Routed Human Movement Networks”,Proc. ESORICS, LNCS 7459, pp. 181–198, 2012.

[2] G. Costantino, F. Martinelli, P. Santi, “Investigating the Privacy vs.Forwarding Accuracy Tradeoff in Opportunistic Interest-Casting”, IEEETrans. on Mobile Computing, (to appear).

[3] G. Costantino, F. Martinelli, P. Santi, D. Amoruso, “An Implementationof Secure Two-Party Computation for Smartphones with Applicationto Privacy-Preserving Interest-CastO, Proc. Int. Conference on Privacy,Security, and Trust (PST), pp.9–16, 2012.

[4] D.J. Crandall, L. Backstrom, D. Cosley, S. Suri, D. Huttenlocher,J. Kleinberg, “Inferring Social Ties from Geographic Coincidences”,Proc. National Academy of Science (PNAS), Vol 107, n. 52, pp. 22436–22441, 2010.

[5] E. Daly, M. Haahr, “Social Network Analysis for Routing in Discon-nected Delay-Tolerant MANETs”, Proc. ACM MobiHoc, 2007.

[6] W. Dong, V. Dave, L. Qiu, Y. Zhang, “Secure friend discovery in mobilesocial networksO, Proc. IEEE Infocom, pp. 1647–1655, 2011.

[7] P. Hui, J. Crowcroft, E. Yoneki, “BUBBLE Rap: Social-based Forward-ing in Delay Tolerant Networks”, Proc. ACM MobiHoc, 2008.

[8] M. Li, N. Cao, S. Yu, W. Lou, “Findu: Privacy-preserving personalprofile matching in mobile social networksO, Proc. IEEE Infocom, pp.2435–2443, 2011.

[9] J. Leguay, T. Friedman, V. Conan, “Evaluating Mobility Pattern SpaceRouting for DTNs”, Proc. IEEE Infocom, 2006.

[10] D. Malkhi, N. Nisan, B. Pinkas, Y. Sella, “FairPlay - Secure Two-PartyComputation System”, Proc. USENIX Security Symposium, pp. 287–302,2004.

[11] A. Mei, G. Morabito, P. Santi, J. Stefa, “Social-aware Stateless Routingin Pocket-Switched Networks”, Proc. IEEE Infocom, 2011.

[12] S. Scellato, A. Noulas, C. Mascolo, “Exploiting Place Features in LinkPrediction on Location-Based Social Networks”, Proc. ACM KDD, pp.1046–1054, 2011.

[13] C. Shannon, “A Mathematical Theory of Computation”, Bell SystemsTechnical Journal, vol. 27, pp. 623–656, 1948.

[14] C. Song, Z. Qu, N. Blumm, A.L. Barabasi, “Limits of Predictability ofHuman Mobility”, Science, vol. 327, pp. 1018–1021, 2010.

[15] C. Song, P. Wang, A.L. Barabasi, “Modeling the Scaling Properties ofHuman Mobility”, Nature Physics, vol. 7, pp. 713–718, 2010.

[16] D. Wang, D. Pedreschi, C. Song, F. Giannotti, A.L. Barabasi, “HumanMobility, Social Ties, and Link Prediction”, Proc. ACM KDD, pp. 1100-1108, 2011.

[17] Y. Zheng, L. Zhang, X. Xie, W. Ma, “Mining interesting locations andtravel sequences from GPS trajectories”, Proc. Int. Conf. on World WildWeb (WWW 2009), Madrid Spain. ACM Press: 791-800.

[18] Y. Zheng, Q. Li, Y. Chen, X. Xie, W. Ma, “Understanding MobilityBased on GPS Data”, Proc. ACM Ubicomp, pp. 312–321, 2008.

[19] Y. Zheng, X. Xie, W. Ma, “GeoLife: A Collaborative Social NetworkingService among User, location and trajectory”, IEEE Data EngineeringBulletin, Vol. 33, n. 2, pp. 32-40, 2010.

[20] A. Vahdat, D. Becker, “Epidemic Routing for Partially Connected AdHoc Networks”, Tech. Rep. CS-200006, Duke University, 2000.

[21] A. Yao, “Protocols for Secure Computations”, Proc. IEEE FOCS, pp.160–164, 1982.

[22] R. Zhang, Y. Zhang, J. Sun, G. Yan, “Fine-grained private matching forproximity-based mobile social networkingO, Proc. IEEE Infocom, pp.1969–1977, 2012.