Keywords

12.1 Introduction

The smartphones and other wireless devices like tablets and PDA have tremendously grown in the last decade in terms of computation capability and variety of application and services they can support. Location-based services (LBS) is one such application which has gained huge popularity over the recent years; LBS has been powered by the advances in location-enabling technologies like Global Positioning System (GPS), cell tower-based identification, Internet Protocol (IP) address approximation, and Wi-Fi triangulation. Latest survey reveals that LBS is most popular among the users of social networking applications [6] such as geotagging of photos and videos, check-ins, directory services for nearby places, friend finder, etc. LBS application can be categorized into three main types:

  1. 1.

    Point-of-Interest based (PoI)

  2. 2.

    Friend-Finding (FF)

  3. 3.

    People-Discovery (PD)

PoI applications are used by users to locate nearest places like ATMs, bus station, restaurants, etc. Family and friends can be tracked or located using friend-finder applications; people-discovery applications are useful in case of locating and interacting with new people who are total strangers.

Users using LBS applications are forced to provide access to their location information to the application service provider in order to access the service; this compromises the user’s location privacy. Major challenge in LBS application is to preserve the user’s location privacy.

12.2 Related Work

The main focus of our paper is to address the problem of location proximity, i.e., dealing with the problem of computing whether user ′A′ is at a certain distance from user ′B′ or not; the major challenge here is to preserve the user location information of both user ′A′ and ′B′ private to each other and the service provider and just reveal only the proximity and not the actual distance between user ′A′ and ′B′.

Disclosing only the proximity rather than the distance between user ′A′ and ′B′ helps in preventing external attacks like triangulation effectively. Class of solutions which uses proximity-based approach are referred to as privacy-preserving location-proximity (PPLP) [1, 2, 5, 6, 8,9,10, 12] protocols. There are several ways in which we can achieve location privacy. Several researchers have used k-anonymity [4, 11], where there exist a set of users and the location of the user is indistinguishable. These solutions focus mainly on hiding the identity of the user rather than location coordinates.

In this paper we try to readdress the issue of location privacy in proximity-based services proposed by Muhammad N. Sakib and Chin-Tser Huang in [7]. We retain the elliptic curve-based proximity test solution provided in [7] and try to make it more efficient.

Contributions

Our contributions in this paper are as follows:

  • We propose an algorithm and steps to sanitize the GPS coordinates to eliminate false negatives for location proximity.

  • We reduce communication and computation cost by eliminating the unnecessary message exchanges suggested by authors in [7].

  • We suggest steps to share private key among the communicating parties within the proximity range without incurring overhead.

12.3 Background

12.3.1 Testing Proximity of Users by GPS Coordinates Matching

GPS coordinates are a pair of signed floating-point numbers (±x, ±y) which represents latitude and longitude values of the location on the surface of the earth. Say we take two real location values, say L A (13.3268, 77.126) and L B (13.3267, 77.1180), by looking at the values we can clearly see that there is partial match among the location coordinates, indicating proximity among the coordinates. Refer to Table 12.1 for details about precision values and proximity range.

Table 12.1 Various precision values and corresponding distance ranges
Full size table

12.3.2 Distance Calculation Using GPS Coordinates

We can make use of the following equation to compute the distance between two location coordinates in kilometers.

$$\displaystyle \begin{aligned} \begin{array}{rcl} {} \text{Distance} &\displaystyle =&\displaystyle \text{acos(cos(radians}(90-\text{lat1}))*\text{cos(radians(90}-\text{lat2))}\\ &\displaystyle &\displaystyle +\text{sin(radians(90}-\text{lat1}))*\text{sin(radians(90}-\text{lon2))}\\ &\displaystyle &\displaystyle \quad *\,\text{cos(radians(lat1}-\text{lat2)))}\,*\,6371 \end{array} \end{aligned} $$
(12.1)

Example: distance between say L A (13.3268, 77.126) and L B (13.3267, 77.1180) using Eq. (12.1) is 876 m.

12.3.3 Elliptic Curve Basics

Elliptic curve cryptography is a public key cryptosystem. Generally, an elliptic curve is defined over a finite field consisting of finite points satisfying the below equation:

$$\displaystyle \begin{aligned} y^2 = x^3 + ax + b \end{aligned} $$
(12.2)

The equation will be defined over a large finite field denoted by prime number P. Elliptic curve contains numerous points satisfying the elliptic curve along with a special point called point at infinity (Θ).

The following operations are possible on an elliptic curve:

  • Point addition: adding two points on the curve results in a third point which satisfies the curve.

  • Point multiplication: multiplying a point on the curve with a scalar (integer) value results in a point which satisfies the curve (i.e., repeated addition of given point, also referred to as point doubling).

12.4 Proposed Work

