Közismert, hogy a /dev/random, egy kriptográfiailag biztonságos álvéletlenszám-generátor (CSPRNG), egy bosszantó problémától szenved: a lefagyásoktól. Ez a cikk elmagyarázza, hogyan lehet megoldani ezt a problémát.
A kernel véletlenszám-generáló funkcióit az elmúlt hónapokban kissé átdolgozták, de az alrendszer problémáit hosszabb idő alatt kezelték. A legtöbb Ezek célja az volt, hogy megakadályozzák a getrandom() rendszerhívás hosszú ideig tartó blokkolását a rendszerindítás során, de a mögöttes ok a blokkoló véletlenszerű készlet viselkedése volt. Egy nemrégiben kiadott javítás eltávolította ezt a készletet, és várhatóan bekerült a fő kernelbe.
Andy Lutomirski december végén tette közzé a javítás harmadik verzióját. Bemutatja "két fő szemantikai változás a véletlenszerű API-kban Linux»A patch egy új GRND_INSECURE jelzőt ad a getrandom() rendszerhíváshoz (bár Lutomirsky getentropy()-ként hivatkozik rá, amelyet a glibc-ben a getrandom() segítségével valósítottak meg fix jelzőkkel); ez a jelző azt eredményezi, hogy a hívás mindig visszaadja a kért adatmennyiséget, de nincs garancia arra, hogy ez az adat véletlenszerű. A kernel egyszerűen mindent megtesz, hogy a lehető legjobb véletlenszerű adatot adja vissza, amivel az adott pillanatban rendelkezik. „Talán a legjobb, amit tehetsz, az az, hogy »BIZTOSATLAN«-nak nevezed.” (nem biztonságos), hogy megakadályozzuk ennek az API-nak a használatát olyan dolgokhoz, amelyek biztonságot igényelnek."
A javítások a blokkoló készletet is eltávolítják. Jelenleg a kernel két véletlenszerű adatkészletet tart fenn, az egyik a /dev/random, a másik a /dev/urandom fájlnak felel meg, a jelen leírásban leírtak szerint. 2015. A blokkoló készlet a /dev/random készlete; az erre az eszközre történő olvasás blokkolva lesz (ahogy a neve is sugallja), amíg a rendszerből „elegendő” entrópia nem gyűlik össze a kérés teljesítéséhez. A fájlból történő további olvasás akkor is blokkolódik, ha a készletben nincs entrópia.
A zárolási készlet eltávolítása azt jelenti, hogy a /dev/random flagből való olvasás úgy viselkedik, mint a getrandom() függvény, amelynek a flagjei nullára vannak állítva (és a GRND_RANDOM flaget noop-pá alakítja). A kriptográfiai véletlenszám-generátor (CRNG) inicializálása után a /dev/random flagből való olvasás és a getrandom(…,0) meghívása nem blokkolja a folyamatot, és a kért mennyiségű véletlenszerű adatot adja vissza.
Lutomirsky szerint: "Azt hiszem, a blokkoló medence Linux túlhaladta a hasznosságát. Linux olyan jó minőségű kimenetet generál, amelyet akár kulcsgenerálásra is lehetne használni. Egy blokkoló készlet semmilyen lényeges módon nem erősebb, és a fenntartása sok, kétes értékű infrastruktúrát igényel."
A változtatásokat azzal a szándékkal hajtották végre, hogy a meglévő programok ne sérüljenek, sőt, kevesebb probléma merüljön fel a hosszú várakozási idővel olyan dolgoknál, mint a GnuPG kulcsgenerálás.
„Ezeknek a sorozatoknak nem szabadna egyetlen meglévő programot sem megzavarniuk. A /dev/urandom változatlan marad. A /dev/random továbbra is blokkol közvetlenül a rendszerindítás után, de kevesebbet, mint korábban. A getentropy() a meglévő flagekkel 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 úgynevezett „valódi véletlenszámokat” kellene-e biztosítania, ami bizonyos mértékig a zároló kernel feladata lett volna. Erre csak egyetlen okot lát: a „kormányzati szabványoknak való megfelelést”. Lutomirsky azt javasolta, hogy ha a kernel ezt biztosítaná, akkor azt egy teljesen más felületen keresztül kellene megtenni, vagy a felhasználói térbe kellene áthelyezni, lehetővé téve számára, hogy nyers eseménymintákat kinyerjen, amelyek felhasználhatók lennének egy ilyen zároló készlet létrehozásához.
Stephan Müller azt javasolta, hogy a szettje egy véletlenszám-generátorhoz Linux Az (LRNG) (jelenleg a 26-os verzióban) módszert kínálhat valódi véletlenszámok előállítására az azokat igénylő alkalmazások számára. Az LRNG „teljes mértékben megfelel az SP800-90B véletlenszerű bitgeneráláshoz használt entrópiaforrásokra vonatkozó ajánlás követelményeinek”, í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, megjegyezve, hogy a mintavételezett eszközök elvileg elég pontosan modellezhetők ahhoz, hogy kiszámíthatóak legyenek: „itt nem kvantumeseményeket mintavételezünk”.
Müller válaszul azt mondta, hogy a kifejezés a német AIS 31 szabványból származik, és egy olyan véletlenszám-generátort ír le, amely csak "ugyanolyan ütemben állít elő kimenetet, mint ahogyan az alapul szolgáló zajforrás entrópiát termel".
A terminológiai különbségeken túl az LRNG javítások által javasolt zárkészlet egyszerűen különféle problémákhoz vezet, legalábbis akkor, ha jogosultságok nélkül is elérhető.
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, akkor egyszerűen kiéheztetik egymást. Jelenleg két fő problémát látok a /dev/random-mal: hajlamos a DoS-ra (azaz erőforrás-kimerülésre, rosszindulatú befolyásra vagy hasonlókra), és mivel a használatához nem szükségesek jogosultságok, a visszaélésekre is hajlamos. A Gnupg rossz, egy teljes kudarc. Ha hozzáadunk egy új, jogosultság nélküli felületet, amelyet a gnupg és hasonló programok használhatnak, akkor ismét veszíteni fogunk.”
Müller megjegyezte, hogy a getrandom() hozzáadása mostantól lehetővé teszi a GnuPG számára, hogy ezt az interfészt használja, mivel biztosítja a szükséges garanciát arra, hogy a pool inicializálva van. A GnuPG fejlesztőjével, Werner Kochhal folytatott megbeszélések alapján Müller úgy véli, hogy ez a garancia az egyetlen ok, amiért a GnuPG jelenleg közvetlenül a /dev/random könyvtárból olvas. Ha azonban létezik egy nem privilegizált interfész, amely ki van téve a szolgáltatásmegtagadásnak (mint amilyen a /dev/random jelenleg), akkor Lutomirsky szerint egyes alkalmazások visszaélésszerűen fogják használni.
Theodore Ts'o (Theodore Yue Tak Ts'o), a véletlenszám-alrendszer fejlesztője Linux, nyilvánvalóan meggondolta magát a blokkoló medence szükségességével kapcsolatban. Azt mondta, hogy annak eltávolítása gyakorlatilag megszüntetné azt az elképzelést, hogy Linux rendelkezik egy valódi véletlenszám-generátorral (TRNG): „Ez nem ostobaság, hiszen a *BSD pontosan ezt csinálta mindig is.”
Azt is aggasztja, hogy a TRNG mechanizmus biztosítása csupán csaliként szolgál majd az alkalmazásfejlesztők számára, és úgy véli, hogy a valóságban, tekintettel a támogatott hardverek különböző típusaira Linux, lehetetlen garantálni a TRNG-t a kernelben. Még az sem oldja meg a problémát, ha csak root jogosultságokkal működtetjük a hardvert: „Az alkalmazásfejlesztők biztonsági okokból root felhasználóként követelik meg az alkalmazás telepítését, mert csak így férhetnek hozzá a „tényleg jó” véletlenszámokhoz.”
Müller rákérdezett, hogy Cao felhagyott-e a régen javasolt blokkoló pool implementációjával. Cao azt válaszolta, hogy Lutomirsky javításait tervezi átvenni, és aktívan ellenzi a blokkoló interfész kernelbe való visszaillesztését.
„A kernel semmilyen garanciát nem tud adni arra vonatkozóan, hogy a zajforrást megfelelően jellemezték-e. Egy GPG vagy OpenSSL fejlesztő csak egy homályos érzést kaphat, hogy a TRUERANDOM „jobb”, és mivel nagyobb biztonságot akarnak, kétségtelenül megpróbálják majd használni. Valamikor blokkolva lesz, és amikor egy másik okos felhasználó (talán egy disztribúciós kiadásért felelős mérnök) beilleszti egy init szkriptbe, és a rendszerek leállnak, a felhasználóknak csak magának Linus Torvaldsnak lehet panaszuk.”
Cao azt is javasolja, hogy a kriptográfusok és azok számára, akiknek valóban szükségük van TRNG-kre, biztosítsanak egy módszert a saját entrópiájuk gyűjtésére a felhasználói térben saját használatra. Azt állítja, hogy az entrópiagyűjtés nem olyan folyamat, amelyet a kernel minden támogatott hardveren el tud végezni, és hogy maga a kernel nem tudja megbecsülni a különböző források által biztosított entrópia mennyiségét.
„A processzormagnak nem szabad különböző zajforrásokat kevernie, és semmiképpen sem szabad azt állítania, hogy tudja, hány bit entrópiát kap, amikor egy nevetségesen egyszerű CPU architektúrán próbál „rángatózó entrópiajátékot” játszani IoT/beágyazott felhasználói esetekhez, amikor minden nincs szinkronban egyetlen fő oszcillátorral, amikor nincs CPU utasítás egy regiszter átrendezésére vagy átnevezésére stb.”
„Beszélhetünk olyan eszközök biztosításáról, amelyek megpróbálják elvégezni ezeket a számításokat, de ezeket a dolgokat minden felhasználó hardverén kellene elvégezni, ami egyszerűen nem praktikus a legtöbb disztribúciós felhasználó számára. Ha ez csak kriptográfusoknak szól, akkor hagyjuk, hogy az ő felhasználói terükben történjen. És ne egyszerűsítsük le a GPG-t, az OpenSSL-t és így tovább, hogy mindenki azt mondja: »Igazi véletlenszerűséget akarunk«, és ne elégedjünk meg kevesebbel. Beszélhetünk arról, hogyan biztosítunk interfészeket a kriptográfusok számára, hogy a szükséges információkat a mögöttes zajforrások elérésével szerezhessék meg, elkülönítve és elnevezve, és talán valahogy lehetővé téve, hogy a zajforrás hitelesítse magát egy felhasználói térbeli könyvtárban vagy alkalmazásban.”
Volt némi vita arról, hogy hogyan nézhet ki egy ilyen interfész, mivel egyes eseményeknek például biztonsági vonatkozásai lehetnek. Cao megjegyezte, hogy a billentyűzetleolvasási kódokat (azaz a billentyűleütéseket) az entrópiagyűjtés részeként gyűjtik össze: „Ennek a felhasználói térbe helyezése, akár egy privilegizált rendszerhíváson keresztül is, legalábbis nem lenne bölcs dolog.” Az is lehetséges, hogy más eseményidőzítések valamilyen oldalcsatornás információszivárgást okozhatnak.
Úgy tűnik tehát, hogy a véletlenszám-alrendszer régóta fennálló problémája Linux úton van a megoldás felé. A véletlenszám-alrendszerben a közelmúltban végrehajtott változtatások gyakorlatilag csak szolgáltatásmegtagadási problémákhoz vezettek a használata során. Most azonban hatékony módszerek vannak a kernel által kínált legjobb véletlenszámok elérésére. Ha a TRNG továbbra is kívánatos a következőkhöz: Linux, akkor ezt a hiányosságot a jövőben orvosolni kell, de valószínűleg ez nem magában a kernelben 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
