SMART ACCESS CONTROL

Transcripción

1 GRADO EN INGENIERÍA TELEMÁTICA SMART ACCESS CONTROL Autor: Ramón Prado Moreno Director: Eric P. Jiang Madrid Junio 2015

2 Autorizada la entrega del proyecto del alumno/a: Ramón Prado Moreno EL DIRECTOR DEL PROYECTO Eric P. Jiang Fdo.: Fecha: / / Vº Bº del Coordinador de Proyectos David Contreras Bárcena Fdo.: Fecha: / /

3

4

5 AUTORIZACIÓN PARA LA DIGITALIZACIÓN, DEPÓSITO Y DIVULGACIÓN EN ACCESO ABIERTO ( RESTRINGIDO) DE DOCUMENTACIÓN 1º. Declaración de la autoría y acreditación de la misma. El autor D., como de la UNIVERSIDAD PONTIFICIA COMILLAS (COMILLAS), DECLARA que es el titular de los derechos de propiedad intelectual, objeto de la presente cesión, en relación con la obra 1, que ésta es una obra original, y que ostenta la condición de autor en el sentido que otorga la Ley de Propiedad Intelectual como titular único o cotitular de la obra. En caso de ser cotitular, el autor (firmante) declara asimismo que cuenta con el consentimiento de los restantes titulares para hacer la presente cesión. En caso de previa cesión a terceros de derechos de explotación de la obra, el autor declara que tiene la oportuna autorización de dichos titulares de derechos a los fines de esta cesión o bien que retiene la facultad de ceder estos derechos en la forma prevista en la presente cesión y así lo acredita. 2º. Objeto y fines de la cesión. Con el fin de dar la máxima difusión a la obra citada a través del Repositorio institucional de la Universidad y hacer posible su utilización de forma libre y gratuita ( con las limitaciones que más adelante se detallan) por todos los usuarios del repositorio y del portal e-ciencia, el autor CEDE a la Universidad Pontificia Comillas de forma gratuita y no exclusiva, por el máximo plazo legal y con ámbito universal, los derechos de digitalización, de archivo, de reproducción, de distribución, de comunicación pública, incluido el derecho de puesta a disposición electrónica, tal y como se describen en la Ley de Propiedad Intelectual. El derecho 1 Especificar si es una tesis doctoral, proyecto fin de carrera, proyecto fin de Máster o cualquier otro trabajo que deba ser objeto de evaluación académica

6 de transformación se cede a los únicos efectos de lo dispuesto en la letra (a) del apartado siguiente. 3º. Condiciones de la cesión. Sin perjuicio de la titularidad de la obra, que sigue correspondiendo a su autor, la cesión de derechos contemplada en esta licencia, el repositorio institucional podrá: (a) Transformarla para adaptarla a cualquier tecnología susceptible de incorporarla a internet; realizar adaptaciones para hacer posible la utilización de la obra en formatos electrónicos, así como incorporar metadatos para realizar el registro de la obra e incorporar marcas de agua o cualquier otro sistema de seguridad o de protección. (b) Reproducirla en un soporte digital para su incorporación a una base de datos electrónica, incluyendo el derecho de reproducir y almacenar la obra en servidores, a los efectos de garantizar su seguridad, conservación y preservar el formato.. (c) Comunicarla y ponerla a disposición del público a través de un archivo abierto institucional, accesible de modo libre y gratuito a través de internet. 2 (d) Distribuir copias electrónicas de la obra a los usuarios en un soporte digital. 3 4º. Derechos del autor. El autor, en tanto que titular de una obra que cede con carácter no exclusivo a la Universidad por medio de su registro en el Repositorio Institucional tiene derecho a: a) A que la Universidad identifique claramente su nombre como el autor o propietario de los derechos del documento. b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a través de cualquier medio. 2 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría redactado en los siguientes términos: (c) Comunicarla y ponerla a disposición del público a través de un archivo institucional, accesible de modo restringido, en los términos previstos en el Reglamento del Repositorio Institucional 3 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría eliminado.

7 c) Solicitar la retirada de la obra del repositorio por causa justificada. A tal fin deberá ponerse en contacto con el vicerrector/a de investigación (curiarte@rec.upcomillas.es). d) Autorizar expresamente a COMILLAS para, en su caso, realizar los trámites necesarios para la obtención del ISBN. d) Recibir notificación fehaciente de cualquier reclamación que puedan formular terceras personas en relación con la obra y, en particular, de reclamaciones relativas a los derechos de propiedad intelectual sobre ella. 5º. Deberes del autor. El autor se compromete a: a) Garantizar que el compromiso que adquiere mediante el presente escrito no infringe ningún derecho de terceros, ya sean de propiedad industrial, intelectual o cualquier otro. b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la intimidad y a la imagen de terceros. c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por daños, que pudieran ejercitarse contra la Universidad por terceros que vieran infringidos sus derechos e intereses a causa de la cesión. d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por infracción de derechos derivada de las obras objeto de la cesión. 6º. Fines y funcionamiento del Repositorio Institucional. La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y respetuoso con los derechos del autor, según lo permitido por la legislación aplicable, y con fines de estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la Universidad asume los siguientes deberes y se reserva las siguientes facultades: a) Deberes del repositorio Institucional: - La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no garantiza ni asume responsabilidad alguna por otras formas en que los usuarios hagan un uso posterior de las obras no conforme con la legislación vigente. El uso posterior, más allá de la copia

8 privada, requerirá que se cite la fuente y se reconozca la autoría, que no se obtenga beneficio comercial, y que no se realicen obras derivadas. - La Universidad no revisará el contenido de las obras, que en todo caso permanecerá bajo la responsabilidad exclusiva del autor y no estará obligada a ejercitar acciones legales en nombre del autor en el supuesto de infracciones a derechos de propiedad intelectual derivados del depósito y archivo de las obras. El autor renuncia a cualquier reclamación frente a la Universidad por las formas no ajustadas a la legislación vigente en que los usuarios hagan uso de las obras. - La Universidad adoptará las medidas necesarias para la preservación de la obra en un futuro. b) Derechos que se reserva el Repositorio institucional respecto de las obras en él registradas: - retirar la obra, previa notificación al autor, en supuestos suficientemente justificados, o en caso de reclamaciones de terceros. Madrid, a.. de... de. ACEPTA Fdo

9 SMART ACCESS CONTROL Author: Prado Moreno, Ramón Director: Jiang, Eric P. Collaborative Entity: USD University of San Diego & ICAI Universidad Pontificia Comillas. ABSTRACT In this Project we purpose a system for managing and monitoring the access to certain rooms in a facility. Every user can access the rooms where he or she is permitted using an Android application and the system administrators can change every user permissions and monitor them with a web application. Any door can be controlled using the system by attaching a locking device to it. Keywords: Bluetooth, Android application, Web application, Arduino 1. Introduction Nowadays, access control is extensively used in a lot of companies but not in an efficient way. Some companies use outdated systems with barcode cards creating a false sense of security. Everyone has a card to access and thinks that without a card accessing is impossible but this cards are really easy to copy and the barcodes can be easily generated with a computer. Other companies focused on security use much more safe systems like biometric scans, the problem with this systems is the price. The cheapest one is a fingerprint scanner and the average price is around $90 in the United States and 80 in Spain[4]. The system we purpose uses much cheaper hardware. The hardware used is an android phone and an Arduino Uno board. Since the Uno board does not include Bluetooth connection, the board has to be connected to a HC-06 Bluetooth module. As a consequence, an interested company would need a locking device (Arduino Board + Bluetooth module) for each door, a computer for the administrator and Android phones for the users. The phones and the computers would probably have minimum cost for the company, almost none if the company decides to invest in developing the phone application also for ios. I paid approximately $12 for the locking device, assuming an extra $8 for the non-electronic components (handle and lock) and without taking into account the buying in bulk saves it is almost five times cheaper. The designed system can be as safe as the company wants. Right now it allows two different modes of operation for each room depending on the security needed. On low security mode, the user needs to specify his username and password to access the application and just press a button to access a certain low security room. For level two security rooms, the user needs to be logged in and specify pin number each time he wants to access the room. More levels of security would be easy to implement thanks to the modular programming used to development.

