Grundlæggende principper for IoT-sikkerhed - Del 3: Sikring af sikker opstart og firmwareopdatering

Redaktørens note: På trods af spredning af IoT-enheder forbliver sikring af disse enheder en løbende bekymring.Sikkerhedsudfordringer kan være en barriere for vedtagelse af tilsluttede enheder i IIOT (Industrial IoT) og mission kritiske applikationer, hvor virksomheds- og personlige data kan være kompromitteret i tilfælde af et vellykket hacker-angreb. Sikring af IoT-applikationer kan være skræmmende, men i virkeligheden kan IoT-enhedens sikkerhed bygges på nogle få relativt enkle principper, som understøttes af hardware-sikkerhedsudstyr. Ved at følge veletablerede sikkerhedspraksis kan disse bekymringer løses. Denne mulltidel serie giver praktisk vejledning til at hjælpe udviklere med at sikre, at bedste praksis følges fra starten. Del 1 diskuterer de kryptografiske algoritmer, der ligger til grundlag for sikre design. Del 2 diskuterer rollen som private nøgler, nøglestyring og sikker opbevaring i sikre IoT-design. I del 3 undersøges de mekanismer, der er indbygget i sikre processorer for at mindske andre typer trusler mod IoT-enheder. Del 4 identificerer og viser, hvordan man anvender sikkerhedsmekanismer i avancerede processorer for at hjælpe med at sikre den isolation, der er nødvendig for at afbøde angreb på IoT-enhedernes runtime-miljø. Del 5 beskriver, hvordan IoT-sikkerheden fortsætter fra IoT-enhederne gennem sikkerhedsforanstaltninger på højere niveau, der anvendes til at forbinde disse enheder med IoT-skyressourcer

Hardware-baseret kryptografi og sikker lagring giver i kombination vigtige funktioner, der er nødvendige for at implementere sikre IoT-designs (Internet of Things). Når IoT-enhederne først er blevet installeret, står de imidlertid over for flere trusler, der er designet til at undergrave disse enheder, til at iværksætte øjeblikkelige angreb eller til mere subtile og avancerede vedvarende trusler.

Denne artikel beskriver, hvordan udviklere kan forbedre sikkerheden i IoT-enheder ved hjælp af en tillidsrod, der bygger på underliggende sikkerhedsmekanismer for at skabe et pålideligt miljø for softwareudførelse på sikre processorer fra bl.a. Maxim Integrated, Microchip Technology, NXP Semiconductors og Silicon Labs.

Hvad er tillidsroden, og hvorfor er den nødvendig?

Kryptografiske metoder og sikre nøgler er afgørende forudsætninger for sikkerheden i enhver tilsluttet enhed. Som nævnt i del 1 og del 2 i denne serie leverer de grundlæggende mekanismer, der anvendes af protokoller på højere niveau til at beskytte data og kommunikation. Beskyttelse af selve systemet kræver, at udviklerne tager højde for sårbarheder, der kan påvirke systemets drift og softwarekørsel i indlejrede systemer.

I et typisk indlejret system vil en systemreset på grund af strømsvigt eller en kritisk softwareundtagelse i sidste ende sætte softwareopstartprocessen i gang for at genindlæse et firmwareaftryk fra ikke-flygtig hukommelse. Normalt er genstart af software en vigtig sikkerhedsmekanisme, der bruges til at genoprette funktionen af et system, der ved et uheld eller forsætligt er blevet destabiliseret. I forbundne systemer, hvor hackere bruger en række forskellige black hat-værktøjer til at kompromittere software, anbefaler sikkerhedsspecialister ofte genstart for at imødegå indbrud, der påvirker softwareudførelsen. I 2018 anbefalede FBI for eksempel, at forbrugere og virksomhedsejere genstartede deres routere for at forhindre en massiv hacker-kampagne, der var i gang på det tidspunkt.

I praksis er genstart ingen garanti for systemintegritet. Efter genstart med et kompromitteret firmware-image er systemet stadig under hackernes kontrol. For at mindske denne type trusler skal udviklere sikre, at deres software kører på en tillidskæde, der bygger på en tillidsrod, der etableres ved opstart og strækker sig gennem alle lag i softwarens eksekveringsmiljø. Muligheden for at opnå dette sikkerhedsniveau afhænger i høj grad af at sikre, at opstartsprocessen starter med pålidelig firmware.

Verifikation af firmwareaftryk til sikker opstart

I et indlejret system indlæser værtsprocessoren et firmware-image fra flash til hovedhukommelsen og begynder at udføre det (eller begynder at udføre det direkte fra flash med XIP-funktion (execute-in-place)). Hvis hackere har kompromitteret firmwareaftrykket, resulterer opstartsprocessen i et kompromitteret system.

