[2] 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.
[12] 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.
[13][14] 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.
[16][17] 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.
[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 por infección, se envía un informe a un servidor central.
Al comienzo del día, un cliente genera una lista local de tamaño
nuevos EphID para transmitir durante todo el día, donde
Para evitar que terceros malintencionados establezcan patrones de movimiento rastreando identificadores estáticos en un área grande, los EphID se rotan con frecuencia.
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.
[26] 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).
[27] 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.
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
[27] 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.
[27] 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.
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.
Las aplicaciones, además, enviarán informes a estos otros servidores extranjeros si el usuario ha dado positivo en las pruebas de infección.
- Serge Vaudenay, [28]: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.
Por el contrario, los sistemas centralizados ofrecen muchas contramedidas, mediante la contabilidad y la auditoría.
- Serge Vaudenay,[29]:p. 6 En el mismo trabajo[29] 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,[30] Epione[31] y Pronto-C2[32] como una "tercera ví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,[35] 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.
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.
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.
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.
Esto supone que no se va a adquirir información adicional sobre la interacción del paciente con la autoridad sanitaria.
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.