La sicurezza nell’IoT: come proteggersi dagli attacchi informatici

 

La diffusione dell’Internet delle cose rappresenta un’opportunità unica di sviluppo e crescita sotto molti aspetti, che toccano l’evoluzione della diagnostica, l’analisi dei comportamenti, lo studio delle abitudini ai fini del marketing, il miglioramento delle condizioni di vita in generale, il monitoraggio e l’analisi di processi e di apparati tecnologici distribuiti, ma tanto altro ancora.

L’IoT passa anche attraverso la diffusione massiccia di sensori in ogni ambito, perché servono a raccogliere quei dati (anche noti come Big Data) che permettono poi l’analisi finalizzata all’applicazione nei succitati settori (e non solo) e tale diffusione implica altrettante potenziali “porte aperte” o backdoor, come si usa dire nel gergo della Sicurezza IT, che gli hacker possono sfruttare per portare dei cyber attacchi ai server che presiedono, tipicamente in Cloud, alle reti IoT.

Infatti una miriade di sensori connessi significa anche una capillare e sconfinatamente ampia rete informatica, attaccabile con una certa facilità (perché la cosiddetta “superficie attaccabile” è vastissima) se non vengono adottate strategie ed architetture a prova di penetrazione e non vengono corrette le vulnerabilità.
In questo articolo proveremo a fare il punto sull’architettura e la tecnologia dell’IoT, focalizzando il discorso sulle problematiche di sicurezza che si portano dietro.

Che cos’è l’IoT

Internet delle cose (Internet of Things) significa dotare dispositivi e soprattutto oggetti di uso comune ed anche indossabili, di quell’elettronica che permette loro di rilevare (mediante sensori e dispositivi di digitalizzazione) dati dall’ambiente circostante o dal corpo o veicolo cui vengono applicati e trasmetterli tramite Internet a server di raccolta e di elaborazione, tipicamente in Cloud Computing.
Ma significa anche connettere a server remoti terminali, erogatori, interfacce utente, macchinari e apparati di ogni genere attraverso Internet a una rete di computer che provvede alla raccolta dei dati e talvolta ad impartire comandi.

La connessione alla Rete è, per la natura dei dispositivi, quasi totalmente wireless, il che implica la possibilità di penetrarla, da parte dei cyber-attaccanti, senza dovervi entrare in contatto, ma sfruttando connessioni radio come il WiFi.

Perché l’IoT è a rischio sicurezza

Si tratta di un pericolo concreto perché un ipotetico attaccante potrebbe introdursi nella comunicazione con una certa facilità, sia perché non sempre il progettista dei sistemi ha l’accortezza di adottare algoritmi di protezione e cifratura sicuri, sia perché una connessione radio è per sua natura più vulnerabile, dato che non serve andare localmente ad attaccare un cavo per cercare di entrarvi. Peraltro esistono sul web parecchi tool nati ufficialmente per condurre dei test di penetrabilità (i cosiddetti Penetration Test) al fine di identificare le falle di sicurezza e le vulnerabilità per risolverle, ma troppo spesso impiegati dagli hacker per entrare in un sistema informatico e da lì scalarlo fino ad arrivare a conoscerne il contenuto, violarlo, sottrarlo o renderlo inutilizzabile per poi chiedere un riscatto (è il caso dei ransomware e dei cryptolocker) in denaro per sbloccare i dati.

Tra questi tool c’è KaliLinux, una distribuzione Linux nata per simulare cyber attacchi a vari livelli, che raggruppa tutta una serie di tool altrimenti rintracciabili in Rete distintamente, da configurare e via di seguito. La principale problematica insita nell’IoT è quindi rendere sicura la comunicazione ed evitare intrusioni, identificare e chiudere le backdoor; l’importanza si comprende considerando che un sistema IoT parte da una serie di dispositivi periferici e da un eventuale edge computer (un elaboratore posto sul luogo dove si trovano sensori e apparati IoT egde) che ne pre-elabora i dati per compattarli e inviare sulla linea dati il minimo payload possibile al fine di limitare l’occupazione di banda (e di risorse sulla piattaforma Cloud cui si appoggia il sistema) per poi arrivare a dei server spesso virtualizzati in ambiente Cloud.