In this section we revisit the proposed work of Muhammad N. Sakib and Chin-Tser Huang in [7] and propose an algorithm to minimize the false negative results of the existing solution and to reduce the communication and computation overhead for proximity test plus suggest an improvement of private key exchange. The proposed work is as shown in Fig. 12.1 and is divided into two parts:

Fig. 12.1
figure 1

Proximity test and ECDHE private key exchange between Alice and Bob

Full size image
  1. 1.

    Proximity test

  2. 2.

    ECDHE private key exchange

Algorithm-1

Sanitization of GPS coordinates

Purpose:

Avoids false negatives by sanitizing GPS coordinates

Input:

Latitude or longitude value in floating-point format ± abc.xyz

Output:

Latitude or longitude value in floating-point format ± abc.000 or ± abd.000 or ± abc.xyz

Steps:

 

if

′xyz′ == ′99 ∗′ (* indicate any digit between 0 and 9)

return:

± abd.000 (where |abd = abc + 1|)

else if

′xyz′ == ′00 ∗′

return:

± abc.000

else

 

return:

± abc.xyz

12.4.1 Proximity Test

12.4.1.1 Decimal Precision Agreement (Optional)

To begin with, Alice and Bob can agree upon a decimal precision value based upon their proximity search requirement; this is an optional step; we can avoid this if the default value for decimal precision value r is set (generally we use r = 2).

12.4.1.2 Sanitization of GPS Coordinates

Sanitization of GPS coordinates is done at both ends of communication, i.e., Alice and Bob sanitize their coordinates independently using the agreed precision value r and r − 1 using Algorithm-1, e.g., if the agreed precision value r = 2, then the coordinate value L A (13.3268, 77.126) becomes L A (13.32, 77.12), since elliptic curves do not deal with floating points, we convert it to whole number by removing decimal points. Final coordinates after sanitization will be L A (1332, 7712) for r = 2 and L A (133, 771) for precision r − 1 = 1.

At Bob’s end we introduce additional sanitization steps for precision r − 1 = 1 as follows:

  • case 1: L B (x, y − 1) i.e., (original,low)

  • case 2: L B (x, y + 1) i.e., (original,high)

  • case 3: L B (x − 1, y) i.e., (low,original)

  • case 4: L B (x + 1, y) i.e., (high,original)

  • case 5: L B (x − 1, y − 1) i.e., (low,low)

  • case 6: L B (x − 1, y + 1) i.e., (low,high)

  • case 7: L B (x + 1, y − 1) i.e., (high,low)

  • case 8: L B (x + 1, y + 1) i.e., (high,high)

For example, L B (133, 771) for precision r − 1 = 1 becomes as follows:

  • case 1: L B (133, 770)

  • case 2: L B (133, 772)

  • case 3: L B (132, 771)

  • case 4: L B (134, 771)

  • case 5: L B (132, 770)

  • case 6: L B (132, 772)

  • case 7: L B (134, 770)

  • case 8: L B (134, 772)

12.4.1.3 Elliptic Curve Generation

Using Eq. (12.2), coefficient a, large prime number p, and sanitized values, Alice generates elliptic curves for precision value r and r − 1 as follows:

$$\displaystyle \begin{aligned} b_i = (y^{2}_{i} - x^{3}_{i} - ax_{i})~\text{mod}~p \end{aligned} $$
(12.3)

Alice then forwards the curve parameters p, a, b r , and b r−1 to Bob.

12.4.1.4 Elliptic Curve Evaluation

Bob upon receiving the elliptic curve parameters p, a, b r , and b r−1 verifies his sanitized value L b (x b , y b ) with precision r by substituting values into Eq. (12.2). Upon successful verification, he replies back with a positive result, else he continues with verification with precision r − 1 by substituting values into Eq. (12.2). If the test is successful, he replies back with a positive result, else he continues with verification of L b (x b , y b  − 1), L b (x b , y b  + 1), L b (x b  − 1, y b ), L b (x b  + 1, y b ), L b (x b  − 1, y b  − 1), L b (x b  − 1, y b  + 1), L b (x b  + 1, y b  − 1), and L b (x b  + 1, y b  + 1) by substituting values into Eq. (12.2), one set of coordinates at a time in case of success, he replies back with a positive result and discontinues the test. If no match found, he replies back with negative result. These test results are sufficient for proximity testing.

We demonstrate our technique using sample values as follows:

Alice

Bob

L a (37.295, 28.135)

L b (37.321, 28.138)

Sanitize L a using default precision r = 2 and r − 1 = 1

Sanitize L a using default precision r = 2 and r − 1 = 1

L a (3729, 2813) for r = 2 and L a (372, 281) for r − 1 = 1

L b (3732, 2813) for r = 2 and L b (373, 281) for r − 1 = 1

