samaritancloud: secure infrastructure for scalable location-based services

Computer Communications xxx (2014) xxx–xxx

Contents lists available at ScienceDirect

Computer Communications

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

SamaritanCloud: Secure infrastructure for scalable location-basedservices

http://dx.doi.org/10.1016/j.comcom.2014.08.0130140-3664/� 2014 Elsevier B.V. All rights reserved.

⇑ Corresponding author.E-mail addresses: [email protected] (A. Samanta), [email protected]

(F. Zhou), [email protected] (R. Sundaram).

Please cite this article in press as: A. Samanta et al., SamaritanCloud: Secure infrastructure for scalable location-based services, Comput. Commun.http://dx.doi.org/10.1016/j.comcom.2014.08.013

Abhishek Samanta ⇑, Fangfei Zhou, Ravi SundaramNortheastern University, Boston, MA 02115, United States

a r t i c l e i n f o

Article history:Available online xxxx

Keywords:Location-based serviceMobile devicesPrivacyHomomorphic encryption

a b s t r a c t

With the maturation of online social networks (OSNs), people have begun to form online communitiesand look for assistance at a particular place and time from people they only know virtually. However,seeking for such help on existing OSN infrastructures has some disadvantages including loss of privacy(in terms of both location as well as the nature of the help sought) and high response times. In this paperwe propose SamaritanCloud, a scalable infrastructure that enables a group of mobile and geographically-dispersed personal computing devices to form a cloud for the purpose of privately sharing relevant local-ity-specific information. From a technical standpoint our main contribution is to show that only additivehomomorphic encryption is sufficient to compute nearness in a cryptographically secure and scalableway in a distributed setting. This allows us to harness the benefit of linear match time while guaranteeingthe locational privacy of the clients. In terms of performance our system compares favorably with simplerpublish/subscribe schemes that support only equality match. We demonstrate the practical feasibility ofSamaritanCloud with experimental evaluations.

� 2014 Elsevier B.V. All rights reserved.

1. Introduction

People often have the need for assistance from strangers inremote locations. Consider the following requests: please tell themarathon runner with bib #123 I will wait at the finish line; didI leave my keychain on campus? Is there a brown puppy roamingin the playground? In this paper we propose, not just a newarchitecture, but, in fact, a new cloud based service – Samaritan-Cloud – the goal is to provide a way for people to connect withothers (possibly strangers) in a remote location and obtain (phys-ical) help from them. SamaritanCloud is deployed as cell phoneapplication, users submit their requests to the cloud which coordi-nates users’ requests and efficiently find possible candidates torespond to the request. Such a service will require efficient techni-cal solutions to problems such as scalability, privacy, andreputation to overcome the social barriers of soliciting help fromstrangers. We focus primarily on the technical aspects of scalabilityand privacy (matching people with strangers in a secure andprivate way) so that the need for help and the ability/desire toassist are disclosed safely.

Since the emergence of online social networks (OSNs), peoplehave sought help from their social contacts. The most commonmethod to seek for help on social network sites, e.g., Facebook,Twitter, or ‘‘strangers helping strangers’’ [1], is post – an user postshis/her question or request on his/her social network page or a rel-ative group page and waits for response, which is very similar tosubscribing to an email list and broadcast questions except expos-ing more privacy. This method is simple but suffers from threemajor drawbacks. High/unpredictable response latency: PopularOSNs, e.g., Facebook, Twitter own worldwide users, who live indifferent locations and have different schedules. A post on a grouppage could not reach all the members in a short time and may beoverwhelmed by other posts soon. Limited range of request subjects:Groups on OSNs are typically centered around interests,occupations, genders, ages. So, it is hard to elicit response fortime-restricted and location sensitive questions. Most onlinerequests focus on recommendation, suggestions and people donot make off-line offer before they build trust on each other. Pri-vacy loss: Users requesting help on OSNs could end up exposingthemselves to a large group, including friends they know in reallife, as well as users, who are not willing/able to offer help.Unnecessary privacy leak may affect user’s personal life and shouldbe avoided.

(2014),

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

mailto:[email protected]




http://www.sciencedirect.com/science/journal/01403664

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


2 A. Samanta et al. / Computer Communications xxx (2014) xxx–xxx

1.1. Related work

Geosocial networking [2–5] offers location based services (LBS)to users to interact relative to their locations. LBS typically is aninformation or entertainment application that is dependant onlocation of user. By these services users are offered possibilitiesto find other people, machines and location-sensitive resources.Some applications [6,7] match users with locations of interest.These services are used for finding a physically proximal socialcontact or for crowd sourcing. Many of such public LBS provideno privacy while some offer limited protection on an opt-in oropt-out basis. Here we briefly categorize the different approachesto providing privacy, as well as the associated shortcomings.

Middleware: Geopriv [8] and LocServ [9] are policy-based pri-vacy management approaches for secure location transfer thatemploy a trustworthy middleware mediating between location-based applications and location tracking servers. Geopriv [8]describes an approach to securely transferring location informa-tion and associated privacy data by creating ‘‘location objects’’ thatencapsulate user location data and associated privacy require-ments. Once ‘‘location generator’’ (e.g. user device) creates an‘‘location object’’, it sends it to a middle server which forwardsthe object to ‘‘location recipient’’ based on different kinds of rules.LocServ [9] is a middleware service that lies between location-based applications and location tracking servers. It offers a generalframework of components that allows users to apply general poli-cies to control release of their location information. However, thepracticality of such systems have yet to be determined, as thetrustworthiness of middleware is hard to guarantee.

Dummies or anonymity: Instead of sending out the exact loca-tion, a client sends multiple different locations to the server withonly one of them being true [10]. The drawback of such schemesis that over the long run the server is able to figure out the client’slocation by comparing the intersection of uploaded locations. Someother schemes [11,12] separate location information from otheridentifying information and report anonymous locations to the ser-ver. However, guaranteeing anonymous usage of location-basedservices requires that the precise location information transmittedby a client cannot be easily used to re-identify the subject.

Location hiding: Clients define sensitive locations where they donot want to be tracked, and the location-based application stopstracking when the user gets close to those areas [13].

Location perturbation: These schemes ‘‘blur’’ the exact locationinformation to a spatial region [14–17] or send a proxy landmarkinstead [18] and hence, are not suitable for applications thatrequire accurate locations.

The scheme presented in this paper uses client-specific, person-alized and global blurs that are random elements in a finite fieldto guarantee perfect accuracy and cryptographic security; moreon this in the sections to follow.

To complete our review of related work we briefly survey the lit-erature on homomorphic encryption. Homomorphic encryption is atype of encryption scheme that provides ability to perform arithme-tic operation on cipher text and get the encrypted result which isequivalent to the encryption of the result by applying the samearithmetic operation on the plaintext. The encryption systems ofGoldwasser and Micali [19], and Elgamal [20] are known to supporteither addition or multiplication among encrypted cypher texts, butnot both operation at the same time. In a breakthrough work,Gentry [21] constructed a fully homomorphic encryption scheme(FHE) capable of an arbitrary number of addition and multiplicationon encrypted data. Fully homomorphic encryption schemes arevery powerful as it computes any function on an encrypted cipher-text. But, Lauter et al. [22] showed that fully homomorphic encryp-tion schemes till date are very resource consuming and areimpractical to be used for most of practical purposes.

Please cite this article in press as: A. Samanta et al., SamaritanCloud: Secure infhttp://dx.doi.org/10.1016/j.comcom.2014.08.013

1.2. Our contributions

