Master’s Project Report

SEG: Secure Enhanced Geolocking

Ashish A Korpe

A ProjectSubmitted to the Graduate School Faculty of the

University of Colorado Colorado SpringsIn Partial Fulfilment of the Requirements

For the Degree of Master of Science in Computer ScienceDepartment of Computer Science

Fall 2015

i

This project for the Master of Science in Computer Science degree byAshish A Korpe

Has been approved for theDepartment of Computer Science

By

__________________________________________________________________________________Dr. C. Edward Chow Date

__________________________________________________________________________________ Dr. Jia Rao Date

__________________________________________________________________________________ Dr. Jonathan Ventura Date

ii

Abstract

This project aims at improving the geolocking technique proposed by Denning et al [1] by providing tools for specifying and enforcing the designated reception geolocation area and encrypting data with web cryptography standard. Location is chosen to restrict access since the area can now be specified uniquely and be verified with enough precision. This type of security services can have good applications in areas like military, health care, and academics to provide enhanced security and privacy based on additional geolocation context information. A web app was developed to allow users to specify the restrictive geolocation area using google maps geocoding API and providing user interface to specify the corner points of the area. Javascripts and server side PHP scripts are developed to convert the geocoding information into Keyhole Markup Language (KML) representation. Javascripts with Web Crypto API was integrated in this web app to allow the author to specify the key and data to be encrypted with AES standard. The encrypted data, the receiver’s identify information including email, and geolocation area information are sent over to a web server. The web server will notify the receiver with an email which is embedded with geolocation where the receiver can receive the encrypted data. When clicking on the email attachment with KML-geolocation area, the receiver can observe it with Google earth. On receiving the receiver’s retrieving request, the web server will check the provided GPS location and provide the encrypted data only if it is within the geolocation area. The performance evaluation of our secure enhanced geolocking system showed the responses are fast enough for practical use both on the authoring and delivering.

iii

Acknowledgement:

I would like to take this opportunity to express my deepest gratitude to my advisor Dr. Edward Chow, for his excellent guidance, patience and for giving me the opportunity to work on this project. I admire his devotion and his expertise in problem solving. (He has answered my emails even at 4 in the morning!) I thank him for all the support and constructive feedback, which pushed me to keep improving on my work. His insights into the project helped a lot.

I would also like to thank my committee members Dr. Jia Rao and Dr. Jonathan Ventura for their enthusiasm, feedback and guidance.

I dedicate this project to my parents Sharda and Anil Korpe, my cousin Kunal Bele and my uncle Dr. Nagendra Bele. Pursuing Masters in Computer Science would never have been a reality for me without the constant love, support and inspiration from these wonderful folks!

Many thanks go to my family members and friends for their constant support, encouragement and putting up with me on my grumpiest days. A special vote of thanks to my cousins Prasann Handigund and Girish Hukkeri for their pointers. A fist bump to peers and roommates without whom, life would not have had the life it has!

iv

Table of Contents1. Introduction.....................................................................................................................................6

1.1 Motivation...................................................................................................................................6

1.2 Goal of the Project.......................................................................................................................6

2. Background and Prior work...........................................................................................................7

3. Design................................................................................................................................................9

4. Implementation..............................................................................................................................12

4.1 Overview...................................................................................................................................12

4.2 Implementation details...............................................................................................................12

A Sender side components...........................................................................................................13

B Receiver side components........................................................................................................13

4.3 Challenges faced in this project.................................................................................................14

5. Performance Evaluation of SEG System.....................................................................................23

5.1 SEGS Testbed............................................................................................................................23

5.2 Test Results:..............................................................................................................................23

5.3 Performance Analysis:...............................................................................................................24

6. Lessons Learnt...............................................................................................................................25

7. Future Work..................................................................................................................................27

8. Conclusion......................................................................................................................................30

9. References:.....................................................................................................................................31

Appendix A: Configuration and Installation of SEG System...............................................................32

Appendix B: Demonstration Steps of SEG System.............................................................................35

A. Sender.....................................................................................................................................35

B Receiver...................................................................................................................................38

v

1. Introduction In a world bursting with ever increasing information, hacking and gaining illegal access to

important information is on the rise. In the digital age, one could be looted based on the information they let out. Security of information has thus gained additional importance these days. Much research is being carried out where parameters like time, location, velocity are being considered and used to complement the conventional methods of providing security. One of the important research areas being carried out today is providing security by restricting access to important documents based on the location of the user trying to access it, i.e., location based secure access. Several strategies have been proposed which inculcated the idea of using location as a means to ensure secure access. One strategy is to encrypt the data based on the geolocation of the intended receivers with the option of including their credentials. The other strategy is to verify the source of the access and ensure that the request is coming from specific areas designated as secure or reliable even before the data is delivered. In the former strategy, the encrypted data can be distributed ahead of time while in the latter, the data will not be delivered unless the locations of the receivers are validated and are within the specified ranges at specified locations. In either case, the capability for verifying the authenticity of location is critical. The latter strategy has been followed for this project.

