4.5 KiB
Protocollo TCN
Descrizione del protocollo
Il protocollo TCN, Temporary Contact Number, è un protocollo di tracciamento dei contatti decentralizzato, ideato dalla TCN Coalition. Quest'ultima è una comunità di persone che durante l'emergenza COVID-19 hanno sviluppato questo supporto per lo sviluppo di applicazioni per notificare l'esposizione al contagio. Il protocollo non richiede, informazioni personali ed è compatibile con autorità sanitarie. I dispositivi degli utenti inviano un identificativo agli utenti vicini tramite Bluetooth e successivamente, se un utente è risultato positivo al contagio, può notificarlo ai suo contatti.
Per aumentare la scalabilità la TCN Coalition ha scelto di non generare randomicamente tcn, ma di generarli in modo deterministico da un seed. In questo modo si riduce la dimensione del report da inviare, in quanto contiene solo le informazione necessarie per calcolare i tcn e non l'elenco intero di tcn. L'utente può caricare diversi report di dimensioni minori in modo da non caricare l'intera cronologia dei contatti.
Chiavi di autenticazione e verifica
L'user agent crea una chiave di autorizzazione rak (report authorization key) e una chiave di verifica rvk (report verification key).
A partire dalla rak è possibile ricavare la chiave di contatto iniziale tck_0.
tck_0 ← H_tck(rak)
dove H_tck è una funzione di hash con 256 bit di output.
Chiave temporanea di contatto
Ogni report può contenere al massimo 2^{16} chiavi di contatto.
Partendo un tcn se ne può derivare il prossimo tcn come mostrato di seguito:
tck_i ← H_tck(rvk || tck_{i-1})
dove ||indica una concatenazione.
Numeri temporanei di contatto
Per ogni tck viene generato un numero di contatto temporaneo come mostrato di seguito:
tcn_i ← H_tcn(le_u16(i) || tck_i)
dove H_tcn è una funzione di Hash con 128 bit di output.
Dalla chiave rak è possibile generare la chiave rvk e la chiave tck_0, dalle quali è possibile generare le successive tck e quindi tutti i successivi tcn.
┌───┐
┌──▶│rvk│─────────┬──────────┬──────────┬──────────┬──────────┐
│ └───┘ │ │ │ │ │
┌───┐ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ │ ┌─────┐ │
│rak│──────▶│tck_0│─┴─▶│tck_1│─┴─▶│tck_2│─┴─▶ ... ─┴─▶│tck_n│─┴─▶...
└───┘ └─────┘ └─────┘ └─────┘ └─────┘
│ │ │
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│tcn_1│ │tcn_2│ ... │tcn_n│
└─────┘ └─────┘ └─────┘
Report
Un utente che vuole caricare il proprio report del periodo compreso tra j1 e j2, lo farà nel seguente modo:
report ← rvk || tck_{j1-1} || le_u16(j1) || le_u16(j2) || memo
dove memo è una stringa di byte di lunghezza variabile che va da 2 a 257 byte.
Inoltre si utilizza il rak per produrre una firmasig per il report report e verrà mandata la concatenazione di sig || report al server.
Chiunque può verificare l'integrità della sorgente e ricavare il tcn tramite sig, report e rvk, per poi confrontare questo tcn ottenuto con le proprie osservazioni.
tck_j1 ← H_tck(rvk || tck_{j1-1}) # Ratchet
tcn_j1 ← H_tcn(le_u16(j1) || tck_{j1}) # Generate
tck_{j1+1} ← H_tck(rvk || tck_{j1}) # Ratchet
tcn_{j1+1} ← H_tcn(le_u16(j1+1) || tck_{j1+1}) # Generate
...
non so se mettere o no questa parte di codice
Si noti che il tcn deriva dal tck_1{j1-1}che non è incluso nel report, perchè il destinatario non può verificare se è associato al rvk.
Se la verifica del client non è importante, il server, in modo arbitrario, può rmuover i 64 byte finali da ciascun report.