To overcome the above mentioned drawbacks of LBS and OSNs,we propose SamaritanCloud, a location-based cyber-physical net-work allowing people to reach friends or strangers in desired loca-tions for help. SamaritanCloud is formed by a collection of backendservers and a set clients being served. The client side functionalityof SamaritanCloud is easily deployed as a location-based cell phoneapplication; the cloud coordinates client requests and efficientlyfinds candidates who are able/willing to offer help, even possiblyphysical help, in real-world life-threatening emergencies. From atechnical standpoint our primary contribution is to show how par-tially homomorphic encryption can be adapted to a distributed set-ting so as to guarantee cryptographic security without sacrificingefficiency gains. The resulting protocol finds near-neighbors inconstant-time thus providing efficient and private match of help-seekers and help-givers. SamaritanCloud preserves efficiency andprivacy while calculating near neighbor, by employing differentblurring techniques and partially homomorphic encryption.

2. System design

SamaritanCloud is a protocol used by a cloud S and a set of cli-ents C to securely compute neighbors nearby a given client. Thecloud S is formed by connecting m servers with each other forminga clique with high speed network connections. The cloud serves atotal of n clients. These clients are equally distributed among mservers in S. Clients are directly connected to their correspondingservicing servers. Each client has a mobile device with enoughcomputation power to efficiently encrypt–decrypt using additivehomomorphic functions. Clients are assumed to share a commonkey with which they exchange private messages that are deniedto the cloud. A server is efficient in using public–private crypto-system. It is also capable of broadcasting request to f clients,efficiently. On the other hand, a client can efficiently talk to itsservicing server or a small group of other clients. The cloud Sauthenticates clients and initiates distributed near-neighbor com-putation. Each client is associated with an user-name, passwordand profile. A client uses user-name and password for authentica-tion. A profile contains several private informations of the client,e.g. location, the reward the client is willing to pay on receivinghelp, etc. The profile is represented as a collection of d variablesand their respective values (or, range of values). Variables aredrawn from a metric space and for the purposes of this paper areassumed to take real numbers. To minimize dependencies oncloud infrastructure, SamaritanCloud delegates all computationallyextensive operations, viz, distance computations, encryption–decryption process, to servicing clients. A client is called a servicingclient, when it participates in secured neighbor computation forother clients. In SamaritanCloud, all clients present in the networkbehave as servicing clients. We analyze performance of Samaritan-Cloud in presence of an adversary. We assume that the adversarydeploys as many attackers as it requires to successfully launch anattack against the proposed system. An attacker eavesdrops ontransmission(s) among several parts of the system and shares theoverheard message(s) among other attackers. The goal of theattackers is to extract profile informations from the messagesheard so far. We classify an attacker as external or internal depend-ing on its capacity of infiltrating SamaritanCloud. An externalattacker is aware SamaritanCloud protocol but it does not haveaccess to secrets used by the proposed protocol. Whereas, an inter-nal attacker is aware of both SamaritanCloud protocol and some ofthe secrets used by it. Also, it is capable of compromising differentparts of either cloud or the set of clients. When at-least one serverof the cloud is compromised we assume that no part of the entire

rastructure for scalable location-based services, Comput. Commun. (2014),


A. Samanta et al. / Computer Communications xxx (2014) xxx–xxx 3

cloud is trusted. Moreover, when a cloud or a client is compro-mised it behaves as an attacker and launches attack against restof the system using SamaritanCloud. Formally, we classify theseattackers as follows,

� Rogue cloud: In this scenario, at-least one server of the cloud iscompromised and tries to retrieve profile information of at-leastone good client from messages stored in the cloud.� Rogue client: We assume that there are a number of rogue

clients (attackers) present in the network and launch attacksto leak profile information of at-least one good client. Rogueclients can launch two types of attacks as follows,– Passive attack: The compromised client passively tries to

extract profile information of at-least one good client.– Active attack: A compromised client sends a fake Profile-

Update-Request and Help-Request to SamaritanCloud. Afterreceiving these requests, the cloud disseminates its responseto the network. With help of this response, other attackerstry to retrieve profile information of a good clientsuccessfully.

2.1. Definitions

Distance: The distance between two profiles p1; p2, representedas d-dimensional vectors, is defined as:

kp1 � p2k ¼ fRiðj pi1 � pi2 jÞ2gð1=2Þ

;

where pi1 and pi2 are the values of the ith dimension of p1 and p2;

respectively:

Near-neighbor: A client ci 2 C is said to be near-neighbor of arequesting client cq R C if the distance between profile informa-tions of ci and cq is at most a given distance, D, i.e. if

kpq � pik 6 D; where pq and pi are profile data of cq and ci;

respectively:

Blur: Blur is a random number which is used to blur data. Forexample, data p is blurred with a random blur r as follows,

b�r ðpÞ ¼ ðp� rÞ mod P; where r 2 ½1; P� and P is a large publicprime number:

Profile: Profile (pi) of a client ci, is defined as a collection of infor-mations of ci, viz, x and y coordinates of its current location,maximum amount of weight ci can help with, area where ci canhelp, etc. A profile of a client is represented as a d-dimensionalvector (in d-dimensional Euclidean space).

Tolerance-value: Tolerance value is the maximum distancebetween profile of a client cj and profile requested by cq, withinwhich cj receives help request from cq.

Our scheme builds on prior work on confidential publish/subscribe schemes. In the subsections to follow we briefly summa-rize these techniques.1

2.2. A confidential publish/subscribe scheme and its issues

In the content-based publish/subscribe model the interests ofsubscribers are stored in a forwarding server which matches androutes relevant notifications to interested subscribers [23]. Proce-dures in Fig. 1a–c is the basic primitives shown in [23].

Observe that, in the above scheme, the server can match profilesacross clients and across time so long as the random number usedby the querying client is same as the random number used by theserver. But, for the security of the scheme, it is necessary to change

1 Texts after right arrowheads (.) in pseudo-codes are comments.


the random number often. But this change incurs large overheadon the system. The extra overhead is explained with the followingscenario.

A client cq wants to send a request to the cloud. So, it invokesprocedure REQUEST_PUB_SUB, Fig. 1a. But, after cq fetches the ran-dom number (line 2 in Fig. 1a), cloud updates it. When cq sends thepair of random number and the encrypted value (line 4 in Fig. 1a)back to the cloud, it is rejected as the random number in cloud ischanged. To avoid such scenarios cloud has to keep extra book-keeping to make sure that, all the requests are processed beforethe random number is changed. For a large system this incurs largeoverhead. Also, the request process in publish/subscribe is veryresource consuming as clients have to perform two encryptionsbefore sending a request to the cloud. More importantly, the abovescheme, without fully-homomorphic crypto-system only com-putes equality match and not the closeness of two attributes.But, Lauter et al. [22], have shown that fully-homomorphic encryp-tions are highly resource consuming and are not practical in reallife scenario. Therefore, the above publish/subscribe algorithm isinadequate for our purposes.

3. SamaritanCloud

3.1. Protocol