10 2. Description of the System Android Application Locking Device Administrator All users Database Server Web Application Figure 1: Technologies Used The system has three different parts: A web application, used by administrators for managing the permissions of the users and monitoring the access; an Android phone application that allows the users to open doors and a locking device that keeps the door locked until a permitted user opens it. The web application also acts as a server creating a response for each phone application request and uses a MySQL database to store all the information needed to work. Every time a user wants to access a room he or she uses the phone to request access for that room. The web application elaborates a response that includes an access code if the security is low or asks for a pin number if the level of security is two, then if the user inputs the correct pin number the response is sent. Once the phone application has the access code it connects with the lock device via Bluetooth and sends the access code. The locking device checks the access number, if it is correct it opens the door and sends a success message to the phone, if it is not, it sends a fail message to the phone and the door stays closed. 3. Results At the moment, we have a working web application that is able to: manage all the locks, permissions and user information; elaborate one response at a time and show a table with all the users that have accessed to a lock and when. The phone application is able to exchange messages with the server and open doors; the locking device that we built works but it is a simulation, instead of opening a lock, the device turns on a LED light. We have been focused on the electronic and software approaches leaving aside the mechanical part of the project.

11 4. Future Work This project has been a first approach to a complex idea from an electronics and software development point of view. As a consequence, there is still a lot functionalities that can be added to the system. Some of the future improvements that we purpose are: Creating an ios application: We have been working in an Android environment because it is the mobile operating system that we use but the extended use of ios cannot be denied. Having an application for both operating systems would make the whole locking system cheaper because everyone could use his own phone. Design the lock and electronics case: This is probably a job for a mechanical engineer. As we have said the system uses a LED light to symbolize the open and close state. For an implementation of the system in a company a mechanic or magnetic lock is needed. All the electronics should also be contained in a light and resistant box. Improve the electronics: Right now we are using an Arduino Uno board that is capable of much more than the needed. Developing a locking device with the minimum electronic components would make it cheaper and smaller. Add security levels: As it has been said, the system has two different levels of security. Right now we are not using all the security that can be provided by an average smartphone. Some of the smartphone capabilities that can be used are for example: face recognition, fingerprint scanner, voice recognition, etc. Use NFC instead of Bluetooth: NFC technology is much safer than Bluetooth. The algorithms are harder to break and the man on the middle attack is much harder because Bluetooth works in a ten meters range and NFC in a ten centimeters range. We decided to use Bluetooth because nowadays is much more common in smartphones. Another solution could be to use both depending on your phone. 5. References [1] Williams, Alex (9 July 2012). "GitHub Pours Energies into Enterprise Raises $100 Million From Power VC Andreessen Horowitz". Tech Crunch. [2] Information obtained from indeed.com, website used in the used to find out the approximated salaries in the United States per city [3] Stack Overflow a website designed for asking questions related to programming http: [4] Prices obtained from the web page http: for the American prices and http: for the Spanish prices.

12

13 SMART ACCESS CONTROL (CONTROL DE ACCESO INTELIGENTE) Autor: Prado Moreno, Ramón Director: Jiang Eric, P Entidad Colaboradora: USD University of San Diego & ICAI Universidad Pontificia Comillas. RESUMEN En este Proyecto se propone un Sistema para administrar y monitorizar el acceso a ciertas salas en una empresa. Todo usuario puede acceder a una sala en la que está autorizado usando una aplicación Android y los administradores del sistema pueden cambiar los permisos y monitorizar el acceso de todos los usuarios mediante una aplicación web. Toda sala puede ser controlada si se instala un dispositivo para control de acceso. Palabras clave: Bluetooth, aplicación Android, aplicación Web, placa Arduino 1. Introducción Hoy en día, el control de acceso es muy usado en diferentes empresas pero no de una manera eficiente. Un sistema muy usado son las tarjetas con códigos de barras que solo crean una falsa sensación de seguridad, como todo el mundo tiene una tarjeta de acceso piensa que solo pueden acceder aquellos que la tienen lo cual es mentira. Las tarjetas con código de barras son fáciles de copiar y los códigos de barras pueden ser generados por ordenador fácilmente. Otras empresas más preocupadas por la seguridad usan escáneres biométricos, el problema de estos sistemas es el precio. El más barato es el lector de huella dactilar con un precio medio aproximado de $90 en Estados Unidos y 80 en España [4]. El Sistema propuesto utiliza componentes más baratos, un teléfono Android y una placa Arduino Uno. Como la placa no incluye conexión Bluetooth debe estar conectada a un módulo Bluetooth HC-06. Por lo tanto, una compañía interesada en implementar el sistema necesitaría un dispositivo de control de acceso (placa Arduino + módulo Bluetooth) por cada puerta, un ordenador para el administrador y teléfonos Android para los usuarios. Tanto los teléfonos como el ordenador tendrán un coste ínfimo para la empresa, casi nulo si se decide invertir en una versión para ios de la aplicación. Para el desarrollo invertimos aproximadamente $12 en la construcción del dispositivo de control de acceso, asumiendo unos $8 adicionales para componentes no electrónicos (mango y cerrojo) y sin tener en cuenta el descuento por comprar a granel nuestra solución es casi ocho veces más barata. El sistema diseñado puede ser tan seguro como la empresa desee. Por el momento permite dos modos de funcionamiento para cada sala dependiendo de la seguridad que sea necesaria. En el modo de baja seguridad, el usuario tiene que especificar su nombre de usuario y contraseña para acceder a la aplicación móvil y tan solo presionar un botón para acceder a una sala de baja seguridad. Para las salas con seguridad nivel dos, el usuario además necesita introducir un número pin. Sería fácil implementar nuevos niveles de seguridad gracias a la programación modular que usamos durante el desarrollo.

14 2. Descripción del sistema Dispositivo de control de acceso Aplicación Android Administrador Todos los usuarios Base de datos Servidor Aplicación Web Figure 2: Tecnologías usadas El Sistema consta de tres partes distintas: una aplicación web, usada por el administrador para cambiar u otorgar permisos de los usuarios y monitorizar sus accesos; una aplicación Android que permite a los usuarios acceder a salas y dispositivos de acceso que mantienen las puertas cerradas hasta que un usuario permitido la abra. La aplicación web también actúa como servidor creando respuestas para cada petición procedente de una aplicación móvil y, además, utiliza una base de datos MySQL para almacenar toda la información necesaria para su funcionamiento. Cada vez que un usuario quiere acceder a una sala usa su teléfono para solicitar acceso para esa sala. La aplicación web construye una respuesta que incluye un código de acceso si el nivel de seguridad de la sala es bajo o solicita el número pin si el nivel de seguridad es mayor. En este segundo caso, tras introducir correctamente el pin en la aplicación móvil, el código de acceso es recibido. Una vez la aplicación tiene el código se conecta con al dispositivo de control de acceso vía Bluetooth y se lo envía. El dispositivo de control de acceso comprueba el número de acceso; si es correcto, abre la puerta y envía un mensaje indicándoselo a la aplicación móvil; si no lo es no se abre y también envía un mensaje indicándoselo a la aplicación móvil. 3. Resultados Hasta el momento, se ha conseguido una aplicación web capaz de: administrar todos los dispositivos de control de acceso, permisos y perfiles de usuario; elaborar respuestas, de una en una, y mostrar una tabla con todos los usuarios que han accedido y cuando. La aplicación móvil es capaz de intercambiar mensajes con el servidor y abrir puertas. El dispositivo de control de acceso funciona correctamente pero el cerrojo es simulado, en vez de abrir un

