Protocolo centralizado de rastreo COVID-19

El protocolo centralizado de rastreo COVID-19 se trata de un sistema de rastreo por proximidad centralizado propuesto por el consorcio PEPP-PT liderada por Hans-Christian Boos cuya finalidad es notificar a las personas que han estado cerca de los portadores de virus COVID-19 en los últimos días. En un enfoque centralizado, en lugar de que los teléfonos o dispositivos recopilen información para saber si el propietario está en riesgo, es el servidor central quien identifica a los usuarios en riesgo y notifica a los teléfonos de esos usuarios por medio de Bluetooth de baja energía (BLE).

La ventaja principal es que ofrece información que los epidemiólogos necesitan para rastrear de forma efectiva la evolución de la pandemia.

Contexto[editar]

Inicialmente contaba con el apoyo de la mayoría de los socios europeos. Sin embargo, varios socios se han retirado después de la publicación de las directrices de EPDB y la confirmación por parte de Apple + Google de que las nuevas API de "Notificación de exposición" para el rastreo de contactos BLE (Bluetooth Low Energy) no admitirán arquitecturas centralizadas. El 26 de abril de 2020 sólo el Gobierno francés sigue apoyando el desarrollo de una aplicación nacional de seguimiento de contactos (STOPCOVID) basada en el protocolo PEPP-PT (ROBERT/INRIA).

Componentes[editar]

El sistema consta de tres componentes principales:

APLICACIÓN: se instala una app en los teléfonos móviles de los usuarios y se recogen y almacenan los seudónimos efímeros transmitidos vía Bluetooth (EBIDs) son recogidos y almacenados. También se emite un EBID propio.
SERVIDOR O BACKEND: se encarga de generar los EBID que emiten los usuarios. El backend también procesa los EBID que han sido observados y cargados por los usuarios infectados en los últimos 21 días y ejecuta una evaluación de riesgo para determinar los contactos que son epidemiológicamente relevantes(expuestos en un grado que hace muy probable una infección).
NOTIFICACIONES: se utiliza un servicio de notificaciones push para activar a las personas de contacto y hacer que su aplicación extraiga el mensaje de notificación del backend.

Funcionamiento[editar]

En dicha aplicación intervienen los servidores de las distintas autoridades sanitarias (nacionales, regionales …) donde se analiza qué contactos han estado en proximidad con un usuario marcado como contagiado ya que tienen acceso a los datos que envían los móviles de los ciudadanos (códigos encriptados que intercambian los dispositivos).

La comunicación el backend y la aplicación está asegurada vía TLS y que el servidor siempre se autentifica a través de un certificado apropiado (autenticación del servidor TLS). Los pasos para su uso son los siguientes:

El usuario instala la aplicación, da su consentimiento para el rastreo de proximidad básico y se registra en el backend siempre de forma anónima. El servidor crea un seudónimo aleatorio, único y persistente, llamado PUID. Los usuarios podrán cambiar ese seudónimo reinstalando la aplicación en cualquier momento.
Durante el funcionamiento normal, la aplicación está en modo de rastreo de proximidad.
En caso de que se confirme el diagnóstico de COVID-19, el usuario puede consentir que se comparta el historial de proximidad de proximidad con el backend e informar a las personas de contacto pertinentes.
La federación de contactos es un proceso inadvertido por el usuario que permite notificar a personas de contacto que no están registradas en el mismo backend.

Con la finalidad de que los atacantes creen cuentas de forma masiva y cumplir con el requisito F-REQ-5 requiere la autenticación del usuario basada en atributos de identidad (por ejemplo, cuentas de correo electrónico o números de teléfono) que no pueden crearse infinitamente.

Sistema de rastreo de proximidad[editar]

Tras el registro, el servidor o backend genera regularmente claves secretas globales BKt, que se aplican a todos los usuarios y son válidas durante un breve periodo de tiempo (por ejemplo, 1 hora), así como identificaciones efímeras de Bluetooth (EBID) para todos los usuarios mediante la encriptación de su PUID (seudónimo aleatorio):

EBIDt(PUID) = AES(BKt, PUID)

A petición de la aplicación, el backend genera suficientes EBID para la aplicación durante un periodo de tiempo en el futuro (por ejemplo, 2 días). La aplicación almacena los EBIDs para asegurarse de que no se quedará sin EBIDs válidos si el teléfono no tiene conexión a Internet durante un tiempo. El EBID se renueva periódicamente para evitar el seguimiento de la ubicación de usuarios y se transmite a través de anuncios BLE utilizando la función de privacidad de Bluetooth Low Energy.

La aplicación busca constantemente otras aplicaciones PEPP-PT y sus emisiones Bluetooth suscribiéndose al ID de servicio Bluetooth de la aplicación PEPP-PT. La aplicación registra todos los EBIDs recibidos por el escaneo junto con la hora actual y los metadatos de la conexión Bluetooth y, opcionalmente, la información del dispositivo y el estado del dispositivo. Los metadatos se utilizan para el algoritmo de puntuación del riesgo e incluyen datos no personales que permiten una interpretación más detallada del historial de proximidad.