SamaritanCloud works in 3 different phases called Initialization,Profile-Update-Request and Help-Request phases. In Initializationphase, the cloud S is started. At the start-up time, S generatesseveral different blurs which are kept secrets from the clientsand are used to maintain secrecy of client profiles. A client invokesProfile-Update-Request phase when its profile information ischanged and Help-Request phase when it requires help. In Pro-file-Update-Request phase, a client blurs its changed profile witha random personalized blur and sends it to S along with encryptedblur. Since, the profile data is blurred with a random blur and therandom blur is encrypted, no profile information leaks from theblurred profile. S then re-blurs the already blurred profile with glo-bal and client-specific blur of the client and distributes amongselected set of servicing clients. In Help-Request phase the request-ing client blurs its request-profile with its personalized blur andsends to S which in turn re-blurs the already blurred profile anddistributes to selected servicing clients. Along with thesere-blurred profiles, S also forwards sum of encrypted client specificand personalized blurs. Additive-homomorphic nature of the usedcypto-system helps a client securely compute the set of near-neighbors of the requesting client, with these informations. Thesedifferent phases of operations are explained in detail, below.

Initialization: In this phase, the cloud (S), assigns 1 client-spe-cific blur csri to each client ci. S also generates a global blur rg . Bothclient-specific and global blurs are kept secret from clients. Theseare used by the cloud to blur client profiles (see Fig. 3).

Profile-Update-Request: This phase, Fig. 2a, is invoked by a clientci when its profile data pi is changed. A client, ci sends its blurredprofile data to the cloud S. S forwards blurred pi among selectedset of clients. The data transfer is thus composed of two sub-phasesas follows,

Update: In Update phase ci blurs its profile data pi by blurringeach dimension separately.

b�riðpjiÞ¼ ðpji� riÞ mod P; 8j2 ½1;d�; where; pji is jth

dimension of pi; and ri is the personalized blur used by ci: ð1Þ

The client also encrypts its personalized blur, using the additive-homomorphic encryption nh

skðriÞ, and sends the pair (nhskðriÞ;b�ri

ðpiÞ)to the cloud.



Fig. 1. Procedures invoked in publish/subscribe scheme.

Fig. 2. SamaritanCloud in different phase.

Fig. 3. Procedure invoked by the cloud at start of SamaritanCloud system.


Redistribution: The cloud S invokes this phase, when itreceives an update request from a client ci. Client-specific blur(csri) and the global blur (rg) are used to blur already blurred profileof ci. We call this process re-blurring.

prblurji ¼ ðb�ri

ðpjiÞ�csri þ rgÞ mod P ¼ ðpji � ri�csri þ rgÞ mod P;

ð2Þ

where prblurji is jth dimension of re-blurred profile of ci (prblur

i ). S savesthe encrypted blur nh

skðriÞ and distributes re-blurred profile valuescomputed in Eq. (2) along with the address of ci to k clients. Thesek clients are selected in k rounds. In each round, 2 clients are chosenand the least loaded of these 2 clients is selected in that round.

Help-Request: When a client (cq) is in need of help, it invokesHelp-Request phase Fig. 2b. In this phase, cq sends blurred


requested-profile along with a tolerance value to the cloud (S).On reception of a request, S broadcasts the blurred requested-pro-file and delegates the near-neighbor computation to all servicingclients. Clients compute distance between the requested profileand saved blurred-profiles and send back the result directly to cq.Thus, this phase is composed of 3 sub-phases as follows,

Request: The requesting client cq blurs the requested-profile pq

with a randomly generated personalized blur (rq), by blurring eachdimension of pq, separately.

bþrq ðpqi Þ ¼ ðp

qi þ rqÞ mod P; 8i 2 ½1;d�; where bþrq ðpq

i Þ is the ithdimension of blurred profile of the requesting client cq; ð3Þ

cq encrypts its personalized blur and tolerance value (tol) and sendsthe tuple ðnh

skðrqÞ; nskðtolÞ;bþrq ðpqÞÞ to the cloud (S).




Redistribution: S invokes this phase on reception of arequest from cq. Without loss of generality, let us assume that aclient ci has blurred profile information of t other clientscj; 8j 2 ½1; t�. S builds a set (Ri) of t 6-tuples (Tj) and sends it to ci.

1st and 2nd entries of Tj are addresses of cq and cj, respectively.

1Tj ¼ cq; 2Tj ¼ cj

3rd entry is built by re-blurring the blurred profile of cq, withthe clients-specific blurs assigned to cq (csrq) and the global blur(rg), as follows.

3Tlj ¼ ðbþrq ðpql Þþ

csrq þ rgÞ mod P ¼ ðpql þ rqþcsrq þ rgÞ mod P;

ð4Þ

where 3Tlj is lth dimension of 3rd entry of Tj.S adds encrypted personalized random blur of cq and cj to build

4th entry of the tuple. This is where we use additive homomorphicnature of encryption scheme.

4Tj ¼ ðnhskðrqÞ þ nh

skðrjÞÞ mod P ¼ nhskðrq þ rjÞ mod P: ð5Þ

5th entry is built by adding the client specific blur of cq and cj.Since, both the client-specific blurs are not known to clients, theindividual value of either of client-specific blur or the global blursare not leaked by this entry.

5Tj ¼ ðcsrq þ csrjÞ mod P: ð6Þ

6th entry is the encrypted tolerance value sent by cq. Thistolerance value is used in the near-neighbor computation.

6Tj ¼ nskðtolÞ

Distance-computation: In this phase, Fig. 5c, clients com-pute distance between the blurred requested-profile and savedblurred profile data of other clients. Let us assume that after redis-tribution phase, a client ci receives a set Ri. Let us also assume thatci has blurred profile informations of t clients, cj; 8j 2 ½1; t�. LetTj 2 Ri be the tuple containing data to compare with cj and prblur

j

be the re-blurred profile of cj. Since, ci has the shared secret sk, itdecrypts the encrypted blur and tolerance value in Tj. ci informsrequesting client (cq) about clients whose re-blurred profile satisfythe following condition.

Xd

l¼1

3Tlj � prblurj � dh

skð4TljÞ � 5Tlj

n o2" #1=2

< dhskð6TljÞ; where dh

skð�Þ decryption using key sk: ð7Þ

After stating the newly proposed scheme, here we prove that,the scheme calculates distance correctly between requested profiledata cq and blurred profile of a candidate client cj. The fact thatblurring according to our proposed scheme preserves distance iscaptured by the following lemma.

Lemma 1. Given, Tqj is the tuple containing data to compare with cj

and prblurj is the blurred profile of cj

Xd

i¼1

3Tqij � prblur

j � dhskð4Tq

ijÞ �5Tq

ij

n o2" #1=2

¼ kpq � pjk:

Proof. As described in Profile-Update-Request protocol, blurredprofile stored on SamaritanCloud is calculated using Eq. (2).

prblurij ¼ ðpij � rj�csrj þ rgÞ mod P: ð8Þ

Now, using Eq. (5),

dhskð4Tq

j Þ ¼ dhskðn

hskðrq þ rjÞ mod PÞ ¼ ðrq þ rjÞ mod P: ð9Þ


So, combining Eqs. (4), (6), (8), and (9)

3Tqij�prblur

j �dhskð4Tq

ijÞ�5Tq

ij ¼ðpql þ rqþcsrqþ rgÞ mod P

�ðpij� rj� csrjþ rgÞ mod P

�ðrqþ rjÞ mod P�ðcsrqþ csrjÞ mod P

¼ðpqi �pijÞ mod P

Thus, according to the definition,

Xd

i¼1

3Tqij � prblur

j � dhskð4Tq

ijÞ �5Tq

ij

n o2" #1=2

¼Xd

i¼1

ðpqi � pijÞ

2n o1=2

" #mod P ¼ kpq � pjk �

