Aplicación de mensajería segura y certificada en entornos Android
95
0
0
Texto completo
(2)
(3) Agradecimientos En primer lugar, deseo expresar mi agradecimiento al profesor Dr. Luı́s Mengual Galán, director de este Trabajo de Fin de Máster, por la dedicación y ayuda que me ha prestado a lo largo de la realización del mismo. Deseo expresar también mi agradecimiento a todo el profesorado de la Escuela Técnica Superior de Ingenieros Informáticos de la Universidad Politécnica de Madrid por sus esfuerzos en enseñarnos de forma rigurosa, a mi y a mis compañeros de promoción, los principios y técnicas de ingenierı́a necesarios para realizar un trabajo como éste. Por último, quiero dar las gracias a mi familia por su apoyo a lo largo de los estudios, ya que siempre me han ayudado en todo lo que ha estado de su mano. A todos, muchas gracias..
(4)
(5) Resumen El objetivo de este trabajo es el análisis, diseño e implementación de un sistema de mensajerı́a instantánea seguro para dispositivos móviles Android. Se trata de un sistema que implementa técnicas criptográficas con el fin de garantizar la confidencialidad y la integridad de los mensajes intercambiados entre los usuarios, ası́ como la autenticación efectiva de los usuarios emisores y el no repudio. En el sistema desarrollado, el operador del mismo no podrá acceder al contenido de los mensajes, a diferencia de otros sistemas ampliamente implantados. Entre los aspectos más novedosos de este proyecto, destaca la incorporación de un mecanismo de firma digital con el DNI electrónico de España que permitirá a los usuarios intercambiar mensajes firmados con idéntica validez a la de una firma manuscrita. El sistema desarrollado supone además una plataforma abierta a la incorporación de nuevos servicios con mecanismos de seguridad como un sistema de burofax electrónico o el intercambio de contenido multimedia de forma segura.. i.
(6) Summary This Project is oriented to the analysis, design and implementation of an instant-messaging secure system for Android mobile devices. Cryptographic techniques will be used to assure the confidentiality and integrity of the messages exchanged by the users of the system, as well as the effective authentication of the senders and the non-repudiation. In the developed system, the operator won’t be able to access to the content of the exchanged messages (due to the usage of end to end encryption), unlike other widely extended systems. One of the most relevant aspects of this project is the integration of a digital signature mechanism, which uses the Spanish Electronic Identification Card (DNI). This feature will allow the users to exchange signed messages with the same value as if they were signed with a handwritten signature, according to the Spanish Law. Moreover, the developed system can be seen as an open platform to the addition of new services with security mechanisms such as an electronic certified fax service or a multimedia exchanging secure platform.. ii.
(7) Índice general 1. Introducción y Objetivos 1.1. Introducción . . . . . . . 1.2. Objetivos del proyecto . 1.3. Estructura del trabajo . 1.4. Normativa aplicable . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 1 1 2 3 3. 2. Estado del arte 2.1. Historia de la mensajerı́a instantánea . . . . . . 2.2. Caracterı́sticas de la comunicación instantánea 2.3. Análisis del funcionamiento de las aplicaciones 2.4. Análisis de la solución planteada . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 4 4 5 5 8. 3. Evaluación de riesgos 3.1. Identificación de los riesgos . . . . . . . . . . . . . . . . . . 3.2. Análisis cualitativo de los riesgos . . . . . . . . . . . . . . . 3.2.1. Evaluación de Probabilidad e Impacto de los Riesgos 3.2.2. Matriz de Probabilidad-Impacto . . . . . . . . . . . 3.3. Planificación de la respuesta a los riesgos . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 9 9 10 10 11 11. 4. Desarrollo 4.1. Planteamiento del problema . . . . . . . . . . 4.1.1. Análisis de requisitos . . . . . . . . . . 4.1.2. Casos de uso . . . . . . . . . . . . . . 4.1.3. Matriz de trazabilidad . . . . . . . . . 4.2. Ciclo de vida del proyecto . . . . . . . . . . . 4.3. Gestión de la configuración . . . . . . . . . . 4.3.1. Control de cambios . . . . . . . . . . . 4.4. Esquema de Descomposición de Tareas . . . . 4.5. Estimación temporal . . . . . . . . . . . . . . 4.6. Estimación de costes . . . . . . . . . . . . . . 4.7. Diseño de la solución . . . . . . . . . . . . . . 4.7.1. Especificación de la solución propuesta 4.7.2. Arquitectura del sistema . . . . . . . . 4.7.3. Tecnologı́as seleccionadas . . . . . . . 4.7.4. Modelos criptográficos . . . . . . . . . 4.7.5. Diseño de las interfaces de usuario . . 4.8. Implementación . . . . . . . . . . . . . . . . . 4.8.1. Servidor . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. 12 12 12 15 21 22 23 23 25 25 27 28 29 30 36 37 42 46 46. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. iii. . . . .. . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . ..
(8) 4.8.2. Base de Datos . . . . . . . . . . . . 4.8.3. Cliente móvil . . . . . . . . . . . . . 4.8.4. Infraestructura de clave pública . . . 4.9. Pruebas . . . . . . . . . . . . . . . . . . . . 4.9.1. Pruebas de los servicios del servidor 4.9.2. Pruebas de la aplicación móvil . . . 4.9.3. Pruebas de concurrencia . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 50 53 60 62 62 64 66. 5. Resultados y conclusiones. 67. 6. Lı́neas futuras. 69. A. Manual de instalación A.1. Requisitos previos . . . . . . . . . . A.2. Configuración del gestor MySQL . . A.3. Configuración del Servidor . . . . . . A.4. Configuración de la aplicación móvil B. Manual de usuario. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 70 70 71 73 73 75.
(9) Índice de figuras 4.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Matriz de trazabilidad entre requisitos funcionales y casos de uso . . . . . . 4.3. Esquema del ciclo de vida en cascada . . . . . . . . . . . . . . . . . . . . . . 4.4. Esquema de Descomposición de Tareas . . . . . . . . . . . . . . . . . . . . . 4.5. Estimación temporal de las tareas . . . . . . . . . . . . . . . . . . . . . . . 4.6. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8. Diagrama de arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . 4.9. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10. Diagrama Entidad-Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11. Diagrama de secuencia para el registro de usuarios . . . . . . . . . . . . . . 4.12. Diagrama de secuencia para el envı́o de mensajes . . . . . . . . . . . . . . . 4.13. Diagrama de secuencia para la recepción de mensajes . . . . . . . . . . . . . 4.14. Representación del funcionamiento del cifrado simétrico . . . . . . . . . . . 4.15. Representación del funcionamiento del cifrado asimétrico (confidencialidad) 4.16. Representación del funcionamiento del cifrado asimétrico (firma digital) . . 4.17. Representación del funcionamiento del sobre digital . . . . . . . . . . . . . . 4.18. Diseño de la interfaz de lista de contactos . . . . . . . . . . . . . . . . . . . 4.19. Diseño de la interfaz de registro . . . . . . . . . . . . . . . . . . . . . . . . . 4.20. Diseño de la interfaz de conversación . . . . . . . . . . . . . . . . . . . . . . 4.21. Configuración del SGBD para permitir la conexión con SSL . . . . . . . . . 4.22. Configuración de MySQL Workbench para la conexión con SSL . . . . . . . 4.23. Estructura de la aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . 4.24. Esquema sobre los almacenes utilizados para establecer la conexión SSL . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. 16 21 22 25 26 26 30 31 32 33 34 35 35 38 39 39 40 44 45 46 51 51 54 61. A.1. A.2. A.3. A.4.. Importación del script de creación de las tablas de la base de datos Configuración de MySQL para permitir la conexión con SSL . . . . Parámetros de conexión a la base de datos con JDBC . . . . . . . Configurar la conexión con el servidor desde la aplicación móvil . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 71 72 73 74. B.1. B.2. B.3. B.4. B.5. B.6. B.7. B.8. B.9.. Registro en el sistema desde la aplicación móvil . . . . . . . Añadir contactos desde la aplicación móvil . . . . . . . . . . Envı́o de mensajes sin firmar desde la aplicación móvil . . . Recepción de mensajes sin firmar desde la aplicación móvil Envı́o de un mensaje firmado con el certificado interno . . . Recepción de un mensaje firmado con el certificado interno Firma digital de un mensaje con el DNI electrónico . . . . . Envı́o de mensajes firmados con el DNI electrónico . . . . . Recepción de un mensaje firmado con el DNI electrónico . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 75 76 76 77 78 79 79 80 80. v. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . ..
(10) Índice de cuadros 2.1. Comparativa de aplicaciones de mensajerı́a . . . . . . . . . . . . . . . . . . . . . . . 3.1. 3.2. 3.3. 3.4. 3.5. 3.6.. Identificación de los riesgos del proyecto . . . . . . . . Valoración de la probabilidad de los riesgos . . . . . . Valoración del impacto de los riesgos . . . . . . . . . . Evaluación de la probabilidad e impacto de los riesgos Matriz de Probabilidad-Impacto de los riesgos . . . . . Planificación de la respuesta a los riesgos . . . . . . .. 4.1. Lista de requisitos no funcionales . . . . . . . . . . . 4.2. Lista de requisitos funcionales . . . . . . . . . . . . . 4.3. Lista de actores identificados en el sistema . . . . . . 4.4. Caso de uso de registro de usuarios . . . . . . . . . . 4.5. Caso de uso de consulta de datos de usuarios . . . . 4.6. Caso de uso de añadir un contacto . . . . . . . . . . 4.7. Caso de uso de eliminar un contacto . . . . . . . . . 4.8. Caso de uso de inicio de sesión . . . . . . . . . . . . 4.9. Caso de uso de cierre de sesión . . . . . . . . . . . . 4.10. Caso de uso de consulta de estadı́sticas . . . . . . . . 4.11. Caso de uso de envı́o de un mensaje . . . . . . . . . 4.12. Caso de uso de recepción de un mensaje . . . . . . . 4.13. Caso de uso de consulta de un mensaje . . . . . . . . 4.14. Coste por hora de los recursos humanos del proyecto 4.15. Costes indirectos del proyecto por mes . . . . . . . . 4.16. Costes del proyecto relacionados con el equipamiento. vi. . . . . . . . . . . . . . . . .. 7. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 9 10 10 10 11 11. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. 12 13 16 17 17 18 18 18 19 19 20 20 21 27 27 28.
(11) Capı́tulo 1. Introducción y Objetivos 1.1.. Introducción. Hoy en dı́a existen múltiples tecnologı́as que permiten el intercambio de información en nuestra sociedad, desde el correo postal hasta las modernas aplicaciones de mensajerı́a instantánea. En un mundo conectado, como es el nuestro, resulta fundamental garantizar la seguridad en las comunicaciones, estableciendo un canal que garantice la confidencialidad de la información enviada. El secreto de la correspondencia (incluido dentro del derecho de privacidad) es un derecho recogido en la Declaración Universal de los Derechos Humanos[1] y en la Constitución Española de 1978[2]. Para garantizar este derecho, en el contexto de la Sociedad de la Información, es fundamental proteger la información personal transmitida a través de la red. El intercambio de información a través de la red plantea múltiples desafı́os, además de la confidencialidad. Estos son la autenticación (el usuario receptor debe ser quien dice ser), la integridad (los datos no deben poder ser modificados en medio de la transmisión) y la disponibilidad (los datos deben estar accesibles cuando sea necesario). Actualmente existen múltiples aplicaciones informáticas que permiten el intercambio de información entre usuarios pero no todas ellas garantizan la confidencialidad en las comunicaciones ya que algunas protegen únicamente la información en tránsito entre sus servidores y los clientes. En este trabajo se tratará el diseño y desarrollo de un sistema de mensajerı́a para entornos Android que implementará servicios de seguridad que garanticen la confidencialidad de los mensajes enviados, recibidos y almacenados. Además de esto, el sistema a desarrollar gestionará datos adicionales de los mensajes que permitan garantizar la identidad del usuario emisor mediante el uso de la firma digital. Esta firma, que podrá realizarse con DNI electrónico, permitirá a los usuarios del sistema firmar mensajes con plena validez jurı́dica, de acuerdo con la legislación española.[3] El desarrollo de este proyecto requerirá la creación de una infraestructura de clave pública en la que los usuarios dispondrán de certificados digitales con una clave privada personal asociada a cada uno de ellos. Se utilizará la criptografı́a para garantizar la confidencialidad, la integridad y la autenticación en las comunicaciones realizadas. 1.
(12) CAPÍTULO 1. INTRODUCCIÓN Y OBJETIVOS. 2. 1.2.. Objetivos del proyecto. El objetivo fundamental de este proyecto es la realización de un sistema de mensajerı́a instantánea segura y autenticada para entornos Android. Dentro de este objetivo general se incluyen los siguientes objetivos concretos: 1. Introducción a los servicios de seguridad y su implementación en sistemas Android. 2. Creación de una Base de Datos para almacenar mensajes cifrados y firmas asociadas. 3. Creación de la infraestructura TCP/IP para la conexión remota de las entidades interfaz de cliente, Sistema de Gestión de Mensajes y Base de Datos de almacenamiento. 4. Implementación de los mecanismos de cifrado y firma electrónica en el sistema móvil del cliente. 5. Verificación de los intercambios propuestos. El sistema de mensajerı́a que se pretende desarrollar estará compuesto por tres entidades: Interfaz de cliente: consistirá en una aplicación móvil Android que incluirá la interfaz de usuario con el sistema de mensajerı́a. Servidor web: consistirá en un servidor web desarrollado con tecnologı́a Java que prestará servicios a los diferentes clientes. Base de datos: Se encargará del almacenamiento de los diferentes datos que gestiona el sistema (datos de los usuarios, mensajes etc.). La aplicación móvil cliente será la encargada de proporcionar a los usuarios del sistema la interfaz con la que realizar las operaciones de registro, envı́o de mensajes, recepción de mensajes, firma de mensajes y validación de firmas. Se utilizará una infraestructura de clave pública para garantizar la confidencialidad de los mensajes enviados entre los usuarios del sistema. La firma de los mensajes permitirá garantizar la autenticación del usuario emisor. Esta firma se podrá realizar de una de las siguientes maneras: Firma mediante el uso de un certificado digital: Se utilizará un certificado digital contenido en la memoria interna del dispositivo móvil que será generado por el sistema tras la solicitud de registro del usuario. Firma mediante el uso del DNI electrónico 3.0: Se utilizará la tecnologı́a NFC (Near Field Communication) integrada en el dispositivo móvil para realizar una firma digital reconocida con plena validez jurı́dica. Una vez configurado y desplegado el sistema, los usuarios que utilicen la aplicación móvil desarrollada podrán establecer comunicaciones seguras entre ellos, ası́ como asegurarse de la autenticidad del usuario con el que se están comunicando..
(13) 1.3. ESTRUCTURA DEL TRABAJO. 1.3.. 3. Estructura del trabajo. Este Trabajo de Fin de Máster se compone de la presente Memoria (incluida en este documento) y del Sistema de Mensajerı́a desarrollado cuyo código fuente se adjunta junto con los archivos necesarios para el despliegue del mismo[38]. La memoria de este trabajo se organiza en diferentes capı́tulos cuyo contenido y propósito se describe brevemente en este apartado: Capı́tulo 1 - Introducción y objetivos: Incluye la justificación del desarrollo del trabajo y sus objetivos. Capı́tulo 2 - Estado del Arte: Incluye un análisis del ámbito de negocio en el que se enmarca el proyecto. Capı́tulo 3 - Evaluación de riesgos: Incluye un análisis de los riesgos que pueden afectar al desarrollo del proyecto. Capı́tulo 4 - Desarrollo: Explica la metodologı́a seguida para el desarrollo del sistema y las particularidades de la solución planteada. Capı́tulo 5 - Resultados y conclusiones: Se analiza el funcionamiento y las funcionalidades del sistema desarrollado y se plantean conclusiones sobre los resultados obtenidos. Capı́tulo 6 - Lı́neas futuras: Se analizan los lı́mites de las tecnologı́as utilizadas y se plantean posibles mejoras y ampliaciones del sistema desarollado. Además de esto se incluyen como anexos un manual de instalación (que incluye las instrucciones para el despliegue y configuración del sistema desarrollado) y un manual de usuario (que incluye una guı́a sobre como utilizar las diferentes funcionalidades que ofrece el sistema desarrollado). Por último, se incluye una bibliografı́a con las referencias acerca de los materiales consultados para la elaboración de este trabajo.. 1.4.. Normativa aplicable. Este Trabajo de Fin de Máster ha sido realizado en la Escuela Técnica Superior de Ingenieros Informáticos de la Universidad Politécnica de Madrid para la obtención del tı́tulo universitario oficial de Máster Universitario en Ingenierı́a Informática[4], vinculado con el ejercicio de la profesión de Ingeniero en Informática (BOE A-2009-12977)[5]. Se trata de un Trabajo de Fin de Máster de la Modalidad A[6] (con una carga de trabajo de 18 créditos ECTS) de los citados estudios de Máster Universitario, sujeto a la normativa universitaria aplicable[7] ası́ como a la normativa especı́fica del citado tı́tulo[8]..
(14) Capı́tulo 2. Estado del arte En este capı́tulo se introducirán diferentes aplicaciones de mensajerı́a instantánea disponibles hoy en dı́a, explicando sus ventajas y desventajas. Se abordarán diversos conceptos relacionados con el procesamiento de los datos gestionados por estas aplicaciones y se expondrán detalladamente las novedades que la solución planteada en este proyecto ofrece sobre los diseños ya existentes.. 2.1.. Historia de la mensajerı́a instantánea. La mensajerı́a instantánea es una forma de comunicación en tiempo real entre diferentes personas basada en el intercambio de mensajes de texto. Estos mensajes son enviados a través de Internet entre el emisor y los destinatarios, sin importar la distancia o el tipo de comunicación existente entre ellos. Se trata de un servicio similar pero diferente al que ofrece el correo electrónico. El correo electrónico, que es el sucesor del correo postal, tiene sus orı́genes antes de la aparición de Internet y está orientado al intercambio de información sin que los usuarios emisor y receptor estén conectados de forma simultánea. Frente a las aplicaciones de mensajerı́a instantánea, que se caracterizan por estar orientadas a comunicaciones breves y en tiempo real, el correo electrónico ofrece la posibilidad de mandar mensajes más grandes (habitualmente incorporando archivos adjuntos), los cuales pueden ser consultados en cualquier momento por los usuarios receptores. A diferencia del correo electrónico, donde los protocolos utilizados para el intercambio de mensajes son de dominio público, las aplicaciones de mensajerı́a instantánea utilizan protocolos privados y adaptados especialmente para sus servidores e infraestructura. Para facilitar la comunicación en tiempo real entre los usuarios de las aplicaciones de mensajerı́a instantánea, es necesario utilizar un software cliente de mensajerı́a instantánea que se encarga de consultar periódicamente los mensajes recibidos y de posibilitar el envı́o de mensajes a otros usuarios.. 4.
(15) 2.2. CARACTERÍSTICAS DE LA COMUNICACIÓN INSTANTÁNEA. 5. Los primeros clientes de mensajerı́a instantánea se diseñaron para ser ejecutados en ordenadores de escritorio conectados a Internet. Algunos de ellos se diseñaron utilizando una arquitectura clienteservidor y otros una arquitectura peer-to-peer. Los comienzos de las aplicaciones de mensajerı́a instantánea tal como las conocemos hoy en dı́a se remontan a mediados de los años 90. Aplicaciones como PowPow, ICQ o AOL Instant Messenger fueron pioneras en facilitar el envı́o de mensajes de texto a través de Internet. Más adelante aparecieron otras aplicaciones como MSN, Excite, Ubique o Yahoo con sus propios protocolos y particularidades. A las funcionalidades básicas de envı́o de mensajes de texto se fueron incorporando el envı́o de imágenes, vı́deos, archivos y demás contenido multimedia con el paso del tiempo. En los últimos años, con la extensión del uso de los dispositivos móviles, han aparecido nuevas aplicaciones de mensajerı́a instantánea como WhatsApp, Facebook Messenger, Telegram o Line que se han convertido en las más utilizadas del mundo para el intercambio de mensajes.. 2.2.. Caracterı́sticas de la comunicación instantánea. La comunicación entre los usuarios mediante el uso de la mensajerı́a instantánea presenta algunas caracterı́sticas particulares que suelen orientar el desarrollo de las diferentes aplicaciones de mensajerı́a. Los usuarios de este tipo de aplicaciones suelen disponer de una lista de contactos (los cuales son clientes de la aplicación de mensajerı́a) con los que intercambiar información. En algunos casos, esta lista de contactos se encuentra sincronizada con la lista de contactos interna del dispositivo donde está instalada la aplicación. La lista de contactos permite identificar a diferentes personas con las que el usuario puede comunicarse. Suele incluirse para cada contacto su nombre y una imagen identificativa ası́ como un mensaje de estado en algunos casos (disponible, ocupado etc.). Por otra parte, las aplicaciones de mensajerı́a suelen disponer de una lista de conversaciones (generalmente se muestran en primer lugar las más recientes). Las conversaciones pueden estar asociadas a la comunicación individual entre dos usuarios o a la comunicación en grupo de varias personas. Con respecto al tipo de mensajes enviados, habitualmente se trata de mensajes breves, los cuales incluyen con frecuencia emoticonos (que ayudan a transmitir emociones durante una conversación no presencial). Además de esto, muchas aplicaciones de mensajerı́a incluyen la posibilidad de adjuntar archivos como pueden ser fotografı́as o vı́deos.. 2.3.. Análisis del funcionamiento de las aplicaciones. En esta sección se busca comparar el funcionamiento, especialmente en lo referente a la seguridad de las comunicaciones, de las aplicaciones de mensajerı́a instantánea más populares..
(16) 6. CAPÍTULO 2. ESTADO DEL ARTE. WhatsApp WhatsApp es la aplicación de mensajerı́a instantánea más utilizada actualemente con más de 1500 millones de usuarios[9]. Además de esto, se estima que supera los 1000 millones de usuarios activos. Esta aplicación tiene su origen en el año 2009 y está disponible para los sistemas operativos móviles más utilizados (como Android, iOS o Windows Phone). En el año 2014 fue adquirida por Facebook, empresa que se encarga actualmente de su desarrollo. Esta aplicación facilita el envı́o de mensajes instantáneos entre usuarios individuales y grupos ası́ como de fotos, vı́deos y música. En las últimas versiones de esta aplicación se ha incorporado la posibilidad de enviar archivos (aunque esta opción está restringida a una serie de tipos de archivo concretos), GIFs animados o la ubicación en tiempo real[10]. Desde 2015 cuenta con una interfaz web (WhatsApp Web) que permite acceder a las conversaciones de WhatsApp de un teléfono móvil, con el que deberá sincronizarse mediante la lectura de un código QR. Desde 2016 dispone también de un cliente de escritorio (para Windows y Mac) similar. Desde un punto de vista técnico, cuando un usuario envı́a un mensaje, este es insertado en una cola de mensajes del servidor de WhatsApp para ser posteriormente consultado desde la aplicación del usuario receptor mediante el uso del protocolo “Extensible Messaging and Presence Protocol”[11]. Desde el año 2016, los mensajes almacenados en el servidor de WhatsApp se almacenan cifrados con un cifrado de extremo a extremo, por lo que WhatsApp asegura que el contenido de los mensajes no puede ser consultado desde sus servidores (al realizarse el cifrado desde los dispositivos terminales)[12]. A pesar de esto, el algoritmo de cifrado utilizado es propietario y únicamente están disponibles al público partes del código fuente de su implementación[13]. Además de esto, WhatsApp registra en sus servidores fotografı́as y vı́deos incluso habiendo sido borrados desde los dispositivos móviles desde donde fueron enviados o recibidos[14].. Telegram Telegram[15] es otra aplicación de mensajerı́a instantánea que cuenta con 100 millones de usuarios. Su creación se remonta al año 2013, siendo desarrollada por los hermanos Nikolái y Pável Dúro. En un principio esta aplicación fue creada con unas funcionalidades prácticamente idénticas a las de WhatsApp. Sin embargo, a lo largo de los años la aplicación se ha ido ampliando y hoy en dı́a incluye múltiples funcionalidades novedosas (contenido gráfico adicional, cuentas de usuario conocidas como “bots” que ofrecen respuestas automatizadas a consultas de los usuarios, temas de personalización, pequeños juegos, etc.). En lo referente al funcionamiento de la aplicación, Telegram dispone de dos tipos de conversaciones que los usuarios pueden seleccionar (chats normales y secretos). Las conversaciones por defecto (normales) se registran en los servidores de Telegram y únicamente se cifran durante el tránsito de la información entre el dispositivo móvil y el servidor[16]. Por otra parte, los chats secretos utilizan un cifrado de extremo a extremo de código abierto (MTProto) que permite proteger la información transmitida entre los dispositivos móviles..
(17) 2.3. ANÁLISIS DEL FUNCIONAMIENTO DE LAS APLICACIONES. 7. A diferencia de WhatsApp, que oficialmente sólo funciona en un único dispositivo a la vez (aunque puede retransmitir mensajes desde el dispositivo móvil a su cliente web), Telegram ofrece soporte multiplataforma y una mayor variedad de programas cliente (escritorio, web, móvil, tablet etc.).. Hangouts Google Hangouts[17] es una aplicación de mensajerı́a instantánea creada por Google en 2013. Esta aplicación fue creada a partir de Google Talk y ha sido integrada con otros servicios de Google como GMail. Entre las novedades que ofrece con respecto a otras aplicaciones, destacan sus funcionalidades de llamadas y videollamadas en grupo de hasta 15 personas o de envı́o de mensajes de texto SMS. Las conversaciones realizadas con esta aplicación se almacenan en los servidores de Google y pueden ser consultadas desde diferentes dispositivos conectados. En esta aplicación no se realiza ninguna clase de cifrado de extremo a extremo. Únicamente se realiza un cifrado de los mensajes enviados en la comunicación entre el cliente y el servidor de Google.. Signal Se trata de una aplicación novedosa que incorpora estándares de cifrado de extremo a extremo de dominio público y que se han demostrado confiables a lo largo de muchos años. Entre los algoritmos utilizados se incluyen curvas elı́pticas (Curve25519), cifrado simétrico (AES-256) o autenticación de de mensajes HMAC (HMAC-SHA256) con el objetivo de garantizar la confidencialidad de los mensajes intercambiados[18]. Por otra parte, todo el código fuente de la aplicación está disponible al público, lo cual permite su verificación y validación por parte de terceros. A diferencia de WhatsApp, que almacena en su sistema las imágenes y los vı́deos enviados, Signal no almacena ningún tipo de información sobre las conversaciones de los usuarios (exceptuando la información convenientemente encriptada necesaria para transmitir los mensajes, la cual es borrada cuando ya no es necesaria)[14]. Esta aplicación, desarrollada en 2014 por la empresa Marlinspike, incluye la posibilidad de enviar mensajes, llamadas o imágenes de forma segura, utilizando los citados algoritmos.. Comparativa A modo de resumen, se adjunta una tabla comparativa entre las aplicaciones analizadas. Aplicación Whatsapp Telegram. Cifrado Extremo a extremo Cliente-Servidor. Hangouts. Cliente-Servidor. Algoritmos Privados Parcialmente públicos Privados. Signal. Extremo a extremo. Públicos y confiables. Otros No cifra imágenes ni vı́deo Cifrado Ext.-Ext.(chats secretos) Múltiples clientes conectados Integración con servicios de Google Múltiples clientes conectados En desarrollo actualmente. Cuadro 2.1: Comparativa de aplicaciones de mensajerı́a.
(18) 8. 2.4.. CAPÍTULO 2. ESTADO DEL ARTE. Análisis de la solución planteada. En este proyecto se ha decidido desarrollar una aplicación de mensajerı́a instantánea teniendo en cuenta el contexto, las ventajas e inconvenientes de las diferentes aplicaciones ya existentes. En el apartado anterior se han analizado una serie de aplicaciones, de funcionalidades similares, que internamente gestionan la información de los usuarios de forma diferente. Actualmente existen múltiples aplicaciones que protegen la información en tránsito entre los dispositivos de los usuarios y sus servidores. De esta manera, es posible evitar que un usuario malintencionado intercepte las comunicaciones entre cliente y servidor con el fin de obtener información personal de los usuarios del sistema. Otras aplicaciones permiten el uso de cifrados de extremo a extremo, garantizando en teorı́a que la información enviada no pueda ser consultada ni analizada desde el servidor donde se almacena. La aplicación que se va a desarrollar en este proyecto garantizará la confidencialidad de la información enviada en estos dos niveles. Por un lado se encriptará la información en tránsito mediante el uso del protocolo SSL y por otro lado, se encriptará la información de extremo a extremo mediante el uso de la criptografı́a de clave pública. Además de esto, el sistema guardará los mensajes mientras que no hayan sido recuperados por el destinatario y cuya lectura no haya sido comprobada por parte del usuario emisor. Una vez que se hayan cumplido estas dos condiciones, los mensajes serán eliminados completamente del servidor y quedarán registrados únicamente en los dispositivos móviles de los usuarios emisor y receptor del mensaje. También se abordará el problema de almacenar los mensajes en los dispositivos móviles de los clientes de forma segura, utilizando la criptografı́a. De esta manera se podrá garantizar que un usuario no autorizado, con acceso al móvil, no pueda leer estos mensajes, ya que éstos sólo podrán ser descifrados mediante el uso de unas credenciales de acceso conocidas únicamente por el usuario legı́timo de la aplicación. Uno de los aspectos más destacables de la solución planteada es posibilidad de autenticar al usuario emisor mediante el uso de la firma digital. Teniendo en cuenta la integración que se va a realizar con el DNI Electrónico 3.0 (mediante el uso de la tecnologı́a NFC), el usuario receptor de un mensaje podrá estar totalmente seguro de que el emisor del mensaje es quien dice ser, aún sin tener contacto con él presencialmente. Todo mensaje que se firme con el DNI electrónico tendrá un valor legal equivalente al de estar firmado con una firma manuscrita (al tratarse de una firma electrónica reconocida) según está establecido en la legislación vigente[3]. Esta caracterı́stica de la firma digital garantiza otro de los principios de la seguridad informática, el “no repudio” (el usuario emisor de un mensaje no podrá argumentar que éste ha sido enviado sin su conocimiento o consentimiento)..
(19) Capı́tulo 3. Evaluación de riesgos Partiendo de los objetivos expuestos en el primer capı́tulo, es necesario realizar un análisis de los riesgos que afectan al proyecto, como paso previo a la realización del desarrollo del mismo. Comprender los riesgos que afectan al proyecto es fundamental para poder determinar el ciclo de vida y la estrategia a seguir a lo largo de su desarrollo. Se comenzará este capı́tulo identificando los riesgos, para lo cual se utilizará la técnica de tormenta de ideas (conocida también como “brainstorming”). Una vez identificados los posibles riesgos que afecten al proyecto, se estimará su probabilidad de ocurrencia e impacto. Los riesgos evaluados de esta manera serán agrupados por categorı́as en función de su incidencia y se indicará una estrategia de tratamiento para cada uno de ellos.. 3.1.. Identificación de los riesgos. En este proyecto se han identificado los siguientes riesgos: Código RSG-1. Nombre Modificación de los requisitos. RSG-2. Daños a los recursos materiales. RSG-3. Falla la conexión a internet. RSG-4. Errores en la estimación temporal. RSG-5. Pérdida de información valiosa. Descripción Los requisitos del proyecto son modificados durante el desarrollo. Posibles desastres o accidentes que dañen los recursos fı́sicos (incluyendo hardware). Posibles interrupciones en el proceso de control de cambios, en la búsqueda de información y documentación o en el acceso al servidor. No se puede construir un proyecto de tal envergadura en el plazo disponible. En un incremento del desarrollo del software se modifica o elimina una parte del código valiosa.. Cuadro 3.1: Identificación de los riesgos del proyecto. 9.
(20) CAPÍTULO 3. EVALUACIÓN DE RIESGOS. 10. 3.2.. Análisis cualitativo de los riesgos. 3.2.1.. Evaluación de Probabilidad e Impacto de los Riesgos Valoración de la probabilidad. Ocurrencia del riesgo >= 80 % (casi segura). Probabilidad Alta. Entre 30 % y 80 % (muy probable). Media. <= 30 % (poco probable). Baja. Significado Se considera que el riesgo se va a producir durante la vida del proyecto, pero no sabemos cuando. El riesgo tiene una probabilidad considerable de que ocurra en el perı́odo del proyecto. Se considerarı́a extraordinario que el riesgo sucediese, pero no se descarta la posibilidad.. Cuadro 3.2: Valoración de la probabilidad de los riesgos Valoración del impacto Repercusión >= 20 %. Impacto Alto. Entre 10 % y 20 %. Medio. <= 10 %. Bajo. Significado Tiene un impacto grave en el desarrollo. Requiere una solución inmediata, y dicha solución supone un gasto a mayores tanto económico (más del 20 %) como temporal (solucionarlo puede incrementar un 20 % o más el tiempo total de desarrollo del proyecto). El problema se resuelve sin demasiadas complicaciones pero no cuenta con una prioridad alta de resolución. Supone un incremento en el tiempo y presupuesto del proyecto de entre un 5 % y un 20 %. Las consecuencias son tan bajas que no será necesario solucionar el problema. No alarga significativamente el tiempo del proyecto ni supone un gran gasto a mayores sobre el presupuesto (entre un 1 % y un 5 %).. Cuadro 3.3: Valoración del impacto de los riesgos A continuación se muestra una evaluación de la probabilidad e impacto para cada uno de los riesgos identificados: Código RSG-1 RSG-2 RSG-3 RSG-4 RSG-5. Probabilidad Baja Baja Baja Media Alta. Impacto Medio Alto Bajo Medio Alto. Cuadro 3.4: Evaluación de la probabilidad e impacto de los riesgos.
(21) 3.3. PLANIFICACIÓN DE LA RESPUESTA A LOS RIESGOS. 3.2.2.. 11. Matriz de Probabilidad-Impacto. La matriz de probabilidad e impacto permite agrupar los diferentes riesgos en categorı́as según las dimensiones de probabilidad e impacto mencionadas previamente. Im. \Pr. Alto Medio Bajo. Alta RSG-5 -. Media RSG-4 -. Baja RSG-2 RSG-1 RSG-3. Cuadro 3.5: Matriz de Probabilidad-Impacto de los riesgos. 3.3.. Planificación de la respuesta a los riesgos. En este apartado se incluye la planificación de la respuesta a los riesgos planteados. Los diferentes riesgos serán ordenados de mayor a menor incidencia partiendo de los resultados obtenidos en la matriz de probabilidad e impacto. La incidencia de los riesgos se calculará como el producto de la probabilidad por el impacto considerando una escala de valores del uno al tres en función de los grupos anteriores (bajo, medio y alto). En el caso de que dos riesgos tengan el mismo impacto calculado, se considerará de mayor impacto aquel que tenga más probabilidad. Si la probabilidad e impacto coinciden, se ordenarán en función de su código de identificación. Listado de riesgos de mayor a menor impacto: Código RSG-5. RSG-4. RSG-2 RSG-1 RSG-3. Tratamiento Se seguirá una estrategia de prevención. Se utilizará un proceso de control de cambios y se realizarán versiones de forma periódica en el marco de un desarrollo incremental. El repositorio donde se almacenarán los datos será remoto. Se seguirá una estrategia de mitigación, realizando la etapa de desarrollo del proyecto de forma incremental, priorizando determinados requisitos y posibilitando el fin de la implementación en el tiempo previsto. Teniendo en cuenta la posibilidad muy reducida de que esto suceda, se acepta el riesgo. Será necesario reponer el material fı́sico dañado con posterioridad al suceso. Se seguirá una estrategia de prevención de este riesgo. Se especificarán los requisitos del proyecto de forma exhaustiva en el Plan de Trabajo, como paso previo al desarrollo. Se seguirá una estrategia de mitigación. Se configurará el equipo para el acceso a la red de la universidad. En caso de que la red personal falle, se podrá utilizar esta red si fuera necesario. Cuadro 3.6: Planificación de la respuesta a los riesgos. Teniendo en cuenta los diferentes tratamientos de los riesgos analizados, se deberá seleccionar un ciclo de vida del proyecto y una metodologı́a compatible con los principios descritos. En el siguiente capı́tulo se describirán los detalles de la metodologı́a seguida para realizar el desarrollo del proyecto..
(22) Capı́tulo 4. Desarrollo El objetivo de este capı́tulo es exponer los diferentes pasos que se han seguido para el desarrollo de este proyecto y del producto software que se adjunta al mismo. Se comenzará el desarrollo del proyecto por el planteamiento del problema. Posteriormente se enunciará la metodologı́a seguida para llevar a cabo el proyecto ası́ como el diseño de la solución propuesta y los detalles acerca de la implementación y las pruebas realizadas.. 4.1.. Planteamiento del problema. Se comenzará el desarrollo del proyecto con una fase de análisis del problema que se pretende resolver, partiendo de las conclusiones expuestas en los capı́tulos anteriores. En este capı́tulo se incluirá un análisis de los requisitos del proyecto y un análisis de casos de uso que servirán como guı́a para realizar el diseño e implementación de un producto software que sirva como solución al problema planteado.. 4.1.1.. Análisis de requisitos. En este apartado se especifican los requisitos del sistema a desarrollar (funcionales y no funcionales) clasificados según su importancia junto con la descripción de los criterios usados para determinarla. Requisitos no funcionales Se incluye a continuación una tabla con la lista de requisitos no funcionales identificados secuencialmente. Se distinguen requisitos de rendimiento (RR) y requisitos de interfaz (RI). Código RI-1 RI-2 RI-3 RI-4 RR-1 RR-2. Descripción Firma de mensajes mediante certificados digitales Integración con el DNI electrónico 3.0 Comunicación cliente-servidor mediante SSL Aplicación móvil desarrollada en Android Interfaz usable Minimizar los datos guardados en el servidor Cuadro 4.1: Lista de requisitos no funcionales 12. Importancia Alta Alta Media Alta Baja Media.
(23) 4.1. PLANTEAMIENTO DEL PROBLEMA. 13. Requisitos funcionales Se incluye a continuación una tabla con la lista de requisitos funcionales identificados secuencialmente. Se incluyen las dependencias que puedan presentar entre ellos. Posteriormente se describirán con más detalle estos requisitos que se corresponden con las funcionalidades que ofrecerá el producto desarrollado. En apartados siguientes se procederá a agrupar estos requisitos por subsistemas de funcionalidades y a relacionar los mismos con los casos de uso definidos. Código RF-1 RF-2 RF-3 RF-4 RF-5 RF-6 RF-7 RF-8 RF-9 RF-10 RF-11. Descripción Registro de usuarios Consultar datos de los usuarios Gestión de lista de contactos Enviar mensajes cifrados a usuarios Enviar mensajes firmados a usuarios Inicio y cierre de sesión en la aplicación Gestión de conversaciones por contacto Notificaciones de mensajes recibidos Gestión de usuarios y estadı́sticas Verificación de firmas digitales Confirmación de lectura de los mensajes. Dependencias RF-1 RF-1, RF-1, RF-1, RF-1 RF-3, RF-3, RF-1, RF-5 RF-4,. RF-2 RF-2, RF-3 RF-2, RF-3 RF-4, RF-5 RF-4, RF-5 RF-4, RF-5 RF-5. Importancia Alta Alta Alta Alta Alta Baja Alta Media Baja Alta Media. Cuadro 4.2: Lista de requisitos funcionales Descripción de los requisitos RI-1 - Firma de mensajes mediante certificados digitales Se utilizará una infraestructura de clave pública en la que cada usuario del sistema dispondrá de un certificado digital interno. Cuando un usuario desee realizar una firma digital podrá realizarla usando su certificado de usuario y la clave privada asociada. RI-2 - Integración con el DNI electrónico 3.0 Se utilizará un middleware para la conexión con el DNI electrónico 3.0 mediante la tecnologı́a NFC (Near Field Communication). La conexión con el DNI electrónico podrá ser utilizada para generar firmas digitales sobre los mensajes enviados. El uso de la firma digital con DNI electrónico será alternativo al del certificado interno. RI-3 - Comunicación cliente-servidor mediante SSL Las comunicaciones que se realicen entre el cliente (la aplicación móvil) y el servidor que integran el sistema a desarrollar (junto con la base de datos) serán encriptadas utilizando el protocolo SSL. RI-4 - Aplicación móvil desarrollada en Android La aplicación móvil será desarrollada en Android y será compatible con dispositivos móviles Android con una versión del sistema operativo igual o superior a Android 4.4 que dispongan de lector NFC..
(24) 14. CAPÍTULO 4. DESARROLLO. RR-1 - Interfaz usable La interfaz de usuario de la aplicación móvil será diseñada de acuerdo con criterios de simplicidad y eficiencia en las operaciones a realizar, buscando conseguir la mejor experiencia de usuario posible. RR-2 - Minimizar los datos guardados en el servidor Con el fin de economizar el almacenamiento de información en el servidor del sistema ası́ como de garantizar la privacidad de las comunicaciones realizadas, los mensajes de los usuarios que hayan sido leı́dos y cuya lectura se haya confirmado, serán eliminados de la base de datos del sistema. RF-1 - Registro de usuarios Los usuarios podrán darse de alta en el sistema como paso previo a la utilización de los servicios disponibles. En el proceso de registro, un usuario generará una clave privada personal y una solicitud de certificado con algunos datos personales (como el nombre, paı́s, ciudad o provincia). El servidor devolverá al usuario un certificado firmado y añadirá el nuevo usuario al sistema. RF-2 - Consultar datos de los usuarios Un usuario del sistema podrá solicitar al servidor los datos de registro de otro usuario del sistema y su certificado digital. Estos datos serán utilizados para poder añadir contactos y enviar mensajes cifrados mediante la criptografı́a de clave pública. RF-3 - Gestión de lista de contactos Cada usuario del sistema dispondrá en su aplicación móvil de una lista de contactos sobre la cual podrá añadir nuevos contactos o eliminar los ya existentes. Para cada contacto se mostrará su nombre y el número de mensajes nuevos que haya enviado. Cuando el usuario de la aplicación seleccione un contacto, podrá acceder a una interfaz de conversación con ese contacto. RF-4 - Enviar mensajes cifrados a usuarios La aplicación móvil permitirá enviar mensajes cifrados a otros usuarios añadidos como contactos. RF-5 - Enviar mensajes firmados a usuarios La aplicación móvil permitirá enviar mensajes firmados (además de cifrados) a otros usuarios añadidos como contactos. La firma digital podrá realizarse con un certificado interno o con el que se incluye en el DNI electrónico. RF-5 - Enviar mensajes firmados a usuarios La aplicación móvil permitirá enviar mensajes firmados (además de cifrados) a otros usuarios añadidos como contactos. La firma digital podrá realizarse con un certificado interno o con el que se incluye en el DNI electrónico..
(25) 4.1. PLANTEAMIENTO DEL PROBLEMA. 15. RF-6 - Inicio y cierre de sesión en la aplicación Los usuarios podrán gestionar una sesión en la aplicación a la cual se acceda mediante contraseña. Mientras la sesión esté cerrada, no se podrá acceder a las conversaciones con los diferentes contactos ni modificar la configuración de la aplicación. RF-7 - Gestión de conversaciones por contacto Los usuarios podrán acceder a los mensajes enviados y recibidos, que constituyen la conversación con un contacto, en cualquier momento. A medida que se envı́en o se reciban nuevos mensajes, la conversación se irá actualizando. Si se selecciona un mensaje, se podrá obtener más información sobre el mismo, incluyendo los datos del emisor y datos de la firma digital (si está incluida). Se mostrarán también las fechas de envı́o y recepción del mensaje (según el tipo de mensaje). RF-8 - Notificaciones de mensajes recibidos La aplicación lanzará notificaciones en el sistema Android cuando se reciban nuevos mensajes, con el fin de avisar al usuario de la existencia de nuevos mensajes. RF-9 - Gestión de usuarios y estadı́sticas El administrador del sistema (usuario con acceso a la configuración del servidor) podrá realizar operaciones de gestión de usuarios (consulta y modificación de datos) ası́ como consultar estadı́sticas de funcionamiento sobre los usuarios y mensajes que gestiona el servidor. Este usuario no tendrá acceso en ningún caso al contenido de los mensajes ya que estarán cifrados de extremo a extremo. RF-10 - Verificación de firmas digitales Todo usuario que reciba un mensaje firmado podrá verificar la firma digital realizada. Se comprobará que sea realizada por una entidad de confianza (la autoridad de certificación del sistema o la correspondiente al DNI electrónico) y se revisará la integridad de los mensajes firmados y su autenticidad mediante este mecanismo. RF-11 - Confirmación de lectura de los mensajes Los usuarios podrán comprobar la fecha y hora de recepción de un mensaje por parte del usuario destinatario, consultando las propiedades del mensaje enviado. Criterios de clasificación de las funcionalidades Alta - Requisito necesario para el funcionamiento básico del programa. Media - Requisito muy deseable cuya ausencia no impide el funcionamiento del programa. Baja - Requisito sin el cual el programa perderá solamente un poco de calidad.. 4.1.2.. Casos de uso. Una vez definidos los requisitos del sistema que se va a desarrollar, se expondrán los casos de uso que representan la interacción de los usuarios con el sistema..
(26) CAPÍTULO 4. DESARROLLO. 16. Se comenzará definiendo el conjunto de actores (que en este caso representan los diferentes roles de usuarios que se distinguen en el sistema) y posteriormente, se incluirá un diagrama de casos de uso y una especificación de los mismos. Actores ACT-01 Descripción Comentarios. Invitado Representa a un usuario de la aplicación no identificado. Es el usuario por defecto al iniciar la aplicación.. ACT-02 Descripción Comentarios. Usuario Representa a un usuario identificado no privilegiado (“usuario normal”). Será necesario estar identificado para acceder a la mayorı́a de los servicios.. ACT-03 Descripción Comentarios. Administrador Representa a un usuario identificado como administrador. Los administradores tienen acceso a determinados servicios especiales. Cuadro 4.3: Lista de actores identificados en el sistema. Diagrama de casos de uso. Figura 4.1: Diagrama de casos de uso.
(27) 4.1. PLANTEAMIENTO DEL PROBLEMA. 17. Especificación de los casos de uso Se incluye la descripción detallada de los casos de uso identificados (los cuales figuran en el diagrama de casos de uso). Para cada caso de uso se incluyen precondiciones, un escenario principal y escenarios alternativos ası́ como el actor o actores relacionados (los cuales fueron descritos en el apartado anterior), inclusiones o extensiones de otros casos de uso, frecuencia de uso y, opcionalmente, comentarios.. CU-1 Descripción Actores Precondiciones Flujo normal. Flujos alternos. Incluye Extiende Fecuencia de uso Comentarios. Registrar usuario El sistema permitirá la creación de usuarios identificados de forma unı́voca mediante el uso de un ID de usuario. Invitado, Usuario, Administrador Aplicación iniciada. 1 - El usuario selecciona la opción de registrarse. 2 - El usuario introduce sus datos. 3 - El usuario confirma la operación. Los datos introducidos no son válidos. 3 - Falla la confirmación de registro. 4 - Se solicita al usuario de nuevo introducir sus datos. Nada Nada Media Si el usuario ya está registrado, se sobreescribirán sus datos. Cuadro 4.4: Caso de uso de registro de usuarios. CU-2 Descripción Actores Precondiciones Flujo normal. Flujos alternos Incluye Extiende Fecuencia de uso. Consultar usuario El sistema permitirá obtener los datos de un usuario mediante búsqueda por ID. Administrador Aplicación iniciada. 1 - El usuario selecciona la opción de consultar usuario. 2 - El usuario introduce el ID del usuario a buscar. 3 - El usuario confirma la operación. 4 - Se muestran los datos del usuario. El usuario no existe. 4 - Se muestra un error de usuario inexistente. Nada Nada Media Cuadro 4.5: Caso de uso de consulta de datos de usuarios.
(28) 18 CU-3 Descripción Actores Precondiciones Flujo normal. Flujos alternos Incluye Extiende Fecuencia de uso. CAPÍTULO 4. DESARROLLO Añadir contacto El sistema permitirá añadir contactos mediante búsqueda por ID. Usuario Aplicación iniciada. 1 - El usuario selecciona la opción de añadir contacto usuario. 2 - El usuario introduce el ID del usuario a añadir. 3 - El usuario confirma la operación. 4 - Se añade el contacto con sus datos a la lista de contactos. El usuario no existe. 4 - Se muestra un error de usuario inexistente. CU-2 (Consultar usuario) Nada Alta Cuadro 4.6: Caso de uso de añadir un contacto. CU-4 Descripción Actores Precondiciones Flujo normal. Flujos alternos Incluye Extiende Fecuencia de uso. Eliminar contacto El sistema permitirá eliminar contactos añadidos previamente. Administrador Aplicación iniciada, contacto existente previamente. 1 - El usuario selecciona un contacto existente. 2 - El usuario selecciona la opción de eliminar contacto. 3 - El usuario confirma la operación. Nada Nada Baja Cuadro 4.7: Caso de uso de eliminar un contacto. CU-5 Descripción Actores Precondiciones Flujo normal. Flujos alternos. Incluye Extiende Fecuencia de uso. Iniciar sesión El sistema permitirá iniciar sesión a usuarios registrados. Usuario Aplicación iniciada, usuario registrado previamente 1 - Se muestra una interfaz para introducir la contraseña. 2 - El usuario introduce la contraseña. 3 - El usuario confirma la operación e inicia sesión. El usuario cancela la operación. 3 - Se solicita restablecer la aplicación o cerrar. 4 - Si se restablece la aplicación, el usuario deberá registrarse de nuevo. Contraseña incorrecta 3 - Se muestra un mensaje de que la contraseña es errónea. Nada Nada Media Cuadro 4.8: Caso de uso de inicio de sesión.
(29) 4.1. PLANTEAMIENTO DEL PROBLEMA CU-6 Descripción Actores Precondiciones Flujo normal. Flujos alternos Incluye Extiende Fecuencia de uso Comentarios. 19. Cerrar sesión El sistema permitirá cerrar sesión cuando la sesión esté iniciada. Usuario Aplicación iniciada, sesión iniciada 1 - El usuario selecciona el menú de opciones. 2 - El usuario selecciona la opción de cerrar sesión. 3 - La aplicación finaliza. Nada Nada Media Tras cerrar sesión, el usuario deberá iniciar sesión de nuevo en el sistema para poder realizar las tareas de añadir contactos, consultar mensajes enviados o enviar nuevos mensajes. La sesión permanecerá abierta por defecto desde que el usuario se registra. Sólo será cerrada si el usuario ejecuta esta operación de forma explı́cita. Cuadro 4.9: Caso de uso de cierre de sesión. CU-7 Descripción Actores Precondiciones Flujo normal. Flujos alternos Incluye Extiende Fecuencia de uso Comentarios. Consultar estadı́sticas El sistema permitirá consultar estadı́sticas sobre usuarios registrados y mensajes en el sistema. Administrador Servidor iniciado 1 - El administrador selecciona la opción de ver estadı́sticas. 2 - El administrador puede seleccionar una operación. El administrador selecciona ver estadı́sticas de los usuarios registrados 3.1 - Se muestra el número de usuarios registrados en el sistema. 3.1 - Se muestran los datos de los últimos usuarios registrados. El administrador selecciona ver estadı́sticas de los mensajes 3.2 - Se muestra el número de mensajes en cola. 4.2 - Se muestran los usuarios con más mensajes en cola. Nada Nada Baja Se deja abierta la posibilidad de añadir nuevos tipos de estadı́sticas sobre el funcionamiento del sistema o sobre los datos almacenados. Cuadro 4.10: Caso de uso de consulta de estadı́sticas.
(30) 20 CU-8 Descripción Actores Precondiciones Flujo normal. Flujos alternos. Incluye Extiende Fecuencia de uso. CAPÍTULO 4. DESARROLLO Enviar mensaje El sistema permitirá enviar mensajes a usuarios. Usuario Aplicación iniciada, usuario registrado 1 - El usuario configura el tipo de firma a realizar en los mensajes. 2 - El usuario selecciona un contacto de la lista de contactos. 3 - El usuario escribe un mensaje. El mensaje no está firmado o se firma con certificado interno 4.1 - El usuario selecciona la opción de enviar el mensaje. 5.1 - El mensaje se envı́a. 6.1 - El mensaje aparece en la conversación con el contacto como enviado. 7.1 - Cuando el mensaje sea leı́do se marcará como leı́do. El mensaje se firma con el DNI electrónico 4.2 - El usuario selecciona la opción de enviar el mensaje. 5.2 - Se solicita al usuario que introduzca el número CAN. 6.2 - Se solicita al usuario que acerque su DNI electrónico. 7.2 - Se solicita el PIN del DNI electrónico. 8.2 - Se firma el mensaje y se pregunta al usuario si desea enviarlo. 9.2 - Si el usuario acepta, se envı́a el mensaje. 10.2 - El mensaje aparece en la conversación con el contacto como enviado. 11.2 - Cuando el mensaje sea leı́do se marcará como leı́do. Falla la conexión con el DNI electrónico 7.2 - Se solicita al usuario que repita la operación. El usuario cancela la firma 5.2 - Se regresa a la vista de envı́o de mensajes. Nada Nada Alta Cuadro 4.11: Caso de uso de envı́o de un mensaje. CU-9 Descripción Actores Precondiciones Flujo normal. Flujos alternos Incluye Extiende Fecuencia de uso. Recibir mensaje El sistema permitirá recibir mensajes de otros usuarios. Usuario Aplicación iniciada, usuario registrado 1 - El usuario recibe un mensaje nuevo. 2 - Se muestra una notificación y se incrementa el número de mensajes nuevos para el contacto emisor. Si el contacto es nuevo, se añade a la lista. 3 - Se valida la firma del mensaje (en el caso de incluirse). 4 - El usuario abre la conversación con el contacto emisor del mensaje 5 - Se muestra el mensaje nuevo según su tipo (no firmado o firmado). Nada Nada Alta Cuadro 4.12: Caso de uso de recepción de un mensaje.
(31) 4.1. PLANTEAMIENTO DEL PROBLEMA CU-11 Descripción Actores Precondiciones Flujo normal. Flujos alternos Incluye Extiende Fecuencia de uso. 21. Consultar mensaje El sistema permitirá consultar datos de mensajes recibidos y enviados. Usuario Aplicación iniciada, existen mensajes enviados y recibidos. 1 - El usuario abre una conversación con un contacto. 2 - El usuario selecciona un mensaje de la conversación. Mensaje enviado 3.1 - Se muestra le fecha de envı́o. 4.1 - Se muestra la fecha de recepción (si fue recibido). 5.1 - Se muestran datos de la firma (si fue realizada). Mensaje recibido 3.2 - Se muestra la fecha de recepción. 4.2 - Se muestran datos de la firma (si fue realizada). Nada Nada Alta Cuadro 4.13: Caso de uso de consulta de un mensaje. 4.1.3.. Matriz de trazabilidad. A continuación, se incluye la matriz de trazabilidad que relaciona requisitos funcionales y casos de uso incluidos en los apartados anteriores.. Figura 4.2: Matriz de trazabilidad entre requisitos funcionales y casos de uso.
(32) CAPÍTULO 4. DESARROLLO. 22. 4.2.. Ciclo de vida del proyecto. El ciclo de vida de un proyecto se refiere al conjunto de etapas que sigue el software desde el comienzo del proyecto, hasta la finalización del mismo[20]. Existen múltiples modelos de ciclos de vida que se pueden utilizar en función de las caracterı́sticas concretas del proyecto a realizar. En este caso, se ha optado por la utilización de un ciclo de vida en cascada para desarrollar este proyecto. El ciclo de vida en cascada es el paradigma más antiguo de los utilizados en la Ingenierı́a de Software. Se caracteriza por el uso de un enfoque sistemático y secuencial a lo largo del desarrollo del software. Un proyecto realizado con esta metodologı́a parte de un análisis de requisitos que busca reunir las necesidades del producto software que se pretende desarrollar. Después de esta fase, se continúa con el diseño del software permitiendo traducir los requisitos a una serie de representaciones que permiten comprender su funcionamiento (a nivel de arquitectura del sistema, estructuración de los datos, interfaces, etc.). Durante la etapa de codificación (o implementación) se busca, a partir de los diseños realizados, construir un código fuente que, una vez compilado, permita la generación de uno o varios ejecutables que contengan el producto software desarrollado. En la etapa de pruebas, se revisará el funcionamiento de la aplicación y se realizarán cambios para asegurar que el resultado final se ajusta a los requisitos planteados al comienzo del proyecto. Tras la finalización exitosa de las pruebas, se considera que el producto software está finalizado y se procede a su despliegue para dar soporte a los diferentes usuarios. Además de esto, existe una última etapa de mantenimiento que busca dar solución a posibles cambios que pida el cliente o a resolver errores latentes. En el caso de este proyecto, se seguirán las fases de análisis de requisitos, diseño, implementación, pruebas y despliegue. No se contempla la etapa de mantenimiento ya que no está reflejada en los objetivos del proyecto.. Figura 4.3: Esquema del ciclo de vida en cascada.
(33) 4.3. GESTIÓN DE LA CONFIGURACIÓN. 23. El modelo en cascada se trata de un modelo sencillo que facilita la gestión de los proyectos. Se caracteriza por el hecho de que una fase comienza cuando termina la fase anterior, aunque existe la posibilidad de retroceder en el ciclo para hacer cambios en los diseños o en la implementación realizada. Se ha optado por la elección de un modelo en cascada para el ciclo de vida del proyecto debido a las siguientes caracterı́sticas del proyecto: Se trata de un proyecto realizado de forma individual Los requisitos están claramente definidos al comienzo del proyecto No hay cambios previstos en los requisitos a lo largo del desarrollo Existen unos plazos de entrega fuertemente definidos Facilita el seguimiento y control del desarrollo del proyecto Existen otros modelos de ciclo de vida basados en incrementos, ası́ como metodologı́as ágiles que están orientadas especialmente al trabajo en equipos, a la entrega continua o a tratar con clientes que exigen cambios frecuentes en los requisitos. Teniendo en cuenta las caracterı́sticas expuestas del proyecto, se ha decidido descartar este tipo de metodologı́as y apostar por el modelo en cascada.. 4.3.. Gestión de la configuración. Partiendo de las conclusiones obtenidas en el análisis de riesgos, es fundamental establecer un proceso de gestión de la configuración que permita prevenir la posible pérdida de información valiosa motivada por errores de edición o por la eliminación accidental o provocada. Se aplicará un proceso de gestión de la configuración sobre los siguientes elementos que constituyen el software desarrollado (elementos de configuración): Memoria del proyecto Servidor Aplicación móvil cliente (Android) Los elementos de configuración identificados serán sometidos a un proceso de control de cambios que permitirá conservar versiones intermedias de los mismos previas a la liberación de la versión definitiva del software (cuando finalice el proyecto). Teniendo en cuenta la metodologı́a en cascada utilizada para el desarrollo del proyecto, únicamente se garantizará como funcional la última versión publicada, que incluirá los diferentes elementos de configuración en su versión más reciente, y que se adjuntará junto a esta memoria de proyecto.. 4.3.1.. Control de cambios. El proceso de gestión de la configuración deberá permitir un control de cambios adecuado que permita comparar las diferentes versiones de los elementos de configuración..
(34) CAPÍTULO 4. DESARROLLO. 24. Según las conclusiones extraı́das del análisis de riesgos, es necesario prevenir el riesgo de que se pierda la información en caso de que el equipo de trabajo resulte dañado por un problema fı́sico o cualquier desastre. En consecuencia, se ha decidido utilizar un repositorio remoto que permita mantener almacenada, de forma segura, la información generada para los diferentes elementos de configuración. Se utilizará la herramienta Git para posibilitar el control de cambios realizados entre las diferentes versiones generadas a lo largo del desarrollo del sistema para todos los elementos de configuración descritos. Se creará un repositorio privado en Bitbucket[19] que incluya en su directorio raı́z los diferentes elementos de configuración (memoria y código fuente del software que forma parte del proyecto). Bitbucket permite la utilización de repositorios privados de forma gratuita, permitiendo almacenar la información generada de forma segura, evitando accesos no autorizados a la misma. Para realizar el control de cambios, se creará un repositorio local con Git y se vinculará al repositorio remoto de Bitbucket. Cuando se desee realizar cambios en el repositorio, se utilizará la operación “commit” para registar una nueva versión del proyecto con los cambios actualizados. Una vez generada la nueva versión, se utilizará la operación “push” de Git para registrar los cambios en el repositorio remoto sincronizando el mismo con el repositorio local.. Se utilizará Bitbucket como repositorio. La generación de versiones se realizará diariamente. Cada dı́a de trabajo se construirá al menos una nueva versión con los cambios más actualizados. Si se realizan muchos cambios, se podrán realizar múltiples versiones el mismo dı́a. Para asegurar la integridad de los elementos de configuración gestionados, unicamente se realizarán cambios en el repositorio desde una única copia local. Teniendo en cuenta que este proyecto es individual, sólo realizará cambios el autor de este proyecto.. Control de versiones..
(35) 4.4. ESQUEMA DE DESCOMPOSICIÓN DE TAREAS. 4.4.. 25. Esquema de Descomposición de Tareas. Partiendo de los objetivos del proyecto y del análisis de requisitos y casos de uso realizado, se ha procedido a elaborar el Esquema de Descomposición de Tareas (EDT) del proyecto. Este esquema presenta las diferentes tareas del proyecto organizadas de forma jerárquica, definiendo el alcance del mismo. Este esquema servirá como base para la realización de la estimación temporal a nivel de tarea que se presentará en el siguiente apartado.. Figura 4.4: Esquema de Descomposición de Tareas. 4.5.. Estimación temporal. Tras la realización del Esquema de Descomposición de Tareas (EDT), se ha procedido a realizar la estimación temporal de la duración de las tareas del proyecto. Se ha realizado una estimación en horas de trabajo necesarias para realizar cada una de las tareas y se ha calculado la duración estimada teniendo en cuenta una dedicación media de cinco horas de trabajo por dı́a. Una vez realizada la estimación de la duración de las tareas, se ha realizado una planificación temporal de las mismas teniendo en cuenta las fechas de entregas que se deben realizar a lo largo del desarrollo del proyecto y, especialmente, el plazo lı́mite para la entrega de este trabajo. Tras realizar la estimación de las tareas y la planificación temporal de las mismas, se ha realizado un diagrama de Gantt que permite visualizar la distribución del esfuerzo a lo largo de la realización del proyecto ası́ como las dependencias existentes entre las diferentes tareas..
(36) CAPÍTULO 4. DESARROLLO. 26. Figura 4.5: Estimación temporal de las tareas. Figura 4.6: Diagrama de Gantt.
(37) 4.6. ESTIMACIÓN DE COSTES. 4.6.. 27. Estimación de costes. Para proceder a la estimación de costes del proyecto, es necesario tener en cuenta el personal disponible para la realización del mismo. Como este proyecto es de carácter individual, el autor del mismo será el único recurso humano encargado de su desarrollo. Se ha determinado el siguiente coste por hora: Rol Ingeniero en Informática. Coste por hora 15 e. Número de horas 486. Cuadro 4.14: Coste por hora de los recursos humanos del proyecto El coste de recursos humanos se calculará a partir de la multiplicación del coste por hora del recurso por el número de horas estimadas de trabajo. Para realizar la estimación del coste por hora en recursos humanos, se ha realizado una estimación del salario bruto anual que podrı́a ser aplicable al autor de este trabajo en función de los estudios y titulación alcanzada, experiencia laboral y sector profesional en el que encajarı́a este proyecto. Teniendo en cuenta diferentes ofertas de trabajo publicadas en el portal de UPM empleo ası́ como en otros portales de empleo de dominio público y la experiencia personal del autor de este trabajo, se ha estimado el siguiente salario bruto anual: Rol Ingeniero en Informática. Salario bruto anual 27.000 e. Partiendo del “XVI Convenio colectivo estatal de empresas de consultorı́a y estudios de mercado y de la opinión pública” publicado en el BOE[21], en el cual se incluyen empresas de servicios informáticos, el número máximo de horas de trabajo anuales no deberá exceder las 1800. Teniendo en cuenta el máximo de 1800 horas trabajadas por año y el salario bruto de referencia, se ha calculado el coste por hora para el ingeniero incluido en la tabla de costes. Si se realiza el producto entre el coste por hora en recursos humanos y las horas de trabajo estimadas para realizar el proyecto, se obtiene un coste en recursos humanos del proyecto estimado en 7290e. Junto con el coste de los recursos humanos calculado, es necesario tener en cuenta los siguientes costes indirectos relacionados con las necesidades del proyecto: Elemento Acceso a Internet 30 Mb ADSL Consumo eléctrico. Coste estimado mensual 30 e 60 e. C.E. mensual según uso 15 e 30 e. Cuadro 4.15: Costes indirectos del proyecto por mes.
(38) CAPÍTULO 4. DESARROLLO. 28. Para calcular el coste estimado mensual, en función del uso, se ha estimado un 50 % de utilización de los diferentes elementos, teniendo en cuenta la estimación temporal realizada donde se estiman unas 120 horas de trabajo mensuales aproximadamente. Teniendo en cuenta la duración estimada del proyecto de 4 meses aproximadamente, el coste total a lo largo del proyecto de estos costes indirectos se estima en 180e. Existen otros costes indirectos correspondientes a equipamiento: Elemento Ordenador personal Móvil Android con NFC. Coste estimado 1200 e 200 e. Coste E. según uso 40e 10e. Cuadro 4.16: Costes del proyecto relacionados con el equipamiento Los costes de equipamiento se han calculado en función del porcentaje de uso sobre la vida media de los diferentes elementos. En el caso del ordenador personal, se estima una duración de 5 años de vida media, mientras que en el caso del móvil se estiman 3 años. En lo referente a su utilización, se estima un 50 % de uso durante los 4 meses de duración estimada del proyecto. Estos costes de equipamiento suponen 50e. Si se suma esta cantidad a los costes indirectos anteriores se obtiene un coste total de 230e en costes indirectos. Para la estimación de los costes indirectos, se ha seguido la técnica de “Juicio de Expertos” utilizando la experiencia personal adquirida ası́ como la búsqueda y documentación al respecto de los precios medios del equipamiento. Si se suma el total de costes del proyecto, se obtiene un coste total de 7480e de los cuales un 97,5 % corresponde a costes de personal (recursos humanos). Teniendo en cuenta el coste total estimado, se incluirá un margen de beneficio del 30 % sobre dicho coste. De esta manera, se presupuesta el proyecto en 9724e teniendo en cuenta la metodologı́a expuesta. Si se observa el tipo general de IVA en España[24] (21 %) aplicable a la venta de un proyecto como el que se pretende desarrollar, el precio de venta al público deberı́a ser de 11766e. Se excluyen de esta estimación los costes relacionados con los aspectos académicos de la realización del proyecto (tutorización, tasas de matrı́cula, etc.).. 4.7.. Diseño de la solución. El diseño del sistema es una parte fundamental dentro del desarrollo del proyecto. Esta etapa parte de los resultados obtenidos en la fase de análisis y sirve como base para la posterior implementación del sistema que se pretende desarrollar. Se incluye el diseño del sistema en términos generales con la justificación de la arquitectura seleccionada ası́ como el diagrama de arquitectura del sistema, diagrama de clases, diagrama entidad-relación, diagramas de secuencia y patrones de diseño utilizados. Además de esto, se incluyen las tecnologı́as seleccionadas para la implementación del sistema, un análisis detallado de los modelos criptográficos que se pretenden utilizar y el diseño de las interfaces de usuario del sistema..
Documento similar