Datové schránky: když už ani časové razítko nepomůže….

Dokud byl elektronický podpis něčím, s čím si „hrála“ jen méně početná komunita nadšenců, řada jeho praktických aspektů se vůbec nedočkala pozornosti. S příchodem datových schránek se ale věci změnily, a to docela zásadně: najednou musí s elektronickým podpisem zcela rutinně pracovat velké množství uživatelů. A jak se do oběhu dostává stále více a více elektronicky podepsaných dokumentů, a jak plyne čas, vyplouvají na povrch různé zádrhele, či přímo problémy, na které dosud nikdo nenarazil.

Ten, který budu popisovat dnes, patří spíše do kategorie nedomyšleností a nevznikl v souvislosti s datovými schránkami. Jen díky nim a jejich dopadům začíná nabírat na relevantnosti. O co ale vlastně jde?

Podstata problému

Podstatu problému ukazují následující dva obrázky. V obou případech jde o stejný dokument, který je výstupem autorizované konverze dokumentu z listinné do elektronické podoby, je řádně elektronicky podepsán (obsluhou CzechPointu) a opatřen časovým razítkem (k datu 1.7.2009, kdy tento elektronický podpis vznikl). Certifikát, na kterém je založen elektronický podpis tohoto dokumentu, platil od 26.3.2009 do 26.3.2010.

První obrázek ukazuje výsledek ověření tohoto podpisu dne 19.8.2009, a tedy ještě v době řádné platnosti certifikátu. Jak můžete sami vidět, podpis byl programem Adobe Reader vyhodnocen jako platný (resp. byla ověřena jeho platnost).

Druhý obrázek ukazuje vyhodnocení stejného dokumentu stejným (a stejně nastaveným) programem Adobe Reader, a to dne 2.10.2010. Tedy v době, kdy certifikátu již skončila jeho řádná platnost. S výsledkem, že „platnost podpisu je neznámá“.

Podle pravidel pro vyhodnocování (ověřování) elektronických podpisů by ale správný výsledek i v tomto druhém případě měl být ten, že podpis je platný, resp. že se podařilo ověřit jeho platnost: příslušný certifikát sice již expiroval (skočila jeho řádná platnost, a během ní nebyl revokován), ale časové razítko je stále platné, a díky němu by mělo být možné platnost podpisu ověřit. Nicméně Adobe Reader to neudělal a zachoval se vlastně stejně, jako kdyby dokument vůbec nebyl opatřen časovým razítkem.

Zdůrazněme si, že nejde o žádnou chybu Adobe Readeru, který se v tomto případě chová tak, jak mu velí příslušné standardy. Stejně tak nejde o nějakou vadu PDF dokumentu, který byl použit na obou obrázcích. Jde o soubor, který zveřejnil ve svém článku pan  Vojtěch Kment, když počátkem července loňského popisoval zde na Lupě své první zkušenosti s autorizovanou konverzí.

Popisovaný problém je totiž obecný, a můžete si ho vyzkoušet na libovolném podepsaném PDF dokumentu, jehož elektronický podpis (či značka) je založen na již expirovaném certifikátu, ale je opatřen stále ještě platným časovým razítkem.

Jaký je ale důsledek právě naznačeného obecného problému? Znamená to, že tolik zdůrazňovaná potřeba časových razítek, nutných pro dlouhodobější „ověřitelnost“ elektronických podpisů, je vlastně fámou, která se nezakládá na pravdě?

Naštěstí nikoli. Principy elektronického podpisu se popisovaným zjištěním nijak nemění. Co se může měnit, je naše vnímání schopností těch programů, které pro ověřování elektronických podpisů používáme. Jako je třeba Adobe Reader. Pokud si někdo dosud myslel (tak jako donedávna i já), že by tyto programy měly umět správně vyhodnotit „starší“ elektronický podpis (založený na již expirovaném certifikátu, ale opatřený platným časovým razítkem), pak z této své představy musí poněkud slevit.

Kde je příčina?

Stručně řečeno je celý problém přesně v tom, co nám Adobe Reader říká na druhém obrázku, byť svými slovy (tj. slovy nepříliš podařené české lokalizace): že „odvolání identity autora nelze ověřit“. Přeloženo do obvyklé terminologie tím říká, že nedokáže zkontrolovat případnou revokaci certifikátu, na kterém je podpis založen. A už kvůli tomu nemůže konstatovat, že podpis je platný. Pokud nemá jiný důvod, kvůli kterému by podpis mohl prohlásit za neplatný (jako například porušenou integritu dokumentu), musí nutně skončit výsledkem „nevím“. Neboli: „platnost podpisu je neznámá“.

