App di contact tracing e vulnerabilità dei sistemi decentralizzati: modalità di mitigazione

Durante l’attuale emergenza Covid-19 sono stati proposti diversi protocolli e applicazioni per la ricerca dei contatti, la maggior parte basata sulla tecnologia dei beacon Bluetooth. Tutti questi protocolli e implementazioni, insieme alla loro analisi della sicurezza e della privacy, sono stati realizzati in lassi di tempo molto brevi, a causa dell’emergenza attuale e della necessità di adottare rapidamente soluzioni efficaci. A causa di questa urgenza, potrebbe accadere che non vengano individuati alcuni scenari di rischio e vulnerabilità.

Un lettore che non approfondisca i dettagli tecnici può essere portato a pensare in modo aprioristico che una determinata architettura risulta intrinsecamente meno vulnerabili di altre. In particolare, il buon senso ci può portare a ritenere che un trattamento decentralizzato delle informazioni comporti un rischio di loro violazione inferiore rispetto ad un trattamento centralizzato.

Certamente una singola violazione in una architettura distribuita ha un impatto inferiore rispetto ad una singola violazione di una architettura centralizzata, ma in un contesto come quello digitale in cui tutti i dispositivi sono in realtà adiacenti in virtù dell’annullamento dello spazio e del tempo, si deve anche considerare il rischio emergente da una violazione sistematica di tutti o gran parte dei dispositivi periferici e la complessità della loro protezione complessiva rispetto alla complessità di protezione di un singolo sistema centralizzato.

Tutto ciò non si può considerare in modo avulso dal quadro normativo che definisce i perimetri della liceità e con essa le pratiche attuabili da un attaccante e delle contromisure praticabili da chi difende.

Buona parte del contesto operativo di queste app ruota intorno alla raccolta di dati “anonimi” in quanto individualmente e collettivamente scollegate da ogni informazione personale (PII). Ma è possibile affermare in assoluto che i dati raccolti da un’app negli scenari di utilizzo previsti fino ad oggi possano essere considerati “anonimi”? Ed è possibile offrire garanzia di anonimato con particolari misure di sicurezza? In realtà, come vedremo, è un assunto molto problematico.

La diffusione capillare di terminali mobili con disponibilità di diversi sensori e canali di comunicazione, unitamente all’impossibilità di assicurare un comportamento completamente cooperativo e sensibile ai temi di privacy da parte dei loro possessori, possono limitare il presunto anonimato offerto dalle soluzioni oggi disponibili.

È proprio la presunzione o la falsa certezza di anonimato che, agli occhi di chi scrive, costituiscono il principale problema da affrontare, in quanto volendo affermare tale principio e non essendo tuttavia in grado di garantirlo, i decisori corrono il rischio di non prevedere alcune misure opportune (tanto normative quanto tecniche) o di limitare la portata di alcune di esse, che potrebbero al contrario essere determinanti nel proteggere la privacy delle persone nella più concreta ipotesi che i dati siano, in realtà, riconducibili ad esse.

Questo non significa che non si debbano adottare le migliori soluzioni disponibili, ma suggerisce di essere prudenti e di aggiungere diversi livelli di protezione per prevenire le vulnerabilità che potrebbero essere scoperte in futuro.

Analizzando i protocolli sono già stati individuati possibili comportamenti inattesi.

I presupposti di un possibile attacco

Il DP-3T è uno dei protocolli più noti tra quelli volti a garantire il tracciamento “anonimo”, e ne viene considerata l’implementazione in molti paesi. Serge Vaudenay^[1] ha descritto diversi possibili metodi di attacco al protocollo, insieme a possibili strategie di mitigazione; uno di questi attacchi è il cosiddetto “attacco delle milizie”.

Descriviamo una generalizzazione di questo attacco, che può essere eseguito passivamente contro protocolli che condividono identificatori anonimi in modo analogo a quanto previsto dal protocollo DP-3T, insieme ad alcune possibili strategie di mitigazione.