Se un attaccante riesce a penetrare la connessione, magari sottraendo l’identità a un dispositivo che ha determinati privilegi di accesso, può portare un attacco informatico sia di tipo verticale, sia di tipo orizzontale: per verticale si intende che dalla linea Internet che accede al server Cloud e superando l’eventuale firewall perimetrale può penetrare sempre più in profondità fino al server principale; per orizzontale significa che una volta entrato in una “macchina” può propagare l’attacco a quelle adiacenti, collegate sulla stessa VLAN dell’ambiente Cloud, del cluster o del rack.

Quindi, una volta fatta l’enumerazione delle risorse (ciò dopo aver esplorato il sistema ed aver catalogato server, storage, interfacce di rete) presenti nel sistema può concentrarsi sulle più interessanti, muovendosi per portare attacchi mirati, per esempio attraverso una privilege escalation che consiste nel cercare di ottenere i privilegi di accesso come quelli di utenti esistenti di cui si ruba l’identità o, peggio ancora, dell’amministratore, che ha, per così dire, potere di vita o di morte sull’infrastruttura attaccata. Tra gli attacchi più pericolosi si annoverano anche gli Esploit, per i quali esistono tool specifici (sempre in rete) come Metasploit.

Quindi entrando da un dispositivo IoT poco protetto, paradossalmente si può portare attacchi ai server con cui si interfaccia; considerato poi, che nel Cloud si ha a che fare con Macchine Virtuali (VM o Virtual Machine che dir si voglia) ovvero server simulati con sistemi operativi virtualizzati su un sistema operativo ospite e attraverso un hypervisor (per esempio VMware) o ambienti di virtualizzazione come VirtualBox, si pone il problema dell’isolamento delle risorse, ovvero di come il Cloud Provider ha studiato l’isolamento tra macchine virtuali, le quali non sono computer fisici ma software in esecuzione su una stessa macchina.

Spesso non si tratta neppure di VM, ma di applicazioni Cloud eseguite su container, quindi unità ancor più astratte e che di fatto sono isolate a livello software ma non nella realtà fisica e delle risorse utilizzate; tanto per dare l’idea, due macchine virtuali possono risiedere su uno stesso disco rigido ed essere separate dall’hypervisor, il quale potrebbe non riuscire a isolare un attacco informatico ricevuto da una delle VM.

Quando si parla di IoT non si intende, però, solamente il rapporto fra end-device e server Cloud ma anche di problematiche originate dalla proliferazione di dispositivi domestici connessi e integrati nelle funzioni domotiche, nella videosorveglianza wireless ecc. e comunque affacciati al web, magari per attingere a funzioni gestite da remoto da parte dei fornitori dei prodotti. In questo caso le vulnerabilità critiche creano un rischio elevato, perché non solo è possibile violare i dispositivi e la loro connessione wireless, ma anche accedervi da Internet inserendosi nella connessione con il fornitore dei servizi; si possono quindi carpire immagini e suoni degli ambienti, codici di blocco delle porte e dei sistemi d’allarme ecc. I dispositivi domestici intelligenti non protetti, o nodi, sono un bersaglio interessante per gli hacker, poiché si intromettono nelle reti domestiche, rubano e utilizzano in modo improprio i dati personali.
Tra gli attacchi che possono essere portati ci sono anche i DDoS, dove l’hacker sfrutta host casuali per colpire un obiettivo specifico. Più specifico dell’ambiente IoT è l’attacco Mirai, che mira a prendere il controllo dei dispositivi connessi al fine di distribuirli in attacchi denial of service (DDoS) non autorizzati e distribuiti in modo massiccio.

Piattaforme IoT e sicurezza

Per proteggersi dagli attacchi, i grandi provider di soluzioni per IoT hanno implementato accorgimenti in grado di garantire la necessaria sicurezza; questo significa che per poter scambiare i dati con essi, i dispositivi che ci si vogliono interfacciare devono rispondere a un protocollo di sicurezza e autenticazione.
Tra questi provider si trovano Amazon, Microsoft, Google, che esigono un’autenticazione anche sofisticata da parte dei dispositivi IoT che vogliono accedere ai sistemi. Per soddisfare tale requisito, i produttori di semiconduttori e moduli per IoT implementano nei propri prodotti i protocolli di autenticazione richiesti dalla connessione alle suddette piattaforme, allo scopo di rendere sicuri i dispositivi IoT edge.

