Jaderné noviny – 13. 3. 2014: Hardwarové generátory náhodných čísel a bezpečnost (diskuse)

[ndd]

pokud máme počáteční tajný stav zdroje X a útočníkem podstrčená data Y

přimíchání nemůže nikdy odstranit neznámost obsahu zdroje, může ji jedině přidat.

Ibaze ten zdroj je pre procesor znamy. A ked bude Intel velmi zakerny, tak moze kludne RDSEED implementovat tak, ze bude vracat presne rovnake cisla ako iny zdroj entropie (napr. bude pocitat s nejakym vzorom pristupu do pamate). Pri XORe nam taky nahodny generator bude vracat napr. same nuly alebo co chceme.

V zaujme bezpecnosti to mozeme obmedzit tak, ze bude nejaky seed MAC adresa sietovky (napriklad) - ta sa da vzdialene zistit a hned mozeme generovat rovnake nahodne cisla ako ten pocitac.

Naproti tomu ma nenapada rozumny sposob, ako by procesor mohol ovplyvnit nahodnost jemu znamych pseudonahodnych cisel bez svojej instrukcie - mohol by sice nieco "zle spocitat", ale to je velmi napadne.

[chrono]

Ak by také niečo dokázal pri inštrukcii RDSEED, tak by si s tým určite poradil aj bez nej.

[ndd]

Ako bez zvysenia narocnosti?

[chrono]

Ak by pri tej inštrukcii dokázal zistiť, kde má OS uložené údaje, ktoré potom bude chcieť zmanipulovať, tak to určite dokáže aj bez tej inštrukcie.

[ndd]

Lenze priama manipulacia "vypoctovych vysledkov" je velmi nachylna na nahodne objavenie, na rozdiel od manipulacie vysledku nejakej instrukcie, ktora ma aj tak vracat nahodne data. Alebo to chces robit inak?

[Zopper]

Jedna věc je provést útok stylem "vygeneruju predikovatelnou hodnotu", druhá věc je znát kompletní stav systému. Pokud by ten CPU mohl zjistit, co je aktuálně v poolu (a tedy dokázal interpretovat linuxové jádro, kde je který paměťový prostor...), tak nepotřebuješ takhle oslabovat generátor, stačí natvrdo přepsat pool nulama (či náhodně vypadající hodnotou) a zvýšit hodnotu entropie.

A nebo udělat jakýkoliv jiný útok, protože pokud ví co a jak, tak v tuhle chvíli má to CPU větší možnosti, než root. Jinak, tohle je právě to, proč vznikla petice [1] za odstranění RdRand z jádra, kterou Linus odmítl.

[1] http://www.change.org/en-GB/petitions/linus-torvalds-remove-rdrand-from-dev-random-4

[ndd]

Nemusi vediet plne interpretovat Linuxove jadro. Staci, ked sa nauci (vymyslim si), ze pristup postupne na adresy x az x+19 a na kazdej nejaky shift, bitovy OR a XOR ma pouzit k vygenerovaniu "svojej" hodnoty. Zhodou okolnosti nemusi ist o generator nahodnych cisel - prepisanie "nenahodnych" hodnot nulami by bolo asi programatormi rychlo odhalene. Ked sa na zaklade hodnot vrati iny vysledok "nahodneho cisla", tak to nie je az take napadne.

[Jirka W.]

Pověsit škodlivý kód na instrukci, kterou uživatel vůbec nemusí použít, by moc rozumné nebylo. To je, jako by se počítačový vir přidal do seznamu nainstalovaných programů s možností odinstalace. Kdyby chtěl Intel ovlivňovat výsledky generátoru náhodných čísel, udělá to tak, aby tomu nemohl uživatel zabránit.

[ndd]

Ibaze robit nieco v PC tak, aby tomu uzivatel nemohol zabranit, to dost dobre nejde. Ked to teda ma zaroven fungovat. Kludne navrhnite riesenie - to moje predchadzajuce je trivialne a myslim, ze by to Intel zvladol kludne implementovat.

[chrono]

Lenže to by procesor musel vedieť, aké sú tie údaje veľké, kde sa nachádzajú, čo sa s nimi bude robiť (aby to vygenerovanie hodnoty malo želaný účinok)... Ak by také niečo dokázali, tak by určite mohli urobiť čokoľvek (napr. odlíšiť tú časť, ktorá kontroluje, či generované náhodné údaje nie sú nejako upravované).

[Jendа]

Pokud tam je tohle

if (!arch_get_random_long(&v))
  break;
hash.l[i] ^= v;

(což se nejspíš přeloží jako RDRAND a pak hned XOR s něčím), tak není potřeba přílišná invence, aby procesor zjistil, co se asi stane…

(napr. odlíšiť tú časť, ktorá kontroluje, či generované náhodné údaje nie sú nejako upravované)

To mi přijde jako mnohem složitější (udělat to tak, aby na to brzo někdo nepřišel).

[chrono]

Predpokladám, že to, že kód využívajúci tú funkciu musí vyzerať práve takto a nikdy inak, je popísané v nejakej dokumentácii, aby to jednotlivé OS mohli správne implementovať. :)

[Jendа]

V případě potřeby se detekce opraví updatem mikrokódu.

[ndd]

+1; uz som sa bal, ze to napadlo len mna.

[chrono]

Takže vlastne stačí upraviť ten kód a zakázať aktualizáciu mikrokódu procesoru a problém je vyriešený. :)

[Jendа]

Pověsit škodlivý kód na instrukci, kterou uživatel vůbec nemusí použít, by moc rozumné nebylo.

Zajímavé. Přitom se šíří spousta škodlivého software přes e-maily, které uživatel vůbec nemusí otevřít, webové stránky, které uživatel vůbec nemusí navštívit…