Princip ověřování elektronického podpisu skutečně vyžaduje, aby při ověření bylo zkontrolováno, zda náhodou nedošlo k revokaci (předčasnému ukončení platnosti) certifikátu ještě předtím, než podpis vznikl. Nebo alespoň k nějakému pozdějšímu okamžiku, ke kterému máme jistotu, že podpis již existoval. Zde nám takovou jistotu poskytuje časové razítko, takže podpis ověřujeme k okamžiku, uvedenému na časovém razítku. V příkladu na obou obrázcích jde o 1.7.2009, takže v obou případech bylo zapotřebí spolehlivě zjistit, zda k tomuto datu (a příslušné hodině, minutě a sekundě) byl certifikát revokovaný, či nebyl.

Asi již tušíte, že v prvním případě (kdy se ověření provádělo dne 19.8.2009) se potřebnou informaci podařilo získat, a z ní vyplynulo, že k uvedenému datu a okamžiku certifikát revokován nebyl. Proto mohl být podpis ověřen jako platný. Naopak ve druhém případě (kdy se ověření provádělo 2.10.2010) se potřebnou informaci získat nepodařilo. Tudíž se nepodařilo zjistit, zda certifikát byl či nebyl k 1.7.2009 re­vokován, a proto musel Adobe Reader skončit verdiktem „nevím“.

Rozdíl mezi oběma případy je pak ten, že v prvním ještě neskončila řádná platnost podpisového certifikátu, zatímco ve druhém případě naopak již skončila. Jak ale tato skutečnost ovlivňuje dostupnost informací o revokaci?

Seznamy CRL

K pochopení toho, co se vlastně stalo, si musíme připomenout, jakým způsobem naše certifikační autority zveřejňují informace o revokaci (předčasném zneplatnění) svých certifikátů.

V principu existují dvě možnosti: jedna z nich je interaktivní a zprostředkovává ji protokol OCSP (Online Certificate Status Protocol). Jeho prostřednictvím se program, ověřující platnost podpisu, interaktivně zeptá certifikační autority na případnou revokaci konkrétního certifikátu a  obratem dostane odpověď. Jenže naše tuzemské certifikační autority tuto variantu zatím nenabízí.

Zbývá tedy druhá varianta, která má „dávkový“ charakter: informace o revokovaných certifikátech se vydávají ve formě seznamů CRL (Certificate Revocation List). Ty samozřejmě nemohou být statické, ale musí být průběžně aktualizovány, tak aby se informace o nově revokovaných certifikátech staly co nejdříve dostupné. Že to není ihned (ale může to trvat třeba až 12 či dokonce 24 hodin), je také nepříjemným problémem.

Ale teď jde o jiný problém: když jsou seznamy CRL pravidelně obměňovány a neustále jsou do nich přidávány informace o nových a nových revokovaných certifikátech, co dělat s informacemi o starších certifikátech? Mají být z CRL seznamů zase průběžně vyřazovány? Jinak by totiž hrozilo, že seznamy CRL časem  nabobtnají do neúnosné velikosti (u větších certifikačních autorit), a nebude se s nimi dát rozumně pracovat.

Příslušné standardy praví, že by se „starší“ certifikáty měly ze seznamů CRL vyřazovat. Konkrétně takové certifikáty, kterým již skončila řádná doba jejich platnosti. Takže na aktuálním seznamu CRL mají být jen takové revokované certifikáty, kterým ještě neskončila řádná doba jejich platnosti. Má to i svou logiku: certifikáty lze revokovat jen v době jejich řádné platnosti, a jakmile ta jednou skončí, už jsou certifikáty neplatné tak jako tak.

Dvě naše akreditované certifikační autority, konkrétně I.CA a PostSignum, takto skutečně postupují: v aktuální verzi svého CRL seznamu, jehož URL adresa je obsažena v každém vydaném certifikátu, udržují informaci o revokaci pouze těch certifikátů, kterým ještě neskončila řádná doba jejich platnosti. Třetí autorita, eIdentity, nechává na svém aktuálním CRL seznamu i starší certifikáty.

Informace o revokaci se neztrácí!

Informace o revokaci starších certifikátů, jejichž řádná platnost již skončila, se jejich odebráním ze seznamů CRL samozřejmě neztrácí. Striktně vzato tyto informace ani odebírány nejsou, protože jsou neustále vydávány nové a nové seznamy CRL. Takže se tyto informace pouze přesouvají z aktuální verze seznamu CRL do starších verzí.

„Otcové zakladatelé“ elektronického podpisu naštěstí pamatovali na potřebu zachování informací o revokaci, a zakotvili ji do zákona (č. 227/2000 Sb. o elektronickém podpisu). Podle něj  jsou certifikační autority povinny uchovávat tyto informace po 10 let, a pak je předávat dozorovému orgánu, kterým je dnes  ministerstvo vnitra.