For at verificere firmwarens integritet, inden den startes op med den, bruger udviklerne en kodeunderskriftsproces, der begynder tidligt i forsyningskæden. I et sikkert anlæg signeres systemets firmware-image med en privat nøgle fra et privat-offentligt nøglepar, der er oprettet med en kryptografisk robust algoritme som f.eks. ECDSA (Elliptic Curve Digital Signature Algorithm). Selv om den private nøgle aldrig forlader anlægget, følger den offentlige nøgle med systemet. Under opstart anvender processoren denne offentlige systemnøgle til at verificere firmwaresignaturen, før afbildningen anvendes.

Den netop beskrevne proces gør naturligvis selve den offentlige nøgle sårbar, og i forlængelse heraf gør den også systemets firmware sårbar over for uautoriseret udskiftning. Hvis den offentlige nøgle forbliver ubeskyttet i det indlejrede system, kan hackere potentielt erstatte den med en offentlig nøgle fra et privat-offentligt nøglepar, som de selv har genereret. Hvis de udskifter systemets firmware-image med ondsindet firmware, der er signeret med den tilhørende private nøgle, som de er i deres besiddelse, klarer den kompromitterede firmwaresignatur verifikationsprocessen, og opstartsprocessen fortsætter, hvilket resulterer i et kompromitteret system.

Derfor er sikre systemer afhængige af en gyldig offentlig nøgle, som er tilvejebragt i et sikkert element i sikkerhedsfaciliteten. Sikkerheds-IC'er som f.eks. DS28C36 fra Maxim Integrated og ATECC608A fra Microchip Technology giver både sikker lagring af et traditionelt sikkert element og sikker udførelse af autentifikationsalgoritmer - f.eks. ECDSA - til verifikation af firmwaresignaturer.

Før opstart kan værtsprocessoren sende firmwaren via en seriel grænseflade til DS28C36, f.eks. DS28C36 bruger til gengæld den offentlige systemnøgle, der tidligere er blevet tildelt i den sikre facilitet, til at verificere, at firmwaresignaturen faktisk er blevet oprettet med den tilhørende private nøgle i den samme sikre facilitet. Endelig signalerer DS28C36 verifikationsresultatet til værtsprocessoren, som indlæser firmwareaftrykket, hvis signaturen er gyldig (figur 1).

Figur 1: Udviklere kan bruge sikkerheds-IC'er som f.eks. Maxim Integrated DS28C36 til at verificere firmwaresignaturer for at forhindre værtsprocessoren i at starte kompromitteret firmware op. (Billedkilde: Maxim Integrated)

En mere sikker opstartsproces beskytter firmwareaftrykket for at fjerne enhver bekymring for kompromitterede nøgler eller aftryk. Ved hjælp af sikker lagring og kryptografiacceleratorer er der indbygget effektive sikre opstartsfunktioner i et stigende antal processorer, herunder Silicon Laboratories' Gecko Series 2-processorer, NXP's LPC55S69JBD100, Maxim Integrated's MAX32520 og Microchip Technology's ATSAML11D16A, blandt andre. Ved hjælp af disse egenskaber kan denne klasse af sikre processorer levere den tillidstankegang, der er nødvendig for at skabe et pålideligt miljø til afvikling af system- og applikationssoftware.

Sikring af en tillidsrod gennem sikker opstart

Sikre processorer i denne klasse har sikre opstartsmuligheder, der er designet til at sikre integriteten af det firmwareaftryk, der ligger til grund for tillidsroden. F.eks. opbygger Silicon Laboratories' EFR32MG21A- og EFR32BG22 Gecko Series 2-processorer denne tillidsrod gennem en opstartsproces i flere trin baseret på henholdsvis et hardware-sikkerhedselement og et virtuelt sikkerhedselement (VSE) (figur 2).

Figur 2: Silicon Laboratories' Gecko Series 2 EFR32MG21A-processor bruger et integreret hardware-sikkerhedselement i første fase af sin flertrins opstartsproces (vist her), mens EFR32BG22 starter sin flertrins opstartsproces med et virtuelt sikkerhedselement. (Billedkilde: Silicon Laboratories)

I EFR32MG21A leverer en dedikeret processorkerne kryptografisk funktionalitet sammen med et sikkert hardwareelement til sikker nøgleopbevaring. Understøttet af denne dedikerede funktion starter processoren opstartsprocessen ved hjælp af kode, der er gemt i ROM (ROM) for at verificere FSB-koden (first stage bootloader). Når den er verificeret, kører FSB-koden, som igen verificerer kodens signatur for anden trin bootloader (SSB). Opstartsekvensen fortsætter med udførelse af den verificerede SSB, som igen verificerer signaturen af applikationskoden, som typisk omfatter både kode på systemniveau og applikationskode på højere niveau. Endelig kører den verificerede applikationskode, og systemoperationer fortsætter som krævet af applikationen.