15 cerrojo el dispositivo enciende una luz LED. El proyecto está centrado en el campo de la electrónica y el desarrollo software dejando de lado la parte mecánica de la idea. 4. Posibles mejoras Este Proyecto ha sido el primer acercamiento a una idea de alta complejidad desde un punto de vista centrado en el desarrollo de software y la electrónica. Obviamente todavía hay bastantes funcionalidades que pueden ser añadidas. Algunas de las mejoras que proponemos son: Crear una aplicación para ios: Hemos estado trabajando en un entorno Android debido a que es el que más usamos pero no podemos negar el uso extendido de dispositivos móviles de la marca Apple. Tener una aplicación para ambos sistemas operativos haría más barata la implementación del sistema porque la gran mayoría de los usuarios podrían usar su propio teléfono. Diseño de cerrojo y caja para la electrónica: Este es, probablemente, un trabajo para un ingeniero mecánico. Como ya se ha comentado el sistema usa una luz LED para simbolizar los estados de abierto y cerrado. Para una implementación del sistema en una empresa se necesitaría un cerrojo, ya sea mecánico o magnético. Además, todos los componentes electrónicos deberían estar en una caja ligera y resistente. Mejoras electrónicas: Actualmente usamos una placa Arduino Uno capaz de mucho más de lo necesario. Desarrollar un dispositivo de control de acceso con solo los componentes necesarios lo haría mucho más pequeño y barato sin alterar su funcionamiento. Añadir niveles de seguridad: Como ya se ha comentado, el sistema tiene dos niveles distintos de seguridad. No se están aprovechando todas las capacidades que un Smartphone de precio medio ofrece. Algunas de estas capacidades que podrían ser aprovechadas son: reconocimiento de cara, escáner de huella dactilar, reconocimiento de voz, etc. Utilizar NFC en vez de Bluetooth: La tecnología NFC es más segura que Bluetooth. Los algoritmos usados son más difíciles de romper y los ataques del tipo man on the middle son mucho más complicados ya que Bluetooth emite en un rango de decenas de metros mientras que NFC en un rango de diez centímetros. Decidimos usar Bluetooth porque, hoy en día, es mucho más común en teléfonos de precio medio. Otras solución que se podría estudiar sería usar una tecnología u otra dependiendo del teléfono del usuario. 5. Referencias [1] Williams, Alex (9 July 2012). "GitHub Pours Energies into Enterprise Raises $100 Million From Power VC Andreessen Horowitz". Tech Crunch. [2] Información obtenida en indeed.com, página web usada en Estados Unidos para averiguar salaries aproximados por ciudad. [3] Stack Overflow un sitio web para preguntas y respuestas relacionadas con la programación http:

16 [4] Precios obtenidos del sitio web amazon.com para los precios americanos y amazon.es para los españoles.

17

18 Agradecimientos Me gustaría dedicar todo este trabajo a mis padres que me animaron a estudiar este grado.

19 INGENIERO EN TELEMÁTICA THESIS INDEX Thesis Index Chapter 1 Introduction Definition Present Situation Motivation of the project Overview of the proposed solution Chapter 2 Technologies used Web technology Smartphone technology Microcontroller technology Communications technology Chapter 3 State of the Art Chapter 4 System Design Overview Web Application Mobile Application Locking Device Development Tools Project objectives Work methodology Work planning Web server application requirements Android application requirements Locking device requirements Planned Schedule Followed Schedule

20 INGENIERO EN TELEMÁTICA THESIS INDEX 4.6 Project Cost Estimation Chapter 5 System Implementation Web server Application Database Communication between the database and the servlets User Interface Information flow Phone Application Activities Bluetooth class Locking device Overview Command data flow Chapter 6 Conclusions and future work Results Future Development Chapter 7 References APPENDIX A: Final user interface for the web application APPENDIX B: Final user interface for the phone application

21 FIGURE INDEX Figure Index: Figure 1: Technologies Used Figure 2: Tecnologías usadas Figure 3: Examples of the access control methods explained Figure 4: Reviews of Danalock and Lockitron from amazon.com Figure 5: Architecture of the system Figure 6: Model view controller Figure 7: Iterative and Incremental Model Figure 8: First web application user interface Figure 9: Final web application user interface example Figure 10: Confirmation message example Figure 11: UserLoginActivity view Figure 12: AccessActivity, Access validation view Figure 13: AccessActivity, access validated view Figure 14: Lock management flowchart Figure 15: Login Screen Figure 16: Manage Users tab Figure 17: Manage Users tab after selecting create or update Figure 18: Manage Permissions tab Figure 19: Manage Permissions tab after selecting add or change Figure 20: Manage Locks tab Figure 21: Manage Locks after selecting add or change

22 FIGURE INDEX Figure 22: Show Accesses tab

23 TABLE INDEX Table Index: Table 1: Initial Planning Table 2: Cost estimation of the followed schedule

24 CODE INDEX Code Index: Code 1: JavaScript function used for Ajax technology Code 2: DAO use example

25 INTRODUCTION Chapter 1 INTRODUCTION In this first chapter the present we will talk about what is access control, the present situation and the solution proposed. 1.1 DEFINITION Access control is a system which enables an authority to control access to areas and resources in a given physical facility or computer-based information system [5]. This systems determine who, where and when. Who is allowed to enter or exit, where they are allowed to exit or enter and when they are allowed to exit or enter. 1.2 PRESENT SITUATION Nowadays the access control has become so common that we are not even aware of it. Every time we enter home or our car, we use a key and every time we use our computer we have to log in. This increase in the use of access control has been affected by new technologies and incorporated to companies. Probably the most used system in this environment are: 1. Magnetic Cards: They use an outdated technology from the 60 s but the system is cheap to implement and it works well for daily life. The problem comes when someone with bad intentions and enough knowledge tries to access. Since the 25

26 INTRODUCTION system is more than fifty year old and the information may not even be encrypted it can be overridden and an unauthorized user can gain access. 2. Biometric systems: They are based on the uniqueness on every person. They take one of our biologic characteristics that is unique like, for example, the fingerprint or the retinal blood vessels scan it and compare it to a previous sample. This systems are really safe but, since you need accurate and complex scanners, much more expensive. 1.3 MOTIVATION OF THE PROJECT The current situation shows that if you are dealing with sensitive equipment or information and you need high security access control you will need to expend a lot of money in, for example, biometric scanners. Nowadays there are a lot of smartphones equipped with various biometric scanners such as face recognition or fingerprint scanners. Why not using them as biometric scanners? The hypothetical company would be saving a lot of money and if the company was using magnetic cards it will be also good for the users because they wouldn t have to worry about an extra card. Another factor that motivated us was being innovative, as it is said in the State of the Art chapter, there are some companies working on using smartphones for access control but they are focused houses instead of companies. Our system has a monitoring and administration module for managing multiple locks and users at the same time. It is also universal, it uses extended technologies in order to be usable by as many different devices as possible. 26

