BlueTrace

BlueTrace es un protocolo de aplicación de código abierto que facilita el rastreo digital de contactos de usuarios para frenar la propagación de la pandemia de COVID-19 . ^{[ 2 ]} Desarrollado inicialmente por el Gobierno de Singapur , BlueTrace impulsa el rastreo de contactos para la aplicación TraceTogether . ^{[ 3 ] [ 4 ]} Australia y los Emiratos Árabes Unidos ya han adoptado el protocolo en sus aplicaciones gubernamentales, ^{[ 5 ] [ 6 ] [ 7 ]} y otros países estaban considerando adoptar BlueTrace. ^{[ 8 ] [ 9 ]} Un principio del protocolo es la preservación de la privacidad y la cooperación de las autoridades sanitarias. ^{[ 10 ]}

La preservación de la privacidad del usuario fue una de las consideraciones fundamentales en torno a las cuales se diseñó BlueTrace. Para lograrlo, la información personal se recopila solo una vez, al momento del registro, y se utiliza únicamente para contactar a pacientes potencialmente infectados. Además, los usuarios pueden optar por no participar en cualquier momento, eliminando toda su información personal y haciendo que cualquier dato registrado sea imposible de rastrear. El rastreo de contactos se realiza completamente de forma local en el dispositivo del cliente mediante Bluetooth de bajo consumo , almacenando todos los encuentros en un registro de historial de contactos que documenta los encuentros de los últimos 21 días. Los usuarios en el registro de contactos se identifican mediante identificadores temporales anónimos emitidos por la autoridad sanitaria. Esto significa que la identidad de un usuario solo puede ser verificada por la autoridad sanitaria con la que está registrado. Además, dado que los identificadores temporales cambian periódicamente, terceros malintencionados no pueden rastrear a los usuarios observando las entradas del registro a lo largo del tiempo.

Cuando un usuario da positivo en la prueba de infección, la autoridad sanitaria solicita el registro de contactos. Si el usuario decide compartirlo, este se envía a la autoridad sanitaria, donde se coteja el identificador temporal con la información de contacto. Las autoridades sanitarias no pueden acceder a los registros de usuarios extranjeros, por lo que estos se envían a la autoridad sanitaria extranjera correspondiente para su procesamiento. Una vez procesado el registro, la autoridad sanitaria se pone en contacto con el usuario identificado en el mismo.

El protocolo se centra en dos áreas: el registro local de usuarios registrados en las proximidades de un dispositivo y la transmisión de dicho registro a la autoridad sanitaria correspondiente, todo ello preservando la privacidad. Para lograrlo, el protocolo se divide en comunicación entre dispositivos (DDC) y comunicación entre el dispositivo y el servidor de informes (DRSC).

El componente DDC opera sobre el protocolo Bluetooth Low Energy existente , definiendo cómo dos dispositivos reconocen la presencia del otro. ^{[ 10 ] : p. 2} El componente DRSC utiliza HTTPS para comunicar una cronología de visitas a un servidor centralizado propiedad de una autoridad sanitaria una vez que un usuario ha dado positivo en la prueba de una infección. La autoridad sanitaria puede entonces, utilizando el registro, notificar a los usuarios que estuvieron en contacto con el paciente infectado. ^{[ 10 ] : p. 2}

Protocolo de comunicación entre el dispositivo y el servidor de informes

Cada aplicación que implementa el protocolo BlueTrace tiene un servidor de informes central correspondiente operado por una autoridad sanitaria. El servidor de informes es responsable de gestionar el registro inicial, proporcionar identificadores de usuario únicos y recopilar los registros de contacto creados por la parte DDC del protocolo. Cuando el usuario inicia por primera vez una aplicación BlueTrace, se le solicitará su número de teléfono con formato internacional y se le asignará un ID de usuario estático. ^{[ 10 ] : sección. 4} Este número de teléfono se utiliza posteriormente si el usuario ha registrado un encuentro en el registro de contactos de un paciente infectado.

Una vez registrados, a los usuarios se les proporcionan identificadores temporales (TempID) que los identifican de forma única ante otros dispositivos. Cada TempID tiene una duración de 15 minutos para evitar que terceros malintencionados realicen ataques de repetición o rastreen a los usuarios a lo largo del tiempo con identificadores únicos estáticos. ^{[ 10 ] : sección 4.2} Los TempID se generan a partir del ID de usuario, la hora de inicio y la hora de caducidad del TempID, que el servidor cifra y convierte en una cadena codificada en Base64 mediante una clave de cifrado simétrica secreta . Para garantizar que los dispositivos dispongan de un suministro constante de TempID, incluso en un entorno de red inestable, los TempID se transmiten a los dispositivos en lotes con fecha futura. ^{[ 10 ] : sección 4.2} La composición de un TempID se muestra a continuación:

Una vez que un usuario da positivo en la prueba de infección, la autoridad sanitaria genera un PIN que lo autentica para que pueda subir su registro de contactos al servidor de informes. Este registro incluye metadatos sobre cada encuentro; entre los más importantes se encuentran la marca de tiempo y el identificador de la autoridad sanitaria (HAI).

El HAI identifica a qué autoridad sanitaria se notifica el contacto registrado. Si el HAI representa a una autoridad sanitaria extranjera, la entrada del registro se transmite a la autoridad identificada para su procesamiento.

