TRABAJO FIN DE GRADO ESTUDIOS DE GRADO EN INGENIERÍA DE TECNOLOGÍAS DE TELECOMUNICACIONES

Sistema de autenticación de dispositivos remotos utilizando una pasarela Bluetooth Autor Juan Carlos Angulo Santos Director Jorge Navarro Ortiz

Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación — Granada, Julio de 2016

3

Sistema de autenticación de dispositivos remotos utilizando una pasarela Bluetooth

Autor Juan Carlos Angulo Santos Director Jorge Navarro Ortiz

Sistema de autenticación de dispositivos remotos utilizando una pasarela Bluetooth Juan Carlos Angulo Santos Palabras clave: Sistema de autenticación, Servicio de Proyección de Material Docente, SPMD, Pasarela, Bluetooth, Android, VPN, Wifi, Proyector, Diapositivas, Criptografía, Seguridad

Resumen Es algo habitual en las aulas de cualquier centro de la Universidad de Granada que el docente utilice el proyector para hacer uso de diapositivas a la hora de impartir una clase. Este proyecto surge a partir de un Proyecto de Innovación Docente (PID), denominado Servicio de Proyección de Material Docente (SPMD), cuyo objetivo es almacenar material docente del profesorado en una base de datos dedicada a ello y controlar de forma inalámbrica la visualización en el proyector desde e.g. un móvil. Para ello, este PID utiliza un dispositivo TV Stick, basado en Android, que se conecta al proyector. Este TV Stick se conecta a la red inalámbrica de la universidad para recibir el contenido y los comandos necesarios para la visualización. Además, utiliza una conexión VPN para garantizar la seguridad de sus comunicaciones. Sin embargo, Android almacena en archivos información de autenticación en texto plano, por lo que puede ocurrir que alguna persona ajena a la UGR obtenga información sensible, como diferentes claves de acceso. Este proyecto propone que el TV Stick se conecte al arrancar con un servidor de autenticación para obtener información como el acceso a la red Wi-Fi y a una posible red VPN. Así, en caso de robo del dispositivo y por lo tanto, el posible acceso a las claves antes mencionadas, existirá la posibilidad de cambiar las claves Wi-Fi y VPN en el servidor y que el dispositivo vuelva a obtenerlas en cada arranque. Sin embargo, dicha comunicación no se puede hacer a través de la red Wi-Fi, ya que las credenciales para acceder a la red son parte de la información que proporcionará el servidor de autenticación. El objetivo del proyecto es implementar una aplicación que actúe como pasarela para la autenticación entre un dispositivo TV Stick de Android y un servidor. Concretamente, este Trabajo de Fin de Grado propone que el TV Stick se comunique a través de Bluetooth con un dispositivo Android perteneciente al usuario, como un móvil o una tableta, que actuará como pasarela hacia el servidor de autenticación.

Authentication system for remote devices using a Bluetooth gateway Juan Carlos Angulo Santos Keywords: Authentication System, Service of Projection of Teaching Materials, SPMD, Gateway, Bluetooth, Android, VPN, Wi-Fi, Projector, Slideshow, Cryptography, Security

Abstract It is common in classrooms at any center of the University of Granada that the professor use the projector in order to display slideshow to teach a class. This project tries to improve the functionality of a Project on Innovative Teaching (PIT) whose objective is twofold: to store the teaching material in a centralized server, and to wirelessly control the visualization of the teaching material on a projector. For that purpose, an Android TV Stick will be connected to the projector, which will be connected to the wireless network of the university to receive the files and the commands from e.g. a mobile device. Additionally, the TV Stick will be also connected to a VPN in order to ensure the security of its communications. However, Android stores authentication information in plain text, such as different passwords. This project proposes that the TV Stick connects to an authentication server when booting, to get information such as e.g. access Wi-Fi network and a possible VPN network. Consequently, in case of device theft and the access to sensible keys, it shall be possible to change the Wi-Fi and VPN passwords on the server and the device would get them on every boot. Thus, the objective of this project is the implementation of an application that act as a gateway for authentication between an Android TV Stick device and a server. This TV Stick will be connected to a TV or projector in classrooms, and on the server the material to be displayed through the Android device will be stored. However, this communication can not be done through the Wi-Fi network because the credentials to access the network are part of the information that provides the authentication server. This bachelor thesis proposes that the TV Stick communicate using Bluetooth with an Android user device, such as a mobile or tablet, which will act as a gateway to the authentication server.

Yo, Juan Carlos Angulo Santos, alumno de la titulación de la Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación de la Universidad de Granada, con DNI 75933482-V, autorizo la ubicación de la siguiente copia de mi Trabajo Fin de Grado en la biblioteca del centro para que pueda ser consultada por las personas que lo deseen.

Fdo: Juan Carlos Angulo Santos

Granada a 10 de julio de 2016 .

D. Jorge Navarro Ortiz, Profesor del Área de Ingeniería Telemática del Departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada. Informa: Que el presente trabajo, titulado Sistema de autenticación de dispositivos remotos utilizando una pasarela Bluetooth, ha sido realizado bajo su supervisión por Juan Carlos Angulo Santos, y autorizamos la defensa de dicho trabajo ante el tribunal que corresponda. Y para que conste, expiden y firman el presente informe en Granada a 10 de julio de 2016 .

El director:

Jorge Navarro Ortiz

Agradecimientos

Todo comienzo tiene un final, y ese momento ha llegado. Han sido muchos los obstáculos que ha habido que superar para llegar hasta aquí. He tenido la suerte de tener la ayuda de personas que siempre me han mostrado su apoyo. Quiero aprovechar este prólogo para agradecer a todas esas personas que me han prestado su ayuda en cualquier momento. A mis padres y a mis hermanos por su apoyo incondicional, por sus consejos y su preocupación constante sobre mi trabajo. Personas como ellas me han animado a seguir siempre adelante. A mis amigos de toda la vida y mis compañeros de la universidad, con los que he tenido el placer de compartir todas las experiencias de la carrera. Sin ellos estos años no tendrían el mismo significado, ya que los buenos momentos que hemos compartido no los olvidaré nunca. Gracias a aquellos que me han apoyado con este proyecto y que se han mantenido en contacto conmigo siempre para ofrecerme ayuda. A mi tutor del proyecto, Jorge. Sin él este trabajo no hubiese sido posible. Agradezco enormemente todos los consejos ofrecidos y la preocupación que ha mostrado siempre, con el fin de que este trabajo se realizara de la mejor manera posible. Gracias a todos.

Índice general Índice de figuras

iii

Índice de tablas

v

1. Introducción. 1.1. Contextualización y Motivación . . . . . . . . . . . . . . . . .

1 1

2. Estado del arte.

5

3. Especificación de requisitos 13 3.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . 14 4. Planificación y presupuesto 4.1. Planificación . . . . . . . 4.2. Presupuesto . . . . . . . . 4.2.1. Recursos humanos 4.2.2. Recursos hardware 4.2.3. Recursos software . 4.2.4. Presupuesto final .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5. Herramientas utilizadas 5.1. Android . . . . . . . . . . . . . . . . . . . . 5.2. Bluetooth . . . . . . . . . . . . . . . . . . . 5.2.1. Bluetooth en Android: sockets . . . . 5.3. Seguridad . . . . . . . . . . . . . . . . . . . 5.3.1. Criptografía de clave simétrica: AES 5.3.2. Criptografía asimétrica: RSA . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

17 17 22 22 23 24 25

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

27 27 30 31 33 33 36

6. Diseño e implementación 6.1. Desarrollo de las aplicaciones en Android . . . . 6.1.1. Programación de la aplicación cliente . . 6.1.2. Programación de la aplicación TV Stick 6.2. Desarrollo del servidor de autenticación . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

39 39 40 50 55

i

. . . . . .

ÍNDICE GENERAL

ii

6.3. Protocolo de envío de mensajes . . . . . . . . . . . . . . . . . 6.4. Uso de criptografía: RSA y AES . . . . . . . . . . . . . . . . 7. Fase de pruebas

59 61 65

8. Conclusiones y líneas futuras 73 8.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 8.2. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 A. Manual de instalación 77 A.1. Manual de instalación de las aplicaciones Android . . . . . . . 77 A.2. Manual de utilización de los archivos PHP en el servidor . . . 85 B. Manual de uso de la aplicación Android

87

Índice de figuras 1.1. 1.2. 1.3.

. . . . . . . . . . . . . . . . . . . Porcentajes de venta en smartphones dependiendo del sistema operativo. [1] .

2.1. 2.2. 2.3. 2.4.

Elementos de entrada de un MK809 III.

4.1.

Phonegap permite programar aplicaciones en lenguaje web y traducir la apli-

TV Stick MK809 III que será usado el proyecto.

Cuota de mercado para smartphones según el sistema operativo. [1]

. . . . . . . . . . . Funcionamiento del sistema WGA-310. . . . Funcionamiento del sistema WIPG-1500. . .

. . . .

6 7 8 10

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19 21

Proyector BenQ W1500.

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

cación para diferentes dispositivos.

4.2.

Diagrama de Gantt

5.1. 5.2. 5.3. 5.4. 5.5.

Interfaz de Android Studio.

. . . . . . . . . . . . . . . . . Funcionamiento de la criptografía de clave simétrica. . Estructura del algoritmo de encriptación AES. . . .

. . . .

28 29 34 35

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40 42 43 46 47 51 56 56

. . . . .

56 57 57 59 63

Ejemplo de archivo AndroidManifest.xml.

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Funcionamiento de criptografía asimétrica utilizando encriptación con clave pública.

6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9.

2 4 4

Diagrama de clases para la aplicación cliente. Portada de la aplicación cliente.

Login de SPMD visualizado a través de un WebView en un dispositivo Android.

. Interfaz de la aplicación (con Bluetooth activo). . Diagrama de clases para la aplicación TV Stick. . Generación del reto por parte del servidor. . . . Encriptación del reto por parte del TV Stick. . . Interfaz de la aplicación (sin Bluetooth activo).

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Proceso de desencriptación en el servidor del reto encriptado por parte del TV

Stick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.10. Comparación del reto generado por el servidor y el mensaje recibido. . . . 6.11. Intercambio de mensajes en el servidor, en el caso de autenticación correcta. 6.12. Intercambio de mensajes entre TV Stick, Cliente y Servidor. . . . . . . . 6.13. Proceso de encriptación por parte del TV Stick. . . . . . . . . . . . . .

iii

ÍNDICE DE FIGURAS

iv

6.14. Proceso de desencriptación por parte del servidor. . . . . . . . . . . . . .

64

7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7.

. . . . . . . . . . . . . . . . . . . . . . Mensaje devuelto por el servidor tras solicitar un reto. . . . . . . . . . . . El dispositivo cliente envía un identificador y un reto encriptado al servidor. . . . . . . . . . . . . .

68 68 68 68 69 70 71

A.1. A.2. A.3.

Archivo Strings.xml para la aplicación cliente.

. . . . . . . . . . . . . . para la aplicación TV Stick. . . . . . . . . . . . . .

78 78

Trazas de los mensajes enviados entre cliente y servidor Solicitud del reto por parte de la aplicación cliente.

Claves Wi-Fi y VPN encriptadas y enviadas por el servidor al dispositivo cliente. Clave Wi-Fi enviada por el servidor e introducida en el TV Stick Clave VPN enviada por el servidor e introducida en el TV Stick

Archivo Strings.xml

Generación de claves pública y privada haciendo uso de las librerias instaladas

. . . . . . . . . . . . . . . . . . . . . A.4. Generación de claves pública y privada haciendo uso de un generador online. . A.5. Botón para ejecutar la aplicación. . . . . . . . . . . . . . . . . . . . . A.6. Elección de dispositivo en el que instalar la aplicación. . . . . . . . . . . . A.7. Pestaña para generar el archivo .apk . . . . . . . . . . . . . . . . . . . A.8. Generación de Keystore. . . . . . . . . . . . . . . . . . . . . . . . . A.9. Introducción de datos para firmar la aplicación. . . . . . . . . . . . . . . A.10.Mensaje de éxito al generar el archivo .apk. . . . . . . . . . . . . . . . . A.11.Permiso para instalar aplicaciones de orígenes desconocidos. . . . . . . . . A.12.Instalación de la aplicación en Android. . . . . . . . . . . . . . . . . .

79 80 81 81 82 83 83 83 84 84

B.1. B.2. B.3. B.4. B.5. B.6.

88 88 89 90 91

en el servidor de autenticación.

Ajustes de visibilidad Bluetooth en Android.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . Interfaz de la aplicación una vez terminada la búsqueda de dispositivos. . . .

Interfaz de la aplicación cliente.

Proceso de búsqueda de dispositivos con dispositivo encontrado.

Interfaz de la aplicación en el proceso de envío de claves desde el servidor al TV Stick.

B.7.

. . . . . . . . . . . . . . .

Login de SPMD visualizado a través de un WebView en un dispositivo Android.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Inicio de la página del SPMD en la aplicación cliente tras el envío de credenciales.

92 92

Lista de Tablas 4.1. 4.2. 4.3.

Estudio de costes para los recursos humanos.

Presupuesto final del proyecto teniendo en cuenta los distintos recursos utilizados.

23 24 25

6.1. 6.2. 6.3. 6.4.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comportamiento de RSA según la clave utilizada. [2] . . . . . . . . . . . Tiempo de generación de una clave para RSA dependiendo de su tamaño. [2] .

49 53 61 61

Estudio de costes para los recursos hardware.

Mensajes enviados por la aplicación cliente

Mensajes enviados por la aplicación TV Stick

v

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Capítulo 1

Introducción. 1.1.

Contextualización y Motivación

Este proyecto surge como complemento a un Proyecto de Innovación Docente (PID) con el objetivo de mejorar la seguridad de sus comunicaciones. En concreto, este PID se denomina Servicio de Proyección de Material Docente (SPMD) [3] y tiene como objetivos fundamentales el de almacenar material docente del profesorado en una base de datos dedicada a ello y visualizar dicho contenido mediante diferentes dispositivos (portátiles, móviles, tabletas) conectados de forma inalámbrica al proyector ubicado en cada aula. Éste tendrá conectado un dispositivo TV Stick de Android y será el medio para mostrar el contenido. La ventaja de este PID es la de mantener alojado el material docente en una base de datos, accesible desde cualquier lugar y la de no necesitar ningún tipo de conexión cableada para visualizarlo mediante un proyector. El dispositivo principal del proyecto, como se ha comentado anteriormente, será un TV Stick MK809 III (véase la figura 1.1), el cual utiliza el sistema operativo Android 4.4 y soporta Bluetooth 4.0. La ventaja de este TV Stick es que puede configurarse como cualquier otro dispositivo Android y es posible conectarlo a un monitor o proyector que sea compatible con puertos de entrada HDMI para mostrar un contenido determinado. 1

2

1.1. Contextualización y Motivación

Figura 1.1:

TV Stick MK809 III que será usado el proyecto.

En este contexto, el presente proyecto surge con el objetivo de eliminar problemas de seguridad inherentes a los sistemas Android. El dispositivo que se conectará al proyector con el objetivo de visualizar el material docente utiliza el sistema operativo Android. Éste presenta un grave problema de seguridad, ya que inserta información sensible dentro de ficheros, como claves Wi-Fi o claves VPN, en texto plano. Para ello, se pretende que se puedan modificar estas claves de forma centralizada por parte del gestor del PID y enviarlas de nuevo al dispositivo TV Stick para su modificación. Sin embargo, esto presenta el problema de que los dispositivos TV Stick no pueden utilizar la red Wi-Fi para recuperar estas claves si han sido modificadas, ya que éstas son las credenciales para poder conectarse a la red. Por ello, el presente proyecto surge con el objetivo de crear una conexión auxiliar que pueda utilizar el dispositivo para descargarse, de forma segura, las nuevas contraseñas. Debido a las posibilidades de conexión de los MK809 III y a las tecnologías habituales en los móviles o tabletas usadas para controlar la proyección en este PID, se ha utilizado Bluetooth para establecer una conexión entre el dispositivo TV Stick y el móvil/tableta. Éste último será el que actuará de pasarela para conectarse al servidor central (ya sea por Wi-Fi o a través de la red móvil). Por tanto, el objetivo del proyecto consiste en la creación de una pasarela que permita la autenticación del dispositivo remoto TV Stick MK809 III con el servidor central del PID y que éste último pueda enviar las credenciales al TV Stick. La conexión entre el TV Stick y la pasarela utilizará Bluetooth como tecnología de comunicación. Dicho TV Stick estaría conectado a un televisor o proyector, donde el contenido a mostrar estaría controlado por un móvil/tableta del usuario interesado en proyectar. En el caso de este PID, el escenario habitual será el de un TV Stick conectado a un proyector o televisor en las aulas de la Universidad de Granada. Dado que el dispositivo estará siempre en el aula, podría darse el caso de que

Introducción.

3