Jenže už nikdo moc nepamatoval na to, jak se k těmto „starším“ informacím dostat. Přesněji: u „dávkové varianty“ (seznamů CRL) není pamatováno na standardizované mechanismy a postupy, jak se dostat ke starším verzím CRL seznamů. Ani naše certifikační autority je nijak neutajují, a kdokoli si je může na webu „naklikat“. Problém je v tom, že je každá autorita zveřejňuje obecně jinak (na jinak konstruovaných URL adresách či skrze jiné služby). A tak univerzální programy, typu Adobe Readeru, se o získávání  starších seznamů CRL ani nesnaží. Svým způsobem přitom také vychází z toho, co říkají relevantní standardy.

Pro dokreslení si připomeňme, že každý certifikát si nese přímo v sobě URL odkaz na to místo, kde je u jeho vydavatele dostupná aktuální verze seznamu CRL. Ale už nikoli odkaz či jakýkoli návod na to, jak se dostat ke starším CRL seznamům. Proto se programy jako Adobe Reader snaží najít informace o případné revokaci jen v aktuálním seznamu CRL. Z něj Reader pozná, jaké časové období seznam „pokrývá“ – a když zjistí, že ho zajímá okamžik, který aktuální verzí seznamu CRL pokryt není, skončí tak jako na druhém dnešním obrázku: konstatováním, že „odvolání identity autora nelze ověřit“, resp. že nedokáže zkontrolovat případnou revokaci certifikátu.

Není to tedy tím, že příslušná informace nebyla k dispozici. Jde o to, že univerzální programy, jako je Adobe Reader, se k této informaci nedostanou. A to proto, že standardy ani nepočítají s tím, že by se k ní potřebovaly dostat. A tak nespecifikují nějaký jednotný (a standardizovaný) postup, jak tak činit.

Co jiné programy a autorizovaná konverze?

Zdůrazněme si ale znovu, co právě popsaný problém znamená, a co naopak neznamená. Rozhodně neznamená, že by časové razítko bylo k ničemu (a že by ani při existenci časového razítka nebylo možné ověřit platnost podpisu, který je založen na již expirovaném certifikátu). Znamená pouze to, že některé programy takového ověření nejsou schopné. Jak jsme si již ukázali, patří mezi ně Adobe Reader (a obecně i další produkty od Adobe, například Acrobat).

Také to ale neznamená, že nemohou existovat jiné programy, které budou schopné popisované ověření provést. A to díky tomu, že budou nějak šity na míru tomu, jak konkrétně naše certifikační autority nakládají se staršími  informacemi o revokovaných certifikátech, a dokáží se k nim dostat. Příkladem může být program VerisignIT od společnosti Dignita, který kromě podepisování PDF dokumentů (i vícenásobného) zvládá také ověřování podpisů – a na rozdíl od Adobe Readeru například posuzuje i kvalifikovaný charakter podpisových certifikátů, včetně těch zahraniční provenience (dle aktuálního seznamu TSL). A jak vidíte na následujícím obrázku, VerisignIT na stále stejném dokumentu dokázal ověřit i to, že certifikát nebyl revokován.

Velmi důležité je i chování CzechPointů k popisovaným dokumentům. Pokud by se totiž CzechPointy chovaly (jen) podle standardů, tak jako Adobe Reader, pak by (z pohledu konverzí) bylo vlastně úplně jedno, jestli je nějaký dokument časovým razítkem opatřen, nebo nikoli. Protože konverze by byla možná jen do doby, než expiruje podpisový certifikát (než skončí jeho platnost), a informace i jeho případné revokaci vypadne z aktuálních CRL seznamů.

Naštěstí tomu tak není, a centrála CzechPointů (která zajišťuje konverzi centrálně, pro všechna kontaktní místa) konvertuje i dokumenty ve zde popisované situaci (tj. které mají platné časové razítko, ale již expirovaný podpisový certifikát). Ověřoval jsem si to na stejném dokumentu, na kterém jsou založeny oba obrázky z úvodu článku: CzechPoint tento elektronický dokument úspěšně zkonvertoval do listinné podoby. Konverzní doložku vidíte na následujícím obrázku.

Pravdou je, že této konverzní doložce chybí jedna (z mého pohledu velmi podstatná) náležitost, a to konstatování, že podpisový certifikát nebyl v době vzniku podpisu (resp. v okamžiku, uvedeném na časovém razítku) revokován. Absence tohoto konstatování, které je nezbytným předpokladem pro celkovou platnost podpisu a možnost konverze, by dokonce mohla naznačovat, že kontrola stavu revokace ani nebyla provedena.

