di Andrea Gadotti* (Ha collaborato Simone Benazzo)

Immuni è operativa. Dopo una prima fase di test in quattro regioni, il 15 giugno l’app di contact tracing ufficiale del governo italiano è stata attivata in tutta Italia. Disponibile per Android e iOS, Immuni dovrebbe contribuire a tracciare i casi di possibile contagio tra la popolazione. L’app tiene traccia di tutti i contatti avuti dall’utente nelle precedenti due settimane e, se una delle persone con cui ha interagito viene segnalata come positiva al coronavirus, lo avverte del possibile rischio e fornisce alcuni consigli su come comportarsi.

Leggi anche >> App di contact tracing: soluzione o problema?

Il lancio di Immuni arriva dopo mesi di indiscrezioni e discussioni, influenzate anche da un complicato contesto internazionale. Una questione centrale di questo dibattito ha riguardato la privacy: le app di contact tracing richiedono di raccogliere e inviare molti dati personali, che potrebbero rivelare informazioni sensibili sugli utenti che le installano, tra cui gli spostamenti effettuati o le persone incontrate. Alcuni di questi dati vengono persino condivisi con chiunque si trovi nelle vicinanze - inclusi sconosciuti, curiosi e malintenzionati. Ciò richiede che il protocollo usato per gestire il flusso di dati sia progettato con estrema attenzione alla sicurezza e alla protezione dei dati degli utenti.

Leggi anche >> Tutti i nostri articoli sulle app di contact tracing

Sviluppare un protocollo al contempo robusto ed efficiente è un compito molto arduo. Negli scorsi mesi sono state avanzate decine di proposte diverse, perlopiù da ricercatori nel campo del privacy engineering. Tra queste, sono emersi due modelli contrapposti: il modello centralizzato e il modello decentralizzato. Entrambi prevedono un’entità centrale che coordina il flusso di dati, ma nel primo modello questa ha accesso a molti più dati rispetto al secondo. Per questo motivo, diversi esperti ritengono che il modello centralizzato potrebbe, in casi particolari, facilitare la sorveglianza di massa (qui un confronto del modello centralizzato e decentralizzato e qui un’analisi più tecnica dei rischi del sistema centralizzato).

Immuni ha adottato il modello decentralizzato. L’app si basa sul framework (un insieme di funzionalità) per il contact tracing reso disponibile da Apple e Google per i sistemi operativi mobile iOS e Android. Questo framework impone l’utilizzo di un protocollo decentralizzato che, secondo la maggior parte degli esperti, offre ottime protezioni per la privacy. Il protocollo è in realtà vulnerabile ad alcuni attacchi (descritti più avanti), che sono tuttavia piuttosto complicati da attuare. Per questo, la maggior parte dei cittadini può usare Immuni senza doversi preoccupare troppo della sicurezza dei propri dati.

La decisione di adottare un protocollo decentralizzato per Immuni non era scontata: in una fase iniziale, le autorità italiane e Bending Spoons — l’azienda incaricata dal governo italiano di sviluppare l’app — sembravano orientate verso l’adozione di un modello centralizzato. Le forti critiche rivolte ai modelli centralizzati e la decisione di Apple e Google di supportare solo il modello decentralizzato hanno spinto il governo a cambiare idea. Diversi altri Stati europei, tra cui Germania ed Austria, hanno optato per un cambio di rotta simile per le loro app ufficiali. Al momento, in Europa solo Francia e Regno Unito sembrano intenzionati ad adottare un modello centralizzato per le loro app di contact tracing.

Il problema principale del modello centralizzato risiede nel fatto che richiede agli utenti di fidarsi che l’autorità centrale si comporti come dichiarato e non tenti di abusare del sistema per sorvegliare i cittadini. Secondo Privacy International, i sistemi centralizzati prevedono che gli utenti accordino alle istituzioni una fiducia eccessiva. La fondazione ha ricordato che alcune operazioni di sorveglianza già attuate da alcune agenzie governative europee con modalità “poco rispettose degli standard democratici e persino illegali” hanno dimostrato come questa fiducia sarebbe, allo stato attuale, immeritata. Per la tutela della privacy la fiducia riposta dagli utenti nell’autorità deve essere accompagnata dall’utilizzo della crittografia e da altre garanzie tecniche di sicurezza.

