Bruk av e-papirskjermer for å indikere fatale feil og sikkerhetsrisikoer i kritiske IoT-noder

Tingenes internett (Internet of Things – IoT) og industriell-IoT (Industrial IoT – IIoT) brukes i stadig sikrere systemer der trygghet og sikkerhet for nettverket som helhet er viktigere enn funksjonaliteten til de enkelte enhetene på nettverket. Dette betyr at hvis en IoT-node oppdager at den er kompromittert, eller hvis en uopprettelig firmware-feil skulle oppstå, kan den sikreste handlingen være å slå av noden så snart det er praktisk mulig, for å beskytte noden og nettverket mot potensielt farlige konsekvenser.

Når noden er slått av, går imidlertid alt flyktig minneinnhold tapt. Lagring av feilsøkingsdata i ikke-flyktig minne, for eksempel EEPROM eller flash, bruker tid og strøm, noe som øker risikoen for potensiell skade. I tillegg kan systemet ha blitt kompromittert til et punkt hvor lesing av data om oppstart kanskje ikke gir pålitelige data hvis oppstartssekvensen også er kompromittert.

Denne artikkelen forklarer hvordan e-papirskjermer (EPD) enkelt kan kobles til en IoT-node eller IIoT-node for å vise den siste kjente feilen, og gir en visuell indikasjon på årsaken til avslutningshendelsen slik at teknikere kan treffe de nødvendige tiltakene. Den gir oss deretter noen eksempler på e-papirskjermer fra Pervasive Displays og Display Visions, samt ta for seg hvordan disse skjermene kan kobles til en mikrokontroller og konfigureres til å gi diagnoseinformasjon mens de trekker liten eller ingen strøm.

Høysikkerhets-IoT- og IIoT-noder

Det hviler i økende grad krav til stadig mer sofistikerte sikkerhetsmetoder på designere av IoT- og IIoT-noder, for å garantere riktig drift av vertsmikrokontrolleren. Generelt er det tre typer sikkerhetstrusler det må beskyttes mot:

1. Feil på mikrokontrollers firmware
2. Ugyldige inndata fra sensorer, tastaturer, serielle periferiutstyr eller andre eksterne enheter
3. Handling fra ondsinnet aktør

Feil på en mikrokontrollers firmware kan oppstå av en rekke grunner: kodefeil i den installerte firmwaren, ugyldige beregninger som resulterer i en feil, eller – i svært sjeldne tilfeller, en maskinvarefeil på mikrokontrolleren. Velskrevet firmware oppdager vanligvis dette ved å skrubbe inngangene til underrutiner og funksjoner. I ekstreme tilfeller der firmwaren er låst eller går i endeløs sløye (loop), vil en overvåknings-timeout (watchdog timeout) gjenopprette firmwaren ved å vektorisere til en underrutine for feilkontroll eller utføre en hard tilbakestilling av mikrokontrolleren.

I tilfelle ugyldige inndata, for eksempel hvis en ekstern sensor feiler eller saboteres, kan data utenfor intervallet resultere i data som kanskje ikke er riktig redegjort for i applikasjonskoden. Hvis for eksempel omgivelsestemperatursensoren i et menneskebebodd kontrollrom feilaktig registrerer temperaturer på 121 °C (250 °F), kan dette være en sensorfeil eller ondsinnet sabotasje. En uforsiktig firmware-programmerer har kanskje ikke kodet for en så høy temperaturavlesning, kan føre til noe så trivielt som feil datalogging, eller noe så alvorlig som å tillate en inntrenger tilgang til et sikkert område, eller så kritisk som en feil i en kontrollalgoritmeberegning – som igjen kan føre til utstyrssvikt eller alvorlig personskade. De potensielle negative resultatene er mange.

Ondsinnede aktører er forskjellige ved at de kan ha bevisst til hensikt å forårsake feil i IoT-noden. Feilen på grunn av hackingsforsøket kan oppdages av sikkerhetsrutiner som et innbrudd. Det kan imidlertid også skjule seg som en firmware-feil eller ugyldige eksterne inndata. Eksemplet med avlesning av omgivelsestemperatur på 121 °C (250 °F) kan forårsakes av en ondsinnet aktør som tester firmware-atferd ved en så høy avlesning – med hensikt å teste en metode for inntrengning. Eksempelvis kan dører låses opp automatisk hvis avlesningen av 121 °C (250 °F) omgivelsestemperatur blir feilaktig evaluert som en brann.

