Mint tudjuk, a /dev/random, a kriptográfiailag biztonságos véletlen számokat generáló (CSPRNG) generátor, rendelkezik egy kellemetlen problémával – a blokkolással. Ebben a cikkben arról lesz szó, hogyan lehet ezt a problémát megoldani.
Az utóbbi pár hónapban a véletlen számok generálásának eszközei a kernelben kissé átdolgozásra kerültek, de ennek a részrendszernek a problémáit szélesebb időkeretekben oldották meg. A legújabb célja az volt, hogy megakadályozza a getrandom() rendszerhívás hosszú blokkolását a rendszer betöltésekor, de ennek hátterében a blokkoló véletlen tartály viselkedése állt. A közelmúlt javítása eltávolította volna ezt a tartályt, és várható volt, hogy a fő kernelhez fog folyni.
Andy Lutomirski december végén közzétette a patch harmadik verzióját. Ez bevezet „két alapvető szemantikai változást a Linux véletlen API-jában”.A patch új GRND_INSECURE zászlót ad a getrandom() rendszerhíváshoz (bár Lutomirski getentropy()-ként hivatkozik rá, amelyet a glibc a getrandom() segítségével valósít meg rögzített zászlókkal); ez a zászló arra kényszeríti a hívást, hogy mindig visszaadja a kért adatmennyiséget, de nem garantálja, hogy ezek az adatok véletlenszerűek. A kernel csak annyit tesz, hogy a legjobban elérhető véletlenszerű adatokat adja meg a rendelkezésre álló időpontban. „Valószínűleg a legjobb, amit tehetünk, az, hogy INSECURE-nek hívjuk (nem biztonságos), hogy megakadályozzuk ennek az API-nak a biztonságot igénylő dolgokhoz való használatát.”
A patchok eltávolítják a blokkoló tartályt is. Jelenleg a kernel két véletlenszerű adatgyűjtő tartályt támogat, az egyik a /dev/random, a másik pedig a /dev/urandom, ahogyan ezt a 2015-ös dokumentumban leírták. A blokkoló tartály a /dev/random; ennek az eszköznek az olvasása blokkolva lesz (nevéből adódóan), amíg a rendszer nem gyűjt össze „megfelelő” mennyiségű entrópiát a kérés teljesítéséhez. További olvasások erről a fájlról szintén blokkolva vannak, ha a tartályban nincs elegendő entrópia.
A blokkoló pool eltávolítása azt jelenti, hogy a /dev/random-ból való olvasás a getrandom() függvényt viselkedésként követi, ahol a flags értéke nulla (és a GRND_RANDOM flag noop-ra vált). A kriptográfiai véletlenszám-generátor (CRNG) inicializálása után a /dev/random-ból való olvasás és a getrandom(…,0) hívások nem fognak blokkolni, és visszaadják a kért mennyiségű véletlenszerű adatot.
Lutomirsky mondta: „Úgy vélem, hogy a Linux blokkoló poolja elavult. A Linux CRNG olyan kimenetet generál, amely elég jó ahhoz, hogy akár kulcsok generálására is használható legyen. A blokkoló pool nem jelent erősebb megoldást semmilyen szempontból, és a fenntartásához rengeteg kétes értékű infrastruktúrára van szükség.”
A változtatásokat úgy hajtották végre, hogy a meglévő programok valójában ne szenvedjenek, és valóban kevesebb problémát okoz majd a hosszú várakozás az olyan dolgok esetében, mint a GnuPG kulcsgenerálás.
„Ezek a sorozatok nem szabad, hogy megsértsenek semmilyen meglévő programot. A /dev/urandom változatlan marad. A /dev/random továbbra is blokkolva van a rendszer indításakor, de most kevesebb időt blokkol. A getentropy() a meglévő flag-ekkel olyan eredményt fog visszaadni, amely gyakorlati célokra ugyanolyan megfelelő, mint korábban.”
Lutomirsky megjegyezte, hogy még mindig nyitott kérdés, hogy a kernelnek kell-e biztosítania úgynevezett „valódi véletlen számokat”, amit a blokkoló kernelnek részben kellett volna biztosítania. Csak egy okot lát erre: „az állami normák betartása”. Lutomirsky feltételezte, hogy ha a kernelnek ezt biztosítania kell, akkor azt egy teljesen más interfészen keresztül kellene megtenni, vagy át kellene vinni a felhasználói térbe, lehetővé téve számára, hogy nyers eseménymintákat gyűjtsön, amelyek felhasználhatók egy ilyen blokkoló pool létrehozásához.
Stephan Müller azt javasolta, hogy a készlete A Linux random number generator (LRNG) (currently released version 26) can be a way to provide true random numbers for applications that need them. LRNG 'fully complies with the recommendations for entropy sources used for generating random bits' SP800-90B, making it a solution to the problem of government standards.
Matthew Garrett objected to the term 'true random data', noting that the devices selected can, in principle, be modeled closely enough to make them predictable: 'we are not sampling quantum events here'.
Müller responded that this term comes from the German standard AIS 31 for describing a random number generator, which only outputs results 'at the same speed as the underlying source of noise produces entropy'.
Aside from terminological discrepancies, the presence of a lock pool, as suggested by LRNG patches, will simply lead to various problems at least if it is available without privileges.
As Lutomirski said: ‘This does not solve the problem. If two different users run dumb programs like gnupg, they will just exhaust each other. I see that there are currently two main issues with /dev/random: it is prone to DoS (i.e., resource exhaustion, malicious influence, or something similar), and since no privileges are required to use it, it is also prone to abuse. Gnupg is wrong, it is a complete collapse. If we introduce a new unprivileged interface that gnupg and similar programs will use, we will lose again.’
Müller noted that adding getrandom() will now allow GnuPG to use this interface, as it will provide the necessary guarantee that the pool has been initialized. Based on discussions with GnuPG developer Werner Koch, Müller believes that the guarantee is the only reason GnuPG currently reads directly from /dev/random. But if there is an unprivileged interface that is subject to denial of service (like /dev/random today), it will, according to Lutomirski, be misused by some applications.
A Theodore Yue Tak Ts’o, a Linux véletlenszám-generátor-alrendszer fejlesztője, úgy tűnik, megváltoztatta a blokkoló pool szükségességéről alkotott véleményét. Azt mondta, hogy ennek a poolnak az eltávolítása lehetővé teszi, hogy hatékonyan megszabaduljanak attól az elképzeléstől, hogy a Linuxnak igazi véletlenszám-generátora (TRNG) van. „Ez nem értelmetlenség, mivel pontosan ezt csinálták mindig *BSD-n.
Aggódik amiatt is, hogy a TRNG mechanizmus biztosítása csupán csalogató eszközké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 hardverek figyelembevételével lehetetlen garantálni a TRNG-t a kernelben. A probléma még root jogosultságokkal rendelkező hardverek kezelésével sem oldható meg. „Az alkalmazásfejlesztők arra figyelmeztetnek, hogy az alkalmazás biztonsági okokból root-ként legyen telepítve, mert csak így érhetjük el a "valóban jó" véletlenszámokat.
Müller megkérdezte, hogy Cao nem mondott-e le arról a blokkoló pool megvalósításáról, amelyet korábban ő maga javasolt. Cao válaszolt, hogy tervezi a Lutomirsky javítások átvételét, és aktívan ellenzi a blokkoló interfész újra beillesztését a kernelbe.
„A kernel nem tud semmilyen garanciát adni arra nézve, hogy a noise source megfelelően van-e karakterizálva. Az egyetlen dolog, amit a GPG vagy OpenSSL fejlesztője megkaphat, az egy homályos érzés, hogy a TRUERANDOM "jobb", és mivel ők nagyobb biztonságot akarnak, biztosan meg fogják próbálni használni. Egy adott pillanatban blokkolva lesz, és amikor valamelyik másik okos felhasználó (talán egy disztribúciók kiadásáért felelős szakember) beilleszti az init szkriptbe, a rendszerek le fognak állni, a felhasználóknak csak Linus Torvalds-nak marad lehetőségük panaszra.
Cao szintén azon dolgozik, hogy a kriptográfusoknak és azoknak, akik valóban szükségük van TRNG-re, lehetőséget biztosítson saját entropy gyűjtésére felhasználói térben, hogy azt tetszésük szerint használhassák. Azt mondja, hogy az entropy gyűjtése nem olyan folyamat, amit a kernel képes végrehajtani a támogatható hardverek sokaságán, ráadásul a kernel maga nem tudja értékelni, hogy a különböző források mennyi entropy-t biztosítanak.
A mag, hogy a mag nem keverheti össze a különböző zajforrásokat, és természetesen nem állíthatja, hogy tudja, hány bit entropiát kap, amikor valamilyen 'rángatózó entropiajátékot' próbál játszani egy rendkívül egyszerű CPU-architektúrán a felhasználói IoT/Embedded esetekhez, amikor minden el van szinkronizálva egyetlen mester-generátorral, amikor nincs CPU utasítás a regiszterek újrarendezésére vagy átnevezésére, stb.
Beszélhetünk olyan eszközök biztosításáról, amelyek megpróbálnak ezekben a számításokban segíteni, de ezeknek a dolgoknak a felhasználók gépein kell zajlania, ami a disztribúció többsége számára egyszerűen nem praktikus. Ha ez csak a kriptográfusok számára van szánva, akkor legyen a felhasználói terükben. És ne egyszerűsítsük le a GPG-t, OpenSSL-t, stb., hogy mindenki azt mondhassa: 'igazi véletlenszerűséget' akarunk, és nem érjük be kevesebbel. Beszélhetünk arról, hogyan biztosítunk interfészeket a kriptográfusok számára, hogy hozzáférhessenek a szükséges információkhoz az elnevezett és elválasztott elsődleges zajforrásokhoz, és talán valamilyen módon a zajforrás hitelesítheti magát a könyvtárban vagy a felhasználói területen.
Volt egy kis vita arról, hogyan is nézhet ki egy ilyen interfész, hiszen például egyes események biztonsági következményekkel járhatnak. Cao megjegyezte, hogy a billentyűleütés (vagyis a billentyűk lenyomása) kódjai a zajgyűjtés részeként keverednek a medencébe: 'ezt a felhasználói térbe helyezni, még egy privilegizált rendszerhívás révén is, legalábbis nem lenne bölcs döntés'. Teljesen valószínű, hogy más események időzítései is okozhatnak valamilyen információszivárgást mellékcsatornákon.
Így tehát úgy tűnik, hogy a Linux véletlenszám-generáló alrendszerének régóta fennálló problémája a megoldás küszöbére érkezett. Az alrendszer az utóbbi időben végrehajtott változtatásai valójában csak DoS problémákhoz vezettek a használata során. Most azonban hatékony módok állnak rendelkezésre a legjobb véletlenszámok megszerzésére, amelyeket a kernel biztosítani tud. Ha a TRNG továbbra is kívánatos Linux számára, akkor ezt a hiányosságot a jövőben meg kell oldani, de valószínűleg nem a kernel belsejében fogják végrehajtani.
Egy kis reklám 🙂
Köszönjük, hogy velünk maradtál. Tetszenek a cikkeink? Szeretnél több érdekes anyagot látni? Támogass minket, és rendelés leadásával vagy ismerősöknek ajánlással segíts nekünk. , Egyedülálló alternatívája az entry-level szervereknek, amelyet Önnek találtunk ki: (elérhetők RAID1 és RAID10 opciók, akár 24 magig és 40GB DDR4-ig).
Dell R730xd kétszer olcsóbban a Tier IV Equinix adatközpontban Amszterdamban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 dollártól! Olvasd el ezt
Forrás: habr.com