Sicurezza a livello di applicazione

A questo livello, in cui vengono forniti il ​backend e le applicazioni utente, si implemenano controlli di accesso tramite autorizzazioni, ruoli, password complesse, crittografia in transito, registrazione e monitoraggio.
La crittografia è a livello Transport Layer Security (TLS, Fig. 1) che garantisce che il traffico tra dispositivo e server sia indecifrabile da qualsiasi potenziale intercettatore.

Fig. 1

Il TLS viene utilizzato comunemente per accedere ai siti web e prevede un’autenticazione sicura, durante la sessione, dell’host (non del computer o cliente che vi si connette) attraverso uno username e una password. Siccome tali credenziali possono essere sottratte da un hacker, per elevare il livello di sicurezza si ricorre ai certificati; il certificato utilizza la crittografia asimmetrica, che implica una separazione dei ruoli: la parte che rilascia il certificato (CA=autorità di certificazione) garantisce il collegamento tra il dispositivo fisico e la chiave pubblica, la qual da sola non è sufficiente. Inoltre, il verificatore non ottiene mai nulla di valore (come la password) per essere in grado di autenticare il dispositivo. Questo offre un livello di sicurezza molto più elevato, ma sfortunatamente eleva la complessità dei sistemi.
La CA dispone di un certificato radice e di una chiave privata che devono essere custoditi con cura; la chiave può essere utilizzata per generare una CA intermedia con lo scopo di firmare altre chiavi, ad esempio per i dispositivi IoT.
I certificati per autenticare i dispositivi sono formati dalle coppie di chiavi privata e pubblica e sono scritti in ogni dispositivo in fabbrica (in una ROM) ovvero creati e salvati in un’area di memoria Flash protetta.
Affinché i dispositivi possano autenticarsi al Cloud IoT, le loro chiavi pubbliche devono essere caricate nel Cloud stesso. Per eseguire la mutua autenticazione, il dispositivo dovrà memorizzare la propria chiave privata, chiave pubblica, uno stack TLS con mutua autenticazione, un certificato con la chiave pubblica dell’endpoint cui connettersi nel Cloud.
Per elevare il livello di sicurezza è conveniente che i dispositivi periodicamente cambino le chiavi.

Sicurezza a livello di hardware

Archiviare in modo sicuro le chiavi private nei dispositivi IoT può risultare difficile; per elevare la sicurezza bisogna passare all’implementazione a livello hardware. Per questo occorre integrare nei dispositivi un chip in grado di memorizzare in modo sicuro le chiavi stesse: si tratta di un processore di sicurezza dotato di funzionalità anti-manomissione che bloccano tutti i tentativi di hackerare il dispositivo per carpirne le chiavi.
In generale sempre più architetture delegano a un chip specifico la gestione della sicurezza delle connessioni.
Il chip di sicurezza può essere integrato in un gateway tramite cui un sistema domotico o di videosorveglianza (Fig. 2) sfruttando la connessione WiFi, si collegano a Internet; in questo modo è possibile bloccare tentativi di accesso fraudolento dalla Rete e alla rate, portato ad esempio da un hacker penetrato attraverso la connessione WiFi in dispositivi come termostati e telecamere di sorveglianza.

Fig. 2

Complice, anche, il fatto che i sistemi come le telecamere di sicurezza funzionano per periodi di tempo più lunghi ed è complicato eseguire aggiornamenti periodici.
Componenti del genere ne esistono diversi, sovente certificati dai Cloud IoT provider per la connessione dei dispositivi. In questo contesto va precisato che esistono processori multicore che integrano crittografia e memoria ad accesso sicuro in un SoC (System-on-Chip); si tratta di microcontrollori abilitati alla crittografia.
In alternativa è possibile affiancare al processore di una piattaforma esistente un coprocessore di sicurezza, che poi è il chip di sicurezza ed elementi crittografici, che operano attraverso l’integrazione di crittografia, autenticazione e archiviazione sicura dei dati (Fig. 3).

