La sicurezza dei dispositivi indossabili

UBA024(Fig1)_WEB

prescindere che cerchino lo stile di un Apple Watch, un fitness band o cuffie per esperienze di gioco potenziate, i consumatori hanno a disposizione un ampio ventaglio di prodotti indossabili. Molti di questi dispositivi puntano ad ampliare la portata e l’utilità dello smartphone (l'immagine di apertura dell'articolo illustra la vasta gamma dei dispositivi indossabili) ma esiste un ulteriore settore emergente di dispositivi indossabili di localizzazione. Questi cosiddetti personal tracker o sistemi di emergenza mobile o dall’acronimo inglese Mpers (Mobile personal emergency response systems) sono adottati per rintracciare minori, persone anziane e lavoratori in solitario. Oltre a poter essere localizzati, gli individui che li indossano possono, semplicemente premendo un pulsante, chiedere aiuto in caso di malore, smarrimento o se si trovano in pericolo di vita. Inutile sottolineare che la connettività è onnipresente in qualsiasi dispositivo indossabile. Prevalgono, in genere, comunicazioni a corto raggio via Wi-Fi o Bluetooth, quest’ultimo estremamente comune nel caso in cui si usi uno smartphone per le funzionalità di archiviazione locale e presentazione di dati oppure come gateway per le app di analisi basate su cloud. Per altre applicazioni, invece, come i sistemi Mpers, il requisito fondamentale che garantisce piena mobilità di comunicazione è la connessione cellulare.


Connettività e sicurezza

Come avviene per tutti i dispositivi IoT, il concetto di connettività va di pari passo con quello di sicurezza. La maggior parte dei dispositivi indossabili contiene dati personali come, ad esempio, frequenza cardiaca o misurazioni del livello di glucosio nel sangue nel caso dei fitness tracker. Inoltre vi si trovano informazioni di localizzazione con tanto di registrazione dell’orario e, talora, anche profili e password di accesso a piattaforme cloud. Uno sviluppatore professionale di dispositivi, app o servizi indossabili dovrebbe sempre tener conto della sicurezza: la fase di progettazione richiede attente riflessioni e stime meticolose di potenziali attacchi alla sicurezza. In un mondo ideale, i progetti dovrebbero essere realizzati da zero, con un unico team capace di ideare e sviluppare in modo autonomo ogni singolo blocco funzionale. Nella realtà, invece, la pressione per ridurre il time-to-market e per realizzare maggiore integrazione - come, ad esempio, con l’utilizzo di modelli wireless pre-certificati e omologati - rende necessario un approccio più olistico alla sicurezza che deve dunque essere implementata con un approccio end-to-end. I possibili punti di attacco alla sicurezza possono coinvolgere i sensori, l’archiviazione locale, l’elaborazione informatica, la configurazione del dispositivo, i metodi di autenticazione e il trasferimento di dati. Per poter comprendere meglio alcuni concetti relativi alla sicurezza occorre esaminare le componenti fondamentali di un dispositivo indossabile con sistema Mpers. I componenti chiave sono quattro: i sensori che rilevano la frequenza cardiaca, la temperatura corporea, i dati di localizzazione ricevuti tramite un sistema globale di navigazione satellitare, la connettività ad ampio raggio fornita in genere da un modulo cellulare/Lte e, dove richiesto per rilevamenti interni/domestici, un sistema di comunicazione a corto raggio, generalmente coperto da un modulo Bluetooth. Esempi di componenti wireless per il dispositivo in questione includono un modulo Lte multibanda u-blox LARA-R211 e un dispositivo Gnss, sempre di u-blox, EVA M8M. A rivestire il ruolo di hosting per l’app e di gestore del trasferimento dati c’è un microcontrollore. Per la sicurezza del dispositivo occorre creare una catena di fiducia end-to-end, dal sensore risp. dai sensori al Gnss, dalla connessione wireless fino all’app del cloud terminale e viceversa. Un possibile approccio per implementare la catena di fiducia consiste nel suddividerla in un determinato numero di domini fidati.

Potenziali aree di attacco