alguien tenga acceso al dispositivo y obtenga información restringida para el personal ajeno a la UGR, como claves Wi-Fi o VPN. Este acceso a las claves es posible, ya que como se ha comentado anteriormente, Android guarda en ficheros información sensible, como claves, en texto plano. Para evitar un uso inapropiado de la información que es posible sustraer de un dispositivo Android, se propone que el TV Stick se conecte con un servidor de autenticación que le proporcionará la información de acceso a la red Wi-Fi y VPN. En el caso de que se tenga constancia de dicha sustracción de datos, se cambiarán las claves que el dispositivo necesita para conectarse a la red y para acceder al servidor que le proporciona el contenido a mostrar. Este cambio de claves afectaría a todos los dispositivos TV Stick que estén conectados en las aulas, por lo que se requerirá al arrancar el dispositivo una comprobación de las claves por si se da el caso de que hayan cambiado. Además, el cambio de claves por parte del servidor central puede realizarse de forma periódica como acción preventiva. Este periodo se podría modificar en la configuración, aunque una periodicidad de un día debería ser suficiente para una seguridad razonable. Así, como se ha comentado, al arrancar el TV Stick, éste comprobará si es posible establecer una conexión a la red Wi-Fi. En caso afirmativo el dispositivo se conectará sin problemas al servidor para tener acceso al contenido que desea mostrar. En cambio, si se da el caso de que el dispositivo no pueda acceder al servidor, se deberá utilizar algún mecanismo para poder obtener dichas claves, ya que la conexión Wi-Fi no estará disponible sin las claves correspondientes. En cambio, si se da el caso de que el dispositivo no pueda acceder al servidor, se deberá utilizar algún mecanismo para poder obtener dichas claves. Si esto ocurre quiere decir que el dispositivo no posee la clave Wi-Fi o que las claves en el servidor han cambiado, por lo que se necesitará otro método de conexión para obtener la información de autenticación. Este proyecto propone usar una pasarela utilizando un dispositivo (el móvil o tableta del docente) que permita conectarse mediante Bluetooth al TV Stick para proporcionarle las claves. Para ello, el dispositivo que actúa como pasarela deberá obtener las claves del servidor mediante una conexión Wi-Fi o a través de la red móvil y, una vez obtenidas, conectarse a través de Bluetooth al TV Stick y proporcionarle las nuevas claves. De esta manera, el TV Stick no tendrá que hacer uso en ningún momento de la red Wi-Fi para la autenticación. Para la programación de la pasarela, se ha decidido utilizar el sistema operativo Android, debido a que según diversos estudios, es el sistema operativo más utilizados en smartphones y tabletas. En concreto, un estudio reciente de IDC (International Data Corporation) [1], muestra que este sistema operativo domina en el mercado, con hasta un 82.8 % del total de smartphones vendidos del total en 2015, y una cifra similar para años anteriores.

4

1.1. Contextualización y Motivación

En la siguiente figura se puede observar una tabla que muestra la cuota de mercado para smartphones cada año, según el sistema operativo:

Figura 1.2:

Figura 1.3:

Cuota de mercado para smartphones según el sistema operativo. [1]

Porcentajes de venta en smartphones dependiendo del sistema operativo. [1]

Así, en el contexto presentado y debido a las motivaciones explicadas, este trabajo de fin de grado abordará la implementación en dispositivos móviles Android de una pasarela para la autenticación del TV Stick.

Capítulo 2

Estado del arte. En este capítulo se desarrollará el estado del arte, dando una perspectiva global del área con la que se trabaja en el proyecto. En primer lugar se comentará el porqué de la elección del TV Stick de Android MK809 III y no otro cualquiera, ya que existen otros productos de diferentes marcas con características similares, entre los que destacan Google Chromecast, Apple TV, Roku o Amazon Fire TV. El mini-PC Android MK809 III, cuyo procesador ha sido fabricado por la empresa Rockchip, presenta como principal característica ser un dispositivo sin pantalla, disponiendo de un puerto HDMI, con el fin de conecta el dispositivo a un televisor o un proyector para visualizar el contenido. Al utilizar el sistema operativo Android podrá instalarse cualquier aplicación compatible con este sistema operativo. Además, al disponer de dos puertos USB, permite introducir diferentes periféricos, como por ejemplo un ratón o teclado para poder moverse por la interfaz e interactuar con ella.

5

6

Figura 2.1:

Elementos de entrada de un MK809 III.

Cabe destacar que el uso del MK809 III es un requisito impuesto por el tutor del proyecto, Jorge Navarro Ortiz, ya que el PID utiliza ese dispositivo para la visualización del contenido. La motivación para el uso de este mini PC fueron sus prestaciones sobresalientes y su ajustado precio, inferior a los 50 euros. Su hardware compite con muchos otros dispositivos cuyo precio es considerablemente más elevado. El TV Stick de Android, consta de un procesador Rockchip RK3188 con cuatro núcleos, capaz de alcanzar velocidades de 1,8 GHz. Además, destaca su memoria RAM de 2 GB de tipo DDR3 y sus 8 GB de memoria interna, con la opción de ampliarla mediante una tarjeta microSD. A continuación se describirán los principales dispositivos que tienen una funcionalidad similar y que se podrían utilizar para la proyección de material de manera inalámbrica. El primero de los dispositivos a considerar es Chromecast [4]. De los nombrados es el dispositivo más barato (39 e), y su funcionalidad principal es la de permitir streaming entre una televisión y un smartphone o tableta. Sin embargo, en nuestro contexto presenta varios inconvenientes: no hay interfaz gráfica para la visualización por pantalla, ni un control remoto que permita controlar el streaming, controlándose todo desde el dispositivo del usuario. Pero su principal defecto es la falta de conectividad para redes WiFi empresariales que necesiten autenticación 802.1X [5], es decir, utilizando un servidor de autenticación, como es el caso de la red de la Universidad de Granada. Apple TV [6], con un precio bastante más elevado que Chromecast (89 e),

Estado del arte.

7

funciona únicamente con dispositivos Apple y presenta el mismo problema de conectividad que Chromecast con redes que requieren autenticación 802.1X, por lo que se hace inviable para el presente proyecto. Amazon Fire TV [7] es un aparato que funciona excepcionalmente bien con el sistema de streaming. Utiliza el sistema operativo Amazon FireOS que está basado en Android, por lo que para el propósito del proyecto sería viable, debido al sistema operativo, ya que modificando el dispositivo para obtener permisos de root, se hubiese podido acceder al sistema e introducir los scripts necesarios que se requieren en este proyecto. Sin embargo, presenta el mismo problema que los anteriores dispositivos y es que no soporta autenticación WPA2 Enterprise, es decir, el uso de 802.1X para acceder a un servidor de autenticación Además del uso de los sticks también cabría la posibilidad de utilizar proyectores inalámbricos, que se conectarían directamente al dispositivo del usuario. Estos proyectores tienen la gran ventaja de tener una instalación sencilla y de poder conectarse mediante vía Wi-Fi a otros dispositivos como smartphones, tabletas u ordenadores, que controlan el contenido a mostrar. El principal inconveniente es el precio de dichos productos, bastante más elevado que los proyectores convencionales, además de requerir la sustitución de todos los proyectores disponibles actualmente. Un caso de proyector inalámbrico que puede ser controlado por smartphones o dispositivos con capacidad Wi-Fi es el proyector BenQ W1500 [8] (véase la figura 2.2)

Figura 2.2:

Proyector BenQ W1500.

Este proyector, valorado en 1500 e, se conecta de manera inalámbrica a cualquier dispositivo a través de la banda de 5 GHz, usando para ello un dongle HDMI que se encarga de enviar la imagen del dispositivo de reproduc-

8 ción al proyector. Esto se convierte en un problema si el dispositivo que va a enviar el contenido no dispone de puerto HDMI o de un adaptador capaz de insertar dicho dongle, como es el caso habitual de móviles y tabletas. Para el objetivo del proyecto, aunque es una solución simple, su precio hace que se vuelva inviable en comparación al uso de TV Sticks, que permiten una conexión con el proyector de una manera más compleja, pero también mucho más barata. Dejando a un lado el tema de dispositivos que podrían realizar una función similar al TV Stick de Android, existen empresas que podrían proporcionar el equipo necesario para realizar el mismo objetivo que el que tiene este proyecto, es decir, alojar archivos en un servidor y tras la correspondiente autenticación obtenerlos en un dispositivo y poder utilizarlos para mostrar contenido. En esta parte del estado del arte comentaremos dichas empresas y los servicios que ofrecen: La empresa AWIND ofrece productos como el WGA-310 [9], que conectado mediante cable a un proyector o televisor, permite proyectar contenido que se transmite desde cualquier dispositivo con conexión Wi-Fi. En la siguiente imagen se muestra un esquema del funcionamiento.

Figura 2.3:

Funcionamiento del sistema WGA-310.

Este sistema WPS (Wireless Presentation System) permite que desde smartphones, tabletas o un ordenador, se envíe contenido de manera inalámbrica o cableada al dispositivo WGA. Éste lo reenviará a través de un cable conectado al proyector o a un ordenador cualquiera, donde se proyectará el contenido a mostrar. Es posible conectar periféricos como ratón y teclado al WGA-310 para poder controlar el dispositivo del usuario. La diferencia con el presente proyecto es que se sustituye el uso del TV Stick, que como se mencionó anteriormente guarda información de autenticación en texto plano, por el WGA-310, que no presenta problemas de seguridad. Además, la conexión Wi-Fi entre el dispositivo del usuario y WGA-310 se hace mediante un punto de acceso que crea el propio aparato, por lo que no habrá problemas

Estado del arte.

9

con que ambos tengan que estar conectados a una red Wi-Fi con seguridad WPA2 Enterprise, como ocurría con los distintos sticks que se comentaban anteriormente. Aunque presenta la ventaja de la seguridad, su sencilla instalación y el uso en dispositivos con diferentes sistemas operativos (Windows, iOs, Android), su precio ronda los 400 e, bastante caro en comparación con la alternativa de un TV Stick. Además, en el caso de la Universidad de Granada y de otras universidades/empresas, no está permitido añadir nuevos puntos de acceso que no estén integrados en su sistema de gestión. Esto se debe a que, en caso contrario, no sería posible gestionar de forma adecuada la interferencia entre los elementos de la red. En el caso de la Universidad de Granada, esta gestión la realiza el Centro de Servicios de Informática y Redes de Comunicaciones (CSIRC). Otra empresa que ofrece un servicio con efecto similar al de este proyecto es WePresent, cuyos productos WiPG-1000 [10] o WiPG-1500 [11] tienen el mismo funcionamiento que el WGA-310 que se nombraba anteriormente (véase la figura 2.4). El precio del WiPG-1000 es similar al del WGA-310, pero el del WiPG-1500 prácticamente dobla esa cantidad, debido a que añade muchas más características interactivas, como por ejemplo la posibilidad de realizar anotaciones en pantalla durante una presentación.

10

Figura 2.4:

Funcionamiento del sistema WIPG-1500.

Existen otros productos que funcionan de forma similar. A continuación, se presenta una lista de algunos de los más relevantes junto con una breve descripción: WPS-HD (IPEVO) [12]: Solo es compatible con ordenadores con sistema operativo Windows o Mac OS. El funcionamiento es el mismo que los anteriores y la conexión Wi-Fi entre el aparato y el dispositivo de usuario puede hacerse mediante un punto de acceso creado por el aparato. WPS - Dongle (OPTOMA) [13]: Se trata de un dongle que se conecta a un proyector mediante una entrada VGA. El funcionamiento es el mismo que los anteriores dispositivos, exceptuando que éste va conectado directamente al proyector mediante la entrada VGA con un dongle, y en los anteriores se realizaba mediante un cable VGA o HDMI. WPG-210N (PLANET) [14]: Permite transmisiones Wireless de hasta 300 Mbps. Solo soporta los sistemas operativos Windows y MAC OS. Mismo funcionamiento que los anteriores.

Estado del arte.

11

WiD510 (TEQ) [15]: Soporta MAC OSX, Windows, Android e iOS. Mismo funcionamiento que los anteriores. LiteShow III (InFocus) [16]: Adaptador Wireless que se conecta a dispositivos capaces de proyector. Mismo funcionamiento que los anteriores. WPG-370 (ViewSonic) [17]: Aparato que funciona como punto de acceso al igual que los anteriores para transmitir la información a dispositivos capaces de proyectar, y que es compatible con Android, MAC OSX, iOS y Windows. AVX-HDMI-WI (BlackBox) [18]: Compatible con Mac OSX o Windows. Mismo funcionamiento que los anteriores. Los diferentes productos que se han comentado presentan algunos inconvenientes, ya sean funcionales o económicos, por lo que se considera que el uso de un TV Stick como el MK809 III es una solución razonable para el problema planteado.

Capítulo 3

Especificación de requisitos En este capítulo se pretende llevar a cabo un análisis del proceso de diseño realizado para este proyecto, incluyendo, de la manera más completa posible, los requisitos funcionales y no funcionales que se deben cumplir. Estos requisitos son importantes, ya que proporciona documentación sobre el contenido del proyecto durante la fase de diseño.

3.1.

Requisitos funcionales

En esta sección se listarán los requisitos funcionales mínimos que serán necesarios para el funcionamiento del proyecto, y que serán útiles a la hora de tener presente las ideas del diseño: Búsqueda de dispositivos y conexión Bluetooth: La aplicación dedicada al usuario (cliente) debe tener la capacidad de realizar búsquedas de dispositivos Bluetooth, por lo que será imprescindible que el dispositivo en el que se instale la aplicación disponga de un adaptador Bluetooth capaz de enviar y recibir datos. Adicionalmente, será necesario que se muestren por pantalla los dispositivos encontrados una vez realizada la búsqueda, y que se dé la opción al usuario de elegir un dispositivo al cual realizar la conexión. Capacidad de la aplicación cliente de actuar como pasarela: La aplicación cliente que se le presenta al usuario deberá tener la capacidad de conectar, a modo de pasarela, el TV Stick y el servidor, sin que ambos se conecten directamente, con el fin de que el TV Stick pueda recibir las claves Wi-Fi y VPN. 13

14

3.2. Requisitos no funcionales Autenticación entre las distintas partes del sistema: Será necesario que el TV Stick se autentique con el servidor mediante algún método, con el fin de evitar que el envío de credenciales se realice por parte de personas que no tengan la autorización necesaria. Envío de credenciales por parte del servidor: El servidor deberá enviar las claves Wi-Fi y VPN al TV Stick a través de una pasarela. Estas claves deberán ir cifradas durante el transcurso de la comunicación, evitando así que alguna persona o dispositivo pueda capturarlas al ser enviadas por la red. Acceso a la página oficial del Servicio de Proyección de Material Docente (SPMD): Una vez realizado el intercambio de credenciales, la aplicación cliente deberá mostrar la página web de acceso al servicio de proyección, donde estará alojado el material docente.

3.2.

Requisitos no funcionales

En esta sección se presentarán los requisitos no funcionales, que son aquellos que imponen restricciones en el diseño o la implementación. Sistema operativo Android: El uso del sistema operativo Android será el escogido para la programación de la aplicación cliente, debido a que es la herramienta más vendida en el mundo y que proporcionará una gran compatibilidad con el TV Stick, que también posee el sistema operativo Android. Esto abre la posibilidad de realizar una programación utilizando el lenguaje Java para la programación en diferentes sistemas operativos, dada su portabilidad. Sin embargo, sí será necesario el uso de las APIs de Bluetooth específicas para cada sistema operativo. Interfaz sencilla e intuitiva La interfaz de la aplicación cliente debe ser sencilla e intuitiva, de modo que el usuario sepa en todo momento lo que debe hacer para poder acceder al material docente alojado en el servidor. Programación Android para el mayor número de versiones posibles La aplicación cliente debe estar pensada para actuar en el mayor número de versiones Android disponibles en el mercado, de modo que la compatibilidad no varíe según la versión. Android posee una característica llamada compatibilidad hacia atrás, que permite que una

Especificación de requisitos

15

aplicación desarrollada para una determinada versión de Android, siga siendo compatible con versiones futuras. Aplicaciones tolerantes a fallos Las aplicaciones programadas para el TV Stick y el cliente deben ser tolerantes a fallos, especialmente la del dispositivo TV Stick. Esto es debido a que no será posible la intervención del usuario en este último aparato, por lo que si la aplicación falla, es posible que sea necesario reiniciar la aplicación.

Capítulo 4

Planificación y presupuesto En el presente capítulo se tratarán los aspectos relacionados con la planificación y el presupuesto del proyecto, haciendo una estimación de costes. En primer lugar se tratarán las diferentes etapas de las que ha constado el proyecto y el número de horas dedicado a cada etapa. Para ello se realizará un diagrama de Gantt, que representará gráficamente la evolución del proyecto. Además, posteriormente se identificarán los recursos utilizados y el tipo de cada uno. Por otro lado, se realizará una aproximación del presupuesto total necesario para llevar a cabo el proyecto, basándose en los recursos utilizados y el estudio de costes necesario.

4.1.

Planificación

En esta sección se describirá la planificación que se ha adoptado para la realización del proyecto. Tarea 1: Revisión bibliográfica En esta primera etapa se realizará una investigación sobre estudios relacionados con la temática del proyecto, en dónde se buscarán evidencias de productos que hagan algo exactamente igual al objetivo de este proyecto. Por otro lado, se investigará la mejor manera de realizar este proyecto, ya que existen diferentes tipos de software y hardware que podrían ser utilizados, por lo que habrá que estudiar las características de cada método. Tarea 2: Definición de requisitos y elección de herramientas/plataformas Esta segunda etapa consistirá en planificar que requisitos serán los necesarios según el problema planteado, y cuál podría ser la plataforma 17

18

4.1. Planificación adecuada en la que desarrollar la aplicación del cliente.

Tarea 3: Aprendizaje de herramientas seleccionadas En esta etapa se profundizará en el aprendizaje de las herramientas seleccionadas, así como en los lenguajes de programación escogidos para el desarrollo del proyecto. Además, conociendo que el TV Stick necesitaría programación en Android, es un lenguaje que ha de estudiarse, debido a que el autor del proyecto carecía de conocimientos sobre programación en Android.