Una vez que la autoridad sanitaria ha filtrado los registros para incluir únicamente a los pacientes que acuden a domicilio, descifra el TempID para obtener el ID de usuario, la hora de inicio y la hora de caducidad. La fecha de inicio y la de caducidad se comparan con la marca de tiempo del encuentro para garantizar su validez, y el ID de usuario se asocia a un número de teléfono. La autoridad sanitaria puede entonces contactar con dicho número para informar al usuario de un posible contacto con un paciente infectado.

{ "id" : "FmFISm9nq3PgpLdxxYpTx5tF3ML3Va1wqqgY9DGDz1utPbw+Iz8tqAdpbxR1 nSvr+ILXPG==" , // TempID "md" : "iPhone X" , // Modelo del dispositivo "rc" : -60 , // Intensidad de la señal "o" : "IJ_HAI" , // Identificador de la autoridad sanitaria "v" : 2 // Versión del protocolo }

La cooperación entre distintas autoridades sanitarias es un componente fundamental del protocolo BlueTrace, diseñado para que múltiples autoridades puedan colaborar sin revelar información personal a autoridades extranjeras con las que el usuario no esté registrado. Dado que cada autoridad mantiene su propia clave de cifrado y registros de usuario, ninguna autoridad sanitaria puede descifrar ni acceder a los datos de un usuario extranjero.

Para garantizar que las entradas de registro se envíen a la autoridad correcta, parte del protocolo de enlace DDC incluye un identificador de autoridad sanitaria (HAI), una cadena única asignada a las autoridades sanitarias registradas. Una vez identificada la entrada de registro de una autoridad sanitaria extranjera, la autoridad sanitaria receptora la transmite al servidor de informes de dicha autoridad, donde se verifica y se devuelve un pseudo-ID estático.

El PseudoID es un hash criptográfico con sal del ID de usuario, diseñado para permitir que las autoridades sanitarias extranjeras realicen análisis estadísticos de los registros de contactos y se comuniquen sobre un usuario específico sin revelar información personal innecesaria. Una vez que se determina que el PseudoID ha estado en contacto cercano con el paciente infectado, se informa a la autoridad sanitaria extranjera que lo emitió, la cual puede tomar las medidas necesarias.

La posibilidad de que los usuarios retiren su consentimiento para el uso y la recopilación de sus datos en cualquier momento fue una consideración importante en el diseño del protocolo. ^{[ 10 ] : sección 3, punto 4} Para permitir esto, la información de identificación personal se excluye del componente DDC del protocolo. Esto significa que la información personal solo se almacena en el servidor de informes, donde se asocia con un ID de usuario estático anónimo. Este ID de usuario (encriptado en un TempID) es el que se utiliza para la identificación en la parte DDC del protocolo. Si un usuario retira su consentimiento, el registro del usuario se elimina del servidor de informes, lo que significa que los ID de usuario obtenidos a través de los registros de contacto ya no se pueden vincular a un número de teléfono.

Una de las mayores preocupaciones sobre la privacidad planteadas en relación con protocolos como BlueTrace o PEPP-PT es el uso del procesamiento centralizado de informes. ^{[ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ]} En un protocolo de procesamiento centralizado de informes, un usuario debe cargar todo su registro de contactos a un servidor administrado por la autoridad sanitaria, donde esta es responsable de cotejar las entradas del registro con los datos de contacto, determinar el contacto potencial y, en última instancia, advertir a los usuarios sobre el contacto potencial. ^{[ 18 ]}

Alternativamente, los protocolos de procesamiento de informes descentralizados, si bien cuentan con un servidor central de informes, delegan la responsabilidad de procesar los registros a los clientes de la red. Los protocolos que utilizan este enfoque, como TCN y DP-3T , requieren que el cliente cargue un número a partir del cual los dispositivos individuales pueden derivar tokens de encuentro. Los clientes luego verifican estos tokens con sus registros de contacto locales para determinar si han estado en contacto con un paciente infectado. ^{[ 19 ]} Dado que el protocolo nunca permite que el gobierno acceda a los registros de contacto, este enfoque ofrece importantes beneficios en materia de privacidad. Sin embargo, este método también presenta algunos problemas, principalmente la falta de intervención humana en la generación de informes, lo que conlleva una mayor incidencia de falsos positivos; ^{[ 18 ]} y posibles problemas de escala, ya que algunos dispositivos podrían verse sobrecargados con una gran cantidad de informes. Los protocolos de informes descentralizados también son menos maduros que sus contrapartes centralizadas. ^{[ 20 ] [ 21 ] [ 22 ]}

OpenTrace es la implementación de referencia de código abierto de BlueTrace publicada bajo la licencia GPL-3.0 . ^{[ 23 ] [ 24 ] [ 25 ]} El lado DRSC del protocolo se implementa utilizando la plataforma Firebase , ^{[ 26 ]} utilizando las funciones de Firebase, un marco de computación sin servidor , para todas las llamadas del cliente; y Firebase Secret Manager ^{[ 27 ] : líneas 29–37} y Storage ^{[ 28 ] : línea 22} para almacenar la clave de cifrado y los registros de contacto respectivamente. Para el lado de la aplicación/DDC del protocolo, se incluye una versión modificada de la aplicación TraceTogether para dispositivos Android e iOS. ^{[ 29 ] [ 30 ]}

• TraceTogether
• Protocolo TCN
• Sistema paneuropeo de rastreo de proximidad que preserva la privacidad
• Notificación de exposición (Google/Apple) (GAEN)

• Documento técnico archivado el 20 de abril de 2020 en Wayback Machine.
• OpenTrace GitHub
• Página principal de BlueTrace archivada el 11 de abril de 2020 en Wayback Machine.