App coronavirus e sicurezza informatica: tutti i problemi e come affrontarli

Molte applicazioni di contact tracing per il coronavirus non garantiscono la sicurezza dei dati raccolti e (di conseguenza) la privacy delle persone. Ad esempio, nel mondo esistono 43 applicazioni per il tracciamento ma circa il 30% di loro non adotta nessun meccanismo di sicurezza.

Un dato di fatto con cui bisognerà fare i conti, mentre è opinione comune che una app per lo smartphone sia la soluzione più semplice ed efficace per tracciare persone potenzialmente infette a cui applicare misure sanitarie.

Molte delle strategie di progetto di queste applicazioni utilizzano l’approccio di “aggiungere” la sicurezza informatica a posteriori dimenticando come questo approccio abbia prodotto le decine di data breach degli ultimi anni con la diffusione dei dati personali di milioni di persone. Si utilizza l’approccio della sicurezza “aggiunta” quando, ad esempio, si adotta un approccio “data driven” per scegliere applicazioni per il tracciamento delegando la sicurezza informatica ad altri che devono operare successivamente. Anche quando ci si preoccupa della privacy si dimentica della sicurezza informatica, come se fosse possibile avere la prima senza la seconda.

I diversi problemi di sicurezza e privacy per le app coronavirus

Per descrivere i problemi di sicurezza e privacy da affrontare nello sviluppo di un sistema per il tracciamento è utile distinguere tra due tipi di sistema che corrispondono ai fondamentali contesti di utilizzo dei dati generati dal sistema stesso 1, 2, 3. Il primo tipo di sistema è progettato per un contesto che, per brevità, indichiamo sinteticamente con strategico perché il sistema viene sviluppato per raccogliere dati di supporto alle decisioni politiche sulla gestione dell’emergenza e per fornire al singolo cittadino informazioni sul suo stato di salute e le potenziali infezioni. Tipica decisione politica che utilizza i dati raccolti da un sistema strategico è se terminare il lockdown o ripartire, in quali luoghi geografici ed in quali contesti – industria, centri commerciali, scuole o università – si ha una maggiore diffusione del virus. Le informazioni per il singolo cittadino riguardano il suo stato di salute, la sua potenziale infezione, il rischio che sta correndo e quello per gli altri.

Il secondo contesto di utilizzo che, con altrettanta sinteticità, indicheremo con personale, è quello in cui il sistema raccoglie e gestisce unicamente le informazioni su contatti avuti dalla singola persona, senza informazioni di dove e quando i contatti sono avvenuti o sull’identità delle persone coinvolte. Assumiamo per il momento che la distinzione tra i due contesti sia netta ed esaminiamo i problemi di sicurezza condivisi o specifici di ogni contesto.

Un sistema per un contesto strategico raccoglie informazioni geolocalizzate sulle posizioni di ogni smartphone, e quindi sui contatti di ogni persona. I dati raccolti devono necessariamente essere geolocalizzati perché questo è l’unico modo di scoprire i luoghi più esposti ai pericoli di infezioni. I dati raccolti vengono memorizzati e gestiti in un backoffice che comprende un insieme di server interconnessi. I server del backoffice analizzano i dati per scoprire quante persone erano in un certo luogo ma anche per rintracciare i potenziali infetti e pianificare dove servire un certo servizio sanitario o dove creare ospedali di emergenza. La granularità della localizzazione varia, ad esempio quella inglese usa i codici postali ma comunque esiste. Anche se assumiamo che l’informazione raccolta dal singolo smartphone sia anonima, perché non contiene informazioni sull’identità del proprietario, numerose ricerche hanno dimostrato che la localizzazione permette di risalire facilmente alle identità specialmente se chi gestisce il sistema ha a disposizione altre informazioni, ad esempio le carte di credito utilizzate in un centro commerciale. Il problema della deanonimizzazione dei dati raccolti può essere meno rilevante se il sistema è gestito da un ente pubblico ma questo può porre il problema dei tempi e delle risorse per la costruzione del sistema su cui torneremo nel seguito.