1.1 MotivationThe conventional methods of providing security using cryptography do a pretty good job.

However, with the increase in computational power of the machines and devices we use in our day to day lives and due memory getting cheaper, the conventional methods are now being seen as vulnerable to attacks. The attackers now have abundant memory and greater computational power to work around the conventional techniques of cryptography. Even popular methods like secure email are prone to attacks. Hence, newer methods which use parameters like time, location and velocity need to be incorporated along with the conventional techniques of cryptography.

Denning et al [1] provide a solid example of loss of revenue faced by the movie industry due to piracy. When movie goers get free access to movies, they do not turn up to the movie theatres to see movies. This results in the distributors facing loss of revenue. Hence a system which ensures that only authorized people get the access to concerned data and that only confined to a particular location is needed.

Similarly, military strategies getting leaked to civilians is not good. The security of the entire country would be at stake. Again, a robust system which prevents unauthorized access by any means is welcome.

1.2 Goal of the ProjectThe goal of the project could be shortly summarized as follows: “Develop a robust web

system which provides secure access to authorized personnel only and uses conventional cryptography and location coordinates to achieve this”. The intended purpose is to encrypt the data based on the intended receiver’s location. The system should provide access only for specific location and not let even authorized users access files in location outside of the specified region.

1

2. Background and Prior workA significant amount of work has been done on this front by. Denning et al. They have gained

the patent for “System and Method for Delivering Encrypted Information in a Communication Network Using Location Identity and Key Tables” [1]. Their work details the ideology of location based encryption and decryption of files in order to overcome the many problems faced by the conventional cryptographic methods [2]. In the paper “Geo Location Based RSA Encryption Technique”, [3] the authors Khan, Patil and Bhanarkar show the possible shortcomings in using conventional cryptographic methods like RSA for including location as a key component. The main applications of “location based secure access” as mentioned by the authors Scott and Denning are in digital cinema distribution and secure GPS [1].

The authors V. Rajeshwari, V. Murali and A.V.S Anil discuss an application in military [8] where the firing of missiles could be done only from a specific position. Authors Abolghasemi, Sefidab and Atani have discussed applying geo encryption technology in cloud computing to provide better security to cloud based environments and applications in the paper [10]. We are not dealing with cloud based computing here. Research is also being carried out on applying geo-fencing in an energy efficient manner [9]. Bareth proposes a novel way to implement privacy by exploiting signals broadcasted from cellular radio network infrastructure at that location. We are trying to implement privacy through an additional layer of cryptography irrespective of the positioning technology used (GPS/ cellular network/Wi-Fi/Cell-Id). The authors Namiot and Sneps put forth the idea of replacing geo data with network proximity [7] where, they try to replace the need of using GPS all the time by using Wi-Fi scanning and thus making location services energy efficient.

The authors Denning et al. for the above mentioned patent [1] have specified the use of a central server for same applications like digital cinema. In this project, we are trying to implement the ideology of location based access where the owner of a file/document can provide access to this document based on the receiver’s location. Here, the proposed implementation assumes users having the app on their smartphones and a central server. The server will store the file sent and validate the receiver of the location he should be in/at to access the file. This system has been implemented by GeoCodexTM in June 2010 for the windows platform using the LBED (Location based Encryption Decryption) technology. GeoCodexTM claim that their application works successfully [5] [6].For their Windows phone web app named SAGE, GeoCodex make use of a secure Bluetooth connection between the smartphone a PC [7]. In SAGE, the server sends out two keys: one for the PC and other for the Windows smartphone. The key sent to the smartphone is encrypted with constraints on location and time to access the key. The user of the smartphone is supposed to access the key in the specified location and time and decrypt the key, send it to the PC using a secure Bluetooth connection and then access the encrypted file using the decrypted key. If the key for the smartphone is not accessed in the specified location and time frame, it cannot be decrypted. In SEG, we use only one key which is stored on the database. The key is accessible to the receiver only after his location is verified against the specified location. The other significant difference between SEG and SAGE is that SEG has the constraint of location only whereas SAGE has constraints of both time and location. In SAGE, the PC stores the file to be accessed so the smartphone has to be in a close proximity to the PC to access the file. In SEG, the file is stored on the server and the receiver has to get his location verified against the location specified by the sender and only then he can access the file from that location. In other words, SAGE binds the smartphone and the PC, whereas SEG compels the receiver to access the encrypted file only from the specified location.

This project builds up on the research paper “Location Based Encryption and its Role in Digital Cinema Distribution” [1] proposed by Denning et al. ‘Geolocking’ refers to the process of locking a file by means of encrypting it and providing decryption and access capabilities to specific users based solely on their geolocation. The distributors of movies can use ‘geolocking’ by restricting the access

2

