V předchozím článku jsme se začali zabývat fungováním služby BankID SIGN. Řekli jsme si, že nejde o samostatně využitelnou službu, ale o určitou komponentu, určenou k zabudování do jiných služeb. Typicky do služeb nejrůznějších poskytovatelů, prodejců, operátorů, utilit atd., kteří chtějí uzavírat smluvní vztahy se svými klienty elektronicky – a službu BankID SIGN využívají k podepsání příslušných smluvních dokumentů za stranu klienta (zatímco sami je pak elektronicky podepisují přímo, resp. opatřují svou elektronickou pečetí).
Také jsme si ukázali, jak vypadá ono „podepsání za stranu klienta“ na konkrétním PDF dokumentu: že dochází k přidání jednoho zaručeného elektronického podpisu a jedné kvalifikované elektronické pečeti. S tím, že zaručený elektronický podpis je založený na komerčním (tj. nikoli kvalifikovaném) certifikátu, který vydala interní certifikační autorita poskytovatele služby BankID SIGN (cn=BankID Document CA).
Tato autorita (ani její nadřazená autorita) ale není na žádném z obvyklých seznamů důvěryhodných autorit (ani na tzv. důvěryhodném seznamu autorit, vydávajících kvalifikované certifikáty), a proto ji obvykle používané nástroje pro práci s elektronickými podpisy neznají a nevědí, zda jejím certifikátům mohou důvěřovat. Což je i důvodem toho, proč Adobe Acrobat Reader nedokáže ověřit platnost zaručeného elektronického podpisu a hlásí, že tato je pro něj neznámá.
Mimochodem, obdobně to dopadne při pokusu o ověření pomocí dalších programů, nástrojů a služeb pro ověřování platnosti elektronických podpisů.
Například kvalifikovaná služba pro ověřování platnosti elektronických podpisů SecuSign, stejně jako program Signer od SW602, hlásí, že interní autoritu nezná („Certifikát vydavatele … je neznámý“). Vadí jí i absence časového razítka a upozorňuje na zastaralý formát zaručeného elektronického podpisu (pouze PAdES Basic).
Obdobně dopadne pokus o ověření u vzorové implementace unijní služby DSS, ani ona nezná vydavatele podpisového certifikátu (interní autoritu), ani jej nedokáže podřadit pod nějakou jinou autoritu, které důvěřuje. A tak samotný certifikát nemůže považovat za důvěryhodný.
Dobře to nedopadne ani u slovenského validátoru, který provozuje autorita Disig: tomu hodně vadí již jen to, že podpis (ani pečeť) nemá referenční formát (viz „podpis neslpňa požiadavky formátu PAdES“). A v případě kvalifikované elektronické pečeti je již tato samotná skutečnost důvodem toho, proč ji slovenský validátor také odmítá ověřit jako platnou.
Jak dopadne autorizovaná konverze?
V podstatě jedinou službou, u které ověřování dopadne „dobře“, je úschovna Czech POINTu. Přesněji: dobře dopadne ověření toho, zda dokument lze autorizovaně konvertovat. Ukazuje to následující obrázek, ze kterého je ale patrná jedna velmi důležitá skutečnost: Czech POINT vůbec „nevidí“ zaručený elektronický podpis. A „nevidí“ jej (a ignoruje) právě proto, že nedokáže ověřit jeho platnost.
Jelikož ale „za“ tímto zaručeným elektronickým podpisem neznámé platnosti „následuje“ kvalifikovaná elektronická pečeť, kterou je Czech POINT již ochoten ověřit jako platnou, nebrání mu to v provedení autorizované konverze. A nevadí mu ani absence časového razítka, ani zastaralý formát pečeti, který třeba slovenskému validátoru vadí docela zásadně.
Tomu, že Czech POINT vůbec „nevidí“ zaručený elektronický podpis, odpovídá i obsah konverzní doložky, který vidíte na následujícím obrázku. Celou doložku si můžete nechat zobrazit v jejich úschovně.
Zdůrazněme si znovu, že Czech POINT vůbec „nevidí“ zaručený elektronický podpis, který by ale měl být právě tím podstatným – projevem vůle jednající strany (klienta, resp. podepsané osoby). O tom ale není v konverzní doložce ani zmínka.
Nicméně po tom, komu by měl zaručený elektronický podpis patřit, přeci jen existují další stopy: vizualizace podpisu, kterou služba BankID SIGN přidává do podepisovaného dokumentu. A ta obsahuje alespoň jméno (a příjmení) toho, komu by podpis měl patřit, viz následující obrázek.
Jenže s vizualizacemi elektronických podpisů při konverzi do listinné podoby je problém: z výstupu „na papíře“ nemusí být poznat, co je původní obsah a co vizualizace. A tak to Czech POINTy řeší tak, že vizualizace do listinného výstupu raději vůbec nepřenáší. Tak jak ukazuje následující obrázek.
Jenže tím z původního dokumentu zmizela jakákoli stopa po tom, kdo má být považován za podepsanou osobu. Což je docela problém již jen proto, že výstup z autorizované konverze má mít stejné právní účinky jako vstup (viz § 22 odst. 2 zákona č. 300/2008 Sb.).
Není to ale něco specifického jen pro službu BankID SIGN. Stejný problém s autorizovanou konverzí mají obecně všechny služby, které pro stvrzení projevu vůle klienta používají pouze zaručený elektronický podpis (neboli elektronický podpis, založený na komerčním, a nikoli kvalifikovaném certifikátu), nebo dokonce jen tzv. prostý podpis (neboli takový podpis, který vůbec není založen na kryptografických technikách a nepracuje s žádnými certifikáty).
Důvod je ten, že pravidla autorizované konverze počítají pouze s tím, že podpis (případně pečeť) je založen na kvalifikovaném certifikátu. Což zase vychází z toho, že samotné nařízení eIDAS přisuzuje právní účinky vlastnoručního podpisu pouze kvalifikovanému elektronickému podpisu. U nás jsme si možnost podepisování rozšířili i o takové podpisy, které jsou založené na kvalifikovaném certifikátu, a tomu uzpůsobili i pravidla autorizované konverze.
Jenže pak do všeho na poslední chvíli a nesystémově zasáhl § 7 zákona č. 297/2016 Sb., který připustil možnost používat v soukromoprávních vztazích i zaručené elektronické podpisy (tj. založené jen na komerčních certifikátech, jako v případě služby BankID SIGN), a dokonce i ony prosté elektronické podpisy (podrobněji viz další článek). Jenže už neřekl, jaké konkrétní právní účinky takovéto „slabé“ elektronické podpisy mají mít – zda stejné jako vlastnoruční podpisy, nebo také „slabší“ (například zda má jít jen o elektronickou obdobu nahrazení vlastnoručního podpisu mechanickými prostředky, které se dá využít jen někde – tam, kde je to obvyklé).
Podle mého názoru by byla namístě druhá varianta. S tou koresponduje i nastavení pravidel autorizované konverze, která vyžaduje podpis či pečeť, založenou na kvalifikovaném certifikátu.
Nepomáhá ovšem ani to, když služba pro elektronické podepisování sice pracuje s kvalifikovanými certifikáty, ale projev vůle klienta chce stvrdit svou vlastní uznávanou elektronickou pečetí (tj. zaručenou elektronickou pečetí, založenou na kvalifikovaném certifikátu). A pouze jako vizualizaci této své vlastní pečeti použije křivku vlastnoručního podpisu klienta (získanou odebráním vzorku jeho podpisu na dotykové destičce).
I takováto vizualizace při autorizované konverzi do listinné podoby zmizí a na doložce po identitě klienta nezůstane ani stopa. Na následujícím obrázku vidíte příklad smluvní dokumentace České spořitelny (nahoře je elektronický originál, dole výstup z autorizované konverze do listinné podoby, včetně doložky).
Co by bylo nutné udělat, aby to (v Adobe Readeru) dopadlo „zeleně“?
Vraťme se ale ještě k původní elektronické verzi výstupu služby BankID SIGN a zkusme si nyní rozebrat, zda je možné nastavit program Adobe Reader tak, aby dokázal ověřit zaručený elektronický podpis od této služby jako platný. Aby to dopadlo tak jako na následujícím obrázku.
Přitom si řekneme, zda je vůbec vhodné něco takového dělat, alespoň ze strany běžného příjemce podepsaného dokumentu. Dopředu si můžeme naznačit, že nikoli.
Hlavní překážkou pro možnost ověření stavu platnosti zaručeného elektronického podpisu od služby BankID SIGN je to, že program nezná vydavatele certifikátu a neví, zda může důvěřovat obsahu jím vydaných certifikátů. Nejde přitom jen o to, komu byl certifikát vystaven (kdo je jeho držitelem, a měl by tedy být považován za podepsanou osobu). Jde i o všechny další údaje obsažené v certifikátu. Například o to, kam se podívat (resp. kde se zeptat), zda nedošlo k revokaci (zneplatnění) certifikátu. Což je mimochodem nutnou podmínkou pro možnost ověřit elektronický podpis jako platný.
Standardní řešení problému s důvěryhodností certifikátů je přitom takové, které jsme si již naznačili: kvalifikovaný vydavatel certifikátu (certifikační autorita) je zařazen na tzv. důvěryhodný seznam (TL, Trusted List) a program podle toho pozná, že může jeho certifikátům důvěřovat. Pokud nejde o kvalifikovaného vydavatele (kvalifikovanou certifikační autoritu), může využít již zmiňovaných programů (seznamů) komerčních firem (AATL či MRCP), které fungují na obdobném principu. Jinými slovy a velmi zjednodušeně: standardní řešení je takové, o které se postará někdo jiný, než je koncový uživatel. Někdo, kdo má potřebné znalosti, „ví, co dělá“ a je pod alespoň nějakou kontrolou.
V ostatních případech – jako je ten zde popisovaný – zůstává vyjádření důvěry na koncovém uživateli. Ten by k tomu ale měl přistoupit opravdu jen tehdy, pokud dobře ví, co dělá i jaké to bude mít důsledky. Proto si zde nebudeme ukazovat ani popisovat konkrétní postup. Řekneme si jen důležité poznatky, určené pro zkušenější uživatele.
Jak je to s autoritami BankID?
Certifikační politiky autorit společnosti Bankovní identita, a.s., ani certifikační zásady pro vydávání koncových certifikátů nejsou veřejně dostupné, a to ani na adrese ca.bankid.cz (viz dále), ani na ně nejsou odkazy přímo ve vydávaných certifikátech (v příslušných položkách, které nemají ani koncové certifikáty, ani certifikáty samotných autorit).
Ze samotného obsahu certifikátů lze zjistit, že autorita Bankovní identity, sloužící k vydávání koncových certifikátů v rámci služby BankID SIGN, má hierarchickou strukturu, po vzoru autorit, jako jsou I.CA, PostSignum či eIdentity.
Autorita „BankID Document Root CA“, která je kořenem této hierarchie, ale není jedinou kořenovou autoritou, kterou Bankovní identita, a.s., používá. Povšimněme si, že dceřiná autorita „BankID Document CA“ má ve svém certifikátu odkaz na zdroj CRL seznamů na adrese https://ca.bankid.cz/document/root.crl.
Server na adrese ca.bankid.cz se ale prokazuje SSL certifikátem, vydaným další interní kořenovou autoritou („Bank ID Production CA“).
Jinými slovy: místo obvyklého řešení, v podobě použití SSL certifikátu od některého z „dobře známých“ vydavatelů, si Bankovní identita, a.s., vydává vlastní SSL certifikáty.
To vše pak ve svém důsledku znamená, že problém s důvěryhodností se netýká jen jedné hierarchicky uspořádané interní autority, ale hned dvou.
Pokud koncový uživatel (který „ví, co dělá“) vyjádří svou důvěru oběma kořenovým autoritám, podle mých empirických zjištění to stejně nepřinese kýžený efekt – když neúspěchem skončí již pokus o stažení aktuálního CRL seznamu pro dceřinou autoritu „BankID Document CA“ (i v případě, kdy vydavatel SSL certifikátu je považován za důvěryhodný).
Navíc je zde problém v tom, že samotné (komerční) koncové certifikáty vystavované na identitu podepisující osoby (coby koncového uživatele, resp. držitele bankovní identity) v sobě nemají žádný odkaz na revokační údaje (CRL seznam či OCSP server).
Podle poskytovatele služby BankID SIGN jde o certifikáty (a párová data) jen na jedno použití. To koresponduje s tím, že když využijete veřejné demo či narozeninovou aplikaci vícekrát po sobě, bude v příslušném elektronickém podpisu vždy nový a „čerstvý“ certifikát.
Dříve to bylo podpořeno i tím, že certifikáty podepisujících osob byly vydávány s řádnou dobou platnosti jedné jediné minuty, takže jejich opakované využití reálně nepřipadalo v úvahu. Nicméně dnes jsou tyto certifikáty vydávány s platností na celý jeden rok (možný důvod viz dále).
Vzhledem k deklarovanému jednorázovému využití koncových certifikátů by se asi dalo spekulovat nad tím, zda je jejich případná revokace skutečně nutná. Nicméně dostupnost revokačních informací je standardními postupy pro ověřování platnosti elektronických podpisů vyžadována. A jen u některých nástrojů lze požadavek na kontrolu revokace zcela mimořádně potlačit (což by opět měl dělat jen ten, kdo „ví, co dělá“).
Lze to udělat i v Adobe Acrobat Readeru, který si pak ale neodpustí disclaimer, upozorňující na neprovedení kontroly revokace (předčasného zneplatnění, resp. odvolání), jak ukazuje i následující obrázek.
Ještě je zde ale jeden zajímavý aspekt: ani zaručený elektronický podpis, ani kvalifikovaná elektronická pečeť služby BankID SIGN neobsahují elektronické časové razítko (ani žádné „obyčejné“, natož pak kvalifikované). Zřejmě se počítá s tím, že „fixaci v čase“ zajistí druhá smluvní strana, která k dokumentu připojí svou elektronickou pečeť (případně podpis) již s kvalifikovaným časovým razítkem.
Nicméně pokud máte v ruce jen „jednostranně podepsaný“ dokument (buď z veřejného dema, nebo z narozeninové aplikace), nemáte žádné jeho spolehlivé ukotvení v čase. Proto by platnost podpisu (i pečeti) měla být ověřována k aktuálnímu času, jako je tomu v horní části následujícího obrázku. V případě „nových“ koncových certifikátů vydávaných s dobou platnosti jednoho roku to v jeho průběhu není problém.
Ale v případě původních certifikátů, vydávaných s řádnou dobou platnosti, to již problém je – a je nutné jej obejít ověřováním „k času podepsání“, který je ale jen deklarovaným časem, a nikoli časem garantovaným, na který by se dalo spoléhat.
Je toto důvodem, proč služba BankID SIGN přešla na vydávání (komerčních) certifikátů s dobou platnosti celého jednoho roku místo jedné jediné minuty?
ČLÁNKY DO MAILU