Tarea 4: Diseño La etapa de diseño es de gran importancia, ya que consistirá en planificar como desarrollar la arquitectura final del proyecto, según la solución adoptada al problema planteado.

Tarea 5: Toma de contacto con la programación del dispositivo del usuario

En esta etapa se investigará y se aprenderá el lenguaje de programación escogido para el desarrollo de la aplicación en el dispositivo del usuario. El objetivo será realizar una aplicación que permita conectividad Bluetooth con el TV Stick y que actúe de pasarela entre éste y el servidor del SPMD. En un principio, con el objetivo en mente de desarrollar una aplicación móvil que actuara como cliente para diferentes sistemas operativos como Android o iOs, se pensó en utilizar Phonegap [19], una solución de Adobe que permite desarrollar aplicaciones en lenguaje web (HTML, CSS y JavaScript) y posteriormente traducirlas a aplicaciones para teléfonos móviles o tabletas con distinto sistema operativo. Es lo que se llama desarrollo de aplicaciones multidispositivo.

Planificación y presupuesto

19

Figura 4.1:

Phonegap permite programar aplicaciones en lenguaje web y traducir la aplicación para diferentes dispositivos.

Esta opción se descartó debido a que el uso de Bluetooth en Phonegap estaba muy limitado, y presentaba demasiadas incompatibilidades con el sistema que se pretendía realizar en el TV Stick. Finalmente la solución escogida para la programación en el dispositivo del usuario fue Android, debido a su gran compatibilidad con el TV Stick y su elevado uso en la actualidad. Tarea 6: Programación del TV Stick : Android y Scripts para Linux En esta etapa se estudiará como programar una aplicación que mediante Bluetooth se mantenga siempre en estado de escucha, esperando por una conexión entrante mediante sockets. Como esta aplicación se ejecutará en el TV Stick, al que no tendrá acceso ningún usuario, se deberá realizar una programación para que la aplicación sea autosuficiente, lo que significa que no debe ocurrir ningún evento que requiera la actuación de un usuario. La aplicación estará siempre activa en cuanto se encienda el dispositivo, y en caso de un posible error del terminal se

20

4.1. Planificación reiniciará la aplicación para que vuelva a estar en funcionamiento. Por otro lado, se programarán distintos scripts para la consola de Android. Éstos serán ejecutados desde la misma aplicación realizada, para que el dispositivo sea capaz de cambiar las claves Wi-Fi y VPN que reciba del servidor.

Tarea 7: Programación de la parte servidor en PHP En esta etapa se estudiará como programar en el servidor un sistema de autenticación que permita recibir información de los dispositivos TV Sticks mediante la pasarela Android. Este sistema de autenticación comprobaría la veracidad de la identidad de dichos dispositivos mediante un reto y en caso de poder resolver el reto, enviaría las claves Wi-Fi y VPN necesarias para que los TV Sticks tuvieran acceso a la red. Se pretende que el reto este basado en el uso de criptografía híbrida, es decir, utilizando claves asimétricas y claves simétricas, por lo que se realizará un estudio de cómo utilizarlas tanto en PHP como en Android. Se tendrá que estudiar como encriptar la información tanto en PHP como en Android y obtener una compatibilidad adecuada a la hora de desencriptar entre ambos lenguajes de programación. Tarea 8: Fase de pruebas En esta etapa se realizarán las pruebas necesarias para las implementaciones realizadas en el proyecto. Se tendrán que corregir los fallos detectados en las etapas de implementación y por otro lado, se comprobará que el sistema cumple con su propósito correctamente. Tarea 9: Memoria técnica del proyecto En esta etapa final se realizará una memoria técnica sobre el presente proyecto, en el que se explicarán todos los pasos detalladamente, documentando de la mejor manera posible todos los aspectos que puedan tener relevancia para este proyecto. Con esta memoria se pretende informar al lector de cualquier detalle que pueda resultar de interés sobre la elaboración del proyecto y la información referente al mismo. Tarea 10: Exposición del Trabajo de Fin de Grado Como última etapa del proyecto, se realizará una exposición frente a un tribunal defendiendo el presente trabajo y sus características. Una vez que han quedado identificadas las tareas realizadas en este proyecto, se hará una planificación dependiendo del tiempo estimado que tomaría realizar cada una de las tareas. Esta distribución se puede ver mediante

Planificación y presupuesto

21

un diagrama de Gantt (Ver figura 4.2), donde se hace una estimación de los días planificados a cada una de las tareas.

Figura 4.2:

Diagrama de Gantt

Como se puede observar en el diagrama de Gantt, existen tareas que se han ido haciendo paralelamente a otras. Es el caso de la programación en el dispositivo cliente, en el TV Stick y en el servidor, debido a que para el correcto funcionamiento del sistema completo se debe realizar una conexión entre estos dispositivos (TV Stick con el dispositivo cliente y éste último con el servidor).

22

4.2. Presupuesto

4.2.

Presupuesto

En esta sección se tratará el tema del presupuesto del proyecto, en la que se listarán los recursos utilizados y el precio estimado correspondiente a cada uno.

4.2.1.

Recursos humanos

Los recursos humanos son aquellos en los que ha sido necesaria la intervención humana para la realización del proyecto. En el caso del presente trabajo los recursos humanos son:

Juan Carlos Angulo Santos: Autor del proyecto y alumno del grado en Ingeniería de Tecnologías de Telecomunicación.

Jorge Navarro Ortiz: Tutor del proyecto y profesor contratado doctor de la Universidad de Granada del Departamento de Teoría de la Señal, Telemática y Comunicaciones.

Teniendo en cuenta que el precio de un ingeniero graduado en ingeniería de tecnologías de telecomunicación es de aproximadamente 25 euros/hora y el de un doctor de la Universidad de Granada es de aproximadamente 50 euros/hora, podemos hacer un cálculo estimado de los recursos humanos invertidos en el proyecto. Aproximadamente, el tutor del proyecto, entre tutorías y revisión del trabajo, habrá invertido unas 15 horas. En la siguiente tabla (véase tabla 4.1) podemos observar el número de horas dedicado a cada tarea acorde a tal y como se vio en el diagrama de Gantt. En otra columna se mostrará el precio estimado para dicha tarea y finalmente se concluirá con el precio total que tomaría realizar este proyecto únicamente haciendo uso de los recursos humanos.

Planificación y presupuesto Tarea Revisión bibliográfica Definición de requisitos y elección de herramientas/plataformas Aprendizaje de herramientas seleccionadas Diseño Toma de contacto con la programación del dispositivo del usuario Programación del TV Stick Programación servidor Fase de pruebas Memoria del TFG Exposición TFG Trabajo de ingeniero doctor Total Tabla 4.1:

4.2.2.

23 Tiempo (Horas) 20 5

Coste (Euros) 500 125

10 10 80

250 250 2000

50 30 50 60 15 15 345

1250 750 1250 1500 375 750 9000

Estudio de costes para los recursos humanos.

Recursos hardware

A continuación, se muestran los recursos software utilizados: Ordenador portátil HP Pavilion g6, con un procesador Intel(R) Core(TM) i5-2430M a 2,40 GHz. TV Stick de Android MK809 III, con procesador Quad Core y 2 GB de memoria RAM. Smartphone Sony Xperia Z1, con sistema operativo Android 5.1.1, utilizado para probar el programa cliente. Pantalla LCD Benq GL2260-T con puerto HDMI utilizada para hacer pruebas de conexión con el dispositivo TV Stick. Ratón inalámbrico USB Logitech M185 utilizado para controlar el TV Stick. Teclado cableado USB Logitech K120 utilizado para controlar el TV Stick. Adaptador multi USB: Adaptador con varios puertos USB utilizado para conectar el ratón y el teclado al único puerto USB del TV Stick.

24

4.2. Presupuesto Recurso hardware Ordenador portátil Smartphone Xperia Z1 TV Stick MK809 III Pantalla LCD Benq Ratón inalámbrico Teclado cableado Adaptador multi USB Total Tabla 4.2:

4.2.3.

Coste (Euros) 480 220 30 120 14 12 4 880

Estudio de costes para los recursos hardware.

Recursos software

Estos son los recursos software que se han utilizado: Android Studio 1.5.1: Es un entorno de desarrollo integrado de carácter gratuito ofrecido por la compañía JetBrains utilizado para la programación en Android. Sublime Text: Es un editor de texto gratuito dedicado a código, utilizado en este proyecto para la programación en PHP. XAMPP: Es un servidor independiente de plataforma de software libre que se ha utilizado para emular el servidor en una página web y hacer distintas pruebas. TeXstudio: Es un editor de LaTeX de código abierto que se ha utilizado para redactar la memoria del proyecto. GanttProject: Es el programa utilizado para realizar el diagrama de Gantt que se vio anteriormente. SourceTree: Es un cliente GUI utilizado para manejar repositorios GIT que ha servido para tener la seguridad de que el proyecto no se perdería y poder ver los cambios realizados en cada push. En el caso de los recursos software, se ha buscado que todos los recursos tuvieran un coste gratuito, con el propósito de hacer este proyecto lo más económico posible.

Planificación y presupuesto

4.2.4.

25

Presupuesto final

El presupuesto final será la suma del estudio de costes realizado para los recursos humanos, hardware y software. Podemos ver el precio estimado para cada sección en la siguiente tabla (Tabla 4.3): Recursos Recursos humanos Recursos hardware Recursos software Total Tabla 4.3:

Presupuesto (Euros) 9000 880 0 9880

Presupuesto final del proyecto teniendo en cuenta los distintos recursos utilizados.

En definitiva, el presupuesto total del proyecto será de 9880 e, considerando todos los aspectos anteriores.

Capítulo 5

Herramientas utilizadas En este capítulo se van a describir las herramientas software utilizadas para el diseño del proyecto, en el cual se especificarán detalladamente sus funciones y el uso que se les ha dado.

5.1.

Android

Como se ha comentado en diferentes ocasiones, el sistema operativo Android ha sido el escogido para la programación de la aplicación cliente y la del TV Stick. Esta programación se desarrollará utilizando Android Studio [20], un entorno de desarrollo integrado para la plataforma Android. Este IDE (Integrated Development Environment) es totalmente gratuito y puede descargarse desde la página oficial de Android. Los componentes que incluye el paquete de Android Studio son dos: Android SDK y Android Virtual Device, utilizado para emular dispositivos Android. Android Studio fue el IDE escogido debido a su facilidad de uso a la hora de programar y de compilar las aplicaciones, además de soportar programación para las versiones más actuales de Android. Otra gran ventaja de este paquete es la ayuda que presenta a la hora de diseñar la aplicación, ya que puede verse en el mismo programa como es el diseño actual que se ha programado (Véase figura 5.1). 27

28

5.1. Android

Figura 5.1:

Interfaz de Android Studio.

La programación en este IDE se basa en la creación de proyectos, que constan de diferentes carpetas y archivos. En un proyecto, la primera clase que debe crearse siempre será una Activity, término utilizado para distinguir las distintas pantallas o fases de una aplicación. Estas Activities constan de una parte lógica y una gráfica. La parte lógica es el archivo .java en el que se crea el código necesario para poder interactuar con la aplicación, y que a su vez puede relacionarse con otras clases. Respecto a la parte gráfica, son archivos .xml utilizados para contener los distintos elementos que se visualizan en pantalla, declarados mediante etiquetas. En la parte lógica, las diferentes Activities tienen la capacidad de poder editarse gráficamente, haciendo uso de los archivos .xml de la parte gráfica. Esto se gestiona en la programación de las Activities, en dónde se deberá seleccionar su archivo .xml correspondiente. Adicionalmente, es necesario mencionar el archivo conocido como AndroidManifest.xml, en el cual se podrán declarar las características de cada Activity, como por ejemplo el logo a utilizar o la orientación de la pantalla. En este archivo también se declaran los permisos de la aplicación y las diferentes características del proyecto. En la siguiente figura se puede ver un extracto de código de un archivo AndroidManifest.xml en Android Studio:

Herramientas utilizadas

Figura 5.2:

29

Ejemplo de archivo AndroidManifest.xml.

Se puede observar en la figura superior los permisos que se le han dado a la aplicación, entre los que destacan los permisos para interactuar con el adaptador Bluetooth o los permisos para acceder a Internet. Para la parte gráfica, se crean etiquetas xml en las que se fijan características de los objetos, o cualidades de la aplicación que serán visibles por pantalla. Estos archivos luego serán llamados por la clase de la Activity correspondiente, dónde cada una tendrá su propio esquema si así se desea. Estos archivos .xml estarán incluidos en una carpeta llamada layout, que a su vez se encuentra incluida en otra llamada res. Dentro de res existen diferentes carpetas de gran importancia dedicadas al diseño, cada una con su correspondiente función. Por ejemplo, la carpetas color es utilizada para introducir archivos que determinan el color de un determinado objeto. Otra carpeta de gran importancia es la carpeta drawable, en dónde se introducirán las diferentes imágenes que serán utilizadas en un proyecto. En Android Studio, además de poder declarar los diferentes elementos que se visualizan por pantalla mediante código, es posible escogerlos de una lista y arrastrarlos a una visualización previa de la pantalla, como se veía en la figura 5.1. Ésto facilita el trabajo de la programación, puesto que al existir la opción de visualización previa, se tiene la capacidad de ajustar los diferentes tamaños de estos objetos hasta que el usuario lo de por válido, sin tener que hacer numerosas pruebas de compilación. Al realizar el diseño gráfico del proyecto mediante este procedimiento, el código es incluido automáticamente a los diferentes archivos .xml, sin que sea necesaria la intervención del usuario. Si será necesaria la intervención del usuario en la parte lógica, en dónde

30

5.2. Bluetooth

se deberá realizar la programación correspondiente de los objetos gráficos, dependiendo de las distintas acciones del usuario que utilice la aplicación. Por otro lado, la intervención del usuario en la parte gráfica a la hora de modificar el diseño, es necesaria si se desea cambiar el estilo de los objetos que están incluidos por defecto en Android Studio. Existe la posibilidad de diseñar un propio estilo para cada objeto, como por ejemplo botones o líneas de texto.

5.2.

Bluetooth

La principal tecnología de comunicación utilizada en este sistema se basa en el uso de Bluetooth, que permite la transmisión de voz y datos mediante un enlace por radiofrecuencia. Esta tecnología ha evolucionado a lo largo de los años, por lo que existen diferentes versiones utilizadas hoy en día. Antiguamente, se utilizaba el llamado Bluetooth clásico, hasta la llegada de la versión 4.0 de Bluetooth, en la que se introdujo el Bluetooth de baja energía o Bluetooth low energy (BLE) [21]. Bluetooth y Bluetooth de baja energía se utilizan con diferentes objetivos. Bluetooth clásico se utiliza cuando la información a tratar es una gran cantidad de datos, con el problema de que el consumo de batería aumenta notablemente. Por el contrario, Bluetooth de baja energía está diseñado para aplicaciones que no necesitan realizar un intercambio elevado de datos, disminuyendo en gran medida el gasto de batería para el dispositivo utilizado. Este último tipo de Bluetooth fue implementado en Android a partir de la versión 4.3 (API Level 18), lo que permite a estos dispositivos conectarse con otros que también soporten BLE, como por ejemplo, sensores de proximidad, monitores de ritmo cardiaco o aparatos para controlar el estado físico de una persona. Esto significa que el dispositivo TV Stick, al tener instalada la versión 4.4 de Android, posee conectividad BLE, lo que permitiría conexiones de este tipo de Bluetooth. El problema reside en que realizar una conexión de este tipo limitaría los dispositivos del usuario que pueden utilizar la aplicación cliente, ya que mínimamente se requeriría la versión de Android 4.3 Adicionalmente, como se ha nombrado en el anterior párrafo, BLE está diseñado para enviar pequeñas cantidades de datos, concretamente, 22 bytes por paquete, por lo que para el presente proyecto no sería interesante escoger este tipo de conexión al utilizar un mayor volumen de datos. Por ello, se ha optado por el uso de Bluetooth clásico para la programación de las aplicaciones, lo que permite enviar grandes cantidades de datos sin tener que realizar múltiples envíos. En la siguiente sección se explicará cómo se ha manejado la conectividad

Herramientas utilizadas

31

Bluetooth entre un dispositivo que actuará como cliente y otro como servidor.

5.2.1.

Bluetooth en Android: sockets