Podle neoficiálních informací od CzechPointu tomu tak není, a jde jen o nedokonalost konverzní doložky. Ve skutečnosti to prý CzechPointy dělají tak, že si samy vedou jakési vlastní kopie starších CRL seznamů, ve kterých si  shromažďují informace o revokaci již expirovaných certifikátů – a podle nich pak postupují při konverzi. Tedy pro CA PostSignum a I.CA, zatímco pro certifikáty od eIdentity takovéto řešení nepotřebují (důvody viz výše, eIdentity na svém aktuálním CRL seznamu uchovává i informace o revokaci již expirovaných certifikátů).

Jaké by bylo řešení?

Popisovaný problém je z hlediska běžné praxe dosti nepříjemný. Má ale nejméně dvě možná řešení.

Jedním z nich by bylo použití již zmíněného protokolu OCSP, skrze který by se kdokoli (kdo právě ověřuje nějaký elektronický podpis) mohl interaktivně zeptat příslušné certifikační autority na platnost jakéhokoli jejího certifikátu, obecně k jakémukoli datu. Jenže na tuto možnost si ještě nějakou dobu počkáme, protože tuzemské certifikační autority protokol OCSP nepodporují. Sice již vydávají signály, že by jej do budoucna chtěly podporovat, ale zatím jej nepodporují.

Druhé řešení vystačí i bez podpory protokolu OCSP, ale zase vyžaduje určité „dodatečné úkony“. Příklad tohoto řešení vidíte na následujícím obrázku. Je na něm dokument, vytvořený 11.2.2010, a jeho podpis je založený na kvalifikovaném certifikátu, který platil od 5.2.2010 do 7.4.2010. Tedy ještě mnohem kratší dobu, než tuzemské kvalifikované certifikáty. Tento podpis jsem ověřoval 2.10.2010 (tedy již v době, kdy tomuto certifikátu skončila řádná platnost). A (defaultně nastavený) Adobe Reader ho ověřil jako platný. Jak je to možné, když v aktuálním CRL vydavatele by informace o takovémto certifikátu již neměly být?

Není to přitom tak, že by vydavatel certifikátu (stejně jako naše eIdentity) na svém aktuálním seznamu CRL udržoval revokační informace i o starších a již expirovaných certifikátech. Vysvětlení je takové, že jde o PDF dokument, který si již přímo v sobě nese potřebné informace o revokaci. Tedy vhodně datovaný seznam CRL, samozřejmě podepsaný příslušným vydavatelem, na kterém by informace o případné revokaci musela být uvedena. O jeho existenci (vložení přímo do PDF dokumentu) vypovídá následující obrázek.

Tento vložený CRL seznam je přitom datován do doby následující po podpisu (s „dostatečným odstupem“), ale předcházející konci řádné platnosti certifikátu.

Jak vkládat informace do PDF dokumentů?

V souvislosti s právě popsanou možnosti si řekněme, že k podpisům na PDF dokumentech lze vkládat informace o revokaci (kopie seznamů CRL) jak při jejich vzniku (tj. v okamžiku podepisování), tak i kdykoli později. Z pohledu naší legislativy ale vkládání v okamžiku vzniku podpisu moc nepomůže, protože naše certifikační autority mají až 12 či dokonce 24 hodin na to, aby se informace o revokaci objevila v aktuálním CRL seznamu.

Stále ale zbývá možnost vložit do PDF dokumentu potřebné revokační informace později, s dodatečným odstupem (12, resp. 24 hodin). Zajímavé je, že tuto možnost nabízí i Adobe Reader, když se mu podaří ověřit platnost podpisu – a v nabídce, aktivované pravým tlačítkem, nabízí možnost „Přidat informace o ověření“.

Pokud si uživatel tuto možnost navolí, Adobe Reader dokonce ohlásí úspěšné vložení těchto informací.

A nejspíše má i pravdu, protože (do svého zavření) se otevřený soubor s PDF dokumentem skutečně chová tak, jak by měl (tj. odkazuje se na vložený seznam CRL). Co už Adobe Reader nedělá, ale určitě by dělat měl, je informovat uživatele, že při zavření souboru se vložená informace ztrácí.

Aby se vložená informace neztrácela, je nutné, aby samotný PDF dokument byl „aktivován“ pro úpravy v Adobe Readeru. Pak je možné ho nejen podepisovat (v samotném Readeru), ale je možné příslušné „informace o ověření“ s dokumentem i ukládat.

Problém je ale v tom, že k aktivaci PDF dokumentu pro vkládání revokačních informací nestačí „běžné“ aplikace, používané pro vytváření a samotné podepisování PDF dokumentů, ale jsou zapotřebí originální nástroje od společnosti Adobe (např. Adobe Acrobat). A ty nejsou nejlevnější. Možná i proto se v ČR s datovými schránkami rozjela „ve velkém“ práce s elektronickými dokumenty, aniž by někdo pamatoval na právě popsaný problém.