to the movie files so that the movie file will be accessible only in the area of the movie theatre. ‘Geolocking’ can effectively ensure that the files will not be accessed out the designated area, thus curbing piracy. Similarly, critical military commands and related intelligences should be accessible only to personnel in the military operating at a military base and not elsewhere to prevent leakage of critical warfare information as suggested by V. Rajeshwari, V. Murali and A.V.S Anil in "A Navel Approach to Identify Geo-Encryption with GPS and Different Parameters (Locations And Time)."[2]

Important information regarding a patient’s health and the procedures he/she has undergone can be confined to the doctors or medical staffs in hospital premises only. Similarly, for academia, important student identity and performance information can be confined to the campus of a school/university to preserve the privacy of the students.

3

3. Design This project implements a web system called Secure Enhanced Geolocking (SEG) System with tools implementing geolocking feature and encrypting data AES standards. The outcome is a robust system where a sender can encrypt a file, choose a location for the receiver to access the file in and send it across to the receiver via an email notification. The encrypted file and related geolocation area are sent to a web server. The receiver will receive an email giving the following details:

a. Senderb. File namec. Address to access the filed. A link to access the file ande. An attachment (KML file) to facilitate viewing the precise area where the file can be

decrypted and accessed

The receiver is then expected to go to the address in the email and then use the link in the email to access the file. The receiver is then compelled to provide the current location to the web server which will verify if the receiver’s provided geolocation lies in the specified accessible area and provide the key to decrypt the file accordingly. If the receiver is not in the geolocation area, the web server does not provide the key or the data.

The SEG system has been built using HTML5, CSS, JavaScript and PHP technologies. The Database used is Maria DB.

4

Figure 1 gives an overview of the components in the SEG system.

5

akorpe.csnet.uccs.edu

2

3

2

3

6

Credentials

Table

Files

Table

Login / Register webpage

Compose webpage

Inbox

Webpage

Validate Position Webpage

Final result Webpage

Sender Receiver

Maria DB

Database

1

Menu

WebpageEmail

4

Figure 1: SEG Design

5

6

1

4

5

6

The website akorpe.csnet.uccs.edu hosts a Maria DB database ‘ProjectAshish’. This database has two tables viz. Credentials – holds the registered users’ details and Files – holds the details of the file sent by the sender in an encrypted form, receiver’s address, address to access the file and the location to access the file in.

The website also hosts a login page, a register page, a menu page and a compose page. Once the user has logged in or has registered with his email and password, the website takes him to a menu page. The sender can then open the compose web page and provide input which is stored in the ‘Files’ database by the compose web page and an email is sent to the receiver.

The Receiver opens the email and clicks on the link to open the inbox web page. The inbox web page takes the receiver to a validate position webpage. This validate position webpage sends a query to the ‘Files’ table and extracts location and file information. After this is done, it takes the receiver’s current location coordinates and compares them with the location coordinates it gets from the ‘Files’ table. Depending on the outcome of this comparison, the validate position webpage generates a final result webpage which is displayed to the receiver.

7

4. Implementation

4.1 OverviewThe SEG system consists of the following components:

1. Web forms to register and login.

2. Web page to compose the outgoing message to the receiver.

3. A web page generated (inbox.php) after the receiver clicks on the link in the email. It has a button on it which when clicked, gets the receiver’s location coordinates and takes the receiver to another webpage (validateLocation.php). Web pages that get generated out of scripts based on the outcome of certain conditions.

4. The webpage validateLocation.php has a space allocated for a map and on it. This webpage queries the database, gets the data file data and compares the receiver’s coordinates against those specified by the sender. Based on the outcome of this comparison, validateLocation.php displays:

a. A fresh webpage with a text message and a button to decrypt the file and see the contents. This webpage also shows a small map on which the accessible location and the receiver’s current location are shown.

b. A fresh webpage with an error message and a small map on which the accessible location and the receiver’s current location are shown.

4.2 Implementation details

HTML5 and JavaScript handle the front end processing of the system while PHP version 5.6.12 handles the sender’s inputs and operations with the Maria database on the server.

CSS 3.0 is used to tidy up the display of the components. JavaScript are used in conjunction with HTML5 for handling button click events. Here are the important libraries used in the SEG system:

o Crypto JS: JavaScript implementation of secure and standard cryptographic algorithms. For encrypting and decrypting the files, AES encryption has been used [12].

o Xml libraries for creation of kml files. Geocoder API has been used to translate string address like ‘1420 Austin Bluffs Parkway,

Colorado Springs CO 80918’ to a format usable by Geolocation API to draw a map of the corresponding region [8].

Geolocation API has been used to determine receiver’s current location, pinpoint the receiver’s most accurate location on a map using a marker and to draw a polygon to show the file-accessible area [9] [10].

KML is used to give the receiver a clear picture of the region he/she can access the file in [11].

Maria DB (version 10.0.21) database has been used to store the following information:o Credentials of the registered users.o The details of the file/s sent across by the sender.

The following screen shots give a clear picture of the tables and their structure in the database

8

Credentials table:

Files table:

A Sender side componentsa. Login Page

