/dev/random, en kryptografisk sikker pseudo-tilfeldig tallgenerator (CSPRNG), er kjent for å ha ett irriterende problem: blokkering. Denne artikkelen forklarer hvordan du kan løse det.
I løpet av de siste månedene har de tilfeldige tallgenereringsfasilitetene i kjernen blitt litt omarbeidet, men problemer i dette undersystemet har blitt løst i løpet av det bredere . Det meste ble laget for å forhindre at getrandom()-systemanropet blokkerte i lang tid når systemet starter opp, men den underliggende årsaken til dette var blokkeringsatferden til den tilfeldige poolen. En nylig oppdatering ville ha fjernet dette bassenget, og det ville vært forventet å gå mot hovedkjernen.
Andy Lutomirski publiserte den tredje versjonen av oppdateringen i slutten av desember. Han bidrar "to store semantiske endringer i tilfeldige Linux APIer". Patchen legger til et nytt GRND_INSECURE-flagg til getrandom()-systemkallet (selv om Lutomirsky refererer til det som getentropy(), som er implementert i glibc ved å bruke getrandom() med faste flagg); dette flagget fører til at anropet alltid returnerer mengden data som er forespurt, men uten å garantere at dataene er tilfeldige. Kjernen vil ganske enkelt gjøre sitt beste for å produsere de beste tilfeldige dataene den har på det gitte tidspunktet. "Sannsynligvis er det beste å gjøre å kalle det 'USIKKER' (usikker) for å forhindre at denne API-en brukes til ting som trenger sikkerhet."
Plastrene fjerner også blokkeringsbassenget. Kjernen opprettholder for tiden to tilfeldige datapooler, en som tilsvarer /dev/random og den andre til /dev/urandom, som beskrevet i denne 2015. Det blokkerende bassenget er bassenget for /dev/random; leser for den enheten vil blokkere (som betyr navnet) til "nok" entropi er samlet inn fra systemet til å tilfredsstille forespørselen. Ytterligere lesninger fra denne filen blokkeres også hvis det ikke er nok entropi i bassenget.
Å fjerne låsepoolen betyr at lesing fra /dev/random oppfører seg som getrandom() med flagg satt til null (og gjør GRND_RANDOM-flagget til en noop). Når den kryptografiske tilfeldige tallgeneratoren (CRNG) er initialisert, vil lesing fra /dev/random og kall til getrandom(...,0) ikke blokkere og vil returnere den forespurte mengden tilfeldig data.
Lutomirsky sier: "Jeg tror at Linux-blokkeringspoolen har blitt foreldet. CRNG Linux genererer utdata som er gode nok til å bli brukt til nøkkelgenerering. Det blokkerende bassenget er ikke sterkere i noen materiell forstand og krever mye infrastruktur av tvilsom verdi for å støtte det.»
Endringene ble gjort med mål om å sikre at eksisterende programmer ikke virkelig ville bli påvirket, og faktisk ville det være færre problemer med lange ventetider på ting som GnuPG-nøkkelgenerering.
"Disse episodene må ikke forstyrre eksisterende programmer. /dev/urandom forblir uendret. /dev/random blokkerer fortsatt umiddelbart ved oppstart, men den blokkerer mindre enn før. getentropy() med de eksisterende flaggene vil returnere et resultat som er like egnet for praktiske formål som før."
Lutomirsky bemerket at det fortsatt er et åpent spørsmål om kjernen skal gi såkalte "sanne tilfeldige tall", som er hva blokkeringskjernen til en viss grad skulle gjøre. Han ser bare én grunn til dette: «overholdelse av myndighetenes standarder». Lutomirsky foreslo at hvis kjernen skulle gi dette, skulle det gjøres gjennom et helt annet grensesnitt, eller det skulle flyttes inn i brukerområdet, slik at brukeren kan hente rå hendelsesprøver som kan brukes til å lage en slik låsepool.
Stephan Müller foreslo at hans sett for Linux Random Number Generator (LRNG) (nå versjon 26 utgitt) kan være en måte å gi sanne tilfeldige tall for applikasjoner som trenger det. LRNG er "fullstendig kompatibel med SP800-90B retningslinjer for entropikilder som brukes til å generere tilfeldige biter", noe som gjør det til en løsning på myndighetenes standardproblem.
Matthew Garrett protesterte mot begrepet "ekte tilfeldige data," og la merke til at enhetene som ble samplet i prinsippet kunne modelleres nøyaktig nok til å gjøre dem forutsigbare: "vi prøver ikke kvantehendelser her."
Müller svarte at begrepet kommer fra den tyske standarden AIS 31 for å beskrive en tilfeldig tallgenerator som bare produserer et resultat "i samme hastighet som den underliggende støykilden produserer entropi."
Terminologiforskjeller til side, vil det å ha en låsepool som foreslått av LRNG-patchene ganske enkelt føre til forskjellige problemer, i det minste hvis den er tilgjengelig uten privilegier.
Som Lutomirsky sa: «Dette løser ikke problemet. Hvis to forskjellige brukere kjører dumme programmer som gnupg, vil de bare tappe hverandre. Jeg ser at det for øyeblikket er to hovedproblemer med /dev/random: det er utsatt for DoS (dvs. ressursutarming, ondsinnet påvirkning eller noe lignende), og siden det ikke kreves privilegier for å bruke det, er det også utsatt for misbruk. Gnupg tar feil, det er en fullstendig kollaps. Hvis vi legger til et nytt uprivilegert grensesnitt som gnupg og lignende programmer vil bruke, vil vi tape igjen."
Mueller bemerket at tillegget av getrandom() nå vil tillate GnuPG å bruke dette grensesnittet, siden det vil gi den nødvendige garantien for at bassenget er initialisert. Basert på diskusjoner med GnuPG-utvikler Werner Koch, mener Mueller at garantien er den eneste grunnen til at GnuPG for øyeblikket leser direkte fra /dev/random. Men hvis det er et uprivilegert grensesnitt som er mottakelig for tjenestenekt (som /dev/random er i dag), hevder Lutomirsky at det vil bli misbrukt av noen applikasjoner.
Theodore Yue Tak Ts'o, utvikler av Linuxs tilfeldige tall-undersystem, ser ut til å ha ombestemt seg om behovet for en blokkerende pool. Han sa at fjerning av dette bassenget effektivt ville bli kvitt ideen om at Linux har en ekte tilfeldig tallgenerator (TRNG): "dette er ikke tull, siden dette er akkurat hva *BSD alltid har gjort."
Han er også bekymret for at det å gi en TRNG-mekanisme rett og slett vil tjene som et lokkemiddel for applikasjonsutviklere og mener at det faktisk, gitt de forskjellige typer maskinvare som støttes av Linux, er umulig å garantere TRNG i kjernen. Selv muligheten til å jobbe med utstyr bare med root-privilegier vil ikke løse problemet: "Applikasjonsutviklere spesifiserer at applikasjonen deres skal installeres som root for sikkerhetsformål, slik at dette er den eneste måten du kan få tilgang til de 'virkelig gode' tilfeldige tallene."
Mueller spurte om Cao hadde forlatt implementeringen av blokkeringsbassenget som han selv lenge hadde foreslått. Cao svarte at han planlegger å ta Lutomirskys oppdateringer og motsetter seg aktivt å legge til et blokkerende grensesnitt tilbake til kjernen.
«Kjernen kan ikke gi noen garantier for om støykilden er riktig karakterisert. Det eneste en GPG- eller OpenSSL-utvikler kan få er en vag følelse av at TRUERANDOM er «bedre», og siden de ønsker mer sikkerhet, vil de utvilsomt prøve å bruke det. På et tidspunkt vil den bli blokkert, og når en annen smart bruker (kanskje en distribusjonsspesialist) setter den inn i init-skriptet og systemene slutter å fungere, vil brukerne bare måtte klage til Linus Torvalds selv."
Cao tar også til orde for å gi kryptografer og de som faktisk trenger TRNG en måte å høste sin egen entropi i brukerområdet for å bruke etter eget ønske. Han sier at innsamling av entropi ikke er en prosess som kan utføres av kjernen på all den forskjellige maskinvaren den støtter, og heller ikke kan kjernen selv anslå mengden entropi som leveres av forskjellige kilder.
"Kjernen skal ikke blande forskjellige støykilder sammen, og den burde absolutt ikke prøve å påstå å vite hvor mange biter av entropi den får når den prøver å spille et slags "twitchy entropy game" på en uhyrlig enkel CPU arkitektur for forbrukerbrukere. IOT/Embedded tilfeller der alt er ute av synkronisering med en enkelt hovedoscillator, hvor det ikke er noen CPU-instruksjon for å omorganisere eller gi nytt navn til et register, osv.
«Du kan snakke om å tilby verktøy som prøver å gjøre disse beregningene, men slike ting må gjøres på hver brukers maskinvare, noe som rett og slett ikke er praktisk for de fleste distribusjonsbrukere. Hvis dette kun er ment for kryptografer, så la det gjøres i deres brukerrom. Og la oss ikke forenkle GPG, OpenSSL osv. slik at alle sier «vi vil ha «ekte tilfeldighet» og ikke nøyer oss med mindre». Vi kan snakke om hvordan vi gir grensesnitt til kryptografer slik at de kan få informasjonen de trenger ved å få tilgang til de primære støykildene, separert og navngitt, og kanskje på en eller annen måte kan støykilden autentisere seg til et bibliotek eller brukerromsapplikasjon."
Det var en del diskusjon om hvordan et slikt grensesnitt kan se ut, siden det for eksempel kan være sikkerhetsmessige implikasjoner for enkelte hendelser. Cao bemerket at tastaturskanningskoder (dvs. tastetrykk) blandes inn i en pool som en del av entropisamlingen: "Å bringe dette inn i brukerrommet, selv gjennom et privilegert systemanrop, ville være mildt sagt uklokt." Det er ganske mulig at andre hendelsestidspunkter kan skape en slags informasjonslekkasje gjennom sidekanaler.
Så det ser ut som et langvarig problem med Linuxs tilfeldige tall-undersystem er på vei mot en løsning. Endringene som undersystemet tilfeldig tall har gjennomgått nylig har faktisk bare resultert i DoS-problemer mens du bruker det. Nå er det effektive måter å få de beste tilfeldige tallene kjernen kan gi. Hvis TRNG fortsatt er ønskelig på Linux, må denne feilen løses i fremtiden, men mest sannsynlig vil dette ikke bli gjort i selve kjernen.
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com