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-based services Abhishek Samanta ⇑, Fangfei Zhou, Ravi Sundaram Northeastern 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 service Mobile devices Privacy Homomorphic encryption

a b s t r a c t With the maturation of online social networks (OSNs), people have begun to form online communities and 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 paper we propose SamaritanCloud, a scalable infrastructure that enables a group of mobile and geographicallydispersed personal computing devices to form a cloud for the purpose of privately sharing relevant locality-specific information. From a technical standpoint our main contribution is to show that only additive homomorphic encryption is sufficient to compute nearness in a cryptographically secure and scalable way in a distributed setting. This allows us to harness the benefit of linear match time while guaranteeing the locational privacy of the clients. In terms of performance our system compares favorably with simpler publish/subscribe schemes that support only equality match. We demonstrate the practical feasibility of SamaritanCloud with experimental evaluations. Ó 2014 Elsevier B.V. All rights reserved.

1. Introduction People often have the need for assistance from strangers in remote locations. Consider the following requests: please tell the marathon runner with bib #123 I will wait at the finish line; did I leave my keychain on campus? Is there a brown puppy roaming in the playground? In this paper we propose, not just a new architecture, but, in fact, a new cloud based service – SamaritanCloud – the goal is to provide a way for people to connect with others (possibly strangers) in a remote location and obtain (physical) help from them. SamaritanCloud is deployed as cell phone application, users submit their requests to the cloud which coordinates users’ requests and efficiently find possible candidates to respond to the request. Such a service will require efficient technical solutions to problems such as scalability, privacy, and reputation to overcome the social barriers of soliciting help from strangers. We focus primarily on the technical aspects of scalability and privacy (matching people with strangers in a secure and private way) so that the need for help and the ability/desire to assist are disclosed safely. ⇑ Corresponding author. E-mail addresses: [email protected] (A. Samanta), [email protected] (F. Zhou), [email protected] (R. Sundaram).

Since the emergence of online social networks (OSNs), people have sought help from their social contacts. The most common method to seek for help on social network sites, e.g., Facebook, Twitter, or ‘‘strangers helping strangers’’ [1], is post – an user posts his/her question or request on his/her social network page or a relative group page and waits for response, which is very similar to subscribing to an email list and broadcast questions except exposing more privacy. This method is simple but suffers from three major drawbacks. High/unpredictable response latency: Popular OSNs, e.g., Facebook, Twitter own worldwide users, who live in different locations and have different schedules. A post on a group page could not reach all the members in a short time and may be overwhelmed 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 for time-restricted and location sensitive questions. Most online requests focus on recommendation, suggestions and people do not make off-line offer before they build trust on each other. Privacy loss: Users requesting help on OSNs could end up exposing themselves to a large group, including friends they know in real life, as well as users, who are not willing/able to offer help. Unnecessary privacy leak may affect user’s personal life and should be avoided.

http://dx.doi.org/10.1016/j.comcom.2014.08.013 0140-3664/Ó 2014 Elsevier B.V. All rights reserved.

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

2

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

1.1. Related work

1.2. Our contributions

Geosocial networking [2–5] offers location based services (LBS) to users to interact relative to their locations. LBS typically is an information or entertainment application that is dependant on location of user. By these services users are offered possibilities to 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 social contact or for crowd sourcing. Many of such public LBS provide no privacy while some offer limited protection on an opt-in or opt-out basis. Here we briefly categorize the different approaches to providing privacy, as well as the associated shortcomings. Middleware: Geopriv [8] and LocServ [9] are policy-based privacy management approaches for secure location transfer that employ a trustworthy middleware mediating between locationbased applications and location tracking servers. Geopriv [8] describes an approach to securely transferring location information and associated privacy data by creating ‘‘location objects’’ that encapsulate user location data and associated privacy requirements. Once ‘‘location generator’’ (e.g. user device) creates an ‘‘location object’’, it sends it to a middle server which forwards the object to ‘‘location recipient’’ based on different kinds of rules. LocServ [9] is a middleware service that lies between locationbased applications and location tracking servers. It offers a general framework of components that allows users to apply general policies to control release of their location information. However, the practicality of such systems have yet to be determined, as the trustworthiness of middleware is hard to guarantee. Dummies or anonymity: Instead of sending out the exact location, a client sends multiple different locations to the server with only one of them being true [10]. The drawback of such schemes is that over the long run the server is able to figure out the client’s location by comparing the intersection of uploaded locations. Some other schemes [11,12] separate location information from other identifying information and report anonymous locations to the server. However, guaranteeing anonymous usage of location-based services requires that the precise location information transmitted by a client cannot be easily used to re-identify the subject. Location hiding: Clients define sensitive locations where they do not want to be tracked, and the location-based application stops tracking when the user gets close to those areas [13]. Location perturbation: These schemes ‘‘blur’’ the exact location information to a spatial region [14–17] or send a proxy landmark instead [18] and hence, are not suitable for applications that require accurate locations. The scheme presented in this paper uses client-specific, personalized and global blurs that are random elements in a finite field to guarantee perfect accuracy and cryptographic security; more on this in the sections to follow. To complete our review of related work we briefly survey the literature on homomorphic encryption. Homomorphic encryption is a type of encryption scheme that provides ability to perform arithmetic operation on cipher text and get the encrypted result which is equivalent to the encryption of the result by applying the same arithmetic operation on the plaintext. The encryption systems of Goldwasser and Micali [19], and Elgamal [20] are known to support either addition or multiplication among encrypted cypher texts, but not 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 multiplication on encrypted data. Fully homomorphic encryption schemes are very powerful as it computes any function on an encrypted ciphertext. But, Lauter et al. [22] showed that fully homomorphic encryption schemes till date are very resource consuming and are impractical to be used for most of practical purposes.

