Vyšlo na Lupě, 27.02.2017
Vytištěno z adresy: http://www.earchiv.cz/b17/b0227001.php3

SHA-1 není bezpečná, přesto se někde stále ještě používá

Úspěšný kolizní útok na hašovací funkci SHA-1 má zásadní dopady i do oblasti elektronických podpisů. Důrazně nám připomíná potřebu digitální kontinuity.

V závěru minulého týdne prošla odbornými médii zpráva o úspěšném kolizním útoku na hašovací funkci SHA-1. Mohli jste se o tom dočíst na mnoha místech (např. i zde na Rootu), proto jen velmi stručná a zjednodušená rekapitulace: spojenými silami Googlu a amsterodamského CWI se podařilo najít (vypočítat) způsob, jakým lze (již velmi rychle a snadno) vytvářet dvojice PDF dokumentů, které jsou vzájemně kolizní vzhledem k hašovací funkci SHA-1. Jinými slovy: dokumenty jsou různé, ale při použití hašovací funkce SHA-1 mají stejný otisk (hash, či: heš).

Jak co a jak přesně se podařilo, je čtením pro odborníky. Zde si snad vystačíme s velmi zjednodušenou představou: nejde o žádné „přímé prolomení hrubou silou“, ale o využití určité „zkratky“, navíc využívající konkrétních vlastností některých formátů elektronických dokumentů.

Konkrétně u formátu PDF se využívá toho, že kromě užitečného obsahu mohou mít konkrétní PDF dokumenty i poměrně velkou „vycpávku“, která se dá upravovat tak, aby při vkládání různého obsahu dokument stále vykazoval stejný otisk (při použití hašovací funkce SHA-1). To, co bylo nyní nalezeno, samozřejmě po dlouhých a náročných výpočtech, je základ takového PDF dokumentu, se kterým lze přesně toto dělat.

 
Stránka útoku Shattered
 

Praktické dopady si lze ukázat na prvních generátorech kolizních PDF dokumentů, které se velmi rychle objevily. Například tento (prý jen narychlo spíchnutý) vám umožní přijít se dvěma různými obrázky (musí být ve formátu JPG a do 64 kB), a z nich vám (prakticky ihned) vytvoří dva stejně velké soubory ve formátu PDF se stejným SHA-1 otiskem, ale s různým obsahem: každý z nich ukazuje jeden z obou vstupních obrázků.

Pro potřeby tohoto článku, a zejména pro názorné předvedení praktických důsledků, jsem si sám nechal vytvořit dva takovéto kolizní dokumenty: jeden s číslem 1, druhý s číslem 1000 (pro jejich vzájemné odlišení). Jde o soubory 1.pdf a 1000.pdf, které si můžete stáhnout v tomto ZIP balíčku i s jejich externím el. podpisem (viz dále).

 
Dva kolizní dokumentu - různé, ale se stejným otiskem
 

To, že oba PDF dokumenty (s různým obsahem) mají stejný SHA-1 otisk, si můžete ověřit pomocí libovolného nástroje, který takový otisk dokáže spočítat. V on-line podobě je jich k dispozici řada, zde je použit tento:

 
Dva kolizní dokumentu - různé, ale se stejným otiskem
 

Stejně tak si můžete sami vyzkoušet nový nástroj (file tester), který výzkumníci z Googlu a CWI sami zveřejnili a který slouží k odhalování takovýchto vzájemně kolizních dokumentů (tj. různých, ale se stejným SHA-1 otiskem). A to dokonce tak, že jim stačí jen jeden z obou (vzájemně kolizních) dokumentů.

 
Detekce kolizního dokumentu
 

Je to možné díky tomu, že jejich nástroj vlastně testuje, zda jde o PDF dokument, se kterým si někdo (zde konkrétně: použitý generátor kolizních dokumentů) „hrál“ tím způsobem, na který oni právě přišli. Zjednodušeně: zda jde o onen specifický „základ“ PDF dokumentu, do kterého byl vložen nějaký konkrétní obsah a současně byla upravena jeho „vycpávka“ tak, aby soubor ve formátu PDF měl jako celek stále stejný otisk.

Co znamená stejný otisk?

Když mají dva různé dokumenty stejný otisk, je to samozřejmě problém. Velký problém. Projevuje se obecně všude tam, kde se nepracuje přímo s celými soubory, ale jen s jejich otisky – protože pak je nejde rozlišit.

