Ako je známe, /dev/random, kryptograficky bezpečný generátor pseudonáhodných čísel (CSPRNG), má jednu nepríjemnú vlastnosť – blokovanie. V tomto článku sa hovorí o tom, ako tento problém vyriešiť.
V posledných niekoľkých mesiacoch došlo k menšej úprave prostriedkov na generovanie náhodných čísel v jadre, avšak problémy v tejto subsystéme sa riešili po dlhšiu dobu. . Najnovšie boli urobené s cieľom zabrániť dlhodobému blokovaniu systémového volania getrandom() pri spustení systému, avšak podkladovým dôvodom bol spôsob blokovania náhodného poolu. Nedávny patch by mal tento pool odstrániť, takže sa očakáva, že sa dostane do hlavného jadra.
Andy Lutomirski zverejnil tretiu verziu patchu koncom decembra. Prináša „dve základné sémantické zmeny v náhodných API Linuxu“. Patch pridáva nový flag GRND_INSECURE k systémovému volaniu getrandom() (hoci Lutomirski sa naň odvoláva ako na getentropy(), ktoré je implementované v glibc pomocou getrandom() s pevnými flagmi); tento flag spôsobí, že volanie vždy vráti požadovaný objem dát, ale bez záruky, že tieto dáta sú náhodné. Jadro sa jednoducho snaží poskytnúť čo najlepšie náhodné dáta, ktoré má v danom okamihu. „Je pravdepodobne najlepšie nazvať to „INSECURE“ (nebezpečným), aby sa zabránilo používaniu tohto API na veci, ktoré vyžadujú bezpečnosť.“
Patche tiež odstraňujú blokujúci pool. V súčasnosti jadro podporuje dva pooly náhodných dát, z ktorých jeden zodpovedá /dev/random a druhý /dev/urandom, ako je popísané v tejto správe z roku 2015. Blokujúci pool je pool pre /dev/random; čítanie z tohto zariadenia bude blokované (myslí sa jeho názov) dovtedy, kým nebude zo systému zhromaždená „dostatočná“ entropia na splnenie požiadavky. Ďalšie čítania z tohto súboru sú tiež blokované, ak je v poole nedostatok entropy.
Odstránenie blokovacieho poolu znamená, že čítanie z /dev/random sa správa ako getrandom() s hodnotou flags rovnou nule (a premieňa flag GRND_RANDOM na noop). Po inicializácii kryptografického generátora náhodných čísel (CRNG) nebude čítanie z /dev/random a volania getrandom(…,0) blokať a vráti požadované množstvo náhodných údajov.
Lutomirský hovorí: „Myslím, že blokovací pool Linuxu sa stal prežitkom. CRNG Linuxu generuje výstupy, ktoré sú dostatočne dobré na to, aby sa použili aj na generovanie kľúčov. Blokovací pool už nie je silnejší v žiadnom hmatateľnom zmysle a na jeho udržiavanie je potrebné veľa infraštruktúry pochybnej hodnoty.“
Zmeny boli vykonané s ohľadom na to, aby existujúce programy naozaj neboli postihnuté, a v skutočnosti bude problémy s dlhým čakaním na také veci, ako je generovanie kľúčov GnuPG, menej.
„Tieto série by nemali narušiť žiadne existujúce programy. /dev/urandom zostáva nezmenené. /dev/random sa stále blokuje hneď po spustení, ale blokuje sa menej ako predtým. getentropy() s existujúcimi flagmi vráti výsledok, ktorý bude pre praktické účely rovnako vhodný ako predtým.“
Lutomirský poznamenal, že stále zostáva otvorenou otázkou, či by jadro malo poskytovať takzvané „skutočné náhodné čísla“, čo malo do určitej miery robiť blokujúce jadro. Vidí pre to iba jeden dôvod: „dodržiavanie štátnych noriem“. Lutomirský naznačil, že ak by to jadro malo zabezpečiť, malo by to byť urobené prostredníctvom úplne iného rozhrania alebo by to malo byť presunuté do užívateľského priestoru, ktorý by mu umožnil extrahovať surové vzorky udalostí, ktoré by sa mohli použiť na vytvorenie takého blokovacieho poolu.
Stephan Müller navrhol, že jeho súbor Pre generátor náhodných čísel Linux (LRNG) (aktuálne vydanie 26) môže byť spôsobom, ako poskytnúť pravé náhodné čísla pre aplikácie, ktoré ich potrebujú. LRNG "úplne spĺňa požiadavky "Odporúčaní pre zdroje entropie používané na generovanie náhodných bitov" SP800-90B", čo ho robí riešením problému štátnych štandardov.
Matthew Garrett namietal proti termínu "pravé náhodné údaje", poznamenávajúc, že vyberané zariadenia môžu byť v zásade modelované dostatočne presne, aby sa stali predvídateľnými: "tu nevyberáme kvantové udalosti."
Müller odpovedal, že tento termín pochádza z nemeckého štandardu AIS 31, ktorý popisuje generátor náhodných čísel, ktorý vydáva výsledok "rovnakou rýchlosťou, akou základný zdroj šumu produkuje entropiu."
Okrem nejednoznačností terminológie, existencia zamykacieho poolu, ako sa navrhuje v patchoch LRNG, jednoducho vytvorí rôzne problémy, aspoň ak je dostupný bez privilégií.
Ako povedal Lutomirsky: "To nerieši problém. Ak dvaja rôzni užívatelia spustia hlúpe programy, ako gnupg, jednoducho si navzájom vyčerpajú zdroje. Vidím, že v súčasnosti existujú dva hlavné problémy s /dev/random: má tendenciu k DoS (t. j. vyčerpaniu zdrojov, škodlivému ovplyvneniu alebo niečomu podobnému), a pretože nie sú potrebné žiadne privilégiá na jeho použitie, tiež sa často zneužíva. Gnupg - to je nesprávne, to je úplný kolaps. Ak pridáme nové nepriviligované rozhranie, ktoré budú používať gnupg a podobné programy, znovu prehráme."
Müller poznamenal, že pridanie getrandom() teraz umožní GnuPG používať toto rozhranie, pretože poskytne potrebnú záruku, že pool bol inicializovaný. Na základe diskusií s vývojárom GnuPG Wernerom Kochom, Müller považuje záruku za jediný dôvod, prečo GnuPG v súčasnosti číta priamo z /dev/random. Ale ak existuje nepriviligované rozhranie, ktoré je náchylné na útoky Denial-of-Service (ako dnes /dev/random), potom podľa Lutomirského bude nesprávne používané niektorými aplikáciami.
Teodor Cao (Theodore Yue Tak Ts’o), vývojár subsystému náhodných čísel Linux, sa zjavne zmenil v názore na potrebu blokovacieho poolu. Povedal, že odstránenie tohto poolu efektívne zbaví predstavy, že Linux má skutočný generátor náhodných čísel (TRNG): „nie je to nezmysel, pretože to je to, čo *BSD vždy robili."
Je tiež znepokojený tým, že poskytnutie mechanizmu TRNG bude iba návnadou pre vývojárov aplikácií a považuje za nemožné zaručiť TRNG v jadre, keď zohľadníme rôzne typy hardvéru podporovaných Linuxom. Problém nerieši ani možnosť fungovania s hardvérom len na základe root-privilégií: „Vývojári aplikácií požadujú, aby ich aplikácia bola nainštalovaná s oprávneniami root, pretože len tak môžete získať prístup k „naozaj dobrým“ náhodným číslam".
Müller sa opýtal, či sa Cao vzdal realizácie blokovacieho poolu, ktorý sám dávno navrhol. Cao odpovedal, že plánuje prevziať patche Lutomirského a aktívne sa oponuje pridaniu blokovacieho rozhrania späť do jadra.
„Jadro nemôže poskytnúť žiadne záruky týkajúce sa toho, či bol noise source riadne charakterizovaný. Jediné, čo môže vývojár GPG alebo OpenSSL získať, je neurčitý pocit, že TRUERANDOM je „lepší“, a preto, ak chcú väčšiu bezpečnosť, určite sa pokúsia to využiť. V určitej chvíli sa to zablokuje, a keď nejaký iný zdatný používateľ (možno špecialista na vydanie distribúcie) to vloží do init skriptu a systémy prestanú fungovať, používateľom ostane iba sťažovať sa samotnému Linusovi Torvaldsovi."
Cao sa taktiež vyslovil za to, aby sa kryptografom a tým, ktorí skutočne potrebujú TRNG, poskytol spôsob, ako zbierať svoj vlastný entropiu v užívateľskom priestore na vlastné využitie. Hovorí, že zbieranie entropie nie je proces, ktorý by mohlo vykonávať jadro na všetkých podporovaných hardvérových prostriedkoch, navyše samo jadro nemôže posúdiť množstvo entropie, ktoré poskytujú rôzne zdroje.
„Jadro by nemalo miešať rôzne noise source a samozrejme by sa nemalo pokúšať tvrdiť, že vie, koľko bitov entropie získava, keď sa snaží hrať nejakú 'trhnutú hru entropie' na prekliato jednoduchých architektúrach CPU pre používateľské prípady IOT/Embedded, keď je všetko nesynchronizované s jediným master-generátorom, keď neexistuje žiadna inštrukcia CPU na preusporiadanie alebo premenovanie registra a podobne.“
„Môžeme hovoriť o poskytovaní nástrojov, ktoré sa pokúšajú tieto výpočty vykonať, ale takéto veci by sa mali vykonávať na zariadeniach každého používateľa, čo je pre väčšinu používateľov distribúcie jednoducho nepraktické. Ak je to však určené len pre kryptografov, tak nech sa to deje v ich používateľskom Priestore. A nenechajme sa zmiasť GPG, OpenSSL a podobne, aby všetci hovorili: 'chceme „pravú náhodnosť“ a nechceme menej'. Môžeme hovoriť o tom, ako poskytujeme rozhrania kryptografom, aby mohli získať potrebné informácie prostredníctvom prístupu k primárnym noise sources, oddeleným a pomenovaným, a možno, že nejakým spôsobom noise source bude schopný autentifikovať sa v knižnici alebo aplikácii používateľského priestoru.“
Prebehla malá diskusia o tom, ako by takéto rozhranie mohlo vyzerať, pretože niektoré udalosti môžu mať následky z hľadiska bezpečnosti. Cao poznamenal, že kódy skenovania klávesnice (t.j. stlačenia klávesov) sa miešajú do poolu ako súčasť zberu entropie: „Preniesť to do používateľského priestoru, aj cez privilegovaný systémový volanie, by bolo aspoň nerozvážne“. Je celkom možné, že aj iné časovanie udalostí môže spôsobiť nejaké úniky informácií cez bočné kanály.
Tak vzniká pocit, že starý problém subsystému náhodných čísel Linuxu je na ceste k riešeniu. Zmeny, ktorými tento subsystém nedávno prešiel, v skutočnosti viedli iba k problémom DoS pri jeho používaní. Teraz sa však objavili efektívne spôsoby, ako získať najlepšie náhodné čísla, ktoré môže poskytnúť jadro. Ak je TRNG stále žiadúce pre Linux, tento nedostatok bude potrebné v budúcnosti odstrániť, avšak pravdepodobne sa to nebude robiť priamo v jadre.
Trochu reklamy 🙂
Ďakujeme, že ostávate s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavých materiálov? Podporte nás, vytvorením objednávky alebo odporúčaním známym, , unikátny ekvivalent entry-level serverov, ktorý sme pre vás vytvorili: (k dispozícii varianty s RAID1 a RAID10, až 24 jadier a až 40GB DDR4).
Dell R730xd je dvakrát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len u nás v Holandsku! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolárov! Prečítajte si o tom
Zdroj: habr.com