En este capítulo se tratará el tema de la conectividad Bluetooth entre el dispositivo que actuará como cliente y otro como servidor. El TV Stick de Android MK809 III soporta hasta Bluetooth 4.0, que es la última versión conocida de Bluetooth. Esta versión engloba el Bluetooth clásico, Bluetooth de alta velocidad y los protocolos Bluetooth de bajo consumo. Como se ha explicado anteriormente se optará por el uso de Bluetooth clásico. Una ventaja de bluetooth clásico es que permite la conexión entre diferentes dispositivos a través de sockets. De esta forma, su programación resulta similar a la del paradigma cliente/servidor en redes IP. Los objetos que permiten realizar una conexión Bluetooth mediante sockets son conocidos como BluetoothSocket [22] y BluetoothServerSocket [23] . En el lado del servidor, es decir, el que espera para una conexión, se utilizará un BluetoothServerSocket, cuyo objetivo es crear un socket que se mantiene escuchando hasta el momento de recibir una conexión entrante. En el lado del cliente se creará un BluetoothSocket con el que será posible inicializar dicha comunicación. En las siguientes secciones se explica el procedimiento seguido. BluetoothSocket en el lado cliente En el lado de la aplicación que actuará como cliente lo primero que se debe programar es un mecanismo que sea capaz de buscar dispositivos con la conexión Bluetooth activada. Para ello se hará uso de la clase BluetoothAdapter, que representa el adaptador Bluetooth del dispositivo y que permite iniciar el descubrimiento de dispositivos. Al elegir uno de los dispositivos del listado de dispositivos encontrados comenzará el proceso de creación del BluetoothSocket encargado de la conexión. En Android existen dos métodos para crear el socket: createRfcommSocketToServiceRecord: Crea un BluetoothSocket mediante el protocolo RFCOMM (Radio Frequency Communication) [24] que comienza una conexión segura utilizando un UUID (Universally Unique Identifier) [25] o identificador único, con el que se buscará el canal RFCOMM que tenga el mismo UUID. Este identificador único deberá ser el mismo tanto en el dispositivo cliente como en el servidor para que la conexión mediante socket sea efectiva, ya que en caso contrario no podrán llegar a conectarse. Este método de conexión requiere de una autenticación en la que ambos dispositivos comparten una clave

32

5.2. Bluetooth y que necesita la intervención de un usuario. Esta autenticación previene el clásico ataque conocido como Man-in-the-middle, ya que solo se conectará al dispositivo que le proporcione la misma clave. La ventaja es la seguridad que proporciona al realizar la autenticación y que además guarda los dispositivos que han sido previamente conectados, por lo que establecer una comunicación entre dos dispositivos es sencillo una vez que se han conectado una primera vez. El problema para este proyecto reside en que al requerir la intervención de un usuario para la autenticación, el TV Stick nunca podría llegar a realizarla, debido a que la intervención de un usuario en este aparato queda descartada en este proyecto. createInsecureRfcommSocketToServiceRecord: Al igual que el anterior, crea un BluetoothSocket, con la diferencia de que crea una conexión insegura mediante un UUID. Utilizando este método no se tiene una clave de seguridad que comparten ambos dispositivos, por lo que no existe la autenticación segura y puede ser susceptible a ataques como el de Man-in-the-middle. Aun así, la comunicación entre los sockets una vez que se ha realizado la conexión estará encriptada. El problema reside en que los dispositivos que han realizado una conexión no se guardan como dispositivos previamente enlazados, por lo que cada vez que se desee iniciar una conexión Bluetooth será necesario buscar el dispositivo y conectarse sin autenticación mediante el identificador único (UUID). La ventaja es que no requiere intervención del usuario, por lo que este método es el indicado para que el TV Stick se mantenga siempre a la espera de conexiones entrantes y las acepte automáticamente cuando reciba una.

Por lo tanto, una vez que se ha elegido el método createInsecureRfcommSocketToServiceRecord para crear el socket, se tendrá que iniciar la conexión con el método connect() de BluetoothSocket, y ésta será aceptada si existe un servidor socket esperando por una conexión entrante. BluetoothServerSocket en el lado servidor En el socket servidor, el primer paso será obtener el adaptador Bluetooth como en el lado del cliente. Este adaptador Bluetooth servirá para crear el BluetoothServerSocket utilizando uno de los siguientes métodos: listenUsingRfcommWithServiceRecord: Es el método análogo a createRfcommSocketToServiceRecord visto anteriormente. Con él es posible crear una conexión mediante la autenticación de dos dispositivos compartiendo una clave entre ambos dispositivos.

Herramientas utilizadas

33

listenUsingInsecureRfcommWithServiceRecord: Es el método análogo a createInsecureRfcommSocketToServiceRecord, en el que se crea una conexión no segura, sin autenticación pero sin intervención del usuario. Ambos métodos requieren de un UUID que deberá ser el mismo que el usado en el cliente y además será necesario un nombre que identifique la autenticación SPD. Una vez creado el BluetoothServerSocket habrá que llamar a su método accept(), que se mantendrá a la espera de recibir una conexión entrante. Al recibir una conexión se creará un BluetoothSocket, de donde se obtendrán los datos del dispositivo que realiza la petición y la conexión se mantendrá establecida hasta que uno de los dos dispositivos decida cancelarla, saliendo de la aplicación o llamando al método close() de BluetoothSocket.

5.3.

Seguridad

En esta sección se tratará el tema de la criptografía utilizada para el envío de mensajes entre las distintas partes que componen el sistema del proyecto. La tecnología de encriptación utilizada se basará en AES y RSA, utilizados conjuntamente para la encriptación y desencriptación, por lo que se procederá a explicar qué es cada uno de estos métodos criptográficos, el porqué de su elección y el modo en el que se utilizan.

5.3.1.

Criptografía de clave simétrica: AES

El cifrado de clave simétrica consiste en el uso de una única clave que poseen dos o más usuarios. Esta clave será la que cifrará y descifrará la información transmitida a través de un determinado canal. Existen diferentes algoritmos de clave simétrica que deben cumplir las siguientes condiciones para considerarlos fiables: Una vez que el mensaje es cifrado, no se puede obtener la clave secreta ni tampoco el texto plano. Si se conociera el texto plano y el texto cifrado, se debe tardar más y gastar más dinero en obtener la clave secreta, que el posible valor derivado de la información sustraída (texto plano). En la siguiente figura podemos ver el funcionamiento de los algoritmos de clave simétrica:

34

5.3. Seguridad

Figura 5.3:

Funcionamiento de la criptografía de clave simétrica.

La seguridad en los algoritmos de clave simétrica reside en la propia clave secreta, por lo que el principal problema es la distribución de dicha clave a los distintos usuarios para cifrar y descifrar la información. Por otro lado, su principal ventaja es su velocidad y su gran eficiencia para el cifrado de grandes cantidades de datos. Para resolver el problema del envío de la clave simétrica mediante un canal inseguro, existen opciones como la creación de claves asimétricas, cifrar la clave simétrica, y enviarla encriptada, como se verá en la siguiente sección, en la que se explica el algoritmo RSA. Algunos de los algoritmos más conocidos de clave simétrica son: [26] DES (Data Encryption Standard) 3DES (Triple Data Encryption Standard) RC4, RC5, RC5 (Rivest Cipher) IDEA (International Data Encriptión Algorithm) AES (Advanced Encryption Standard) Blowfish Para el presente proyecto se buscaba un algoritmo que fuera soportado por la API de Android y que pudiera ser programado. Para ello, viendo el listado de algoritmos soportados del objeto Cipher de Android, se comprobó que podían utilizarse algoritmos como AES, Blowfish, RC4 o DES. Finalmente se escogió el algoritmo AES [27], debido a que es el algoritmo estándar recomendado por NIST (National Institute of Standards and Techology), instituto por el que fue seleccionado cuidadosamente. Es el más extendido, con mayor documentación y el que más criptoanálisis ha recibido

Herramientas utilizadas

35

debido a su robustez, por lo que se convierte en el algoritmo más indicado para ser usado. AES, también conocido como Rijndael, es un esquema de cifrado de bloques, siendo uno de los más populares usados en criptografía simétrica. Este sistema criptográfico opera con bloques y tamaños de llave de 128, 192 o 256 bits. El resultado intermedio del cifrado constituye una matriz de bytes de cuatro filas por cuatro columnas. A esta matriz se le vuelve a aplicar una serie de bucles de cifrado basado en operaciones matemáticas. Estas operaciones matemáticas se basan en sustituciones no lineales de bytes, desplazamiento de filas de la matriz, combinaciones de las columnas mediante multiplicaciones lógicas y sumas XOR en base a claves intermedias. [28]

Figura 5.4:

Estructura del algoritmo de encriptación AES.

Respecto a la seguridad de AES, consta de 10 rondas para llaves de 128 bits, 12 rondas para llaves de 192 bits y 14 rondas para llaves de 256 bits. Los algoritmos de cifrado de bloque como AES separan el mensaje en trozos de tamaño fijo, por ejemplo de 64 o 128 bits. La forma en que se gestionan estos bloques de mensaje, se denomina “modo de cifrado”. Existen los siguientes modos de cifrado en bloques: [29] Modo ECB (Electronic Code Book): En este modo se hace una división por bloques y cada bloque se cifra uno a la vez. Los bloques cifrados son totalmente independientes entre sí, por lo que los errores de transmisión solo afectarán al bloque que contiene el error. El modo ECB es el más

36

5.3. Seguridad débil de los modos, ya que no posee suficientes medidas de seguridad, aunque es el más rápido de implementar. Modo CBC (Cipher Block Chaining): En este modo de operación, a cada bloque de texto cifrado con ECB se le aplica una operación XOR con el bloque previo cifrado. De este modo, cada bloque cifrado depende de todos los bloques usados hasta ese punto. Este modo de funcionamiento es más seguro que el ECB debido a que la operación XOR añade un proceso más al cifrado. Modo OFB (Output Feedback): El keystream se genera cifrando el bloque anterior del keystream. Este término hace referencia a un flujo pseudo aleatorio de caracteres que son combinados con un mensaje en texto plano. Este cifrado da lugar al siguiente bloque. El primer bloque se genera mediante un vector de inicialización. Modo CFB (Cipher Feedback): Para producir el keystream se cifra el último bloque de cifrado, en lugar del último bloque del keystream como hace OFB.

Estos dos últimos modos poseen una seguridad razonable, pero el cómputo es más lento que los dos primeros modos. Por lo tanto, en el caso de este proyecto, se ha usado el modo de cifrado CBC, debido a que el tiempo de cómputo es aceptable y es más seguro que el modo ECB. En este modo a cada bloque de texto plano se le aplica la operación XOR con el bloque cifrado anterior antes de ser cifrado. De esta forma, cada bloque de texto cifrado depende de todo el texto plano procesado hasta este punto. Al no disponer de un texto cifrado con el que combinar el primer bloque, se usa un vector de inicialización (número aleatorio que puede ser públicamente conocido), conocido como IV.

5.3.2.

Criptografía asimétrica: RSA

La criptografía asimétrica, conocida como criptografía de clave pública, es el método criptográfico que usa un par de claves para el envío de los mensajes. Las dos claves deben pertenecer a la misma persona que ha enviado el mensaje. Una clave es pública y se puede entregar a cualquier persona, y la otra clave es privada y solo la conocerá el propietario de las claves. Cabe destacar, que los métodos criptográficos garantizan que este par de claves solo podrá generarse una vez, por lo que no existe la posibilidad de que se generen dos pares de claves iguales. El funcionamiento es el siguiente: si la persona que desea enviar un mensaje lo cifra con su clave privada, cualquier persona podrá descifrarlo con la clave pública. Con esto se consigue la identificación y autenticación de la

Herramientas utilizadas

37

persona que envía el mensaje, ya que únicamente solo una persona puede encriptar el mensaje con su clave privada. Esta rama de la criptografía de clave pública es llamada firma digital. En cambio, también cabe la opción de cifrar un mensaje con la clave pública de una persona, por lo que solo podrá ser desencriptada por la clave privada correspondiente a dicha clave pública. Encriptando un mensaje de esta manera, se garantiza la confidencialidad del mensaje. Este método fue inventado con el fin de evitar el problema del intercambio de claves en los sistemas de cifrado simétrico, en los que se requiere una única clave secreta, tanto para encriptar como para desencriptar.

Figura 5.5: Funcionamiento de criptografía asimétrica utilizando encriptación con clave pública. Algunos algoritmos de tecnología de clave asimétrica son: DSA ElGamal Criptosistema de Merkle-Hellman Criptografía de curva elíptica RSA El más importante de éstos y el más utilizado es RSA [30]. Así, en el caso de este proyecto, se ha utilizado RSA, por lo que se explicará dicho algoritmo. RSA (Rivest, Shamir y Adleman), es el algoritmo más utilizado en los sistemas de criptografía asimétrica, y está basado en una pareja de claves, pública y privada, comentadas anteriormente. La seguridad de este algoritmo radica en el problema de factorización de números enteros. Los mensajes enviados se representan mediante números, y el funcionamiento se basa en el producto, conocido, de dos números primos grandes elegidos al azar y mantenidos en secreto.

38

5.3. Seguridad

El funcionamiento del algoritmo es similar a lo explicado anteriormente, en el que se encriptará un mensaje con una clave pública o privada perteneciente a una persona, y se desencriptará con su respectiva clave privada o pública.

Capítulo 6

Diseño e implementación En el presente capítulo se van a abordar los aspectos referentes al diseño y a la implementación del sistema que se pretende desarrollar en este proyecto, cuyos términos teóricos se han desarrollado anteriormente. Posteriormente, se tratarán los temas de la programación implementada para el desarrollo de las aplicaciones y el servidor, el diseño de la interfaz de la aplicación del cliente, y el protocolo de envío de mensajes entre las aplicaciones.

6.1.

Desarrollo de las aplicaciones en Android

En este capítulo se describirán los aspectos relacionados con la programación en Android, utilizada para desarrollar la aplicación cliente y la del TV Stick. Se realizará una documentación detallada, explicando la funcionalidad de las clases utilizadas, sin necesidad de que el lector tenga que conocer el código utilizado. Adicionalmente, se comentará la interfaz de la aplicación cliente, desarrollada en las diferentes clases de la programación en Android. Esta interfaz fue diseñada para que fuera sencilla y fácil de comprender por el usuario que se disponga a utilizar la aplicación, teniendo únicamente dos botones que se utilizarán para enlazar el dispositivo por Bluetooth al TV Stick. Además de la comunicación Bluetooth, el usuario no deberá realizar ninguna otra operación hasta ser dirigido a la página web del Servicio de Proyección de Material Docente, que gestiona el almacenamiento de dicho material y su visualización en el TV Stick. Las operaciones realizadas en dicha página quedan fuera del objetivo del proyecto, por lo que el usuario no deberá tener dificultades para utilizar la interfaz de la aplicación. 39

40

6.1.1.

6.1. Desarrollo de las aplicaciones en Android

Programación de la aplicación cliente

En esta sección se explican detalladamente las clases del cliente y su funcionalidad, sin entrar especialmente a fondo en la programación. Por otro

Figura 6.1:

Diagrama de clases para la aplicación cliente.

Diseño e implementación

41

lado, la interfaz como se verá más adelante se ha desarrollado de manera que el usuario sea capaz de distinguir con claridad los distintos elementos y el funcionamiento de la aplicación. En la figura anterior (véase figura 6.1) se ve una representación de como actúan las clases entre sí, dónde las flechas acabadas en un rombo blanco tienen como significado que una clase actúa para la que apunta la flecha, y las flechas en negro indican el proceso de inicio de una Activity. A continuación se detallarán todas las clases utilizadas para la aplicación, teniendo en cuenta que las clases que tengan la palabra Activity en su nombre, serán una Activity de la aplicación. Estas son las distintas clases utilizadas en la aplicación cliente:

Clase PortadaActivity La clase PortadaActivity es únicamente utilizada para visualizar una portada al iniciarse la aplicación, en la que se mostrará el logo de la UGR durante 1 segundo. Esta es la clase más sencilla de las programadas, ya que únicamente se muestra la portada y tras transcurrir 1 segundo de la proyección, se llamará a la clase PaginaLoginActivity, que se verá a continuación.

La portada que se proyecta al iniciarse la aplicación puede verse en la siguiente figura:

42

6.1. Desarrollo de las aplicaciones en Android

Figura 6.2:

Portada de la aplicación cliente.

Clase PaginaLoginActivity La clase PaginaLoginActivity es utilizada para enviar al usuario al login de la página web del Servicio de Proyección de Material Docente, en dónde dicho usuario deberá introducir sus credenciales de acceso al SPMD para utilizar la aplicación. Esta página web es en concreto la siguiente: https://palas.ugr.es/SPMD/entrar.php, desarrollada por los componentes del PID para el que trabaja este proyecto. Para la programación de esta clase se ha utilizado un elemento de Android llamado WebView, con el que se ofrece la posibilidad de mostrar una página web cualquiera, incluida en la aplicación y sin necesidad de utilizar un navegador. Esto supone que una vez que el usuario esté navegando por la página, no tendrá la posibilidad de introducir una dirección, por lo que solo será posible navegar en dicha página a través de los enlaces disponibles. Para controlar la dirección URL en la que se encuentra actualmente el

Diseño e implementación

43

WebView, se ha utilizado el método de la clase WebViewClient, conocido como shouldOverrideUrlLoading(WebView view, String url), cuya función es controlar la dirección URL en la que se encuentra actualmente el WebView y realizar diferentes acciones según convenga. En caso de que el login sea incorrecto, la URL será la misma, por lo que no habrá que desarrollar ninguna acción para ese caso. Al realizarse el login correctamente, el usuario será redirigido a la URL siguiente: https://palas.ugr.es/SPMD/index.php, por lo que se ha programado que si en algún momento la dirección URL del WebView es la anterior, se concluirá que el login se ha realizado correctamente. Si esto ocurre, se llamará a la clase MainActivity, que será la encargada de realizar los procesos principales de la aplicación. En la siguiente figura (véase figura 6.3) se puede visualizar el aspecto del WebView en la dirección en la que se realiza el login del SPMD.

Figura 6.3:

Login de SPMD visualizado a través de un WebView en un dispositivo Android.

