Rastreo de proximidad descentralizado para preservar la privacidad

Rastreo de proximidad descentralizado para preservar la privacidad (DP-3T, estilizado como $DP^{3}T$ ) es un protocolo de código abierto​ desarrollado en respuesta a la pandemia de coronavirus 2019-2020 para facilitar el rastreo de contactos digitales de los participantes infectados.​ El protocolo, como el protocolo de competencia Pan-European Privacy-Preserve Proximity Tracing (PEPP-PT), utiliza Bluetooth Low Energy para rastrear y registrar encuentros con otros usuarios.​​​ Los protocolos difieren en su mecanismo de informes, ya que PEPP-PT requiere que los clientes carguen registros de contactos a un servidor central, mientras que con DP-3T, el servidor central nunca tiene acceso a los registros de contactos ni es responsable de procesar e informar a los clientes del contacto. Debido a que los registros de contactos nunca se transmiten a terceros, tiene importantes beneficios de privacidad sobre el enfoque PEPP-PT,​​​​​ sin embargo, esto tiene la desventaja de requerir más potencia informática en el lado del cliente para procesar informes de infección.​

El 21 de abril de 2020, la Oficina Federal Suiza de Salud Pública anunció que la aplicación de rastreo de contactos de coronavirus nacional suizo se basará en DP-3T.​

Existe un proyecto, Exposure Notification, de Apple y Google basado en principios similares a los del protocolo DP-3T, utilizando la tecnología Bluetooth para determinar la distancia entre dos dispositivos.​​ Por otro lado, Huawei añadió una implementación similar al protocolo DP-3T a sus APIs de servicios móviles llamada “Contact Shield” en junio de 2020, utilizando también la tecnología Bluetooth con el mismo objetivo e intercambiando información con los dispositivos detectados, recogiendo la información anónimamente de los usuarios detectados.​

El SDK de DP-3T y sus aplicaciones de calibración pretenden ser compatibles con la API de Apple/Google tan pronto como se lance para los dispositivos iOS y Android.​​

Numerosos países como Estonia, La Cruz Roja Austriaca, y Finlandia (con su versión denominada “Ketju”) ya empezaron a utilizar el rastreo de proximidad a finales de abril.​​ Uniéndose posteriormente Alemania al construir una aplicación basada en el DP-3T por SAP SE y Deutsche Telekom junto con CISPA nos encontramos con que el 30 de septiembre de 2020 ya existen aplicaciones de rastreo de proximidad usando el protocolo DP-3T en Austria, Bélgica, Croacia, Alemania, Irlanda, Italia, los Países Bajos, Portugal y Suiza.​​ En cuanto a España, el gobierno decidió también unirse a esta propuesta utilizando el sistema creado por Apple/Google.​

Visión general

El protocolo DP-3T funciona a partir de ID efímeras (EphID), cadenas rotativas semialeatorias que identifican de forma exclusiva a los clientes.​ Cuando dos clientes se encuentran, intercambian EphID y los almacenan localmente en un registro de contactos.​ Luego, una vez que un usuario da positivo por infección, se envía un informe a un servidor central. Cada cliente en la red recopila los informes del servidor y busca independientemente en sus registros de contactos locales si hay un EphID contenido en el informe. Si se encuentra un EphID coincidente, el usuario ha entrado en contacto cercano con un paciente infectado y el cliente le advierte. Dado que cada dispositivo verifica localmente los registros de contactos y, por lo tanto, los registros de contactos nunca se transmiten a terceros, el servidor central de informes no puede determinar por sí mismo la identidad o el registro de contactos de ningún cliente en la red. Esto contrasta con los protocolos de la competencia como PEPP-PT, donde el servidor central de informes recibe y procesa los registros de contacto del cliente.​

Identificación efímera

Al igual que el Protocolo TCN y sus Números de contacto temporales, el protocolo DP-3T utiliza ID efímeras de 16 bytes (EphID) para identificar dispositivos de forma exclusiva en la proximidad de un cliente. Estos EphID se registran localmente en el dispositivo de un cliente receptor y nunca se transmiten a terceros.