Například v nejrůznějších systémech pro práci se soubory a jejich verzemi se mohou shodné soubory detekovat právě podle jejich otisku. Ale pokud se již nelze spoléhat na to, že dva různé soubory mají různé otisky, přestává být takováto detekce použitelná.

Dalším velkým příkladem jsou elektronické podpisy: elektronické podepisování ve skutečnosti funguje (a musí fungovat) tak, že se podepisuje nikoli samotný (a libovolně veliký) podepisovaný soubor, ale až jeho otisk pevné (a „malé“) velikosti. Důsledky jistě již tušíte: pokud mají dva různé soubory stejný otisk, budou mít i stejný elektronický podpis – a tak již nepůjde rozlišit, který z nich byl původně podepsán.

Opět si to ukažme na konkrétním příkladu: jeden z výše popisovaných dokumentů jsem opatřil svým kvalifikovaným elektronickým podpisem, a to s využitím hašovací funkce SHA-1. Fakticky jsem tak podepsal otisk, který je pro oba soubory stejný (společný).

Abyste si mohli sami a snadno ověřit, že oba soubory (1.pdf a 1000.pdf) mají (při použití SHA-1) stejný elektronický podpis – a že je tedy vlastně jedno a nejde poznat, který z nich jsem původně podepsal – zvolil jsem variantu externího elektronického podpisu. V ZIP balíčku, který si můžete stáhnout a vyzkoušet, je tento externí el. podpis obsažen v souboru podpis.pkcs7.

Pro praktické ověření toho, že jeden podpis „pasuje“ k oběma různým (ale dle SHA-1 vzájemně kolizním) PDF souborům, samozřejmě potřebujete takový nástroj, který s externími podpisy umí pracovat. Moc jich dnes není, ale zkusit můžete třeba tento „unijní“ validátor. Jako „Signed file“ mu musíte zadat soubor s podpisem (tj. podpis.pkcs7), a jako podepsaný soubor pak postupně oba PDF soubory (1.pdf a 1000.pdf). V obou případech by měl být jeden a tentýž podpis vyhodnocen jako platný kvalifikovaný elektronický podpis kteréhokoli z obou PDF dokumentů (souborů). Takže opravdu nepoznáte, který z obou dokumentů jsem skutečně podepsal a který nikoli.

 
Oba dokumenty mají stejný (platný) podpis
 

Jak moc je to nebezpečné?

K dosud řečenému si ještě dodejme jeden důležitý aspekt: to, o co (zatím) jde, jsou kolize označované jako kolize prvního řádu. Tedy takové, v rámci kterých se hledají (nějaké) dva dokumenty, které mají různý obsah, ale stejný otisk (zde: otisk, realizovaný pomocí SHA-1). Ještě složitější je hledání kolizí druhého řádu: kdy již máte nějaký konkrétní dokument a k němu hledáte jiný dokument se stejným otiskem.

Praktické důsledky kolizí druhého řádu, konkrétně pro oblast elektronických podpisů, si zde lze představit ještě snáze než u kolizí prvního řádu: již máme elektronický dokument, který někdo jiný platně podepsal. Třeba nějaký dlužní úpis či smlouvu s konkrétním obsahem apod. Někdo se zlými úmysly ale k tomuto platně podepsanému dokumentu najde jiný dokument s jiným obsahem (například dlužní úpis na vyšší částku, smlouvu s jinými podmínkami apod.) a díky koliznímu charakteru obou dokumentů bude prezentovat nově nalezený dokument jako ten skutečně podepsaný. A pokud nebudou k dispozici nějaké jiné důkazy, ze samotných elektronických dokumentů nepůjde poznat, který z nich byl skutečně podepsán a na který byl podpis z jiného dokumentu pouze přenesen.

Nicméně i s kolizemi prvního řádu lze dělat různé podvody. Jen scénář musí být trochu jiný a složitější: ten, kdo by chtěl někoho podvést, si musí připravit dva vzájemně kolizní dokumenty s takovým obsahem, jaký k podvodu potřebuje. Pak musí přimět toho, koho chce podvést, aby podepsal jeden z nich. Pak může vzít jeho el. podpis a „přenést“ jej na druhý (kolizní) dokument.

Co s tím?

