S kvalifikovaným certifikátem raději necestujte

Vše může začít úplně nevinně: Řekněme, že jste se rozhodli vytvořit webovou aplikaci určenou širokému spektru uživatelů v rámci jednoho státu, v našem případě České republiky. Abyste dosáhli maximálního zabezpečení prováděných transakcí, budete požadovat, aby každý uživatel všechna důležitá data zasílaná do systému elektronicky podepsal. To však nemusí být  všechno: můžete také chtít, aby se uživatel prokázal certifikátem při přihlášení do vašeho systému (certifikát pak může – ale nemusí – sloužit také jako náhrada jména a hesla). Můžete také implementovat podporu pro kryptování dat, která uživatel do systému zasílá.

První otázka asi bude znít: jaké formální požadavky budete vyžadovat z hlediska použití certifikátů, kterými by se měli vaši uživatelé autentikovat vůči vaší aplikaci, elektronicky podepisovat data, případně šifrovat.

Měli byste asi vyžadovat certifikáty kvalifikované – oproti „nekvalifikovaným“ poskytují jednoznačně větší míru důvěryhodnosti. V případě kvalifikovaného certifikátu máte velký stupeň jistoty, že certifikát není podvrh a že uživatel, který certifikát používá, je skutečně tím, za koho se vydává.

Je možné, že budete také požadovat, aby vydavatel kvalifikovaného certifikátu byl akreditovaným poskytovatelem certifikačních služeb, obdobně jako to požaduje stát pro komunikaci občanů s orgány státní správy. Zda to budete vyžadovat či nikoliv, se může v současné době jevit jako lhostejné, protože seznam kvalifikovaných poskytovatelů a akreditovaných poskytovatelů jsou zatím totožné jednoprvkové množiny čítající jedinou společnost – První certifikační autoritu.

Chcete-li po uživatelích, aby kromě elektronického podepisování prováděli také autentizaci a kryptování dat, příslušný certifikát bude muset být vystaven ke všem těmto účelům. K tomu je v certifikátu určena položka Key Usage, která definuje, k jakým operacím může být příslušný certifikát použit.

Před třemi lety narazil Jiří Peterka na problém, který se týkal právě použitelnosti kvalifikovaných certifikátů 1. CA pro elektronické podepisování. Zjednodušeně řečeno, kvalifikované certifikáty tehdy de facto neumožňovaly elektronické podepisování, a to v souvislosti s možným dvojím výkladem RFC 2459. Podrobněji o tom pojednává článek na Lupě Kvalifikovaný certifikát na dvě věci II. Náprava byla tehdy zjednána velice rychle, takže se zdá, že problém byl vyřešen. Bohužel tomu tak ale není.

Kvalifikovaný certifikát v Evropské unii

Nyní se vraťme k našemu předchozímu příkladu a představme si, že chcete služby své aplikace nabídnout také zahraničním uživatelům. Pojmy „kvalifikovaný certifikát“, „akreditovaný poskytovatel certifikačních služeb“ a další nejsou v Evropské unii neznámé, naopak – zákon o elektronickém podpisu vychází z direktivy Evropské unie, která uvedené termíny na obecné úrovni definuje. Na členské státy je pak přenesena úloha zpřesnit pravidla pro kvalifikované certifikáty a způsoby jejich vydávání. A v tom je právě problém.

Jednotlivé členské státy přistoupily k problému různými způsoby a v důsledku se místy liší i  podoba kvalifikovaných certifikátů, které certifikační autority v jednotlivých státech vydávají. I když se záhy po nabytí účinnosti direktivy objevily snahy o standardizaci a upřesnění pravidel (např. iniciativa EESSI či fórum FESA) a v řadě aspektů se skutečně mnohé podařilo, některé klíčové detaily zůstaly stále nevyřešeny.

V praxi lze na rozpor narazit například v Polsku. Polská vyhláška totiž definuje, že kvalifikovaný certifikát musí mít v položce Key Usage vybrán pouze bit NonRepudiation (nepopiratelnost) a všechny ostatní bity musí zůstat vypnuté. Tedy včetně bitu DigitalSignature.

Pokud tedy budete požadovat, že elektronický podpis, který má být použitelný ve vaší aplikaci, musí být založen na kvalifikovaném certifikátu vydaném v některém členském státě Evropské unie, velmi pravděpodobně se dostanete do situace, že polské certifikáty budou ve vaší aplikaci nepoužitelné. A to už vůbec nemluvím o tom, že jste původně chtěli certifikát používat i pro šifrování.

Když jsem se o tento problém, na nějž jsem narazil ve své profesní praxi, začal zajímat podrobněji, ukázalo se, že názory na problematiku jsou opravdu různé.

Například Andrzej Borzyszkowski z polské akademie věd mi na můj dotaz odpověděl, že polská legislativa je v pořádku a že přesně implementuje obecné standardy. Tím obecným standardem je zde myšlen zejména RFC 3039, z nějž zmíněná vyhláška vychází, a která říká, že bit NonRepudiation nemá být kombinován s žádnými dalšími bity. To je jistě pravda, nicméně je třeba dodat, že RFC 3039 byl cca před půl rokem „novelizován“ a nová verze RFC 3739 již tuto omezení neobsahuje. Pouze se obecně zmiňuje o bezpečnostních rizicích vyplývajících z kombinování bitu NonRepudiation s dalšími bity. Nikde však již není napsáno, v čem tato rizika spočívají, a vzhledem k tomu, že drtivé většině ostatních států Unie taková kombinace nevadí, zřejmě to s těmi riziky nebude tak horké.

