Som kjent har /dev/random, en kryptografisk sterk generator av pseudotilfeldige tall (CSPRNG), et uheldig problem – blokkeringer. Denne artikkelen forklarer hvordan man kan løse dette.
I løpet av de siste månedene har metodene for å generere tilfeldige tall i kjernen blitt litt omarbeidet, men problemene i dette undersystemet har blitt løst over et mye bredere De nyeste ble gjort for å forhindre langvarig blokkering av systemanropet getrandom() ved oppstart av systemet, men årsaken bak dette var at den blokkende tilfeldige poolen oppførte seg. Den nylige oppdateringen fjernet denne poolen, og man kan forvente at det vil bli en del av hovedkjernen.
Andy Lutomirski publiserte en tredje versjon av patchen i slutten av desember. Den innfører "to hovedsemantiske endringer i Linux sin tilfeldige API".Patchen legger til et nytt flagg GRND_INSECURE til systemanropet getrandom() (selv om Lutomirski refererer til det som getentropy(), som er implementert i glibc ved hjelp av getrandom() med faste flagg); dette flagget gjør at anropet alltid returnerer det forespurte antallet data, men uten garanti for at disse dataene er tilfeldige. Kjernen vil bare gjøre sitt beste for å gi de beste tilfeldige dataene den har på nåværende tidspunkt. "Sannsynligvis det beste man kan gjøre, er å kalle det 'INSECURE' (usikkert), for å hindre bruken av dette API-et for ting som trenger sikkerhet."
Patchene fjerner også den blokkende poolen. For tiden støtter kjernen to pooler for tilfeldige data, hvorav den ene tilsvarer /dev/random, og den andre – /dev/urandom, som beskrevet i denne 2015-rapporten. Den blokkende poolen er en pool for /dev/random; lesing fra denne enheten vil bli blokkert (som navnet antyder) inntil det er samlet inn 'tilstrekkelig' entropi fra systemet for å oppfylle forespørselen. Ytterligere lesninger fra denne filen blir også blokkert hvis det er utilstrekkelig entropi i poolen.
Fjerning av blokkeringpoolen betyr at lesing fra /dev/random oppfører seg som getrandom() med flaggverdien satt til null (og gjør flagget GRND_RANDOM til en noop). Etter initialisering av den kryptografiske tilfeldighetsgeneratoren (CRNG), vil lesing fra /dev/random og kall på getrandom(…,0) ikke bli blokkert og vil returnere det forespurte antallet tilfeldige data.
Lutomirski sier: «Jeg mener at Linux blokkeringpool har utspilt sin rolle. Linux CRNG genererer utdata som er gode nok til å bruke selv for nøkkelgenerering. Blokkeringpoolen er ikke sterkere i noe betydelig henseende, og vedlikeholdet av den krever mye tvilsom infrastruktur.»
Endringene ble gjort med mål om at eksisterende programvare faktisk ikke skal lide, og i realiteten vil problemene med lang ventetid på ting som GnuPG nøkkelgenerering bli færre.
«Denne serien skal ikke forstyrre noen eksisterende programvare. /dev/urandom forblir uendret. /dev/random blir fortsatt blokkert umiddelbart etter oppstart, men det blokkerer mindre enn før. getentropy() med eksisterende flagg vil returnere et resultat som er like passende for praktiske formål som før.»
Lutomirski påpekte at spørsmålet om kjernekoden bør tilby såkalte «ekte tilfeldige tall» fortsatt er åpent, noe som til en viss grad var det blokkeringskjernen skulle gjøre. Han ser bare én grunn til dette: «overholdelse av statlige standarder». Lutomirski antydet at hvis kjernekoden skal sørge for dette, bør det gjøres gjennom et helt annet grensesnitt, eller flyttes til brukerrommet for å gi det muligheten til å trekke ut rå hendelsesmønstre som kan brukes til å lage en slik blokkeringpool.
Stephan Müller foreslo at hans sett Linux-randomnummergeneratoren (LRNG) (for tiden utgitt i versjon 26) kan være en måte å tilby ekte tilfeldige tall for applikasjoner som trenger det. LRNG "oppfyller fullt ut kravene i 'Anbefalingene for kilder til entropi som brukes for generering av tilfeldige biter' SP800-90B", noe som gjør det til en løsning på problemet med statlige standarder.
Matthew Garrett motsatte seg bruken av termen "ekte tilfeldige data", og bemerket at valgte enheter i prinsippet kan modelleres så nøyaktig at de blir forutsigbare: "her trekker vi ikke kvantehendelser ut av lommen".
Müller svarte med at denne termen stammer fra den tyske standarden AIS 31 for å beskrive en tilfeldig tallgenerator som bare gir resultater "i samme hastighet som den grunnleggende støy kilden produserer entropi".
Bortsett fra terminologiske misforståelser, vil tilstedeværelsen av en blokkeringpool, som foreslått av LRNG-lappene, bare føre til ulike problemer, spesielt hvis den er tilgjengelig uten privilegier.
Som Lutomski sa: «Dette løser ikke problemet. Hvis to forskjellige brukere kjører dumme programmer som gnupg, vil de bare tømme hverandre. Jeg ser at det for tiden er to hovedproblemer med /dev/random: det er tilbøyelig til DoS (det vil si utarming av ressurser, ondsinnede angrep eller noe lignende), og siden det ikke kreves noen privilegier for å bruke det, er det også utsatt for misbruk. Gnupg er feil, det er fullstendig kollaps. Hvis vi legger til et nytt, ikke-privilegert grensesnitt som gnupg og lignende programmer vil bruke, vil vi igjen tape».
Müller bemerket at tillegg av getrandom() nå vil tillate GnuPG å bruke dette grensesnittet, ettersom det vil gi den nødvendige garantien for at poolen har blitt initialisert. Basert på diskusjoner med GnuPG-utvikler Werner Koch, mener Müller at garantien er den eneste grunnen til at GnuPG i dag leser direkte fra /dev/random. Men hvis det finnes et ikke-privilegert grensesnitt som er mottakelig for tjenestenekt (slik som dagens /dev/random), vil det ifølge Lutomski bli feilaktig brukt av enkelte applikasjoner.
Teodor Cao (Theodore Yue Tak Ts’o), utviklaren av Linux' tilfeldige tallsubsystem, har åpenbart endret mening angående nødvendigheten av en blokkert pool. Han sa at fjerning av denne poolen vil effektivt eliminere ideen om at Linux har en ekte tilfeldig tallgenerator (TRNG): «Dette er ikke meningsløst, da dette nettopp er det som alltid har blitt gjort i *BSD."
Han er også bekymret for at det å gi en TRNG-mekanisme bare vil fungere som agn for applikasjonsutviklere, og mener at det faktisk er umulig å garantere TRNG i kjernen, gitt de forskjellige typene maskinvare som Linux støtter. Problemet vil ikke bli løst selv med muligheten for å arbeide med maskinvare kun basert på root-rettigheter: «Applikasjonsutviklere angir at for å installere applikasjonen deres trygt, må den kjøre som root, fordi kun da kan du få tilgang til 'virkelig gode' tilfeldige tall".
Müller spurte om Cao hadde trukket tilbake implementeringen av den blokkede poolen, som han selv hadde foreslått for lenge siden. Cao svarte at han planlegger å ta inn Lutomirski sine patcher og motsetter seg aktivt å legge en blokkert grensesnitt tilbake i kjernen.
«Kjernen kan ikke gi noen garantier om hvorvidt støykilden er karakterisert på en ordentlig måte. Det eneste utvikleren av GPG eller OpenSSL kan få, er en vag følelse av at TRUERANDOM er 'bedre', og siden de ønsker bedre sikkerhet, vil de utvilsomt forsøke å bruke det. På et tidspunkt vil det bli blokkert, og når en annen smart bruker (kanskje en distribusjonsspesialist) setter det inn i init-skript, vil systemene slutte å fungere, og brukerne vil bare ha klager til Linus Torvals.
Cao argumenterer også for å gi kryptografer og de som virkelig trenger TRNG, muligheten til å samle sin egen entropi i brukerrommet for å bruke den etter eget ønske. Han sier at innsamling av entropi ikke er en prosess som kan utføres av kjernen på alle de støttede maskinvareenhetene, i tillegg kan kjernen selv ikke vurdere mengden entropi som tilbys av de forskjellige kildene.
«Kjernen skal ikke blande forskjellige noise-kilder sammen, og den bør absolutt ikke forsøke å påstå at den vet hvor mange biter entropi den får når den prøver å spille et slags «rykkete entropispill» på en ekstremt enkel CPU-arkitektur for brukerens IOT/Embedded-saker, når alt er usynkronisert med en enkelt mastergenerator, når det ikke finnes noen CPU-instruksjon for å omorganisere eller omdøpe registre osv.».
«Man kan snakke om å tilby verktøy som prøver å gjøre disse beregningene, men slike ting må utføres på hver brukers utstyr, noe som er praktisk talt umulig for de fleste distributørbrukere. Hvis dette derimot kun er ment for kryptografer, bør det gjøres i deres brukerrum. Og la oss ikke forenkle GPG, OpenSSL osv., slik at alle sier: «vi vil ha «ekte tilfeldighet» og aksepterer ikke mindre». Man kan snakke om hvordan vi tilbyr grensesnitt for kryptografer slik at de kan få nødvendig informasjon ved å få tilgang til primære noise-kilder, skilt og navngitt, og kanskje på en eller annen måte kan noise-kilden autentisere seg i biblioteket eller applikasjonen i brukerrommet».
Det var en liten diskusjon om hvordan et slikt grensesnitt kan se ut, ettersom for eksempel kan noen hendelser ha sikkerhetsmessige konsekvenser. Cao bemerket at kode for tastaturskanning (det vil si tastetrykk) blandes inn i puljen som en del av innsamlingen av entropi: «Å flytte dette til brukerrommet, selv gjennom et privilegert systemanrop, ville vært, minst sagt, uforsvarlig». Det er helt mulig at andre tidspunkter for hendelser kan skape lekkasje av informasjon via sidekanaler.
Dermed oppstår følelsen av at det lange problemet med Linuxs tilfeldige tall subsystem er på vei mot løsning. Endringene som subsystemet for tilfeldige tall har gjennomgått nylig, har faktisk bare ført til DoS-problemer ved bruk av det. Nå har det imidlertid blitt utviklet effektive metoder for å få de beste tilfeldige tallene som kjernen kan tilby. Hvis TRNG fortsatt er ønskelig for Linux, må denne mangelen rettes i fremtiden, men det vil sannsynligvis ikke bli gjort innen selve kjernen.
Litt reklame 🙂
Takk for at du er med oss. Liker du artiklene våre? Ønsker du å se mer interessant materiale? Støtt oss ved å legge inn en bestilling eller ved å anbefale oss til kjente, , en unik alternativ til entry-level servere, som vi har laget for deg: (tilgjengelige alternativer med RAID1 og RAID10, opptil 24 kjerner og opptil 40GB DDR4).
Dell R730xd er 2 ganger billigere i Equinix Tier IV datasenteret i Amsterdam? Bare hos oss i Nederland! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — fra $99! Les om hvordan
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish