/dev/random

256 byte hex dump av /dev/urandom

I Unix-liknande operativsystem är /dev/random och /dev/urandom specialfiler som fungerar som kryptografiskt säkra pseudoslumptalsgeneratorer . De ger tillgång till omgivningsljud som samlas in från drivrutiner och andra källor. /dev/random blockeras vanligtvis om det fanns mindre entropi tillgänglig än begärt; på senare tid (se nedan, olika operativsystem skiljer sig åt) blockeras det vanligtvis vid start tills tillräcklig entropi har samlats in, och blockeras sedan permanent. /dev/urandom- enheten var vanligtvis aldrig en blockeringsenhet, även om fröet för pseudoslumptalsgeneratorn inte var helt initierat med entropi sedan start. Alla operativsystem implementerar inte samma metoder för /dev/random och /dev/urandom .

Linux

Rngtest testing /dev/random pool

Generering av slumptal i kärnutrymmet implementerades för första gången för Linux 1994 av Theodore Ts'o . Implementeringen använde säkra hash snarare än chiffer , [ förtydligande behövs ] för att undvika exportrestriktioner för kryptografi som fanns när generatorn ursprungligen designades. Implementeringen utformades också med antagandet att varje given hash eller chiffer så småningom kan upptäckas vara svag, och därför är designen hållbar inför sådana svagheter. Snabb återhämtning från poolkompromiss anses inte vara ett krav, eftersom kraven för poolkompromiss är tillräckliga för mycket enklare och mer direkta attacker på orelaterade delar av operativsystemet.

I Ts'os implementering håller generatorn en uppskattning av antalet bitar av brus i entropipoolen . Från denna entropipool skapas slumptal. Vid läsning /dev/random -enheten endast slumpmässiga bytes inom det uppskattade antalet bitar av brus i entropipoolen. När entropipoolen är tom kommer läsningar från /dev/random att blockeras tills ytterligare miljöbrus samlas in. Avsikten är att fungera som en kryptografiskt säker pseudoslumptalsgenerator, som levererar utdata med så stor entropi som möjligt. Detta föreslås av författarna för användning vid generering av kryptografiska nycklar för högt värde eller långsiktigt skydd.

En motsvarighet till /dev/random är /dev/urandom ("obegränsad"/icke-blockerande slumpmässig källa) som återanvänder den interna poolen för att producera fler pseudo-slumpmässiga bitar. Detta innebär att anropet inte kommer att blockeras, men utdata kan innehålla mindre entropi än motsvarande läsning från /dev/random . Även om /dev/urandom fortfarande är avsedd som en pseudoslumptalsgenerator som lämpar sig för de flesta kryptografiska ändamål, noterar författarna till motsvarande man-sida att det teoretiskt sett kan finnas en ännu opublicerad attack på algoritmen som används av /dev/urandom , och att användare som är oroade över en sådan attack bör använda /dev/random istället. Det är dock osannolikt att en sådan attack kommer till stånd, för när entropipoolen är oförutsägbar läcker den inte säkerhet med ett minskat antal bitar.

Det är också möjligt att skriva till /dev/random . Detta gör att alla användare kan blanda slumpmässiga data i poolen. Icke-slumpmässiga data är ofarliga, eftersom endast en privilegierad användare kan utfärda den ioctl som behövs för att öka entropiuppskattningen. [ tvivelaktigt – diskutera ] Den aktuella mängden entropi och storleken på Linux-kärnantropipoolen, båda mätt i bitar, är tillgängliga i /proc/sys/kernel/random/ och kan visas med kommandot cat /proc/sys/ kernel/random/entropy_avail respektive cat /proc/sys/kernel/random/poolsize .

Gutterman, Pinkas och Reinman publicerade i mars 2006 en detaljerad kryptografisk analys av Linuxs slumptalsgenerator där de beskriver flera svagheter. Det kanske allvarligaste problemet de rapporterar är med inbäddade eller live-cd- system, såsom routrar och disklösa klienter , för vilka starttillståndet är förutsägbart och det tillgängliga utbudet av entropi från miljön kan vara begränsat. För ett system med icke-flyktigt minne rekommenderar de att spara något tillstånd från RNG vid avstängning så att det kan inkluderas i RNG-tillståndet vid nästa omstart. När det gäller en router för vilken nätverkstrafik representerar den primära tillgängliga källan till entropi, noterar de att lagring av tillstånd över omstarter "skulle kräva att potentiella angripare antingen avlyssnar all nätverkstrafik" från det att routern först tas i bruk, eller skaffar direkt tillgång till routerns interna tillstånd. Detta problem, noterar de, är särskilt kritiskt i fallet med en trådlös router vars nätverkstrafik kan fångas på avstånd, och som kan använda RNG för att generera nycklar för datakryptering.

Linux-kärnan ger stöd för flera slumptalsgeneratorer för hårdvara, om de skulle installeras. Den råa utdata från en sådan enhet kan erhållas från /dev/hwrng .