a = 5 and P = 1, 000, 003 in Eq. (12.3)

 

for r = 2 b 2 = 660, 373

 

for r = 1 b 1 = 598, 409

 

send a = 5, P = 1, 000, 003, b 2 = 660, 373 and b 1 = 598, 409

 
 

Substitute a = 5, P = 1, 000, 003, b 2 = 660, 373, L b (3732, 2813) in Eq. (12.2) and evaluate the curve

 

912, 948≢162, 264 (indicates curve does not satisfy)

 

Substitute a = 5, P = 1, 000, 003, b 1 = 598, 409, L b (373, 281) in Eq. (12.2) and evaluate the curve

 

78, 961≢495, 235 (indicates curve does not satisfy)

 

Our proposed extension

 

Case 1: substitute a = 5, P = 1, 000, 003, b 1 = 598, 409, L b (373, 280) in Eq. (12.2) and evaluate the curve

 

78, 400≢495, 235 (indicates curve does not satisfy)

 

Case 2: substitute a = 5, P = 1, 000, 003, b 1 = 598, 409, L b (373, 282) in Eq. (12.2) and evaluate the curve

 

79, 524≢495, 235 (indicates curve does not satisfy)

 

Case 3: substitute a = 5, P = 1, 000, 003, b 1 = 598, 409, L b (372, 281) in Eq. (12.2) and evaluate the curve

 

78, 961 ≡ 78, 961 (indicates curve values satisfied for precision 1 for case 3)

a = 5, P = 1, 000, 003, b 1 = 598, 409, L a (372, 281) in Eq. (12.2)

Send positive result for precision value 1

78, 961 ≡ 78, 961

Same value at both ends indicate proximity for precision value 1

12.4.2 ECDHE Private Key (Symmetric Key) Exchange

In [7] they have proposed additional steps of ECDHE for verification of location proximity which we feel is an unnecessary burden; instead the same can be used for symmetric key exchange between Alice and Bob. ECDHE symmetric key exchange steps are as follows:

Alice:

  • Selects a secret value K a randomly

  • Computes M a  = K a  ∗ L a using the verified curve and sanitized coordinate L a

  • Sends M a to Bob

Bob:

  • Selects a secret value K b randomly

  • Computes M b  = K b  ∗ L b using the verified curve and sanitized coordinate L b

  • Sends M b to Alice (similar to Alice)

Alice:

  • Receives M b from Bob

  • Computes N a  = K a  ∗ M b  = K a  ∗ K b  ∗ L b

  • Uses N a as symmetric key

Bob:

  • Receives M a from Alice

  • Computes N b  = K b  ∗ M a  = K b  ∗ K a  ∗ L a

  • Uses N b as symmetric key (N a  = N b if all steps are correct)

Repeat the above steps with different random secrets to arrive at a different secret key when required.

12.5 Security Analysis

Security of our work relies on the hardness of elliptic curve discrete log problem (ECDLP). Let M is point on the curve and k be a secret integer N = [k] ∗ M, given M and N it is hard to reveal k if the finite field value P is sufficiently large. Please refer [3] for more details about ECDLP.

Our paper has achieved the following four security goals which are listed below (interested readers can refer [7] for proofs and additional information):

  1. 1.

    Alice and Bob can perform proximity verification, in order to know if they are located in a certain distance range.

  2. 2.

    Either Alice or Bob cannot narrow down on each other’s single specific location information (i.e., region smaller than the Earth) if they are not in the proximity range. But they get to know they are not within the specified distance.

  3. 3.

    Either Alice or Bob cannot narrow down on each other’s single specific location information (i.e., region smaller than the Earth) if they are within the proximity range, except if they are in the eyesight distance.

  4. 4.

    None of the third party (intruder/communication server) can narrow down on single specific region smaller than the Earth where Alice or Bob is located.

Our desired goals are achieved using ECC and the hardness of elliptic curve discrete logarithm problem. Our protocol assumes that both Alice and Bob use the protocol to communicate only about their proximity information. If at all they want to share their location information for calculating distance, they can do so by first exchanging symmetric key using ECDHE private key exchange and exchanging the encrypted coordinates using the symmetric key.

12.6 Conclusion

In our paper we revisited the proposed work of Muhammad N. Sakib and Chin-Tser Huang in [7] and propose an algorithm to minimize the false negative results of the existing solution and to reduce the communication and computation overhead for proximity test plus suggest an improvement of symmetric key exchange for secure communication. Our contributions are as follows:

  • We proposed an algorithm plus additional steps to sanitize the GPS coordinates to eliminate false negatives for location proximity.

  • We reduced communication and computation cost by eliminating the unnecessary message exchanges suggested by the authors in [7].

  • We suggested an improvement to share symmetric key among the communicating parties within the proximity range without adding any overhead to the scheme.