b. Compose page

c. Email and Storage script

B Receiver side componentsa. Email with text, link and attachment

b. Web pages with buttons, maps and textarea (inbox.php, validateLocation.php)

9

4.3 Challenges faced in this project“Race of hurdles”

There were a lot of challenges during the development of the project.

Geolocation uses four techniques for determining location:

a) a GPSb) b Wi-Fic) c Cell Phone triangulationd) d IP addresses

The technique used by geolocation at any instant of time depends on various factors like device being used, Internet availability, etc. While working on this project, I came across peculiar phenomena with functionality of geolocation. While carrying out testing of my code, I came to know a significant amount about geolocation and mapping of location coordinates to IP addresses.

Following are the challenges faced while working on this project:

1. Untrustworthiness of latitude and longitude based on IP address: While working on the project I relied heavily on IP address and Wi-Fi methods to determine location. (Testing was done using google chrome browser Version 46.0.2490.86 m)These methods can sometimes generate very weird results where the current location marker appears to be shifting its place after regular intervals of time. This illustrates the fact that Wi-Fi and IP addresses can sometimes take longer intervals of time to provide accurate information. If asked for location information in between, they may provide information that is a ‘little off’ from the supposed location.

I conducted a simple experiment to determine this. I created a simple web page using JavaScript and HTML5 to compute the latitude-longitude coordinates and display a marker at my current location on a map. I did three trial runs and captured the screen shots of the results.

Here is the source code for the experiment:

HTML code:

<!doctype html><html><head><title>Wherever you go, there you are</title><meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1"><meta charset="utf-8"><script src="http://maps.google.com/maps/api/js?sensor=false"></script><script src="myLoc.js"></script><link rel="stylesheet" href="myLoc.css"></head><body>

<div id="location">Your location will go here.</div>

<div id="map">

10

</div>

</body></html>

JavaScript code:

var map = null;window.onload = getMyLocation;function getMyLocation() {

if (navigator.geolocation) {navigator.geolocation.getCurrentPosition(

displayLocation, displayError,{enableHighAccuracy: true, timeout:9000});

}else {

alert("Geolocation not supported");}

}

function displayLocation(position) {var latitude = position.coords.latitude;var longitude = position.coords.longitude;

var div = document.getElementById("location");div.innerHTML = "You are at Latitude: " + latitude + ", Longitude: " + longitude;div.innerHTML += " (with " + position.coords.accuracy + " meters accuracy)";

if (map == null) {showMap(position.coords);

}

function showMap(coords) {var googleLatAndLong = new google.maps.LatLng(coords.latitude,

coords.longitude);var mapOptions = {

zoom: 10,center: googleLatAndLong,mapTypeId: google.maps.MapTypeId.ROADMAP

};var mapDiv = document.getElementById("map");map = new google.maps.Map(mapDiv, mapOptions);

var title = "Your Location";var content = "You are here: " + coords.latitude + ", " + coords.longitude;addMarker(map, googleLatAndLong, title, content);

}

function addMarker(map, latlong, title, content) {var markerOptions = {

position: latlong,

11

map: map,title: title,clickable: true

};var marker = new google.maps.Marker(markerOptions);

var infoWindowOptions = {content: content,position: latlong

};

var infoWindow = new google.maps.InfoWindow(infoWindowOptions);google.maps.event.addListener(marker, 'click', function() {

infoWindow.open(map);});

}

function displayError(error) {var errorTypes = {

0: "Unknown error",1: "Permission denied",2: "Position is not available",3: "Request timeout"

};var errorMessage = errorTypes[error.code];if (error.code == 0 || error.code == 2) {

errorMessage = errorMessage + " " + error.message;}var div = document.getElementById("location");div.innerHTML = errorMessage;

}

CSS code:

body {font-family: Arial, Helvetica, sans-serif;margin: 10px;

}form, div#location, div#distance {

padding: 5px;}

div#map {margin: 5px;width: 400px;height: 400px;border: 1px solid black;

}

12

Result - Run 1:

Result - Run 2:

13

Result - Run 3:

As seen from the images above, the values of latitude and longitude change for every run and accordingly the marker shifts its position thus illustrating that current location detection system is not accurate.

2. Inaccurate mapping of latitude, longitude based on IP address: Since the IP address method of getting location information uses an external database with mapping of IP addresses to physical location, there is a great scope for human error. As a result, some IP addresses may be mapped to locations that are situated away from the supposed location. It is very difficult, if not impossible to rectify these mappings to get accurate results.

3. There were many other insignificant challenges faced like accessing the database, being unable to write/create a file in a directory on the server, etc.

4. One of the common errors seen on the web is the ‘500 – server error’. The server throws this error when it cannot exactly locate the cause of the error. We encountered this error and narrowed it down to a syntax error in one of the PHP scripts. We found this out on checking the error log files on the server. Similarly, the script responsible for sending email to the receiver would not work due to a syntax error.