As has been discussed earlier, profile information of a client isblurred with randomly selected blurs and each of these blur is uni-formly selected from the range ½1; P�, where P is a large publicprime number. So, without any information about the randomnumbers used for blurring technique, the only way an attackercomputes correct profile from a blurred profile is by guessing therandom blur, correctly. Since, there are P possible numbers toselect a random blur from, the probability of guessing a randomblur correctly is at-least 1=P. The chance of guessing the randomblur used by a client varies depending on how much informationan attacker has about the blur. But for better security, this chanceshould be as close to 1=P as possible. In the article to follow, weshow that security offered by SamaritanCloud against differentkind of attacker is 1=P. Before, going into details, we formallydefine the metric we use as a measure of security, as follows.

Probability of Information Leak by at-most One Guess (PILOG):PILOG is defined as the probability of an adversary successfullycomputing the profile data of a client from its re-blurred profileby at-most one guess.

Security against external attacker and rogue cloud:

In the proposed protocol Profile-Update-Request and Help-Requestare blurred with random personalized blur of a client and thenthese already blurred profiles are further blurred with client spe-cific and global blurs. So, only way for an external attacker androgue client to retrieve client profile from a blurred profile is byguessing the blur correctly. Since, all the blurs are selecteduniformly at random from ½1; P�,

PILOGexternal ¼ PILOGrogue—cloud ¼1P

Security against passive rogue client: A passive rogueclient tries to retrieve client profile data from their respective re-blurred profiles data. According to the proposed protocol, the pro-file data of a client ci is re-blurred with its client-specific blur andthe global blur as follows,

prblurji ¼ ðpji � ri�csri þ rgÞ mod P

where ri is the personalized blur and csri is the client-specific blursfor ci. rg is the global blurs. The only way for an adversary to retrievethe profile information successfully is by guessing the blursð�ri�csri þ rgÞ mod P, correctly. Since, all the blurs are selecteduniformly at random from ½1; P�, chance of that happening is 1

P. Thus,

PILOGpassive—rogue—client ¼1P

Security against active rogue clients: Now let us con-sider attacks launched by active rogue clients. A rogue client ai

sends a fake Help-Request to the cloud (S) with an intention ofhelping other attackers in the network retrieve profile informationof at-least one good client from its blurred profile data. On




receiving a fake Help-Request from ai; S builds a set of tuples Ri

with Tj as follows for each selected clients (ci) and forwards it toa set of selected clients as follows,

� 1Tj ¼ ai

� 2Tj ¼ cj, where cj is a client whose blurred profile data is storedby ci.� The third dimension of Tj is re-blurred request-profile of the

requesting attacker (ai). The request-profile (pa) blurred withpersonalized blur of ai (ra) is further re-blurred by using clientspecific blur of ai (csra) and global blur (rg). This process of re-blurring is shown below,

rblurpahl ¼ ðpa

l þ raþcsra þ rgÞ mod P;

where aprblurl is lth dimension of re-blurred requested profile of

ai.� 4Tj ¼ nh

skðra þ rjÞ mod P, where ra is the random personalizedblur used by ai and rj is the random personalized blur used byclient cj

� 5Tj ¼ ðcsra þ csrjÞ mod P� 6Tj ¼ nh

skðtolÞ, where tol is the tolerance value requested by ai.

Since, all the attackers share informations, aj knows the profilerequested by ai (pa) and the random personalized blur used by ai

(ra). With these informations, aj retrieves {ðcsra þ rgÞ mod P} andpersonalized blur (rj) of cj from fake Help-Request. If aj guesseseither global blur (rg) or the client specific blur of ai (csra) correctly,it retrieves the profile information of cj from its blurred profile.Since, both the client-specific and global blurs are selecteduniformly at random from ½1; P�,

PILOGactive�rogue�client ¼1P

3.2. Improved performance

In SamaritanCloud, on receiving a Help-Request from a client,the cloud S communicates with all servicing clients in the network.But, each server in the cloud efficiently broadcasts to f clientssimultaneously. So, a cloud consisting of m servers is capable ofbroad-casting to m � f clients, simultaneously. Thus, for a networkof size more than m � f , in Help-Request phase the cloud communi-cates with clients in multiple rounds. In each round, at-most m � fclients are communicated to. This increases average waiting timefor a Help-Request as the number of clients in network is morethan m � f . To avoid this problem, we propose an optional modeof operation, called ‘‘clustered’’ mode. We call the protocoldescribed so far, ‘‘unclustered’’ mode of SamaritanCloud. In‘‘clustered’’ mode SamaritanCloud divides nodes available in thenetwork among several clusters each of size at-most s. We discussmore about the clustered mode in detail later in this section. Asdiscussed in the previous section (Section 3.1), SamaritanCloud issecured against attacks by passive rogue clients. But, in the lastsection we consider only passive rogue clients which are not capa-ble of listening to information transmission among clients andcloud. If a passive rogue client (ai) eavesdrop on these transmis-sions, SamaritanCloud is compromised. Please note that since theattacker is a rogue client, it has access to secret key (sk) shared onlyamong clients. Now, in Profile-Update-Request phase, a client blursits profile using a randomly selected personalized blur. It alsoencrypts the blur using the sk and sends the blurred profile alongwith the encrypted blur to cloud. A passive rogue client eavesdrop-ping on this transmission successfully retrieves the personalizedblur used by the good client. Using this random blur, the profileinformation is then retrieved.


To avoid such attacks against rogue clients with eavesdroppingcapability, we extend our already proposed SamaritanCloud. Theextended SamaritanCloud protocol, along with secret key (sk)shared only among clients also uses a pair of public–private keyof the cloud S. The public key (pk) of S is known to all the clientsin the network.

Initialization: In this phase the cloud S is initialized and in theprocess of starting S randomly assigns unique client-specific blursto clients and also it randomly generates a random blur (rg).

Profile-Update-Request: In this phase (Fig. 4a), a client blurs itsupdated profile as follows and sends it to S.

b�riðpjiÞ ¼ ðpji � riÞ mod P; 8j 2 ½1;d�; where; pji is jth

dimension of pi; and ri is the personalized blur used by ci:

The client (ci) also generates a random salt si and adds it to thepersonalized blur ri. Then, ci encrypts (ri þ si) using the additive-homomorphic encryption nh

skðri þ siÞ; si using pk and sends the tuple(nh

skðri þ siÞ; npkðsiÞ;b�riðpiÞ) to the cloud. On receiving this request S

saves the pair (nhskðri þ siÞ; si) and re-blurs the already blurred

received profile as follows and sends it to selected set of servicingclients.

rblurpji ¼ ðb�riðpjiÞ�csri þ rgÞ mod P ¼ ðpji � ri�csri þ rgÞ mod P;

ð10Þ

where prblurji is jth dimension of re-blurred profile of ci (prblur

i ). The setof servicing clients selected to forward the re-blurred profile tovaries from ‘‘clustered’’ mode to ‘‘unclustered’’ mode as follows.

� Unclustered mode: k different clients are selected in k rounds. Ineach round two clients are chosen randomly. The client which isless loaded is selected.� Clustered mode: The cloud divides the set of available clients

into several clusters. From each cluster, k clients are selectedat random in k rounds. In each round, two clients are chosenfrom each cluster. The less loaded client between the 2 clientschosen from same cluster is selected.

Help-request: When a client needs help, it blurs the requestprofile with a randomly generated personalized blur as followsand sends it to S, Fig. 5.

bþrq ðpqi Þ ¼ ðp

qi þ rqÞ mod P; 8i 2 ½1;d�; where bþrq ðpq

i Þ is the ithdimension of blurred profile of the requesting client cq: ð11Þ

