Utilizzare i display e-paper per indicare errori irreversibili e compromissioni della sicurezza nei nodi critici di IoT

I nodi di Internet delle cose (IoT) e IoT industriale (IIoT) sono utilizzati in sistemi sempre più sicuri, dove la sicurezza e la protezione della rete nel suo complesso è più importante della funzionalità dei singoli dispositivi sulla rete. Ciò significa che se un nodo di IoT rileva di esser stato compromesso, o in caso di un errore irreversibile del firmware, l'azione più sicura può essere l'arresto del nodo non appena possibile per proteggere la rete da conseguenze potenzialmente pericolose.

Tuttavia, una volta spento il nodo, tutti i contenuti della memoria volatile vanno persi. L'archiviazione dei dati di debug in memoria non volatile come EEPROM o flash richiede tempo e potenza, aumentando il rischio di potenziali danni. Inoltre, il sistema potrebbe essere stato compromesso al punto che la lettura dei dati all'accensione potrebbe non essere affidabile, se anche la sequenza di accensione è stata compromessa.

Questo articolo spiega come i display e-paper (EPD) possono essere collegati facilmente a un nodo di IoT o IIoT per visualizzare l'ultimo errore noto, fornendo un'indicazione visiva del motivo dell'evento di arresto, affinché i tecnici possano prendere le misure appropriate. Fornisce poi esempi di display e-paper di Pervasive Displays e Display Visions e spiega come interfacciarli a un microcontroller e configurarli per fornire informazioni diagnostiche pur consumando poca o nessuna energia.

Nodi di IoT e IIoT ad alta sicurezza

Spesso è compito dei progettisti di nodi di IoT e IIoT disporre di metodi di sicurezza sempre più sofisticati per garantire il corretto funzionamento del microcontroller host. In generale, ci sono tre tipi di minacce alla sicurezza da cui bisogna proteggersi:

1. Un malfunzionamento del firmware del microcontroller
2. Dati di ingresso non validi provenienti da sensori, tastiere, periferiche seriali o altri dispositivi esterni
3. Azioni umane di natura malvagia

Un malfunzionamento del firmware del microcontroller può verificarsi per una serie di motivi: errori di codifica nel firmware installato, calcoli non validi che causano un malfunzionamento o, in casi estremamente rari, un malfunzionamento hardware del microcontroller. Un firmware ben scritto di solito rileva questo fatto cancellando gli ingressi alle subroutine e alle funzioni. Nei casi estremi in cui il firmware è bloccato o in loop, un watchdog di timeout ripristinerà il firmware vettorizzandolo su una subroutine di controllo degli errori o eseguendo un reset forzato del microcontroller.

In caso di dati in ingresso non validi, ad esempio se un sensore esterno non funziona correttamente o viene manomesso, possono risultare dati non previsti nel codice dell'applicazione. Ad esempio, se il sensore di temperatura ambiente in una sala di controllo registra erroneamente una temperatura di 120 °C, potrebbe trattarsi di un malfunzionamento del sensore o di una manomissione dolosa. Un programmatore di firmware incauto potrebbe non aver previsto nel codice una lettura di temperatura così elevata e ciò potrebbe portare banalmente a una registrazione di dati non corretta, o in maniera più grave può autorizzare l'accesso a un'area sicura da parte di un intruso, o un errore critico nel calcolo di un algoritmo di controllo che potrebbe portare a un guasto dell'apparecchiatura o a gravi lesioni personali. I potenziali risultati negativi sono molteplici.

I malintenzionati possono avere l'intenzione di provocare il malfunzionamento di un nodo di IoT. Il malfunzionamento dovuto a un tentativo di hackeraggio potrebbe essere rilevato dalle routine di sicurezza come un'intrusione, ma potrebbe anche mascherarsi da malfunzionamento del firmware o da dati in ingresso non validi. L'esempio di una lettura di temperatura ambiente di 120 °C potrebbe essere causato da un malintenzionato che prova il comportamento del firmware a una lettura così alta con l'intenzione di testare un metodo di intrusione; ad esempio, le porte potrebbero aprirsi automaticamente se la lettura di 120 °C è erroneamente considerata un incendio.

Reagire ai malfunzionamenti del firmware