Fig. 3

Un coprocessore di sicurezza è un microcontrollore a basso costo che consente anche a nodi IoT piccoli ed economici di implementare potenti metodi crittografici per l’autenticazione reciproca e la derivazione della chiave di sessione; solleva il microprocessore o microcontrollore principale dal lavoro di elaborazione crittografica, che a sua volta porta a un minore consumo energetico e un tempo di autenticazione più veloce. I coprocessori di sicurezza contengono chiavi e certificati di sicurezza.
Altro esempio è nella famiglia Microchip SAML10/11 di MCU a 32 bit low-power, capaci di offrire sicurezza a livello di chip e basati sulla tecnologia Arm TrustZone. Le MCU integrano un’ampia varietà di periferiche, le funzionalità di sicurezza, clock a 32 MHz, fino a 64 kB di Flash e 16 kB di SRAM.
Il micro SAM L11-KPH aggiunge una radice della chiave di attendibilità fornita in fabbrica per assegnare alla MCU un’identità sicura che può essere utilizzata per lo sviluppo di applicazioni IoT sicure. SAM L11 e SAML11-KPH sono supportati da un ecosistema di sicurezza completo che include la soluzione Kinibi-M della Trustonic e l’architettura Secure Deploy della Secure Thingz.
Gli MCU SAM L11 sono PSA Certified Livello 1, che garantisce l’implementazione delle migliori pratiche di sicurezza integrate per i prodotti IoT, tra cui una protezione anti-manomissione a 256 byte su RAM, True Random Number Generator (TRNG), standard AES di codifica avanzata, Secure Hash Algorithm (SHA) e storage sicuro delle chiavi.
Altra soluzione di Microchip è il CEC1702: si tratta di un microcontrollore basato su architettura ARM Cortex-M4 con integrata una soluzione completa abilitata per la crittografia hardware, che consente l’avvio sicuro del firmware di sistema. Questo microcontrollore a 32 bit a basso consumo ma potente e programmabile, protegge i dati attraverso la crittografia a chiave pubblica e la convalida, garantendo che il firmware sia stato firmato digitalmente e non sia stato alterato.
La sua suite di crittografia hardware riduce i tempi di elaborazione di ordini di grandezza rispetto alle soluzioni software e, ad esempio, fornisce un miglioramento delle prestazioni da 20x a 50x per l’accelerazione PKE, nonché un miglioramento 100x per la crittografia/decrittografia.
La famiglia CEC1702 comprende il dispositivo CEC1702Q-B2-I / SX (libero) e il CEC1702Q-S1-I/X che va utilizzato con il firmware Soteria personalizzato, disponibile in base a un contratto di licenza firmato (SLA). Il processore conta su 480 kB di SRAM per codice e dati, su una robusta suite di crittografia hardware e 2,5 kB bit di memoria OTP programmabile dall’utente.
L’avvio protetto fornisce una radice di attendibilità basata sull’hardware. Il CEC1702 può sostituire o integrare il microcontrollore esistente nel device IoT perché è un micro completo di funzionalità di autenticazione e crittografia semplici e intuitive per le applicazioni connesse, che possono sia essere fornite nella modalità coprocessore di sicurezza, sia integrate nell’applicazione.

Amazon AWS IoT

AWS IoT è una piattaforma Cloud gestita da Amazon Web Services che consente ai dispositivi connessi di interagire facilmente e in sicurezza con le applicazioni Cloud e altri dispositivi. Affinché i dispositivi possano interagire con AWS IoT tramite il protocollo MQTT (Message Queue Telemetry Transport) che è quello tipico dell’IoT, devono prima autenticarsi utilizzando l’autenticazione reciproca TLS e quindi scambiandosi le chiavi (handshake).