cq generates a random salt sq and adds it to the personalized blurused by cq (rq). cq, then, encrypts ðrq þ sqÞ and tolerance value (tol)and sends the tuple ðnh

skðrq þ sqÞ; nskðtolÞ; npksq; bþrq ðpqÞÞ to the cloud(S). After receiving this request, S builds a set of 6-tuples and sendsthose to a set of selected servicing clients. Without loss of generalitylet us assume that, S builds a set (Ri) of tuples for a client ci. A tupleTj has enough information to enable ci to determine is a client cj is anear-neighbor of cq. Tj is built as follows, 1st and 2nd entries of Tj

are addresses of cq and cj, respectively.

1Tj ¼ cq; 2Tj ¼ cj

3rd entry is built by re-blurring the blurred profile of cq, withthe clients-specific blurs assigned to cq (csrq) and the global blur(rg), as follows.

3Tlj ¼ ðbþrq ðpql Þ þ

csrq þ rgÞ mod P ¼ ðpql þ rq þ csrq þ rgÞ mod P;

ð12Þ

where 3Tlj is lth dimension of 3rd entry of Tj.



Fig. 4. Procedures invoked in Profile-Update-Request phase.


S adds encrypted random personalized blurs and salts of cq andcj to build 4th entry of the tuple. This is where we use additivehomomorphic nature of encryption scheme.

4Tj¼ðnhskðrqþ sqÞþnh

skðrjþ sjÞÞ mod P¼ nhskðrqþ rjþ sqþ sjÞ mod P:

ð13Þ5th entry is built by adding the client specific blurs and the ran-

dom salts of cq and cj. Since, either of the client-specific blurs is notknown to clients, the individual values of client-specific blurs arenot leaked by this entry.

5Tj ¼ ðcsrq þ csrj � sq � sjÞ mod P: ð14Þ

6th entry is the encrypted tolerance value sent by cq. Thistolerance value is used in the near-neighbor computation.

6Tj ¼ nskðtolÞ: ð15Þ

The set of servicing clients selected to forward the set of 6-tuplesvaries from ‘‘clustered’’ mode to ‘‘unclustered’’ mode as follows,

� Unclustered mode: All nodes in the network are selected.� Clustered mode: In this mode, S selects all clients of a randomly

chosen cluster.

A client(ci) starts computing the near-neighbors of the request-ing client (cq) after receiving the set of tuples Ri. A clientcj is anear-neighbor of ci if the following predicate is satisfied.

Xd

l¼1

3Tlj � prblurj � dh

skð4TljÞ � 5Tlj

n o2" #1=2

< dhskð6TljÞ; where dh

skð�Þ decryption using key sk: ð16ÞUsing Eqs. (10), (12) and (13) it is to be noted that the left side of Eq.(16) is the distance between the profile data of a client cj and therequesting profile rq. Right side of Eq. (16) is the tolerance value.


3.3. Optimality

Random blurs and salts are essential in maintaining secrecy ofprofile data in SamaritanCloud. Although, these blurs and salts helpthe proposed protocol avert different attacks, these also increasethe overhead bookkeeping. So, for better performance, proposedprotocol should use least number of blurs and salts possible with-out affecting security. Here we prove that, if the proposed protocolhad used different sets of random blurs or salts, it would have beenless efficient. To prove this, we first define a family of protocols,which we call generic family of protocols (GFP) that uses acollection of blurs and salts to hide profile informations. Then,we show that, any protocol from this family of protocols, is at-mostas efficient as proposed SamaritanCloud.

Generic Family of Protocols (GFP): GFP is a collection of proto-cols used to securely compute set of near-neighbors of a clientusing a cloud. A protocol P in GFP may use a set of client-sideand server-side blurs and salts to achieve required security. A pro-tocol P belongs to GFP if it has 3 phases of operations as follows,

Initialization: In this phase, the cloud is started. At thestart up time, the cloud also initializes different blurs it uses in Pto hide client profile information.

Profile update: If clients use random blur according to P,client-profile data are blurred before being sent to the cloud.Otherwise, if P does not allow client side random blur, clients sendprofile informations to the cloud without blurring. Also, if the cli-ent has access to random salts, it sends the sum of personalizedblur and the salt encrypted with secret key shared among clientsalong with the salt encrypted with public key of the cloud S.Other-wise only encrypted personalized blur is sent. On receivingthe blurred profile data, the cloud re-blurs received data and sendsit to selected servicing clients. Re-blurring is achieved with therandom blurs available to the cloud, according to P. If the clouddoes not have access to any random blur, it distributes the received



Fig. 5. Procedures invoked in Help-Request phase.


data to selected set of servicing clients. Servicing clients areselected depending on the mode of operation of the system asfollows,

� Unclustered mode: k clients are selected in k rounds. In eachround two clients are chosen randomly. The client which is lessloaded is selected.� Clustered mode: From each cluster, k clients are selected in k

rounds. In each round, two clients are chosen at random fromeach cluster. The less loaded client between the 2 clients chosenfrom same cluster is selected.

Help request: In this phase, the requesting client, sends theblurred requested profile data and encrypted tolerance value.Also, if random salt is available to the client, it sends the sumof personalized blur and the salt encrypted with shared secretkey. If no salt is available it sends only the encrypted personal-ized blur to S. If no blur is available, the client sends therequested profile data and encrypted tolerance value to the cloud.The tolerance value is encrypted with a key shared among all cli-ents. After receiving these, the cloud builds a set of tuples foreach selected client. A tuple is a vector containing the re-blurredrequested profile, encrypted tolerance value and other informa-tions required for successful near-neighbor computation. Theseinformations depend on the set of blurs used. The cloud thensends these sets of tuples to selected set of servicing clients.Selection of servicing clients depend on the mode of operationof the cloud as follows,


� Unclustered mode: The cloud selects all available clients in thenetwork.� Clustered mode: The cloud selects all clients from a randomly

selected cluster.

After receiving the set, a servicing client determines near-neighbor of requested profile and informs the requested client.

Remark 1. SamaritanCloud is a protocol in GFP.

Definition 1. A protocol P1 is defined to be more efficient thananother protocol P2, iff P1 is at-last as secured as P2;P1 uses at-most as much computation power as P2 and P1 uses at-most asmuch memory as P2.

Lemma 2. SamaritanCloud is the most efficient protocol in GFP.

Proof. Because of the space constraint we could not put the proofhere. The lemma can be verified with Table 1. h

4. Evaluation

4.1. Runtime analysis

As has been explained before, SamaritanCloud works in two dif-ferent modes called ‘‘clustered’’ and ‘‘unclustered’’. In unclustered




mode, the cloud communicates with entire set of clients in the net-work in Help-Request phase. Whereas, in clustered mode the cloudmakes clusters each containing at-most s clients each and commu-nicates with all clients in a single cluster.

In Profile-Update-Request phase, a client sends its blurredprofile to the cloud which re-blurs this already blurred profileand distributes it among different selected servicing clientsdepending on different modes of operation as follows,

� Unclustered mode: In this mode, the cloud selects k clients in krounds. In each round the least loaded of randomly chosen 2 cli-ents is selected. According to our assumption, a cloud is com-posed of m servers and a server is capable of efficientlycommunicating to f clients. So, the cloud communicates effi-ciently to m � f clients. If there are more clients present thecloud communicates in multiple rounds, m � f clients per round.Since, the computation (blurring and re-blurring a profile data)in this phase is achieved in constant time, total time spent inthis phase is Oðm � f Þ. So, to disseminate Profile-Update-Request,the cloud requires Oðk=m � f Þ time. It is to be noted that, ifk� m � f , Profile-Update-Request phase can be done in constanttime(Oð1Þ) in unclustered mode.� Clustered mode: The cloud selects k clients from each cluster in k