Un sistema per il contesto personale utilizza strategie p2p per gestire in modo decentralizzato la raccolta di informazioni sui contatti. In un sistema di questo tipo, la app eseguita su ogni smartphone genera in maniera pseudocasuale degli identificatori temporanei che distribuisce agli altri smartphone con cui entra in contatto via Bluetooth. L’uso di identificatori temporanei impedisce il tracciamento della persona che usa lo smartphone. L’applicazione inoltre ricorda su ogni smartphone gli identificatori temporanei ricevuti da quelli delle persone con cui si è entrati in contatto. In questo sistema problemi di prestazioni del backoffice sono meno critici perché il backoffice viene utilizzato solo per caricare gli identificatori temporanei utilizzati da un infetto e trasmetterli a tutti gli altri smartphone. Questa diffusione permette a tutti gli smartphone che ricordano almeno uno degli identificatori temporanei trasmessi di avvertire il proprietario della potenziale infezione. Uno smartphone elimina gli identificatori ricevuti dopo un tempo che dipende dal tempo di incubazione della malattia, circa 14 nel caso del CoVid-19. Gli smartphone cancellano autonomamente e gradualmente tutti gli identificatori quando l’infezione viene eliminata.

La peer review del codice del sistema, prima soluzione

Un primo requisito, del tutto ovvio e scontato quando si parla di sicurezza informatica e che vale per entrambi i contesti, è la peer review del codice del sistema. La review deve applicare un insieme di analisi standard che vanno dal vulnerability scanning al fuzzing. Ovviamente, il fatto che il codice della app sia open source facilita la peer review ed aumenta il numero dei reviewer. Un punto che però è spesso trascurato è che la review deve analizzare il codice di tutto il sistema per la raccolta e gestione dei dati e non solo l’applicazione per lo smartphone. Ogni sistema ha un backoffice, una infrastruttura formata da sistemi hardware e software per la raccolta, la memorizzazione e la gestione dei dati di raccolti. Per questo occorre considerare tutto il sistema e non solo l’applicazione. Focalizzarsi sull’applicazione ci fa dimenticare che quando un cellulare scambia una qualunque informazione con il backoffice deve essere autenticato, occorre creare dei backup dei dati raccolti, patchare le vulnerabilità del backoffice ed eseguire le normali attività di amministrazione. Queste attività sono critiche perché i dati gestiti dal backoffice non sono anonimi. Inoltre, lo scambio di dati tra i vari smartphone offre numerose opportunità ai malintenzionati di inviare dati manipolati che potrebbero essere usati per attaccare il backoffice. Ciò richiede rigorosi controlli sui dati che il backoffice riceve per individuare dati malevoli. Le indicazioni suggerite da ENISA 4 per la sicurezza informatica devono essere applicare a tutto il sistema e non solo alla app.

Dimenticare il backoffice e focalizzarsi solo sull’adozione di un app open source può far trascurare problemi di sicurezza altrettanto importanti. Sarebbe bello ragionare sulla sicurezza di un sistema in modo modulare, valutando la sicurezza del singolo modulo, ma sappiamo da tempo che la sicurezza non può essere affrontata in questo modo.

I problemi di sicurezza di un sistema per il contesto strategico