Para generar un EphID, primero un cliente genera una clave secreta que rota diariamente ( $SK_{t}$ ) computando $SK_{t}=H(SK_{t-1})$, dónde $H()$ es función criptográfica como SHA-256 . $SK_{0}$ se calcula mediante un algoritmo estándar de clave secreta como Ed25519 . El cliente usará $SK_{t}$ durante el día $t$ para generar una lista de EphIDs. Al comienzo del día, un cliente genera una lista local de tamaño $n=(24*60)/l$ nuevos EphID para transmitir durante todo el día, donde $l$ es la vida útil de un EphID en minutos. Para evitar que terceros malintencionados establezcan patrones de movimiento rastreando identificadores estáticos en un área grande, los EphID se rotan con frecuencia. Dada la clave secreta del día $SK_{t}$, cada dispositivo calcula $EphID_{n}(BK)=PRG(PRF(SK_{t},BK))$, dónde $BK$ es una cadena de caracteres fija global, $PRF()$ es una función pseudoaleatoria como HMAC-SHA256, y $PRG()$ es un cifrador secuencial que produce $n*16$ bytes Esta secuencia se divide en fragmentos de 16 bytes y se ordena aleatoriamente para obtener los EphID del día.

Los EphID antiguos serán borrados, permaneciendo en los teléfonos el tiempo que las autoridades sanitarias consideren pertinente, estando establecido por defecto en 14 días siendo este valor configurable.​

Especificaciones técnicas

El protocolo DP-3T se ha realizado para dos responsabilidades diferentes: rastrear los encuentros cercanos con otros usuarios (“device handshake” o en español “saludo de dispositivo”) y reportar estos encuentros para que otros clientes puedan determinar si han estado en contacto con un paciente infectado (reporte de infecciones).

Como la mayoría de los protocolos de contacto digital, el device handshake utiliza Bluetooth Low Energy para encontrar e intercambiar detalles con clientes locales, y el reporte de infecciones usa HTTPS para cargar el reporte en un servidor central de reportes. Adicionalmente, como otros , el servidor central de reportes nunca permite el acceso a los registros de contacto de cada cliente, sino que está estructurado de manera que los clientes pueden individualmente recuperar su propia información de los registros.​

El utilizar un protocolo descentralizado va a suponer que cuando un usuario resulte diagnosticado positivo, y si éste lo consiente, se guarde esa información en el servidor y la aplicación de cada usuario pueda detectar sin ningún tipo de intervención intermediaria si se ha realizado un contacto con el mismo lo suficientemente arriesgado como para suponer un contagio de este otro usuario.​

Device handshake

Con el objetivo de encontrar y comunicarse con los clientes en la proximidad de los dispositivos, el protocolo hace uso de los modos servidor y cliente de Bluetooth LE, cambiando entre ambos con frecuencia.  En el modo servidor, el dispositivo anuncia su EphID para que lo lean los clientes, y los clientes buscan los servidores.​ Cuando un cliente y un servidor se encuentran, el cliente lee el EphID y posteriormente escribe su propio EphID en el servidor. A continuación, los dos dispositivos almacenan el encuentro en sus respectivos registros de contacto, además de una marca de tiempo aproximada y la intensidad de la señal. La intensidad de la señal se utiliza posteriormente como parte del proceso de notificación de la infección para estimar la distancia entre un paciente infectado y el usuario.​

Reporte de infecciones

Cuando se reporta una infección, existe un servidor central de reportes controlado por la autoridad sanitaria local. Antes de que un usuario pueda enviar un informe, la autoridad sanitaria debe primero confirmar la infección y generar un código que autorice al cliente a guardar el informe. Además, la autoridad sanitaria instruirá al paciente en qué día debería empezar el reporte (indicado como $t$ ). El cliente posteriormente sube el par $SK_{t}$ y $t$ al servidor central de reportes, que otros clientes de la red descargan en una fecha posterior. Debido a usar el mismo algoritmo que el que genera las originales EphIDs, los clientes pueden reproducir todas las EphID usadas en el periodo pasado e incluyendo $t$, que luego cotejan con su registro de contactos local para determinar si el usuario ha estado cerca de un paciente infectado.​

En todo el protocolo, la autoridad sanitaria nunca tiene acceso a los registros de contactos, y sólo sirven para comprobar los pacientes y autorizar el envío de informes.​

Análisis epidemiológico

