Come funziona DP-3T, la soluzione che vuole combattere il COVID-19 col tracciamento dei contatti

di Enrico Nardelli

(per favore consultare anche gli aggiornamenti alla fine del post e la descrizione della nuova versione)

Ecco quello che ho capito di come funziona la soluzione proposta per il tracciamento dei contatti di prossimità rispettosa della privacy (PEPP-PT: Pan-European Privacy Preserving Proximity Tracing, descritta anche nota come DP-3T: Decentralized Privacy-Preserving Proximity Tracing) che sta venendo proposta in questi giorni come la soluzione necessaria per combattere la diffusione del COVID-19.

Nel mio post precedente ho discusso alcune delle altre problematiche non tecniche di una tale soluzione.

Aggiungo qui una sola considerazione che richiede di essere sottolineata. Sapere con chi è stata in contatto una persona infetta nei giorni precedenti quello in cui è stata diagnosticata serve soltanto se la diagnosi arriva abbastanza presto per avvisare i suoi contatti PRIMA che essi contattino altre persone. Se una persona mediamente viene in contatto con altre 10 durante un giorno (attenzione che essere in contatto non vuol dire fermarsi a parlare, ma essere stati nello stesso ufficio, negozio, locale, mezzo di trasporto, etc), un infetto genera al secondo giorno 100 potenziali infetti, al terzo 1.000 e 10.000 al quarto. Se mi accorgo solo oggi che 5 giorni fa quella persona era infetta devo fare OGGI 10.000 tamponi (o chiedere a 10.000 persone di auto-isolarsi) per evitare di trovarmi domani con 100.000 potenziali infetti. Non impossibile, se ci si è preparati, ma non è qualcosa che si organizza in qualche giorno o in poche settimane. Non è un caso che in Cina è dall'epidemia di SARS del 2003 che stanno lavorando su questo.

L'idea di base di PEPP-PT DP-3T è installare su ogni smartphone di chi vuole partecipare un'app che usa il Bluetooth per interagire con altri smarthpone nelle vicinanze registrando reciprocamente che si è stati in contatto. Il tutto mantenendo l'anonimato. Un server centrale periodicamente aggiorna tutte le app con informazioni anonime relative a chi è stato infettato, permettendo ad ogni smartphone di scoprire se è stato vicino ad un infettato, ma senza consentirgli di scoprire chi sia.

Andiamo agli aspetti tecnici più rilevanti. Non discuto tutti i dettagli per motivi di spazio. Chi volesse approfondire può consultare la loro documentazione tecnica.

All'atto dell'installazione l'app genera una chiave, che è un numero casuale SK₀ di 32 byte, e si registra presso un server centrale, cui però non invia SK₀ ma un'altro ID che il server centrale usa solo per gli aggiornamenti periodici relativi agli infetti. A partire da quando è stata installata l'app, ogni giorno la chiave viene rinnovata, calcolando un nuovo numero casuale di 32 byte SK_t+1 mediante una funzione hash H1 predefinita che ha come argomento SK_t. L'uso di H1 garantisce che dato il numero casuale di un giorno non sia possibile calcolare quello del giorno prima. L'app memorizza le ultime 14 SK_t usate, perchè 14 giorni sono ritenuti il tempo necessario per l'infezione per svilupparsi. Il valore 14 può essere modificato se le autorità sanitarie lo ritengono opportuno.

Il numero casuale di ogni giorno SK_t viene usato per generare, attraverso una diversa funzione hash H2, un certo numero di "identificatori effimeri" EphID che saranno usati solo quel giorno per registrare i contatti avuti durante solo quel giorno. Quando due telefoni, attraverso il Bluetooth, capiscono di essere vicini allora le due app si scambiano gli EphID che vengono memorizzati localmente insieme ad un'indicazione temporale grossolana (la documentazione non è esplicita, diciamo una finestra temporale di 4 ore), alla forza del segnale Bluetooth ricevuto (che è un'indicatore della distanza tra i dispositivi) e al tempo di vicinanza. Di nuovo, l'uso di H2 non consente di risalire dagli EphID al SK_t usato per generarli, neanche conoscendo tutti gli EphID usati durante una stessa giornata, né permette di capire se due EphID ricevuti nello stesso giorno sono relativi ad uno stesso SK_t.

Ogni giorno l'app cancella i dati più vecchi dei 14 giorni, sia gli SK_t che gli EphID dei telefoni cui è stato vicino, che i dati associati agli EphID ricevuti.

Quando una persona scopre da un controllo medico di essere infetta riceve un codice di autorizzazione dall'autorità sanitaria, che può scegliere di usare per avvisare il server centrale di essere infetta. In tal caso l'app utilizza il codice per inviare in modo sicuro lo SK_t relativo al presumibile giorno di inizio dell'infezione, diciamo che sia il più vecchio che conserva, quello di 14 giorni fa. Per evitare che la semplice esistenza di tale comunicazione sveli ad osservatori esterni che la persona è infetta, essa viene fatta nell'ambito di comunicazioni che la app fa al server più volte durante il giorno a intervalli regolari. Esse ad un esame esterno sono indistinguibili, ma solo una di esse contiene lo SK_t. Quando la app effettua la comunicazione al server centrale relativa all'infezione essa contestualmente genera un nuova chiave iniziale, cioè un nuovo numero casuale SK₀ di 32 byte, che verrà usato dal quel momento in avanti nel meccanismo di tracciamento dei contatti.