5. The other significant challenge faced was with the email script which needed a differentiator between the html link and the attachment file in the body of the email.

Following is the php code used to create the header and body of the email to be sent:

$file = $path.$filename; $file_size = filesize($file); $file_type = filetype($file); $handle = fopen($file, "r"); $content = fread($handle, $file_size); fclose($handle); $content = chunk_split(base64_encode($content)); $name = basename($file); $boundary = md5(uniqid(time()));

14

$header = "MIME-Version: 1.0\r\n"; $header .= "From: ".$from_mail."\r\n"; $header .= "Content-Type: multipart/mixed; boundary=$boundary\r\n\r\n";

$body = "--$boundary\r\n"; $body .= "Content-type:text/plain; charset=ISO-8859-1\r\n"; $body .= "Content-Transfer-Encoding: 7bit\r\n\r\n"; $body .= $message."\r\n\r\n";

$body .= "--$boundary\r\n"; $body .= "Content-type:text/html; charset=utf-8\r\n"; $body .= "Content-Transfer-Encoding: 7bit\r\n\r\n"; $body .= $link."\r\n\r\n";

$body .= "--$boundary\r\n"; $body .="Content-Type: $file_type; name=\"$filename\"\r\n"; $body .="Content-Disposition: attachment; filename=\"$filename\"\r\n"; $body .= "Content-Transfer-Encoding: base64\r\n"; $body. ="X-Attachment-Id: ".rand(1000, 99999)."\r\n\r\n"; // ***imp step

$body. = $content."\r\n\r\n";

The problem was that in the email sent with the attachment, some part of the beginning of the attached file would get clipped off, which rendered the attachment unusable. (The problematic line of code has been underlined). This one was difficult to debug given that google email worked fine even with the underlined line absent in the code, while other email carriers (yahoomail, rediffmail and outlook) faced problems. Adding this line helped to get rid of the bug.

The following shows the clipped off KML file and the error in google earth when it tries to read such a clipped file.

/www.opengis.net/kml/2.2"> xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom"><Document><Folder><name>uccs</name><visibility>0</visibility><description>uccs</description><Placemark><name>uccs</name><visibility>0</visibility><Style><LineStyle><width>1.5</width></LineStyle><PolyStyle><color>7d00ff00</color></PolyStyle></Style><Polygon><extrude>1</extrude><altitudeMode>relativeToGround</altitudeMode><outerBoundaryIs><LinearRing>

15

<coordinates>-104.800456,38.893279,10 -104.801261,38.892761,10 -104.799941,38.891893,10 -104.799303,38.892557,10 -104.800456,38.893279</coordinates></LinearRing></outerBoundaryIs></Polygon></Placemark></Folder></Document></kml>

Error in google earth on opening the faulty attached file.

16

The following shows contents of a good KML file:

<?xml version="1.0" encoding="UTF-8"?><kml xmlns ="http://www.opengis.net/kml/2.2"> xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom"><Document><Folder><name>uccs</name><visibility>0</visibility><description>uccs</description><Placemark><name>uccs</name><visibility>0</visibility><Style><LineStyle><width>1.5</width></LineStyle><PolyStyle><color>7d00ff00</color></PolyStyle></Style><Polygon><extrude>1</extrude><altitudeMode>relativeToGround</altitudeMode><outerBoundaryIs><LinearRing><coordinates>-104.800456,38.893279,10 -104.801261,38.892761,10 -104.799941,38.891893,10 -104.799303,38.892557,10 -104.800456,38.893279</coordinates></LinearRing></outerBoundaryIs></Polygon></Placemark></Folder></Document></kml>

The code in green font is the content of the .kml file getting clipped off earlier.

6. Other challenge was enabling the receiver to access the file using his credentials. This was overcome using the code below:

$plaintext_receiver = $mailto.'receiver';//changing 'cyber' to 'receiver'$key_receiver = hash('sha256', 'GeolockFiles', true);$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);$ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key_receiver,$plaintext_receiver, MCRYPT_MODE_CBC, $iv);$ciphertext = $iv.$ciphertext;$ciphertext_base64 = urlencode(base64_encode($ciphertext));

$link="Please click <a href=\"http://$domain/inbox.php?email=$mailto&emailfrom=$my_mail&token=$ciphertext_base64\"> this link </a> to access the

17

file.";

In the PHP code above, we use a plaintext string, generate an initialization vector and use the key, plaintext and the initialization vector to generate a ciphertext. We further use this along with the receiver’s email to form a link. This link is sent as a part of the email to the receiver to access the file sent by the sender. This link is further processed and upon decryption, we compare the receiver’s email address with the outcome of the decryption process. We allow the receiver to proceed further only if the two values are same.

7. Validation of receiver’s location within the accessible region was another challenge. The first approach followed was to cross check the receiver’s latitude-longitude using a custom developed trivial method. The sender would be asked to input the location coordinates in an anticlockwise manner when selecting the accessible location to form the 4 vertices of the access polygon. The location coordinates would be stored in an array. Once the receiver tried to verify his location, the web page would derive the latitude-longitude pair of the receiver using Geolocation API. Then using a few comparisons for both the latitude and longitude against the latitude longitude of the 4 vertices from the stored array, we could determine if the receiver was within the accessible region or outside.

