close
agenda digitale

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

no thumb

I problemi di sicurezza cyber da affrontare nello sviluppo di un sistema/app per il tracciamento dei contatti anti coronavirus sono diversi. 

Analizziamoli, con le possibili contromisure per massimizzare l’efficacia delle tecnologie volte a limitare la diffusione dei contagi covid-19 14 minuti fa Fabrizio Baiardi Università di Pisa 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. Indice degli argomenti I diversi problemi di sicurezza e privacy per le app coronavirus La peer review del codice del sistema, prima soluzione I problemi di sicurezza di un sistema per il contesto strategico I problemi di sicurezza di un sistema per il contesto personale 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.

Tags : appletechnologyyoung
carlo

The author carlo

Leave a Response