Van /dev/random, een cryptografisch veilige pseudo-willekeurige nummergenerator (CSPRNG), is bekend dat deze één vervelend probleem heeft: blokkeren. In dit artikel wordt uitgelegd hoe je dit kunt oplossen.
De afgelopen maanden zijn de faciliteiten voor het genereren van willekeurige getallen in de kernel enigszins herwerkt, maar de problemen in dit subsysteem zijn in de loop van de bredere periode opgelost. . Het meest zijn gemaakt om te voorkomen dat de systeemaanroep getrandom() lange tijd blokkeert wanneer het systeem opstart, maar de onderliggende reden hiervoor was het blokkeergedrag van de willekeurige pool. Een recente patch zou deze pool hebben verwijderd en er zou verwacht worden dat deze richting de hoofdkern zou gaan.
Andy Lutomirski publiceerde eind december de derde versie van de patch. Hij draagt bij "twee belangrijke semantische veranderingen in willekeurige Linux API's". De patch voegt een nieuwe GRND_INSECURE vlag toe aan de getrandom() systeemaanroep (hoewel Lutomirsky ernaar verwijst als getentropy(), wat in glibc is geïmplementeerd met behulp van getrandom() met vaste vlaggen); deze vlag zorgt ervoor dat de oproep altijd de gevraagde hoeveelheid gegevens retourneert, maar zonder te garanderen dat de gegevens willekeurig zijn. De kernel zal eenvoudigweg zijn best doen om de beste willekeurige gegevens te produceren waarover hij op dat moment beschikt. "Waarschijnlijk is het het beste om het 'ONZEKER' te noemen (onveilig) om te voorkomen dat deze API wordt gebruikt voor zaken die beveiliging nodig hebben."
De pleisters verwijderen ook de blokkerende pool. De kernel onderhoudt momenteel twee willekeurige datapools, één corresponderend met /dev/random en de andere met /dev/urandom, zoals beschreven in dit document. 2015. De blokkeerpool is de pool voor /dev/random; leest voor dat apparaat zal blokkeren (wat de naam betekent) totdat er "genoeg" entropie uit het systeem is verzameld om aan het verzoek te voldoen. Verdere leesbewerkingen uit dit bestand worden ook geblokkeerd als er niet voldoende entropie in de pool aanwezig is.
Het verwijderen van de lock-pool betekent dat het lezen uit /dev/random zich gedraagt als getrandom() met vlaggen ingesteld op nul (en verandert de vlag GRND_RANDOM in een noop). Zodra de cryptografische generator voor willekeurige getallen (CRNG) is geïnitialiseerd, zal het lezen van /dev/random en oproepen naar getrandom(...,0) niet blokkeren en de gevraagde hoeveelheid willekeurige gegevens retourneren.
Lutomirsky zegt: “Ik geloof dat de Linux-blokkeerpool verouderd is. CRNG Linux genereert uitvoer die goed genoeg is om zelfs voor het genereren van sleutels te worden gebruikt. De blokkeringspool is in materiële zin niet sterker en vereist veel infrastructuur van twijfelachtige waarde om deze te ondersteunen.”
De veranderingen werden aangebracht met als doel ervoor te zorgen dat bestaande programma's niet echt zouden worden beïnvloed, en dat er in feite minder problemen zouden zijn met lang wachten op zaken als het genereren van GnuPG-sleutels.
“Deze afleveringen mogen bestaande programma’s niet verstoren. /dev/urandom blijft ongewijzigd. /dev/random blokkeert nog steeds onmiddellijk na het opstarten, maar blokkeert minder dan voorheen. getentropy() met de bestaande vlaggen zal een resultaat opleveren dat net zo geschikt is voor praktische doeleinden als voorheen."
Lutomirsky merkte op dat het nog steeds een open vraag is of de kernel zogenaamde ‘echte willekeurige getallen’ zou moeten leveren, wat de blokkerende kernel tot op zekere hoogte zou moeten doen. Hij ziet daar maar één reden voor: “naleving van overheidsnormen.” Lutomirsky suggereerde dat als de kernel dit zou bieden, dit via een compleet andere interface zou moeten gebeuren, of dat het naar de gebruikersruimte zou moeten worden verplaatst, waardoor de gebruiker onbewerkte gebeurtenisvoorbeelden kon ophalen die gebruikt konden worden om zo'n lock-pool te creëren.
Stephan Müller stelde zijn set voor voor Linux Random Number Generator (LRNG) (momenteel versie 26 uitgebracht) zou een manier kunnen zijn om echte willekeurige getallen te bieden voor toepassingen die dit nodig hebben. LRNG is “volledig in overeenstemming met de SP800-90B-richtlijnen voor entropiebronnen die worden gebruikt om willekeurige bits te genereren”, waardoor het een oplossing is voor het probleem van de overheidsstandaarden.
Matthew Garrett maakte bezwaar tegen de term ‘echte willekeurige gegevens’ en merkte op dat de bemonsterde apparaten in principe nauwkeurig genoeg konden worden gemodelleerd om ze voorspelbaar te maken: ‘we bemonsteren hier geen kwantumgebeurtenissen.’
Müller antwoordde dat de term afkomstig is uit de Duitse standaard AIS 31 om een generator van willekeurige getallen te beschrijven die alleen een resultaat produceert "in dezelfde mate als de onderliggende ruisbron entropie produceert".
Afgezien van de verschillen in terminologie, zal het hebben van een lock-pool, zoals voorgesteld door de LRNG-patches, eenvoudigweg tot verschillende problemen leiden, tenminste als er zonder rechten toegang toe wordt verkregen.
Zoals Lutomirsky zei: “Dit lost het probleem niet op. Als twee verschillende gebruikers stomme programma's als gnupg uitvoeren, zullen ze elkaar gewoon uitputten. Ik zie dat er momenteel twee hoofdproblemen zijn met /dev/random: het is vatbaar voor DoS (d.w.z. uitputting van bronnen, kwaadwillige beïnvloeding of iets dergelijks), en aangezien er geen privileges vereist zijn om het te gebruiken, is het ook vatbaar voor misbruik. Gnupg heeft ongelijk, het is een complete ineenstorting. Als we een nieuwe, onbevoorrechte interface toevoegen die gnupg en vergelijkbare programma's zullen gebruiken, zullen we opnieuw verliezen."
Mueller merkte op dat de toevoeging van getrandom() GnuPG nu in staat zal stellen deze interface te gebruiken, omdat het de noodzakelijke garantie biedt dat de pool is geïnitialiseerd. Op basis van gesprekken met GnuPG-ontwikkelaar Werner Koch is Mueller van mening dat de garantie de enige reden is waarom GnuPG momenteel rechtstreeks uit /dev/random leest. Maar als er een interface zonder privileges bestaat die vatbaar is voor Denial of Service (zoals /dev/random tegenwoordig is), beweert Lutomirsky dat deze door sommige applicaties zal worden misbruikt.
Theodore Yue Tak Ts'o, ontwikkelaar van het Linux-subsysteem met willekeurige getallen, lijkt van gedachten te zijn veranderd over de noodzaak van een blokkeringspool. Hij zei dat het verwijderen van deze pool effectief het idee zou wegnemen dat Linux een echte willekeurige nummergenerator (TRNG) heeft: "Dit is geen onzin, aangezien dit precies is wat *BSD altijd heeft gedaan."
Hij is ook bezorgd dat het aanbieden van een TRNG-mechanisme alleen maar zal dienen als lokaas voor applicatie-ontwikkelaars en is van mening dat het in feite, gezien de verschillende soorten hardware die door Linux worden ondersteund, onmogelijk is om TRNG in de kernel te garanderen. Zelfs de mogelijkheid om alleen met apparatuur met rootrechten te werken, zal het probleem niet oplossen: "Applicatieontwikkelaars specificeren dat hun applicatie om veiligheidsredenen als root moet worden geïnstalleerd, zodat dit de enige manier is waarop je toegang krijgt tot de 'echt goede' willekeurige getallen."
Mueller vroeg of Cao de implementatie van de blocking pool had opgegeven die hij zelf al lang had voorgesteld. Cao antwoordde dat hij van plan is de patches van Lutomirsky over te nemen en zich actief verzet tegen het toevoegen van een blokkerende interface aan de kernel.
“De kernel kan geen garantie geven of de geluidsbron goed is gekarakteriseerd. Het enige dat een GPG- of OpenSSL-ontwikkelaar kan krijgen is een vaag gevoel dat TRUERANDOM "beter" is, en aangezien ze meer beveiliging willen, zullen ze ongetwijfeld proberen daar gebruik van te maken. Op een gegeven moment zal het worden geblokkeerd, en wanneer een andere slimme gebruiker (misschien een distributiespecialist) het in het init-script invoegt en de systemen niet meer werken, hoeven gebruikers alleen maar te klagen bij Linus Torvalds zelf.
Cao pleit er ook voor om cryptografen en degenen die TRNG daadwerkelijk nodig hebben een manier te geven om hun eigen entropie in de gebruikersruimte te oogsten en te gebruiken zoals zij dat nodig achten. Hij zegt dat het verzamelen van entropie geen proces is dat door de kernel kan worden uitgevoerd op alle verschillende hardware die het ondersteunt, noch kan de kernel zelf de hoeveelheid entropie schatten die door verschillende bronnen wordt geleverd.
"De kernel zou geen verschillende ruisbronnen moeten mixen, en hij zou zeker niet moeten proberen te beweren hoeveel bits entropie hij krijgt als hij een soort "twitchy entropie-spel" probeert te spelen op een waanzinnig eenvoudige CPU architectuur voor consumentengebruikers. IOT/Embedded-gevallen waarin alles niet synchroon loopt met een enkele master-oscillator, waar er geen CPU-instructie is om een register opnieuw te ordenen of te hernoemen, enz."
“Je kunt praten over het aanbieden van tools die deze berekeningen proberen uit te voeren, maar zulke dingen moeten op de hardware van elke gebruiker worden gedaan, wat voor de meeste distributiegebruikers simpelweg niet praktisch is. Als dit alleen bedoeld is voor cryptografen, laat het dan in hun gebruikersruimte gebeuren. En laten we GPG, OpenSSL, etc. niet vereenvoudigen, zodat iedereen zegt: "we willen 'echte willekeur' en nemen geen genoegen met minder." We kunnen praten over hoe we interfaces bieden aan cryptografen, zodat ze de informatie kunnen krijgen die ze nodig hebben door toegang te krijgen tot de primaire ruisbronnen, gescheiden en benoemd, en misschien kan de ruisbron zichzelf op de een of andere manier authenticeren bij een bibliotheek of gebruikersruimtetoepassing."
Er was enige discussie over hoe een dergelijke interface eruit zou kunnen zien, omdat er bijvoorbeeld beveiligingsimplicaties kunnen zijn voor sommige evenementen. Cao merkte op dat toetsenbordscancodes (dat wil zeggen toetsaanslagen) in een pool worden gemengd als onderdeel van de entropieverzameling: "Dit in de gebruikersruimte brengen, zelfs via een geprivilegieerde systeemoproep, zou op zijn zachtst gezegd onverstandig zijn." Het is heel goed mogelijk dat andere gebeurtenistimings een soort informatielek via zijkanalen veroorzaken.
Het lijkt er dus op dat een al lang bestaand probleem met het Linux-subsysteem met willekeurige getallen op weg is naar een oplossing. De veranderingen die het willekeurige nummer-subsysteem onlangs heeft ondergaan, hebben feitelijk alleen maar tot DoS-problemen geleid bij het gebruik ervan. Nu zijn er efficiënte manieren om de beste willekeurige getallen te krijgen die de kernel kan bieden. Als TRNG nog steeds wenselijk is op Linux, dan zal deze fout in de toekomst moeten worden aangepakt, maar dit zal hoogstwaarschijnlijk niet binnen de kernel zelf gebeuren.
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com