Grundlæggende principper for IoT-sikkerhed - Del 4: Afdæmpning af trusler under kørslen

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. At sikre IoT-applikationer kan være skræmmende. Men i virkeligheden kan IoT-enhedssikkerhed bygges på et par relativt enkle principper, der understøttes af hardware-sikkerhedsenheder. 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. Del 3 undersøger mekanismerne, der er indbygget i sikre processorer til at modstå andre typer trusler mod IoT-enheder. Her identificeres og vises i del 4, 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 med sikker lagring giver det nødvendige grundlag for at implementere sikre IoT-designs. Sikker opstart og sikker opdatering af firmware over-the-air (FOTA) bruger dette fundament til at opbygge en tillidsrod for softwareudførelse. Ikke desto mindre kræver en IoT-enhed (Internet of Things) fortsat beskyttelse mod software, der ved et uheld eller forsætligt kan kompromittere sikre ressourcer, som et softwareprogram og systemkode, der udføres i køremiljøet, har adgang til.

Denne artikel beskriver, hvordan udviklere kan bruge sikkerhedsmekanismer, der er integreret i visse processorer fra NXP Semiconductors, STMicroelectronics og andre, til mere effektivt at beskytte systemer mod trusler, der opstår under udførelsen af software.

Hvordan runtime-software kan undergraves

Som omtalt i tidligere dele af denne serie er kryptering, sikker nøgleopbevaring og sikker opstart og firmwareopdatering nødvendige byggesten for IoT-sikkerhed. Selv om disse funktioner er afgørende bidrag til den overordnede IoT-enhedssikkerhed, kan de udgøre en ufuldstændig løsning på angreb, der er designet til at undergrave runtime-software i tilsluttede systemer. Ideelt set vil forsøg på at trænge igennem de forsvarslinjer, som disse mekanismer giver, mislykkes takket være det betroede miljø, der er bygget på den tillidsrod, der er skabt ved sikker opstart. I praksis kan systemer, der er bygget med disse robuste sikkerhedsfunktioner, blive - og er blevet - kompromitteret af angreb, der indfører et stykke korrupt kode eller malware i systemet.

Ved hjælp af en lang række forskellige metoder kan hackere udnytte sikkerhedshuller i en del af et system til at angribe andre dele. Bufferoverløbsangreb udnytter f.eks. softwareprogrammer, der tillader store inputdatastrømme at skrive forbi det tilsigtede bufferområde. Hvis disse overløbsdata indeholder kode, kan processoren senere udføre den, hvilket giver hackere en indgang til yderligere angreb. Ved hjælp af disse og andre metoder udvider hackere gradvist deres indtrængen til bredere dele af et system.

Sårbarheder kan findes i enhver softwarekomponent i ethvert lag af et systems softwarestak. I takt med at udviklerne arbejder på at skabe mere funktionsrige systemer, øger behovet for flere softwarekomponenter risikoen for, at deres systemer bliver udsat for flere sårbarheder. Samtidig vokser antallet af sårbarheder, der findes i software, fortsat. F.eks. viste den autoritative CVE®-liste (Common Vulnerabilities and Exposures) over offentligt kendte cybersikkerhedssårbarheder en stigning på 15 % fra år til år i 1. kvartal 2020.

Beskyttelsesniveauer beskytter kritisk software

Trusselsbekæmpelse er en konstant kamp mellem black hat-hackere og white hat-sikkerhedsspecialister. Selv om der fortsat vil dukke trusler op, kan udviklere i høj grad skærpe sikkerheden i deres design ved at udnytte metoder, der er designet til at isolere de mange forskellige softwareprocesser, der kræves i et typisk program. I årevis har sikre systemer været bygget på en differentieret beskyttelsestilgang. I denne klassiske tilgang giver koncentriske beskyttelsesringe stigende niveauer af isolation i et system. Programmer, der kører i det yderste lag, har begrænset adgang til enhedsdrivere og systemtjenester i de indre lag, som igen har begrænset adgang til softwarekernen i det inderste lag (figur 1).

Figur 1: Sikre softwaresystemer beskytter programmer, drivere og operativsystemkerner i beskyttelsesringe, der giver en gradvis større beskyttelse. (Billedkilde: Wikipedia)

Intel x86-enheder fra og med 80286, der nu kan fås fra Rochester Electronics, understøttede fire niveauer, der blev udpeget ved hjælp af et vælgerregister, som indeholdt et to-bit felt for anmodet privilegieniveau (RPL). Moderne processorarkitekturer som Arm's® TrustZone har udvidet sikkerhedsfunktionerne betydeligt gennem en række mekanismer, der er designet til at isolere brugerprocesser under kørslen. Udviklere kan finde denne form for differentieret beskyttelsesfunktion i en række processorer til indlejrede systemer, herunder:

