El rastreo de proximidad descentralizado que preserva la privacidad ( DP-3T , estilizado como dp 3 t ) es un protocolo abierto desarrollado en respuesta a la pandemia de COVID-19 para facilitar el rastreo de contactos digitales de los participantes infectados. [4] [5] El protocolo, al igual que el protocolo competidor Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT), utiliza Bluetooth Low Energy para rastrear y registrar encuentros con otros usuarios. [6] [7] Los protocolos difieren en su mecanismo de informes, ya que PEPP-PT requiere que los clientes carguen registros de contactos en un servidor de informes central, mientras que con DP-3T, el servidor de informes central nunca tiene acceso a los registros de contactos ni es responsable de procesar e informar a los clientes sobre el contacto. [1] Debido a que los registros de contactos nunca se transmiten a terceros, tiene importantes beneficios de privacidad sobre el enfoque PEPP-PT; [8] [9] sin embargo, esto tiene el costo de requerir más potencia de procesamiento en el lado del cliente para procesar los informes de infección. [10]
El proyecto de notificación de exposición de Apple/Google se basa en principios similares a los del protocolo DP-3T y admite una variante del mismo desde mayo de 2020. [11] [12] [13] Huawei agregó una implementación similar de DP-3T a sus API de servicios móviles de Huawei conocidas como "Contact Shield" en junio de 2020. [14]
El SDK DP-3T y las aplicaciones de calibración tienen como objetivo admitir la API de Apple/Google tan pronto como se lance para dispositivos iOS y Android. [15] [16]
El 21 de abril de 2020, la Oficina Federal Suiza de Salud Pública anunció que la aplicación nacional suiza de rastreo de contactos de coronavirus se basará en DP-3T. [17] El 22 de abril de 2020, la Cruz Roja austríaca , líder en la aplicación nacional de rastreo de contactos digitales, anunció su migración al enfoque de DP-3T. [18] Estonia también confirmó que su aplicación se basaría en DP-3T. [19] El 28 de abril de 2020, se anunció que Finlandia estaba probando una versión piloto de DP-3T llamada "Ketju". [20] En Alemania , SAP SE y Deutsche Telekom están construyendo una aplicación nacional sobre DP-3T junto con CISPA , una de las organizaciones que crearon el protocolo. [21] A partir del 30 de septiembre de 2020, las aplicaciones de rastreo de contactos que utilizan DP-3T están disponibles en Austria , Bélgica , Croacia , Alemania, Irlanda , Italia , Países Bajos , Portugal y Suiza . [22]
El protocolo DP-3T funciona sobre la base de identificadores efímeros (EphID), cadenas rotativas semialeatorias que identifican de forma única a los clientes. [23] Cuando dos clientes se encuentran, intercambian EphID y los almacenan localmente en un registro de contactos. [24] Luego, una vez que un usuario da positivo en la prueba de infección, se envía un informe a un servidor central. Cada cliente de la red recopila los informes del servidor y verifica de forma independiente sus registros de contactos locales en busca de un EphID contenido en el informe. Si se encuentra un EphID coincidente, entonces el usuario ha estado en contacto cercano con un paciente infectado y el cliente lo 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 de informes central no puede determinar por sí mismo la identidad o el registro de contactos de ningún cliente en la red. Esto contrasta con protocolos de la competencia como PEPP-PT, donde el servidor de informes central recibe y procesa los registros de contactos del cliente. [25]
De manera similar al protocolo TCN y sus números de contacto temporales, el protocolo DP-3T utiliza identificadores efímeros (EphID) de 16 bytes para identificar de forma única los dispositivos que se encuentran cerca de un cliente. Estos EphID se registran localmente en el dispositivo del cliente receptor y nunca se transmiten a terceros. [1]
Para generar un EphID, primero un cliente genera una clave secreta que rota diariamente ( ) calculando , donde es una función hash criptográfica como SHA-256 . se calcula mediante un algoritmo de clave secreta estándar como Ed25519 . El cliente utilizará durante el día para generar una lista de EphID. Al comienzo del día, un cliente genera una lista local de tamaño nuevos EphID para transmitir durante el día, donde 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 , cada dispositivo calcula , donde es una cadena fija global, es una función pseudoaleatoria como HMAC-SHA256 y es un cifrado de flujo que produce bytes. Luego, este flujo se divide en fragmentos de 16 bytes y se ordena aleatoriamente para obtener los EphID del día. [1]
El protocolo DP-3T se compone de dos responsabilidades independientes: el seguimiento y registro de los encuentros a corta distancia con otros usuarios (device handshake) y la notificación de dichos encuentros de forma que otros clientes puedan determinar si han estado en contacto con un paciente infectado (notificación de infecciones). Como la mayoría de los protocolos de rastreo de contactos digitales, el protocolo de enlace de dispositivos utiliza Bluetooth Low Energy para buscar e intercambiar detalles con los clientes locales, y la etapa de notificación de infecciones utiliza HTTPS para cargar un informe en un servidor de informes central. Además, al igual que otros protocolos de informes descentralizados , el servidor de informes central nunca tiene acceso a los registros de contactos de ningún cliente; en cambio, el informe está estructurado de forma que los clientes puedan derivar individualmente el contacto a partir del informe. [1]
Para encontrar y comunicarse con clientes que se encuentran cerca de un dispositivo, el protocolo utiliza tanto el modo servidor como el modo cliente de Bluetooth LE, alternando entre ambos con frecuencia. [26] En el modo servidor, el dispositivo anuncia su EphID para que lo lean los clientes, y estos escanean en busca de servidores. [27] Cuando un cliente y un servidor se encuentran, el cliente lee el EphID y posteriormente escribe su propio EphID en el servidor. Luego, 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 más tarde como parte del proceso de notificación de infecciones para estimar la distancia entre un paciente infectado y el usuario. [1]
Cuando se informa de una infección, existe un servidor de informes central controlado por la autoridad sanitaria local. Antes de que un usuario pueda enviar un informe, la autoridad sanitaria debe confirmar primero la infección y generar un código que autorice al cliente a cargar el informe. La autoridad sanitaria también indica al paciente en qué día debe comenzar su informe (indicado como ). A continuación, el cliente carga el par y en el servidor de informes central, que otros clientes de la red descargan en una fecha posterior. Al utilizar el mismo algoritmo utilizado para generar los EphID originales, los clientes pueden reproducir todos los EphID utilizados durante el período anterior e incluido , que luego verifican con su registro de contactos local para determinar si el usuario ha estado en proximidad cercana a un paciente infectado. [1]
En todo el protocolo, la autoridad sanitaria nunca tiene acceso a los registros de contactos, y sólo sirven para realizar pruebas a los pacientes y autorizar el envío de informes. [1] : p. 11
Cuando un usuario instala una aplicación DP-3T, se le pregunta si desea aceptar compartir datos con epidemiólogos . Si el usuario da su consentimiento, cuando se confirme que ha estado en contacto cercano con un paciente infectado, se programa el envío de la entrada del registro de contacto correspondiente que contiene el encuentro a un servidor central de estadísticas. Para evitar que terceros malintencionados descubran posibles infecciones al detectar estas cargas, se envían informes a intervalos regulares, y se envían informes ficticios indistinguibles cuando no hay datos para transmitir. [1]
Para facilitar la compatibilidad entre las aplicaciones DP-3T administradas por distintas autoridades sanitarias, las aplicaciones mantienen una lista local de las regiones que ha visitado un usuario. Las regiones son grandes áreas que corresponden directamente a la jurisdicción de la autoridad sanitaria; no se registra la ubicación exacta. La aplicación conectará posteriormente estas regiones con su respectivo servidor central de informes extranjero y obtendrá informes de estos servidores además de su servidor de informes local normal. Las aplicaciones también enviarán informes a estos servidores de informes extranjeros si el usuario da positivo en la prueba de infección. [1]
El especialista en criptografía y seguridad Serge Vaudenay , al analizar la seguridad de DP-3T [28], argumentó que:
Algunas medidas de protección de la privacidad adoptadas por DP3T pueden tener el efecto contrario [ sic ] al que se pretendía. En concreto, se puede desanonimizar a las personas enfermas y denunciadas, se pueden revelar encuentros privados y se puede obligar a las personas a revelar los datos privados que recopilan.
— Serge Vaudenay, [28] : pág. 1
El trabajo de Vaudenay presenta varios ataques contra DP-3T y sistemas similares. En respuesta, el grupo DP-3T afirma que de los doce riesgos que presenta Vaudenay, ocho también están presentes en sistemas centralizados, tres no funcionan y uno, que implica el acceso físico al teléfono, funciona pero se puede mitigar. [29] En un trabajo posterior [30] Vaudenay revisa los ataques contra sistemas de rastreo tanto centralizados como 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 contabilidad y auditoría.
— Serge Vaudenay, [30] : pág. 6
En el mismo trabajo [30] Vaudenay defiende que, dado que ni los enfoques centralizados ni los descentralizados ofrecen un nivel suficiente de protección de la privacidad, se deberían explorar diferentes soluciones, sugiriendo en particular los sistemas ConTra Corona [31] , Epione [32] y Pronto-C2 [33] como una "tercera vía".
Tang [34] analiza los principales sistemas de rastreo de contactos digitales y muestra que DP-3T está sujeto a lo que él llama "ataques de identificación dirigidos".
Se han simulado ataques teóricos a DP-3T [35] 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 Low Energy . Este ataque aprovecha la capacidad de vinculación de un usuario durante un día y, por lo tanto, es posible en un día para todos los usuarios de algunos sistemas centralizados como el sistema propuesto en el Reino Unido [36] , pero no funciona en versiones "no vinculables" de DP-3T donde los identificadores de los usuarios infectados no se transmiten utilizando una representación compacta como una clave o una semilla [37] .
{{cite web}}: CS1 maint: multiple names: authors list (link){{cite web}}: CS1 maint: numeric names: authors list (link)