Decentralized Privacy-Preserving Proximity Tracing

Decentralized-Privacy-Preserving Proximity Tracking (DP-3T, stilizzata come $DP^{3}T$ ) è un protocollo open-source sviluppato da un team europeo guidato da Carmela Troncoso e formato da ricercatori provenienti da diverse università in risposta alla pandemia di COVID-19 per facilitare la tracciatura dei contatti avuti dai partecipanti infetti. Il protocollo, come anche il protocollo Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT), utilizza Bluetooth Low Energy per tenere traccia e registrare gli incontri con altri utenti. I protocolli differiscono nel loro meccanismo di reportistica: PEPP-PT richiede ai client di caricare i log dei contatti su un server di report centrale e mentre su DP-3T il server di reporting centrale non ha mai accesso ai log di contatti né è responsabile dell'elaborazione e della comunicazione ai client dei contatti avvenuti. Poiché i registri dei contatti non vengono mai trasmessi a terzi, presenta importanti vantaggi in termini di privacy rispetto all'approccio PEPP-PT, tuttavia ciò comporta costi che richiedono maggiore potenza di elaborazione sul lato client per elaborare i rapporti sulle infezioni.

Secondo Google, il progetto di tracciamento dei contatti di Google / Apple è stato "fortemente ispirato" dal protocollo DP-3T.

L'SDK DP-3T e le app di calibrazione intendono supportare le API Apple / Google non appena verranno rilasciate su dispositivi iOS e Android.

Il 21 aprile 2020, l'Ufficio federale della sanità pubblica svedese ha annunciato che l'applicazione nazionale per la tracciatura dei contatti da coronavirus sarà basata su DP-3T. Il 22 aprile 2020, la Croce Rossa austriaca, leader del progetto dell'app nazionale di tracciamento dei contatti digitali, ha annunciato la sua migrazione verso l'approccio di DP-3T. L'Estonia ha inoltre confermato che la sua app sarebbe basata su DP-3T. Il 28 aprile 2020, la Finlandia ha annunciato di stare testando una versione di DP-3T chiamata "Ketju". In Germania, l'app nazionale si basa su DP-3T ed è stata sviluppata da SAP SE e Deutsche Telekom insieme a CISPA, che è una delle organizzazioni che hanno creato il protocollo.

Panoramica

