Názory k článku Zůstává elektronický podpis bezpečný?

Jak říkávám na přednáškách - slušnost je alespoň jeden dotaz nebo komentář, a tak tedy začnu.

1).. z toho plyne, že jsou schopni kolidující bloky o 128 bytech umístit kamkoliv mezi 64bytové úseky jedné zprávy ...
to sice ano, ale příslušný inicializační vektor je jen 64 bitů, a tak stačí kolidujicí zprávy vkládat za text, který je násobkem 64-bitových bloků...

2) s tím útokem na certifikáty (Lenstra, Wang, Weger) to není tak jednoduché, jak to prezentujete.
Bud musíte spolupracovat s autoritou (jako ve zminenenm clanku, kde autori za tim ucelem si poridili "vlastni") nebo (a to je ten problem) musí byt splneny nasledujici dve podminky (coz obecne nejsou :-( .. ).
- Data v certifikatu do mista kam se vklada verejny klic (ktery pouzijete k zamaskovani kolize) musi byt delitelna 64 bity
- (!) Musite znat data v certifikatu az do mista, kde chcete vlozit kolizni blok. Z techto dat spoctete inicializacni vektor a pak TEPRVE pripravite ty dve kolizni zpravy (verejne klice). Jenze tato data do vydani certifikatu neznate ....
Jinymi slovy netreba se bat ... :-).

3) Vyhláška 366/2001 Sb, ... doplnim ,
a) MD5 neni povolena ani v pripade pouziti prostredku pro bezpecne vytvareni a overovani zarucenych elektronickych podpisu
b) chysta se novela teto vyhlasky (bude reagovat i na vydavani kvalifikovanych casovych razitek a dalsi kvalifikovane certifikacni sluzby)

4) ... ale viníkem je nepochybně ta ze stran, která zprávu zformátovala ...
Tady a dale by se dalo diskutovat.
Co je napr. formatujcici strana ?
Navic sam píšete, že vzdy potrebujete pro kolizi mit moznost vytvaret oba texty --- jinak tam zatim tu kolizi nedostanete (viz. kolize prvniho a druheho druhu).
Chapu-li formatujici stranu toho, kdo text pripravuje - pak je tvrzeni o vine ponekud striktni. Co kdyz dotycny pripravuje svuj text na SW, ktery tam kolidujici blok vypocte a na vhodne misto vlozi bez jeho vedomi ?


5) K některým aspektům (aktualni stav, moznost zneuziti) hašovacích funckí doporučují výborný česky psaný dvoudílný článek Vlastika Klímy - Co se stalo s hašovacími funkcemi ? (Crypto-World 3/2005 a Crypto-World 4/2005, http://crypto-world.info )

K poznámce 4) - to přece znamená, že když máte na počítači virus (který to dělá), tak potom za všechno můžete VY.
Konečně se k tomuto problému propracovali i kryptologové!

ad 1) Ježíši - na co jsem myslel - máte samozřejmě pravdu :-) !!!! Mea culpa, mea maxima culpa!

ad 2) Ano souhlasim, jen znovu pripomenu, ze ten problem je opravdu dvoji. Nejen, ze musite uhodnout jak bude vypadat "obsah" certifikatu vcetne jeho serioveho cisla, ale protoze kolizi muzete vlozit jen po 64 bytech (:-) , a kolizni vypocteny blok musite vlozit do mista verejneho klice, je zde jeste problem s tim, aby zacatek certifikatu až do mista kolizniho bloku byl te spravne delky ... Inu spoluprace s CA by to zajistila, bez ni trochu moc potizi...