Sebbene la fiducia nelle istituzioni sia un elemento fondamentale per il funzionamento di un sistema democratico, esistono meccanismi di pesi e contrappesi finalizzati a limitarne abusi e distorsioni. La crittografia e il privacy engineering possono fornire un ulteriore contributo in questo senso. È molto difficile progettare un sistema che richieda zero fiducia, ma la ricerca in computer security e privacy si concentra proprio sul ridurre il più possibile la quantità di fiducia necessaria e il numero di attori in cui si chiede di riporla. Sebbene non eliminino completamente il requisito della fiducia, i protocolli decentralizzati come quello adottato da Immuni tentano di fare proprio questo.

Di chi ci stiamo fidando quando usiamo Immuni?

Nello sviluppo di Immuni, Bending Spoons ha dovuto trovare un compromesso accettabile tra più requisiti di tipo diverso. Tra i principali vi sono l’efficacia nell’avvisare gli utenti a rischio (e non avvertire erroneamente quelli non a rischio), il corretto funzionamento nella maggior parte degli smartphone presenti sul mercato e la protezione dei dati degli utenti. Per quanto riguarda l’ultimo punto, va riconosciuto l’impegno dell’azienda nel progettare una soluzione che minimizzi la fiducia richiesta agli utenti nei confronti di diversi attori.

Innanzitutto, agli utenti non è richiesto di riporre fiducia in Bending Spoons quando installano Immuni. Oltre a una dettagliata documentazione, anche il codice sorgente di Immuni è stato rilasciato pubblicamente sulla piattaforma GitHub con licenza open source (AGPL-3.0) e, almeno per il momento, viene aggiornato di pari passo con gli aggiornamenti dell’app sugli store di Android e iOS. Questo permette a chiunque — e, in particolare, agli esperti di sicurezza — di studiare nel dettaglio come funziona l’app e verificare che non si comporti in modo diverso da quanto dichiarato.

Tecnicamente, anche se il codice sorgente è pubblico, sarebbe teoricamente possibile inserire del codice malevolo “in segreto” durante la fase di compilazione del codice, a cui segue poi la pubblicazione dell’app compilata sugli store. Nel caso di software proprietario (closed source)—e spesso anche per il software open source—gli utenti confidano che questo non accada, ma a volte succede. Per minimizzare questo rischio, Bending Spoons ha lavorato sulle build riproducibili, ovvero un processo grazie al quale chiunque può verificare che le app disponibili sugli store corrispondano effettivamente al codice disponibile pubblicamente. Purtroppo, è un fatto noto che ottenere build riproducibili è molto complicato e infatti pochissime app vengono sviluppate supportando questa proprietà (le più note sono le app di messaggistica Telegram e Signal). Bending Spoons ha affermato che le build non sono ancora del tutto riproducibili, ma stanno ancora lavorando per ottenere una riproducibilità completa.

Tuttavia, il fatto che il codice sia open source non implica necessariamente che il protocollo implementato dal codice sia rispettoso della privacy. In particolare, l’app di Immuni comunica regolarmente con il Ministero della Salute, e più precisamente con la società pubblica SoGEI che gestisce il server per conto del Ministero. In alcuni casi, la comunicazione comporta l’invio di alcuni dati dal dispositivo dell’utente al server di SoGEI. Ma la scelta del protocollo decentralizzato riduce fortemente la fiducia che gli utenti devono riporre nel server e la gravità di un eventuale data breach. Questo perché, come spiegato sopra, il server raccoglie molti meno dati rispetto a un protocollo centralizzato e questi dati hanno un livello di anonimato considerevolmente più alto.

