Jak je známo, /dev/random, kryptograficky bezpečný generátor pseudonáhodných čísel (CSPRNG), má jeden nepříjemný problém – blokace. V tomto článku se popisuje, jak lze tento problém vyřešit.
Během posledních několika měsíců byly prostředky pro generování náhodných čísel v jádře lehce přepracovány, ale problémy v tomto subsystému se řeší delší dobu. Nejnovější byly provedeny s cílem zabránit dlouhé blokaci systémového volání getrandom() při spouštění systému, ale důvodem bylo chování blokovacího náhodného poolu. Nedávný patch by měl tento pool odstranit, a očekávalo se, že se dostane do hlavního jádra.
Andy Lutomirski publikoval třetí verzi patche koncem prosince. Úpravy přinášejí "dvě hlavní změny v semantice náhodných API Linuxu".Patch přidává nový příznak GRND_INSECURE k systémovému volání getrandom() (i když se Lutomirski odvolává na getentropy(), která je implementována v glibc pomocí getrandom() se stanovenými příznaky); tento příznak způsobí, že volání vždy vrátí požadované množství dat, ale bez záruky, že jsou tato data náhodná. Jádro se zkrátka bude snažit poskytnout nejlepší náhodná data, která má k dispozici v daném okamžiku. "Pravděpodobně nejlepší, co lze udělat, je nazvat to 'INSECURE' (nebezpečné), aby se zabránilo používání tohoto API pro věci, které vyžadují bezpečnost."
Patche také odstraňují blokující pool. V současnosti jádro podporuje dva pooly náhodných dat, z nichž jeden odpovídá /dev/random a druhý /dev/urandom, jak je popsáno v této zprávě z roku 2015. Blokující pool je pool pro /dev/random; čtení z tohoto zařízení bude blokováno (měl by to říkat jeho název), dokud nebude shromážděna "dostatečná" entropie z systému pro uspokojení požadavku. Další čtení z tohoto souboru jsou také blokována, pokud v poolu není dostatek entropie.
Odstranění blokovacího bazénu znamená, že čtení z /dev/random se chová jako getrandom() se systémovými parametry nastavenými na nulu (a převádí příznak GRND_RANDOM na noop). Po inicializaci kryptografického generátoru náhodných čísel (CRNG) nebude čtení z /dev/random a volání getrandom(…,0) blokovat a vrátí požadovaný počet náhodných dat.
Lutomirski říká: „Myslím, že blokovací bazén Linuxu se stal zastaralým. CRNG Linuxu generuje výstupy, které jsou dostatečně dobré na to, aby je bylo možné použít i pro generaci klíčů. Blokovací bazén již není silnější v žádném hmatatelném ohledu a na jeho udržování je potřeba spousta infrastruktury pochybné hodnoty.“
Změny byly provedeny s cílem zajistit, aby stávající programy skutečně neutrpěly, a ve skutečnosti dojde ke snížení problémů s dlouhým čekáním na takové věci, jako je generování klíčů GnuPG.
„Tyto série by neměly narušit žádné stávající programy. /dev/urandom zůstává nezměněno. /dev/random je stále blokováno ihned po startu, ale je blokováno méně než dříve. getentropy() s existujícími parametry vrátí výsledek, který bude pro praktické účely tak vhodný jako dříve.“
Lutomirski poznamenal, že stále zůstává otevřená otázka, zda by jádro mělo poskytovat takzvaná „skutečná náhodná čísla“, což do určité míry měla dělat blokující jádra. Vidí pro to pouze jeden důvod: „dodržování státních standardů“. Lutomirski navrhl, že pokud by jádro mělo to zajistit, mělo by to být provedeno prostřednictvím zcela jiného rozhraní nebo by mělo být přesunuto do uživatelského prostoru, což by mu umožnilo extrahovat surové vzorky událostí, které mohou být použity k vytvoření takového blokovacího bazénu.
Stephan Müller navrhl, že jeho sada Generátor náhodných čísel Linux (LRNG) (v současnosti je k dispozici verze 26) může být způsobem, jak poskytovat pravá náhodná čísla pro aplikace, které je potřebují. LRNG "plně vyhovuje požadavkům 'Doporučení pro zdroje entropie používané k generování náhodných bitů' SP800-90B", což z něj činí řešení problémů státních standardů.
Matthew Garrett namítal proti termínu "pravé náhodné údaje", upozorňující, že vybraná zařízení mohou být v zásadě modelována dostatečně přesně, aby byla předvídatelná: "nevybíráme kvantové události".
Müller odpověděl, že tento termín pochází z německého standardu AIS 31, který popisuje generátor náhodných čísel, jenž vydává výsledek "stejnou rychlostí, jakou základní zdroj šumu produkuje entropii".
Kromě nesrovnalostí v terminologii přítomnost blokačního poolu, jak je navrženo v patchech LRNG, jednoduše povede k různým problémům, alespoň pokud bude dostupný bez privilegií.
Jak řekl Lutomirský: "To neřeší problém. Pokud dva různí uživatelé spustí hloupé programy, jako je gnupg, prostě se vyčerpají navzájem. Vidím, že v současnosti existují dva hlavní problémy s /dev/random: je náchylný k DoS (tj. vyčerpání zdrojů, škodlivému vlivu nebo něčemu podobnému) a protože pro jeho použití nejsou potřeba žádná privilegovaná práva, také náchylný k zneužitím. Gnupg je špatně, je to úplný kolaps. Pokud přidáme nové nepriviligované rozhraní, které budou používat gnupg a podobné programy, opět prohrajeme."
Müller poznamenal, že přidání getrandom() nyní umožní GnuPG použít toto rozhraní, protože zajistí potřebnou záruku, že pool byl inicializován. Na základě diskusí s vývojářem GnuPG Wernerem Kochem se Müller domnívá, že záruka je jediným důvodem, proč GnuPG v současnosti čte přímo z /dev/random. Ale pokud existuje nepriviligované rozhraní, které je náchylné k odmítnutí služby (jak je tomu dnes s /dev/random), pak podle Lutomirského bude nesprávně používáno některými aplikacemi.
Teodor Cao (Theodore Yue Tak Ts’o), vývojář subsystému náhodných čísel Linux, se zdá, že změnil názor na potřebu blokujícího poolu. Řekl, že odstranění tohoto poolu umožní efektivně zbavit se myšlenky, že Linux má skutečný generátor náhodných čísel (TRNG): „To není nesmysl, protože to je přesně to, co vždy dělali *BSD“.
Znepokojuje ho také to, že poskytování mechanismu TRNG by bylo pouze návnadou pro vývojáře aplikací, a domnívá se, že skutečně, vzhledem k různým typům hardwaru podporovaného Linuxem, není možné zaručit TRNG v jádře. Tuto problematiku nevyřeší ani možnost práce s hardwarem pouze na základě root privilegii: „Vývojáři aplikací uvádějí, že pro bezpečnost by se jejich aplikace měla instalovat jako root, jen tak můžete získat přístup k „opravdu dobrým“ náhodným číslům“.
Müller se zeptal, zda Cao neodstoupil od realizace blokujícího poolu, který sám dávno navrhl. Cao odpověděl, že plánuje vzít patch od Lutomirského a aktivně se ohrazuje proti přidání blokujícího rozhraní zpět do jádra.
„Jádro nemůže poskytnout žádné záruky ohledně toho, zda byl noise source správně charakterizován. Jediné, co může vývojář GPG nebo OpenSSL získat, je matný pocit, že TRUERANDOM je „lepší“, a protože chtějí větší bezpečnost, nepochybně se ho pokusí použít. V určitém okamžiku bude zablokován, a když nějaký jiný chytrý uživatel (možná odborník na vydání distribuce) jej vloží do init skriptu a systémy přestanou fungovat, uživatelům nezbude nic jiného, než si stěžovat samotnému Linusu Torvaldsovi.“
Cao také podporuje, aby kryptografové a ti, kdo skutečně potřebují TRNG, měli možnost sbírat svoji vlastní entropii v uživatelském prostoru a používat ji podle svého uvážení. Říká, že sběr entropie není proces, který může jádro provádět na veškerém podporovaném hardwaru, navíc samo jádro nemůže vyhodnotit množství entropie poskytované různými zdroji.
„Jádro by nemělo míchat různé zdroje šumu dohromady a rozhodně by se nemělo pokoušet tvrdit, kolik bitů entropie získává, když se pokouší hrát nějakou 'trhnutou entropickou hru' na jednoduché, až nehezké architektuře CPU pro uživatelské případy IOT/Embedded, když je vše nesynchronizováno s jedním master-generátorem, a když neexistuje žádný příkaz CPU pro přeřazení nebo přejmenování registru atd.“
„Můžeme mluvit o poskytování nástrojů, které se pokoušejí provádět tyto výpočty, ale takové věci by měly být prováděny na hardwaru každého uživatele, což je pro většinu uživatelů distribuce zkrátka nepraktičné. Pokud je to však určeno pouze pro kryptografy, ať je to provedeno v jejich uživatelském prostoru. A nenechme se zjednodušovat GPG, OpenSSL atd., aby všichni říkali: 'chceme 'skutečnou náhodnost' a nechceme méně'. Můžeme mluvit o tom, jak poskytujeme rozhraní kryptografům, aby mohli získat potřebné informace díky přístupu k primárním zdrojům šumu, odděleným a pojmenovaným, a možná, že nějakým způsobem se zdroj šumu bude moci autentizovat v knihovně nebo aplikaci uživatelského prostoru.“
Proběhla malá diskuse o tom, jak by takové rozhraní mohlo vypadat, neboť například některé události mohou mít důsledky z hlediska bezpečnosti. Cao poznamenal, že kódy pro skenování klávesnice (tj. stisknutí kláves) se míchají do poolu jako součást shromažďování entropie: „Přesunout to do uživatelského prostoru, i přes privilegovaný systémový volání, by bylo minimálně nerozvážné“. Je velmi pravděpodobné, že i jiné časování událostí mohou vytvořit jakýsi únik informací přes boční kanály.
Tak vzniká pocit, že dlouhodobý problém subsystému náhodných čísel Linuxu směřuje k řešení. Změny, které subsystém náhodných čísel v poslední době prodělal, ve skutečnosti vedly pouze k problémům DoS během jeho používání. Nyní se však objevily účinné způsoby, jak získat nejlepší náhodná čísla, která jádro může poskytnout. Pokud je TRNG i nadále žádoucí pro Linux, bude nutné tento nedostatek v budoucnu odstranit, ale pravděpodobně se to nebude dít uvnitř samotného jádra.
Malá reklama 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavých materiálů? Podpořte nás objednávkou nebo doporučením známým, , unikátní alternativa entry-level serverů, kterou jsme pro vás vymysleli: (k dispozici varianty s RAID1 a RAID10, až 24 jader a až 40GB DDR4).
Dell R730xd je dvakrát levnější v datovém centru Equinix Tier IV v Amsterdamu? Jen u nás v Nizozemsku! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Čtěte o tom
Zdroj: habr.com