Vzhledem k tomu, že Poláci si toto pravidlo nešťastně vtělili přímo do zákonné normy (narozdíl od většiny ostatních států, kde je certifikační politika řešena zpravidla terciární legislativou), změny se nejspíš jen tak nedočkáme. Jak tedy z toho ven?

Jak mi napsal specialista na problematiku certifikátů Libor Dostálek, možná řešení jsou v zásadě dvě:

1. Ve své aplikaci se vzdáte pojmu „kvalifikovaný certifikát“, pak polské certifikační autority mohou bez problémů vystavit certifikát v podobě, v níž jej požaduje vaše aplikace. Bezpečnostní rizika takového kroku jsou zřejmá, bude tedy třeba tuto liberalizaci kombinovat alespoň s jednoznačným požadavkem na akreditaci příslušných certifikačních autorit, které mají certifikáty (byť nekvalifikované) vydávat. S tím ale souvisí další problém, kterému se věnuje druhá část článku.
2. Druhá cesta je složitější jak pro uživatele, tak pro vás jako provozovatele aplikace. Můžete trvat alespoň na tom, že kvalifikovaný certifikát má být použit pro elektronické podepisování odesílaných dat, a pro ostatní operace (například šifrování) kvalifikovaný certifikát požadovat nebudete. To v praxi bude znamenat, že vaši uživatelé budou muset mít certifikátů více, z nichž ale pouze jeden bude kvalifikovaný a bude sloužit právě pouze pro elektronické podepisování. Pro ostatní účely budou uživatelé používat certifikáty jiné. Nepohodlí pro uživatele je zřejmé, a navíc to přináší potřebu poskytnout uživatelům takový nástroj, jehož prostřednictvím budou moci takto „omezené“ certifikáty použít k podepsání dat – jak píše také Jiří Peterka, například s Outlookem si totiž stejně neškrtnete. Jedním z řešení (o nichž mám ověřeno, že fungují v aplikacích vytvořených na platformě Microsoft) je použití komponenty Microsoft CAPICOM.
   

Akreditovaný, či kvalifikovaný poskytovatel?

Opět se vraťme k našemu původnímu příkladu a připomeňme si, že po uživatelích požadujeme certifikáty vydané akreditovanou certifikační autoritou. Jakmile však překročíme hranice našeho státu, ocitneme se na tenkém ledě. Evropská unie totiž proces akreditace definuje jako dobrovolný (tím nemyslím, že je dobrovolné se akreditovat, ale že dobrovolná je samotná existence akreditačního procesu). A skutečně existuje v Evropě několik zemí, které akreditační proces v legislativě zakotven vůbec nemají. Patří mezi ně opět Polsko, ale i Maďarsko, Malta a další.

Pokud tedy budeme požadovat, aby certifikáty uživatelů byly vydány akreditovaným poskytovatelem, mohou se někteří potenciální uživatelé dostat do svízelné situace. Požadavek budou schopni splnit v podstatě pouze tak, že navštíví některý stát, který má akreditační proces zaveden, a u místního akreditovaného poskytovatele si certifikát zajistí.

Z toho vyplývá, že od požadavku na akreditaci poskytovatelů bychom měli v zájmu nediskriminace některých uživatelů ustoupit a spokojit se s poskytovateli kvalifikovanými. Na ty je kladena také celá řada zákonných požadavků, jsou však mírnější než pravidla pro poskytovatele akreditované.

Ale i kdybychom to neudělali, je to zřejmě pouze náš problém – jsme to zase jenom my, kdo tím přichází o potenciální uživatele, které náš přísný požadavek nejspíše odradí.

Ve zcela jiné situaci je však například český stát jako takový – i on vyžaduje pro komunikaci se svými úřady použití certifikátu od akreditovaného poskytovatele, neřeší však, jak se má zachovat občan jiného státu EU, který chce se státem komunikovat. Můžeme si představit třeba hypotetický příklad, kdy jako občan ostrovního státu Malta koupím v Česku nemovitost a pak chci prostřednictvím aplikace daňové správy podat na nabytou nemovitost elektronicky daňové přiznání.

Narozdíl od Libora Dostálka se domnívám, že by daný přístup mohl být za určitých okolností chápán jak diskriminační. Můj soukromý názor se opírá i o stanovisko zveřejněné v článku ředitele odboru koncepce a koordinace ISVS (Ministerstvo informatiky) Jana Hobzy:

„Ještě zásadnější odlišností a možným nedostatkem zákona o elektronickém podpisu je obligatorní využívání služeb pouze akreditovaných poskytovatelů certifikačních služeb v oblasti orgánů veřejné moci. Toto ustanovení vnímají někteří odborníci z Evropské komise jako diskriminační a je v rozporu s článkem 3 odstavce 7 Směrnice“.