Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019
Pedro Emanuel
Amaral Santos
RideShare: Provas de viagens em grupo para um
sistema de recompensas
RideShare: Trustworthy ridesharing evidences for a
rewarding system
“I am still learning.”
— Michelangelo Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática
2019
Pedro Emanuel
Amaral Santos
RideShare: Provas de viagens em grupo para um
sistema de recompensas
RideShare: Trustworthy ridesharing evidences for a
rewarding system
Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019
Pedro Emanuel
Amaral Santos
RideShare: Provas de viagens em grupo para um
sistema de recompensas
RideShare: Trustworthy ridesharing evidences for a
rewarding system
Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia de Computadores e Telemática, realizada sob a orientação científica do Doutor André Ventura Zúquete, Professor Auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro, e do Doutor João Paulo Silva Barraca, Professor Auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro.
o júri / the jury
presidente / president Prof. Doutor Joaquim Manuel Henriques de Sousa Pinto
professor auxiliar da Universidade de Aveiro
vogais / examiners committee Prof. Doutor Miguel Filipe Leitão Pardal
professor auxiliar da Universidade de Lisboa - Instituto Superior Técnico (arguente)
Prof. Doutor João Paulo Silva Barraca
agradecimentos /
acknowledgements sempre nas minhas decisões e sem o apoio deles ao longo destes anos não seriaAgradeço à minha família toda e em especial aos meus pais, pois me apoiam possível estar onde estou; à minha irmã por todos os momentos partilhados durante estes anos e por estar sempre pronta a ajudar-me.
Agradeço aos meus Professores orientadores de dissertação, ao Professor Doutor André Ventura Zúquete e ao Professor Doutor João Paulo Silva Barraca. Ambos foram fundamentais para a realização deste trabalho.
Agradeço à minha namorada, Xinyi Gao, não só pelos momentos memoráveis que vivemos, mas também por estar sempre ao meu lado, em especial nos momentos de mais trabalho e por apoiar-me nesses momentos.
Agradeço a todos os meus amigos que fiz durante este percurso, sem eles teria sido um percurso muito mais difícil. Para além dos momentos de descontração e de divertimento que também são muito importantes, mostram-se sempre disponíveis para me ajudar quando algum problema ou dificuldade aparece.
Palavras Chave provas de partilha de viagens, provas de partilha de carro, arquitetura de sistemas, aplicações móveis.
Resumo Muitas pessoas usam os seus carros privados para ir para os seus destinos, mas o uso dos carros privados poderia ser reduzido se as pessoas partilhassem o seu carro com outras pessoas.
Se as pessoas partilhassem o carro com outras que usam o carro privado, o número de carros a circular nas estradas diminuiria. Ao diminuir o número de carros nas estradas a poluição gerada é reduzida e o tráfego que existe diminui. Por isso, iria ser mais rápido ir do ponto A ao B, como também seria mais fácil estacionar o carro.
O objetivo desta dissertação é apresentar o design e a implementação de um sis-tema que recompensa as pessoas que partilham o seu carro com outras pessoas quando estas poderiam usar o seu carro pessoal. Os utilizadores para interagir com o sistema têm de ter uma aplicação móvel no telemóvel e o desenvolvimento desta aplicação também é apresentado neste trabalho.
Existem vários desafios no design e implementação de um sistema com este ob-jetivo. Estes desafios estão associados a como é possível garantir que as pessoas estão a partilhar o carro com outras pessoas que poderiam estar a usar o seu carro particular.
O sistema deve tentar garantir que os utilizadores estão num carro, para não ser possível recompensar o utilizador quando está a andar a pé, a andar de bicicleta, etc... O sistema deve tentar garantir saber quais são as pessoas que estão no veí-culo, para não ser possível, por exemplo uma pessoa ter vários telemóveis e simular que está a partilhar o carro com outras pessoas. O sistema deve tentar garantir que os utilizadores têm carta de condução e carro para não recompensar os utilizadores que não teriam a opção de usar o seu próprio carro.
A dissertação apresenta soluções para cada uma destes desafios e um sistema aonde é possível aumentar a dificuldade de enganar o sistema ao longo do tempo ao adicionar ou melhorar as soluções que foram desenvolvidas.
Keywords ridesharing evidences, carsharing evidences, system architecture, mobile applicati-ons.
Abstract A lot of people use their private cars to go to their destination, but the use of private cars could be reduced if people would share the ride with others.
If people would share the ride with others who use their private car, the number of cars circulating could diminish. By reducing the number of cars circulating, there would be less pollution, the traffic would diminish, making it faster to move from point A to B, and it would also be easier to park the car.
The objective of this dissertation is to present the design and implementation of a system, that rewards people when they share their private car with other people, that could use their private car. To interact with the system the users need to have a mobile application that it is also developed and presented in this work.
There are several challenges to design and implement a system with this objective. These challenges are associated with how it is possible to ensure that people are sharing their car with other people that could be using their car.
The system should try to ensure that the users are in a car, so that it does not reward users when they are riding a bicycle, walking or going on a train. The system should try to ensure who is inside the car, so that it is not possible for a user to carry several phones, and simulate that it is sharing the car with other people. The system should try to ensure the location of the users, so that it is not possible to simulate trips. The system should also try to ensure that they have a driving license, and a car to not rewarding users when they would not have the option of using their own car.
The dissertation presents solutions to each one of these challenges, and a system in which it is possible to increase the complexity of deceiving the system over time, by adding or improving the current solutions.
Contents
Contents i
List of Figures v
List of Tables vii
Glossary ix
1 Introduction 1
1.1 Context and Motivation . . . 1
1.2 Objectives . . . 1
1.3 Challenges . . . 2
1.4 Structure of the Dissertation . . . 2
2 Background and Related Work 5 2.1 Ride Share Applications . . . 5
2.1.1 Related Applications . . . 6
2.2 Ensure Absolute Location . . . 7
2.2.1 Review . . . 7 2.2.2 Summary . . . 13 2.3 Ensure Proximity . . . 13 2.3.1 Review . . . 14 2.3.2 Summary . . . 17 2.4 User Authentication . . . 18 2.4.1 Review . . . 18 2.4.2 Summary . . . 22
2.5 Trusted Execution Environment . . . 22
2.5.2 Summary . . . 25
2.6 Conclusion . . . 25
3 Scenarios and Requirements 27 3.1 Scenarios and Use cases . . . 27
3.1.1 Scenarios . . . 27 3.1.2 Use cases . . . 29 3.2 Requirements . . . 31 3.2.1 Functional Requirements . . . 31 3.2.2 Non-Functional Requirements . . . 34 3.3 Summary . . . 36
4 Architecture and Methodology 37 4.1 System Architecture . . . 37 4.1.1 Components Description . . . 37 4.1.2 Processes Workflow . . . 38 4.1.3 Architecture Principles . . . 40 4.2 Databases . . . 40 4.2.1 Relational Database . . . 41 4.2.2 Geographical Database . . . 42 4.2.3 NoSQL Database . . . 43 5 Related Technologies 47 5.1 Architecture styles and design patterns . . . 47
5.1.1 REST . . . 47
5.1.2 MicroServices Architecture . . . 49
5.1.3 Publisher-Subscriber pattern . . . 49
5.2 Technologies and Platforms . . . 50
5.2.1 MQTT - Protocol . . . 50
5.2.2 JWT . . . 51
5.2.3 Relational vs Non-Relational database . . . 51
5.2.4 OpenStreetMap . . . 52 5.2.5 Firebase . . . 52 5.2.6 Autenticação.Gov . . . 53 5.3 Android . . . 55 5.3.1 Building Blocks . . . 55 5.3.2 BLE . . . 56
5.3.3 Fused Location Provider API . . . 56
5.3.5 SafetyNet Attestation API . . . 57
6 Proposed Solution 59 6.1 Location Authentication . . . 59
6.2 Ensure Proximity . . . 59
6.3 Ensure that each person can have only one account . . . 60
6.4 Ensure the person who created the account is near the device when the trip happens 60 6.5 The user has a car and driving license . . . 60
6.6 Ensure that the user is in a vehicle . . . 60
7 Implementation - Server side 63 7.1 Components Description . . . 63
7.1.1 Reverse Proxy and Server Gateway . . . 65
7.1.2 MongoDB Database . . . 65
7.2 Workflow Description . . . 66
7.2.1 User Sign-up . . . 66
7.2.2 User Sign-in . . . 67
7.2.3 Create trip . . . 68
7.2.4 Generate QR code of the trip . . . 69
7.2.5 Join Trip . . . 70
7.2.6 Start trip . . . 71
7.2.7 Trip happening . . . 72
7.2.8 End/Exit Trip . . . 73
7.2.9 Chave Móvel Digital Authentication . . . 74
7.2.10 SafetyNet Attestation Verification . . . 76
7.3 Agents . . . 77
7.3.1 Redis Queue . . . 77
7.3.2 Agent - Insert Telemetry . . . 78
7.3.3 Agent - Generate Path Files . . . 78
7.3.4 Agent - Validate Trip . . . 79
7.4 Task - Validate Trip . . . 79
7.4.1 Algorithm - Sublist with weighted mean greater than or equal to a given value 80 7.4.2 Mock Locations Detection . . . 82
7.4.3 Train Detection . . . 82
7.4.4 Activities Detection . . . 85
7.4.5 Calculation of the Kilometers/Points . . . 86
8 Implementation - Client Side 91 8.1 Application Architecture . . . 91
8.2 WorkFlow Client Side Description . . . 92
8.2.1 User register/sign-in . . . 92
8.2.2 Menu . . . 93
8.2.3 Create Trip . . . 95
8.2.4 Join Trip . . . 97
8.2.5 Resume of the Trip . . . 99
8.2.6 Add passenger . . . 100
8.3 Features . . . 100
8.3.1 Chave Móvel Digital authentication . . . 100
8.3.2 Scan QR codes . . . 102
8.3.3 SafetyNet Attestation . . . 103
8.4 Services . . . 103
8.4.1 Main Service . . . 103
8.4.2 BLE Services . . . 104
8.4.3 Detect Activities Service . . . 105
8.4.4 Location Service . . . 105
8.4.5 Sensors Service . . . 105
9 Evaluation and Results 107 9.1 Calculation of the Kilometers . . . 108
9.1.1 Two users during all the trip . . . 108
9.1.2 Three users during all the trip . . . 109
9.1.3 Trip of a user entering in the middle, and exiting before the end of the trip . 109 9.1.4 Trip of a user entering in the middle of a trip . . . 111
9.1.5 Trip of a user entering in the middle of a trip, and another one leaving before the end of the trip . . . 112
9.2 Forgery Detection Algorithms . . . 114
9.2.1 Activity Detection . . . 114
9.2.2 Train Detection . . . 119
9.2.3 Bluetooth Low Energy . . . 122
9.3 Conclusion . . . 123
10 Conclusions and Future Work 125 10.1 Conclusions . . . 125
10.2 Future Work . . . 126
List of Figures
2.1 Security Extensions abstract model [38] . . . 24
3.1 UML Use case diagram . . . 30
3.2 Activity diagram . . . 31
4.1 Architecture Diagram . . . 37
4.2 Entity-Relationship Diagram of users relational Database . . . 42
4.3 Entity-Relationship Diagram of Geographical Database . . . 43
4.4 Entity-Relationship Diagram of NoSQL Database . . . 44
4.5 Logs Diagram . . . 45
5.1 Interaction of the different components in the Publisher-Subscriber pattern . . . 50
5.2 MQTT - Topic levels . . . 50
5.3 Workflow of the authentication using Autenticação.Gov . . . 55
5.4 Safety Net Workflow protocol [69] . . . 57
7.1 Architecture Diagram . . . 64
7.2 Sign up - Interactions Diagram . . . 66
7.3 Sign-in - Interactions Diagram . . . 68
7.4 Create Trip - Interactions Diagram . . . 68
7.5 QR code generation - Interactions Diagram . . . 70
7.6 Join Trip - Interactions Diagram . . . 70
7.7 Start trip - Interactions Diagram . . . 71
7.8 Trip happening - Interactions Diagram . . . 72
7.9 End/Exit Trip - Interactions Diagram . . . 73
7.10 Chave Móvel Digital authentication - Interactions Diagram . . . 74
7.11 SafetyNet Attestation - Interaction Diagram . . . 76
8.1 Application architecture . . . 91
8.2 Screenshots of the sign-in/register process . . . 92
8.3 Screenshots of the implementation of the different tabs of the menu . . . 94
8.4 Screenshot of the activity that presents the information about the last trips . . . 95
8.5 Screenshots from the application of the user that creates the trip . . . 95
8.6 Screenshots from the application of the user that joins the trip . . . 98
8.7 Screenshots from the application when trip ends . . . 99
8.8 Screenshots of the authentication with the Chave Móvel Digital in the application . . . . 100
9.1 Path of each one of the users in a trip that the third user entered in the middle and exit before the end of the trip . . . 110
9.2 Path of each one of the users in a trip that the third user entered in the middle . . . 111
9.3 Path of each one of the users in a trip that the user leaving in the middle is different from the one that joined. . . 113
9.4 Path of each one of the users in a trip using the train . . . 120
List of Tables
7.1 Comparation of processing times with and without preprocessing for the algorithm to find
the sublist . . . 81
7.2 Detected activities and their labels . . . 85
9.1 Results of the trip with two users . . . 109
9.2 Results of the trip with three users . . . 109
9.3 Results of the trip when the same user enters in the middle of a trip and leaves before the end of the trip . . . 110
9.4 Results of the trip when a user enters in the middle of a trip . . . 112
9.5 Results of the trip when a user enters in the middle of a trip and another one leaves before the end of the trip . . . 113
9.6 Results of the algorithm to analyse the segments length . . . 114
9.7 Results of the trips only walking . . . 115
9.8 Results of the trips only riding the bicycle . . . 116
9.9 Results of the trip when a user does forbidden activities during the trip . . . 118
9.10 Information about the average of the total kilometers and the total time of the trips done to analyse the train detection . . . 119
9.11 Results of the validation of the trip by changing the minimum readings and the intersection distance. . . 121
Glossary
AMA Agência para a ModernizaçãoAdministrativa
AP Acess Point
BLE Bluetooth Low Energy CMD Chave Móvel Digital CO Carbon Monoxide FCM Firebase Cloud Messaging
GNSS Global Navigation Satellite System GSM Global System for Mobile
Communications
HTTPS Hypertext Transfer Protocol Secure HTTP Hypertext Transfer Protocol ID Identifier
IMTT Instituto da Mobilidade e dos
Transportes Terrestres
JWE JSON Web Encryption JWS JSON Web Signature JWT JSON Web Token LoRa Long Range
MAC Media Access Control Address MNO Mobile Network Operator
MQTT Message Queuing Telemetry Transport NFC Near Field Communication
NIC Número de Identificação Civil
NIF Número de Identificação Fiscal NISS Número de Identificação da Segurança
Social
NOx Nitrogen Oxides
OEM Original Equipment Manufacturer PIN Personal Identification Number PKI Public Key Infrastructure RAM Random Access Memory
RDBMS Relational Database Management
System
REST Representational state transfer RFID Radio-Frequency IDentification RQ Redis Queue
SAML Security Assertion Markup Language SDK Software Development Kit
SSID Service Set Identifier SSL Secure Socket Layer
TCB Trusted Computing Hardware TEE Trusted Execution Environment ToA Time–of–Arrival
URI Uniform Resource Identifier UUID Universally Unique Identifier UWB Ultra-wideband
Chapter
1
Introduction
This chapter starts by describing the context and motivation of developing a system that rewards people when they share their private car with other people that could use their private car. The second part describes the main objectives of the work of this dissertation.
The third part explains the challenges of developing a system that rewards people when they share their private car with other people that could use their private car. Lastly, the structure of the dissertation is presented.
1.1 Context and Motivation
The pollution of the environment is a current problem and it must be addressed due to its negative effects on the Earth [1]. One of the factors that contributes to air pollution is the use of private cars [2]. Each day there are millions of cars circulating [3] and, with some effort from people, it would be possible to diminish this number considerably. But how can people be encouraged to do that? We live in an era where, in developed countries, a big part of the population has a smartphone, and most of the population is connected to the Internet [4]. With this in mind, it is possible to take advantage of this fact, and use technology to educate people, and incentivize them to have more sustainable habits.
One solution to diminish the use of private cars is to share the ride with other people, which may not only lead to the reduction of pollution levels but also help solve other issues. One of the main problems in big cities is the enormous quantity of cars that circulate on the roads, an even bigger issue during rush hours. This originates big queues and makes it hard and time consuming to travel from point A to B. If more people share rides, it can be easier and faster to travel by car, and to find a place to park it. Furthermore, when shared the ride with others, sharing the car can also transform the time that is spent in the car, allowing to build stronger friendships, by spending time with people while traveling by car.
1.2 Objectives
This dissertation has the goal of presenting the design and implementation of a system that rewards people when they share the ride with other people that could use their car.
The rewards are points that can be traded by discount vouchers or products. To be able to receive the points, participants should use their mobile phone with a mobile application installed. The application should also be developed also in this work.
The design system should be hard to deceive, so it should try to ensure that the people are sharing the car with others who could have used their own car.
The system should have the following properties:
• The system should be hard to deceive, and should try to ensure that the people are doing a legit trip.
• The system should be prepared to handle a big number of users, and be able to scale fast.
• The system should be prepared to handle changes in the requirements, and be easy to add new functionalities, or new algorithms to detect when a trip is not valid.
• The system should be designed to be easy and safe to use. It is centered on people’s mobile phone and it has to have a virtual wallet for each user.
1.3 Challenges
The development of this project is associated with a set of challenges. These challenges consist of proving if the users are in a car, who is inside the car, what is their location, and also if the users have a driving license and a car.
This application rewards people, so there will be interests in manipulating or cheating the system. For that reason, it is necessary to create a solution that it makes difficult to deceive the system.
It is necessary to ensure if the users are in a car because, without any measure to try to verify it, the users can simulate that they are sharing a car in several ways. It is necessary to authenticate the people who are inside the car for several reasons. One of the reasons is due to the fact that people can carry several phones and therefore they could simulate that they are sharing the car with somebody else to earn points; Another possible situation is that people can share their application account with other people, and simulate that they are sharing the car.
Lastly, people that don’t have a car or driving license can use their phones pretending that they were helping the environment, by abdicating to use their own car. However, they can’t be driving themselves, so it doesn’t make sense to give points in this situation.
For these reasons, it was necessary to develop a solution to try to ensure in the best possible way that the users are not trying to deceive the system to receive points dishonestly. The other problem is that it is necessary to ensure the location of people when they are using the application. People can try to forge their location and simulate trips to win free points. 1.4 Structure of the Dissertation
• Chapter 2 - Background and Related work: It can be divided in two parts. First, it presents different applications that encourage in some way people sharing their ride with other. Then, it analyses several studies done that can help to solve the different challenges to detect if a trip is forged.
• Chapter 3 - Scenarios and Requirements: The different scenarios are explored to be possible to understand how should the system behave in different situations, and the requirements of the system are presented.
• Chapter 4 - Architecture and Methodology: It is explained the architecture of the system in the first part, and then the database design is presented.
• Chapter 5 - Related Technologies: It presents the main technologies, architecture styles and design patterns that are used in the development of the system.
• Chapter 6 - Proposed Solution: It gives a brief description of the adopted solution to each one of the main problems.
• Chapter 7 - Implementation - Server-Side: It describes the implementation of the server-side of the system.
• Chapter 8 - Implementation - Client-Side: It describes the implementation of the client-side, more specifically the Android application developed.
• Chapter 9 - Evaluation and Results: It presents and analyses the different tests done to the system.
• Chapter 10 - Conclusions and Future Work: Presentation of the conclusions of the dissertation work and suggestions for future improvements related to the presented work.
Chapter
2
Background and Related Work
This chapter starts by presenting different applications and services, in which it is possible to share car rides with other people. Secondly, this chapter presents and analyses different solutions that try to ensure the location of the user, without being possible to forge their location.
The third section focuses on ensuring the proximity between the devices of the users that are sharing a car.
The fourth section focuses on presenting different solutions about how it can be possible to ensure that each person is only able to create one account in the system and not able to simulate that they are sharing the ride with other people using several phones.
Lastly, different studies about the Trusted Execution Environment (TEE) are presented to analyse if the TEE can be used to solve the problem about ensuring the location of the user and how it can be made their authentication.
2.1 Ride Share Applications
This section analyses different applications that encourage people directly or indirectly share cars with others. The applications to encourage the rideshare can have different concepts. One of the concepts is applications where users can find a driver that is going for where the user wants to go. The cost of the trip is divided or the user pays to the driver for the trip. Another concept is sharing the car with several people when they are going to the same destination, however, the driver is a professional driver.
Lastly, there is an application that encourages people sharing the car, by giving them discounts in the tolls.
All the presented applications have a different concept behind, and no application with the concept proposed on this dissertation was found. There are more applications similar to these ones. However, the underlying concept is very similar to the ones analysed, and the major differences are where they operate, and the prices charged by each one of them.
2.1.1 Related Applications
The first analysed application was BlaBlacar [5]. Blablacar allows the user to be a driver or a rider. The user can search if there is a driver that will do the same route as him or the user can be the driver and post and try to find someone that it is searching for a driver. The riders need to pay for the trip to the driver.
ZimRide [6] has a similar concept, however it is an application to help people find a ride in a private network. In Zimride the user enters a community, from a university or a company, and can find a ride inside that community, and help in the costs of the gas. The process to use the application is to create an account by doing a profile, and securely log into the private network of the corporation or university. The next step is to search by rides or riders and then find a match. The last step is to take the ride and in the end pay for it.
The Hitch [7] application is another service of ridesharing, however, it is limited between Austin and Houston. Basically, it is a service that connects these two cities. There are specific locations where the driver can stop to pick up the other users. The driver receives money for each trip. The driver receives 120 dollars for the round trip between this two cities.
The Uber [8] is a service works similar to Taxi. The application has drivers and, using the app, the user calls the driver, and the driver will drive to the destination. Then the rider will pay the driver. Part of the money goes to the company and another one goes to the driver. The driver is doing his job. However, this application has an option where it is possible to find people that are going in the same direction, and it is possible to pick those people and share the costs of the trip. So, if this option is used, people will share the car and fewer cars will be on the roads and less pollution will be generated.
Via [9] is an application that works similar to Uber, however, in this service, the car will be shared with other people every time that it is possible, not making it possible for people to choose.
The GoCarma [10] is an application with a different concept. This app gives discounts on the tolls for vehicles with high occupation. To be able to use this application, and get the discounts, every user in the car has to have the application installed. It is necessary to order a small Bluetooth device to put on the car’s glove box. The application will automatically report when it’s in a specific car, and it will give discounts on the toll for the cities that participate in this program.
In the research made of applications where it is possible to share a car, and described previously, there is not any application with the same concept of the one proposed on this dissertation.
In all of these applications, the users don’t gain anything in simulating trips. If a user would simulate a trip, he would not have any reward and would have to pay for the ride himself, and a percentage of the trip cost would go to the application, in the cases where commissions are applied, so it is not a threat for the application.
Even though there is not interest in simulating trips in the application GoCarma, this application is very different from the other ones. This application encourages people to share their car, by giving them discounts on the tolls, if the car has several people inside. There
is not any interest in forging trips, because the reward is smaller than the cost of the toll, however, there is the interest of simulating the occupancy of the vehicle.
The information available about how to ensure the occupancy is protected by a patent [11]. The information available about how they ensure the occupancy states that it resorts to monitoring the continuously coordinated proximity of user devices. However, the fact that in a car there are several devices, it doesn’t mean that there is more than one person.
2.2 Ensure Absolute Location
The development of this application comes associated with different challenges. One of them is how it can be possible to ensure the location of people that are sharing a car, due to the fact of it being possible to forge the location on the device. The development of a solution to this problem is important to ensure that it is not possible to fake trips, and receive points without even moving.
This is important not only because it will help in the sustainability of the application, but also because people will feel the system to have more fairness if they know that it is very hard, or impossible, to deceive the application, and therefore they’ll take the use of the application more seriously. Moreover, the development of a solution to this application can help the development of other applications or services with similar properties.
2.2.1 Review
Regarding location spoofing different types of attacks to forge the location are defined in this work [12]. The spoofing can be done in different ways, such as:
• Spoofing on the hardware level: This is done when the attacker manipulates/hacks GPS hardware or module or simulate it using software by given fake location signals to the operating system.
• Spoofing on the operative system-level: This is done when attackers modify or run a modified version of the operating system that reports the location desired by the attacker.
• Spoofing on the application level: This happens when the source code of the application is modified to send to the location-based server a forged location chosen by the attacker.
Besides this types of attacks, there is another one that consists in simulating certain environ-mental parameters such as cell towers, access points, etc... with the goal of fool the location modules that rely on the information from this sources, however this kind of attacks require a lot of effort to do and even more in a global scale.
To make forgery harder, Dorothy E. Denning and Peter F. MacDoran [13] introduced (in 1996), a location signature sensor to compute a location signature from the microwave signals transmitted by the GPS satellites. This solution consists of having a location signature sensor connected to a small antenna. It will be able to calculate the location signature from bandwidth compressed raw observations of all the GPS satellites that are picked up. The signals of the GPS are constantly changing with the orbital motion of the satellites, therefore
these signals can be used to compute a location signature that is unique to that time and location. When the remote client wants to have access to the host server, it is challenged to supply its current location signature, and the host, which has also a location signature sensor, will process the signature of the client and its own simultaneously acquired satellite signals, to verify the client’s location.
In this solution, they propose a hardware to be able to calculate signature from the raw observations of all the GPS satellites, but it is necessary to have into consideration that this is a study from 1996. A lot of things changed, and nowadays it is considered that everyone has a smartphone with GPS and back in the day the smartphones didn’t exist.
The implementation of this solution into our system has two major problems:
• it is necessary to have a trusted device to calculate the signatures from a given place, to be possible to compare the location signatures of the trusted device with the location signature of the user device.
• The smartphones may not have access to the raw Global Navigation Satellite System (GNSS) output to create the location signature1.
This solution will not help us ensure the location of the user, because it is not viable/possible to have trusted devices everywhere to collect the location signatures, and it is necessary in our case to ensure worldwide localization, and not only in a specific place where would be set the trusted device.
The survey [14] about location authentication protocols and spatial temporal-attestation services has two main goals:
• Present some services and protocols that exist with the objective of location authentica-tion and spatial temporal-attestaauthentica-tion services.
• Explain some of the security properties they should provide and which security mecha-nisms are appropriate.
The authors started by giving the definitions, assumptions and threat model of these proto-cols/services. Then, they presented Distance-Bounding Protocols.
Distance-Bounding Protocols are used when it is necessary to prove that the user is within some distance from some location where a location entity is placed.
Two types were presented.
• Based on Fast Challenge-Response Exchanges: Protocols founded on the mea-surement of the round trip latency λ between the prover and the verifier. They are designed as interactive two-party protocols, and one assumption is that the propagation speed to transmit the exchanged messages is constant. The prover can say that it is farther away from the Location Entity, but it cannot say that it is near to the Location Entity.
• Based on Token Broadcast: The location entity broadcasts some tokens and these tokens can only be received if the receiver is in the transmission range of the location entity. If someone knows the token, it is considered that it is near the location entity.
Besides explaining these distance bounding protocols they explain two Absolute Positioning Protocols. These are aimed at authenticating absolute position with some resolution and they usually rely on triangulation techniques.
• Based on Simultaneous Fast Challenge-Response Exchanges: Simultaneous execution of several distance bounding protocols on fast exchanges by several location entities. After doing this, it is possible to use the results to calculate the position of the prover. If the prover lies within the triangle of the vertices generated by the Location Entities, it can’t forge the location. The prover can always prove that it is further a Location Entity. However, if the prover tries to prove that it is further a location entity, it is necessary to prove that it is closer to another Location Entity and that it is not possible under the assumptions set.
• Based on Authenticated Ranging: Based on signals broadcast by global navigation satellite systems, where the satellites play the role of location entities. The positioning principle consists in measuring the time of flight from different satellites to the prover. This allows computing their distance or range; several ranges can be used to calculate the absolute position by triangulation. To ensure that it is not possible to forge the location using this protocol it is necessary to use tamper-resistant receivers. The receivers would authenticate the location calculated with received navigation signals.
Another consideration necessary to do when using the global navigation satellite is that, their signals can be spoofed to make a device calculate the wrong locations. It is necessary to evaluate the costs of these simulators because, in several applications, the costs of it would not be worth comparing with the reward.
In our case, it is necessary to calculate the location of the user worldwide or at least it is necessary to localize the user in a specific country, so it is necessary to have already the necessary infrastructures. From the different protocols explained in this study, the only one that meets with the requirements is the one that uses the global navigation satellite systems.
According to this study if the global navigation satellite system is used to ensure the location of the user, it is necessary to use a tamper-resistant device. However even when using a tamper-resistant receiver, it is possible forging the location by spoofing GPS signals.
The other protocols have the drawback of being dependent of infrastructures that are not available worldwide to calculate the location of the users.
Another proposal [15] presents a solution to solve the problem of long-term authentication and accountability of location tracking history information or path. The work focuses on location tracking applications, in situations where an entity ’A’ wants to prove to entity ’B’ the used path and the entity ’B’ can verify that information by authorized external entities. To accomplish this, ’A’ has to use a special device to provide his location and tracking the path, and the protocol is developed using a path stamping architecture.
The study doesn’t solve the problem of how to ensure the location of a device if the device is not tampered resistance, and in our system, the device is a smartphone phone from the user and it is not tampered resistance.
Using this protocol presented in our system, we will only ensure that the path that was sent is impossible to change. However, it doesn’t ensure that the sent path is not forged. So, this study reinforces the idea that if it is necessary to ensure the location of the user it is necessary to use a tamper resistance device.
Another work [16] introduces a different solution. The protocol presented assumes an environment where many Radio-Frequency IDentification (RFID) readers pervasively exist in public settings.
One of the goals is to preserve the privacy of the user. There are a lot of services that use the location of the users and some of the services maybe can’t be trusted and the users have a lack of privacy. Even though the users might not trust the services, the service also should not trust the users, so the other goal of this protocol is to certify user location.
The entity (user) who wants to prove the location has a RFID and there are detectors, that are a detection entity, connected to an RFID-reader. These detectors are placed in the locations where it is necessary to prove that the entity is there. There is an entity resolver that has a table to map clients’ RFID to IP addresses. When detectors detect a RFID, they request to the resolver the IP address of the correspondent RFID and they send a notification to that address saying that a ticket is available. The user can obtain that ticket and this ticket is the proof of his location. When the service provider wants to verify the location of the user asks for the ticket and then it sends the ticket to the detector which generated that ticket. The detector will verify the ticket.
A solution such as the one presented in this study doesn’t seem viable to our case. The use of RFID could be helpful to prove that they are in a public transportation, because the position of this RFID is trustworthy and harder to adulterate. Anyway, the encouragement of the use of public transportation is out of the scope of this project.
When the user uses private cars, an external tampered resistance device could have a RFID reader and the user would use their RFID to connect to the device of the car. This solution has several disadvantages, such as the user needs to keep two devices and some security threats would be raised from the fact that the RFID of the user could be borrowed to someone else.
The goal of this study [17] is to create a certification service that allows content creators to tag their content with a spatial timestamp indicating its physical location. This is done to ensure that the location tags are not fake, and the photo or video was taken in the reported location. To accomplish this, it is important to ensure that the location sent is not forged.
One of the options is to use trusted nodes. These nodes are equipped with GPS, and they are operated by a trusted party to perform the localization of a given user using a small range wireless technology. This solution would be viable if the goal was to ensure the location in a particular place, and not in every part of the world, as it would be extremely expensive to have trusted nodes to cover a big area.
Another approach is to use tower localization. This method consists of using multiple cell phone towers to centrally locate a node’s position. In regions with high density of towers, it can achieve meter precision. However, this method is dependent on the Telecom providers,
and it would be necessary for them to provide this service for this to work.
Another approach is to use 802.11 access points [18], which, given their high density, could be an option to consider. This solution uses the strength of the signal of the access points, and was developed to determine the location in a specific building or region, but makes necessary to create a map of the strength of the signal. To do this map in a building it is necessary to spend a little less than one minute in each room, and then it is possible to determine the location of the users correctly at least in 95% of the cases.
Lastly, the authors of study [17] presented the solution used by Yahoo!’s ZoneTag cellular application for tagging pictures, which is a hybrid scheme. The application firstly tries to acquire the location information using GPS. If it can’t access the GPS information, it will use the location information of the cell that it currently lies in. This information comes from other users that upload valid information when using the same cell. However, with this solution, it is still possible to forge the location. To be able to secure the location, cellular telephone towers should be able to behave as certificate authorities or proxies, so that users do not manipulate their location.
With this last solution, it is possible to forge the location. If the cell Identifier (ID) is used together with the GPS data, it would be possible to forge locations. However, it will increase the complexity of the attack. If the location of the cells is known, it can be possible to detect forgery in the cases that users only manipulate the GPS location, or if they don’t manipulate the number of the cell ID correctly to the correspondent location.
In another work [19], to ensure the location of a user, the authors suggest the use of location proofs. Location proofs are meta-data tokens issued by a Wi-Fi access point or a cell tower. When a device is in the range of an infrastructure can ask for the location proof. The location proof has a timestamp, so it is also possible to store it and use them later when an application wants to know the location in the past. The location proofs are signed by the infrastructure, so the application must trust the infrastructure to be able to verify the location proof’s signature.
The authors explained the process of proving the location of the user with an example that consists of a content delivery server waiting to restrict the content accordingly to user location. Before starting the download, the server asks the device for the location proofs from the cellular network. The device contacts a nearby cell tower, requests a location proof and transmits it to the movie server. The movie server can verify the location of the device, and decide whether or not to give access to the content.
Another approach [20] has the goal to ensure the location of vehicles, where vehicles use packets received from roadside units to construct their location proofs. This solution is lightweight, doesn’t rely on Public Key Infrastructure (PKI) system and keeps the privacy of the users.
The last two solutions ensure the location of the user or at least prove that the user was there in a specific moment. The solutions may have vulnerabilities, and it might still be possible to forge the location, but the complexity to do so would increase.
changes to the infrastructures that already exist, and it would be hard to implement any of these solutions without the cooperation of the entities in charge of them.
Another work [12] has the goal of developing a scheme to authenticate and authorize the access to some resources using, not only the traditional credentials, but also considering the location of the user. The user to get access to the resource has to be near the location where he made the registration, and how near has to be of the location can be defined by defining a radius. So, in this application it is necessary to create measures to mitigate the problem of location spoofing.
It was proposed some measures to mitigate the mentioned type of attacks to spoof the location. The first solution is to use distance bounding protocols and this type of solution deduce and verify the location of a particular client taking advantage of the physical limitations of wireless technology. For example, a Wi-Fi access point can help confirm that the location of the user is the one that he is reporting. The second measure is to use the IP address to deduce the client’s location. The IP addresses are issued by the Mobile Network Operator (MNO) and it is hard for the clients to change them. However, this approach is not good enough due to the fact that the same IP address space covers hundred of miles [21]. Another measure is to compare the round-trip time from the client to other known reference points.
With these measures, they proposed a hybrid solution to take advantage of the strengths, and reduce the weakness of each measure. The approach has several layers of verification, so if the first layer doesn’t detect that the location sent by the client is forged, there are other layers to try to detect and prevent the spoofing. The different layers are:
• First layer: Consists in obtain the location from several sources. For example, it can be used the normal Android Location API, Skyhook, etc. So, if it is used by two different sources, we get two location coordinates. Therefore, the reliability and accuracy of the location is bigger because it doesn’t rely only on only one source. The coordinates from the different sources are then compared, if there is no overlap between the different sources, there is a high chance of the location has been compromised.
• Second layer: Consists in verify if the IP address corresponds to all the areas detect in the first layer. The IP address covers a big area, so it is supposed to cover all the areas of the first layer.
• Third layer: Corresponds to compare the captured Media Access Control Address (MAC) address of the access point with the strongest signal and compare it with the one picked in the registration phase. If the MAC address doesn’t match, the verification process fails.
If all the verification made in each one of the layers is true, the user has access to the resource. The last layer of this solution is very specific to this case, because the goal of this proposed scheme is to ensure that the user is in the same location where it made the registration in the system. However, the other layers suggested can be helpful to develop our solution.
Another technology that can be used to mitigate or solve our problem is Ultra-wideband (UWB). This technology uses a very low energy level for short-range, high-bandwidth
communications over a large portion of the radio spectrum. One of the applications of this technology is in the development of locating and tracking applications [22].
Another work [23], developed and proposed a protocol to secure determining the location of a user using UWB, with capabilities of doing this in the presence of an adversary. This protocol uses Time–of–Arrival (ToA) secure localization system, and it works in the current hardware and/or firmware of existing UWB ranging platforms, without being necessary doing any changes in them.
Although this work manages to securely calculate the position of a user, it has one big drawback which makes it unfeasible to our case: UWB has a very short range, so it would be very difficult to cover a big area to be able to secure determine the location of the user without being possible to forge their location.
There is another technology named Long Range (LoRa) that has a lot of uses cases and one of them is localization [24]. This technology is a long-range wireless communication protocol and it has already good coverage around the world [25]. LoRa has long-range transmissions and it is possible to use it to transmit in rural areas more than 10 km of distance with low power consumption. The drawback of this technology is that the use of the smartphone is not enough, and it is necessary to develop or use extra hardware to perform the location using this technology.
2.2.2 Summary
None of the studies found have a viable solution to ensure the location of the user, provided by the smartphone of the user. The solutions found to ensure location consists of using an external tampered resistance device connected to a smartphone of the user, or to change infrastructures like the cellular telephone towers.
Both solutions are not considered viable for our system. The first is considered not viable because it is necessary to provide an external device to the user to be able to use the application. The use of an external device will probably reduce significantly the number of users interested in experimenting and use the application.
The second solutions are not viable because it is unfeasible to us to implement a working solution, in which would be necessary to change how the infrastructures like the cellular telephone towers work.
In conclusion, there is not a solution that meets the requirements, and that it is possible to have full control over the implementation.
2.3 Ensure Proximity
Due to the fact that we didn’t find a solution to ensure the absolute location of the user smartphone, it is necessary to study how it can be possible to ensure that the users are near each other.
If the location would not be possible to forge, it could be ensured the proximity only by checking the locations of each one of the users. If the locations would be near each other, it would mean that the users are near each other. However, it is not possible to trust in the
locations sent by the users. For that reason, the next phase of the research will focus on how it is possible to ensure that several phone devices are near to each other.
There are several studies that use the device sensors to prove that they are near other devices. One of the reasons there are so many studies is due to the increased use of Near Field Communication (NFC) to make payments.
The NFC technology is used to perform payments by only bringing the devices close to each other. It is clear that if the goal is to make a payment, they are dealing with a sensible operation, so it is very important to ensure the security of the process and one the reasons to use the sensors to prove the proximity of the devices is to mitigate the relay attacks.
2.3.1 Review
In [26] authors analyse how it can be possible to securely determine if two devices are close to each other. The presented solution consists in verifying the proximity of both devices by correlating certain sensor data extracted from the two devices. The sensors used in the study were audio sensors (microphones), and ambient light sensor. For each sensor the authors presented several solutions that can be used for determining the similarity between two short audio signals, as well as between the light extracted. Three techniques were proposed to calculate the correlation between audio. The first technique was Time-Based Similarity Detection, the second one Frequency-Based Similarity Detection and the last one a method that combined time and frequency. To compare the light data it was used a simple solution, that consists of comparing the mean value of the illuminance data captured by each sensor.
They alert for the fact that the audio data can be heavily affected by surrounding human/nonhuman activity, as opposed to light that is much more constant over time. The results of using the time-based “correlation” for the sound generated a 38% detection rate, while the light sensor generated a detection rate of 14%. Using the third method that uses the time and the frequency the detection rate was of 53%.
The last step was to test the dataset to determine the performance of the time-frequency detection on data taken, not only under normal usage, but also on an attack scenario. To accomplish that it was used the SimpleLogistics classifier from the WEKA package to classify the samples.
By using the classifier it was possible to arrive at a simple classification formula. By using the formula, and the correlation between the two samples, it is possible to verify if both were taken at the same place. Calculating the result of the expression resulting from the formula, produced a detection rate of 100%. This calculation is computationally light.
It is possible to conclude that the results using sound were very positive. It was concluded in the tests that the light conditions are location-dependent, however, illuminance readings can be affected by a lot of factors, such as human movements like for example hand waving. The false accept rate was equal to 6.5% while the false reject rate was equal to 5%. By analysing the results, it was concluded that the audio is a much stronger signal for detecting the proximity of two devices when compared to light. When the sound is being used it will be very hard for the attacker to have success, and when the light is being used it will difficult the
attack, however, it can be possible. The tests were done in commercial environments, such as restaurants, shops, and department stores.
This study can be helpful to prove that two or more devices are close to each other, however, the NFC reader is a point of trust. In our problem, it is necessary to analyse this situation carefully because there is not a device that we can trust, so it can be possible to do relay attack of the sensors readings.
Another work [27] presented a solution for testing if someone’s phone is near without any part revealing any information about their location. The system was implemented on Android, and they discuss the use of location tags to accomplish the necessary security of a proximity testing. The part of this study that is important for the discussion of this problem is when they discuss the use of location tags. They define location tag has a secret associated with a point in space and time, and they derived it from signals present in the physical environment. The two properties that location tags must have are reproducibility and unpredictability:
• Reproducibility: if two entities make measurements at the same time and location, the location tags must be comparable and similar.
• Unpredictability: an adversary cannot predict the location tags of some local. The first location tag suggested is WiFi broadcast packets. By capturing the packets over a WiFi network it is possible to compare the source and destination IP addresses, sequence numbers of packets, and precise timing information and all these properties offer varying degrees of entropy. They performed a test to this location tag and it was successful. The authors only used protocols carrying purely local traffic, the capture was made in promiscuous mode and they restricted to the top 5 protocols by the number of packets. The result was : ’ARP’, ’BROWSER’, ’DHCP’, ’MDNS’, and ’NBNS’. After comparing the results, 90% of the packets are common to both devices. Dependentement of the volume of traffic, it is possible to derive meaningful location tags within 2-3 seconds.
The second location tag presented was WiFi Access point IDs. Wireless access points have Service Set Identifier (SSID) and MAC Address which they advertise. This technique is already being used by Skyhook. They measured the list of visible MACs with two devices in three different locations, and they concluded that the differences in hardware led to significant differences in the list of IDs measured. On average, 10.7 IDs were visible per device and the mean number of common IDs was 5.3.
Bluetooth was another location tag discussed. Bluetooth has the advantage of being more associated with mobile devices than with fix devices, which means that makes it more time variant. However, the range of this signal is very small, so this was not tested by them.
Another location tag was using the information of the cell towers of the Global System for Mobile Communications (GSM). Each tower has space and time-varying characteristics, such as signal strength, so this can be used also has a location tag, however the authors didn’t explore this location tag. The audio was also proposed to be used. Acoustic fingerprinting is a well-known technique to extract features and the audio is time variable, and also location variable.
The last one was Atmospheric gases. In the future, there is the possibility of having Carbon Monoxide (CO), Nitrogen Oxides (NOx) and temperature sensors on cell phones being mainstream, and they can be used also has a location tag.
The study introduced the use of location tags, to help us to solve the problem of proving that two or more entities are close to each other. Nowadays, many cars having Bluetooth and all the devices must be close to each other, so even though for their case Bluetooth was not practical, for our case it can be. The use of WiFi has the problem that some areas where people are traveling are not covered by it. If the system relies only on this and in the GPS to verify the location, this is a vulnerability. It is easy to find zones without any access point, and basically the extra layer added with the access points IDs disappeared, so it is not possible to rely uniquely in the use of WiFi broadcast packets and access point IDs. However, in some cases can be possible to use them. So, the location tags that are used can be different according to the environment.
The use of the captured audio is a good source to create location tags. There is even the possibility of each device reproducing sound, for example at the same time, and the captured sound has to be the intersection of the reproduced sounds. This seems a good technique to avoid relay attacks. GSM can also be a good source of information to us, even more if service providers would share some information about the location of the users, like for example the base station that a given user is connected.
Another point that it is necessary to have in consideration is that there are many more sensors that can be used to location tag in our situation, such as the accelerometer. In our case people is sharing the same vehicle, so they will have similar accelerations at the same time. It may be possible to use the acceleration to prove that they are in a vehicle, and that they are in the same vehicle. Another sensor that can be used in the same way is the magnetic field.
Bluetooth Low Energy (BLE) is being explored in the last years for several things, such as verify the proximity of devices, or keep track of users indoor position.
One work [28] presents an implementation of an attendance management system using BLE. It was proposed to use the BLE to be possible to optimize and automate the process of knowing which students are in the classroom.
Each one of the students has a sensor that advertises a unique string that can be associated with the ID card. The phone of the teacher needs to have the application installed. The application can sense the beacons up to 200 meters, and the application scans for the BLE devices that are registered in the class. By detecting the different advertisements of BLE devices, it is possible to know which students are in the class. It is computed the distance of each beacon to the smartphone sensor. The sensed beacons are the ones which are in the range of the classroom, and have comparable received signal strength to avoid that the students are detected, even if they are outside of the classroom.
To increase the complexity of deceiving the system, such as by keeping a strategical distance outside of the classroom, or borrow the sensor to a colleague, it is necessary to use a system to count the number of students in the room and compare with the number of devices
captured by the phone teacher.
In this study, BLE was used to track which users are in a room, and the scenario presented in this dissertation is not very different as it is necessary to ensure that the users are inside a vehicle. In their case it is possible to have a way to verify if the number of devices scanned matches the number of users in the classroom, however, in our case, it is not possible.
Other authors [29] present another solution using BLE to track the attendance in events or classes. This solution has the main goal of being able to track the attendance of classes or events with more than a thousand participants. Each participant has to have a smartphone with a mobile application, and each room has a beacon that advertises its address. The user makes a scan and the results of the scan are sent to the server, to prove that he is an event. The user selects which event he wants to attend, and the application sends to the server a request to attendee’s presence.
This study solves the problem of attendance with a different approach. In this solution, each one of the users needs to scan the beacon that it is in the room and this will divide the workload by each one of the users, instead of the solution presented before that the smartphone of the teacher would scan each one of the users.
Another study [30] tracks attendance using QR codes. An application generates a unique QR code that identifies him, and the teacher or someone responsible for it, scans each one of the QR codes to track the persons that are in the event.
In our case the use of QR code is an option to use because it is an efficient way of the users joining a specific trip by scanning the QR code of the user that created a trip. However, it doesn’t ensure that the users are together or that they will continue together. In the study, the person scanning the QR codes is an entity of trust, so it is harder to deceive the system. In the studies that used BLE it is not well discussed how it is possible to protect against users trying to deceive the system. Only the first one [29] discussed some attacks, such as borrowing the sensor from a colleague, but the solution used cannot be adopted for our case. It is not discussed if it is possible to simulate the beacon with another device, and simulate that it is in the event or class. Therefore, the use of the BLE may not ensure that they are close to each other, but adds a layer of protection and complexity to deceive the system. 2.3.2 Summary
There are several studies with solutions to verify if two devices are near, at least without considering attacks and attempts to deceive the system. In several studies was concluded that it is viable the creation of location tags, and it is possible to use several fonts of information from different sensors to create them.
If both devices are in the possession of an attacker there was not found any study to ensure that they are near. However it may be possible to implement several measures to increase the complexity of doing an attack in this scenario.
One of the options that seems more reliable to increase the complexity of deceiving the system is the use of BLE. The use of the BLE will detect when the users are not near each other, however, it may be possible to forge the system.
Even though, the system may have ways of being deceived and be possible to simulate that the devices are together, the implementation of one solution adds an extra layer of security, and increases the complexity of deceiving the system.
2.4 User Authentication
Another challenge that must be addressed is the authentication of the users. This problem can be divided into two parts. The first part consists of being necessary to difficult the creation of different accounts per person, to mitigate the problem of a user having several phones with different accounts, and being able to simulate trips.
The second part is to ensure that the person who created the account is the person who is using the smartphone. Both parts are interrelated and it is possible that one solution can solve all the problems. Nevertheless, to solve at least the second part of this problem, it is necessary to use biometry or information from the user that it is hard to share with others due to be confidential or sensitive. If the application is protected with only a simple password, this is easily shared with other people. On the other hand, the biometry cannot be shared, so it seems an option to associate with each user a piece of biometry information that identifies and characterizes each user.
2.4.1 Review
Part of the worked presented in [19] was already analysed before, due to the fact that it presents a solution to proof the location of a device using a location proof, but this study also addressed the problem of how can be possible to ensure that the owner of the phone is close to it and he didn’t borrow the phone to someone else. To solve this problem the authors suggest to the location proof issuer to have the photo of the user and ask to take a photo of the owner and send it to the Acess Point (AP) to be able to authenticate himself. This solution is not bulletproof. It is possible to have an old photo and send it to the AP. So, it was added a challenge to the photo inspired by the CAPTCHAS on the web.
When the AP requests the photo of the device’s owner, the AP also sends a NONCE. The user should write in the NONCE in a white paper, take a photo with it, and send it to the AP. The AP would verify if the NONCE is correct in the paper, and that the person on the photo is the owner of the phone. This solution also is not bulletproof because it is possible to have a photo with a full white paper, and with software to edit photos would be possible to put there the NONCE received.
The last scheme suggested is to use voice recognition. The AP would send an English phrase and the owner would have to send the record of him saying that phrase to the AP. They concluded that all these solutions have a possible attack. The personator could send the challenge to the device owner, and the device owner would send back him the response, and the impersonator would send the response to the AP.
The survey [31] analyses current approaches and mechanisms of behavioral biometrics to authenticate smartphone users. Even though, this type of authentication is not the most appropriated for our project, in the paper, they define some important concepts that can
help us understand how we can approach the problem. They say that Personal Identification Numbers (PINs) and patterns approaches are weak to authenticate users, because they fail to detect an intruder after entering in the system, and they suffer from non-conventional attacks such as picking up oils from users’ skin to detect patterns or PINs, or looking over the shoulder to see the PIN or the pattern.
This type of authentication can be used. However, it must be used together with continuous authentication. Continuous authentication can be performed in two different ways: using physiological and behavioral biometrics. Physiological biometric authentication consists of using the user’s static physical attributes such as fingerprints, facial features or retina images. Behavioral biometric authentication consists of using features of user’s behavior that are constant over time during daily activities such as typing motions, photo manipulations, and hand motions.
There are three main strategies to authenticate the user. The first one is Knowledge-based and this consists in authenticating the user with something that only that user knows, for example, a password. This type of authentication doesn’t solve any part of the problem. It is possible to share the secret with other people and it doesn’t identify the person, in order to limit the creation of multiple accounts.
The second type is possession of something and this type of authentication is done by the user proving to the system that has some object with him, it can be a security token, an ID card, or another trusted device. This type of authentication can be useful for our project. For example, the use of the driving license or ID card can be an effective way to authenticate the user, because it is not easy or convenient to share the driving license, or the ID card, with other people. It also mitigates part of the problem related with the creation of several accounts by the same user, because each user has only one ID card, or driving license. Moreover, the user to create an account should have a driving license, so maybe it makes sense to use this card to authenticate the user.
The last type of authentication is biometrics. This type of authentication denotes a physical or behavioral characteristic, and the most common examples are when it is used with fingerprints or keystroke dynamic models of the owner of the device.
The use of biometrics to authenticate the user by using physical characteristic of the user can be used in our project, mainly because it is hard to share this information with another user, so it proves that the owner of that account is close to the smartphone, and it has some potential to identify the person and mitigate the problem of being possible to the same user create multiple accounts.
The authentication using behavioral characteristics is not very relevant and promising for our project, because it is more used in a passive way (the authentication is made at same time that the user uses the application) and considering the type of usage of our application it doesn’t make sense, if users are driving.
In one study [32] the authors state that biometric-based authentication techniques on the smartphones, until now, are not adopted on a global scale because they can be expensive and sometimes slow and unreliable.
