L’approccio al contact tracing (“exposure notification”, meglio) scelto da Apple e Google – a differenza di quello centralizzato che aveva caratterizzato in un primo tempo l’app Immuni scelta dal nostro Governo per la Fase 2 – rappresenta un compromesso per la privacy accettabile. Una scelta decisamente migliore, soprattutto per gli utenti, rispetto all’alternativa centralizzata che si era scelta in precedenza in Italia (e in genere in Europa).
Le due aziende hanno creato un framework basato sulla proposta iniziale di DP-3T – evolutosi di recente con numerosi aggiustamenti per fornire un più elevato livello di sicurezza – e che garantisce un protocollo decentralizzato per il tracciamento dei contatti.
Sussistono però diversi problemi di usabilità, di sicurezza e privacy.
E di fondo c’è, poco rilevato, il paradosso di una soluzione del tutto decentralizzata che è però del tutto centralizzata a livello di sviluppo e gestione del codice nelle mani dei due colossi.
Come funziona il sistema di Apple e Google, nel dettaglio
Il sistema, come già anticipato nelle scorse settimane, si basa sull’associazione di un ID ad ogni dispositivo su cui l’applicativo è installato. Tramite Bluetooth Low Energy questo ID è scambiato con gli altri dispositivi su cui l’applicativo è installato. Se un soggetto risulta positivo al virus, tramite un codice fornito dall’autorità sanitaria, trasmette il log degli ID con cui è entrato in contatto nei 14 giorni precedenti ad un server centrale che poi dirama un “avviso” agli ID con cui l’utente positivo è entrato in contatto.
I tecnici dei due colossi tech USA, venerdì sono scesi in maggior dettaglio con riguardo ai presidi privacy del loro servizio, precisando che il sistema genera l’ID dell’utente in maniera casuale (la preoccupazione di molti, sul punto, era che questo ID potesse essere generato con un modello matematico dai dati dell’utente, non ottenendosi così una reale pseudonimizzazione dei soggetti che utilizzano l’applicativo).
Il protocollo opererà generando una Temporary Exposure key, che viene ricreata ogni 24 ore. Questa chiave principale è ottenuta da un generatore crittografico e a sua volta viene utilizzata per derivare due chiavi ulteriori: la Rolling Proximity Identifier key (RPI Key) e la Associated Encrypted Metadata key (AEM key).
La RPI key serve a generare i Rolling Proximity Identifiers, ovvero gli ID trasmessi dai telefoni. Questi ID cambiano, assieme all’indirizzo MAC del trasmettitore bluetooth, ad intervalli di 10 minuti, in maniera coordinata ed uguale per tutti (ad esempio: ogni 10 minuti a partire dalla mezzanotte). Il pacchetto dati inviato da un telefono conterrà quindi un ID e dei metadati, questi ultimi cifrati con la AEM Key.
L’autorità sanitaria, plausibilmente a livello regionale o nazionale, deciderà i criteri e le soglie per avere un “contatto”, basandosi sulla durata dell’incontro e la distanza tra i soggetti. Per ogni contatto stabilito, il telefono registrerà il Rolling Proximity Identifier ed i relativi metadati ricevuti via Bluetooth. In ogni caso, al fine di tutelare la riservatezza degli incontri, nessun contatto verrà registrato per più di 30 minuti.
Quando un soggetto viene identificato come infetto, l’app procederà ad inviare al server di diagnostica le temporary exposure keys degli ultimi 14 giorni. Ad intervalli regolari l’app scaricherà dal server di diagnostica, di proprietà dell’autorità sanitaria, la lista delle Diagnostic Keys, ovvero una collezione di tutte le temporary exposure keys dei soggetti identificati come infetti. Una volta ottenute queste chiavi il telefono non dovrà far altro che rigenerare tutti i possibili Rolling Proximity Identifiers e controllare che non ci siano match con la propria lista interna.
Questo approccio consente di verificare la presenza di contatti, senza inviare dati sensibili ad un server centrale fintanto che non si viene identificati come infetti. L’utilizzo di chiavi che cambiano frequentemente mitiga il rischio di venir tracciati. Un potenziale attaccante potrebbe comunque collezionare, con un’antenna, i vari RPI ma non sarebbe comunque possibile risalire al dispositivo del proprietario o tracciarne gli spostamenti per più di dieci minuti.
I metadati inviati potranno contenere svariate informazioni, tra le quali la versione dell’app installata sul dispositivo del soggetto risultato positivo, e la potenza utilizzata per trasmettere il segnale Bluetooth (elemento utile per eliminare eventuali falsi positivi).
In caso di avvenuto contatto con una persona poi risultata infetta, l’app indicherà all’utente come procedere.
Apple e Google hanno ribadito che il sistema verrà rilasciato sotto forma di API (Application Programming Interface, ovvero le librerie che gli sviluppatori utilizzeranno per creare applicazioni di contact tracing) e potrà essere implementato in applicativi delle varie autorità statali.
Le API verranno rilasciate già il 28 di aprile mentre il codice non sarà disponibile al pubblico.
Nella fase successiva l’”applicazione” diventerà una vera e propria impostazione di sistema e sarà possibile “attivarla” o “disattivarla” e scegliere quali dati condividere. Sia Apple che Google rilasceranno degli update per i propri sistemi operativi che consentiranno di effettuare la tracciatura dei contatti senza alcuna applicazione. In caso di contatto positivo sarà il telefono stesso a notificare l’utente, ed a suggerire la relativa app da scaricare per segnalare l’evento all’autorità sanitaria.
I rappresentanti di Google e Apple hanno dato atto esplicitamente che il sistema è volontario, può essere disattivato dall’utente, e che comunque verrà integralmente disabilitato al cessare dell’emergenza sanitaria (anche se non è chiaro su quali basi i gestori delle due piattaforme “decideranno” il momento della fine dell’epidemia, verosimilmente in accordo con le autorità locali).
I cellulari esclusi dal contact tracing Apple e Google
Rimangono fuori da questa equazione, però, iPhone precedenti al 6S del 2015, smartphone Android senza i servizi Google (es. Huawei), Windows Phone e feature phone, questi ultimi ancora molto diffusi, specie tra le fasce più anziane della popolazione (secondo un rapporto del 2018 di comScore, il 23% degli italiani al tempo non possedeva uno smartphone e il dato, sebbene in rapida discesa, fa ben comprendere la difficoltà di raggiungere la “soglia” del 60% di download perché l’app Immuni sia efficace).
Perché le app hanno difficoltà a fare a meno del protocollo Apple-Google
In ogni caso, sembra solo teorica la possibilità di sviluppare app che facciano a meno di questo modello Apple-Google, magari per inseguire quello (più) centralizzato, come vogliono fare Francia e Regno Unito (ancora per molto non si sa; la Germania già ha cambiato idea, come l’Italia).
Significherebbe perdere tutti i vantaggi di funzionalità permessi dall’uso delle API, per ridurre per i falsi positivi ad esempio (vedi sotto). Ma c’è un problema anche con i falsi negativi.
Come segnalato nella documentazione tecnica relativa all’app Immuni, uno dei principali problemi relativi al funzionamento dell’app è proprio quello dei limiti imposti dai sistemi operativi iOS e Android alle app “ordinarie”. Ad esempio:
- il sistema operativo iOS pone significative limitazioni al funzionamento continuo di app in background e al pieno controllo della comunicazione tramite Bluetooth;
- Il sistema operativo Android può talvolta terminare le app attive in background, causando l’interruzione delle operazioni in atto.
Gli sviluppatori hanno trovato workaround per aggirare il problema, ma con dubbia efficacia. Per questo motivo da più parti si sono levate richieste a Google e Apple di concedere “accessi speciali” alle app dedicate al contact tracing.
I due colossi USA paiono però orientati a proseguire nello sviluppo delle loro librerie, garantendo questi privilegi solamente passando attraverso il loro protocollo congiunto per il tracciamento.
Il modello DP-3T
Sotto l’ombrello del progetto PEPP-PT (iniziativa di cui fa parte anche Bending Spoons) è stata inizialmente proposta la soluzione definita DP-3T, sigla che sta per “Decentralized Privacy-Preserving Proximity Tracing” (progetto menzionato anche nella nota del 21 aprile 2020 del Ministero per l’innovazione tecnologica e la digitalizzazione).
L’applicativo, descritto in un white paper diffuso il 3 aprile scorso, è una soluzione basata sul principio cardine della decentralizzazione, che secondo gli sviluppatori è l’architettura che garantirà il massimo rispetto della privacy degli utenti.
L’8 aprile i fautori del protocollo DP-3T si sono distaccati dall’iniziativa PEPP-PT (pur riconoscendone l’importanza quale motore di condivisione e di sviluppo di iniziative sul tema), desiderando valorizzare il proprio specifico approccio in tema privacy.
Le implementazioni per Android e iOS del sistema (in versione Alpha) sono disponibili per il download sul sito del progetto e sono rilasciate in licenza Open Source.
Il team DP-3T ha accolto con favore il progetto congiunto di Apple e Google, affermando che lo stesso accoglie numerosi dei tratti della loro soluzione, ma evidenziando che i due colossi tech dovranno adottare anche i successivi presidi adottati dal protocollo DP-3T, descritti negli aggiornamenti del white paper del progetto.
La fase di verifica degli avvenuti contatti
Nel rispondere alle critiche su privacy e sicurezza, i colossi USA hanno anche modificato la loro comunicazione del progetto, che da sistema di “contact tracing” ora passa a chiamarsi sistema di “exposure notification”, per evidenziare che si tratta solamente di un tassello da includere nei più ampi sforzi di tracciamento del contagio che potranno essere messi in pratica dalle autorità, sono anche state diffuse delle FAQ per aiutare a spiegare in termini accessibili il funzionamento del sistema.
Ancora avvolta nel mistero resta però la fase di “verifica” degli avvenuti contatti, fase cruciale per eliminare i falsi positivi, segnalando il potenziale contagio solamente se c’è stato un contatto significativo.
Il Bluetooth è una tecnologia che consente di rilevare solamente se due dispositivi sono stati “a contatto”, ma non dà informazioni ulteriori, rendendo così difficile distinguere situazioni di potenziale contagio (es. due colleghi che hanno lavorato insieme o due persone che hanno affrontato un viaggio in treno insieme stando vicini fra di loro) da situazioni che non lo sono affatto (es. due persone sedute vicine in attesa nelle rispettive vetture o due persone che si incrociano per la strada).
Algoritmo vs i falsi positivi
Per escludere i contagi non significativi (“falsi positivi”) è essenziale quindi che oltre al log dei contatti siano trasmessi dati ulteriori (appunto ad esempio la potenza del segnale bluetooth del dispositivo, l’intensità del segnale e la durata del contatto) e soprattutto che questi dati ulteriori siano messi a sistema e valutati (verosimilmente in automatico) escludendo da segnalazioni tutti i contatti sotto la soglia definita dall’autorità.
Una simile attività (e la sua efficace comunicazione) sono essenziali anche per garantire la fiducia nell’applicativo e il suo successo.
Per fornire il dato relativo alla distanza, il sistema effettua una comparazione tra l’intensità del segnale Bluetooth dei dispositivi coinvolti e approssima così l’effettiva distanza tra i soggetti. Apple e Google precisano però, sul punto, che l’intensità del segnale può variare in maniera significativa sulla base di una pluralità di fattori, difficilmente prevedibili, quali il fatto che il dispositivo sia tenuto in mano o in tasca, l’orientamento, etc.
I problemi del bluetooth (falsi positivi) e le soluzioni
Del resto, è esperienza comune quella di estrarre dalla tasca lo smartphone e cercare la posizione più “consona” (magari rivolgendolo al cielo) per cercare di ottenere più segnale di rete. Allo stesso modo anche la posizione e inclinazione dell’antenna bluetooth influiscono, pur a parità di RSSI (Received Signal Strength Indicator), sulla distanza e quantità dei dispositivi che possono “agganciarsi” al mio segnale Bluetooth, ottenendo i reciproci ID se entrambi abbiamo attivato l’applicativo di contact tracing.
Quindi una situazione di attesa alla fermata del bus o di viaggio sui mezzi pubblici, momento in cui molti stanno guardando il telefono per far passare il tempo (presumibilmente a dovuta distanza di sicurezza fra di loro) è più “a rischio” contatto via Bluetooth di un contatto anche prolungato al supermercato (magari una chiacchierata con un amico che non vedo da tempo a causa delle misure di contenimento), quando i nostri dispositivi sono protetti da strati di tessuto e forse orientati in maniera tale da rendere difficoltoso lo scambio degli ID. O si può pensare a situazioni comuni in abitati ad alta densità, il Bluetooth infatti, pur percorrendo generalmente brevi distanze, può attraversare i muri e due soggetti che ad esempio lavorano al computer e sono separati da una parete, possono venir continuamente registrati come contatti.
Contro il rischio falsi positivi, Google e Apple abilitano adesso (appunto) l’accesso degli sviluppatori delle app a parametri e funzioni bluetooth prima non operabili. Così almeno sarà possibile provare a regolare la potenza del segnale per arrivare a un algoritmo in grado – con tentativi ed errori – di essere sempre più affidabile a determinare quale sia la distanza reale tra i dispositivi e il tempo effettivo di esposizione.
Cresce la consapevolezza degli esperti, però (Bluetooth contact tracing needs bigger, better data, Mit Technology Review) che tutto questo non basti. La soluzione passa probabilmente dai big data. In generale, servono molti dati per avere un algoritmo affidabile in un contesto di realtà non prevedibile (tale è quella del contact tracing).
Per evitare falsi positivi quindi sarebbe necessario utilizzare più dati di altri sensori, aumentando così la mole di dati scambiati e trasmessi, appesantendo il sistema e ottenendo più dati personali dei soggetti che scaricano l’applicativo
È chiaro però che le soluzioni (che esistono) per risolvere una simile problematica hanno delle severe controindicazioni dal punto di vista privacy.
Le controindicazioni privacy
Ad esempio, si parla spesso di utilizzare GPS o WiFi per eliminare falsi positivi, ma è evidente che così facendo la mole dei dati personali trattati diventa molto più intensa in quanto non so più solo con chi un utente è stato a contatto, ma anche dov’era quando questo è avvenuto, magari rivelando così dati sanitari o relativi ad un’appartenenza ad un credo o religione o altro.
Altre idee più raffinate (che appesantiscono comunque il sistema ma sono molto meno invasive dal punto di vista privacy) suggeriscono di utilizzare altre tipologie di sensori, più specifiche, per capire in che posizione era lo smartphone quando è avvenuto il contatto (ad esempio accelerometro e giroscopio per capire come era orientato il dispositivo, il sensore di luminosità ambientale per capire se vi è una “barriera” fra il telefono e l’esterno, come ad esempio una tasca o una borsa, e capire quanto questa può incidere sul contact tracing).
È evidente però che stiamo parlando (sul lato Android) di uno sforzo considerevole nel momento della verifica, in quanto dovremmo mettere a sistema questo dato con l’orientamento di ogni singola antenna Bluetooth di ogni coppia di dispositivi “abbinati” dal sistema per poter assegnare un valore effettivo all’inclinazione del telefono ad esempio.
La soluzione migliore quindi è forse quella di dar corso a sperimentazioni le quali consentano di capire la frequenza degli abbinamenti Bluetooth in reali situazioni d’uso e con dispositivi reali, calibrando quindi a ritroso le soglie di intensità e i sensori necessari per evitare falsi positivi. È estremamente probabile che il sistema andrà affiancato da team di contact tracer capaci di verificare i contatti e riportare, o gestire, l’inevitabile mole di falsi positivi a cui, per forza di cose, andremo incontro.
Da questo punto di vista preoccupa il fatto che Google e Apple sembrino intenzionate a lasciare alle autorità nazionali la scelta sulle soglie di intensità da ritenere rilevanti. Se minime variazioni sono giustificabili dal contesto sociale e della densità di abitazione di un singolo paese, è chiaro che deve trattarsi di una scelta ben studiata ed indirizzata da chi fornisce il servizio e lo conosce meglio.
Restano inoltre da chiarire alcuni punti, ad esempio Apple e Google hanno confermato che non monetizzeranno i dati provenienti dal progetto, ma non è chiaro quali siano questi dati, sappiamo solo che non sono identificativi dei soggetti con cui gli utenti sono venuti a contatto. Non è ancora chiaro il processo con cui gli utenti verranno contrassegnati come infetti e se sarà necessaria o meno la conferma dell’autorità sanitaria. In ultimo sarà anche importante capire se le app verranno verificate, per assicurarsi che si comportino in maniera coerente con il progetto, al fine di garantire che non contengano tracker e che non inviino più dati dello stretto necessario.
La sicurezza del sistema
Al di là dei falsi positivi esiste un’altra categoria di problemi da gestire, parliamo infatti della sicurezza del sistema da attacchi mirati, un esempio immediato è quello di un attaccante dotato di antenna, in grado di ricevere segnali da una zona considerevolmente ampia. Tale attaccante potrebbe generare contatti sia in ingresso che in uscita, ad esempio inviando tramite antenna dedicata i suoi ID nella zona coperta, e ricevendo quelli che un normale smartphone non sarebbe in grado di rilevare. Questo ed altri problemi sono comunque mitigati nelle versioni successive alla prima del framework DP-3T, sebbene al costo di un carico computazionale e traffico dati discretamente più elevati.
In particolare, il progetto DP-3T ha introdotto un ulteriore livello di sicurezza per scongiurare attacchi esterni tesi a raccogliere un elevato numero di ID con apparecchiature specialistiche (es. antenne ad ampio raggio) al fine di carpire dati degli utenti (specie unendo ai dati ottenuti metadati o informazioni ottenibili dall’applicativo, quali la positività al virus o il potenziale contagio “da contatto”).
Per rispondere a queste potenziali minacce, il team DP-3T ha pensato al sistema “EphID Spreading With Secret Sharing”.
In buona sostanza gli ID vengono diffusi secondo uno schema di condivisione segreto del tipo “k-out-of-n”. Invece di trasmettere l’ID al momento del contatto, lo codifichiamo in “n” condivisioni, in modo tale che ogni ricevitore debba ricevere almeno “k” condivisioni per ricostruire l’ID.
Conclusioni
Il protocollo adottato da Apple e Google, sebbene non ancora perfetto, rappresenta una buona scelta, in grado di risolvere alla base il problema di avere una miriade di applicazioni diverse, nessuna in grado di comunicare con le altre.
Un ecosistema frammentato avrebbe portato al fallimento certo di un’iniziativa così importante. Certamente però non dobbiamo dimenticare che il contact tracing è soltanto un singolo componente di un ampio meccanismo che necessita del supporto di più parti affinché l’intero processo funzioni a dovere.
In questo contesto si profila all’orizzonte uno scontro fra alcune nazioni europee (si parla in particolare di Regno Unito e Francia) e Google e Apple.
Se i colossi del tech americano hanno scelto la via della decentralizzazione, considerandola in linea con le garanzie privacy dovute ai loro utenti, è evidente che il contraltare di questa scelta è il fatto che Google ed Apple non supporteranno iniziative “centralizzate” portate avanti da singole nazioni; ossia per queste non rimuoveranno le limitazioni per le app in background né daranno il via libera al controllo dei sensori (da più parti richiesto in nome degli obiettivi sanitari ed emergenziali di questi applicativi).
Questa scelta potrebbe essere particolarmente incisiva quando si parla di ambiente iOS, che di default pone significative limitazioni al funzionamento continuo di app in background e al controllo della comunicazione tramite sensori.
L’altra faccia della medaglia è, infine, la chiusura di Google ed Apple a soluzioni parallele a quella da loro prescelta ed implementata, basate sul medesimo principio di decentralizzazione ma obbligate a adottare le librerie dei due colossi tech per aggirare le limitazioni di sistema.