27 INTRODUCTION 1.4 OVERVIEW OF THE PROPOSED SOLUTION This project consist of three main parts: 1. The lock device is an Arduino board with some hardware attached to it. Part of theses hardware is a small lock that can be opened or closed. The design is not focused on finding the strongest or most appropriate lock or the most adequate shape to work on every door. It is focused on making the whole system work from a software developing point of view not from a mechanical point of view. 2. The phone application is an Android application that will allow the authorized personnel to prove their identity and open locks. The unauthorized personal will also have the opportunity to ask for access to a certain area by sending a message to the security administrator. 3. The web application will be used by the security administrator to stablish who has access to where and monitor all the accesses to all the locked areas. The administrator will also have the possibility of receiving a message of someone that needs access and grant the access for once, for now on or don t grant it. 27

28 TECHNOLOGIES USED Chapter 2 TECHNOLOGIES USED This project tries to use smartphones as access control tools. This is not a new idea but we are using it in a new field. It has been used mainly for controlling the access to private homes, our idea is using it in a company s environment with a lot of users at the same time. In order to do so, our development has been focused around two concepts: Universality: The systems that are in the market have problems of compatibility with certain phone models or brands. Our objective is to make a system that works in almost all the phones in the market. Administration module: A tool that can help administrators to manage a lot of users at the same time and know where and when they are accessing. This two ideas have determined all the technologies that we used. They will be explained divided into the following four general categories. 2.1 WEB TECHNOLOGY We have used web technology to develop an administration module that manages all the company access control: all the rooms, the workers and the permissions. This tool is a web application that is supposed to be only used by the administrators of the system and it has to be comfortable to work with. In order to achieve this we incorporated the following characteristics: 28

29 TECHNOLOGIES USED Simple Interface: Making the web application user friendly and allowing the administrators to work faster and in a more efficient way. Responsive Design: The web application should adapt to any device, sometimes working on a tablet might be more comfortable for the administrator. Fluent Design: Dynamism has been used in order to hide all the information that is not needed and show it when it is. Modular Design: This way of programming guarantees that it is easy to add new functionalities to the web application without interfering with the ones already present. The most important specific technologies used in the development of the web application are the following: Ajax (Asynchronous JavaScript And XML): is a group of interrelated web development techniques used on the client-side to create asynchronous web applications. With Ajax, web applications can send data to and retrieve from a server asynchronously (in the background) without interfering with the display and behavior of the existing page. This technology has been used specifically to update specific parts of the information shown to the user without loading a new web page. In order to use this technology we have been using the following JavaScript function: 29

30 TECHNOLOGIES USED function peticionajax(url, iddiv) { var xmlhttpreq = new XMLHttpRequest(); xmlhttpreq.onreadystatechange=function() { if (xmlhttpreq.readystate == 4 && xmlhttpreq.status==200) document.getelementbyid(iddiv).innerhtml = xmlhttpreq.responsetext; } } xmlhttpreq.open('get', url, true); xmlhttpreq.send(); Code 1: JavaScript function used for Ajax technology JSTL (JavaServer pages Standard Tag Library): It is tag library part of the Java EE 5 platform that encapsulates as simply tasks the core functionalities common to many web applications. It has support for common, structural tasks such as iteration and conditionals, tags for manipulating XML documents, internationalization tags, and SQL tags. It also provides a framework for integrating existing custom tags with JSTL tags. The library version used in the project is and it has been used for data manipulation in JavaServer Pages (JSP) following the 2.1 specification, in other words, to simplify the code by using JSTL tags instead of Java embedded code and make it understandable for non-java programmers. JDBC (Java Database Connectivity): It is an Application Programming Interface (API) used as industry standard for database-independent connectivity between the Java programming language and a wide range of databases. It also provides a call- 30

31 TECHNOLOGIES USED level API for SQL-based database access. The library used in the project is MySQL JDBC Driver version and the main purpose was for storing, retrieving and updating user, permission and access information. Bootstrap (version 3.3.4): It is a really popular framework designed to support the development of dynamic websites and web applications. It provides a set of CSS classes and JavaScript functions that we used for developing a clean, dynamic and responsive user interface. 2.2 SMARTPHONE TECHNOLOGY The smartphones will be used by all the workers to gain access to a room where they are permitted. We decided to use them because they are equipped with hardware and software that allows them to check if a person is who he or she claims to be. They are able to do facial recognition and some devices can even do fingerprint scans. After taking this decision, the next question is: What operating system? Android has been the chosen one because it is widely used, Jorge is familiarized with the programming language and we both have Android devices that we can use for testing. For the phone application development we also used GitHub (version 1.9.5) for sharing code and version control. GitHub is a web-based Git repository hosting service, which offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its own features. Unlike Git, which is strictly a command-line tool, GitHub provides a web-based graphical interface and desktop as well as mobile integration. It also provides access control and several collaboration features 31

32 TECHNOLOGIES USED such as wikis, task management, and bug tracking and feature requests for every project [1]. 2.3 MICROCONTROLLER TECHNOLOGY The locking device has to send and receive information from the user s phone and it has to take decisions based on this communication. To do so, it needs a microprocessor. It also needs to be connected to a Bluetooth module and power supply, the simplest solution was a microcontroller. The chosen one was the Arduino Uno and the reasons where: An Arduino device was chosen because we both have extended experience with the C programming language and this devices allows you to use it. The Uno model was chosen because we did not need a lot of functionality and we wanted a low-coast solution. Here is a brief description of the microcontroller: The Arduino Uno is a microcontroller board based on the ATmega328. It has 14 digital input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, a 16 MHz crystal oscillator, a USB connection, a power jack, an ICSP header, and a reset button. It contains everything needed to support the microcontroller; simply connect it to a computer with a USB cable or power it with a ACto-DC adapter or battery to get started. The Uno differs from all preceding boards in that it does not use the FTDI USB-to-serial driver chip. Instead, it features the Atmega8U2 programmed as a USB-to-serial converter. [6]. 32

33 TECHNOLOGIES USED 2.4 COMMUNICATIONS TECHNOLOGY For the communications we have decided to use Bluetooth and Wi-Fi. As we have said earlier in this chapter we want our system to be able to work with as many different devices as possible. For this reason, we are using the simplest and most extended technologies. Now we will explain what are they and how are they used: Bluetooth: It is a wireless technology used for exchanging information over short distances, about tens of meters. As it is said in their website: Virtually all mobile and smartphones already include Bluetooth technology [7]. In this project it has been used for communication between the smartphone and the locking device Wi-Fi: It is a local area wireless computer networking technology that allows electronic devices to exchange information using a common network. It is also really common, as we can read in the Huffington Post. 90% of all smartphones are equipped with Wi-Fi capabilities. [8]. Some of the specific technics or technologies that we used for the communications are: Android.bluetooth package: It is a package for android programming that provides a set of classes and methods to manage Bluetooth functionalities such as scanning or connecting devices and exchange of information. We used it for the communication between the lock device and the android phone application. JSON (JavaScript Object Notation): An open standard format that uses humanreadable text to transmit data objects consisting of attribute value pairs. It is used primarily to transmit data between a server and web application. This format allows 33

34 TECHNOLOGIES USED us to create the lightest objects, ideal for small exchanges of information. This property makes this format ideal for the communication between the phone and the server. The library used is GSON (version 2.3.1): It gives you a set of functions for JSON object manipulation and provides simple methods to convert Java objects to JSON and vice-versa. 34