To overcome the above mentioned drawbacks of LBS and OSNs, we propose SamaritanCloud, a location-based cyber-physical network allowing people to reach friends or strangers in desired locations for help. SamaritanCloud is formed by a collection of backend servers and a set clients being served. The client side functionality of SamaritanCloud is easily deployed as a location-based cell phone application; the cloud coordinates client requests and efficiently finds candidates who are able/willing to offer help, even possibly physical help, in real-world life-threatening emergencies. From a technical standpoint our primary contribution is to show how partially homomorphic encryption can be adapted to a distributed setting so as to guarantee cryptographic security without sacrificing efficiency gains. The resulting protocol finds near-neighbors in constant-time thus providing efficient and private match of helpseekers and help-givers. SamaritanCloud preserves efficiency and privacy while calculating near neighbor, by employing different blurring techniques and partially homomorphic encryption.

2. System design SamaritanCloud is a protocol used by a cloud S and a set of clients C to securely compute neighbors nearby a given client. The cloud S is formed by connecting m servers with each other forming a clique with high speed network connections. The cloud serves a total of n clients. These clients are equally distributed among m servers in S. Clients are directly connected to their corresponding servicing servers. Each client has a mobile device with enough computation power to efficiently encrypt–decrypt using additive homomorphic functions. Clients are assumed to share a common key with which they exchange private messages that are denied to the cloud. A server is efficient in using public–private cryptosystem. It is also capable of broadcasting request to f clients, efficiently. On the other hand, a client can efficiently talk to its servicing server or a small group of other clients. The cloud S authenticates clients and initiates distributed near-neighbor computation. Each client is associated with an user-name, password and profile. A client uses user-name and password for authentication. A profile contains several private informations of the client, e.g. location, the reward the client is willing to pay on receiving help, etc. The profile is represented as a collection of d variables and their respective values (or, range of values). Variables are drawn from a metric space and for the purposes of this paper are assumed to take real numbers. To minimize dependencies on cloud infrastructure, SamaritanCloud delegates all computationally extensive operations, viz, distance computations, encryption– decryption process, to servicing clients. A client is called a servicing client, when it participates in secured neighbor computation for other clients. In SamaritanCloud, all clients present in the network behave as servicing clients. We analyze performance of SamaritanCloud in presence of an adversary. We assume that the adversary deploys as many attackers as it requires to successfully launch an attack against the proposed system. An attacker eavesdrops on transmission(s) among several parts of the system and shares the overheard message(s) among other attackers. The goal of the attackers is to extract profile informations from the messages heard so far. We classify an attacker as external or internal depending on its capacity of infiltrating SamaritanCloud. An external attacker is aware SamaritanCloud protocol but it does not have access to secrets used by the proposed protocol. Whereas, an internal attacker is aware of both SamaritanCloud protocol and some of the secrets used by it. Also, it is capable of compromising different parts of either cloud or the set of clients. When at-least one server of the cloud is compromised we assume that no part of the entire

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

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

cloud is trusted. Moreover, when a cloud or a client is compromised it behaves as an attacker and launches attack against rest of the system using SamaritanCloud. Formally, we classify these attackers as follows,  Rogue cloud: In this scenario, at-least one server of the cloud is compromised and tries to retrieve profile information of at-least one 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 attacks to leak profile information of at-least one good client. Rogue clients 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 ProfileUpdate-Request and Help-Request to SamaritanCloud. After receiving these requests, the cloud disseminates its response to the network. With help of this response, other attackers try to retrieve profile information of a good client successfully. 2.1. Definitions

2 ð1=2Þ

kp1  p2 k ¼ fRi ðj pi1  pi2 jÞ g

;

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 a requesting client cq R C if the distance between profile informations of ci and cq is at most a given distance, D, i.e. if

where pq and pi are profile data of cq and ci ;

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

br ðpÞ ¼ ðp  rÞ mod P;

where r 2 ½1; P and P is a large public

prime number: Profile: Profile (pi ) of a client ci , is defined as a collection of informations of ci , viz, x and y coordinates of its current location, maximum amount of weight ci can help with, area where ci can help, etc. A profile of a client is represented as a d-dimensional vector (in d-dimensional Euclidean space). Tolerance-value: Tolerance value is the maximum distance between profile of a client cj and profile requested by cq , within which cj receives help request from cq . Our scheme builds on prior work on confidential publish/ subscribe schemes. In the subsections to follow we briefly summarize these techniques.1 2.2. A confidential publish/subscribe scheme and its issues In the content-based publish/subscribe model the interests of subscribers are stored in a forwarding server which matches and routes relevant notifications to interested subscribers [23]. Procedures in Fig. 1a–c is the basic primitives shown in [23]. Observe that, in the above scheme, the server can match profiles across clients and across time so long as the random number used by the querying client is same as the random number used by the server. But, for the security of the scheme, it is necessary to change 1

the random number often. But this change incurs large overhead on the system. The extra overhead is explained with the following scenario. A client cq wants to send a request to the cloud. So, it invokes procedure REQUEST_PUB_SUB, Fig. 1a. But, after cq fetches the random number (line 2 in Fig. 1a), cloud updates it. When cq sends the pair 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 is changed. To avoid such scenarios cloud has to keep extra bookkeeping to make sure that, all the requests are processed before the random number is changed. For a large system this incurs large overhead. Also, the request process in publish/subscribe is very resource consuming as clients have to perform two encryptions before sending a request to the cloud. More importantly, the above scheme, without fully-homomorphic crypto-system only computes equality match and not the closeness of two attributes. But, Lauter et al. [22], have shown that fully-homomorphic encryptions are highly resource consuming and are not practical in real life scenario. Therefore, the above publish/subscribe algorithm is inadequate for our purposes.

3. SamaritanCloud

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

kpq  pi k 6 D;

3

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

