/dev/random, en kryptografisk sikker pseudo-tilfældig talgenerator (CSPRNG), er kendt for at have ét irriterende problem: blokering. Denne artikel forklarer, hvordan du kan løse det.
I løbet af de sidste par måneder er de tilfældige talgenereringsfaciliteter i kernen blevet omarbejdet en smule, men problemer i dette undersystem er blevet løst i løbet af det bredere . For det meste blev lavet for at forhindre getrandom()-systemkaldet i at blokere i lang tid, når systemet starter, men den underliggende årsag til dette var den tilfældige puljes blokeringsadfærd. En nylig patch ville have fjernet denne pool, og den ville have været forventet at lede mod hovedkernen.
Andy Lutomirski udgav den tredje version af patchen i slutningen af december. Han bidrager "to store semantiske ændringer af tilfældige Linux API'er". Patchen tilføjer et nyt GRND_INSECURE flag til getrandom() systemkaldet (selvom Lutomirsky refererer til det som getentropy(), som er implementeret i glibc ved hjælp af getrandom() med faste flag); dette flag bevirker, at opkaldet altid returnerer den ønskede mængde data, men uden at garantere, at dataene er tilfældige. Kernen vil simpelthen gøre sit bedste for at producere de bedste tilfældige data, den har på det givne tidspunkt. "Det bedste at gøre er nok at kalde det 'USIKKER' (usikker) for at forhindre denne API i at blive brugt til ting, der kræver sikkerhed."
Plastrene fjerner også den blokerende pool. Kernen vedligeholder i øjeblikket to tilfældige datapuljer, den ene svarende til /dev/random og den anden til /dev/urandom, som beskrevet i denne 2015. Den blokerende pool er poolen for /dev/random; læser for den enhed vil blokere (betyder dens navn), indtil "nok" entropi er blevet indsamlet fra systemet til at opfylde anmodningen. Yderligere læsninger fra denne fil blokeres også, hvis der ikke er nok entropi i puljen.
Fjernelse af låsepuljen betyder, at læsning fra /dev/random opfører sig som getrandom() med flag sat til nul (og forvandler GRND_RANDOM flaget til et noop). Når først den kryptografiske tilfældige talgenerator (CRNG) er initialiseret, vil læsning fra /dev/random og kald til getrandom(...,0) ikke blokere og returnere den ønskede mængde tilfældige data.
Lutomirsky siger: "Jeg tror, at Linux-blokeringspuljen er blevet forældet. CRNG Linux genererer output, der er godt nok til endda at blive brugt til nøglegenerering. Blokeringspuljen er ikke stærkere i nogen materiel forstand og kræver en masse infrastruktur af tvivlsom værdi for at understøtte den."
Ændringerne blev foretaget med det mål at sikre, at eksisterende programmer ikke virkelig ville blive påvirket, og faktisk ville der være færre problemer med lange ventetider på ting som GnuPG-nøglegenerering.
“Disse episoder må ikke forstyrre eksisterende programmer. /dev/urandom forbliver uændret. /dev/random blokerer stadig umiddelbart 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."
Lutomirsky bemærkede, at det stadig er et åbent spørgsmål, om kernen skal give såkaldte "sande tilfældige tal", hvilket er, hvad den blokerende kerne til en vis grad skulle gøre. Han ser kun én grund til dette: "overholdelse af regeringens standarder." Lutomirsky foreslog, at hvis kernen skulle levere dette, skulle det gøres gennem en helt anden grænseflade, eller den skulle flyttes ind i brugerrummet, hvilket giver brugeren mulighed for at hente rå hændelsesprøver, der kunne bruges til at skabe en sådan låsepulje.
Stephan Müller foreslog, at hans sæt for Linux Random Number Generator (LRNG) (aktuelt version 26 udgivet) kunne være en måde at give sande tilfældige tal til applikationer, der har brug for det. LRNG er "fuldt i overensstemmelse med SP800-90B retningslinjer for entropikilder, der bruges til at generere tilfældige bits", hvilket gør det til en løsning på regeringens standardproblem.
Matthew Garrett protesterede mod udtrykket "sande tilfældige data," og bemærkede, at de samplede enheder i princippet kunne modelleres præcist nok til at gøre dem forudsigelige: "vi tager ikke stikprøver af kvantehændelser her."
Müller svarede, at udtrykket kommer fra den tyske standard AIS 31 for at beskrive en tilfældig talgenerator, der kun producerer et resultat "i samme hastighed som den underliggende støjkilde producerer entropi."
Terminologiforskelle til side, vil det at have en låsepulje som foreslået af LRNG-patcherne simpelthen føre til forskellige problemer, i det mindste hvis den tilgås uden privilegier.
Som Lutomirsky sagde: "Dette løser ikke problemet. Hvis to forskellige brugere kører dumme programmer som gnupg, vil de bare dræne hinanden. Jeg kan se, at der i øjeblikket er to hovedproblemer med /dev/random: det er tilbøjeligt til DoS (dvs. ressourceudtømning, ondsindet påvirkning eller noget lignende), og da der ikke kræves privilegier for at bruge det, er det også tilbøjeligt til at misbruge. Gnupg er forkert, det er et fuldstændigt sammenbrud. Hvis vi tilføjer en ny uprivilegeret grænseflade, som gnupg og lignende programmer vil bruge, vil vi miste igen."
Mueller bemærkede, at tilføjelsen af getrandom() nu vil tillade GnuPG at bruge denne grænseflade, da den vil give den nødvendige garanti for, at puljen er blevet initialiseret. Baseret på diskussioner med GnuPG-udvikler Werner Koch, mener Mueller, at garantien er den eneste grund til, at GnuPG i øjeblikket læser direkte fra /dev/random. Men hvis der er en uprivilegeret grænseflade, der er modtagelig for lammelsesangreb (som /dev/random er i dag), hævder Lutomirsky, at den vil blive misbrugt af nogle applikationer.
Theodore Yue Tak Ts'o, udvikler af Linuxs tilfældige tal-undersystem, ser ud til at have ændret mening om behovet for en blokerende pool. Han sagde, at fjernelse af denne pulje effektivt ville slippe af med ideen om, at Linux har en ægte tilfældig talgenerator (TRNG): "det er ikke noget sludder, da det er præcis, hvad *BSD altid har gjort."
Han er også bekymret for, at levering af en TRNG-mekanisme simpelthen vil tjene som lokkemad for applikationsudviklere og mener, at det faktisk, givet de forskellige typer hardware, der understøttes af Linux, er umuligt at garantere TRNG i kernen. Selv evnen til kun at arbejde med udstyr med root-privilegier vil ikke løse problemet: "Applikationsudviklere specificerer, at deres applikation skal installeres som root af sikkerhedsmæssige årsager, så det er den eneste måde, du kan få adgang til de 'rigtig gode' tilfældige tal."
Mueller spurgte, om Cao havde opgivet implementeringen af blokeringspuljen, som han selv længe havde foreslået. Cao svarede, at han planlægger at tage Lutomirskys patches og er aktivt imod at tilføje en blokerende grænseflade tilbage til kernen.
"Kernen kan ikke give nogen garantier for, om støjkilden er korrekt karakteriseret. Det eneste en GPG- eller OpenSSL-udvikler kan få, er en vag følelse af, at TRUERANDOM er "bedre", og da de ønsker mere sikkerhed, vil de uden tvivl forsøge at bruge det. På et tidspunkt vil det blive blokeret, og når en anden smart bruger (måske en distributionsspecialist) indsætter det i init-scriptet og systemerne holder op med at virke, skal brugerne kun klage til Linus Torvalds selv.”
Cao går også ind for at give kryptografer og dem, der rent faktisk har brug for TRNG, en måde at høste deres egen entropi i brugerrummet, så de kan bruge dem, som de finder passende. Han siger, at indsamling af entropi ikke er en proces, der kan udføres af kernen på alle de forskellige hardware, den understøtter, og kernen selv kan heller ikke estimere mængden af entropi, der leveres af forskellige kilder.
"Kernen skal ikke blande forskellige støjkilder sammen, og den burde bestemt ikke forsøge at påstå at vide, hvor mange bits af entropi den får, når den forsøger at spille en slags "twitchy entropy game" på en uhyrligt simpel CPU arkitektur for forbrugerbrugere. IOT/Embedded tilfælde, hvor alt er ude af sync med en enkelt master oscillator, hvor der ikke er nogen CPU-instruktion til at genbestille eller omdøbe et register osv.
”Man kan tale om at levere værktøjer, der forsøger at lave disse beregninger, men sådanne ting skal gøres på hver brugers hardware, hvilket simpelthen ikke er praktisk for de fleste distributionsbrugere. Hvis dette 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 vil have "ægte tilfældigheder" og ikke nøjes med mindre." Vi kan tale om, hvordan vi leverer grænseflader til kryptografer, så de kan få den information, de har brug for, ved at få adgang til de primære støjkilder, adskilt og navngivet, og måske på en eller anden måde kan støjkilden autentificere sig selv til et bibliotek eller en brugerrumsapplikation."
Der var en del diskussion om, hvordan en sådan grænseflade kunne se ud, da der for eksempel kunne være sikkerhedsmæssige konsekvenser for nogle begivenheder. Cao bemærkede, at tastaturscanningskoder (dvs. tastetryk) blandes i en pulje som en del af entropiindsamling: "At bringe dette ind i brugerrummet, selv gennem et privilegeret systemopkald, ville mildest talt være uklogt." Det er meget muligt, at andre begivenhedstider kan skabe en form for informationslækage gennem sidekanaler.
Så det ser ud til, at et langvarigt problem med Linuxs tilfældige tal-undersystem er på vej mod en løsning. De ændringer, som undersystemet tilfældigt tal har gennemgået for nylig, har faktisk kun resulteret i DoS-problemer under brugen. Nu er der effektive måder at få de bedste tilfældige tal, kernen kan give. Hvis TRNG stadig er ønskelig på Linux, så skal denne fejl løses i fremtiden, men det vil højst sandsynligt ikke blive gjort i selve kernen.
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com