Indipendentemente dalla fonte di errore, il firmware del microcontroller per i nodi di IoT e IIoT ad alta sicurezza deve essere impervio agli errori. Tutti i guasti devono essere codificati e bloccati. Gli ingressi alle subroutine e alle funzioni devono essere cancellati e tutti i dati di ingresso del sensore devono essere convalidati. I timer watchdog devono essere programmati con l'intenzione di rilevare il codice bloccato o in loop che richiede troppo tempo sulla base di un tempo di esecuzione noto.

Quando viene rilevato un malfunzionamento del firmware in un nodo di IoT o IIoT ad alta sicurezza, indipendentemente dal fatto che il malfunzionamento sia fortuito o intenzionale, il firmware deve bloccare l'evento il prima possibile. Le azioni comuni includono anche il tentativo di compensare il malfunzionamento. Per un sensore malfunzionante costantemente fuori limite, il firmware può prevedere un modo per quel sensore di compensare i dati difettosi fino a quando non è possibile sostituirlo. Una routine del firmware che restituisce risultati non corretti può essere reinizializzata. Spesso viene inviato un codice di errore attraverso la rete per notificare il problema all'host della rete.

Tuttavia, in alcuni nodi di IoT o IIoT ad alta sicurezza esiste una categoria speciale di malfunzionamenti per la quale non possono o non dovrebbero esserci compensazioni o contromisure. Ciò può includere il rilevamento di manomissioni fisiche, guasti interni del checksum, alcuni guasti dell'autotest integrato (BIST) e qualsiasi guasto che può essere causato da un firmware compromesso o da un sistema violato. Per queste situazioni ad alta sicurezza, l'unica opzione può essere quella di arrestare immediatamente e in modo sicuro il nodo. L'host di rete determinerà che il nodo si è spento quando non risponde alle richieste di rete. Se il nodo si arresta senza inviare un rapporto di errore all'host, e se il nodo ignora i comandi di rete per il riavvio, è indice del fatto che si è verificato un guasto irreversibile e che un tecnico deve esaminare fisicamente il nodo per verificarne la causa.

Tuttavia, una volta che il nodo si è spento, tutta la memoria volatile e i dati di stato sono cancellati immediatamente. Ciò rende molto difficile, se non impossibile, la diagnosi della causa dell'arresto. Opzionalmente, prima di arrestare il nodo, i dati diagnostici possono essere archiviati nella memoria non volatile come EEPROM o flash. Il problema è che la scrittura su questo tipo di memoria richiede tempo, durante il quale il nodo deve rimanere attivo e potrebbe provocare ulteriori danni.

Diagnosticare errori irreversibili con e-paper

Gli EPD assorbono pochissima energia e possono essere utilizzati per memorizzare e visualizzare le informazioni di errore e diagnostiche appena prima di arrestare il nodo. Una volta spento il nodo, l'EPD può mantenere l'immagine visualizzata senza alimentazione per giorni o settimane. Le informazioni sul display forniscono ai tecnici un'indicazione visiva del motivo dell'arresto, per decidere se è sicuro alimentare il nodo di IoT o se deve essere tolto dalla rete per un'analisi dettagliata.

Un esempio di EPD adatto alla visualizzazione di informazioni diagnostiche è il modulo EPD E2271CS091 di Pervasive Displays. Si interfaccia a qualsiasi microcontroller compatibile con un'interfaccia seriale SPI e ha un display ad alto contrasto di 2,71 pollici (Figura 1).

Figura 1: Il modulo EPD E2271CS091 ha un display ad alto contrasto di 2,71" con una risoluzione di 264x176 pixel. Ha un ampio angolo di visione e si interfaccia con qualsiasi microcontroller compatibile con un'interfaccia SPI. (Immagine per gentile concessione di Pervasive Displays)

Il modulo EPD E2271CS091 utilizza un display a transistor a film sottile (TFT) a matrice attiva con una risoluzione nativa di 264x176 pixel a 117 dpi. Ciò permette al display di contenere molte informazioni per assistere i tecnici nella diagnostica. Lo schermo antiriflesso ha un ampio angolo di visione di quasi 180°, che ne consente una facile visualizzazione in posizioni di montaggio insolite. L'EPD richiede un'alimentazione a 3,0 V.

Il microcontroller host invia i dati all'EPD tramite un'interfaccia SPI sul connettore a nastro a 24 pin del display. La comunicazione dati SPI è unidirezionale, dal microcontroller host all'EPD. L'unica comunicazione di ritorno dall'EPD al microcontroller host è un pin "device busy" sul connettore a nastro, semplificando notevolmente l'interfaccia e aumentando la fiducia nei dati diagnostici visualizzati.