Per archiviare queste chiavi in modo sicuro sui dispositivi IoT da connhettere ad AWS IoT si può contare su chip di sicurezza come l’ATECC508A della Microchip, che dispone di un meccanismo di archiviazione delle chiavi sicuro: una volta memorizzata una chiave nell’ATECC508A, il suo contenuto non può essere letto. Il chip realizza questo con funzioni di accelerazione crittografica basate su hardware che gli consentono di eseguire operazioni crittografiche molto rapidamente e a basso consumo. Microchip può precaricare i certificati sull’elemento di sicurezza durante la produzione, prima della consegna.

La combinazione di questa funzionalità con il supporto di AWS IoT per autorità di certificazione personalizzate e la registrazione just-in-time può semplificare il provisioning e la sicurezza dei dispositivi. Per facilitare utilizzo e integrazione dell’ATECC508A nei dispositivi che si connetteranno ad AWS IoT, Microchip rende disponibile un kit di valutazione chiamato Zero Touch Secure Provisioning Kit, che include un microcontrollore SAM G55 Cortex-M4, il chip di sicurezza ATECC508A e un modulo 802.11 b/g/ ad alta efficienza energetica ATWINC1500 e viene fornito con istruzioni per iniziare a lavorare con AWS IoT.

I settori attenti all’affidabilità, tra cui l’automazione domestica e degli edifici, stanno adottando sempre più soluzioni hardware incentrate su processore di sicurezza, che dev’essere integrato nelle prime fasi del ciclo di progettazione, quindi la scelta della piattaforma hardware cui affidarsi è fondamentale ed è la prima da fare.
Proteggere i dispositivio IoT è importante, ma ancora più importante è la protezione dell’elemento di raccolta dei dati di questi dispositivi per esempio un server web o un servizio Cloud, come Amazon Web Services (AWS). In altre parole, l’implementazione della sicurezza è fondamentale a più livelli in tutto il progetto, dal sensore al nodo della Smart Home, al collegamento del servizio Cloud.

Fig. 4

Questo ci porta a un aspetto critico della sicurezza negli ambienti di automazione domestica, ossia l’autenticazione del dispositivo al Cloud.
Come accennato, un tipo di autenticazione da dispositivo a Cloud è il TLS, tuttavia se è implementato a livello software, non avere una memoria sicura per chiavi e dati sensibili consente agli hacker di sfruttare bug del software e penetrare nella memoria del microcontrollore o microprocessore in cui risiedono dati sensibili. D’altra parte, i co-processori di sicurezza che memorizzano chiavi private, certificati e dati sensibili in hardware sicuro facilitano un rafforzamento dei ben noti stack di implementazione TLS, come Secure Socket Layer (SSL) sotto forma di OpenSSL e wolfSSL.
La protezione avanzata consente agli sviluppatori di eliminare le vulnerabilità del software creando livelli di sicurezza hardware aggiuntivi. Un coprocessore di sicurezza offre il modo più semplice per implementare uno stack TLS sicuro. Oltre a consentire l’hardening TLS, un coprocessore di sicurezza consente a un nodo IoT l’autenticazione a un servizio Cloud senza un ritardo percepibile dall’utente.

Microsoft Azure Sphere

Azure Sphere è una piattaforma applicativa Cloud protetta con funzionalità di comunicazione e di protezione integrate per i dispositivi connessi a Internet; implementa un servizio di sicurezza che stabilisce una connessione sicura tra un dispositivo fisico (un microcontrollore o un microprocessore) e il servizio cloud Azure di Microsoft. In pratica l’hardware IoT garantisce il secure boot (avvio sicuro) delle applicazioni e delle connessioni con il Cloud. Il secure boot è qualcosa che impedisce l’avvio di un sistema operativo se questo è stato alterato, impedendo, per esempio, che un nodo IoT corrotto da un attacco informatico possa instaurare una connessione con il Cloud.
In questo modo l’attacco malevolo ai dati diventa pressoché impossibile.

Come è per AWS IoT, la connessione tra un dispositivo Azure Sphere e il servizio di sicurezza del cloud Azure si basa su un sistema di autenticazione dell’identità del dispositivo, garantendo così l’integrità e l’attendibilità del software di sistema.
Il servizio fornisce anche il canale protetto utilizzato da Microsoft per scaricare e installare automaticamente gli aggiornamenti del sistema operativo Azure Sphere e gli aggiornamenti delle applicazioni dell’utente sui dispositivi distribuiti. Il cuore della tecnologia risiede in un’unità microcontroller (MCU) protetta e connessa, in cui risiedono un sistema operativo personalizzato basato su Linux e un servizio di sicurezza basato sul Cloud Azure.
Il primo MCU certificato Azure Sphere (e per il momento l’unico) è prodotto da Mediatek. Include il chip MediaTek 3620, siglato MT3620 (Fig. 5).

