I dispositivi Internet of Things che trasmettono dati e comandi sfruttando la rete universale sono esposti a un numero e una varietà di minacce molto superiori rispetto a quello a cui erano sottoposti i dispositivi che utilizzavano la comunicazione Machine-to-Machine che solitamente avveniva su una rete chiusa privata. Il modello di classificazione “Stride”, sviluppato in origine da Microsoft, elenca le potenziali minacce alla sicurezza che un dispositivo IoT o gli utenti di quel determinato dispositivo devono affrontare: spoofing (falsificazione dell’identità), manomissione (tampering), ripudio, divulgazione di informazioni riservate (information disclosure), attacchi di tipo DoS (Denial of Service) ed elevazione dei privilegi (EoP) di un eventuale malware all’interno di un sistema infetto. Le funzioni e le risorse di sicurezza richieste per la protezione di un dispositivo IoT contro queste minacce alla sicurezza sono ora disponibili all’interno di circuiti integrati discreti realizzati ad hoc come ad esempio: un dispositivo sicuro, un System-on-Chip che abbina un microcontrollore con funzionalità crittografiche, una memoria sicura e interfacce; circuiti integrati di memoria non volatile sicuri che solitamente dispongono di un engine crittografico per accoppiare in modo sicuro la memoria con dispositivi autorizzati. L’impiego di questi circuiti integrati discreti per la realizzazione dei dispositivi IoT contribuisce a incrementare il numero di componenti, il grado di complessità e il costo della Bill Of Material rispetto a un progetto che utilizza le funzionalità di sicurezza integrate della Mcu host (o in certi casi di un processore applicativo). Il dilemma cruciale di un progettista di dispositivi per applicazioni IoT è determinare se le funzionalità della Mcu host sono adeguate per contrastare le minacce descritte nel modello Stride.
Protezione su più livelli
La vulnerabilità dei dispositivi IoT è imputabile al fatto che devono funzionare all’interno di una rete. Un braccialetto connesso utilizzato per il monitoraggio della frequenza cardiaca e dei livelli di ossigeno nel sangue di un paziente, per esempio, potrebbe inviare su base continuativa dati privati sensibili su una connessione wireless a un’applicazione medicale ospitata da un fornitore di servizi basati su Cloud. È utile pensare alla vulnerabilità di questo tipo di dispositivi - e di conseguenza alla protezione richiesta - in termini di livelli. Un livello, per esempio, è rappresentato dalla connessione con la rete Pan (Personal area network), di solito un collegamento radio Bluetooth Low Energy con uno smartphone o un tablet ai quali è accoppiato il braccialetto. Un’estensione di questo livello potrebbe essere rappresentato dal collegamento Wi-Fi tra uno smarphone o un tablet con un gateway o un router domestico. Il secondo livello potrebbe invece essere la piattaforma Cloud, come ad esempio Azure di Microsoft o Aws di Amazon, mentre il terzo livello potrebbe essere la stessa applicazione che gira nel Cloud. In funzione della particolare architettura è possibile definire altri livelli. Naturalmente, l’utente del braccialetto citato nell’esempio si aspetta di poter utilizzare il dispositivo in assoluta tranquillità, senza doversi preoccupare di eventuali minacce relative alla sicurezza. Le minacce da tenere in considerazione sulla base del modello Stride potrebbero comprendere:
- Spoofing: un altro dispositivo finge di essere il braccialetto dell’utilizzatore, accedendo in tal modo ai dati della sua applicazione residenti su Cloud.
- Manomissione: questo attacco prevede la falsificazione delle letture relative alla frequenza cardiaca o del livello di ossigeno nel sangue che vengono fornite dal braccialetto all’applicazione basata su Cloud.
- Divulgazione di informazioni riservate: un intrusore acquisisce i dati medici privati del paziente.
- Attacchi di tipo Dos (Denial of Service): in questo caso si tratta di inibire su base temporanea l’utilizzo di un servizio Cloud. Se un paziente ricorre a un’applicazione basata su Cloud per richiedere con urgenza cure o farmaci, un attacco di questo tipo può avere anche serie conseguenze sulla salute del possessore del braccialetto.
- Il braccialetto in questione potrebbe essere esposto a una più di queste minacce in corrispondenza di ciascuno dei livelli descritti in precedenza. Di conseguenza non è opportuno utilizzare un unico meccanismo di sicurezza per l’intero sistema connesso. Per esempio, come ampiamente riportato, una singola vulnerabilità nel meccanismo di sicurezza di Yahoo! ha consentito agli intrusori di utilizzare cookie falsificati per potersi spacciare come utenti validi e quindi accedere agli account degli utenti sotto attacco senza dover utilizzare un password. Un attacco di tipo “spoofing” (ovvero di falsificazione dell’identità) condotto contro un fornitore di servizi Cloud potrebbe aprire il canale utilizzato dal braccialetto per accedere al Cloud. Di conseguenza è indispensabile assicurarsi che i meccanismi di sicurezza che proteggono gli altri strati - ovvero l’applicazione ospitata nel Cloud e i collegamenti Wi-Fi e Bluetooth Low Energy a Internet - siano implementati separatamente. Per esempio, la chiave utilizzata per cifrare i dati relativi alla frequenza cardiaca inviati all’applicazione basata su Cloud dovrebbe essere diversa dalla chiave impiegata dal braccialetto per autenticare il servizio basata su Cloud.
Requisiti per implementare la sicurezza
Per ciascuna delle sei categorie previste dal modello Stride di classificazione delle possibili minacce esistono corrispondenti tipologie di requisiti di sicurezza (Fig. 1). Oltre a ciò, la sicurezza di un dispositivo IoT si basa su tre elementi:
- Procedure di sicurezza: definiscono quali requisiti di sicurezza vengono utilizzate per fornire l’accesso ai sistema, alla rete e/o ai dati.
- Crittografia: si tratta di algoritmi aritmetici impiegati per implementare differenti tipi di requisiti di sicurezza.
- Resistenza alla manomissione: indica la capacità di un sistema di eseguire la crittografia e garantire la conformità alle proprie procedure senza subire perdite o alterazioni di informazioni sensibili.
Solitamente la prima decisione da prendere riguarda le procedure di sicurezza per un dispositivo IoT e i relativi utenti. Successivamente il progettista deve decidere se i requisiti di sicurezza che utilizzano la crittografia e la resistenza a tentativi di manomissione possono essere implementati in maniera adeguata nel microcontrollore del dispositivi IoT. Ciò comporta l’insorgere di alcune domande in merito a: la possibilità di memorizzare in modo sicuro le chiavi crittografiche; la disponibilità di blocchi per l’accelerazione hardware per gli algoritmi crittografici standard come Rsa, Ecc, Aes e Sha; l’esistenza di un generatore Tnrg (True random number generator) possibilmente certificato; la possibilità di rilevare fenomeni di manomissione fisica del dispostivi IoT. Fino ad ora queste funzioni erano disponibili su un limitato numero di circuiti integrati specialistici. La rapida diffusione di dispositivi IoT di nuova generazione ha generato la richiesta di Mcu che dispongano di queste e di altre funzioni in grado di soddisfare le esigenze specifiche delle applicazioni IoT. Questo è l’obiettivo che Cypress Semiconductor si è proposta di conseguire con l’introduzione della famiglia di Mcu PSoC 6: questi dispositivi abbinano consumi contenuti con capacità di elaborazione avanzate e funzioni di sicurezza multi strato in grado di contrastare in maniera efficace le minacce tipiche dei dispositivi IoT. Una caratteristica tipica delle Mcu PSoC 6 è senza dubbio l’architettura dual-core formata da:
- un core Arm Cortex-M4 ad alte prestazioni in grado di eseguire in tempi brevi compiti che richiedono una gran mole di calcoli e di entrare in una modalità di shut-down a basso consumo una volta terminate le operazioni richieste;
- un core Arm Cortex-M0+ in grado di eseguire semplici funzioni che devono essere sempre attive, come ad esempio far funzionare un sensor hub (in pratica un processore utilizzato per effettuare calcoli sui dati ricevuti dai sensori) o gestire una connessione Ble, garantendo consumi estremamente bassi. L’architettura delle Mcu PSoC 6 sfrutta i vantaggi legati alla disponibilità di due core per garantire la sicurezza della memoria a livello hardware.
Una Mcu a core singolo può operare solamente in un singolo spazio di indirizzamento. I dati sicuri come le chiavi sono memorizzati in questo spazio unitamente al firmware. Una funzione di supervisione in tempo reale (che solitamente fa parte di un Rtos) gestisce quindi gli indirizzi sicuri durante il funzionamento normale in modo tale che l’accesso sia consentito solamente ai programmi autorizzati. Nei dispositivi della famiglia PSoC 6 il controllo dell’accesso può essere configurato a un livello architetturale prima che la Cpu inizi la sua normale attività. Per esempio, una sezione di memoria condivisa può essere configurata in modo tale che l’accesso sia consentito solamente al core Cortex-M0+. In questo modo le Mcu della linea PSoC 6 possono garantire la disponibilità di una memoria la cui sicurezza è basata sull’hardware che contribuisce ad aggiungere un ulteriore livello di protezione contro accessi non autorizzati (Fig. 2). Le Mcu della famiglia PSoC 6 prevedono inoltre un blocco di accelerazione hardware dedicato per la sicurezza che supporta i più diffusi algoritmi di cifratura, come ad esempio Aes, Rsa, Ecc e Sha, oltre a un generatore hardware di numeri casuali. Come accade per la memoria on-chip, l’accesso a questo blocco può essere controllato a livello architetturale. I dispositivi PSoC 6, infine, integrano le funzioni richieste per rilevare eventuali tentativi di manomissione condotti contro il contenitore del dispositivo. I blocchi analogici programmabili possono essere configurati in modo da eseguire il rilevamento di correnti e tensioni e il monitoraggio del clock, mentre la tecnologia di rilevamento capacitivo CapSense di Cypress può essere utilizzata per rilevare tentativi non autorizzati di apertura del contenitore.