This method, though easy to implement was trivial in nature, would work on the client side only, keeping the server unknown. To overcome this, we used the ‘Point in polygon method’ [3]. This method eliminated the need of choosing location coordinates in an anticlockwise manner. A few complex computations would be done in this method to determine if the receiver was inside the file-accessible polygon. This method though sophisticated, had the same issue as earlier method. This worked on the client side while the server had to rely on the results of the client side comparison.

To bring the server into the picture, we finally used the ‘Find point in polygon’ method [4]. This method comprises of comparisons of the receiver’s latitude and longitude with those of the polygon indicated by the sender. The advantage of using this method is that the validation takes place on the server and the sender need not point the polygon vertices in an anticlockwise fashion.

Following is the related code snippet:

function is_in_polygon($points_polygon, $vertices_x, $vertices_y, $longitude_x, $latitude_y){ $i = $j = $c = 0; for ($i = 0, $j = $points_polygon-1 ; $i < $points_polygon; $j =

$i++) {if ( (($vertices_y[$i] > $latitude_y != ($vertices_y[$j] >

$latitude_y)) &&($longitude_x < ($vertices_x[$j] - $vertices_x[$i]) *

($latitude_y - $vertices_y[$i]) / ($vertices_y[$j] - $vertices_y[$i]) + $vertices_x[$i]) ) ) $c = !$c;

} return $c;}

18

5. Performance Evaluation of SEG System

5.1 SEGS Testbed The Test Driven Development approach was followed for this project. Test cases were written

first and the compiled code was tested against it.

The environment used for testing (localhost) is as follows:

Windows 7 home basic machine running Wamp server version 2.5.

The database used was MySQL version 5.6.17

Database server: MySQL Community Server (GPL) 5.6.17

Web server: Apache/2.4.9 (Win32)

Once the system worked fine on localhost, the code was migrated to akorpe.csnet.uccs.edu

The production environment (akorpe.csnet.uccs.edu) is described below:

VM running Fedora Core FC22 operating system.

The database used is Maria DB version 10.0.21

Database server: Maria DB 10.0.21

Web server: Apache/2.4.16 (Fedora)

5.2 Test Results:The system worked well on both localhost as well as on the production environments. Users

were able to register their emails and login using the registered credentials.

Senders were able to encrypt the desired file from their machine and specify the area the file should be accessed in by pinpointing on the map. The system gave a confirmation of the email sent.

Receivers were able to see the email from the server sent on behalf of the sender. The email consisted of sender’s email, the sent filename, the address designated by the sender to access the file, a link to access the file and an attached KML file (accessible_location.kml) to visualize the area to access the file in.

Receivers were able to open the .kml file in google earth. The link to access the file produced a web page with a button to verify the receiver’s location. The server then took over and compared the receiver’s location against the accessible region and accordingly generated a final web page:

i) With a button to decrypt and access the file if the location was ok. (When the button was clicked, the server would decrypt the file using the key and display the contents of the file in a textarea on the same web page) or

ii) With an error message indicating that the receiver was not within location and he should refer the kml file again to see the accessible location.

The final web page also had a map which showed the accessible area and the receiver’s current location by a marker. If the marker was clicked on, it opened a small window which showed the receiver’s current location coordinates.

19

20

5.3 Performance Analysis:The following section shows the performance of the system in terms of time taken by the server for its operation.

Time taken to compose the email message and send the email: 1-5 second

Time taken by the server after the link is clicked from the email to access the file:

i) If the receiver is in correct location: 10-40 millisecond

ii) If the receiver is not in correct location: 1-5 millisecond

These figures suggest that the SEG system takes little time to get the necessary work done. It works well and this system is suitable for practical usage.

21

6. Lessons Learnt“Executing a project is futile if it doesn’t teach you something new”

While working on this project, I came to know a lot about web development. I learnt HTML5, CSS 3 JavaScript and PHP 5 from scratch. Interfacing with Geolocation and Geocoder API taught me various cool features like tracing a current location, marking a current location, drawing a polygon across the given points or location coordinates on a map and so on.

Moreover, I learnt debugging code on both front and back ends enabling me to develop robust code.

This being a research project, I came across peculiar phenomena with functionality of geolocation. While carrying out testing of my code, I came to know a significant amount about geolocation and mapping of location coordinates to IP addresses.

Geolocation API uses a variety of methods to determine location like GPS, IP address, Cell Phone triangulation and Wi-Fi. We cannot exactly figure out which method is being currently used at any instant of time.

GPS: This depends on the satellites to provide extremely accurate location information, but is taxing on the batteries.

IP addresses: This method uses an external database where the IP address for a particular location is mapped to its physical location. This is believed to work almost anywhere, but is not trusted as being reliable.