Cuando un usuario instala la aplicación DP-3T, son preguntados si desean optar a compartir sus datos con los epidemiólogos. Si el usuario da su consentimiento, cuando se confirma que ha estado en contacto cercano con un paciente infectado, se programa el envío de la respectiva entrada del registro de contactos que contiene el encuentro a un servidor central de estadísticas. Para evitar que terceros malintencionados descubran posibles infecciones al detectar estas cargas, los informes se envían a intervalos regulares, con informes ficticios indistintos enviados cuando no hay datos que transmitir.​

Cooperación de las autoridades sanitarias

Para facilitar la compatibilidad entre las aplicaciones DP-3T administradas por distintas autoridades sanitarias, las aplicaciones mantienen una lista local de las regiones que un usuario ha visitado. Las regiones son consideradas como áreas largas que corresponden directamente a la jurisdicción de una autoridad sanitaria; la localización exacta no será almacenada. La aplicación conectará posteriormente estas regiones a sus correspondientes servidores centrales de reportes extranjeros y obtendrá información de estos servidores además del propio servidor habitual. Las aplicaciones, además, enviarán informes a estos otros servidores extranjeros si el usuario ha dado positivo en las pruebas de infección.​

Ataques al DP-3T y críticas

El experto en criptografía y seguridad Serge Vaudenay, al analizar la seguridad de DP-3T,​ argumentó que:

algunas medidas de protección de la privacidad por parte de DP3T pueden tener el efecto contrario al que pretendían. En concreto, se puede desanonimizar a los enfermos y a los denunciados, se pueden revelar encuentros privados y se puede coaccionar a las personas para que revelen los datos privados que recogen.

- Serge Vaudenay, ​^{:p. 1}

El trabajo de Vaudenay presenta varios ataques contra DP-3T y sistemas similares, generando esta afirmación una respuesta del grupo DP-3T afirmando que de los doce riesgos que presenta, ocho también están presentes en los sistemas centralizados (algunos de ellos heredados a que el mero uso de la tecnología Bluetooth en sí misma ya presenta problemas de privacidad o que haya diversos ataques o informes falsos), tres no funcionan y uno, que implica el acceso físico al teléfono, funciona pero puede mitigarse por ejemplo utilizando un sistema centralizado en el que un servidor mantenga la información de individuos infectados y no infectados, haciendo innecesario el acceso a sus teléfonos.​

En un trabajo posterior​ Vaudenay revisa los ataques contra los sistemas de rastreo centralizados y descentralizados y refiriéndose a los ataques de identificación de personas diagnosticadas concluye que:

Al comparar las arquitecturas centralizadas y descentralizadas, observamos que los ataques contra los sistemas descentralizados son indetectables, pueden realizarse a gran escala, y que las contramedidas propuestas son, en el mejor de los casos, capaces de mitigar los ataques en un número limitado de escenarios. Por el contrario, los sistemas centralizados ofrecen muchas contramedidas, mediante la contabilidad y la auditoría.

- Serge Vaudenay,​:p. 6

En el mismo trabajo​ Vaudenay defiende que, dado que ni los enfoques centralizados ni los descentralizados ofrecen un nivel suficiente de protección de la privacidad, deberían explorarse diferentes soluciones, sugiriendo en particular los sistemas ConTra Corona,​ Epione​ y Pronto-C2​ como una "tercera vía".

Tang​ estudia los principales sistemas de rastreo digital de contactos y muestra que el DP-3T está sujeto a lo que él llama "ataques de identificación dirigidos".

Se han simulado ataques teóricos a DP-3T​ que muestran que el seguimiento persistente de los usuarios de la primera versión del sistema DP-3T que han cargado voluntariamente sus identificadores puede ser fácil para cualquier tercero que pueda instalar una gran flota de dispositivos Bluetooth de baja energía. Este ataque aprovecha la vinculabilidad de un usuario durante un día, y por tanto es posible en un día sobre todos los usuarios de algunos sistemas centralizados como el sistema propuesto en el Reino Unido,​ pero no funciona en las versiones "no vinculables" del DP-3T en las que los identificadores de los usuarios infectados no se transmiten utilizando una representación compacta como una clave o una semilla.​

Sin embargo, los desarrolladores de DP-3T, conscientes de la acumulación de datos sensibles en bases centralizadas, teorizan los posibles ataques en el sistema:

-Un adversario experto en tecnología podría volver a identificar los identificadores de las personas infectadas a las que ha

