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“.