EO_470

EDA/SW/T&M CYBER SECURITY tipologia di dispositivo come quello appena descritto esistono limiti in termini di costo e fattore di forma. Di conseguenza, la scelta del microcontrollore da utiliz- zare per far funzionare tale dispositivo è generalmente orientata verso un modello caratterizzato da un’archi- tettura molto semplice e con risorse di memoria em- bedded limitate. Attualmente il candidato che riscuote il maggior successo è il processore Cortex-M di ARM. In- dipendentemente dalla strategia adottata per lo svilup- po del software, che può essere scritto da un team in- terno o da una software house esterna, è indubbio che il passaggio da una a più appli- cazioni comporta un sensibile incremento della complessità e della varietà del codice em- bedded. Di conseguenza, poi- ché il core Cortex-M dispone solamente di una MPU (Me- mory Protection Unit), esiste il rischio che per lo sviluppo del software del dispositivo si adotti un modello piatto (flat model), dove tutte le applica- zioni condividono le stesse risorse e i medesimi privilegi. Adottando un modello di que- sto tipo solamente l’uso delle migliori procedure (best prac- tice), le capacità degli svilup- patori software, l’esaustiva verifica del codice e, non ulti- ma, una buona dose di fortuna, possono garantire che ciascuna applicazioni non disturbi o in qualche modo “inquini” tutte le altre (Fig. 2). Analisi del problema In un modello architetturale di tipo piatto, il rischio maggiore è rappresentato dal fatto che qualsiasi vul- nerabilità e malfunzionamento in una qualunque delle applicazioni possa influenzare tutte le altre e di conse- guenza il funzionamento dell’intero dispositivo. Poiché non esistono una protezione e una separazione reali, un potenziale attacco può diffondersi dall’applicazione più vulnerabile alle altre a causa di una condivisione delle risorse non controllata e alla mancanza di distinzione tra i privilegi di esecuzione. Il canale di attacco prefe- rito è rappresentato dall’interfaccia di comunicazione esterna, una via di accesso particolarmente “invitante” per un potenziale hacker. L’interfaccia, per definizione, è accessibile dall’esterno del dispositivo e, in teoria, da remoto attraverso una rete. Lo stack software che gesti- sce le comunicazioni è sempre validato in termini fun- zionali, ma molto raramente lo è in termini di sicurezza. Una strategia di attacco finalizzata a sfruttare una vul- nerabilità in uno stack di comunicazione di solito utiliz- za un overflow del buffer (ovvero la stringa di ingres- so è più grande del buffer che la dovrà contenere) o la mancanza di verifica dei dati in ingresso: un hacker potrebbe iniettare codice dannoso nella RAM interna del microcontrollore sfruttando i buffer di comunicazio- ne che non sono stati verificati in modo corretto. Una volta che il codice è penetrato nella piattaforma e vie- ne eseguito. Le conseguenze possono essere diverse, limitate solo dalla fantasia dell’hacker: furto di informa- zioni biometriche, esecuzione di attacchi di tipo relay e numerose altre tipologie di danni in funzione del tipo di applicazioni embedded ospitate (Fig. 3). La soluzione Per contrastare tali minacce di solito vengono proposte soluzioni software che sfruttano meccanismi di sicurez- za dell’hardware come la MMU (Memory Management Unit – Unità di gestione della memoria) o la TrustZone di Arm. Si tratta software che permettono di implementare il concetto di isolamento, denominati hypervisor o mac- chine virtuali. In pratica essi sfruttano meccanismi har- dware per definire “box” software separati o “contenitori” ciascuno dei quali ospita un’applicazione. L’obbiettivo 67 - ELETTRONICA OGGI 470 - MAGGIO 2018 Fig. 3 – Una volta che il codice è penetrato nella piattaforma e viene eseguito, l’hacker può acquisire il controllo completo del software che gira sul dispositivo