Supponiamo che, come sta accadendo, il governo di un paese scelga di utilizzare un’applicazione di tracciamento dei contatti, che chiameremo TrackerApp, la quale implementa a tale scopo il protocollo DP-3T.

Questo attacco viene eseguito da un’applicazione, che chiameremo MalApp, installata sullo stesso dispositivo (ad esempio uno smartphone) dell’applicazione di tracciamento dei contatti.

È ragionevole ipotizzare che un’app malevola, volta a violare l’anonimato dell’app governativa, sia presente su molti dei terminali degli utenti?

MalApp potrebbe essere un’app con una base di installazione già diffusa e successivamente modificata per aggiungere questa funzione, o anche un’app malware già installata di nascosto sul dispositivo dell’utente; tuttavia, il caso più interessante sarebbe quello di un’app che l’utente sia indotto ad installare.

Prendiamo in considerazione un’app che affermi quanto segue:

“Questa app monitora solo i segnali degli altri utenti, non raccoglie alcuna informazione sul vostro dispositivo. Raccoglie solo le informazioni già anonime e volontariamente trasmesse da altri utenti. Se venite informati di un contatto con una persona che è risultata positiva al test Covid-19, l’app può dirvi chi è. L’app può anche dirvi chi siano le persone risultate positive al test nella vostra zona“.

È realistico immaginare che molti utenti la installerebbero, anche in numero maggiore rispetto a TrackerApp, ritenendo di tutelare sé stessi e, con un atteggiamento da “milizia” nei confronti dei propri vicini, anche la comunità. Affinché queste informazioni siano disponibili, l’app deve essere in grado di re-identificare i profili delle persone che risultino positive al test Covid-19.

Facciamo quindi alcune ipotesi molto generali su MalApp e TrackerApp.

TrackerApp implementa, come detto, un protocollo di ricerca dei contatti come DP-3T secondo il modello decentralizzato, in cui i dati sono residenti solo sui terminali mobili, ovvero:

• trasmette un identificatore ogni x secondi o minuti (ad es. ogni minuto). Questo identificatore è un numero casuale, cioè MalApp non può riconoscere alcuna struttura nell’identificatore, se non che fa parte del sistema di tracciamento TrackerApp, né estrarre alcuna informazione da esso;
• legge anche gli identificatori trasmessi dai dispositivi vicini;
• cambia il proprio identificatore ogni n ritrasmissioni, ovvero dopo alcuni minuti (ad esempio dieci minuti); il nuovo identificatore è anch’esso un numero casuale, quindi non c’è alcun legame tra i due numeri, a parte essere trasmesso dallo stesso dispositivo in momenti diversi;
• gli identificatori trasmessi sono considerati anonimi fino a quando non vengono esposti ad un’autorità sanitaria dal proprietario del dispositivo quando il test è positivo alla Covid-19, ma l’effettiva identità del proprietario del dispositivo non viene esposta dall’autorità, al fine di preservarne la privacy e la sicurezza;
• affinché un contatto sia rilevante, deve avere una certa durata, ad esempio alcuni minuti; ciò significa che un identificatore verrà trasmesso più volte durante il contatto e TrackerApp può scartare gli identificatori che non vengono osservati per una quantità sufficiente di minuti.

Questo è, in sostanza, quanto già sappiamo della gran parte delle applicazioni che molti governi stanno valutando.

Le caratteristiche di MalApp, assumendo realisticamente che possa funzionare senza violare la sicurezza dei dispositivi mobili che la ospitano, sono le seguenti:

• non può leggere gli identificatori trasmessi da TrackerApp sullo stesso dispositivo, ma può leggere gli identificatori trasmessi dai dispositivi vicini, allo stesso modo di TrackerApp;
• può legittimamente associare il dispositivo a un’identità del proprietario, sia perché il proprietario l’ha installata e registrata fornendone il consenso, sia attraverso una delle tante tecniche di tracciamento/profiling solitamente adottate dalle app;
• non utilizza nessuna informazione aggiuntiva per eseguire l’attacco, ad esempio non viene raccolta alcuna geolocalizzazione o MAC Address (sebbene tali funzionalità siano facilmente implementabili e potrebbero aumentare l’efficacia dell’attacco, ma qui non vengono considerate per dimostrare come l’attacco stesso sia possibile con una minima conoscenza da parte di MalApp); utilizzando gli stessi algoritmi e parametri utilizzati da TrackerApp vengono raccolti passivamente solo:

1. gli identificatori trasmessi da TrackerApp;
2. la misurazione della distanza, per decidere se un contatto stia avvenendo;

• è installata su una percentuale rilevante dei dispositivi su ci è installata TrackerApp nella regione in cui questa è adottata (come detto, può essere un’ipotesi realistica a seconda di come MalApp si presenta);
• è in grado di rilevare se TrackerApp è installato sullo stesso dispositivo.

Si valuti infine che:

1. Il distanziamento sociale implica che di solito le persone abbiano pochi individui nelle vicinanze, ognuno con un solo dispositivo con TrackerApp installata. I dispositivi senza TrackerApp non sono rilevanti in quanto non trasmettono alcun identificatore;
2. TrackerApp utilizza un protocollo aperto che può essere implementato da MalApp. Non è richiesto codice open source per TrackerApp.

Come avviene l’attacco

Per prima cosa descriviamo l’attacco di base. Tre dispositivi sono vicini l’uno all’altro: A, B e C. Non ci sono altri dispositivi con TrackerApp installata. Tutti hanno TrackerApp installato, e MalApp è installato su A e B.

Scenario base dell’attacco.

MalApp associa a ciascun dispositivo su cui è installata la corrispondente identità utente, rispettivamente UA ed UB. Al momento t0, (l’istanza TrackerApp su) A trasmette un identificatore iat, B trasmette un identificatore ibt, C trasmette un identificatore ict.

Le istanze di MalApp su A e B possono raccogliere gli identificatori inviati dagli altri due dispositivi (ma non possono raccogliere i propri). Ogni istanza di MalApp invia i dati raccolti ad un server centrale, insieme all’identità del proprio utente:

• A invia { UA, ibt, ict }
• B invia { UB, iat, ict }

Il riconoscimento di “C” da parte delle MalApp.

Il server può:

• dedurre che A e B sono vicini, dato che entrambi vedono il medesimo identificatore ict;
• limitare la propria analisi ad A e B, poiché nessun’altra istanza di MalApp invia ict;
• riconoscere gli identificatori di A e B: dato che non è stato raccolto alcun altro identificativo, non vi sono nelle vicinanze altri dispositivi con TrackerApp, quindi A vede l’identificatore di B, B vede l’identificatore di A e pertanto ogni identificatore può essere correttamente associato al dispositivo che lo emette: iat ad UA ed ibt ad UB.

Affinché questo attacco risulti efficace, sono necessari almeno tre dispositivi e su almeno due di essi deve essere installata MalApp. Possono essere dedotte solamente le identità dei dispositivi che hanno installata MalApp.

Da questo punto in poi, iat sarà associato ad A sino a quando A non lo cambierà.

Quindi, se nel frattempo (t1) A incontra D, se D ha installate le app TrackerApp e MalApp e sta trasmettendo idt, A e D invieranno al server questi dati:

• A invia { UA, idt }
• D invia { UD, iat }

ma dato che il server sa già che iat è associato a UA, può anche associare idt ad UD.

Il riconoscimento di “D” da parte della sola MalApp “A”.

Successivamente (t2), se E, dotato di TrackerApp e MalApp incontra D, anche questi dispositivi possono inviare i dati raccolti al server:

• E invia { UE, idt }
• D invia { UD, iet }

e possiamo associare iet ad UE, e via dicendo.

Il riconoscimento di “E” da parte della sola MalApp “D”.