Fig. 5

Tale componente integra:
• processore ARM Cortex-A7 (500 MHz);
• 2 sottosistemi I/O ARM Cortex-M4F (200 MHz);
• 5 interfacce UART;
• 1 interfaccia I²C (Inter-integrated Circuit) con clock del bus a 100 KHz, 400 KHz e 1 MHz;
• 1 interfaccia SPI (Serial Periphera Interface) con clock fino a 40 MHz;
• 2 interfacce I²S (Inter-integrated System);
• 8 ingressi ADC;
• 12 contatori PWM;
• 72 pin GPIO;
• connettività WiFi.

Il chip componente MT3620 contiene anche il sottosistema di sicurezza Microsoft Pluton con un core Arm Cortext-M4F dedicato, che gestisce l’avvio e il funzionamento sicuro del sistema; il servizio di sicurezza Azure Sphere permette quindi ai microcontrollori dei device IoT una connessione sicura e garantisce che ogni dispositivo venga avviato solo con una versione autorizzata di applicazioni approvate. Inoltre, fornisce un canale protetto tramite cui Microsoft può scaricare e installare automaticamente gli aggiornamenti del sistema operativo per i dispositivi distribuiti sul campo, al fine di limitare i problemi di sicurezza.

Il chip Mediatek MT3620 si rivolge a un’ampia gamma di applicazioni IoT, tra cui smart home, IoT commerciale e industriale e molti altri ambiti, grazie al suo ampio sottosistema di periferiche I/O che consente flessibilità e libertà di progettazione dei dispositivi.
Il processore per applicazioni ad alte prestazioni dell’MT3620 è un processore applicativo Arm Cortex-A7 che funziona fino a 500 MHz di clock e include cache L1 di grandi dimensioni e cache L2 e SRAM integrata per un funzionamento altamente efficiente su un’ampia gamma di applicazioni.
Due sottosistemi I/O Arm Cortex-M4F per uso generico in esecuzione fino a 200 MHz supportano i requisiti delle periferiche on-chip.
Questi due sottosistemi I/O Cortex-M4F sono destinati principalmente a supportare l’elaborazione I/O in tempo reale, ma possono anche essere utilizzati per il calcolo e il controllo generale. I core Cortex-M4F possono eseguire qualsiasi sistema operativo fornito dall’utente finale o eseguire una “app bare metal” senza sistema operativo. La memoria Flash per supportare Cortex-A7 ed entrambi i processori Cortex-M4F è integrata nell’MT3620.

Il sottosistema di sicurezza Microsoft Pluton e il sottosistema WiFi dedicato sono al di fuori di questi tre core accessibili all’utente finale; il sottosistema radio WiFi 802.11a/b/g/n dual-band 1×1 è controllato da un core RISC Andes N9 a 32 bit dedicato; tale sottosistema contiene il transceiver radio in banda base e il MAC progettati per consentire applicazioni ad alto rendimento con grande efficienza energetica. Il funzionamento delle funzionalità di sicurezza MT3620 e della rete WiFi è isolato ed eseguito indipendentemente dalle applicazioni dell’utente finale. Solo le funzionalità hardware supportate da Azure Sphere sono direttamente accessibili agli utenti finali. Di conseguenza, le funzionalità di sicurezza e quelle del WiFi sono accessibili solo tramite API Azure Sphere definite e sono resistenti agli errori di programmazione nelle applicazioni degli utenti finali, indipendentemente dal fatto che queste applicazioni vengano eseguite sui core Cortex-A7 o Cortex-M4F accessibili dall’utente.