Reagerer på firmware-feil

Uansett feilkilde, må mikrokontrollerens firmware for høysikkerhets-IoT- og IIoT-noder være feilintolerante. Alle feil må kodes for og fanges opp. Inngangene til underrutiner og funksjoner må testes, og alle sensorinngangdata må valideres. Timere for overvåkningsfunksjoner må programmeres med hensikt å oppdage kode som er låst eller går i endeløs sløyfe (loop) – som tar for lang tid, basert på en kjent kjøretid.

Når en fastvarefeil oppdages i en høysikkerhets-IoT- eller IIoT-node, uavhengig av om feilen er utilsiktet eller bevisst, må firmwaren fange opp hendelsen så raskt som mulig. Vanlige handlinger omfatter forsøk på å kompensere for feilen. For en sensor som feiler, kan firmwaren ha en «nødkjøringsmodus» for sensoren, for å kompensere for dårlige data, til den kan byttes ut. En firmware-rutine som returnerer feil resultater, kan nullstilles. Ofte sendes en feilkode over nettverket for å varsle nettverksverten om problemet.

I noen høysikkerhets-IO- eller IIoT-noder er det imidlertid en spesiell kategori av feilfunksjoner som det ikke kan, eller ikke bør være, kompensasjon eller mottiltak for. Dette kan inkludere fysisk sabotasjedeteksjon, interne sjekksumfeil, noen innebygde selvtestfeil (BIST) og eventuelle feil som kan skyldes kompromittert fastvare eller et hacket system. I disse høysikkerhetssituasjonene kan det eneste alternativet være å slå av noden umiddelbart på sikkert vis. Nettverksverten vil finne ut at noden har slått seg av når den ikke svarer på nettverksforespørsler. Hvis noden slås av uten å sende en feilrapport til verten, samt hvis noden ignorerer nettverkskommandoer for å starte på nytt, er det en indikasjon på at en fatal feil har oppstått og at en tekniker må sendes for å fysisk undersøke noden for årsaken.

Når noden er slått av, slettes imidlertid umiddelbart alle flyktige minne- og statusdata. Dette gjør diagnostiseringen av årsaken til avslåing veldig vanskelig, om ikke umulig. Alternativt kan diagnosedata lagres i ikke-flyktig minne, for eksempel EEPROM- eller Flash-minne, før noden slås av. Problemet er at skriving til disse typene minne tar tid, fordi noden må forbli aktiv under skrivingen og muligens føre til at ytterligere skade oppstår.

Diagnostisering av fatale feil med e-papir

EPD-er trekker svært lite strøm og kan brukes til å lagre, samt vise feil- og diagnoseinformasjon rett før noden slås av. Når noden er slått av, kan EPD-en beholde visningsbildet uten strøm i flere dager eller uker. Informasjonen på skjermen gir teknikere en visuell indikasjon på årsaken til avslåingen, slik at de kan avgjøre om det er trygt å slå på IoT-noden, eller om den bør fjernes fra nettverket for detaljert analyse.

Et eksempel på en EPD egnet for visning av diagnostisk informasjon er Pervasive Displays sin EPD-modul E2271CS091. Den grensesnitter til enhver kompatibel mikrokontroller med et serielt SPI-grensesnitt og har en 2,71-tommers skjerm med høy kontrast (figur 1).

Figur 1: EPD-modulen E2271CS091 har en 2,71-tommers skjerm med høy kontrast med en oppløsning på 264 x 176 piksler. Den har en bred visningsvinkel og grensesnitter til enhver kompatibel mikrokontroller med et SPI-grensesnitt. (Bildekilde: Pervasive Displays)

EPD-modulen E2271CS091 bruker en TFT-skjerm (active matrix thin-film transistor) med en innebygd oppløsning på 264 x 176 piksler med 117 punkter per tommer (dpi). Dette gjør at skjermen kan inneholde mye informasjon for å hjelpe teknikere med diagnostikk. Antirefleksskjermen har en bred visningsvinkel på nesten 180˚, noe som gir enkel visning på uvanlige monteringssteder. EPD krever en strømforsyning på 3,0 volt.

