IoT

IoT-enheder har alvorlige sikkerhedsmangler på grund af dårlig generering af ”random-numbers”

Mangel på en kryptografisk sikker random-numbers generator til IoT-enheder vil gøre dem sårbare.

Fortroligheds- og integritetsgarantierne for moderne kommunikationsprotokoller er afhængige af algoritmer, der genererer hemmelige nøgler eller tokens, som angribere ikke kan gætte og bruges til godkendelse, kryptering, adgangskontrol og mange andre aspekter af moderne sikkerhed. De kræver alle kryptografisk sikre random-numbers – sekvenser af tal eller symboler, der er valgt på en måde, som er uforudsigelig af en hacker.

Alle kryptografiske algoritmer, der involverer en slags sikker nøgle- eller tokengenerering, skal seedes med tilfældige tal kendt som tilfældige talgeneratorer (RNGs). Den proces hvormed tallene vælges, er grundlaget for mange sikkerhedssystemer og funktioner. Mens moderne operativsystemer og computere længe har haft sikker RNG udarbejdet er IoT-enheder, især har ressource-begrænset dem uden mange grænseflader, der kører mere enkle operativsystemer, længe haft et problem med at finde kilder til tilfældighed også kendt som entropi.

I de senere år har system-on-a-chip (SoC) leverandører forsøgt at løse problemet ved at indarbejde perifere controllere i deres produkter, der er designet til at generere tilfældige tal, som operativsystemet derefter sikkert kan bruge. Men et team af forskere fra sikkerhedsfirmaet Bishop Fox, der analyserede den måde, IoT-udviklere bruger disse hardware-RNG’er på, fandt store implementeringsproblemer, der kompromitterer sikkerheden i deres systemer. De fremlagde for nylig deres resultater på DEF CON-sikkerhedskonferencen.

Nogle af konklusionerne var:

Hardware RNG vs software RNG

Softwarebaserede RNG’er er også kendt som pseudo-tilfældige talgeneratorer (PRNGs), fordi de bruger deterministiske softwarealgoritmer og de skal seedes med tilfældige værdier, normalt fra en entropipulje, der kombinerer tilfældige værdier fra forskellige kilder: netværksinformation, radiogrænseflader, forskellige timingværdier osv. Generelle PRNG’er bruges til ikke-sikkerhedsmæssige formål, og kryptografisk sikre PRNG’er (CSPRNGs) er designet til at tilbyde sikkerhedsgarantier mod angreb, der forsøger at gætte seed-værdierne eller forudsige deres output inden for en rimelig og beregningsmæssigt mulig tid.

CSPRNGs anvender kryptografiske krypteringer og hashingfunktioner til at producere output, der derefter bruges til kritiske handlinger som nøglegenerering. De udfører også test for at forhindre kendte angreb. Alle handlingerne bruger computerressourcer og hukommelse, som begge er meget begrænsede på IoT-enheder, hvorfor SoC-leverandører tilføjede hardware-RNG-funktioner.

Hardware-RNG’er er også kendt som ægte RNGs (TRNGs), fordi de genererer tilfældige tal fra fysiske processer på en måde, der ikke kan forudsiges som i tilfælde af softwarealgoritmerne. Produktionen af TRNGs formodes at være sikkert at bruge direkte, men som biskop Fox forskere fundet, grænseflader med dem kan være vanskelige og fejl har ødelæggende konsekvenser for sikkerhedssystemer bygget oven på dem.

Ingen kontrol af hardware-RNG-fejl

SoC-leverandører giver udviklere mulighed for at interagere med deres hardware-RNG gennem HAL API ‘en (hardware abstraction layer) ved at kalde forskellige funktioner i deres C-kode. Navnene på disse RNG-funktioner kan variere fra leverandør til leverandør, men deres output er en pointer til det random-number (32-bit heltal) og en returværdi, der angiver potentielle fejl.

“Hal-funktionen til RNG-perifere kan mislykkes af forskellige årsager, men langt den mest almindelige er, at enheden er løbet tør for entropi. RNG periferiudstyr trækker entropi ud af universet gennem en række forskellige midler, men har det ikke i en uendelig forsyning. De er kun i stand til at producere et specifikt antal tilfældige bits i sekundet. Hvis du prøver at kalde RNG HAL-funktionen, når den ikke har nogen tilfældige tal at give dig, mislykkes den og returnerer med en fejlkode. Så hvis enheden forsøger at få for mange random-numbers for hurtigt, begynder opkaldene at mislykkes.