L’analisi dei problemi di sicurezza di un sistema per il contesto strategico è già stata magistralmente sviluppata da Ross Anderson 5 che solleva problemi non banali. Il primo è l’anonimato che è difficile da garantire quando la persona che viene segnalata infetta o potenziale infetta deve essere contattata dal servizio sanitario. Il problema è indipendente dalla specifica tecnologia o soluzione utilizzate perché ogni sistema, indipendentemente dal contesto in cui opera, deve trasmettere i dati delle persone infette all’ufficio competente del servizio sanitario. Da questo momento, ogni anonimato cessa. Questo vale, o dovrebbe valere, anche per un sistema per il contesto personale perché pare assurdo non coinvolgere il servizio sanitario nella gestione delle informazioni su infetti o potenziali infetti. In questo caso, ad esempio, la persona potenzialmente infetta può decidere volontariamente di fornire le proprie informazioni personali, che il backoffice raccoglie e gestisce in appositi database da proteggere opportunamente. Se teniamo conto del volume delle informazioni di cui stiamo parlando, alcuni milioni di cittadini se consideriamo i potenziali infetti, anche il progetto di un sistema per il contesto personale deve decidere come gestire le infrastrutture del backoffice, se e quando eliminarle, come distruggere i dati ancora contenuti. Infatti, questa parte del sistema non viene cancellata quando gli smartphone smettono di raccogliere informazioni sui contatti. Ciò pone problemi di privacy altrettanto importanti di quelli del tracciamento e delle applicazioni.

Anderson evidenzia un problema comune ad ogni sistema di rilevazione di eventi ma di cui poco si parla, quello dei falsi positivi e negativi. Questi problemi sorgono sia in sistemi per il contesto strategico che in quelli per il contesto personale ed influenzano significativamente la qualità e l’accuratezza dei dati raccolti. Un sistema produce un falso positivo quando segnala un contatto che non è avvenuto mentre il mancato segnale di un contatto che è avvenuto corrisponde ad un falso negativo. Il problema dei falsi positivi non dipende dalla soluzione tecnologica utilizzata perché può verificarsi sia in sistemi che decidono l’avvenuto contatto mediante geolocalizzazione che mediante Bluetooth. Infatti, non sempre la vicinanza tra due smartphone corrisponde ad una potenziale trasmissione del virus.

Consideriamo due stanze contigue ed una persona in ogni stanza. Non conoscendo il muro che divide le persone, una app può segnalare un contatto perché la distanza tra i cellulari è inferiore ad un valore di soglia o i due cellulari riescono a scambiarsi gli identificatori. Se le due stanze sono spazi pubblici dove si recano molte persone, ad esempio due ambulatori medici, il numero dei falsi positivi aumenta perché la app si comporta come se ogni medico avesse visitato tutti i pazienti. Se uno dei medici si ammala, solo il 50% dei contatti segnalati dalla app è avvenuto davvero. Altri esempi sono quello di due uffici di docenti universitari e degli studenti che vi passano o quello di una coda di auto 6. Ross Anderson è particolarmente perfido e si diverte ad immaginare falsi positivi dovuti a qualcuno che lega il proprio smartphone ad un cane che poi manda a spasso in un quartiere. Il costo di un falso positivo dipende dal tipo di trattamento che si prevede di applicare ai potenziali infetti, all’aumentare di questo costo un alto numero di falsi positivi riduce la convenienza del sistema. È ben noto che molti strumenti di sicurezza informatica non riescono a diffondersi proprio per l’alto numero di falsi positivi che generano. Il problema dei falsi negativi sembra ad una prima analisi di minore impatto perché dovuto a particolari eventi non particolarmente probabili. Ad esempio, il raggio d’azione del virus potrebbe essere esteso da un forte vento. Un caso a parte sono i falsi negativi dovuti a mancata alimentazione del cellulare visto che il consumo dovuto ad una applicazione Bluetooth può essere alto. Infine, in ambienti con numerose persone qualche contatto potrebbe essere perso perché lo smartphone non riesce a memorizzare tutti gli identificatori ricevuti. Ovviamente questo scenario può essere improbabile in tempi di social distancing.

I problemi di sicurezza di un sistema per il contesto personale