ad 3)a) MIČR mělo ... Takovou povinnost MIČR nemá ...
b) MD5 se tam dostala pouze z duvodu kompatibility, jiz tehdy v roce 2001 byla "vyhozena" vzdy, kdy se jednalo o vyssi bezpecnost - tj. neni ve schematech pouzivnych u poskytovatle a u SSCD (prostredku pro bezpecne vytvareni a overovani podpisu). Pokud nepouzivate SSCD jsou mozne i jine utoky, ktere jsou zname a nepotrebujete k tomu MD5 (v casti 4 o nich take sam pisete, proste se da podvrhnout k podpisu otisk jine zpravy). Takze tim "vcasnym zakazem" MD5 nic nezachranite ....
c) navic nalijme si ciste kavy - jeste stale prakticke utoky na zaklade kolizi prvniho radu u MD5 moc nehrozi... Jen si vzpomente, jak dlouho od zverejneni kolizi trvalo nez bylo zverejneno mozne vyuziti k "rozumnemu utoku" (priklad studenta MFF UK Mikle-Barata).
d) MI ČR bych za to tedy nepranyroval. Pockejme si na novelu. To leto 2005 mne osobne staci. Spise by mely postupne zacit reagovat provozovatele prislusnych aplikaci... V otazkach bezpecnosti se prece neceka na vyhlasky ministerstev, ale reaguje se na aktualni stav.
e) Z duvodu pod pismenem d) bych si dovolil pranyrovat agendy, kde se zjevne nedba na bezpecnost a na aktualni stav "poznani"... Např. Česká správa sociálního zabezpečení používá RSA klíč o délce 512 bitů (a je to root certifikát CA !). Byl vydán 15.6.2004 s platností 10 let. To, že lze modul délky 512 bitů faktoritovat - ví již každé malé dítě .... Kdo nevěří - může se přesvědčit zde : http://www.cssz.cz/tiskopisy/ELDP_2004/CSSZ_CA_CERT.cer .

4)Jen poznámka k : ".... Je možné, že v elektronickém světě se stane zvykem připojovat do podpisovaného obsahu informace typu "Zpráva.... ".
Již jsem viděl návrhy, aby bylo v certifikátu uvedeno, že uživatel prohlašuje, že používá SSCD nebo se take pouziva extenze, ktera presne specifukuje pouzity SW uzivatele... To by take mohlo byt elegantnim resenim...

5) Take s vami sdilim nazor, ze nam SHA1 jeste chvili vydrzi ... Nicmene cisti kryptologove ji již odepisuji ze sveho jidelnicku a maji k tomu duvody o kterych Klima pise.
Oficialni doporuceni co dale a co do kdy pouzivat nam da asi NISTem pořádaný Cryptographic Hash Workshop (Oct. 31-Nov. 1, 2005).
http://www.nist.gov/hash-function

Zdravím a děkuji za pětinásobnou slušnost.

1) Já zatím žiji v domnění, že ty nekolidující meziúseky zprávy musí být 64 bytové (tj. 512 bitů) násobky, neboť MD5 pracuje s touto délkou vstupního bloku ?? Viz též citát: "This input to MD5 is an exact multiple of 512 bits" (Colliding X.509 Certificates, p.2). Též inicializační vektor MD5 jsou 4x32 bitů = 128 bitů. Nevylučuji ale, že se jedná o závadu na mém přijímači, MD5 je pro mne mrtvá věc a nepitval jsem to více než jsem měl dojem, že je třeba, ani se, obrazně řečeno, nepovažuji za patologa (skutečných i obrazných patologů si vážím).

2) Ano, to je pravda - je to hypotetický případ a jak to popisujete (až na těch 64bitů/bytů ??). V ČR např. toto u kvalifikovaných certifikátů nehrozí vůbec, protože se MD5 pro podpis certifikační autoritou vydávající kvalifikované certifikáty používat nesmí (což v článku je)! U těch CA, které MD5 používají, si však hypoteticky můžete vyzkoušet, jakým způsobem zpracovává ta která certifikační autorita žádosti o certifikát a připravit si svá data do příští žádosti tak, aby to sedlo. Pak by nemusela spolupracovat. Je ale fakt, že v úvodu certifikátu X.509 zpravidla bývá číslo certifikátu, které nemusíte trefit, zejména pokud ho CA generuje náhodně, což některé CA dělají, aby se nevědělo kolik zákazníků vlastně mají => v praxi to bez spolupráce s CA půjde jen velmi těžko. Podrobný rozbor případu jsem neuváděl, protože nebylo místo - i takhle bylo článek nutné rozdělit do dvou dílů. Příklad je kromě své fotogeničnosti zajímavý však tím, že ukazuje, že v praxi přeci jen lze zneužít i kolize smysluplných "náhodných dat" (dle obr.4), což intuitivně není samozřejmé. Kolize v binárních datech, obrázcích nebo exe kódech, si asi představíme spíš.

