Si alguien nos dijera a comienzos del 2020 que íbamos a vivir todo lo que hemos vivido este año, con todas las desgracias que ello ha acarreado y el radical cambio en nuestras vidas a nivel mundial, probablemente no lo hubiéramos creído.
COVID-19 o Coronavirus disease 2019 es una enfermedad infecciosa de la que tuvimos la primera noticia en diciembre del año 2019 a raíz de un brote epidémico de neumonía que afectaba a más de 60 personas en Wuhan, China. En los últimos días del año. El 30 de diciembre el Centro de Control de Enfermedades Chino se desplazó para tomar muestras y se informó a la OMS (Organización Mundial de la Salud) al día siguiente. El 7 de enero, se confirmó que el virus no era ninguno conocido y que era una variante del SARS (síndrome respiratorio agudo grave) cuyo genoma se envió a la OMS el 12 de enero.
Como podéis ver, el origen, la propagación y la situación mundial se han generado en muy poco tiempo. Y otras epidemias de años anteriores como la gripe aviar, hicieron que las autoridades no se tomarán el tema todo lo serio que era necesario hasta que, a las pruebas nos remitimos, todo ha sido demasiado tarde.
Actualmente existe vacuna de la enfermedad en periodo de prueba, pero no tenemos un tratamiento claro, y hemos ido conociendo al virus poco a poco. Lo que sí sabemos es que una de las formas más claras de prevenir su propagación y contagio, es intentar buscar lo que se conoce como inmunidad colectiva, a través de seguir y aislar a los posibles casos sospechosos o contagiados.
Un dato clave del virus es que podemos estar infectados y transmitir el mismo, entre 48 y 72 horas antes de tener anticuerpos del mismo (antes que una prueba de COVID-19 de positivo). Por lo que podemos dar negativo, pero estar transmitiendo el virus. Esto hace que el aislamiento de posibles casos sospechosos sea clave, porque si has estado en contacto con alguien que ha dado positivo, hay probabilidad que tú ya estés transmitiendo si te has contagiado y que des positivo más adelante.
Para cubrir esta necesidad, las grandes tecnológicas, dueñas de los sistemas operativos de mayor uso del mundo, Google y Apple, se pusieron de acuerdo en un proyecto conjunto para crear una herramienta que proporcione a los distintos países y autoridades sanitarias del mundo, una solución tecnológica que permita hacer ese seguimiento de las personas. Ese trazado de contactos que nos permita saber en todo momento, con quién hemos estado, cuánto tiempo, si tenemos riesgo de contagio en caso que alguien con quien hayamos estado de positivo en la enfermedad, y podamos tener acceso a la información necesaria sobre la enfermedad y cómo actuar para evitar que seamos foco de propagación en caso de poder serlo.
En este artículo vamos a analizar y ver paso a paso cómo funcionan la librería de Apple y Google Exposure Notification, y el kit de desarrollo de DP-3T en que se ha basado la app Radar COVID de España. También cómo funciona la app en sí, pero no hemos podido auditar su código fuente pues este no está aún publicado (aunque hay un compromiso en hacerlo en breve).
Privacidad ante todo: ni un dato personal ni localización
¿Cómo se consigue hacer un seguimiento de los contactos sin usar datos personales? Esa es la gran duda que un equipo de profesionales de distintas ramas, comandados por la profesora Carmela Troncoso, profesora de la Escuela Politécnica Federal de Lausana en Suiza, ingeniera de telecomunicaciones e investigadora española especialista en privacidad, se hicieron. Y fue la semilla del proyecto DP-3T (rastreo de proximidad descentralizado para preservar la privacidad).
Un proyecto con unos pilares básicos: no almacenar información alguna personal en ningún de servidor que pueda sufrir cualquier fuga, brecha o intento de aprovechar esa información (de ahí el término "descentralizado"). Toda la información para este proceso se guardaría en el dispositivo y solo se acudiría a un sistema centralizado para datos que no pudieran comprometer la privacidad en forma alguna.
La solución que encontraron fue usar el protocolo Bluetooth, pero pronto se encontraron con el difícil problema que los iPhone NO permiten procesos en segundo plano en Bluetooth por su sistema operativo. Pudieron llegar a una solución para Android pero no para iOS. Hasta que Apple y Google decidieron anunciar su proyecto, que está inspirado en el trabajo desarrollado en el proyecto europeo. Pero esta vez, al venir de Apple, se incorpora una API (una librería pública del sistema) que sí crea un proceso en segundo plano en Bluetooth que transmite la información necesaria.
Al final, DP-3T (que es el proyecto que se ha usado como base para la app Radar COVID, con el asesoramiento de la propia profesora Troncoso al Gobierno de España) acabó integrando la solución de Apple y Google para mejorar su eficiencia y depender directamente de librerías hechas por los creadores de los sistemas, que siempre serán más eficientes.
DP-3T ofrece una forma más fácil y unificada entre sistemas de tratar con las bases de datos que explicaremos a continuación, con los datos de seguimiento, así como plantillas de pantallas y flujo de interfaces de usuario. Digamos, que DP-3T ha conseguido montar una "plantilla" de app unificada que facilita el desarrollo tanto en Android como iOS de una forma muy similar en cuanto a estructuras, flujo y funcionamiento. Ha proporcionado la capa de abstracción de usuario, interfaz y gestión de datos sobre Exposure Notification, y con ello, facilitar la tarea a los países que hagan la app pues ya tienen todo el flujo hecho y solo tienen que poner sus propios contenidos en los placeholders correspondientes y conectar a sus propios servidores de claves, como veremos ahora.
Cómo se hace el seguimiento de forma anónima
La API de Apple y Google hace lo siguiente: cada 24 horas, genera un número aleatorio criptográficamente seguro. Un número aleatorio que no depende de ningún tipo de elemento del dispositivo (como el reloj o los componentes) y por lo tanto es "imposible" de predecir en base a ningún tipo de dato concreto. Bajo estas líneas, el código que lo genera llamando a CCRandomGenerateBytes, que devuelve la clave. Esta función es llamada cada 24 horas.
Si nosotros pedimos un número aleatorio a nuestro dispositivo, este los obtienen normalmente del reloj. Y según el momento en que pedimos el dato, podríamos predecir qué número se dará en el futuro si encontramos el patrón que sigue el sistema. Pero un número criptográficamente seguro no sigue patrón alguno en su cálculo, y además está cifrado en su entrega por lo que nunca sabemos cuál es realmente el número en sí. Es una mezcla de dos conceptos para obtener una aleatoriedad no predictiva 100% real.
Ese número se almacena en nuestro teléfono durante 14 días, y cada 24 horas se crea uno nuevo. A los 14 días, se van borrando. ¿Por qué? Porque está demostrado que en ningún caso un contacto de más de 14 días puede provocar una infección. Así que el histórico se limita a ese número de días, por llamarlo de alguna forma, seguro. Este número aleatorio criptográficamente seguro se llama Clave Temporal de Exposición.
Nuestro teléfono tiene un chip Bluetooth, que tiene una dirección de red que lo identifica. Su MAC. Pero por razones de privacidad, desde la versión 4.2, los chips Bluetooth tienen la capacidad de camuflar ese número de red y generar otros para evitar que pueda saberse de quién proceden distintas señales transmitidas en el tiempo. Esta función permite que en intervalos de 10 a 20 minutos, la dirección de red de Bluetooth cambie cuando se realiza una transmisión "anónima". Si accedemos a emparejar nuestro teléfono con un dispositivo Bluetooth (algo que hacemos de forma voluntaria) sí se comunica la MAC real, pero si no se ha emparejado, esta cambia por seguridad y privacidad.
Pues bien, cada vez que el teléfono cambia esa dirección Bluetooth (unos 15 minutos), se genera un número aleatorio o Rolling Proximity Identifier (identificador de proximidad rotativo) a partir de la Clave Temporal de Exposición. Este código, se transmite por Bluetooth (cifrado), en un paquete de apenas 16 bytes, donde también se incluye el dato de intensidad de la señal Bluetooth con el propósito de determinar la distancia.
Generación del RPIK o Rolling Proximity Identifier Key, a partir de la Temporary Exposure Key (TEK)
Siguiendo una forma muy parecida a los beacons (fuentes de transmisión de datos Bluetooth que se usan para triangular posiciones en espacios cerrados y detectar dispositivos cerca de estos), nuestro móvil emitirá ese identificador de proximidad rotativo de forma continua, cada pocos segundos, con el objeto de ser escuchado por otros móviles a su alrededor. Y como decimos, a los 15 minutos cambia tanto el identificador de la tarjeta de red Bluetooth, como el número aleatorio que se generó (el identificador de proximidad rotativo) a partir de la Clave Temporal de Exposición.
Adicionalmente, cuando se crea una nueva clave temporal, se pone a 0 un contador que luego almacena los segundos que han pasado desde que se generó y lo guarda para cada nuevo identificador de proximidad. Ese tiempo es una de las claves de generación del identificador y será necesario más adelante para regenerar el dato sin necesidad de transmitirlo.
En el código sobre estas líneas, tenemos la función clave: genera la clave llamando a ENGenerateRPIK con el dato de la clave temporal, para luego cifrarla con ccecb_one_shot y devolverla en el buffer de memoria de salida outBuffer que entra en el penúltimo parámetro de la función.
¿Cuándo se da un contacto por realizado? Cuando otro móvil escucha la misma señal que yo transmito durante más de 10 minutos con una intensidad de señal que indique que estamos a una distancia de riesgo. En el momento que esto sucede, el otro móvil almacena nuestro identificador de proximidad transmitido. Nada más. Identificador que a los 14 días, será borrado del sistema.
Ese es todo el proceso de seguimiento: no hay nada más. No existen datos privados, identificadores de red, algún dato más como puede ser el sistema operativo del móvil... nada de nada. Solo un número aleatorio y un valor de intensidad de la señal Bluetooth en un pequeño paquete de 16 bytes. Emitido cada pocos segundos, que apenas consume batería. Un valor, que sigue siendo transmitido aunque nuestro móvil se quede sin batería usando la energía residual de la misma.
Esto ha sido certificado por expertos en seguridad y privacidad, que realmente lo que se transmite es eso y nada más. Y todo queda almacenado en nuestro dispositivo o en el aquel que ha detectado nuestro contacto por más de 10 minutos. Nada más. Y en mi caso, todo esto que os he contado podéis comprobarlo auditando el código como yo he hecho y leyendo toda la documentación. No hay trampa ni cartón.
¿Y si hay un positivo, qué sucede en Radar COVID?
Si en algún momento damos positivo en una prueba de COVID-19, nosotros decidimos si queremos o no reportarlo. Al igual que nosotros también tenemos la facultad de decidir si queremos o no usar la API de seguimiento. Si instalamos Radar COVID, la app nada más arrancar comprueba que hayamos dado permiso para nuestro seguimiento. Para ello usa la clase ENManager que permite preguntar por el estado de la autorización de esta función o posibles peticiones y es el centro de comunicación entre el sistema y nuestra app.
La SDK del proyecto DP-3T, extiende en su propia funcionalidad esta clase, para proporcionar funciones más simples que recuperan estas claves, de forma que así no hay que llamar a APIs en Objective-C o C más complejas.
Si dimos permiso, sigue adelante y pregunta a las bases de datos que tiene el sistema, las cuales están ocultas para la propia app. Esto es importante de entender: ninguna app puede acceder a los datos de los identificadores de proximidad. Sí pueden acceder a las claves temporales de exposición (aunque cifradas), pero solo en caso de reportar un positivo como veremos ahora. Así que ninguna app de Gobierno o autoridad sanitaria puede saber qué se ha estado transmitiendo por Bluetooth para intentar usar el dato en alguna forma: es un dato privado del sistema e inaccesible.
Cuando hemos dado positivo y queremos reportarlo, el sistema solicita (en el caso de España) un código de validación de la prueba de laboratorio del COVID-19. Una forma de evitar falsos negativos. Este servicio es una API REST (un servidor en la red) cuyo único dato que recibe es un código de 12 cifras que verifica que tienes una prueba positiva. Nada más. Insisto, con el fin de evitar falsos positivos.
Funcionamiento de Radar COVID (montaje de Levante-EMV-com)
Una vez se ha verificado que el positivo es correcto, se comunica con un servidor de claves que cada país tiene que crear siguiendo unas especificaciones concretas (para ser capaz de comunicarse con la app). Ese servidor da servicio a cada zona geográfica donde haya una app, teniendo en cuenta que (salvo Estados Unidos), Apple y Google solo permiten una app por país. En Estados Unidos se permite una por Estado.
¿Qué se envía al servidor de claves? El total de mis claves temporales de exposición, de los últimos 14 días, junto al tiempo transcurrido desde su generación para crear cada uno de los identificadores de proximidad. Pero no estos que como hemos dicho, jamás quedan expuestos, ni siquiera a la app. Nunca sale de nuestro dispositivo aquel dato que se emitió para identificarnos a otros móviles ni podemos acceder a él. Y las claves temporales van cifradas: solo el sistema puede descifrarlas.
Luego, cada X tiempo, todos los móviles configurados sobre un mismo servidor de claves, se descargan el conjunto de claves temporales de exposición y base de tiempos de generación de identificadores de proximidad. Una vez en tu móvil (se descarga en segundo plano) se calculan los identificadores de proximidad que se generaron a partir de la clave temporal de exposición y los intervalos. Este proceso es interno de la API y opaco a la app. La app Radar COVID, ni ninguna otra, sabe la fórmula con que se obtienen los identificadores de proximidad a partir de la clave temporal y los tiempos. Simplemente, este conjunto de datos se envían a la API del dispositivo e internamente se regeneran los identificadores de proximidad y se comparan con la base de datos oculta del dispositivo para que nos diga si alguno de los identificadores de proximidad que tenemos almacenados coincide con los que acabamos de crear de personas infectadas.
¿Hay coincidencia? Pues quiere decir que hemos estado expuestos a alguien infectado. Pero ojo, el sistema aún no da el positivo. Dependerá de la app y cada autoridad decidir si el factor de riesgo es suficiente para avisar o no al usuario. Si el positivo es de una persona con quien tuvimos contacto hace 12 días (por ejemplo), lo normal es que no se nos diga nada si la autoridad lo considera prudente. Este criterio lo decide cada país. Pero si está cerca en el tiempo, se reportará un positivo en el sistema. Un positivo cuya información es: "ha estado usted cerca de un contagiado". Nada más. Nunca sabremos quién o cuándo.
Cómo funciona esto en la app de seguimiento de contactos
La app internamente usa varias estructuras de datos para comunicarse con el servidor de cada país y configurar su funcionamiento. El mínimo de riesgo actual, los umbrales de duración de la atenuación para un contacto, los valores de la atenuación, días desde la última exposición, valores de riesgo de transmisión y una de serie de valores que configuran la app para la situación concreta de cada país en cada momento.
Las autoridades de cada país deben crear un certificado de firma que valide su servidor de claves y pasarle este a Apple y Google para que la incluya entre los servicios autorizados y no permita conectar con otros servidores distintos.
El sistema guarda una estructura de datos de claves de diagnóstico, donde se almacena la clave en sí, cuánto tiempo fue válida esa clave, el número de intervalo de tiempo en que fue creada y el nivel de riesgo de transmisión. Estos valores son propios de la librería de notificación de exposición, y permiten al sistema recrear desde un informe de positivos los valores que luego se pasan al manager para que este nos diga si hay o no coincidencias con los datos que este almacena y que son opacos a nosotros.
Lo importante a entender es que las apps no gestionan en modo alguno el ciclo de vida de la generación de identificadores de proximidad ni las claves temporales de exposición. Las apps son solo una pasarela para recuperar la información que necesitamos para reportar el positivo. Por este motivo, le pedimos al manager de la app desde un método llamado getDiagnosisKeys, el conjunto de claves temporales (las generadas cada 24 horas). En ellas medimos el valor de riesgo de transmisión en función de los umbrales de tiempo que cada zona determine, y enviamos las claves que cumplen con ese criterio junto a los datos de tiempo.
Pero no gestionamos en forma alguna ningún identificador de proximidad ni accedemos a ellos. Y las claves van cifradas. Ni se conoce cómo se generan los identificadores a partir de las claves temporales. Solo gestionamos el positivo y, sobre todo, la información que se proporciona en caso de ser positivo.
También, y es importante matizarlo, en ningún caso se usa el GPS para localizarnos porque, de hecho, si pidiéramos permiso para este, Apple rechazaría la app al subirla al App Store (y Google también en Play Store). Y el código (verificado) no usa el GPS ni recibe o transmite en forma alguna cuando se usa la API.
Análisis de la notificación de exposiciones express de iOS 13.7
Con la salida de iOS 13.7, Apple y Google han dado un paso más para facilitar el uso de este sistema de seguimiento y tranquilizar a aquellos que piensan que las apps de los Gobiernos pueden servir para algún tipo de control (hecho descartado por completo con ver el código fuente y cómo funciona). Pero si aún así no queremos bajar la app Radar COVID o aquella que se use en nuestro país, podemos usar la configuración express que no necesita app.
Los Gobiernos o autoridades sanitarias autorizados y que tengan una app, pueden crear un servidor que se comunique directamente con el sistema operativo, de forma que ya no es necesario que la persona se baje la app. Es cierto, que para proporcionar el fichero de configuración, debe existir una app para esa región. Pero el bajarla o no es decisión del ciudadano. Si no quiere bajarla pero usar la notificación de exposiciones, se puede si el país o autoridad de salud crea el siguiente flujo:
Adicionalmente al servidor de claves que ya usa la app, el país debe crear un servidor de validación de los test (pruebas) del COVID-19, siguiendo las directrices de Apple. Junto al servidor de claves que ya usa la app, este nuevo servidor servirá para centralizar todos los casos positivos de pruebas y para validar a las personas que reporten un informe.
Cuando una autoridad tiene una prueba positiva, lo subirá a este servidor y este le devolverá un código de verificación de la misma que será comunicado vía telemática al interesado. Una vez recibido, si el interesado quiere reportar el positivo, deberá poner el código o pulsar en la URL que lo valida. Esta URL pedirá algún dato adicional de la prueba para validarla y luego creará un JWT anónimo (o JSON Web Token) que use la prueba para validar la autenticidad del positivo y una sesión que sirva para entrar al servidor de claves sin necesidad de usar la app.
Una vez validado el acceso, el sistema sube el conjunto de claves temporales junto a los tiempos de generación para informar del positivo y listo. Nada más. En el lado de las personas que no reporten positivos, el sistema se encargará cada X tiempo de bajar todas las claves positivas del servidor de claves e informamos si ha habido alguna coincidencia, siempre siguiendo los criterios de riesgo de cada país.
En el caso de Apple todo el flujo lo lleva el sistema operativo sin necesidad de app, pero en el de Android, Google Play generará una app automática con la configuración de cada región y la instalará él solo en el dispositivo.
Fuentes de la información
Toda esta información, analizada, se ha recopilado de la información pública que Apple pone a disposición de los desarrolladores e investigadores de seguridad y privacidad. Podemos ver parte del código de esta librería, en Objective-C, y comprobar cómo a partir de clases como ExposureNotificationManager, se gestiona toda la conexión Bluetooth y se envía la información para luego grabarla localmente, y cifrada, en una base de datos local.
La API usa un cifrado AES de modo contador en 128 bits, (AES-128 block cipher in Counter Mode) usando la librería de Apple CoreCrypto (escrita en C) y ningún dato se guarda en la base de datos tal cual. Las claves para ese cifrado se almacenan en la cartera de certificados.
Espero que os haya gustado este análisis y ahora os quede más claro la calidad de este desarrollo y cómo puede ayudarnos a contener la propagación de esta o cualquier otra enfermedad que pudiera aparecer en el futuro de alta propagación. Aquí podemos ver toda la información:
- Documentación de la librería Exposure Notificación: Documentación de Apple
- Configurando un servidor de claves: Documentación de Apple.
- Especificación de Bluetooth: PDF en Apple.
- Especificación de criptografía: PDF en Apple.
- Código fuente de la API: Descarga en Apple previa aceptación de condiciones
- Notificación de Exposiciones Express (sin app): Documentación en Apple.
- DP-3T, SDK para iOS: Código fuente en GitHub.
- DP-3T, app de ejemplo: Código fuente en GitHub.
Ver 33 comentarios