Ci sono diversi altri attori “secondari” che giocano un ruolo nel sistema di Immuni. Uno di questi è il gestore della CDN (content delivery network), la rete di server distribuiti sul territorio nazionale che, stando al parere del Copasir, svolgerebbe la funzione di intermediario tra gli utenti e il server di Immuni. Tale rete non sarebbe sotto il controllo diretto di SoGEI e potrebbe anzi appartenere a società estere, il che costituirebbe un potenziale rischio per la protezione dei dati degli utenti nel caso in cui il gestore della CDN analizzasse (illegalmente) il traffico prodotto dal sistema Immuni (criptare la comunicazione non è sufficiente ad azzerare il pericolo). Per ridurre questo rischio, Bending Spoons ha implementato alcuni metodi per generare dummy traffic che tentano di “ingannare” con informazioni fittizie un potenziale osservatore.

Un altro scenario delicato è quello in cui un utente viene trovato positivo al test per il coronavirus e viene invitato dall’operatore sanitario a inviare⁠, su base volontaria,⁠ alcuni dati dal suo dispositivo al server. L’operatore sanitario conosce l’identità del paziente, ma il sistema sviluppato da Immuni permette all’utente di inviare i dati in modo anonimo. Il principale atto di fiducia richiesto in questo passaggio è che l’operatore sanitario non riveli al server l’identità dell’utente: a mio avviso, un requisito più che accettabile.

Quanto possiamo fidarci di Apple e Google?

La scelta di Bending Spoons di basare Immuni sul framework proposto da Apple e Google ha generato molte polemiche. Dal punto di vista tecnico, il framework opera localmente sui dispositivi e non invia nessun dato ad Apple o Google (perlomeno nella versione attuale). Chi critica questa decisione sottolinea però che tale framework è closed source, il che rende piuttosto difficile verificare che si comporti come dichiarato da Apple e Google e vanifica di fatto la trasparenza derivante dalla natura open source di Immuni.

Leggi anche >> A che punto siamo con la App di contact tracing digitale

Sebbene queste obiezioni siano senz’altro motivate, la questione va valutata tenendo in considerazione il contesto concreto. È certamente vero che la natura closed source del framework introduce un rischio teorico di abusi da parte di Apple e Google, richiedendo di fatto un atto di fiducia di cui sarebbe auspicabile poter fare a meno del tutto, specialmente in un frangente così delicato. Tuttavia, Apple e Google non sembrano realisticamente avere sufficienti incentivi per operare in modo ingannevole e illegale in un caso come questo. Se ipotizziamo che Apple e Google siano pronte a inserire backdoor (vulnerabilità intenzionali) nei propri sistemi operativi, questo permetterebbe loro di raccogliere già ora molti dati anche più sensibili di quelli prodotti dalle app di contact tracing. La quasi totalità dei dispositivi Android e iOS presenti sul mercato viene venduta con grandi quantità di software closed source preinstallato, in gran parte prodotti proprio da Google e Apple. Tale software opera con privilegi molto elevati sul sistema, avendo accesso praticamente a qualsiasi dato personale processato dal dispositivo (localizzazione, messaggi, chiamate, immagini, dati bancari, etc). Se Apple e Google volessero spiare segretamente gli utenti raccogliendone illegalmente i dati senza il loro consenso, avrebbero già questa possibilità. Di fatto, questo vale anche per i dati prodotti da app di contact tracing che non utilizzano il framework di Apple e Google, ma devono comunque supportare i loro sistemi operativi, che costituiscono complessivamente il 99% del mercato degli smartphone.

Riporre fiducia nel framework di Apple e Google è quindi un requisito purtroppo inevitabile, ma accettabile sul piano della privacy. Considerazioni diverse varrebbero qualora Apple e Google decidessero di modificare il framework e obbligassero a sostituire i server del Ministero con un server gestito da loro, un’evenienza da non escludere completamente, stando alle dichiarazioni ambigue delle due aziende rispetto a una possibile “fase due”.