3) Myslím si, že pokud hovoříte o vyhlášce týkající se provozu certifikačních autorit (vydání vyhlášky zmocněné loňskou novelou ZoEP), tak ta bude příliš pozdě - až někdy v létě 2005. MIČR by podle mne mělo ohledně MD5 učinit něco již dříve - aspoň dát do svých FAQ na web něco ve smyslu, že se MD5 nedoporučuje. Možná pak má ještě MIČR nějaké jiné možnosti oficiálního zveřejňování - aspoň to vydat formou tiskové zprávy, prostě aby to bylo veřejně oficiálně známo. Není třeba panikařit, ale úřední tempo půl roku žádná doba také není adekvátní. MIČR mělo ohledně MD5 reagovat asi již v září-říjnu 2004.

4) V článku zde (skutečně záměrně) používám edukační metodu "od jednoduššího ke složitějšímu". Myslím, že o odstavec níže v článku to je dostatečně upřesněno.

Vámi uvedené podvržení podpisovaného obsahu je pak jednou z nejvážnějších hrozeb právní nepopiratelnosti e-podpisu vůbec (nepotřebujete ani vytvářet kolize haší :-). Do značné míry to lze eliminovat prostředkem pro bezpečné vytváření podpisu, jehož prostředím je bezpečná aplikace vytvářející podpis, jejímž prostředím je přiměřeně bezpečný operační systém. Což je v článku doporučeno. Lze-li pak eliminovat podvržení obecně, lze eliminovat i podvržení kolidujících součástí a důvěryhodně uvést i formátující stranu.

Přesto jsem si vědom, že "formátující strana" je trochu vágní pojem, který v mezinárodních normách a specifikacích není (zatím ?) obsažen. Berte to jako invenci tohoto článku o něčem takovém uvažovat. V právních textech jako jsou smlouvy je rovněž zvykem připojovat některé chronické zaříkávací formule typu "zde neupravené záležitosti se řídí občanským zákoníkem ČR" apod., které nenesou podstatnou informaci daného dokumentu, ale přesto jsou kvůli právním důvodům připojeny. Je možné, že v elektronickém světě se stane zvykem připojovat do podpisovaného obsahu informace typu "Zpráva byla zformátována na počítači podpisujícího s procesorem 9990123 aplikací Neprustrelna Build 1". Pochopitelně, že to nemá sloužit jako náhrada síly hašovací funkce, ale takové údaje mohou mít relevanci při právním projednávání obecně a v situaci nejistoty ohledně SHA-1 jako (doufejme nadbytečná) pojistka.

Obecně ja pak lepší, když podpisující aplikace pracuje off-line a podpisující má možnost zprávu před odesláním nahlédnout ještě nějakou jinou aplikací (ideálně na jiném compu bez síťového rozhraní :-).