Da denne proces starter med ROM-kode og kun kører verificeret FSB-, SSB- og applikationskode, resulterer denne fremgangsmåde i en verificeret tillidskæde for udførelse af kode. Da det første led i denne tillidskæde er baseret på ROM-kode, der ikke kan ændres, udvider hvert efterfølgende led i kæden dette betroede miljø. Samtidig giver denne fremgangsmåde udviklerne mulighed for sikkert at opdatere applikationskoden og endda bootloaderkoden i første og anden fase. Så længe hver kodepakke indeholder en verificeret signatur, forbliver det betroede miljø intakt.

Processorer, der tilbyder denne form for sikker opstart med en tillidsrod, understøtter typisk flere tilstande og muligheder. Silicon Laboratories' Gecko Series 2-processorer giver f.eks. en stærkere certifikatbaseret sikker opstartsfunktion.

Certifikater, der anvendes i rutinemæssige PKI-transaktioner (Public Key Infrastructure), indeholder den offentlige nøgle sammen med en henvisning til et eller flere tilknyttede certifikater, der i sidste ende peger på et rodcertifikat, som er udstedt af en certifikatudstedende myndighed (CA). Hvert certifikat i denne kæde tjener til at verificere de(t) efterfølgende certifikat(er), hvilket resulterer i en tillidskæde baseret på en pålidelig CA. Browsere er afhængige af denne tillidskæde under godkendelsesfasen af TLS (Transport Layer Security) for at bekræfte webservernes identitet. På samme måde kan indlejrede systemer bruge certifikater til at bekræfte identiteten af kilden til bootloader- eller applikationskoden. Her foregår opstartsprocessen i flere trin som beskrevet tidligere, men med yderligere verifikation af det certifikat, der er knyttet til hvert trin (figur 3).

Figur 3: Silicon Laboratories' Gecko Series 2-processorer forbedrer systemsikkerheden ved at verificere certifikater for offentlige nøgler, der anvendes under signaturverifikation i hvert trin af opstartsprocessen. (Billedkilde: Silicon Laboratories)

Andre processorer, som f.eks. NXP LPC55S69JBD100, understøtter en række forskellige muligheder for firmware-image. Ud over signerede firmwareimages understøtter disse processorer boot-images ved hjælp af branchestandarden DICE (device identifier composition engine) fra Trusted Computing Group. En tredje mulighed giver udviklerne mulighed for at lagre billeder i særlige områder af processor-flash, der understøtter PRINCE-chifringen, som er en blokchifring med lav latenstid, der kan opnå en sikkerhedsstyrke, der kan sammenlignes med andre chifringer, men på et meget mindre område i silicium. PRINCE-cifringen, der er implementeret i LPC55S69JBD100, kan udføre dekryptering on-the-fly af krypteret kode eller data, der er gemt i processorens dedikerede PRINCE-regioner i flash. Da de hemmelige nøgler, der anvendes til dekryptering, kun er tilgængelige for PRINCE-kryptografimaskinen, er denne dekrypteringsproces fortsat sikker. Faktisk er disse hemmelige nøgler beskyttet af en nøglekrypteringsnøgle (KEK), der genereres af LPC55S69JBD100's PUF-funktion (Physical Unclonable Function). (For mere om brugen af PUF og KEK, se del 2.)

Denne tilgang giver udviklere mulighed for at lagre yderligere firmwareaftryk - en evne, der er nødvendig for at give IoT-enheder firmwareover-the-air-opdateringsmetoder (FOTA) uden risiko for at "bricke" enheden. Hvis processoren kun kan bruge ét sted til at gemme firmwareaftryk, kan et defekt firmwareaftryk sende processoren ind i en ubestemt eller låst tilstand, der låser eller blokerer enheden. Ved at lagre firmwareimages i LPC55S69JBD100's PRINCE-aktiverede flash-regioner kan udviklere anvende back-off-strategier, der gendanner en tidligere fungerende version af firmware, hvis den nye version starter i en ikke-funktionel tilstand.

Fordi alle disse nye firmwareimages skal bestå signaturverifikationskontrollen, der kræves i den underliggende opstartsproces, kan udviklere drage fuld fordel af sikker FOTA til at tilføje nye funktioner eller rette fejl uden at omfatte systemet eller dets tillidskæde.

Konklusion

Sikkerhed på system- og programniveau kræver et eksekveringsmiljø, som kun tillader autoriseret software at fungere. Selv om verifikation af kodesignaturer er en vigtig funktion for at muliggøre denne type miljøer, skal sikre systemer trække på et mere omfattende sæt af funktioner for at opbygge den tillidskæde, der er nødvendig for at sikre pålidelig softwareudførelse. Grundlaget for disse pålidelige miljøer ligger i en tillidsrod, der leveres gennem sikre opstartsmekanismer, som understøttes af sikre processorer. Ved hjælp af denne klasse af processorer kan udviklere implementere sikre IoT-enheder, der kan modstå angreb, der har til formål at lamme softwareudførelsen i et system eller kapre systemet helt og holdent.