Inoltre, riconoscere che la fiducia in Apple e Google è irrinunciabile non significa accettare che sia giusto così. Come sostenuto da tempo dagli attivisti per i diritti digitali e dai fautori del software libero, la dipendenza dalle decisioni dei “giganti del web” (Google, Apple, Facebook, Amazon e altri) compromette la protezione delle libertà individuali e mina la sovranità digitale degli Stati. Sebbene il dibattito sull’adozione delle app di contact tracing sia avvenuto in modo a tratti forzato e pretestuoso, ha avuto il merito di spingere l’opinione pubblica e la politica a riflettere ulteriormente sull’enorme potere effettivo di cui queste aziende private godono nei confronti della società e delle istituzioni pubbliche. Il codice sorgente di Immuni non è però che un esempio circoscritto di questo conflitto tra poteri contrapposti, e non è quindi il terreno di scontro più adatto per affrontarlo.

Gli attacchi a cui è vulnerabile Immuni

Nonostante gli sforzi compiuti da Bending Spoons per sviluppare un’app sicura, Immuni è potenzialmente vulnerabile ad alcuni attacchi che possono mettere a rischio sia la privacy degli utenti che l’integrità del sistema. Quasi tutte le vulnerabilità dipendono in realtà dal framework di Apple e Google, e quindi riguardano qualsiasi app basata su di esso. Gli sviluppatori di queste app hanno inoltre un ristrettissimo margine d’azione per risolvere le falle del framework. Fortunatamente, la maggior parte degli attacchi non sono facili da eseguire, ma in casi specifici e per individui particolari possono costituire una minaccia reale. Prima di entrare nel merito degli attacchi, è utile descrivere brevemente il funzionamento (semplificato) di Immuni.

Supponiamo che un utente di nome Bob abbia installato e attivato Immuni sul proprio smartphone. Così configurato, il dispositivo di Bob usa il Bluetooth per trasmettere continuamente dei codici alfanumerici ai dispositivi circostanti, che li memorizzano automaticamente. Questi codici sono pseudonimi, ovvero univoci ma non riconducibili in modo diretto a Bob. Un osservatore malevolo potrebbe però tentare di reidentificare i codici appartenenti a Bob, basandosi sulle condizioni esterne in cui il codice è stato osservato. Ad esempio, supponiamo che Bob si trovi spesso con la sua amica Alice, e ogni volta che si incontrano il dispositivo di Alice osserva lo stesso codice d8x73nfe0. Questo potrebbe facilmente suggerire ad Alice che d8x73nfe0 è proprio il codice di Bob. Per evitare questo rischio, l’app di Bob rinnova spesso il codice che trasmette (circa ogni 15 minuti). I codici sono quindi temporanei. L’app di Bob memorizza tutti i codici che ha trasmesso nelle due settimane precedenti e li salva in una lista che chiamiamo my_codes. Allo stesso tempo, l’app di Bob tiene traccia di tutti i codici trasmessi dai dispositivi circostanti e li salva in una lista che chiamiamo observed_codes. Quindi la lista observed_codes di Bob contiene alcuni codici trasmessi da Alice e, viceversa, la lista observed_codes di Alice contiene alcuni codici trasmessi da Bob.

Supponiamo ora che Bob risulti positivo al test per il coronavirus. A quel punto, Bob può decidere se inviare (upload) volontariamente tutta la sua lista my_codes al server del Ministero della salute. L’upload richiede l’autorizzazione dell’operatore sanitario, al fine di evitare che un utente possa segnalarsi come positivo al coronavirus senza in realtà esserlo. A quel punto, il server aggiunge tutti i codici nella lista my_codes di Bob a una grande lista infected_users che contiene tutti i codici di tutte le persone trovate positive nelle ultime due settimane. Periodicamente, il server invia la lista infected_users a tutti i dispositivi che hanno installato Immuni. Ciò significa che la lista infected_users è essenzialmente pubblica. Come vedremo, questo fatto è l’origine di alcune vulnerabilità. Ogni dispositivo può quindi confrontare la lista infected_users con la propria lista observed_codes. Se le due liste hanno almeno un codice in comune, significa che l’utente è stato in prossimità di una persona trovata in seguito positiva al coronavirus. A quel punto, l’app produce una notifica che avvisa l’utente del possibile rischio e fornisce alcuni consigli su come comportarsi, ad esempio per richiedere un test.

