L'Internet delle cose promette di essere uno dei megatrend dell'era digitale, che creerà o manderà in fallimento molte aziende tecnologiche, a seconda della loro capacità di adattamento. Tra le sfide più evidenti vi sono la privacy e la sicurezza: se già pensiamo di avere problemi di sicurezza con un miliardo di smartphone controllati dall'uomo, immaginate che cosa potrà succedere con mille miliardi di oggetti autonomi che raccolgono un numero incalcolabile di informazioni sulla nostra salute, su come guidiamo e su come pensiamo. L'ampiezza e la diversità della generazione, distribuzione ed elaborazione delle informazioni dell'IoT rendono di per se stesso difficile concepire tutte le minacce e i veicoli di attacco in cui potremmo imbatterci. L'architettura della piattaforma per le “Cose” dell'IoT deve adattarsi a progetti che siano a prova di futuro per quanto riguarda questa sfida.
Internet delle cose: architettura virtualizzata
Le Cose sono dei sistemi embedded (incorporati in altri sistemi). La differenza tra i sistemi embedded tradizionali e le Cose è semplicemente che le Cose sono collegate a Internet, direttamente o tramite un gateway. Questa connettività porta con sé sia l'opportunità di maggiori funzionalità, sia un aumento dei rischi relativi alla sicurezza a causa dell'accesso remoto. L'architettura tradizionale di una piattaforma per sistemi embedded è semplice: un sistema operativo embedded adattato all'hardware (ad esempio tramite il Board Support Package) e le applicazioni situate al di sopra del sistema operativo e che utilizzano la sua interfaccia di programmazione per eseguire una serie di funzioni localizzate, come ad esempio la comunicazione tra i processi o Ipc (InterProcess Communication). Al contratio, l'architettura della piattaforma delle Cose sta rapidamente evolvendosi in un sistema che impiega la virtualizzazione sia nella parte superiore che in quella inferiore dello stack software. Ai livelli superiori, l'esistenza del web porterà a sostituire molte applicazioni residenti nei dispositivi con procedure eseguibili da remoto, invocate tramite chiamate remote o Rpc (Remote Procedure Calls) anziché tramite Ipc e utilizzando Api web (ad esempio, i servizi web RESTful) invece delle Api del sistema operativo. Ai livelli inferiori, l'hardware è virtualizzato e permette ai progettisti di passare più facilmente da un sistema operativo all'altro o di combinare opportunamente più sistemi operativi in un unico sistema, utilizzando il prodotto che meglio si adatta alle esigenze di ogni singolo sottosistema. L'inevitabilità di questa trasformazione dell'architettura della piattaforma è anticipata dalla stessa trasformazione che traspariva nel precedente megatrend digitale, il cloud computing. Nella prima metà degli anni 2000, i cloud hypervisor (o cloudvisor) come VMware ESX server, Hyper-V, e Xen hanno avuto modo di evolversi e Intel ha rilasciato la tecnologia VT per aiutarli a funzionare in modo più efficiente. Alla fine del decennio, tutti i principali data center del mondo erano virtualizzati. Questo cambiamento architetturale incredibilmente rapido è stato favorito dalla grande efficienza delle risorse, da una maggiore fault-tolerance e dalla flessibilità resa possibile dalla virtualizzazione dei sistemi computerizzati. Nel mondo delle Cose, anche i Thingvisor, come il Green Hills Integrity Multivisor, sono maturati nell'ultimo decennio e vengono ora supportati da funzionalità di virtualizzazione hardware analoghe, aggiunte di recente all'architettura Arm (per esempio, oggi disponibile in molti dispositivi mobili), compresa la famiglia Arm v8-R di processori “real-time” di nuova generazione, da poco annunciata. Le Cose hanno esigenze molto diverse rispetto ai server cloud. Mentre i cloudvisor devono virtualizzare le risorse della Cpu, di archiviazione e delle risorse di rete, i Thingvisor devono virtualizzare in aggiunta una gamma incredibilmente vasta di componenti hardware supplementari che comprendono molti tipi di interfacce wireless, sensori, acceleratori multimediali e altro ancora. Inoltre, i Thingvisor devono spesso gestire carichi di lavoro a criticità mista; ad esempio, negli impianti a bordo autoveicolo non sarà raro vedere un’unica piattaforma su cui operano un sistema operativo di alto livello come Android (ad esempio per l’infotainment) insieme a funzionalità safety-critical in tempo reale (ad esempio, la telecamera per la retromarcia o gli strumenti sul cruscotto). Il Thingvisor consente di eseguire i compiti meno gravosi, facendoli girare direttamente sul Thingvisor stesso, evitando il sovraccarico causato dalla presenza di due livelli per gestione di interrupt schedulazione e comunicazione, che altrimenti sarebbe necessario nel caso di applicazioni che girano su un sistema operativo “guest” (ospite). In campo automotive, un'applicazione Thingvisor leggera è in grado di soddisfare i requisiti di avvio rapido e di gestione “real-time” associati alle comunicazioni della rete intraveicolare (ad esempio il bus Can), nonché di gestire operazioni safety-critical (ad esempio, il funzionamento della telecamera posteriore, la strumentazione sul cruscotto e i sistemi Adas), ospitando nel contempo le operazioni più sofisticate di un sistema operativo “guest” come Android. Il Thingvisor può anche essere considerato come una “root of trust” del software da cui i progettisti possono far derivare un sistema nel complesso solido e sicuro. Componenti critici per la sicurezza, come ad esempio un ambiente di esecuzione fidata o Tee (Trusted Execution Environment), funzioni di crittografia e la gestione dei diritti digitali, possono essere eseguiti in processi isolati in cima allo stack del Thingvisor, isolati dai carichi di lavoro ordinari del sistema.
Protezione dei dati nella IoT
Uno degli errori relativamente alla sicurezza dei sistemi cloud è il fatto che i fornitori di soluzioni concentrano i propri investimenti sulle difese del data center - con bunker sotterranei, guardie armate, sistemi di controllo accessi multifattore e una moltitudine di apparecchiature hardware di sicurezza che proteggono la rete - ignorando praticamente la sicurezza dei terminali remoti che possono collegarsi al data center. Questo è il modo pericoloso di pensare nell'era del cloud ed è una vera follia nell'epoca dell'IoT. Gli aggressori sono sempre alla ricerca del punto debole di un sistema e, se le Cose restano scarsamente protette, saranno le prime ad essere prese di mira. Una volta che la Cosa è stata espugnata, gli aggressori potranno utilizzarla per accedere ai “gioielli della corona” nel data center. Un altro degli errori è poi la credenza che non ci siano molte informazioni che vale la pena di proteggere in periferia. Anche questa è un’opinione discutibile nell'epoca del cloud, ma incredibilmente sbagliata nell'epoca dell'IoT. Le Cose generano un tesoro di informazioni preziose e private, la nostra salute, le nostre attività sociali e la nostra posizione, solo per citare qualche esempio. Quando l’IoT giungerà a decine di miliardi e infine a migliaia di miliardi di oggetti connessi, il valore complessivo generato dalle Cose diventerà un obiettivo incredibilmente prezioso. A titolo di esempio, nel recente attacco informatico contro la Target Corporation, il malware è stato inserito nelle Cose del negozio - nei terminali del punto vendita - invece che introdotto nei server aziendali o nei server di elaborazione dei pagamenti. Gli aggressori hanno trafugato oltre 100 milioni tra numeri di carte di credito e dati personali. Anche di recente, i ricercatori della sicurezza hanno identificato una “botnet” costituita da elettrodomestici intelligenti, come i frigoriferi. Questi attacchi basati su Cose sono solo la punta dell'iceberg: possiamo aspettarci che tali attacchi crescano tanto velocemente quanto il numero degli oggetti stessi. Un altro errore banale che si commette spesso nel cloud computing è pensare che una connessione Https tra il dispositivo di accesso e il cloud sia sufficiente a proteggere le informazioni che attraversano il web. Man mano che l’IoT cresce in complessità, per gli sviluppatori non è semplice individuare in che modo i dati fluiranno attraverso la rete e se i vari sistemi presenti lungo il percorso saranno degni della nostra fiducia. Ad esempio, quando si collega il browser a Facebook, l'utilizzo del protocollo SSL può proteggere le informazioni che transitano verso la DMZ di Facebook (si noti, tuttavia, che la mancanza di un'autenticazione reciproca forte nella maggior parte delle transazioni web rende discutibile persino questo supposizione), ma che cosa succede ai dati una volta che sono entrati nel cloud di Facebook? I dati possono essere inviati agli inserzionisti, ai database e a servizi web di terze parti. Non sarà pratico che gli sviluppatori delle Cose siano certi della qualità dei controlli di sicurezza attuati da tutti questi attori. Pertanto, dobbiamo adottare una strategia di “fiducia zero”, in cui si suppone che il cloud sia intrinsecamente insicuro. Se il nostro sistema emette dati di valore, dobbiamo prendere adeguate misure per proteggere quei dati, indipendentemente da dove andranno a finire circolando nel web. Ad esempio, un dispositivo sanitario indossabile può criptare informazioni generate localmente con una chiave che viene controllata dal proprietario del dispositivo e condivise “fuori banda” solo con operatori sanitari che abbiano la necessità di conoscerle.
Impedire l’attacco informatico con una piattaforma sicura
I principi architetturali della piattaforma sopra descritti offrono agli sviluppatori una serie di strumenti potenti con cui realizzare sistemi IoT sicuri. Per dare un'idea di ciò, diamo uno sguardo all’attacco informatico a Target e a come la cosa avrebbe potuto essere facilmente evitata. Anche se al momento non si hanno a disposizione tutti i dettagli su come il malware è stato installato nei terminali Pos, sappiamo che il malware era in grado di ottenere pieni privilegi e di accedere alla Ram al fine di raccogliere informazioni personali nel momento in cui venivano inserite dai clienti nei terminali. Un'architettura PoS evoluta utilizzerebbe un sistema operativo senza privilegi e un'applicazione security-critical leggera, chiamata tokenizer (distributore di gettoni virtuali), per gestire l'elaborazione dei dati personali. Il tokenizer opera direttamente sul Thingvisor e gestisce il dispositivo Usb fisico utilizzato per strisciare le carte di credito magnetiche. Il tokenizer utilizza una connessione sicura a un servizio Web di back-end basato su server per la mappatura di dati personali su record “tokenizzati” e poi genera una “strisciata” Usb virtuale, passando il token all'ambiente operativo del punto vendita. Anche se il sistema operativo principale del punto vendita contiene il malware, questo non dispone di informazioni personali da rubare. La mappatura dei dati in formato token avviene a livello di back-end. Il Thingvisor può anche includere un’apparecchiatura di sicurezza virtuale, come ad esempio un componente per la gestione unificata delle minacce di sistema o Utm (Unified Threat Management), che si trova tra la rete fisica e un'interfaccia di rete virtuale senza privilegi, esposta al sistema operativo del PoS. Tale approccio dà alle Cose la capacità di incorporare funzioni di sicurezza di rete di livello server, senza l'ingombro, il peso, i consumi e i costi associati al tradizionale hardware di rete per la sicurezza del data center.
Root of Trust di livello Hardware
È anche importante notare che le Cose richiedono una “root of trust” di livello hardware, inferiore alla “root of trust” di livello software del Thingvisor. Una “root of trust” hardware, nella sua forma più semplice, è un deposito di chiavi resistente alle manomissioni, utilizzato, come minimo, per un avvio sicuro del Thingvisor e dei componenti security-critical associati (ad esempio il tokenizer nell'esempio precedente). La sequenza di avvio deve utilizzare la chiave per controllare e firmare questi componenti prima di avviarli. Successivamente, la “root of trust” hardware può essere utilizzata anche per conferme remote e per una maggiore garanzia di sicurezza delle chiavi utilizzate per la protezione dei dati in transito e di quelli residenti in memoria. Se un utente malintenzionato tentasse di sovrascrivere la flash del firmware con un codice dannoso, l'avvio sicuro lo rileverà permettendo di adottare misure correttive. Una volta lanciato in modo sicuro, il Thingvisor può ricorrere, se necessario, a controlli di altri componenti, come i kernel del sistema operativo ospite.
