Vista la criticità dei dati trattati e la potenziale universalità dei servizi di contact tracing digitale per gestire al meglio la fase di post-lockdown, assume particolare rilevanza l’analisi di eventuali minacce all’integrità delle soluzioni e alla confidenzialità dei dati.
Partiamo dall’analisi dei modelli in uso e delle minacce che li rendono vulnerabili, per presentare una nostra recente proposta di ricerca – che prende il nome di ZE2-P3T ( Zero Ephemeral Exchange Privacy Preserving Proximity Tracing) – che dimostra come si possa trovare un’alternativa ai protocolli in uso, basati sullo scambio di identità fittizie tra smartphone che si trovano in prossimità (attraverso l’interfaccia BLE). Ciò infatti può essere alla base di minacce alla confidenzialità ed integrità dei protocolli.
Contact tracing: i modelli in uso
Le app per il contact tracing hanno lo scopo di identificare gli utenti che sono venuti a stretto contatto con un determinato paziente risultato successivamente positivo al virus durante un’adeguata finestra temporale di contagiosità (attualmente fissata a 14 giorni). Esse possono basarsi su un modello decentralizzato o su un modello centralizzato.
Le soluzioni decentralizzate consentono di garantire proprietà di privacy elevate. Tra queste soluzioni, il protocollo emergente e prevalente, soprattutto nell’Unione europea, è sicuramente il Decentralized Privacy-Preserving Proximity Tracing (DP-3T) [6] (anche nella sua declinazione Apple-Google) che si basa su pseudonimi effimeri (chiamati Ephemeral ID) inviati tramite Bluetooth Low Energy (BLE) e registrati dagli utenti in prossimità. L’idea di base è installare un’app su ogni smartphone che utilizza il BLE per interagire con altri smartphone vicini per acquisire gli Ephemeral ID dei vicini. Ogni smartphone, quindi, conserva in memoria tutti gli Ephemeral ID “raccolti” durante gli ultimi 14 giorni.
Se un utente risulta positivo al COVID-19, sulla base di un processo di autorizzazione avviato dell’autorità sanitaria, può uploadare presso il server le informazioni anonime che lo individuano nella finestra temporale di contagiosità. Grazie a queste informazioni, e i meccanismi di condivisione che il server mette in atto con la comunità di utenti che aderiscono al sistema, le app degli utenti che sono entrati in contatto con il positivo nei precedenti 14 giorni rilevano la presenza dei suoi Ephemeral ID, e allertano i rispettivi utenti.
Il modello DP-3T offre due design, uno detto Low cost, l’altro chiamato Unlinkable. In sintesi, la differenza di rilievo tra i due è che gli Ephemeral della modalità unilikable non sono collegabili tra loro, riducendo quindi il potenziale rischio di ricostruzione del comportamento degli utenti nel caso di deanonimizzazione di uno solo degli Ephemeral. Sempre decentralizzata e, nella sostanza, assimilabile a DP-3T, è la soluzione proposta congiuntamente da Google e Apple [1] che, inoltre, prevede un sistema di notifiche di esposizione in cui gli pseudonimi e le chiavi generatrici vengono prodotte e gestite all’interno del Sistema Operativo, e quindi in maniera protetta.
Altre soluzioni optano per un approccio centralizzato come NTK [5] e ROBERT [4] che sono stati sviluppati all’interno del Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT). Proprio come DP-3T, NTK e ROBERT si basano sullo scambio di Ephemeral inviati tramite BLE che sono registrati dagli utenti vicini, con la differenza che le chiavi segrete per il calcolo degli EphID sono create e gestite da un server back-end e non dal telefono dell’utente.
Minacce alla privacy e all’integrità delle soluzioni di contact tracing decentralizzate
È d’obbligo tuttavia fare una premessa. Sebbene, come vedremo, il protocollo DP-3T presenta, in linea di principio, alcune debolezze sia dal punto di vista della privacy degli utenti sia dal punto di vista dell’integrità, lo stesso protocollo o versioni simili, quali quello disegnato da Apple-Google, si possono tradurre in implementazioni pratiche, quali l’app Immuni adottata in Italia, che garantiscono comunque un livello adeguato di affidabilità e sicurezza, essendo le minacce esistenti difficilmente appetibili per un attaccante.
Tuttavia, ciò non deve scoraggiare la ricerca scientifica dal cercare approcci più robusti che non presentano le debolezze sopra menzionate. Questo articolo, che riassume quanto descritto in dettaglio nel lavoro scientifico [3], si colloca pertanto all’interno di questa linea di ricerca, proponendo un’alternativa agli approcci decentralizzati.
Partiamo dall’analisi delle minacce alla privacy e all’integrità nel protocollo DP-3T, elencando un insieme di possibili attacchi, rilevati in [3; 2].
Attacco “Paparazzi”: L’obiettivo è quello di tracciare gli utenti infetti. L’attaccante dispone dispositivi Bluetooth passivi in diversi luoghi (pubblici o privati) che catturano tutti gli Ephemeral rilasciati dagli smartphone degli utenti. A questi Ephemeral vengono associate altre informazioni personali, come ora e luogo in cui sono stati catturati, o la foto degli utenti che li hanno rilasciati. Se uno di questi diventa infetto, i suoi Ephemeral vengono pubblicati e l’attaccante è in grado di tracciare i movimenti dell’utente infetto. Questo tipo di attacco non richiede ingenti risorse economiche in quanto i dispositivi Bluetooth hanno un costo irrisorio.
Attacco “Brutus”: Questo attacco richiede la collusione tra il server centrale, che raccoglie e distribuisce gli Ephemeral degli utenti infetti, e la struttura sanitaria che esegue i test sui soggetti. L’obiettivo è di de-anonimizzare gli Ephemeral di un utente. Le attuali soluzioni si basano su un codice autorizzativo che la struttura sanitaria comunica al server centrale per consentire agli utenti positivi di condividere i propri Ephemeral. Tale codice è generato o dall’utente o dalla struttura stessa. In ogni caso, quando un utente positivo comunica i propri Ephemeral, deve fornire anche questo codice. Sebbene questo meccanismo di autenticazione sia utile a evitare che un utente non infetto possa comunicare i propri Ephemeral creando falsi report, il server potrebbe chiedere alla struttura sanitaria a quale utente è stato rilasciato quel codice e, quindi, scoprire tutti gli Ephemeral associati a quell’utente.
Attacco “Missile”: Questa volta l’obiettivo è creare falsi contatti tra utenti. In questo caso l’attaccante è un utente potenzialmente infetto che, attraverso un amplificatore Bluetooth, trasmette i propri Ephemeral a grandi distanze, in modo che vengano catturati da altri utenti che, sebbene non siano mai entrati in contatto con l’attaccante, aggiungono i suoi Ephemeral alla propria lista dei contatti. Chiaramente, l’attacco si concretizza nel momento in cui l’attaccante scopre di essere infetto e comunica i propri Ephemeral al server che, a sua volta, li trasmette in broadcast a tutti gli utenti. Tra questi, gli utenti che hanno ricevuto gli Ephemeral dell’attaccante tramite amplificatore Bluetooth, vengono allertati inutilmente. Sebbene, a primo impatto, questo attacco può sembrare poco probabile in quanto l’attaccante deve essere un utente infetto (che comunque può rappresentare una porzione significativa degli utenti), esso diventa più efficace se combinato con l’attacco “Paparazzi” costituendo l’attacco “Fregoli”.
Attacco “Fregoli”: L’obiettivo è lo stesso dell’attacco “Missile” con la differenza che l’attaccante trasmette, con o senza l’ausilio dell’amplificatore Bluetooth, gli Ephemeral di altri utenti che possono essere catturati, ad esempio, come descritto nell’attacco “Paparazzi”. Questa volta, chiaramente, aumentano drasticamente le probabilità di trasmettere Ephemeral di utenti infetti. Ad esempio, si potrebbero piazzare i dispositivi Bluetooth passivi in prossimità delle strutture sanitarie che effettuano i test dove la probabilità di incontrare un utente infetto è molto alta.
La soluzione ZE2-P3T
Si può osservare facilmente che la maggior parte degli attacchi descritti nella sezione precedente, così come molte varianti non riportati in questo articolo per semplicità, sfruttano come vulnerabilità lo scambio di Ephemeral tra gli utenti.
Ci si può quindi porre la domanda se lo scambio degli Ephemeral tra utenti possa essere evitato. Per ottenere ciò viene subito in mente l’uso di un approccio che non determina la prossimità attraverso meccanismi basati sulla posizione relativa degli utenti, ma, indirettamente, attraverso meccanismi che forniscono la posizione assoluta. Il tracciamento basato su GPS è la tecnologia alla quale riferirsi, a tal fine. E il modello naturale, in questo caso, è certamente centralizzato. Tuttavia, la sfida da superare, affinché un sistema del genere possa essere adottato in contesti culturali e giuridici nei quali la privacy del cittadino attiene a questioni relative ai diritti fondamentali dell’individuo, è non consentire comunque il tracciamento da parte del server.
La prima ipotesi che può affacciarsi è quella di ricorrere a tecniche di crittografia omomorfica con la quale il server, a partire dalle coordinate cifrate inviate da due utenti, è in grado di calcolare la distanza tra essi operando nel dominio cifrato, e quindi non sulle coordinate in chiaro. Un approccio del genere, sfortunatamente, non sarebbe risolutivo. Il server infatti potrebbe calcolare la distanza tra le coordinate incognite inviate da un utente e le coordinate di un punto arbitrario. Una volta stabilita tale distanza, il server potrebbe scegliere un nuovo punto cercando di avvicinarsi al punto incognito. Iterando il procedimento, si potrebbe arrivare ad una buona stima della posizione. Simile considerazione vale nel caso in cui si utilizzino hash crittografici con caratteristiche omomorfiche, quali per esempio i bio-hash.
Di conseguenza, l’ipotesi che appare più adeguata è quella di utilizzare hash crittografici, confidando sulla non invertibilità di tali funzioni. Ma, evidentemente, se si facesse il digest della posizione di ogni utente, non si avrebbe modo di valutare la distanza reciproca, lato server. Pertanto, l’idea potrebbe essere quella di suddividere idealmente il territorio in microcelle e assegnare ad ogni microcella una posizione che la caratterizza, in modo da rilevare l’appartenenza alla stessa microcella attraverso la corrispondenza tra i digest inviati.
Anche in questo caso, però, il server potrebbe tracciare gli individui, perché il numero di possibili microcelle non sarebbe tanto grande da non consentire un dictionary-based attack, permettendo quindi al server di invertire la funziona hash.
La nostra soluzione supera il problema dei dictionary-based attack, attraverso l’adozione della tecnica del salt. Il salt è un valore random che è “aggiunto” alla posizione prima di calcolarne il digest. In tal modo l’esplorazione del dominio diventa infeasible. Ma chi fornisce il salt a tutti gli utenti che stanno nella stessa microcella? Se il salt non fosse lo stesso non sarebbe possibile rilevare la presenza contemporanea degli utenti. L’idea adottata nella nostra soluzione è che il salt è fornito dal gestore telefonico, in tutta l’area di copertura della cella telefonica (che racchiude diverse microcelle).
Vediamo più in dettaglio come opera la nostra soluzione. Essa prende il nome di ZE2-P3T, che è un acronimo di Zero Ephemeral Exchange Privacy Preserving Proximity Tracing [3].
Il territorio nazionale è idealmente suddiviso in microcelle, ognuna delle quali ha associato un punto chiamato centroide corrispondente al centro della microcella stessa. Ogni utente che si trova all’interno di una microcella recupera, attraverso il GPS, le coordinate del centroide e la sua posizione relativa rispetto ad esso. Inoltre, l’utente riceve dal gestore telefonico il salt. Infine, come in DP-3T, l’utente periodicamente genera un random che rappresenta uno pseudonimo che lo identifica all’interno del sistema.
Un aspetto su cui abbiamo posto la nostra attenzione riguarda l’accuratezza delle coordinate rilevate tramite GPS che potrebbe non essere sufficiente in questo contesto applicativo. Pertanto, ZE2-P3T richiede l’utilizzo del Bluetooth per migliorare l’accuratezza delle coordinate relative, attraverso un protocollo chiamato NPN. In sintesi, gli utenti che entrano nel raggio di azione del Bluetooth si scambiano le loro coordinate relative rilevate tramite GPS e calcolano la loro distanza misurando l’intensità della potenza del segnale Bluetooth. Sfruttando questa distanza, che rappresenta una stima più precisa rispetto a quella calcolata con il GPS, viene apportata una correzione delle coordinate relative. É importante sottolineare che, usando NPN, l’utente scambia, attraverso Bluetooth, solo le coordinate relative e nessun identificatore. Pertanto, gli attacchi sopra citati non possono essere eseguiti.
A questo punto, l’utente trasmette al server: il suo random corrente, le coordinate relative in chiaro e l’hash del centroide concatenato con il salt. In questo modo, quando due utenti sono nella stessa microcella, essi trasmettono lo stesso digest (perché calcolato a partire dallo stesso centroide e con lo stesso salt) e il server è in grado di creare un collegamento tra i loro random senza avere alcuna informazione, neppure approssimata, circa la loro posizione. Inoltre, grazie alle coordinate relative, il server è in grado di calcolare la distanza tra essi e determinare il livello di rischio (sfruttando anche delle informazioni riguardo il tempo di contatto degli utenti).
Quando un utente scopre di essere infetto, può fare l’upload dei propri random presso il server, previo un opportuno meccanismo di autenticazione. Il server, attraverso questi random e le informazioni di contatto inviate precedentemente dagli utenti, cerca i random di tutti gli utenti entrati in contatto con l’utente infetto e li inserisce in una lista. Questa lista è mandata in broadcast all’intera rete e ogni utente può verificare se i propri random sono contenuti al suo interno.
Per contrastare l’attacco Brutus, introduciamo un meccanismo di autenticazione tra server e utente che sfrutta la firma blind. L’idea è che un utente risultato positivo invia un’informazione firmata digitalmente dalla struttura sanitaria che ha fatto il test senza che quest’ultima conosca effettivamente ciò che ha firmato. In questo modo il server può autenticare l’utente consentendogli di fare l’upload dei propri random, ma non è in grado di linkare i suoi random alla sua identità, anche in caso di collusione con la struttura sanitaria.
Conclusioni
Il digital contact tracing può rappresentare un valido supporto alle diverse strategie messe in atto dai governi al fine di contenere e contrastare la pandemia di COVID-19 che sta affliggendo il mondo.
La proposta che abbiamo descritto sfrutta le informazioni di geolocalizzazione ottenute attraverso il GPS e migliorate attraverso BLE. Tuttavia, diversamente da quanto possa intuitivamente apparire come una necessaria conseguenza, il server non apprende alcuna informazione circa la posizione degli utenti e le minacce alla privacy e alla integrità sono mitigate rispetto ai protocolli decentralizzati attualmente in uso.
Un vantaggio significativo, su cui stiamo lavorando per una sua completa declinazione, è che, grazie alla geolocalizzazione, è possibile identificare anche i casi di contagio indiretto (e cioè verificatisi attraverso il contatto con oggetti comuni), che, in accordo alle attuali conoscenze mediche nel settore, possono giocare un ruolo non trascurabile nella trasmissione dell’infezione.
___________________________________________________________________________
[1] Apple and Google, “Apple and google’s exposure notification system,” 2020. [Online]. Available: https: // www.apple. com/ covid 19/ contacttracing.
[2] G. Avitabile, V. Botta, V. Iovino, and I. Visconti, “Towards defeating mass surveillance and sars-cov-2: The pronto-c2 fully decentralized automatic contact tracing system,” Cryptology ePrint Archive, Report 2020/493, 2020. https://eprint. Iacr.org, Tech. Rep., 2020.
[3]Buccafurri, V. De Angelis, and C. Labrini, “A Privacy-Preserving Solution for Proximity Tracing Avoiding Identifier Exchanging,” Proceedings of the International Conference CYBERWORLDS 2020, 29 September, 1 October 2020, Caen (France), IEEE Computer Society, to appear.
[4] C. Castelluccia, N. Bielova, A. Boutet, M. Cunche, C. Lauradoux, D. Le M´etayer, and V. Roca, “Robert: Robust and privacy-preserving proximity tracing,” 2020.
[5] P.-P. Team, “Pan-european privacy-preserving proximity tracing need-to-know system. overview of pepp-pt ntk,” 2020.
[6] C. Troncoso, M. Payer, J. Hubaux, M. Salath´e, J. Larus, E. Bugnion, W. Lueks, T. Stadler, A. Pyrgelis, D. Antonioli et al., “Decentralized privacy-preserving proximity tracing. apr. 12, 2020. url: https://github. com/dp- 3t/documents/raw/master,” DP3T White Paper.pdf.