35 STATE OF THE ART Chapter 3 STATE OF THE ART The actual solutions to the problem we are dealing with, the access of just authorized people to a facility, are numerous. Some of the most used are the following: Physical barriers and security personnel: This method is obviously the safest one, there are few access points to the facility and they are constantly watched. Someone can still get a fake permit or trick the guard but this will probably be extremely hard and risky. The main problems of this systems are the following: o It is expensive, you have to periodically pay all the security guards. o It might be non-viable in some cases, for example, you cannot have a guard for every lab and classroom in a university. Biometric scanners: This scanners can be installed in the entrance of any door and allow only authorize personnel inside. They scan one of our unique biological characteristics, for example a fingertip, and compare it with a previous sample to check if you are who you say. The problems of this systems are: o It is expensive, one biometric scanner is needed per each door that wants to be secured and the price of an average scanner is around 80 euros [4]. o If a system has problems with the authentications, for example, false positives or negatives, the passwords can be changed. In a biometric system it is impossible, fingerprints or retinal patterns cannot be changed. Magnetic cards: This is probably the most used system. Every user has a magnetic card that allows him to access all the rooms where he or she is permitted, in order 35

36 STATE OF THE ART to do so he just has to swipe his card in the card reader. This system is cheaper than the others but it also has problems: o It is not safe at all, it uses technology developed in the 60 s that uses plain text and sometimes not even the simplest encryption. o Since it is the most extended, it is relatively easy to find information about how to bypass the system or even create master keys. Main entrance of the Air Force base in Amarillo Texas Biometric fingerprint scanner Magnetic card scanner Figure 3: Examples of the access control methods explained There are also other solutions that try to use smartphones as access control methods. Some companies have developed phone applications that allow authorized personnel to open doors. The problems of this apps are the following: Focused on private houses: The systems are meant to be installed in a home, they are not practical for a work environment with many doors to control and many users to access them. 36

37 STATE OF THE ART Compatibility: They do not work in every smartphone, a lot of people is experiencing unacceptable problems such as: o Waiting periods of more than two minutes to open a door. o Partial access to de customization options of the applications. o Not being able to open any door. Examples of this phone applications are Danalock or Lockitron. Danalock has 2.8 stars and Lockitron 2.2, both of a total of 5 stars in amazon.com [9]. Some reviews can be seen in the following figure: 37

38 STATE OF THE ART Obtained from: Amazon.com, Danalock Obtained from: Amazon.com, Lockitron (Piano Black) Figure 4: Reviews of Danalock and Lockitron from amazon.com 38

39 SYSTEM DESIGN Chapter 4 SYSTEM DESIGN 4.1 OVERVIEW Figure 5: Architecture of the system Users are provided with dynamic access keys generated and managed by the server. The keys can then be used to access the different areas in the facilities. The access keys are validated by an automated door lock that communicated to the mobile application. The 39

40 SYSTEM DESIGN application allows users to gain access to the different areas in a facility or building. A door lock with Bluetooth capability is able to grant access to users that possess a valid access key. A user that wants to use our system must first login in our system and act as administrator granting the desired level of access to all his workers using the web application. Once the permissions are all set, all the users are going to be able to use the lock. The first step is login, then put the phone close to the lock and press open. If the user is not allowed by the lock he can request access and the administrator can use the web application to let him in once or upgrade his permissions. The automated door lock has a unique identifier based on the specific location. The user received the appropriate access keys according to his level of authorization. Access can be granted after the user permissions are validated WEB APPLICATION The web application provides an interface for access management throughout the facilities. Allows user to see which locations have been accessed and by who. It allows key and permissions management to the administrators of the system MOBILE APPLICATION The Android based mobile application provides an interface for user to manage access keys and locate areas in facility. The application stores keys and communicates with server that 40

41 SYSTEM DESIGN manages all the system keys. It communicates to door lock via Bluetooth interface and provides access if available LOCKING DEVICE The smart lock provides access to areas in the facilities. It is microcontroller based device with Bluetooth connectivity and lock actuators to open and close doors. The lock communicates with mobile application to check if user has access to the pertaining area. When connection is established, it provides a unique ID for the location to the mobile device which then checks the key availability. An access code is sent to lock in order to grant access in the valid case, denies access otherwise. 4.2 DEVELOPMENT TOOLS The main languages used to develop the web application were: Java, for backend code, responsible for algorithm execution; HTML, for presenting the information to the user; CSS for describing the look and formatting the information presented to the user; JavaScript, for interacting and communicating asynchronously with the user and SQL for saving and retrieving data from the database. In the case of the phone application the language used was also Java using android API s. For the locking device the language used was C, using Arduino libraries for Bluetooth connections. The software used for the web application was: NetBeans IDE (versions 7.4. and 8.0.2) for writing the code because we were already familiar with it; Google Chrome (version m) for testing because it has really powerful and easy to use developer tools 41

42 SYSTEM DESIGN and HeidiSQL (version Portable ) for database construction and manipulation because of its simplicity. For the phone application we used Android Studio (version ) to write all the code because it is the tool recommended by Google. For the locking device the software used was the official Arduino software (portable version 1.6.5) because it is necessary to upload the code to the Arduino Uno board. Since both application have to do complex operation and, at the same time, be able to show results to the user, the software architecture used is the Model view controller (MVC). This architecture divides a given software application into three interconnected parts: a models, set of Java classes that define all the elements in your design; controllers, set of Java classes that manipulate all the information in order to obtain the desired information (servlets and activities) and views, set of HTML pages that may have embedded Java code and show to the user the information obtained by the controller (JSP or XML interfaces). 42

43 SYSTEM DESIGN Figure 6: Model view controller 4.3 PROJECT OBJECTIVES The main objective of this Project is to create a system that allows you to control the access of personnel to certain rooms. This general objective can be dissected into the following specific objectives: Development of a locking control device that controls a lock and is able to communicate with a phone application. When the locking control device receives a certain signal it will open the lock. 43

44 SYSTEM DESIGN Development of a phone application that is able to: o Communicate with the locking control device. In case that an authorized user is trying to open the lock, the lock should open and in other case the lock should stay closed. o Communicate with the server to check the user credentials and know what locks does he has access to. o Send to the server all the information about the accesses of the user. o Send to the server a message asking for access to a restricted area in case of need. o Receive a message from the server in case that some of the permissions that the user has have been updated. Development of a web application that is able to: o Check the credentials of the user trying to access and let him use the application just in case he is an administrator. o Create and delete users. o Update the credentials of any user. o Monitor all the accesses of all the users o Receive a message from a user asking for access to an area where he is not authorized and give him a temporal or permanent permit. Make sure that both developed applications are user friendly and easy to use. We want to make a tool accessible for everyone and make the users life easier. Make sure that the system can be used in two different ways. One centered in security and another centered in easy access. If our system is used to protect valuable investigations the security way would be the most adequate if it is used 44

45 SYSTEM DESIGN to lock labs in a university the easy access way would be used. The first one asks for extra information to the user and the second one does not. 4.4 WORK METHODOLOGY The methodology followed to develop the whole project has been a combination of the iterative method and the incremental build model for software development. In other words, we have developed our system through repeated cycles and at each cycle design modifications are made and new functionalities are added. Figure 7: Iterative and Incremental Model 45

