Zoals bekend heeft /dev/random, een cryptografisch veilige pseudo-random generator (CSPRNG), één vervelende kwestie: blokkades. Dit artikel legt uit hoe deze kan worden opgelost.
In de afgelopen maanden zijn de middelen voor het genereren van willekeurige getallen in de kernel een beetje herzien, maar problemen in dit subsysteem zijn al langer aan de orde. . De meest werden gemaakt om langdurige blokkades van de systeemaanroep getrandom() bij het opstarten van het systeem te voorkomen, maar de onderliggende oorzaak was het gedrag van de blockerende willekeurige pool. Een recente patch zou deze pool verwijderen en het was te verwachten dat deze naar de hoofdkernel zou gaan.
Andy Lutomirski publiceerde eind december de derde versie van de patch. Hij brengt "twee belangrijke semantische wijzigingen in de willekeurige API's van Linux". De patch voegt een nieuwe vlag GRND_INSECURE toe aan de systeemaanroep getrandom() (hoewel Lutomirski deze aanroept als getentropy(), die in glibc wordt geïmplementeerd met getrandom() en vaste vlaggen); deze vlag zorgt ervoor dat de aanroep altijd het gevraagde aantal gegevens retourneert, maar zonder garantie dat deze gegevens willekeurig zijn. De kernel zal gewoon zijn best doen om de beste willekeurige gegevens te geven die hij op dat moment heeft. "Waarschijnlijk is het beste wat we kunnen doen om het 'INSECURE' te noemen, (onveilig), om gebruik van deze API voor zaken die beveiliging vereisen te voorkomen."
De patches verwijderen ook de blockerende pool. Momenteel ondersteunt de kernel twee pools van willekeurige gegevens, waarvan de ene overeenkomt met /dev/random en de andere met /dev/urandom, zoals beschreven in deze 2015 document. De blockerende pool is de pool voor /dev/random; lezen van dit apparaat zal worden geblokkeerd (wat is bedoeld met zijn naam) totdat er voldoende "entropie" uit het systeem is verzameld om aan het verzoek te voldoen. Verdere leesoperaties van dit bestand worden ook geblokkeerd als er niet genoeg entropie in de pool is.
Het verwijderen van de blokkering pool betekent dat lezen van /dev/random zich gedraagt als getrandom() met vlaggen gelijk aan nul (en zet de vlag GRND_RANDOM om naar noop). Na de initialisatie van de cryptografische willekeurige getallengenerator (CRNG), zal lezen van /dev/random en aanroepen van getrandom(…,0) niet blokkeren en het aangevraagde aantal willekeurige gegevens retourneren.
Lutomirski zegt: „Ik geloof dat de blokkering pool van Linux zijn nut heeft verloren. CRNG van Linux genereert uitvoer die goed genoeg is om zelfs te gebruiken voor het genereren van sleutels. De blokkering pool is op geen enkele manier sterker, en om deze in stand te houden is veel twijfelachtige infrastructuur nodig.“
Er zijn wijzigingen aangebracht met het oog op het feit dat bestaande programma's er echt niet onder hoeven te lijden, en feitelijk zullen er minder problemen zijn met lange wachttijden voor zaken als het genereren van GnuPG-sleutels.
„Deze series zouden geen bestaande programma's moeten verstoren. /dev/urandom blijft onveranderd. /dev/random blijft nog steeds blokkeren direct na het opstarten, maar wordt minder geblokkeerd dan eerder. getentropy() met de bestaande vlaggen zal een resultaat teruggeven dat even geschikt is voor praktische doeleinden als voorheen.“
Lutomirski merkte op dat de vraag nog steeds openstaat of de kernel zogenaamde „echte willekeurige getallen“ moet bieden, wat tot op zekere hoogte de taak was van de blokkering kernel. Hij ziet hiervoor slechts één reden: „naleving van overheidsnormen“. Lutomirski suggereerde dat als de kernel dit moet leveren, dit moet gebeuren via een geheel andere interface of moet worden verplaatst naar de gebruikersruimte, zodat deze ruwe gebeurtenismonsters kan extraheren die kunnen worden gebruikt voor het creëren van zo'n blokkering pool.
Stephan Müller suggereerde dat zijn set De Linux random number generator (LRNG) (momenteel in versie 26) kan een manier zijn om echte willekeurige getallen te bieden voor toepassingen die dit nodig hebben. LRNG "voldoet volledig aan de vereisten van de 'Aanbevelingen voor entropiebronnen die worden gebruikt voor het genereren van willekeurige bits' SP800-90B", wat het een oplossing maakt voor het probleem van overheidsnormen.
Matthew Garrett heeft bezwaar gemaakt tegen de term "echte willekeurige gegevens", waarbij hij opmerkt dat de gekozen apparaten in principe voldoende nauwkeurig kunnen worden nagebootst om voorspelbaar te maken: "wij selecteren hier geen kwantumevenementen".
Mueller antwoordde dat deze term afkomstig is van de Duitse standaard AIS 31 voor het beschrijven van een willekeurige getallengenerator die alleen resultaten produceert "met dezelfde snelheid als de basisgeluidsbron entropie produceert".
Afgezien van terminologische onduidelijkheden, zal het hebben van een lock pool, zoals voorgesteld door de LRNG-patches, gewoon leiden tot verschillende problemen, althans als deze toegankelijk is zonder privileges.
Zoals Lutomirski zei: "Dit lost het probleem niet op. Als twee verschillende gebruikers domme programma's zoals gnupg draaien, 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, kwaadaardige invloed of iets dergelijks), en omdat er geen privileges vereist zijn voor het gebruik ervan, is het ook vatbaar voor misbruik. Gnupg is verkeerd, het is een totale mislukking. Als we een nieuwe niet-privilegieerde interface toevoegen die door gnupg en soortgelijke programma's wordt gebruikt, verliezen we opnieuw."
Mueller merkte op dat de toevoeging van getrandom() nu GnuPG in staat zal stellen deze interface te gebruiken, aangezien het de nodige garantie biedt dat de pool is geïnitialiseerd. Op basis van gesprekken met GnuPG-ontwikkelaar Werner Koch, gelooft Mueller dat de garantie de enige reden is waarom GnuPG momenteel rechtstreeks uit /dev/random leest. Maar als er een niet-privilegieerde interface is die vatbaar is voor dienstweigering (zoals tegenwoordig /dev/random), dan zal deze volgens Lutomirski verkeerd worden gebruikt door sommige applicaties.
Theodore Yue Tak Ts’o, de ontwikkelaar van de Linux-random number subsystem, lijkt zijn mening te hebben gewijzigd over de noodzaak van een blocking pool. Hij zei dat het verwijderen van deze pool een effectieve manier is om het idee te ontkrachten dat Linux een echte true random number generator (TRNG) heeft. "Het is geen onzin, want dat is precies wat *BSD altijd heeft gedaan."
Hij is ook bezorgd dat het aanbieden van een TRNG-mechanisme slechts een lokmiddel voor applicatieontwikkelaars zal zijn en meent dat het in werkelijkheid onmogelijk is om, gezien de verschillende soorten hardware die door Linux worden ondersteund, een TRNG in de kernel te garanderen. Het probleem zal niet worden opgelost door alleen op hardware met root-rechten te werken. "Applicatieontwikkelaars geven aan dat hun toepassing om veiligheidsredenen als root moet worden geïnstalleerd, omdat je alleen dan toegang hebt tot 'echt goede' willekeurige getallen."
Müller vroeg of Ts’o geen afstand had genomen van de implementatie van de blocking pool, die hijzelf al enige tijd had voorgesteld. Ts’o antwoordde dat hij van plan is de patches van Lutomirsky over te nemen en zich actief verzet tegen het opnieuw toevoegen van de blocking interface aan de kernel.
"De kernel kan geen garanties geven over het correct karakteriseren van de noise source. Het enige wat de ontwikkelaar van GPG of OpenSSL kan krijgen, is een vaag gevoel dat TRUERANDOM 'beter' is, en omdat ze meer veiligheid willen, zullen ze het zeker proberen te gebruiken. Op een bepaald moment zal het vastlopen, en wanneer een andere slimme gebruiker (misschien een release-specialist) het in een init-script plaatst, zal het systeem stoppen met werken, en gebruikers blijven met slechts klachten aan Linus Torvalds."
Ts’o pleit ook voor het bieden van een manier voor cryptografen en degenen die echt een TRNG nodig hebben om hun eigen entropie in de gebruikersruimte te verzamelen, zodat ze deze naar eigen inzicht kunnen gebruiken. Hij zegt dat het verzamelen van entropie geen proces is dat door de kernel kan worden uitgevoerd op allerlei ondersteunde hardware, bovendien kan de kernel zelf de hoeveelheid entropie die door verschillende bronnen wordt geleverd niet beoordelen.
«De kernel mag verschillende noise sources niet met elkaar mengen, en het mag uiteraard niet proberen te beweren dat het weet hoeveel bits aan entropie het krijgt wanneer het probeert te spelen met een of andere 'schokkerige entropiespel' op een belachelijk simpele CPU-architectuur voor IoT/embedded-use cases, wanneer alles gedesynchroniseerd is met één enkele master generator, als er geen CPU-instructie is voor het herordenen of hernoemen van registers, enzovoort.»
«Je kunt het hebben over het bieden van tools die proberen deze berekeningen te doen, maar zulke zaken moeten op de hardware van elke gebruiker plaatsvinden, wat voor de meeste gebruikers van de distributie gewoon onpraktisch is. Als dit echter alleen bedoeld is voor cryptografen, laat het dan in hun gebruikersruimte gebeuren. En laten we GPG, OpenSSL, enzovoort niet vereenvoudigen zodat iedereen zegt: 'we willen 'ware willekeur' en zijn met minder niet tevreden'. We kunnen praten over hoe we interfaces aan cryptografen aanbieden, zodat ze de benodigde informatie kunnen verkrijgen door toegang tot primaire noise sources, die gescheiden en benoemd zijn, en misschien kan een of andere noise source zichzelf authenticeren in de bibliotheek of de applicatie van de gebruikersruimte.»
Er vond een kleine discussie plaats over hoe zo'n interface eruit zou kunnen zien, aangezien sommige evenementen veiligheidsimplicaties kunnen hebben. Cao merkte op dat toetsenbordscan codes (d.w.z. toetsaanslagen) worden gemengd in een pool als onderdeel van het verzamelen van entropie: 'Het verplaatsen hiervan naar de gebruikersruimte, zelfs via een bevoorrechte systeemaanroep, zou op zijn minst onverstandig zijn.' Het is heel goed mogelijk dat ook andere timing evenementen enige informatielekken via zijkanalen kunnen creëren.
Er ontstaat dus de indruk dat het langdurige probleem van de Linux-randomnumber-subsystemen op het punt staat opgelost te worden. De recente wijzigingen aan het randomnumber-subsystem hebben feitelijk alleen geleid tot DoS-problemen tijdens het gebruik ervan. Nu zijn er echter effectieve manieren om de beste willekeurige getallen te verkrijgen die de kernel kan bieden. Als TRNG nog steeds gewenst is voor Linux, moet deze tekortkoming in de toekomst worden aangepakt, maar het is waarschijnlijk dat dit niet binnen de kernel zelf zal gebeuren.
Een beetje reclame 🙂
Bedankt dat je bij ons blijft. Houd je van onze artikelen? Wil je meer interessante inhoud zien? Ondersteun ons door een bestelling te plaatsen of ons aan vrienden aan te bevelen, , een unieke variant van entry-level servers, die we voor jou hebben bedacht: (opties beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd is 2 keer goedkoper in datacenter Equinix Tier IV in Amsterdam? Alleen bij ons in Nederland! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — vanaf $99! Lees over hoe
Bron: habr.com