3.1. Protocol SamaritanCloud works in 3 different phases called Initialization, Profile-Update-Request and Help-Request phases. In Initialization phase, the cloud S is started. At the start-up time, S generates several different blurs which are kept secrets from the clients and are used to maintain secrecy of client profiles. A client invokes Profile-Update-Request phase when its profile information is changed and Help-Request phase when it requires help. In Profile-Update-Request phase, a client blurs its changed profile with a random personalized blur and sends it to S along with encrypted blur. Since, the profile data is blurred with a random blur and the random blur is encrypted, no profile information leaks from the blurred profile. S then re-blurs the already blurred profile with global and client-specific blur of the client and distributes among selected set of servicing clients. In Help-Request phase the requesting client blurs its request-profile with its personalized blur and sends to S which in turn re-blurs the already blurred profile and distributes to selected servicing clients. Along with these re-blurred profiles, S also forwards sum of encrypted client specific and personalized blurs. Additive-homomorphic nature of the used cypto-system helps a client securely compute the set of nearneighbors of the requesting client, with these informations. These different phases of operations are explained in detail, below. Initialization: In this phase, the cloud (S), assigns 1 client-specific blur cs r i to each client ci . S also generates a global blur r g . Both client-specific and global blurs are kept secret from clients. These are used by the cloud to blur client profiles (see Fig. 3). Profile-Update-Request: This phase, Fig. 2a, is invoked by a client ci when its profile data pi is changed. A client, ci sends its blurred profile data to the cloud S. S forwards blurred pi among selected set of clients. The data transfer is thus composed of two sub-phases as follows, Update: In Update phase ci blurs its profile data pi by blurring each dimension separately.

bri ðpji Þ ¼ ðpji  r i Þ mod P; 8j 2 ½1; d; where; pji is jth dimension of pi ; and r i is the personalized blur used by ci :

ð1Þ

The client also encrypts its personalized blur, using the additivehomomorphic encryption nhsk ðr i Þ, and sends the pair (nhsk ðr i Þ; b r i ðpi Þ) to the cloud.

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

4

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

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 it receives an update request from a client ci . Client-specific blur (cs ri ) and the global blur (r g ) are used to blur already blurred profile of ci . We call this process re-blurring.

prblur ¼ ðbri ðpji Þcs ri þ rg Þ mod P ¼ ðpji  ri cs ri þ r g Þ mod P; ji ð2Þ where prblur is jth dimension of re-blurred profile of ci (prblur ). S saves ji i the encrypted blur nhsk ðr i Þ and distributes re-blurred profile values computed in Eq. (2) along with the address of ci to k clients. These k clients are selected in k rounds. In each round, 2 clients are chosen and the least loaded of these 2 clients is selected in that round. Help-Request: When a client (cq ) is in need of help, it invokes Help-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-profile and delegates the near-neighbor computation to all servicing clients. Clients compute distance between the requested profile and 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 (r q ), by blurring each dimension of pq , separately.

bþrq ðpqi Þ ¼ ðpqi þ r q Þ mod P; 8i 2 ½1; d;

where bþrq ðpqi Þ is the ith

dimension of blurred profile of the requesting client cq ;

ð3Þ

cq encrypts its personalized blur and tolerance value (tol) and sends q the tuple ðnhsk ðr q Þ; nsk ðtolÞ; bþ rq ðp ÞÞ to the cloud (S).

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

5

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

Redistribution: S invokes this phase on reception of a request from cq . Without loss of generality, let us assume that a client ci has blurred profile information of t other clients cj ; 8j 2 ½1; t. S builds a set (Ri ) of t 6-tuples (T j ) and sends it to ci . 1st and 2nd entries of T j are addresses of cq and cj , respectively. 1

T j ¼ cq ;

2

3 q T ij

 prblur  dhsk ð4 T qij Þ  5 T qij ¼ ðpql þ r q þcs r q þ r g Þ mod P j  ðpij  rj  cs r j þ r g Þ mod P  ðr q þ r j Þ mod P  ðcs r q þ cs rj Þ mod P ¼ ðpqi  pij Þ mod P

T j ¼ cj

3rd entry is built by re-blurring the blurred profile of cq , with the clients-specific blurs assigned to cq (cs r q ) and the global blur (r g ), as follows. 3

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

T lj ¼ ðbþrq ðpql Þþcs r q þ r g Þ mod P ¼ ðpql þ r q þcs rq þ rg Þ mod P;

Thus, according to the definition,

" d n X

3 q T ij

i¼1

ð4Þ where 3 T lj is lth dimension of 3rd entry of T j . S adds encrypted personalized random blur of cq and cj to build 4th entry of the tuple. This is where we use additive homomorphic nature of encryption scheme. 4

T j ¼ ðnhsk ðrq Þ þ nhsk ðrj ÞÞ mod P ¼ nhsk ðr q þ r j Þ mod P:

ð5Þ q

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

T j ¼ ðcs r q þ cs r j Þ mod P:

ð6Þ q

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

T j ¼ nsk ðtolÞ

Distance-computation: In this phase, Fig. 5c, clients compute distance between the blurred requested-profile and saved blurred profile data of other clients. Let us assume that after redistribution phase, a client ci receives a set Ri . Let us also assume that ci has blurred profile informations of t clients, cj ; 8j 2 ½1; t. Let T j 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, it decrypts the encrypted blur and tolerance value in T j . ci informs requesting client (cq ) about clients whose re-blurred profile satisfy the following condition.

" d n X

3

T lj 

prblur j



dhsk ð4 T lj Þ

5

 T lj

o2

#1=2

l¼1

< dhsk ð6 T lj Þ;

where dhsk ðÞ decryption using key sk:

ð7Þ

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

¼



" d n X

prblur j



dhsk ð4 T qij Þ 2

ðpqi  pij Þ

o1=2



5 q T ij

o2

#1=2

# mod P ¼ kpq  pj k



i¼1

As has been discussed earlier, profile information of a client is blurred with randomly selected blurs and each of these blur is uniformly selected from the range ½1; P, where P is a large public prime number. So, without any information about the random numbers used for blurring technique, the only way an attacker computes correct profile from a blurred profile is by guessing the random blur, correctly. Since, there are P possible numbers to select a random blur from, the probability of guessing a random blur correctly is at-least 1=P. The chance of guessing the random blur used by a client varies depending on how much information an attacker has about the blur. But for better security, this chance should be as close to 1=P as possible. In the article to follow, we show that security offered by SamaritanCloud against different kind of attacker is 1=P. Before, going into details, we formally define 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 successfully computing the profile data of a client from its re-blurred profile by at-most one guess. Security against external attacker and rogue cloud: In the proposed protocol Profile-Update-Request and Help-Request are blurred with random personalized blur of a client and then these already blurred profiles are further blurred with client specific and global blurs. So, only way for an external attacker and rogue client to retrieve client profile from a blurred profile is by guessing the blur correctly. Since, all the blurs are selected uniformly at random from ½1; P,