Cell Phone triangulation: This method relies on nearby cell phone towers for its location information. It works well indoors as well unlike GPS but it depends on the number of cell phone towers in the vicinity.

Wi-Fi: Wi-Fi uses one or more Wi-Fi access points to get the location information. It works well indoors as well, is fast and is believed to be very accurate.

Following are my findings on geolocation:

1. Untrustworthiness of latitude, longitude based on IP address.

While working on the project I relied heavily on IP address and Wi-Fi methods to determine location. These methods can sometimes generate very weird results where the current location marker appears to be shifting its place after regular intervals of time. This illustrates the fact that Wi-Fi and IP addresses can sometimes take longer intervals of time to provide accurate information. If asked for location information in between, they may provide information that is a ‘little off’ from the supposed location.

2. Inaccurate mapping of latitude, longitude based on IP address.

Since the IP address method of getting location information uses an external database with mapping of IP addresses to physical location, there is a great scope for human error. As a result, some IP addresses may be mapped to locations that are situated away from the supposed location. It is very difficult, if not impossible to rectify these mappings to get accurate results.

3. Insight into functioning of Geolocation API, Geocoder API, and KML files.

Geolocation API, Geocoder API and KML all are cool technologies which provide a developer with a great bunch of capabilities while working with maps. Using geolocation, one can not only find his/her current location, but also put a marker on a map. Complex stuff like drawing a polygon or a rectangle is made easy by Geolocation API. Additional capabilities include making the boundaries of the

22

thick/thin as desired, controlling the opacity of the polygon, etc. Moreover, one can create an infoWindow which shows the current location coordinates like latitude and longitude.

Geocoder API is an excellent technology which changes an address into a format usable by Geolocation API to draw a map and vice versa. This enables a developer to get location coordinates of almost any location with a valid address on the globe and in turn get a valid address from just the location coordinates.

KML or Keyhole Markup Language is another powerful tool developed by Google Inc. This allows us to display geographic data in a browser like Google Earth and Google Maps using different types of placemarks, markup and highlighted icons, ground overlays, paths and polygons. One can even put up pictures on the globe in Google Earth taken at that particular location. I used KML to generate a file with an Extruded polygon to display the area where the receiver can access the encrypted file.

23

7. Future Work“Nothing is perfect in this world, there is always scope for improvement”

1. After a significant amount of development had been done, I came across the fact that IP addresses can be spoofed. A user sitting at location ‘X’ could use IP addresses that enable him to depict that he is at location ‘Y’. Similarly, while testing the code on browser, I realized that any desired location could be emulated i.e. once we have latitude and longitude coordinates of a desired location, we can use those to emulate that location. Following is a screen shot showing the same in google chrome:

Emulation of latitude, longitude in google chrome

Upon further research, I came across many apps which enable users to spoof any location they want on the globe.

This seriously hampers the motivation of this project. This project relies heavily on the accuracy of the receiver’s location to enable him to access the sent encrypted file. Spoofing or emulating location coordinates enables the receiver’s browser/device to pose like being in the file- access permissible area while not being actually present in the area.

Hence the future work on this project is mainly validating if the user’s location determined is accurate and legitimate. It needs to be ensured that the location specified by the receiver is not a spoofed one. In order to validate the user’s location, a combination of techniques like Wi-Fi, IP addresses, GPS and latitude, longitude could be used. Location coordinates calculated using one technique could be cross checked with those computed using a different technique.

2. Another scope for future work is to run a background service to check if the device has any location spoofing application installed. As far as emulation on browsers on stationary PCs is concerned, detection of emulation is difficult. Hence potential work could include differentiating between emulated location coordinates and genuine ones.

This project currently enables display of only text files sent via encryption. A future enhancement would be displaying different types of files like pdf, jpeg, etc.

3. Another enhancement would be sending multiple files via encryption. This project currently supports sending one file. Making the app more user friendly: currently SEG supports quadrilateral

24

shaped polygons (4 vertices) to mark the file-accessible region. A future enhancement would be to be able to work with other shapes as well e.g. a triangular or circular region.

4. In the present scenario, the sender just marks 4 vertices of a polygon to specify the file-accessible region. A possible future enhancement would be giving the sender an ability to mark lines or shapes on the map to specify the file-accessible region.

25

8. ConclusionIn an age where even small vulnerabilities may lead to major economic and/or informational

loss, security has gained a lot of importance. One of the major techniques of providing security is the use cryptography.

As the computing power of machines/devices increases, even the best of cryptographic techniques are now vulnerable to attacks. Hence, to enhance security, it is needed that two or more parameters or techniques be used in conjunction, making it difficult for the attackers to break. In this project, an effort has been made to encompass the location parameter in addition to cryptography to provide better data security.

This project provides a head-start in the direction of using unique physical phenomena like location and time to further enhance the conventional techniques of cryptography.

