Análisis de privacidad en una app de rastreo

An´alisis de Privacidad en una App de Rastreo Juan Vel´azquez Garc´ıa Tutores Juli´an Arroyo ´ Alvarez Mercedes Mart´ınez Gonz´alez 1 UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Agradecimientos En primer lugar, me gustar´ıa agradecer a mis tutores Juli´an Arroyo ´ Alvarez y Mercedes Mart´ınez Gonz´alez por su esfuerzo en aconsejar y corregir este trabajo. Tambi´en me gustar´ıa darle las gracias al profesor Amador Aparicio de la Fuente por sus consejos e inter´es en el desarrollo de este proyecto. En segundo lugar, me gustar´ıa dar las gracias a mis padres Juan Luis y Henar, a mi hermano Enrique, a mis abuelas Eulalia y Petra, a mis t´ıos Ceci y Azucena y a toda mi familia por creer en m´ı y darme la oportunidad de estudiar lo que quisiera. Tambi´en quer´ıa agradecer a mis abuelos ´ Angel y Eleuterio, all´a donde est´en, su esfuerzo por darles lo mejor a mis padres y t´ıos. Qui´en les iba a decir a un humilde pastor y a un honrado panadero de pueblo que su nieto estudiar´ıa en la universidad. Por ´ultimo quer´ıa dar las gracias a mis amigos de la universidad V´ıctor, Christopher, H´ector, Pedro, Susana y a mi compa˜nera de proyecto Mar´ıa por las risas, los llantos, las locuras, los agobios... En definitiva por hacer m´as feliz mi estancia en la universidad. Jam´as lo olvidar´e. Escuela de Ingenier´ıa Inform´atica 2An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Resumen Este proyecto aborda los riesgos de seguridad y privacidad en aplicaciones m´oviles. El trabajo aqu´ı plasmado consiste en una propuesta de evaluaci´on de riesgos e impacto en la privacidad y seguridad del usuario usando el est´andar propuesto por el CCN-CERT (Espa˜na). Para ello se ha desarrollado, junto a Mar´ıa Ruiz Molina, una aplicaci´on prototipo de rastreo de contactos COVID, sobre la cual se aplica dicha evaluaci´on. Escuela de Ingenier´ıa Inform´atica 3An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Abstract This project aims to study some privacy and security standards, specifically, the proposals from the administrative authority, Centro Criptol´ogico Nacional Computer Emergency Response Team (CCN-CERT). Likewise, the current state of affairs regarding mobile contact-tracing apps’ privacy and security 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 Mar´ıa Ruiz Molina, 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 4An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa ´ Indice 1. Introducci´on 12 2. Objetivos 13 3. Planificaci´on y Metodolog´ıa 14 4. An´alisis de la aplicaci´on 18 4.1. Requisitos no funcionales .................................... 19 4.1.1. Requisitos de seguridad ................................. 19 4.1.2. Requisitos de privacidad ................................. 20 4.1.3. Requisitos que se aplican ´unicamente cuando la aplicaci´on env´ıa al servidor una lista de contactos .......................................... 23 4.1.4. Requisitos que se aplican ´unicamente cuando la aplicaci´on env´ıa al servidor una lista de sus propios identificadores ................................ 24 4.1.5. Requisitos de Usabilidad ................................... 25 4.2. Requisitos Funcionales ...................................... 25 4.2.1. De cara al usuario ..................................... 25 4.2.2. De cara a otros dispositivos ............................... 26 4.2.3. De cara a la propia aplicaci´on ................................ 26 4.3. Requisitos de Informaci´on ...................................... 26 4.4. Base de Datos ............................................. 27 4.5. Modelo de intercambio de datos ................................... 30 4.6. Desarrollo de los casos de uso .................................... 30 4.6.1. Enviar diagn´ostico ...................................... 32 4.6.2. Cambiar idioma ....................................... 32 4.6.3. Comunicar semillas asociadas a IDs infectados ...................... 33 4.6.4. Comprobar riesgo de contagio ................................ 33 4.6.5. Enviar diagn´ostico falso ................................... 34 4.6.6. Recibir ID ........................................... 34 4.6.7. Enviar ID ........................................... 35 5. Dise˜no de la aplicaci´on 36 5.1. Estado del Arte: Protocolos ..................................... 36 5.1.1. Decentralized Privacy-Preserving Proximity Tracing (DP-3T) .............. 36 5.1.2. (Google/Apple) Exposure Notification (GAEN) system ................. 37 5.1.3. Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT/PEPP) ....... 38 Escuela de Ingenier´ıa Inform´atica 5An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 5.1.4. BlueTrace ........................................... 39 5.1.5. Otros ............................................. 39 5.2. Elecci´on del protocolo ........................................ 40 5.3. Imprevistos respecto al protocolo elegido y consecuencias .................... 41 5.4. Implementaci´on de los requisitos acorde a nuestra versi´on de DP-3T .............. 45 5.5. Implementaci´on de los Requisitos de Usabilidad .......................... 51 5.6. Dise˜no de la Interfaz e Implementaci´on de los Requisitos ..................... 52 5.6.1. Pantalla Principal ...................................... 52 5.6.2. Pantalla de Informaci´on ................................... 55 5.6.3. Pantalla de Ajustes de Idioma ................................ 55 5.7. Implementaci´on de la aplicaci´on ................................... 57 5.7.1. Implementaci´on final de la interfaz ............................. 57 5.7.2. Conexiones de red TCP. ................................... 59 5.7.3. Conexiones de red UDP. ................................... 59 5.7.4. Decisi´on sobre Bluetooth .................................. 59 5.7.5. Cifrado de los datos ..................................... 60 5.7.6. Adaptaciones realizadas cara al prototipo ......................... 61 6. Casos de prueba 63 6.1. Pruebas de caja negra ........................................ 63 6.1.1. Intercambiar un ID entre dos dispositivos v´ıa BT en rango ............... 63 6.1.2. Intercambiar un ID entre dos dispositivos v´ıa BT en el l´ımite del rango ........ 65 6.1.3. Intercambiar un ID entre dos dispositivos v´ıa BT fuera de rango ............ 65 6.1.4. Intercambiar un ID entre dos dispositivos v´ıa BT y desconectarse justo en el momento del env´ıo ........................................... 65 6.1.5. Intercambiar un ID entre dos dispositivos v´ıa BT y desconectarse justo 1 segundo antes del momento del env´ıo .................................... 66 6.1.6. Intercambiar un ID entre dos dispositivos v´ıa BT y desconectarse justo 1 segundo despu´es del momento del env´ıo ............................... 66 6.1.7. Uso de la aplicaci´on sin conexi´on a BT ........................... 67 6.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.) ............................ 68 6.1.9. Env´ıo de un c´odigo incorrecto al servidor ......................... 70 6.1.10. Env´ıo de diagn´ostico sin fecha ................................ 70 6.1.11. Env´ıo de diagn´ostico sin inserci´on de c´odigo ........................ 71 6.1.12. Env´ıo de c´odigo con menos de 12 cifras .......................... 72 6.1.13. Env´ıo de c´odigo con m´as de 12 cifras ............................ 73 6.1.14. Env´ıo de c´odigo con caracteres no num´ericos ....................... 73 Escuela de Ingenier´ıa Inform´atica 6An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.1.15. Env´ıo con fecha anterior a 14 d´ıas ............................. 73 6.1.16. Env´ıo con fecha posterior a 14 d´ıas ............................. 74 6.1.17. Multicast de IDs infectados desde el servidor a los clientes ................ 75 6.1.18. Uso de la aplicaci´on sin conexi´on a Internet (y sin recepci´on de multicast) ....... 76 6.1.19. Recepci´on por multicast de un ID infectado que se encuentra en la base de datos local 78 6.1.20. Recepci´on por multicast de IDs infectados y ninguno se encuentra en la base de datos local .............................................. 80 6.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 ............. 80 6.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 .............. 81 6.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 ................................. 81 6.1.24. Env´ıo del multicast pero sin recepci´on (clientes inactivos) ................ 82 6.1.25. Escucha, por parte del cliente, de multicast pero sin env´ıo (servidor inactivo) ..... 82 6.1.26. Cambio de idioma ...................................... 83 6.2. Pruebas de caja blanca ........................................ 84 6.2.1. Escucha del canal de conexi´on en el momento de env´ıo de un c´odigo con los IDs al servidor ............................................ 84 6.2.2. Escucha del canal de conexi´on en el momento de env´ıo de un c´odigo incorrecto al servidor 85 6.2.3. Escucha del canal de conexi´on en el momento del env´ıo del multicast .......... 85 6.2.4. Barrido de puertos de la m´aquina cliente ......................... 86 6.2.5. Barrido de puertos de la m´aquina servidor ......................... 87 6.2.6. Ataque DDoS ......................................... 89 6.2.7. Inyecci´on de c´odigo desde la aplicaci´on cliente ....................... 91 7. An´alisis de riesgos de seguridad y privacidad 92 7.1. Estado del arte: Seguridad y Privacidad .............................. 92 7.1.1. Fase 1: Definici´on del alcance ................................ 92 7.1.2. Fase 2: Identificaci´on de activos .............................. 92 7.1.3. Fase 3: Identificaci´on y selecci´on de amenazas ...................... 92 7.1.4. Fase 4: Identificaci´on de vulnerabilidades y salvaguardas ................ 92 7.1.5. Fase 5: Evaluaci´on del riesgo ................................ 93 7.1.6. Fase 6: Tratamiento del riesgo ................................ 93 7.1.7. CCN-CERT .......................................... 94 7.1.8. PILAR ............................................ 94 7.1.9. Metodolog´ıa MAGERIT ................................... 95 7.1.10. Esquema Nacional de Seguridad .............................. 95 Escuela de Ingenier´ıa Inform´atica 7An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 7.1.11. Amenazas en la actualidad. ................................. 97 7.2. Identificaci´on de Activos ....................................... 98 7.3. Valoraci´on de los activos .......................................100 7.4. Amenazas ...............................................107 7.5. Riesgos de privacidad ........................................123 7.6. Salvaguardas .............................................125 8. Conclusiones 127 Bibliografia 143 Escuela de Ingenier´ıa Inform´atica 8An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa ´ Indice de figuras 1. Planificaci´on inicial .......................................... 14 2. Planificaci´on final ........................................... 16 3. Modelo conceptual .......................................... 27 4. Modelo l´ogico Cliente ........................................ 28 5. Modelo l´ogico Servidor ........................................ 29 6. Modelo de intercambio de datos ................................... 30 7. Diagrama de casos de uso ...................................... 31 8. Esquema de generaci´on de identificadores ef´ımeros ........................ 36 9. Solicitud a cumplimentar para tener acceso a la API ....................... 41 10. Documentaci´on requerida ...................................... 41 11. Modelo f´ısico de la base de datos de los clientes .......................... 49 12. Modelo f´ısico de la base de datos del servidor ........................... 50 13. Men´u de navegaci´on ......................................... 52 14. Pantalla Principal .......................................... 53 15. Bot´on Comunica tu contagio .................................... 53 16. Confirmaci´on del env´ıo ........................................ 54 17. Simulaci´on de los distintos tipos de daltonismo .......................... 54 18. Pantalla de informaci´on ....................................... 55 19. Pantalla de idiomas .......................................... 55 20. Pantalla de inicio. Colores de la aplicaci´on ............................. 57 21. Pantalla de inicio. Protanopia .................................... 58 22. Pantalla de inicio. Deuteranopia .................................. 58 23. Pantalla de inicio. Tritanopia .................................... 58 24. Resultado de entrop´ıas ........................................ 60 25. Intercambio de ID entre dispositivos ................................ 64 26. Solicitud para activar Bluetooth .................................. 67 27. Aplicaci´on con contagio ....................................... 69 28. Aviso sobre c´odigo incompleto .................................... 71 29. Aviso sobre c´odigo incompleto .................................... 72 30. L´ımite anterior de aceptaci´on de fechas ............................... 73 31. L´ımite posterior de aceptaci´on de fechas .............................. 74 32. Aviso de desconexi´on ......................................... 76 33. Aplicaci´on ejecut´andose correctamente ............................... 77 34. Aplicaci´on ejecut´andose correctamente ............................... 79 Escuela de Ingenier´ıa Inform´atica 9An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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. El diagrama de Gantt tras esto 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 y seguridad. •Investigaci´on sobre el protocolo DP-3T. •Investigaci´on sobre la generaci´on de identificadores ef´ımeros. 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: •Caso de uso. •Actores. •Diagrama de casos de uso. •Modelo de intercambio datos. Escuela de Ingenier´ıa Inform´atica 16 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Dise˜no de la aplicaci´on. Desde la semana 10 a la semana 16. Se subdivide en: •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 37 a la semana 44. Escuela de Ingenier´ıa Inform´atica 17 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 4. 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 [21] y art´ıculos como el escrito por Patrick Howell O’Neil [50], 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. En este ´ambito encontramos dos enfoques principales para realizar el rastreo de contactos. Intercambio de Identificadores. Este enfoque se basa en el uso de identificadores ef´ımeros. Los identificadores ef´ımeros son c´odigos alfanum´ericos que identifican a un usuario an´onimamente durante un cierto periodo de tiempo, tras el cual se desechan por otros. Geolocalizaci´on. Por otro lado, en este paradigma se emplean t´ecnicas de geolocalizaci´on, tal que de haber un usuario contagiado se alerta a aquellos que hayan estado en las mismas zonas que ´el a la vez. Este enfoque es mucho m´as invasivo que el anterior para la privacidad de los usuarios, pues se hace uso de un dato sensible. Debido a que los diferentes organismos legislativos empleados como referentes a lo largo del proyecto refieren al uso de identificadores, todo el desarrollo se orientar´a hacia este paradigma en lugar de al de geolocalizaci´on. Los datos de geolocalizaci´on pueden revelar mucha informaci´on personal del usuario a partir de los lugares que visita, como son por ejemplo su direcci´on personal o la de su trabajo, pero tambi´en datos sobre su religi´on si visita alg´un edificio de culto, o incluso sobre su orientaci´on sexual determinado por algunos lugares que pudiera visitar. EL EDPB (European Data Protection Board) establece que los datos de geolocalizaci´on no deber´ıan requerirse excepto si son de absoluta necesidad. En concreto dicta que ((El seguimiento sistem´atico y masivo de la localizaci´on o los contactos de las personas f´ısicas es una grave injerencia en su privacidad. Esta pr´actica solo puede legitimarse sobre la base de su adopci´on voluntaria por parte de los usuarios para cada uno de los fines respectivos, lo que implica, entre otras cosas, que las personas que decidan no utilizar esas aplicaciones, o no sepan hacerlo, no deben sufrir ninguna desventaja.)) (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, P´arrafo 24) 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. Escuela de Ingenier´ıa Inform´atica 18 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 4.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. 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. [19] 3. El servidor debe enviar ´unicamente los identificadores activos. Se considera identificador 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. 4.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 de localizaci´on y herramientas de rastreo de contactos en el contexto de la pandemia de COVID-19, Anexo SEC-1, 2020) [16] 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) Escuela de Ingenier´ıa Inform´atica 19 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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) 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) 4.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. •Los identificadores diarios propios y las semillas con las que se generen. •Los identificadores de los usuarios con los que se haya tenido contacto. •Las semillas de los contactos positivos. Para generar los identificadores asociados a esta y compararlos con los almacenados. Escuela de Ingenier´ıa Inform´atica 20 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa •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. [36] ◦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. ◦El c´odigo dado por la autoridad sanitaria. Solo en caso de dar positivo en una prueba diagn´ostica. ◦De manera opcional la fecha de s´ıntomas o de prueba diagn´ostica positiva. ◦Las semillas con la que se generan los identificadores ef´ımeros. 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 la comunicaci´on cliente direcci´on servidor solo se da en caso de positivo. •De servidor a cliente. ◦Las semillas para generar los identificadores. Las emplean para generar los identificadores y compararlos despu´es con los almacenados. 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. ◦Se intercambian los identificadores ef´ımeros que est´an activos en ese momento a trav´es de Bluetooth. 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, 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) Escuela de Ingenier´ıa Inform´atica 21 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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) 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) Escuela de Ingenier´ıa Inform´atica 22 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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 siendo el mismo cliente el que env´ıa peri´odicamente la lista de contagios que posea en la base de datos. 19. Evitar la identificaci´on de los usuarios a partir del c´odigo de diagn´ostico. Esto se evita haciendo que dicho c´odigo sea solamente asociado al identificador y desde el servidor se env´ıe la notificaci´on a todos los clientes como se especifica en el patr´on software observador modelo de suscripci´on. 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, si 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: 4.1.3. Requisitos que se aplican ´unicamente cuando la aplicaci´on env´ıa al servidor una lista de contactos 1. ((El servidor central debe recoger el historial de contactos de los usuarios declarados positivos [...] como resultado de una acci´on voluntaria por parte 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 CON-1, 2020) 2. ((El servidor central no debe mantener ni difundir una lista de los identificadores seud´onimos de usuarios 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 CON-2, 2020) 3. ((El historial de contactos almacenado en el servidor central debe eliminarse una vez se haya notificado a los usuarios su proximidad a una persona con diagn´ostico positivo)). (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 CON-3, 2020) Escuela de Ingenier´ıa Inform´atica 23 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 4. ((Excepto si un usuario detectado como positivo comparte su historial de contactos con el servidor central o si un usuario solicita al servidor que investigue su posible exposici´on su posible exposici´on al virus, ning´un dato debe salir del equipo del usuario)). (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 CON-4, 2020) 5. ((Cualquier identificador incluido en el historial local debe eliminarse a los X d´ıas de su recogida (corresponde a las autoridades sanitarias definir el valor X))). (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 CON-5, 2020) 6. ((Los historiales de contactos enviados por distintos usuarios no deben someterse a tratamiento adicional; por ejemplo, no debe examinarse su correlaci´on cruzada para elaborar mapas globales 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 CON-6, 2020) 7. ((Los datos contenidos en los registros del servidor han de minimizarse y deben cumplir los requisitos de protecci´on 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 CON-7, 2020) Por el contrario, en el caso de que un usuario se declarase infectado si la aplicaci´on env´ıa a un servidor la lista de sus propios identificadores difundidos, se aplicar´an los siguientes requisitos: 4.1.4. Requisitos que se aplican ´unicamente cuando la aplicaci´on env´ıa al servidor una lista de sus propios identificadores 1. ((El servidor central debe recoger los identificadores de los usuarios declarados positivos [...] difundidos por la aplicaci´on, como resultado de una acci´on voluntaria por parte 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 ID-1, 2020) 2. ((El servidor central no debe mantener ni difundir el historial de contactos de usuarios 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 ID-2, 2020) 3. ((Los identificadores almacenados en el servidor central deben eliminarse una vez distribuidos a las dem´as aplicaciones)). (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 ID-3, 2020) 4. ((Excepto si un usuario detectado como positivo comparte sus identificadores con el servidor central o si un usuario solicita al servidor que investigue su posible exposici´on al virus, ning´un dato debe salir del equipo del usuario)). (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 ID-4, 2020) 5. ((Los datos contenidos en los registros del servidor han de minimizarse y deben cumplir los requisitos de protecci´on 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 ID-5, 2020) Escuela de Ingenier´ıa Inform´atica 24 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 4.1.5. Requisitos de Usabilidad Uno de los aspectos m´as importantes de esta aplicaci´on es que sea accesible para la gran mayor´ıa de las personas debido a su estrecha relaci´on con la salud. El hecho de que en uno de los puntos de la aplicaci´on se requiera que los usuarios comuniquen su contagio e intercambien identificadores entre ellos (explicado m´as adelante en Requisitos Funcionales), convierte en una necesidad que una gran mayor´ıa de la poblaci´on haga uso de la aplicaci´on. 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: 1. La interfaz debe ser sencilla. 2. La interfaz debe ser suficientemente intuitiva. 3. La interfaz debe ser agradable a la vista. 4. La interfaz debe ser accesible para personas con daltonismo. Se ha empleado un simulador para determinar una paleta de colores apropiada. [67] 5. El texto debe ser claro y conciso. 6. El texto debe ser legible para todas las edades y capacidades visuales. 7. La interfaz debe invitar a publicitar su uso. La interfaz incorporar´a detalles atractivos e identificativos originales de la aplicaci´on. 8. La interfaz debe concienciar sobre los s´ıntomas del estado de exposici´on del usuario. 9. Internacionalizaci´on. La interfaz ser´a accesible en diversos idiomas. 4.2. Requisitos Funcionales Debido a la naturaleza del proyecto, donde habr´a una interacci´on entre distintos despliegues de la aplicaci´on, se ha realizado una distinci´on entre los requisitos que llegan al usuario y los que ven otros dispositivos. 4.2.1. De cara al usuario 1. Visualizaci´on de mi riesgo de exposici´on. El usuario debe recibir retroalimentaci´on visual sobre si ha estado expuesto o no a otro usuario contagiado y en qu´e medida. 2. Posibilidad de comunicaci´on de contagio. Tanto a las autoridades sanitarias como a contactos cercanos. 3. Notificaci´on y muestra del nivel de exposici´on a un contagio. El usuario debe recibir un aviso en el caso de haber tenido un contacto cercano, as´ı como informaci´on sobre el nivel de riesgo del mismo. 4. La aplicaci´on dar´a directrices y recomendaciones al usuario. Dependiendo de su nivel de riesgo, la aplicaci´on dar´a unas u otras recomendaciones acorde a la enfermedad. Escuela de Ingenier´ıa Inform´atica 25 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 4.6.1. 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 1El actor Usuario introduce el c´odigo de diagn´ostico proporcionado por la autoridad sanitaria. 2El sistema pide confirmaci´on al usuario. 3El actor usuario verifica la acci´on. 4El sistema env´ıa el c´odigo al servidor. 5El sistema le comunica al actor Usuario que el c´odigo es correcto y le informa de las medidas que debe tomar. 6El 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 1: Caso de uso: Enviar diagn´ostico 4.6.2. 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 1El actor Usuario selecciona un idioma entre los disponibles. 2El sistema le pide confirmaci´on al actor Usuario. 3El actor Usuario confirma su selecci´on. 4El 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 2: Caso de uso: Cambiar idioma Escuela de Ingenier´ıa Inform´atica 32 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 4.6.3. 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 1El actor Servidor env´ıa los pares infectados a todos los clientes. 2Se realiza el caso de uso Comprobar riesgo de contagio Secuencia Alternativa Excepciones Sub Caso de Uso Comprobar riesgo de contagio Tabla 3: Caso de uso: Comunicar semillas asociadas a IDs infectados 4.6.4. 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 1El sistema genera los ID’s asociados a los pares recibidos. 2El sistema compara los ID’s generados con aquellos obtenidos mediante intercambio Bluetooth. 3El 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 4: Caso de uso: Comprobar riesgo de contagio Escuela de Ingenier´ıa Inform´atica 33 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 4.6.5. 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 1El actor Timer genera unas claves falsas y una fecha aleatoria fuera de los ´ultimos 14 d´ıas. 2El sistema genera un c´odigo de diagn´ostico falso. 3El sistema env´ıa el c´odigo al servidor. 4El 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 5: Caso de uso: Enviar diagn´ostico falso 4.6.6. 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 1El actor Sensor Bluetooth servidor detecta una se˜nal Bluetooth de la aplicaci´on. 2El sistema inicia un contador de 15 min. 3El actor Sensor Bluetooth servidor recibe del actor Sensor Bluetooth cliente el ID ef´ımero correspondiente a ese periodo de tiempo. 4El 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 6: Caso de uso: Recibir ID Escuela de Ingenier´ıa Inform´atica 34 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 4.6.7. 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 1El actor Sensor Bluetooth cliente detecta una se˜nal Bluetooth de la aplicaci´on. 2El sistema inicia un contador de 15 min. 3El 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 7: Caso de uso: Enviar ID Escuela de Ingenier´ıa Inform´atica 35 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 5. 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. 5.1. Estado del Arte: Protocolos El protocolo de comunicaci´on de exposici´on es una de las partes principales de la aplicaci´on. Existen diferentes protocolos para poder llevarlo a cabo. Se recogen a continuaci´on los m´as relevantes. [38] 5.1.1. Decentralized Privacy-Preserving Proximity Tracing (DP-3T) Se trata de un protocolo descentralizado de c´odigo abierto. 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 36 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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. [19] [28] [40] 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. 5.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 dispositivos Android 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.[29] 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). [23] Escuela de Ingenier´ıa Inform´atica 37 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 5.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 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. [51] Algunos riesgos principales a ra´ız de estas caracter´ısticas son: Falsificaci´on de un positivo. 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 de 2020 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 PEPP-PT/PEPP. Escuela de Ingenier´ıa Inform´atica 38 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 5.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 de la autoridad sanitaria. Los tres primeros par´ametros se transmiten encriptados pero el IV lo hace en texto plano. Si a esto le sumamos un ataque a los servidores de las autoridades sanitarias, se podr´ıan llegar a desencriptar los TempID. Otro inconveniente, propio de este protocolo, es que es necesario proveer el n´umero de tel´efono para poder iniciar las aplicaciones que lo utilicen y que las autoridades comuniquen a ese n´umero de tel´efono un posible contacto, lo que vulnera claramente la privacidad del usuario. [37] 5.1.5. Otros A parte de los protocolos mencionados en la secci´on anterior, existen otras alternativas menos probadas, pero bastantes prometedoras. Estas son consideradas alternativas factibles al protocolo DP-3T, pues presentan un grado similar de privacidad. Estos protocolos son: ConTra Corona. Es un protocolo que pretende aprovechar las virtudes de los protocolos centralizados, pero delegando cierta funciones principales en otras organizaciones, para minimizar la confianza requerida en el servidor central. Para ello, esta soluci´on se basa en el paradigma Upload What You Observed, que consiste en enviar al servidor todos los pseud´onimos (los identificadores ef´ımeros de este protocolo) que ha recogido en un periodo determinado. Esto marca una diferencia con respecto a DP-3T, que utiliza el paradigma Upload What You Sent, es decir enviar los pseud´onimos que has usado durante el periodo de tiempo. [12] EpiOne. Se trata de un protocolo h´ıbrido que emplea criptograf´ıa de clave p´ublica. Permite identificar cu´antos tokens almacenados por un usuario coinciden con los que posee el servidor pero sin la necesidad de que el usuario revele sus tokens. Esto se logra con cardinalidad de intersecci´on de conjuntos privados o PSI-CA. La PSI-CA de EpiOne permite que haya dos partes, cada una con un conjunto privado de tokens, conozcan el tama˜no de la intersecci´on entre sus conjuntos sin revelar m´as informaci´on. Con ello se puede ver si hay alguna coincidencia, pero no cu´al. De esta forma se respeta la privacidad y a su vez se puede alertar en caso de contacto con alguien contagiado. [62] Escuela de Ingenier´ıa Inform´atica 39 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Pronto-C2. Este protocolo es totalmente descentralizado. Este utiliza el algoritmo de Diffie-Hellman para establecer la clave privada con la que trabajar´a. Tambi´en emplea firmas digitales ciegas para preservar la anonimicidad del emisor a la vez que se autentifica. Este protocolo emplea direcciones e identificadores ef´ımeros para cada usuario, las cuales se env´ıan al servidor en caso de contagio. Las comunicaciones con el servidor se realizan v´ıa redes privadas como TOR con el fin de preservar el anonimato de los datos enviados. [10] Por otro lado los protocolos que menos vulnerabilidades poseen son Hamagen yCOVID Safe Paths. Sin embargo, emplean constante geolocalizaci´on y los datos enviados son las rutas de los usuarios contagiados, por lo que a nivel de privacidad dejan mucho que desear. Existen m´as protocolos descentralizados como son PACT (East-coast), PACT (West-coast), DP-3T Unlinkable, TCN o DESIRE, que es h´ıbrido. [8] 5.2. Elecci´on del protocolo Bas´andonos en los argumentos proporcionados por el estudio realizado por Serge Vaudenay [65] hemos decidido el uso de DP-3T para nuestra aplicaci´on. Esto es debido a los siguientes puntos: En el caso de los sistemas centralizados, los ataques suelen tener consecuencias m´as graves, pues el acceso es a un ´unico lugar, poniendo en peligro la privacidad de los usuarios ante usuarios malintencionados. El uso de un protocolo descentralizado nos permite mitigar el riesgo a que los usuarios sean rastreados por terceros. Si ponemos el foco en el grafo de contactos entre los usuarios, los sistemas centralizados pueden llegar a revelar parte del grafo a un servidor malintencionado. En cambio, los descentralizados solo pueden revelar a un determinado usuario si ha habido contacto entre ´unicamente dos usuarios. Aunque los protocolos descentralizados pueden permitir ciertos ataques de robo de las identidades de usuarios contagiados, DP-3T busca cubrir algunos de ellos. Una de sus soluciones es ante ataques de Paparazzi. Esta consiste en enviar el identificador “desmenuzado”, enviando la clave secreta y la fecha necesarias para generarlo por separado. Sin embargo, es cierto que desde este enfoque ser´ıa mejor un protocolo centralizado debido a que otros ataques como Nerd attack o el Militia attack no est´an cubiertos en DP-3T. [66] Sin embargo, debido a que, a grandes rasgos, cara a la privacidad el riesgo de manejar un protocolo centralizado es mayor que uno descentralizado, optamos por el uso de DP-3T. Esto es porque consideramos m´as peligroso el hecho de que se pueda acceder a una parte del grafo de contactos de los usuarios o el rastreo de los mismos, que determinar que un individuo puntual est´e contagiado. Escuela de Ingenier´ıa Inform´atica 40 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 5.3. Imprevistos respecto al protocolo elegido y consecuencias Tras comenzar a investigar sobre la implementaci´on de DP-3T para la aplicaci´on, surge el inconveniente de que, si bien su c´odigo es abierto, es necesario cumplimentar una solicitud1para tener acceso a la API. Figura 9: Solicitud a cumplimentar para tener acceso a la API Figura 10: Documentaci´on requerida Uno de los requisitos exigidos para tener acceso a la API es ser representante o tener el permiso de una Autoridad Sanitaria P´ublica Gubernamental, as´ı como proveer de una documentaci´on atestando que se est´a en posesi´on de una cuenta Google de desarrollador o dando dichos permisos a otra cuenta de la que no se es propietario. Dado que no es nuestra situaci´on, no es posible implementar la aplicaci´on con el protocolo inicialmente elegido. A causa de este contratiempo, es necesario reorientar el desarrollo a un nuevo protocolo. El hecho de generar nuevos planteamientos entra dentro de la metodolog´ıa inicialmente elegida para el desarrollo e implementaci´on de la aplicaci´on, en este caso, Extreme Programming. As´ı pues, aunque se trate de algo imprevisto, es un cambio factible y que no trastocar´a la planificaci´on inicial. Como previamente se realiz´o un estudio de los posibles protocolos candidatos, se procede a considerar cu´ales pueden ser otras buenas opciones. 1https://support.google.com/googleplay/android-developer/contact/expo notif api Escuela de Ingenier´ıa Inform´atica 41 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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. 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. 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 pueda eliminar. Escuela de Ingenier´ıa Inform´atica 48 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Figura 11: Modelo f´ısico de la base de datos de los clientes 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. [43] [47] [17] 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. [46] 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 rendimiento. 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. [42] 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. Escuela de Ingenier´ıa Inform´atica 49 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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. 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 pueda eliminar. Figura 12: Modelo f´ısico de la base de datos del servidor Tecnolog´ıas utilizadas Las tecnolog´ıas, y sus correspondientes versiones, empleadas en este proyecto, son las siguientes: Java. JDK8 Android. Versi´on 10 MariaDB. Versi´on 10.5.9 SQLite. Versi´on 3.28 Escuela de Ingenier´ıa Inform´atica 50 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 5.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. 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, ya sea por el tama˜no del bot´on o por el 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 contagiado; 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 cama 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 51 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 5.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. 5.6.1. Pantalla Principal La pantalla principal cuenta con un t´ıtulo adem´as de las siguientes ´areas: 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 52 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Figura 14: Pantalla Principal 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. Escuela de Ingenier´ıa Inform´atica 53 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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 Los colores elegidos para los botones de Aceptar yCancelar son verde y rojo suaves para minimizar el impacto visual. Adem´as, son bastante intuitivos y para los tres tipos de daltonismo m´as habituales, protanopia, deuteranopia y tritanopia, se mantiene una diferenciaci´on suficiente entre los colores.[67] Figura 17: Simulaci´on de los distintos tipos de daltonismo Escuela de Ingenier´ıa Inform´atica 54 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 5.6.2. Pantalla de Informaci´on La pantalla de informaci´on contiene una peque˜na presentaci´on de la aplicaci´on, as´ı como donde se ubicar´ıa la pol´ıtica de privacidad, para que esta pueda ser consultada en cualquier momento. Figura 18: Pantalla de informaci´on 5.6.3. Pantalla de Ajustes de Idioma En la pantalla de ajustes de idioma aparecen una serie de botones de selecci´on del idioma en el que se quiere poner la aplicaci´on. Tras seleccionarlo hay que pulsar el bot´on de aceptar, con el fin de confirmar la acci´on para evitar que el usuario cometa un error. Figura 19: Pantalla de idiomas Escuela de Ingenier´ıa Inform´atica 55 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa ¿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 lindo dise˜no 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 56 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 5.7. Implementaci´on de la aplicaci´on 5.7.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. Respetando los requisitos anteriores, la aplicaci´on queda con la siguiente interfaz: Figura 20: 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. Escuela de Ingenier´ıa Inform´atica 57 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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. Figura 25: Intercambio de ID entre dispositivos Escuela de Ingenier´ıa Inform´atica 64 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.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.[59] 6.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. 6.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. Escuela de Ingenier´ıa Inform´atica 65 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.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. 6.1.6. Intercambiar un ID entre dos dispositivos v´ıa BT y desconectarse justo 1 segundo despu´es del momento del env´ıo Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones Bluetooth Se inician dos dispositivos con Bluetooth activado. Tras ello se parean de manera manual mediante la opci´on Ajustes del tel´efono. Inicialmente aparece el mensaje de Conectado. Tras ello el de mensaje recibido, con el identificador. Se desconecta Bluetooth tras ello, y como era de esperar, el identificador se almacena correctamente. Esto es porque el mensaje ya se recibi´o previamente a la desconexi´on, en el momento en el que sale un aviso en la pantalla de la aplicaci´on. Escuela de Ingenier´ıa Inform´atica 66 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.1.7. Uso de la aplicaci´on sin conexi´on a BT 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 26: Solicitud para activar Bluetooth De este modo, la aplicaci´on nos comunica que el dispositivo no tiene activado Bluetooth. Tras este aviso, pulsamos Denegar para que la aplicaci´on siga funcionando sin Bluetooth. Tras ello, la aplicaci´on funciona sin problemas. Permite las conexiones con el servidor v´ıa Internet, es decir, pueden enviarse c´odigos de contagio al servidor y recibir el multicast sin problemas. El funcionamiento es el esperado, pues aquellas funcionalidades relacionadas con Bluetooth dejan de poderse ejecutar al no activarlo. Por otro lado, aquellas que no necesitan de Bluetooth, funcionan correctamente. Escuela de Ingenier´ıa Inform´atica 67 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.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.) Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones TCP 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. El c´odigo solo permite introducir doce caracteres num´ericos, formato de los c´odigos de contagio. Inicialmente, el caso de prueba ten´ıa un error, pues permit´ıa enviar claves y fechas generadoras al servidor sin la necesidad de rellenar previamente los datos de fecha y c´odigo. De este modo se permit´ıa el env´ıo de claves y fechas generadoras sin comprobaci´on, pudiendo enviar claves y fechas generadoras de una persona no contagiada como si lo estuviera. El problema se solucion´o obligando a que el env´ıo recogiera la informaci´on introducida en esos campos. De este modo, la informaci´on enviada por la red recoge tanto la fecha, como el c´odigo, como la lista de claves y fechas generadoras de identificadores obtenida de la base de datos local. Inicialmente hubo un problema, pues el servidor no recib´ıa informaci´on. Esto fue porque se abr´ıan puertos no habituales, y por lo tanto, el firewall del ordenador empleado para las pruebas imped´ıa la llegada de los paquetes generados por el dispositivo cliente, el m´ovil. Se desactiv´o el firewall para realizar la recepci´on con el fin de finalizar el caso de prueba, y efectivamente se recibi´o la informaci´on en el servidor sin problemas. Una vez el servidor recibe esta informaci´on, comprueba que el c´odigo sea uno de los generados por la autoridad sanitaria, y por tanto correcto y activo. De ser as´ı introduce a la base de datos las claves y fechas recibidas. La comprobaci´on la realiza compar´andolo con un listado de c´odigos que tiene almacenado en un Array. En caso de producirse una coincidencia, se permite la inserci´on. Una vez recibido, se cambia el valor de la variable que define el estado de contagio. Con ello, la imagen y los textos de la pantalla principal cambian al estado Contagiado. Escuela de Ingenier´ıa Inform´atica 68 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Inicialmente, para que este cambio fuese visible en la interfaz, el usuario deb´ıa reiniciar la aplicaci´on. Este error se solucion´o haciendo que la aplicaci´on se reiniciara autom´aticamente cada vez que cambiase el estado. Figura 27: Aplicaci´on con contagio Escuela de Ingenier´ıa Inform´atica 69 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.1.9. Env´ıo de un c´odigo incorrecto al servidor Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones TCP y 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. El c´odigo solo permite introducir doce caracteres num´ericos, formato de los c´odigos de contagio. De este modo se impide la inserci´on de un c´odigo estructurado de manera incorrecta. Una vez el servidor recibe esta informaci´on, comprueba que el c´odigo sea uno de los generados por la autoridad sanitaria, y por tanto correcto y activo. De ser as´ı introduce a la base de datos las claves y fechas recibidas. La comprobaci´on la realiza compar´andolo con un listado de c´odigos que tiene almacenado en un Array. En caso de producirse una coincidencia, se permite la inserci´on. En este caso no se produce ninguna coincidencia, por lo que rechaza la informaci´on recibida y no la introduce en la base de datos. Este caso de prueba queda parcialmente incompleto, pues el cliente no recibe una retroalimentaci´on sobre si el c´odigo es o no uno de los aceptados por el servidor; pero el servidor act´ua como se esperaba, rechazando los identificadores recibidos y sin almacenarlos en la base de datos. 6.1.10. Env´ıo de diagn´ostico sin fecha Tipo de prueba: Prueba funcional ´ Ambito de la prueba: Comunicaciones TCP y Usabilidad Se realiza el mismo proceso que en el anterior caso y se rellena ´unicamente el campo del c´odigo con uno correcto, dejando el de fecha vac´ıo. A continuaci´on se pulsa en aceptar y se confirma el env´ıo. El mensaje se env´ıa sin problema y nos proporciona el resultado esperado, que es la recepci´on del mensaje en el servidor. Escuela de Ingenier´ıa Inform´atica 70 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.1.11. Env´ıo de diagn´ostico sin inserci´on de c´odigo Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Usabilidad El proceso para llegar a la pantalla de env´ıo es el mismo que en el caso anterior. Una vez se llega al formulario de Comunica tu positivo se pulsa el bot´on de Aceptar para enviar el c´odigo. Dado que no se han introducido datos, aparece un mensaje que indica que el c´odigo est´a incompleto. Figura 28: Aviso sobre c´odigo incompleto Escuela de Ingenier´ıa Inform´atica 71 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.1.12. Env´ıo de c´odigo con menos de 12 cifras Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Usabilidad El proceso para llegar a la pantalla de env´ıo es el mismo que en el caso anterior. Una vez se llega al formulario de Comunica tu positivo se escoge una fecha en el rango y se rellena el campo del c´odigo con 11 cifras. Tras ello se pulsa sobre aceptar. Figura 29: Aviso sobre c´odigo incompleto El resultado es el esperado, la aparici´on de un mensaje que nos indica que el c´odigo est´a incompleto y que no permite avanzar a la siguiente pantalla para aceptar el env´ıo. Escuela de Ingenier´ıa Inform´atica 72 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.1.13. Env´ıo de c´odigo con m´as de 12 cifras Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Usabilidad Se realiza el mismo proceso que en el caso anterior y se intenta insertar un c´odigo de 13 cifras. El campo del c´odigo nos impide superar las 12 cifras, por tanto el resultado es el esperado. 6.1.14. Env´ıo de c´odigo con caracteres no num´ericos Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Usabilidad Se realiza el mismo proceso que en el caso anterior y se intenta insertar un c´odigo con caracteres alfab´eticos y/o s´ımbolos. El propio campo de la aplicaci´on cliente no acepta ese tipo de caracteres, por lo que la escritura de ellos no se admite. 6.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 30: L´ımite anterior de aceptaci´on de fechas Escuela de Ingenier´ıa Inform´atica 73 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.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 mensaje, 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. 6.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 mensaje, 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. Escuela de Ingenier´ıa Inform´atica 80 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.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 mensaje, 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 con ´exito 6.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 mensaje, 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. Escuela de Ingenier´ıa Inform´atica 81 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.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. 6.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 82 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.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 English. 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 35: Aplicaci´on en ingl´es Escuela de Ingenier´ıa Inform´atica 83 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.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. 6.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 36: 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 84 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.2.2. Escucha del canal de conexi´on en el momento de env´ıo de un c´odigo incorrecto al servidor Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Seguridad El proceso es el mismo que en el caso anterior. Figura 37: Resultado del sniffing Como vemos, al igual que en el caso anterior, el resultado es que se puede ver el mensaje cifrado y que por tanto est´a a salvo de observaciones no deseadas. 6.2.3. Escucha del canal de conexi´on en el momento del env´ıo del multicast Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Seguridad Se inicia un programa de sniffing filtrando las direcciones de multicast (224.0.0.0 en adelante hasta 224.0.0.255).[20] Se abre la aplicaci´on estando el dispositivo conectado a Internet. El resultado es que el mensaje de multicast se puede observar sin ning´un tipo de impedimento. Esto se debe a que en las conexiones UDP no hay un handshake donde se puedan intercambiar claves para poder realizar un cifrado. Escuela de Ingenier´ıa Inform´atica 85 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.2.4. Barrido de puertos de la m´aquina cliente Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Seguridad Se inician tanto la m´aquina cliente como la m´aquina servidor. Para la realizaci´on de esta prueba se utiliz´o una m´aquina virtual Kali y la herramienta nmap. La informaci´on que devuelve nmap tras usarse, incluye el barrido de puertos realizado junto a el n´umero de estos, protocolo, el nombre del servicio y su estado (abierto, cerrado, filtrado o no filtrado). Si el estado se marcara como filtrado esto significa que el puerto est´a siendo bloqueado por un firewall u otro software similar. Para llamar a nmap se escribe el comando de la forma: # nmap <Aqu´ı los argumentos> <Aqu´ı el nombre del host> En concreto el comando utilizado fue: sudo nmap -p <PUERTO> 192.168.1.N Donde en <PUERTO>se especifica el puerto a escanear y donde N es el ´ultimo bloque de la direcci´on IP en la red local. Se analiz´o el puerto 4446 (multicast de recepci´on). Inicialmente se obtuvo como respuesta que el puerto estaba cerrado. Esto no ten´ıa sentido, pues el cliente estaba recibiendo paquetes en ese momento. El problema era que el an´alisis se estaba realizando v´ıa TCP, forma predeterminada de nmap. Tras especificar en el comando el an´alisis de puertos UDP con el par´ametro -sU, quedando el comando: sudo nmap -sU -p 4446 192.168.1.N Se obtuvo una respuesta m´as l´ogica: Figura 38: Puerto 4446. Recepci´on de multicast. UDP Aqu´ı se puede ver que el puerto est´a open|filtered. Dicho estado significa que puede estar abierto o filtrado. Al tratarse de paquetes UDP, los paquetes para realizar el escaneo se env´ıan sin carga. Debido a esto, el puerto los descarta incluso estando abierto, pues no poseen contenido. Por tanto nmap no puede concretar si el estado es abierto o filtrado por un firewall. Se ha podido comprobar que la aplicaci´on solamente abre el puerto necesario para establecer las comunicaciones con el servidor, y ninguno m´as. Escuela de Ingenier´ıa Inform´atica 86 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.2.5. Barrido de puertos de la m´aquina servidor Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Seguridad Se inician tanto la m´aquina cliente como la m´aquina servidor. Para la realizaci´on de esta prueba se utiliz´o una m´aquina virtual Kali y la herramienta nmap. El comando utilizado es el siguiente: Para llamar a nmap se escribe el comando de la forma: # nmap <Aqu´ı los argumentos> <Aqu´ı el nombre del host> En concreto el comando utilizado fue: sudo nmap -p <PUERTO> 192.168.1.N Donde en <PUERTO >se especifica el puerto a escanear y donde N es el ´ultimo bloque de la direcci´on IP en la red local. Se analizaron los puertos 4445 (multicast de env´ıo), 3327 (puerto de conexi´on de MariaDB) y 3384 (puerto de recepci´on de datos v´ıa TCP en el servidor). Para el an´alisis del puerto 4445, el cual env´ıa los paquetes de multicast, se emplea el par´ametro -sU, pues el env´ıo de dichos paquetes se realiza v´ıa UDP. Para los otros dos puertos se realiza un escaneo habitual, v´ıa TCP, que es el protocolo por el que admite las conexiones habituales desde un cliente. Los resultados son los siguientes: Para el env´ıo de multicast v´ıa UDP: Figura 39: Puerto 4445. Env´ıo de multicast. UDP. El resultado obtenido es open|filtered. Dicho estado significa que puede estar abierto o filtrado. Escuela de Ingenier´ıa Inform´atica 87 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Para la escucha de paquetes para la base de datos MariaDB v´ıa TCP: Figura 40: Puerto 3327. Acceso a base de datos. TCP. Para la escucha de conexiones con el servidor de paquetes con c´odigos de contagio v´ıa TCP: Figura 41: Puerto 3384. Env´ıo de c´odigos. TCP. El resultado en ambos casos es puertos abiertos. Por l´ogica, el puerto UDP tambi´en estar´a abierto. En el caso de desplegar la aplicaci´on servidor en una m´aquina servidor, una de las formas de evitar el escaneo de puertos ser´ıa la instalaci´on de un cortafuegos o el uso de puertos honeypot, los cuales pueden servir para atrapar en bucle bots atacantes. Escuela de Ingenier´ıa Inform´atica 88 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 6.2.6. Ataque DDoS Tipo de prueba: Prueba no funcional ´ Ambito de la prueba: Seguridad Se inicia el dispositivo, conectado a la red. Para poder realizar el ataque se utiliz´o una m´aquina virtual Kali y la herramienta inviteflood. Este comando env´ıa paquetes v´ıa UDP de forma masiva con la intenci´on de que el objetivo se sature y no pueda realizar sus funciones de red correctamente. En concreto el comando utilizado fue el siguiente: sudo inviteflood eth0 ’’ 192.168.1.N 192.168.1.N 700000 -D 4446 En dicho comando, hay argumentos obligatorios, los cuales son: Interfaz. En este caso es eth0, y es la interfaz o red donde tanto el objetivo como la m´aquina atacante deben estar conectados. Usuario objetivo. Aqu´ı se debe especificar el usuario de la m´aquina objetivo al que se va a atacar. En este caso no hay, luego se deja con comillas vac´ıas. Dominio objetivo. Este campo admite tanto direcciones URL como direcciones IPv4. Dado que es un servidor montado en una red local, aqu´ı se especifica su IPv4 192.168.1.N donde N es el ´ultimo bloque de la direcci´on IP en la red local. Objetivo. En este campo se especifica la direcci´on IPv4. En caso de haberla puesto en el anterior punto, se repite. Flood stage. En este campo se introduce el n´umero de paquetes UDP que se mandar´an para realizar el ataque. En este caso se realiz´o un ataque con 700000 paquetes. Adem´as, en este caso se va a realizar un ataque al puerto 4446. Escuela de Ingenier´ıa Inform´atica 89 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Unificar criterios. Mediante la puesta en com´un de las medidas de seguridad empleadas por las Administraciones en materia de seguridad de la informaci´on. Integraci´on de sistemas. Establecer un lenguaje com´un tanto para la comunicaci´on entre Administraciones, como al la hora de fijar unos requisitos de seguridad a los proveedores de los sistemas de informaci´on. 2. Principios B´asicos del ENS Con estos objetivos en mente, el ENS establece unos criterios o principios b´asicos para realizar la toma de decisiones en el ´ambito de la seguridad de la informaci´on. Estos principios son: [2] Seguridad Integral. Gesti´on de Riesgos. Prevenci´on, reacci´on y recuperaci´on. L´ıneas de Defensa. Reevaluaci´on peri´odica. 3. Requisitos M´ınimos del ENS Como se ha mencionado con anterioridad, con la finalidad de garantizar la adecuada protecci´on de la informaci´on, el ENS establece una serie de requisitos m´ınimos que cualquier tipo de sistema debe cumplir. Estos requisitos son: [2] Organizaci´on e implantaci´on del sistema de seguridad. An´alisis y gesti´on de riesgos. Gesti´on del personal. Profesionalidad. Autorizaci´on y control de accesos. Protecci´on de las instalaciones. Adquisici´on de productos. Seguridad por defecto. Integridad y actualizaci´on del sistema. Protecci´on de la informaci´on almacenada en tr´ansito. Prevenci´on ante otros sistemas de informaci´on interconectados. Registro de la actividad. Incidentes de seguridad. Continuidad de la actividad. Mejora de la continuidad del proceso. 4. Clasificaci´on de los sistemas de informaci´on Como es l´ogico, no todos los sistemas de informaci´on tratan con informaci´on del mismo valor. Siguiendo este razonamiento, informaci´on de diferente consideraci´on necesitar´a de diferente tipo de medidas de seguridad. Por esta raz´on, el ENS propone unas categor´ıas para la clasificaci´on de estos sistemas: [2] Categor´ıa alta. Los sistemas de categor´ıa alta son aquellos en los que los riesgos de seguridad pueden causar da˜nos catastr´oficos. Categor´ıa media. Los sistemas de categor´ıa media se caracterizan por padecer riesgos de seguridad en los que los da˜nos causados son graves, sin llegar a un nivel superior. Escuela de Ingenier´ıa Inform´atica 96 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Categor´ıa baja. Un sistema se considera de categor´ıa baja cuando los riesgos en la seguridad de la informaci´on no superan la causa de un da˜no limitado, sin alcanzar niveles graves o superiores. 5. Medidas de seguridad en el ENS. El cumplimiento de esta normativa tiene como consecuencia la implantaci´on de medidas de seguridad. Estas medidas pueden afectar en diferentes aspectos los sistema de informaci´on, en concreto: [2] Organizaci´on. A nivel organizativo nos encontramos medidas como pol´ıticas, normativas y procedimientos de seguridad o procesos de autorizaci´on. Operatividad. A nivel operativo aparecen medidas como la planificaci´on, el control de acceso o la monitorizaci´on del sistema. Protecci´on. A nivel de protecci´on surgen medidas como la protecci´on de activos (equipos, comunicaciones, instalaciones, servicios, etc...) o la gesti´on del personal. 7.1.11. Amenazas en la actualidad. El Centro Criptol´ogico Nacional (CCN-CERT) publica todos los a˜nos un informe donde recoge las ciberamenazas y tendencias que se han podido observar. Debido a la irrupci´on de la pandemia de COVID-19 que ha tenido lugar durante el a˜no 2020, se ha hecho hincapi´e en la ciberseguridad relacionada con este ´ambito. Ya que este proyecto esta orientado hacia este dominio, se va a describir a continuaci´on un resumen de las amenazas recogidas en dicho informe. Ataques de ransomware El ransomware es uno de los tipos m´as extendidos y peligrosos de ciberataques. Es un malware o programa malicioso cuya funci´on es impedir el acceso a determinadas partes o a ciertos archivos del sistema operativo que ha infectado. Una vez realizado esto el atacante exige a la v´ıctima del programa el pago de un rescate para poder volver a tener acceso a los datos restringidos. [56] Por lo general, este ataque no se realiza de forma inmediata. Una vez la v´ıctima ha sido infectada, los ciberdelincuentes emplean varios d´ıas con el objetivo de localizar los activos de mayor valor ya que, as´ı, el impacto del programa ser´a el m´aximo posible. Seg´un el CCN-CERT, la inmensa mayor´ıa de estos ataques se realizaron mediante la cooperaci´on de diferentes programas. A continuaci´on se explican dos ejemplos de ransomware cooperativos y su m´etodo de actuaci´on: [48] •Emotet, Trickbot y Ryuk. Emotet es un troyano cuyo origen se remonta a 2014. Su principal objetivo era el robo de credenciales bancarias. En la actualidad su ´ambito ha evolucionado y se usa en conjunci´on con el troyano bancario Trickbot y el ransomware Ryuk. El m´etodo de infecci´on m´as com´un es a trav´es de correos electr´onicos con documentos ofim´aticos manipulados que se encargan de instalar Emotet. Este, a su vez, descarga Trickbot y se comienzan a expandir por la organizaci´on. Una vez se ha conseguido, los ciberdelincuentes eval´uan mediante herramientas de control remoto de Trickbot si la v´ıctima es adecuada para la instalaci´on de Ryuk. •Dridex y BitPaymer. Es un caso similar al anterior. El ataque mediante esta combinaci´on comienza con la infecci´on con Dridex un malware o programa malicioso que reconoce y recolecta informaci´on de la red infectada. La finalidad es siempre poder distribuir el ransomware, en este caso BitPaymer, por toda la red para posteriormente pedir el rescate. Durante el a˜no 2020 y a causa de la pandemia de COVID-19 estos ataques se han realizado principalmente en redes y dispositivos dom´esticos, industrias, laboratorios de investigaci´on y farmac´euticas. Escuela de Ingenier´ıa Inform´atica 97 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Ataques a sistemas de acceso remoto Seg´un el CCN-CERT, se ha observado un incremento en el uso de los sistemas de acceso remoto como v´ıas de entrada para atacantes. Esto se debe a que, debido a la pandemia de COVID-19, el teletrabajo se ha extendido de manera exponencial y en casi todos los sectores hacen uso de ´el. [48] Los ciberdelincuentes utilizan como baza principal las vulnerabilidades de estos sistemas. Se aprovechan de vulnerabilidades reci´en descubiertas y que los usuarios no han podido parchear con una actualizaci´on, o bien de vulnerabilidades sin soluci´on en ese momento. Tambi´en se ha extendido mucho el uso de t´ecnicas de phishing para obtener las credenciales de redes virtuales privadas (VPN), sesiones de escritorio remoto o incluso correos electr´onicos. Operaciones de adquisici´on de informaci´on y ciberespionaje La actual situaci´on geopol´ıtica y el incremento de los pa´ıses capaces de recopilar inteligencia del ciberespacio ha provocado un aumento de las operaciones de ciberespionaje. Este tipo de acciones las realizan los grupos denominados de amenaza persistente avanzada o ATP. Est´an compuestos por personal especializado con gran cantidad de recursos tanto materiales como econ´omicos y su finalidad es permanecer en la red objetivo el mayor tiempo posible obteniendo informaci´on sin ser detectados.[48] Estos ataques se lanzan sobre industrias, universidades, empresas sanitarias o incluso dispositivos inteligentes. Cabe destacar en estos ´ultimos que la puerta de entrada suelen ser las comunicaciones inal´ambricas como Bluetooth o Bluetooth Low Energy (BLE). Aunque se recomienda desactivar estas comunicaciones siempre que no se usen, muchos usuarios ignoran estos consejos convirti´endoles en potenciales v´ıctimas. [49] 7.2. Identificaci´on de Activos Una vez identificadas todas las herramientas y explicado el estado del arte podemos comenzar el an´alisis. Para realizarlo, se comenzar´a por identificar los activos que componen el proyecto. Para ello haremos uso de la herramienta PILAR Basic. Como se ha comentado anteriormente, este programa se basa en la metodolog´ıa MAGERIT. Seg´un esta metodolog´ıa, lo primero que se debe realizar es caracterizar los activos utilizando su lista de atributos o, como en este caso la de PILAR Basic. A continuaci´on se expondr´an en cursiva los atributos, en [negrita y entre corchetes] los c´odigos de identificaci´on de cada activo para PILAR Basic, en negrita el nombre del activo y a continuaci´on una peque˜na descripci´on en aquellos activos que la necesiten para comprenderlo totalmente. Activos esenciales •[essential][info][per][sensitive][salud][estado de salud] [INFO-001] Estado de contagio. Solo puede verlo el usuario de la aplicaci´on m´ovil. •[essential][info][per][pseundonymous] [INFO-002] Identificadores Contagiados. Representa los identificadores que env´ıa quien comunica un positivo. Solo tiene acceso a ellos quien administre la base de datos del servidor. •[essential][info][per][pseundonymous] [INFO-003] Identificadores Cliente. Es el elemento m´as importante de la aplicaci´on. Nadie puede acceder a ellos ya que se generan en la propia aplicaci´on de forma interna. Es necesario que est´en seguros y no se puedan manipular de ninguna forma. Escuela de Ingenier´ıa Inform´atica 98 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa •[essential][info][vr][classified][UC] [INFO-004] Documentaci´on Proyecto. Se trata de todo el trabajo de investigaci´on y dise˜no de la aplicaci´on y que ser´a presentado al tribunal. En otras palabras, este documento. •[essential][info][vr][classified][UC] [D] [backup] [INFO-005] Copia de seguridad de documentaci´on proyecto en local. •[essential][info][vr][keys][com][channel] [KEY-001] Clave de cifrado de comunicaci´on con servidor. Esta clave no puede estar accesible para nadie, ya que es la que garantiza que un ataque de sniffing pueda ver los datos que se intercambian entre el servidor y los clientes. •[essential][info][vr][D][password] [PWD-001] Contrase˜na de acceso a base de datos del servidor. •[essential][info][vr][D][source] [COD-001] C´odigos fuente en local. Aqu´ı se engloban tanto el c´odigo del servidor como el de la aplicaci´on m´ovil, ya que las medidas de seguridad a las que se deben someter son las mismas. •[essential][info][vr][D][backup][source] [COD-002] C´odigos fuente en repositorio. Aqu´ı se engloban, al igual que en el punto anterior, tanto el c´odigo del servidor como el de la aplicaci´on m´ovil, ya que las medidas de seguridad a las que se deben someter son las mismas. •[essential][info][vr][D][exe] [COD-003] Ejecutables. Como en los puntos anteriores, se consideran tanto el ejecutable del servidor como el de la aplicaci´on m´ovil, ya que las medidas de seguridad a las que se deben someter son las mismas. •[essential][service][administrative][S][prov][int] [SERV-001] Almacenamiento en base de datos. La informaci´on que se almacena son los identificadores contagiados que los clientes env´ıan junto con el c´odigo proporcionado por la autoridad sanitaria. De este servicio solo pueden hacer uso los clientes con la aplicaci´on m´ovil. Aplicaciones Inform´aticas - Software •[essential][bp][SW][prp] [SW-001] Aplicaci´on m´ovil. Se trata de la aplicaci´on que los usuarios utilizar´an en sus dispositivos m´oviles. Por tanto es accesible a todos los clientes del proyecto. •[essential][bp][SW][prp] [SW-002] Aplicaci´on servidor. Es el software que recibe las peticiones, accede a la base de datos y env´ıa los identificadores contagiados a todos los clientes. •[essential][service][administrative][SW][std][dbms] [SW-003] MariaDB. Es el software gestor de base de datos y el que implementa todas las operaciones necesarias para el mantenimiento de la base de datos. Equipamiento - Hardware •[HW][host][data] [HW-001] Ordenador Juan. Es el equipo que act´ua como servidor principal y host de la base de datos. •[HW][backup][data] [HW-002] Ordenador Mar´ıa. Es el equipo que act´ua como servidor de respaldo. Contiene tambi´en una copia de la base de datos. •[HW][mobile][data] [HW-003] Dispositivo m´ovil cliente. Engloba todos los dispositivos m´oviles que instalen la aplicaci´on y hagan uso del proyecto. Redes de comunicaci´on •[COM][LAN] [RED-001] Red Local Piso Juan. Red local utilizada para realizar las simulaciones de comunicaci´on. Es la red principal. •[COM][LAN] [RED-002] Red Local Casa Juan. Red local utilizada como alternativa y para realizaci´on de pruebas. Escuela de Ingenier´ıa Inform´atica 99 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa •[COM][LAN] [RED-003] Red Local Casa Mar´ıa. Red local utilizada como alternativa y para realizaci´on de pruebas. •[COM][LAN] [RED-004] Red Local Caf´e La Passion. Red local utilizada para aquellas pruebas en las que se necesitaban dos dispositivos m´oviles. Soportes de Informaci´on •[Media][electronic][disk] [MED-001] Disco duro Juan. •[Media][electronic][disk] [MED-002] Disco duro Mar´ıa. •[Media][electronic][san] [MED-003] Canal de Discord. Almacenamiento en la nube que contiene todas las fuentes y referencias utilizadas para la realizaci´on del proyecto. Tambi´en contiene documentaci´on del proyecto, ´unicamente es accesible al personal del proyecto. •[Media][electronic][san] [MED-004] Chat de Telegram. Almacenamiento en la nube que contiene versiones del proyecto. Al igual que lo anterior, ´unicamente accesible al personal del proyecto. •[Media][electronic][san] [MED-005] Repositorio de la aplicaci´on servidor. Contiene una copia del proyecto y los pasos realizados hasta la versi´on final. •[Media][electronic][san] [MED-006] Repositorio de la aplicaci´on m´ovil. Contiene una copia del proyecto y los pasos realizados hasta la versi´on final. •[Media][electronic][san] [MED-007] Overleaf. Contiene una copia en la nube de este documento. ´ Unicamente accesible al personal del proyecto. Instalaciones •[L][local] [L-001] Piso Juan. Local donde se ha desarrollado el proyecto. •[L][backup] [L-002] Casa Juan. Local donde se ha desarrollado el proyecto. •[L][backup] [L-003] Casa Mar´ıa. Local donde se ha desarrollado el proyecto. •[L][local] [L-004] Caf´e La Passion. Local utilizado para la realizaci´on de pruebas bluetooth. Personal •[P] [P-001] Juan Vel´azquez Garc´ıa. Administrador y desarrollador del proyecto. •[P] [P-002] Mar´ıa Ruiz Molina. Administradora y desasorrolladora del proyecto. •[P] [P-003] Usuarios. 7.3. Valoraci´on de los activos Para determinar el valor de los activos se utilizar´an las dimensiones de valoraci´on, caracter´ısticas o atributos que hacen valioso un activo. En primer lugar se definir´an las dimensiones tal como especifica la metodolog´ıa MAGERIT: [24] [D] Disponibilidad. Propiedad o caracter´ıstica de los activos consistente en que las entidades o procesos autorizados tienen acceso a los mismos cuando lo requieren. [UNE 71504:2008] [I] Integridad de los datos. Propiedad o caracter´ıstica consistente en que el activo de informaci´on no ha sido alterado de manera no autorizada. [ISO/IEC 13335-1:2004] [C] Confidencialidad de la informaci´on. Propiedad o caracter´ıstica consistente en que la informaci´on ni se pone a disposici´on, ni se revela a individuos, entidades o procesos no autorizados. [UNEISO/IEC 27001:2007] Escuela de Ingenier´ıa Inform´atica 100 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa [A] Autenticidad. Propiedad o caracter´ıstica consistente en que una entidad es quien dice ser o bien que garantiza la fuente de la que proceden los datos. [UNE 71504:2008] [T] Trazabilidad. Propiedad o caracter´ıstica consistente en que las actuaciones de una entidad pueden ser imputadas exclusivamente a dicha entidad. [UNE 71504:2008] Es momento de determinar la escala de valores a utilizar. Seg´un MAGERIT, ((Para valorar los activos vale, te´oricamente, cualquier escala de valores.))(Portal de Administraci´on Electr´onica. MAGERIT v.3 : M´etodolog´ıa de An´alisis y Gesti´on de Riesgos de los Sistemas de Informaci´on, 2012) En este caso, al utilizar la herramienta PILAR Basic, se tomar´a la escala que trae el programa. En orden de mayor a menor la escala de valoraci´on es la siguiente: [10] Nivel 10 [9] Nivel 9 [A+] Nivel Alto + [A] Nivel Alto [A-] Nivel Alto - [M+] Nivel Medio + [M] Nivel Medio [M-] Nivel Medio - [B+] Nivel Bajo + [B] Nivel Bajo [n.a] No Aplicable Finalmente, utilizando estas dimensiones de valoraci´on y esta escala, se obtuvo la siguiente tabla de valoraciones: Estado de contagio. •Disponibilidad: Se ha valorado con un 10, ya que el usuario no podr´ıa saber si est´a o no contagiado de la enfermedad. •Integridad del dato: Se ha valorado con un 10 porque su modificaci´on no autorizada, podr´ıa, por ejemplo, crear un foco de contagio marcando como sanas a personas contagiadas antes de tiempo, llegando a afectar incluso a quienes no utilizan la aplicaci´on. •Confidencialidad de la informaci´on: Se ha valorado con un 9, pues el estado de salud es un dato personal cuya difusi´on debe ser decisi´on de su propietario, pero su difusi´on afectar´ıa ´unicamente a los usuarios de la aplicaci´on. •Autenticidad: Se ha valorado con un 10 debido a que si un atacante pudiera intercambiar este dato entre varios usuarios, se podr´ıa crear un foco de contagio al marcar como sanas personas que no lo son. Afectar´ıa incluso a aquellas personas que no utilicen la aplicaci´on. •Trazabilidad: Se ha valorado como no aplicable, ya que este dato est´a siempre visible en la aplicaci´on y por tanto no es necesario llevar un registro de qui´en accede a ´el. Escuela de Ingenier´ıa Inform´atica 101 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Figura 44: Tabla de valoraci´on de activos Identificadores Contagiados. •Disponibilidad: Se ha valorado con un 10, ya que la aplicaci´on no podr´ıa funcionar si no est´an disponibles. •Integridad del dato: Se ha valorado con un 10, ya que cualquier modificaci´on en ellos podr´ıa provocar, por ejemplo, que a un usuario contagiado le cambie su estado a no contagiado antes de tiempo, lo que podr´ıa generar contagios. •Confidencialidad de la informaci´on: Se ha valorado con un 9, ya que, a pesar de ser una informaci´on valiosa de la aplicaci´on, estos identificadores son an´onimos y conocer, por ejemplo, a qui´en pertenece es pr´acticamente imposible. •Autenticidad: Se ha valorado con un 10, ya que si se falsificara el origen de los datos se podr´ıa enviar informaci´on falsa al servidor. •Trazabilidad: Se ha valorado con un 10, ya que no conocer qui´en tiene acceso a ellos puede provocar que no se sepa la autor´ıa y/o existencia de una fuga de informaci´on. Identificadores Cliente. •Disponibilidad: Se ha valorado con un 10, ya que la aplicaci´on no podr´ıa funcionar si no est´an disponibles. •Integridad del dato: Se ha valorado con un 10, ya que la modificaci´on de este dato podr´ıa ocasionar, por ejemplo, que un usuario que haya estado en contacto con un contagiado no reciba el pertinente aviso. •Confidencialidad de la informaci´on: Se ha valorado con un 9, pues, a pesar de moverse en un entorno muy amplio, si alguien pudiese coger estos identificadores e introducirlos en otro dispositivo con la aplicaci´on a la otra punta del pa´ıs, en ese dispositivo se mostrar´ıa, en caso de contagio del primero, un contacto de riesgo cuando no ha sido as´ı. •Autenticidad: Se ha valorado con un 10, ya que si alguien consiguiera intercambiar un identificador de otra persona haci´endose pasar como suyo, si esa persona se contagiara, el receptor del identificador no recibir´ıa ninguna alerta. Esto podr´ıa generar, si el usuario del dispositivo receptor se hubiera contagiado, un foco de contagio, al no recibir aviso del contacto con un positivo. Escuela de Ingenier´ıa Inform´atica 102 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa •Trazabilidad: Se ha valorado como no aplicable puesto que estos identificadores viajan entre los dispositivos y por tanto, ser´ıa pr´acticamente imposible conocer qui´en ha podido acceder a ellos. Documentaci´on del proyecto. •Disponibilidad: Se ha valorado con un B, ya que el hecho de que no est´e disponible no tendr´ıa ning´un efecto grave en el proyecto. Adem´as existe una copia de seguridad en local, que evitar´ıa los problemas que pudiera generar en t´erminos de disponibilidad. •Integridad del dato: Se ha valorado con un B, ya que la modificaci´on o alteraci´on de este documento no tendr´ıa consecuencias graves en el funcionamiento del proyecto. En esta caso la copia de seguridad cubre cualquier problema relacionado con la integridad. •Confidencialidad de la informaci´on: Se ha valorado como no aplicable, ya que el documento va a ser de dominio p´ublico. •Autenticidad: Se ha valorado con un B puesto que si, por ejemplo, alguien realizara una falsificaci´on de este activo, la informaci´on ah´ı escrita podr´ıa ser considerada verdadera por quien la observe y podr´ıa afectar a la veracidad e imagen del proyecto aunque no a su funcionamiento. •Trazabilidad: Se ha valorado como no aplicable, ya que el documento va a ser p´ublico. Copia de seguridad de documentaci´on proyecto en local. •Disponibilidad: Se ha valorado con un M-, pues a pesar de ser una copia de seguridad, el hecho de no estar disponible no generar´ıa problemas muy graves en el proyecto. Adem´as, hay que tener en cuenta que ´unicamente se necesitar´a en caso de que no est´e disponible el activo original. •Integridad del dato: Se ha valorado con un 10, pues en el caso de hacer uso de esta copia, el hecho de que se haya modificado har´ıa que este activo no cumpla su funci´on. •Confidencialidad de la informaci´on: Se ha valorado como no aplicable, ya que aunque es una copia de seguridad, el documento es el mismo que el original, que es de dominio p´ublico. •Autenticidad: Se ha valorado con un B puesto que si, por ejemplo, alguien realizara una falsificaci´on de este activo, la informaci´on ah´ı escrita podr´ıa ser considerada verdadera por quien la observe y podr´ıa afectar a la veracidad e imagen del proyecto aunque no a su funcionamiento. •Trazabilidad: Se ha valorado con un M, ya que al ser en local, saber qui´en tiene acceso a estas copias es lo mismo que saber cu´antas hay. A pesar de ser importante conocer las copias de seguridad que existen, no conocerlo ser´ıa grave pero no vital para el funcionamiento del proyecto. Clave de cifrado de comunicaci´on con servidor. •Disponibilidad: Se ha valorado con un 10 puesto que si no tenemos disponible esta clave la informaci´on viajar´ıa expuesta. •Integridad del dato: Se ha valorado con un 10, pues la modificaci´on o borrado de esta, podr´ıa dejar a la vista toda la informaci´on que intercambia el servidor con los dispositivos. •Confidencialidad de la informaci´on: Se ha valorado con 10, ya que si alguien externo a la organizaci´on conociera la clave y la difundiera la informaci´on intercambiada podr´ıa ser descifrada y quedar expuesta. •Autenticidad: Se ha valorado con un 10 debido a que si, por ejemplo, la clave la hubiese proporcionado una persona ajena al proyecto, podr´ıa realizar ataques de escucha y utilizar la clave para descifrar la informaci´on. •Trazabilidad: Se ha valorado con un 10, ya que si no se tiene un registro de qui´en tiene acceso a ella, alguien ajeno al proyecto podr´ıa filtrarla al exterior, lo que desembocar´ıa en que las comunicaciones quedar´ıan expuestas. Escuela de Ingenier´ıa Inform´atica 103 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Contrase˜na de acceso a base de datos del servidor •Disponibilidad: Se ha valorado con un 10, ya que es necesaria para acceder o restaurar la base de datos en caso de que sea necesario. •Integridad del dato: Se ha valorado con un 10, pues si alguien consiguiera alterarla, no se podr´ıa acceder a la base de datos. Tampoco podr´ıamos conocer si esta ha sido alterada de ninguna forma. •Confidencialidad de la informaci´on: Se ha valorado con un 10, ya que la difusi´on de esta clave podr´ıa dar acceso a la informaci´on contenida en la base de datos a personas ajenas al proyecto, generando as´ı una fuga de informaci´on. •Autenticidad: Se ha valorado con un 10, ya que, por ejemplo, podr´ıa haber sido generada por alguien ajeno al proyecto con fines maliciosos. •Trazabilidad: Se ha valorado con un 10 debido a que si no sabemos quien ha tenido acceso a esta contrase˜na, podr´ıamos haber obviado el acceso por parte de individuos ajenos al proyecto. Esto podr´ıa desembocar en una fuga de informaci´on. C´odigos fuente en local. •Disponibilidad: Se ha valorado con un A, ya que si, por ejemplo, se detectara un bug o una brecha de seguridad, se deber´ıa reparar lo antes posible. Por tanto, la disponibilidad de los c´odigos es fundamental para este fin. Se debe tener un cuenta que se dispone de un repositorio donde hay copias de los c´odigos para los casos en los que sea necesario. •Integridad del dato: Se ha valorado con un A, ya que cualquier alteraci´on en el c´odigo podr´ıa generar que el proyecto no realice las funciones que debe. El hecho de existir las copias en los repositorios con el historial de cambios, nos da un cierto margen para poder detectar la modificaci´on y solucionar el contratiempo relativamente r´apido. •Confidencialidad de la informaci´on: Se ha valorado como no aplicable puesto que hay copias en el repositorio que es p´ublico. •Autenticidad: Se ha valorado como no aplicable puesto que el conocer qui´en ha originado los c´odigos fuente no es relevante para el funcionamiento del proyecto. •Trazabilidad: Se ha valorado como no aplicable. Esto es debido a que los repositorios son p´ublicos y el c´odigo contenido en ellos deber´ıa ser el mismo que en local. Por tanto, no ser´ıa posible ni tampoco tendr´ıa sentido saber qui´en ha tenido acceso a ellos. C´odigos fuente en repositorio. •Disponibilidad: Se ha valorado con un 10, ya que si, por ejemplo, se detectara un bug o una brecha de seguridad, se deber´ıa reparar lo antes posible. Por tanto, la disponibilidad de los c´odigos es fundamental para este fin. •Integridad del dato: Se ha valorado con un 10. Esto se debe a que al ser la copia de seguridad es necesario que, en caso de cualquier alteraci´on de las copias en local, el c´odigo no sea alterado y/o borrado. Esto podr´ıa generar un mal funcionamiento del proyecto y obligar a una revisi´on profunda del c´odigo para restaurarlo. •Confidencialidad de la informaci´on: Se ha valorado como no aplicable debido a que el repositorio es p´ublico y por tanto no hay un ´ambito delimitado de donde no debiera salir. •Autenticidad: Se ha valorado como no aplicable puesto que el conocer qui´en ha originado los c´odigos fuente no es relevante para el funcionamiento del proyecto. •Trazabilidad: Se ha valorado como no aplicable debido a que el repositorio es p´ublico y por tanto no tendr´ıa sentido saber qui´en accede a ellos. Escuela de Ingenier´ıa Inform´atica 104 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Ejecutables. •Disponibilidad: Se ha valorado con un A. Esto se debe a que si bien para poder funcionar el proyecto es necesario tener los ejecutables, en caso de no estar disponibles se podr´ıan generar de nuevo con los c´odigos fuente. •Integridad del dato: Se ha valorado con un 10, ya que cualquier modificaci´on en este activo provocar´ıa que el proyecto no funcionara correctamente. •Confidencialidad de la informaci´on: Se ha valorado como no aplicable porque los ejecutables son los archivos que se necesitan para usar el proyecto y por tanto cualquier usuario actual o potencial tiene acceso a ellos. •Autenticidad: Se ha valorado con un 10 debido a que si el origen de estos es desconocido podr´ıan haber sido alterados para realizar otro tipo de funciones. •Trazabilidad: Se ha valorado como no aplicable, ya que cualquier persona, tanto usuarios como no usuarios, tiene acceso a ellos para hacer uso del proyecto. Por tanto, no tiene sentido tener un registro de acceso a estos activos. Almacenamiento en base de datos. •Disponibilidad: Se ha valorado con un 10, ya que si este servicio no est´a disponible el proyecto no podr´ıa funcionar. •Integridad del dato: Se ha valorado como no aplicable. Esto se debe a que este activo es un servicio, no un dato, y por tanto la integridad del dato no se puede aplicar. •Confidencialidad de la informaci´on: Se ha valorado como no aplicable puesto que, al igual que la integridad del dato, esta dimensi´on de valoraci´on ´unicamente se aplica a datos y no a servicios como ocurre en este caso. •Autenticidad: Se ha valorado con un 10 puesto que si se permitiera almacenar datos a cualquiera podr´ıamos encontrarnos con datos falsos o intentos de inyecciones de c´odigo. •Trazabilidad: Se ha valorado con un 10 porque no saber si se ha hecho uso de este servicio podr´ıa inhabilitar la persecuci´on delitos. Aplicaci´on m´ovil. •Disponibilidad: Se ha valorado con un 10, ya que si este servicio no est´a disponible, el proyecto no podr´ıa funcionar. •Integridad del dato: Se ha valorado como no aplicable debido a que este activo es un servicio, no un dato y por tanto la integridad del dato no se puede aplicar. •Confidencialidad de la informaci´on: Se ha valorado como no aplicable. Esto se debe a que este activo es un servicio y no un dato y en consecuencia la confidencialidad de la informaci´on no se puede aplicar. •Autenticidad: Se ha valorado con un 10, ya que si alguien hiciera uso de este servicio por ejemplo, para generar una aplicaci´on m´ovil manipulada usando un c´odigo de contagio robado, ocurrir´ıan falsos avisos a los contactos de esa persona o incluso se llegar´ıa a impedir la comunicaci´on de su contagio a la v´ıctima del robo del c´odigo de contagio. •Trazabilidad: Se ha valorado como no aplicable porque la aplicaci´on es de uso p´ublico, por tanto no se puede dejar constancia de su uso. Escuela de Ingenier´ıa Inform´atica 105 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Figura 49: Listado de amenazas de PILAR Basic (Parte 5) Escuela de Ingenier´ıa Inform´atica 112 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Figura 50: Listado de amenazas de PILAR Basic (Parte 6) El m´etodo a seguir para la identificaci´on de amenazas ser´a comprobar las consideradas por la herramienta, obviar aquellas menos probables y, en caso de ser necesario y haciendo uso del manual de MAGERIT, completarlas. Acto seguido se proceder´a a establecer a qu´e dimensiones afectan ([D] Disponibilidad, [I] Integridad, [C] Confidencialidad, [A] Autenticidad y [T] Trazabilidad), escribi´endolas en orden de relevancia de izquierda a derecha. A continuaci´on, se estimar´a la probabilidad y el impacto siguiendo una escala del 1 al 10 donde 1 sea el valor m´as bajo y 10 el valor m´as alto, es decir, se realizar´a un an´alisis cuantitativo. Finalmente, se calcular´a el riesgo multiplicando la probabilidad por el impacto. Se reflejar´a el riesgo con ese resultado y con una escala de colores. En ella encontraremos verdes para los riesgos bajos, amarillos para los riesgos medios, naranjas para los riesgos altos y finalmente rojos para los riesgos muy altos. Escuela de Ingenier´ıa Inform´atica 113 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Activos Amenazas Afecta a Probabilidad Impacto Riesgo [A.15] Modificaci´on de la informaci´on [I] 4 10 40 Estado de contagio [A.19] Revelaci´on de informaci´on [C] 9 7 63 [A.18] Destrucci´on de informaci´on [D] 2 10 20 [A.19] Revelaci´on de informaci´on [C] 2 10 20 Identificadores contagiados [E.19] Fugas de informaci´on [C] 4 10 40 [A.15] Modificaci´on de la informaci´on [I] 2 10 20 Identificadores cliente [A.19] Revelaci´on de informaci´on [C] 2 4 8 [E.15] Alteraci´on de la informaci´on [I] 4 2 8 [E.18] Destrucci´on de la informaci´on [D] 2 4 8 [A.15] Modificaci´on de la informaci´on [I] 4 2 8 Documentaci´on del proyecto [A.18] Destrucci´on de la informaci´on [D] 2 4 8 [E.15] Modificaci´on de la informaci´on [I] 7 3 28 [E.18] Destrucci´on de la informaci´on [D] 2 5 10 [A.15] Modificaci´on de la informaci´on [I] 4 3 12 [A.18] Destrucci´on de la informaci´on [D] 4 4 16 [A.11] Acceso no autorizado [C] [I] 8 2 16 Copia de seguridad de documentaci´on del proyecto en local [A.5] Suplantaci´on de la identidad [C] [A] [I] 1 2 2 Tabla 8: Tabla de amenazas y riesgos (Parte 1) Escuela de Ingenier´ıa Inform´atica 114 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Activos Amenazas Afecta a Probabilidad Impacto Riesgo [E.15] Alteraci´on de la informaci´on [I] 2 10 20 [E.18] Destrucci´on de la informaci´on [D] 2 10 20 [E.19] Fugas de informaci´on [C] 6 10 60 [A.5] Suplantaci´on de la identidad [C] [A] [I] 8 10 80 [A.6] Abuso de privilegios de acceso [C] [I] [D] 6 10 60 [A.11] Acceso no autorizado [C] [I] 8 10 80 [A.15] Modificaci´on de la informaci´on [I] 8 10 80 [A.18] Destrucci´on de la informaci´on [D] 8 10 80 Clave de cifrado de comunicaci´on con servidor [A.19] Revelaci´on de la informaci´on [C] 8 10 80 [E.15] Alteraci´on de la informaci´on [I] 2 10 20 [E.18] Destrucci´on de la informaci´on [D] 2 10 20 [E.19] Fugas de informaci´on [C] 7 10 70 [A.5] Suplantaci´on de la identidad [C] [A] [I] 8 10 80 [A.6] Abuso de privilegios de acceso [C] [I] [D] 7 10 70 [A.11] Acceso no autorizado [C] [I] 8 10 80 [A.15] Modificaci´on de la informaci´on [I] 7 10 70 [A.18] Destrucci´on de la informaci´on [D] 7 10 70 Contrase˜na de acceso a base de datos del servidor [A.19] Revelaci´on de la informaci´on [C] 8 10 80 [E.15] Alteraci´on de la informaci´on [I] 8 7 56 [E.18] Destrucci´on de la informaci´on [D] 3 10 30 [A.11] Acceso no autorizado [C] [I] 8 5 40 [A.15] Modificaci´on de la informaci´on [I] 7 7 49C´odigos fuente en local [A.18] Destrucci´on de la informaci´on [D] 5 8 40 [E.15] Alteraci´on de la informaci´on [I] 6 10 60 [E.18] Destrucci´on de la informaci´on [D] 3 10 30 [A.15] Alteraci´on de la informaci´on [I] 8 10 80C´odigos fuente en el repositorio [A.18] Destrucci´on de la informaci´on [D] 4 10 40 Tabla 9: Tabla de amenazas y riesgos (Parte 2) Escuela de Ingenier´ıa Inform´atica 115 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Activos Amenazas Afecta a Probabilidad Impacto Riesgo [E.15] Alteraci´on de la informaci´on [I] 1 7 7 [E.18] Destrucci´on de la informaci´on [D] 3 7 21 [A.15] Alteraci´on de la informaci´on [I] 5 7 35 Ejecutables [A.18] Destrucci´on de la informaci´on [D] 4 7 28 [E.2] Errores del administrador [D] [I] [C] 7 10 70 [E.15] Alteraci´on de la informaci´on [I] 7 10 70 [E.18] Destrucci´on de la informaci´on [D] 3 10 30 [E.24] Ca´ıda del sistema por agotamiento de recursos [D] 6 10 60 [A.6] Abuso de privilegios de acceso [C] [I] [D] 7 10 70 [A.7] Uso no previsto [D] [C] [I] 2 10 20 [A.11] Acceso no autorizado [C] [I] 4 10 40 [A.15] Modificaci´on de la informaci´on [I] 8 10 80 [A.18] Destrucci´on de la informaci´on [D] 8 10 80 Almacenamiento en base de datos [A.24] Denegaci´on de servicio [D] 8 10 80 [I.5] Aver´ıa de origen f´ısico o l´ogico [D] 2 10 20 [E.20] Vulnerabilidades de los programas [I] [D] [C] 9 10 90 [E.21] Errores de mantenimiento / actualizaci´on de software [I] [D] 9 10 90 Aplicaci´on m´ovil [A.22] Manipulaci´on de programas [C] [I] [D] 8 10 80 [I.5] Aver´ıa de origen f´ısico o l´ogico [D] 2 10 20 [E.20] Vulnerabilidades de los programas [I] [D] [C] 9 10 90 [E.21] Errores de mantenimiento / actualizaci´on de software [I] [D] 8 10 80 Aplicaci´on servidor [A.22] Manipulaci´on de programas [C] [I] [D] 7 10 70 Tabla 10: Tabla de amenazas y riesgos (Parte 3) Escuela de Ingenier´ıa Inform´atica 116 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Activos Amenazas Afecta a Probabilidad Impacto Riesgo [I.5] Aver´ıa de origen f´ısico o l´ogico [D] 2 10 20 [E.8] Difusi´on de software da˜nino [D] [I] [C] 6 10 60 [E.20] Vulnerabilidades de los programas [I] [D] [C] 9 10 90 [E.21] Errores de mantenimiento / actualizaci´on de software [I] [D] 8 10 80 [A.8] Difusi´on de software da˜nino [D] [I] [C] 8 10 80 MariaDB [A.22] Manipulaci´on de programas [C] [I] [D] 7 10 70 [N.1] Fuego [D] 1 8 8 [N.2] Da˜nos por agua [D] 1 8 8 [N.*] Desastres naturales [D] 1 8 8 [I.1] Fuego [D] 2 8 16 [I.2] Da˜nos por agua [D] 2 8 16 [I.*] Desastres industriales [D] 1 8 8 [I.3] Contaminaci´on mec´anica [D] 1 3 3 [I.4] Contaminaci´on electromagn´etica [D] 1 8 8 [I.5] Aver´ıa de origen f´ısico o l´ogico [D] 2 8 16 [I.6] Corte del suministro el´ectrico [D] 3 8 24 [E.23] Errores de mantenimiento / actualizaci´on de equipos hardware [D] 8 8 64 [E.24] Ca´ıda del sistema por agotamiento de recursos [D] 6 8 48 [E.25] P´erdida de equipos [D] [C] 6 10 60 [A.6] Abuso de privilegios de acceso [C] [I] [D] 8 10 80 [A.7] Uso no previsto [D] [C] [I] 9 5 40 [A.11] Acceso no autorizado [C] [I] 8 10 80 [A.23] Manipulaci´on del hardware [C] [D] 4 10 40 [A.24] Denegaci´on de servicio [D] 8 8 64 [A.25] Robo de equipos [D] [C] 7 10 70 Ordenador Juan [A.26] Ataque destructivo [D] 2 8 16 Tabla 11: Tabla de amenazas y riesgos (Parte 4) Escuela de Ingenier´ıa Inform´atica 117 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Activos Amenazas Afecta a Probabilidad Impacto Riesgo [N.1] Fuego [D] 1 10 10 [N.2] Da˜nos por agua [D] 1 10 10 [N.*] Desastres naturales [D] 1 10 10 [I.1] Fuego [D] 2 10 20 [I.2] Da˜nos por agua [D] 2 10 20 [I.*] Desastres industriales [D] 1 10 10 [I.3] Contaminaci´on mec´anica [D] 1 3 3 [I.4] Contaminaci´on electromagn´etica [D] 1 10 10 [I.5] Aver´ıa de origen f´ısico o l´ogico [D] 2 10 20 [I.6] Corte del suministro el´ectrico [D] 3 10 30 [E.23] Errores de mantenimiento / actualizaci´on de equipos hardware [D] 8 10 80 [E.24] Ca´ıda del sistema por agotamiento de recursos [D] 6 10 60 [E.25] P´erdida de equipos [D] [C] 6 10 60 [A.6] Abuso de privilegios de acceso [C] [I] [D] 8 10 80 [A.7] Uso no previsto [D] [C] [I] 9 5 40 [A.11] Acceso no autorizado [C] [I] 8 10 80 [A.23] Manipulaci´on del hardware [C] [D] 4 10 40 [A.24] Denegaci´on de servicio [D] 8 10 80 [A.25] Robo de equipos [D] [C] 7 10 70 Ordenador Mar´ıa [A.26] Ataque destructivo [D] 2 10 20 Tabla 12: Tabla de amenazas y riesgos (Parte 5) Activos Amenazas Afecta a Probabilidad Impacto Riesgo [N.1] Fuego [D] 1 10 10 [N.2] Da˜nos por agua [D] 2 10 20 [N.*] Desastres naturales [D] 1 10 10 [I.1] Fuego [D] 1 10 10 [I.2] Da˜nos por agua [D] 2 10 20 [I.*] Desastres industriales [D] 1 10 10 [I.3] Contaminaci´on mec´anica [D] 1 3 3 [I.4] Contaminaci´on electromagn´etica [D] 1 10 10 [I.5] Aver´ıa de origen f´ısico o l´ogico [D] 2 10 20 [I.6] Corte del suministro el´ectrico [D] 8 7 56 [E.23] Errores de mantenimiento / actualizaci´on de equipos hardware [D] 8 10 80 [E.25] P´erdida de equipos [D] [C] 9 10 90 [A.23] Manipulaci´on del hardware [C] [D] 5 10 50 [A.25] Robo de equipos [D] [C] 9 10 90 Dispositivo m´ovil cliente [A.26] Ataque destructivo [D] 6 10 60 Tabla 13: Tabla de amenazas y riesgos (Parte 6) Escuela de Ingenier´ıa Inform´atica 118 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Activos Amenazas Afecta a Probabilidad Impacto Riesgo [I.8] Fallo de servicios de comunicaciones [D] 5 10 50 [E.2] Errores del administrador [D] [I] [C] 5 8 40 [E.24] Ca´ıda del sistema por agotamiento de recursos [D] 5 10 50 [A.5] Suplantaci´on de la identidad [C] [A] [I] 5 10 50 [A.9] Reencaminamiento de mensajes [C] 8 7 56 [A.11] Acceso no autorizado [C] [I] 3 10 30 [A.12] An´alisis de tr´afico [C] 8 1 8 [A.14] Interceptaci´on de informaci´on [C] 8 7 56 [A.15] Modificaci´on de la informaci´on [I] 4 10 40 [A.18] Destrucci´on de la informaci´on [D] 5 10 50 Red local de piso de Juan [A.24] Denegaci´on de servicio [D] 8 10 80 [I.8] Fallo de servicios de comunicaciones [D] 5 7 35 [E.2] Errores del administrador [D] [I] [C] 5 5 25 [E.24] Ca´ıda del sistema por agotamiento de recursos [D] 5 8 40 [A.5] Suplantaci´on de la identidad [C] [A] [I] 5 8 40 [A.9] Reencaminamiento de mensajes [C] 8 8 64 [A.11] Acceso no autorizado [C] [I] 8 8 64 [A.12] An´alisis de tr´afico [C] 8 1 8 [A.14] Interceptaci´on de la informaci´on [C] 8 7 56 [A.15] Modificaci´on de la informaci´on [I] 3 8 24 [A.18] Destrucci´on de la informaci´on [D] 3 8 24 Redes locales de pruebas ([RED-002], [RED-003] y [RED-004]) [A.24] Denegaci´on de servicio [D] 8 8 64 Tabla 14: Tabla de amenazas y riesgos (Parte 7) Escuela de Ingenier´ıa Inform´atica 119 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Activos Amenazas Afecta a Probabilidad Impacto Riesgo [N.1] Fuego [D] 1 10 10 [N.2] Da˜nos por agua [D] 1 10 10 [N.*] Desastres naturales [D] 1 10 10 [I.1] Fuego [D] 1 10 10 [I.2] Da˜nos por agua [D] 2 10 20 [I.*] Desastres industriales [D] 1 10 10 [I.4] Contaminaci´on electromagn´etica [D] 1 10 10 [I.5] Aver´ıa de origen f´ısico o l´ogico [D] 1 10 10 [I.10] Degradaci´on de los soportes de informaci´on [D] 10 10 100 [E.15] Alteraci´on de la informaci´on [I] 8 1 8 [E.18] Destrucci´on de la informaci´on [D] 5 5 25 [E.19] Fuga de informaci´on [C] 6 10 60 [E.23] Errores de mantenimiento / actualizaci´on de equipos hardware [D] 8 10 80 [E.25] P´erdida de equipos [D] [C] 6 10 60 [A.15] Modificaci´on de la informaci´on [I] 6 1 6 [A.18] Destrucci´on de la informaci´on [D] 8 5 40 [A.23] Manipulaci´on del hardware [C] [D] 6 10 60 [A.25] Robo de equipos [D] [C] 7 10 70 Discos duros ([MED-001] y [MED-002]) [A.26] Ataque destructivo [D] 2 10 20 Tabla 15: Tabla de amenazas y riesgos (Parte 8) Escuela de Ingenier´ıa Inform´atica 120 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Activos Amenazas Afecta a Probabilidad Impacto Riesgo [E.15] Alteraci´on de la informaci´on [I] 8 8 64 [E.18] Destrucci´on de la informaci´on [D] 6 10 60 [E.19] Fugas de informaci´on [C] 7 10 70 [A.11] Acceso no autorizado [C] [I] 5 10 50 [A.15] Modificaci´on de la informaci´on [I] 5 8 40 Canal de Discord y Chat de Telegram [A.18] Destrucci´on de la informaci´on [D] 5 10 50 [E.15] Alteraci´on de la informaci´on [I] 5 10 50 [E.18] Destrucci´on de la informaci´on [D] 3 10 30 [A.15] Modificaci´on de la informaci´on [I] 7 10 70Repositorios de las aplicaciones [A.18] Destrucci´on de la informaci´on [D] 6 10 60 [E.15] Alteraci´on de la informaci´on [I] 7 3 21 [E.18] Destrucci´on de la informaci´on [D] 3 5 15 [A.11] Acceso no autorizado [C] [I] 5 2 10 [A.15] Modificaci´on de la informaci´on [I] 4 3 12Overleaf [A.18] Destrucci´on de la informaci´on [D] 5 5 25 [N.1] Fuego [D] 1 8 8 [N.2] Da˜nos por agua [D] 1 8 8 [N.*] Desastres naturales [D] 1 8 8 [I.1] Fuego [D] 1 8 8 [I.2] Da˜nos por agua [D] 2 8 16 [I.*] Desastres naturales [D] 1 8 8 [A.26] Ataque destructivo [D] 1 8 8 Piso de Juan [A.27] Ocupaci´on enemiga [D] [C] 1 10 10 Tabla 16: Tabla de amenazas y riesgos (Parte 9) Escuela de Ingenier´ıa Inform´atica 121 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa 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. De la aplicaci´on cliente hay varias mejoras que podr´ıan implementarse 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. 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. Como se ha podido observar en el an´alisis de riesgos de seguridad y privacidad, la mayor´ıa de riesgos en el ´ambito de la privacidad tienen como causa la ausencia o la mala redacci´on de una pol´ıtica de privacidad. Es por ello que para cumplir la normativa se deber´ıa redactar una, prestando especial atenci´on a los riesgos ah´ı expuestos. Implementar las contramedidas extra´ıdas del an´alisis. Para que este proyecto sea viable se deber´ıan minimizar los riesgos que surgidos en el an´alisis. Para lograr paliar aquellos m´as perjudiciales habr´ıa que aplicar las salvaguardas descritas en el apartado anterior. Como podemos ver, todav´ıa hay muchas l´ıneas de trabajo que pueden ser desarrolladas y mejoradas. Muchas de ellas refieren a la implementaci´on, as´ı como a las salvaguardas deducidas del an´alisis llevado a cabo con la herramienta PILAR. Como se ha podido concluir, en este tipo de aplicaciones de control sobre el estado COVID, todav´ıa hay muchos riesgos desde el punto de vista de dise˜no del protocolo. Es por ello que una buena idea ser´ıa llevar a cabo un enfoque distinto empleando otras tecnolog´ıas, como puede ser el uso de tecnolog´ıas descentralizadas que permitan al usuario almacenar su propia informaci´on, las cuales proporcionan una mejor privacidad de los datos. En este campo encontramos el concepto de la Identidad Autosoberana o SSI (Self-Sovereign Identity). Lo que este concepto viene a decir en l´ıneas generales es que sea el propio usuario el propietario de sus datos, almacen´andolos en un monedero virtual o wallet, sin recurrir a otras entidades centralizadas. As´ı cada usuario posee su propia identidad digital. De esta forma, en el caso, por ejemplo, de tener que presentar tu estado COVID, en lugar de mostrar un pasaporte con toda tu identificaci´on nacional, acreditar´ıas ´unicamente el estado de vacunaci´on o PCR asociado a tu identidad digital. Escuela de Ingenier´ıa Inform´atica 128 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Valoraci´on personal Con este trabajo he podido conocer en profundidad en el campo de los protocolos de rastreo de contactos. Creo firmemente que el uso de ellos puede ayudar en la contenci´on de futuras epidemias y pandemias. Aunque no es mi deseo en absoluto, en un mundo tan sumamente globalizado la probabilidad de que aparezcan es bastante alta. Por esta raz´on debemos estar preparados y utilizar la tecnolog´ıa como una aliada para evitarlas. Otros aspectos en los que me he podido adentrar son la seguridad y la privacidad. Pienso que son aspectos del software a los cuales no se les dedica el suficiente trabajo y dedicaci´on. Si bien es un campo complejo, me ha resultado interesante conocer los est´andares que rigen los desarrollos de software, as´ı como los cifrados que se utilizan en ellos y las amenazas a las que est´an expuestos. Para finalizar me gustar´ıa tambi´en hablar sobre el desarrollo en equipo. Siempre he considerado que el trabajo en equipo, sobre todo en el desarrollo y mantenimiento de software, es algo imprescindible ya que es muy dif´ıcil que una ´unica persona disponga de todos los conocimientos necesarios para realizar un desarrollo completo. Con este trabajo he podido vivir en primera persona todo lo que implica: Adecuaci´on de horarios, confrontaci´on de ideas, uso de metodolog´ıas de trabajo, puntos muertos, toma de decisiones... En este caso, mi compa˜nera Mar´ıa Ruiz Molina ha realizado una labor fant´astica tanto en el aprendizaje como en la transmisi´on de conocimientos. Siempre ha demostrado compromiso, esfuerzo, profesionalidad y compa˜nerismo lo que ha hecho m´as ameno el desarrollo de este proyecto. Escuela de Ingenier´ıa Inform´atica 129 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Anexo I: Contenido adjunto El contenido adjunto a este documento incluye: DatosTFGJuanVelazquezGarcia.zip. Que contiene los siguientes ficheros. •agavaserver.zip. C´odigo aplicaci´on servidor. •agavaclient.zip. C´odigo aplicaci´on cliente. •agavaanalisis.mgr. Proyecto para programa PILAR Basic. Contrase˜na: a Escuela de Ingenier´ıa Inform´atica 130 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Anexo II: Manual de instalaci´on Requisitos de instalaci´on Se necesitan los siguientes elementos previamente a realizar la instalaci´on de todo el proyecto. Dispositivo m´ovil con Android versi´on 10 y Bluetooth. Dispositivo diferente al anterior para despliegue del servidor. Acceso a una red para realizar comunicaciones por Internet. Ser´a necesaria la instalaci´on de los siguientes componentes en el dispositivo donde se desplegar´a el servidor. Java JDK-8. NetBeans IDE 8.2 para la ejecuci´on del servidor. Configuraci´on del c´odigo en UTF-8. Gestor de base de datos MariaDB versi´on 10.5.9. MySQL Connector/J para realizar la conexi´on de la base de datos con NetBeans. Android Studio. Solo en caso de querer editar alg´un componente del c´odigo de la aplicaci´on cliente. Ser´a necesaria la instalaci´on de los siguientes componentes en el dispositivo donde se desplegar´a el cliente. Ejecutable de la aplicaci´on. Instalaci´on del servidor Se descargar´a e instalar´a NetBeans 8.2 desde https://www.oracle.com/technetwork/java/javase/downloads/ jdk-netbeans-jsp-3413139-esa.html. Esta versi´on incluye JDK-8, pero de querer instalar este por separado puede hacerse desde https://www. oracle.com/es/java/technologies/javase/javase-jdk8-downloads.html. Tras ello, se descargar´a el gestor de base de datos MariaDB desde https://mariadb.org/download/, en concreto la versi´on 10.5.9. Despu´es se ejecuta el gestor y se crea la base de datos con el siguiente comando: CREATE DATABASE agavacovid; Ejecutamos el comando para usar la base de datos: USE agavacovid; A continuaci´on creamos la tabla: CREATE TABLE ids_infectados(id SERIAL NOT NULL, clave_gen VARCHAR(255) NOT NULL, fecha_gen DATE NOT NULL, fecha_rec DATE NOT NULL, PRIMARY KEY (id)); Escuela de Ingenier´ıa Inform´atica 131 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Una vez hecho esto, es necesario instalar el conector MySQL Connector/J (descargable desde https: //dev.mysql.com/downloads/connector/j/8.0.html). Se descomprime el contenido de lo descargado. El archivo mysql-connector-java-8.0.12.jar se debe situar en el mismo directorio que mantiene los archivos comunes de las librer´ıas de JAVA. Se hace click derecho encima del nombre del proyecto y se selecciona Properties. Tras ello se pulsa en Libraries - Compile - Add Jar/Folder. Aqu´ı se selecciona el archivo mysql-connectorjava-8.0.12.jar y se pulsa Open y tras ello OK. Es importante cambiar en el c´odigo del archivo AgavaCovidServer.java los datos referentes a usuario y contrase˜na por los propios. AgavaPreferences.setCredentials("TU_USUARIO", "TU_CONTRASE~ NA"); Instalaci´on del cliente Se descargar´a e instalar´a Android Studio desde https://developer.android.com/studio?hl=es&gclid= EAIaIQobChMIqr2blNjq8QIVxQwGAB27WQ96EAAYASAAEgKFv_D_BwE&gclsrc=aw.ds. Despu´es se abrir´a el proyecto agavaclient.zip A continuaci´on habr´a que editar en el c´odigo de la aplicaci´on la direcci´on IP del ordenador con el servidor, as´ı como, de ser necesario, los puertos con los que se comunicar´a en el archivo AgavaSocket.java que se encuentra en el paquete sockets. . Tras realizar las pertinentes modificaciones, se selecciona la siguiente opci´on en el men´u superior con el fin de generar un ejecutable de la aplicaci´on. Este ejecutable lo descargaremos en nuestro dispositivo y finalmente lo instalaremos. Figura 51: Build APK Escuela de Ingenier´ıa Inform´atica 132 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Anexo III: Manual de usuario Aplicaci´on servidor Para el uso de esta aplicaci´on solo debemos tener en cuenta ciertos detalles: Comprobar el estado del firewall. En el equipo donde vayamos a ejecutar la aplicaci´on debemos comprobar que el firewall no filtre los puertos que utiliza el programa. Esto se puede comprobar f´acilmente al ejecutar el proyecto, pues a la aplicaci´on m´ovil no le llegar´an mensajes si efectivamente se realiza este filtrado. La soluci´on pasa por desactivarlo mientras se lleva a cabo la ejecuci´on. Algunos antivirus, gestionan este filtrado y permitir o no el paso seg´un su configuraci´on. En este caso debemos explorar nuestro antivirus y configurarlo para que permita las comunicaciones. Comprobar el uso de los puertos. Tambi´en puede ocurrir que alg´un otro software tenga en uso los puertos utilizados por la aplicaci´on. Recomendamos revisar si los puertos 3327, 3384 y 4445 est´an uso. Para ejecutar la aplicaci´on ´unicamente debemos abrir Netbeans y ejecutar el archivo AgavaCovidServer.java localizado en el paquete agavacovidserver. Aplicaci´on Cliente. Bienvenid@ a AgavaCovid, tu nueva aplicaci´on de rastreo de contactos. Antes de empezar, nos gustar´ıa darte las gracias por confiar en nosotros para la protecci´on de tu salud y la de tus conocidos. ¿Qu´e es AgavaCovid? Como ya sabr´as, AgavaCovid es una aplicaci´on de rastreo de contactos pero, ¿eso qu´e quiere decir? AgavaCovid permite conocer si has tenido contacto con otro usuario de la aplicaci´on contagiado gracias a la tecnolog´ıa Bluetooth. Al cruzarte con esa persona vuestras aplicaciones registran el uno al otro an´onimamente. En caso de que uno de los dos se contagie, mediante el uso de un c´odigo proporcionado por la autoridad sanitaria el infectado podr´a comunicar su contagio y la aplicaci´on autom´aticamente te avisar´a en caso de haber estado en contacto. Primeros pasos. Para abrir la aplicaci´on solo debemos pulsar en el icono con el t´ıtulo AgavaCovid. Una vez abierta nos aparecer´a un peque˜no di´alogo donde nos preguntar´a si queremos dar nuestro permiso para utilizar Bluetooth. Para que la aplicaci´on funcione correctamente debemos dar a permitir. Acto seguido, si nos fijamos en la parte superior de nuestro tel´efono veremos que nos aparecer´a el icono de Bluetooth encendido. Escuela de Ingenier´ıa Inform´atica 133 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Pantalla principal. En la pantalla principal nos encontramos con cuatro elementos. En la parte superior encontramos una imagen con las mascotas de la aplicaci´on Aga y Gava. En esta versi´on prototipo, al pulsar este bot´on realizamos el intercambio de informaci´on entre dispositivos (en la versi´on final esto se har´ıa de forma autom´atica). Justo debajo encontramos un recuadro con nuestro estado de contagio. En caso de no estar contagiado y sin contactos contagiados, aparecer´a en verde; en caso de un contacto contagiado, en naranja; y en caso de estar contagiado, en rojo. Si pulsamos en ´el nos aparecer´a una pantalla con unos consejos que cambiar´an dependiendo de nuestro estado de contagio. Si volvemos a la pantalla principal vemos un bot´on azul que dice Comunica tu positivo. Este bot´on nos da a acceso a un formulario para comunicar nuestro positivo en caso de estar contagiados. Finalmente, en la parte de abajo encontramos tres botones con los t´ıtulos Principal,Informaci´on yAjustes de Idioma. Si pulsamos sobre ellos cambiaremos de pantalla. Pantalla de informaci´on En la pantalla de informaci´on encontramos la pol´ıtica de privacidad y el compromiso con el usuario. Pantalla de Ajustes de Idioma En primer lugar encontramos una lista con los diferentes idiomas para los que la aplicaci´on est´a disponible. Si pulsamos sobre uno de ellos veremos que se oscurecer´a, significando que est´a seleccionado. En la parte de abajo encontramos un bot´on de confirmaci´on que al pulsar cambiar´a el idioma al seleccionado en la lista anterior. ¿C´omo comunico que estoy contagiado? 1. Nos colocamos en la Pantalla Principal y pulsamos el bot´on Comunica tu positivo. 2. En la pantalla del formulario encontramos dos campos la fecha y el c´odigo de contagio. 3. En caso de conocer alguna, introduciremos o bien la fecha de inicio de s´ıntomas o bien la fecha de toma de muestra para diagn´ostico. Para ello simplemente tendremos que pulsar sobre el campo y nos aparecer´a un calendario. Ah´ı nos saldr´an en resaltado las fechas de los ´ultimos 14 d´ıas para poder seleccionar una de ellas. Pinchamos en una de ellas y pulsamos en Aceptar. Una vez seleccionemos la fecha, nos aparecer´a escrita en formato a˜no-mes-d´ıa. 4. Tras esto pulsamos sobre el campo Introduzca el c´odigo. Introducimos el n´umero proporcionado por la autoridad sanitaria. En este caso al ser un prototipo a modo de simulaci´on hay disponibles ´unicamente estos c´odigos v´alidos 123456789012, 273384273384 y 133713371337. 5. Si el c´odigo es correcto al pulsar en Aceptar nos saldr´an dos nuevos botones para confirmar el env´ıo. En caso de querer rectificar pulsaremos Cancelar y modificaremos los datos que sean necesarios. Si est´a todo bien pulsamos en Aceptar. 6. Podremos apreciar en la pantalla principal que nuestro estado de contagio habr´a cambiado a Contagiado. Escuela de Ingenier´ıa Inform´atica 134 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa Anexo IV: Diccionario RGPD ((El Reglamento General de Protecci´on de Datos (RGPD) es el reglamento europeo relativo a la protecci´on de las personas f´ısicas en lo que respecta al tratamiento de sus datos personales y a la libre circulaci´on de estos datos. Entr´o en vigor el 24 de mayo de 2016 y fue de aplicaci´on el 25 de mayo de 2018, dos a˜nos durante los cuales las empresas, las organizaciones, los organismos y las instituciones se fueron adaptando para su cumplimiento. Es una normativa a nivel de la Uni´on Europea, por lo que cualquier empresa de la uni´on, o aquellas empresas que tengan negocios en la Uni´on Europea, que manejen informaci´on personal de cualquier tipo, deber´an acogerse a ella. Las multas por el no cumplimiento del RGPD pueden llegar a los 20 millones de euros.))(Wikipedia. Reglamento General de Protecci´on de Datos, 2021) ENS ((En el ´ambito de la Administraci´on Electr´onica espa˜nola, el Esquema Nacional de Seguridad (ENS) tiene por objeto establecer la pol´ıtica de seguridad en la utilizaci´on de medios electr´onicos y est´a constituido por principios b´asicos y requisitos m´ınimos que permitan una protecci´on adecuada de la informaci´on. Dicho esquema se regula en Real Decreto 3/2010, de 8 de enero, y fue establecido anteriormente en el art´ıculo 42 de la Ley 11/2007, de 22 de junio, de acceso electr´onico de los ciudadanos a los Servicio P´ublicos, que fue modificado por el Real Decreto 951/2015 para actualizarlo a la luz de la experiencia obtenida en su implantaci´on, de la evoluci´on de la tecnolog´ıa y las ciberamenazas y del contexto regulatorio internacional y europeo.)) (Wikipedia. Esquema Nacional de Seguridad, 2021) COVID-19 ((La enfermedad por coronavirus de 2019, m´as conocida como COVID-19 es una enfermedad infecciosa causada por el virus SARS-CoV-2. Produce s´ıntomas similares a los de la gripe o catarro, entre los que se incluyen fiebre, tos, disnea, mialgia y fatiga. En casos graves se caracteriza por producir neumon´ıa, s´ındrome de dificultad respiratoria aguda, sepsis y choque s´eptico que conduce a cerca de 3,75 % de los infectados a la muerte seg´un la OMS.18)) (Wikipedia. COVID-19, 2021) Identificador ef´ımero Elemento que se emplea para identificar al usuario un´ıvocamente. Son ´unicos con el fin de evitar colisiones. Son generados de manera aleatoria a partir de unas semillas. Su duraci´on est´a delimitada por un determinado periodo de tiempo y es sucedido por otro. Esto es as´ı porque en el contexto de esta aplicaci´on, es necesario determinar el periodo temporal en el cual se ha mantenido el contacto entre dos usuarios. De esta manera se dificulta el seguimiento de un usuario ya que el identificador cambia transcurrido dicho tiempo. En el tipo de aplicaciones como la desarrollada en este trabajo, es fundamental que los identificadores no revelen informaci´on personal y/o privada de los usuarios. Escuela de Ingenier´ıa Inform´atica 135 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa SDK ((Un kit de desarrollo de software (en ingl´es, software development kit o SDK) es generalmente un conjunto de herramientas de desarrollo de software que permite a un desarrollador de software crear una aplicaci´on inform´atica para un sistema concreto, por ejemplo ciertos paquetes de software, entornos de trabajo, plataformas de hardware, computadoras, videoconsolas, sistemas operativos, etc´etera.)) (Wikipedia. Kit de desarrollo de software, 2020) IMEI IMEI significa International Mobile Equipment Identity, y es un identificador ´unico que tiene cada tel´efono m´ovil. El c´odigo consta de cuatro partes: TAC o Type Allocation Code (los primeros dos indican el RBI o Reporting Body Identifier, es decir, la organizaci´on encargada de regular el tel´efono), FAC o Final Assembly Code (indica el fabricante), N´umero de serie, C´odigo verificador (verifica que el c´odigo sea correcto y no haya habido errores). Direcci´on MAC ((En las redes de computadoras, la direcci´on MAC (siglas en ingl´es de Media Access Control) es un identificador de 48 bits (6 bloques de dos caracteres hexadecimales [8 bits]) que corresponde de forma ´unica a una tarjeta o dispositivo de red. Se la conoce tambi´en como direcci´on f´ısica, y es ´unica para cada dispositivo. Est´a determinada y configurada por el IEEE (los ´ultimos 24 bits) y el fabricante (primeros 24 bits))). (Wikipedia. Direcci´on MAC, 2021) Direcci´on MAC de BlueTooth Se trata de la direcci´on identificadora de cada dispositivo para entablar conexiones BlueTooth. Estas est´an conformadas por 12 caracteres hexadecimales. BlueTooth ((Bluetooth es una especificaci´on industrial para redes inal´ambricas de ´area personal (WPAN) creado por Bluetooth Special Interest Group, Inc. que posibilita la transmisi´on de voz y datos entre diferentes dispositivos mediante un enlace por radiofrecuencia en la banda ISM de los 2.4 GHz. Los principales objetivos que se pretenden conseguir con esta norma son: Facilitar las comunicaciones entre equipos m´oviles. Eliminar los cables y conectores entre estos. Ofrecer la posibilidad de crear peque˜nas redes inal´ambricas y facilitar la sincronizaci´on de datos entre equipos personales. Los dispositivos que con mayor frecuencia utilizan esta tecnolog´ıa pertenecen a sectores de las telecomunicaciones y la inform´atica personal, como tel´efonos m´oviles, computadoras port´atiles [...] o c´amaras digitales)). (Wikipedia. Bluetooth, 2021) Escuela de Ingenier´ıa Inform´atica 136 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa WiFi ((El wifi (escrito tambi´en wi fi) es una tecnolog´ıa que permite la interconexi´on inal´ambrica de dispositivos electr´onicos. Los dispositivos habilitados con wifi (tales como ordenadores personales, tel´efonos, televisores, videoconsolas, reproductores de m´usica, etc´etera) pueden conectarse entre s´ı o a Internet a trav´es de un punto de acceso de red inal´ambrica)). (Wikipedia. Wifi, 2021) IP ((La direcci´on IP es un conjunto de n´umeros que identifica, de manera l´ogica y jer´arquica, a una interfaz en la red (elemento de comunicaci´on/conexi´on) de un dispositivo (computadora, laptop, tel´efono inteligente) que utilice el protocolo (Internet Protocol) o, que corresponde al nivel de red del modelo TCP/IP. La direcci´on IP no debe confundirse con la direcci´on MAC)). (Wikipedia. Direcci´on IP, 2021) BLE/BlueTooth Low Energy ((Bluetooth Low Energy (Bluetooth LE, coloquialmente BLE) es una tecnolog´ıa de red de ´area personal [...] destinada a aplicaciones novedosas en el cuidado de la salud, fitness y beacons, seguridad y las industrias de entretenimiento en el hogar. Comparado con el Bluetooth cl´asico, Bluetooth Low Energy est´a dise˜nado para proporcionar un bajo consumo de energ´ıa, manteniendo un rango de alcance de comunicaci´on similar)). (Wikipedia. Bluetooth de baja energ´ıa, 2020) Semillas generadoras Estas consisten en dos elementos, la clave generadora, y la fecha generadora. Claves generadoras Consiste en una clave generada a partir de una secuencia binaria, la cual es subdividida en n claves generadoras que se emplean a lo largo del d´ıa. Dicha secuencia es obtenida de manera pseudoaleatoria a partir de metodolog´ıas criptogr´aficas. Estas claves se emplean para generar cada uno de los identificadores ef´ımeros. Fechas generadoras Es la fecha que indica el fragmento a seleccionar de la clave generadora. Estas fechas siempre van de 15 en 15 minutos desde las 00:00:00. Cada 15 minutos indica se selecciona el fragmento siguiente a utilizar, el cual determina el identificador ef´ımero de ese periodo de tiempo. Paradigma ((Para la Ingenier´ıa de Software el paradigma es una agrupaci´on de m´etodos, herramientas y procedimientos con el fin de describir un modelo.)) (Heli Sulbaran Sistemas. Paradigmas en el desarrollo de software, 2014) Escuela de Ingenier´ıa Inform´atica 137 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa [18] Paul Dalg y col. “Das gef¨ahrliche Chaos um die Corona-App”. En: Tagesspiegel (abr. de 2020). url:https : / / www . tagesspiegel . de / wissen / welche - technologie - soll - es - sein - das - gefaehrliche-chaos-um-die-corona-app/25755338.html (visitado 23-03-2021). [19] Decentralized Privacy-Preserving Proximity Tracing. [Online]. Dic. de 2020. url:https://en.wikipedia. org/wiki/Decentralized_Privacy-Preserving_Proximity_Tracing (visitado 16-04-2021). [20] Definition of IP multicast. url:https : / / www . pcmag . com / encyclopedia / term / ip - multicast (visitado 19-04-2021). [21] Paul-Olivier Dehaye y Joel Reardon. “SwissCovid: a critical analysis of risk assessment by Swiss authorities”. En: CoRR abs/2006.10719 (2020). arXiv: 2006.10719.url:https://arxiv.org/abs/2006. 10719 (visitado 09-11-2020). [22] Desconocido. “Den Tracing-App-Entwicklern laufen die Partner weg”. En: Spiegel Netzwelt (abr. de 2020). url:https://www.spiegel.de/netzwelt/apps/pepp-pt-in-corona-krise-den-tracingapp - entwicklern - laufen - die - partner - weg - a - 017f50eb - c1e2 - 4097 - 8182 - 53708ca6db59 (visitado 23-03-2021). [23] Difference with Apple/Google solution. [Online]. Nov. de 2020. url:https://github.com/DP-3T/ documents/issues/128 (visitado 19-04-2021). [24] Procedimientos e Impulso de la Administraci´on Electr´onica Direcci´on General de Modernizaci´on Administrativa. “MAGERIT – versi´on 3.0. Metodolog´ıa de An´alisis y Gesti´on de Riesgos de los Sistemas de Informaci´on. Libro II - Cat´alogo de Elementos”. En: (oct. de 2012). url:https://pilar.ccn-cert. cni.es/index.php/docman/documentos/2-magerit-v3-libro-ii-catalogo-de-elementos/file (visitado 30-06-2021). [25] Documento BOE-A-2015-11881. url:https://www.boe.es/eli/es/rd/2015/10/23/951 (visitado 05-07-2021). [26] Documento consolidado BOE-A-2007-12352. url:https://www.boe.es/eli/es/l/2007/06/22/11/ con (visitado 05-07-2021). [27] Documento consolidado BOE-A-2010-1330. url:https://www.boe.es/eli/es/rd/2010/01/08/3/ con (visitado 05-07-2021). [28] DP3T - Decentralized Privacy-Preserving Proximity Tracing. [Online]. Dic. de 2020. url:https:// github.com/DP-3T/documents (visitado 16-04-2021). [29] Exposure Notification. [Online]. Nov. de 2020. url:https://en.wikipedia.org/wiki/Exposure_ Notification (visitado 15-04-2021). [30] Carlos Alonso Gonz´alez. Introducci´on a la Miner´ıa de Datos. https://aulas.inf.uva.es/pluginfile. php/41079/mod_resource/content/6/01IntroduccionMD.pdf. Accessed: 2021–03-03. 2020. [31] Lisa Hegemann. “Wissenschaftler warnen vor ”beispielloser ¨ Uberwachung””. En: Zeit (abr. de 2020). url:https://www.zeit.de/digital/datenschutz/2020-04/corona-app-initiative-pepp-ptdatenschutz-warnung-forscher (visitado 23-03-2021). [32] Alex Hern. “Digital contact tracing will fail unless privacy is respected, experts warn”. En: The Guardian (abr. de 2020). url:https : / / www . theguardian . com / world / 2020 / apr / 20 / coronavirus - digitalcontacttracingwillfailunlessprivacyisrespectedexpertswarn (visitado 17-11-2020). [33] Mike Cotterell . Bob Hughes. ““Software Project Management”, Fifth Edition, Tata McGraw Hill, 2004.” En: 2015. [34] Simon Hurtz. “Der Anti-Corona-App droht ein Glaubenskrieg unter Forschern”. En: S¨uddeutsche Zeitung (abr. de 2020). url:https://www.sueddeutsche.de/digital/coronaviruspeppptdp3tsmartphone-app-streit-1.4882612 (visitado 23-03-2021). Escuela de Ingenier´ıa Inform´atica 144 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa [35] INES. url:https : / / www . ccn - cert . cni . es / soluciones - seguridad / ines . html (visitado 06-07-2021). [36] Introducci´on general a Bluetooth. [Online]. Nov. de 2020. url:https://developer.android.com/ guide/topics/connectivity/bluetooth?hl=es-419 (visitado 30-05-2021). [37] A. Tan; C. Sheng Hau; L. Yongquan; J. Tan J. Bay; J. Kek y T. Anh Quy. “BlueTrace: A privacypreserving protocol forcommunity-driven contact tracing across borders”. En: (dic. de 2020). url: https://bluetrace.io/static/bluetrace_whitepaper938063656596c104632def383eb33b3c. pdf (visitado 25-01-2021). [38] Bobbie Johnson. “Some prominent exposure apps are slowly rolling back freedoms”. En: (nov. de 2020). url:https : / / 2020 . internethealthreport . org / slideshow - internet - health / #16 (visitado 13-11-2020). [39] Sebastian Kl¨ockner. Joint Statement on Contact Tracing. Abr. de 2020. url:https://cispa.de/ en/newsandevents/newsarchive/articles/2020/jointstatement-oncontacttracing (visitado 24-03-2021). [40] N. Lomas. “Norway pulls it’s coronavirus contacts tracing app after privacy watchdogs warning”. En: (dic. de 2020). url:https://techcrunch.com/2020/06/15/norwaypullsitscoronaviruscontacts-tracing-appafter-privacy-watchdogswarning/?guccounter=1&guce_referrer= aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAANqd1ugQ71yUiD22OjcVdJtVmSUPfuVEqULuAwgeXtLXCIZwYz3ij5XYlOX8ZseqYHiE1Ct4Af9h2mm061Tar2KJKokRTfuejJAwNkdt8-1LMvTajRzId8N4ptyTw4X1Aa-O7nN7KrQIiC3v6i896imMAzsmaaR7AO9UaLaapln (visitado 29-12-2020). [41] MAGERIT v.3 : Metodolog´ıa de An´alisis y Gesti´on de Riesgos de los Sistemas de Informaci´on. url:https: //administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_ Magerit.html (visitado 05-07-2021). [42] MariaDB. [Online]. Mar. de 2021. url:https : / / es . wikipedia . org / wiki / MariaDB (visitado 07-04-2021). [43] Rafael Mar´ın. Los gestores de bases de datos m´as usados en la actualidad. url:https://revistadigital. inesem.es/informaticaytics/losgestoresdebasesdedatosmasusados/ (visitado 07-04-2021). [44] Misi´on y Objetivos. url:https://www.ccn-cert.cni.es/sobre-nosotros/mision-y-objetivos. html (visitado 03-07-2021). [45] Mobile databases: SQLite and SQLite alternatives for Android and iOS. [Online]. Dic. de 2020. url: https://greenrobot.org/news/mobiledatabasessqlitealternativesandnosqlforandroid-and-ios/ (visitado 04-04-2021). [46] MySQL. [Online]. Ene. de 2021. url:https://es.wikipedia.org/wiki/MySQL (visitado 04-04-2021). [47] MySQL, MariaDB y PostgreSQL: ¿Cu´al elegimos? [Online]. Jun. de 2020. url:https://www.arsys. es/blog/mysql-mariadb-postgresql/ (visitado 04-04-2021). [48] Centro Criptol´ogico Nacional. “Ciberamenazas y tendencias”. En: (sep. de 2020). url:https : / / www.ccn-cert.cni.es/informes/informes-ccn-cert-publicos/5377-ccn-cert-ia-13-20ciberamenazas-y-tendencias-edicion-2020/file.html (visitado 02-07-2021). [49] Centro Criptol´ogico Nacional. “Dispositivos m´oviles. Informe de buenas pr´acticas”. En: (mayo de 2021). url:https://www.ccn-cert.cni.es/informes/informes-ccn-cert-publicos/1807-ccn-certbp-03-dispositivos-moviles-1/file.html (visitado 02-07-2021). [50] Patrick Howell O’Neill. Norway halts coronavirus app over privacy concerns. Nov. de 2020. url:https: //www.technologyreview.com/2020/06/15/1003562/norwayhaltscoronavirusapp-overprivacy-concerns/ (visitado 15-12-2020). Escuela de Ingenier´ıa Inform´atica 145 An´alisis de Privacidad en una App de Rastreo UVa - Trabajo de Fin de Grado 2020/21 J. Vel´azquez Garc´ıa [51] Pan-European Privacy-Preserving Proximity Tracing. [Online]. Dic. de 2020. url:https://en.wikipedia. org/wiki/Pan-European_Privacy-Preserving_Proximity_Tracing (visitado 20-04-2021). [52] Pilar. url:https://pilar.ccn-cert.cni.es/index.php/pilar/pilar (visitado 06-07-2021). [53] Pilar Basic. url:https://pilar.ccncert.cni.es/index.php/pilar/pilarbasic (visitado 06-07-2021). [54] Plan Director de Seguridad. Mar. de 2021. url:https://www.incibe.es/protege-tu-empresa/ que-te-interesa/plan-director-seguridad (visitado 14-06-2021). [55] Protocolo seguro. [Online]. Mar. de 2021. url:https://es.wikipedia.org/wiki/Protocolo_seguro (visitado 20-03-2021). [56] Ransomware. [Online]. Jun. de 2021. url:https://es.wikipedia.org/wiki/Ransomware (visitado 04-07-2021). [57] REYES. url:https://www.ccncert.cni.es/solucionesseguridad/amparo.html (visitado 06-07-2021). [58] Security Considerations For Bluetooth Smart Devices. url:https : / / www . design - reuse . com / articles / 39779 / security - considerations - for - bluetooth - smart - devices . html (visitado 10-05-2021). [59] Jos´e Luis Sevillano y col. “Soft real-time communications over Bluetooth under interferences from ISM devices”. En: Int. J. Commun. Syst. 19.10 (2006), p´ags. 1103-1116. doi:10.1002/dac.796.url: https://doi.org/10.1002/dac.796 (visitado 22-05-2021). [60] Soluciones de Ciberseguridad. url:https://www.ccn-cert.cni.es/soluciones-seguridad.html (visitado 02-07-2021). [61] Mark Surman. Privacy Norms and the Pandemic. Abr. de 2020. url:https://blog.mozilla.org/ blog/2020/04/22/privacy-norms-and-the-pandemic/ (visitado 27-04-2021). [62] Ni Trieu y col. “Epione: Lightweight Contact Tracing with Strong Privacy”. En: IEEE Data Eng. Bull. 43.2 (2020), p´ags. 95-107. url:http://sites.computer.org/debull/A20june/p95.pdf (visitado 21-04-2021). [63] Ni Trieu y col. “Epione: Lightweight Contact Tracing with Strong Privacy”. En: ArXiv abs/2004.13293 (2020). (Visitado 25-04-2021). [64] Ni Trieu y col. Epione: Lightweight Contact Tracing with Strong Privacy. url:https://sunblazeucb.github.io/privacy/projects/epione.html (visitado 25-04-2021). [65] Serge Vaudenay. “Analysis of DP3T”. En: IACR Cryptol. ePrint Arch. 2020 (2020), p´ag. 399. url: https://eprint.iacr.org/2020/399 (visitado 27-04-2021). [66] Serge Vaudenay. “Centralized or Decentralized? The Contact Tracing Dilemma”. En: IACR Cryptol. ePrint Arch. 2020 (2020), p´ag. 531. url:https://eprint.iacr.org/2020/531 (visitado 27-04-2021). [67] Matthew Wickline y the Human-Computer Interaction Resource Network. “Color Blind Simulation”. En: (- de 2001). url:https://www.color-blindness.com/coblis-color-blindness-simulator/ (visitado 06-07-2021). [68] PILAR. url:https : / / pilar . ccn - cert . cni . es / index . php / pilar / pilar - micro (visitado 06-07-2021). Escuela de Ingenier´ıa Inform´atica 146 An´alisis de Privacidad en una App de Rastreo