Desarrollo y evaluación de riesgos de privacidad en una App de rastreo

Desarrollo y Evaluaci´on de Riesgos de Privacidad en una App de Rastreo. Mar´ıa Ruiz Molina Tutores Mercedes Mart´ınez Gonz´alez Amador Aparicio de la Fuente 1 UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Agradecimientos En primer lugar, quiero agradecer a mis tutores Mercedes Mart´ınez Gonz´alez y Amador Aparicio de la Fuente, el hecho de haberme elegido para realizar este proyecto, as´ı como por su paciencia y tiempo dedicados a la correcci´on y orientaci´on del mismo. Tambi´en incluyo al profesor Juli´an Arroyo ´ Alvarez por sus aportaciones a este trabajo. En segundo lugar quiero dar las gracias a toda mi familia, en especial a mi madre, que ha estado siempre ah´ı, en momentos de risas y llantos; a mis t´ıos y a mis primos. Todos me han apoyado a lo largo de la carrera, y ayudado a tomar las mejores decisiones en los momentos m´as dif´ıciles. No me olvido de los que ya no est´an; mi padre, mi abuela, mi t´ıa y mi t´ıa abuela. Desde donde est´en espero que se sientan orgullosos. En tercer lugar quiero dar las gracias a la Realeza Agastre, mis amigos de la facultad y de fuera de ella, en especial a Dani, Willy, Christopher, Susana y Clara. Todos ellos han contribuido a que estos a˜nos hayan sido incre´ıblemente buenos. Y por supuesto y en especial, a Juan, que iniciamos este camino juntos aquel primer d´ıa de clase y lo hemos acabado a la vez, trabajando codo con codo, echando horas diarias, afrontando unidos los momentos complicados, y conoci´endonos m´as y m´as. Gracias por haber hecho de este recorrido algo memorable. Escuela de Ingenier´ıa Inform´atica 2Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Resumen El trabajo aqu´ı plasmado consiste en el dise˜no y desarrollo, junto a Juan Vel´azquez Garc´ıa, de una aplicaci´on de rastreo de contactos, sobre la cual se elabora una evaluaci´on de riesgos e impacto en la privacidad del usuario usando la herramienta PIA de la Commission Nationale de l’Informatique et des Libert´es o CNIL (Francia), la cual implementa el Reglamento General de Protecci´on de Datos. Para ello, primeramente se realiza una profunda investigaci´on sobre las aproximaciones para el desarrollo de aplicaciones de rastreo de contactos, la normativa entorno a ello y algunos casos existentes. Tambi´en qu´e caracter´ısticas poseen y los datos que obligatoriamente deben tratar. Una vez estudiado el Estado del Arte, se elicitan aquellos requisitos necesarios para realizar una aplicaci´on de rastreo de contactos. Posteriormente, se realiza un estudio sobre el tipo de protocolos y paradigmas existentes en este ´area, se elige aquel que mejor se adapte al an´alisis de requisitos previamente realizado, y con ello se plantea y dise˜na la aplicaci´on. Durante todo este proceso se tiene en mente, siempre en primera instancia, la privacidad de los datos del usuario. Tras ello, se ha desarrollado un prototipo de la aplicaci´on empleando la t´ecnica Pair Programming. Esto abarca tanto el desarrollo de la aplicaci´on cliente como del servidor. Tambi´en se logran los distintos tipos de comunicaciones existentes entre ellos, Bluetooth, TCP y UDP. Se comentan los distintos problemas que pudieran haber surgido durante el desarrollo de la aplicaci´on y los cambios que se han tenido que realizar para poder ajustar el proyecto a la planificaci´on sin grandes repercusiones. Para demostrar el correcto funcionamiento de todo ello, se ha elaborado una lista de Casos de Prueba, clasificados en Caja Negra o Caja Blanca, Funcionales o No Funcionales, y aspecto concreto a tratar (seguridad, disponibilidad, interacci´on y comunicaci´on). Se describe el procedimiento llevado a cabo para el ´exito de cada uno de ellos, as´ı como los distintos problemas que hayan podido surgir durante las pruebas y c´omo se solventaron. Una vez probado el correcto funcionamiento de la aplicaci´on, se realiza una evaluaci´on de riesgos e impacto en la privacidad. Para ello, se especifica primero el Estado del Arte, los distintos aspectos del Reglamento General de Protecci´on de Datos a tratar en dicha evaluaci´on, as´ı como una presentaci´on de la herramienta PIA, de la Commission Nationale de l’Informatique et des Libert´es (CNIL), la cual ser´a empleada para efectuar el an´alisis de riesgos y privacidad a la aplicaci´on. Detectadas las principales amenazas, se elabora una serie de salvaguardas con el fin de disminuir, para cada una, el riesgo de que esta se produzca. Finalmente, se elabora una serie de conclusiones, as´ı como una comparativa de este tipo de aplicaciones, sus vulnerabilidades y ventajas, frente a otras propuestas que han ido surgiendo a lo largo del a˜no 2021 en la Uni´on Europea, territorio bajo la normativa del RGPD. Escuela de Ingenier´ıa Inform´atica 3Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Abstract This project aims to study some privacy standards, specifically, the proposals from the administrative authority, Commission Nationale de l’Informatique et des Libert´es (CNIL). Likewise, the current state of affairs regarding mobile contact-tracing apps’ privacy risks will be reviewed. A risk evaluation will be proposed as a conclusion from the aforementioned standards. Therefore, a prototyped app based on the current Covid contact-tracing applications will be developed, together with Juan Vel´azquez Garc´ıa, and the previously-established proposal will be applied to it. Finally, a series of conclusions from this study will be presented in further detail. Escuela de Ingenier´ıa Inform´atica 4Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina ´ Indice 1. Introducci´on 12 1.1. Contexto ............................................... 12 1.2. Motivaci´on .............................................. 12 1.3. Planteamiento del Problema ..................................... 13 1.3.1. Objetivos ........................................... 13 2. Planificaci´on y Metodolog´ıa 14 2.1. Metodolog´ıa .............................................. 14 2.2. Planificaci´on ............................................. 15 2.3. Camino cr´ıtico ............................................ 16 2.4. Presupuesto .............................................. 18 2.5. Seguimiento .............................................. 19 3. An´alisis de la aplicaci´on 21 3.1. Requisitos no funcionales .................................... 21 3.1.1. Requisitos de seguridad ................................. 21 3.1.2. Requisitos de privacidad ................................. 23 3.1.3. Requisitos que se aplican ´unicamente cuando la aplicaci´on env´ıa al servidor una lista de contactos .......................................... 26 3.1.4. Requisitos que se aplican ´unicamente cuando la aplicaci´on env´ıa al servidor una lista de sus propios identificadores ................................ 26 3.1.5. Requisitos de usabilidad ................................... 27 3.2. Requisitos Funcionales ...................................... 27 3.2.1. De cara al usuario ..................................... 28 3.2.2. De cara a otros dispositivos ............................... 28 3.2.3. De cara a la propia aplicaci´on ................................ 28 3.3. Requisitos de Informaci´on ...................................... 28 3.4. Base de Datos - Modelo conceptual ................................. 29 3.5. Elecci´on de paradigma de protocolos ................................ 30 3.6. Base de Datos - Modelo l´ogico ................................... 31 3.7. Modelo de intercambio de datos ................................... 33 3.8. Desarrollo de los casos de uso .................................... 33 3.8.1. UC-01 Enviar diagn´ostico .................................. 35 3.8.2. UC-02 Cambiar idioma ................................... 35 3.8.3. UC-03 Comunicar semillas asociadas a IDs infectados .................. 36 3.8.4. UC-04 Comprobar riesgo de contagio ............................ 36 Escuela de Ingenier´ıa Inform´atica 5Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 3.8.5. UC-05 Enviar diagn´ostico falso ............................... 37 3.8.6. UC-06 Recibir ID ....................................... 37 3.8.7. UC-07 Enviar ID ....................................... 38 4. Dise˜no de la aplicaci´on 39 4.1. Estado del Arte: Protocolos ..................................... 39 4.1.1. Decentralized Privacy-Preserving Proximity Tracing (DP-3T) .............. 39 4.1.2. (Google/Apple) Exposure Notification (GAEN) system ................. 40 4.1.3. Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT/PEPP) ....... 40 4.1.4. BlueTrace ........................................... 41 4.1.5. Otros ............................................. 42 4.2. Elecci´on del protocolo ........................................ 43 4.3. Imprevistos respecto al protocolo elegido y consecuencias .................... 43 4.4. Implementaci´on de los requisitos acorde a nuestra versi´on de DP-3T .............. 48 4.4.1. Tecnolog´ıas utilizadas .................................... 54 4.5. Implementaci´on de los Requisitos de Usabilidad .......................... 54 4.6. Dise˜no de la Interfaz e Implementaci´on de los Requisitos ..................... 55 4.6.1. Pantalla Principal ...................................... 56 4.6.2. Pantalla de Informaci´on ................................... 59 4.6.3. Pantalla de Ajustes de Idioma ................................ 59 4.7. Diagrama de paquetes ........................................ 60 4.8. Implementaci´on de la aplicaci´on ................................... 65 4.8.1. Implementaci´on final de la interfaz ............................. 65 4.8.2. Conexiones de red TCP ................................... 67 4.8.3. Conexiones de red UDP ................................... 67 4.8.4. Decisi´on sobre Bluetooth .................................. 67 4.8.5. Cifrado de los datos ..................................... 68 4.8.6. Adaptaciones realizadas cara al prototipo ......................... 69 5. Casos de prueba 71 5.1. Pruebas de caja negra ........................................ 71 5.1.1. Intercambiar un ID entre dos dispositivos v´ıa BT en rango ............... 71 5.1.2. Intercambiar un ID entre dos dispositivos v´ıa BT en el l´ımite del rango ........ 72 5.1.3. Intercambiar un ID entre dos dispositivos v´ıa BT fuera de rango ............ 73 5.1.4. Intercambiar un ID entre dos dispositivos v´ıa BT y desconectarse justo en el momento del env´ıo ........................................... 73 Escuela de Ingenier´ıa Inform´atica 6Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.1.5. Intercambiar un ID entre dos dispositivos v´ıa BT y desconectarse justo 1 segundo antes del momento del env´ıo .................................... 73 5.1.6. Intercambiar un ID entre dos dispositivos v´ıa BT y desconectarse justo 1 segundo despu´es del momento del env´ıo ............................... 74 5.1.7. Uso de la aplicaci´on sin conexi´on a BT ........................... 74 5.1.8. Env´ıo de un c´odigo correcto al servidor. (C´odigo correcto: el pedido por la aplicaci´on, otorgado por la autoridad sanitaria.) ............................ 75 5.1.9. Env´ıo de un c´odigo incorrecto al servidor ......................... 76 5.1.10. Env´ıo de diagn´ostico sin fecha ................................ 77 5.1.11. Env´ıo de diagn´ostico sin inserci´on de c´odigo ........................ 77 5.1.12. Env´ıo de c´odigo con menos de 12 cifras .......................... 78 5.1.13. Env´ıo de c´odigo con m´as de 12 cifras ............................ 79 5.1.14. Env´ıo de c´odigo con caracteres no num´ericos ....................... 79 5.1.15. Env´ıo con fecha anterior a 14 d´ıas ............................. 80 5.1.16. Env´ıo con fecha posterior a 14 d´ıas ............................. 81 5.1.17. Multicast de IDs infectados desde el servidor a los clientes ................ 81 5.1.18. Uso de la aplicaci´on sin conexi´on a Internet (y sin recepci´on de multicast) ....... 82 5.1.19. Recepci´on por multicast de un ID infectado que se encuentra en la base de datos local 84 5.1.20. Recepci´on por multicast de IDs infectados y ninguno se encuentra en la base de datos local .............................................. 85 5.1.21. Recepci´on por multicast de IDs infectados y ninguno se encuentra en la base de datos local, pero el ID es un n´umero por encima de uno almacenado ............. 86 5.1.22. Recepci´on por multicast de IDs infectados y ninguno se encuentra en la base de datos local, pero el ID es un n´umero por debajo de uno almacenado .............. 86 5.1.23. Recepci´on por multicast de IDs infectados y no se posee ning´un ID en la base de datos local con los que comparar ................................. 87 5.1.24. Env´ıo del multicast pero sin recepci´on (clientes inactivos) ................ 87 5.1.25. Escucha, por parte del cliente, de multicast pero sin env´ıo (servidor inactivo) ..... 87 5.1.26. Cambio de idioma ...................................... 88 5.2. Pruebas de caja blanca ........................................ 89 5.2.1. Escucha del canal de conexi´on en el momento de env´ıo de un c´odigo con los IDs al servidor ............................................ 89 5.2.2. Escucha del canal de conexi´on en el momento de env´ıo de un c´odigo incorrecto al servidor 90 5.2.3. Escucha del canal de conexi´on en el momento del env´ıo del multicast .......... 90 5.2.4. Barrido de puertos de la m´aquina cliente ......................... 91 5.2.5. Barrido de puertos de la m´aquina servidor ......................... 92 5.2.6. Ataque DDoS ......................................... 94 5.2.7. Inyecci´on de c´odigo desde la aplicaci´on cliente ....................... 96 Escuela de Ingenier´ıa Inform´atica 7Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 6. An´alisis de riesgos de seguridad y privacidad 97 6.1. Estado del arte: Seguridad y Privacidad .............................. 97 6.1.1. Reglamento General de Protecci´on de Datos ........................ 97 6.1.2. Delegado de Protecci´on de Datos ..............................100 6.1.3. Seguridad de los datos ....................................100 6.1.4. Evaluaci´on de Impacto de Protecci´on de Datos ......................100 6.1.5. Uni´on Europea y aplicaciones de rastreo de contactos ..................100 6.1.6. Uni´on Europea y estado COVID ..............................102 6.1.7. Commission Nationale de l’Informatique et des Libert´es .................105 6.1.8. Herramienta PIA .......................................108 6.2. PIA: Evaluaci´on de Impacto de la Privacidad ...........................110 6.2.1. Creaci´on del proyecto ....................................110 6.2.2. Contexto ...........................................114 6.2.3. Principios Fundamentales ..................................116 6.2.4. Riesgos ............................................119 6.2.5. Validaci´on ...........................................123 6.3. PIA: Proceso de la Evaluaci´on ...................................126 6.3.1. Contexto ...........................................126 6.3.2. Principios Fundamentales ..................................126 6.3.3. Riesgos ............................................126 6.3.4. Validaci´on ...........................................127 6.3.5. Conclusiones de la evaluaci´on ................................149 6.4. Comparativa de resultados con otras alternativas europeas ....................150 7. Conclusiones y Trabajo Futuro 152 Bibliograf´ıa 169 Escuela de Ingenier´ıa Inform´atica 8Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina ´ Indice de figuras 1. Planificaci´on inicial .......................................... 15 2. Planificaci´on final ........................................... 19 3. Modelo conceptual .......................................... 30 4. Modelo l´ogico Cliente ........................................ 31 5. Modelo l´ogico Servidor ........................................ 32 6. Modelo de intercambio de datos ................................... 33 7. Diagrama de casos de uso ...................................... 34 8. Esquema de generaci´on de identificadores ef´ımeros ........................ 39 9. Solicitud a cumplimentar para tener acceso a la API ....................... 43 10. Documentaci´on requerida ...................................... 44 11. Modelo de datos de la base de datos de los clientes ........................ 51 12. Modelo de datos de la base de datos del servidor ......................... 53 13. Men´u de navegaci´on ......................................... 55 14. Pantalla Principal .......................................... 56 15. Bot´on Comunica tu contagio .................................... 57 16. Confirmaci´on del env´ıo ........................................ 57 17. Simulaci´on de los distintos tipos de daltonismo .......................... 58 18. Pantalla de informaci´on ....................................... 59 19. Pantalla de idiomas .......................................... 59 20. Diagrama de Paquetes Aplicaci´on Cliente JAVA .......................... 61 21. Diagrama de Paquetes Aplicaci´on Cliente RES .......................... 62 22. Diagrama de Paquetes Aplicaci´on Servidor ............................. 63 23. Pantalla de inicio. Colores de la aplicaci´on ............................. 65 24. Pantalla de inicio. Protanopia .................................... 66 25. Pantalla de inicio. Deuteranopia .................................. 66 26. Pantalla de inicio. Tritanopia .................................... 67 27. Resultado de entrop´ıas ........................................ 68 28. Intercambio de ID entre dispositivos ................................ 72 29. Solicitud para activar Bluetooth .................................. 74 30. Aplicaci´on con contagio ....................................... 76 31. Aviso sobre c´odigo incompleto .................................... 77 32. Aviso sobre c´odigo incompleto .................................... 78 33. L´ımite anterior de aceptaci´on de fechas ............................... 80 34. L´ımite posterior de aceptaci´on de fechas .............................. 81 Escuela de Ingenier´ıa Inform´atica 9Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina •Investigaci´on sobre la generaci´on de identificadores ef´ımeros •Dise˜no del protocolo. •Dise˜no de la base de datos del cliente. •Dise˜no de la base de datos del servidor. Dise˜no de la interfaz de usuario. Tambi´en se considera su programaci´on. Desde la semana 15 a la semana 20. Programaci´on de la aplicaci´on cliente. Desde la semana 20 a la semana 28. Programaci´on de la aplicaci´on servidor. Desde la semana 24 a la semana 28. Dise˜no de los casos de prueba. Desde la semana 24 a la semana 28. Realizaci´on y redacci´on de los casos de prueba. Desde la semana 28 a la semana 31. An´alisis con la herramienta PILAR. Desde la semana 30 a la semana 35, teniendo un margen de 3 semanas m´as hasta el momento de cierre de actas. An´alisis con la herramienta PIA. Desde la semana 30 a la semana 42, teniendo un margen de 3 semanas m´as hasta el momento de cierre de actas. 2.3. Camino cr´ıtico Dentro del proyecto, hay etapas que pueden provocar un desplazamiento temporal importante en las subsiguientes. Esto puede deberse a la necesidad que tienen unas de que otras hayan sido acabadas del todo. En concreto nos encontramos con las siguientes etapas: Elicitaci´on de requisitos. Esta primera fase es necesaria para poder empezar a elaborar las necesidades de la aplicaci´on central del proyecto, la cual es necesaria para poder llevar a cabo el an´alisis de riesgos y privacidad. Debe ser previa al an´alisis, donde se tendr´an en cuenta las necesidades aqu´ı encontradas. An´alisis. Al igual que la anterior, esta etapa es necesaria para poder comenzar a dar forma a lo que ser´a la aplicaci´on de rastreo de contactos. Dise˜no de la aplicaci´on. Del mismo modo que las dos fases anteriores, es necesario que la tarea de dise˜no se realice previamente al desarrollo. De este modo, un retraso en esta parte afectar´ıa a la programaci´on de la aplicaci´on y con ello a las tareas que dependen de un prototipo funcional. Programaci´on de la aplicaci´on cliente. Debido a que las etapas que la siguen necesitan probarla y analizarla, es necesario que la aplicaci´on cliente funcione correctamente en todos los aspectos. Programaci´on de la aplicaci´on servidor. Del mismo modo, debido a que las tareas que la siguen necesitan probarla y analizarla, es necesario que el servidor est´e terminado y funcionando para poder continuar. La tarea de Investigaci´on y recolecci´on de Informaci´on Inicial, si bien una parte ha de llevarse a cabo al principio del proyecto para poder tener un mejor enfoque, parte de la investigaci´on se puede llevar a cabo de manera paralela a la Elicitaci´on de Requisitos, e incluso en momentos m´as avanzados del proyecto, pues al tratarse de un campo tan nuevo, es frecuente que surjan nuevas fuentes de informaci´on que ayuden a redondear aspectos concretos. Escuela de Ingenier´ıa Inform´atica 16 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Por otro lado, el Dise˜no de la interfaz de usuario es un apartado que puede posponerse, pues no hace falta un dise˜no atractivo para poder comprobar el correcto funcionamiento de la aplicaci´on, as´ı como analizar c´omo trata los datos que recolecta. El Dise˜no de los casos de prueba puede elaborarse en parte de manera paralela al An´alisis con la herramienta PIA. Si bien hay ciertas funcionalidades que deber´an probarse antes de realizar el an´alisis para corroborar que se va a evaluar la aplicaci´on tal y como se ha dise˜nado, la evaluaci´on de otros casos de prueba no necesita ser previa al an´alisis de riesgos y privacidad. Estos pueden ser aquellos relacionados con la interacci´on o disponibilidad. Escuela de Ingenier´ıa Inform´atica 17 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 2.4. Presupuesto Se procede a presentar un an´alisis del coste monetario del proyecto. Para realizar el c´alculo del tiempo empleado por ambos alumnos en el desarrollo del proyecto, se parte del total de cr´editos de un Trabajo de Fin de Grado de Ingenier´ıa Inform´atica. Esto equivale a 12 ECTS, y dado que 1 ECT equivale a 25 horas de trabajo, se obtiene un total de 300 horas por proyecto. Dado que se engloban dos TFG, el total ser´ıa de 600 horas, muchas de ellas elaboradas realmente en paralelo en el momento inicial de creaci´on de la aplicaci´on (la parte com´un). Una vez esta serie de tareas comunes es terminada, las horas restantes se desarrollar´ıan de manera individual por cada alumno. As´ı, se va a calcular en concreto para este proyecto, teniendo en cuenta las horas llevadas a cabo en la parte com´un junto a las del compa˜nero Juan Vel´azquez Garc´ıa, y las de la parte individual ´unicamente las respectivas a las de mi parte correspondiente. Considerando en la planificaci´on que la parte com´un llevar´a de la semana 1 a la 30 y la parte individual de la 30 a la 42, equivale a una proporci´on de 30 semanas sobre 42 para la parte com´un, esto es aproximadamente un 70 % del proyecto y un 30 % para la parte individual. De este modo, de un total de 600 horas suma de ambos esfuerzos, 600 * 0.7 = 420 horas. Sin embargo esta primera parte, dado que fue iniciada apenas comenz´o el curso escolar, el total de horas es superior, 450 para cada alumno y haciendo un total de 900 * 0.7 = 630 horas (315 para cada alumno). Por otro lado, de 300 horas que lleva a un ´unico alumno un TFG, 300 * 0.3 = 90 horas. En total, el esfuerzo entre ambas partes ser´a de 720 horas, teniendo en cuenta que las correspondientes a la primera parte se dividen entre dos alumnos. Se ha utilizado la p´agina de la Secci´on Sindical CGT Sopra Steria, https://cgtsoprasteria.org/blog/ rangos-salariales-anuales-tic/, para obtener los salarios. Por ello, se considera un salario promedio para programador junior (grupo E-I) de 14800 euros al a˜no por 7.5 horas diarias, una para cada alumno, se obtiene, a 6.51 euros la hora[20], para la primera alumna 6.51 * 405 = 2636.55 euros y para el segundo alumno, 6.51 * 315 = 2050.65 euros. Por otro lado, el trabajo de gu´ıa, correcci´on y resoluci´on de problemas llevado a cabo por los tutores del proyecto, se calcular´a empleando un salario medio de programador senior (grupo D-I). Esta cifra equivale a 16531 euros al a˜no, que se traduce a 7.27 euros la hora.[20] Entre el tiempo empleado en reuniones, lecturas y correcciones de la memoria, as´ı como resoluci´on de dudas, se calculan unas 60 horas en total de dedicaci´on. Esto hace un total de 60 * 7.27= 436.2 euros * 3 tutores en total = 1308.6 euros Para una mejor visualizaci´on de los costes, estos pueden consultarse en la siguiente tabla: Personal Coste €/Hora Horas Total € Alumna Mar´ıa Ruiz Molina 6.51 405 2636.55 Alumno Juan Vel´azquez Garc´ıa 6.51 315 *para este proyecto 2050.65 Tutora Mercedes Mart´ınez Gonz´alez 7.27 60 436.20 Tutor Amador Aparicio de la Fuente 7.27 60 436.20 Tutor Juli´an Arroyo ´ Alvarez 7.27 60 436.20 Tabla 1: Costes por personal del proyecto En total, el presupuesto por personal del proyecto ser´ıa de 5995.80 euros. Escuela de Ingenier´ıa Inform´atica 18 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 2.5. Seguimiento Debido a un imprevisto a la hora de hacer uso del protocolo de rastreo de contactos, hubo que ajustar los tiempos de la planificaci´on. En concreto, hubo que desarrollar un protocolo desde cero, por lo que los tiempos de programaci´on de la aplicaci´on tuvieron que aumentarse. Esto llev´o a un desplazamiento de las actividades posteriores a esta y tambi´en a una disminuci´on del tiempo disponible para realizarlas. Tras esto, el diagrama de Gantt queda as´ı: Figura 2: Planificaci´on final La planificaci´on final queda distribuida de la siguiente manera: Investigaci´on y recolecci´on de Informaci´on Inicial. Desde la semana 1 a la semana 8. Se subdivide en: •Investigaci´on de protocolos de rastreo de contactos. •Investigaci´on de la aplicaci´on Radar Covid. •Investigaci´on sobre est´andares de privacidad. •Investigaci´on sobre el protocolo DP-3T. Elicitaci´on de requisitos. Desde la semana 2 a la semana 10. An´alisis. Desde la semana 10 a la semana 15. Se subdivide en: •Investigaci´on sobre los tipos de paradigmas en aplicaciones de rastreo de contactos. •Caso de uso. •Actores. •Diagrama de casos de uso. •Modelo de intercambio datos. Dise˜no de la aplicaci´on. Desde la semana 10 a la semana 16. Se subdivide en: Escuela de Ingenier´ıa Inform´atica 19 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina •Investigaci´on sobre la generaci´on de identificadores ef´ımeros. •Dise˜no del protocolo. •Dise˜no de la base de datos del cliente. •Dise˜no de la base de datos del servidor. Dise˜no de la interfaz de usuario. Tambi´en se considera su programaci´on. Desde la semana 15 a la semana 20. Programaci´on de la aplicaci´on cliente. Desde la semana 20 a la semana 31. Programaci´on de la aplicaci´on servidor. Desde la semana 24 a la semana 31. Dise˜no de los casos de prueba. Desde la semana 24 a la semana 28. Realizaci´on y redacci´on de los casos de prueba. Desde la semana 31 a la semana 34. An´alisis con la herramienta PILAR. Desde la semana 33 a la semana 38. An´alisis con la herramienta PIA. Desde la semana 33 a la semana 44. Debido a este contratiempo, el camino cr´ıtico se vio afectado, y esto retras´o en parte a las tareas de Programaci´on de la aplicaci´on cliente,Programaci´on de la aplicaci´on servidor,Dise˜no de los casos de prueba yAn´alisis con la herramienta PIA. Afortunadamente, se previ´o cierto margen de finalizaci´on, por lo que este problema pudo ser afrontado, apoyado adem´as por la metodolog´ıa empleada, Pair Programming, la cual admite que puedan ocurrir contratiempos como el sucedido. Escuela de Ingenier´ıa Inform´atica 20 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 3. An´alisis de la aplicaci´on En este trabajo se ha llevado a cabo el desarrollo de una aplicaci´on de rastreo de contactos, la cual interacciona con: Usuarios. Los cuales instalan una aplicaci´on cliente en sus dispositivos m´oviles. Autoridad Sanitaria. La cual gestiona un servidor. Dado que aqu´ı se ha desarrollado un prototipo, se simulan las funcionalidades b´asicas de un caso real. Para comenzar el proyecto, primeramente se realiz´o una b´usqueda de informaci´on sobre aplicaciones de rastreo de contactos existentes en el mercado, como son SwissCovid,COVIDSafe,Smittestopp oRadar COVID. El fin de dicho estudio ha sido comprender las necesidades y funcionamiento primordiales para poder deducir y aplicar los requisitos esenciales. En especial se toma en consideraci´on aquellos relacionados con la privacidad del usuario debido al car´acter m´edico y sensible de los datos. Estudios como el realizado por Paul-Olivier Dehaye y Joel Reardon [26] y art´ıculos como el escrito por Patrick Howell O’Neil [55], nos marcan que hay pa´ıses, en este caso Suiza y Noruega, que consideran la privacidad como algo indispensable, hasta el punto de retirar del mercado sus aplicaciones de rastreo de contactos. Debido al especial hincapi´e en dicha cuesti´on, estos se han tomado como gu´ıas esenciales para concluir en la fuerte necesidad de otorgar a la privacidad la merecida atenci´on. A ra´ız de ello, se decidi´o tomar como referentes a diversos organismos legislativos que dictaminan requisitos de privacidad sobre este tipo de aplicaciones. De esta investigaci´on hemos obtenido como resultado la siguiente lista de requisitos para la aplicaci´on. Estos se clasifican en funcionales, no funcionales, donde se incluyen los aspectos de privacidad. 3.1. Requisitos no funcionales 1. Aplicaci´on m´ovil. Al ser una aplicaci´on en la que se requiere recopilar con qui´en se tiene contacto, esta ha de ser port´atil y por tanto debe instalarse en un tel´efono m´ovil, ya que es un objeto que llevamos siempre encima. 2. Anonimizaci´on de identificadores. Con el fin de preservar la privacidad del usuario, este ser´a identificado de manera an´onima. 3. El servidor debe avisar ´unicamente de los contagios activos. Se considera contagio activo aquel cuya fecha es menor a la fecha de recepci´on en el servidor. Esto es con el fin de evitar almacenar identificadores asociados a individuos ya recuperados de la enfermedad. 3.1.1. Requisitos de seguridad 1. Control de entrada de datos. Se supervisar´an las entradas de datos de la aplicaci´on con el fin de evitar inyecciones de c´odigo. 2. ((Un mecanismo debe verificar el estado de los usuarios que notifican en la aplicaci´on su condici´on de positivos en infecci´on. [...] Por ejemplo, facilitando un c´odigo de un solo uso vinculado con un laboratorio de pruebas o a un profesional de atenci´on sanitaria. Si no se puede obtener confirmaci´on de forma segura, no debe procederse al tratamiento de datos)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo Directrices 04/2020 sobre el uso de datos Escuela de Ingenier´ıa Inform´atica 21 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-1, 2020) [13] 3. ((Los datos enviados al servidor central han de transmitirse a trav´es de un canal seguro. El uso de servicios de notificaci´on prestados por proveedores de plataformas de sistema operativo debe evaluarse cuidadosamente y no debe dar lugar a la divulgaci´on de ning´un dato a terceros)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-2, 2020) 4. ((Las solicitudes no deben ser vulnerables a la manipulaci´on por parte de un usuario malintencionado)).Para evitar falsos positivos. (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-3, 2020) 5. Uso de t´ecnicas criptogr´aficas. ((Deben aplicarse las t´ecnica criptogr´aficas m´as avanzadas para asegurar los intercambios entre la aplicaci´on y el servidor, y entre aplicaciones, y, como regla general, para proteger la informaci´on almacenada en las aplicaciones y en el servidor. Entre las t´ecnicas que pueden utilizarse figuran, por ejemplo, las siguientes: cifrado sim´etrico y asim´etrico, funciones hash, prueba privada de pertenencia (private membership test, PMT), intersecci´on privada de conjuntos adoptadas 19 (private set intersection, PSI), filtros Bloom, recuperaci´on de informaci´on privada, cifrado homom´orfico, etc.)) (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-4, 2020) 6. El servidor central no debe conservar los identificadores de conexi´on a la red de ning´un usuario. ((El servidor central no debe conservar los identificadores de conexi´on a la red (p. ej., las direcciones IP) de ning´un usuario, incluidos los que han sido diagnosticados positivamente y que han transmitido su historial de contactos o sus propios identificadores)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-5, 2020) 7. El servidor debe autenticar la aplicaci´on y viceversa. ((Para evitar la suplantaci´on o la creaci´on de falsos usuarios, el servidor debe autenticar la aplicaci´on)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-6, 2020) 8. ((La aplicaci´on debe autenticar el servidor central)).(European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-7, 2020) 9. ((Las funcionalidades del servidor deben estar protegidas frente a ataques de repetici´on)). Para evitar suplantaci´on de identidad y ataques de denegaci´on de servicio. (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-8, 2020) 10. ((La informaci´on transmitida por el servidor central debe estar firmada para autenticar su origen e integridad)).Esto se logra mediante la criptograf´ıa asim´etrica. (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-9, 2020) 11. Administraci´on de acceso al servidor. ((El acceso a todos los datos almacenados en el servidor central y que no est´en a disposici´on del p´ublico debe circunscribirse a las personas autorizadas)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-10, 2020) Escuela de Ingenier´ıa Inform´atica 22 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 12. Administraci´on de permisos de la aplicaci´on. ((El gestor de permisos del dispositivo en el nivel del sistema operativo solo debe solicitar los permisos necesarios para acceder a los m´odulos de comunicaci´on y utilizarlos cuando resulte necesario, para almacenar los datos en el equipo terminal y para intercambiar informaci´on con el servidor central)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-11, 2020) 3.1.2. Requisitos de privacidad 1. Minimalidad de los datos.((Los intercambios de datos deben respetar la privacidad de los usuarios (y, en particular, el principio de minimizaci´on de datos))). Para respetar la privacidad de los datos, la aplicaci´on se limitar´a a trabajar con datos que no permitan averiguar la identidad del usuario, tales que los identificadores ef´ımeros o el intercambio de semillas generadoras con el servidor para que no viajen los identificadores por la red. (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-1, 2020) Datos que se almacenan. •La informaci´on anonimizada que identifica al usuario. •La informaci´on de los contactos cercanos. •Datos referentes a permisos de la aplicaci´on. ◦android.permission.INTERNET: permite comunicarse con el backend del servidor. ◦android.permission.ACCESS NETWORK STATE: permite a la aplicaci´on saber si el dispositivo est´a conectado a internet. ◦android.permission.BLUETOOTH: usado para poder comunicarse entre dispositivos m´oviles. [42] ◦android.permission.REQUEST IGNORE BATTERY OPTIMIZATIONS: permite que la aplicaci´on se ejecute en cualquier momento en segundo plano, permitiendo que las sincronizaciones entre la aplicaci´on y el servidor sucedan en los momentos oportunos. Datos que se env´ıan •De cliente a servidor de la entidad sanitaria. ◦Prueba de haber dado positivo en un diagn´ostico. ◦De manera opcional la fecha de s´ıntomas o de prueba diagn´ostica positiva. ◦Informaci´on anonimizada que representa al usuario. De esta forma se respeta la privacidad del usuario, pues no se puede asociar dicho positivo a ning´un identificador. ◦Tr´afico de paquetes disuasorios para evitar que agentes externos identifiquen usuarios infectados, pues de otro modo la comunicaci´on cliente direcci´on servidor solo se da en caso de positivo. •De servidor a cliente. ◦Informaci´on anonimizada de usuarios infectados. Esta la recibe la aplicaci´on cliente y puede contrastar si ha estado en contacto o no con alg´un positivo. En caso de coincidir se avisa de posible contacto de riesgo. Estas se env´ıan mediante broadcast a todos los clientes para evitar distinciones entre usuarios que pudieran afectar a su privacidad. •Entre clientes. ◦Informaci´on que identifique que han estado en contacto. 2. Evitar que la aplicaci´on identifique o rastree a los usuarios. ((La aplicaci´on no puede permitir identificar directamente a los usuarios al utilizar la aplicaci´on)). (European Data Protection Board, Escuela de Ingenier´ıa Inform´atica 23 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-2, 2020) 3. ((La aplicaci´on no ha de permitir que se rastreen los movimientos de los usuarios)).(European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-3, 2020) 4. ((El uso de la aplicaci´on no debe permitir que los usuarios obtengan informaci´on de otros usuarios (y, en particular, que sepan si son o no portadores del virus))).(European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-4, 2020) 5. La confianza en el servidor debe ser limitada. ((La gesti´on del servidor central debe seguir normas de gobernanza claramente definidas e incluir todas las medidas necesarias para garantizar su seguridad. La ubicaci´on del servidor central debe permitir una supervisi´on eficaz por parte de la autoridad supervisora competente)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-5, 2020) 6. ((Ha de llevarse acabo una evaluaci´on de impacto relativa a la protecci´on de datos, que deber´ıa ponerse a disposici´on del p´ublico)).(European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-6, 2020) 7. ((La aplicaci´on solo debe revelar al usuario si ha estado expuesto al virus y, en la medida de lo posible, sin facilitar informaci´on sobre otros usuarios, el n´umero de veces y las fechas de la exposici´on)).(European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-7, 2020) 8. ((La informaci´on transmitida por la aplicaci´on no debe permitir a los usuarios identificar a los usuarios portadores del virus ni conocer sus movimientos)).(European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-8, 2020) 9. Preservar la identidad de los usuarios frente a las autoridades sanitarias. ((La informaci´on transmitida por la aplicaci´on no debe permitir a las autoridades sanitarias identificar a los usuarios que pueden estar expuestos sin el consentimiento de estos)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-9, 2020) 10. ((Las solicitudes cursadas por la aplicaci´on al servidor central no deben revelar ninguna informaci´on sobre el portador del virus.)) (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-10, 2020) 11. ((Las solicitudes cursadas por la aplicaci´on al servidor central no deben revelar ninguna informaci´on innecesaria sobre el usuario, excepto, posiblemente —y solo cuando resulte necesario—, sus identificadores seud´onimos y su lista de contactos)).(European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-11, 2020) 12. ((Impedir ataques de enlace)).Para evitar el robo de datos de los usuarios. (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-12, 2020) Escuela de Ingenier´ıa Inform´atica 24 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 13. ((Los usuarios han de poder ejercer sus derechos a trav´es de la aplicaci´on)).(European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-13, 2020) 14. ((La supresi´on de la aplicaci´on debe entra˜nar la eliminaci´on de todos los datos recogidos a nivel local)).Esto incluir´ıa la lista de identificadores de los contactos, as´ı como los identificadores propios y las semillas recibidas por el servidor al hacer broadcast. (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-14, 2020) 15. ((La aplicaci´on solo puede recoger datos transmitidos por instancias de la aplicaci´on o de aplicaciones interoperables equivalentes. No pueden recogerse datos sobre otras aplicaciones ni otros dispositivos de comunicaci´on de proximidad)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-15, 2020) 16. Implementaci´on de servidores proxy. ((Para evitar la reidentificaci´on por parte del servidor central, deben implementarse servidores proxy. La finalidad de estos servidores no colusores es combinar los identificadores de varios usuarios (tanto los de los portadores del virus como los enviados por los solicitantes) antes de compartirlos con el servidor central, para evitar que este conozca los identificadores de los usuarios (como las direcciones IP))). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-16, 2020) 17. ((La aplicaci´on y el servidor deben desarrollarse y configurarse cuidadosamente con el fin de que no recojan datos innecesarios. (P. ej., no debe incluirse ning´un identificador en los registros del servidor, etc.) y de evitar el uso de SDK de terceros que recojan datos para otros fines)). (European Data Protection Board, Directrices 04/2020 sobre el uso de datos de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo PRIV-17, 2020) 18. Salvaguardar la privacidad de la lista de contactos de cara al servidor. El servidor no invade la lista de contactos de los clientes. 19. Evitar la identificaci´on de los usuarios a partir de la prueba de diagn´ostico positivo. Esto se evita haciendo que dicha prueba sea solamente asociada al identificador an´onimo y desde el servidor se env´ıe la notificaci´on a todos los clientes. 20. Evitar el acceso al IMEI del dispositivo m´ovil. Pues mediante este n´umero de 15 d´ıgitos, se identifica a un terminal cuando se conecta a una red m´ovil. 21. Evitar el acceso a la direcci´on MAC de Bluetooth del m´ovil. Pues este identificador ´unico se emplea durante conexiones Bluetooth. 22. Evitar el acceso a la direcci´on IPv4 y MAC de la tarjeta WiFi.Pues pueden utilizarse para identificarnos al conectarnos a la red. El desarrollo de las aplicaciones de rastreo de contactos puede realizarse desde dos enfoques. Dependiendo de la opci´on elegida en la parte de dise˜no, tras analizar el estado del arte y los diferentes protocolos existentes para su desarrollo, se aplicar´an un grupo de los siguientes requisitos. En el caso de que un usuario se declarase infectado, la aplicaci´on env´ıa a un servidor el historial de los contactos de proximidad que se han obtenido mediante escaneo, se aplicar´an los siguientes requisitos: Escuela de Ingenier´ıa Inform´atica 25 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Fecha generadora. Es uno de los par´ametros necesarios para la generaci´on del identificador. Fecha de recepci´on. Es la fecha de recepci´on en el servidor de los datos del identificador contagiado. De este modo, quedar´ıa de la siguiente forma: Figura 5: Modelo l´ogico Servidor Escuela de Ingenier´ıa Inform´atica 32 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 3.7. Modelo de intercambio de datos Los datos ser´an intercambiados entre los siguientes involucrados: Aplicaci´on cliente. Estos realizar´an el intercambio de identificadores actuando entre ellos como cliente y servidor alternando los roles. Servidor. El servidor recibe de un cliente contagiado el c´odigo y las semillas asociadas a sus identificadores. Adem´as, de manera aleatoria, todos los clientes env´ıan datos an´alogos pero falsos con el fin de generar ruido. A la hora de interactuar el servidor con los clientes para enviar los datos, se realiza un broadcast o multicast con el fin de salvaguardar la privacidad al no hacer diferenciaci´on entre clientes. Figura 6: Modelo de intercambio de datos 3.8. Desarrollo de los casos de uso Tras un an´alisis de los requisitos elicitados en este documento, hemos llegado a la conclusi´on de que nuestro sistema implica la actuaci´on de cinco actores: Usuario. Ser´ıa el actor principal, es decir, a quien va pensada la funcionalidad de la aplicaci´on. Servidor. Sirve como punto de contacto con la autoridad sanitaria pertinente. Su funci´on principal es la gesti´on de los datos referentes a los identificadores ef´ımeros y los diagn´osticos, tanto su env´ıo y recepci´on como el borrado de registros antiguos o no vigentes. Timer. Es un representaci´on del paso del tiempo, el cual desencadena aquellos casos de uso que se llevan a cabo seg´un un periodo temporal. En segundo plano, env´ıa al servidor de manera peri´odica c´odigos falsos. Esto se hace con la finalidad de generar ruido, pues de otro modo podr´ıa detectarse qui´en est´a infectado ya que el env´ıo de datos direcci´on cliente servidor solo se har´ıa al comunicar un contagio. Escuela de Ingenier´ıa Inform´atica 33 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Sensor Bluetooth servidor. Se trata de un actor que act´ua como parte de la comunicaci´on Bluetooth, el cual es el encargado de recibir los identificadores enviados por el Sensor Bluetooth cliente de otros dispositivos implicados en el intercambio. Sensor Bluetooth cliente. Al igual que el anterior, se trata de un actor que act´ua como parte de la comunicaci´on Bluetooth. En cambio, la funci´on de este es transmitir los identificadores a recibir por el Sensor Bluetooth servidor del resto de dispositivos implicados en el intercambio. Figura 7: Diagrama de casos de uso Escuela de Ingenier´ıa Inform´atica 34 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Como se puede apreciar en el diagrama anterior los casos de uso ser´ıan los siguientes: 3.8.1. UC-01 Enviar diagn´ostico ELEMENTO VALOR Caso de Uso Enviar diagn´ostico Resumen Se realiza este caso de uso cuando el actor Usuario quiere comunicar su contagio. Actor Usuario, Servidor Precondici´on Tener conexi´on a Internet. Postcondici´on Las semillas generadoras del actor Usuario aparecen como infectadas en el servidor. La aplicaci´on (usuario) cambia su estado a infectado. Secuencia Base 1- El actor Usuario introduce el c´odigo de diagn´ostico proporcionado por la autoridad sanitaria. 2- El sistema pide confirmaci´on al usuario. 3- El actor usuario verifica la acci´on. 4- El sistema env´ıa el c´odigo al servidor. 5- El sistema le comunica al actor Usuario que el c´odigo es correcto y le informa de las medidas que debe tomar(cambiar pantalla inicial). 6- El sistema env´ıa las semillas generadoras de los ID del actor Usuario al servidor. Secuencia Alternativa Excepciones 3’- El actor usuario no verifica la acci´on y se vuelve al paso 1. 5’- El sistema comunica un error de conexi´on y el caso de uso queda sin efecto. 5”- El sistema comunica al actor Usuario que el c´odigo es incorrecto y el caso de uso queda sin efecto. Sub Caso de Uso Tabla 2: Caso de uso: Enviar diagn´ostico 3.8.2. UC-02 Cambiar idioma ELEMENTO VALOR Caso de Uso Cambiar idioma Resumen Se realiza este caso de uso cuando el actor Usuario quiere cambiar el idioma de la aplicaci´on. Actor Usuario Precondici´on Postcondici´on El idioma de la aplicaci´on ha cambiado al seleccionado por el actor Usuario. Secuencia Base 1- El actor Usuario selecciona un idioma entre los disponibles. 2- El sistema le pide confirmaci´on al actor Usuario. 3- El actor Usuario confirma su selecci´on. 4- El sistema aplica los cambios sobre la aplicaci´on. Secuencia Alternativa Excepciones 3’- El actor Usuario no confirma la acci´on y el caso de uso queda sin efecto. Sub Caso de Uso Tabla 3: Caso de uso: Cambiar idioma Escuela de Ingenier´ıa Inform´atica 35 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 3.8.3. UC-03 Comunicar semillas asociadas a IDs infectados ELEMENTO VALOR Caso de Uso Comunicar semillas asociadas a ID infectados Resumen Se realiza un broadcast del contenido de la base de datos del servidor de forma peri´odica con el fin de notificar posibles contagios a los clientes. Actor Servidor Precondici´on Debe haber pares clave - fecha marcados como infectados en la base de datos. Tener conexi´on a Internet Postcondici´on Los clientes obtienen los pares clave - fecha necesarios para generar los ID’s infectados. Secuencia Base 1- El actor Servidor env´ıa los pares infectados a todos los clientes. 2- Se realiza el caso de uso Comprobar riesgo de contagio Secuencia Alternativa Excepciones Sub Caso de Uso Comprobar riesgo de contagio Tabla 4: Caso de uso: Comunicar semillas asociadas a IDs infectados 3.8.4. UC-04 Comprobar riesgo de contagio ELEMENTO VALOR Caso de Uso Comprobar riesgo de contagio Resumen Este caso de uso se realiza para comprobar si ha habido alg´un contacto con alg´un usuario infectado. Actor Precondici´on Debes haber recibido pares clave - fecha infectados. Postcondici´on El sistema muestra el riesgo de contagio m´as alto entre los identificadores comprobados. Secuencia Base 1- El sistema genera los ID’s asociados a los pares recibidos. 2- El sistema compara los ID’s generados con aquellos obtenidos mediante intercambio Bluetooth. 3- El sistema muestra el riesgo de contagio m´as alto de entre los ID’s coincidentes. Secuencia Alternativa Excepciones 3’- Ning´un ID generado coincide el caso de uso queda sin efecto. Sub Caso de Uso Tabla 5: Caso de uso: Comprobar riesgo de contagio Escuela de Ingenier´ıa Inform´atica 36 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 3.8.5. UC-05 Enviar diagn´ostico falso ELEMENTO VALOR Caso de Uso Enviar diagn´ostico falso Resumen Este caso de uso se realiza un n´umero aleatorio de veces a lo largo del dia Actor Timer, Servidor Precondici´on Tener conexion a Internet. Postcondici´on Se genera tr´afico falso que realiza la funci´on de ruido en la red con la finalidad de prevenir ataques pasivos de escucha. Secuencia Base 1- El actor Timer genera unas claves falsas y una fecha aleatoria dentro de los ´ultimos 15 d´ıas. 2- El sistema genera un c´odigo de diagn´ostico falso. 3- El sistema env´ıa el c´odigo al servidor. 4- El sistema env´ıa las claves y fechas generadoras de los ID del actor Usuario al servidor. Secuencia Alternativa Excepciones 3’- El sistema comunica un error de conexi´on y el caso de uso queda sin efecto. Sub Caso de Uso Tabla 6: Caso de uso: Enviar diagn´ostico falso 3.8.6. UC-06 Recibir ID ELEMENTO VALOR Caso de Uso Recibir ID Resumen Este caso de uso se realiza cuando el actor Sensor Bluetooth servidor detecta una se˜nal Bluetooth de otro dispositvo para recibir su ID. Actor Sensor Bluetooth servidor, Sensor Bluetooth cliente Precondici´on El dispositivo debe tener el Bluetooth y la geolocalizaci´on activados. Postcondici´on El ID recibido es almacenado en la base de datos del sistema. Secuencia Base 1- El actor Sensor Bluetooth servidor detecta una se˜nal Bluetooth (UUID IGUAL) de la aplicaci´on. 2- El sistema inicia un contador de 15 min. 3- El actor Sensor Bluetooth servidor recibe del actor Sensor Bluetooth cliente el ID ef´ımero correspondiente a ese periodo de tiempo. 4- El sistema almacena el ID recibido en la base de datos junto con la intensidad de se˜nal recibida. Secuencia Alternativa Excepciones 3’ - Se deja de detectar se˜nal Bluetooth antes de agotar los 15 min y el caso de uso queda sin efecto. Sub Caso de Uso Tabla 7: Caso de uso: Recibir ID Escuela de Ingenier´ıa Inform´atica 37 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 3.8.7. UC-07 Enviar ID ELEMENTO VALOR Caso de Uso Enviar ID Resumen Este caso de uso se realiza cuando el actor Sensor Bluetooth cliente detecta una se˜nal Bluetooth de otro dispositvo para enviar su propio ID. Actor Sensor Bluetooth cliente, Sensor Bluetooth servidor Precondici´on El dispositivo debe tener el Bluetooth y la geolocalizaci´on activados. Postcondici´on El ID ef´ımero del periodo de tiempo correspondiente se env´ıa al Sensor Bluetooth servidor. Secuencia Base 1- El actor Sensor Bluetooth cliente detecta una se˜nal Bluetooth (UUID IGUAL) de la aplicaci´on. 2- El sistema inicia un contador de 15 min. 3- El actor Sensor Bluetooth cliente env´ıa al actor Sensor Bluetooth servidor el ID ef´ımero correspondiente a ese periodo de tiempo. Secuencia Alternativa Excepciones 3’ - Se deja de detectar se˜nal Bluetooth antes de agotar los 15 minutos y el caso de uso queda sin efecto. Sub Caso de Uso Tabla 8: Caso de uso: Enviar ID Escuela de Ingenier´ıa Inform´atica 38 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 4. Dise˜no de la aplicaci´on Partiendo de los requisitos anteriormente elicitados, se deben tomar ciertas decisiones importantes de dise˜no. Para ello, se acotan las soluciones que vamos a implementar para los problemas que han sido presentados anteriormente en los requisitos. 4.1. Estado del Arte: Protocolos El protocolo de comunicaci´on de exposici´on es una de las partes principales de la aplicaci´on. Se recogen a continuaci´on los m´as relevantes. [44] 4.1.1. Decentralized Privacy-Preserving Proximity Tracing (DP-3T) Se trata de un protocolo descentralizado de c´odigo abierto. [5] Este protocolo se basa en la generaci´on de identificadores ef´ımeros, los cuales se intercambian cuando dos clientes se encuentran a una distancia inferior a 2 metros y durante m´as de 15 minutos de exposici´on. El proceso para generar estos identificadores, ilustrado en la Figura 8 es el siguiente: Figura 8: Esquema de generaci´on de identificadores ef´ımeros 1. Generaci´on de SKt.O Secret Key (clave secreta) n´umero t. Inicialmente se genera una clave secreta SKtcorrespondiente al d´ıa tactual. Esta clave se obtiene a partir del resumen hash SHA-256 de la clave SKt-1. La generaci´on de la primera SK0se hace mediante el algoritmo de curvas de Edward Ed25519. 2. Generaci´on del S EphID. O Secret Ephemeral IDentifier (identificador ef´ımero secreto). A partir del SKtdel d´ıa se genera el S EphID empleando una funci´on: S EphID(BK) = P RG(P RF (SKt, BK)) Donde PRG es un cifrado de flujo que produce n*16 bytes, siendo n el n´umero de identificadores diarios. El n´umero n se determina tal que n=(2460)/l, siendo l el tiempo de vida en minutos de un identificador ef´ımero. PRF es una funci´on pseudoaleatoria de la forma HMAC-SHA256 y BK es una variable global. Escuela de Ingenier´ıa Inform´atica 39 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 3. Generaci´on de EphIDnTras ello el S EphID se subdivide en n fragmentos de tama˜no 16 bytes. Cada uno de estos fragmentos es un EphID cuyo orden de uso se determina de forma aleatoria. En concreto, en DP-3T el tiempo de uso para su intercambio de un identificador ef´ımero es de 15 minutos. Cuando dos usuarios se encuentran, las aplicaciones m´oviles comienzan a actuar entre ellas como servidorcliente, intercambiando los roles, para de esta manera enviarse mutuamente los identificadores. Cuando se produce un contagio, el usuario env´ıa un c´odigo de verificaci´on que previamente la autoridad sanitaria le ha proporcionado. Este c´odigo se env´ıa junto a las semillas generadoras. Esta informaci´on recibida por el servidor es enviada de forma peri´odica a los clientes. As´ı, las aplicaciones cliente pueden calcular los identificadores contagiados a partir de las semillas generadoras recibidas desde el servidor. Si alguno de estos identificadores generados coincide con uno de los almacenados significa que ha habido una exposici´on a contagio y el protocolo avisa al usuario de ello a trav´es de la aplicaci´on cliente. Al enviar las semillas generadoras, se preserva la privacidad de los usuarios contagiados, pues los identificadores no son enviados nunca como tal. [24] [30] [49] Este protocolo se cre´o para apoyar el protocolo GAEN, funcionando sobre ´el aunque con algunos cambios a nivel de tratamiento y a la hora de crear las semillas generadoras y los identificadores. 4.1.2. (Google/Apple) Exposure Notification (GAEN) system Originalmente conocido como Privacy-Preserving Contact Tracing Project. Este protocolo emplea un enfoque descentralizado. Fue creado con el fin de que existiera una comunicaci´on entre dispositivosAndroid eiOS. Sin embargo no es compatible con los dispositivos Huawei posteriores a mayo de 2019. Est´a implementado a nivel de sistema operativo para de esta forma ser m´as eficiente al realizar todos los procesos en segundo plano. Funciona de manera muy similar a DP-3T, empleando identificadores ef´ımeros (EphIDs), los cuales cambian cada 15-20 minutos (al resetearse la MAC Bluetooth del dispositivo). Estos son calculados mediante una clave AES y una marca de tiempo calculada a partir de Unix Epoch Time. Cuando se produce un contagio, desde la aplicaci´on cliente se suben al servidor las semillas generadoras. De esta forma, el servidor puede reenviar esa informaci´on a los dem´as usuarios y estos generar los identificadores correspondientes. Si alguno coincidiera con uno almacenado, el protocolo avisa a trav´es de la aplicaci´on cliente de que se ha estado expuesto a un posible contagio.[31] La diferencia principal con DP-3T se encuentra en la generaci´on de las claves secretas SK. En DP-3T estas claves se obtienen a partir de un resumen hash de la clave SK del d´ıa anterior. Sin embargo, en GAEN todas las claves secretas son generadas a partir del mismo inicializador. Otra diferencia reside en el sello temporal empleado para generar esos identificadores. DP-3T utiliza una marca de tiempo m´as basta o un resumen hash de la misma. Por ello garantiza la privacidad mejor que GAEN, aunque a costa de ser m´as vulnerable ante los ataques de repetici´on, pues son m´as f´aciles de llevar a cabo debido a un per´ıodo de validez m´as largo (ya que las estampas temporales son menos precisas y por lo tanto hay m´as d´ecimas de tiempo entre ellas). [28] 4.1.3. Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT/PEPP) Este protocolo es descartado debido a la necesidad de registro en el servidor, medida tomada para evitar multicuentas. Esto se hace mediante datos personales pseud´onimos que se usan para generar el identificador PUID. Dicho identificador es necesario para que el servidor asocie dicho dispositivo y sea capaz de enviarle los datos pertinentes ante el registro de casos positivos. El PUID se emplea junto a una clave global, la cual cambia cada 60 minutos, para generar en el servidor los ID ef´ımeros EBID. Estos se env´ıan mediante Escuela de Ingenier´ıa Inform´atica 40 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina broadcast a los clientes de la aplicaci´on. Dichas claves globales se eliminan a las 4 semanas. El hecho de que el servidor sea capaz de obtener los PUID originales mediante la clave y los EBID, lo convierte en un sistema con gran capacidad para identificar a usuarios, de divulgaci´on completa y correlaci´on. Esto le convierte en un objetivo con un riesgo muy alto, pues es posible reidentificar a los usuarios mediante los PUID y las claves, ya que estas se quedan almacenadas durante bastante tiempo. Por otro lado, los EBID permiten el rastreo en tiempo real de los usuarios, infectados o no. Esto es debido a que el servidor backend permite su conversi´on en identificadores permanentes, relacionando cualquier reporte o interacci´on del portador con dispositivos y sensores Bluetooth al PUID original. Adem´as, debido a que no existe una metodolog´ıa de identificaci´on y autenticaci´on de los EBID, es posible generarlos de manera falsa, asoci´andolos a un usuario de manera externa. Esta amenaza puede concretarse en un ataque de un tercero que, asociando un EBID falso a un usuario, sea capaz de rastrearlo. El servidor nunca identificar´ıa dicha anomal´ıa al carecer de una firma digital o certificado que corrobore la autenticidad del EBID. Esto desanonimiza a los usuarios sin necesidad de atacar al servidor al asignarles un EBID persistente externo, permitiendo su geolocalizaci´on constante mediantes sensores Bluetooth. Los detalles de los contactos de un caso positivo son revisados de manera manual por la entidad sanitaria con el fin de evitar falsos positivos, haciendo el trabajo m´as lento que estando gestionado por un servidor como en las variantes de DP-3T. [56] Algunos riesgos principales a ra´ız de estas caracter´ısticas son: Falsificaci´on de un riesgo. Dado que los usuarios infectados suben al servidor su lista de contactos, es posible realizar una inyecci´on de un EBID en dicha lista para generar un falso positivo. Dado que la verificaci´on de los encuentros no es posible, no hay manera de defenderse de dicho ataque. Este problema no se encuentra en protocolos descentralizados, pues los identificadores del registro de contactos no se suben al servidor en ning´un momento. Adem´as es necesario el consentimiento de la autoridad sanitaria para notificar de un positivo. Riesgo de compromiso de datos en dispositivos desbloqueados. Actualmente, el desarrollo de este protocolo es imposibilitado debido a que el d´ıa 10 de abril Apple y Google, acorde a la minimalizaci´on de datos, introdujeron una nueva api de Rastreo de Contactos, donde se imposibilita la transmisi´on de la lista de contactos v´ıa red como exige el protocolo PEPPPT/PEPP. 4.1.4. BlueTrace El principal inconveniente de este protocolo, al igual que en PEPP-PT/PEPP es el uso del procesamiento de reportes centralizado. Los protocolos que utilizan este tipo de procesamiento tienen como principal inconveniente el env´ıo de los datos de contacto del usuario a las autoridades sanitarias. Entre las responsabilidades de dichas autoridades se encuentran asignar los detalles del contacto a cada usuario, determinar si ha habido un contagio y finalmente advertir a los usuarios si este ha ocurrido. Esto implica una correlaci´on directa entre el usuario y los contactos. En cambio, los protocolos descentralizados delegan todas estas funciones en la red, aumentando as´ı la eficiencia y la privacidad de los usuarios. A diferencia de PEPP-PT/PEPP, BlueTrace genera los identificadores temporales (TempIDs) utilizando el identificador del usuario, el instante de tiempo en el que se crea el TempID, el tiempo de expiraci´on del ID, un vector de inicializaci´on (IV) y una clave privada proveniente la autoridad sanitaria. Escuela de Ingenier´ıa Inform´atica 41 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 4.4. Implementaci´on de los requisitos acorde a nuestra versi´on de DP-3T Una vez se ha decidido el desarrollo de una versi´on propia del protocolo DP-3T, es necesario comprobar que este sea capaz de cumplir los requisitos estipulados en la fase de an´alisis y explicar c´omo se llevar´a a cabo. Implementaci´on de los Requisitos No Funcionales Rotaci´on de identificadores. Con el fin de incrementar la confusi´on y difusi´on, diariamente se generan un n´umero fijo de identificadores que rotan cada cierto tiempo. Estos identifican de manera an´onima a los usuarios. Implementaci´on de los Requisitos Funcionales De cara al usuario Visualizaci´on de mi riesgo de exposici´on. Se mostrar´a un panel que variar´a de color seg´un el nivel de riesgo. •Nulo. Verde. •Riesgo. Amarillo. •Contagiado. Rojo. Posibilidad de comunicaci´on de contagio. Cuando un usuario haya dado positivo, la autoridad sanitaria le proporcionar´a un c´odigo que este podr´a introducir en la aplicaci´on. Dicho c´odigo se enviar´a al servidor junto a las semillas generadoras de los identificadores del usuario y la fecha de PCR positiva o de inicio de s´ıntomas. El servidor se encargar´a de corroborar que dicho c´odigo es v´alido y, de serlo, almacenar los datos enviados. Notificaci´on y muestra de la exposici´on a un contagio. Se avisar´a al usuario de un posible contagio mediante una notificaci´on en su smartphone. Tambi´en dentro de la aplicaci´on mediante el cambio de color del panel de riesgo de exposici´on. De cara a otros dispositivos Intercambio de identificadores. Estos se generar´an criptogr´aficamente como especifica DP-3T e identificar´an usuarios de manera an´onima. El intercambio se llevar´a a cabo al transcurrir 15 minutos seguidos de contacto con otro dispositivo. Permitir la identificaci´on de otros dispositivos con la aplicaci´on. La aplicaci´on detectar´a otros dispositivos cercanos que posean la aplicaci´on activa tambi´en. El radio abarcado es de dos metros. Medici´on del tiempo de exposici´on a un contacto. Para medir el tiempo de exposici´on DP-3T utiliza la atenuaci´on de los paquetes de datos transmitidos mediante Bluetooth, de forma que si dicha atenuaci´on se encuentra por encima de unos valores, se comenzar´a a contar el tiempo. La estimaci´on se realiza utilizando un conjunto de beacons recibidos de un dispositivo concreto, los cuales se env´ıan cada cierto tiempo (entre 2 minutos y medio y 5 minutos) a modo de cerciorarse de que los dispositivos permanecen en rango del otro. Escuela de Ingenier´ıa Inform´atica 48 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Informar de un contagio. De manera peri´odica el servidor emitir´a mediante broadcast las semillas generadoras asociadas a identificadores contagiados que tiene almacenados. Cuando la aplicaci´on recibe dichas semillas, genera los identificadores en local y los compara con los almacenados. En caso de producirse una coincidencia, la aplicaci´on informa al usuario que ha estado en las cercan´ıas de un individuo contagiado. Contacto tras exposici´on a otro dispositivo. A partir de los 15 minutos de exposici´on se considera contacto. C´alculo de la distancia entre dispositivos. Se considera distancia cercana cuando se detecta una atenuaci´on inferior a 50dB. Con ello tenemos una muy alta certeza de que la distancia es inferior a dos metros. Para corregir discrepancias entre modelos de dispositivos m´oviles, al comienzo del encuentro se realiza una calibraci´on. [2] Al igual que en DP-3T, existir´an los siguientes estados:[3] •Sin riesgo. El usuario no ha estado en contacto con ning´un usuario contagiado. •Con riesgo. La aplicaci´on ha detectado un identificador contagiado entre sus almacenados, lo cual indica que el usuario ha estado en contacto cercano con alg´un usuario contagiado. •Contagiado. El usuario ha proporcionado un c´odigo de contagio v´alido al servidor, lo cual indica que ha obtenido positivo en una PCR, pues una autoridad sanitaria le ha cedido un c´odigo v´alido. Env´ıo de c´odigos de contagio al servidor de la autoridad sanitaria. Para realizar el env´ıo del c´odigo de contagio DP-3T utiliza un objeto de tipo GaenRequest. Este objeto es una adaptaci´on de la petici´on b´asica del protocolo HTTP realizada por el protocolo GAEN. [4] Debido a la imposibilidad para acceder a un servidor propio de la autoridad sanitaria, la aplicaci´on se orientar´a inicialmente a una red local. Para ello lo que se har´a es enviar el paquete cifrado por la red a un puerto TCP concreto donde se llevar´an a cabo las pruebas. Comunicaci´on con el servidor para obtener lista de nuevos contagios. El servidor emitir´a de manera peri´odica el listado de todas las semillas generadoras de identificadores contagiados que posea. La aplicaci´on cliente recibir´a dicho listado y comparar´a lo recibido con lo almacenado para determinar si el usuario ha estado expuesto. De cara a la propia aplicaci´on C´alculo de los identificadores. Se calculan empleando el algoritmo de DP-3T explicado en la secci´on dedicada al protocolo DP-3T. C´alculo de estado de exposici´on. El estado de exposici´on pasa a ser de riesgo en el momento en el que se reciben las semillas generadoras de un identificador recibido previamente, es decir, se ha estado en contacto con un usuario contagiado a menos de 2 metros. El estado de contagiado aparece en el momento en el que se env´ıa un c´odigo de contagio al servidor y este es validado como tal. [3] Implementaci´on de los Requisitos de Informaci´on Informaci´on almacenada en local Identificadores an´onimos propios de cada usuario. Se usar´an identificadores generados de manera pseudoaleatoria, como se ha explicado en el apartado dedicado DP-3T, con el fin de no proporcionar ning´un dato personal del usuario.[24] Escuela de Ingenier´ıa Inform´atica 49 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Informaci´on anonimizada sobre qu´e usuarios han estado en contacto. Se usar´an identificadores ef´ımeros que se intercambiar´an entre usuarios que mantengan contacto. Informaci´on almacenada en el servidor Datos asociados a los identificadores infectados. Se almacenar´an las semillas generadoras de los identificadores, es decir la clave primigenia y fecha generadora, y la fecha de recepci´on. Fecha de recepci´on. Se almacenar´a la fecha de recepci´on de los datos anteriores con el fin de eliminarlos a los 14 d´ıas (tiempo que permanece activo el virus). Base de Datos. Modelo F´ısico La arquitectura de este proyecto requiere la utilizaci´on de dos bases de datos, una situada en el servidor y encargada de gestionar los identificadores contagiados, y otra en los clientes de la aplicaci´on, en local, encargada de almacenar tanto los identificadores propios como los obtenidos por intercambio. Para su implementaci´on es necesario llevar a cabo un an´alisis sobre qu´e gestores de bases de datos nos ofrecen las caracter´ısticas ´optimas para cada una de ellas. Base de Datos Local La base de datos local es aquella que se crear´a en las instancias cliente de la aplicaci´on, en este caso los dispositivos Android de cada uno de los usuarios. En este caso, las alternativas que se han encontrado son:[52] Oracle Berkeley DB. Es un familia de productos que ofrece librer´ıas para gestionar datos con un gran rendimiento y escalabilidad. Proporciona flexibilidad ya que se puede manejar o bien como una base de datos clave-valor o bien como una base de datos relacional cuando sea necesario. Su almacenamiento requiere de en torno a 1 MB como m´ınimo. A pesar de aparentar ser una buena opci´on, dado que la base de datos local es muy sencilla, y no haremos uso de su escalabilidad y necesidad de alto rendimiento, es preferible buscar opciones que requieran de menor almacenamiento. Interbase ToGo. Se trata de un sistema gestor de bases de datos relacionales que requiere de m´ınimo 400 KB de almacenamiento. Es una base de datos SQL empotrada disponible para Android e iOS. Posee m´odulos propios que permiten integrar opciones offline a la aplicaci´on, y tambi´en, eliminar la necesidad de implementar drivers de cliente que se conecten a la versi´on servidor de esta base de datos. Aunque es mucho menos pesada que Oracle Berkeley DB, su licencia es privada y no de dominio p´ublico. SQLite. Se define como un gestor de bases de datos relacional. La principal caracter´ıstica de este gestor es que no consta de una arquitectura cliente-servidor. En su lugar, se enlaza con el programa llegando a formar parte del mismo, ya que toda su funcionalidad esta contenida en una biblioteca de c´odigo relativamente peque˜na. La principal ventaja de este gestor es su tama˜no, ya que su tama˜no m´ınimo es de tan solo 500 KB en memoria, pues se almacena como un fichero que la biblioteca bloquea o desbloquea autom´aticamente en el momento que sea necesario. Adem´as su licencia es de dominio p´ublico y existe una amplia documentaci´on sobre su uso en dispositivos Android, lo que facilita su implementaci´on. Escuela de Ingenier´ıa Inform´atica 50 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina La decisi´on que se ha considerado m´as apropiada es utilizar el gestor SQLite, debido al poco espacio de almacenamiento que ocupa, las facilidades que ofrece a la hora de implementarse y tener licencia de dominio p´ublico. La primera tabla almacenar´a aquella informaci´on relacionada con los identificadores propios. Adem´as, el valor de id sirve para facilitar el acceso a los datos de la tabla. Tabla ids propios id Es el identificador de cada fila de la base de datos. Es de tipo INTEGER y se autogenera cada vez que se a˜nade un registro. Simplifica el acceso ordenado a la base de datos. identificador ef Se trata del identificador ef´ımero empleado para referir a cada usuario de manera un´ıvoca y an´onima. Es de tipo TEXT. clave gen Es la clave generadora, miembro del par que conforma la semilla generadora del identificador ef´ımero. Es de tipo TEXT . fecha gen Es la fecha generadora, miembro del par que conforma la semilla generadora del identificador ef´ımero. Es de tipo TEXT . La segunda, refiere a aquellos identificadores ef´ımeros obtenidos mediante intercambio BlueTooth. Tabla ids ajenos id Es el identificador de cada fila de la base de datos. Es de tipo INTEGER y se autogenera cada vez que se a˜nade un registro. Simplifica el acceso ordenado a la base de datos. identificador ef Se trata del identificador ef´ımero empleado para referir a cada usuario de manera un´ıvoca y an´onima. Es de tipo TEXT. fecha rec Es la fecha de recepci´on del identificador ef´ımero. Es de tipo TEXT. Se emplea para saber cu´ando un identificador recibido por intercambio BlueTooth deja de ser contagioso y se elimina (a los 14 d´ıas). Figura 11: Modelo de datos de la base de datos de los clientes Escuela de Ingenier´ıa Inform´atica 51 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Base de Datos del Servidor La base de datos del servidor es aquella que almacenar´a los identificadores de los usuarios infectados y a la cual tendr´an acceso las autoridades sanitarias pertinentes. Para su implementaci´on se han analizado los principales gestores de bases de datos. Se han considerado como candidatos aquellos cuyas caracter´ısticas mejor se adaptaban a la aplicaci´on y a su desarrollo futuro. [51] [54] [22] MySQL. Es un sistema gestor de base de datos relacional de c´odigo abierto, considerado el m´as popular por una amplia mayor´ıa de usuarios. Se utiliza principalmente para el desarrollo de p´aginas web, aunque su uso en software libre tambi´en est´a muy extendido. En el caso de nuestra aplicaci´on, los factores que nos han llevado a considerarlo un buen candidato son principalmente: •Facilidad de uso. Al ser uno de los gestores m´as populares, la documentaci´on, los usuarios y los ejemplos de uso son abundantes. •Buen rendimiento. MySQL destaca por tener un buen rendimiento para bases de datos con una cantidad de datos no muy elevada. Precisamente este ´ultimo punto ha sido determinante y nos ha llevado a descartarlo, pues el objetivo de la aplicaci´on es llegar al mayor p´ublico posible y por tanto la cantidad de datos ser´ıa elevada. [53] MariaDB. Este gestor de bases de datos es una derivaci´on de MySQL, por lo que son completamente compatibles. Posee una gran escalabilidad y ofrece buena seguridad y velocidad a la hora de realizar transacciones. Adem´as, es de c´odigo abierto, por lo que su licencia es de dominio p´ublico. Frente a MySQL, su optimizador funciona mejor ante cargas complejas, poseyendo un mejor rendimien- to. Tambi´en ofrece una mayor usabilidad, pues aporta estad´ısticas de tablas, mejoras en comandos y mayor precisi´on en algunos tipos de datos, as´ı como facilidades a la hora de realizar testeos. [50] PostgreSQL. Este gestor est´a optimizado para gestionar grandes vol´umenes de datos, por lo que puede funcionar algo peor con cantidades de datos menores. Posee una buena flexibilidad en cuanto a lenguajes de programaci´on y es multiplataforma, por lo que puede adaptarse a m´ultiples proyectos. Adem´as, dispone de una herramienta mucho m´as visual, pgAdmin, para gestionar las bases de datos. Se caracteriza por ser robusta, eficiente y estable. Sin embargo, optimizar su uso y recursos requiere de un mayor conocimiento del gestor. Adem´as, dado que para los casos de prueba se emplear´an vol´umenes de datos menores, no funcionar´a de una manera tan optimizada como har´ıa con grandes cantidades de datos. Se elige, por tanto, MariaDB por las facilidades que ofrece tanto a nivel de testeo, como de documentaci´on al tratarse de un gestor de c´odigo abierto. Tabla ids infectados id Es el identificador de cada fila de la base de datos. Es de tipo SERIAL y se autogenera cada vez que se a˜nade un registro. Simplifica el acceso ordenado a la base de datos. clave gen Es la clave generadora, miembro del par que conforma la semilla generadora del identificador ef´ımero. Es de tipo VARCHAR. fecha gen Es la fecha generadora, miembro del par que conforma la semilla generadora del identificador ef´ımero. Es de tipo DATE. Escuela de Ingenier´ıa Inform´atica 52 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina fecha rec Es la fecha de recepci´on del par clave y fecha generadoras. Es de tipo DATE. Se emplea para saber cu´ando un par clave-fecha generadoras deja de ser contagioso y se elimina (a los 14 d´ıas). Figura 12: Modelo de datos de la base de datos del servidor Escuela de Ingenier´ıa Inform´atica 53 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 4.4.1. Tecnolog´ıas utilizadas Las tecnolog´ıas, y sus correspondientes versiones, empleadas en este proyecto, son las siguientes: Java. JDK 1.8 Android. Versi´on 10 MariaDB. Versi´on 10.5.9 SQLite. Versi´on 3.28 4.5. Implementaci´on de los Requisitos de Usabilidad Una vez han sido definidos, se debe pensar la manera de implementarlos en la aplicaci´on a desarrollar. Veamos, entonces, la propuesta que se ha dise˜nado para cada aspecto de usabilidad y accesibilidad destacado en la secci´on de An´alisis: Esto, por tanto, obliga a que la interfaz de usuario tenga que estar pensada y dise˜nada a conciencia. Los requisitos que debe cumplir el dise˜no de la interfaz son los siguientes: La interfaz debe ser sencilla. La funcionalidad de la aplicaci´on se condensar´a en tres pantallas, principal, informaci´on y ajustes de idiomas, sin una navegaci´on entre men´us excesiva. La interfaz debe ser suficientemente intuitiva. Se usar´a simbolog´ıa f´acilmente identificable y utilizada universalmente en la mayor´ıa de aplicaciones del mercado. La interfaz debe ser agradable a la vista. Para ello se utilizar´an colores suaves. Se buscar´a que sean gamas de colores afines, evitando contrastes fuertes o visualmente agresivos. Accesibilidad para personas con daltonismo. Se utilizar´a un simulador de daltonismo para ajustar los colores de forma que estos sean lo suficientemente diferenciables para personas con trastornos visuales tales como protanopia,deuteranopia ytritanopia. El texto debe ser claro y conciso. Se evitar´a el uso de tecnicismos as´ı como de palabras redundantes con el fin de hacerlo m´as f´acil de entender a un mayor n´umero de personas. Legibilidad para todas las edades y capacidades visuales. Se emplear´an tipograf´ıas claras y sencillas, as´ı como tama˜nos de letra lo suficientemente grandes. En el caso de que esto no sea posible (por el tama˜no del bot´on o espacio en la pantalla), se emplear´an s´ımbolos visuales para complementar el concepto referenciado. La interfaz debe invitar a publicitar su uso. Se dibujar´a a Aga y Gava, que actuar´an como mascotas de la aplicaci´on, para hacerla m´as distinguible. La interfaz debe concienciar sobre los s´ıntomas del estado de exposici´on del usuario. Dependiendo del estado, sin riesgo, con riesgo o infectado; Aga y Gava, as´ı como los colores del bot´on de recomendaciones, aparecer´an de un modo u otro. •Sin riesgo. Aga y Gava aparecer´an felices. •Con riesgo. Aga y Gava aparecer´an tomando precauciones y en cuarentena. •Contagiado. Aga y Gava aparecer´an con un term´ometro y en una camita siendo cuidados por el enfermero Donehre, otro personaje. Internacionalizaci´on. Se incluir´a un apartado de ajustes de idioma para facilitar la accesibilidad a personas con distintas lenguas. Escuela de Ingenier´ıa Inform´atica 54 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 4.6. Dise˜no de la Interfaz e Implementaci´on de los Requisitos Esta aplicaci´on est´a dirigida a un espectro de usuarios muy amplio. Esto impone que la interfaz de usuario sea muy intuitiva y sencilla, con el fin de que un usuario sin experiencia pueda hacer uso de ella con facilidad. El elemento a destacar en la interfaz de la aplicaci´on es el men´u de navegaci´on. Figura 13: Men´u de navegaci´on Consta de tres botones con amplia superficie para garantizar la m´axima precisi´on a la hora de seleccionar cada uno. Adem´as, se ha cuidado de que ´unicamente se implementen las funcionalidades necesarias, dejando de lado elementos superfluos. En orden de izquierda a derecha son: Acceso a pantalla principal. Nos permite ingresar en la pantalla principal de la aplicaci´on cuando nos encontremos en cualquier otra pantalla, salvo en el formulario de comunicaci´on de contagio. Acceso a pantalla de informaci´on. Nos permite ingresar en la pantalla de informaci´on cuando nos encontremos en cualquier otra pantalla, salvo en el formulario de comunicaci´on de contagio. Acceso a pantalla de cambio de idioma. Nos permite ingresar en la pantalla de cambio de idioma cuando nos encontremos en cualquier otra pantalla, salvo en el formulario de comunicaci´on de contagio. A continuaci´on procederemos a explicar brevemente cada dise˜no preliminar de las respectivas pantallas. En las im´agenes se se˜nala con una flecha en cu´al de los botones del men´u inferior se encuentra. Escuela de Ingenier´ıa Inform´atica 55 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 4.6.1. Pantalla Principal La pantalla principal cuenta con un t´ıtulo adem´as de las siguientes ´areas: Figura 14: Pantalla Principal Pantalla Riesgo de Contagio. Aqu´ı se indicar´a el nivel de riesgo de contagio del usuario. Dependiendo del nivel de riesgo el color de este recuadro cambiar´a: •Verde. El usuario no ha estado en contacto con ning´un individuo contagiado, ende el riesgo de contagio no existe. •Naranja. El usuario ha estado cerca de alg´un individuo contagiado, ende posee riesgo de contagio. •Rojo. El usuario ha enviado un c´odigo proporcionado por una entidad sanitaria y el servidor lo ha validado, ende estando contagiado. Como hemos detallado en los requisitos de usabilidad de la aplicaci´on los colores elegidos son suaves y poco impactantes. Bot´on Comunica tu contagio. Si el usuario desea comunicar su contagio, ha de pulsar este bot´on. Cuando lo haga aparecer´a una pantalla como la siguiente: Escuela de Ingenier´ıa Inform´atica 56 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Figura 15: Bot´on Comunica tu contagio Esta pantalla incluye dos cuadros, el primero deja introducir la fecha de inicio de s´ıntomas o PCR positiva, el segundo, el c´odigo proporcionado por la autoridad sanitaria, el cual seguir´a un patr´on con el fin de evitar env´ıo de diagn´osticos falsos. Una vez pulsado el bot´on de Enviar diagn´ostico, la aplicaci´on procede a mostrar el siguiente cuadro confirmativo. Figura 16: Confirmaci´on del env´ıo Escuela de Ingenier´ıa Inform´atica 57 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina ¿Qui´enes son Aga y Gava? Aga y Gava son dos dragoncitos, pero los nombres provienen de agaporni ygaviota, respectivamente. Aga fue creada a inicios de la carrera por Mar´ıa Ruiz Molina y ha sido su marca en diversos trabajos de asignaturas, as´ı como proyectos individuales. Gava fue creado por Juan Vel´azquez Garc´ıa como intento de dibujar a Aga. Su nombre proviene de que en su primera versi´on, la cual fue un intento de dibujar a Aga, su pelo parec´ıa una gaviota. El dise˜no ha evolucionado perdiendo la forma de pico de gaviota a un pelo m´as refinado. Posteriormente Gava se a˜nadi´o al universo de Aga junto a otros tantos personajes que se crearon, varios de ellos a modo de avatares o agatares de amigos del grupo de la facultad. Si bien la idea final de estos personajes es incorporarlos a futuro como parte de un videojuego o historietas c´omicas, debido a su simpleza y dise˜no lindo se ha decidido incluirles tambi´en en este trabajo a modo de mascotas y marca personal. Como an´ecdota, el primer trabajo universitario realizado conjuntamente por ambos autores incluy´o tambi´en a Aga y Gava, en el primer cuatrimestre de segundo de carrera, y desde entonces Aga ha acompa˜nado pr´acticamente todas las entregas de Mar´ıa Ruiz Molina. Escuela de Ingenier´ıa Inform´atica 64 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 4.8. Implementaci´on de la aplicaci´on 4.8.1. Implementaci´on final de la interfaz A la hora de implementar la interfaz en la aplicaci´on, se opt´o por usar colores distintos de los de Radar Covid. As´ı, se cambi´o la paleta de colores de morado a azules suaves. La aplicaci´on queda con la siguiente interfaz, respetando los los requisitos anteriores. Figura 23: Pantalla de inicio. Colores de la aplicaci´on Como puede verse, los colores siguen siendo lo suficientemente diferenciados, permitiendo la visualizaci´on de los iconos del men´u de abajo, as´ı como la legibilidad. En cuanto a las pruebas de daltonismo, los colores del men´u de abajo siguen contrastando lo suficiente. Los colores del nivel de alerta puede que se vean peor en ciertos casos, pero al ir acompa˜nados de un mensaje sobre el estado de contagio, se compensa el menor contraste entre colores asociados a estados. Estas pruebas se han realizado con el simulador online https://www.color-blindness.com/coblis-color-blindness-simulator/ Escuela de Ingenier´ıa Inform´atica 65 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Figura 24: Pantalla de inicio. Protanopia Figura 25: Pantalla de inicio. Deuteranopia Escuela de Ingenier´ıa Inform´atica 66 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Figura 26: Pantalla de inicio. Tritanopia 4.8.2. Conexiones de red TCP En la elaboraci´on del protocolo, as´ı como de las conexiones que realizar´a el cliente con el servidor, los env´ıos de c´odigos contagiados se har´an por red empleando el protocolo TCP. De este modo, nos aseguramos de que el orden de env´ıo de los paquetes se mantenga, as´ı como evitar la p´erdida de estos. Esto es importante, pues el c´odigo solo va a transmitirse una vez por red. 4.8.3. Conexiones de red UDP Por otro lado, el servidor enviar´a identificadores contagiados de manera peri´odica. Este env´ıo se realiza a todos los clientes, por lo que se trata de un multicast, donde los clientes pertenecen a un grupo concreto, definido con una direcci´on IP de grupo de multicast. Debido al uso de multicast el protocolo empleado es UDP, pues la conexi´on no se realiza solamente entre dos dispositivos, sino que es de un servidor a todos los clientes. 4.8.4. Decisi´on sobre Bluetooth El hecho de desarrollar una versi´on del protocolo DP-3T desde cero, aunque este utilice Bluetooth Low Energy, plantea un dilema sobre qu´e tipo de protocolo Bluetooth es m´as aconsejable. Durante el estudio realizado con anterioridad sobre protocolos de rastreo de contactos, se encontr´o que BLE era una tecnolog´ıa que ofrec´ıa como principal ventaja la eficiencia energ´etica, pero a cambio de necesitar permisos de geolocalizaci´on para poder funcionar. Debido a la orientaci´on hacia la privacidad de este proyecto, esta ventaja deb´ıa ser lo suficientemente considerable como para justificar su uso. Adem´as, debido a que BLE funciona por broadcast, enviando la MAC Bluetooth, el UUID e informaci´on sobre el servicio abierto, los mensajes y esta informaci´on pueden ser interceptados con mayor facilidad. Escuela de Ingenier´ıa Inform´atica 67 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Bluetooth por otro lado crea canales seguros mediante el pareado de dispositivos. De este modo se realiza un intercambio de clave y el canal se cierra a agentes externos. [blvsble1] Tras muchas b´usquedas, se encontraron estudios sobre sus diferencias, aunque los resultados no proporcionaban informaci´on sobre la disparidad de gasto energ´etico en cuanto a tiempo de uso de la bater´ıa. Por esta raz´on, se decidi´o realizar un estudio propio de forma r´apida, para comprobar cu´anta bater´ıa puede llegar a consumir Bluetooth en un periodo de tiempo amplio. Para ello, se conectaron unos cascos inal´ambricos a un dispositivo m´ovil y se reprodujeron pistas de audio durante 1 hora. Tras este tiempo, se comprob´o el porcentaje aproximado de consumo de bater´ıa que ofrece el sistema. El valor obtenido fue un consumo de bater´ıa aproximado de un 2 % en 1 hora de reproducci´on de audio. Si extrapolamos a la cantidad de datos que se van a intercambiar con esta aplicaci´on, por supuesto mucho menor, podemos concluir que la diferencia en cuanto a consumo de energ´ıa entre Bluetooth y BLE no justifica el solicitar permisos de geolocalizaci´on al usuario. Es por ello que esta aplicaci´on utilizar´a el protocolo Bluetooth. 4.8.5. Cifrado de los datos El cifrado de los datos se llevar´a a cabo durante la transmisi´on TCP del cliente al servidor, para de este modo evitar la interceptaci´on o escucha de lo identificadores contagiados y del c´odigo de contagio proporcionado por la autoridad sanitaria. Para ello, el servidor env´ıa al cliente su clave p´ublica. Con ella, el cliente cifrar´ıa una clave sim´etrica AES- 256 y se la enviar´ıa al servidor. Una vez que ambos poseen la clave sim´etrica, el cliente enviar´ıa el paquete con el c´odigo e identificadores contagiados. De este modo, solo el servidor podr´ıa descifrar el mensaje. Tras dicho intercambio, se ha optado por un cifrado de clave sim´etrica de los datos debido a su menor complejidad computacional Adem´as, el tipo de cifrado usado se ha determinado calculando la entrop´ıa generaba tras cifrar un mensaje formateado como un c´odigo y los identificadores a enviar. En la siguiente imagen pueden verse los resultados obtenidos con los tipos de cifrado, en orden, ECB (Electronic Codebook), CBC (Cipher Block Chaining) y CFB Cipher Feedback): Figura 27: Resultado de entrop´ıas Si bien el tipo de cifrado que mejor entrop´ıa obtiene es ECB, debido a su funcionamiento es descartado. Al tratarse de un cifrado que a iguales bloques da iguales resultados, es susceptible de ataques de repetici´on. Esto se debe a que emplea la misma clave para cifrar cada bloque, y de haber dos iguales, el resultado ser´ıa Escuela de Ingenier´ıa Inform´atica 68 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina el mismo. Es por ello que se escoge CFB, por ser el siguiente con mejor entrop´ıa, adem´as de estar orientado a cifrado de textos. 4.8.6. Adaptaciones realizadas cara al prototipo Debido a la complejidad de la aplicaci´on, as´ı como del protocolo a implementar, y las restricciones de tiempo, se han realizado simplificaciones en algunos aspectos del desarrollo de la aplicaci´on, llevando a cabo un prototipo que implementa todas las funciones pero con algunos cambios. Estos o bien facilitan el seguimiento de las pruebas y an´alisis posteriores, o bien facilitaron la programaci´on de algunos aspectos, permitiendo cuadrar los tiempos dentro de la planificaci´on. Las adaptaciones son las siguientes. Intercambio activo de los identificadores. Para un mayor control de las pruebas, se ha implementado un bot´on en la aplicaci´on prototipo. Al pulsarlo se realiza el env´ıo de los identificadores v´ıa Bluetooth a los dispositivos pareados. Env´ıo activo de ruido. Para evitar postergar en la planificaci´on las fases posteriores a la implementaci´on de la aplicaci´on, se ha prescindido de esta funcionalidad en este prototipo. Generaci´on y rotaci´on manual de los identificadores. Debido a la planificaci´on prevista, no ha sido posible implementar un contador que generase y gestionase los identificadores en segundo plano. Para la realizaci´on de las pruebas, en caso de necesitar esta funcionalidad, se simula la rotaci´on empleando diferentes versiones, cada una con un identificador distinto. Cambio manual de estado de Contagiado aSin contactos tras 14 d´ıas. Debido al tiempo del que se dispon´ıa, se decidi´o realizar el cambio de estado tras 14 d´ıas de Contagiado aSin contactos cada vez que se reiniciase la aplicaci´on. De otro modo, deber´ıa mantenerse la aplicaci´on activa en todo momento en segundo plano, para que pasados los 14 d´ıas cambiase el estado. Otro modo ser´ıa realizarlo tan solo al abrir la aplicaci´on, comprobando la fecha, pero esto falsear´ıa realmente el borrado tras 14 d´ıas, pudiendo ser m´as de no abrirse la aplicaci´on transcurrido exactamente ese tiempo. Eliminado manual de los identificadores con fecha extinta. Debido al tiempo del que se dispon´ıa, se decidi´o realizar el borrado en el servidor de manera manual desde la consola de MariaDB, mediante el comando: DELETE FROM ids_infectados WHERE CURDATE()-fecha_rec > 14; Intensidad de la se˜nal de Bluetooth predeterminada. Debido al tiempo del que se dispon´ıa, se decidi´o dejar la distancia predeterminada, pues para realizar los casos de prueba y el an´alisis de privacidad, esta no iba a influenciar. Pareado manual previo al intercambio de identificadores v´ıa Bluetooth. El pareado se realiza desde Ajustes del tel´efono. Tras varios intentos sin ´exito de programar el pareado para que la aplicaci´on lo realizase autom´aticamente, se decidi´o no dedicar m´as tiempo a esto para evitar afectar a la planificaci´on. Ya que el realizar el pareado dentro o fuera de la aplicaci´on no era algo fundamental para poder realizar las pruebas de intercambio de identificadores, se decidi´o hacer de manera manual. Escuela de Ingenier´ıa Inform´atica 69 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Simplificaci´on del proceso de cifrado de los datos que viajan por red. La idea original es que, con cada intercambio de informaci´on entre cliente y servidor, se realice el siguiente cifrado. El servidor poseer´a un par clave p´ublica-privada. A su vez, el cliente generar´a una clave sim´etrica AES256. Cuando el cliente realice una conexi´on TCP con el servidor, este le enviar´a al cliente su clave p´ublica, con la que el cliente podr´a cifrar la clave sim´etrica para envi´arsela al servidor y as´ı comenzar a intercambiar la informaci´on cifrada. En el prototipo de la aplicaci´on desarrollado, se establecer´a manualmente una clave sim´etrica entre servidor y cliente para realizar las pruebas y an´alisis. Esta clave ser´a constante y no viajar´a por la red. Al trabajar con CFB, modo de cifrado que necesita de un Vector de Inicializaci´on, este tambi´en estar´a fijado, para asegurar mismos resultados en ambos lados de la aplicaci´on, cliente y servidor. De nuevo, esto es una medida tomada con el fin de simplificar el proceso de cifrado en el prototipo. No retroalimentaci´on sobre si el env´ıo del c´odigo es o no correcto. El servidor no enviar´a al cliente un mensaje de retroalimentaci´on sobre si el c´odigo es o no es correcto. Esta funcionalidad, si bien ser´ıa clave cara a una aplicaci´on con una buena usabilidad, se ha prescindido cara al posterior an´alisis de privacidad. No implementaci´on de la notificaci´on al usuario. Dado que no es una funcionalidad fundamental para el prototipo, se ha prescindido de que la aplicaci´on avise al usuario mediante una notificaci´on cuando haya un cambio de estado. Escuela de Ingenier´ıa Inform´atica 70 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5. Casos de prueba El objetivo de las pruebas software es comprobar que la aplicaci´on cumple con los requisitos que se han dictaminado en la Fase de An´alisis. Aunque se pueden clasificar de diversas formas, las principales clases de prueba son pruebas de caja negra y pruebas de caja blanca. Como a˜nadido, se pueden categorizar dependiendo de qu´e aspecto se est´a probando. En este caso, se han clasificado en pruebas de caja negra y caja blanca, y dentro de estas funcional y no funcional. Las pruebas englobar´an pruebas de seguridad, de disponibilidad, de interacci´on y de comunicaci´on Bluetooth, UDP y TCP. 5.1. Pruebas de caja negra Las pruebas de caja negra son aquellas que se realizan sin saber la especificaci´on de c´omo se ha hecho aquello que se prueba, en otras palabras, solo nos interesa ver qu´e salidas o outputs producen las entradas o inputs que se introducen en el software. Las pruebas se consideran correctas cuando se obtiene el resultado esperado, cumpliendo los requisitos previamente definidos. En caso contrario, se detallan los errores obtenidos y c´omo se solucionaron hasta obtener el resultado deseado. 5.1.1. Intercambiar un ID entre dos dispositivos v´ıa BT en rango Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones Bluetooth Se inician dos dispositivos m´oviles y se activa Bluetooth en ambos. Despu´es, se parean de forma manual a trav´es del men´u de Ajustes de cada dispositivo. En un principio, este proceso previo se iba a realizar de forma autom´atica en la aplicaci´on. La idea inicial era hacerlo mediante c´odigo y sin pareado. Se consigui´o la detecci´on de los dispositivos, pero la aplicaci´on se cerraba en cuanto ocurr´ıa. Siguiendo la metodolog´ıa escogida, tras varios intentos sin ´exito se tom´o la decisi´on de realizar este proceso pareando los dispositivos y desvincul´andolos al terminar la operaci´on, pues investigando, se encontr´o que la comunicaci´on mediante dispositivos Bluetooth pareados se realiza mediante un canal cerrado.[10] Finalmente, al obtener los mismos resultados, se decidi´o optar por realizar el pareo de forma manual. Se inicia la aplicaci´on y se presiona el bot´on que se ha habilitado para realizar las pruebas Bluetooth. Los primeros resultados fueron negativos. Los dispositivos conectaban pero la aplicaci´on se cerraba al instante. Esto era debido a un mal uso de las funciones Bluetooth, en concreto cancelDiscovery(), pues se situ´o en un lugar err´oneo del c´odigo. Posterior a ello, debido a cambios anteriores, hab´ıa quedado una conexi´on insegura de Bluetooth, realizada mediante listenUsingInsecureRfcommWithServiceRecord ycreateInsecureRfcommSocketToServiceRecord. Debido a esto se produc´ıa una incoherencia, pues ese tipo de conexi´on permite conectar dispositivos sin previo pareado, cuando la aplicaci´on funciona mediante dispositivos pareados. Tras realizar la conexi´on en modo seguro de nuevo, uno de los dispositivos recibi´o el mensaje con los identificadores de manera correcta, manteniendo la aplicaci´on abierta. Escuela de Ingenier´ıa Inform´atica 71 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Figura 28: Intercambio de ID entre dispositivos 5.1.2. Intercambiar un ID entre dos dispositivos v´ıa BT en el l´ımite del rango Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones Bluetooth Se inician dos dispositivos m´oviles con Bluetooth activado. Tras ello se realiza el pareado manual a trav´es del men´u de Ajustes del tel´efono. A continuaci´on, se busc´o el l´ımite del rango que alcanza la se˜nal de Bluetooth. Inicialmente se calcul´o mal y se realiz´o desde una distancia m´as cercana. Se fue buscando el punto l´ımite hasta que se perd´ıa la se˜nal. Una vez encontrado el punto l´ımite se realiz´o el env´ıo de un identificador. En el dispositivo que actuaba como servidor apareci´o el mensaje de Conectado, pero no lleg´o el identificador. Este resultado es l´ogico, pues la recepci´on de la conexi´on ocupa menos slots que el propio identificador. Esto se debe a que el mensaje se divide en m´ultiples slots que son enviados y por lo tanto la p´erdida de uno es m´as probable, haciendo que el mensaje ya no llegue completo y correctamente.[61] Escuela de Ingenier´ıa Inform´atica 72 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.1.3. Intercambiar un ID entre dos dispositivos v´ıa BT fuera de rango Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones Bluetooth Se inician dos dispositivos con Bluetooth activado. Estos se parean manualmente desde la secci´on de Ajustes del sistema. Tras ello, se inicia la aplicaci´on, y estando los dispositivos lo suficientemente alejados, se realiza un env´ıo. Como era de esperar, no se recibe ning´un tipo de se˜nal. 5.1.4. Intercambiar un ID entre dos dispositivos v´ıa BT y desconectarse justo en el momento del env´ıo Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones Bluetooth Se inician dos dispositivos con Bluetooth activado. Se parean desde Ajustes del tel´efono de manera manual. Tras ello, se inicializa la aplicaci´on y se pulsa el bot´on de env´ıo de identificador. En el momento en el que en el dispositivo que act´ua como servidor aparece el mensaje de Conectado, se desactiva Bluetooth del dispositivo que act´ua como cliente. Como era de esperar, la conexi´on se interrumpe, no lleg´andose a enviar el mensaje con el identificador, por lo que el servidor no recibe la informaci´on. 5.1.5. Intercambiar un ID entre dos dispositivos v´ıa BT y desconectarse justo 1 segundo antes del momento del env´ıo Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones Bluetooth Se inician dos dispositivos con Bluetooth activado. Se parean desde Ajustes del sistema de manera manual. Tras ello, se inicializa la aplicaci´on y se pulsa el bot´on de env´ıo de identificador. Inicialmente aparecen los mensajes de creaci´on de los sockets, mensajes dispuestos a modo de comprobar su correcto despliegue en la aplicaci´on prototipo. Una vez ambos dispositivos han creado el socket correspondiente para comunicarse entre s´ı, se desconecta Bluetooth. Debido a ello, como era de esperar, se obtiene el mensaje de Conexi´on fallida, pues no se llega a establecer la conexi´on entre dispositivos. Escuela de Ingenier´ıa Inform´atica 73 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.1.15. Env´ıo con fecha anterior a 14 d´ıas Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Usabilidad Se abre la aplicaci´on estando el dispositivo conectado a Internet. Tras ello, dentro de la aplicaci´on se selecciona Comunica tu positivo y se rellenan los datos. La fecha solo permite seleccionar aquellas fechas entre la actual y 14 d´ıas atr´as. Con esta restricci´on se impide el env´ıo de identificadores con fecha inv´alida al servidor, logr´andose el caso de prueba correctamente. Figura 33: L´ımite anterior de aceptaci´on de fechas Escuela de Ingenier´ıa Inform´atica 80 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.1.16. Env´ıo con fecha posterior a 14 d´ıas Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Usabilidad Al igual que en el caso anterior, la aplicaci´on cliente solo permite la selecci´on de fechas 14 d´ıas anteriores a la actual. Con ello se impide el env´ıo de identificadores con fechas futuras. Figura 34: L´ımite posterior de aceptaci´on de fechas 5.1.17. Multicast de IDs infectados desde el servidor a los clientes Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones UDP Para realizar el env´ıo de identificadores, se activa el servidor. De manera peri´odica realiza un env´ıo multicast del contenido de su base de datos, el cual es las claves y fechas generadoras asociadas a identificadores contagiados. Escuela de Ingenier´ıa Inform´atica 81 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Inicialmente el env´ıo no funcionaba correctamente, pues se empleaba una direcci´on IP para multicast fuera del rango de las reservadas para ello (es decir, las comprendidas entre la 224.0.0.0 hasta la 239.255.255.255). Una vez se asign´o una direcci´on de multicast correcta, se pudo comprobar empleando un sniffer de paquetes (Wireshark), que el env´ıo y la petici´on de uni´on a dicha direcci´on se realizaba correctamente y de manera peri´odica. 5.1.18. Uso de la aplicaci´on sin conexi´on a Internet (y sin recepci´on de multicast) Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Disponibilidad Se abre la aplicaci´on y nada m´as ejecutarse sale el siguiente aviso en pantalla: Figura 35: Aviso de desconexi´on De este modo, la aplicaci´on nos comunica que no est´a conectada a una red WiFi. Debido a ello algunas funciones no podr´an realizarse, como es el env´ıo de un c´odigo al servidor o la recepci´on de multicast. Escuela de Ingenier´ıa Inform´atica 82 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Sin embargo, se puede navegar por la aplicaci´on y esta no se queda colgada. Figura 36: Aplicaci´on ejecut´andose correctamente Del mismo modo, las conexiones Bluetooth se pueden realizar correctamente. El funcionamiento es el esperado, pues al no haber conexi´on a Internet, es l´ogico que las funcionalidades dependientes de la red no puedan llevarse a cabo. Por otro lado, aquellas que no dependen de una conexi´on a Internet siguen funcionando correctamente. Escuela de Ingenier´ıa Inform´atica 83 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.1.19. Recepci´on por multicast de un ID infectado que se encuentra en la base de datos local Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones UDP Teniendo el servidor activado realizando el env´ıo peri´odico, se abre la aplicaci´on, estando el dispositivo conectado a Internet. Para la comprobaci´on de la recepci´on del multicast se genera un peque˜no mensaje en el cual se avisa con un texto de la recepci´on de un paquete desde una direcci´on IP. Inicialmente la recepci´on no funcionaba debido a que la direcci´on empleada dentro del rango de direcciones multicast no era para redes internas. Tras cambiarla una vez m´as, la recepci´on funcionaba pero el resto de funcionalidades se bloqueaban. Para solucionarlo se crearon dos hilos de ejecuci´on, uno para la recepci´on del multicast y otro para las funcionalidades de la aplicaci´on. Tras separar el hilo de ejecuci´on de cada proceso, la recepci´on del multicast dejaba de bloquear a las dem´as funcionalidades de la aplicaci´on. De este modo el funcionamiento es el correcto, pudiendo recibir multicast de manera peri´odica a la vez que se permite el uso de la aplicaci´on correctamente. Una vez se recibe este multicast, se obtiene la lista de claves y fechas generadoras, se calculan los identificadores y se comparan con los almacenados en la base de datos local, en concreto los de la tabla ids ajenos. Se encuentra una coincidencia y con ello se cambia el valor de la variable que define el estado de contagio. Una vez cambiado, la imagen y los textos de la pantalla principal cambian al estado Con contactos contagiados. Escuela de Ingenier´ıa Inform´atica 84 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Figura 37: Aplicaci´on ejecut´andose correctamente 5.1.20. Recepci´on por multicast de IDs infectados y ninguno se encuentra en la base de datos local Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones UDP Teniendo el servidor activado realizando el env´ıo peri´odico, se abre la aplicaci´on, estando el dispositivo conectado a Internet. Para la comprobaci´on de la recepci´on del multicast se genera un toast, en el cual se avisa con un texto de la recepci´on de un paquete desde una direcci´on IP. Una vez se recibe este multicast, se obtiene la lista de claves y fechas generadoras, se calculan los identificadores y se comparan con los almacenados en la base de datos local, en concreto los de la tabla ids ajenos. Al no encontrarse ninguna coincidencia, no cambia el valor de la variable de contagio, permaneciendo en sin contactos. El caso de prueba acaba con ´exito. Escuela de Ingenier´ıa Inform´atica 85 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.1.21. Recepci´on por multicast de IDs infectados y ninguno se encuentra en la base de datos local, pero el ID es un n´umero por encima de uno almacenado Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones UDP Teniendo el servidor activado realizando el env´ıo peri´odico, se abre la aplicaci´on, estando el dispositivo conectado a Internet. Para la comprobaci´on de la recepci´on del multicast se genera un toast, en el cual se avisa con un texto de la recepci´on de un paquete desde una direcci´on IP. Una vez se recibe este multicast, se obtiene la lista de claves y fechas generadoras, se calculan los identificadores y se comparan con los almacenados en la base de datos local, en concreto los de la tabla ids ajenos. Al no encontrar ninguna coincidencia, pues el identificador generado con la clave y la fecha ha de ser exacto a alguno de los almacenados para detectar un contacto, no cambia el valor de la variable de contagio, permaneciendo en sin contactos. El caso de prueba acaba con ´exito. 5.1.22. Recepci´on por multicast de IDs infectados y ninguno se encuentra en la base de datos local, pero el ID es un n´umero por debajo de uno almacenado Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones UDP Teniendo el servidor activado realizando el env´ıo peri´odico, se abre la aplicaci´on, estando el dispositivo conectado a Internet. Para la comprobaci´on de la recepci´on del multicast se genera un toast, en el cual se avisa con un texto de la recepci´on de un paquete desde una direcci´on IP. Una vez se recibe este multicast, se obtiene la lista de claves y fechas generadoras, se calculan los identificadores y se comparan con los almacenados en la base de datos local, en concreto los de la tabla ids ajenos. Al no encontrar ninguna coincidencia, pues el identificador generado con la clave y la fecha ha de ser exacto a alguno de los almacenados para detectar un contacto, no cambiar´ıa el valor de la variable de contagio, permaneciendo en sin contactos. El caso de prueba acaba. Escuela de Ingenier´ıa Inform´atica 86 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.1.23. Recepci´on por multicast de IDs infectados y no se posee ning´un ID en la base de datos local con los que comparar Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones UDP Teniendo el servidor activado realizando el env´ıo peri´odico, se abre la aplicaci´on, estando el dispositivo conectado a Internet. Para la comprobaci´on de la recepci´on del multicast se genera un toast, en el cual se avisa con un texto de la recepci´on de un paquete desde una direcci´on IP. Una vez se recibe este multicast, se obtiene la lista de claves y fechas generadoras, se calculan los identificadores y se procede a comparar con la base de datos local. Esta, al estar vac´ıa, no devuelve nada y por lo tanto no se encuentran coincidencias. Tras esto, el caso de prueba termina exitoso sin realizar ning´un cambio en la interfaz. 5.1.24. Env´ıo del multicast pero sin recepci´on (clientes inactivos) Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones UDP Se inicia el servidor, conectado a la red, pero sin abrir la aplicaci´on cliente en ning´un momento. El servidor realiza de manera peri´odica, un env´ıo a la direcci´on IPv4 del grupo de multicast con la informaci´on de las claves y fechas generadoras de los identificadores contagiados. Tambi´en, de manera peri´odica hace un llamamiento a que los dispositivos de dicho grupo se unan a ´el. Estos env´ıos se realizan sin necesidad de que haya clientes de dicho grupo de multicast conectados. El resultado es el esperado, pues es necesario que este env´ıo se realice en todo momento para que siempre puedan unirse nuevos clientes cuando se conecten a la red. 5.1.25. Escucha, por parte del cliente, de multicast pero sin env´ıo (servidor inactivo) Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Disponibilidad Se inicia la aplicaci´on cliente, con conexi´on a la red. La espera para recepci´on de paquetes v´ıa multicast se queda en segundo plano, y el resto de la aplicaci´on funciona correctamente, permitiendo su uso. La aplicaci´on no env´ıa nada por red, como era de esperar, manteni´endose a la escucha de paquetes multicast de su grupo. Escuela de Ingenier´ıa Inform´atica 87 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.1.26. Cambio de idioma Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Usabilidad Se inicia la aplicaci´on y se va a la pantalla de Ajustes de idioma. Una vez ah´ı, se selecciona el idioma al que se desea cambiar. En este caso, seleccionamos Ingl´es. Una vez pulsado Aceptar, la aplicaci´on se reinicia, haciendo un breve pesta˜neo. Tras ello, el idioma de los textos aparece cambiado al ingl´es. Figura 38: Aplicaci´on en ingl´es Escuela de Ingenier´ıa Inform´atica 88 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.2. Pruebas de caja blanca Las pruebas de caja blanca son aquellas dise˜nadas con conocimiento profundo del software. Esto nos permite comprobar funcionalidades concretas del propio software, como por ejemplo comprobar el nivel de seguridad de la aplicaci´on desarrollada. 5.2.1. Escucha del canal de conexi´on en el momento de env´ıo de un c´odigo con los IDs al servidor Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Seguridad Se abre la aplicaci´on estando el dispositivo conectado a Internet. Tras ello, dentro de la aplicaci´on se selecciona Comunica tu positivo y se rellenan los datos. Se inicia un programa de sniffing y se env´ıa el c´odigo desde la aplicaci´on. Figura 39: Resultado del programa de sniffing El resultado nos dice que el mensaje que env´ıa la aplicaci´on viaja cifrado y que por tanto est´a salvo de observadores externos. Escuela de Ingenier´ıa Inform´atica 89 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 5.2.7. Inyecci´on de c´odigo desde la aplicaci´on cliente Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Seguridad Existen dos v´ıas para la posible inyecci´on de c´odigo: Campo de selecci´on de fecha. Aqu´ı el usuario puede seleccionar una fecha de un calendario que aparece cuando hace click, denegando la posibilidad de escribir caracteres de forma libre. Como esto ocurre siempre que se quiere cambiar este campo no es posible inyectar ning´un tipo de c´odigo. Campo de introducci´on de c´odigo de contagio. En este campo se le pide introducir un c´odigo al usuario. Los caracteres est´an restringidos tal que solo se admiten d´ıgitos. De este modo se bloquea la posibilidad de escribir inyecciones de c´odigo en la base de datos del servidor, pues no es posible introducir caracteres tales que %para especificar caracteres v´ıa c´odigo URL, buscando nombres o direcciones, u otros admitidos en el lenguaje SQL (guiones, comillas...). Escuela de Ingenier´ıa Inform´atica 96 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 6. An´alisis de riesgos de seguridad y privacidad En este apartado se procede a realizar el an´alisis de riesgos a la aplicaci´on realizada. De este modo se busca detectar aquellas malas pr´acticas en el tratamiento de los datos, as´ı como la implementaci´on de salvaguardas y medidas necesarias para contrarrestarlas Tambi´en se resaltan aquellas ventajas y desventajas de una aplicaci´on de rastreo de contactos frente a otras opciones existentes para el control del estado COVID, as´ı como comparar sus posibilidades y el nivel de protecci´on de los datos que puede llegar a garantizar. 6.1. Estado del arte: Seguridad y Privacidad Para elaborar este an´alisis primeramente se presenta el Estado del Arte referente a la seguridad y privacidad a nivel europeo. En este se tratar´an aquellos puntos propios del RGPD que afecten a componentes de la aplicaci´on aqu´ı desarrollada como son por ejemplo, las comunicaciones Bluetooth o las aplicaciones m´oviles. Tambi´en se realiza un especial enfoque en la situaci´on de la Uni´on Europea, ´area abarcada por la normativa del RGPD, con respecto a las aplicaciones de rastreo de contactos y otras alternativas existentes para el control del estado COVID. 6.1.1. Reglamento General de Protecci´on de Datos El Reglamento General de Protecci´on de Datos es el reglamento en vigor dentro de la Uni´on Europea, relativo a la privacidad, circulaci´on y protecci´on de los datos de las personas f´ısicas. Por ello, cualquier instituci´on, p´ublica o privada, que o bien pertenezca a la Uni´on Europea o bien trate con ella, debe cumplirlo.[59] Entr´o en vigor el 24 de mayo de 2016, momento en el que las empresas tuvieron que ir adapt´andose a este, con fecha l´ımite el 25 de mayo de 2018, a partir de la cual se ha estado aplicando. El RGPD ha dado directrices respecto a diversos ´ambitos que se ven involucrados en el desarrollo de aplicaciones de rastreo de contactos. Una de ellas es entorno a las aplicaciones m´oviles, que al estar en dispositivos que siempre llevamos con nosotros, han de tratarse con ciertos matices. La normativa general implica que deben especificarse los tratamientos de los datos en todos los aspectos, es decir, su recolecci´on, conservaci´on, respaldo, uso, posibilidad de modificaci´on, comunicaci´on, archivo y su destrucci´on. El cliente debe poder en todo momento ejercer sus derechos de borrado y modificaci´on de esos datos. Dentro del mundo de las aplicaciones m´oviles esto, por supuesto, no es excepci´on. La normativa del RGPD ha de aplicarse a cualquier aplicaci´on m´ovil que recolecte datos de los ciudadanos europeos y eso incluye la aplicaci´on aqu´ı desarrollada que, adem´as, trata con informaci´on sensible como son datos de salud. Son por ello los aspectos que van a ser analizados. Consentimiento expl´ıcito por parte de los usuarios para recolectar sus datos personales. Protecci´on de datos por dise˜no y por defecto. Acceso del usuario a los datos recolectados. Derecho de los usuarios a la portabilidad de los datos. Derecho al olvido. Implementaci´on de las reglas de forma estricta. Derecho del usuario a conocer cu´ando se han violado los datos personales. Escuela de Ingenier´ıa Inform´atica 97 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Consentimiento expl´ıcito Esta normativa viene marcada por el ((Consideraci´on 42 Pruebas y Requisitos para el Consentimiento)) del Reglamento General de Protecci´on de Datos. Se ha de proporcionar consentimiento de forma activa, informando sobre qu´e datos se recolectar´an, antes de recoger y procesar esa informaci´on personal de los usuarios. De esta forma la instituci´on due˜na de la aplicaci´on, debe de ser capaz de demostrar que tiene el consentimiento del sujeto cuyos datos se est´an recopilando, al igual que el usuario debe ser consciente del tratamiento de datos que se hace. La manera en la que se solicita el consentimiento debe ser en un lenguaje conciso, accesible y con t´erminos claros. Adem´as, el usuario debe ser consciente de la identidad del sujeto que recopilar´a su informaci´on. Este consentimiento debe poder darse de manera libre, es decir, por elecci´on propia del usuario, con posibilidad de rechazarlo y de modificarlo posteriormente.[72] Derechos de los individuos Adem´as del consentimiento, los usuarios de aplicaciones m´oviles tienen derechos adicionales sobre el control y tratamiento de los datos. Estos deben ser mencionados en la Pol´ıtica de Privacidad de la aplicaci´on. Son los siguientes. Derecho al acceso a los datos recolectados En el Art´ıculo 15 ((Derecho de acceso del interesado)) del RGPD se dictamina este derecho.[67] El usuario debe poder conocer los siguientes puntos adem´as de qu´e datos se est´an recolectando: El prop´osito del procesamiento. Las categor´ıas de los datos personales recopilados. Los destinatarios o categor´ıas de destinatarios a los que estos datos ser´an comunicados, sobre todo si se tratan de pa´ıses terceros u organizaciones internacionales. Periodo durante el cual los datos ser´an almacenados. La existencia del derecho a borrar los datos o restringir el procesamiento de los datos. El derecho a presentar una queja ante una autoridad supervisora. Si no se recopilan datos personales directamente del usuario, fuentes de datos del mismo a las que tengan acceso. La existencia de toma de decisiones automatizadas, como la elaboraci´on de perfiles. Se debe dejar a disposici´on del usuario la l´ogica que emplea el programa que toma dichas decisiones. En caso de que se traspasen datos a otros pa´ıses, el usuario debe ser consciente de ello. Este debe poder acceder a los datos que se est´an recopilando, y el derecho a obtener esta copia no debe afectar los derechos o libertades de otros. Escuela de Ingenier´ıa Inform´atica 98 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Derecho a restringir el procesamiento de datos Acorde al art´ıculo 18 ((Derecho a la limitaci´on del tratamiento)) del RGPD, los usuarios tienen el derecho a restringir el tratamiento de sus datos si se da alguno de los siguientes casos.[66] Los datos son incorrectos. El procesamiento es ilegal. Los datos no se necesitan para el prop´osito originalmente estipulado. El individuo se opone al procesamiento de sus datos. El derecho a la portabilidad de los datos En el caso de que los datos sean tratados de manera automatizada, los usuarios tienen el derecho a la portabilidad de sus datos. Esto significa que tienen el derecho a transmitirlos a otras aplicaciones m´oviles o negocios sin que interfiera la aplicaci´on que originalmente los ha recolectado. Este usuario tambi´en puede solicitar que la aplicaci´on original transmita esos datos a otra, y esto ha de cumplimentarse siempre y cuando no se viole la ley. Derecho a oponerse a la recolecci´on de sus datos En el art´ıculo 21 ((Derecho de oposici´on)) del RGPD[68] se describe el derecho a solicitar que la aplicaci´on deje de procesar sus datos si se usan para alguno de los siguientes fines: Procesamiento para la elaboraci´on de perfiles. Marketing directo. Procesamiento para investigaci´on cient´ıfica, estad´ıstica o hist´orica. Derecho a la rectificaci´on El art´ıculo 16 ((Derecho de rectificaci´on)) del RGPD[69] dictamina que los usuarios deben tener el derecho a poder rectificar datos incorrectos referentes a su informaci´on personal. El c´omo ejercer este derecho debe ser explicado en la Pol´ıtica de Privacidad. Principio de transparencia El principio de transparencia implica que los usuarios han de estar en posesi´on del derecho a ser informados. Esto implica que han de ser conscientes de qu´e datos se est´an recolectando y con qu´e fines. Esta informaci´on debe ser accesible de manera sencilla y gratuita, y ser f´acil de comprender. Este derecho es definido en la consideraci´on n´umero 58 ((Principio de transparencia)) del RGPD.[71] Especial atenci´on en el caso de los ni˜nos, donde, si el comunicado fuera dirigido a ellos, deber´ıa emplearse un lenguaje que puedan entender. Escuela de Ingenier´ıa Inform´atica 99 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Derecho al borrado El derecho al borrado o al olvido implica que el usuario, en caso de que sus datos ya no sean necesarios para el prop´osito para el que hab´ıan sido recolectado, pueda solicitar su borrado. Tambi´en podr´an ejercer su derecho en caso de que los datos se traten de manera ilegal. 6.1.2. Delegado de Protecci´on de Datos En algunos casos, ser´a necesario contar con un Delegado de Protecci´on de Datos, que se encargar´a de que se cumpla debidamente la legislaci´on. [34] Es necesario contar con uno si: Se es una entidad p´ublica. Se procesan y monitorizan datos de ciudadanos de la Uni´on Europea de manera regular. Se tratan con categor´ıas especiales de datos personales o datos personales relacionados con antecedentes criminales u ofensas. 6.1.3. Seguridad de los datos El RGPD dictamina que los controladores y procesadores de datos deben asegurar la privacidad y seguridad de los datos. Esto incluye el uso de algoritmos criptogr´aficos actualizados. El art´ıculo 32 del RGPD, ((Seguridad del tratamiento)), tambi´en recomienda el uso de pseud´onimos a modo de identificar a los usuarios.[74] Los propietarios de la aplicaci´on deben asegurar la confidencialidad, integridad, disponibilidad y resiliencia de aquellos sistemas que procesen los datos. En caso de un incidente, el procesador de datos debe restaurar la disponibilidad de los datos cuanto antes. 6.1.4. Evaluaci´on de Impacto de Protecci´on de Datos Una Evaluaci´on de Impacto de la Protecci´on de Datos, como la que se elaborar´a m´as adelante en este proyecto, es una evaluaci´on de los riesgos existentes de que se produzca una infracci´on de seguridad. Se debe realizar a todas las aplicaciones, con especial prioridad aquellas que traten datos sensibles de los usuarios. En caso de suceder una brecha de informaci´on, el controlador de datos debe informar inmediatamente a los usuarios y autoridades. Tambi´en se ha de poseer un plan de contingencia y actuaci´on, en el que se defina c´omo actuar en caso de que se produzca una brecha de datos. 6.1.5. Uni´on Europea y aplicaciones de rastreo de contactos La pandemia cre´o una situaci´on ideal para la recolecci´on de datos de usuarios. Es por ello, que lo m´as esperado hubiera sido crear protocolos que abiertamente hubiesen sido cien por cien centralizados, y hubiesen tratado a los usuarios como productos. Sin embargo, no fue directamente as´ı. La idea inicial fue crear un protocolo que emplease pseud´onimos para identificar a los usuarios y as´ı preservar su informaci´on. Escuela de Ingenier´ıa Inform´atica 100 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Aun as´ı, este protocolo comenz´o a tener el apoyo de empresas como Google y Apple, los cuales comenzaron a implementar ciertos requisitos debido a sus pol´ıticas de desarrollo que, al final, no ayudaron a que estas aplicaciones fuesen del todo privadas. Requisitos como el uso de la geolocalizaci´on a la vez que Bluetooth Low Energy o la existencia de balizas que se comunican v´ıa BLE con los dispositivos m´oviles para recolectar datos. Aun as´ı, inicialmente la Uni´on Europea luch´o por mantener este protocolo lo m´as respetuoso con la privacidad posible e, inicialmente, se convirti´o en una soluci´on esperanzadora.[39] Una de las aplicaciones de rastreo de contactos que adopt´o el extendido protocolo DP-3T fue StopCOVID, propuesta en Francia. Los miembros de la Commission Nationale de l’Informatique et des Libert´es (CNIL) hicieron p´ublica su opini´on sobre la aplicaci´on de rastreo de contactos StopCOVID el d´ıa 24 de abril de 2020.[18] Indic´o que, dada la situaci´on excepcional de crisis pand´emica, la aplicaci´on pod´ıa ser recomendable siempre y cuando cumpliera una serie de requisitos t´ecnicos y de privacidad. Adem´as, la aplicaci´on deb´ıa pertenecer a una estrategia general de salud y su utilidad deb´ıa ser demostrada. Posteriormente, la aplicaci´on fue presentada ante el parlamento franc´es, donde en caso de ser aprobada, la CNIL volver´ıa a analizarla para examinar su implementaci´on. Finalmente la aplicaci´on fue aprobada, aunque origin´o diversos debates. Incluso lleg´o a haber a una actualizaci´on, TousAntiCovid, mejorada con acceso a informaci´on de salud y basada en evidencias sobre la pandemia.[32] La CNIL en 2020 admiti´o el uso de este tipo de aplicaciones, pues se han dise˜nado con el concepto de protecci´on de datos por dise˜no, utilizando identificadores an´onimos a modo de pseud´onimos de los usuarios. Adem´as, tampoco permiten recuperar listas de personas contaminadas, pues los identificadores almacenados en el servidor siempre permanecer´an anonimizados. Sin embargo, a lo largo del a˜no comenzaron a surgir problemas con el protocolo. El primero, en octubre de 2020, implicaba que las aplicaciones dise˜nadas con DP-3T solo pose´ıan tr´afico de datos direcci´on cliente a servidor en el momento de notificar un contagio. De este modo, mediante un ataque de escucha, se pod´ıa identificar aquel tr´afico de datos que solo se originaba desde clientes contagiados. De este modo, pod´ıa averiguarse qu´e usuarios hab´ıan dado positivo en una PCR. Este problema se solucion´o r´apidamente, generando ruido que se env´ıa de forma aleatoria desde todos los dispositivos clientes al servidor. Sin embargo, debido a la poca acogida que estas aplicaciones tuvieron a lo largo de los dos a˜nos, 2020 y 2021, la Uni´on Europea comenz´o a investigar soluciones alternativas. Los ciudadanos no parec´ıan muy contentos con las aplicaciones de rastreo de contactos y muy pocos realmente la llevaban activa en el m´ovil. Este hecho, unido a que la aplicaci´on necesita comunicarse con otros dispositivos con la aplicaci´on para intercambiar los identificadores, imposibilita totalmente el que la aplicaci´on logre su cometido.[33] Esto se vio propiciado tambi´en debido a los cambios en las necesidades en torno al estado COVID. Mientras que en el primer a˜no de la pandemia se buscaba romper cadenas de contagio, comunicando a los ciudadanos cu´ando hab´ıan mantenido contacto con una posible persona contagiada; actualmente, en 2021, se busca conocer qu´e personas est´an vacunadas, cu´ando lo han hecho, cu´antas dosis han recibido, si han pasado la enfermedad... Todo ello con el objetivo de controlar qu´e poblaci´on est´a ya inmunizada. Este nuevo enfoque ha ocasionado que, a lo largo del desarrollo de este proyecto, las aplicaciones de rastreo de contacto hayan perdido fuerza en la Uni´on Europea y en todo el mundo, dej´andose de fomentar su uso y buscando nuevas soluciones para los nuevos problemas. Escuela de Ingenier´ıa Inform´atica 101 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 6.1.6. Uni´on Europea y estado COVID Como se ha mencionado antes, las necesidades de la Uni´on Europea sobre el control del estado COVID de sus ciudadanos, ha variado mucho a lo largo de este a˜no. Inicialmente todo se centr´o en un plan de contingencia del virus y en la b´usqueda de maneras para frenar su expansi´on. Es por ello que en la Uni´on Europea se foment´o el desarrollo de protocolos de rastreo de contactos. Primeramente, el m´as popular fue el Pan-European Privacy-Preserving Proximity Tracing, un protocolo centralizado introducido el 1 de abril de 2020. Sin embargo, tan solo 19 d´ıas m´as tarde, el Centro Helmholtz para la Seguridad de la Informaci´on se retir´o p´ublicamente del consorcio debido a una ((falta de transparencia y gobernanza clara)) y preocupados por si el protocolo era lo suficientemente cauto con los datos de sus usuarios. Ese mismo 20 de abril se public´o la carta ya mencionada en el apartado sobre PEPP-PT/PEPP, donde m´as de 300 acad´emicos de seguridad y privacidad criticaron el enfoque de este protocolo, pues permit´ıa volver a obtener los datos anonimizados a partir de los pseud´onimos. Fue tras ello que el grupo formado por la ´ Ecole Polytechnique F´ed´erale de Lausanne, ETH Zurich, KU Leuven y el Institute for Scientific Interchange desarrollaron el protocolo Decentralized Privacy-Preserving Proximity Tracing. Este marc´o la diferencia siendo descentralizado, y a partir de ah´ı los subsiguientes protocolos seguir´ıan en su mayor´ıa, dentro de la Uni´on Europea, el paradigma descentralizado. Sin embargo, las necesidades han ido cambiando a lo largo del a˜no 2021, y con el desarrollo de las vacunas, ahora prima el control de datos sobre las dosis administradas. Es por ello que la Uni´on Europea busca otorgar a sus ciudadanos alg´un tipo de certificado donde se puedan consultar datos como tipo de vacuna, n´umero de dosis que ese individuo ha recibido, fecha, si ha pasado o no la enfermedad del COVID-19... De la mano de esta necesidad comienza a incentivarse la investigaci´on entorno a la Identidad Digital y la posibilidad de crear un sistema descentralizado donde los usuarios puedan ser realmente propietarios de sus datos. Estos se almacenar´ıan en sus propios dispositivos, de manera local, y se llevar´ıa ´unicamente un registro o hist´orico de las operaciones realizadas, anonimizando los datos de los involucrados y sin mostrar los datos presentados en ella. De este modo, la privacidad es absoluta, priorizando ante todo la minimizaci´on de los datos. El d´ıa 1 de junio de 2021, Ursula von der Leyen anunci´o que la Uni´on Europea busca otorgar a sus ciudadanos un nuevo modelo de identidad digital, descentralizado y privado, donde sean los usuarios propietarios de sus identidad.[57] El d´ıa 3 de junio de 2021, se anunci´o el soporte para esta identidad digital a trav´es del uso de wallets, o monederos digitales.[60] Esta identidad digital apunta al modelo de Self-Sovereign Identity. Con el modelo de Self-Sovereign Identity se logra un sistema descentralizado en el que el usuario es due˜no de sus datos, elige qu´e informaci´on quiere realmente compartir con qu´e proveedores de servicios y organizaciones, y permite emplear las mismas credenciales para identificarse ante cualquier sistema. Modelo Self-Sovereign Identity y Credenciales Verificables Este modelo para la gesti´on de la Identidad Digital consta de tres tipos de entidades, las cuales interact´uan entre s´ı mediante una serie de tokens y datos, llamados Credenciales Verificables y Presentaciones Verificables. Escuela de Ingenier´ıa Inform´atica 102 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Se trata de un modelo descentralizado, cuya aplicaci´on se da en la blockchain. Esta estructura almacena la informaci´on de las operaciones que se lleven a cabo en ella en m´ultiples nodos u ordenadores. De este modo, siempre se poseer´a una copia de ello, evitando la p´erdida de la informaci´on. Adem´as, la informaci´on almacenada refiere ´unicamente a los resultados de las operaciones, con las firmas digitales de los involucrados. De este modo se confirma su validez y el no repudio. Cada operaci´on se almacena en lo llamado un bloque, donde cada bloque, adem´as, posee una referencia a la informaci´on del anterior a modo de resumen hash. De esta manera, la informaci´on se vuelve inmutable, pues para cambiar el contenido de un bloque, habr´ıa que alterar el contenido de todos los bloques subsiguientes. Las Credenciales Verificables consisten en una serie de datos clave-valor sobre una entidad, en este caso modelados acorde al est´andar del World Wide Web Consortium sobre Credenciales Verificables. [77] Una de estas Credenciales Verificables pudiera ser la informaci´on del estado COVID de una persona, cuyos datos se modelan acorde al est´andar. Una iniciativa con mucho impulso que ya est´a trabajando en este tipo concreto de Credenciales Verificables es COVID Credentials Initiative (CCI).[21] CCI es una comunidad global abierta que colabora para estandarizar Credenciales Verificables del ´ambito de la salud. Buscan, ante todo, la preservaci´on de la privacidad y que los datos se generen, almacenen y administren a prueba de manipulaciones. Son miembros de la Linux Foundation Public Health (LFPH) desde diciembre de 2020, desarrollando especificaciones para dar a las Credenciales COVID un enfoque de c´odigo abierto basado en est´andares p´ublicos. Todo tipo de Credenciales Verificables se almacenan en una wallet o monedero digital del usuario, que funciona de manera local en su dispositivo de preferencia. Estas Credenciales Verificables permiten presentar los datos m´ınimamente necesarios para acceder a alg´un tipo de servicio. Esto se logra mostrando a la entidad solicitante ´unicamente cada dato solicitado y ninguno m´as. As´ı se evita mostrar informaci´on excesiva e innecesaria como, por ejemplo, cuando se muestra el DNI para demostrar la mayor´ıa de edad, donde adem´as se est´an ense˜nando datos como nombre,apellidos,fecha de nacimiento... Su validez se logra al ser firmadas por una entidad capacitada para ello. Para ello, dicha entidad hace uso de su clave privada, firmando el token representativo de la Credencial Verificable. Dentro del reglamento de electronic IDentification, Authentication and trust Services (eIDAS), es eIDAS Bridge el que otorga a dichas entidades la capacidad de ser cualificadas, para que su firma sea legalmente v´alida, y por lo tanto regulada. Pr´oximamente dicha regulaci´on se ver´a extendida con la llegada de eIDAS 2 y la regulaci´on de monederos digitales en la UE. [48] [29] El registro, no repudio y la imposibilidad de modificaci´on de estas se logra mediante la escritura de las mismas en el ledger o hist´orico de transacciones de la blockchain. Con ello la clave p´ublica y direcci´on de la entidad que las ha validado, as´ı como del usuario propietario de ellas, quedan visibles para todo el que quiera consultarlo. Para evitar abusos en el registro de la blockchain, la Uni´on Europea cuenta con una infraestructura blockchain privada y permisionada, donde cada pa´ıs miembro puede tener nodos. Esta es la European Blockchain Services Infrastructure o EBSI. Esta blockchain est´a especialmente dise˜nada para cumplir con todas las regulaciones y valores de la Uni´on Europea. [19] Por otro lado, las Presentaciones Verificables consisten en un conjunto de Credenciales Verificables, firmadas por el propio usuario. Estas se presentan a aquellos proveedores de servicios, los cuales verifican tanto la firma del usuario como la validez de las Credenciales Verificables presentadas. Las tres entidades que componen el sistema son las siguientes: Holder. Este tipo de entidades son los usuarios del sistema. Solicitan la creaci´on de Credenciales Verificables a un Issuer y las presentan dentro de una Presentaci´on Verificable a los Service Provider Escuela de Ingenier´ıa Inform´atica 103 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina oVerifiers. Todos los ciudadanos de la UE ser´ıan Holders en el sistema y contar´ıan con una identidad digital propia. Issuer. Este tipo de entidad est´a capacitada para emitir y firmar Credenciales Verificables de un nivel igual o inferior de confianza (Level of Assurance). Su firma est´a validada, bien por eIDAS (cualificados), bien por el sistema interno (autoproclamados). Aquellas Credenciales Verificables con su firma o certificado digital poseen validez ante un Service Provider. En el caso de Credenciales Verificables sobre el estado COVID estos Issuers ser´ıan entidades gubernamentales sanitarias cualificadas por eIDAS. Service Provider o Verifier. Son aquellas entidades que admiten Credenciales Verificables contenidas en Presentaciones Verificables. Se encargan de comprobar la validez de las mismas cercior´andose de que la firma adjunta sea la de un Issuer v´alido. Ofrecen servicios a los Holders, los cuales se identifican con las Credenciales Verificables m´ınimamente necesarias. Un Service Provider que pudiera solicitar las Credenciales sobre el estado COVID de un ciudadano puede ser, por ejemplo, una agencia de viajes en el momento de compra de un billete. Figura 46: Diagrama del modelo de Self-Sovereign Identity. Escuela de Ingenier´ıa Inform´atica 104 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 6.1.7. Commission Nationale de l’Informatique et des Libert´es La Commission Nationale de l’Informatique et des Libert´es o CNIL es una autoridad administrativa independiente, creada en 1978. Ejerce sus funciones acorde a la Ley de Protecci´on de Datos de Francia.[15] Debido a que Francia es pa´ıs miembro de la Uni´on Europea, el 13 de febrero de 2018, la Asamble Nacional de Francia aprob´o el Proyecto de Ley de Protecci´on de Datos para transponer a derecho nacional el Reglamento General de Protecci´on de Datos. Es por ello que la normativa de la CNIL va fuertemente ligada al RGPD en materias de privacidad de los datos. [6] El an´alisis que se va a llevar a cabo a la aplicaci´on desarrollada en este proyecto se har´a con una herramienta de la CNIL. La CNIL presenta una serie de recomendaciones y obligaciones en torno a las aplicaciones m´oviles, as´ı como conexiones Bluetooth, caracter´ısticas que posee esta aplicaci´on. Son las siguientes.[14] Respecto a las aplicaciones m´oviles de salud La CNIL, en su art´ıculo, a la hora de evaluar c´omo debiera afectar el RGPD al desarrollo de aplicaciones m´oviles de salud, primeramente se plantea si por definici´on entran en el ´ambito de aplicaci´on de la normativa sobre protecci´on de datos personales. Este planteamiento surge porque, en el caso de que la aplicaci´on m´ovil de salud registre y almacene datos personales para uso exclusivamente local, sin comunicaciones con el exterior, y con un fin solamente personal, la legislaci´on no aplicar´ıa. Aunque esto sea as´ı, el proveedor ha de garantizar al usuario que se cumplen las medidas m´ınimas de seguridad, para evitar riesgos relacionados con la invasi´on de la privacidad. Es por ello que la normativa se aplica a toda aquella aplicaci´on cuyos datos salgan al exterior, bien sea para prestar servicios remotos o bien porque posea conexiones de cualquier tipo con el exterior. Es por ello que la CNIL para estos casos dictamina que las aplicaciones m´oviles de salud con dichas caracter´ısticas han de cumplir los puntos marcados por el Reglamento General de Protecci´on de Datos. Esto incluye, entre otros, el an´alisis de impacto en la privacidad. La CNIL propone diversos fines que una aplicaci´on m´ovil de salud puede tener que necesitan cumplir el RGPD. La aplicaci´on aqu´ı desarrollada posee los siguientes. Ayudar al usuario en el seguimiento de su propia salud. Pues la aplicaci´on le informa sobre su estado de contagio, as´ı como de posibles contactos contagiados. Tener mejor control sobre la propia salud. Debido a los consejos que aparecen en pantalla para evitar entrar en contacto con el virus, tener cuidado en cuarentena o en caso de contacto contagiado; la aplicaci´on podr´ıa cumplir en parte con este fin. Cabe destacar que, si bien la aplicaci´on aqu´ı desarrollada no comparte los datos entre diversas autoridades sanitarias, algunas aplicaciones de rastreo de contactos son interoperables. Este es otro caso que la CNIL considera. Lo primeramente remarcado, es que los fines para los que los datos van a procesarse deben ser leg´ıtimos, expl´ıcitos y espec´ıficos. No pueden a˜nadirse fines a posteriori, menos si son incompatibles con los anteriores. Estos prop´ositos deben hacerse antes del dise˜no de la aplicaci´on, para evaluar qu´e datos son realmente necesarios. En el caso de la aplicaci´on del proyecto, como se especifica en los Requisitos de Informaci´on de la Escuela de Ingenier´ıa Inform´atica 105 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina La primera es la zona de la izquierda con los pasos que se ir´an tomando a lo largo del desarrollo del an´alisis. Por el momento solo se puede avanzar a la edici´on de uno de los pasos siguientes al actual (Contexto) una vez se hayan completado todos los apartados del mismo. Figura 51: Pasos para el an´alisis PIA. En la zona de la derecha aparece un men´u informativo. Aqu´ı aparecen aquellas regulaciones, observaciones, definiciones... Que el RGPD y la CNIL dictaminan con respecto a lo tratado en la fase de la pantalla en la que se encuentre en ese momento la aplicaci´on. Escuela de Ingenier´ıa Inform´atica 112 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Figura 52: Recomendaciones para el an´alisis PIA. Finalmente, est´a la zona central. Dentro de esta aparecen los pasos a dar dentro de la fase del an´alisis en la que nos encontremos. Se deben ir rellenando en orden, siendo algunos campos obligatorios, pues ser´an necesarios para fases posteriores del an´alisis. Estas pantallas se ir´an mostrando en los siguientes apartados, cada una en su fase correspondiente.[17] Escuela de Ingenier´ıa Inform´atica 113 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 6.2.2. Contexto La primera fase a llevar a cabo con la aplicaci´on PIA es el Contexto.[17] En esta fase se describe el contexto bajo el que se procesar´an los datos recopilados en cuesti´on. Se busca ganar una visi´on clara de las operaciones que llevan a cabo el procesamiento de los datos. Aqu´ı se describe la naturaleza de los datos, su alcance, el contexto, prop´ositos y fines para los cuales son recopilados y por cu´anto tiempo se almacenan. Tambi´en se identifica al controlador de los datos y a los encargados del procesamiento. Otro paso es se˜nalar aquellas referencias aplicables al procesamiento de los datos, las cuales deben ser cumplidas en todo momento. Tambi´en se referencian aquellos certificados referentes a la protecci´on de datos con los que el proyecto cuenta (Art. 42 del RGPD) y c´odigos de conducta aprobados (Art. 40 del RGPD).[73] La aplicaci´on PIA divide este paso en dos, Overview yData, Processes and Supporting Assets. La primera permite presentar el objeto de estudio, la finalidad del proyecto. Figura 53: Pantalla Overview de Context en PIA. Escuela de Ingenier´ıa Inform´atica 114 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina La segunda, definir el alcance del procesamiento de datos al detalle. Figura 54: Pantalla Data, Processes and Supporting Assets de Context en PIA. M´as adelante puede verse todo este subapartado al completo, en el an´alisis completo de PIA al final de este apartado. Escuela de Ingenier´ıa Inform´atica 115 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 6.2.3. Principios Fundamentales El objetivo de este punto del an´alisis es dar forma al sistema que asegura el cumplimiento de los principios de privacidad y protecci´on de los datos.[17] Primeramente se realiza una evaluaci´on sobre aquellos controles que garantizan la proporcionalidad y necesidad del tratamiento de los datos. Esto significa justificar aquellas decisiones tomadas para tratar los siguientes puntos. Prop´osito. Es prop´osito para el cual los datos son recopilados debe ser leg´ıtimo, expl´ıcito y espec´ıfico. (Art. 5.1 (b) del RGPD). [73] Fundamentos. Cu´al es la legalidad del procesamiento y especificar la prohibici´on de un uso indebido de los datos y sus finalidades. (Art. 6 del RGPD).[73] Minimizaci´on de los datos. Los datos recopilados deben ser relevantes, limitados y adecuados al fin para el que se est´an recopilando. (Art. 5.1 (c) del RGPD).[73] Calidad de los datos. Los datos recopilados deben ser precisos, ciertos y estar actualizados. (Art. 5.1 (d) del RGPD).[73] Periodos de almacenamiento. Estos han de ser limitados en el tiempo, ning´un dato debe mantenerse almacenado de forma indefinida. (Art. 5.1 (e) del RGPD).[73] Tambi´en ha de especificarse que el cumplimiento con el RGPD no puede mejorarse m´as, y de este modo demostrando que la aplicaci´on hace todo lo posible por el cumplimiento de la legislaci´on. De ser necesario, estos apartados deben revisarse y a˜nadir aquellos controles que puedan irse encontrando. Escuela de Ingenier´ıa Inform´atica 116 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Figura 55: Pantalla Proportionality and Necessity de Fundamental Principles en PIA. Una vez definidos los principios por los cuales el tratamiento es llevado a cabo, el siguiente paso es especificar los controles llevados a cabo para asegurar la protecci´on de los datos de los usuarios. Tambi´en se describen aquellos que a´un no se hayan implementado pero se planee hacer y c´omo se har´an. Por lo tanto, la informaci´on aqu´ı contenida abarca los siguientes puntos. Informaci´on para los sujetos de los datos. Esta debe escribirse de forma justa, clara y transparente. (Art. 12, 13, 14 del RGPD). [73] Obtener el consentimiento de los usuarios para el procesamiento de los datos. Se ha de poder demostrar que efectivamente se ha obtenido su consentimiento. (Art. 7, 8 del RGPD).[73] C´omo pueden ejercer los usuarios su derecho a la portabilidad de los datos. (Art. 15, 20 del RGPD).[73] C´omo pueden ejercer los usuarios su derecho al borrado y/o rectificaci´on de los datos. (Art. 16, 17 del RGPD).[73] C´omo pueden ejercer los usuarios su derecho a la restricci´on del procesamiento de sus datos y/o a su oposici´on. (Art. 18, 21 del RGPD).[73] Se ha de identificar a los procesadores de los datos. Estos deben estar identificados y gobernados bajo las condiciones de un contrato. (Art. 28 del RGPD).[73] Se ha de especificar c´omo es la transferencia de datos fuera de la Uni´on Europea. (Art. 44 a 49 del RGPD).[73] Escuela de Ingenier´ıa Inform´atica 117 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina De nuevo, se debe demostrar que cada control establecido es inmejorable y que con ello mejorar el cumplimiento del RGPD no es posible. Cuando sea aplicable, se deber´an revisar estas descripciones y, de ser necesario, proponer controles adicionales. En PIA la pantalla referente a esta parte es la siguiente. Figura 56: Pantalla Controls to Protect the Personal Rights of Data Subjects de Fundamental Principles en PIA. Escuela de Ingenier´ıa Inform´atica 118 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 6.2.4. Riesgos Un riesgo, seg´un la definici´on de las gu´ıas de la CNIL para PIA, es un escenario hipot´etico que describe un evento temido y todas las amenazas que pueden provocarlo.[17] Esto incluye las posibles fuentes que desencadenen ese riesgo, las vulnerabilidades que pueden ser explotadas, el contexto que lleva a dichas amenazas y permite que sucedan, afectando a los datos personales de los usuarios almacenados y provocando as´ı impactos negativos en su privacidad. El nivel del riesgo se obtiene de considerar la probabilidad de que este suceda y la severidad del mismo. La probabilidad de que un riesgo se materialice depende de las vulnerabilidades del proyecto, as´ı como de las capacidades de la fuente que puede producir ese riesgo. La severidad depende de la naturaleza perjudicial y el impacto negativo que puede tener ese riesgo en caso de materializarse. A mayor sea el da˜no causado, m´as severo se considera el riesgo. Este apartado consta de dos fases. Evaluaci´on de controles existentes o planificados El objetivo en este apartado es definir los controles establecidos que contribuyen a la seguridad del sistema. Se busca identificar o determinar la existencia de planes de contingencia ya existentes. Estos pueden englobarse en tres formas diferentes. 1. Controles relacionados directamente con los datos que se procesan. Esto incluye cifrado, anonimizaci´on, descentralizaci´on, control de acceso, trazabilidad... 2. Controles de seguridad general aplicados al sistema que realiza el tratamiento de datos. Esto incluye copias de seguridad, seguridad del hardware... 3. Controles organizacionales o gobernanza. Pol´ıtica, gesti´on del proyecto, personal encargado, gesti´on de incidentes o brechas de seguridad y datos, relaciones con terceros... Se ha de comprobar que cada control aplicado debe ser m´aximo y no puede mejorarse. De ser necesario, se revisar´an las descripciones y se propondr´an medidas adicionales. Escuela de Ingenier´ıa Inform´atica 119 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina Figura 57: Pantalla Planned or Existing Measures de Risks en PIA. Evaluaci´on de riesgos: Posibles violaciones de la privacidad El objetivo aqu´ı es conocer y comprender bien las causas y consecuencias de los riesgos. Los riesgos referentes a los datos que se consideran en PIA son los siguientes: Acceso ileg´ıtimo a los datos. Modificaci´on de los datos. Borrado de los datos. Figura 58: Tipos de riesgos en PIA. Tras definir los riesgos para cada categor´ıa, hay que determinar el impacto potencial en la privacidad de los datos de los usuarios en caso de ocurrir. Tras ello, se tendr´ıa que estimar su severidad, sobre todo teniendo Escuela de Ingenier´ıa Inform´atica 120 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina en cuenta el impacto potencial y, si es aplicable, qu´e salvaguardas disponer para controlarlos. Tambi´en se han de identificar las amenazas posibles que pueden llevar a que este riesgo se materialice. Una vez se dispone de toda esta informaci´on se calcula la probabilidad de que ocurra, teniendo en cuenta las vulnerabilidades existentes en el proyecto y las capacidades de las amenazas para explotarlas. En PIA se encuentra una pantalla distinta para cada tipo de riesgo, todas con apartados donde se etiqueta cada caracter´ıstica. Figura 59: Pantalla ejemplo de Risks en PIA. Se ha de considerar si los riesgos son asumibles o no tras realizar este apartado. De no serlo, se han de especificar las salvaguardas que habr´ıa que incorporar y se ha de revisar este apartado actualizando los riesgos para que sean residuales. PIA genera una pantalla para visualizar los riesgos, amenazas, fuentes y medidas, y las relaciones que poseen con cada uno de los posibles incidentes. Escuela de Ingenier´ıa Inform´atica 121 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 6.3.5. Conclusiones de la evaluaci´on Como puede verse, el PIA tiene puntos a mejorar. Se califica como aceptable para concluir este proyecto, pues dado el alcance de este es suficiente. Si la aplicaci´on fuese de car´acter p´ublico con unos sujetos no voluntarios para las pruebas, como es el caso de cualquier aplicaci´on de rastreo de contactos desarrollada durante la pandemia, el PIA ser´ıa mejorable. Esto llevar´ıa a realizar una iteraci´on m´as del an´alisis. Previamente se habr´ıan de incorporar aquellos aspectos m´as importantes para la seguridad de los datos. Del an´alisis se extraen los siguientes. Cifrado de las bases de datos. Para que en caso de acceso indebido, los datos no quedaran expuestos o modificados. Cifrado asim´etrico en las comunicaciones con el servidor. Implementaci´on de criptograf´ıa de clave asim´etrica. El servidor otorgar´ıa su clave p´ublica al cliente para que este cifrase con ella la clave sim´etrica para futuras comunicaciones. Tras ello se la mandar´ıa al servidor, el cual podr´ıa descifrarla usando su clave privada. Adem´as, el servidor podr´ıa tener su clave p´ublica validada por una Autoridad Certificadora con el fin de ser m´as confiable. Env´ıo de ruido al servidor. Dado que el ´unico flujo de informaci´on cliente a servidor es cuando se comunica un contagio, mediante un ataque de escucha pueden detectarse. Para evitar esto, se generar´ıa ruido emitido de cliente a servidor, as´ı no ser´ıa posible mediante el sniffing diferenciar el ruido de datos reales. Trazabilidad en el servidor. Con el fin de detectar accesos indebidos al servidor, debiera hacerse un registro de los mismos. De este modo ser´ıa m´as f´acil detectar si ha ocurrido una brecha de seguridad o frenarlo a tiempo bloqueando al atacante de alg´un modo. Redacci´on de una pol´ıtica de privacidad en la aplicaci´on. Con el fin de que los usuarios queden correctamente informados y puedan aceptarla nada m´as iniciar la aplicaci´on. Elaboraci´on de un contrato. Este ser´ıa firmado por los encargados del procesamiento de los datos con el fin de llevar un control regulado de los mismos, de sus deberes y de sus derechos. Con estas mejoras el PIA quedar´ıa mejorado. De esta forma probablemente se pudiera validar tras la nueva iteraci´on, siempre revisando de nuevo punto por punto para que no se escapasen nuevos o anteriores detalles. Escuela de Ingenier´ıa Inform´atica 149 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 6.4. Comparativa de resultados con otras alternativas europeas Como puede verse el prototipo necesita todav´ıa un par de actualizaciones que permitan asegurar la privacidad de los datos m´as a´un. Esto es implementar el cifrado de las bases de datos y el uso de la criptograf´ıa de clave p´ublica, as´ı como el env´ıo de ruido de forma peri´odica al servidor. El prototipo, por lo tanto, a´un tiene aspectos que son f´acilmente mejorables. Suponiendo su implementaci´on, el an´alisis PIA quedar´ıa validado y con ello una protecci´on de los datos maximizada. La aplicaci´on sin embargo posee ciertas debilidades por dise˜no. La principal es el hecho de estar operativa constantemente en segundo plano haciendo uso de comunicaciones Bluetooth. Esta caracter´ıstica no solo mantiene una puerta abierta a la escucha de tr´afico de datos v´ıa Bluetooth, sino que adem´as no ha inspirado mucha confianza entre los usuarios. El uso de una aplicaci´on de rastreo de contactos puede ser ´util para frenar el n´umero de casos, pero de nada sirve si la acogida entre los ciudadanos no es mayoritaria. Las primeras opciones que se propusieron, de protocolos centralizados, fueron r´apidamente descartadas, dando lugar a los protocolos descentralizados como el usado en Agava COVID. Actualmente, la Uni´on Europea ante las nuevas necesidades de la pandemia y de un control m´as globalizado, propone el sistema de Self-Sovereign Identity. Ambas opciones se encargan de controlar el estado COVID de los ciudadanos, si bien en distintos momentos de la pandemia. Una aplicaci´on de rastreo de contactos que hace uso de la tecnolog´ıa Bluetooth y es descentralizada, almacena de forma local ´unicamente la informaci´on sobre el propio contacto. Sin embargo, sigue habiendo presente un servidor en cierto modo centralizado, el cual se encarga de recibir todos aquellos identificadores contagiados. Aunque estos no poseen correlaci´on directa con sus propietarios, el hecho de que haya un ´unico punto de almacenamiento de los identificadores contagiados, implica una mayor atracci´on al mismo en caso de ataque. Si el servidor no estuviera correctamente configurado o surgiera alg´un tipo de problema, accediendo al mismo una persona no autorizada con fines malintencionados, podr´ıa introducir identificadores realmente no contagiados o borrar los contagiados. De este modo podr´ıa manipular los focos de contagio, creando nuevos y eliminando los realmente existentes. Aunque se tomasen todas las medidas posibles para evitar el riesgo, este nunca ser´ıa nulo y el hecho de que esta parte de los datos se almacene de modo centralizado, puede suponer peligros para la poblaci´on, ya no solo usuaria de la aplicaci´on sino tambi´en aquella en contacto con los usuarios, provocando un efecto en cadena. Dadas las circunstancias actuales en las que adem´as, el inter´es sobre el estado COVID ya no son tanto los focos de contagio sino qui´en est´a ya inmunizado (sea mediante vacuna o por haber pasado la enfermedad), los intereses tecnol´ogicos tambi´en var´ıan en parte. El modelo de identidad autosoberana (Self-Sovereign Identity) permite el almacenamiento de la informaci´on de modo exclusivamente local. De esta manera los usuarios son completamente due˜nos de sus datos sanitarios y pueden elegir a qui´en se los presentan. Los usuarios podr´ıan obtener estas Credenciales Verificables de autoridades sanitarias, las cuales las crear´ıan con toda la informaci´on necesaria, como tipo de vacuna y n´umero de dosis. As´ı, cuando una entidad proveedora de servicios que necesita comprobar si un usuario ha podido pasar la enfermedad o ha recibido una vacuna. Adem´as, dependiendo de las circunstancias, el usuario podr´ıa mostrar m´as o menos informaci´on. En caso de que una p´agina que organiza viajes solicite informaci´on sobre si el ciudadano est´a inmunizado, Escuela de Ingenier´ıa Inform´atica 150 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina el usuario podr´ıa elegir presentar ´unicamente una Credencial Verificable con el dato de S´ı oNo. Este dato al llevar la firma digital de una entidad sanitaria podr´ıa ser comprobado por el proveedor de servicios y con ello dado por v´alido y confiable. Adem´as, la transacci´on quedar´ıa registrada en la blockchain para garantizar el no repudio, almacenando solo los datos referentes a que esa interacci´on se ha realizado, sin guardar datos privados como el valor de la Credencial Verificable. Por otro lado, si el proveedor de servicios solicita el tipo de vacuna administrada, siendo por ejemplo un centro m´edico, la Credencial Verificable esta vez no ser´ıa ´unicamente un predicado afirmativo o negativo, sino que contendr´ıa el tipo de vacuna recibida. De nuevo esa informaci´on ir´ıa firmada por la entidad sanitaria emisora que actu´o como Issuer, dando por v´alido el dato. Est´a claro que este modelo presenta una estructura mucho m´as segura, puesto que no debe estar constantemente activo y hace al usuario due˜no de sus datos. Las aplicaciones de rastreo de contacto tuvieron muchas dificultades, siendo una tecnolog´ıa desarrollada r´apido, bajo mucha presi´on y cr´ıticas constantes. El paso a unas nuevas necesidades las deja atr´as, por ahora, pero no quita que deba ser un campo a todav´ıa investigar en caso de otra pandemia que necesite de control de focos de contagio. Quiz´a una extensi´on del modelo Self-Sovereign Identity para estos casos o nuevos protocolos que hagan uso de otras tecnolog´ıas y tipos de conexiones, ayuden a, desde la calma, crear aplicaciones verdaderamente confiables y con un alto grado de privacidad y seguridad. Escuela de Ingenier´ıa Inform´atica 151 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina 7. Conclusiones y Trabajo Futuro Finalmente, se exponen las conclusiones obtenidas de este trabajo. Primeramente, se revisa qu´e objetivos se han logrado, as´ı como en qu´e cantidad se han podido llegar a satisfacer. De estos objetivos y del trabajo mejorable surge el apartado de A futuro, donde se exponen aquellos puntos mejorables o nuevos apartados que podr´ıan complementar este proyecto. Finalmente, se cierra con una conclusi´on general sobre el proyecto y lo aprendido durante su desarrollo. Objetivos cumplidos Los objetivos planteados inicialmente pueden encontrarse en la secci´on Objetivos. Una vez se ha terminado de elaborar el proyecto se hace retrospectiva para ver qu´e objetivos se han completado Objetivo 1. Se ha podido llevar a cabo una profunda investigaci´on tanto sobre los protocolos de rastreo de contactos, como sobre el posicionamiento de la Uni´on Europea ante estos, la evoluci´on del estado COVID, y tambi´en sobre materias de seguridad y privacidad en aplicaciones m´oviles y conexi´on Bluetooth. Se ha podido observar c´omo ha evolucionado a lo largo del a˜no los distintos planteamientos tecnol´ogicos ante la pandemia. Desde protocolos de rastreo de contactos en proceso de desarrollo, sus diversas perspectivas y enfoques en la privacidad, hasta nuevas propuestas como el modelo de Self-Sovereign Identity. En cuanto a seguridad de los datos y privacidad, se ha podido indagar sobre la legislaci´on europea entorno a este tema. Tanto recomendaciones para elaborar aplicaciones de rastreo de contactos, como gu´ıas para hacer an´alisis de impacto en la privacidad o diversos puntos del Reglamento General de Protecci´on de Datos. Objetivo 2. Respecto a la realizaci´on de una aplicaci´on prototipo de rastreo de contactos se puede considerar cumplido. Del desarrollo de este trabajo ha nacido Agava COVID, una aplicaci´on prototipo con mucho potencial de desarrollo. Objetivo 3. Se ha elaborado un an´alisis de impacto en la privacidad mediante el uso de la herramienta PIA, herramienta de la CNIL. En este se ha podido llevar a cabo el proceso para corroborar que se cumple con el RGPD en todo el proyecto, sacar a la luz las amenazas m´as importantes para los datos personales, su nivel de impacto y probabilidad; y medidas para contrarrestarlo. Objetivo 4. De este trabajo se han obtenido diversas conclusiones. El desarrollar una aplicaci´on de rastreo de contactos implica muchos retos para la privacidad. Los datos sanitarios de los usuarios son de especial sensibilidad y es por ello que las soluciones tecnol´ogicas para controlar la pandemia deben ser especialmente seguras y privadas. Tambi´en se ha podido ver c´omo la UE se va adaptando a las necesidades que emergen con el transcurso de la pandemia, elaborando protocolos y soluciones cada vez m´as seguros y privados. Escuela de Ingenier´ıa Inform´atica 152 Trabajo de Fin de Grado UVa - Trabajo de Fin de Grado 2020/21 M. Ruiz Molina A futuro En esta secci´on se exponen los puntos a tratar en el futuro del proyecto, pues bien no se han podido llevar acabo por falta de tiempo o porque se escapan del alcance de este trabajo. Mejoras en el uso de la tecnolog´ıa Bluetooth. Hasta ahora el prototipo necesita de interacci´on activa por parte del usuario para el env´ıo de identificadores por Bluetooth. Esta funcionalidad deber´ıa ser implementada tal que funcionase en segundo plano y de manera autom´atica. Adem´as, el alcance de la se˜nal de Bluetooth deber´ıa restringirse a 2 metros en lugar de a la distancia predeterminada. Borrado autom´atico de identificadores caducados en la base de datos del servidor. Este proceso deber´ıa ser automatizado para mejorar el rendimiento de la aplicaci´on servidor, evitar el almacenamiento de datos superfluos y cumplir fielmente con la normativa del RGPD y la no conservaci´on indefinida de los datos. Mejor tratamiento de los identificadores. Hasta ahora, con el fin de controlar las pruebas, los identificadores se rotaban de manera manual. Estos deber´ıan ir rotando de forma autom´atica cada 15 minutos. Tambi´en, un punto a tener muy en cuenta, es la necesidad de env´ıo de ruido al servidor, pues de otro modo mediante la escucha del canal puede averiguarse qui´en env´ıa c´odigos de contagio, pues es la ´unica comunicaci´on que hay direcci´on al servidor. Para ello se implementar´ıa el env´ıo de identificadores falsos, los cuales llegar´ıan igualmente a la base de datos, solo que ser´ıan descartados al momento, pues tendr´ıan una fecha superior a 14 d´ıas. Con ello, la base de datos los eliminar´ıa al comprobar la existencia de identificadores caducados. Pulir el funcionamiento de la aplicaci´on cliente. Hay varias mejoras que podr´ıan implementarse en la aplicaci´on cliente con el fin de perfeccionar su interacci´on con el usuario. Estos aspectos a pulir son automatizar el cambio de estado de contagiado a sin contactos, un aviso como notificaci´on m´ovil en el momento en el que el estado de contagio cambie, y la retroalimentaci´on por parte del servidor en el momento de validar si un c´odigo de contagio es o no aceptado. Despliegue de la aplicaci´on servidor en Internet. Para conseguir que la aplicaci´on funcione a nivel del gran p´ublico habr´ıa que desplegar la aplicaci´on servidor en la red. Por supuesto, se deber´ıa revisar su correcto funcionamiento y, si fuese necesario adaptar el c´odigo para ello, as´ı como revisar los apartados pertinentes en el an´alisis de impacto sobre la privacidad debido a su mayor exposici´on al p´ublico. Cifrado usando pares de clave p´ublica y privada. Para la aplicaci´on prototipo se ha utilizado el cifrado sim´etrico AES-256, pero para una mayor protecci´on de los datos enviados por red, se habr´ıa de implementar un cifrado de clave asim´etrica, como podr´ıa ser RSA. De este modo, al inicio de la conexi´on TCP, el servidor env´ıa al cliente su clave p´ublica, con la que el cliente cifra la clave sim´etrica para posteriores comunicaciones. El servidor podr´ıa obtener esa clave sim´etrica descifrando el mensaje con su clave privada. Tras ello usar´ıa la clave sim´etrica para comunicarse con el cliente. Redacci´on de pol´ıtica de privacidad. Para cumplir con la normativa del RGPD se deber´ıa redactar una accesible desde la aplicaci´on, al igual que implementar una pantalla de aceptaci´on de la pol´ıtica al momento de iniciar por primera vez la aplicaci´on. Implementar las contramedidas especificadas en el an´alisis. Para que este proyecto sea viable se deber´ıan minimizar los riesgos que surgidos en el an´alisis. Entre ellos los m´as destacables refieren al cifrado de la base de datos y el uso de criptograf´ıa de clave p´ublica para las comunicaciones cliente con servidor. Escuela de Ingenier´ıa Inform´atica 153 Trabajo de Fin de Grado