PILOGexternal ¼ PILOGrogue—cloud ¼

1 P

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

Lemma 1. Given, T qj is the tuple containing data to compare with cj and prblur is the blurred profile of cj j

prblur ¼ ðpji  ri cs ri þ rg Þ mod P ji

" d n X

where ri is the personalized blur and cs r i is the client-specific blurs for ci . r g is the global blurs. The only way for an adversary to retrieve the profile information successfully is by guessing the blurs ðr i cs ri þ r g Þ mod P, correctly. Since, all the blurs are selected uniformly at random from ½1; P, chance of that happening is 1P. Thus,

3 q T ij

 prblur  dhsk ð4 T qij Þ  5 T qij j

o2

#1=2 ¼ kpq  pj k:

i¼1

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

prblur ¼ ðpij  r j cs r j þ r g Þ mod P: ij

ð8Þ

Now, using Eq. (5),

dhsk ð4 T qj Þ ¼ dhsk ðnhsk ðr q þ r j Þ mod PÞ ¼ ðrq þ rj Þ mod P:

ð9Þ

PILOGpassiv e—rogue—client ¼

1 P

Security against active rogue clients: Now let us consider attacks launched by active rogue clients. A rogue client ai sends a fake Help-Request to the cloud (S) with an intention of helping other attackers in the network retrieve profile information of at-least one good client from its blurred profile data. On

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

6

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

receiving a fake Help-Request from ai ; S builds a set of tuples Ri with T j as follows for each selected clients (ci ) and forwards it to a set of selected clients as follows,  1 T j ¼ ai  2 T j ¼ cj , where cj is a client whose blurred profile data is stored by ci .  The third dimension of T j is re-blurred request-profile of the requesting attacker (ai ). The request-profile (pa ) blurred with personalized blur of ai (ra ) is further re-blurred by using client specific blur of ai (cs ra ) and global blur (rg ). This process of reblurring is shown below, rblur ah pl

¼ ðpal þ r a þcs r a þ rg Þ mod P;

where a prblur is lth dimension of re-blurred requested profile of l ai .  4 T j ¼ nhsk ðr a þ rj Þ mod P, where ra is the random personalized blur used by ai and rj is the random personalized blur used by client cj  5 T j ¼ ðcs r a þ cs r j Þ mod P  6 T j ¼ nhsk ðtolÞ, where tol is the tolerance value requested by ai . Since, all the attackers share informations, aj knows the profile requested by ai (pa ) and the random personalized blur used by ai (ra ). With these informations, aj retrieves {ðcs r a þ r g Þ mod P} and personalized blur (r j ) of cj from fake Help-Request. If aj guesses either global blur (rg ) or the client specific blur of ai (cs ra ) correctly, it retrieves the profile information of cj from its blurred profile. Since, both the client-specific and global blurs are selected uniformly at random from ½1; P,

PILOGactiv erogueclient

To avoid such attacks against rogue clients with eavesdropping capability, we extend our already proposed SamaritanCloud. The extended SamaritanCloud protocol, along with secret key (sk) shared only among clients also uses a pair of public–private key of the cloud S. The public key (pk) of S is known to all the clients in the network. Initialization: In this phase the cloud S is initialized and in the process of starting S randomly assigns unique client-specific blurs to clients and also it randomly generates a random blur (r g ). Profile-Update-Request: In this phase (Fig. 4a), a client blurs its updated profile as follows and sends it to S.

bri ðpji Þ ¼ ðpji  r i Þ mod P; 8j 2 ½1; d;

