Protocolo TCN

Para generar un TCN, primero se crean una clave de autorización de informe (RAK) y una clave de verificación de informe (RVK) como claves de firma y verificación de un esquema de firma (par RAK-RVK). En la implementación de referencia, este par se crea utilizando el esquema de firma Ed25519 . ^{[ 40 ] : línea 13} Luego, utilizando la RAK, se genera una clave de contacto temporal inicial (TCK) mediante el algoritmo${\displaystyle tck_{0}=H\_tck(rak)}$, dónde${\displaystyle H\_tck()}$es la función hash SHA-256 como${\displaystyle H\_tck(s)=SHA256({\text{b'H}}\_{\text{TCK'}}||s)}$Este TCK no se utiliza para generar ningún TCN, sino que se utiliza en el siguiente TCK; donde todos los TCK futuros se calculan utilizando el algoritmo.${\displaystyle tck_{i}=H\_tck(rvk||tck_{i-1})}$A continuación, se genera un TCN de 128 bits a partir de un TCK dado utilizando el algoritmo.${\displaystyle tcn_{i>0}=H\_tcn(le\_u16(i)||tck_{i})}$, dónde ${\displaystyle le\_u16()}$formatea un número proporcionado como un entero sin signo de 2 bytes little endian , ^{[ 41 ]} y${\displaystyle H\_tcn()}$es la función hash SHA-256 como${\displaystyle H\_tcn(s)=SHA256({\text{b'H}}\_{\text{TCN'}}||s)[0:128]}$El siguiente diagrama muestra el proceso de derivación clave:

Los TCN son únicos para cada interacción con el dispositivo, y los pares RAK-RVK se alternan a intervalos regulares para permitir que un cliente informe solo sobre períodos de contacto específicos.

Cuando un cliente desea presentar un informe para los índices TCN${\displaystyle s>0}$a${\displaystyle e}$, estructura el informe como${\displaystyle report=rvk||tck_{s-1}||le\_u16(s)||le\_u16(e)||memo}$. Luego se calcula una firma utilizando el RAK y se transmite al servidor como${\displaystyle s\_report=report||sig}$.

Debido a que cualquier TCK dado solo puede usarse para derivar TCN indexados iguales o superiores, al enviar${\displaystyle tck_{s-1}}$ningún encuentro previo${\displaystyle tcn_{s-1}}$se pueden calcular. Sin embargo, no hay límite superior para los encuentros calculados usando el mismo par RAK-RVK, razón por la cual se repiten con frecuencia. Para evitar que los clientes calculen TCN no utilizados,${\displaystyle e}$indica el último índice TCN generado con el RVK dado. ^{[ 42 ] : líneas. 49–61} Además, dado que el RVK se utiliza para calcular un TCK, y${\displaystyle tck_{s-1}}$Se proporciona, no se pueden derivar TCN válidos en el período de informe a partir de un informe ilegítimo. El único TCN correcto que se puede calcular a partir de un RVK que no coincide y${\displaystyle tck_{s-1}}$es${\displaystyle tcn_{s-1}}$, el TCN antes del inicio del período de informe.

Una vez recibido el informe, los clientes recalculan individualmente los TCK y TCN para un período determinado utilizando los algoritmos originales:$${\displaystyle {\begin{array}{lcr}tck_{s}=H\_tck(rvk||tck_{s-1})\\tcn_{s}=H\_tcn(le\_u16(s)||tck_{s})\\tck_{s+1}=H\_tck(rvk||tck_{s})\\tcn_ {s+1}=H\_tcn(le\_u16(s+1)||tck_{s+1})\\...\\tck_{e}=H\_tck(rvk||tck_{e-1})\\tcn_{e}=H\_tcn(le\_u16(e)||tck_{e})\end{array}}}$$Los dispositivos cliente utilizan esta función para comprobar sus registros de contactos locales en busca de posibles encuentros con el paciente infectado, pero tiene la doble ventaja de verificar los informes, ya que los informes falsos nunca producirán TCN coincidentes.

En la estructura del informe, el memo es un espacio para mensajes de formato libre que difieren entre las implementaciones de TCN. La sección tiene entre 2 y 257 bytes y se compone de una etiqueta que identifica la implementación específica, así como un par de datos y longitud de datos. Tiene el formato de ${\displaystyle memo=etiqueta||len(datos)||datos}$Los datos están estandarizados para diferentes etiquetas y pueden ser los siguientes:

Cuando dos dispositivos se encuentran dentro del alcance uno del otro, intercambian un handshake que contiene TCN. Para lograr esto, el handshake de encuentro opera en dos modos (ambos con dos submodos), orientado a la difusión y orientado a la conexión. El modo orientado a la difusión opera usando los modos emisor y observador, mientras que el modo orientado a la conexión opera usando periférico y central. Los dos modos se utilizan para sortear ciertas limitaciones del dispositivo, particularmente con respecto a las restricciones de iOS vigentes antes de la versión 13.4. ^{[ 43 ]} En ambos modos, el protocolo se identifica con el UUID0xC019 de 16 bits .

En el modo de difusión, un emisor anuncia un TCN de 16 bytes utilizando el campo de datos de servicio de los datos de anuncio. El observador lee el TCN de este campo. En el modo orientado a la conexión, el periférico anuncia mediante el UUID. El servicio expone un paquete de lectura y escritura para compartir TCN. Tras compartir un TCN, el dispositivo central se desconecta del periférico.

Cuando un usuario da positivo en la prueba de infección, sube un informe firmado a un servidor central, lo que permite calcular sus contactos de los últimos 14 días. Los dispositivos cliente descargan periódicamente los informes del servidor y consultan sus registros de contactos locales mediante el algoritmo de verificación. Si se encuentra una coincidencia, la aplicación notifica al usuario sobre la posible infección.