Microsoft fornisce un potente ambiente di sviluppo basato su Visual Studio che sfrutta il compilatore gcc, consentendo lo sviluppo delle applicazioni dei clienti in C.
Microsoft Azure Sphere MT3620 fornisce un livello di sicurezza senza precedenti per i dispositivi collegati. La soluzione sicura fornisce autenticazione e attestazione del dispositivo, supporta aggiornamenti software over-the-air remoti per mantenere la sicurezza di fronte agli attacchi in evoluzione e automatizza anche la registrazione e la segnalazione degli errori.
MediaTek NeuroPilot-Micro fa parte di NeuroPilot ed è progettato specificamente per applicazioni di apprendimento automatico miniaturizzate. Sfrutta gli strumenti di ottimizzazione NeuroPilot e fornisce framework di reti neurali popolari per l’inferenza. NeuroPilot-Micro SDK supporta TensorFlow Lite per microcontrollori (TFLm) e API di ottimizzazione per l’inferenza e l’ottimizzazione del modello.
La Fig. 5 propone lo schema a blocchi dell’MT3620.
La maggior parte dei pin viene multiplexata tra I/O di utilizzo generico (GPIO) e altre funzioni: oltre ai pin GPIO elencati, i GPIO12-23 sono disponibili rispettivamente nei pin MT3620 27-38.

Fig. 6

Alcuni pin presentano capacità di multiplexing tra GPIO, PWM (Pulse Width Modification, modifica della larghezza degli impulsi) e contatori hardware.
Le funzioni GPIO attualmente supportate sono l’impostazione dell’output alto/basso e la lettura dell’input. Sono supportate anche le modalità di guida aperte di svuotamento/open source e il controllo del livello di attendibilità dell’unità. Gli interrupt esterni sono supportati nel solo core Arm Cortex M4 core, ma non nel core A7.
Se l’applicazione usa un controller PWM, tutti i pin associati a tale controller vengono allocati per l’uso come output PWM e nessuno di essi può essere usato come GPIO. L’hardware PWM può essere configurato per un clock 32 kHz, 2 MHz (XTAL/13) o 26 MHz (XTAL). Nel core di alto livello (A7), il driver Linux userà sempre il clock a 2 MHz; ciò comporta limitazioni del ciclo di servizio e del periodo nelle applicazioni di alto livello.

Google IoT

Anche questa piattaforma (quella di “Big G”) implementa dei meccanismi di sicurezza che prevedono sia lo scambio di chiavi e la memorizzazione sicura in un co-processore dotato di funzionalità anti-manomissione, sia l’utilizzo di un JWT per l’autenticazione.
Anche in questo caso sono supportati coprocessori crittografici Microchip come l’ATECC608A, che non solo permette la memorizzazione sicura delle chiavi private, ma convaliderà anche il firmware e offrirà un processo di avvio più sicuro (secure boot) per il dispositivo.

L’ATECC608A offre molte funzionalità: per esempio la chiave privata viene generata dallo stesso elemento protetto, non da un’autorità certificatrice (CA); il chip utilizza un generatore di numeri casuali per creare la chiave, rendendo praticamente impossibile la decifrazione. La chiave privata non lascia mai il chip e utilizzando la chiave privata, il chip potrà generare una chiave pubblica che potrà essere firmata dalla CA scelta dalla piattaforma e dal cliente.

Microchip esegue questa firma elettronica in una struttura sicura dedicata collocata negli Stati Uniti, dove un impianto isolato e protetto memorizza le chiavi CA intermedie del cliente (produttore di dispositivi IoT) in un server altamente sicuro collegato alla linea di produzione.
Una volta che i dispositivi protetti hanno generato ciascuno le proprie coppie di chiavi, le chiavi pubbliche corrispondenti vengono inviate all’account Google Cloud del cliente e archiviate in modo sicuro nel gestore dispositivi Cloud IoT Core. Poiché Cloud IoT Core può archiviare fino a 3 chiavi pubbliche per dispositivo, la rotazione delle chiavi può essere eseguita con sicurezza senza problemi. Tutto ciò che il cliente deve fare è fornire una CA intermedia per un determinato lotto di dispositivi alla Microchip, che restituirà un reel di chip securizzati, che il produttore dei dispositivi IoT monterà poi sulle proprie schede.