Se viene rilevato un errore o un tentativo di hackeraggio, e se l'errore è abbastanza grave da richiedere l'arresto del nodo, l'errore deve prima essere bloccato dal firmware, dal watchdog o da un altro metodo. Il controllo deve poi essere trasferito alla routine di registrazione degli errori che invia i dati all'EPD. Questa routine di registrazione degli errori dovrebbe avere la massima priorità per prevenire l'interruzione o il danneggiamento dei dati. Per la massima affidabilità, si raccomanda che tale routine sia completamente autonoma, senza chiamate a subroutine o funzioni esterne. Preferibilmente, la routine di registrazione degli errori dovrebbe risiedere in maniera permanente nella flash e protetta da scrittura per garantire l'integrità del codice, anche dopo gli aggiornamenti del firmware.

Prima che l'EPD sia aggiornato con i dati di errore, il microcontroller host dovrebbe inviare un comando di reset attraverso l'interfaccia SPI all'EPD per azzerare il display. Dopodiché invia le informazioni del display in bianco e nero in una serie di sequenze di byte, dove ogni bit di un byte rappresenta un pixel sull'EPD. Una volta completata la sequenza, la routine di registrazione degli errori può spegnere il microcontroller. I diversi produttori di microcontroller hanno modi diversi di eseguire lo spegnimento, in quanto ciò dipende dall'architettura e dal produttore. In alcune situazioni, e per motivi di sicurezza, il produttore può avere un modo non documentato di spegnere il microcontroller, disponibile solo su richiesta. Opzionalmente, può essere utilizzato un circuito esterno per interrompere l'alimentazione al microcontroller; tuttavia questo aumenta la complessità del sistema e ne riduce l'affidabilità. Pertanto, si preferisce il controllo dello spegnimento del firmware del microcontroller.

Per aiutare nello sviluppo utilizzando l'EPD, Pervasive Display offre il kit di espansione EPD B3000MS034 (Figura 2). Ha una scheda di espansione con un connettore per display EPD a 24 pin, così come connettori per altri EPD di Pervasive Displays che richiedono connettori a 40 e 26 pin. La scheda di espansione è compatibile con il kit di sviluppo e valutazione LaunchPad di Texas Instruments, ma può essere utilizzata anche con altri kit di sviluppo. Un cavo di collegamento a 20 pin può essere collegato al connettore per basetta a 20 pin a 90° che, una volta saldato alla scheda di espansione, permette di monitorare i segnali di controllo verso l'EPD durante lo sviluppo.

Figura 2: Il kit di espansione per il modulo EPD E2271CS091 di pervasive Displays include un connettore a 24 pin sulla scheda di espansione per il cavo a nastro a 24 pin del display. Comprende anche un cavo di derivazione in parallelo e un connettore per basetta a 20 pin a 90°. (Immagine per gentile concessione di Pervasive Displays)

Un'altra opzione EPD è EA EPA20-A di Display Visions (Figura 3).

Figura 3: L'EPD EA EPA20-A di Display Visions è un display 172x72 che può mantenere lo stato di visualizzazione senza alimentazione. (Immagine per gentile concessione di Display Visions)

Questo EPD ha un display in scala di grigi di 172x72 e utilizza un'interfaccia SPI per la comunicazione con un microcontroller host. L'EPD ha una potenza estremamente bassa, richiede una singola alimentazione a 3,3 V e assorbe solo 40 mW durante un cambio di visualizzazione. L'EPD EA EPA20-A di Display Visions può anche mantenere la visualizzazione quando non è applicata l'alimentazione.

Conclusione

I nodi di IoT e IIoT ad alta sicurezza a volte devono spegnersi in risposta a un errore irreversibile del firmware o una minaccia rilevata. Ciò può comportare la perdita di tutti i dati in memoria volatile, compreso lo stato interno del microcontroller host. Tuttavia, i dati di stato e diagnostici possono essere inviati a un EPD collegato prima dell'arresto e visualizzati per giorni o settimane. Ciò fornisce ai tecnici le informazioni necessarie per determinare la causa dell'arresto e per prendere precauzioni in futuro, se necessario, per salvaguardare e mettere in sicurezza il nodo e la rete.