L’associazione dei dispositivi agli identificatori si diffonde fino a quando, dopo alcuni minuti, gli identificatori non vengono cambiati dai dispositivi. Ma i dispositivi possono essere re-identificati una volta che si verificano le giuste condizioni, ad esempio le condizioni iniziali, o qualche dispositivo già identificato si trova nelle vicinanze.

Alcuni lavori preliminari mostrano che il collegamento dell’identificatore al dispositivo e quindi al profilo utente può essere efficace anche con diversi (ad esempio cinque) dispositivi intorno ad ogni dispositivo, alcuni con MalApp a bordo, altri no.

L’attacco è efficace almeno ogni volta che due dispositivi con MalApp (e TrackerApp) si incontrano con un terzo dispositivo con TrackerApp installata. L’aggiunta di altri dispositivi intorno ad essi, con o senza MalApp, sembra aumentare la complessità dell’analisi, ma anche la probabilità di collegare efficacemente gli identificatori ai dispositivi.

Inoltre, lo stesso lavoro preliminare suggerisce che gli algoritmi di analisi distribuiti (ad esempio su una botnet) potrebbero essere molto efficaci, poiché l’analisi su un insieme di identificatori e profili utente è “locale” su un insieme limitato di dispositivi vicini, che possono essere isolati e analizzati senza coinvolgere l’intera popolazione dei dispositivi.

I dispositivi che si stanno spostando sono più difficili da gestire e possono anche introdurre alcuni errori nelle associazioni, ma in molti casi questi errori possono essere corretti con osservazioni successive.

Dal tracciamento al riconoscimento dell’utente

Supponiamo che A ed E siano informati di aver avuto un contatto con qualcuno che è risultato positivo. Il server può conservare la cronologia dei loro contatti tracciati.

Poiché entrambi hanno incontrato (solo) D, anche se in momenti diversi, il server può informarli di questo contatto, insieme a UD.

Il server non può affermare che questo sia l’unico contatto comune che hanno avuto, dato che potrebbero essere stati in contatto, ad esempio, con qualcuno senza TrackerApp, ma non possiamo aspettarci che questo tipo di servizio sia assolutamente preciso e corretto nelle sue informazioni. In molti casi, comunque, le informazioni potrebbero essere corrette.

Inoltre, lo storico dei contatti permette di costruire un grafo di contatti con associata una distanza stimata, così quando qualcuno vicino a D chiede informazioni circa il proprio quartiere, potrebbe essere fornito il profilo di UD.

Anche la geolocalizzazione potrebbe essere realizzata molto efficacemente, ma non viene discussa in questa sede.

L’impatto sulla privacy e la falsa “sensazione” di anonimato

Esistono molte tecniche di tracciamento: qualsiasi applicazione potrebbe raccogliere i numerosi segnali unici trasmessi dagli smartphone (ad esempio il Mac Address Bluetooth) e geolocalizzarli.

Questo genere di attacchi e le relative tecniche di mitigazione sono ampiamente discussi^[2]. Tuttavia, ai sensi del Regolamento Generale sulla Protezione dei Dati (GDPR), normalmente il tracciamento sarebbe illegale perché comporterebbe il trattamento di dati personali, a meno che ricada in una delle condizioni elencate nell’articolo 6 del GDPR (di solito il consenso dell’utente) e/o dell’art.9, con specifico riferimento al comma 2.i, tenuto conto del Considerando 54, che recita: “Il trattamento di categorie particolari di dati personali può essere necessario per motivi di interesse pubblico nei settori della sanità pubblica, senza il consenso dell’interessato. Tale trattamento dovrebbe essere soggetto a misure appropriate e specifiche a tutela dei diritti e delle libertà delle persone fisiche”.

Generalmente non è possibile effettuare lecitamente un tracciamento di massa, a meno che non sia chiaramente definito il quadro di interesse pubblico, limiti, durata e garanzie che ne sostengono la necessità e liceità, tramite appositi dispositivi normativi.

