Som bekendt har /dev/random, en kryptografisk sikker pseudo-random number generator (CSPRNG), et uheldigt problem – blokeringer. Denne artikel beskriver, hvordan man kan løse det.
I de seneste måneder er midlerne til at generere tilfældige tal i kernen blevet lidt omarbejdet, men problemerne i dette subsystem har været løst over en længere periode. De seneste blev foretaget med henblik på at forhindre langvarige blokeringer af systemopkaldet getrandom() ved systemstart, men årsagen til dette var adfærden af den blokerende tilfældige pulje. Den nylige patch ville fjerne denne pulje, og man kunne forvente, at den ville blive sendt til hovedkernen.
Andy Lutomirski offentliggjorde den tredje version af patchen i slutningen af december. Den medbringer "to væsentlige semantiske ændringer i Linux's tilfældige API'er".Patchen tilføjer et nyt flag GRND_INSECURE til systemopkaldet getrandom() (selvom Lutomirski omtaler det som getentropy(), som er implementeret i glibc ved hjælp af getrandom() med faste flag); dette flag får opkaldet til altid at returnere det anmodede antal data, men uden garanti for, at disse data er tilfældige. Kernen vil blot gøre en indsats for at give de bedste tilfældige data, den har på det tidspunkt. "Sandsynligvis det bedste, man kan gøre, er at kalde det 'INSECURE' (usikkert), for at forhindre brug af dette API til ting, der kræver sikkerhed."
Patchene fjerner også den blokerende pulje. I øjeblikket understøtter kernen to puljer af tilfældige data, hvoraf den ene svarer til /dev/random, og den anden til /dev/urandom, som beskrevet i denne 2015. Den blokerende pulje er en pulje for /dev/random; læsning fra denne enhed vil blive blokeret (det menes af dens navn), indtil der er samlet 'tilstrækkelig' entropi fra systemet for at imødekomme anmodningen. Yderligere læsninger fra denne fil blokeres også, hvis der ikke er tilstrækkelig entropi i puljen.
Fjernelse af blokkeringspuljen betyder, at læsning fra /dev/random fungerer som getrandom() med flagværdien sat til nul (og omdanner flaget GRND_RANDOM til noop). Efter initialisering af den kryptografiske tilfældighedsgenerator (CRNG) vil læsning fra /dev/random og kald af getrandom(…,0) ikke blokere og returnere det ønskede antal tilfældige data.
Lutomirski siger: „Jeg mener, at Linux' blokkeringspulje er forældet. Linux' CRNG genererer output, der er godt nok til at bruge det selv til nøglegenerering. Blokkeringspuljen er ikke stærkere på nogen væsentlig måde, og opretholdelsen kræver en masse infrastruktur af tvivlsom værdi.“
Ændringerne er foretaget med henblik på, at eksisterende programmer ikke reelt skal lide skade, og faktisk vil problemerne med lang ventetid på ting som GnuPG nøglegenerering blive færre.
„Disse serier bør ikke forstyrre nogen eksisterende programmer. /dev/urandom forbliver uændret. /dev/random er stadig blokeret straks efter opstart, men det blokerer mindre end før. getentropy() med de eksisterende flag vil returnere et resultat, der er lige så egnet til praktiske formål som før.“
Lutomirski bemærkede, at spørgsmålet om, hvorvidt kernen skal levere såkaldte 'ægte tilfældige tal', stadig er åbent, hvilket i visse henseender var meningen med blokkeringspuljen. Han ser kun én grund til dette: „overholdelse af statslige standarder“. Lutomirski foreslog, at hvis kernen skal levere det, så skal det gøres gennem et helt andet interface, eller det skal flyttes til brugerrummet, der giver mulighed for at trække rå hændelsessamples ud, som kan bruges til at skabe en sådan blokkeringspulje.
Stephan Müller foreslog, at hans sæt Til Linuxs tilfældige talgenerator (LRNG) (som i øjeblikket har version 26) kan være en måde at levere ægte tilfældige tal til applikationer, der har brug for det. LRNG "lever fuldt ud op til anbefalingerne i 'Recommendations for the Entropy Sources Used for Random Bit Generation' SP800-90B", hvilket gør det til en løsning på problemet med statslige standarder.
Matthew Garrett har protesteret mod termen "ægte tilfældige data" og bemærket, at de valgte enheder grundlæggende kan modelleres tilstrækkeligt præcist til at blive forudsigelige: "vi her ikke udvælger kvantehændelser."
Müller svarede, at termen kommer fra den tyske standard AIS 31 til beskrivelse af en tilfældig talgenerator, som kun udleverer resultater "med samme hastighed, som den grundlæggende støjkilde producerer entropi."
Udover terminologiske misforståelser vil tilstedeværelsen af en låsepool, som foreslået af LRNG-patches, blot føre til forskellige problemer, i det mindste hvis den er tilgængelig uden privilegier.
Som Lutomirski sagde: "Dette løser ikke problemet. Hvis to forskellige brugere kører dumme programmer som gnupg, vil de blot udtømme hinanden. Jeg ser, at der i øjeblikket er to hovedproblemer med /dev/random: det er tilbøjeligt til DoS (dvs. udtømning af ressourcer, ondsindet indflydelse eller noget lignende), og da der ikke kræves nogen privilegier for at bruge det, er det også tilbøjeligt til misbrug. Gnupg er forkert, det er en fuldstændig kollaps. Hvis vi tilføjer et nyt uprivilegeret interface, som gnupg og lignende programmer vil bruge, vil vi igen tabe.
Müller bemærkede, at tilføjelsen af getrandom() nu muliggør, at GnuPG kan bruge dette interface, da det vil sikre den nødvendige garanti for, at puljen er blevet initialiseret. Baseret på diskussioner med GnuPG-udvikleren Werner Koch, mener Müller, at garantien er den eneste grund til, at GnuPG i øjeblikket læser direkte fra /dev/random. Men hvis der er et uprivilegeret interface, der er udsat for tjenestenægtelse (som i dag /dev/random), så vil det ifølge Lutomirski blive misbrugt af nogle applikationer.
Theodore Yue Tak Ts'o, udvikleren af Linux' tilfældige tal subsystem, har angiveligt ændret mening om nødvendigheden af en blokkeringspulje. Han sagde, at fjernelse af denne pulje effektivt ville fjerne ideen om, at Linux har en ægte tilfældig tal generator (TRNG): «Dette er ikke meningsløst, da det netop er, hvad *BSD altid har gjort.»
Han er også bekymret for, at tilvejebringelsen af en TRNG-mekanisme blot vil fungere som lokkemad for app-udviklere og mener, at det i virkeligheden er umuligt at garantere TRNG i kernen, givet de forskellige typer hardware, som Linux understøtter. Problemet løses ikke engang af muligheden for kun at arbejde med hardware baseret på root-rettigheder: «App-udviklere anviser, at deres applikation af sikkerhedsmæssige årsager skal installeres som root, for kun derved kan du få adgang til 'virkelig gode' tilfældige tal.»
Müller spurgte, om Ts'o havde trukket tilbuddet om at implementere en blokkeringspulje tilbage, som han selv havde foreslået for længe siden. Ts'o svarede, at han planlægger at tage patchene fra Lutomirsky og er aktivt imod at tilføje en blokkeringsgrænseflade tilbage til kernen.
«Kernen kan ikke give nogen garantier for, om noise source er karakteriseret korrekt. Det eneste, som udvikleren af GPG eller OpenSSL kan få, er en vag fornemmelse af, at TRUERANDOM er 'bedre', og da de ønsker bedre sikkerhed, vil de uden tvivl forsøge at bruge det. På et eller andet tidspunkt vil det blive blokeret, og når en anden smart bruger (måske en distributionsudgiver) indsætter det i init scriptet, og systemerne stopper med at fungere, vil brugerne kun have mulighed for at klage til Linus Torvalds selv.»
Ts'o taler også for at give kryptografer og dem, der virkelig har brug for TRNG, en måde at indsamle deres egen entropi i brugerområdet, så de kan bruge det, som de ønsker. Han siger, at indsamlingen af entropi ikke er en proces, som kernen kan udføre på al den hardware, den understøtter, desuden kan selve kernen ikke vurdere mængden af entropi, der leveres af de forskellige kilder.
«Kernen må ikke blande forskellige støjkilder sammen, og det må bestemt ikke påstå, at den ved, hvor mange bit entropi den modtager, når den forsøger at spille et eller andet 'stridigt entropispil' på en aldeles enkel CPU-arkitektur til IOT/Embedded brugssituationer, når alt er desynkroniseret med en eneste mastergenerator, når der ikke findes nogen CPU-kommando til at omarrangere eller omdøbe registre osv.»
«Man kan tale om at give værktøjer, der forsøger at gøre disse beregninger, men sådanne ting bør ske på hver brugers udstyr, hvilket for de fleste brugere af distributionen simpelthen er upraktisk. Hvis det derimod kun er beregnet til kryptografer, så lad det gøres i deres brugerrum. Og lad os ikke forenkle GPG, OpenSSL osv., så alle siger: 'vi ønsker 'sand tilfældighed' og accepterer ikke mindre'. Man kan tale om måden, hvorpå vi giver kryptografer grænseflader, så de kan få den nødvendige information gennem adgang til primære støjkilder, der er adskilt og navngivet, og måske på en eller anden måde kan støjkilden autentificere sig selv i biblioteket eller brugerrum-applikationen.»
Der var en lille diskussion om, hvordan en sådan grænseflade kunne se ud, da nogle hændelser kan have sikkerhedsmæssige konsekvenser. Cao påpegede, at koder for tastetryk (dvs. taster, der trykkes) blandes ind i puljen som en del af entropisamlingen: «At flytte dette til brugerrummet, selv gennem et privilegeret systemopkald, ville være, mildest talt, ufornuftigt». Det er helt muligt, at andre hændelser kan skabe en eller anden form for informationslækage gennem sidekanaler.
Derfor opstår der en følelse af, at det gamle problem med Linux' tilfældige tal subsystem er på vej til at blive løst. De ændringer, som det tilfældige tal subsystem har gennemgået for nylig, har faktisk kun ført til DoS-problemer under brugen. Nu er der effektive måder at få de bedste tilfældige tal, som kernen kan levere. Hvis TRNG stadig er ønskeligt for Linux, skal denne mangel rettes i fremtiden, men det vil sandsynligvis ikke blive gjort inden for selve kernen.
Lidt reklame 🙂
Tak fordi du bliver hos os. Kan du lide vores artikler? Ønsker du at se flere interessante materialer? Støt os ved at bestille eller anbefale os til dine bekendte, , en unik analog til entry-level servere, som vi har designet til dig: (tilgængelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd til halv pris i datacenteret Equinix Tier IV i Amsterdam? Kun hos os i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $! Læs om hvordan
Kilde: habr.com