rounds. Assuming that each cluster contains s clients, totalnumber of servicing clients selected for re-distribution is n�k

s .Moreover, the cloud efficiently communicates with m � f clients.So, communication among clients and the cloud takesOððn � kÞ=ðs �m � f ÞÞ time. Similar to ‘‘Unclustered mode’’,computation (blurring and re-blurring single profile data) takesconstant time. So, total time complexity of Profile-Update-Request in this mode is Oððn � kÞ=ðs �m � f ÞÞ.

In Help-Request phase, the requesting client sends blurredrequested profile along with encrypted tolerance value to thecloud. The cloud builds and forwards sets of 6-tuples for each

Table 1PILOG values for different scenarios and under different types of attacks. Protocol1:Protocol with no blur (we call it PlainText protocol). Protocol2: Protocol withpersonalized blur. Protocol3: Protocol with client-specific blur. Protocol4: Protocolwith global blur. Protocol5: Protocol with personalized and client-specific blurs.Protocol6: Protocol with personalized and global blurs. Protocol7: Protocol withclient-specific and global blurs. Protocol8: Protocol with personalized and 2 globalblurs. Protocol9: Protocol with a personalized and 2 client-specific blurs. Protocol10:Protocol with client-specific and 2 global blurs. Protocol11: Protocol with 2 client-specific and a global blur. Protocol12: Protocol with 2 personalized and a global blur.Protocol13: Protocol with 2 client-specific and a global blur. Protocol14: Protocol withpersonalized, client-specific and global blurs. Protocol15: Protocol with personalized,client-specific and global blurs along with a salt. (SamaritanCloud) Attacker1:External attacker. Attacker2: Rogue cloud. Attacker3: Passive rogue client not capableof eavesdropping. Attacker4: Passive rogue client capable of eavesdropping.Attacker5: Active rogue client.

Attacker1 Attacker2 Attacker3 Attacker4 Attacker5

Protocol1 1 1 1 1 1Protocol2 1=P 1=P 1=P 1 1Protocol3 1=P 1 1=P 1 1Protocol4 1=P 1 1=P 1 1Protocol5 1=P 1=P 1=P 1 1Protocol6 1=P 1=P 1=P 1 1Protocol7 1=P 1 1=P 1 1=PProtocol8 1=P 1=P 1=P 1 1Protocol9 1=P 1=P 1=P 1 1=PProtocol10 1=P 1 1=P 1 1=PProtocol11 1=P 1 1=P 1 1=PProtocol12 1=P 1=P 1=P 1 1Protocol13 1=P 1 1=P 1 1=PProtocol14 1=P 1=P 1=P 1 1=PProtocol15 1=P 1=P 1=P 1=P 1=P


selected servicing clients. The set of servicing clients selected forthis operation varies from clustered mode to unclustered mode.

� Unclustered mode: All clients in the network are selected. Asstated before, the cloud efficiently communicates with m � f cli-ents simultaneously. So, the cloud takes Oðn=ðm � f ÞÞ time tocommunicate with all clients. Moreover, the cloud builds a setof tuple for each servicing clients. A tuple contains enoughinformation to successfully compare blurred request-profileand the blurred profile stored by the selected servicing client.In Profile-Update-Request phase, k copies of the blurred profileof a client is distributed throughout the network. Also, it is to benoted that SamaritanCloud builds as many 6-tuples as the num-ber of blurred profiles stored throughout the network. So,assuming a 6-tuple takes constant time to be built, the cloudspends a Oðk � nÞ time to compute these tuples. After receivingthese sets, each servicing client compares each tuple from thereceived set with the corresponding blurred profile stored.Since, there are d dimensions in a blurred profile, comparing apair of tuple and blurred profile takes OðdÞ time. Because ofthe load balancing technique we use in Profile-Update-Requestphase, each servicing client has profile information ofOðlog log nÞ other clients. Thus, a servicing client spendsOðd � log log nÞ time to compare received set of tuples with theblurred profiles stored. Thus, time complexity of this phase isOðn=ðm � f Þ þ k � nþ d � log log nÞ ¼ Oðk � nþ d � log log nÞ.� Clustered mode: In this mode, the cloud randomly selects a clus-

ter. The Help-Request is forwarded to all the clients of theselected cluster. So, assuming s to be the size of a cluster, thecloud distributes Help-Request in s=ðm � f Þ rounds among ser-vicing clients. Moreover, in this mode a cluster contains k copiesof profile informations of every client in the network. Thus, thecloud spends a total of Oðk � nÞ time to build all sets of tuples fordistribution. After receiving these sets of tuples, each clientcompares each tuple with the corresponding stored blurredprofile. Since, there are d dimensions in a profile and there areOðn=sÞ different blurred profiles stored in a servicing client, ittakes Oðd � n=sÞ time for a servicing client to determine the setof neighbors near-by the requesting client. So, total time com-plexity of SamaritanCloud in clustered Help-Request isOðs=ðm � f Þ þ k � nþ d � n=sÞ ¼ Oðk � nþ d � n=sÞ

It is to be noted that, for small size of cluster (s ¼ oðn= log log nÞ)clustered mode works slower than unclustered mode both in Pro-file-Update-Request and Help-Request phase. On the other hand,for larger cluster size (s ¼ xðn= log log nÞ), clustered mode isasymptotically more efficient than unclustered mode in Help-Request phase. Also, for larger cluster size Profile-Update-Requestphase has asymptotically comparable runtime for clustered andunclustered mode (clustered mode is Oðlog log nÞ times slowerthan unclustered).

4.2. Setup

For the purpose of evaluation of the proposed SamaritanCloudprotocol, we use the setup shown in Fig. 6. The clients use theircredentials to login to the cloud. Once the identity of the client isverified, the consequent Profile-Update-Request or Help-Requestare forwarded to the control server which in-turn hands those overto the available set of servicing servers (e.g. S1; S2 and S3 in Fig. 6).The intercommunication among servers is done over high speedLAN connection. A client is automatically logged out of the cloudif no request (either Profile-Update-Request or, Help-Request) isreceived from the client in 15 min. The control server works as loadbalancer by randomly distributing the available clients among theset of available servicing servers. The measurement server issues



Fig. 6. Experimental setup.


different queries for different measurement matrices (viz. latency,battery life, etc.) to clients using control server. When clientsreply back to these queries, they are channeled to the measure-ment server by control server. Also the measurement server deci-des on the total number of severs available to service availableclients by sending a query to the control server. We developed aprototype mobile application based on iOS 5 to be used as clientside application of SamaritanCloud. We generated our experimen-tal data set by distributing this application among 200 volunteersin Boston area. Each of these volunteers installed SamaritanCloudapplication on their primary mobile phone. This prototype allowsusers to,

� log in or register with unique user name and password,� choose time interval to update profile; by setting a fixed update

time interval, exact profile change time is not exposed to theserver,� input request location (either latitude and longitude coordi-

nates or zip-code) and request content,� get notification when the client is close to a requested location;

response willingness to offer help,� get notification if anyone offers help to the client’s request.