Se tali requisiti possono valere per TrackerApp, non valgono invece per qualsiasi MalApp che venga identificata da una corte come esecutrice di un analogo tracciamento di massa, che potrebbe quindi essere rimossa dagli store, ed il titolare potrebbe essere legalmente perseguito.

Tuttavia, il GDPR si applica solo ai dati personali: se i dati trasmessi fossero effettivamente anonimi, o considerati erroneamente tali, il GDPR non li proteggerebbe, e chiunque potrebbe raccoglierli e inviarli, ad esempio, in un paese in cui il GDPR non può essere applicato in modo efficace.

Lì, potrebbero essere trattati da un altro soggetto per ricollegarli ai proprietari dei rispettivi dispositivi se e quando venisse appresa l’identità dei loro proprietari.

Questa elaborazione sarebbe illecita, ma in questa situazione potrebbe essere molto più difficile far rispettare il GDPR. Dimostrando che i dati possono essere re-identificati, suggeriamo che i dati trasmessi da un’app di tracing, pur consentendo agli utenti di “essere reciprocamente anonimi in prima istanza”^[3], siano effettivamente protetti dal GDPR, e sia preferibile considerarli sempre dati pseudonimi.

Mitigare il rischio di attacchi

Esistono due modalità di mitigazione del rischio dell’attacco appena descritto, una normativa e una tecnica. Analizziamole in dettaglio.

Mitigazione normativa

Una prima misura di mitigazione potrebbe consistere nel proteggere normativamente le trasmissioni del beacon dalla loro elaborazione, evitando di considerarle per via legislativa come anonime (come già diversamente dimostrato sopra), oppure vietandone espressamente l’elaborazione da chi non faccia parte del sistema (o normandone specifici trattamenti, come quelli ai fini di ricerca).

In caso contrario, qualsiasi elaborazione dovrebbe essere perseguita dimostrando successivamente che le informazioni non sono anonime.

Un tale presupposto normativo può costituire la base legale certa ex ante, altrimenti valutabile giuridicamente solamente ex post, per richiedere agli store la rimozione di MalApp, limitandone pertanto la diffusione e invalidando la tecnica di attacco.

Dichiarare o “scoprire” solo ex post che i beacon non sono anonimi potrebbe avere un grande impatto sulla fiducia che i cittadini ripongono nella TrackerApp, nell’intero sistema di tracciamento e, in ultima analisi, nelle istituzioni.

Mitigazione tecnica

Può essere discutibile se sia necessaria una protezione tecnica, dato che il tracciamento illecito degli utenti potrebbe essere eseguito in modo più semplice per via normativa.

Tuttavia, l’aggiunta di misure di sicurezza a un protocollo suggerito o imposto dagli Stati nazionali sembra essere appropriata. Dal punto di vista tecnico, l’attacco è piuttosto generale ed è quindi difficile da contrastare. I suoi limiti sono legati principalmente alla percentuale di MalApp installate, che è una questione “sociale” e, come abbiamo visto sopra, normativa.

L’analisi dei dati richiesta dall’attacco può essere distribuita in modo efficiente (sulle MalApp stesse o su botnet simili a quelli utilizzati per il crypto mining), ma è comunque costosa. L’aumento del costo di calcolo potrebbe essere un’efficace strategia di mitigazione, tale da scoraggiare l’aggressore.

Una strategia di mitigazione potrebbe essere che TrackerApp trasmetta più di una sequenza di identificatori contemporaneamente.

In questo modo, per un osservatore come MalApp, sembrerebbe di trovarsi in un luogo affollato invece che in un luogo con pochi dispositivi, a meno che tutti questi identificatori non possano essere collegati a qualche altra informazione univoca del dispositivo (ad esempio un MAC Address).

Anche se ciò ne aumenta la complessità, lo stesso lavoro preliminare sembra suggerire che una analisi effettuata correttamente potrebbe portare a collegare il dispositivo ad un insieme di identificatori invece di collegarlo ad un singolo dispositivo. In alcuni casi, gli errori potrebbero essere più comuni, specialmente con dispositivi in movimento, ma la strategia di mitigazione non sembra essere sufficientemente efficace.