5) Aha, ty jsem nečetl a číslo (4) zatím ani neregistrován nemohu. Článek na Lupě měl též nějakou dobu v redakční frontě. Většina odkazů i informací však přesto myslím je též v odkázané Klímově přednášce z Cryptofestu (doufám, že kašel už přešel). Co se čísla (3) týče, byl bych méně přísný na SHA-2, protože to, že nemají pravděpodobnostní vlastnosti náhodného orákula je sice matematická vada na kráse, ale pokud budou odolávat nalezení kolizí, tak to (aspoň pro e-podpis) stačí. Pokud vím, k většině algoritmů PKI existují útoky s nižší výpočetní náročností než je hrubá síla, což se kompenzuje zvětšováním délky klíče a nikoliv zavrhováním algoritmů. Protože pak nic jiného než SHA-2 není a v dohledné době nebude, doporučuji ve svém článku migraci na SHA-2. Kdybych napsal do veřejného článku zde na Lupě, že se loučíme s SHA-1, tak asi vypukne panika. Nevím, zda-li je to realistické hodnocení situace?? Jinak vzdávám V.Klímovi zasloužený hold, snad to i plyne z toho článku.

3a) Podíval jsem se do předpisů a zřejmě máte pravdu, že z nich tato povinnost pro MIČR neplyne přímo. Ovšem také existuje zákon 82/1998 Sb. o odpovědnosti (státu) mj. za nesprávné úřední postupy. ZoEP je esenciálně zákon o používání e-podpisu ve veřejnoprávní oblasti a pokud by někdo ve styku s úřady nyní dokázal využít kolizi MD5 nějak ve svůj prospěch, nebo tak, že mu tím naopak nějak vznikne (třeba i jakoby) škoda, tak při situaci, že MD5 je uvedeno tak jak je - v platné vyhlášce, by za to normální soud odsoudil stát. Nehovořím zde o nějakém triviálním útoku, ale o nějaké zamotané situaci ala Lauder a licence TV Nova, kde stát nakonec také doplatil na (ne)činnost jednoho regulačního orgánu. V oblasti e-podpisu je bezesporu hlavním dozorujícím úřadem nyní MIČR, uvedenou vyhlášku včetně zmocnění ji měnit podědilo od ÚOOÚ pak právě a jen MIČR.

3b) To víme zde neoficiálně my dva a pak ještě dalších pár lidí v ČR, ve vyhlášce 366/2001 Sb. není, že je tam MD5 jen kvůli zpětné kompatibilitě. Nepoužívání SSCD a kolize MD5 jsou dvě různé věci. Že se státu v roce 2000 do používání SSCD nechtělo (když nebyly ani jeho PP) je vážně jiná věc.

3c) Ano, ty útoky jak proti MD5 tak proti SHA-1 nejsou totálně horké, nicméně kolize MD5 na notebooku za 8 hodin s libovolným inicializačním vektorem jsou na mě přeci jen trochu moc. Prodlevu publikace útoků bych pak nebral jako velké kritérium, protože jednak nějakou dobu trvá, než se napíšou a opublikují (tím se útočník nezdržuje), jednak v krypto působí spousta subjektů, které nepublikují vůbec. Také je to věc motivace.

3d) Já ano. Existence MIČR nemá opodstatnění, pokud nechá každý subjekt státní/veřejné správy ve štychu, aby si všechno dělal sám. Já si myslím, že existence MIČR může mít svůj dobrý účel a nejsem pro jeho rušení a převádění věcí na Úřad vlády (který zmůže úplné nic), ale takhle se světovosti ani v českém měřítku nedopracují.

3e) Zajímavé. Ten certifikát ovšem není pro vydávání kvalifikovaných certifikátů, ergo mohou být použity jen pro vnitřní účely provozu ČSSZ. Pokud s ním nějak komunikují navenek, tak asi porušují § 11 ZoEP. Pokud vím, panují okolo toho na ČSSZ nějaké zmatky, protože když podáváte ELDP přes portál, tak buďto musíte mít certifikát I.CA a pak to snad stačí, anebo musíte mít jejich a pak ještě musíte něco dalšího dělat (asi to jít ještě podepsat vlastnoručně). Adepti na to koupit si moji studii.

4) Certifikační politiky "QCP Public + SSCD" jsou již nějakou dobu součástí specifikací ETSI. SSCD buďto může vydávat přímo CA, nebo si uživatel koupí SSCD jinde a předloží CA osvědčení, že používá SSCD. Myslím, že to není ve fází návrhů, ale (skoro běžné) praxe. Snad i GlobalSign. Zahrnout do certifikátu aplikaci asi nejde, pokud tedy není SSCD nějaký jednoúčelový přístroj. Spíše se může aplikace někam zanést do podpisovaných atributů.