Por otro lado, como en todas las aplicaciones, existen datos que se guardan en la memoria caché del teléfono, por lo que es probable que la sesión en la página del SPMD se mantega iniciada aunque se haya salido de la aplicación. Si se desea que esto no ocurra, el usuario deberá borrar los datos de la aplicación desde su terminal Android. Clase MainActivity La clase MainActivity es la clase principal de la aplicación, donde comienzan todos los procesos referentes a la comunicación Bluetooth, y en la que se ha diseñado la interfaz con la que interactuará el usuario para poder realizar la conexión Bluetooth al TV Stick, Antes de explicar los distintos métodos a los que llama MainActivity se hará una descripción del funcionamiento de la clase y los diferentes pasos que se siguen hasta que se decide conectar con un dispositivo.

44

6.1. Desarrollo de las aplicaciones en Android Paso 1: Creación de variables En este paso se crearán en primer lugar las variables de clase que vayan a utilizarse. Las dos más importantes son el BluetoothAdapter, variable que se encargará de obtener el adaptador Bluetooth del dispositivo para poder trabajar con él, y un BroadcastReceiver, cuyo objetivo es recibir o enviar acciones (Intents a partir de ahora). Cuando el BroadcastReceiver reciba un Intent realizará una serie de acciones que se verán más adelante. Paso 2: Referenciación de elementos Como se comentó en el apartado de desarrollo de la interfaz, los elementos visuales que el usuario percibe son cuatro: tres botones (Button) y un listado (ListView ). El primer método encargado de la referenciación de estos elementos será uno llamado referenciarControles(), encargado de referenciar las variables creadas en la clase con sus respectivos elementos (Buttons y ListView ). Seguidamente se llama a registrarEventosControles(), donde se les añade a los botones la capacidad de realizar diferentes acciones cuando el usuario los presiona. Al ListView se le añadirá esa capacidad una vez que haya terminado la búsqueda de dispositivos como se verá más adelante. Por otro lado, en el conocido método sobrescrito onClick(View v), se definirán las acciones que deben tomarse al pulsar los distintos botones. Al pulsar el botón de activar la conectividad Bluetooth se lanzará una acción (Intent) que recogerá el BroadcastReceiver para realizar las acciones correspondientes. En estas acciones el BroadcastReceiver cambiará el texto y estado de los botones. Al pulsar el botón de buscar dispositivos se empezará la búsqueda de dispositivos se comenzará la búsqueda de dispositivos como se verá en el paso tres, y por último, el botón para salir de la aplicación simplemente finalizará los procesos y saldrá de la aplicación. Paso 3: Búsqueda de dispositivos Al pulsar el botón de buscar dispositivos empezará la búsqueda de dispositivos mediante el adaptador Bluetooth y su método startDiscovery(). Este método lanzará un Intent que recogerá el BroadcastReceiver y que realizará las acciones correspondientes. Estas acciones se basan en la creación de un ArrayList en el que se guardarán los distintos dispositivos encontrados, extraídos previamente del Intent. Se extraerá el nombre y la dirección MAC del dispositivo, mostrándose

Diseño e implementación

45

en pantalla cada vez que se encuentre uno el nombre más su dirección MAC.

Paso 4: Conexión con dispositivo

Una vez que la búsqueda de dispositivos ha finalizado se recibirá dicho Intent en el BroadcastReceiver y se llamará a la clase BluetoothDeviceArrayAdapter que se comentará más adelante. Esta clase devolverá un ArrayAdapter que se mostrará en el ListView. Una vez que se ha mostrado la lista de dispositivos encontrados al usuario, éste tendrá la opción de escoger uno con el cual realizar la conexión. Cuando el usuario haya escogido un dispositivo se creará un objeto de la clase ThreadConexionBT y se empezará una hebra que se encargará de la conexión con dicho dispositivo.

Se hablará ahora de la interfaz de la aplicación cliente, mostrándose figuras para su correcta visualización.

Interfaz de la aplicación El diseño inicial de la interfaz de la aplicación consta únicamente de dos botones: uno para activar la conectividad Bluetooth y otro para buscar dispositivos. Este último no estará disponible hasta que el Bluetooth no esté activado.

46

6.1. Desarrollo de las aplicaciones en Android

Figura 6.4:

Interfaz de la aplicación (sin Bluetooth activo).

Diseño e implementación

Figura 6.5:

47

Interfaz de la aplicación (con Bluetooth activo).

El funcionamiento de la aplicación se explicará en el anexo dedicado al manual de usuario (véase anexo B). Clase BluetoothDeviceArrayAdapter La clase BluetoothDeviceArrayAdapter es una clase que, como su propio nombre indica, devuelve un adaptador de listas (ListAdapter) utilizado para mostrar el listado de dispositivos encontrados vía Bluetooth. Su funcionamiento se basa en la creación de vistas mediante un LayoutInflater,método que se utiliza para construir y añadir Views a distintos diseños a partir de una capa (Layout) realizada en formato XML. Utili-

48

6.1. Desarrollo de las aplicaciones en Android zando el método inflate de LayoutInflater podremos crear una vista que contendrá dos TextView : uno con el nombre del dispositivo y otro con la dirección MAC para cada uno de los dispositivos Bluetooth que han sido encontrados y guardados en una lista (List).

Clase ThreadConexionBT

La clase ThreadConexionBT es la encargada de realizar la petición de conexión a otro dispositivo. Cuando el usuario selecciona un dispositivo de la lista, la clase MainActivity hará una llamada a la clase ThreadConexionBT, pasándole a su constructor el dispositivo seleccionado, que tal y como se describió en el capítulo referente al Bluetooth (Capítulo 5.2), se utilizará para crear un BluetoothSocket mediante createInsecureRfcommSocketToServiceRecord y un UUID o identificador único. Una vez creado el BluetoothSocket el sistema estará listo para realizar una conexión mediante el método connect(), siempre que haya un BluetoothSocket en la parte receptora a la espera de una conexión entrante. Si la conexión mediante sockets de Bluetooth tiene éxito empezará el envío de mensajes entre ambos dispositivos mediante la clase ThreadMensajes que se describirá a continuación.

Clase ThreadMensajes

La clase ThreadMensajes tiene como objetivo principal el envío y recepción de mensajes de texto(Strings) entre dos dispositivos conectados mediante BluetoothSocket, que en el caso del presente proyecto será entre el dispositivo del usuario y el TV Stick. Por otro lado, esta clase introduce las claves Wi-Fi y VPN en los archivos internos del dispositivo, una vez que éstas han sido recibidas. Esta clase hereda de la clase Thread y dispondrá del BluetoothSocket utilizado para la conexión, objeto que además contiene dos métodos realmente útiles para el envío y recepción de mensajes que son getInputStream() y getOutputStream() respectivamente. Al iniciar la hebra, se enviará un mensaje mediante el método getInputStream() al TV Stick, y una vez que se obtenga una respuesta a dicho mensaje, se creará un bucle infinito en el que ambas partes se intercambiarán nuevas cadenas de texto. Estos son los mensajes enviados por parte del cliente y su correspondiente significado resumido:

Diseño e implementación

49

Mensaje enviado

Mensaje a recibir

Descripción

’id?’

ID del dispositivo TV Stick

Con este mensaje se pretende conocer el ID del dispositivo TV Stick con el que se ha realizado la conexión. Una vez obtenida la respuesta del TV Stick se realizará una conexión al servidor que devolverá un reto.

’reto’ + reto del servidor

Reto completado por el TV Stick

Este mensaje que tendrá una cabecera de cuatro caracteres que será ’reto’, enviará el reto enviado por el servidor al TV Stick

Ninguno

Este mensaje tendrá como cabecera los cuatro caracteres ’auth’ y adicionalmente se enviarán las claves Wi-Fi y VPN al TV Stick únicamente si éste hubiese completado el reto del servidor correctamente.

’auth’ + claves Wi-Fi y VPN

Tabla 6.1:

Mensajes enviados por la aplicación cliente

Estos mensajes se verán detalladamente en el capítulo dedicado al protocolo de envío de mensajes. Clase PeticionServidor La clase PeticionServidor, como su propio nombre indica, tiene como objetivo realizar una petición a una dirección URL específica, que en el caso del presente proyecto será a la dirección del servidor de autenticación, que se alojará en el servidor del SPMD. Por lo tanto, al utilizar la dirección del servidor de autenticación, se obtendrá el reto necesario para la autenticación y además, en caso de que la autenticación sea correcta, se obtendrán las credenciales Wi-Fi Y VPN. Esta petición se realizará mediante una clase que hereda de AsynTask y un método de dicha clase, conocido como doInBackground, donde se realizarán diferentes acciones de manera asíncrona. El método que se utilizará será HttpURLConnection que hará uso de la URL especificada para obtener el contenido mediante el objeto BufferedInputStream. Clase PaginaSPMDActivity La clase PaginaSPMDActivity se trata de la última Activity de la aplicación, y tendrá como función abrir una la página web del SPMD, https://palas.ugr.es/SPMD/index.php, una vez enviadas las claves WiFi y VPN al TV Stick. Esta página web se mostrará únicamente de

50

6.1. Desarrollo de las aplicaciones en Android manera horizontal para su correcta visualización, debido a que la visualización verticalmente presenta problemas en dispositivos móviles, problema que es ajeno a este proyecto. Por otro lado, en esta página visualizada en el WebView, el usuario se encontrará conectado con su cuenta, ya que los datos de acceso debieron ser introducidos en la clase PaginaLoginActivity y se guardarán en los datos de la aplicación. Es en este punto, cuando el usuario podrá acceder al material alojado en el servidor y transmitirlo a los proyectores de las aulas. Este procedimiento se hará mediante el objeto WebView, al igual que en la clase PaginaLoginActivity, entre otros métodos de menor importancia. Cabe estacar que esta página web mostrará el contenido dentro de la misma aplicación y no en un navegador diferente.

6.1.2.

Programación de la aplicación TV Stick

En esta sección se explica la programación básica utilizada en la aplicación que se instalará en el TV Stick. Cabe destacar que dicho dispositivo deberá especificar en sus ajustes Bluetooth que se desea estar visible para todos los dispositivos que realicen una búsqueda Bluetooth, y además ajustar un tiempo ilimitado para dicha visibilidad, debido a que la aplicación deberá estar siempre disponible para cualquier usuario que desee realizar la conexión. En la siguiente figura (véase figura 6.6) puede observarse la relación entre las distintas clases.

Diseño e implementación

Figura 6.6:

Diagrama de clases para la aplicación TV Stick.

51

52

6.1. Desarrollo de las aplicaciones en Android

A continuación se detallarán todas las clases utilizadas para la aplicación de manera resumida, puesto que en la sección anterior se ha explicado la programación de clases similares: Clase MainActivity La clase MainActivity, al igual que en la aplicación cliente, hereda de la clase AppCompatActivity y tendrá como objetivo la de inicializar las variables principales y hacer una llamada a las hebras encargadas de la conexión Bluetooth. La diferencia de esta clase con la que se utilizaba en la aplicación cliente es que no será necesario realizar una búsqueda de dispositivos y tampoco el uso de ningún botón o TextView que sea visto por pantalla, ya que esta aplicación no tiene la necesidad de interactuar con el usuario. En primer lugar se inicializará un UUID, que será el mismo que en la aplicación cliente, y además un nombre que se obtendrá del UUID al convertirlo a String y que es necesario para realizar la conexión Bluetooth. Estas variables serán utilizadas por la clase ThreadConexionBT al igual que en la aplicación cliente. Una vez declaradas dichas variables se sobrescribirá la función onStart(), en la cual se le indicará a la aplicación que active automáticamente la conectividad Bluetooth mediante el método enable() del adaptador Bluetooth (BluetoothAdapter ), justo al iniciar la aplicación por primera vez, por si se diese el caso en que la conectividad Bluetooth Bluetooth del TV Stick estuviese desactivada. La conexión deberá estar configurada en los ajustes del dispositivo con un tiempo ilimitado de visibilidad para otros dispositivos. Esta funcionalidad no se ha realizado mediante programación puesto que utilizando la API Bluetooth de Android era necesaria intervención del usuario con la aplicación para activar dicha visibilidad y además no era compatible con todas las versiones Android. Una vez que la conexión Bluetooth está activa y visible para todos los dispositivos se procederá a crear el objeto de la clase ThreadConexionBT y empezará a funcionar la hebra. Clase ThreadConexionBT La clase ThreadConexionBT, que hereda de Thread, tendrá como objetivo que la aplicación espere a recibir una conexión Bluetooth entrante. Para ello se utilizará el método listenUsingInsecureRfcommWithServiceRecord del objeto BluetoothAdapter que creará un BluetoothSocket como se explicó en el apartado de Bluetooth. En la función sobrescrita run() de la hebra se llamará al método accept() de BluetoothSocket que esperará a recibir la conexión Bluetooth entrante, y una vez aceptada se obtendrá el dispositivo remoto que ha

Diseño e implementación

53

solicitado la conexión mediante el método getRemoteDevice() de BluetoothSocket y la aplicación estará lista para llamar a la siguiente clase: ThreadMensajes. Por otro lado, en caso de que se produzca un error de conexión o que se pierda la conectividad con el dispositivo remoto, la aplicación deberá volver al punto de espera para recibir una conexión entrante, debido a que de este modo la aplicación siempre estará operativa incluso al acabar una conexión con otro dispositivo. Clase ThreadMensajes La clase ThreadMensajes tiene distintos objetivos: enviar y recibir mensajes con la aplicación cliente, desencriptar mensajes e introducir las claves recibidas en el dispositivo. Como se explicó en el apartado de la programación de la aplicación cliente, la clase ThreadMensajes envía y recibe mensajes (Strings) mediante los métodos getInputStream() y getOutputStream() de BluetoothSocket, por lo que el funcionamiento es el mismo. Los mensajes que se enviarán son los siguientes: Mensaje esperado ’id?’

’reto’ + reto del servidor

’auth’ + claves Wi-Fi y VPN

Mensaje enviado ’id_dispositivo_’ + ID del dispositivo TV Stick ’reto_enc’ + reto del servidor encriptado

claves_recibidas

Tabla 6.2:

Descripción Este mensaje se envía como respuesta al mensaje del cliente ’id?’ e indica el ID del TV Stick, que es único para cada dispositivo. Se envía el reto solicitado por el servidor de forma encriptada para que el servidor compruebe que la autenticación es correcta. El mensaje recibido ’auth’ indica que la autenticación se ha realizado correctamente y que las claves Wi-Fi y VPN han sido enviadas al TV Stick. En el caso de que se reciban se enviará el mensaje claves_recibidas.

Mensajes enviados por la aplicación TV Stick

En la tabla se puede observar que el primer mensaje que la aplicación envía incluye el ID del dispositivo TV Stick, único para cada uno. Cuando la aplicación cliente reciba dicho ID, contactará con el servidor que le devolverá un reto y que reenviará al TV Stick con la cabecera

54

6.1. Desarrollo de las aplicaciones en Android ’reto’. Mediante la clase Criptografia que se verá posteriormente, se encriptará dicho reto y se volverá a enviar al cliente. Cuando el servidor confirme que el reto es correcto y por lo tanto la autenticación se ha completado, el TV Stick obtendrá las claves Wi-Fi y VPN de manera encriptada mediante un mensaje enviado por la aplicación cliente. Como se ha comentado anteriormente, el reto que envía el servidor deberá ser devuelto encriptado por la aplicación TV Stick y desencriptado por el servidor para comprobar la autenticación. Por otro lado, las claves llegarán al TV Stick encriptadas y deberán ser desencriptadas por la aplicación del TV Stick. Estas encriptaciones y desencriptaciones se llevarán a cabo mediante la clase Criptografia. Clase Criptografia La clase Criptografia tiene como principal objetivo el desarrollo de funciones con capacidad de encriptar y desencriptar utilizando diferentes tipos de cifrado, en concreto AES (Advanced Encryption Standard). que hará uso de una clave secreta, y RSA (Rivest, Shamir y Adleman) que hará uso de un par de claves (privada y pública), pertenecientes al TV Stick y que el servidor también poseerá. En primer lugar, se hizo una búsqueda de librerías que permitieran el uso de criptografía en Android. La librería que se decidió utilizar es conocida como Spongy Castle, un proyecto que es una versión modificada de Bouncy Castle, una colección de APIs que venía incluido en Android y que se utilizaba para criptografía, pero que empezó a dar problemas en las versiones más recientes de Android. Para solucionar estos problemas nacía Spongy Castle, creada por terceros. En lo referente a la programación, se crearon dos funciones para encriptar con cifrado de tipo AES, que será el primer uso de criptografía utilizado, ya sea para encriptar el reto que devuelve el TV Stick al cliente o para desencriptar las claves Wi-Fi y VPN que envía el servidor. Estas funciones hacen uso de la clase Cipher para la implementación de cifrados, a la cual se le indicará el tipo de cifrado que se desea, en este caso AES en modo CBC (Cipher Block Chaining) y con un padding PKCS 5. Es necesario además, declarar un IV o Vector de Inicialización, que es un bloque de bits requerido para permitir un cifrado en bloques y que deberá ser el mismo tanto en el TV Stick como en el servidor para que la desencriptación de los mensajes encriptados sea posible. Otra declaración necesaria es la de una clave simétrica o clave secreta, que también deberá ser la misma que en la parte servidora y que es necesaria tanto como para encriptar y desencriptar un mensaje en concreto, siempre que las claves en ambos lados coincidan.

Diseño e implementación

55