dimension of pi ; and r i is the personalized blur used by ci : The client (ci ) also generates a random salt si and adds it to the personalized blur r i . Then, ci encrypts (ri þ si ) using the additivehomomorphic encryption nhsk ðr i þ si Þ; si using pk and sends the tuple (nhsk ðr i þ 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 servicing clients. rblur

pji ¼ ðbri ðpji Þcs r i þ r g Þ mod P ¼ ðpji  r i cs r i þ r g Þ mod P; ð10Þ

where prblur is jth dimension of re-blurred profile of ci (prblur ). The set ji i of servicing clients selected to forward the re-blurred profile to varies from ‘‘clustered’’ mode to ‘‘unclustered’’ mode as follows.  Unclustered mode: k different clients are selected in k rounds. In each round two clients are chosen randomly. The client which is less loaded is selected.  Clustered mode: The cloud divides the set of available clients into several clusters. From each cluster, k clients are selected at random in k rounds. In each round, two clients are chosen from each cluster. The less loaded client between the 2 clients chosen from same cluster is selected.

1 ¼ P

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 clients simultaneously. So, a cloud consisting of m servers is capable of broad-casting to m  f clients, simultaneously. Thus, for a network of size more than m  f , in Help-Request phase the cloud communicates with clients in multiple rounds. In each round, at-most m  f clients are communicated to. This increases average waiting time for a Help-Request as the number of clients in network is more than m  f . To avoid this problem, we propose an optional mode of operation, called ‘‘clustered’’ mode. We call the protocol described so far, ‘‘unclustered’’ mode of SamaritanCloud. In ‘‘clustered’’ mode SamaritanCloud divides nodes available in the network among several clusters each of size at-most s. We discuss more about the clustered mode in detail later in this section. As discussed in the previous section (Section 3.1), SamaritanCloud is secured against attacks by passive rogue clients. But, in the last section we consider only passive rogue clients which are not capable of listening to information transmission among clients and cloud. If a passive rogue client (ai ) eavesdrop on these transmissions, SamaritanCloud is compromised. Please note that since the attacker is a rogue client, it has access to secret key (sk) shared only among clients. Now, in Profile-Update-Request phase, a client blurs its profile using a randomly selected personalized blur. It also encrypts the blur using the sk and sends the blurred profile along with the encrypted blur to cloud. A passive rogue client eavesdropping on this transmission successfully retrieves the personalized blur used by the good client. Using this random blur, the profile information is then retrieved.

where; pji is jth

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

bþrq ðpqi Þ ¼ ðpqi þ r q Þ mod P; 8i 2 ½1; d;

where bþrq ðpqi Þ is the ith

dimension of blurred profile of the requesting client cq : ð11Þ cq generates a random salt sq and adds it to the personalized blur used by cq (rq ). cq , then, encrypts ðr q þ sq Þ and tolerance value (tol) q and sends the tuple ðnhsk ðr q þ sq Þ; nsk ðtolÞ; npk sq ; bþ r q ðp ÞÞ to the cloud (S). After receiving this request, S builds a set of 6-tuples and sends those to a set of selected servicing clients. Without loss of generality let us assume that, S builds a set (Ri ) of tuples for a client ci . A tuple T j has enough information to enable ci to determine is a client cj is a near-neighbor of cq . T j is built as follows, 1st and 2nd entries of T j are addresses of cq and cj , respectively.

1

T j ¼ cq ;

2

T j ¼ cj

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

T lj ¼ ðbþrq ðpql Þ þ cs r q þ r g Þ mod P ¼ ðpql þ r q þ cs r q þ r g Þ mod P; ð12Þ 3

where T lj is lth dimension of 3rd entry of T j .

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

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

7

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

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

T j ¼ ðnhsk ðr q þ sq Þ þ nhsk ðrj

þ sj ÞÞ mod P

¼ nhsk ðr q þ r j þ sq þ sj Þ

mod P: ð13Þ

5th entry is built by adding the client specific blurs and the random salts of cq and cj . Since, either of the client-specific blurs is not known to clients, the individual values of client-specific blurs are not leaked by this entry. 5

T j ¼ ðcs r q þ cs r j  sq  sj Þ mod P:

ð14Þ q

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

T j ¼ nsk ðtolÞ:

ð15Þ

The set of servicing clients selected to forward the set of 6-tuples varies 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 requesting client (cq ) after receiving the set of tuples Ri . A clientcj is a near-neighbor of ci if the following predicate is satisfied.

" d n X

3

T lj 

prblur j



dhsk ð4 T lj Þ

5

 T lj

o2

#1=2

l¼1

< dhsk ð6 T lj Þ;

where dhsk ðÞ 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 the requesting profile r q . Right side of Eq. (16) is the tolerance value.

3.3. Optimality Random blurs and salts are essential in maintaining secrecy of profile data in SamaritanCloud. Although, these blurs and salts help the proposed protocol avert different attacks, these also increase the overhead bookkeeping. So, for better performance, proposed protocol should use least number of blurs and salts possible without affecting security. Here we prove that, if the proposed protocol had used different sets of random blurs or salts, it would have been less efficient. To prove this, we first define a family of protocols, which we call generic family of protocols (GFP) that uses a collection of blurs and salts to hide profile informations. Then, we show that, any protocol from this family of protocols, is at-most as efficient as proposed SamaritanCloud. Generic Family of Protocols (GFP): GFP is a collection of protocols used to securely compute set of near-neighbors of a client using a cloud. A protocol P in GFP may use a set of client-side and server-side blurs and salts to achieve required security. A protocol P belongs to GFP if it has 3 phases of operations as follows, Initialization: In this phase, the cloud is started. At the start up time, the cloud also initializes different blurs it uses in P to 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 send profile informations to the cloud without blurring. Also, if the client has access to random salts, it sends the sum of personalized blur and the salt encrypted with secret key shared among clients along with the salt encrypted with public key of the cloud S. Other-wise only encrypted personalized blur is sent. On receiving the blurred profile data, the cloud re-blurs received data and sends it to selected servicing clients. Re-blurring is achieved with the random blurs available to the cloud, according to P. If the cloud does not have access to any random blur, it distributes the received

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

8

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

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

data to selected set of servicing clients. Servicing clients are selected depending on the mode of operation of the system as follows,  Unclustered mode: k clients are selected in k rounds. In each round two clients are chosen randomly. The client which is less loaded is selected.  Clustered mode: From each cluster, k clients are selected in k rounds. In each round, two clients are chosen at random from each cluster. The less loaded client between the 2 clients chosen from same cluster is selected. Help request: In this phase, the requesting client, sends the blurred requested profile data and encrypted tolerance value. Also, if random salt is available to the client, it sends the sum of personalized blur and the salt encrypted with shared secret key. If no salt is available it sends only the encrypted personalized blur to S. If no blur is available, the client sends the requested profile data and encrypted tolerance value to the cloud. The tolerance value is encrypted with a key shared among all clients. After receiving these, the cloud builds a set of tuples for each selected client. A tuple is a vector containing the re-blurred requested profile, encrypted tolerance value and other informations required for successful near-neighbor computation. These informations depend on the set of blurs used. The cloud then sends these sets of tuples to selected set of servicing clients. Selection of servicing clients depend on the mode of operation of the cloud as follows,

 Unclustered mode: The cloud selects all available clients in the network.  Clustered mode: The cloud selects all clients from a randomly selected cluster. After receiving the set, a servicing client determines nearneighbor of requested profile and informs the requested client. Remark 1. SamaritanCloud is a protocol in GFP. Definition 1. A protocol P 1 is defined to be more efficient than another protocol P 2 , iff P 1 is at-last as secured as P 2 ; P 1 uses atmost as much computation power as P 2 and P 1 uses at-most as much memory as P 2 . Lemma 2. SamaritanCloud is the most efficient protocol in GFP. Proof. Because of the space constraint we could not put the proof here. The lemma can be verified with Table 1. h

4. Evaluation 4.1. Runtime analysis As has been explained before, SamaritanCloud works in two different modes called ‘‘clustered’’ and ‘‘unclustered’’. In unclustered

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

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

mode, the cloud communicates with entire set of clients in the network in Help-Request phase. Whereas, in clustered mode the cloud makes clusters each containing at-most s clients each and communicates with all clients in a single cluster. In Profile-Update-Request phase, a client sends its blurred profile to the cloud which re-blurs this already blurred profile and distributes it among different selected servicing clients depending on different modes of operation as follows,  Unclustered mode: In this mode, the cloud selects k clients in k rounds. In each round the least loaded of randomly chosen 2 clients is selected. According to our assumption, a cloud is composed of m servers and a server is capable of efficiently communicating to f clients. So, the cloud communicates efficiently to m  f clients. If there are more clients present the cloud 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 in this 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, if k  m  f , Profile-Update-Request phase can be done in constant time(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, total number of servicing clients selected for re-distribution is nk . s Moreover, the cloud efficiently communicates with m  f clients. So, communication among clients and the cloud takes Oððn  kÞ=ðs  m  f ÞÞ time. Similar to ‘‘Unclustered mode’’, computation (blurring and re-blurring single profile data) takes constant time. So, total time complexity of ProfileUpdate-Request in this mode is Oððn  kÞ=ðs  m  f ÞÞ. In Help-Request phase, the requesting client sends blurred requested profile along with encrypted tolerance value to the cloud. The cloud builds and forwards sets of 6-tuples for each

Table 1 PILOG values for different scenarios and under different types of attacks. Protocol1: Protocol with no blur (we call it PlainText protocol). Protocol2: Protocol with personalized blur. Protocol3: Protocol with client-specific blur. Protocol4: Protocol with global blur. Protocol5: Protocol with personalized and client-specific blurs. Protocol6: Protocol with personalized and global blurs. Protocol7: Protocol with client-specific and global blurs. Protocol8: Protocol with personalized and 2 global blurs. Protocol9: Protocol with a personalized and 2 client-specific blurs. Protocol10: Protocol with client-specific and 2 global blurs. Protocol11: Protocol with 2 clientspecific 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 with personalized, 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 capable of eavesdropping. Attacker4: Passive rogue client capable of eavesdropping. Attacker5: Active rogue client.

Protocol1 Protocol2 Protocol3 Protocol4 Protocol5 Protocol6 Protocol7 Protocol8 Protocol9 Protocol10 Protocol11 Protocol12 Protocol13 Protocol14 Protocol15

Attacker1

Attacker2

Attacker3

Attacker4

Attacker5

1 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P

1 1=P 1 1 1=P 1=P 1 1=P 1=P 1 1 1=P 1 1=P 1=P

1 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P 1=P

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1=P

1 1 1 1 1 1 1=P 1 1=P 1=P 1=P 1 1=P 1=P 1=P

9

selected servicing clients. The set of servicing clients selected for this operation varies from clustered mode to unclustered mode.  Unclustered mode: All clients in the network are selected. As stated before, the cloud efficiently communicates with m  f clients simultaneously. So, the cloud takes Oðn=ðm  f ÞÞ time to communicate with all clients. Moreover, the cloud builds a set of tuple for each servicing clients. A tuple contains enough information to successfully compare blurred request-profile and the blurred profile stored by the selected servicing client. In Profile-Update-Request phase, k copies of the blurred profile of a client is distributed throughout the network. Also, it is to be noted that SamaritanCloud builds as many 6-tuples as the number of blurred profiles stored throughout the network. So, assuming a 6-tuple takes constant time to be built, the cloud spends a Oðk  nÞ time to compute these tuples. After receiving these sets, each servicing client compares each tuple from the received set with the corresponding blurred profile stored. Since, there are d dimensions in a blurred profile, comparing a pair of tuple and blurred profile takes OðdÞ time. Because of the load balancing technique we use in Profile-Update-Request phase, each servicing client has profile information of Oðlog log nÞ other clients. Thus, a servicing client spends Oðd  log log nÞ time to compare received set of tuples with the blurred profiles stored. Thus, time complexity of this phase is Oð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 cluster. The Help-Request is forwarded to all the clients of the selected cluster. So, assuming s to be the size of a cluster, the cloud distributes Help-Request in s=ðm  f Þ rounds among servicing clients. Moreover, in this mode a cluster contains k copies of profile informations of every client in the network. Thus, the cloud spends a total of Oðk  nÞ time to build all sets of tuples for distribution. After receiving these sets of tuples, each client compares each tuple with the corresponding stored blurred profile. Since, there are d dimensions in a profile and there are Oðn=sÞ different blurred profiles stored in a servicing client, it takes Oðd  n=sÞ time for a servicing client to determine the set of neighbors near-by the requesting client. So, total time complexity of SamaritanCloud in clustered Help-Request is Oð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 Profile-Update-Request and Help-Request phase. On the other hand, for larger cluster size (s ¼ xðn= log log nÞ), clustered mode is asymptotically more efficient than unclustered mode in HelpRequest phase. Also, for larger cluster size Profile-Update-Request phase has asymptotically comparable runtime for clustered and unclustered mode (clustered mode is Oðlog log nÞ times slower than unclustered). 4.2. Setup For the purpose of evaluation of the proposed SamaritanCloud protocol, we use the setup shown in Fig. 6. The clients use their credentials to login to the cloud. Once the identity of the client is verified, the consequent Profile-Update-Request or Help-Request are forwarded to the control server which in-turn hands those over to the available set of servicing servers (e.g. S1; S2 and S3 in Fig. 6). The intercommunication among servers is done over high speed LAN connection. A client is automatically logged out of the cloud if no request (either Profile-Update-Request or, Help-Request) is received from the client in 15 min. The control server works as load balancer by randomly distributing the available clients among the set of available servicing servers. The measurement server issues

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

10

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

Fig. 6. Experimental setup.

 How different are performance of SamaritanCloud in clustered and 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 of the client device would be drained fast. On the other hand, if the updates are sent rarely, the location data of clients are at a risk of getting outdated. So, it is important to determine the frequency the update frequency for optimal performance of the network. 4.3. Battery usage

different queries for different measurement matrices (viz. latency, battery life, etc.) to clients using control server. When clients reply back to these queries, they are channeled to the measurement server by control server. Also the measurement server decides on the total number of severs available to service available clients by sending a query to the control server. We developed a prototype mobile application based on iOS 5 to be used as client side application of SamaritanCloud. We generated our experimental data set by distributing this application among 200 volunteers in Boston area. Each of these volunteers installed SamaritanCloud application on their primary mobile phone. This prototype allows users 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 the server,  input request location (either latitude and longitude coordinates 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 VoIP service allowing it to (1) maintain a persistent connection with the server, (2) periodically fetch location information, even if the application is running on background. Our application utilizes Core Location Framework to get physical location. Location coordinates can be obtained through (a) standard location service and (b) significant-change location service (SLS). With standard location service, location data is gathered with either cell triangulation, Wi-Fi hot-spots or GPS satellites, depending on required accuracy. As our application periodically updates location to the server, it saves battery life by enabling the standard location service shortly at per the interval defined by client.2 With SLS, a location update is triggered by the operating system only if a device moves from one cell tower to the other, thus it provides only coarse location update. There is an accuracy-power trade off – GPS location update is accurate but power inefficient while significant-change location service is a less accurate but less power consuming technique. We developed servers using Apache Tomcat 7.0. We configure each server to simultaneously work with 50 clients. With this experimental setting we wish to answer the following questions,  What is the effect of SamaritanCloud on battery life of client mobile devices? This is important because consumer mobile devices severely suffer from limited power supply from its onboard battery system.  What is the effect of SamaritanCloud on server scalability?

2

Fetching location data requires a few seconds, the first location coordinates returned is usually saved from last time. Time-stamp of the location data is used to determine if the update is fresh.

The major difficulty in measuring the effect of SamaritanCloud on battery life of a mobile device is to determine the battery power used solely by the proposed protocol. The difficulty arises from the fact that a mobile device is capable of running multiple applications simultaneously. So, battery measurements taken from the device is the effect of running multiple applications, not SamaritanCloud solely. To make things worse, different sets of applications might be run on different devices. This makes direct comparison of battery power used by different devices while running SamaritanCloud, irrelevant. For this experiment, we assume that, set of applications run on a mobile device does not change over time. With this assumption, we minimize the effect of above mentioned problems by measuring scaled time as defined below. with

scaled timeðx;yÞ ¼

absolute timeðx;yÞ without

absolute timeðx;yÞ

;

where

without

absolute timeðx;yÞ = absolute time taken by battery of the client to reach power level y from level x without using SamaritanCloud with and absolute timeðx;yÞ = absolute time taken by battery of the client to reach power level y from level x using SamaritanCloud. For this experiment the cloud is formed with 1 server. At a time 50 clients are selected randomly from the network. These selected clients send Profile-Update-Request to the cloud at different rates. Fig. 7 shows scaled time averaged over all the users. We also observe that battery power of most of the client devices cycle from 95% to 30%. In Fig. 7 we present the battery data with scaled time for a battery to drain its power level from 95% to 30%. As can be seen form the figure, more frequent transmission of ProfileUpdate-Request results in faster power loss. When a client uses GPS to determine its location and 3G network to connect to the cloud, 1 Profile-Update-Request every minute makes the battery charge to drain from 95% to 30% in 20% of the time when SamaritanCloud is not used. Similar scenario happens when a client uses GPS to determine its location and Wifi network to connect to the cloud (S). We also observe that, irrespective of the client using 3G or Wifi network to connect to S, the use of GPS is the most energy inefficient way and use of significant location change (SLS) is the most energy efficient way of computing location. When the client uses Wifi network to connect to S, energy consumption of using SLS and Wifi for location computation are very similar. We also observe that, energy efficiency of SamaritanCloud grows very slowly with time period between two consecutive ProfileUpdate-Request being 10 min or more. 4.4. Server-side performance measurement In this section, we evaluate the effect on server-side performance using SamaritanCloud due to the following reasons,  Change in frequency of Profile-Update-Request being sent to the cloud.  Change in number of servers in the cloud.  Change in number of nodes present in the network.

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

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

11

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

We evaluate the effect of each of these separately in 3 different experiments as discussed below. First, we measure the effect of frequency of transmission of Profile-Update-Request and HelpRequest on servers. For this experiment the cloud is set up with one server. We select 50 clients randomly from the network of 200 clients to participate. Each client participating in the experiment sends out Profile-Update-Request and Help-Request request at a given frequency (pre-computed by measurement server) for 5 min. Fig. 8 shows the processing time of a request averaged over all the clients in the network. We define the processing time for Profile-Update-Request as the time difference between the time when the update request is sent by a client to S and the time when all servicing clients receive the re-blurred profile of the updated profile from S. For Help-Request, processing time is defined to be the time difference between the time when the help request is sent by a requesting client to S and the time when all the servicing clients finish computing the set of near neighbors of the requesting client. It is to be noted in Fig. 8 that, when more than 1 ProfileUpdate-Request is sent in 80 ms by a client, the average processing time is very high making SamaritanCloud virtually impossible to use. But, as the Profile-Update-Request are sent out less frequently (more than 80 ms time period between two consecutive requests by a client) average processing time of a request remain more or less unchanged at around 80 ms. This is because, a single ProfileUpdate-Request takes around 80 ms of time to process. Also, the cloud is only capable of servicing 50 requests simultaneously and 50 clients participate in the experiment at a time. Thus, when more than 1 request is sent to the cloud by a client, only 1 of those is processed while rests are kept in a waiting queue. As the waiting queue becomes longer so does the waiting time of the newly added requests. Moreover, when clients send Profile-Update-Request at this heightened rate (more than 1 in 80 ms) the waiting queue keeps on growing until it is full. At this point any new request is dropped. A client re-sends the dropped request, after some time. This process, makes the processing time of Profile-Update-Request long. On the other hand, when time period between 2 consecutive requests by a client is set to be more than 80 ms, a request by a client arrives at the cloud after the last request from that client is finished processing. Thus, each request is processed on its arrival without being put in a waiting queue. Thus, average processing time for a Profile-Update-Request request remains more or less the same at around 80 ms. Similar situation occurs with HelpRequest when time period between 2 Help-Request from a client is set to be more than 143 ms. Now, we measure the performance variation of SamaritanCloud with change in number of servers

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

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

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

12

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

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 unclustered mode with different cluster size (viz. 40, 50, 60). For each of these modes, we compute processing time of a request with different number of nodes in the network changing from 10 to 80. We present our results in Fig. 10. In our experiment, during ProfileUpdate-Request phase, 8 copies of the re-blurred profile of the update request is distributed throughout the selected set of servicing nodes. As can be seen from Fig. 10a, Profile-Update-Request requests have similar processing time in unclustered and clustered mode. Total processing time for both clustered and unclustered mode does not change much with change in number of nodes in the network as long as the total number of nodes are less than maximum requests (50, for this experiment) S serves, simultaneously. With number of nodes more than 50, total processing time increases linearly with the number of nodes in the network both in clustered and unclustered mode. According to our experiment, all clients transmit their request almost at the same time. Thus, as long as 50 or less clients are present in the network, S serves all requests on their arrival. But, as the number of nodes increases over 50, some requests are put in a waiting queue, there by increasing average waiting time. Moreover, it is to be noted in

Fig. 10a that average processing time of a Profile-Update-Request is more for clustered mode than in cluster mode with number of nodes more than 50. This is because, according to our experimental setup S sends 8 copies of re-blurred profile in repose to a ProfileUpdate-Request to the entire network in unclustered mode and to every cluster in the clustered mode. Thus, S transmits more re-blurred profiles in clustered mode than in unclustered mode. With more than 50 nodes in the network, these transmissions take place in multiple rounds. This, increases processing time of a request in clustered mode during Profile-Update-Request phase. In Help-Request phase (Fig. 10b), total processing time of a request remains the same both in clustered and unclustered mode with change in number of nodes in the network for less than 50 nodes. As number of nodes increases further, processing time increases linearly with number of nodes. Average processing time in clustered mode is less than that in unclustered mode. This is because in clustered mode, on receiving a Help-Request, S broadcasts the re-blurred profiles to all nodes in the network. But in clustered mode, re-blurred profiles are forwarded to all node in a selected cluster. This decreases number of data transmission by S in clustered mode over unclustered mode. So, as can be seen in Fig. 10,

Fig. 10. Performance comparison of clustered and unclustered mode in Profile-Update-Request and Help-Request phases with m ¼ 1; f ¼ 50; k ¼ 8.

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

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

clustering decreases processing time in Help-Request phase, but it increases processing time by a small amount in Profile-UpdateRequest phase. 5. Conclusion To the best of our knowledge, SamaritanCloud is the first of its kind in using location-based social networking system to enable people to physically help each other. In our system, when an user needs help at a particular location, the request is sent to the server and the users near the area of interest are looked up efficiently using distributed additive homomorphic encryption. To hinder external and internal security attacks SamaritanCloud uses randomly generated blurs. We have implemented a SamaritanCloud mobile application for iOS 5.0. The application fetches user’s location with the help of one of cell triangulation, Wi-Fi hotspot or GPS. Because of the limited battery-life and processing power of smartphones, the mobile application allows users to manually select the frequency of location update and the level of security that they desire. Our SamaritanCloud system, opens up an entirely new approach to enable people to benefit from location-based social networks. References [1] [2] [3] [4] [5] [6] [7] [8]

Strangers Helping Strangers. . Yelp. . Facebook Places. . Gowalla. . Foursquare. . D. Stackpole, Dynamic Geosocial Networking (06 2008). Q. Huang, Y. Liu, On Geo-social Network Services, Geoinformatics. A. Cooper, T. Hardie, Geopriv: creating building blocks for managing location privacy on the internet, IETF J. (2009).

13

[9] G. Myles, A. Friday, N. Davies, Preserving privacy in environments with location-based applications, Pervasive Comput., IEEE (2003). [10] H. Kido, Y. Yanagisawa, T. Satoh, An anonymous communication technique using dummies for location-based services, in: Proceedings of IEEE International Conference on Pervasive Service, 2005. [11] A.R. Beresford, F. Stajano, Location privacy in pervasive computing, IEEE Pervasive Comput. (2003). [12] K.P. Tang, P. Keyani, J. Fogarty, J.I. Hong, Putting people in their place: an anonymous and privacy-sensitive approach to collecting sensed data in location-based applications, in: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2006. [13] M. Gruteser, X. Liu, Protecting privacy in continuous location-tracking applications, IEEE Sec. Privacy (2004). [14] M. Duckham, L. Kulik, A formal model of obfuscation and negotiation for location privacy, Pervasive Comput. (2005). [15] M. Gruteser, D. Grunwald, Anonymous usage of location-based services through spatial and temporal cloaking, in: Proceedings of the International Conference on MobiSys, 2003. [16] B. Gedik, L. Liu, A customizable k-anonymity model for protecting location privacy, in: Proceeding of the International Conference on Distributed Computing Systems, 2005. [17] M.F. Mokbel, C.-Y. Chow, W.G. Aref, The new casper: a privacy-aware locationbased database server, in: IEEE 23rd International Conference on Data Engineering, 2007. [18] J.I. Hong, J.A. Landay, An architecture for privacy-sensitive ubiquitous computing, in: Proceedings of the International Conference on Mobile Systems, 2004. [19] S. Goldwasser, S. Micali, Probabilistic encryption & how to play mental poker keeping secret all partial information, in: Proceedings of the Fourteenth Annual ACM Symposium on Theory of Computing, STOC ’82, ACM, 1982. [20] T. Elgamal, A public key cryptosystem and a signature scheme based on discrete 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: Proceedings of the 41st Annual ACM Symposium on Theory of Computing, STOC ’09, ACM, 2009. [22] K. Lauter, M. Naehrig, V. Vaikuntanathan, Can homomorphic encryption be practical?, in: Proceedings of the 3rd ACM Workshop on Cloud Computing Security Workshop, CCSW ’11, ACM, 2011 [23] C. Raiciu, D.S. Rosenblum, Enabling confidentiality in content-based publish/ subscribe infrastructures, in: Securecomm and Workshops, 2006.

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