Nelle scorse settimane si è sviluppato a livello internazionale—ma soprattutto europeo—un dibattito piuttosto appassionante incentrato sul grado di tutela della privacy nelle diverse app di contact tracing proposte. Tutto questo mentre, com’è noto, l’Italia procede per il lancio della propria app, Immuni, per fine maggio.
Molti si sono chiesti, in particolare, quale sia il protocollo più sicuro tra quelli avanzati. Purtroppo, questo dibattito ha assunto in molti casi una connotazione politica, relegando in secondo piano il lato tecnico e una valutazione oggettiva di vantaggi e rischi per le diverse soluzioni. La conversazione ha inoltre raggiunto toni piuttosto accesi, seminando ancora più confusione e panico in una situazione già estremamente complessa e tesa.
Proviamo allora a chiarire quali rischi per la privacy comportano concretamente i diversi protocolli per il contact tracing proposti, partendo da una panoramica su quali sono i protocolli principali e come funzionano.
Prima di iniziare, una precisazione: come indicato nel titolo, questo articolo analizza i protocolli di contact tracing dalla prospettiva della tutela della privacy. La scelta del protocollo più adatto dipende ovviamente da molti altri fattori, in primo luogo l’efficacia per il contenimento del contagio. Questo aspetto non rientra nelle mie competenze, quindi non verrà esaminato nell’articolo.
La lotta dei modelli o protocolli
Nelle scorse settimane sono stati presentati in tutto il mondo svariati protocolli e app per il contact tracing. La maggior parte di questi protocolli prevede che un utente scarichi e installi un’app sul proprio smartphone. La app si connette poi periodicamente a un server gestito da un’autorità centrale, con cui scambia alcuni dati. Nel caso italiano, verosimilmente, l’autorità centrale incaricata potrebbe essere il Servizio Sanitario Nazionale o il Ministero della Salute.
I governi europei stanno valutando l’utilizzo principalmente di tre protocolli:
- ROBERT: Questo protocollo è stato sviluppato dall’istituto di ricerca francese Inria e rappresenta essenzialmente la proposta ufficiale del consorzio PEPP-PT, a cui si conformava anche Immuni. Basandoci sui documenti forniti dagli sviluppatori di Immuni, Bending Spoon, al ministero dell’innovazione ci si voleva inizialmente adottare un protocollo molto simile a ROBERT (solo un po’ più di decentralizzazione dei dati di tracking). Questo protocollo viene spesso chiamato centralizzato, perché l’autorità centrale processa più dati e gestisce il processo di notifica degli utenti a rischio.
- DP-3T: Questo protocollo è stato inizialmente sviluppato da un gruppo di ricercatori dell’EPFL di Losanna, ma il team si è rapidamente esteso a ricercatori di altri istituti e università europee. Il team sta sviluppando un’app open source, attualmente in fase di test e liberamente scaricabile. Questo protocollo viene spesso definito decentralizzato, in quanto il server centrale ottiene una quantità molto limitata di dati.
- Protocollo di Apple e Google: Mentre ROBERT e DP-3T sono di fatto dei prototipi di app, il protocollo di Apple e Google consiste invece in un insieme di API (Application Programming Interface), ovvero un insieme di nuove funzionalità per iOS e Android che verranno messe a disposizione degli sviluppatori di app di contact tracing. Per poter sfruttare queste funzionalità, le app sono vincolate a seguire un determinato protocollo proposto da Apple e Google, obbligo che rende di fatto complicato sviluppare un’app che segua un protocollo diverso. Questo protocollo è decentralizzato, come il protocollo DP-3T (a cui si è ispirato). Poiché la versione attuale sembra orientarsi su un modello molto simile al protocollo di DP-3T, nel resto di questo articolo mi concentrerò principalmente su quest’ultimo come modello decentralizzato di riferimento. Quasi tutte le considerazioni più rilevanti su DP-3T valgono anche per il protocollo di Apple e Google, stando ai documenti finora presentati. Secondo quanto emerso alla stampa, l’app Immuni ha deciso di adottare un protocollo simile a DP-3T e basato sulle API di Apple e Google. Non è ancora certo però se ci saranno alcune personalizzazioni in ottica di una maggiore centralizzazione.
Il dibattito sulla sicurezza di questi tre protocolli ha spinto diversi governi—tra cui quello austriaco e quello tedesco—a rivedere i piani originari, passando da una soluzione centralizzata a una decentralizzata. Al momento, l’eccezione principale è il Regno Unito, dove lunedì scorso il governo ha annunciato che adotterà un modello centralizzato, attirando molte critiche.
Ma di cosa si sta parlando davvero? Perché il modello centralizzato viene ritenuto più pericoloso da molti esperti di privacy? E ancora: il modello decentralizzato è in grado di proteggere completamente la privacy degli utenti? Iniziamo a dare qualche risposta, affidandoci ai dati già disponibili.
Privacy e contact tracing: una relazione complicata
Stabilire il grado di protezione della privacy nelle app di contact tracing richiede competenze molto tecniche, e non vige un accordo unanime nemmeno tra gli addetti ai lavori. In ogni fase dell’utilizzo di tali app sono coinvolti diversi attori, tra cui: l’utente che utilizza l’app, i contatti nelle vicinanze, l’autorità centrale, il gestore della rete a cui è connesso il dispositivo.
Ipoteticamente, dal punto di vista tecnico tutti questi attori potrebbero agire in modo malevolo, ovvero cercare di compromettere la privacy o la sicurezza dell’utente (o altri requisiti, come l’integrità dei dati raccolti). In gergo tecnico, l’insieme degli attori, delle vulnerabilità e dei rischi finali che caratterizzano un certo scenario di compromissione del protocollo prendono il nome di threat model. Gli attori che agiscono in modo malevolo vengono chiamati avversari e ogni threat model prefigura degli attacchi che questi avversari potrebbero tentare di attuare.
Assieme ad alcuni colleghi del mio gruppo di ricerca—il Computational Privacy Group dell’Imperial College di Londra—ho scritto un articolo per spiegare anche ai non esperti questi threat model e attacchi. L’articolo vuole fornire anche ai meno esperti gli strumenti per comprendere meglio quali sono i rischi concreti di un’app di contact tracing, andando oltre le vaghe rassicurazioni sul rispetto della privacy provenienti da chi propone l’app. L’articolo contiene 8 domande a cui chiunque sviluppi un’app di contact tracing dovrebbe essere in grado di rispondere. Nel resto della mia analisi prenderò spunto da queste domande per discutere più nel dettaglio i principali rischi per la privacy che riguardano i protocolli ROBERT e DP-3T.
Come funzionano i protocolli: ROBERT e DP-3T a confronto
Per comprendere davvero i rischi di questi due protocolli, è necessario richiamare alcuni dettagli tecnici sul loro funzionamento. Nonostante ROBERT e DP-3T siano piuttosto complessi, i dettagli necessari per discuterne i rischi sono relativamente semplici. Quella che segue è una descrizione semplificata, ma sufficientemente fedele, dei due protocolli.
- In entrambi i protocolli, tutti gli utenti trasmettono dei codici numerici ai dispositivi circostanti tramite Bluetooth. Allo stesso tempo, il dispositivo di ciascun utente osserva e conserva i codici numerici trasmessi dagli altri utenti.
- Questi codici numerici dovrebbero essere anonimi, nel senso che la sequenza numerica non dovrebbe rivelare direttamente l’identità di chi la ha trasmessa. Tuttavia, il concetto di dato anonimo è molto delicato. Come vedremo a breve, anche i dati anonimi possono spesso essere de-anonimizzati, qualora si verifichino determinate condizioni.
- I codici vengono rinnovati di frequente. Ciò offre una prima protezione per la privacy. Se, al contrario, ogni dispositivo trasmettesse sempre lo stesso codice, sarebbe facile reidentificarlo, ovvero risalire all’identità del proprietario. Ad esempio, se ogni volta che vado dal mio panettiere il mio dispositivo osserva il codice numerico 129874728, è probabile che quel codice appartenga al mio panettiere. Per evitare questo rischio, entrambi i protocolli prevedono che ogni dispositivo aggiorni spesso il codice numerico trasmesso ai dispositivi circostanti. L’aggiornamento dovrebbe avvenire circa ogni 15 minuti, ma la frequenza è stabilita dall’autorità centrale. Per questo, si parla di codici temporanei.
- La prima importante differenza tra ROBERT e DP-3T risiede nel diverso soggetto che genera i codici temporanei, il chi.
- In ROBERT, i codici temporanei vengono generati e assegnati dall’autorità centrale che gestisce il server. Questo significa che l’autorità centrale sa se due o più codici temporanei appartengono allo stesso utente. Ciò rende di fatto gli utenti pseudonimi rispetto all’autorità che gestisce il server. Ovvero, l’utente è associato a un singolo codice identificativo (lo pseudonimo), che resta invariato.
- In DP-3T, i codici temporanei vengono generati direttamente sul dispositivo dell’utente. Questo significa che nessuno, tranne l’utente stesso, può capire facilmente se due codici temporanei sono stati trasmessi dallo stesso dispositivo. Nemmeno l’autorità centrale. Discuterò meglio i dettagli e i limiti di questo aspetto nell’analisi dei rischi di DP-3T.
- La seconda importante differenza consiste nei dati che vengono inviati dagli utenti al server centrale, il cosa.
- In ROBERT, quando un utente viene diagnosticato positivo al Covid-19, può inviare al server la lista di tutti i codici numerici che il suo dispositivo ha osservato dai contatti circostanti nel periodo in cui l’operatore sanitario ritiene potesse avere già contratto il virus. Il server mantiene una lista di tutti questi codici, che chiamiamo exposed_users.
- In DP-3T, ogni utente trovato positivo può inviare al server solo la lista dei propri codici temporanei che ha trasmesso agli altri dispositivi nel periodo in cui l’operatore sanitario ritiene fosse contagioso. Il server mantiene una lista di tutti questi codici, che chiamiamo infected_users.
- La terza importante differenza è il modo in cui vengono avvisati gli utenti entrati in contatto con persone infette, il come.
- In ROBERT, ogni utente si connette periodicamente al server con un proprio codice identificativo. Il server può quindi verificare se l’utente è presente nella lista exposed_users. In tal caso, l’utente verrà avvisato di essere a rischio.
- In DP-3T, ogni utente si connette periodicamente al server, ma senza inviare alcun dato. Al contrario, è il server che rivela all’utente l’intera lista infected_users (rappresentata in un formato particolare). A quel punto, il dispositivo dell’utente può verificare, in segreto (ovvero, senza inviare nessun dato), se tale lista contiene uno dei codici che ha osservato precedentemente. Se ne contiene, significa che l’utente è stato in prossimità di una persona infetta, e quindi l’app avvisa l’utente di essere a rischio.
- Nota: in realtà, per decidere se avvertire l’utente che è entrato in contatto con individui infetti, entrambi i protocolli usano un sistema più sofisticato per calcolare un coefficiente di rischio. Dettagli del genere sono stati trascurati nella mia analisi, in quanto eccessivamente tecnici o secondari al fine di stabilire l’entità dei rischi per la privacy comportati dai protocolli esaminati.
Analisi dei rischi nel modello centralizzato (ROBERT)
Un’analisi completa dei rischi che presentano entrambi i protocolli richiederebbe molto spazio e l’utilizzo di un gergo tecnico. Per i lettori che volessero approfondire, l’analisi più esaustiva di questi rischi è probabilmente quella pubblicata dal team di DP-3T. In questo articolo mi limito a descrivere quelli che io ritengo essere i rischi principali dei due protocolli.
Innanzitutto, va detto che nessuno dei due protocolli è un sistema sviluppato appositamente per la violazione della privacy e la sorveglianza di massa. Entrambi i modelli si sforzano di trovare un tradeoff accettabile tra privacy ed efficacia dell’app per il contact tracing. In particolare, come abbiamo visto, entrambi i sistemi cercano genuinamente di preservare l’anonimato degli utenti, usando dei codici teoricamente anonimi. Ma chi si occupa di privacy engineering e computer security è consapevole che l’anonimato è molto difficile da preservare in pratica. Le domande da porci a questo punto sono due:
- È possibile de-anonimizzare i codici “anonimi”, e quindi reidentificare gli utenti?
- Una volta reidentificati gli utenti, quali violazioni della privacy diventano possibili?
Risponderò a queste domande prima per ROBERT e poi per DP-3T.
Attacchi di reidentificazione
La caratteristica più problematica per la privacy nel protocollo ROBERT sta nel fatto che l’autorità centrale è sempre in grado di sapere se due o più codici temporanei appartengono allo stesso utente. In altre parole, gli utenti sono pseudonimi rispetto all’autorità che gestisce il server. Questo è l’origine di tutte le vulnerabilità più serie, in quanto la pseudonimizzazione è una difesa molto fragile per l’anonimato. In particolare, l’autorità centrale può sfruttare questa proprietà per risalire all’identità dell’utente a cui appartengono i codici temporanei. Questi attacchi di reidentificazione possono essere attuati principalmente in tre modi.
Il primo metodo sfrutta l’analisi dei codici identificativi di rete che vengono trasmessi da qualsiasi dispositivo connesso ad internet, come ad esempio l’indirizzo IP. L’autorità potrebbe infatti tentare di ottenere dagli operatori telefonici le identità degli intestatari associati agli indirizzi IP, collegandoli quindi ai codici pseudonimi dell’app. In pratica, i codici identificativi di rete non identificano sempre con esattezza una singola persona. La connessione WiFi di un’abitazione, ad esempio, espone un solo indirizzo IP ma può essere utilizzata da diversi inquilini. Tuttavia, se combinati con altre informazioni (vedi sotto), i codici identificativi di rete possono giocare un ruolo importante in un attacco di reidentificazione a più fasi.
Il secondo metodo prevede la reidentificazione del grafo sociale, ovvero degli individui visti come punti in una struttura connessa da archi che riflettono i contatti avuti. In ROBERT, il server centrale riceve tutti i codici identificativi dei contatti degli infetti (e l’ora in cui il contatto è avvenuto). Nel lungo termine, questo permette al server di ricostruire un grafo che include una buona parte degli utenti e rivela quali sono i loro contatti. In teoria, gli utenti sono anonimi. In pratica, nella letteratura sono stati proposti numerosi attacchi che mostrano come sia possibile, in alcuni casi, reidentificare gli utenti in un grafo sociale utilizzando delle informazioni ausiliari. L’informazione ausiliaria potrebbe includere, ad esempio, un altro grafo sociale per il quale si conoscono le identità, come i social network (Facebook, Instagram, etc.) o il grafo sociale generato automaticamente ogni volta che chiamiamo o mandiamo un SMS a qualcuno usando il nostro numero di telefono (queste attività vengono registrate dagli operatori telefonici e conservate a lungo nei loro database).
La praticabilità di questo attacco dipende principalmente proprio dal tipo e dalla quantità di informazione ausiliaria disponibile all’avversario (in questo caso, all’autorità centrale). Inoltre, ROBERT prevede alcuni sistemi per mitigare questo rischio, ma l’analisi proposta dal team DP-3T rivela come questi accorgimenti siano poco robusti, potenzialmente eludibili e, nel complesso, non del tutto convincenti.
Il terzo metodo richiede più sforzo, ma è estremamente più efficace. Supponiamo che l’autorità centrale costruisca una rete di sensori Bluetooth in una città, o abbia accesso a una già esistente. Questo permetterebbe all’autorità di tracciare gli spostamenti degli utenti (ricordiamo che in ROBERT l’autorità sa associare tutti i diversi codici temporanei allo stesso utente). Una volta che gli spostamenti degli utenti vengono tracciati, è molto facile de-anonimizzarli. Questo perché la cronologia degli spostamenti di ogni individuo è quasi sempre unica tra la popolazione (che due individui si spostino nel tempo e nello spazio in maniera identica è pressoché impossibile), e quindi facilmente reidentificabile. In un articolo pubblicato nel 2013 dal mio gruppo di ricerca, si è dimostrato che 4 punti (definiti da luogo e ora) visitati da una persona possono bastare per reidentificare il soggetto in maniera univoca nel 95% dei casi. Se attuato, questo metodo avrebbe quindi un livello di accuratezza quasi perfetto.
Ma quanto è facile attuare un attacco del genere? Dal punto di vista tecnico, installare una rete di sensori è un’operazione estremamente semplice ed economica per un attore sufficientemente potente. Inoltre, in alcune aree le infrastrutture per collezionare questo tipo di dati sono già abbastanza diffuse. Ad esempio, Transport for London—l’azienda che gestisce i trasporti pubblici a Londra—ha da tempo avviato un programma per raccogliere alcuni dati sugli spostamenti dei viaggiatori tramite sensori WiFi installati in tutta la rete metropolitana. Questo programma ha attirato molte critiche proprio per i rischi che costituirebbe per la privacy. Da un punto di vista tecnico, sarebbe semplicissimo aggiungere dei sensori Bluetooth a quelli per il Wifi già introdotti. Inoltre, l’autorità potrebbe facilmente incrociare i dati Bluetooth con quelli degli abbonamenti nominativi usati nelle metro. In quel caso la reidentificazione sarebbe quasi immediata.
Violazioni della privacy: tracciamento dei contatti e degli spostamenti
Abbiamo visto come i codici temporanei usati dagli utenti in ROBERT potrebbero essere reidentificati dall’autorità centrale, se sufficientemente determinata e provvista di risorse. Ora possiamo chiederci: cosa può scoprire l’autorità centrale sugli utenti, una volta reidentificati?
In primo luogo, l’autorità centrale può immediatamente scoprire l’identità degli utenti entrati in contatto con individui positivi. Questa informazione potrebbe essere considerata come dato sensibile da alcuni, in particolare se dovesse portare a misure di contenimento forzato per questi utenti.
In secondo luogo, una volta reidentificato il grafo sociale, l’autorità può ricostruire chi ha incontrato chi e quando è avvenuto l’incontro. Questo scenario potrebbe tradursi in conseguenze particolarmente preoccupanti. Ad esempio, nel caso di una fonte anonima che incontra un giornalista per rivelare episodi di corruzione. Inoltre, se da un lato è vero che in ROBERT solo gli utenti infetti condividono i contatti che hanno osservato, dall’altro questo offre una protezione solo parziale, perché questi dati includono informazioni sugli individui circostanti. Un paper pubblicato nel 2018 dal mio gruppo di ricerca ha dimostrato che in una città densamente popolata come Londra i dati trasmessi anche solo dall’1% della popolazione sarebbero sufficienti ad osservare i contatti del 56% degli utenti presenti in quella città.
In terzo luogo, gli utenti reidentificati sono vulnerabili al tracciamento dei loro spostamenti e al rilevamento della loro presenza per tutto il tempo di utilizzo dell’app. Ad esempio, l’autorità potrebbe installare dei sensori Bluetooth nelle vicinanze della sede di un partito politico di opposizione, o di una ONG, per tracciare le persone che le visitano. Oppure, l’autorità potrebbe dotare le forze dell’ordine di sensori Bluetooth (basterebbe un’app apposita per un normale smartphone), per poi trasmettere agli agenti di polizia una lista di codici identificativi di individui considerati “dissidenti”. Questo consentirebbe agli agenti di rilevare immediatamente la presenza e anche l’identità di questi individui senza il bisogno di chiedere i documenti, ma semplicemente osservando quali codici vengono trasmessi dalle persone circostanti e confrontandoli con la lista dove sarebbero indicati i soggetti “dissidenti”. Un esempio pratico: un giornalista che tentasse di avvicinarsi a un membro del governo per porre delle domande ritenute scomode, potrebbe venire immediatamente rilevato, identificato e quindi allontanato dalla scorta.
OK, ma succede davvero?
Ci si potrebbe chiedere se queste considerazioni non scaturiscano da timori eccessivi. Tutto sommato, le forze di polizia possono già accedere ai nostri dati, no? Rispondere esaustivamente a questa domanda richiederebbe un articolo a sé. Qui mi limito solo a qualche considerazione fondamentale.
Innanzitutto, l’aspetto importante dei rischi che ho descritto non è tanto il fatto che una persona possa essere messa sotto sorveglianza. Questo è sempre potenzialmente possibile attraverso, ad esempio, i mandati di perquisizione. Il problema è che la tecnologia può permettere questa violazione della privacy su larga scala, in modo essenzialmente automatico e perlopiù impercettibile per i cittadini. Di fatto, si verificherebbero le condizioni per operare una sorveglianza di massa.
Inoltre, lo sviluppo e l’adozione su larga scala di una nuova tecnologia potenzialmente rischiosa si inserirebbe in un processo ben noto agli esperti di privacy, ovvero quello dell’erosione graduale. Questo concetto viene riassunto perfettamente da Daniel Solove: “Quasi mai la privacy si perde in un colpo solo. Solitamente viene erosa nel tempo. Piccoli frammenti si dissolvono in modo quasi impercettibile, e solo alla fine ci accorgiamo di quanta ne abbiamo persa”.
È opportuno aggiungere un’altra considerazione: i governi cambiano, le infrastrutture restano. Ora possiamo e dobbiamo decidere quali siano le infrastrutture e le tecnologie più sicure e future-proof. Non possiamo decidere né sapere ora come le utilizzeranno i governi futuri. Di conseguenza, agire con cautela è la scelta più lungimirante.
Infine, tornando all’attualità, è interessante notare che alcuni governi sembrano aver già dichiarato, più o meno apertamente, l’intenzione di reidentificare gli utenti o comunque usare i dati delle app di contact tracing a fini di sorveglianza. Ad esempio, il Guardian ha avuto accesso a un documento riservato del governo inglese che discute la possibilità di “permettere la de-anonimizzazione degli utenti” nell’app di contact tracing promossa dalle autorità. Inoltre, il governo inglese (e non solo) sembra stia da tempo cercando di convincere Apple e Google a rivedere i loro piani, in quanto il protocollo proposto dalle due aziende sarebbe troppo “limitante”. Apple e Google si sono mostrate poco disponibili ad assecondare queste richieste perché, a loro avviso, risulterebbero in protezioni della privacy più deboli rispetto alla loro proposta. In ogni caso, ora sembra che il governo inglese abbia trovato dei modi per aggirare le limitazioni tecniche imposte da Apple e Google e adottare un modello centralizzato.
Data breach e sicurezza nazionale
Un’altra osservazione importante riguarda la possibilità che si verifichi un data breach, ovvero un accesso non autorizzato ai dati archiviati sul server dell’autorità. Anche supponendo che l’autorità centrale sia completamente affidabile e priva di cattive intenzioni, l’accumulo di grandi quantità di dati in un database centralizzato rappresenta comunque una seria minaccia per la sicurezza individuale e nazionale. Ad esempio, se un gruppo di hacker dovesse riuscire ad accedere a questo database, otterrebbe di fatto dei poteri di sorveglianza simili a quelli dell’autorità centrale, ma non sottoposto alla supervisione delle istituzioni statali preposte a tale scopo, come il Garante per la privacy e la magistratura. Uno scenario che si farebbe ancora più preoccupante, se il gruppo hacker fosse al soldo di un governo straniero ostile.
DP-3T: ottimo, ma non perfetto: i rischi
Come ho spiegato sopra, in DP-3T l’autorità non può sapere a priori se due codici temporanei appartengono allo stesso utente. Essenzialmente, in DP-3T i dispositivi rinnovano davvero la propria identità ogni 15 minuti. Inoltre, gli utenti infetti rivelano all’autorità solo i propri codici temporanei, non quelli dei contatti che hanno osservato. Queste due differenze rendono DP-3T estremamente più sicuro rispetto ai rischi di ROBERT descritti sopra. In particolare, qualsiasi attacco di reidentificazione diventa notevolmente più complicato, se non impossibile—a meno di non ottenere accesso forzato al dispositivo dell’utente, ad esempio in caso di perquisizione. Inoltre, se anche un certo codice temporaneo venisse reidentificato, l’autorità non potrebbe ricavarne molte informazioni sensibili: il codice temporaneo può essere tracciato solo per 15 minuti. Infine, in DP-3T il server conosce esclusivamente i codici identificativi degli utenti infetti nel periodo in cui erano contagiosi. Quindi l’autorità non può ricostruire un grafo sociale.
Tutto questo significa che DP-3T è perfettamente sicuro? No, anche DP-3T è vulnerabile ad alcuni attacchi. Questi sono stati descritti in dettaglio nel documento pubblicato dallo stesso team che ha sviluppato DP-3T. Nel documento viene tuttavia anche chiarito che la maggior parte di questi attacchi colpisce in realtà la maggior parte dei protocolli di contact tracing. Vediamo allora quelli che, secondo me, sono i due attacchi principali che potrebbero verificarsi.
La prima vulnerabilità deriva dal fatto che gli utenti positivi rivelano al server tutti i codici trasmessi durante il periodo in cui si presume avessero già contratto il virus. Questo potenzialmente consente al server di associare questi codici alla stessa persona. In questo caso, l’utente diventa potenzialmente reidentificabile e tracciabile, ma solo retroattivamente e limitatamente al periodo di infezione. Per mitigare il rischio di rivelare informazioni sensibili in questo scenario, DP-3T include la possibilità per gli utenti diagnosticati infetti di rimuovere selettivamente i codici trasmessi durante determinati periodi ritenuti sensibili dall’utente, prima dell’invio dei codici al server. Questa misura potrebbe però risultare un po’ macchinosa e complicata per l’utente medio.
Il secondo rischio è peculiare, perché, diversamente da tutti gli attacchi esaminati finora, non riguarda la riservatezza dei dati rispetto all’autorità, ma piuttosto verso gli altri utenti, che in questo threat model vengono visti come potenziali avversari. Infatti, quando un utente infetto invia al server la lista dei suoi codici temporanei, il server include questi codici nella lista infected_users, la quale viene poi inviata a tutti i dispositivi che utilizzano DP-3T. Questo significa che, in alcuni casi particolari, un utente particolarmente esperto potrebbe estrarre i dati dall’app e osservare quali dei codici dei suoi contatti sono stati segnalati come infetti. Se l’utente è inoltre in grado di legare i codici all’identità di una persona, ciò rivela all’utente che quella persona è stata trovata positiva al COVID-19, un’informazione potenzialmente sensibile che potrebbe portare a recriminazioni e discriminazioni.
DP-3T (e, in modo simile, il protocollo di Apple e Google) include diversi meccanismi per rendere estremamente difficile, se non impossibile, effettuare questo attacco in modo retroattivo da parte di utenti che utilizzano l’app originale. Questi meccanismi sono molto tecnici, quindi rimando al white paper di DP-3T per i dettagli. Purtroppo, questi sistemi di protezione possono essere aggirati da un utente sufficientemente esperto e determinato che decida, in modo proattivo e premeditato, di modificare il funzionamento dell’app in modo da registrare l’ora esatta in cui avviene ogni contatto.
Ma su questo va fatta una precisazione fondamentale: qualsiasi sistema di contact tracing è essenzialmente vulnerabile a un attacco simile. Questo fatto è tecnicamente molto interessante e dimostra al tempo stesso la bellezza e la complessità del privacy engineering. I dettagli dell’attacco sono illustrati nel documento di DP-3T, ma l’idea è piuttosto semplice e si basa su quello che nella letteratura viene chiamato Sybil attack. Per eseguire un attacco simile contro un sistema centralizzato come ROBERT, l’utente malintenzionato modifica l’app in modo da simulare l’utilizzo di molti dispositivi diversi, ognuno solo per un breve intervallo di tempo (e.g. 15 minuti). Successivamente, continua a interrogare il server da tutti questi dispositivi virtuali. Se uno di questi dispositivi viene notificato di essere entrato in contatto con un utente infetto, l’utente malevolo può identificare con certezza in quale intervallo di 15 minuti è avvenuto il contatto. In particolare, se l’utente malevolo si trovava da solo con un’altra persona in quel periodo di tempo, è facile concludere che quella persona era infetta in quel momento.
Come detto, questa vulnerabilità colpisce in teoria tutti i sistemi di contact tracing. In pratica, esistono alcune strategie per mitigare i rischi, soprattutto nei protocolli centralizzati. In un modello centralizzato, il compito di “incrociare” gli utenti infetti e i loro contatti è affidato al server centrale. Questo permette all’autorità centrale di adottare misure per rendere più complicati gli abusi da parte di utenti malintenzionati che dovessero tentare di verificare se un certo codice temporaneo è stato contrassegnato come infetto (o a rischio). Purtroppo, misure di protezione davvero affidabili ed efficaci per questo scopo richiedono tipicamente che ogni utente registri la propria app usando credenziali verificabili, (ad esempio usando il numero di telefono personale), in modo da impedire l’utilizzo di più dispositivi (reali o virtuali). Purtroppo, allo stato dell’arte è molto difficile implementare un sistema di credenziali verificabili che preservi allo stesso tempo l’anonimato degli utenti. E, come abbiamo visto, l’anonimato degli utenti è fondamentale per proteggere la loro privacy, specialmente in un sistema centralizzato. Se gli utenti fossero costretti a rivelare la propria identità in fase di registrazione, questo potrebbe scoraggiare molti cittadini dall’installare l’app. Una scarsa partecipazione ridurrebbe drasticamente la sua adozione e ne pregiudicherebbe quindi l’efficacia ai fini della lotta al contagio.
Conclusione e commenti
In questo articolo ho descritto i principali rischi per la privacy nelle app di contact tracing con modello centralizzato e decentralizzato, prendendo come riferimento i protocolli ROBERT e DP-3T. Voglio sottolineare che questa non è un’analisi completa di tutti i rischi che comporta l’utilizzo di queste app. Oltre alle protezioni per la privacy, vanno valutati attentamente altri requisiti, tra cui, ad esempio, come garantire il più possibile l’integrità dei dati raccolti, la sicurezza dei protocolli Bluetooth utilizzati e il corretto funzionamento dell’app anche nei dispositivi affetti da malware.
Detto questo, quale protocollo è il più sicuro per la privacy? Lo scorso 21 aprile, L’EDPB (European Data Protection Board) ha pubblicato delle linee guida sul contact tracing. Il documento dichiara che le quelle centralizzate e decentralizzate sono entrambe “opzioni praticabili”, a condizione che vengano adottate misure di sicurezza adeguate e che vengano chiaramente descritti vantaggi e svantaggi di ognuna di queste. L’EDPB aggiunge però anche che “in generale, le soluzioni decentralizzate sono più in linea col principio di minimizzazione” dei dati raccolti.
Personalmente, sono d’accordo con le considerazioni dell’EDPB. Entrambi i modelli, e in particolare le loro incarnazioni nei prototipi specifici ROBERT e DP-3T, sono soluzioni potenzialmente accettabili. Nessuno dei due è un sistema sfruttabile in modo diretto e immediato ai fini della sorveglianza di massa. Tuttavia, a mio avviso, il modello centralizzato è sensibilmente più soggetto al function creep, ovvero quel fenomeno diffuso per cui una tecnologia progettata per un determinato scopo viene in seguito utilizzata per scopi diversi, spesso lesivi della privacy. Come abbiamo visto, un’autorità sufficientemente potente e determinata potrebbe decidere di sfruttare un sistema centralizzato per fini di sorveglianza di massa. Al contrario, la minimizzazione dei dati gestiti dall’autorità nel protocollo DP-3T lo rende molto più sicuro rispetto al rischio di function creep e di sorveglianza di massa. Quindi, da un punto di vista prettamente di tutela della privacy, la scelta del protocollo dovrebbe quindi propendere, secondo me, verso DP-3T.
Tuttavia, la scelta finale dipende in realtà da molti altri fattori, tra cui l’efficacia dei diversi protocolli per il contact tracing e quindi per il contenimento dell’infezione. Purtroppo, nelle scorse settimane molti sostenitori del modello centralizzato hanno agito e comunicato in modo poco chiaro e trasparente—a differenza del team DP-3T, che è apparso più aperto a collaborazioni e confronti. Anche a causa di questo, non è ancora chiaro quali sarebbero, se esistono, le proprietà del modello centralizzato che lo renderebbero più efficace. Perplessità che si inseriscono in un dibattito più ampio sull’utilità effettiva delle app di contact tracing, sulla quale esistono seri dubbi.
Questo atteggiamento poco trasparente ha legittimamente attirato critiche pesanti, ritardando lo sviluppo e l’adozione delle app, sia a livello europeo che italiano. La fase 2 sta per iniziare e sull’app Immuni rimangono ancora diverse questioni aperte e molta confusione. Il tempo sta scadendo: occorre intavolare al più presto una conversazione razionale basata sui vantaggi e i rischi delle diverse soluzioni proposte. Tenendo bene a mente che la privacy non è una gentile concessione, bensì un diritto fondamentale sancito di fatto dalla Costituzione italiana.
La scelta quindi non è e non deve essere tra privacy e salute. In una democrazia, privacy e salute devono essere garantite allo stesso tempo. La storia ha dimostrato più volte che prediligere un diritto individuale a scapito di un altro è un gioco pericoloso che porta spesso a perderli entrambi, con conseguenze gravi e irreversibili.