Con estas variables declaradas y la clase Cipher se podrá encriptar un mensaje (String) que a su vez será encriptado en Base64 para representar la información binaria originada de la codificación. El segundo grupo de funciones realizará una encriptación o desencriptación de la clave secreta utilizada para la encriptación en AES de un mensaje en concreto como se vio en los párrafos anteriores. Para ello se utilizarán cifrados RSA mediante el uso de una clave privada perteneciente al TV Stick, lo que significa que en el lado del servidor las encriptaciones o desencriptaciones se realizarán mediante la clave pública del TV Stick, por lo que solo estos dos lados del sistema serán capaces de conocer el contenido real del mensaje. Esta función se hará mediante el uso de un Cipher como en el caso de la criptografía en AES, diferenciándose en que se utilizará encriptación RSA y modo SC (Stream Cipher). Con esta clase, termina la explicación resumida de la programación realizada en Android.

6.2.

Desarrollo del servidor de autenticación

Para el funcionamiento del PID por el que se realiza este proyecto, es necesario el uso de un servidor central. Dicho servidor es gestionado por el tutor del proyecto, Jorge Navarro Ortiz y tiene como objetivo administrar el material docente alojado en el mismo. Adicionalmente, para el objetivo de este proyecto, se deberá hacer uso de algún método para autentificar con el servidor, los dispositivos TV Sticks a los que se le enviarán las claves, con el fin de evitar problemas de que se realice el envío a algún dispositivo no autorizado para recibirlas. Para ello, se han programado en el servidor central del PID diferentes archivos en formato PHP con la capacidad de autenticar a los dispositivos que soliciten una petición a dicho servidor. El método pensado para la autenticación es mediante un reto o mensaje que solo conozca el servidor, y la generación de un certificado digital, que constará de una clave pública y privada para cada dispositivo TV Stick, además de una clave secreta de la persona que genera el mensaje. A cada dispositivo TV Stick se le proporcionará una clave pública y otra privada, aunque en realidad dicho dispositivo solo necesitará hacer uso de su clave privada para las encriptaciones y desencriptaciones. Por otro lado, el servidor deberá tener almacenadas como mínimo, las claves públicas para cada dispositivo. El reto generado por el servidor, que será enviado en texto plano al TV Stick a través de la pasarela, deberá ser encriptado con la clave privada de

56

6.2. Desarrollo del servidor de autenticación

éste, y una vez realizado este proceso, será devuelta a través de la pasarela al servidor, que deberá desencriptarlo con la clave pública del TV Stick, conociendo previamente el identificador de dicho dispositivo para seleccionar la clave pública apropiada. Si el mensaje desencriptado por parte del servidor coincide con el mensaje enviado por éste inicialmente, la autenticación será correcta y el servidor procederá a enviar las credenciales a la aplicación cliente, que las reenviará al TV Stick. Si la autenticación no es correcta, el envío de claves no se llevará a cabo. En las siguientes figuras se puede ver el proceso de la autenticación con imágenes, partiendo de que el TV Stick tiene como identificador el número ’123’.

Figura 6.7:

Figura 6.8:

Figura 6.9: Stick.

Generación del reto por parte del servidor.

Encriptación del reto por parte del TV Stick.

Proceso de desencriptación en el servidor del reto encriptado por parte del TV

Diseño e implementación

Figura 6.10:

57

Comparación del reto generado por el servidor y el mensaje recibido.

Una vez explicado el funcionamiento del servidor de autenticación, se procederá a explicar de manera básica la programación utilizada: La programación en PHP se basa en la creación de dos archivos PHP: uno que contiene las funciones encargadas de encriptar y desencriptar mediante AES y RSA, y otro que será el que envíe las credenciales correspondientes tras comprobar que el reto ha sido resuelto correctamente. En el siguiente diagrama puede observarse como funcionarán los dos archivos PHP alojados en el servidor, en el caso de que se realice una llamada al archivo reto.php. Se muestra un ejemplo considerando que la autenticación ha sido correcta y por lo tanto, se procede al envío de claves al cliente. Además, se considera también que el cliente, al recibir el reto, realiza los pasos correspondientes para encriptarlo.

Figura 6.11:

Intercambio de mensajes en el servidor, en el caso de autenticación correcta.

58

6.2. Desarrollo del servidor de autenticación

Para el primero de los archivos PHP, llamado Criptografia.php, se han utilizado unas librerías denominadas phpseclib para la implementación de RSA a la hora de encriptar o desencriptar, ya que PHP no dispone de las librerías correspondientes para realizar esta función. En cambio, si es posible la criptografía mediante AES sin el uso de librerías adicionales, utilizando las funciones propias de PHP. Como se ha comentado en diferentes ocasiones, la encriptación se utilizará al enviar las distintas credenciales de manera encriptada, y la desencriptación tendrá como objetivo desencriptar el reto encriptado proveniente del TV Stick. Cabe destacar que la criptografía utilizada en PHP deberá tener la mismas características que las usadas en Android, es decir, se deberá utilizar el mismo vector inicial (IV), el mismo modo (CBC) y el mismo padding (PKCS 5) al utilizar criptografía basada en AES. Por otro lado, para el uso de RSA simplemente será necesario que se disponga del par de claves generado para cada TV Stick. El IV será enviado junto con los mensajes encriptados, por lo que siempre será el mismo en ambos lados. El segundo de los archivos PHP creados, nombrado como reto.php, tendrá la capacidad de generar el reto y enviar las credenciales. Al realizar una llamada a reto.php, se generará el reto, formado por la fecha y hora a la que se hace la llamada, y un número totalmente aleatorio comprendido entre 1000 y 999999. Por ejemplo, un reto podría tener la siguiente forma: 02-062016-02:45:23-PM-544368. Al generarse dicho reto, se creará un fichero con el contenido del mismo para su posterior recuperación, y una vez creado se enviará el mensaje en texto plano al dispositivo que realizó la petición. En el caso de que el TV Stick haya encriptado el reto recibido con su clave privada, se enviará dicho mensaje, encriptado y codificado en Base64, al servidor de autenticación, mediante un mensaje contenido en la URL al realizar la petición, con el objetivo de obtener los datos necesarios mediante la variable GET de PHP. Esta variable GET, recoge todos los campos contenidos en la URL tras un símbolo de interrogación (? ). Adicionalmente, se le indicará en la URL el ID del dispositivo que desea obtener las credenciales para conocer que clave pública utilizar. Una vez que se ha elegido la clave pública según el ID recibido en la URL, se desencriptará el mensaje, que para una correcta autenticación debe coincidir con el que generado en primer lugar. Se obtendrá el contenido del fichero para el cual se generó el reto y se compararán ambas cadenas de texto. Si el mensaje recibido y el reto guardado en el fichero coinciden se procederá al envío de credenciales de manera encriptada con RSA y AES, además de la correspondiente codificación en Base64, añadiendo al mensaje la cabecera ’OKAY’. En caso contrario se enviará el mensaje ’FAIL’, indicando que no ha sido posible la autenticación.

Diseño e implementación

6.3.

59

Protocolo de envío de mensajes

En la presente sección se describirán los mensajes que participan en la comunicación entre los distintos dispositivos, indicando cuál es su función. En primer lugar, en la siguiente figura (véase figura 6.12) se puede observar el diagrama de mensajes que se envían al iniciar el sistema.

Figura 6.12:

Intercambio de mensajes entre TV Stick, Cliente y Servidor.

Como se observa en el diagrama, el primer mensaje lo inicia el cliente,

60

6.3. Protocolo de envío de mensajes

en el momento en el que un usuario decide conectarse a un TV Stick. Este mensaje tendrá únicamente el contenido "id? ", como una cadena de texto, y tendrá como objetivo conocer el identificador único del TV Stick. El TV Stick, al recibir este mensaje, responderá con su identificador único, que estará implícito en la programación de la aplicación. Para dicha respuesta se utilizará la cadena de texto "id_dispositivo"más el ID del dispositivo, por lo que un posible mensaje podría ser: "id_dispositivo123 ". Una vez que la aplicación cliente haya recibido dicho mensaje correctamente, se guardará el ID del dispositivo TV Stick con el que mantiene la conexión. El cliente enviará en ese momento una petición al servidor, sin enviar ningún mensaje adicional, ya que este reto estará disponible sin ninguna restricción. El servidor al recibir dicha petición, generará un reto y mostrará su contenido mediante HTML, y ese momento el dispositivo cliente obtendrá el reto. El cliente querrá enviar el reto al TV Stick, por lo que utilizará para ello la cabecera "reto", seguido del reto propuesto por el servidor. El TV Stick al recibir el reto del servidor y encriptarlo con sus claves correspondientes, devolverá el reto resuelto al dispositivo cliente, para ello añadirá la cabecera "reto_enc", haciendo referencia a que el reto ha sido encriptado, y a continuación, enviará el reto encriptado. El cliente deberá hacer una última llamada al servidor, indicando que el reto ha sido resuelto y esperando por el resultado de la autenticación y si se enviarán o no las claves. Para ello, se enviará el reto resuelto como cadena de texto en la URL, en forma de parámetros. Estos parámetros que irán junto a la URL serán el ID del TV Stick y el reto encriptado, y se obtendrán en PHP mediante la variable $_GET. Al momento de recibir dichos parámetros, el servidor comprobará si la autenticación es correcta como ya se explicó en la sección anterior. En caso de que sea correcta se enviará un mensaje con la cabecera "OKAY ", seguido de las credenciales necesarias, en este caso la clave Wi-Fi y VPN. Por el contrario, si la autenticación se concluye como inválida, se enviará el mensaje "FAIL el ID del dispositivo que ha fallado en la autenticación. 2

En el caso de que la autenticación no haya sido correcta, la aplicación cliente cancelará la conexión Bluetooth con el TV Stick, y deberá reiniciarse el proceso de autenticación. Por otro lado, si la autenticación ha sido exitosa, el cliente enviará la cabecera "auth", seguida de las credenciales Wi-Fi y VPN que necesitará el dispositivo para su conexión con el servidor. Finalmente, el TV Stick indicará que ha recibido las claves correctamente enviando al cliente el mensaje "claves_recibidas". En el caso de que no se hayan podido recibir debido a un fallo en la conexión Bluetooth se enviará el mensaje "claves_no_recibidas"

Diseño e implementación

6.4.

61

Uso de criptografía: RSA y AES

En esta sección, se va a explicar cómo se han utilizado los algoritmos AES y RSA para enviar mensajes encriptados a través de un canal inseguro, como la red de datos, red Wi-Fi o red Bluetooth, entre los dispositivos TV Stick, la aplicación cliente, y el servidor, con el fin de realizar la autenticación. El sistema que se pensó inicialmente para realizar el envío de mensajes entre las distintas partes del sistema, consistía en la encriptación de los mensajes utilizando el algoritmo AES. En un principio, se pensó utilizar RSA para la encriptación de los mensajes en texto plano, pero uno de los problemas de RSA es que puede encriptar una cantidad limitada de datos, dependiendo del tamaño de las claves generadas [2]. Así, con una clave de 1024 bits es posible encriptar un mensaje de 86 bytes, y a mayor tamaño de la clave, mayor será la información que puede encriptarse. Por otro lado, el inconveniente de utilizar una clave de una gran longitud, es el tiempo de espera para la desencriptación, ya que aumenta considerablemente respecto al tamaño de la clave. En la siguiente tabla puede verse como actúa RSA dependiendo del tamaño de clave. Longitud de clave (bits) 512 bits 1024 bits 2048 bits 4096 bits 8192 bits

Tiempo de encriptación (ms) 16 15 15 15 15

Tabla 6.3:

Tamaño de datos (bytes) 22 86 214 470 982

Tiempo de desencriptación (ms) 1 15 78 438 2625

Comportamiento de RSA según la clave utilizada. [2]

Otro de los inconvenientes de aumentar el tamaño de la clave en RSA es su tiempo de generación. Estos tiempos pueden verse en la siguiente tabla: Longitud de clave (bits) 512 bits 1024 bits 2048 bits 4096 bits 8192 bits Tabla 6.4:

Tiempo de generación (ms) 31 141 531 63844 116891

Tiempo de generación de una clave para RSA dependiendo de su tamaño. [2]

62

6.4. Uso de criptografía: RSA y AES

Visualizando las tablas anteriores, cabe mencionar que el tamaño de clave que se necesitaría para este proyecto dependerá del tamaño de las claves WiFi y VPN que se vayan a enviar, lo que mínimamente requerirá una clave de 4096 bits para la encriptación. Para evitar problemas con los tiempos de generación de claves y de desencriptación de mensajes, se decidió utilizar AES para encriptar el mensaje, ya que permite encriptar datos de tamaño muy superior. El problema surge al querer compartir la clave secreta y el IV utilizados para la encriptación de los mensajes, ya que deben tener los mismos valores tanto para la encriptación como para la desencriptación. Para solventar este problema, se pensó en utilizar criptografía asimétrica, específicamente RSA, para encriptar la clave secreta y el IV utilizados en AES, y enviarlos junto al mensaje final. Por lo tanto, en primer lugar, se encriptará el mensaje en texto plano, utilizando una clave secreta mediante el algoritmo AES, haciendo uso de un vector de inicialización que deberá tener una longitud de 16 bytes, ya que AES utiliza bloques de 128 bits (16 bytes). Una vez encriptado el mensaje, se calculará la longitud de la clave simétrica y la del IV en hexadecimal. Estas longitudes constarán de 3 bytes y se añadirá al mensaje final a enviar, con el fin de encontrar en la cadena de texto enviada la localización exacta de la clave simétrica encriptada y la del IV. Así, en primer lugar, al desencriptar un mensaje, se obtendrán las longitudes de la clave secreta y la del IV, y con estos datos se podrán localizar dichos elementos en el mensaje encriptado. Seguidamente, se encriptará la clave secreta utilizando el algoritmo RSA, donde la clave utilizada para la encriptación dependerá del remitente. Para el caso del TV Stick, la clave secreta se encriptará o desencriptará utilizando la clave privada del dispositivo. En cambio, el servidor de autenticación, utilizará la clave pública del dispositivo TV Stick, tanto para la encriptación como para la desencriptación. Además, se encriptará utilizando RSA el vector de inicialización (IV), con el objetivo de que el dispositivo que reciba el mensaje tenga la capacidad de desencriptar el mensaje final utilizando AES, que requiere el vector inicial con el que se encriptó el mensaje. Finalmente, se generará una cadena de texto formada por las siguientes variables: Longitud de la clave simétrica: 3 bytes sin encriptar al comienzo del mensaje que servirán para localizar la clave simétrica en la cadena de texto. Longitud del vector de inicialización: 3 bytes sin encriptar al comienzo del mensaje que servirán para localizar el vector de inicialización en la

Diseño e implementación

63

cadena de texto. Vector de inicialización: Se adjunta el vector de inicialización encriptado, que dependerá de la longitud de la clave simétrica. Este IV siempre tendrá una longitud de 16 bytes, ya que AES utiliza bloques de 128 bits. Se localizará tras los 3 primeros bytes del mensaje. Clave simétrica encriptada en RSA: Clave simétrica necesaria para desencriptar el mensaje en texto plano. Su localización estará comprendida entre los 19 primeros bytes de la cadena de texto (longitud de clave, sumándole los 16 bytes del IV) y la longitud de la clave simétrica, a la que se le sumarán 3 bytes. Mensaje encriptado en AES: Mensaje final que será desencriptado con la clave simétrica desencriptada mediante RSA y el vector de inicialización, desencriptado con el mismo método. Su localización en la cadena de texto estará comprendida entre el fin de la localización de la clave simétrica encriptada y el fin de la cadena de texto. Con la cadena de texto que se reciba en algún tipo de dispositivo, se desencriptará con RSA la clave simétrica y el IV, conociendo previamente la longitud de cada uno, y con ambos parámetros, se desencriptará el mensaje que se desea obtener utilizando AES, por lo que finalmente, el mensaje en texto plano que fue enviado y encriptado, podrá ser leído correctamente sin que haya podido ser obtenido por alguna entidad ajena al objetivo del proyecto. En las dos siguientes figuras, se ve un diagrama de todo el proceso de encriptación y desencriptación, comenzado por el TV Stick :

Figura 6.13:

Proceso de encriptación por parte del TV Stick.

64

6.4. Uso de criptografía: RSA y AES

Figura 6.14:

Proceso de desencriptación por parte del servidor.

Capítulo 7

Fase de pruebas Este capítulo describe el proceso que se ha llevado a cabo para realizar la fase de pruebas del proyecto. Esta fase de pruebas tiene como objetivo comprobar el comportamiento del sistema completo y solucionar posibles errores. A lo largo de la implementación del proyecto, se han ido realizando distintas pruebas, con el fin de comprobar que lo que se programaba funcionaba correctamente y sin fallos. Además, se corregían distintos aspectos de implementación de cara al uso de la aplicación por parte de un usuario. Las pruebas se han realizado utilizando un smartphone Sony Xperia Z1, que actuaba como móvil de usuario, y que por lo tanto tenía instalada la aplicación cliente. Además, el tutor del proyecto, proporcionó con el fin de realizar pruebas, un TV Stick MK809 III, con el sistema modificado que se usará en las aulas. Por otro lado, en un principio las pruebas entre la aplicación cliente y el servidor se realizaron a través de un software llamado Xampp. Este software es una distribución de Apache completamente gratuita y que contiene MariDB, PHP y Perl. Con este programa, se emulaban de manera local los archivos PHP del servidor de autenticación. Así, haciendo uso de un ordenador portátil con Xampp instalado y que se encontrará conectado a la misma red Wi-Fi que el dispositivo móvil, se hizo posible la realización de pruebas entre ambos dispositivos. Las pruebas realizadas son las siguientes: Funcionamiento correcto de la aplicación cliente Funcionamiento correcto de la aplicación TV Stick Conexión Bluetooth entre la aplicación cliente y el TV Stick 65