Právě popsané nebezpečí je sice reálné, ale lze se mu poměrně snadno vyhnout - včasným přechodem na používání „lepších“ (dokonalejších, propracovanějších a složitějších) hašovacích funkcí. To se ostatně netýká jen dnes probírané hašovací funkce SHA-1, ale obecně všech hašovacích funkcí – které „z něčeho většího“ (celého souboru) dělají „něco menšího“ (otisk/hash).

Jejich základní vlastností je to, aby vytváření otisku („otiskování“, hašování) bylo jen jednosměrné a aby ze samotného otisku nebylo možné zpětně sestavit původní dokument. To ostatně nejde už z principu: malý otisk (v případě SHA-1 jde o 20 bytů, resp. 160 bitů) nestačí na to, abyste podle něj vytvořili třeba několikamegabytový původní dokument. 

Proto nám v praxi jde o něco jiného: aby nebylo reálné najít dva (či více) různé dokumenty, které mají – při použití téže hašovací funkce - stejný otisk. To zase v principu musí jít, a takových dokumentů dokonce musí existovat opravdu velké množství (když se nebudeme omezovat jejich velikostí, pak dokonce nekonečně mnoho). Proto nám v praxi stačí něco slabšího: aby nebylo v silách aktuálně dostupných počítačů najít alespoň dva takové dokumenty dříve než za nějakou opravdu hodně dlouhou dobu (třeba nějaké desetitisíce let).

Jenže schopnosti počítačů velmi rychle rostou, a tak to, co by dnešním počítačům trvalo více jak ony desetitisíce let, by počítače zítřka mohly zvládnout třeba za hodinu. Nebo ještě rychleji, pokud se najde nějaká zkratka či jiný trik, jako právě nyní v případě hašovací funkce SHA-1.

Právě proto je nezbytně nutné postupně přecházet ze „starších“ hašovacích funkcí, ve smyslu méně náročných na složitost hledání kolizních dokumentů, na „novější“, které jsou spolehlivější, a hlavně podstatně náročnější na výpočetní složitost při hledání kolizních dokumentů. Stalo se tak již v případě ještě „starší“ hašovací funkce MD5, a stejně tak je tomu i u SHA-1. U ní je již delší dobu známo, že není dostatečně silná – a bylo jen otázkou času, kdy se objeví praktická možnost nalezení kolizních dokumentů v dostatečně krátkém čase. Nyní se tedy objevila.

Jak je to s přechodem u elektronických podpisů?

V případě elektronických podpisů došlo v ČR k přechodu od SHA-1 k novější rodině hashovacích funkcí SHA-2 (zahrnující varianty SHA-224, SHA-256, SHA384 a SHA-512) s přelomem let 2009 a 2010. Tehdy Ministerstvo vnitra „zavelelo“ k takovémuto přechodu těm subjektům, kterým to mohlo přikázat (kvalifikovaným certifikačním autoritám).

Kvalifikovaní poskytovatelé certifikačních služeb ukončí vydávání kvalifikovaných certifikátů s algoritmem SHA-1 do 31. 12. 2009.

Pravdou je, že naše kvalifikované (resp. akreditované) autority od uvedené doby skutečně vydávají jen takové certifikáty, které se opírají o hašovací funkce z rodiny SHA-2, nejčastěji o SHA-256 (s velikostí otisku/hashe 256 bitů).

Musíme si ale uvědomit, že vydávání certifikátů „s SHA-2“ znamená pouze to, že samotná certifikační autorita použije hašovací funkci SHA-2 pro podepsání (označení) certifikátu, který vystavuje. Přesněji: z té části certifikátu, která je podepisována, vytvoří otisk již pomocí hašovací funkce SHA-2, a tento otisk podepíše (opatří svou značkou). To je pak zaznamenáno i v obsahu samotného certifikátu, viz následující obrázek. Vidíte na něm dva mé starší certifikáty: vlevo certifikát z roku 2004, při jehož vystavování byla ještě využita SHA-1. Vpravo certifikát z roku 2010, vystavený již s využitím SHA-2 (konkrétně SHA256).

 
Dva certifikáty: vlevo s SHA-1, vpravo s SHA-2
 

Podepisování není to samé jako vystavení certifikátu!

Pozor ale na jednu velmi důležitou věc: to, jestli byl váš certifikát vydán již s SHA-2, ještě nepředurčuje to, jaká hašovací funkce bude použita v případě, kdy budete podepisovat nějaký konkrétní dokument.