Med Linux-kärna 3.16 och nyare blandar själva kärnan data från hårdvarugeneratorer för slumptal till /dev/random på en glidande skala baserat på den definierbara entropiuppskattningskvaliteten för HWRNG. Det betyder att ingen användarrymdsdemon, såsom rngd från rng-tools , behövs för att göra det jobbet. Med Linux-kärnan 3.17+ modifierades VirtIO RNG för att ha en standardkvalitet definierad över 0, och som sådan är den för närvarande den enda HWRNG som är inblandad i / dev/random som standard.

Entropipoolen kan förbättras med program som timer_entropyd , haveged , randomsound etc. Med rng-tools kan slumptalsgeneratorer för hårdvara som Entropy Key, etc. skriva till /dev/random . Diehard - testprogrammen dieharder , diehard och ent kan testa dessa slumptalsgeneratorer.

I januari 2014 publicerade Daniel J. Bernstein en kritik av hur Linux blandar olika källor till entropi. Han skisserar en attack där en entropikälla som kan övervaka de andra entropikällorna skulle kunna modifiera dess utdata för att omintetgöra slumpmässigheten hos de andra entropikällorna. Betrakta funktionen där H är en hashfunktion och x , y och z är källor till entropi där z är utdata från en CPU-baserad skadlig HRNG Z:

  1. Z genererar ett slumpmässigt värde på r .
  2. Z beräknar .
  3. Om utmatningen av är lika med det önskade värdet, utmatas r som z .
  4. Annars, upprepa från 1.

Bernstein uppskattade att en angripare skulle behöva upprepa 16 gånger för att äventyra DSA och ECDSA. Detta är möjligt eftersom Linux återseed H på en kontinuerlig basis istället för att använda ett enda högkvalitativt frö.

I oktober 2016, med lanseringen av Linux-kärnan version 4.8, byttes kärnans /dev/urandom över till en ChaCha20 -baserad kryptografisk pseudorandom number generator (CPRNG) implementering av Theodore Ts'o , baserad på Bernsteins välkända ström chiffer ChaCha20 .

År 2020 blockerar Linux-kärnan version 5.6 /dev/random endast när CPRNG inte har initierats. När de har initierats /dev/random och /dev/urandom på samma sätt.

BSD-system

Operativsystemet FreeBSD tillhandahåller en /dev/urandom -länk till /dev/random . Båda blockerar endast tills de är ordentligt sådda. FreeBSD:s PRNG ( Fortuna ) återsås regelbundet och försöker inte uppskatta entropi. På ett system med liten mängd nätverks- och diskaktivitet görs omseedning efter en bråkdel av en sekund.

Sedan OpenBSD 5.1 (1 maj 2012) har /dev/random och /dev/arandom använt en algoritm baserad på RC4 men bytt namn till ARC4 på grund av immateriella skäl. Medan generering av slumptal här använder systementropi som samlats in på flera sätt, tillhandahåller ARC4-algoritmen en felsäker, vilket säkerställer att en snabb och högkvalitativ pseudoslumptalsström tillhandahålls även när poolen är i ett lågt entropitillstånd. Systemet använder automatiskt slumptalsgeneratorer för hårdvara (som de som finns på vissa Intel PCI-hubbar) om de är tillgängliga, genom OpenBSD Cryptographic Framework . Från och med OpenBSD 5.5 (1 maj 2014) arc4random() -anropet som används för OpenBSD:s slumpmässiga enheter inte längre ARC4, men ChaCha20 ( arc4random name kan omprövas som A Replacement Call for Random ). /dev/arandom togs bort i OpenBSD 6.3 (15 april 2018).

NetBSD :s implementering av det äldre API: et arc4random() har också bytts över till ChaCha20.

macOS, iOS och andra Apple OS

Alla Apple OS har flyttat till Fortuna sedan åtminstone december 2019, möjligen tidigare. Den är baserad på SHA-256 . Flera entropikällor såsom den säkra enklaven RNG, startfas timing jitter, hårdvaruavbrott (timing antas) används. RDSEED/RDRAND används på Intel-baserade Mac-datorer som stöder det. Frödata (entropi) lagras också för efterföljande omstarter.

Före ändringen använde macOS och iOS 160-bitars Yarrow baserat på SHA-1 .

Det finns ingen skillnad mellan /dev/random och /dev/urandom ; båda beter sig identiskt.

Andra operativsystem

/dev/random och /dev/urandom är också tillgängliga på Solaris, NetBSD, Tru64 UNIX 5.1B, AIX 5.2 och HP-UX 11i v2. Precis som med FreeBSD implementerar AIX sin egen Yarrow-baserade design, men AIX använder betydligt färre entropikällor än standardimplementeringen /dev/random och slutar fylla på poolen när den tror att den innehåller tillräckligt med entropi.

I Windows NT levereras liknande funktionalitet av ksecdd.sys , men att läsa specialfilen \Device\KsecDD fungerar inte som i UNIX. De dokumenterade metoderna för att generera kryptografiskt slumpmässiga bytes är CryptGenRandom och RtlGenRandom . Windows PowerShell ger tillgång till en kryptografiskt säker pseudoslumptalsgenerator via Get-Random- cmdleten.

Cygwin på Windows tillhandahåller implementeringar av både /dev/random och /dev/urandom , som kan användas i skript och program.

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=/dev/random&oldid=1133315917 "