Trust Platform offre sicurezza, dall’ideazione all’implementazione

La sicurezza è ora un requisito fondamentale per i sistemi embedded. Il desiderio di connettere dispositivi a Internet per semplificare il controllo e l’estrazione di dati in tempo reale dai loro sensori comporta un alto rischio di hackeraggio. La pirateria informatica non mette a rischio solo i singoli dispositivi ma intere reti.

La direzione è chiara: i fornitori non possono arrivare sul mercato senza un prodotto IoT sicuro fin dalla progettazione. Il problema per i produttori di dispositivi che cercano di sfruttare la potenza dell’IoT per i loro sistemi è la complessità dell’implementazione di meccanismi di sicurezza efficaci e pertinenti. È facile vedere in questo la necessità fondamentale di autenticazione e crittografia per quei sistemi. Ma l’implementazione è stata molto più difficile da raggiungere.

Esistono più componenti, sia software che hardware, necessari per creare una base sicura per un sistema embedded. Una debolezza in ognuna di esse può facilmente portare ad un hardware compromesso e caricato con malware che viene utilizzato per attaccare la rete di un operatore o per trasferire dati sensibili ai criminali informatici. Allo stesso tempo, molti team di progettazione stanno affrontando per la prima volta le difficoltà di sviluppo rappresentate dai problemi di sicurezza.

Uno dei requisiti fondamentali per una efficace sicurezza è che ogni dispositivo distribuito deve avere una propria identità univoca. Un difetto comune sfruttato dagli hacker è che i dispositivi vengono forniti da parte di tecnici dell’assistenza e della manutenzione di  una password o un login comuni per il loro utilizzo. I dettagli di questo login sono spesso facili da indovinare e, anche se non lo sono, di solito sono ugualmente e facilmente ottenibili da un hacker. Ottenuti i dati di  login è quindi possibile accedere non solo a un solo dispositivo ma all’intera flotta.
I criminali informatici sono stati in grado di creare botnet (eserciti di computer identici utilizzati negli attacchi di tipo denial of service)  mediante l’uso di semplici script automatici. Gli script hanno identificato e effettuato l’accesso in ciascun dispositivo di un determinato tipo aventi una connessione Internet.

Con un’identità unica, invece, è possibile assegnare a ciascun sistema le proprie credenziali di sicurezza e ridurre notevolmente la possibilità di offrire agli hacker un modo semplice per costruire botnet.  Solo se un utente autorizzato ha le credenziali giuste per un determinato dispositivo potrà effettuare l’accesso. Tuttavia, questo livello di protezione aumentato ha conseguenze di ramificazione nei processi di progettazione, sviluppo e gestione dei servizi.

L’implementazione di una sicurezza efficace tale da facilitare piuttosto che ostacolare lo sviluppo implica scelte accurate. La prima scelta di base è l’hardware da utilizzare per proteggere l’integrità del dispositivo di destinazione. Questa base garantisce l’impossibilità non solo di accedere al core firmware del dispositivo senza autorizzazione, ma di garantire che le sue funzioni non possano essere sovvertite e che il dispositivo venga utilizzato per attaccare la rete. Ad esempio, se un hacker ha ottenuto le credenziali di accesso per un dispositivo, deve essere impossibile convertirne un altro affinché accetti quelle stesse credenziali al fine di formare, ad esempio, una botnet. Di conseguenza, identità e integrità sono strettamente legate. La public-key infrastructure (PKI) fornisce un mezzo per stabilire e provare un’identità affidabile univoca non solo all’interno del dispositivo stesso ma attraverso una rete.  PKI si basa sul concetto di crittografia asimmetrica, una tecnica che collega matematicamente due chiavi numeriche. Una è una chiave pubblica, che viene generalmente utilizzata per verificare i messaggi. Come suggerisce il nome, questa chiave può essere ampiamente distribuita senza compromettere la sicurezza. La stessa fornisce a tutti un modo semplice di inviare messaggi sicuri a un dispositivo, purché sappia quale chiave pubblica usare. Il dispositivo necessita della chiave privata che consente di firmare i messaggi inviati che verranno verificati dalla chiave pubblica corrispondente. Dal funzionamento di base del PKI, è possibile costruire modelli di autenticazione più strutturati, come i certificati digitali che dimostrano l’identità di un dispositivo. Per creare un certificato digitale, un dispositivo firma un messaggio o challenge creando una firma mediante la chiave privata. La chiave pubblica corrispondente viene utilizzata dal destinatario per determinare la validità della firma.

La chiave privata richiede chiaramente una forte protezione. Non è sufficiente programmare una chiave nella memoria non volatile su un dispositivo prima che venga distribuito in quanto quella è facilmente accessibile. La chiave privata non deve mai essere divulgata. Se divulgata, gli hacker potrebbero costruire i propri dispositivi clone. Questi sono quindi in grado di impersonare e quindi fingersi il dispositivo autentico e quindi compromettere la sicurezza delle applicazioni di rete che dipendono dai dati inviati dal dispositivo.

Un problema per una progettazione convenzionale basata su microcontroller è che qualsiasi software crittografico in esecuzione sul core del processore deve accedere alla chiave privata per eseguire i calcoli necessari presupponendo che la chiave si trovi nel controller. Il requisito hardware di base è quindi un elemento sicuro utilizzato per racchiudere quelle operazioni crittografiche in un pezzo indipendente di hardware protetto insieme ad un archivio sicuro per le chiavi private. Poiché le chiavi e funzioni crittografiche sono memorizzate insieme all’interno dello stesso confine fisico sicuro, non è necessario inviare dati sensibili sul bus interno del sistema.

Figura 1 – Un elemento sicuro è come un caveau che protegge dati segreti, ed è un dispositivo complementare del microcontroller.

 

Al contrario, quando il sistema deve comunicare in modo sicuro o dimostrare la sua identità, fa appello all’elemento sicuro per rispondere a una random challenge. La risposta a questa challenge è un codice derivato aritmeticamente dalla parte casuale della challenge stessa e dalla relativa chiave privata memorizzata all’interno dell’elemento sicuro. In altre parole, la  random challenge è firmata dalla chiave privata.  In questo modo, l’elemento sicuro può dimostrare che detiene l’appropriato dato segreto ma non ha bisogno di rivelare quella chiave privata sensibile.

ATTENZIONE: quello che hai appena letto è un estratto dell'articolo. Per continuare la lettura registrati oppure effettua l'accesso.

A cura di Nicolas Demoulin, EMEA Marketing Manager – Secure Products Group, Microchip Technology Inc.

 

 

Post correlati

Commenta questo articolo