• Microchip Technology's SAM L11-mikrocontrollerfamilie baseret på Arm Cortex®-M23
• Nordic Semiconductors trådløse systemer på chip (SoC'er) nRF9160 baseret på Arm Cortex-M33
• Nuvoton Technology's M2351-mikrocontroller baseret på Arm Cortex-M23
• NXP Semiconductors' LPC55-mikrocontrollere baseret på Arm Cortex-M33
• Silicon Labs' EFR32BG21-familie af trådløse SoC'er baseret på Arm Cortex-M33
• STMicroelectronics' STM32L5-mikrocontrollerfamilie baseret på Arm Cortex-M33

Arm TrustZone for Cortex-M giver forbedrede sikkerhedsfunktioner til Arm Cortex-M-processorer til indlejrede systemer, f.eks. NXP LPC55S69JBD100K og STMicroelectronics' STM32L552VET6. TrustZone for Cortex-A giver lignende muligheder for Arm Cortex-A-baserede applikationsprocessorer som f.eks. NXP i.MX 8M Mini MIMX8MM6DVTLZAA og STMicroelectronics' STM32MP157AAC3T.

For hver Arm-serie tilbyder TrustZone mekanismer, der understøtter sikker opstart og sikker kode, data og hukommelse, blandt andre sikkerhedsfunktioner. TrustZone til Cortex-M-processorer er designet til at understøtte krav om lav latenstid i indlejrede systemer og har forbedringer af ydeevnen, herunder hurtige sikre interrupts og hurtige hardwarebaserede overgange mellem sikkerhedstilstande. I denne artikel beskrives TrustZone for Cortex-M-processorer med fokus på et par processorer, der er repræsentative for denne klasse: NXP LPC55S69JBD100K og STMicroelectronics STM32L552VET6.

Processordriftstilstande muliggør udvidet beskyttelse

Kernen i TrustZone-arkitekturen er, at processorer kan køre i flere driftstilstande, der understøtter isolering af softwareprocesser og systemressourcer. Processorens "sikre" og "usikre" tilstande giver mulighed for at isolere betroede processer fra processer, der ikke er tillid til. Processor "handler"- og "tråd"-tilstande giver en separat beskyttelsesmekanisme, der giver yderligere granularitet i forbindelse med isolering af processer og ressourcer.

I TrustZone-arkitekturen medfører en processor, der kører i handlingstilstand, at software altid kører i privilegeret tilstand. Det er derfor den tilstand, der anbefales at bruge til at køre software som f.eks. et realtidsoperativsystem (RTOS) eller til at få adgang til boot-image, sikre nøgler og andre ressourcer, der er vigtige for systemets drift. I trådtilstand kører softwaren i ikke-privilegeret tilstand, men privilegerede processer kan ændre privilegieniveauet for software, der kører i denne tilstand. Trådtilstand bruges typisk til at køre programkode.

Når de anvendes sammen, giver sikre/ikke-sikre og håndterings-/trådtilstande den samme form for differentieret beskyttelse som i tidligere systemer, der understøtter beskyttelsesringe. Ved hjælp af STMicroelectronics STM32L552VET6 kan udviklere f.eks. isolere betroet kode med fulde rettigheder fra ikke betroet kode med minimale rettigheder (figur 2).

Figur 2: TrustZone-processorer som STMicroelectronics STM32L552VET6 tilbyder en kombination af processortilstande, der gør det muligt for udviklere at isolere betroet systemsoftware som f.eks. boot-images fra ikke-troværdig applikationskode som f.eks. radiofrekvenskommunikationsstacks (RF) fra tredjeparter. (Billedkilde: DigiKey, fra STMicroelectronics kildemateriale)

Isoleringsmekanismer, der er integreret i disse processorer, begrænser hver processors mulighed for at få adgang til forskellige områder af programdatahukommelsen. Når NXP LPC55S6x-kernen f.eks. er i sikker tilstand, kan den ikke få adgang til ikke-sikker programhukommelse, selv om den stadig kan nå ikke-sikker datahukommelse. På den anden side kan LPC55S6x-kernen, når den kører i den ikke-sikre tilstand, kun få adgang til ikke-sikret programhukommelse og datahukommelse (figur 3).

Figur 3: Processorer som NXP's LPC55S6x-enheder kan sikre, at kernen kører i sikker tilstand (S-tilstand) for at læse sikker programhukommelse (grøn) eller i ikke-sikret tilstand (NS-tilstand) for at læse ikke-sikret programhukommelse (rød). (Billedkilde: NXP Semiconductors)

Når de kører i sikker tilstand for at udføre betroet software, kan disse processorer ikke hente instruktioner fra ikke-sikker programhukommelse. Omvendt kan disse processorer ikke få adgang til kode eller data, der befinder sig i sikre områder, når de kører i ikke-sikker tilstand for at udføre software uden tillid, f.eks. programkode. Ikke desto mindre kræver applikationskoden typisk mulighed for at udføre pålidelig kode i sikre biblioteker. TrustZone-processorer giver udviklere mulighed for at opfylde dette krav ved at definere ikke-sikkerhedskaldbare hukommelsesområder (NSC), som giver tilladte adgangspunkter til sikre biblioteker (figur 4).

Figur 4: Ikke-sikre områder, der kan kaldes op, giver sikre indgangspunkter fra ikke-sikre til sikre hukommelsesområder, hvilket gør det muligt for ikke-sikre programmer at udføre funktioner i sikre biblioteker. (Billedkilde: STMicroelectronics)

Hukommelsesaliaser øger sikkerheden

TrustZone-processorer som NXP LPC55S69JBD100K og STMicroelectronics STM32L552VET6 styrer udførelsen ved at opdele fysisk programhukommelse i sikre og ikke sikre hukommelsesrum. For eksempel aliaserer STMicroelectronics STM32L552VET6 kode i flash og SRAM to gange - en gang til et ikke-sikkert adresseområde (0x0800_0000 til 0x0BFF_FFFFFF) og igen til et sikkert adresseområde (0x0C00_0000 til 0x0FFF_FFFFFF). På samme måde aliaserer NXP LPC55S69JBD100K fysisk programhukommelse til et ikke-sikkert område, der starter ved 0x0000_0000, og også til et sikkert område, der starter ved 0x1000_0000. Hver af disse processorer anvender en lignende fremgangsmåde for andre hukommelsestyper og perifere enheder, idet de opdeler dem to gange i sikre og usikre områder.

Når processoren skal have adgang til en hukommelsesplacering, bestemmes adgangen til denne placering af en sikkerhedsattribut, der genereres af to hardwareenheder:

• Implementation Defined Attribution Unit (IDAU), som er en fast hardwareenhed uden for processorkernen, der giver en fast sikkerhedsstatus for hukommelseskortet som defineret af producenten.
• Secure Attribution Unit (SAU), som er en programmerbar enhed, der er integreret i processorkernen og bruges til at definere sikkerhedsstatus for op til otte hukommelsesområder.

Under systeminitialiseringen definerer konfigurationsrutiner, der kører i sikker tilstand, sikkerhedsstatus for hvert område ved at indstille nogle få SAU-registre, herunder:

• SAU-regionsnummerregister (SAU_RNR) for at vælge en region til yderligere operationer
• SAU-regionens basisadresseregister (SAU_RBAR) til at definere regionens startadresse
• SAU Region Limit Address Register (SAU_RLAR) til at definere regionens omfang

STMicroelectronics har i sin STM32Cube MCU-softwarepakke til STM32L5-serien flere skabelonfiler, der demonstrerer brugen af processorfunktioner, herunder SAU-konfiguration. Som vist i Listing 1 kan udviklere definere disse regioner for hver konfigurationsparameter ved hjælp af en makro (SAU_INIT_REGION(n)), der indstiller registerværdierne i en SAU-struktur, der bruges, når konfigurationsindstillingerne skrives til enheden.

Kopi
/*
//   <e>Initialize SAU Region 0
//   <i> Setup SAU Region 0 memory attributes
*/
#define SAU_INIT_REGION0    1
 
/*
//     <o>Start Address <0-0xFFFFFFE0>
*/
#define SAU_INIT_START0     0x0C03E000      /* start address of SAU region 0 */
 
/*
//     <o>End Address <0x1F-0xFFFFFFFF>
*/
#define SAU_INIT_END0       0x0C03FFFF      /* end address of SAU region 0 */
 
/*
//     <o>Region is
//         <0=>Non-Secure
//         <1=>Secure, Non-Secure Callable
*/
#define SAU_INIT_NSC0       1
/*
//   </e>
*/
 
/*
//   <e>Initialize SAU Region 1
//   <i> Setup SAU Region 1 memory attributes
*/
#define SAU_INIT_REGION1    1
 
/*
//     <o>Start Address <0-0xFFFFFFE0>
*/
#define SAU_INIT_START1     0x08040000      /* start address of SAU region 1 */
 
/*
//     <o>End Address <0x1F-0xFFFFFFFF>
*/
#define SAU_INIT_END1       0x0807FFFF      /* end address of SAU region 1 */
 
/*
//     <o>Region is
//         <0=>Non-Secure
//         <1=>Secure, Non-Secure Callable
*/
#define SAU_INIT_NSC1       0
/*
//   </e>
*/
   .
   .
   .
**
  \brief   Setup a SAU Region
  \details Writes the region information contained in SAU_Region to the
           registers SAU_RNR, SAU_RBAR, and SAU_RLAR
 */
__STATIC_INLINE void TZ_SAU_Setup (void)
{
 
#if defined (__SAUREGION_PRESENT) && (__SAUREGION_PRESENT == 1U)
 
  #if defined (SAU_INIT_REGION0) && (SAU_INIT_REGION0 == 1U)
    SAU_INIT_REGION(0);
  #endif
   .
   .
   .
#define SAU_INIT_REGION(n) \
    SAU->RNR  =  (n                                     & SAU_RNR_REGION_Msk); \
    SAU->RBAR =  (SAU_INIT_START##n                     & SAU_RBAR_BADDR_Msk); \
    SAU->RLAR =  (SAU_INIT_END##n                       & SAU_RLAR_LADDR_Msk) | \
                ((SAU_INIT_NSC##n << SAU_RLAR_NSC_Pos)  & SAU_RLAR_NSC_Msk)   | 1U
 

Listing 1: Dette uddrag, der er inkluderet i skabeloner i STMicroelectronics' STM32Cube MCU-softwarepakke til STM32L5-serien, viser, hvordan udviklere definerer hukommelsesregioner og deres tilknyttede sikkerhedsstatus. (Kilde til kode: STMicroelectronics)

IDAU og SAU arbejder sammen for at afgøre, om hukommelsesplaceringen er tilgængelig, og returnerer det højeste sikkerhedsniveau af de to. Da en processor arbejder med det hukommelsesalias, der svarer til dens sikre/ikke-sikre driftstilstand, sikrer den sikkerhedsattribut, der genereres af kombinationen af IDAU og SAU, at der kun er adgang til områder med det tilsvarende sikkerhedsniveau (figur 5).

Figur 5: I NXP LPC55S69JBD100K kombinerer IDAU'en og SAU'en for at generere en sikkerhedsattribut for hvert hukommelsesalias, hvilket effektivt fjerner kode, der ikke må køre ud af hvert enkelt område. (Billedkilde: NXP Semiconductors)

Når NXP LPC55S69JBD100K f.eks. fungerer i sikker tilstand, vil den sikkerhedsattribut, der genereres af IDAU'en og SAU'en, forhindre adgang til ikke-sikkerhedsprogrammer, der er indeholdt i det sikre alias for en blok fysisk hukommelse, hvilket effektivt eliminerer den ikke-sikkerhedskode fra det sikre alias. Omvendt vil IDAU- og SAU-sikkerhedsattributten, når processoren fungerer i ikke-sikret tilstand, effektivt udelukke sikre applikationer fra det resulterende ikke-sikre alias.

Indstilling af privilegier og adgangskontrol

IDAU og SAU håndhæver direkte sikre og ikke sikre adgangsbegrænsninger, men de arbejder sammen med sikre og ikke sikre hukommelsesbeskyttelsesenheder (MPU'er) for at bestemme de adgangsrettigheder, der er knyttet til målressourcen (Figur 6).

Figur 6: I TrustZone-processorer som f.eks. den her illustrerede NXP LPC55S69JBD100K kombineres sikkerhedsattributten, der genereres af SAU'en og IDAU'en, med indstillinger, der forvaltes af sikre og ikke sikre MPU'er, for at levere privilegieniveauet sammen med sikkerhedsniveauet. (Billedkilde: NXP Semiconductors)

MPU'en er indbygget i disse processorer og giver finkornet adgangskontrol af hukommelsesressourcerne. I STMicroelectronics STM32L552VET6 understøtter MPU'en f.eks. en række forskellige adgangsrettigheder, der er forskellige, når processoren kører i privilegeret handlingstilstand eller i uprivilegeret trådtilstand (tabel 1).

Tabel 1: STMicroelectronics STM32L552VET6 giver udviklere mulighed for at bruge MPU'en til at definere forskellige adgangsniveauer, der fungerer forskelligt i privilegeret og uprivilegeret tilstand. (Kilde til tabellen: STMicroelectronics)

Blandt disse attributter gør attributten Execute Never (XN) det muligt for udviklere at sikre, at processoren aldrig forsøger at udføre kode fra det tilknyttede hukommelsesområde, hvilket giver endnu et niveau af runtime-beskyttelse. I systemer, der kører kode direkte fra flash, kan udviklerne f.eks. indstille XN-attributten for ubrugte SRAM-regioner for at eliminere enhver mulighed for, at systemet kan blive kompromitteret, selv hvis malware-injektionsangreb lykkes i disse områder.

Udvidelse af beskyttelsen til flere perifere enheder og hukommelse

IDAU-, SAU- og MPU-funktionerne i disse processorer giver et fleksibelt grundlag for beskyttelse af kørselstidsekvering af både systemsoftware og applikationer, men disse funktioner er begrænset til selve processoren. Processorer som NXP LPC55S69JBD100K og STMicroelectronics STM32L552VET6 overfører de sikre og privilegerede funktioner til andre hukommelsessystemer og grænseflader via en række forskellige metoder.

I STM32L552VET6 supplerer STMicroelectronics den indbyggede TrustZone-mekanisme med sin egen globale TrustZone-controller (GTZC), der er designet til at beskytte periferiudstyr, indlejret SRAM og eksterne hukommelser (figur 7).

Figur 7: STMicroelectronics STM32L552VET6-processoren integrerer en global TrustZone-controller (GTZC), der udvider sikkerhedsbeskyttelsen til periferiudstyr og hukommelse, som ikke er omfattet af den oprindelige TrustZone-ramme. (Billedkilde: STMicroelectronics)

I NXP LPC55S69JBD100K overføres privilegieattributten (HPRIV) og sikkerhedsattributten (HNONSEC) over den interne AHB-matrix (Advanced High-performance Bus) for at nå Memory Protection Checkers (MPC'er), Peripheral Protection Checkers (PPC'er) og Master Security Wrappers (MSW'er) for andre busmastere (figur 8).

Figur 8: I NXP LPC55S69JBD100K overføres privilegie- og sikkerhedsniveauerne til yderligere hardwareenheder, som anvender disse egenskaber på operationer, der involverer hukommelse, periferiudstyr og andre busmasterne. (Billedkilde: NXP Semiconductors)

Selv om det er vigtigt at have en forståelse af de underliggende mekanismer for softwareisolering og systembeskyttelse, kan udviklere drage fordel af udviklingsstøtte til hurtigt at anvende disse funktioner i deres egne designs.

STMicroelectronics tilbyder sine STM32L552E-EV-, STM32L562E-DK- og NUCLEO-L552ZE-Q-evalueringskort som en hurtig prototypeplatform til udvikling af applikationer baseret på STM32L5-processorer. Virksomhedens integrerede udviklingsmiljø (IDE) STM32CubeIDE giver et omfattende miljø til softwareprogrammering, og STM32CubeProgrammer tilbyder både grafisk brugergrænseflade (GUI) og kommandolinjeinterface (CLI) til programmering af interne og eksterne hukommelser. Ved hjælp af dette værktøj kan udviklere f.eks. definere sikre områder i flash-hukommelse (figur 9).

Figur 9: STMicroelectronics STM32CubeProgrammer tilbyder en enkel metode til at definere sikre områder i flash-hukommelse. (Billedkilde: STMicroelectronics)

Med henblik på hurtig udvikling af systemer baseret på NXP's LPC55S69-processorer kan udviklere bygge designs på NXP LPC55S69-EVK-evalueringskortet. Til systemkonfiguration og softwareprogrammering tilbyder NXP MCUXpresso IDE en omfattende platform til at skabe applikationer baseret på NXP LPC55S69-processorer.

Konklusion

IoT-sikkerhed afhænger af grundlæggende sikkerhedsmekanismer til kryptografi og sikker lagring samt af mulighederne for at bygge applikationer på en tillidsrod baseret på hardware-sikkerhedsmekanismer. Selv om alle disse tiltag er nødvendige for sikkerheden, er de sjældent tilstrækkelige til at imødegå vedvarende trusler, der er designet til at udnytte sårbarheder i systemets kørselstidsmiljøer. Ved hjælp af differentierede beskyttelsesmekanismer, der er tilgængelige i et voksende udvalg af processorer, kan udviklere bygge sikre IoT-enheder, der er bedre i stand til at afbøde disse trusler og reducere eller fjerne deres indvirkning på IoT-applikationer.