L’Internet of Things (IoT) è ormai una realtà con milioni di oggetti smart che sono entrati a far parte delle nostre vite, prima indirettamente con il loro impiego industriale, poi con la diffusione nelle nostre case (Alexa, Siri, o Google Home).
Come spesso accade nel mondo e ancor più spesso in quello dell’ICT, lo sviluppo di nuove tecnologie si concentra sulle funzionalità prima, lasciando aspetti non sempre secondari come, ad esempio, la sicurezza per successive iterazioni. Eppure, dovremmo aver imparato dai nostri errori: in informatica copiare e incollare informazioni (e programmi) è un’attività sostanzialmente senza costo, ecco che quando si trova una vulnerabilità in un sistema informatico con molta probabilità si scriverà un programma che cercherà sistemi informatici analoghi per massimizzarne lo sfruttamento (qualunque sia il fine ultimo).
La sicurezza al tempo dell’IoT
Non bisogna dimenticare che in un mondo in cui sensori e attuatori agiscono nel mondo reale, semplici errori nella concezione del software si possono riflettere in effetti tangibili e non solo in perdite di dati. Non occorre pensare ad hacker che cercano di forzare centrali per far saltare linee elettriche o avvelenare sorgenti d’acqua, possibilità reale nonostante ci possa sembrare remota; è altrettanto possibile che mentre vi state avvicinando alla vostra auto, se il costruttore ha usato dei chip poco sicuri, qualche malintenzionato intercetti il segnale radio per clonare la chiave e impossessarsi dell’automobile. Se ritenete che anche questo sia uno scenario poco probabile, pensate che se uno grida al vostro assistente vocale “hey! Apri la porta!” e vi siete regalati una smart-lock IoT, qualcuno potrebbe intrufolarsi in casa vostra.
In effetti, soprattutto nel mondo consumer, i dispositivi IoT ospitano un sistema operativo (probabilmente basato su Linux) che non sarà più aggiornato per tutta la sua esistenza e che soffrirà dei bug e delle vulnerabilità non ancora scoperte al momento della sua compilazione. Ma noi ci sentiamo sicuri, perché per poter provare un “exploit” è necessario poter comunicare col dispositivo e quindi avere accesso alla rete (spesso WiFi) a cui esso è connesso. Non si pensa però che uno di questi sensori o attuatori sarà accessibile fisicamente a persone sconosciute (ad esempio una smart-lock è accessibile sia dall’interno che dall’esterno della porta di casa) che possono quindi cercare di forzarlo per poi usarlo come base per condurre l’attacco a tutti i dispositivi connessi alla stessa rete.
Ad oggi non vi sono ricette pronte per rendere sicura la propria installazione IoT, se non quella di tenere aggiornato il software ed effettuare un monitoraggio capace di individuare comportamenti che deviino dalla norma, e se possibile usare meccanismi di sicurezza di rete per aumentare il livello di affidabilità dell’intera installazione.
Si può sperare che emerga una piattaforma software comune per l’IoT che possa quindi fare controlli di sicurezza distribuiti per assicurare un più alto livello di sicurezza della rete, ma ad oggi non sembra emergere nessun vendor capace di definire standard open e realmente interoperabili che non si limitino a crittografare chiamate http utilizzando il protocollo TLS/SSL per convincerci che siamo al sicuro.
Una piattaforma integrata per la sicurezza IoT: Azure Sphere
Nel mentre auspichiamo l’emergere di protocolli IoT, probabilmente basati su HTTP(s), capaci di elevare in modo standard e aperto il livello di sicurezza delle nostre installazioni, alcuni vendor – tra cui Microsoft – hanno intrapreso una strada diversa in cui la sicurezza viene ottenuta attraverso un controllo dell’intero stack del dispositivo, dall’hardware con meccanismi specifici dedicati a renderlo sicuro, e dal software che ne usa le funzioni per assicurare una maggiore robustezza contro gli attacchi.
Come esempio di piattaforma integrata prenderemo Azure Sphere, un’iniziativa verticale nel mondo IoT di Microsoft chiaramente volta a favorire l’adozione del cloud pubblico Azure da parte dei sistemi IoT che concentrino i dati e le loro analisi nel cloud piuttosto che su dispositivi locali. In effetti la piattaforma è ben documentata e consta non solo di un SDK che consente di sviluppare soluzioni, ma anche del riferimento a chip hardware che offrano quelle primitive necessarie al software per ridurre il rischio di intrusione nei dispositivi.
Sono state rilasciate le specifiche per la realizzazione di chip compatibili con Azure Sphere, ma per supportare lo sviluppo anche di board il processore MT3620 di MediaTek è disponibile e compatibile con la piattaforma. Si tratta di un chip ARM basato su Cortex-A7 come mostrato nel diagramma a blocchi in figura.
Osservando le varie etichette dei sottosistemi del chip saltano all’occhio sia il fatto che esistono moduli di comunicazione integrati, che il sottosistema di sicurezza chiamato Pluton responsabile per l’implementazione in hardware di alcune primitive di sicurezza che saranno poi utilizzate dal software. In particolare, il Cortex-A7 è pensato per l’esecuzione delle applicazioni mentre un core Cortex-M4F è pensato per eseguire le funzioni di sicurezza. Infine, non si può non notare il modulo Trust Zone DMA che sottintende che anche le attività di Direct Memory Access possano essere analizzate per assicurare che non vi siano trasferimenti non leciti.
Seguendo la legenda dei colori risalta anche come vi siano delle funzioni la cui esecuzione sia riservata al sistema operativo che, essendo a conoscenza dell’hardware sottostante, ne potrà sfruttare le sue capacità.
Le sette proprietà dei dispositivi sicuri
Microsoft Research propone una visione più astratta della piattaforma indicando delle proprietà che si vogliono garantire con lo stack hardware e software della piattaforma Azure Sphere. Nell’articolo le sette proprietà vengono esemplificate nella seguente tabella.
Alla base si fa uso di crittografia e chiavi crittografiche volte ad assicurare che il software non possa essere alterato. È interessante il riferimento ai cosiddetti “side-channel attacks” resi popolari dai primi testimoni noti con i nomi di spectre e meltdown.
Una volta che l’hardware è reso sicuro è importante avere un software fidato che sia piccolo in modo da poter essere verificato puntualmente evitando che si possano generare stati imprevisti che un attaccante può pensare di sfruttare.
I dispositivi si devono poter aggiornare in modo automatico (e sicuro altrimenti sarebbe facile comprometterli) e fornire informazioni ai produttori quando condizioni critiche per la sicurezza (come ad esempio un buffer overrun) si verificano.
Il produttore hardware e software sono sicuri?
Questa è sempre la domanda imperante quando ci si avvicina a prodotti che hanno parti hardware che non possono essere ispezionate. Questo è vero per server, apparati di rete, e dispositivi IoT, e purtroppo non c’è molto che possiamo fare se non analizzare tutte le informazioni che sono rese disponibili dai vendor.
Non potendo dare per scontata una relazione di fiducia la contromisura naturale in sicurezza è quella di differenziare l’investimento coinvolgendo vari vendor che offrono funzioni simili. Inoltre, in questo modo è possibile evitare fenomeni di lock-in legati all’adozione di una singola tecnologia.
Si potrebbe quindi pensare di essere tornati al punto di partenza: come difendiamo dispositivi che funzionano utilizzando tecnologie diverse? La risposta è che se si dispongono di piattaforme come Azure Sphere che rendono più sicuro dispositivi è possibile creare raggruppamenti omogenei per tecnologia che colloquiano tra loro usando protocolli standard. In questo modo i vari raggruppamenti di dispositivi (cluster) divengono più difficili da aggredire ma le architetture che possiamo realizzare divengono meno vendor specifiche offrendo un modello più sostenibile sia dal punto di vista della sicurezza che anche della manutenzione e dello sviluppo.
Conclusioni
È solo l’inizio. L’emergere di piattaforme verticali per lo sviluppo di dispositivi IoT come Azure Sphere identifica la necessità del settore, che si comincia a sentire pressante, di supportare in modo più strutturato la sicurezza, senza affidarsi ai soli meccanismi di rete. I vari standard e le varie piattaforme competeranno e solo il tempo ci dirà se ne emergerà una, riproponendo un rischio di lock-in anche in questo mondo che per ora è caratterizzato da una forte differenziazione, oppure visto che la sicurezza è una proprietà non funzionale dei sistemi queste nuove tecnologie si limiteranno a garantirla a livello di raggruppamenti lasciando all’architetto di sistema individuare quali raggruppamenti di dispositivi creare e come interconnetterli.
Resta comunque istruttivo cominciare a studiarne le capacità e i modelli per capire come questo settore si stia evolvendo alla ricerca di nuovi punti di incontro tra hardware e software nel rispetto degli standard (es. ARM) di calcolo e di rete.