46 SYSTEM DESIGN The main reasons that made us follow this development methodology where: Having, since the first moment, a prototype with some functionalities so we could evaluate and test our software in order to make sure that the functionalities incorporated each week where working and compatible with the functionalities already coded. Being able to face the communication between devices as soon as possible. During our first meeting we both agreed in the importance and difficulty of this task so we decided to follow this methodology in order to have some time to think in ways of stablish communication but being able to test them as soon as possible. Following this methodology would make debugging much easier, if suddenly the prototype stops working the error must be in the last added functionality. 4.5 WORK PLANNING The first thing we did to face each of the tasks was making a list of all the different requirements WEB SERVER APPLICATION REQUIREMENTS In the case of the web server application the requirements are the following: Decide how all the possible screens should look like. 46

47 SYSTEM DESIGN Decide the objects we are using and the attributes they have Make a database to save all the data. Work on the login screen. Work on a user manipulation servlet and a jsp that will be shown once you are logged in. The objective of the servlet is to create, update and delete users in the database. Show the information of the user s accesses in a jsp. Acting as a server in the communication between the phone application, the computer application and the locking device. Send the number to unlock a certain lock to a phone user. The number must be shown in the screen. Add the possibility of sending a message from the phone application to the computer application to ask for a change in the users permissions. Aesthetic improvement using some online tool such as bootstrap ANDROID APPLICATION REQUIREMENTS In the case of the android application the requirements are: Decide how many activities we are going to have. Decide the basic appearance and function of each activity. Being able to send a request for accessing a certain lock Being able to manage a response from the server and send the corresponding request for access to the lock using Bluetooth. Respect the Android guidelines and design principles. 47

48 SYSTEM DESIGN Have the possibility to send a request for access to the server if the user has no permission to access a certain lock LOCKING DEVICE REQUIREMENTS For the locking device the requirements were really simple because we want the logic to be managed in the phone and the server, the lock just has to check if the access code received is correct, in other words, it receives a key number from the android application and checks if it is the key that opens the lock. If it is, the lock opens, if it is not, nothing happens PLANNED SCHEDULE Once we both knew the main parts of our main responsibilities we divided the work in different weekly activities so the team members can work simultaneously in different tasks. During our meetings we can check the progress and work together in case one of the members is facing a difficult task or just does not know how to solve a problem. The following table contains the plan that we tried to follow: Activity Start Date Finish Date Separation and definition of duties

49 SYSTEM DESIGN Take the initial decisions for both applications: objects to use available screens and options Create a database to save the important data and develop a login screen in both applications Add the following functionality, the administrator is able to create delete and update users information Establish communication between devices and display the access information Send an access number from the computer to the phone and show it on the phone screen Add the possibility of getting permissions with a message to the computer Aesthetic improvements

50 SYSTEM DESIGN Extra week in case of unpredicted problems Learning how to use all the software libraries provided by the peripherals manufacturer Write simple C program to open the lock Improve the C program until lock is fully operational Final modifications Table 1: Initial Planning FOLLOWED SCHEDULE We tried to follow the established plan but we had to do slight modifications because of deadlines and hard tasks that took more than the expected. The schedule followed ordered per week is the following: Week 1: Separation and Definition of duties. We established that I will mainly work on the web application and he will be focused on the phone application. The main reason of this task division is saving time using parallel development. When we have a usable prototype we will start working on the lock device. 50

51 SYSTEM DESIGN Week 2: Overview of the project and decide what classes and attributes are needed. As result of this phase we elaborated a project proposal for our thesis director. Week 3: Development of an SQL database, all the classes needed for a simple login in the web application and an activity based on a template for a simple login in the phone application. Week 4: Add functionality for adding, removing and updating user information in the web application and improvement of the login activity in the phone application. Week 5: This week we were completely focused on finding a way to establish connection between both applications. The best way we found was using the HTTP protocol for requests and JSON objects as responses. Week 6: Add functionality for managing permissions in the web application. Unable to finish due to problems with class date. Add code for managing the communication in the phone app. Week 7: Finish the permission management, adding Ajax technology and working on server-side communication in the web application. Improvement of communications in the Android app, mainly bug correction. Week 8: Final improvements for a working prototype with the basic functionalities. Development of simple user interfaces and extensive testing and bug correction in both applications. Week 9: Development of final user interfaces in both applications and adding final functionalities: lock management and showing accesses in the web application. In the android application, Bluetooth communication. 51

52 SYSTEM DESIGN Week 10: Working on the lock, Development of the C code and the Arduino physical connections. Week 11: Final testing, error correction and adding the last functionality, two different levels of security. 4.6 PROJECT COST ESTIMATION This section shows the cost estimation based on the followed schedule. It has some variations from the initial on and we are going to use it to estimate the price of the project. For the price estimation we have used the average salary in the city of San Diego, CA. The salary of a junior android developer is $39.5 per hour and the salary of a junior java developer is $10.6 per hour [2]. Week Hours Android Hours Web Cost 1 5h. 5h. $ h. 8h. $ h. 10h. $

53 SYSTEM DESIGN 4 5h. 15h. $ h. 5h. $ h. 15h. $ h. 16h. $ h. 25h. $ h. 25h. $ h. 5h. $ h. 8h. $84.8 TOTAL: $ Table 2: Cost estimation of the followed schedule 53

54 SYSTEM IMPLEMENTATION Chapter 5 SYSTEM IMPLEMENTATION 5.1 WEB SERVER APPLICATION DATABASE The system uses only one database called keyuseraccess that is divided into four tables: login: contains all the information that a user needs to have in order to exist in the system. The attributes are the following: o userid: String use to identify a user. o password: String used to access the phone application and, if the user is an administrator, the web application. o administrator: Boolean that is true when the user is an administrator and false otherwise. In SQL there is no boolean type, in order to get the same behavior we created it as a one bit tinyint. lockinfo: stores the parameters of each lock: o lockid: integer that uniquely identifies each lock. o accessnumber: integer between 0 and 999 used by the phone application to open a certain lock. 54

55 SYSTEM IMPLEMENTATION o securitylevel: integer value between 1 and 3 that indicates the security level of the lock. 1 being any user with the phone app and permission could get in, 2 being the user needs to input an extra 4 digit pin to get in and 3 meaning the user needs to pass some kind of biometric scan in order to get in. useraccess: This table has all the information that we save every time a user uses a lock. o userid: As in previous table, String use to identify a user. o lockid: As in previous table, integer that uniquely identifies each lock. o timeofaccess: Timestamp value that represents the exact time when the user accessed. userkey: contains the information associated with the permissions that every user has. o userid: As in previous table, String use to identify a user. o lockid: As in previous table, integer that uniquely identifies each lock. o timeofcreation: Timestamp value that shows the exact time when the permission was created. o timeofexpiration: Timestamp value that represents the exact time when the permission will stop to be valid. 55

56 SYSTEM IMPLEMENTATION The attributes and tables listed are the final ones. At the beginning we thought that all the attributes that contain time should be Date values instead of Timestamps. Early in the development we noticed that a lot of the methods needed to manage our time values where deprecated. After some research the solution was clear, Timestamps. The fact that this type is available in Java and SQL and the way this variables measure time makes them ideal. They count the milliseconds elapsed since the first of January As a consequence, you can get milliseconds accuracy and do not need extra code for object parsing COMMUNICATION BETWEEN THE DATABASE AND THE SERVLETS For this communication we are going to be using a DAO class. This class allows you to create Data Access Objects that provides an abstract interface to a database. By mapping application calls to the persistence layer, DAO provide some specific data operations without exposing details of the database. In other words, a data access object provides you with all the Java methods that you may need to interact with the database without knowing any detail about how the database works. The DAO is used in this project because it provides a separation between application and database by acting as an intermediary. As a consequence, any change in the database would only affect the DAO class and if the persistence logic changes but the interface remains correctly implemented the project can still use it. An example of how the DAO is used can be seen in the following code: 56