Plyne to i ze skutečnosti, že elektronický podpis můžete vytvořit (pomocí soukromého klíče) a jeho platnost ověřovat (pomocí veřejného klíče) i bez toho, abyste vůbec měli vystaven nějaký certifikát. Ten je ostatně jen jakýmsi osvědčením (od třetí důvěryhodné strany) o tom, komu patří soukromý klíč (kdo ho prohlašuje za svůj). Pokud svůj veřejný klíč osobně předáte někomu, kdo vás dobře zná, v zásadě váš certifikát ani nepotřebuje.

Jinými slovy: to, zda váš elektronický podpis využívá hašovací funkci SHA-1, některou z hašovacích funkcí SHA-2, či jakoukoli jinou, je nezávislé na tom, jaká hašovací funkce byla využita pro vystavení certifikátu. Ve skutečnosti záleží na tom, co a jak dělá (resp. jak je nastaven) ten program, který pro podepisování používáte.

Abych to názorně doložil, vytvořil jsem následující PDF dokument, který jsem opatřil pěti svými kvalifikovanými el. podpisy (založenými na stejném kvalifikovaném certifikátu s SHA-256). Každý z těchto podpisů ale byl vytvořen s použitím jiné hašovací funkce: po řadě MD5, SHA-1, SHA-256, SHA-384 a SHA-512.

 
PDF dokument s 5 kvalifikovanými el. podpisy, každý s jinou hašovací funkcí
 

Můžete si to sami ověřit. Třeba v Adobe Acrobat Readeru DC si můžete nechat zobrazit hašovací funkci, použitou při vytváření konkrétního el. podpisu, přes „Vlastnosti podpisu“ a „Další vlastnosti podpisu“, dle následujícího obrázku. 

 
Jak se v Adobe Readeru zjistí. jaká hašovací funkce byla použita pro podpis
 

Přitom právě Adobe Acrobat Reader je jedním z mála programů, které ještě umí vytvářet elektronické podpisy s využitím hašovací funkce SHA-1 (a dokonce i MD5). Právě tento program jsem ostatně použil pro vytvoření popisovaného příkladu souboru s 5 různými podpisy. Přitom jsem musel měnit nastavení programu podle návodu, který je popsán zde. Od verze 9.1 by Adobe Reader (dnes: Adobe Acrobat Reader DC) měl být defaultně nastaven tak, aby při podepisování používal hašovací funkci SHA-256, takže běžní uživatelé nemusí toto jeho nastavení měnit.

V případě podepisování dokumentů pomocí programů MS Office by (alespoň podle tohoto zdroje) mělo platit, že do verze 2010 jsou podpisy vytvářeny ještě s SHA-1 a v novějších verzích již s SHA-2. Případnou změnu nastavení lze provést způsobem popsaným zde.

Zajímavé je to ale i v dalších případech, jako třeba u podepisování zpráv elektronické pošty. I zde samozřejmě záleží na tom, jak je nastaven příslušný program. Například u MS Outlooku se hašovací funkce volí při volbě certifikátu pro podepisování, viz obrázek.

 
Nastavení hašovací funkce v MS Outlooku
 

U konkrétní zprávy si pak můžete nechat zobrazit použitou hašovací funkci postupem dle následujícího obrázku.

 
Jaká hašovací funkce byla použita při podepisování emailové zprávy?
 

Kdo stále ještě používá SHA-1?

U elektronických podpisů je tedy nutné dávat pozor na to, že způsob vydávání certifikátů a samotné podepisování jsou dvě různé věci: i když máte certifikát s SHA-2, stále záleží na tom, co a jak dělá ten program, který k podepisování používáte. A snad z výše popisovaného je dostatečně zřejmé, proč je navýsost vhodné již nepoužívat hašovací funkci SHA-1.

Pravdou je, že snad všechny (současné) programy pro podepisování, které znám a které jsou určeny pro „koncové uživatele“, již podporují funkce SHA-2 a jsou také nastaveny tak, aby je používaly (s výjimkou podepisování v MS Office ve verzích do 2010 včetně, viz výše). A to proto, že jejich autoři si včas uvědomili potřebu přechodu od SHA-1 k SHA-2 a provedli jej.

