Je známo, že /dev/random, kryptograficky bezpečný generátor pseudonáhodných čísel (CSPRNG), má jeden nepříjemný problém: blokování. Tento článek vysvětluje, jak to můžete vyřešit.
Během několika posledních měsíců byla v jádře mírně přepracována zařízení pro generování náhodných čísel, ale problémy v tomto subsystému byly vyřešeny v průběhu širšího . Nejvíc byly vytvořeny, aby zabránily blokování systémového volání getrandom() po dlouhou dobu při spouštění systému, ale hlavním důvodem bylo blokování náhodného fondu. Nedávná oprava by tento fond odstranila a očekávalo by se, že zamíří k hlavnímu jádru.
Andy Lutomirski zveřejnil třetí verzi patche na konci prosince. On přispívá "dvě hlavní sémantické změny náhodných linuxových API". Patch přidává do systémového volání getrandom() nový příznak GRND_INSECURE (ačkoli Lutomirsky jej nazývá getentropy(), který je implementován v glibc pomocí getrandom() s pevný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 data jsou náhodná. Jádro prostě udělá vše pro to, aby produkovalo nejlepší náhodná data, která v daný čas má. "Pravděpodobně nejlepší věc, kterou můžete udělat, je nazvat to "NEBEZPEČNÉ" (nezabezpečené), aby se zabránilo použití tohoto rozhraní API pro věci, které vyžadují zabezpečení."
Záplaty také odstraní blokující fond. Jádro aktuálně spravuje dva náhodné datové fondy, jeden odpovídá /dev/random a druhý /dev/urandom, jak je popsáno v tomto 2015. Blok blokování je fond pro /dev/random; čtení pro toto zařízení bude blokováno (myšleno jeho jméno), dokud nebude ze systému shromážděno "dostatek" entropie k uspokojení požadavku. Další čtení z tohoto souboru jsou také blokována, pokud ve fondu není dostatek entropie.
Odstranění fondu zámků znamená, že čtení z /dev/random se chová jako getrandom() s příznaky nastavenými na nulu (a změní příznak GRND_RANDOM na noop). Jakmile je kryptografický generátor náhodných čísel (CRNG) inicializován, čtení z /dev/random a volání getrandom(...,0) se nezablokují a vrátí požadované množství náhodných dat.
Lutomirsky říká: „Věřím, že blokovací fond Linuxu je zastaralý. CRNG Linux generuje výstup, který je dostatečně dobrý na to, aby byl použit i pro generování klíčů. Blokovací fond není silnější v žádném materiálním smyslu a vyžaduje mnoho infrastruktury pochybné hodnoty, která jej podporuje.“
Změny byly provedeny s cílem zajistit, aby stávající programy nebyly skutečně ovlivněny, a ve skutečnosti by bylo méně problémů s dlouhým čekáním na věci, jako je generování klíčů GnuPG.
"Tyto epizody nesmí narušit žádné existující programy." /dev/urandom zůstává nezměněn. /dev/random stále blokuje ihned po startu, ale blokuje méně než předtím. getentropy() s existujícími příznaky vrátí výsledek, který je stejně vhodný pro praktické účely jako dříve."
Lutomirsky poznamenal, že je stále otevřenou otázkou, zda by jádro mělo poskytovat takzvaná „skutečně náhodná čísla“, což je to, co mělo blokovací jádro do určité míry dělat. Vidí pro to jediný důvod: „dodržování vládních standardů“. Lutomirsky navrhl, že pokud by to jádro mělo poskytnout, mělo by to být provedeno prostřednictvím zcela jiného rozhraní nebo by to mělo být přesunuto do uživatelského prostoru, což uživateli umožní získat nezpracované vzorky událostí, které by mohly být použity k vytvoření takového fondu zámků.
Stephan Müller navrhl, že jeho set for Linux Random Number Generator (LRNG) (aktuálně vydaná verze 26) by mohl být způsob, jak poskytnout skutečná náhodná čísla pro aplikace, které to potřebují. LRNG je „plně v souladu se směrnicemi SP800-90B o zdrojích entropie používaných ke generování náhodných bitů“, což z něj činí řešení problému vládních standardů.
Matthew Garrett protestoval proti termínu „skutečně náhodná data“ a poznamenal, že vzorkovaná zařízení by v zásadě mohla být modelována dostatečně přesně, aby byla předvídatelná: „nevzorkujeme zde kvantové události“.
Müller odpověděl, že termín pochází z německého standardu AIS 31 k popisu generátoru náhodných čísel, který pouze produkuje výsledek „stejnou rychlostí, jakou základní zdroj hluku produkuje entropii“.
Pomineme-li rozdíly v terminologii, mít fond zámků, jak to navrhují LRNG patche, jednoduše povede k různým problémům, alespoň pokud je přístupný bez oprávnění.
Jak řekl Lutomirsky: "To problém neřeší." Pokud dva různí uživatelé spouštějí hloupé programy jako gnupg, navzájem se vyčerpají. Vidím, že v současné době existují dva hlavní problémy s /dev/random: je náchylný k DoS (tj. vyčerpání zdrojů, škodlivý vliv nebo něco podobného), a protože k jeho používání nejsou vyžadována žádná oprávnění, je také náchylný ke zneužití. Gnupg je špatně, je to úplný kolaps. Pokud přidáme nové neprivilegované rozhraní, které bude používat gnupg a podobné programy, opět prohrajeme.“
Mueller poznamenal, že přidání getrandom() nyní umožní GnuPG používat toto rozhraní, protože poskytne nezbytnou záruku, že fond byl inicializován. Na základě diskuzí s vývojářem GnuPG Wernerem Kochem se Mueller domnívá, že záruka je jediným důvodem, proč GnuPG v současnosti čte přímo z /dev/random. Pokud ale existuje neprivilegované rozhraní, které je náchylné k odmítnutí služby (jako dnes /dev/random), Lutomirsky tvrdí, že bude některými aplikacemi zneužito.
Zdá se, že Theodore Yue Tak Ts'o, vývojář linuxového subsystému náhodných čísel, změnil názor na potřebu blokovacího fondu. Řekl, že odstranění tohoto fondu by se účinně zbavilo 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 *BSD vždy dělal."
Také se obává, že poskytnutí mechanismu TRNG poslouží pouze jako návnada pro vývojáře aplikací, a věří, že ve skutečnosti vzhledem k různým typům hardwaru podporovaným Linuxem není možné zaručit TRNG v jádře. Problém nevyřeší ani schopnost pracovat se zařízením pouze s oprávněními root: "Vývojáři aplikací specifikují, že jejich aplikace musí být nainstalována jako root z bezpečnostních důvodů, takže je to jediný způsob, jak získat přístup k "skutečně dobrým" náhodným číslům."
Mueller se zeptal, zda Cao opustil implementaci blokovacího fondu, kterou sám dlouho navrhoval. Cao odpověděl, že plánuje vzít Lutomirského záplaty a aktivně se staví proti přidání blokovacího rozhraní zpět do jádra.
„Jádro nemůže poskytnout žádné záruky, zda byl zdroj hluku správně charakterizován. Jediné, co může vývojář GPG nebo OpenSSL získat, je vágní pocit, že TRUERANDOM je „lepší“, a protože chtějí více zabezpečení, nepochybně se jej pokusí použít. V určitém okamžiku bude zablokován, a když jej nějaký jiný chytrý uživatel (možná specialista na distribuci) vloží do init skriptu a systémy přestanou fungovat, uživatelé si budou muset stěžovat pouze u samotného Linuse Torvaldse.“
Cao také prosazuje, aby kryptografům a těm, kteří skutečně potřebují TRNG, poskytl způsob, jak sklízet svou vlastní entropii v uživatelském prostoru, aby ji mohli používat, jak uznají za vhodné. Říká, že shromažďování entropie není proces, který může jádro provádět na veškerém různém hardwaru, který podporuje, ani samotné jádro nedokáže odhadnout množství entropie poskytované různými zdroji.
"Jádro by nemělo míchat různé zdroje hluku dohromady a rozhodně by se nemělo snažit tvrdit, že ví, kolik bitů entropie získává, když se snaží hrát nějakou "hru s cukavou entropií" na nehorázně jednoduchém CPU. architektura pro spotřebitelské uživatele. IOT/Embedded případy, kdy není vše synchronizováno s jediným hlavním oscilátorem, kde neexistuje žádná instrukce CPU pro změnu pořadí nebo přejmenování registru atd.“
„Můžete mluvit o poskytování nástrojů, které se pokoušejí provádět tyto výpočty, ale takové věci se musí dělat na hardwaru každého uživatele, což pro většinu uživatelů distribuce prostě není praktické. Pokud je toto určeno pouze pro kryptografy, tak ať se to děje v jejich uživatelském prostoru. A nezjednodušujme GPG, OpenSSL atd., aby každý řekl "chceme "skutečnou náhodnost" a nespokojíme se s málem." Můžeme mluvit o tom, jak poskytujeme rozhraní kryptografům, aby mohli získat informace, které potřebují, přístupem k primárním zdrojům šumu, odděleným a pojmenovaným, a možná se nějakým způsobem může zdroj šumu autentizovat v knihovně nebo aplikaci uživatelského prostoru."
Diskutovalo se o tom, jak by takové rozhraní mohlo vypadat, protože například některé události mohou mít bezpečnostní důsledky. Cao poznamenal, že kódy skenování klávesnice (tj. úhozy) jsou zamíchány do fondu jako součást shromažďování entropie: "Přenést to do uživatelského prostoru, dokonce i prostřednictvím privilegovaného systémového volání, by bylo přinejmenším nemoudré." Je docela možné, že jiné načasování událostí může způsobit nějaký druh úniku informací postranními kanály.
Zdá se tedy, že dlouhodobý problém s linuxovým subsystémem náhodných čísel je na cestě k řešení. Změny, kterými subsystém náhodných čísel nedávno prošel, ve skutečnosti vedly pouze k problémům s DoS při jeho používání. Nyní existují účinné způsoby, jak získat nejlepší náhodná čísla, která může jádro poskytnout. Pokud je TRNG na Linuxu stále žádoucí, pak bude třeba tento nedostatek v budoucnu vyřešit, ale s největší pravděpodobností to nebude provedeno v samotném jádře.
Nějaké inzeráty 🙂
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ého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com