Durante tutto il processo, l’app di Bob non invia mai a nessuno informazioni personali direttamente riconducibili a Bob (nome, numero di telefono, email, indirizzo, etc). Grazie alle altre proprietà del protocollo (in particolare il meccanismo di generazione e rinnovo dei codici), questo offre un ottimo livello di anonimato agli utenti, ma non è sufficiente a proteggerlo contro alcuni tentativi di attacco più sofisticati. Illustrerò ora i più importanti (gli attacchi sono stati descritti nel dettaglio da diversi ricercatori). Per comodità, seguirò la consuetudine diffusa degli ambienti di computer security di usare il nome Eve per indicare l’utente malevolo (il nome nasce da eavesdropper, ovvero un individuo che tenta di ascoltare conversazioni private di altri).

Attacco 1 (Nerd attack). Con questo attacco, se Eve viene avvisata di essere a rischio, può potenzialmente risalire all’identità del contatto positivo al coronavirus che ha provocato il presunto contagio. La gravità di questo attacco dipende principalmente dalla condizione personale dell’utente reidentificato: alcuni individui potrebbero temere di essere incolpati di un contagio o discriminati se alcuni dei loro contatti scoprissero che erano positivi al coronavirus in un determinato momento. È importante sottolineare che questo attacco può essere eseguito solo entrando fisicamente in contatto con la vittima nel periodo di infezione. Inoltre, i metodi noti per eseguire questo attacco richiedono che Eve agisca in modo premeditato.

Come funziona l’attacco. Eve decide di tenere traccia di quali persone le sono vicine ogni volta che il suo dispositivo osserva un codice trasmesso da un altro dispositivo. Se Eve riceve una notifica di possibile contagio, può controllare quale dei codici osservati ha generato la notifica e quindi quali persone le erano vicine in quel momento, perché la lista infected_users di tutti i codici degli utenti infetti è pubblica. Se in quel momento Eve era con una sola persona, ad esempio per un meeting di lavoro, Eve può concludere che molto probabilmente quella persona è l’utente segnalato come positivo.

L’idea di questo attacco è piuttosto semplice, ma metterlo in pratica richiede un certo impegno. Immuni (e più precisamente il framework di Apple e Google) non permette agli utenti di accedere alle liste di codici memorizzate sul proprio dispositivo. Esistono principalmente due modi in cui questa limitazione può essere aggirata. La prima è nel caso in cui il dispositivo venga sbloccato in modo da conferire all’utente maggiori privilegi. Questa pratica prende il nome di rooting su Android e jailbreak su iOS. I dispositivi sbloccati possono spesso aggirare restrizioni imposte dal sistema, e potrebbero teoricamente permettere all’utente di accedere alla propria lista observed_codes in modo retroattivo. Per le informazioni di cui disponiamo al momento non pare che questa procedura sia già stata testata in pratica, ma con l’imminente adozione delle app di contact tracing in molti paesi è probabile che qualche hacker o ricercatore ne scriverà presto.

Il secondo metodo non richiede un dispositivo sbloccato, ma prevede invece l’utilizzo di un’app specifica che, oltre a salvare i codici osservati, memorizza l’ora esatta del contatto. Questo permette a Eve di ricordare chi le era vicino in ogni momento. Sviluppare una tale app non è ovviamente alla portata di tutti, ma è molto semplice per un programmatore esperto. Il rischio è che un programmatore sviluppi tale app e la condivida pubblicamente, permettendo anche ad utenti non esperti di installarla facilmente. App come queste si possono già trovare per i computer che utilizzano GNU/Linux. È importante notare che questo secondo metodo funziona solo se Eve agisce in modo premeditato: Eve deve usare l’app modificata per tenere traccia dei contatti quando questi avvengono, non basta installare l’app a seguito di una notifica di possibile contagio da parte di Immuni.