Reálný problém ale může být tam, kde jde o různá „zadrátovaná“ řešení, která jejich autoři ještě neupravili (resp. jejich provozovatelé si to nevyžádali). Nedělal jsem v tomto ohledu žádný systematický průzkum, ale jen jsem se letmo podíval na několik služeb našeho eGovernmentu – a zjistil, že s využitím SHA-1 jsou stále podepisovány například (strojově generované) výpisy z obchodních rejstříků či výpisy ze základních registrů. Ukazují to následující obrázky.

Pro první z nich jsem schválně přepnul Adobe Acrobat Reader DC do angličtiny, aby bylo dobře vidět, že česká lokalizace má drobnou chybu: zatímco anglická verze vypisuje „Hash Algorithm: SHA1“, česká verze nemá v příslušné hlášce dvojtečku ani následnou mezeru, a tak vypisuje nesprávně „Algoritmus hashSHA1“.

 
Výpis ze základního registru osob - jeho podpis (značka) stále využívá SHA-1
 
 
Výpis z Obchodního rejstříku - jeho podpis (pečeť) stále využívá SHA-1
 

Není ale pravdou, že všechna řešení v rámci našeho eGovernmentu stále ještě podepisují (označují, případně: pečetí) s využitím SHA-1. Snad je to právě naopak, a většina již dávno přešla na SHA-2. Třeba datové schránky označují své zprávy s využitím SHA256 již od roku 2011. Ze strojově generovaných výpisů z veřejných rejstříků pak s SHA-2 nemá problém například živnostenský rejstřík.

 
Výpis ze živnsotenského rejstříku - jeho podpis (značka) již využívá SHA-2
 

Mimochodem: právě výpisy z živnostenského rejstříku už jsou také v tzv. referenčním formátu elektronického podpisu, který by orgány veřejné moci měly používat již od roku 2011 (původně kvůli tomuto Rozhodnutí Komise č. 2011/130/EU, nově kvůli eIDASu). Což výše uváděné výpisy ze základních registrů či z obchodního rejstříku stále nedělají.

A to ještě nemluvím o tom, že dnes již účinný zákon č. 297/2016 Sb. o službách vytvářejících důvěru ve svém §11 požaduje, aby i takovéto výpisy z veřejných rejstříků byly opatřeny časovým razítkem. Což dodnes nejsou. Přitom právě časové razítko, přidávané k dokumentu a vytvářené z otisku získaného již pomocí SHA-2, by mohlo eliminovat nebezpečí, plynoucí z použití zastaralé a slabé funkce SHA-1.

Neignorujme digitální kontinuitu!

Na závěr tohoto článku bych rád využil příležitosti a znovu zdůraznil dlouhodobě ignorovaný problém digitální kontinuity. Tedy problém toho, co nám právě bylo velmi názorně předvedeno a prokázáno – že kryptografické algoritmy a funkce s postupem času zastarávají s tím, jak roste výpočetní kapacita dostupných počítačů (a jak se občas daří nalézat různé triky a „zkratky“ na uspíšení). Čímž se otevírá a stává reálně schůdnou cesta pro ty, kteří by chtěli námi původně podepsané dokumenty nahradit nějakými svými (kolizními) dokumenty. Třeba jen proto, aby z původní 1 udělali nově 1000 (viz reálný příklad v tomto balíčku).

Takže pokud chceme uchovávat své elektronické dokumenty v takovém stavu, abychom se na ně mohli - ještě po nějaké delší době – stále spoléhat, musíme tomuto trendu jít naproti. Musíme se starat o včasné posílení toho, jak jsou naše dokumenty zabezpečeny právě proti možné záměně kolizními dokumenty. Nesmíme čekat na to, až se to stane reálně možné, protože pak už by bylo pozdě. Musíme to dělat včas, a to pravidelně, skrze nasazení nových, „lepších“ a hlavně silnějších hašovacích funkcí a delších klíčů. Nejsnáze cestou přidávání dalších časových razítek (pravidelného přerazítkovávání).

Na tuto nezbytnost se stále zapomíná. Nejspíše proto, že je pracná, relativně složitá, a také něco stojí. Samozřejmě je jednodušší nic nedělat a nechávat elektronické dokumenty jen tak někde válet v šuplíku, s představou, že za x let je budeme moci využít (a hlavně: spoléhat se na jejich pravost a autenticitu) úplně stejně jako dnes. Budiž nám dnešní příběh kolem hašovací funkce mementem a důrazným upozorněním, že tomu tak není a nebude.