Molti dei dibattiti sulle contact tracing application si stanno concentrando sulla richiesta di una app open source. Questa discussione può essere fuorviante e inutile perché le proprietà di sicurezza e privacy non possono essere garantite ragionando solamente sulla app. Qualsiasi app di tracing è solo un modulo di un sistema complessivo per il tracciamento e la segnalazione, e le sue proprietà potrebbero essere marginali. Infatti, in un sistema per il tracing la app non può esistere senza un back office, o back end. Il back office è un sistema informatico complesso che comprende un numero elevato di moduli per la ricezione e l’invio di informazioni, la loro memorizzazione e il controllo degli accessi alle informazioni memorizzate. Le proprietà di tutti i moduli che compongono il sistema di tracciamento sono fondamentali quando si parla prima di sicurezza e poi di privacy. Il numero degli utilizzatori del sistema complessivo e le prestazioni richieste fanno si che il back office sia una infrastruttura informatica complessa con un numero non banale di moduli hardware e software che eseguono milioni di istruzioni oltre a quelle eseguite dalla app.
Indice degli argomenti
Il ruolo del backoffice
Per analizzare il ruolo del backoffice seguiamo le linee presentate da INRIA e dal Fraunhofer Institute che giustamente distinguono tra applicazioni di tracing che funzionano in modo centralizzato oppure in modo decentralizzato.
Nel caso centralizzato, l’utente A che ha scaricato una app si collega al back office e scarica alcuni identificatori unici, di solito generati in modo pseudocasuale. Il back office, che è formato da alcuni server, conserva l’informazione degli identificatori associati all’utente A. La app eseguita dallo smartphone di A scambia mediante Bluetooth i propri identificatori con i cellulari delle persone con cui è venuta in contatto e li ricorda localmente in una lista L(A). Se e quando si scopre che A è infetto, L(A) viene caricata sul back-office. Il back office usa le informazioni memorizzate per risalire alle identità delle persone associate agli identificatori in L(A) e li informa senza però segnalare chi si è infettato tra i contatti, ovvero senza rivelare l’identità di A. Questa è la ragione per cui il back office deve ricordare le identità associate ai vari identificatori unici generati. In questo caso, l’app è molto semplice e quasi tutto il carico è spostato sul back office.
È ovvio che una qualche forma di autenticazione deve esistere sia nel momento in cui si generano gli identificatori che in quello in cui A carica L(A), semplicemente per impedire che chiunque si diverta a caricare identificatori unici. Ciò implica che il back office conosce l’identità degli infetti. Già lo diceva Ross Anderson. È ovvio che il back office può essere programmato in modo da non ricordare, o meglio dimenticare, l’identità degli infetti. In altre parole, dopo averla verificata ed usata, il back office può cancellare l’identità di chi ha comunicato la propria lista dei contatti. Per verificare che il back office si ricordi di dimenticare non basta analizzare la app sul proprio smartphone.
Purtroppo, non basta nemmeno analizzare il codice del server del back office che autentica A o che riceve la lista. Basta una piccola applicazione, tecnicamente uno sniffer, che sia eseguito su qualche server del back office e semplicmente ricordi le richieste ricevute e le trasmetta ad un altro server, da qualche parte nel mondo o magari nella stessa stanza ma che non fa parte del back office. Molti economisti e molti virologi non sanno che esistono dei livelli di software sotto le app dei nostri cellulari ed i server e che attaccare questi livelli è il modo più semplice per rubare e manipolare le informazioni su cui poi app e server lavorano. Infatti, è bene ricordare, che la app e i moduli del back office non sono eseguite sull’hardware ma su altri pacchetti software e sapere cosa fanno questi pacchetti è fondamentale per capire se privacy e sicurezza sono rispettati. Scandalizzarsi perché una parte del back office viene collocata in un locale protetto e controllato vuol dire non avere idea dei possibili attacchi che si possono fare accedendo fisicamente alle macchine del back office.
Come già detto, nel caso centralizzato A può fornire il proprio consenso perché la sua identità venga comunicata ai servizi sanitari per una presa in carico e per la cura. In questo caso le informazioni su coloro che hanno fornito il proprio consenso devono essere adeguatamente protette e valgono tutte le considerazioni precedenti sui livelli di software che supportano i moduli del back office.
Un sistema di tracciamento decentralizzato
Un sistema di tracciamento però può anche funzionare in maniera decentralizzata. In questo caso, una persona A si registra e scarica la app che genera localmente gli identificatori unici per il tracing. Può essere problematico garantire che milioni di persone generino identificatori unici senza utilizzare una qualche caratteristica unica dello smartphone, eg codice IMEI e/o numero, che poi potrebbero facilitare la scoperta dell’identità di chi li ha generati, ma assumiamo che esista una soluzione per questo non banale problema. Per quanto riguarda il tracciamento, la app funziona come prima ovvero scambia il proprio identificatore con quelli con cui A è entrato in contatto e costruisce L(A). Quando A viene dichiarato infetto, L(A) viene caricata sul back office che la trasmette a tutte le app sugli smartphone registrati. Lo smarphone di B verifica se uno degli identificatori di B appartiene ad L(A) ed in questo caso B prenderà le opportune azioni. Questo approccio ha due problemi. Il primo è che deve esistere una qualche forma di autenticazione e controllo quando A carica L(A), semplicemente per evitare che qualcuno catturi identificatori a caso andando in giro e poi li carichi sul back office. Anche in questo caso, il back office deve usare e poi dimenticare questa informazione e, come in un sistema centralizzato, solo un esame complessivo può garantire il corretto comportamento del back office.
Ammettiamo di essere certi che il back office rispetti tutte le proprietà di privacy e sicurezza, sarebbe la prima volta che accade fin da subito, ma ammettiamolo. In un sistema decentralizzato, il problema è posto dalla app o meglio dalle altre app che lo smartphone esegue. Infatti, è molto semplice manipolare la app, o svilupparne una leggermente diversa, per ricordare, ad esempio, quando un certo identificatore è stato ricevuto. Quindi lo smartphone di B ora esegue la app ufficiale ed una altra app che gli dice, ad esempio, quando e dove uno degli identificatori di A è stato ricevuto. In moltissimi casi, non è molto difficile per B capire chi è A ovvero, nel caso A sia infetto, non è difficile per B capire chi lo/la ha infettato. Anni di insulti sui vari social network ci permettono di capire cosa potrebbe succedere. La possibilità di risalire alle identità dei contatti spiega la scelta di INRIA e Fraunhofer Institute a favore di un protocollo centralizzato e vale la pena di riportare per intero il loro commento:
“Other, qualified as ‘decentralised’, schemes broadcast to each App an aggregate information containing the pseudonyms of all the infected users. This information allow each App to decode the identifiers of infected users and verify if any of them are part of its contact list. Our scheme does not follow this principle because we believe that sending information about all infected users reveals too much information. In fact, it has been shown that this information can be easily used by malicious users to re-identify infected users at scale. We claim that infected user re-identification must absolutely be avoided since it could lead to stigmatisation. Instead, we chose to securely store this information on a central server”.
In breve, utenti “maliziosi” possono modificare il loro smartphone, o usare un’altra app o un altro smartphone che eseguire una app diversa da quella standard e che riceve gli identificatori e li accoppia con informazioni per risalire all’identità dei vari contatti. Sviluppare un’applicazione del genere non è difficile, diciamo una tesi di laurea triennale in informatica, e se qualcuno lo fa e la mette in vendita, magari nel dark web, potrebbe avere dei ritorni economici interessanti. Quasi tutti i ransomware che sono attivi in questi giorni sono più sofisticati e complessi e forse rendono meno redditizi economicamente. Inoltre, un app di questo tipo può essere interessante per una minaccia ibrida che volesse sfruttare il disagio in cui stiamo vivendo. Questa minaccia può sviluppare le app maliziose e distribuirle gratuitamente.
Il breve confronto tra sistema centralizzato e decentralizzato porta a concludere che un sistema centralizzato è l’unico che permette di controllare il rispetto della garanzia di anonimato. Questo controllo non si deve limitare alla app, ma deve coinvolgere tutti i moduli del sistema. È quindi necessaria una analisi complessiva del sistema che deve essere svolta da esperti nell’ottica di una peer review. È anche utile rendere il codice open source ma limitarsi a questo sperando che chi scopre vulnerabilità o problemi li comunichi perché chi deve rimedi si può rivelare una scelta non adeguata. Infatti, potrebbe essere molto più conveniente vendere l’informazione ad altri. Quindi, bene l’open source ma non per evitare una review seria e indipendente al sistema complessivo. Ovviamente, i risultati della review devono essere pubblici e deve essere altrettanto pubblico chi la ha condotta.
Le prestazioni del backoffice
Risolto i problemi legati alla privacy e alla sicurezza ne restano altri di cui poco si parla. Partiamo da quello delle prestazioni del back office. Il numero degli utenti e la frequenza delle interazioni tra smartphone e back office rendono la velocità delle risposte del back office fondamentale per determinare il successo e la diffusione del sistema di tracciamento, a maggior ragione quando il backoffice è centralizzato. Le soluzioni tecnologiche normalmente utilizzate per risolvere problemi di prestazioni come content delivery networks e caching possono non essere adatte, vista la criticità dei dati scambiati. Ridurre il numero di sistemi che memorizzano copie dei dati è fondamentale per evitare distribuzioni non controllate dei dati garantendo sicurezza e privacy.
Altro problema ancora troppo trascurato è quello dei falsi positivi e falsi negativi, ovvero contatti segnalati che non esistono o contatti che esistono ma non sono segnalati. Insieme a quello delle prestazioni questo problema può essere il punto chiave per determinare la popolarità di tutto il sistema di tracciamento e quindi della copertura della popolazione e della sua efficacia.
Infine, il sistema di tracciamento dovrà essere attivo per mesi, anni per i meno ottimisti. Come viene gestito, chi, quando, come applica le eventuali patch ai sistemi operativi, i database o installa le nuove versioni dei moduli? Passeranno 65 giorni prima di applicare una patch [1]? Chi controlla che le patch siano state applicate? Come scopriamo eventuali attacchi? In media possono essere necessari 6 mesi per farlo, come pensiamo di migliorare le cose per un sistema cosi critico? Rispondere è forse più importante per capire quale sicurezza e quale privacy possiamo attenderci che sapere se una app è open source oppure no. È notizia di pochi giorni fa che forse qualcuno attacca Linux, open source, da 8 anni. Vogliamo tenerne conto?
Complessivamente, il problema è complesso ed è opportuno parlare di tutti i vari aspetti, magari rispettando la competenza degli altri ed evitando sia facili semplificazioni sia di ridurre tutto a una diatriba tra trax e no trax, termini che qualificano solo chi li usa.
- Kenna Security and Cyenta Institure, Priorization to Prediction, Vol.5