Nos referimos a estos datos como datos de contacto/tiempo (CTD). Estos datos inicialmente sólo se conservan y procesan en el dispositivo móvil hasta que se confirma que el usuario está infectado. En caso de infección, el CTD puede utilizarse para estimar la duración de un contacto y la distancia entre los usuarios y, así, determinar un nivel de riesgo. El CTD se borrará del teléfono después del tiempo epidemiológicamente relevante (por ejemplo, 21 días) desde que se produjo el contacto.

Desventajas y problemas[editar]

La desventaja principal es que la forma en la que funciona técnicamente este sistema centralizado podría dar lugar a la identificación de los ciudadanos a nivel individual y a un seguimiento de nuestros movimientos.

Los sistemas centralizados no evitan que un posible atacante pueda saber si estamos infectados o no a través de hackear la base de datos de la autoridad sanitaria. O incluso suprimir contactos en riesgo u ocultar los contactos en riesgo en cualquier sistema de rastreo de proximidad. Evite el descubrimiento de contactos.

La creación de eventos de riesgo falsos es fácil en el diseño centralizado y cualquier paciente infectado con conocimientos de tecnología puede hacerlo retroactivamente. No requiere transmisión. Basta con añadir el objetivo la pseudo-identidades efímeras a la lista de eventos observados antes de cargarlo en el backend.

Diferencias con el modelo descentralizado[editar]

Diferencias entre los modelos (traducido)^[3]

NTK: propuesta alemana[editar]

Funcionamiento[editar]

Cuando se instala una aplicación que traza los contactos en un teléfono móvil, un servidor le atribuye al dispositivo una clave de identificación "persistente" que se crea y asocia con el terminal. Esa clave, mediante procesos de cifrado, genera varias claves de menor entidad que son las que se retransmiten por Bluetooth. El cifrado de esas claves varía mensualmente.

Una vez se detecta un positivo por COVID-19, todas las comunicaciones recibidas las últimas 3 semanas por Bluetooth se suben, incluyendo metadatos e información de los dispositivos que intervinieron en la retransmisión. El servidor entonces desencripta las claves del positivo y sus comunicaciones, e identifica de este modo a los usuarios que se expusieron a un contagiado.

Sin embargo desde que el PEPP-PT presentó su solución NTK, el goteo de abandonos ha sido constante.

Amenazas[editar]

Los desarrolladores de DP-3T, modelo descentralizado, han compartido un análisis con las principales ciberamenazas que han detectado en este protocolo.

Los hackers podrían introducir códigos de quienes no estuvieron expuestos a un infectado, generando falsos positivos.
El dispositivo no estuviese nunca bloqueado o deben permitir el uso de bluetooth con el dispositivo bloqueado, por lo que en caso de hurto el dispositivo podría ser manejado fácilmente.
La persona que reciba la alarma por haberse cruzado con un positivo por COVID-19 es capaz de deanonimizar los datos de los códigos encriptados recibidos.

ROBERT: propuesta francesa[editar]

ROBERT es el resultado de un trabajo colaborativo entre Inria (esfuerzo colaborativo liderado por el equipo de PRIVATICS) y Fraunhofer AISEC.^[4]

Incluye algunos campos nuevos respecto a la propuesta anterior (tiempo y MAC) el servidor almacena la marca de tiempo de la última solicitud de un usuario y solo responde a una nueva solicitud si ha transcurrido un umbral de tiempo mínimo entre dos solicitudes. Esto previene contra ataques de identidad y protege contra ataques de repetición. Este tipo de ataques se suele utilizar con el objetivo de suplantar la identidad.

Referencias[editar]

Bibliografía[editar]

2020. Decentralized Privacy-Preserving Proximity Tracing. [ebook] Disponible en: <https://www.denken.io/wp-content/uploads/2020/04/DP3T_White_Paper.pdf>.
2020. Análisis de la actualidad internacional. [ebook] Cristina Marzal. Disponible en: <https://www.thiber.org/wp-content/uploads/2020/05/Numero_19_Mayo_Analisis_Actualidad_Intern.pdf>.
2020. PEPP-PT-high-level-overview.pdf. [ebook] Disponible en: <https://github.com/pepp-pt/pepp-pt-documentation/blob/master/PEPP-PT-high-level-overview.pdf>.
2020. Security and privacy analysis of the document PEPP-PT. [ebook] Disponible en: <https://github.com/DP-3T/documents/blob/master/Security%20analysis/PEPP-PT_%20Data%20Protection%20Architechture%20-%20Security%20and%20privacy%20analysis.pdf>.
2020. DP3T White Paper. [ebook] Disponible en: <https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf>.

Enlaces externos[editar]

Datos: Q106901476

[1] «Esquema protocolo centralizado».

[2] «Rastreo de proximidad».

[3] «Diferencias entre los modelos».

[4] «Código Robert».

[1]

[2]

[3]

[4]