The client side application registers itself as a background VoIPservice allowing it to (1) maintain a persistent connection with theserver, (2) periodically fetch location information, even if the appli-cation is running on background. Our application utilizes CoreLocation Framework to get physical location. Location coordinatescan be obtained through (a) standard location service and (b) sig-nificant-change location service (SLS). With standard location ser-vice, location data is gathered with either cell triangulation, Wi-Fihot-spots or GPS satellites, depending on required accuracy. As ourapplication periodically updates location to the server, it saves bat-tery life by enabling the standard location service shortly at per theinterval defined by client.2 With SLS, a location update is triggeredby the operating system only if a device moves from one cell towerto the other, thus it provides only coarse location update. There is anaccuracy-power trade off – GPS location update is accurate butpower inefficient while significant-change location service is a lessaccurate but less power consuming technique. We developed serversusing Apache Tomcat 7.0. We configure each server to simulta-neously work with 50 clients. With this experimental setting wewish to answer the following questions,

� What is the effect of SamaritanCloud on battery life of clientmobile devices? This is important because consumer mobiledevices severely suffer from limited power supply from its on-board battery system.� What is the effect of SamaritanCloud on server scalability?

2 Fetching location data requires a few seconds, the first location coordinatesreturned is usually saved from last time. Time-stamp of the location data is used todetermine if the update is fresh.


� How different are performance of SamaritanCloud in clusteredand unclustered mode of operation? Answering this question,would let us decide cluster size for optimal performance.� How frequently should Profile-Update-Request be sent to the

cloud? If the updates are sent little too often the battery life ofthe client device would be drained fast. On the other hand, ifthe updates are sent rarely, the location data of clients are at a riskof getting outdated. So, it is important to determine the frequencythe update frequency for optimal performance of the network.

4.3. Battery usage

The major difficulty in measuring the effect of SamaritanCloudon battery life of a mobile device is to determine the battery powerused solely by the proposed protocol. The difficulty arises from thefact that a mobile device is capable of running multiple applica-tions simultaneously. So, battery measurements taken from thedevice is the effect of running multiple applications, not Samari-tanCloud solely. To make things worse, different sets of applica-tions might be run on different devices. This makes directcomparison of battery power used by different devices while run-ning SamaritanCloud, irrelevant. For this experiment, we assumethat, set of applications run on a mobile device does not changeover time. With this assumption, we minimize the effect of abovementioned problems by measuring scaled time as defined below.

scaled timeðx;yÞ ¼absolute timewith

ðx;yÞ

absolute timewithoutðx;yÞ

; where

absolute timewithoutðx;yÞ = absolute time taken by battery of the client to

reach power level y from level x without using SamaritanCloudand absolute timewith

ðx;yÞ = absolute time taken by battery of the clientto reach power level y from level x using SamaritanCloud.

For this experiment the cloud is formed with 1 server. At a time50 clients are selected randomly from the network. These selectedclients send Profile-Update-Request to the cloud at different rates.Fig. 7 shows scaled time averaged over all the users. We alsoobserve that battery power of most of the client devices cycle from95% to 30%. In Fig. 7 we present the battery data with scaled timefor a battery to drain its power level from 95% to 30%. As can beseen form the figure, more frequent transmission of Profile-Update-Request results in faster power loss. When a client usesGPS to determine its location and 3G network to connect to thecloud, 1 Profile-Update-Request every minute makes the batterycharge to drain from 95% to 30% in 20% of the time when Samari-tanCloud is not used. Similar scenario happens when a client usesGPS to determine its location and Wifi network to connect to thecloud (S). We also observe that, irrespective of the client using3G or Wifi network to connect to S, the use of GPS is the mostenergy inefficient way and use of significant location change(SLS) is the most energy efficient way of computing location. Whenthe client uses Wifi network to connect to S, energy consumptionof using SLS and Wifi for location computation are very similar.We also observe that, energy efficiency of SamaritanCloud growsvery slowly with time period between two consecutive Profile-Update-Request being 10 min or more.

4.4. Server-side performance measurement

In this section, we evaluate the effect on server-sideperformance using SamaritanCloud due to the following reasons,

� Change in frequency of Profile-Update-Request being sent tothe cloud.� Change in number of servers in the cloud.� Change in number of nodes present in the network.



Fig. 7. Change of battery life with change in rate of sent Profile-Update-Request.

Fig. 8. Response time of the cloud with varying frequency of received request.


We evaluate the effect of each of these separately in 3 differentexperiments as discussed below. First, we measure the effect offrequency of transmission of Profile-Update-Request and Help-Request on servers. For this experiment the cloud is set up withone server. We select 50 clients randomly from the network of200 clients to participate. Each client participating in the experi-ment sends out Profile-Update-Request and Help-Request requestat a given frequency (pre-computed by measurement server) for5 min. Fig. 8 shows the processing time of a request averaged overall the clients in the network. We define the processing time forProfile-Update-Request as the time difference between the timewhen the update request is sent by a client to S and the time whenall servicing clients receive the re-blurred profile of the updatedprofile from S. For Help-Request, processing time is defined to bethe time difference between the time when the help request is sentby a requesting client to S and the time when all the servicingclients finish computing the set of near neighbors of the requestingclient. It is to be noted in Fig. 8 that, when more than 1 Profile-Update-Request is sent in 80 ms by a client, the average processingtime is very high making SamaritanCloud virtually impossible touse. But, as the Profile-Update-Request are sent out less frequently(more than 80 ms time period between two consecutive requestsby a client) average processing time of a request remain more orless unchanged at around 80 ms. This is because, a single Profile-Update-Request takes around 80 ms of time to process. Also, thecloud is only capable of servicing 50 requests simultaneously and50 clients participate in the experiment at a time. Thus, when morethan 1 request is sent to the cloud by a client, only 1 of those is pro-cessed while rests are kept in a waiting queue. As the waitingqueue becomes longer so does the waiting time of the newly addedrequests. Moreover, when clients send Profile-Update-Request atthis heightened rate (more than 1 in 80 ms) the waiting queuekeeps on growing until it is full. At this point any new request isdropped. A client re-sends the dropped request, after some time.This process, makes the processing time of Profile-Update-Requestlong. On the other hand, when time period between 2 consecutiverequests by a client is set to be more than 80 ms, a request by aclient arrives at the cloud after the last request from that clientis finished processing. Thus, each request is processed on its arrivalwithout being put in a waiting queue. Thus, average processingtime for a Profile-Update-Request request remains more or lessthe same at around 80 ms. Similar situation occurs with Help-Request when time period between 2 Help-Request from a clientis set to be more than 143 ms. Now, we measure the performancevariation of SamaritanCloud with change in number of servers


present in the cloud S. We change the number of servers presentin S from 1 to 3 and also vary number of clients present in the net-work from 10 to 200. This experiment is done in ‘‘unclustered’’mode. Every client transmits a request (Profile-Update-Requestor Help-Request) once every 10 min. Each of the servers presentin S has a maximum capacity of processing 50 requests, simulta-neously. As can be seen from Fig. 9, both in Profile-Update-Requestand Help-Request phase, the total processing time with one serverin S remains small till the number of nodes in the network is 50.Beyond this point, the processing time increases linearly with thenumber of nodes in the network. This because, with more than50 clients in the network the server in S receives more than 50requests at a time. But, the server is capable of processing 50requests, simultaneously. So, the rest of the requests are put in awaiting queue. This increases the average waiting time. Similarly,with 2 servers the processing time increases beyond network size98. This is because, although each server is capable of handling 50requests simultaneously, these 2 servers use 1 process each tocommunicate between themselves. Similar scenario occurs with3 servers in the cloud. With 3 servers, the processing timeincreases with more than 144 nodes. To measure the differencein performance of SamaritanCloud in clustered and unclusteredmode, we deploy S with one server with a capacity of processing50 request at a time. The client-side application sends Profile-Update-Request and Help-Request once in every 10 min. We



