Le app di tracciabilità di dispositivi mobili e smartphone sono ormai un fatto consolidato e vengono utilizzate per i servizi più disparati: esse sfruttano principalmente tecnologie di geolocalizzazione ed inseguimento del dispositivo su base satellitare GPS o attraverso algoritmi di triangolazioni del segnale su base cella (SRB) e l’utilizzo aggiuntivo del Bluetooth consente l’implementazione di algoritmi di prossimità e contact tracing definibili tra due o più dispositivi in un raggio di alcuni metri.
Di recente, per la tracciabilità Covid-19 sono state sviluppate numerose app specifiche da società specializzate come l’israeliana Hamagen (The Shield), l’app TraceTogether di Singapore oppure l’app Corona100 della Corea del Sud.
Tra le più attese a livello internazionale annoveriamo l’app che scaturisce dalla collaborazione dei due colossi statunitensi Google ed Apple.
Le Application Program Interface di Google (usate dall’app sviluppata dai due colossi) sono, ad oggi, tra le più utilizzate nel modo degli sviluppatori di servizi di georeferenziazione e, come dichiarato sul sito ufficiale di Google, sono previste due fasi di sviluppo in itinere: nella prima fase di maggio 2020, le due aziende rilasceranno API per consentire l’interoperabilità fra i dispositivi Android e iOS delle app sviluppate dalle autorità sanitarie per fronteggiare l’emergenza.
Queste app ufficiali potranno essere scaricate dagli utenti attraverso i rispettivi app store.
Nella seconda fase, nei prossimi mesi, Apple e Google lavoreranno per rendere disponibile una più ampia piattaforma di contact tracing basata su Bluetooth.
In Italia, l’app Immuni è l’applicazione per smartphone scelta per il tracciamento e contenimento del contagio da Covid-19 che sfrutterà API Google. Sviluppata e offerta da Bending Spoons S.p.A. a titolo gratuito, sarà pubblicata con licenza open source Mozilla Public License 2.0.
Relativamente allo sviluppo di questa specifica tipologia di app, l’Unione Europea ha rilasciato inoltre alcune specifiche contenenti informazioni sulla privacy e sul GDPR, che gli sviluppatori di tali app del tipo contact tracing sono tenuti a rispettare.
Il funzionamento del contact tracing Google.
Indice degli argomenti
Il funzionamento dell’app di contact tracing
La generica app che implementa la tecnologia di contact tracing può far uso di uno dei seguenti protocolli:
- DP-3T (Consorzio Mondiale);
- PEPP-PT (Consorzio Europeo);
- ROBERT (Inria – Fraunhofer).
Funzionamento del contact tracing.
Essa farà uso della connettività Bluetooth, ed in particolare BLE (Bluetooth Low Energy), per tracciare le posizioni degli smartphone e quindi dei loro utenti.
Ogni smartphone genera un ID anonimo temporaneo, che viene trasmesso e registrato da tutti gli smartphone vicini. Questo ID viene rinnovato periodicamente (ogni quarto d’ora circa).
Quando un utente risulta infetto, il suo ID viene caricato su un server e tutti gli altri utenti che sono stati a contatto con esso vengono notificati.
L’hashing dell’ID è effettuato in maniera tale da non poter risalire all’infetto che lo ha generato. L’approccio scelto è il meno centralizzato possibile: invece di memorizzare tutte le posizioni degli utenti in un server, quest’ultimo conterrà solo l’ID di chi è risultato infetto.
Contact tracing: le vulnerabilità del Bluetooth Low Energy (BLE)
In una applicazione che fa uso principalmente della tecnologia BLE, sono individuabili una varietà di attacchi (qui e qui) riportati nella tabella seguente.
| ATTACCHI ALLA COMUNICAZIONE BLE | |
| Attacco | Vulnerabilità |
| KNOB | Manipolazione del dispositivo remoto per negoziare chiavi di encryption con 1 byte di entropia e quindi facilmente suscettibili ad attacchi Brute-Force. Alcuni dispositivi a partire dal 2018 hanno ricevuto una patch. |
| MITM (man-in-the-middle) | È possibile monitorare la comunicazione tra due dispositivi e inviare alcuni frame per scopi malevoli. |
| Link Layer Length Overflow | Generazione di buffer overflow che comportano un Denial of Service. |
| Link Layer LLID deadlock | Generazione di un deadlock che comporta quindi un Denial of Service. |
| Truncated L2CAP | Generazione di un Denial of Service che comporta un crash del dispositivo. |
| Silent Length Overflow | Generazione di buffer overflow che comporta un crash del dispositivo. |
| Invalid Connection Request | Generazione di un deadlock che comporta quindi un Denial of Service. |
| Unexpected Public Key Crash | Denial of Service o possibile riavvio del dispositivo. |
| Sequential ATT Deadlock | Generazione di un deadlock che comporta quindi un Denial of Service. |
| Invalid L2CAP fragment | Gestione impropria della dimensione dei pacchetti PDU che può portare ad un comportamento di deadlock. |
| Key Size Overflow | Combinazione di più bug rilevati durante la procedura di associazione dei dispositivi, che porta ad un crash. |
| Zero LTK Installation | Variazione del sopracitato Key Size Overflow. |
Tutti i problemi di questa tecnologia risiedono essenzialmente nel modo in cui i kit di sviluppo software (SDK) utilizzati da più sistemi sulle varie tipologie di chip (SoC, System on Chip) hanno implementato la tecnologia di comunicazione wireless Bluetooth Low Energy (BLE), producendo ad oggi alcune centinaia di prodotti distinti di diversi fornitori tra cui Samsung, FitBit e Xiaomi.
Quindi gli hacker in stretta vicinanza fisica ai dispositivi vulnerabili possono abusare di questa vulnerabilità per attivare in remoto deadlock, DoS, crash e persino bypassare la sicurezza nei prodotti con privilege escalation, consentendo loro di accedere in modo arbitrario a lettura o scrittura alle funzioni del dispositivo che altrimenti potrebbero essere accessibile da un utente autorizzato.
Questo è l’elenco completo codificato delle Common Vulnerabiity Exposure (CVE) relative alla tecnologia BLE:
- Link Layer Length Overflow (CVE-2019-16336, CVE-2019-17519) — These allow attackers in radio range to trigger a buffer overflow by manipulating the LL Length Field, primarily leading to a denial of service attacks.
- Link Layer LLID deadlock (CVE-2019-17061, CVE-2019-17060) — These trigger deadlock state when a device receives a packet with the LLID field cleared.
- Truncated L2CAP (CVE-2019-17517) — This flaw results due to a lack of checks while processing an L2CAP packet, causing a denial of service and crash of the device.
- Silent Length Overflow (CVE-2019-17518) — A buffer overflow occurs when a certain packet payload with higher than expected LL Length is sent, the peripheral crashes.
- Invalid Connection Request (CVE-2019-19195) — When devices do not properly handle some connection parameters while the central attempts a connection to the peripheral, they could lead to Deadlock state.
- Unexpected Public Key Crash (CVE-2019-17520) — This bug is present in the implementation of the legacy pairing procedure, which is handled by the Secure Manager Protocol (SMP) implementation and can be used to perform DoS and possibly restart products.
- Sequential ATT Deadlock (CVE-2019-19192) — This flaw lets attackers deadlock the peripheral by sending just two consecutive ATT request packets in each connection event.
- Invalid L2CAP fragment (CVE-2019-19195) — improper handling of the PDU size of the packets can lead to deadlock behavior.
- Key Size Overflow (CVE-2019-19196) — This overflow in the device memory issue is a combination of multiple bugs found during the pairing procedure of devices, resulting in a crash.
- Zero LTK Installation (CVE-2019-19194) — This critical vulnerability is a variation of one of the Key Size Overflow. It affects all products using Telink SMP implementation with support for secure connection enabled. The detailed report says affected products include consumer electronics, smart home devices, wearables, and are also being used in the logistics and healthcare industry, malfunctioning of which can lead to hazardous situations.
Oltre alle vulnerabilità del BLE, possono essere presenti delle vulnerabilità a livello del Cloud Database e dei dati conservati localmente sui dispositivi con reali problematiche di data breach sui server centralizzati.
In generale l’utilizzo di database sottoposti alle specifiche NIST500-292 e NIST500-299 in grado di operare su big data e con ampia scalabilità e disponibilità di servizi open source, nonché l’ottimizzazione dei dati per l’implementazione di elevati livelli di sicurezza in quello che viene definito Secure Cloud Ecosystem Orchestration, è determinante quando si trattano dati sensibili come le anagrafiche di malati infettivi.
Le possibili contromisure
La principale contromisura alla vulnerabilità dei dati in una comunicazione in chiaro è ovviamente l’utilizzo di un protocollo crittografico sul canale comunicativo; questo, nel caso del BLE, implica il pairing (accoppiamento) tra i dispositivi, nel quale verrà scambiata la chiave per cifrare i dati.
Una delle principali accortezze, in attesa di ulteriori informazioni sull’implementazione lato software dell’applicazione, può essere l’utilizzo del miglior pairing method oltre che l’intercettazione e la segnalazione dei tentativi di accoppiamento.
Questa funzionalità può essere almeno parzialmente servita dal sistema operativo. La causa principale di rischio sta nel fatto che quest’app deve fornire la possibilità di effettuare la registrazione, in modo sicuro, di un numero molto elevato di contatti tra utenti.
L’attuale procedura di pairing.
Struttura di un pacchetto BLE.
Se si parla di un sistema di cifratura dei canali, l’elevata interazione implica la creazione di un numero spropositato di chiavi, spesso utili per pochissimo tempo.
Questo necessita di un determinato meccanismo di timeout delle stesse e un conseguente pairing periodico che aumenterebbe di molto la probabilità di sniffing dei pacchetti contenenti le chiavi.
Una possibile contromisura potrebbe essere quella di rendere “intelligente” l’algoritmo di timeout, rendendolo meno frequente, o inesistente, nel caso di ripetuti pairing tra gli stessi dispositivi. Purtroppo questo metodo non è sufficiente ad annullare il pericolo, ma per ulteriori considerazioni si dovrà aspettare la release dell’applicazione.
La disponibilità del codice in open source renderà ancora più facile emulare il comportamento di dispositivi aventi MAC Address clonati e parametri falsi.
Problemi di jamming, logic flaws e simili dipendono fortemente dall’implementazione software e dal metodo di cifratura del protocollo di comunicazione al livello di collegamento e al livello applicativo del protocollo proprietario.
Tuttavia, la ricerca di alternative efficienti ed applicabili al nostro scenario che rendano nullo, o anche solo basso, il rischio di intercettazione passiva ed attiva dei dati sembra essere il punto più importante e complesso dello sviluppo di questo progetto.
È su questa criticità che teniamo a dirigere l’attenzione del lettore.
L’ultima osservazione nel merito della sicurezza tramite canali cifrati, alla luce di quanto abbiamo detto, sta nel fatto che una tale implementazione non risolverebbe completamente o sufficientemente le vulnerabilità e aumenterebbe in modo considerevole la memoria occupata, la quantità di calcolo effettuata e di conseguenza il consumo della batteria.
Questo problema è cruciale poiché l’applicazione in questione ha necessità di una vasta diffusione e dunque deve risultare il più possibile accessibile ai molti modelli di telefono e non deve risultare fastidiosa operando in background per molte ore.
Il valore delle informazioni contenute nel database
Un aspetto importante della sicurezza informatica sta nella decisione del valore dei dati distribuiti, ponderata tramite il rischio che si è disposti ad assumere (risk appetite).
Il progettista di un protocollo vulnerabile potrebbe pensare, quanto possibile, di ridurre l’appetibilità dei dati per diminuire le probabilità e i danni di un eventuale attacco. Registrando nel database solo le informazioni anonime, ad esempio, queste ultime perderanno di valore. Viceversa, registrando tutte le posizioni, esso aumenterebbe.
Tuttavia, organizzazioni paragovernative o APT potrebbero volere queste informazioni per verificare se quello che viene riportato dai media esteri è effettivamente reale.
Oltre alle vulnerabilità riguardanti la privacy, altre questioni possono creare perplessità sul funzionamento delle app basate su contact tracing BLE.
In prima istanza il problema di eventuali utenti che, volontariamente o no, potrebbero generare falsi positivi tramite un uso improprio della piattaforma. Questo potrebbe risolversi abilitando solo gli operatori sanitari alla modifica dello status di positivo, attraverso appositi QR Code, rendendo necessario però una coordinazione maggiore tra gli enti.
Un’ulteriore incertezza riguarda la penetrazione del Bluetooth attraverso le pareti (a differenza del virus). Una possibile soluzione consisterebbe nella valutazione dell’intensità del segnale ricevuto: segnali passanti attraverso pareti dovrebbero essere classificati come troppo lontani tramite un’opportuna calibrazione dei parametri dell’applicazione.
Inoltre, nel caso dell’utilizzo di un sistema decentralizzato senza geolocalizzazione, sorge il problema di salvare su ogni smartphone una moltitudine di ID giornalieri di nuovi infetti (fino a decine di Giga).
Il fondatore di Signal, Moxie Marlinspike, ha espresso alcuni dubbi proprio sulla dimensione degli ID da scaricare giornalmente sui vari dispositivi.
Per rendere “usabile” il sistema, secondo lui, bisognerebbe pubblicare gli ID dei nuovi malati in maniera geograficamente “mirata” che quindi dovrebbe consistere in un accoppiamento tra ID (anonimi) e posizioni.
All’utente la possibilità di specificare, anche in modo approssimativo, la regione in cui abita.
Appendice
Bluetooth Low Energy (BLE)
Questa tecnologia è presente nativamente nei più comuni sistemi operativi, fatta eccezione per le versioni di Windows precedenti alla 8.
La frequenza di comunicazione è di 2,4 GHz, la stessa del Bluetooth classico e ci si può dunque interagire sfruttando lo stesso tipo di antenna, ma con una modulazione più semplice.
L’interfacciamento tra dispositivi inizia attraverso un procedura di annuncio (broadcast di un pacchetto su uno di 3 canali specifici) e scoperta (ascolto sui canali ad intervalli periodici). Le applicazioni che implementano il protocollo BLE fanno riferimento al GATT per il quale si instaura una struttura Client-Server in cui lo scambio di dati (characteristics e descriptors) avviene nell’ambito del Service.
Il tipico range di comunicazione va dai 100 m (Bluetooth 2.1) ai 400 m (Bluetooth 5), ma può variare a seconda della tecnologia hardware e software. Il Network Standard è IEEE 802.15.1 con topologia point-to-point e mesh network (o scatternet nei primi protocolli Bluetooth).
Il protocollo DP-3T
Il Decentralised Privacy-Preserving Proximity Tracing (DP-3T) è un protocollo open-source per il Proximity Tracing.
Esso fa uso del Bluetooth Low Energy e assicura che i dati personali e la computazione rimanga interamente nel telefono di ogni individuo.
La Svizzera, l’Austria e l’Estonia hanno già annunciato che le loro app saranno basate su questo protocollo. Google ed Apple hanno sviluppato il proprio protocollo di contact tracing basandosi proprio sul DP-3T.
Questo sistema si basa su una chiave SKt che cambia giornalmente dalla quale si ricavano gli Ephemeral IDs (EphID), ovvero ID da 16 Byte e vengono inviati in broadcast ai dispositivi vicini.
Nelle due figure è visibile la procedura di generazione e trasmissione degli ID.
Quando una persona si ammala di Covid-19 e decide di condividerlo, il suo seed viene inviato ad un server centrale; gli altri smartphone periodicamente scaricano le informazioni di tutte le persone infette e le confrontano con gli EphID che hanno memorizzato precedentemente in locale.
Ricerca accademica del nodo CyberChallenge 2020 Link Campus University – Prof.Francesco Corona
Gruppo di lavoro: S.Caputo – M.Viscione – D.Cinque
