Brug af e-paper displays til at indikere fatale fejl og kompromitteret sikkerhed i kritiske IoT-noder

Internet of Things (IoT) og Industrial IoT- og IIoT-noder bruges i stadig mere sikre systemer, hvor sikkerhed i netværket som helhed er vigtigere end funktionaliteten af de enkelte enheder. Dette betyder, at hvis en IoT-node opdager, at den er kompromitteret, eller hvis der skulle opstå en uoprettelig firmwarefejl, kan den sikreste handling være, at noden slukkes, så snart det er praktisk muligt for at beskytte noden og netværket mod potentielt farlige konsekvenser.

Når noden er slukket, går alt flygtigt hukommelsesindhold dog tabt. Opbevaring af debug-data i ikke-flygtig hukommelse såsom EEPROM eller Flash bruger tid og strøm, hvilket øger risikoen for potentiel skade. Derudover kan systemet være kompromitteret til et punkt, hvor aflæsning af data ved opstart muligvis ikke giver pålidelige data, hvis opstartssekvensen også er kompromitteret.

Denne artikel forklarer, hvordan e-paper displays (EPD'er) let kan knyttes til en IoT- eller IIoT-knude for at vise den sidst kendte fejl, hvilket giver en visuel indikation af årsagen til nedlukningen, så teknikere kan tage den passende handling. Det giver derefter eksempler på e-paper displays fra Pervasive Displays og Display Visions og diskuterer, hvordan disse displays kan forbindes til en mikrocontroller og konfigureres til at levere diagnostikoplysninger, mens der kun trækkes lidt eller ingen strøm.

IoT- og IIoT-noder med høj sikkerhed

Det påhviler i stigende grad designere af IoT- og IIoT-noder at have mere og mere sofistikerede sikkerhedsmetoder for at garantere korrekt drift af host-mikrocontrolleren. Generelt er der tre slags sikkerhedstrusler, der skal beskyttes mod:

1. En mikrocontroller firmwarefejl
2. Ugyldige inputdata fra sensorer, tastaturer, seriel periferiudstyr eller andre eksterne enheder
3. Handling fra en hacker

En mikrocontroller-firmwarefejl kan opstå af en række årsager: Kodningsfejl i den installerede firmware; ugyldige beregninger, der resulterer i en funktionsfejl eller i ekstremt sjældne tilfælde en hardwarefejl i mikrocontrolleren. Velskrevet firmware registrerer normalt dette ved at skrubbe input til underrutiner og funktioner. I ekstreme tilfælde, hvor firmwaren er låst eller looper, vil en watchdog-timeout gendanne firmwaren ved at vektorere til en fejlreguleringsundervisning eller udføre en hard-reset nulstilling af mikrocontrolleren.

I tilfælde af ugyldige inputdata, f.eks. Hvis en ekstern sensor fungerer forkert eller er manipuleret med, kan der forekomme data uden for området, som muligvis ikke er korrekt registreret i applikationskoden. For eksempel, hvis omgivelsestemperaturføleren i et menneskeligt beboet kontrolrum forkert registrerer 121 °C, kan dette være en sensorfejl eller ondsindet manipulation. En skødesløs firmwareprogrammerer har muligvis ikke kodet til den høje temperaturaflæsning, der kan føre til noget så trivielt som forkert datalogning eller noget så alvorligt som at give en ubuden gæst adgang til et sikkert område eller så kritisk som en fejl i en kontrolalgoritme beregning, der kan føre til udstyrssvigt eller alvorlig personskade. De potentielle negative resultater er mange.

Hackere er forskellige, fordi de kan have den bevidste hensigt at få IoT-noden til at fungere forkert. Fejlen på grund af hackingforsøget kan blive opdaget af sikkerhedsrutiner som et indbrud; det kan dog også skjule sig som en firmwarefejl eller ugyldige eksterne inputdata. Eksemplet på en aflæsning af den omgivende temperatur på 121 ° C kunne være forårsaget af en hacker, der testede firmwareadfærd ved en så høj aflæsning med det formål at teste en metode til indtrængen for eksempel kan døre automatisk låses op, hvis aflæsningen af 121 °C ved omgivelsestemperatur fejlagtigt vurderes som en brand.

Reagerer på firmwarefejl

Uanset fejlkilden skal microcontroller-firmware til IoT- og IIoT-noder med høj sikkerhed være fejlintolerant. Alle fejl testes i koden og fanges. Indgange til underrutiner og funktioner skal testes, og alle sensorindgangsdata skal valideres. Watchdog-timere skal programmeres med det formål at registrere låst eller loopende kode, der tager for lang tid baseret på en kendt køretid.

Når en firmwarefejl registreres i en højsikkerheds-IoT- eller IIoT-node, uanset om fejlen er utilsigtet eller bevidst, skal firmware fange eventet så hurtigt som muligt. Almindelige handlinger inkluderer forsøg på at kompensere for fejlen. For en sensor, der ikke fungerer korrekt og der konstant er uden for rækkevidde, kan firmwaren have en "nøddrift-tilstand" for den pågældende sensor for at kompensere for de dårlige data, indtil den kan udskiftes. En firmware-rutine, der returnerer forkerte resultater, kan initialiseres igen. Ofte sendes en fejlkode over hele netværket for at underrette netværts-hosten om problemet.

Imidlertid er der i nogle IoT- eller IIoT-noder med høj sikkerhed en særlig kategori af funktionsfejl, for hvilke der ikke kan eller ikke bør være kompensation eller modforanstaltninger. Dette kan omfatte detektion af fysisk manipulation, interne kontrolsumfejl, nogle indbyggede BIST (indbygget selvtest)-fejl og enhver fejl, der kan være forårsaget af kompromitteret firmware eller et hacket system. I disse situationer med høj sikkerhed er den eneste mulighed muligvis straks og sikkert at slukke for noden. Netværks-hosten vil afgøre om noden er slået fra, når den ikke reagerer på netværksanmodninger. Hvis noden slukkes uden at sende en fejlrapport til hosten, og hvis noden ignorerer netværkskommandoer for at genstarte, er det en indikation af, at der er opstået en alvorlig fejl, og at en tekniker skal tilkaldes for fysisk at undersøge noden for årsagen.

Men når noden er slukket, slettes al flygtig hukommelse og statusdata straks. Dette gør diagnosering af årsagen til nedlukningen meget vanskelig, hvis ikke umulig. Valgfrit, inden diagnosticering af noden, kan diagnostiske data lagres i ikke-flygtig hukommelse såsom EEPROM eller flashhukommelse. Problemet er, at det tager tid at skrive til disse typer hukommelse, mens noden skal forblive aktivt og muligvis resultere i yderligere skader.

Diagnosticering af fatale fejl med e-papir

EPD'er trækker meget lidt strøm og kan bruges til at gemme og vise fejl- og diagnostiske oplysninger lige før nedlukning af noden. Når noden er slukket, kan EPD opretholde sit displaybillede uden strøm i dage eller uger. Oplysningerne på skærmen giver teknikere en visuel indikation af årsagen til nedlukningen, så de kan beslutte, om det er sikkert at tænde for IoT-noden, eller om det skal tages ud af netværket til detaljeret analyse.

Et eksempel på en EPD, der er egnet til visning af diagnostisk information, er Pervasive Displays’ E2271CS091 EPD-modul. Det interfacer til enhver kompatibel mikrocontroller med en SPI seriel interface og har en 2,71 tommer (in.) Skærm med høj kontrast (figur 1).

Figur 1: E2271CS091 EPD-modulet har en høj kontrast på en 2,71 tommer skærm med en opløsning på 264 x 176 pixels. Den har en bred betragtningsvinkel og grænseflader til enhver kompatibel mikrocontroller med en SPI-interface. (Billedkilde: Pervasive Displays)

E2271CS091 EPD-modulet bruger en aktiv matrix-tyndfilmtransistor (TFT)-display med en original opløsning på 264 x 176 pixels ved 117 pr. tomme (dpi). Dette gør det muligt for skærmen at indeholde yderligere information til at hjælpe teknikere med diagnostik. Antirefleksskærmen har en bred betragtningsvinkel på næsten 180˚, hvilket gør det let at se skærmen, når den er monteret på begrændsede områder. EPD'en kræver en 3,0 volt strømforsyning.

Host-mikrocontrolleren sender data til EPD'en via et SPI-interface på skærmens 24-bens båndstik. SPI-datakommunikationen er envejs fra host-mikrocontrolleren til EPD. Den eneste kommunikation tilbage fra EPD til host-mikrocontrolleren er en "enhed optaget" stift på båndstikket, hvilket i høj grad forenkler interfaset og øger tilliden til de viste diagnostiske data.

Hvis der opdages en fejl eller et hackerforsøg, og hvis fejlen er alvorlig nok til at kræve en nedlukning af noden, skal fejlen først fanges af firmware, vagthund eller anden metode. Kontrol skal derefter overføres til den fejlloggingsrutine, der sender data til EPD'en. Denne fejlloggingsrutine bør være den højeste prioritetsopgave for at forhindre afbrydelse eller ødelæggelse af data. For maksimal pålidelighed anbefales det, at fejlloggingsrutinen er helt selvstændig uden opkald til eksterne underrutiner eller funktioner. Ideelt set skulle fejlloggingsrutinen være i permanent skrivebeskyttet flash for at garantere kodens integritet, selv efter firmwareopdateringer.

Før EPD opdateres med fejldata, skal host-mikrocontrolleren først sende en soft reset-kommando over SPI-grænsefladen til EPD'en for at rydde displayet. Derefter sender den sort/hvide displayinformation i en række bytesekvenser, hvor hver bit i en byte repræsenterer en pixel på EPD'en. Når sekvensen er afsluttet, kan fejlloggingsrutinen lukke mikrocontrolleren. Forskellige producenter af mikrocontroller har forskellige måder at lukke på, da dette afhænger af arkitektur. I nogle situationer og af sikkerhedsmæssige årsager kan producenten muligvis have en udokumenteret måde at lukke mikrocontrolleren på, som kun er tilgængelig på anmodning. Eventuelt kan et eksternt kredsløb bruges til at afbryde strømmen til mikrokontrolleren; dette øger dog systemets kompleksitet og reducerer pålideligheden. Derfor foretrækkes kontrol af nedlukning af firmware af mikrocontrolleren.

For at hjælpe med udvikling ved hjælp af EPD tilbyder Pervasive Displays B3000MS034 EPD-forlængelseskit (figur 2). Det har et udvidelseskort med et stik til 24-pin EPD-skærm samt stik til andre Pervasive Display EPD'er, der kræver 40-pin og 26-pin stik. Udvidelseskortet er kompatibelt med Texas Instruments 'Launchpad udviklings- og evalueringskit, men kan bruges sammen med andre udviklingskit. Et 20-polet brokabel kan tilsluttes til det 20-polede 90˚-hovedstik, som, når det loddes på forlængerkortet, gør det muligt at overvåge styresignaler til EPD under udvikling.

Figur 2: Udvidelseskittet til Pervasive Displays E2271CS091 EPD-modulet inkluderer et 24-bens stik på forlængelseskortet til skærmens 24-bens båndkabel. Det inkluderer også et brokabel og et 90˚ 20-pin headerstik. (Billedkilde: Pervasive Displays)

En anden EPD-mulighed er Display Visions EA EPA20-A (Figur 3).

Figur 3: Display Visions' EA EPA20-A EPD er en 172 x 72 skærm, der kan opretholde skærmbillede uden strøm tilsluttet. (Billedkilde: Display Visions)

Denne EPD har en 172 x 72 gråtoneskærm og bruger også en SPI-interface til kommunikation med en host-mikrocontroller. EPD'en har ekstremt lav effekt, der kræver en enkelt 3,3 volt forsyning og trækker kun 40 milliwatt (mW) under en opdatering. Display Visions EA EPA20-A EPD kan også bevare sit display, når der ikke er tilsluttet strøm.

Konklusion

IoT- og IIoT-noder med høj sikkerhed skal undertiden slukke som reaktion på en fatal firmwarefejl eller opdaget trussel. Dette kan resultere i tab af alle flygtige data inklusive host-mikrocontrollerens interne status. Imidlertid kan status og diagnostiske data sendes til en tilsluttet EPD inden nedlukning og vises i dage eller uger. Dette giver teknikere de oplysninger, de har brug for til at bestemme årsagen til nedlukningen og om nødvendigt tage fremtidige forholdsregler for at beskytte og sikre noden og netværket.