Autenticazione mediante JWT

Il TLS è una soluzione adatta a proteggere la comunicazione tra dispositivi (PC, sistemi remoti) e il Cloud, ma lo stack di autenticazione non è l’ideale per l’IoT, in quanto lo stack richiesto per l’autenticazione reciproca è di grandi dimensioni e deve avere l’informazione su dove sono archiviate le chiavi, ovvero deve sapere quale elemento sicuro viene utilizzato e come comunicare con esso. Uno stack OpenSSL presumerà che le chiavi siano archiviate in un file system e debbano essere modificate per accedere all’elemento secure, ma ciò implica di eseguire sviluppo e test ad ogni aggiornamento dello stack. Con l’arrivo della TLS 1.3 è probabile che questo lavoro dovrà essere eseguito più volte, il che impone ai produttori di device IoT costi non indifferenti.
In alternativa è possibile utilizzare uno stack TLS già compatibile con l’elemento sicuro, come WolfSSL, ma tale soluzione comporta un costo di licenza che si aggiunge al costo del dispositivo.
Come alternativa a ciò, il servizio Google Cloud IoT permette di utilizzare un JWT, ossia un JSON Web Token, che è una soluzione molto comune per autenticare il dispositivo invece di fare affidamento sull’autenticazione reciproca implementata da uno stack TLS.

Il dispositivo stabilirà una connessione sicura all’endpoint Cloud globale per il Cloud IoT Core (mqtt.googleapis.com) utilizzando lo schema TLS, ma invece di attivare l’autenticazione reciproca genererà un JWT molto semplice, lo firmerà con la sua chiave privata e lo passerà al Cloud come password.
Il coprocessore Microchip ATECC608 offre una semplice interfaccia per firmare il dispositivo attraverso il JWT in modo sicuro e senza mai esporre la chiave privata. Infatti il JWT viene ricevuto da Google Cloud IoT, la chiave pubblica del dispositivo viene recuperata e utilizzata per verificare la firma JWT; se valida, l’autenticazione reciproca è effettivamente stabilita (Fig. 7).

Fig. 7

La convalida JWT può essere impostata dal cliente, ma la sua durata non supera mai le 24 ore, il che la rende molto effimera e difficilmente intercettabile dagli hacker.
L’utilizzo del JSON Web Token porta con sè numerosi vantaggi:

• non esiste alcuna dipendenza dallo stack TLS utilizzato per eseguire l’autenticazione del dispositivo, il che semplifica l’aggiornamento allo stack TLS alla 1.3, quando necessario, senza complicare e rendere onerose le operazioni;
• i dispositivi non hanno bisogno di memorizzare la loro chiave pubblica e il certificato, il che consente di lasciare libera una parte significativa della memoria sul dispositivo;
  il dispositivo non necessita di ospitare uno stack TLS completo, cosa che, anche questa, libera spazio di memoria per l’applicazione;
• i requisiti di memoria sono ben al di sotto dei 50 kB, il che apre la porta all’utilizzo di un MCU (unità microcontrollore) molto più piccolo.

Gli ultimi due punti evidenziano come l’adozione del JSON Web Token rimuova l’intera complessità della gestione dei certificati, consentendo agli sviluppatori di concentrarsi sullo sviluppo del prodotto, sia sotto l’aspetto delle risorse disponibili, sia per quel che riguarda lo sviluppo delle applicazioni IoT.

Conclusioni

Bene, possiamo ritenere di aver terminato; vi abbiamo introdotto il concetto di IoT e quello attualissimo e imperativo della sicurezza dell’Internet of Things, la cui diffusione e la vulnerabilità che ne può derivare ha imposto l’adozione di protocolli e piattaforme di sicurezza in grado di colloquiare con i device periferici.

Abbiamo inoltre spiegato come il concetto di sicurezza e di autenticazione delle connessioni si sia spostato dall’applicazione e dal software, direttamente all’hardware, con la creazione e l’implementazione delle funzioni di sicurezza all’interno di chip specifici, inviolabili e capaci di garantire lo scambio di chiavi di crittografia private in tutta sicurezza, alcuni dei quali progettati secondo le specifiche dei principali provider.