5) Pozvali již Klímu?

3c) Ta prodleva byla dana tim, ze najit realizovatelny utok zalozeny na kolizi prveho radu (a zpocatku jen s vyuzitim publikovanych kolizi) neni tak jednoduche ...

3e) CA ČSSZ vydavá certifikáty, kterým firmy mohou šifrovat svá data, posílaná ČSSZ. Tento certifkat má také RSA klič velký jen 512 bitů. Dobré zabezpečení, že ? Takový certifikátů najdete např. zde http://www.cssz.cz/tiskopisy/ELDP_2004/sifrovaci-certifikat.cer.
Vtip je v tom, že šifrování ZoEP neupravuje (a ani to nemá za cíl). Tedy není nutné (a dokonce není možné) používat kvalifikovaný certifikát. Jiná věc je, že se shodneme, že by měla být používána bezpečná komunikace .... Bohužel jak vidite neni jaksi vynutitelna :-).
Vaši studii bohužel neznám (na můj vkus příliš drahá). My si hrajeme v duchu Open Source i na "Open Informace".
Mimo e-zinu, ktery vytvarime a rozesilame zdarma (Crypto-World) jsem proto pro zajemce uvolnil i knihu Elektronicky podpis a umistil ji v pdf formatu na svuj web ke stazeni (samozrejme po dohode s nakladatelstvím, kde vysla a musel jsem nejakou dobu pockat)...
http://www.crypto-world.info/kniha/

4) Myslite si, ze kdyz si koupite SSCD na Slovensku nebo ve Francii, ze automaticky je to SSCD podle nasi legislativy ?

5) Pozvanka je jedna vec, ale kdo Vam zaplati letenku, ubytovani a polatek :-).

3e) Šifrování skutečně není povinné, aspoň ne v rámci oblasti podpisu. ... 10kKč nejsou v komerčním světě za konzultační text (400+ stran) podstatné peníze. Kdo si váží svého času, pro toho to je velmi rozumná investice. Vydal bych to i jako knihu, kdyby byl někdo, kdo to zaplatí an bloc, z autorských honorářů se to nedá. Rozumím Vašim pohnutkám s crypto-worldem, ale měli jste a máte zaměstnavatele, kteří Vám zaplatí aspoň běžný životní standard (věřím) i veškeré režie kolem a zároveň tolerují publikace. Já jsem solitér, notabene oblast je především věc veřejnoprávní a protože "podnikavý duch" úřady rozhodně nevládne, není snadné to vůbec někde udat (i kdyby to bylo zadarmo jako jsou nyní certifikáty obcím). Vaši knihu mám koupenu, přidal jsem ale Vaše URLko na Téma > e-podpis > odkazy.

4) Pokud by ty státy měly příslušné části svých předpisů v souladu s evropskými předpisy (směrnicí a navazujícími) tak ano, pak je SSCD pan-evropské! Slováci tuhle část nemají v souladu, my s odřenými ušima ano (SSCD je ale nepovinné jak víte). Evropská nekompatibilita je však, a to pořádně a všude, v akreditacích PCS, takže vám stejně SSCD nebude stačit.

5) No myslím, že třeba zrovna MIČR by mělo mít zájem na tom, aby bylo do budoucna schopné vydávat relevantní předpisy, tam někoho z ČR poslat. A nemůžou tam poslat (jen) úředníka, je to workshop a ne prezentace s rautem (otázka financování se nám opět vrací). Pokud by na to relativně chudé MIČR nemělo peníze, tak by možná mohlo mít MFČR, ti myslím mají z resortů nejsofistikovanější řešení podpisů a navíc sedí na penězích.

Přeji hezký víkend, už jsme tady nějak poslední.