Il protocollo DP-3T funziona sulla base degli Ephemeral ID (EphID, trad. ID Temporanei), ossia stringhe semi-casuali che identificano in modo univoco i client e che cambiano di tanto in tanto. Quando due client si incontrano, essi si scambiano i propri EphID e li memorizzano localmente in un registro contatti. Quando un utente risulta positivo all'infezione, viene inviato un rapporto a un server centrale. Ogni client sulla rete quindi raccoglie i report dal server e controlla in modo indipendente i propri registri di contatti in cerca di eventuali EphID presenti nel report del server. Se viene trovato una corrispondenza per un EphID, ciò vuol dire che l'utente è entrato in stretto contatto con un paziente infetto e quindi viene avvisato dal client (ossia dall'app). Poiché ogni dispositivo verifica localmente i registri dei contatti, e quindi i registri dei contatti non vengono mai trasmessi a terzi, il server di report centrale non può da solo accertare l'identità o il registro dei contatti di alcun client nella rete. Ciò è in contrasto con protocolli concorrenti come PEPP-PT, in cui il server di report centrale riceve ed elabora i registri dei contatti del client.

Diagramma che mostra come i diversi componenti dell'algoritmo per la generazione di ID Temporanei (EphID) comunicano l'un l'altro

Come anche il protocollo TCN e suoi Temporary Contact Numbers, il protocollo DP-3T utilizza ID Temporanei a 16 byte (EphID) per identificare in modo univoco i dispositivi che si trovano in prossimità di un client. Questi EphID vengono registrati localmente sul dispositivo ricevente e non vengono mai trasmessi a terzi.

Per generare un EphID, innanzitutto un client genera una chiave segreta che cambia giornalmente ( $SK_{t}$ ) calcolando $SK_{t}=H(SK_{t-1})$, dove $H()$ è una funzione hash crittografica (come ad esempio SHA-256). $SK_{0}$ viene calcolato da un algoritmo tramite una chiave segreta standard, ad esempio tramite Ed25519. Il client utilizzerà $SK_{t}$ durante il giorno $t$ per generare un elenco di EphID. All'inizio della giornata, un client genererà un elenco locale di dimensione $n=(24*60)/l$ di nuovi EphID da trasmettere durante il giorno, dove $l$ è la durata di un EphID in minuti. Per impedire a terzi di stabilire schemi di movimento tracciando gli identificatori su una vasta area, gli EphID vengono cambiati frequentemente. Data la chiave segreta del giorno $SK_{t}$, ogni dispositivo calcola $S\_EphID(BK)=PRG(PRF(SK_{t},BK))$, dove $BK$ è una stringa fissa, $PRF()$ è una funzione pseudo-random come ad esempio HMAC-SHA256 e $PRG()$ è un cifrario a flusso che produce $n*16$ byte. Questo flusso viene quindi suddiviso in blocchi di 16 byte e ordinato in maniera randomica per ottenere gli EphID del giorno.

Specifiche tecniche

Il protocollo DP-3T è costituito da due componenti distinte: il monitoraggio e la registrazione degli incontri a distanza ravvicinata con altri utenti (handshake fra i dispositivi), e la segnalazione di tali incontri, in modo tale che altri client possano determinare se sono stati in contatto con un paziente infetto (segnalazione di infezione). Come la maggior parte dei protocolli di tracciamento dei contatti, l'handshake del dispositivo utilizza Bluetooth Low Energy per trovare e scambiare le informazioni con i client nelle vicinanze e la fase di segnalazione delle infezioni utilizza il protocollo HTTPS per caricare un report su un server centrale. Inoltre, come altri protocolli di reporting decentralizzati, il server di report centrale non ha mai accesso ai registri dei contatti di alcun client; piuttosto il report è strutturato in modo tale che i client stessi possano derivare individualmente gli eventuali contatti dal report.

Handshake del dispositivo

Per trovare i client nelle vicinanze e comunicare con essi, il protocollo utilizza le sia la modalità server che client di Bluetooth LE, cambiando frequentemente modalità. In modalità server, il dispositivo emette il suo EphID affinché venga letto dai client, mentre quando è in modalità client il dispositivo esegue la scansione di eventuali server nelle vicinanze. Quando un client e un server si incontrano, il client legge l'EphID del server e successivamente invia il proprio EphID al server. I due dispositivi memorizzano quindi l'incontro nei rispettivi registri dei contatti, oltre a un timestamp approssimativo e alla potenza del segnale. La potenza del segnale viene successivamente utilizzata come parte del processo di segnalazione delle infezioni per stimare la distanza tra un paziente infetto e l'utente.

Segnalazione dell'infezione

Quando si segnala un'infezione, questa viene inviata ad un server di report centrale controllato dall'autorità sanitaria locale. Prima che un utente possa inviare un rapporto, l'autorità sanitaria deve prima confermare l'infezione e generare un codice che autorizzi il client a caricare il rapporto. L'autorità sanitaria informa inoltre il paziente sul giorno da cui far iniziare il report da inviare (indicato come $t$). Il client carica quindi la coppia $SK_{t}$ e $t$ al server di report centrale, e altri client della rete scaricheranno in un secondo momento tale report. Utilizzando lo stesso algoritmo utilizzato per generare gli EphID originali, i client possono riprodurre tutti gli EphID utilizzati nel periodo passato a partire dal giorno $t$. In questo modo possono confrontare il report con il registro dei contatti locali per determinare se l'utente è stato nelle immediate vicinanze di un paziente infetto.

Nell'intero protocollo, l'autorità sanitaria non ha mai accesso ai registri dei contatti e serve solo per diagnosticare l'infezione ai pazienti e autorizzare l'invio dei report da parte dei pazienti infetti.

Analisi epidemiologica

Quando un utente installa un'app compatibile con il protocollo DP-3T, gli viene chiesto se desidera optare per la condivisione dei dati con gli epidemiologi . Se l'utente acconsente, nel momento in cui viene confermato che è stato in stretto contatto con un paziente infetto, la rispettiva voce del registro contatti contenente l'incontro viene inviata a un server centrale per analisi statistiche. Al fine di impedire a terzi di rilevare potenziali infezioni rilevando tali caricamenti, i rapporti vengono inviati a intervalli regolari insieme con rapporti fittizi, indistinguibili da quelli originali, che vengono inviati anche quando non ci sono dati da trasmettere.

Interoperazione tra le autorità sanitarie

Per facilitare la compatibilità tra le app DP-3T gestite da autorità sanitarie separate, le app mantengono un elenco locale delle regioni visitate da un utente. Le regioni sono ampie aree direttamente corrispondenti alla giurisdizione dell'autorità sanitaria; la posizione esatta non viene registrata. L'app client si connetterà successivamente server di report centrali anche di queste regioni e recupererà i report dai loro server oltre che dal server di report centrale della propria regione. Inoltre l'app client invierà il report anche a questi server nel caso in cui l'utente risultasse infetto.

Attacchi a DP-3T e critiche

L'esperto di crittografia e sicurezza Serge Vaudenay, analizzando la sicurezza di DP-3T ha sostenuto che alcune misure di protezione dei dati personali introdotte in DP-3T potrebbero avere un effetto opposto a quello desiderato; in particolare le persone infette e coloro che sono entrati in contatto con tali persone potrebbero essere de-anonimizzati.

Il lavoro di Vaudenay presenta numerosi attacchi contro DP-3T e sistemi simili. In risposta, il gruppo DP-3T afferma che su dodici rischi che Vaudenay presenta, otto sono anche presenti in sistemi centralizzati, tre non funzionano e uno, che comporta l'accesso fisico al telefono, funziona ma può essere mitigato. In un lavoro successivo di Vaudenay esamina gli attacchi contro sistemi di tracciamento sia centralizzati che decentralizzati e riferendosi ad attacchi contro le persone infette conclude che comparando architetture centralizzate e decentralizzate si può osservare che gli attacchi ad architetture decentralizzate non sono riconoscibili, possono essere attuati su larga scala e che le contromisure proposte al più riescono a mitigare i danni solo in un numero limitato di possibili scenari. Al contrario i sistemi centralizzati possono offrire un numero maggiore di contromisure.

Nello stesso lavoro Vaudenay sostiene che, poiché né gli approcci centralizzati né quelli decentralizzati offrono un livello sufficiente di protezione della privacy, dovrebbero essere esplorate soluzioni differenti, in particolare suggerendo ConTra Corona, Epione e Pronto-C2 come possibili alternative.

Tang ha esaminato i principali sistemi di tracciamento dei contatti e ha mostrato che DP-3T è soggetto a quelli che chiama "attacchi di identificazione mirati".

Attacchi teorici su DP-3T sono stati simulati, dimostrando che sulla prima versione del sistema DP-3T una terza parte può eseguire in maniera permanente e molto semplice il tracciamento degli utenti che hanno caricato volontariamente i loro identificatori sfruttando una grande flotta di dispositivi Bluetooth Low Energy.

Voci correlate

• BlueTrace
• Protocollo TCN
• Traccia di prossimità paneuropea per il rispetto della privacy
• Progetto di tracciamento dei contatti di Google / Apple