Fig. 9. Performance comparison of Profile-Update-Request and Help-Request phases with varying server count in the cloud with f ¼ 50; k ¼ 8.


measure the processing time for a request in clustered and unclu-stered mode with different cluster size (viz. 40, 50, 60). For each ofthese modes, we compute processing time of a request with differ-ent number of nodes in the network changing from 10 to 80. Wepresent our results in Fig. 10. In our experiment, during Profile-Update-Request phase, 8 copies of the re-blurred profile of theupdate request is distributed throughout the selected set of servic-ing nodes. As can be seen from Fig. 10a, Profile-Update-Requestrequests have similar processing time in unclustered and clusteredmode. Total processing time for both clustered and unclusteredmode does not change much with change in number of nodes inthe network as long as the total number of nodes are less thanmaximum requests (50, for this experiment) S serves, simulta-neously. With number of nodes more than 50, total processingtime increases linearly with the number of nodes in the networkboth in clustered and unclustered mode. According to our experi-ment, all clients transmit their request almost at the same time.Thus, as long as 50 or less clients are present in the network, Sserves all requests on their arrival. But, as the number of nodesincreases over 50, some requests are put in a waiting queue, thereby increasing average waiting time. Moreover, it is to be noted in

Fig. 10. Performance comparison of clustered and unclustered mode in Profi


Fig. 10a that average processing time of a Profile-Update-Requestis more for clustered mode than in cluster mode with number ofnodes more than 50. This is because, according to our experimentalsetup S sends 8 copies of re-blurred profile in repose to a Profile-Update-Request to the entire network in unclustered mode andto every cluster in the clustered mode. Thus, S transmits morere-blurred profiles in clustered mode than in unclustered mode.With more than 50 nodes in the network, these transmissions takeplace in multiple rounds. This, increases processing time of arequest in clustered mode during Profile-Update-Request phase.In Help-Request phase (Fig. 10b), total processing time of a requestremains the same both in clustered and unclustered mode withchange in number of nodes in the network for less than 50 nodes.As number of nodes increases further, processing time increaseslinearly with number of nodes. Average processing time in clus-tered mode is less than that in unclustered mode. This is becausein clustered mode, on receiving a Help-Request, S broadcasts there-blurred profiles to all nodes in the network. But in clusteredmode, re-blurred profiles are forwarded to all node in a selectedcluster. This decreases number of data transmission by S in clus-tered mode over unclustered mode. So, as can be seen in Fig. 10,

le-Update-Request and Help-Request phases with m ¼ 1; f ¼ 50; k ¼ 8.




clustering decreases processing time in Help-Request phase, but itincreases processing time by a small amount in Profile-Update-Request phase.

5. Conclusion

To the best of our knowledge, SamaritanCloud is the first of itskind in using location-based social networking system to enablepeople to physically help each other. In our system, when an userneeds help at a particular location, the request is sent to the serverand the users near the area of interest are looked up efficientlyusing distributed additive homomorphic encryption. To hinderexternal and internal security attacks SamaritanCloud uses ran-domly generated blurs. We have implemented a SamaritanCloudmobile application for iOS 5.0. The application fetches user’s loca-tion with the help of one of cell triangulation, Wi-Fi hotspot or GPS.Because of the limited battery-life and processing power of smart-phones, the mobile application allows users to manually select thefrequency of location update and the level of security that theydesire. Our SamaritanCloud system, opens up an entirely newapproach to enable people to benefit from location-based socialnetworks.

References

[1] Strangers Helping Strangers. <http://www.facebook.com/SHStrangers>.[2] Yelp. <http://www.yelp.com/>.[3] Facebook Places. <http://www.facebook.com/facebookplaces>.[4] Gowalla. <http://gowalla.com/>.[5] Foursquare. <https://foursquare.com/>.[6] D. Stackpole, Dynamic Geosocial Networking (06 2008).[7] Q. Huang, Y. Liu, On Geo-social Network Services, Geoinformatics.[8] A. Cooper, T. Hardie, Geopriv: creating building blocks for managing location

privacy on the internet, IETF J. (2009).


[9] G. Myles, A. Friday, N. Davies, Preserving privacy in environments withlocation-based applications, Pervasive Comput., IEEE (2003).

[10] H. Kido, Y. Yanagisawa, T. Satoh, An anonymous communication techniqueusing dummies for location-based services, in: Proceedings of IEEEInternational Conference on Pervasive Service, 2005.

[11] A.R. Beresford, F. Stajano, Location privacy in pervasive computing, IEEEPervasive Comput. (2003).

[12] K.P. Tang, P. Keyani, J. Fogarty, J.I. Hong, Putting people in their place: ananonymous and privacy-sensitive approach to collecting sensed data inlocation-based applications, in: Proceedings of the SIGCHI Conference onHuman Factors in Computing Systems, 2006.

[13] M. Gruteser, X. Liu, Protecting privacy in continuous location-trackingapplications, IEEE Sec. Privacy (2004).

[14] M. Duckham, L. Kulik, A formal model of obfuscation and negotiation forlocation privacy, Pervasive Comput. (2005).

[15] M. Gruteser, D. Grunwald, Anonymous usage of location-based servicesthrough spatial and temporal cloaking, in: Proceedings of the InternationalConference on MobiSys, 2003.

[16] B. Gedik, L. Liu, A customizable k-anonymity model for protecting locationprivacy, in: Proceeding of the International Conference on DistributedComputing Systems, 2005.

[17] M.F. Mokbel, C.-Y. Chow, W.G. Aref, The new casper: a privacy-aware location-based database server, in: IEEE 23rd International Conference on DataEngineering, 2007.

[18] J.I. Hong, J.A. Landay, An architecture for privacy-sensitive ubiquitouscomputing, in: Proceedings of the International Conference on MobileSystems, 2004.

[19] S. Goldwasser, S. Micali, Probabilistic encryption & how to play mental pokerkeeping secret all partial information, in: Proceedings of the FourteenthAnnual ACM Symposium on Theory of Computing, STOC ’82, ACM, 1982.

[20] T. Elgamal, A public key cryptosystem and a signature scheme based ondiscrete logarithms, IEEE Trans. Inform. Theory 31 (4) (1985) 469–472, http://dx.doi.org/10.1109/TIT.1985.1057074.

[21] C. Gentry, Fully homomorphic encryption using ideal lattices, in: Proceedingsof the 41st Annual ACM Symposium on Theory of Computing, STOC ’09, ACM,2009.

[22] K. Lauter, M. Naehrig, V. Vaikuntanathan, Can homomorphic encryption bepractical?, in: Proceedings of the 3rd ACM Workshop on Cloud ComputingSecurity Workshop, CCSW ’11, ACM, 2011

[23] C. Raiciu, D.S. Rosenblum, Enabling confidentiality in content-based publish/subscribe infrastructures, in: Securecomm and Workshops, 2006.


http://www.facebook.com/SHStrangers

http://www.yelp.com/

http://www.facebook.com/facebookplaces

http://gowalla.com/

http://https://foursquare.com/

http://refhub.elsevier.com/S0140-3664(14)00303-X/h0040














http://dx.doi.org/10.1109/TIT.1985.1057074

http://dx.doi.org/10.1109/TIT.1985.1057074










samaritancloud: secure infrastructure for scalable location-based services

Documents