66 Tolerancia a fallos en las aplicaciones Conexión entre la aplicación cliente y el servidor Encriptaciones y desencriptaciones Envío de claves En primer lugar, se comprobó que las aplicaciones cliente y TV Stick funcionaban correctamente, previamente a la conexión Bluetooth. Para ello, el primer paso fue comprobar que el adaptador Bluetooth podía obtenerse y las modificaciones que podían hacerse sobre él. Se pretendía que la conectividad Bluetooth estuviera siempre activa y visible para otros dispositivos nada más iniciar la aplicación del TV Stick, pero tras diversas pruebas se concluyó que era posible activar la conexión Bluetooth sin intervención del usuario, pero no podía hacerse visible para todos los dispositivos por un tiempo ilimitado sin dicha intervención. Para ello se propuso que en se activara dicha opción en los ajustes Bluetooth de Android. Una vez que se determinó que las aplicaciones cliente y servidor funcionaban correctamente, la siguiente prueba era comprobar que la conexión Bluetooth se realizaba correctamente. Para ello, se activó la conectividad Bluetooth visible por tiempo ilimitado, y con la aplicación cliente se buscaban los distintos dispositivos disponibles. Para mejorar la interacción de la aplicación con el usuario, se añadió la opción de mostrar los dispositivos encontrados mientras la aplicación realizaba la búsqueda. Así, y con el fin de reducir la espera, al encontrar el dispositivo deseado se podía cancelar la búsqueda. Esta fase requirió de muchas pruebas y cambios en el diseño, puesto que en un principio se pensaba enlazar en el dispositivo del cliente con el del TV Stick, manteniendo un registro de los dispositivos enlazados en el dispositivo cliente. Esto proporcionaba la ventaja de que podía realizarse una conexión sin necesidad de realizar búsquedas, puesto que existen métodos en Android para conectarse mediante Bluetooth una vez que los dispositivos ya se han conectado una vez. Finalmente, al concluir que este proceso requería intervención del usuario en el TV Stick, se descartó esta opción. Por otro lado, una vez realizada la conexión Bluetooth había que asegurar que el TV Stick era tolerante a fallos, puesto que como ya se ha comentado, la intervención del usuario no es posible. Para ello hubo que realizar pruebas de desconexión, una vez que ya se había establecido la comunicación, para que la aplicación se reiniciara y pudiese volver a usarse haciendo la búsqueda correspondiente. Estos fallos de desconexión pueden ocurrir si la conectividad Bluetooth se pierde debido a la distancia entre los dos dispositivos, o incluso si el adaptador Bluetooth tiene algún tipo de problema hardware.

Fase de pruebas

67

Para la aplicación cliente, la tolerancia a fallos consiste en que no se pueda acceder al contenido de la aplicación sin haber ingresado antes en el servicio SPMD. Además, si se pierde la conexión Bluetooth, se volverá a la pantalla de inicio, en dónde es posible comenzar un nuevo proceso de búsqueda. Respecto a las pruebas realizabas entre el servidor de autenticación y el dispositivo cliente, se ha utilizado Xampp como se comentó anteriormente. Para ello, se usó un ordenador portátil conectado a la misma red Wi-Fi que el dispositivo móvil, y en la aplicación cliente se puso como URL la del servidor local. Una vez que se habían realizado las pruebas de conexión correspondientes, se hicieron numerosas pruebas con la criptografía. Esto es debido a que era necesario que la encriptación y desencriptación fuera compatible tanto en el TV Stick como en el servidor. Las primeras pruebas se hicieron con una encriptación únicamente mediante el algoritmo RSA, pero debido a que no es posible encriptar demasiada información con este algoritmo, se propuso utilizar AES y RSA en su conjunto, como se explicó en la sección referente a la criptografía con AES y RSA (capítulo 6.4). Para realizar la encriptación mediante RSA se tuvieron que buscar librerías, tanto para Android como para PHP, cuyos procedimientos para criptografía basada en RSA fueran compatibles. Para la criptografía en AES se debieron buscar los métodos necesarios, sin hacer uso de librerías, para encontrar funciones compatibles en PHP y Android que fueran capaces de encriptar y desencriptar con el mismo modo CBC y el mismo padding, lo que requiso numerosas pruebas. Para analizar los paquetes que se enviaban por la red, se decidió utilizar tcpdump, una herramienta para línea de comandos cuya utilidad es analizar el tráfico que circula por la red, y que puede ser utilizada en dispositivos Android. Una vez instalada esta herramienta, se ejecutan los comandos correspondientes y empezo el análisis del tráfico. Es en ese momento, en dónde se inician las aplicaciones del cliente y del TV Stick, y se procede a comprobar que las claves se envían correctamente. Lamentablemente, no es tarea fácil analizar las trazas de los paquetes que se envían via Bluetooth, por lo que solo se verán en las trazas analizadas los paquetes entre el cliente y el servidor. Una vez que se ha ejecutado tcpdump y se ha iniciado el proceso de envío de claves del servidor al TV Stick, se generará un fichero en dónde se muestra el contenido de las trazas. Para analizarlo de forma eficiente, se ha utilizado Wireshark, una conocida herramienta con la capacidad de analizar paquetes. En la siguiente figura se pueden observar las trazas de los mensajes enviados entre el cliente y el servidor.

68

Figura 7.1:

Trazas de los mensajes enviados entre cliente y servidor

Es importante observar en la imagen aquellas trazas cuyo protocolo sea HTTP, ya que ahi se visualiza claramente el intercambio de mensajes. La dirección IP 192.168.0.192 corresponde al dispositivo cliente, y la dirección 150.214.190.85, al servidor del SPMD. Así, en la primera traza se observa como el cliente envío una petición HTTP al servidor, llamando a la dirección que genera un reto sin encriptar.

Figura 7.2:

Solicitud del reto por parte de la aplicación cliente.

En la segunda traza en la que se utiliza el protocolo HTTP se obserca el mensaje 200 OK. Si vemos la información del mensaje, podemos ver su contenido, que en este caso es el reto, como puede verse en la siguiente figura:

Figura 7.3:

Mensaje devuelto por el servidor tras solicitar un reto.

El reto, como se observa, esta compuesto de la fecha y hora de generación, y un número totalmente aleatorio. Seguidamente, se observa como el cliente vuelve a llamar a la dirección de reto.php, pero esta vez indicándo en la URL un identificador (ID) y el reto encriptado.

Figura 7.4:

El dispositivo cliente envía un identificador y un reto encriptado al servidor.

El servidor desencriptará el reto y si la autenticación es correcta, devolverá las claves Wi-Fi y VPN encriptadas en el siguiente mensaje. La siguiente traza tendrá devolverá un mensaje del tipo 200 OK, lo que indica que la

Fase de pruebas

69

solicitud ha tenido éxito. El contenido que devuelve el servidor tras recibir la solicitud si la autenticación ha sido correcta se puede observar en la siguiente figura:

Figura 7.5:

Claves Wi-Fi y VPN encriptadas y enviadas por el servidor al dispositivo cliente.

Se puede observar como los primeros cuatro caracteres son ’OKAY’, que como se vio en la sección referente al protocolo de envío de mensajes, indica que la autenticación se ha realizado con éxito y se procede al envío de claves Wi-Fi y VPN. Por último, para comprobar que el envío de claves se realizaba con éxito, era necesario utilizar la imagen instalada en el TV Stick, ya que posee una consola o terminal, en el que pueden visualizarse todas las carpetas y archivos. Para ello, se confirmó que los archivos correspondientes a las claves Wi-Fi y VPN se habían modificado correctamente con las credenciales de prueba que se habían seleccionado. Para visualizar los archivos dónde se guardan las claves, habrá que hacer uso de la consola y de ADB. Se puede hacer uso del terminal instalado en el TV Stick, para lo que es recomendable el uso de un teclado y un ratón que estén conectados al dispostiivo. Otra opción es conectar el TV Stick mediante puerto USB a un ordenador en dónde se disponga de ADB y se reconozca al dispositivo. Si se ha elegido la opción de conexión mediante ordenador, se deberá escribir adb shell, lo que inicializará el terminal conectado al dispositivo. Una vez que se esté en este terminal, escribimos su para obtener permisos de administrador, y seguidamente se procederá a la búsqueda de los archivos que contienen las claves Wi-Fi y VPN. Para la clave Wi-Fi: Habrá que abrir el fichero wpa_supplicant.conf alojado en: \data\misc\wifi.

70 Para llegar a esa carpeta simplemente habrá que escribir en el terminal: cd \data\misc\wifi. Una vez en la carpeta wifi, utilizamos el siguiente comando para visualizar el fichero wpa_supplicant.conf : busybox vi wpa_supplicant.conf En ese momento se abrirá el fichero, que tendrá diferente información sobre la red Wi-Fi y las claves guardadas. En nuestro caso, se puede observar como se ha guardado la contraseña diseñada en el servidor, que era, ’EstaEsLaClaveWIFI’. En la siguiente figura puede observarse un extracto de este fichero, en el cual se contempla la clave para un determinado ssid.

Figura 7.6:

Clave Wi-Fi enviada por el servidor e introducida en el TV Stick

Para la clave VPN: Para visualizar la clave VPN habrá que abrir un fichero llamado com.gmail.mjm4456.vpncwidget_preferences.xml. Este fichero se encontrará alojado en: \data\data\com.gmail.mjm4456.vpncwidget\shared_prefs. Esta ubicación se debe a que en la imagen utilizada en los TV Stick, se ha hecho uso de un widget llamado VPNC, que guarda la información de la conexión VPN en el fichero nombrado anteriormente. Haciendo uso del comando cd será posible situarse en esa carpeta, y una vez ahí, se podrá abrir el fichero utilizando el comando: busybox vi com.gmail.mjm4456.vpncwidget_preferences.xml Al momento de introducir este último comando, se abrirá el fichero y se podrá visualizar la contraseña VPN actualizada, enviada desde el servidor. Esta contraseña, a modo de prueba, se quiso enviar des-

Fase de pruebas

71

de el servidor con el contenido ’EstaEsLaClaveVPN’. Podemos ver un extracto del fichero en la siguiente figura:

Figura 7.7:

Clave VPN enviada por el servidor e introducida en el TV Stick

Como puede observarse en las dos figuras anteriores, las claves llegaron y se introdujeron en el TV Stick correctamente.

Capítulo 8

Conclusiones y líneas futuras 8.1.

Conclusiones

En el presente Trabajo de Fin de Grado se ha desarrollado un sistema compuesto por diversos dispositivos, cuya función final es la de realizar una pasarela que comunique un dispositivo TV Stick y el servidor del Servicio de Proyección de Material Docente, con el fin de que el servidor pueda enviar diferentes tipos de credenciales a través de un medio inseguro. El objetivo propuesto ha sido desarrollado con éxito, elaborándose una aplicación en Android dedicada a smartphones y tabletas, que actuará como pasarela entre el servidor y el TV Stick. Además, se ha creado otra aplicación para el TV Stick con la capacidad de conectarse a la aplicación del cliente que siempre estará activa, realizándose una comunicación sencilla para el usuario. También se ha elaborado un sistema de seguridad que asegura autenticación y protección frente a intrusos que pretendan obtener las credenciales que se enviarán. Este proyecto, surgido con el objetivo de mejorar la funcionalidad de un Proyecto de Innovación Docente, pretende complementarlo, resolviendo algunas deficiencias de seguridad debido al uso de Android. Las contribuciones más destacables de este proyecto son las siguientes: Solventa el problema de falta de seguridad en Android, sistema en el cual se almacena información de carácter sensible, como las credenciales para la conexión Wi-Fi o VPN. Este problema se pretende solucionar realizando un cambio periódico de dichas credenciales cada día aproximadamente. Cada vez que un usuario pretenda utilizar el servicio del SPMD mediante la aplicación dedicada a la pasarela, se procederá al envío de claves por parte del servidor, con el fin de sobrescribir las antiguas claves. 73

74

8.1. Conclusiones Permite a los dispositivos TV Stick que estarán instalados en las aulas, autenticarse ante el servidor, lo que previene que otro tipo de dispositivos no autorizados obtengan las credenciales enviadas por el servidor. La aplicación dedicada al usuario, permite acceder al servicio SPMD y al material docente alojado en el servidor. Esto permite al usuario asegurar que las claves se han introducido correctamente en el TV Stick y por lo tanto, tener constancia de que el sistema funcionará correctamente. Si se utilizara dicho sistema desde un ordenador, sin hacer uso de la aplicación, podría darse el caso de que el TV Stick no dispusiera de las credenciales correctas, por lo que el servicio ofrecido por el SPMD no podría usarse, y no sería posible visualizar ningún material por el proyector. La aplicación no requiere demasiada intervención del usuario, ya que es muy intuitiva. Únicamente habrá que activar la conectividad Bluetooth, buscar el dispositivo TV Stick, cuyo nombre será muy intuitivo, y esperar a que el servidor envíe las claves. Este proceso es rápido y no requiere que el usuario realice ningún paso más, hasta que la aplicación abra la página web del servicio SPMD. Las claves que se envían desde el servidor al TV Stick, van encriptadas en todo momento a través de la red y la conexión Bluetooth, mediante un sistema de claves públicas y privadas. Ésto permite que solo el portador de la clave privada, en este caso el TV Stick, sea el único dispositivo capaz de descifrar las credenciales que hayan sido enviadas. Esto proporciona seguridad frente amenazas externas que tengan la intención de obtener dichas claves, lo que contribuye a que el PID sea más robusto. Esta aplicación, junto con el objetivo del PID, permite que el usuario no necesite utilizar ningún medio cableado para proyectar el material a través del proyector de las aulas. Además, el material estará siempre alojado en el servidor del SPMD, por lo que siempre será posible acceder a dicho material desde cualquier lugar, y por lo tanto, proyectarlo en todas las aulas sin necesidad de hacer uso de un ordenador.

En definitiva, el sistema desarrollado cubre los objetivos propuestos, proporcionando autenticación para los dispositivos TV Sticks utilizados en el PID, y además protegiendo la integridad de la red Wi-Fi y VPN, al realizarse el cambio de claves periódicamente, sin que la obtención de éstas por parte de cualquier usuario tenga un efecto nocivo en el sistema.

Conclusiones y líneas futuras

8.2.

75

Líneas futuras

Aunque se dan por conseguidos los objetivos de este trabajo de fin de grado, existen algunos aspectos que podrían mejorarse en un futuro, o implementarse adicionalmente. Estas mejoras serían las siguientes: Implementar la aplicación dedicada al usuario en otros sistemas operativos, como Windows, iOs, Mac OS y Linux. Este proceso podría llevarse a cabo reutilizando parte del código ya desarrollado, al estar implementado en Java. Sí sería necesario utilizar librerías específicas de estos sistemas operativos para la parte la de comunicación Bluetooth. Modificar el código de la aplicación dedicada al TV Stick, con el fin de activar la conectividad Bluetooth de manera visible para cualquier dispositivo, sin la intervención del usuario. Actualmente, con la versión 4.4 de Android, que es la que utilizan los TV Sticks, es posible modificar en los ajustes Bluetooth, el tiempo de visibilidad del dispositivo. Como se ha comentado a lo largo de este documento, el TV Stick necesitará estar visible todo el tiempo para que la aplicación del cliente sea capaz de encontrarlo. Esto no supone un problema en esta versión de Android, pero a partir de la versión 5.0 de Android, queda eliminada la opción de modificar esta opción en los ajustes de Bluetooth. Por lo tanto, en el caso de que se actualice la versión Android de los TV Sticks, habrá que modificar la programación para que de alguna manera, los dispositivos se mantengan visibles en cualquier momento. Dar la opción a la aplicación cliente de conectarse automáticamente al TV Stick más cercano. Esto podría realizarse enlazando los dispositivos al conectarse por primera vez, lo que permitiría que para ocasiones futuras no fuera necesario realizar el proceso de búsqueda de dispositivos. Actualmente no se ha realizado dicho proceso, ya que la API de Android permite esta opción pero necesita intervención de un usuario, lo que no es factible. Podrían buscarse librerías que permitieran la posibilidad de enlazar los dispositivos y conectarse automáticamente.

Apéndice A

Manual de instalación En este anexo se describirán los pasos necesarios a seguir para instalar las aplicaciones programadas en Android y de cómo hacer uso de los archivos PHP que se han realizado para el servidor del SPMD.

A.1.

Manual de instalación de las aplicaciones Android

En esta sección se explicará cómo instalar las dos aplicaciones realizadas para Android. Este manual sirve tanto para instalar la aplicación cliente, como la aplicación del TV Stick. Antes de instalar la aplicación, se deberá tener en cuenta que el dispositivo móvil cliente debe disponer como mínimo de la versión 3.0 de Android (API Level 11). Esto es necesario para que algunas funcionalidades de la aplicación puedan ser utilizadas, ya que otras versiones no las incluyen. Según la información que proporciona la plataforma Android Studio al crear un proyecto, esta aplicación podrá ser utilizada por el 97 % de los dispositivos Android que se encuentran actualmente en uso, debido a que solo un 3 % utiliza una versión inferior a la 3.0. Esta información que proporciona Android Studio se obtiene del acceso de diferentes dispositivos Android a la conocida aplicación Play Store. En el caso del TV Stick, al disponer dichos aparatos de la versión 4.4 de Android, no habrá ningún requisito a la hora de instalar la aplicación. Para la modificación del código fuente se deberá utilizar un entorno de programación diseñado para aplicaciones en Android. El IDE oficial de Android es Android Studio, que proporciona las herramientas más rápidas y eficaces para desarrollar aplicaciones en cualquier tipo de dispositivo An77