Attacco 2 (Location tracking attack). Se Eve dispone di sufficienti risorse, può teoricamente reidentificare e tracciare retroattivamente gli spostamenti degli utenti positivi al virus che decidono di segnalarsi. Il tracciamento può avvenire solo per gli utenti segnalati come positivi ed esclusivamente durante la finestra di contagio di due settimane precedenti alla diagnosi. Anche questo attacco è molto complicato da mettere in atto, ma in alcuni casi specifici le conseguenze possono essere gravi, poiché gli spostamenti di un individuo potrebbero rivelare informazioni molto sensibili e permettere di ricostruirne le azioni. Ad esempio, si pensi al caso di un informatore che visiti segretamente la sede di un giornale per rivelare fatti di corruzione, oppure al caso di parlamentari che si incontrino privatamente per discutere dossier delicati. Nel caso di cariche istituzionali, il tracciamento dei loro spostamenti può comportare rischi anche sul piano della sicurezza nazionale.

Come funziona l’attacco. Per eseguire l’attacco, Eve deve avere accesso a una rete di sensori Bluetooth che coprono una parte significativa del territorio in cui vuole tracciare gli utenti (ad esempio, una grande città). Tali sensori osservano tutti i codici trasmessi dai dispositivi circostanti e li memorizzano, insieme all’ora esatta e al luogo in cui si trova il sensore. Eve sa quindi quali codici sono stati trasmessi in un certo luogo e a una certa ora. Come abbiamo visto, questi codici sono pseudonimi e cambiano ogni 15 minuti, quindi Eve non può tracciare uno stesso utente per più di 15 minuti—un periodo molto breve. L’immagine sottostante illustra questo fatto. I cerchi blu rappresentano la posizione approssimativa dei dispositivi che si trovano vicino ai sensori, ma sono di fatto anonimi perché i codici trasmessi hanno breve durata. 

La situazione però cambia quando l’utente Bob viene trovato positivo al virus e invia i propri codici al server. A quel punto, il server aggiunge i codici di Bob alla lista infected_users e li invia a tutti i dispositivi (tra cui quello di Eve). La lista infected_users non è però una semplice lista: i codici trasmessi da una stessa persona nel corso di una stessa giornata sono raggruppati (la ragione è tecnica e abbastanza complessa). Questo significa che Eve può collegare tutti i diversi codici trasmessi da Bob in una stessa giornata, e può farlo per i 14 giorni precedenti. Di fatto, questo permette a Eve di osservare la traiettoria di Bob per 14 giorni (a scaglioni di 24 ore) e quindi tracciarne gli spostamenti. In questa seconda immagine, i cerchi rossi sono quelli corrispondenti agli utenti positivi, che diventano collegabili. Ogni linea colorata rappresenta una diversa traiettoria giornaliera di spostamenti di un utente positivo che ha deciso di eseguire l’upload dei propri dati a seguito del test. 

Ma come fa Eve a sapere che quegli spostamenti sono proprio di Bob? La risposta sta nel fatto che gli spostamenti individuali sono unici: è praticamente impossibile che una persona diversa da Bob esegua i suoi stessi spostamenti per un periodo di tempo prolungato. Uno studio ha mostrato che, con una probabilità del 95%, anche solo 4 punti in una traiettoria sono sufficienti a identificare univocamente un individuo in un dataset contenente più di un milione di persone. Questo significa che gli spostamenti individuali sono facilmente reidentificabili. Se Eve conosce, ad esempio, il luogo dove Bob abita (e quindi spende maggior parte della notte), il luogo dove Bob lavora (e quindi spende la maggior parte del giorno) e un altro paio di punti, allora Eve può molto probabilmente reidentificare la sua traiettoria. Questo metodo è stato utilizzato da alcuni giornalisti del New York Times per un famoso articolo pubblicato lo scorso dicembre. I giornalisti hanno ottenuto accesso a un dataset privato contenente gli spostamenti di milioni di cittadini statunitensi, riuscendo poi a reidentificare e tracciare gli spostamenti di alcuni collaboratori stretti di Trump.