57 SYSTEM IMPLEMENTATION Here is an extract from the DAO class UserDAO.java: private static final String QUERY_ADD_USER = "INSERT INTO login(userid,password,administrator,pin) VALUES (?,?,?,?);" ; public void createuser(string user, String password,int pin, boolean admin)throws SQLException { PreparedStatement ps = c.preparestatement(query_add_user); } ps.setstring(1, user); ps.setstring(2, password); ps.setboolean(3, admin); ps.setint(4, pin); ps.executeupdate(); ps.close(); Here is an extract from the UserManagement.java servlet where the DAO is used: UserDAO udao = new UserDAO(); udao.createuser(manageduser, password,pin, admin); Code 2: DAO use example USER INTERFACE There has been two main prototypes for the user interface of the Web Application. The development started focused on functionality, as a consequence the first user interface was meant to show everything at the same time and keeping the elements as simple as possible for testing purposes. 57

58 SYSTEM IMPLEMENTATION Figure 8: First web application user interface The second user interface was developed after all the basic functionalities were working. We used the Bootstrap framework already explained in Chapter 2. The only new functionality that this interface includes is the possibility of managing the lock information and the reason is that we decided to add it in the final stages of the development. The following figure shows one of the tabs, to see the complete UI go to Appendix B. 58

59 SYSTEM IMPLEMENTATION Figure 9: Final web application user interface example The final version of the UI also included confirmation and error messages that are shown in different situations. For example, if the user creates, updates or removes successfully a user, a lock or a permission a confirmation message appears below the navigation menu: Figure 10: Confirmation message example 59

60 SYSTEM IMPLEMENTATION INFORMATION FLOW This section explains all the implemented functionalities and how are they coded without going into too much detail. The goal is explaining the flow of information and the actions taken in each circumstance. Once the user has logged in, he or she has the freedom to go to a different tab by clicking in the navigation bar buttons. We will assume that the user clicks all the buttons from the left to right. The first thing an application administrator does is input in the login screen (Figure 15) his username and password and then the login information is sent to Login.java. This servlet verifies the information with the database and in case it is correct the next servlet, UpdateAccessses.java, is executed. Otherwise the user will be redirected back to the login screen again. UpdateAccesses.java retrieves all the accesses information from the database in a collection and then put it as an attribute of the application context. Since the accesses are a piece of information common to every user and process in the application it should be in the application context so it is always accessible. Once the servlet has done its job the user is redirected to the Manage Users tab (Figure 16). Now the user has three options: create, update or delete a user. The information is redirected to UserManagement.java. If remove was the option selected, this servlet executes the removeuser(string userid ) method from the UserDAO.java class in order to remove the user and then redirects the administrator to the same tab where it was, but this time there is also a message that indicates that the user was successfully removed. If the user selected update or create the administrator is redirected to another HTML form that 60

61 SYSTEM IMPLEMENTATION requires more information to be filled in (Figure 17). The same servlet (UserManagement.java) is going to take the new information and add or update the database. Once this is done the administrator is redirected to the Manage Users tab (Figure 16). If the user tries to update a non-existing user or create an existing user a warning will be displayed to tell the administrator that the user will be created or updated in each case respectively. For the Manage Permissions and the Manage Locks tabs the information flow is the same as in the Manage Users tab. The only difference is the name of the servlets, instead of being UserManagement.java is PermissionManagement.java and LockManagement.java respectively. Every time we click the Show Access tab the UpdateAccess.java servlet is executed and, as it has been explained earlier, the accesses are retrieved from the database and saved in the application context. The view associated with this servlet retrieves a collection that contains all the accesses from the application context and then iterates the collection inserting each access data in a row of the table (Figure 22). The information that flows from the administrator to the system is not the only one, there are also multiple phone app clients exchanging information with the server. This communication is different, the users send information as parameters in a URL instead of using HTML forms and receive JSON objects instead of JSP pages. Every user first executes the following link filling the example spaces: ServerIP:8080/Bluetooth_Lock/LoginPhoneUser?user=example&password=example. As a consequence the servlet LoginPhoneUser.java executes and compares the information 61

62 SYSTEM IMPLEMENTATION provided with the one in the database deciding if the user is allowed in the system or not. This decision is in the JSON object send to the phone application. If the user is allowed the attribute userok of the object is true, otherwise it is false. Not allowed users are redirected to the login screen in the phone app and the allowed users are now able to request access. When the phone user requests access the app executes another URL: IP:port/Bluetooth_Lock/GetKey?user=example&lock=N. Then, the servlet GetKey.java processes the information received and checks in the database if the user has permission and the security level required by the lock. If the user is not permitted he receives a message denying access. If he is permitted the next step depends on the security level, if it is 1 that means low security, the user should receive the key code. If it is 2, extra identity confirmation is needed, a text input appears so the user can input his pin. Now the app executes another URL for pin validation: IP:port/Bluetooth_Lock/PinValidation?user=example&pin=1111&lock=N. Once the server receives all the information, it sends the key to the user. 5.2 PHONE APPLICATION ACTIVITIES The application is composed of several activities in charge of controlling the existing views of the application, perform the data operations, and handle request to the server. Activities inherit methods relating to the application life cycle. 62

63 SYSTEM IMPLEMENTATION UserLoginActivity The user login activity is in charge of performing user validation against the server. Its view provides input fields for Username and Password and a login button to perform value submission. The username field allows the user to enter a unique name identifier string registered in the main database. The password is a protected string. Validation of the user and the required field is divided into local and external procedures. Local or internal procedure validates that the values entered does not contain special characters and that the password field is longer than 4 characters. An asynchronous Task is used to perform the needed network operations. This allows the request process to execute in a separate thread from the UI thread. The task is created with three parameters: username, password, and request URL. These parameters are passed from the activity class when the login button is pressed. Once the task is instantiated, it is executed with the execute() method. The execute() method calls the doinbackground() which performs the network operations and return a Boolean value with after processing the response. An HTTP request handler class is used to create a connection with the server. It gets the input stream after a GET operation is performed and then creates a string of the data received. The data string can then be used to create a JSON object in order to access the attributes contained in the response. The value returned by the doinbackground() method is either true or false. A false value is returned in two cases. The first is in the case of thrown exception in either of the two try- 63

64 SYSTEM IMPLEMENTATION catch blocks from the HTTP request or the JSON object instantiation. The second happens if the attribute userok is false. The method return true only if the server response contains a true userok attribute. The onpostexecute() method receives the returned value from the server and determines if the response is valid. If a invalid response occurs, the activity notifies the user if the credentials are incorrect. The user can re-enter the credentials and repeat the process. If a valid response is received, the activity finishes and starts the MainActivity storing the username. 64

65 SYSTEM IMPLEMENTATION Figure 11: UserLoginActivity view MainActivity An HTTP request handler class is used to create a connection with the server. It gets the input stream after a GET operation is performed and then creates a string of the data received. The data string can then be used to create a JSON object in order to access the attributes contained in the response. 65

66 SYSTEM IMPLEMENTATION AccessActivity The AccessActivity server as controller to the access operations, communicating with the server and the locking device to maintain synchronization. The view shows the status of the access operations providing an interface showing invalid or valid access attempts. Figure 12: AccessActivity, Access validation view 66