i)             modificando activamente la aplicación para registrar datos de identificación más específicos y datos de identificación más específicos y

ii)            recogiendo información adicional sobre las identidades a través de medios adicionales, como una cámara de vigilancia para grabar e identificar a los individuos. Esto sería generalmente ilegal, estaría limitado espacialmente y supondría un gran esfuerzo.

-Un adversario experto en tecnología que despliegue una antena para espiar las conexiones Bluetooth puede saber qué conexiones corresponden a personas infectadas, y luego puede estimar el porcentaje de personas infectadas en un pequeño radio de 50 m.

- Prof. Carmela Troncoso​

En el proyecto, se identifican tres posibles propuestas para los procedimientos de autorización: utilizando códigos de autenticación simples(llamada telefónica, correo, SMS...), códigos de autenticación activados (transcripciones o códigos QR) y códigos de autorización vinculados a los datos (durante la prueba del procedimiento, también con transcripciones y códigos QR). Todas estas opciones impiden los ataques por fuerza bruta y de denegación del servicio, garantizando también que no se producirán ataques contra la privacidad de los individuos.​

Por último, también se incluye una advertencia indicando que es necesario que las aplicaciones ignoren cualquier EphiD coincidente que haya recibido después de validBeforeTime o antes de validAfterTime (variables de la implementación), para evitar ataques de repetición utilizando EphIDs que han sido calculados a partir de información de rastreo publicada, entre otras recomendaciones para el uso del protocolo.​

Privacidad

Se han propuesto ideas como informar a los usuarios sobre encuentros con individuos con resultados positivos en COVID-19, así como proporcionar datos a los epidemiólogos. Sin embargo, estas propuestas pueden fracasar en la protección de datos altamente sensibles, pudiendo ser éstos mal utilizados y extendidos más allá de su propósito inicial, lo cual iría en contra de los derechos fundamentales del individuo.

Para garantizar un servicio funcional que consiga su propósito sin poner en riesgo la privacidad e intimidad de los individuos, se proponen diferentes estimaciones como modelos que minimicen los datos coleccionados o modelos anónimos.​

Nuestra propuesta demuestra que los enfoques de preservación de la privacidad para el rastreo de proximidad son factibles, y que los países u organizaciones no tienen por qué aceptar métodos que plantean grandes riesgos y pueden ser mal utilizados. En los casos en que la ley exige una necesidad y una proporcionalidad estrictas proporcionalidad, y dado el amplio apoyo de la sociedad al rastreo de proximidad, el enfoque descentralizado ofrece una forma de llevarlo a cabo resistente a los abusos.

- Prof. Carmela Troncoso

El protocolo debe estar implementado de manera que el backend debe aprender la menor información posible sobre el usuario que realiza una carga. Esto supone que no se va a adquirir información adicional sobre la interacción del paciente con la autoridad sanitaria. La mitigación de este riesgo garantiza que no se construya (involuntariamente o no) una base de datos que vincule los identificadores con los usuarios infecciosos y que pueda ser pirateada o ser utilizada de forma indebida.

Del mismo modo, los teléfonos no almacenarán información personal de ningún usuario salvo el propio propietario del mismo. Los únicos datos que serán almacenados serán  los EphiD de aquellos con los que han tenido contacto, y serán ordenados en función de valores como la duración del contacto o la proximidad. Los EphID antiguos serán borrados, permaneciendo en los teléfonos el tiempo que las autoridades sanitarias consideren pertinente, estando establecido por defecto en 14 días siendo este valor configurable.​

Mecanismos de seguridad

Se describen diversos mecanismos de seguridad que pueden añadirse a las aplicaciones para asegurar la seguridad y privacidad de la información. Al protocolo se recomiendan medidas para proteger las comunicaciones sensibles entre la aplicación y el servidor (con el objetivo de evitar que adversarios puedan observar la comunicación del tráfico de red entre los usuarios y el servidor), proteger los metadatos del servidor, las comunicaciones entre back-end y los teléfonos y la validación de las notificaciones.​

Véase también

• BlueTrace
• Protocolo TCN
• Rastreo paneuropeo de proximidad para preservar la privacidad
• Proyecto de seguimiento de contactos de Google / Apple

Enlaces externos

• DP-3T Github

• Datos: Q90697518