Sobre la colaboración entre Google y Apple para el seguimiento de infecciones COVID-19 mediante Bluetooth.
Recientemente, los dos gigantes tecnológicos han puesto en marcha una iniciativa conjunta para el seguimiento semi-descentralizado de infecciones y mejorar la gestión de la crisis sanitaria por parte de las autoridades gubernamentales pertinentes. Se trata de la liberación de una API que los gobiernos pueden integrar en sus aplicaciones y que va en la línea de la aplicación TraceTogether empleada por el gobierno de Singapur desde hace meses.
A continuación, se explican algunos detalles técnicos del funcionamiento del modelo y se problematizan tangencialmente algunas de las dudas concernientes a la seguridad y la privacidad de los usuarios que el modelo acarrea.
Entendiendo el modelo.
El objetivo fundamental del modelo es permitir, de forma semi-descentralizada, el aviso entre infectados y personas de riesgo por exposición, así como la agilización del manejo de datos por parte de las autoridades sanitarias competentes.
Para ello, varias personas instalan una aplicación. Cuando una de ellas es diagnosticada con COVID-19 puede enviar información a un servidor con información identificativa. (El radio varía en función de la potencia del Bluetooth y esto puede ser un vector de ataque como se comprobará más adelante). El resto de personas que tienen instalada la aplicación, reciben una notificación indicando que estuvieron cerca de un dispositivo cuyo dueño ha avisado de ser positivo en COVID-19.
En todo este proceso, se toman gran cantidad de medidas para intentar preservar el anonimato y la privacidad de los usuarios, a través de los mecanismos que intentaremos explicar a continuación.
Detalles técnicos de la comunicación (Criptografía).
En primer lugar, con la instalación de una aplicación, se genera una «clave única de trazado» asociada al dispositivo en cuestión. Para la generación de esta clave de 32 bytes, se toman en cuenta componentes del sistema, haciendo hincapié en la impredictibilidad e imposibilidad de replicación para asegurar la privacidad y el anonimato. Además, se almacena de forma segura en el dispositivo, de forma local.
De esa primera clave, se deriva una segunda clave de 16 bytes, que se regenerará cada 24 horas, llamada «clave de trazado diario«. Al conjunto de claves diarias derivadas de la clave de trazado principal, se le denomina «claves de diagnóstico» y jugarán un papel fundamental en la mecánica del modelo, como veremos más adelante.
Mientras el Bluetooth está activado, se aprovecha la comunicación para enviar, en los paquetes asociados al protocolo, un fragmento de información denominado «Identificador de proximidad». Este fragmento es intercambiado entre los dispositivos con Bluetooth activado y es el responsable en primera instancia de la identificación temporal de los dispositivos. Por mor de la privacidad, se trata de una clave de 16 bytes que no puede ser correlacionada con ningún usuario si no se está previamente en posesión de su clave de trazado diario, por lo que se hace francamente difícil realizar ataques por suplantación o ‘replay’. Además, esta clave cambia cada 15 minutos.
Es importante resaltar que, como puede apreciarse, no se incluyen funcionalidades relativas a la localización GPS en ningún momento. Lo único que existe es una transmisión de este fragmento de información en un radio de comunicación cercana vía Bluetooth. Finalmente, los identificadores de proximidad recibidos, son procesados y almacenados exclusivamente de forma local.
Detalles técnicos del envío de información (Cliente – Servidor)
Cuando un individuo comparte voluntariamente su diagnóstico – lo que acarrea algunas dudas como expondremos en la sección dedicada a tal efecto – lo que ocurre es una subida de las claves de diagnóstico (recuérdese, el conjunto de claves diarias que se han ido generando) a un servidor determinado.
Los clientes instalados en otros dispositivos que estén participando en el seguimiento, peticionan al servidor y comprueban si algunas de esas claves existentes sirven para derivar los Identificadores de Proximidad que tienen almacenados localmente.
En caso de que exista un match, el algoritmo de diagnosis, (encargado de valorar si un determinado contacto puede ser calificado ‘de riesgo’, en virtud del tiempo de exposición) pide permisos para continuar el flujo de ejecución en caso de que proceda.
La notificación llega así a los nuevos usuarios y se replica el proceso, es decir, esos nuevos usuarios notificados tienen la posibilidad de «compartir su estado» y suscribir al servidor la información con las claves de diagnóstico generadas.
Algunos apuntes sobre seguridad y privacidad. Ataques plausibles.
En la bibliografía manejada, que adjuntaremos al final del artículo, no hemos encontrado menciones a algunos puntos que consideramos relevantes para el modelado de la amenaza y la valoración de los riesgos asociados tanto al modelo abstracto como a algunos detalles técnicos.
En este sentido, cabe preguntarse acerca de cómo se almacena la información en los servidores. Dado que se propone un modelo semi-descentralizado que permita establecer una arquitectura nodal – modular, lo que resulta en una velocidad y agilidad claramente superiores a otros modelos, existe el riesgo de que la gestión de los servidores que almacenen las claves contra las que los clientes matchean, no sea la mejor posible o carezca de una homologación criptográfica a todos los niveles.
Sí que se menciona que la integridad corre a cargo de firmas SHA-256, pero se delega en las implementaciones particulares la gestión de los distintos servidores. Se entiende no obstante, que serán las autoridades sanitarias competentes las encargadas del control de los datos.
Así mismo, se proponen tiempos prudenciales para albergar dicha información y se aconseja no almacenar metadatos de las comunicaciones, pero, de nuevo, no parece estar implementado de forma intrínseca en el código, sino que se apela a las buenas prácticas de los gestores de los servidores.
Por otro lado, existen algunos escenarios en los que el modelo puede verse vulnerado. Por ejemplo, dado que el algoritmo de diagnosis que determina si procede o no considerar como ‘de riesgo’ el contacto con otros dispositivos, toma no sólo como variable el tiempo de exposición, sino también, por las particularidades de la tecnología Bluetooth, la cercanía de los dispositivos, un atacante podría generar falsos contagios amplificando su señal via hardware de modo que, usuarios que se encontraran a una gran distancia, seguirían siendo igualmente notificados, pese a ser físicamente imposible que se hayan contagiado de ese usuario. Es más, hasta donde hemos visto, la bibliografía no contempla un escenario en el que un atacante comparta su estado de «infectado» sin estarlo, alertando de manera fraudulenta a todos los demás.
¿Cómo comprobar si un usuario que alerta de su contagio está realmente contagiado? Para hacerlo, se requeriría aportar información compulsada oficial (lo que acaba con el modelo descentralizado al tener que acudir a instancias centralizadas oficiales) e identificativa (lo que acaba con el modelo de anonimato y respeto a la privacidad). En la bibliografía se propone un perfilado de usuarios en función de si están infectados o estuvieron expuestos, pero se delega nuevamente en el usuario la transmisión final con el servidor.
Obviamos, por exceder el ámbito temático de este boletín, todas las consideraciones que tienen que ver con el uso de datos sensibles por parte de los gobiernos, pero adjuntamos un escrito del responsable europeo de protección de datos apoyado en la GDPR.
Bibliografía empleada:
https://www.apple.com/covid19/contacttracing/
https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf
https://tracetogether.zendesk.com/hc/en-sg/articles/360043543473-How-does-TraceTogether-work-
Powered by WPeMatico