Come abbiamo visto, questo attacco richiede che Eve abbia accesso a una rete di sensori sufficientemente estesa e densa. Realizzare una tale rete installando molti sensori Bluetooth senza che vengano notati dalle autorità è un compito piuttosto arduo, sebbene i sensori Bluetooth siano molto piccoli ed economici. Ma anziché installare manualmente i sensori, Eve potrebbe adottare una strategia più subdola: sfruttare una botnet di smartphone. In questo scenario, Eve sviluppa e diffonde un malware per smartphone, che viene installato da molti utenti ignari e⁠, a loro insaputa⁠, osserva tutti i codici Bluetooth dei dispositivi circostanti e li invia ad Eve, assieme alla localizzazione dello smartphone infetto. Tale botnet potrebbe quindi essere un ottimo sostituto per una rete di sensori installati manualmente.

Sebbene esistano molte app contenenti malware⁠, riuscire a diffondere un malware non è un’operazione facile. Tuttavia, il numero di dispositivi che sarebbe necessario infettare è piuttosto basso. In uno studio pubblicato nel 2018 dal gruppo di ricerca dell’Imperial College di Londra di cui faccio parte si è dimostrato che se il malware infettasse solo l’1% della popolazione di una città densamente popolata come Londra, questo sarebbe sufficiente per osservare i codici inviati dal 56% di tutti gli utenti. Nella maggior parte dei casi, questi codici cambiano ogni 15 minuti e quindi non sono molto utili a Eve, ma, come abbiamo visto, il discorso è diverso per gli utenti che si segnalano come positivi al virus. Realisticamente, questo attacco è difficilmente praticabile da un utente singolo, ma è probabilmente alla portata dei servizi segreti degli Stati più avanzati e della criminalità organizzata.

Attacco 3 (Replay attack). Con l’aiuto di un numero sufficiente di complici, Eve potrebbe tentare di aumentare a dismisura le segnalazioni di rischio di contagio. Diversamente dai due attacchi precedenti, questo attacco non mira a violare la privacy degli utenti, bensì a compromettere l’integrità dei dati scambiati tra il server di Immuni e gli smartphone degli utenti, immettendo falsi contatti nel sistema. Se eseguito con successo e su larga scala, il numero elevato di false segnalazioni potrebbe provocare panico, mettere sotto pressione il sistema di test del servizio sanitario e minare la fiducia dei cittadini nei confronti di Immuni e, per estensione, nei confronti della gestione della pandemia da parte del governo. Una prospettiva appetibile, ad esempio, per Stati avversari che vogliano intaccare la stabilità politica e la coesione nazionale del nostro paese.

Come funziona l’attacco. Questo attacco sfrutta il fatto che i codici trasmessi da Immuni non sono certificati: quando un dispositivo osserva un certo codice, l’app non ha nessun modo di verificare che quel codice sia stato generato proprio dal dispositivo che lo sta trasmettendo. Ciò significa che chiunque può sviluppare un’app modificata che osserva i codici trasmessi dagli altri utenti e li ritrasmette (replay) a sua volta.

Per esempio supponiamo che Eve venga in contatto con Bob, osservi alcuni dei suoi codici e inizi a trasmetterli appena Bob si allontana. Dopo qualche minuto, Eve entra nelle vicinanze di Alice, il cui dispositivo osserva i codici di Bob trasmessi da Eve. Se Bob viene in seguito trovato positivo al virus e i suoi codici vengono contrassegnati come infetti, questo produrrà una notifica di rischio sul dispositivo di Alice senza che questa sia però mai entrata in contatto con Bob.

