A /dev/random, egy kriptográfiailag biztonságos pszeudo-véletlenszám-generátor (CSPRNG), ismert, hogy van egy bosszantó problémája: a blokkolás. Ez a cikk elmagyarázza, hogyan oldhatja meg.
Az elmúlt néhány hónapban a kernel véletlenszám-generáló szolgáltatásait némileg átdolgozták, de az alrendszer problémái a szélesebb kör során megoldódtak. . A legtöbb azért készültek, hogy megakadályozzák a getrandom() rendszerhívás hosszú ideig történő blokkolását a rendszer indításakor, de ennek oka a véletlenszerű készlet blokkoló viselkedése volt. Egy nemrégiben készült javítás eltávolította volna ezt a készletet, és várhatóan a fő mag felé halad.
Andy Lutomirski december végén publikálta a javítás harmadik verzióját. Hozzájárul "két jelentős szemantikai változás a véletlenszerű Linux API-kban". A javítás egy új GRND_INSECURE jelzőt ad a getrandom() rendszerhíváshoz (bár Lutomirsky getentropy() néven hivatkozik rá, ami a glibc-ben a getrandom() segítségével van megvalósítva rögzített jelzőkkel); ez a jelző azt eredményezi, hogy a hívás mindig a kért adatmennyiséget adja vissza, de nem garantálja, hogy az adatok véletlenszerűek. A kernel egyszerűen mindent megtesz, hogy az adott időpontban a legjobb véletlenszerű adatokat állítsa elő. „Talán a legjobb, ha „BIZTONSÁGOS”-nak hívjuk. (nem biztonságos), hogy megakadályozza, hogy ezt az API-t olyan dolgokra használják, amelyek biztonságot igényelnek."
A tapaszok a blokkolómedencét is eltávolítják. A kernel jelenleg két véletlenszerű adatkészletet tart fenn, az egyik a /dev/random, a másik a /dev/urandom állománynak felel meg, amint azt ebben a cikkben leírtuk. 2015. A blokkolókészlet a /dev/random; Az adott eszköz beolvasása blokkolni fogja (értsd a nevét) mindaddig, amíg "elég" entrópiát nem gyűjt a rendszer a kérés teljesítéséhez. A fájl további olvasása is blokkolva van, ha nincs elegendő entrópia a készletben.
A zárolt készlet eltávolítása azt jelenti, hogy a /dev/random olvasása a getrandom()-hoz hasonlóan viselkedik, ha a jelzők nullára vannak állítva (és a GRND_RANDOM jelzőt noopmá változtatja). A kriptográfiai véletlenszám-generátor (CRNG) inicializálása után a /dev/random olvasása és a getrandom(...,0) hívásai nem blokkolják, és visszaadják a kért mennyiségű véletlenszerű adatot.
Lutomirsky mondja: „Úgy gondolom, hogy a Linux blokkolókészlet elavulttá vált. A CRNG Linux olyan kimenetet hoz létre, amely elég jó ahhoz, hogy akár kulcsgenerálásra is használható legyen. A blokkoló medence semmilyen anyagi értelemben nem erősebb, és sok kétes értékű infrastruktúrára van szükség a támogatásához.”
A változtatásokat azzal a céllal hajtották végre, hogy biztosítsák, hogy a meglévő programok valóban ne legyenek érintettek, sőt, kevesebb probléma legyen a hosszú várakozással olyan dolgokra, mint például a GnuPG kulcsgenerálása.
„Ezek az epizódok nem zavarhatnak meg egyetlen meglévő programot sem. A /dev/urandom változatlan marad. A /dev/random továbbra is azonnal blokkolja a rendszerindítást, de kevesebbet blokkol, mint korábban. A getentropy() a meglévő zászlókkal olyan eredményt ad vissza, amely ugyanolyan alkalmas gyakorlati célokra, mint korábban."
Lutomirsky megjegyezte, hogy továbbra is nyitott kérdés, hogy a kernelnek biztosítania kell-e az úgynevezett „igazi véletlenszámokat”, amit a blokkoló kernelnek bizonyos mértékig meg kellett volna tennie. Ennek egyetlen okát látja: „a kormányzati normáknak való megfelelést”. Lutomirsky azt javasolta, hogy ha a kernel ezt biztosítaná, akkor azt egy teljesen más interfészen keresztül kell megtenni, vagy át kell helyezni a felhasználói térbe, lehetővé téve a felhasználó számára, hogy nyers eseménymintákat tudjon lekérni, amelyek segítségével létrehozhat egy ilyen zárolási készletet.
Stephan Müller javasolta, hogy a készletét A Linux Random Number Generator (LRNG) (jelenleg 26-os verziója) egy módja annak, hogy valódi véletlen számokat adjon meg az arra igénylő alkalmazások számára. Az LRNG „teljes mértékben megfelel az SP800-90B irányelveknek a véletlen bitek generálására használt entrópiaforrásokról”, így megoldást jelent a kormányzati szabványok problémájára.
Matthew Garrett kifogásolta a „valódi véletlenszerű adatok” kifejezést, és megjegyezte, hogy a mintavételezett eszközök elvileg elég pontosan modellezhetők ahhoz, hogy kiszámíthatóak legyenek: „itt nem kvantumeseményekből veszünk mintát”.
Müller azt válaszolta, hogy a kifejezés az AIS 31 német szabványból származik, és olyan véletlenszám-generátort ír le, amely csak "ugyanolyan sebességgel ad eredményt, ahogyan a mögöttes zajforrás entrópiát termel".
A terminológiai különbségektől eltekintve az LRNG javítások által javasolt zárolási készlet egyszerűen különféle problémákhoz vezet, legalábbis ha jogosultságok nélkül fér hozzá.
Ahogy Lutomirsky mondta: „Ez nem oldja meg a problémát. Ha két különböző felhasználó olyan hülye programokat futtat, mint a gnupg, csak kimerítik egymást. Úgy látom, hogy jelenleg két fő probléma van a /dev/random-mal: hajlamos a DoS-re (azaz erőforrás-kimerülésre, rosszindulatú befolyásra vagy valami hasonlóra), és mivel a használatához nem kell semmilyen jogosultság, így visszaélésre is hajlamos. Gnupg téved, teljes összeomlás. Ha hozzáadunk egy új, privilegizált felületet, amelyet a gnupg és hasonló programok fognak használni, ismét elveszítjük."
Mueller megjegyezte, hogy a getrandom() hozzáadása lehetővé teszi a GnuPG számára ennek a felületnek a használatát, mivel ez biztosítja a szükséges garanciát arra, hogy a készlet inicializálva van. A GnuPG fejlesztőjével, Werner Koch-al folytatott megbeszélések alapján Mueller úgy véli, hogy a garancia az egyetlen oka annak, hogy a GnuPG jelenleg közvetlenül a /dev/random fájlból olvas. De ha van egy privilegizált interfész, amely érzékeny a szolgáltatásmegtagadásra (ahogyan ma a /dev/random), Lutomirsky azzal érvel, hogy egyes alkalmazások visszaélnek vele.
Theodore Yue Tak Ts'o, a Linux véletlenszám-alrendszerének fejlesztője úgy tűnik, meggondolta magát a blokkolókészlet szükségességét illetően. Azt mondta, hogy ennek a készletnek az eltávolítása hatékonyan megszabadulna attól a gondolattól, hogy a Linuxnak van valódi véletlenszám-generátora (TRNG): "ez nem hülyeség, mivel a *BSD pontosan ezt tette mindig."
Aggodalmát fejezi ki amiatt is, hogy a TRNG-mechanizmus biztosítása egyszerűen csaliként fog szolgálni az alkalmazásfejlesztők számára, és úgy véli, hogy a Linux által támogatott különféle hardvertípusok miatt lehetetlen garantálni a TRNG-t a kernelben. Még az sem oldja meg a problémát, ha csak root jogosultságokkal dolgozhat a berendezésekkel: "Az alkalmazásfejlesztők biztonsági okokból előírják, hogy az alkalmazásukat rootként telepítsék, így csak így férhet hozzá az "igazán jó" véletlen számokhoz."
Mueller megkérdezte, hogy Cao felhagyott-e a blokkolókészlet megvalósításával, amelyet ő maga régóta javasolt. Cao azt válaszolta, hogy Lutomirsky javításait tervezi, és aktívan ellenzi, hogy blokkoló felületet adjanak vissza a kernelhez.
„A kernel nem tud garanciát vállalni arra vonatkozóan, hogy a zajforrást megfelelően jellemezték-e. Az egyetlen dolog, amit egy GPG vagy OpenSSL fejlesztő kaphat, az az a homályos érzés, hogy a TRUERANDOM "jobb", és mivel nagyobb biztonságot akarnak, kétségtelenül megpróbálják használni. Egy bizonyos ponton blokkolni fogják, és amikor egy másik okos felhasználó (talán egy terjesztési szakember) beilleszti az init parancsfájlba, és a rendszerek leállnak, a felhasználóknak csak magának Linus Torvaldsnak kell panaszkodniuk.”
A Cao azt is támogatja, hogy a kriptográfusoknak és azoknak, akiknek ténylegesen szükségük van a TRNG-re, adják meg a saját entrópiájukat a felhasználói térben, hogy tetszés szerint használhassák. Azt mondja, hogy az entrópia gyűjtése nem olyan folyamat, amelyet a kernel végrehajthat az általa támogatott összes hardveren, és maga a kernel sem tudja megbecsülni a különböző forrásokból származó entrópia mennyiségét.
"A kernelnek nem szabad különböző zajforrásokat kevernie, és nem szabad azt állítani, hogy tudja, hány bit entrópiát kap, amikor valamiféle "rángatózó entrópiajátékot" próbál játszani egy felháborítóan egyszerű CPU-n. architektúra fogyasztói felhasználók számára. IOT/beágyazott esetek, amikor minden nincs szinkronban egyetlen fő oszcillátorral, ahol nincs CPU utasítás a regiszter átrendezésére vagy átnevezésére stb.
„Beszélhetünk olyan eszközökről, amelyek megpróbálják elvégezni ezeket a számításokat, de ezeket minden egyes felhasználó hardverén el kell végezni, ami egyszerűen nem praktikus a legtöbb disztribúciós felhasználó számára. Ha ezt csak a kriptográfusoknak szánják, akkor tegyék meg az ő felhasználói felületükön. És ne egyszerűsítsük le a GPG-t, az OpenSSL-t stb., hogy mindenki azt mondja, "igazi véletlenszerűséget akarunk és nem elégszik meg kevesebbel". Beszélhetünk arról, hogy miként biztosítunk interfészt a kriptográfusok számára, hogy az elsődleges zajforrásokhoz hozzáférve hozzáférjenek a szükséges információkhoz, elválasztva és elnevezett, és esetleg a zajforrás valamilyen módon hitelesíteni tudja magát egy könyvtárban vagy felhasználói téralkalmazásban."
Volt néhány vita arról, hogy hogyan nézhet ki egy ilyen felület, mivel például bizonyos események biztonsági vonatkozásai lehetnek. Cao megjegyezte, hogy a billentyűzet-letapogatási kódokat (vagyis a billentyűleütéseket) az entrópiagyűjtés részeként egy készletbe keverik: "Ezt a felhasználói térbe hozni, még egy privilegizált rendszerhíváson keresztül is, enyhén szólva nem lenne bölcs dolog." Nagyon valószínű, hogy más eseményidőzítések valamilyen információszivárgást idézhetnek elő az oldalsó csatornákon keresztül.
Úgy tűnik tehát, hogy egy régóta fennálló probléma a Linux véletlenszámú alrendszerével a megoldás felé halad. A véletlenszámú alrendszeren a közelmúltban végrehajtott változások valójában csak DoS-problémákat okoztak a használat során. Most már léteznek hatékony módszerek a kernel által kínált legjobb véletlen számok megszerzésére. Ha a TRNG továbbra is kívánatos Linuxon, akkor ezt a hibát a jövőben ki kell javítani, de ez valószínűleg nem a kernelen belül fog megtörténni.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com