Un problema specifico del sistema per contesto personale è la generazione pseudo casuale degli identificatori temporanei. Eventuali correlazioni tra i vari identificatori per la stessa persona potrebbero ridurre l’anonimato. Questo problema diventa più importante se i vari identificatori sono memorizzati non solo negli smartphone ma anche nel backoffice, ad esempio per analisi statistiche sulla diffusione dell’epidemia. Problemi simili hanno invalidato sistemi di voto elettronico, per ultimo quello proposto dalla Svizzera 7. Comunque, un uso pesante della criptografia può aumentare significativamente la complessità e la fragilità di un sistema.

Abbiamo più volte sottolineato l’importanza della parte di backoffice dei sistemi. La sicurezza dei dati gestiti è ovviamente critica ma anche le prestazioni lo sono. Ad esempio, un sistema per un contesto strategico deve ricevere una grande quantità di dati, almeno sui contatti del 60% della popolazione per essere efficace. Sistemi utilizzati dal 10-15% della popolazione si sono rivelati controproducenti 5. Anche assumendo che ogni smartphone possa memorizzare una grande quantità di dati e trasmetterla poche volte al giorno, i volumi in gioco sono di assoluto rilievo ed aumentano con la diffusione dell’app. Pensare di aumentare il carico di banda di rete e di elaborazione su un sistema preesistente non è possibile, anche se il sistema fosse sottoutilizzato. Occorrono quindi nuovi sistemi ed anche nuove connessioni. Il tempo per costruire il tutto è ovviamente critico e non si può pensare di accelerare sfruttando sistemi non pubblici. Il grande volume di dati generati ha un valore troppo elevato ed è estremamente difficile pensare che un soggetto privato rinunci ad analizzare questi dati, anche se in forma anonima. Inoltre, i dati diventano un bersaglio non solo per il cybercrime ma anche per altri stati. Le contromisure informatiche necessarie hanno costi elevati e la loro adozione potrebbe non essere conveniente per un soggetto privato. Il problema esiste anche per un sistema per il contesto personale e la sua gravità dipende dalla quantità di informazioni gestite sul backoffice.

Una considerazione sull’adesione volontaria al sistema per un contesto personale. Un’applicazione può essere poco attrattiva se alla segnalazione di un possibile contagio non è associata anche l’indicazione di dove rivolgersi per un’analisi che fornisca risultati in tempi brevi. Una ridotta attrazione provoca un abbandono dell’applicazione con le conseguenze che è facile immaginare. Anche in questo caso una bassa adesione può invalidare l’efficacia e la convenienza del sistema. Come al solito, non è la tecnologia che può risolvere completamente il problema.

Due considerazioni finali. La prima è che giudizi di sicurezza e privacy devono sempre considerare il sistema complessivo e non un singolo modulo. La seconda è l’ultimo suggerimento di Ross Anderson ai tecnologi che secondo lui “must not give policymakers the false hope that techno-magic might let them avoid the hard decisions”.

_________________________________________________________________________________

Riferimenti

1. C. Frediani, Emergenza Covid-19 e misure tech, Emergenza Covid-19 e misure tech, https://www.valigiablu.it/coronavirus-emergenza-tecnologia/
2. Audizione informale, in videoconferenza, del Presidente del Garante per la protezione dei dati personali sull’uso delle nuove tecnologie e della rete per contrastare l’emergenza epidemiologica da Coronavirus Commissione IX (Trasporti, Poste e Telecomunicazioni) della Camera dei Deputati, 8 aprile 2020
3. R.Rivest et al, The PACT protocol specification, version 0.1, 4/8/2020
4. eHealth Network, Mobile applications to support contact tracing in the EU’s fight against COVID-19, Common EU Toolbox for Member States, Version 1.0, 15.04.2020
5. R. Anderson, Contacts Tracing in the Real World, https://www.lightbluetouchpaper.org/2020/04/12/contact-tracing-in-the-real-world/
6. P. Attivissimo, https://www.zeusnews.it/n.php?c=28021
7. S. Jamie Lewis, O. Pereira and V. Teague, Trapdoor commitments in the SwissPost e-voting shuffle proof, https://people.eng.unimelb.edu.au/vjteague/SwissVote