BlueTrace es un protocolo de aplicación de código abierto que facilita el rastreo digital de contactos de los usuarios para frenar la propagación de la pandemia de COVID-19 . [2] Inicialmente desarrollado por el Gobierno de Singapur , BlueTrace potencia 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 la adopción de BlueTrace. [8] [9] Un principio del protocolo es la preservación de la privacidad y la cooperación con las autoridades sanitarias. [10]
La preservación de la privacidad del usuario fue una de las consideraciones principales en torno a las cuales se diseñó BlueTrace. Para lograrlo, la información personal se recopila solo una vez en el momento del registro y solo se utiliza para contactar con pacientes potencialmente infectados. Además, los usuarios pueden optar por no participar en cualquier momento, borrando toda la información personal y haciendo que los datos registrados sean imposibles de rastrear. El rastreo de contactos se realiza completamente de forma local en un dispositivo cliente mediante Bluetooth Low Energy , almacenando todos los encuentros en un registro de historial de contactos que registra los encuentros de los últimos 21 días. Los usuarios en el registro de contactos se identifican mediante "identificaciones temporales" anónimas que cambian de hora y que emite la autoridad sanitaria. Esto significa que nadie puede determinar la identidad de un usuario excepto la autoridad sanitaria en la que está registrado. Además, dado que las identificaciones temporales cambian periódicamente, terceros malintencionados no pueden rastrear a los usuarios observando las entradas del registro a lo largo del tiempo.
Una vez que un usuario da positivo en la prueba de infección, la autoridad sanitaria solicita el registro de contactos. Si el usuario decide compartir su registro, se envía a la autoridad sanitaria, donde se compara el ID temporal con la información de contacto. Las autoridades sanitarias no pueden acceder a las entradas del registro sobre usuarios extranjeros, por lo que esas entradas se envían a la autoridad sanitaria extranjera correspondiente para que las procese allí. Una vez que se ha procesado un registro, la autoridad sanitaria se pone en contacto con el usuario identificado por el registro.
El protocolo se centra en dos áreas: el registro local de los usuarios registrados en las proximidades de un dispositivo y la transmisión del registro a la autoridad sanitaria encargada del funcionamiento, todo ello preservando la privacidad. Para lograrlo, el protocolo se puede dividir en las áreas de comunicación de dispositivo a dispositivo (DDC) y comunicación de dispositivo a servidor de informes (DRSC).
El componente DDC funciona 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 una prueba de 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
Cada aplicación que implementa el protocolo BlueTrace tiene un servidor central de informes correspondiente operado por una autoridad sanitaria. El servidor de informes es responsable de gestionar el registro inicial, proporcionar identificadores de usuario únicos y recopilar registros de contactos 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 más adelante si el usuario ha registrado un encuentro en el registro de contactos de un paciente infectado.
Una vez registrados, los usuarios reciben 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 UserID de un usuario, la hora de inicio del TempID y la hora de expiración 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 tengan un suministro constante de TempID, incluso en un entorno de red inestable, los TempID se transmiten a los dispositivos en lotes con fecha de vencimiento. [10] : sección. 4.2 La composición de un TempID se muestra a continuación:
Una vez que un usuario ha dado positivo en la prueba de infección, la autoridad sanitaria genera un PIN que autentica al usuario para cargar su registro de contactos al servidor de informes. Como parte del registro, se incluyen metadatos sobre cada encuentro; los más importantes de los cuales son la marca de tiempo y el identificador de la autoridad sanitaria (HAI).
El HAI identifica a qué autoridad sanitaria se dirige el contacto registrado. Si el HAI representa a una autoridad sanitaria extranjera, la entrada del registro se transmite a la autoridad identificada para que allí se procese.
Una vez que una autoridad sanitaria ha filtrado las entradas del registro para incluir solo a los clientes domésticos, descifra el TempID para revelar el UserID, la hora de inicio y la hora de vencimiento. La fecha de inicio y vencimiento se comparan con la marca de tiempo del encuentro para garantizar la validez, y el UserID se asocia a un número de teléfono. La autoridad sanitaria puede entonces ponerse en contacto con el número de teléfono para informar a un usuario sobre un posible contacto con un paciente infectado.
La parte DDC del protocolo define cómo se comunican dos dispositivos y registran su contacto. Cada dispositivo se encuentra en uno de dos estados, central o periférico, con un ciclo de trabajo de aproximadamente 1:4, respectivamente.
En el modo periférico, un dispositivo anuncia su presencia y, en el modo central, busca dispositivos que lo anuncien. Además, ciertos dispositivos no pueden funcionar en el modo central y, por lo tanto, funcionan puramente en el modo periférico. [11] Una vez que dos dispositivos se han descubierto entre sí, se comunican un paquete característico que contiene información sobre ellos mismos. El paquete se forma como un archivo JSON , que contiene el TempID del dispositivo, el modelo del dispositivo, HAI y la versión del protocolo BlueTrace.
Cuando funciona en modo central, el dispositivo envía además la intensidad de la señal, lo que permite calcular posteriormente la distancia aproximada entre los dos dispositivos. A continuación se muestra un ejemplo de paquete característico de Central:
{ "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 } Estas características se añaden a una base de datos local en el dispositivo, donde se almacenan durante 21 días y pueden enviarse al servidor de informes más tarde. El dispositivo contactado también se añade a una lista negra local durante dos ciclos de trabajo para evitar que dos dispositivos se pongan en contacto repetidamente entre sí, ahorrando así energía y almacenamiento.
La cooperación entre distintas autoridades sanitarias es un componente fundamental del protocolo BlueTrace y está diseñado de tal manera que varias autoridades puedan trabajar juntas sin revelar información personal a autoridades extranjeras en las que el usuario no esté registrado. Dado que cada autoridad mantiene su propia clave de cifrado y registros de usuarios, una autoridad sanitaria no puede descifrar ni ver 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 contiene un identificador de autoridad sanitaria (HAI), una cadena única asignada a las autoridades sanitarias registradas. Una vez que se identifica la entrada de registro de una autoridad sanitaria extranjera, la autoridad sanitaria receptora transmite la entrada de registro al servidor de informes de la autoridad extranjera, donde se verifica y se devuelve un PseudoID estático.
El PseudoID es un hash criptográfico con sal del UserID, diseñado para permitir que las autoridades sanitarias extranjeras realicen análisis estadísticos de los registros de contacto y se comuniquen sobre un usuario específico sin revelar información personal innecesaria. Una vez que se determina que el PseudoID estuvo en contacto cercano con el paciente infectado, se informa a la autoridad sanitaria extranjera que emitió el PseudoID y puede hacer el seguimiento necesario.
La capacidad de los usuarios de retirar 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 el único lugar donde se almacena la información personal es 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 lo que se utiliza para la identificación en la parte DDC del protocolo. Si un usuario retira el consentimiento, el registro de usuario se elimina del servidor de informes, lo que significa que los ID de usuario obtenidos a través de los registros de contactos ya no se pueden asociar a un número de teléfono.
Una de las mayores preocupaciones sobre privacidad que se plantean acerca de protocolos como BlueTrace o PEPP-PT es el uso de un procesamiento de informes centralizado. [12] [13] [14] [15] [16] [17] En un protocolo de procesamiento de informes centralizado, un usuario debe cargar todo su registro de contactos en un servidor administrado por una autoridad sanitaria, donde la autoridad sanitaria es entonces responsable de hacer coincidir las entradas del registro con los detalles de contacto, determinar el contacto potencial y, en última instancia, advertir a los usuarios del contacto potencial. [18]
Como alternativa, los protocolos de procesamiento de informes descentralizados, aunque siguen teniendo un servidor de informes central, delegan la responsabilidad de procesar los registros a los clientes de la red. Los protocolos que utilizan este enfoque, como TCN y DP-3T , hacen que el cliente cargue un número del que los dispositivos individuales pueden derivar tokens de encuentro. Luego, los clientes verifican estos tokens con sus registros de contacto locales para determinar si han estado en contacto con un paciente infectado. [19] Inherente al hecho de que el protocolo nunca permite al gobierno acceder a los registros de contacto, este enfoque tiene importantes beneficios de privacidad. Sin embargo, este método también presenta algunos problemas, principalmente la falta de informes humanos en el circuito, lo que lleva a una mayor incidencia de falsos positivos; [18] y posibles problemas de escala, ya que algunos dispositivos pueden verse abrumados 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 funciones de Firebase, un marco de computación sin servidor , para todas las llamadas de cliente; y Firebase Secret Manager [27] : líneas 29 a 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]
COVIDSafe [31] [32] es una aplicación de rastreo de contactos digitales anunciada por el Gobierno Federal Australiano basada en OpenTrace/BlueTrace, anunciada el 14 de abril de 2020 para ayudar a combatir la pandemia actual de COVID-19 . [33] El 26 de abril de 2020, el gobierno federal australiano lanzó públicamente la primera versión de la aplicación. [6] [5] En las primeras 24 horas posteriores al lanzamiento, más de 1 millón de personas descargaron la aplicación, [34] y en 48 horas, más de 2 millones. [35] En la segunda semana, más de 4 millones de usuarios se habían registrado. [36] Acompañando el lanzamiento, Peter Dutton , el Ministro del Interior , anunció una nueva legislación que haría ilegal obligar a cualquier persona a entregar datos de la aplicación, incluso si se había registrado y había dado positivo. [37] [38] El código fuente de la aplicación también se publicó el 8 de mayo de 2020, [39] [40] después de retrasos [41] hasta que se completó una revisión por parte de la Dirección de Señales de Australia . [42]
{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )