Vlákno názorů k článku
Důkaz bezpečnosti linuxového generátoru náhodných čísel od Uncaught ReferenceError: - byly časy, kdy jsme měli monitoring na množství...

byly časy, kdy jsme měli monitoring na množství entropie a u serverů, které generovaly klíče nebo terminovaly šifrované kanály se to kontrolovalo, hlavně přestaly služby fungovat, když entropie klesla pod určitou úroveň. Dnes vše běží z VM strojů někde v kontejnerech, spousty stavů se jim fejkuje hypervizorem/su­pervizorem a vlastně nikdo neví jak moc dobře se ty náhodná čísla generují a z čeho.

Najednou na jednom AMD serveru běží 200 VM a každý si nějaká čísla generuje z toho málo co má k dispozici a ono to nějak funguje. Řekl bych, že v tomhle odvětví máme ještě nějaké dodělávky...

Tak monitorovat entropii můžete stále přes /proc/sys/ker­nel/random/en­tropy_avail. S těmi VM máte pravdu. Většinou se nedostatek entropie a blokování /dev/random řeší přechodem na /dev/urandom, které se neblokuje, ale entropii z ničeho prostě nevyrobí.

ano, entropie se z ničeho nevyrobí, to jsem chtěl říct. Monitorovat samozřejmě lze, ale už nepoznáš jak ten vstup je kvalitní a jak entropie je vlastně entropická, že.

Dnes ale snad na žádném systému na tohle nemáme žádnou kontrolu, najednou o tom admini neví a nějak to funguje na pozadí. To mě trochu zaráží.

Ještě moje malá chyba, od jádra asi 5.6 se /dev/random už neblokuje. Používá se "CPU Jitter RNG", což si můžete představit jako smyčku jen s pár instrukcemi a měří se čas, za jaký se provede na spekulativním CPU. Ukazuje se, že to dává celkem dobrou entropii.

Pro jádra před 5.6 šlo nainstalovat balík haveged, který dělal vlastně totéž.
https://github.com/jirka-h/haveged

18. 9. 2024, 12:11 editováno autorem komentáře

A pozdeji i to prestalo mit smysl, entropy_avail je fixne 256...

Nastesti uz novejsi verze Javy /dev/random nepouzivaji, na OS nespolehaji a kryptograficky bezpecny generatory cisel maji v sobe.

V dobe Java8 bylo caste, ze se neco na siti uprdnulo, popadaly tisice konexi do DB a kdyz se aplikace snazila ty konexe obnovit tak zustala zablokovana a cekala na generator nahodnych cisel.

A je to tak dobre? V okrajovych pripadech to mohlo pomoct, ale ta Java prece jenom nema pristup k takovymu zdroji entropie jako kernel.

Jen tak na okraj: pres "entropy_avail" uz nic nenamonitorujete. Nevim pri jakem kernelu se to zmenilo, ale ted je tam uz vzdycky 256...

...5.10.119 plus vse okolo... viz konkretni commit odkazany vyse ;-)

Ono je těžké tu entropii někde vzít, když v systému není. Snad jen cíleně přidat nějaký harwarový zdroj náhodných dat.

Intel se to pokusil vyřešit instrukcí RDRAND. Ta ale z mě nejasných důvodů nezískala důvěru části Linuxových vývojářů. Tomu nějak nerozumím - procesoru jako takovému věří, ale téhle jedné instrukci ne. Tak snad vymyslet nějaké jiné řešení, ale jaké, aby si důvěru získalo?

nekde se psalo, ze te instrukci neveri, ale ze by se jeji data mohly pouzivat jako seed do vlastni kernelove random funkce.

Pokud si pamatuji dobře, tak Intel tehdy celkem silně tlačil na to, aby rdrand byl JEDINÝ zdroj entropie. Což spoustě lidí smrdělo nějakými zadními vrátky*, a vyvolalo to silnou protireakci. Navíc tou dobou to byla ještě novinka, nebylo úplně jasné, jak spolehlivé to celé je...

* On ten CPU má relativně omezené možnosti, jak škodit, aniž by to bylo hned poznat, a aby to bylo prakticky zneužitelné, bez fyzického přístupu. Ale zrovna u zabudovaného black-box RNG, je ta zneužtelnost i provedení mnohem jednodušší. Místo skutečně náhodných dat to může začít poskytovat známou sekvenci s nízkou entropíí, a triggerem může být spousta věcí, včetně času. A bude to prakticky nezjistitelné.

Ale ono to bolo aj dokazane ze ta Intel implementacia poskytuje nizku entropiu. Vygenerovane udaje sa daju testovat na rozne kvalitativne vlastnosti a bolo to velmi slabe. Ci to bolo urobene umyselne a s nejakou vnutornou logikou je iba spekulacia a je to v podstate jedno.

to by mohla byt dobra reklama, s nasi vps ziskavate pristup k hw generatoru random dat, a datacentrum by zastrkalo do hostitelskeho zeleza treba truerng

Normalne to nektere hostingy nabizi pripadne cmoud provideri.
Netreba nic strkat do klientskeho zeleza. Je to skatule do racku jako kazda jina se sitovym pripojenim.

Dneska se to resi specializovanym HW pripadne pro chude a zebrajici jako cmoudova sluzba. Kde vam dodavatel toho HW garantuje uroven entropie. Nekde je to i primo vyzadovano (vc seznamu overenych reseni) pro sluzby ktere musi mit vysoke zabezpeceni.
Je pak uplne jedno jestli je to virtual nebo ne. Toho HW se zepta po siti na nahodne cislo.

Tahle reseni typu "monitoring entropie" jsou zase typickym obchazenim spravneho reseni - tzv. pojd na mne z boku.

nj. bavíme se o cca roku 2000, kdy jsme v bankovnictví začínali masivně zavádět šifrování, najít nějaký HRNG byla otázka spousty a spousty peněz.

Btw i u toho HRNG musíš povinně monitorovat, jestli ti zdroj entropie nedegraduje.

Zase 24 let v IT je... proste jina dimenze. Vyvoj tady jde kupredu rychle.... a nejvetsi nebezpeci v praxi jsou.... otroci minulosti, co si budem povidat, ze? ;-)

Rok 2000. To by odpovidalo resenim pojd na mne z boku

Jestli nekdo u HRNG ktere je soucasti HSM monitoruje entropii my to nejsme. Mozna by to vylitlo u selftestu z logu. HSM je certifikovano za nejakych podminek na omezeny cas. Budto se resi preklicovani nebo se vymeni za jinou skatuli.