In realtà, i dispositivi che usano Immuni possono verificare se i codici osservati sono temporalmente validi, quindi Eve può ritrasmettere i codici di Bob solo per un massimo di 15 minuti dopo averlo incontrato. Quindi, se non agisce di concerto con altri soggetti, Eve non può generare un numero elevato di false segnalazioni. Lo stesso non vale però se Eve si avvale dell’aiuto di alcuni complici che si trovano in zone diverse. In quel caso, Eve e i complici possono coordinare l’attacco e scambiarsi automaticamente e in tempo reale tutti i codici “copiati” dagli altri utenti, per poi propagarli in tutti i diversi luoghi dove si trovano. Eve potrebbe anche fare a meno di complici qualora disponesse di una botnet come quella descritta nell’attacco precedente.

Immuni è una buona soluzione per il breve termine. Ma il dibattito tra esperti è appena iniziato

Anche se Immuni non è invulnerabile a ogni attacco, i rischi concreti per la privacy sono dunque piuttosto contenuti. Certe categorie di utenti dovrebbero però soppesare attentamente la scelta di usare Immuni, soprattutto in caso risultassero positivi al test e dovessero valutare se inviare o meno i propri dati: 1) Individui a rischio di sorveglianza, come attivisti, giornalisti e magistrati; 2) Personalità istituzionali la cui privacy è fondamentale per la sicurezza nazionale, come politici e militari; 3) Chiunque ritenga di poter venire gravemente discriminato o stigmatizzato dai propri contatti qualora questi scoprissero la sua eventuale positività al coronavirus.

Come illustrato, gli attacchi cui questi soggetti potrebbero venire sottoposti non sono certo facili da eseguire. Inoltre, è molto probabile che qualsiasi azione volta a metterli in pratica si configuri come atto illecito. Ad esempio, l’utilizzo di un’app modificata che osservi i dati trasmessi dagli altri dispositivi per scopi diversi dal contact tracing costituirebbe probabilmente una violazione del GDPR. Sebbene le restrizioni legali non si possano generalmente considerare una valida alternativa a solide protezioni tecniche, agiscono senz’altro da deterrente e facilitano l’individuazione di eventuali abusi.

Leggi anche >> Pandemia, app e tecnologia: un test per le democrazie

Riassumendo, complessivamente Immuni offre buone garanzie di privacy nel contesto attuale, che vede, in particolare, un numero relativamente basso di contagiati e una finestra di contagio di sole due settimane. In condizioni diverse, le vulnerabilità di sicurezza di Immuni e del framework di Apple e Google potrebbero generare invece conseguenze più gravi. Ad esempio, un individuo può accettare il rischio (remoto) che i propri spostamenti vengano tracciati per due settimane (attacco 2), ma potrebbe compiere valutazioni diverse qualora il rischio fosse più prolungato. Inoltre, se il numero di contagi dovesse salire notevolmente, aumenterebbe il numero degli individui potenzialmente tracciabili e quindi l’incentivo per attori malevoli a realizzare un’infrastruttura che permetta di eseguire gli attacchi.

Immuni e il protocollo di Apple e Google sono quindi una soluzione accettabile per il breve termine, ma non possono essere considerati la soluzione definitiva per il contact tracing digitale nel futuro. Il dibattito in ambito accademico sta continuando ed è probabilmente destinato a durare a lungo. Nelle ultime settimane, alcuni ricercatori hanno proposto soluzioni molto più sofisticate e sicure, ma anche più complicate da valutare e implementare. Una volta raggiunto un sufficiente livello di consenso tra accademici ed esperti su quali siano le soluzioni più robuste, sarà opportuno adottare quelle. L’implementazione effettiva di questi eventuali progressi teorici dipenderà però anche dalla disponibilità di Apple e Google, che al momento non sembrano inclini a modificare sensibilmente il protocollo supportato dal loro framework.

*Ricercatore nel Computational Privacy Group all'Imperial College di Londra. L'articolo è stato scritto a titolo personale.

Immagine in anteprima: Ansa via repubblica.it