Názory k článku Jak slabou entropií vznikly faktorizovatelné RSA klíče

Něco mi to silně připomíná. HW bez zdroje entropie, jediná měnící se hodnota, kterou vidí programátor, je tak počet sekund od bootu. Navíc zákazník měl požadavky na náhodnost dat, do kterých se promítalo asi tak (jenom) 1000 vygenerovaných hodnot. Náhodnost se iniciovala až při prvním použití, takže aspoň nějaká náhodnost tam byla, a proto občas neprošel test náhodnosti (při strojových testech běžel tento test až po několika minutách po bootu). Naštěstí to nebylo nic s šifrováním.

Tak tohle je naprosto klasický problém, a i popis toho, jak přemýšlel HW inženýr poměrně sedí. Od jisté doby přidávám do obvodového návrhu dva obyčejné tranzistory, a za pár korun se tím vytvoří pořádný generátor na bázi lavinového průrazu. Místa na PCB to v SMD moc nezabere, a ušetří to značné problémy s generováním náhodných čísel. Při čtení poznámky o warningu ohledně asynchronní logiky mi to připomělo stejný warning, který na mě ohledně asynchronní logiky vyhodilo ISE při pokusu implementovat vícero LFSR na generování náhody uvnitř do FPGA. Jo, a opravdu to moc dobře nefungovalo, a ovlivňovalo vedle položené obvody. Ani když jsem to posunul floorplanem kousek vedle to nebylo úplně ideální.

Je možné najít někde schéma, prosím?

Daj si najst napriklad generator bieleho sumu.

Inak existuju aj specialne sumove diody (Vyber toho najhorsievo diodoveho odpadu)
dobre su napriklad Ruske usmernovacky.

http://cs.wikipedia.org/wiki/%C5%A0umov%C3%BD_gener%C3%A1tor Tie schemicky co tam su staci doplnit niecim co z toho spravy LVTTL vystup.

Ano, je to tento typ zapojení. Je pravda, že potřebuje trochu větší napětí, což je jasné z principu funkce. Pro praktické provedení se někde vhodné napětí "ukradne" od měničů pulsních zdrojů nebo měničů I/O obvodů, jako právě v případě na obrázku, kde se vhodně využívá zdroj od MAX232. Pokud takové napájení k dispozici není, zbytečně by to prodražovalo desku a použije se jiné řešení (šum přechodu diody, nebo cokoliv od A/D převodů - mikrofon, vzorkování basebandu atd., nebo i jenom úrovně signálů z RF modulů pro dodání alespoň nějaké entropie).

Konkrétní řešení mívá konkrétní možnosti - používám většinou tohle, protože potřebné napětí vždy z nějakého pulsního zdroje lze odvodit.

Pokial bopuzijes "lepsie" suciastky da sa to riesit aj z mensim napetim.

1.) Ak pouzijes komparator namiesto tej baterie inventorou. Moze byt napajanie sumoveho clanku nizsie (Tu je to z dovodu vysokeho rozkmytu. Ktory musi byt vyssi ako je sirka pasma neurcitosti http://www.interfacebus.com/voltage_LV_threshold.html)
2.) Pouzijes vyssie zosilnenie.

Když už to startuje s UI, tak ať se využuje lidského faktoru - hebání myší, napsat nesmysly, doba do stisku tlačítka apod. Použít ticks od bootu je spíš lenost a blbost.

S lenosti bych souhlasil, jeste bych dodal nepozornost. Ovsem tvoji - pri cteni clanku.

Kontrolni otazka: O jakych zarizenich se celou dobu psalo?

I v embedded zarizenich muze bezet operacni system ala openWrt(na to staci v ocesane verzi 2MB ROM/8MB RAM a 120MHz procesor, dneska veci za par dolaru). To generovani klicu se muze nechat az na prvni prihlaseni operatora (pres SSH na konsoli, pripadne pres webclienta). Do te doby by to byla jen mrtva krabicka, ktera ceka na iniciaci. Sice opruz, ale za tu bezpecnost to stoji.

Pokud budete počítat entropii ze sekund od spuštění do prvního přihlášení, bude taky velice nedostatečná. Na druhou stranu si dovedu představit, že by to entropii mohlo brát třeba z provozu na síti.

Pokud se budete prihlasovat na weboveho klienta prez https, pripadne prez ssh, tak uz musite mit vygenerovane klice...

Tak je pregeneruji po prvnim prihlaseni uzivatele. Pekne wizard-styl jako z windows. Next, next, next, hejbejte mysi dokud progress bar nedojede na konec, kliknout tlacitko. To jde s pomovi trochy html a javascriptu udelat docela pekne.

Jde to i pres SSH - po prvnim prihlaseni admina se muze spustit programek, ktery po vas bude chtit, abyste busili do klavesnice dokud nerekne 'DOST' a pak vas nucene odhlasi a pregeneruje klice.

Rozdíl mezi prodejní cenou a výrobní cenou = profit. Jednočip navíc je setsakramentsky drahá sranda na to, aby jen generoval náhodná čísla. Jsou i jednodušší řešení externího HW RNG, ale zase jsou prostě dražší než ho tam a) nedat vůbec, b) zkusit to implementovat v rámci SoC, ASIC nebo FPGA, protože to ve výrobě nic nestojí. Proto se vybírá za b.

I 10 Kč u zařízení, které stojí řádově dvě tři stovky, je hodně.

Varianta b se osvědčila, ale mnoho výrobců dalo přednost variantě a a v tom je ten problém.

Co by se stalo, kdyby tam v továrně při flashování firmware do každého zařízení dali párbajtový náhodný seed? Nevyžaduje to žádný přídavný HW → levné.

suhlas, to bola prva vec, ktora ma napadla (kedysi davno som sa uz s tymto problemom stretol), v kazdom mikrokontroleri sa najde kus flash, kde sa da pri zastcit kus individualnej nasady pre generator + kus volnej ram, kde sa uz da za prevadzky poskladat dalsi kus 'nahody' - mac adresy zariadeni, cas, doba prihlasenia atd. Problem je len v tom, kravatak samozrejme zorganizuje vyrobu v cine a tam by individualne flashovanie stalo o 0.1 centa navyse (ak by sa mu to vobec podarilo tym kitajcom vysvetlit, o co vobec ide), co by nasledne sposobilo, ze by si nemohol kupit kazdy druhy rok novu velku kravu za 5 melonov zo spotrebou 20L/100km.

ale generovaie tohoto by stalo peniaze a pri kontrole flash by robilo problemy ze cast pamete moze byt lubovolna.

Celkovo taketo riesenie by IMAO stalo viac ako tam drbnut ATtiny z sumovym generatorom + mikrofon ;-)

Tento nazor celkom nezdielam, po naprogramovani resp. pri vlastnej kontrole integrity pri starte staci spocitat pri verifikacii kontrolnu sumu len po urcitu hranicu (ak neberiem do uvahy, ze po naprogramovani sa da skontrolovat obraz vo flash voci originalu, ktory v tom okamziku este mam k dispozicii).
HW riesenie je VZDY drahsie ako implentacia v SW - plac na plosnom spoji, spolahlivost - pribudne zopar suciastok a niekolko letovanych spojov, procesor a mikrofon daco stoja, mikrofon asi nebude v SMD atd. - zo skusenosti mozem potvrdit, ze sa akakolvek zmena/rozsirenie v HW prejavi minimalne v trojnasobku jej ceny vo finalnom vyrobku.