/dev/random, en kryptografiskt säker pseudo-slumptalsgenerator (CSPRNG), är känd för att ha ett irriterande problem: blockering. Den här artikeln förklarar hur du kan lösa det.
Under de senaste månaderna har slumptalsgenereringsfaciliteterna i kärnan omarbetats något, men problem i detta delsystem har lösts under loppet av det bredare . Mest gjordes för att förhindra att getrandom()-systemanropet blockeras under en lång tid när systemet startar, men den bakomliggande orsaken till detta var slumppoolens blockeringsbeteende. En ny patch skulle ha tagit bort den här poolen och den skulle ha förväntats gå mot huvudkärnan.
Andy Lutomirski publicerade den tredje versionen av patchen i slutet av december. Han bidrar "två stora semantiska förändringar av slumpmässiga Linux API:er". Patchen lägger till en ny GRND_INSECURE-flagga till systemanropet getrandom() (även om Lutomirsky hänvisar till det som getentropy(), som implementeras i glibc med hjälp av getrandom() med fasta flaggor); denna flagga gör att samtalet alltid returnerar den begärda mängden data, men utan att garantera att datan är slumpmässig. Kärnan kommer helt enkelt att göra sitt bästa för att producera den bästa slumpmässiga data den har vid den givna tidpunkten. "Det bästa man kan göra är att kalla det 'OSÄKER' (osäkert) för att förhindra att detta API används för saker som behöver säkerhet."
Plåstren tar också bort den blockerande poolen. Kärnan upprätthåller för närvarande två slumpmässiga datapooler, en som motsvarar /dev/random och den andra till /dev/urandom, som beskrivs i detta 2015. Den blockerande poolen är poolen för /dev/random; läser för den enheten kommer att blockeras (vilket betyder dess namn) tills "tillräckligt" entropi har samlats in från systemet för att tillfredsställa begäran. Ytterligare läsningar från denna fil blockeras också om det inte finns tillräckligt med entropi i poolen.
Att ta bort låspoolen innebär att läsning från /dev/random beter sig som getrandom() med flaggor inställda på noll (och förvandlar GRND_RANDOM-flaggan till en noop). När den kryptografiska slumptalsgeneratorn (CRNG) har initierats kommer läsning från /dev/random och anrop till getrandom(...,0) inte att blockera och returnera den begärda mängden slumpmässig data.
Lutomirsky säger: "Jag tror att Linux-blockeringspoolen har blivit föråldrad. CRNG Linux genererar utdata som är tillräckligt bra för att till och med användas för nyckelgenerering. Blockeringspoolen är inte starkare i någon materiell mening och kräver mycket infrastruktur av tvivelaktigt värde för att stödja den.”
Ändringarna gjordes med målet att säkerställa att befintliga program inte verkligen skulle påverkas, och i själva verket skulle det bli färre problem med långa väntetider för saker som GnuPG-nyckelgenerering.
”Dessa avsnitt får inte störa några befintliga program. /dev/urandom förblir oförändrad. /dev/random blockerar fortfarande omedelbart vid start, men det blockerar mindre än tidigare. getentropy() med de befintliga flaggorna kommer att returnera ett resultat som är lika lämpligt för praktiska ändamål som tidigare."
Lutomirsky noterade att det fortfarande är en öppen fråga om kärnan ska tillhandahålla så kallade "santa slumptal", vilket är vad den blockerande kärnan var tänkt att göra i viss utsträckning. Han ser bara en anledning till detta: "efterlevnad av statliga standarder." Lutomirsky föreslog att om kärnan skulle tillhandahålla detta, skulle det göras genom ett helt annat gränssnitt, eller så skulle det flyttas till användarutrymmet, så att användaren kan hämta råa händelseprover som kan användas för att skapa en sådan låspool.
Stephan Müller föreslog att hans uppsättning för Linux Random Number Generator (LRNG) (för närvarande version 26 släppt) kan vara ett sätt att tillhandahålla sanna slumptal för applikationer som behöver det. LRNG är "fullständigt kompatibel med SP800-90B riktlinjer för entropikällor som används för att generera slumpmässiga bitar", vilket gör det till en lösning på problemet med regeringens standarder.
Matthew Garrett protesterade mot termen "äkta slumpmässiga data", och noterade att enheterna som samplades i princip kunde modelleras tillräckligt exakt för att göra dem förutsägbara: "vi tar inte prov på kvanthändelser här."
Müller svarade att termen kommer från den tyska standarden AIS 31 för att beskriva en slumptalsgenerator som bara producerar ett resultat "i samma takt som den underliggande bruskällan producerar entropi."
Terminologiskillnader bortsett från, att ha en låspool som föreslås av LRNG-patcharna kommer helt enkelt att leda till olika problem, åtminstone om den nås utan privilegier.
Som Lutomirsky sa: "Det här löser inte problemet. Om två olika användare kör dumma program som gnupg kommer de bara att tömma varandra. Jag ser att det för närvarande finns två huvudproblem med /dev/random: det är benäget att göra DoS (d.v.s. resursutarmning, skadlig påverkan eller något liknande), och eftersom det inte krävs några privilegier för att använda det, är det också benäget att missbrukas. Gnupg har fel, det är en total kollaps. Om vi lägger till ett nytt oprivilegierat gränssnitt som gnupg och liknande program kommer att använda kommer vi att förlora igen."
Mueller noterade att tillägget av getrandom() nu kommer att tillåta GnuPG att använda detta gränssnitt, eftersom det kommer att ge den nödvändiga garantin att poolen har initierats. Baserat på diskussioner med GnuPG-utvecklaren Werner Koch, tror Mueller att garantin är den enda anledningen till att GnuPG för närvarande läser direkt från /dev/random. Men om det finns ett oprivilegierat gränssnitt som är mottagligt för denial of service (som /dev/random är idag), hävdar Lutomirsky att det kommer att missbrukas av vissa applikationer.
Theodore Yue Tak Ts'o, utvecklare av Linuxs slumptalsundersystem, verkar ha ändrat uppfattning om behovet av en blockerande pool. Han sa att att ta bort denna pool effektivt skulle bli av med tanken att Linux har en sann slumptalsgenerator (TRNG): "det här är inget nonsens, eftersom det är precis vad *BSD alltid har gjort."
Han är också oroad över att tillhandahållandet av en TRNG-mekanism helt enkelt kommer att fungera som ett lockbete för applikationsutvecklare och tror att det faktiskt, med tanke på de olika typerna av hårdvara som stöds av Linux, är omöjligt att garantera TRNG i kärnan. Även möjligheten att arbeta med utrustning endast med root-privilegier kommer inte att lösa problemet: "Applikationsutvecklare anger att deras applikation ska installeras som root av säkerhetsskäl, så att det är det enda sättet du kan komma åt de 'riktigt bra' slumptalen."
Mueller frågade om Cao hade övergett implementeringen av blockeringspoolen som han själv länge föreslagit. Cao svarade att han planerar att ta Lutomirskys patchar och motsätter sig aktivt att lägga till ett blockerande gränssnitt tillbaka till kärnan.
"Kärnan kan inte ge några garantier för huruvida bruskällan har karakteriserats korrekt. Det enda en GPG- eller OpenSSL-utvecklare kan få är en vag känsla av att TRUERANDOM är "bättre", och eftersom de vill ha mer säkerhet kommer de utan tvekan att försöka använda det. Vid något tillfälle kommer det att blockeras, och när någon annan smart användare (kanske en distributionsspecialist) infogar det i init-skriptet och systemen slutar fungera, behöver användarna bara klaga till Linus Torvalds själv."
Cao förespråkar också att ge kryptografer och de som faktiskt behöver TRNG ett sätt att skörda sin egen entropi i användarutrymmet att använda som de vill. Han säger att insamling av entropi inte är en process som kan utföras av kärnan på alla olika hårdvaror som den stöder, och inte heller kan kärnan själv uppskatta mängden entropi som tillhandahålls av olika källor.
"Kärnan ska inte blanda olika bruskällor tillsammans, och den ska absolut inte försöka påstå sig veta hur många bitar av entropi den får när den försöker spela något slags "twitchy entropy game" på en skandalöst enkel CPU arkitektur för konsumentanvändare. IOT/Embedded fall där allt inte är synkroniserat med en enda huvudoscillator, där det inte finns någon CPU-instruktion för att ordna om eller byta namn på ett register, etc."
”Man kan prata om att tillhandahålla verktyg som försöker göra de här beräkningarna, men sådana saker måste göras på varje användares hårdvara, vilket helt enkelt inte är praktiskt för de flesta distributionsanvändare. Om detta endast är avsett för kryptografer, låt det göras i deras användarutrymme. Och låt oss inte förenkla GPG, OpenSSL, etc. så att alla säger "vi vill ha "true randomness" och inte nöjer oss med mindre." Vi kan prata om hur vi tillhandahåller gränssnitt till kryptografer så att de kan få den information de behöver genom att komma åt de primära bruskällorna, separerade och namngivna, och kanske på något sätt kan bruskällan autentisera sig till ett bibliotek eller en användarrymdapplikation."
Det diskuterades en del om hur ett sådant gränssnitt skulle kunna se ut, eftersom det till exempel kan vara säkerhetskonsekvenser för vissa händelser. Cao noterade att tangentbordsskanningskoder (d.v.s. tangenttryckningar) blandas in i en pool som en del av entropiinsamlingen: "Att ta med detta till användarutrymmet, även genom ett privilegierat systemsamtal, vore minst sagt oklokt." Det är mycket möjligt att andra händelsetider kan skapa någon form av informationsläckage genom sidokanaler.
Så det ser ut som att ett långvarigt problem med Linuxs slumptalsundersystem är på väg mot en lösning. De förändringar som slumptalsundersystemet har genomgått nyligen har faktiskt bara resulterat i DoS-problem när det används. Nu finns det effektiva sätt att få de bästa slumptal som kärnan kan ge. Om TRNG fortfarande är önskvärt på Linux, kommer detta fel att behöva åtgärdas i framtiden, men troligen kommer detta inte att göras inom själva kärnan.
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com