78

A.1. Manual de instalación de las aplicaciones Android

droid. Este programa es muy sencillo de instalar y es totalmente gratuito, pudiendo obtenerse de la página oficial de Android para desarrolladores. Por lo tanto, para acceder al código fuente de la aplicación será necesario disponer de una copia de los archivos del proyecto y abrirla con Android Studio. Una vez se tenga el código fuente, será posible editar todas las clases en caso de que fuera necesario. Existe un archivo llamado strings.xml en dónde se guardarán las cadenas de texto importantes, y que puedan necesitar modificación en el futuro. Este archivo se encuentra en: app → src → main → res → values → strings.xml Este fichero solo podrá ser modificado desde la plataforma de Android Studio, por lo que a la hora de querer cambiar algún tipo de dato, será necesario volver a compilar la aplicación con las nuevas cadenas de texto. Este archivo tendrá cadenas de texto importantes que podrán ser modificadas:

Figura A.1:

Figura A.2:

Archivo Strings.xml para la aplicación cliente.

Archivo Strings.xml para la aplicación TV Stick.

Como se puede observar, incluidos en las etiquetas existen cadenas de texto, que harán referencia a un nombre en concreto. Así, las etiquetas que podrían requerir variación serán el UUID utilizado para la

Manual de instalación

79

comunicación Bluetooth y las distintas direcciones del servidor del SPMD que se utilizarán, en el caso del cliente. En el caso del TV Stick se pondrán modificar las etiquetas para el UUID, la clave secreta y la clave privada del dispositivo, y el identificador del TV Stick. En el caso de que se desee cambiar el UUID utilizado en la conexión Bluetooth, éste puede generarse desde una web online, como la siguiente: https://www.famkruithof.net/uuid/uuidgen. En lo referente a los diferentes componentes que se requieren para el uso de la criptografía, existen distintos requisitos para su generación: Clave privada y pública RSA: La generaciòn de estas dos claves podrá realizarse de diferentes maneras. La más sencilla es mediante el uso de PHP, ya que utilizando dos líneas es posible generar ambas claves. Haciendo uso de las librerias instaladas en el servidor de autenticación, se puede hacer uso de un método que genera ambas claves. Para ello, habrá que crear un nuevo objeto Crypt_RSA(), y a partir de dicho objeto utilizar el método createKey(bits), indícando el número de bits que se desea para la clave. Es recomendable utilizar 2048 bits, ya que es una longitud adecuada y con un tiempo de cómputo reducido. Una vez creadas las claves, éstas se guardarán en un vector, por lo que para obtenerlas habrá que llamar a los índices del vector ’privatekey’ y ’publickey’. Si se desea, pueden guardarse las claves en archivos de texto, con el fin de exportar las claves a alguna carpeta dentro del servidor, con el comando file_put_contents. En la siguiente figura puede verse un ejemplo de dicha generación.

Figura A.3:

Generación de claves pública y privada haciendo uso de las librerias instaladas en el servidor de autenticación.

Generar las claves en Mac o Linux es sencillo haciendo uso de OpenSSl, pero en el caso de Windows resulta más complicado. Para ello, existen webs online con la capacidad de generar un par de claves RSA con total

80

A.1. Manual de instalación de las aplicaciones Android facilidad, simplemente indicando el número de bits que se desea para la clave. Una de las webs más útiles para generar un par de claves es: http://travistidwell.com/jsencrypt/demo/. En la siguiente figura podemos ver un ejemplo de generación de claves desde dicha página.

Figura A.4:

Generación de claves pública y privada haciendo uso de un generador online.

Otro modo de generar un par de claves es haciendo uso de OpenSSl en Linux o Mac. En el terminal, habrá que escribir el siguiente comando para generar la una clave privada. En el primer comando se generará una clave privada, que se guardará en un archivo de nombre opcional. En el ejemplo el archivo es llamado privada.pem, aunque el usuario puede escoger el nombre que desee. openssl genrsa -out privada.pem 2048 Para generar la clave pública será necesario ejecutar el siguiente comando: openssl rsa -in privada.pem -pubout >publica.pub Una vez hecho esto, el usuario dispondrá de una clave pública y una clave privada alojadas en el directorio desde el cual se ejecutaron los comandos. Clave secreta: La clave secreta utilizada para la encriptación mediante AES deberá tener una longitud de 128, 192 ó 256 bits, lo que suponen 16, 24 ó 32 caractéres respectivamente. A mayor longitud de clave, mayor seguridad, pero a su vez, ésto requerirá más tiempo de cómputo a la hora de utilizarla. Por otro lado, para instalar la aplicación en el dispositivo existen dos opciones: Instalar la aplicación a través de Android Studio Instalar la aplicación mediante un archivo .apk

Manual de instalación

81

La primera opción consiste en instalar la aplicación con las funcionalidades que ofrece Android Studio. Para ello será necesario instalar los drivers del dispositivo en el que se desea instalar la aplicación, con el fin de instalar las funcionalidades de ADB (Android Debug Bridge). Una vez instalados, será necesario conectar el dispositivo al ordenador, y que sea detectado por éste. Realizado este paso habrá que pulsar sobre Run app en la pestaña Run, o al icono con forma de flecha verde en la barra superior de Android Studio:

Figura A.5:

Botón para ejecutar la aplicación.

Una vez se haya realizado este paso se abrirá una ventana (véase figura A.6 en dónde se dará la opción de instalar la aplicación en un dispositivo o utilizar un emulador.

Figura A.6:

Elección de dispositivo en el que instalar la aplicación.

Al elegir el dispositivo deseado y pulsar sobre OK, la aplicación se instalará en el dispositivo y se abrirá. La segunda opción es obtener el archivo .apk e instalarlo en el dispositivo. Para ello, en la pestaña Build en la barra superior de Android Studio, seleccionamos Generate Signed APK (véase figura A.7).

82

A.1. Manual de instalación de las aplicaciones Android

Figura A.7:

Pestaña para generar el archivo .apk .

Una vez hemos pinchado en dicha opción, habrá que seleccionar un Key store path en otra ventana [31]. Android requiere que todas las aplicaciones sean firmadas digitalmente con un certificado antes de que sean instaladas en un dispositivo. Para ello existe el llamado keystore, que es un archivo binario que contiene una o más claves privadas. Cuando decides firmar una aplicación utilizando Android Studio, puedes elegir entre generar un nuevo keystore y una clave privada, o seleccionar los mismos componentes si ya habían sido previamente creados. Si no hay ninguno creado, habrá que pulsar la opción de Create new e introducir una contraseña para el keystore y otra para la key (clave privada), además de un Alias, que identifica a la clave. Es recomendable que la clave del keystore y la clave privada sean diferentes. Por otro lado, habrá que rellenar información para el certificado. Esta información no se mostrará en la aplicación pero será incluida en el certificado que formará parte del archivo APK. (Véase figura A.8). Cabe destacar que se deberán utilizar los mismos certificados si se realizan actualizaciones en la aplicación, con el objetivo de que los usuarios puedan instalar nuevas versiones de la misma.

Manual de instalación

83

Figura A.8:

Generación de Keystore.

Se guarda el keystore y el usuario deberá pulsar sobre Next, introduciendo los datos necesarias para la clave privada y el keystore.

Figura A.9:

Introducción de datos para firmar la aplicación.

Hecho esto, se dará la opción en una nueva ventana de seleccionar el directorio donde generar el archivo .apk. Al pulsar sobre Next se generará el archivo y aparecerá un mensaje con la opción de abrir el directorio generado.

Figura A.10:

Mensaje de éxito al generar el archivo .apk.

Si se abre dicho directorio, aparecerá un archivo llamado app-release.apk, que será el que debe instalarse en el dispositivo móvil. Para instalarlo, deberá colocarse el archivo .apk en algún directorio accesible desde el móvil. Una vez que se tenga acceso a la aplicación será necesario activar la opción de instalar aplicaciones de origen desconocido. Para ello, en la configuración de Android, en el apartado de Seguridad, habrá que activar dicha opción.

84

A.1. Manual de instalación de las aplicaciones Android

Figura A.11:

Permiso para instalar aplicaciones de orígenes desconocidos.

Realizado este paso, habrá que acceder al archivo .apk desde el directorio en el que se haya insertado, y pinchar sobre él. Aparecerá en ese momento una ventana indicando los permisos que tiene la aplicación sobre el dispositivo.

Figura A.12:

Instalación de la aplicación en Android.

Al darle a instalar la aplicación será instalada automáticamente.

Manual de instalación

85

Este proceso será exactamente igual para los dispositivos TV Sticks, ya que la aplicación se ha desarrollado utilizando Android Studio y el sistema operativo es Android.

A.2.

Manual de utilización de los archivos PHP en el servidor

En la parte del servidor no será necesario realizar ningún tipo de instalación, solamente habrá que insertar los dos archivos PHP que se han programado en alguna carpeta del servidor. Para ello, el tutor del proyecto, Jorge Navarro Ortiz, ha seleccionado una carpeta en dónde introducir dichos archivos. Utilizando algún programa para transferir archivos a dispositivos remotos, como por ejemplo, SSH Secure File Transfer, y conociendo las credenciales para el servidor central de SPMD, será posible alojar dichos archivos. Estos archivos serán utilizables desde la aplicación Android una vez alojados, por lo que no será necesario realizar más acciones.

Apéndice B

Manual de uso de la aplicación Android El objetivo de este anexo es explicar el modo de funcionamiento de las aplicaciones programadas en Android, con el fin de que el usuario comprenda como interactuar con ellas. Para que sea posible el funcionamiento de la aplicación cliente, es decir, la que está dedicada al usuario, será necesario que la aplicación del TV Stick esté activada. Además el TV Stick deberá mantenerse visible ilimitadamente para todos los dispositivos que realicen búsquedas mediante Bluetooth. Para ello, habrá que ir a los ajustes del TV Stick, y en el apartado Bluetooth pulsar en los tres puntos arriba a la derecha de la pantalla, en dónde habrá que seleccionar la opción de ’Tiempo de visibilidad’ (Visibility Timeout). Se abrirá una nueva pantalla, en la que habrá que seleccionar la opción de ’Sin agotar el tiempo de espera’ (Never Timeout).

87

88

Figura B.1:

Ajustes de visibilidad Bluetooth en Android.

Si el TV Stick está funcionando correctamente, entonces se explicará ahora los pasos que debe seguir el usuario para utilizar la aplicación cliente. En primer lugar, al iniciar la aplicación, se abrirá la web del Servicio de Proyección de Material Docente, en dónde habrá que introducir las credenciales de identificación para la Universidad de Granada.

Figura B.2:

Login de SPMD visualizado a través de un WebView en un dispositivo Android.

Una vez introducidos los datos de acceso, y pulsar sobre login, la aplicación pasará a mostrar la interfaz principal, en dónde el usuario deberá activar la conectividad Bluetooth.

Manual de uso de la aplicación Android

Figura B.3:

89

Interfaz de la aplicación cliente.

El usuario deberá pulsar el botón de ’Buscar dispositivos’. En ese momento empezará una búsqueda de todos los dispositivos que puedan ser visibles mediante Bluetooth, que se mostrarán por pantalla al ser encontrados como se ve en la siguiente figura (ver figura B.4).

90

Figura B.4:

Proceso de búsqueda de dispositivos con dispositivo encontrado.

Si el usuario presiona el botón ’CANCELAR’ mientras se realiza la búsqueda de dispositivos, dicha búsqueda parará y se mostrarán por pantalla todos los dispositivos encontrados hasta el momento. En caso de que el usuario permita continuar la búsqueda, al terminar ésta, se mostrarán por pantalla todos los dispositivos encontrados. Esta búsqueda tiene una duración de aproximadamente 20 segundos.

Manual de uso de la aplicación Android

Figura B.5:

91

Interfaz de la aplicación una vez terminada la búsqueda de dispositivos.

Por lo tanto, al terminar la búsqueda, el usuario deberá seleccionar aquel dispositivo cuyo nombre sea el del dispositivo TV Stick deseado (en el ejemplo, ’rockchip’). En caso de que se seleccione otro dispositivo diferente, la conexión no podrá realizarse. Por lo tanto, al seleccionar al dispositivo cuyo nombre esté asociado al TV Stick, empezará el proceso de envío de credenciales desde el servidor al TV Stick, mostrándose un mensaje al usuario de espera. Este proceso durará aproximadamente de 5 a 10 segundos.

92

Figura B.6:

Interfaz de la aplicación en el proceso de envío de claves desde el servidor al TV

Stick.

Una vez que termine este proceso, las claves habrán sido enviadas al TV Stick, por lo que el usuario será dirigido a la página inicial del SPMD y podrá utilizar el TV Stick para proyectar el contenido del Servicio de Proyección de Material Docente.

Figura B.7:

Inicio de la página del SPMD en la aplicación cliente tras el envío de credenciales.

Bibliografía [1] OS Smartphone. Market Share, 2015 Q2. IDC [on-line].[dostęp 22.08. 2015]. Dostępny w: http://www. idc. com/prodserv/smartphoneos-market-share. jsp, 2015. [2] Abdul-Rahman Mahmood and Nassar Ikram. ELLIPTIC CURVE BASED SECURE MESSAGING SYSTEM. [3] Jorge Navarro Ortiz. Servicio centralizado de Proyección de Material Docente (PID 14-61). http://wdb.ugr.es/~jorgenavarro/downloads/1461-version-extendida.pdf, 2016. [4] Google. Google Chromecast. https://www.google.es/chrome/devices/ chromecast/, 2015. [5] I.E.E.E. Standard. 802.1x, IEEE standard for local and metropolitan are networks. port based network access control, 2004. cited By 1. [6] Apple. Apple TV. http://www.apple.com/es/tv/, 2015. [7] Amazon. Amazon Fire TV. https://www.amazon.com/Amazon-FireTV-Streaming-Media-Player/dp/B00U3FPN4U, 2015. [8] BenQ. BenQ W1500 Home Entertainment Proyector inalámbrico. http://www.benq.es/product/projector/w1500, 2015. [9] Awind. WGA-310 Wireless Presentation http://www.awindinc.com/products_wga_310.html.

System.

[10] wePresent. WiPG - 1000. http://www.wepresentwifi.com/wipg1000.html. [11] wePresent. WiPG - 1500. http://www.wepresent.es/Doc/WP1500.pdf. [12] IPEVO. High-Definition Wireless Presentation System. http://support.ipevo.com/support/qa/HighDefinition_Wireless_Presentation_System. [13] Optoma. WPS Dongle http://www.optoma.es/accessorydetail.aspx?PC=WPS. 93

(OPTOMA).

94

BIBLIOGRAFÍA

[14] Planet Networking & Communication. WPG-210N. http://www.planet.com.tw/en/product/product.php?id=48261. [15] TeqAvit. WiD510. http://www.teqavit.com/wid510. [16] InFocus. LiteShow III. http://www.infocus.com/peripherals/ INLITESHOW3. [17] ViewSonic. WPG-370. http://www.viewsoniceurope.com/es/products/ projectors/WPG-370.php. [18] BlackBox. AVX-HDMI-WI. https://www.blackbox.com/enus/store/Detail.aspx/Wireless-Presentation-System/AVX-HDMI-WI. [19] Adobe. Adobe Phonegap. http://phonegap.com/. [20] Android. Android Studio. https://developer.android.com/studio/ index.html. [21] Carles Gomez, Joaquim Oller, and Josep Paradells. Overview and evaluation of bluetooth low energy: An emerging low-power wireless technology. Sensors, 12(9):11734–11753, 2012. [22] Android. Bluetooth Socket. https://developer.android.com/reference/ android/bluetooth/BluetoothSocket.html. [23] Android. BluetoothServerSocket. https://developer.android.com/ reference/android/bluetooth/BluetoothServerSocket.html. [24] Jinxing MA and Qijun CHEN. Analysis and Implementation of RFCOMM Layer in Bluetooth Protocol Stack [J]. Computer Engineering, 8:042, 2004. [25] Android. UUID. https://developer.android.com/reference/java/util/ UUID.html. [26] Rafael Palacios Hielscher and Vera Delgado. Introducción a la Criptografía: tipos de algoritmos. In anales de mecánica y electricidad, volume 83, pages 42–46. Asociacion de Ingenieros del ICAI, 2006. [27] Joan Daemen and Vincent Rijmen. The design of Rijndael: AES-the advanced encryption standard. Springer Science & Business Media, 2013. [28] Elena Trichina. Combinational Logic Design for AES SubByte Transformation on Masked Data. IACR Cryptology ePrint Archive, 2003:236, 2003. [29] Yuri Tatiana Medina Vargas and Haider Andrés Miranda Mnedez. Comparación de algoritmos basados en la criptografía simétrica DES, AES y 3DES. Mundo FESC, 1(9):14–21, 2015.

BIBLIOGRAFÍA

95

[30] Xin Zhou and Xiaofei Tang. Research and implementation of RSA algorithm for encryption and decryption. In Strategic Technology (IFOST), 2011 6th International Forum on, volume 2, pages 1118–1121. IEEE, 2011. [31] Android. Firma de aplicaciones en Android Studio. https://developer.android.com/studio/publish/app-signing.html.