A working SEG system was developed with responsive geolocking authoring and delivering feature. It was observed that the performance of the system is capable of providing adequate response and data protection features. SEG takes 40 - 50 milliseconds to send an email, store the file data and the file-accessible location coordinates on the database, while it takes 10 - 20 milliseconds to decrypt the file and display if the receiver is in the file-accessible region and 1 – 10 milliseconds to display the error message if the receiver is not in the file-accessible region.

26

9. References:

[1] Scott, L. and Denning, D. E. “Location Based Encryption and its Role in Digital Cinema Distribution,” ION GPS/GNSS 2003, September 9-12, Portland

[2] Rajeswari, V., V. Murali, and A. V. S. Anil. "A Navel Approach to Identify Geo-Encryption with GPS and Different Parameters (Locations And Time)." IJCSIT) International Journal of Computer Science and Information Technologies 3.4 (2012).

[3] https://github.com/tparkin/Google-Maps-Point-in-Polygon

[4] http://stackoverflow.com/questions/5065039/find-point-in-polygon-php/5065219#5065219

[5] Location-Based Encryption / Decryption (L-BED) WHITE PAPER GeoCodex, LLC June 2010

[6] http://www.geocodex.com/

[7] http://www.geocodex.com/technology/smartphone-application-for-geo-encription

[8] https://developers.google.com/maps/documentation/geocoding/intro

[9] https://developers.google.com/maps/documentation/javascript/examples/polygon-arrays

[10] Chapter 5 - “Head First HTML5 Programming” by Eric Freeman and Elisabeth Robson

[11] https://kml-samples.googlecode.com/svn/trunk/interactive/index.html#./Polygons/Polygons.Extruded.kml

[12] https://code.google.com/p/crypto-js/

27

Appendix A: Configuration and Installation of SEG System

The following are the steps to be followed to install and configure the web system in this project:

1. Download the source code from http://walrus.uccs.edu/~gsc/pub/master/akorpe/src/

2. Extract the contents of the compressed file

3. Use Bitvise SSH Client to connect to akorpe.csnet.uccs.edu

a. Use ‘root’ as username and ‘#cs00net$’ as password

Bitvise client window

b. Go to the path /var/www/html/ashish

28

c. Upload the source code files from the extracted folder to ‘/var/www/html/ashish’ directory as shown below.

The var/www/html/ashish

4. Access the Maria DB database using the link:  http://akorpe.csnet.uccs.edu/phpmyadmin/

5. Create a new database ‘projectAshish’ and two tables viz. ‘files’ and ‘credentials’ in the newly created database. Use the structure as shown in the images below:

Structure of the table ‘credentials’

29

Structure of the ‘Files’ table

30

Appendix B: Demonstration Steps of SEG SystemA. Sender5. Open a new window on browser and go to akorpe.csnet.uccs.edu/ashish. This will open the index page.

Index page

6. Click on the ‘Register’ button and input the user details. The system shows a confirmation of successful registration.

Register screen

31

Registration confirmation screen

7. Login using the registered credentials and click on the link to go to Menu.

Menu screen

8. Click the ‘Compose’ button to compose a new message, i.e. encrypt a file and send.

9. Input the receiver’s email address in first text box, choose the file to encrypt, input the key to use for

10. Input a very specific address in the textbox against ‘Location’ e.g. “Engineering building, 1420, Austin Bluffs parkway, Colorado Springs CO 80918” and click on the ‘Show Map’ button

11. The web page will be populated with a map. Navigate to the desired location on the map using the zoom in and zoom out controls. Once the desired area is in focus, click on the ‘Access Boundaries’ button.

12. Click (4 points) on the map at the points surrounding the desired location (with a polygon around the desired location in mind) and encryption .Click the ‘Encrypt the file & key and Send!’ button.

32

Compose screen

33

13. The web page provides a confirmation message showing that the file-key pair and the location information was sent to the receiver.

Email confirmation screen

14. The system also shows a ‘Back to Menu’ button, which enables to go back to menu and either compose another message or logout.

B Receiver15. The receiver opens his email and finds the sender’s info along with an attached .kml file (accessible_location.kml) which when opened in Google earth shows the accessible region specified by the sender. In order to see the region, check the ‘Temporary Places’ check box.

34

Received email

Kml file opened in google earth

16. Click on the link provided in the email to access the file. The system will now show a ‘Verify My Location!’ button.

Link to access the encrypted file

35

Inbox page

17. Click the button.

a. If the receiver is in the accessible region, the web page is populated with a message confirming that the receiver is in correct location and should click the ‘Decrypt the file’ button to access the file.

Contents of the encrypted file

36

b. If the receiver is not in the accessible region, the web page is populated with a message ‘You are not in the file - accessible location. Refer the attached google earth file to go the specified location and try again’.

Receiver not in the file-accessible location

In any case, the web page also shows a map with the accessible region (denoted in a red polygon) and the current location of the receiver (denoted by a marker). Clicking on the marker brings up an info window which shows the current latitude and longitude of the receiver’s location.

37