Nell’analisi dei metodi di protezione fondamentali per ogni dominio emergono diverse aree di attacco potenziale: il firmware del dispositivo, le comunicazioni al server, la sicurezza dell’interfaccia, l’attuazione di un controllo Api e la robustezza con cui si gestiscono, ad esempio, spoofing e jamming. Lo sviluppatore deve garantire una solida fiducia iniziale per ogni componente principale e definire le modalità con cui questi si collegano ai componenti secondari. Vanno sempre verificati gli standard e le linee guida del settore - come le linee guida Gsma per la sicurezza nell’IoT o le linee guida per la sicurezza dei dispositivi indossabili dell’Ieee. Per approfondire la struttura di un modem cellulare per un sistema Mpers si identificano le principali misure di sicurezza per ogni componente. L’immagine mostra cinque differenti metodi di attacco, indicati con dei cerchi numerati e illustrati qui di seguito. Innanzitutto, garantire che un dispositivo esegua un determinato codice richiede un metodo di inizializzazione sicuro. Quando si inizializza un sistema è fondamentale che ogni singola fase sia autenticata prima di avviare un nuovo processo. Parlando di sicurezza del firmware è necessario occuparsi anche dei suoi aggiornamenti: aggiornare il firmware permette di incorporare nuove funzioni ma anche di implementare le misure di sicurezza migliorabili. Per i dispositivi che si connettono a Internet tramite un’app dallo smartphone, il metodo ideale potrebbe essere quello via etere, mentre per i dispositivi indossabili dotati di connettività cellulare, come i nostri sistemi Mpers, l’aggiornamento può avvenire in modo diretto, senza aspettare che il dispositivo venga accoppiato allo smartphone. Il concetto di aggiornamento del firmware via etere è alquanto immediato ma le possibilità che questo rappresenti un punto di attacco sono elevate. È dunque fondamentale far sì che l’immagine o la patch del firmware scaricata venga validata prima di effettuare il flash. Si rende dunque necessario un processo che autentichi e comprovi l’immagine nella sua integrità prima dell’uso, con la possibilità di rintracciare l’immagine previamente autenticata in caso di violazione della sicurezza o al verificarsi di un problema di hardware durante il processo di aggiornamento - e che sia in grado di respingere versioni precedenti. Inoltre, l’aggiornamento via etere e l’archiviazione di diverse versioni di immagine possono richiedere una maggiore memoria, con ripercussioni sulla fase di progettazione. La seguente considerazione riguarda il trasferimento dei dati e le comunicazioni. Deve essere previsto un meccanismo con cui il dispositivo possa autenticarsi con il server di hosting basato su cloud, e viceversa. A prescindere dal metodo utilizzato, il dispositivo deve poter firmare e crittografare tutti i dati comunicati al server. La capacità di gestire in modo sicuro le chiavi usate per i processi di firma, decifratura e cifratura farà sì che queste potranno essere cambiate in qualsiasi momento lo si ritenga necessario, addirittura a ogni sessione. I dati trasmessi sono sempre a rischio di intercettazione o manomissione tramite attacchi man-in-the-middle, inclusa l’interfaccia del dispositivo. Il controllo non autorizzato del dispositivo è un altro scenario che va assolutamente evitato. È inoltre essenziale garantire il dovuto controllo dell’accesso a ogni canale e a ogni porta dell’interfaccia. Ciò implica porte di test e di debug che, seppur fisicamente presenti sul circuito, sono state chiuse in versioni precedenti del software, così come la chiusura delle porte non utilizzate dal microcontrollore o dai moduli wireless. Lasciare aperte e accessibili delle porte rappresenta un rischio facilmente evitabile. L’accesso alla funzionalità del dispositivo avviene, di solito, tramite una serie di interfacce Api. Sfortunatamente, l’accesso alle funzionalità del dispositivo e le sue implicazioni in termini di sicurezza vengono spesso trascurate. Chi vuole sfruttare o compromettere un dispositivo, anche solo per divertimento, ha in genere tutto il tempo per sondare le interfacce Api aperte e sperimentare le interrelazioni tra queste e la funzionalità del dispositivo. A volte, le interfacce Api incorporate nel codice forniscono accesso non solo alle caratteristiche e alle funzionalità standard ma anche a servizi premium o a pagamento. Talvolta, i programmatori inseriscono interfacce Api non documentate per i loro test e per le configurazioni - quindi è imperativo che anche queste vengano protette: ecco perché andrebbero usate tecniche di autenticazione e autorizzazione formale per l’accesso o l’abilitazione di queste interfacce Api. La considerazione finale è inerente alla robustezza delle app che ricevono dati da dispositivi esterni come, ad esempio, da un ricevitore Gnss: in questi casi, la localizzazione è parte integrante del valore dei dati ottenuti dal sensore. Qui, il punto cruciale è la robustezza con cui si individuano e si gestiscono i problemi: se si verifica, ad esempio, un attacco di jamming del ricevitore Gnss o uno spoofing dell’input inviato al ricevitore Gnss, identificare la veridicità della posizione riferita è tanto importante quanto proteggersi da un attacco diretto al restante sistema. Gli attacchi man-in-the-middle ai dati del sensore che passano per l’hosting sono un altro elemento da tenere in considerazione. Essere in grado di identificare sia questi ultimi sia gli attacchi di spoofing e mettere in guardia le applicazioni finali costituiscono aspetti importanti dell’incorporazione della sicurezza nel dispositivo indossabile. Gli ingegneri dovrebbero verificare con attenzione le capacità dei moduli Gnss e dei moduli cellulari quando li scelgono. Ad esempio, il firmware u-blox EVA-M8M incorpora svariate funzionalità di sicurezza che possono indicare all’applicazione hosting, mediante due messaggi di stato interni, la possibilità di un attacco jamming intenzionale dei segnali Gnss. Il messaggio “jamlnd“j indica la presenza di un’onda continua a banda stretta che supera una soglia fissata per un normale ambiente di ricezione, interferendo con la ricezione su tutte le possibili frequenze Gnss. Il messaggio “j jammingState“j mette in guardia l’hosting da interferenze d’onda continue e di banda larga. Il modulo Gnss di u-blox è, inoltre, in grado di rilevare tentativi di spoofing sui dati da satellite. Se qualcuno dovesse provare a creare un finto segnale Gnss con l’intenzione di ingannare il ricevitore si troverebbe in posizione diversa rispetto all’effettivo segnale e verrebbe creato un flag di stato. La funzione di rilevamento dello spoofing si avvale di algoritmi anti-spoofing per monitorare cambiamenti sospetti nel segnale Gnss.

Pubblica i tuoi commenti