Det sker oftere under generering af store nøgler. For eksempel vil enheden under generering af en 2048-bit privat nøgle kalde RNG-hallfunktionen gentagne gange i en løkke og hardwaren vil ofte undlade at følge med på grund af dens begrænsninger og vil derfor begynde at sende fejl.

Baseret på kode fundet i GitHub til interaktion med SoCs og endda RNG-håndteringskoden i populære indlejrede OS’er som FreeRTOS, synes udviklere ikke at kontrollere for hardware RNG-fejl og den adfærd findes på tværs af stort set alle SDK og IoT OS.”

Det er et problem, fordi afhængigt af hardwaren, når HAL RNG-funktionen mislykkes, kan outputtet være delvis entropi, tallet 0 eller uinitialiseret hukommelse og ingen af disse udgange er sikre til kryptografiske formål.

I 2019 analyserede forskere fra Keyfactor 75 millioner digitale certifikater baseret på RSA-nøgler og fandt ud af, at en ud af hver 172 var sårbar over for angreb, der kunne gendanne deres hemmelige nøgler. Synderen var dårlig generering af random-numbers og de fleste af de sårbare certifikater blev fundet i IoT og indlejrede netværksenheder som routere, switche og firewalls. Hvis de primtal der bruges til at generere offentlige RSA-nøgler ikke er tilfældige nok, vil to separate nøgler sandsynligvis dele en faktor. Så er det ekstremt nemt at gendanne deres andre faktorer og kompromittere dem.

Tvungne dårlige implementeringer

Inden man begynder at bebrejde IoT-softwareudviklere for dårlige implementeringer skal det anføres at håndtering af disse fejl på en ordentlig måde har andre ulemper, der kan påvirke enhedens funktion.

Derudover kommer få enheder med korrekt dokumentation for, hvordan RNG skal fungere og hvordan man håndterer fejl eller undgår dem, manglende oplysninger om forventet driftshastighed, sikre driftstemperaturområder eller statistisk bevis for tilfældighed. Selv når der findes dokumentation, er det ikke nogen let opgave at gøre det rigtigt.

Hardware RNG-output alene er ikke pålidelig

For eksempel, i mangel af en ægte CSPRNG, mange SDK’er og IoT operativsystemer, der understøtter hardware RNGs bruger det til at seede en usikker PRNG såsom libc rand() og derefter dens output bruges til sikkerhedsformål, når det ikke burde.

PRNGs såsom libc rand() er usikre, da de tal de producerer afslører oplysninger om den interne tilstand af RNG. De er fine til ikke-sikkerhedsrelevante sammenhænge, fordi de er hurtige og nemme at implementere. Men at bruge dem til ting som krypteringsnøgler fører til katastrofalt sammenbrud af enhedens sikkerhed, da alle numrene er forudsigelige.

I en test på en LPC54628 mikrocontroller bemærkede forskerne, at de random-numbers, der blev produceret af hardware-RNG, var af dårlig kvalitet og mistænkte, at der var noget galt med deres kode. I producentens dokumentation fandt de en anbefaling mod at sammenkæde 32-bit numre outputted af RNG til at konstruere større tal. For eksempel for at få en 128-bit random-number bør udviklere ikke sammenkæde fire på hinanden følgende RNG 32-bit udgange, som producenten sagde. I stedet skal de bruge et 32-bit nummer, kassere de næste 32 tal, bruge det næste og derefter kassere yderligere 32 tal osv.

Den API-funktionsmåde er så mærkelig og ulogisk, at den næsten garanteret vil producere sårbare implementeringer. Selv hvis udviklere ville komme på tværs af den korrekte kode, der kasserer 32 numre, kan de fjerne det, fordi de synes, det er unødvendigt.

Desuden vil nogle hardware-RNG-implementeringer mislykkes. Så selvom udviklere formår at overvinde alle forhindringerne ved korrekt fejlhåndtering, API-særheder, dårlig dokumentation, bør de stadig ikke stole på produktionen af hardware-RNG’er alene.

Svaret er at have ordentlig CSPRNGs for IoTs, hvor produktionen af hardware RNGs er blot en af kilderne i entropi pool. Alle større operativsystemer som Linux, Windows, macOS, Android, iOS, BSD har CSPRNG-undersystemer, der er fejlsikre og applikationsudviklere kan nemt bruge uden at blande sig direkte med hardware og bekymre sig om, at deres kode ikke er korrekt eller at random-numbers er usikre.

Scroll to Top