67 SYSTEM IMPLEMENTATION During the oncreate() method of the activity, an instance of the Bluetooth class is created with the name mbluetooth. The activity connects to the Bluetooth device when the onresume() method is called in the application life cycle through the connectservice() method. The method connect service performs the needed operations to connect with the device, as detailed in the Bluetoooth class section. The Bluetooth adapter is accessed using the BluetothAdapter.getDefaultAdapter() method which returns a handle to the local device Bluetooth adapter. If the adapter is enabled, the start() and connectdevice() methods are called which initialized a the connection with the Bluetooth device. The access activity has an instance of a Handler object that handles alerts and receives data from the Bluetooth service threads. Once the activity has received a successful connection call, it can then begin the server request for an access code. An AsyncTask inner class is used again to handle the operations on the network, such as the one used in the UserLoginActivity. The class receives two three parameters: the username stored from successful login, the lock ID number given when connection is detected with the locking device, and the request URL. The task performs the background operations on the doinbackground() method. It makes the request using the same HTTPRequestHandler class used previously during login which, in case of a valid connection, results in a string representation of the response. In the case of an invalid response, an IOException is thrown. In the case of a thrown exception, it can be catch and return a false value and passing it to the onpostexecute() method as a parameter. The same catch block logic applies when creating a JSON object from the string response by the server. The JSON object is instantiated and the attributes accessed, all performed in 67

68 SYSTEM IMPLEMENTATION the try-catch block. If there is an error when instantiating the object with the string response or an attribute is non-existent in the string, a JSONException is thrown and catched returning again a false value to the onpostexecute() method. If no exception is thrown during this execution, a true value is return from the doinbackground() method, meaning that there was a valid network operation. A variable is assigned with the accesskey value from the JSON object to be used later by the Bluetooth service. The onpostexecute() method receives the parameters returned by the doinbackground() method. If the parameter received is false, it alerts the user that there was a problem with the request that the access in invalid. If the parameter is true, the security level attribute is used to determine if further user action is needed. In the case of a security level of one, the value in the access key variable is sent to the Bluetooth service to be encoded and sent through the output stream to the locking device. In the event of a security level of two, a dialog appears in the screen prompting the user to enter their unique four characters Personal Identification Number. On submitting the required PIN, pin is validated and the access code is sent as through the Bluetooth connection. Once the locking device process the data sent from the application, indication to the user appear on the screen showing a valid or invalid entry to the access point. 68

69 SYSTEM IMPLEMENTATION Figure 13: AccessActivity, access validated view BLUETOOTH CLASS The android platform provides support for Bluetooth networking in order to exchange data with other Bluetooth devices. BluetoothAdapter is the major class controlling Bluetooth process. It provides methods for discovering Bluetooth devices and creating a server socket to listen for communication from other devices. 69

70 SYSTEM IMPLEMENTATION For the application to use Bluetooth features, the Bluetooth permission must be stated in the application manifest. The Bluetooth class contains two main threads that perform the Bluetooth communication: The connectthread: Tries establishing a connection with the external device, and if successful, return a state change back to the activity signaling that a connection has been established. The connectedthread: Runs to manage incoming and outgoing communication from the application to the external device. It runs a server loop waiting for messages to be received from an input stream. A buffer is used to receive the incoming data that can then be decoded into valid or invalid messages. If a valid message is received by the device, an alert is passed to the handler to be used in the activity. 5.3 LOCKING DEVICE OVERVIEW The first locking device prototype was implemented using an Arduino Uno that is connected to a serial Bluetooth module HC-06. The device is in charge of communicating with the mobile application through a Bluetooth communication channel in order to exchange data relating to the access status of an area. The devices has an encoded ID that 70

71 SYSTEM IMPLEMENTATION is used to describe a unique area in a facility. An access key is also stored that can be mapped to the data received through the Bluetooth connection COMMAND DATA FLOW An access code is assigned to the Arduino. The control loop waits for incoming messages received through the serial Bluetooth port. Serial communication is achieved using the SoftwareSerial library, which provides emulation of the hardware UART connection to the other I/O, pins in the microcontroller. Incoming data through the serial stream is decoded to be used by the message handlers. Upon receiving a data, the controller will verify if the access key provided is valid or invalid and then perform the needed actions to allow access. If the access key received is valid, the device will notify the application signaling a valid access code and then it output a signal to control the locking mechanism. Once the access key is validated by the device and the mechanism signals entry, it renters the loop to listen for incoming data. 71

72 SYSTEM IMPLEMENTATION Initialize Variables Wait for serial data Is the key valid? YES Open lock and notify phone application NO Figure 14: Lock management flowchart 72

73 CONCLUSIONS AND FUTURE WORK Chapter 6 CONCLUSIONS AND FUTURE WORK 6.1 RESULTS At this stage, the mobile application is able to communicate to both lock and server. The web application allows user to manage lock permissions and register entry to a certain area. The implementation as a proof of concept of a dynamic key generation system shows the possibility of having more efficient and maintainable access control systems. Despite being an early stage concept, the implementation shows improvement to the systems being used at this moment. 6.2 FUTURE DEVELOPMENT This project is the first approach to an idea. We tried to design a cheap and easy to use locking device and we made it work, but there is still a lot of work to be done in order to improve the system and make it good enough for commercialization. We were mainly focused on the software side of the system. As consequence the communication and application development works really well but there is a lot of functionalities that could be added on top of our work. Interested students from other degrees may also have ways to keep improving the system. Some of the future improvements are: 73

74 CONCLUSIONS AND FUTURE WORK Integrate device with locking mechanism: We used a LED light to demonstrate the locking mechanism. If we want to keep developing the tool we will need a strong lock that changes from open to close when it receives the proper signal. Design a case and the best hardware for the lock: Currently we are just using an Arduino board and a Bluetooth module. Other microprocessors might work better and other technologies like NFC might be safer. Implement extended functionality in the applications and improve the user interface: An example of this could be: o Developing a phone version of the web application and a web version of the phone application, in case the administrator has no access to a computer or the user does not have his phone. o Develop and ios version of the phone application. Add more security levels: A third level of security could be: o Finger print scan o Face recognition with the camera. 74

75 REFERENCES 75

76 REFERENCES Chapter 7 REFERENCES [1] Williams, Alex (9 July 2012). "GitHub Pours Energies into Enterprise Raises $100 Million From Power VC Andreessen Horowitz". Tech Crunch. [2] This information comes from indeed.com, a website used in the United States to find out salaries. [3] Stack Overflow a website for questions and answers related with programming. http: [4] Prices found on amazon.com for the US price and amazon.es for Spain. [5] Information obtained from http: http: [6] Arduino Uno datasheet. [7] Bluetooth technology website. Market.aspx. [8] Huffington Post newspaper s website. [9] The reviews and stars were obtained in from: and 76

77 APPENDIX A 77

78 APPENDIX A APPENDIX A: FINAL USER INTERFACE FOR THE WEB APPLICATION Figure 15: Login Screen Figure 16: Manage Users tab 78

79 APPENDIX A Figure 17: Manage Users tab after selecting create or update Figure 18: Manage Permissions tab 79

80 APPENDIX A Figure 19: Manage Permissions tab after selecting add or change Figure 20: Manage Locks tab 80

81 APPENDIX A Figure 21: Manage Locks after selecting add or change Figure 22: Show Accesses tab 81

82 APPENDIX A APPENDIX B: FINAL USER INTERFACE FOR THE PHONE APPLICATION 82