Vertsmikrokontrolleren sender data til EPD over et SPI-grensesnitt på skjermens 24-pinners båndkontakt. SPI-datakommunikasjonen er kun enveis fra vertsmikrokontrolleren til EPD. Den eneste kommunikasjonen tilbake fra EPD til vertsmikrokontrolleren er en «enhetsopptatt» pinne på båndkontakten, som forenkler grensesnittet og øker tilliten til de diagnosedataene som vises.

Hvis det oppdages en feil eller et hackingsforsøk, og hvis feilen er alvorlig nok til å kreve en avslåing av noden, må feilen først fanges opp av firmware, overvåkningsfunksjon (watchdog) eller en annen metode. Kontrollen må deretter overføres til feilloggingsrutinen, som deretter sender data til EPD-en. Denne feilloggingsrutinen bør være den høyest prioriterte oppgaven for å forhindre avbrudd eller korrupsjon av data. For maksimal pålitelighet anbefales det at feilloggingsrutinen er fullt ut lukket i seg selv, uten anrop til eksterne underrutiner eller -funksjoner. Ideelt sett bør feilloggingsrutinen være i permanent skrivebeskyttet flash for å garantere kodens integritet, selv etter firmware-oppdateringer.

Før EPD-en oppdateres med feildata, bør vertsmikrokontrolleren først sende en myk tilbakestillingskommando over SPI-grensesnittet til EPD-en for å tømme skjermen. Deretter sender den svart-hvitt visningsinformasjonen i en serie byte-sekvenser, der hver bit i en byte representerer en piksel på EPD-en. Når sekvensen er fullført, kan feilloggingsrutinen slå av mikrokontrolleren. Forskjellige mikrokontrollerprodusenter har forskjellige måter å stenge ned på, da dette er arkitektur- og produsentavhengig. I noen situasjoner, og av sikkerhetsgrunner, kan produsenten ha en udokumentert måte å slå av mikrokontrolleren på som bare er tilgjengelig på forespørsel. Alternativt kan en ekstern krets brukes til å avbryte strømmen til mikrokontrolleren, men dette øker kompleksiteten i systemet, noe som reduserer påliteligheten. Derfor foretrekkes en firmware-kontrollert avslåing av mikrokontrolleren.

Pervasive Displays tilbyr EPD-utvidelsessettet B3000MS034 for å assistere utvikling (figur 2). Den har et utvidelseskort med en kontakt for den 24-pinners EPD-skjermen, i tillegg til kontakter for andre Pervasive Displays EPD-er som krever 40-pinners og 26-pinners kontakter. Utvidelseskortet er kompatibelt med Texas Instruments sittLaunchPad-utviklings- og evalueringssett, men kan også brukes sammen med andre utviklingssett. En 20-pinners koblingskabel kan kobles til den 90˚ 20-pinners stiftlistkontakten, som når den er loddet til forlengelseskortet, tillater at kontrollsignaler til EPD-en overvåkes under utvikling.

Figur 2: utvidelsessettet for Pervasive Displays EPD-modul E2271CS091 inkluderer en 24-pinners kontakt på utvidelseskortet til skjermens 24-pinners båndkabel. Den inkluderer også en koblingskabel og en 90˚ 20-pinners stiftlistkontakt. (Bildekilde: Pervasive Displays)

Et annet EPD-alternativ er Display Visions EA EPA20-A (figur 3).

Figur 3: Display Visions EA EPA20-A EPD er en 172 x 72-skjerm som kan beholde visningsstatusen uten strømtilkobling. (Bildekilde: Display Visions)

Denne EPD har en 172 x 72-gråtonevisning og bruker også et SPI-grensesnitt for kommunikasjon med en vertsmikrokontroller. EPD-enheten har ekstremt lav effekt, krever en enkelt 3,3 volts forsyning og trekker bare 40 milliwatt (mW) under et skjermbytte. Display Visions EA EPA20-A EPD kan også beholde visningen uten av noen strøm er tilført.

Konklusjon

Høysikkerhets-IoT- og IIoT-noder må noen ganger slås av som respons på en fatal firmware-feil eller en oppdaget trussel. Dette kan føre til tap av alle flyktige data, inkludert vertsmikrokontrollerens interne status. Imidlertid kan status og diagnosedata sendes til en tilkoblet EPD før avslåing og vises i flere dager eller uker. Dette gir teknikere den informasjonen de trenger for å fastslå årsaken for avslåing, samt for å ta fremtidige forholdsregler, for å beskytte og sikre noden og nettverket om nødvendig.