Analisi più approfondite e alcune simulazioni potrebbero aiutare a valutare meglio il problema.

Una migliore strategia di mitigazione potrebbe comportare un certo coordinamento tra tutte le TrackerApp, ad esempio attraverso un server, al fine di compromettere la capacità dell’aggressore di limitare la sua analisi a piccoli insiemi di dispositivi.

Per fare questo, sfruttiamo l’ipotesi 5, (che affinché un contatto sia tracciato, esso dovrebbe avere una durata minima stabilita: contatti di breve durata comportano un basso rischio di trasmissione virale) aggiungendo solo rumore al sistema di tracing e aggiungendo un carico computazionale non necessario alle strutture incaricate di raggiungere, allertare e testare le persone.

Introduciamo un TrackerServer cui le TrackerApp possono inviare alcuni degli identificatori che stanno trasmettendo. Allo stesso tempo, le TrackerApp raccolgono dal TrackerServer alcuni degli identificatori inviati da altre istanze di TrackerApp e li emettono localmente.

Il TrackerServer deve essere affidabile nel non fornire alle TrackerApps identificativi realizzati per identificarle; tuttavia, per garantire le proprietà di anonimato necessarie, non è necessario che soddisfi altri particolari requisiti funzionali.

Ogni TrackerApp trasmetterà questi identificatori ricevuti dal server per un periodo di tempo limitato, più breve di quello necessario perché un contatto sia rilevante secondo l’ipotesi 5. Mentre questo mix di identificatori potrebbe causare falsi positivi, questo errore è evitato dal fatto che la durata dei falsi contatti è inferiore a quella richiesta per la loro considerazione.

Solo gli identificatori appartenenti alla sequenza autentica trasmessa dalla TrackerApp iniziale sono rilevanti, poiché saranno trasmessi da un singolo dispositivo e per un tempo sufficiente.

Questo meccanismo richiede che l’analisi dell’aggressore tenga conto di diversi altri cluster di dispositivi quando si cerca di collegare un identificatore a un dispositivo, aumentando di fatto la complessità dell’analisi.

Qui si applica il “birthday problem”, quando due TrackerApp vicine possono trasmettere lo stesso identificatore ricevuto dal server, “aggiungendo” così un tempo di trasmissione sufficientemente lungo nello stesso luogo perché il contatto sia classificato come valido.

Questo problema dovrebbe essere affrontato tarando opportunamente i diversi parametri e rilevando se qualche TrackerApp vicina sta già trasmettendo lo stesso identificatore ricevuto dal server, evitando quindi di trasmetterlo.

Attacchi alla strategia di mitigazione

Anche attacchi DDoS rivolti contro il server sono ovviamente un problema, che dovrebbe essere contrastato con le protezioni usuali. In ogni caso, questo attacco ridurrebbe l’efficacia della strategia di mitigazione, ma non avrebbe alcun impatto sull’effettiva attività di tracciamento, e quindi difficilmente avrebbe senso per un attaccante.

MalApp potrebbe connettersi al server e raccogliere o inserire identificatori, ma questo non sembra essere un vero problema, oltre al carico del server, in quanto il server fornirebbe gli identificatori a TrackerApp casuali che lo contattano, quindi non dovrebbe essere possibile alcun collegamento con i dispositivi stessi.

NOTE

1. Vedere ad esempio “Tracing Anonymized Bluetooth Devices”, Johannes K Becker*, David Li, and David Starobinski, 2019 ↑
2. See e.g. “Tracing Anonymized Bluetooth Devices”, Johannes K Becker*, David Li, and David Starobinski, 2019 ↑
3. Garante per la Protezione dei Dati Personali – Parere sulla proposta normativa per la previsione di una applicazione volta al tracciamento dei contagi da Covid-19 – 29 aprile 2020 ↑