Quando il server riceve una comunicazione di infezione, lo SK_t ricevuto viene, nell'ambito degli aggiornamenti periodici, inviato a tutti gli smartphone che hanno l'app installata. Ogni app quindi calcola per ogni SK_t ricevuto, che corrisponde ad un infetto, sia gli EphID di quel giorno (usando la funzione hash H2), che gli SK_t dei giorni successivi fino al giorno corrente (usando la funzione hash H1) e i loro corrispondenti EphID. Tutti gli EphID calcolati in questo modo vengono usati per cercare nei contatti memorizzati se si è stati in contatto con qualche infetto. In tal caso, sulla base dei dati di contatto (distanza e durata) un algoritmo presente sull'app (che usa parametri aggiustabili dall'autorità sanitaria) può calcolare un'indice di rischio per il possessore dello smartphone che viene quindi, sulla base di tale indice, consigliato su cosa fare.

Quest'ultimo elemento della distribuzione degli SK_t è secondo me un punto debole rispetto alla privacy. Infatti, quando un app riceve un SK_t di un infetto può, calcolando mediante H1 gli SK_t dei giorni successivi e mediante H2 gli EphID corrispondenti, arrivare a scoprire l'identità della persona, perché può ricondurre diversi EphID, che sono intrinsecamente scorrelati, ad uno stesso SK_t originale. Ciò è vero ovviamente soprattutto nel caso di persone che si incontrano con una qualche regolarità o per le quali, magari per ragioni di lavoro, si sono annotati nella propria agenda gli appuntamenti svolti.
     Inoltre, il server centrale memorizza gli SK_t ricevuti. Anche questo mi sembra un punto debole perché, anche se tutti quegli smartphone hanno cambiato chiave, i loro SK_t possono essere usati per ricondurre ad uno stesso dispositivo degli EphID che sono altrimenti scorrelati.

Ho chiesto chiarimenti su questi elementi al team che ha messo a punto lo schema e pubblicherò quanto riceverò.

Addendum delle 20:50 CET: Francesco Palmieri mi ha segnalato che il protocollo Bluetooth è noto per essere abbastanza vulnerabile. Avere la soluzione sopra descritta installata su milioni di dispositivi con Bluetooth costantemente attivo vorrebbe quindi dire avere milioni di dispositivi esposti ad attacchi.

Addendum del 6 aprile 17:30 CET: Michael Vaele, uno dei ricercatori del team DP-3T (erroneamente chiamato DPT nella prima versione di questo post) mi ha scritto su Twitter che «the DP-3T protocol is not PEPP-PT. PEPP-PT is an empty shell, to be filled. We try to fill with decentralised.» Ho quindi aggiornato il paragrafo iniziale e il titolo, facendo adesso solo riferimento a DP-3T. La mia analisi non cambia, dal momento che era comunque la documentazione del DP-3T (link sulla prima linea di questo post) quella che avevo analizzato. Inoltre, desidero precisare che la descrizione di PEPP-PT presente sul loro sito coincide con la descrizione di alto livello di DP-3T e INCLUDE la decentralizzazione (vedi figura sotto).

Addendum (April 9th, 19:20 CET). DP-3T ha rilasciato una nuova versione della specifica del protocollo (che sto analizzando), una spiegazione delle relazioni tra DP-3T e PEPP-PT, e un insieme di risposte sollevate (da me ed altri ricercatori) in questa FAQ. La mia osservazione relativa alla distribuzione degli SK_t dei dispositivi delle persone infette viene (credo) discussa al punto P6. Ho scritto "credo" dal momento che il titolo attuale di P6 è «Why do infected people upload a seed (which enables recreating EphIDs) instead of their individual EphIDs?» [Perché le persone infette inviano al server la chiave iniziale (che rende possibile ricreare gli EphIDs) invece dei loro singoli EphIDs?].

Da solo, l'invio al server della chiave iniziale non compromette l'anonimità della persona infetta, dal momento che viene generata casualmente quando l'app viene installata. Il problema che avevo segnalato io è nel fatto che poi il server invia direttamente a tutti queste chiavi iniziali di chi è infetto invece di inviare gli EphIDs che si possono calcolare da essi. La risposta fornita nelle FAQ discute il problema in termini di prestazioni, che in linea di principio è un argomento ragionevole. Ma dal momento che il punto riguarda la privacy delle persone, io rimango convinto che il protocollo NON DOVREBBE inviare le chiavi iniziali degli infetti ma solo gli EphIDs derivati.

Quindi il titolo di P6 dovrebbe essere «Why do the backend broadcast the seeds of infected persons (which enables recreating EphIDs) instead of their individual EphIDs?» [Perché il server invia le chiavi iniziali delle persone infette (che permette di ricreare gli EphIDs) invece dei singoli EphIDs?]. Ho chiesto spiegazioni e vi aggiornerò su quanto ricevo.

NB: nella prima versione pubblicata le chiavi venivano erroneamente descritte come a 32 bit invece che a 32 byte.