SamaritanCloud: Secure and Scalable Infrastructure for enabling Location-based Services Abhishek Samanta Fangfei Zhou Ravi Sundaram Northeastern University Boston, MA 02115 Email: {samanta, youyou, koods}@ccs.neu.edu Abstract—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 geographically-dispersed 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 homorphic 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 an experimental evaluation. Index Terms—location-based service, mobile devices, privacy, homorphic encryption I. I NTRODUCTION A. Motivation 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, reputation etc 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. 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. 1) 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. 2) 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. 3) 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. B. Related Work 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 locationsensitive 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. 1) Middleware: Geopriv [8] and LocServ [9] are policybased privacy management approaches for secure location transfer that employ a trustworthy middleware mediating between location-based 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” 2 (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 location-based 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. 2) 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. 3) 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]. 4) 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 arithmatic operation on cipher text and get the encrypted result which is equivalent to the encryption of the result by applying the same arithmatic operation on the plaintext. The encryption systems of Goldwasser and Micali [19], and El Gamal [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 homorphic 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. C. Our Contributions To overcome the above mentioned drawbacks of LBS and OSNs, we propose SamaritanCloud, a location-based cyberphysical network allowing people to reach friends or strangers in desired locations for help. SamaritanCloud is easily de- ployed 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 help-seekers and help-givers. SamaritanCloud preserves efficiency and privacy while calculating near neighbor, by employing different blurring techniques and partially homomorphic encryption. II. S YSTEM D ESIGN A. System Model SamaritanCloud consists of m servers and it serves n clients. 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. Servers are inter-connected with super-fast network connectors. SamaritanCloud is efficient in simple arithmatic computations (viz. addition, subtraction) and also broadcasting to clients. On the other hand, a client can efficiently talk to SamaritanCloud or a small group of other clients. SamaritanCloud is used to authenticate clients and to initiate distributed near-neighbor computation. Once the querying client knows the set of near neighbors, it sends the help request to them. Each client is associated with an username, password and profile. A client uses username and password for authentication. A profile is a collection of 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 obtain better scalability, SamaritanCloud delegates all computationally extensive operations, viz. distance computations, encryptiondecryption process, to the clients. B. Attack Model There are u adversaries (unknown to SamaritanCloud) present in the network. These adversaries form a group and launch attacks to retrieve profile information of other good clients. Adversaries follow SamaritanCloud protocol to avoid detection and also exchange informations among themeselves to launch an attack. The adversaries try to extract partial or full profile information from blurred profile data of a client. C. Definitions and Preliminaries We present some definitions we will need later on 1) Distance: The distance between two profiles p1 , p2 , represented as d-dimensional vectors, is defined as: kp1 − p2 k = (Σi (|pi1 − pi2 |)2 )(1/2) , where pi1 and pi2 are the values of the ith dimension of p1 and p2 , respectively. 3 2) Near-neighbor: Given a specific client cq , a set of clients C, and a distance value dist, ci ∈ C, cq 6∈ C, is said to be a near-neighbor of cq if the distance between pq and pi is at most dist, i.e. if kpq − pi k ≤ dist, where pq and pi are profile data of cq and ci , respectively. 3) Blur: Blur is a random number which is used to blur data. e.g. data p is blurred with a random blur r as follows, βr± (p) = (p ± r) modP, where r ∈ [0, P ) and P is a large public prime number. 4) 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). 5) Tolerance-value: Tolerence value is the maximum distance between profile of a client cj and profile requested by cq , within which cj receives help request from cq . TABLE I TABLE OF NOTATION Notation ci cq C pi pij pq pqi βr (p) ξk (p) ξkh (p) δkh (c) sk iT Explanation ith client A client which needs help Set of clients Profile data of ci , represented as d-dimensional vector ith dimension of pj Profile data requested by cq , represented as d-dimensional vector ith dimension of pq Profile data p blurred with r Encryption of data p using key k Encryption of data p using key k, using additive homomorphic encryption Decryption of cipher c using key k Secret key only known to clients ith entry of a tuple T The different kinds of communications between the cloud and a client are classified as follows, Authentication: A client uses the assigned username and password to authenticate itself to SamaritanCloud. ProfileUpdate: The client-side application periodically sends update messages to the cloud to update profile data. HelpRequest: When a client looks for help, he/she sends a request to the cloud, which initiates distributed near-neighbor computation. Notification: Once the requesting client finds a set of clients suitable for servicing a request, it forwards the request encrypted with shared key (sk) to the set. Follow-up: SamaritanCloud provides a simple client evaluation scheme by sending follow-up notification to the candidates who committed to offer help. We leave a more complete evaluation/reputation scheme as future work. Our scheme builds on prior work on confidential publish/subscribe schemes. In the subsections to follow we briefly summarize these techniques. 0 Texts after right arrowheads (⊲) in pseudocodes are comments 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: procedure M ATCH PUB SUB(ξξk (pq ) (r)) Sc ← φ for all ci ∈ C do ξk (pi ) ← f etch encrypted prof ile(ci ) ⊲ Encrypted profile of ci if ξξk (pi ) (r) = ξξk (pq ) (r) then Sc ← Sc ∪ c i end if end for Send2Client(cq , Sc ) ⊲ Sends Sc to cq return end procedure Fig. 1. Procedure invoked by the cloud after receiving a request to determine set of clients whose profile match requested profile. 1: 2: 3: 4: 5: 6: 7: procedure R EQUEST PUB SUB(pq ) r ← f etch rand cloud() ⊲ Fetches random number from cloud to encrypt clients data. Send2Cloud(r, ξξk (pq ) (r)) ⊲ Sends arguments to cloud return end procedure Fig. 2. Procedure invoked by a client to request for help D. 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 Figs. 1, 2 and 3 are 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 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.2. But, after cq fetches the random number (line2 Fig.2), cloud updates it. When cq sends the pair of random number and the encrypted value (line4 Fig.2) 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 requestprocesses are completed before the random number is changed. 1: 2: 3: 4: 5: procedure P ROFILE U PDATE PUB SUB(pi ) Send2Cloud(ξk (pi )) ⊲ Sends argument to cloud ⊲ k is the encryption key, shared among all clients return end procedure Fig. 3. Procedure invoked by a client to update its profile to cloud 4 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-homorphic crypto-system only computes equality match and not the closeness of two attributes. But, Lauter et al [22], have shown that fully-homorphic encryptions are highly resource consuming and are not practical in real life scenario. Therefore, the above publish/subscribe algorithm is inadequate for our purposes. E. SamaritanCloud In this section we propose the protocol of SamaritanCloud. Then we prove the correctness of our protocol. At the end we discuss about the security offered by SamaritanCloud. Before delving into technical details, we first present short intuitive description of our protocol. At the startup time, SamaritanCloud generates client specific blur for each client and a global blur, which are kept secret from clients. When profile of a client changes, it blurs the changed profile with a random personalized blur and sends it to SamaritanCloud 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. SamaritanCloud reblurs the already blurred profile with client-specific and global blur of the client and distributes among k least loaded clients. When a client wants help, he/she blurs its own profile with a personalized blur and sends to SamaritanCloud which in turn reblurs the already blurred profile and broadcasts to all clients. Along with these reblurred profiles, SamaritanCloud also broadcasts addition of client specific and encrypted personalized blurs. With these informations, a client computes the set of near-neighbors of requesting client. SamaritanCloud uses both client specific blur and global blur, because without these blurs under certain attack scenarios, an attacker can deterministically compute profile information of a requesting client. 1) Protocol: SamaritanCloud uses additive homomorphic crypto system to compute distance between profiles of two clients. It works in 3 phases as follows, Initialization: In this phase, Fig.5, SamaritanCloud assignes client-specific blur to all the clients. A client-specific blur cs ri is assigned to a client ci . SamaritanCloud also generates a global blur rg . Both client-specific and global blur are kept secret from clients. These are used by SamaritanCloud to blur client profiles. ProfileUpdate: This phase, Fig.4, is invoked by a client ci when its profile data pi is changed. In this phase, ci updates SamaritanCloud with blurred profile data. SamaritanCloud broadcasts blurred pi among set of clients C. The data transfer is thus composed of two subphases as follows, Fig. 4. 1: 2: 3: 4: 5: 6: 7: 8: ProfileUpdate process in SamaritanCloud system procedure I NITIALIZE ⊲ Global blur rg ← get rand() Store(rg ) cs ri ← get rand(), ∀ci ∈ C ⊲ Client-specific blur Store(ci , cs ri ), ∀ci ∈ C ⊲ Stores client-specific blur with corresponding client return end procedure Fig. 5. Procedure invoked at start of SamaritanCloud system a) Update: In U pdate phase, Fig.6, ci blurs its profile data pi by blurring each dimension seperately as follows, βr−i (pji ) = (pji − ri ) βr−i (pi ) = mod P, ∀j ∈ [1, d] (1) (βr−i (p1i ), βr−i (p2i ), ..., βr−i (pdi )) th where, pji is j dimension of pi , and ri is the personalized blur used by ci . ci also encrypts its personalized blur, using the additiveh homomorphic encryption ξsk (ri ), and sends the pair h − (ξsk (ri ), βri (pi )) to the cloud. b) Redistribution: SamaritanCloud invokes this phase, Fig.7, when it receives an update request from a client ci . Client-specific blur cs ri , and the global blur rg are used to blur already blurred profile of ci . We call this process reblurring. prblur = (βr−i (pji ) −cs ri + rg ) ji = (pji − ri − prblur i = cs g mod P, ∀j ∈ [1, d] ri + r ) mod rblur rblur (p1i , p2i , ..., prblur ) di P (2) SamaritanCloud distributes reblurred profile values computed in equation (2) along with the address of ci among k leasth loaded clients and saves the encrypted blur ξsk (ri ). HelpRequest: When a client (cq ) is in need of help, it invokes HelpRequest phase Fig.10. In this phase, cq sends 5 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: procedure U PDATE(pi ) r ← get rand() ⊲ Personalized random blur (p1i , ..., pji , ..., pdi ) ← pi βr− (pji ) ← (pji − r) mod P, ∀j ∈ [1, d] βr− (pi ) ← (βr− (p1i ), ..., βr− (pji ), ..., βr− (pdi )) h ξsk (r) ← (r · sk) mod P h Send2Cloud (ξsk (r), βr− (pi )) ⊲ Sends the pair to SamaritanCloud return end procedure Fig. 6. Procedure invoked by a client to update its blurred profile to SamaritanCloud blurred requested-profile along with a tolerance value to SamaritanCloud. On reception of a request, SamaritanCloud broadcasts the blurred requested-profile to all clients and delegates the near-neighbor computation to 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 subphases as follows, c) Request: The requesting client cq blurs the requestedprofile pq with a randomly generated personalized blur (rq ), Fig.8, by blurring each dimension of pq seperately. βr+q (pqi ) = (pqi + rq ) βr+q (pq ) = mod P, ∀i ∈ [1, d] (3) (βr+q (pq1 ), βr+q (pq2 ), ..., βr+q (pqd )) cq encrypts its personalized blur and tolerance value (tol) and h h sends the tuple (ξsk (rq ), ξsk (tol), βr+q (pq )) to SamaritanCloud. d) Redistribution: SamaritanCloud invokes this phase on reception of a request from cq . 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: h (ri ), βr− (pi ))) procedure R EDIST UP((ξsk cs ri ← f etch cs blur(ci ) ⊲ Fetches client-specific blur for ci rg ← f etch global blur() ⊲ Fetches global blur (βr− (pji ), ..., βr− (pji )), ..., βr− (pdi )) ← βr− (pi )) prblur ← (βr− (pi ) − cs ri + rg ) mod P, ∀j ∈ [1, d] ji rblur pi ← (prblur , ..., prblur , ..., prblur ) 1i ji di Ct ← get random clients(t) ⊲ Randomly selectes set of t clients Send2ClientsCt (ci , prblur ) i ⊲ Sends pair of arguments to Ct h Store(ci , ξsk (ri )) ⊲ Stores encrypted personalized blur return end procedure Fig. 7. Procedure invoked by SamaritanCloud to redistribute reblurred profile of ci Without loss of generality, let us assume that a client ci has blurred profile information of t other clients cj , ∀j ∈ [1, t]. SamaritanCloud builds a set (Siq ) of t 6-tuples (Tjq ) and sends it to ci , Fig.9. 1st and 2nd entries of Tjq are the address of cq and cj , 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: procedure R EQUEST(pq ) rq ← get rand() ⊲ Randomly generates personalized blur (pq1 , ..., pqj , ..., pqd ) ← pq βr+q (pqj ) ← (pqj + rq ) mod P, ∀j ∈ [1, d] βr+q (pq ) ← (βr+q (pq1 ), ..., βr+q (pqj ), ..., βr+q (pqd )) h ξsk (rq ) ← (rq · sk) mod P h ξsk (tol) ← (tol · sk) mod P ⊲ Encrypts tolerance value h h Send2Cloud(ξsk (rq ), ξsk (tol), βr+q (pq )) ⊲ Sends arguments to SamaritanCloud return end procedure Fig. 8. Procedure invoked by a requesting client to compute set of nearneighbors respectively. 1 Tjq = cq 2 Tjq = cj 3rd entry is built by reblurring the blurred profile of cq , with the clients-specific blur assigned to cq and the global blur, as follows. 3 Tljq = (βr+q (pql ) + cs rq + rg ) = (pql q +r + cs q g r +r ) mod P, ∀j ∈ [1, t] mod P, (4) where 3 Tljq is lth dimension of 3rd entry of Tjq , cs rq is client specific blur of cq and rg is the global blur. SamaritanCloud adds encrypted personalized random blur of cq and cj to build 4th entry of the tuple. This is where we use additive homorphic nature of encryption scheme. 4 h h Tjq = (ξsk (rq ) + ξsk (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, the individual value of either cs rq or cs rj is not leaked by this entry. 5 q Tj = (cs rq + cs rj ) mod P (6) 6th entry is the encrypted tolerance value sent by cq . This tolerance value is used in the near-neighbor computation. 6 h Tjq = ξsk (tol) (7) e) Distance-Computation: In this phase, Fig.11, 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 Siq . Let us also assume that ci has blurred profile informations of t clients, cj , ∀j ∈ [1, t]. Let Tji ∈ Siq be the tuple corresponding to cj and prblur be the reblurred profile j of cj . Since, ci has the shared secret sk, it decrypts the encrypted 6 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: h h procedure R EDIST REQ((ξsk (rq ), ξsk (tol), βr+q (pq ))) for all ci ∈ C do rg ← f etch global blur() ⊲ Fetches global blur cs q r ← f etch cs blur(cq ) ⊲ Fetches client-specific blur for ci q + cs q g prblur ← (β (p q r j j ) + r + r ) mod P, ∀j ∈ [1, d] rblur rblur rblur p ← (p1 , ..., pj , ..., prblur ) d Ci ← f etch clients in(ci ) ⊲ Set of clients whose blurred profile is stored by ci Siq ← φ for all cj ∈ Ci do 1 q Tj ← c q 2 q Tj ← c j 3 q Tj ← prblur h ξsk (rj ) ← f etch encrypted blur(cj ) ⊲ Encrypted personalized blur of cj h h 4 q Tj ← (ξsk (rq ) + ξsk (rj )) mod P cs rj ← f etch cs blur(cj ) ⊲ Client specific blur of cj 5 q Tj ← (cs rq + cs rj ) mod P 6 q h Tj ← ξsk (tol) q 1 q 2 q 3 q 4 q 5 q 6 q Tj ← ( Tj , Tj , Tj , Tj , Tj , Tj ) Siq ← Si ∪ Tjq end for Send2Client(ci , Siq ) ⊲ Sends Siq to client ci return end for end procedure Fig. 9. Procedure invoked by SamaritanCloud to delegate nearness computation to clients blur and tolerance value in Tji . ci sends clients whose reblurred profile satisfies the following condition to cq . ( d X h 4 i h 6 i (3 Tlji − prblur − δsk ( Tlj ) −5 Tlji )2 )1/2 < δsk ( Tlj ), (8) j l=1 h where δsk (·) decrypts given cipher data using key sk. 2) Correctness: 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. Lemma 1. Given, Tjq is the tuple corresponding to cj and prblur is the blurred profile of cj j ( d X h 4 q (3 Tijq − prblur − δsk ( Tij ) −5 Tijq )2 )1/2 = kpq − pj k j Fig. 10. Request process in SamaritanCloud system h Since, ξsk (·) is an additive homorphic encryption, from equation (5), 4 h h Tjq = (ξsk (rq ) + ξsk (rj )) = h ξsk (rq + rj ) mod P mod P So, h 4 q h h δsk ( Tj ) = δsk (ξsk (rq + rj ) q = (r + rj ) mod P ) mod P (10) So, combining equations (4), (6), (9), and (10), h 4 q (3 Tijq − prblur − δsk ( Tij ) −5 Tijq ) j = ((pqi + rq + cs rq + rg ) mod P − (pij − rj − cs rj + rg ) mod P − (rq + rj ) mod P − (cs rq + cs rj ) = (pqi − pij ) mod P ) mod P Thus, according to the definition, ( d X h 4 q (3 Tijq − prblur − δsk ( Tij ) −5 Tijq )2 )1/2 j i=1 =( d X ((pqi − pij )2 )1/2 ) mod P i=1 q = kp − pj k i=1 Proof: As described in ProfileUpdate protocol, blurred profile stored on SamaritanCloud is calculated using equation (2). prblur = (pij − rj − cs rj + rg ) mod P (9) ij 3) Security: A client ci has access to reblurred profile data of set of other t clients cj , j ∈ [1, t]. The client ci does not know profile data of any of cj clients, as all the profile data are blurred with random blurs unknown to ci . Attacks on 7 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: procedure D ISTANCE COMP(S) Sc = φ ⊲ Set of clients matching requested profile for all T ∈ S do (cq , cj , 3 Tjq , 4 Tjq , 5 Tjq , 6 Tjq ) ← T prblur ← f etch blur prof ile(cj ) j ⊲ Blurred profile of cj kpq − pj k ← Pd h 4 q ( i=1 (3 Tjq −prblur −δsk ( Tj )−5 Tjq )2 )1/2 j ⊲ Distance between profiles of cq and cj q h 6 q if kp − pi k < δsk ( Tj ) then h ξsk (cj ) ← (cj · sk) modP h Sc ← Sc ∪ ξsk (cj ) end if Send2Client(cq , Sc ) ⊲ Sends the set of near-neighbors to cq end for return end procedure both the protocol and the shared secret key(sk). According to our proposed system, a client has access to reblurred profile of t other clients. Since, for internal attacks, attackers behave as clients, an adversary ai has access to blurred profile data of t other clients ci , i ∈ [1, t]. Some of these t clients are adversaries. There are two types of internal attacks as follows, • – reblurred requested-profile data of the querying adversary (aq ) to all other clients. Thus an adversary (ai ) receives requested profile blurred with personalized blur, client-specific blur of the querying adversary and the global blur rg , equation (4). Assuming aq informs ai about personalized blur (rq ), and requested profile (pq ), ai computes (cs rq +rg ) mod P successfully. Profile data of a client ci is blurred with its own client-specific (cs ri ) and the global blur. So, ai can successfully compute blurred profile (pji −ri ) mod P of a client ci , if cs rq = cs ri , equation (2). Since, all the blurs are selected randomly from [0, P ), Fig. 11. Procedure invoked by clients to compute near-neighbor of requested profile SamaritanCloud are averted by the use of different types of blurs. Here we state the effect of different blurs on the security of the overall SamaritanCloud system, a) Personalized blur: Personalized blur is a random number used by every client to blur their original profile information. Since, this blur is randomly selected by clients, SamaritanCloud cannot gain knowledge from blurred profile about the profile data of a client. b) Client-specific and global blur: Both client-specific and global blurs are randomly generated by SamaritanCloud. These blurs are used by the cloud to reblur profile of a client. Clients do not have access to these blurs. Global blur along with client-specific blur are used to protect profile data from distributed attacks by a group of adversaries. We measure security of the proposed protocol with following metric, Probability of Information Leak per Comparison (PILC): PILC is defined as the probability of an advesary successfully computing the profile data of a client by single comparison between reblurred profile of the client and that of an adversary. Now, we state different kinds of possible attacks as follows, External attack: In external attack, attackers know protocol of SamaritanCloud, but do not know the shared secret key(sk). Every profile data is blurred with above mentioned blurs. Since, blurs are random numbers, it is impossible for external attackers, without the knowledge of blurs used, to extract profile information from the blurred profile data. Also, clients send personalized blurs to SamaritanCloud encrypted with a shared key. The shared key is known only to clients. Thus, blurred profile together with encrypted blurs avert external attacks. Internal attack: For internal attack, the assumptions are much more strict than external attack. Here, attackers know Active attack: An adversary sends a help request to SamaritanCloud. The intention of the help request is to assist other advesaries to compute random blurs and thereby assisting them to successfully retrieve profile information of a good client. We know that, an adversary ai has profile information of a client ci blurred with personalized blur, client-specific blur of ci and the global blur, equation (2). When SamaritanCloud receives the fake help request, it broadcasts following three informations to all clients, P r[ai knows (pji − ri ) mod P ] = 1 P – the addition of client-specific blur of aq and ci as in equation (6). Since, both the blurs are random numbers unknown to clients, this addition does not reveal individual value of each blur. – encrypted value of the addition of the personalized blur of aq and ci as shown in equation (5). ai knows the personlaized blur of aq , as all the advesaries share information. Thus, ai computes ri mod P successfully. Thus, 1 (11) P ILC = P • Passive Attack: An adversary (ai ) can launch a passive attack if it has access to reblurred profile of another adversary aj , equation (2). Let us assume that ai knows the reblurred profile of a client ci . Since, all adversaries share informations, ai knows the blurred profile of aj . If clientspecific blur of aj is same as that of ci , ai can compute blurred profile of ci ((pji − ri ) mod P ), equation (2). Since, reblurred profile of a client is randomly distributed among t clients with least number of reblurred profile of 8 other clients, P r[ai has reblurred prof ile of aj ] u−1 t = 1 − (1 − ) n loglogn (u − 1) · loglogn , [Since, t = [24]] ≈ n · logk logk Since, personalized and client-specific blurs are randomly selected from [0, P ), P r[aj knows client specif ic blur of ci ] = P r[ai knows personalized blur of ci ] = So, P ILC = (u − 1) · loglogn 1 2 ·( ) n · logk P 1 P 1 P (12) Since, P is chosen to be a large prime number, probability of a successful attack is small both in active (equation (11)) and passive (equation (12)) internal attacks. III. E XPERIMENTAL E VALUATION A. Implementation The implementation of SamaritanCloud includes two parts — client side application and the cloud. We implemented the client side application with a prototype mobile application running on iOS 5.0, allowing users to, • log in or register with unique username and password. • choose time interval to update profile; by setting a fixed update time interval, exact profile change time is not exposed to the cloud. • input request location (either latitude and longitude coordinates or zipcode) and request content. • get notification when the client is close to a requested location; respond with willingness to offer help. • get notification if anyone offers help to the client’s request. • get follow-up questionnaire of (1) “did you offer the help that you committed to?” if the client was a candidate, (2) “was the request resolved?” if the client was the requester. We implemented the server using the Python Twisted library. The major concerns of SamaritanCloud performance are client application battery consumption and server scalability. We examine those two concerns with experimental results. B. Mobile application We first examine SamaritanCloud on mobile devices. Our application registers itself as a background VoIP service allowing it to maintain a persistent connection with the server, periodically fetch location information, even if the application is running in background. Our application utilizes Core Location Framework to get physical location. Location coordinates can be obtained through standard location service, and significant-change location service. With standard location service, location data is gathered with either cell triangulation, Wi-Fi hotspots 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 as per the interval defined by clients. With significant-change location service, a location update is triggered by the OS only if a device moves from one cell tower to another, thus providing only coarse location update. There is an accuracy-power tradeoff – GPS location update is accurate but power inefficient while significant-change location service is less accurate and low on power usage. To test the worst possible impact of our application on battery life, we run the applications always in foreground with intensive update (once per minute) via both 3G and WiFi. In each update, the mobile application fetches location coordinates (lat, lon), computes ((lat + r) mod P, (lon + r) mod P ) (P is a prime with 64 bits, r is randomly chosen between [0, P)), sends the result h together with ξsk (r) to the server. The encryption function used is as follows, h ξsk (r) = (r · sk) mod P (13) where, sk is a 512bit key. The results in Table II show that the impact on battery life is acceptable (in real world deployment the application would run in background with infrequent location updates). TABLE II I MPACT OF S AMARITAN C LOUD I OS APPLICATION ON BATTERY LIFE . network 3G WiFi standard (GPS) 10h 11h 14mins standard (WiFi/cellular) 12h 8mins 16h 14mins significant-change location service 12h 10mins 16h 1) Key distrubution: Each client-side application is provided with a long term 1024bit secret key (lk). This key is used to encrypt the secret key sk, equation (13). The shared secret key, sk, is changed every one hour. At the start of each hour, SamaritanCloud randomly selects a client. The selected client, randomly generates the shared secret key, encrypts it with lk as follows, and sends it to SamaritanCloud ξlk (sk) = (sk · lk) mod P SamaritanCloud broadcasts the encrypted shared secret, to all clients. C. Server scalability For server side performance we are primarily interested in understanding the rate of requests that a single server can handle, as this serves as the dominating factor controlling the number of online users that the server can support. In P rof ileU pdate phase, a client sends its blurred profile and SamaritanCloud distributes the blurred profile among t clients having least number of profiles of other clients. Since, SamaritanCloud can distribute in parallel, the runtime of P rof ileU pdate is O(1). In HelpRequest phase, the requesting client sends blurred requested profile along with encrypted tolerance value to the cloud. SamaritanCloud broadcasts these informations among all available clients. Clients compute the distance between 9 requested profile and other stored profile data. Broadcast to clients take O(1) time. Time taken to compute distance between a pair is O(d), because a profile has d dimensions. Since, each client has k number of profile data of other clients, it takes O(d · k) time for a client to determine set of nearneighbors. Since, blurred profile data of a client is distributed among t clients having least number of profile data of other clients, k = loglogn [24]. logt For experimental purpose we consider plain-text mode, where P rof ileU pdate O(1) HelpRequest ) O(d · loglogn logt 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. R EFERENCES TABLE III RUNTIME OF DIFFERENT PHASES OF S AMARITAN C LOUD no profile information is blurred and all communications are un-encrypted. We compared latency of a help request in plaintext mode with that of the proposed protocol. Latency, Fig.12, is measured starting from the moment the requester sends out blurred attributes to the time he gets response from the server. We ran our server implementation on a machine with 2.5 GHz Intel Core i5 and 4GB memory. To minimize the affect of Internet speed, we simulated clients on another machine on the same LAN. The main takeaways 1 n=10k, d=10 n=20k, d=10 n=30k, d=10 n=10k, d=100 n=20k, d=100 n=30k, d=100 Latency (s) 0.8 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] 0.6 0.4 [13] 0.2 [14] 0 0 100 200 300 400 500 Number of requests per second Fig. 12. Matching time measurement: plain-text(red) vs. encrypted message(green) are that using plain-text messages has the benefit of fast query processing but leaks client privacy to the server; communication with encrypted messages preserves client privacy, while the query processing is expensive. When using plain-text messages, query latency nearly remains the same when request rate increases; server scalability depends on the number of live TCP connections (open files) allowed on the machine. In the normal encrypted mode, for n=20k query processing is not fast enough when request rate exceeds 200/second. To prevent congestion each client can send one valid request only every 5 minutes. With this request rate, the server can handle 30,000 live clients simultaneously. IV. C ONCLUSION 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 [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] “Strangers helping strangers,” http://www.facebook.com/SHStrangers. “Yelp,” http://www.yelp.com/. “Facebook places,” http://www.facebook.com/facebookplaces. “Gowalla,” http://gowalla.com/. “Foursquare,” https://foursquare.com/. D. Stackpole, “Dynamic geosocial networking,” Patent US 2008/0 140 650 A1, 06 12, 2008. Q. Huang and Y. Liu, “On geo-social network services,” Geoinformatics, 2009. A. Cooper and T. Hardie, “Geopriv: creating building blocks for managing location privacy on the internet,” IETF Journal, 2002. G. Myles, A. Friday, and N. Davies, “Preserving privacy in environments with location-based applications,” Pervasive Computing, IEEE, 2003. H. Kido, Y. Yanagisawa, and T. Satoh, “An anonymous communication technique using dummies for location-based services,” in Proceedings of IEEE International Conference on Pervasive Service, 2005. A. R. Beresford and F. Stajano, “Location privacy in pervasive computing,” IEEE Pervasive Computing, 2003. K. P. Tang, P. Keyani, J. Fogarty, and 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. M. Gruteser and X. Liu, “Protecting privacy in continuous locationtracking applications,” IEEE security and privacy, 2004. M. Duckham and L. Kulik, “A formal model of obfuscation and negotiation for location privacy,” Pervasive, 2005. M. Gruteser and D. Grunwald, “Anonymous usage of location-based services through spatial and temporal cloacking,” in Proceedings of the International Conference on MobiSys, 2003. B. Gedik and L. Liu, “A customizable k-anonymity model for protecting location privacy,” in Proceeding of the International Conference on Distributed Computing Systems, 2005. M. F. Mokbel, C.-Y. Chow, and W. G. Aref, “The new casper: a privacy-aware location-based database server,” IEEE 23rd International Conference on Data Engineering, 2007. J. I. Hong and J. A. Landay, “An architecture for privacy-sensitive ubiquitous computing,” in Proceedings of the International Conference on Mobile Systems, 2004. S. Goldwasser and 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, ser. STOC ’82. ACM, 1982. T. Elgamal, “A public key cryptosystem and a signature scheme based on discrete logarithms,” Information Theory, IEEE Transactions on, vol. 31, no. 4, pp. 469 – 472, jul 1985. C. Gentry, “Fully homomorphic encryption using ideal lattices,” in Proceedings of the 41st annual ACM symposium on Theory of computing, ser. STOC ’09. ACM, 2009. K. Lauter, M. Naehrig, and V. Vaikuntanathan, “Can homomorphic encryption be practical?” in Proceedings of the 3rd ACM workshop on Cloud computing security workshop, ser. CCSW ’11. ACM, 2011. C. Raiciu and D. S. Rosenblum, “Enabling confidentiality in contentbased publish/subscribe infrastructures,” Securecomm and Workshops, 2006. R. S. Michael Mitzenmacher, Andrea W. Richa, “The power of two random choices: A survey of techniques and results,” in Handbook of Randomized Computing. Kluwer, 2000, pp. 255–312.