Bezpečnost dosud nebyla v českém eGovernmentu výraznější prioritou. Určitá změna k lepšímu přichází až v poslední době, v souvislosti se zákonem o kybernetické bezpečnosti. Nízké je ale i celkové povědomí o potřebě dodržovat alespoň určité elementární principy a postupy v oblasti bezpečnosti.
Bohužel je toto povědomí nízké i mezi těmi, kteří o projektech eGovermentu rozhodují, nebo je dokonce řídí a implementují. Někdy z toho vznikají přímo učebnicové příklady toho, co a jak by se opravdu dělat nemělo.
Vzpomínáte si třeba na spuštění datových schránek, kdy Česká pošta radila jednoduše odkliknout ten certifikát, který browsery na straně uživatelů neznaly a nevěděly, zda mu mohou důvěřovat? Nebo na spuštění základních registrů, kdy se v jejich dokumentaci objevovaly podobné rady typu „prostě to odklikněte“?
Před několika dny byl spuštěn do (zatím jen zkušebního) provozu další opravdu velký projekt českého eGovernmentu: tzv. Národní elektronický nástroj, zkratkou NEN. A bohužel přinesl další příklad toho, co by se v oblasti bezpečnosti dělat nemělo. U něj konkrétně jde o manipulaci se soukromým klíčem, příslušejícím ke kvalifikovanému certifikátu uživatelů aplikace NEN. Tento soukromý klíč slouží k vytváření tzv. uznávaných elektronických podpisů, s právní relevancí vlastnoručního podpisu. V rámci NEN-u konkrétně k právně platnému podepisování poptávek i nabídek.
Zdravý rozum, všechna pravidla bezpečnosti, a dokonce i zákon (č. 227/2000 Sb. o elektronickém podpisu) říkají, že takovýto soukromý klíč si musíte chránit jako oko v hlavě a nesmíte ho dávat z ruky, protože byste nad ním ztratili výhradní kontrolu (a někdo jiný by se pak mohl platně podepisovat vaším jménem). I zadávací dokumentace k projektu NEN konstatuje, že „uživatel vám přeci nesvěří svůj soukromý klíč“:
Přesto byl NEN nakonec spuštěn v takové podobě, která pracuje s variantou: „svěřte nám svůj soukromý klíč“. A dokonce ji považuje za výchozí.
Co je NEN?
Než se pustíme do detailů, naznačme si alespoň stručně, co je zač onen NEN, neboli „Národní elektronický nástroj“. Je jednou ze dvou hlavních součástí Národní infrastruktury pro elektronické zadávání veřejných zakázek (zkratkou NIPEZ), která je sama součástí Národního plánu zavedení elektronického zadávání veřejných zakázek pro období let 2006 – 2010. Druhou hlavní součástí NIPEZu pak jsou elektronická tržiště (modul „e-tržiště“).
Zjednodušeně si celý NEN lze představit jako platformu, umožňující centrální zadávání veřejných zakázek, a samozřejmě i podávání nabídek. Vše pochopitelně již v elektronické podobě, a tedy včetně právně platných elektronických podpisů jak na zakázkách, tak i na nabídkách. Dnes tedy tzv. uznávaných elektronických podpisů, do budoucna (od poloviny roku 2016) tzv. kvalifikovaných elektronických podpisů.
Celkově pak má být NEN jakési „ultimátní řešení“ v oblasti veřejných zakázek a jejich centralizovaného zadávání: všechno, co bylo dosud vybudováno a používáno, bude zahozeno, a subjekty z veřejné správy budou pro své veřejné zakázky používat již jen NEN. Podle současných představ by použití NENu pro subjekty veřejné správy mělo být povinné od 1.1.2016 (a do té doby dobrovolné). Jiné zdroje ale zmiňují jeho povinné používání již od 1.1.2015.
Jako IT projekt prošel NEN mnoha a mnoha peripetiemi, které jsou popsány například v tomto článku České pozice („Projekt Národní elektronický nástroj aneb Jak to nedělat“), či v tomto vydání časopisu Veřejné zakázky (na str. 28 až 29). Nejde přitom o žádný malý projekt: zakázku na jeho implementaci, vypsanou na přelomu let 2011 a 2012, s očekávanou cenou 223,5 milionu, vyhrála společnost DATASYS, s nabídkovou cenou cca 150 milionů (a se subdodavateli TESCO SW, CZECHGEEKS a IBM Česká republika). Zakázka na provozování NENu, po dobu 5 let, s předpokládanou hodnotou 250 milionů, se podle dostupných informací teprve vyhodnocuje.
Od 1.4.2014 přitom běžel NEN v „uzavřeném zkušebním provozu“. Od 5.srpna 2014 běží v „otevřeném zkušebním provozu“, kterého se mohou účastnit zadavatelé veřejných zakázek (nikoli potenciální dodavatelé). Do ostrého provozu, zatím zřejmě ještě bez povinného používání, by měl NEN přejít k 1.1.2015. No a od 1.1.2016 by mělo být jeho používání povinné.
Co je na NENu špatně – kolem elektronických podpisů?
V tomto článku nebudu hodnotit NEN jako celek, ani samotné zadávání veřejných zakázek přes NEN, či implementaci NENu na již dále nerozvíjené platformě Silverlight, s naplánovaným zánikem v roce 2021. Zaměřím se jen na jednu konkrétní oblast, kterou je práce s elektronickými podpisy v rámci NENu. Čerpat přitom budu ze zveřejněné dokumentace v podobě uživatelských příruček, které jsou na webu NENu veřejně dostupné.
Ke spuštění otevřeného zkušebního provozu bylo na webu NENu zveřejněno několik různých příruček. Pro oblast elektronických podpisů je nejdůležitější příručka s názvem „Principy práce s certifikáty v aplikaci NEN z pohledu dodavatelů a zadavatelů“. Ta poměrně podrobně popisuje, jak si nechat vystavit kvalifikovaný certifikát od tuzemské akreditované autority, a jak jej následně vyexportovat i s příslušným soukromým klíčem (do souboru s příponou PFX, který je následně nutné někam uložit).
Už samotný export soukromého klíče (spojeného s kvalifikovaným certifikátem od akreditované autority) je velmi problematickou záležitostí: může být vhodný pro potřeby vlastního zálohování soukromého klíče, ale i v takovém případě by měl být řešen opravdu velmi obezřetně a s dodržením bezpečnostních pravidel. Protože kdykoli exportujete svůj soukromý klíč do nějakého souboru (který si někam ukládáte, do nějakého vlastního souborového úložiště), dáváte šanci možnému útočníkovi, který již pronikl do vašeho počítače, aby si tento soubor zkopíroval, a s ním i váš soukromý klíč. Ten sice musí být chráněn heslem, ale ani to v dnešní době, kvůli různým keyloggerům (programům na „odposlech klávesnice“) není problém získat.
Ostatně, i stávající evropská směrnice o elektronických podpisech (pocházející ještě z roku 1999) říká, že pro „právně platné“ elektronické podepisování máme používat jen soukromé klíče, uložené „natvrdo“ v čipových kartách či USB tokenech, bez možnosti jejich exportu. Činí tak skrze požadavek na použití tzv. bezpečného nástroje (pro vytváření elektronických podpisů). Nicméně naše národní právní úprava se od této směrnice odlišuje právě v tom, že u uznávaných podpisů (tedy těch právně platných, na úrovni vlastnoručního podpisu) nepožaduje použití bezpečného nástroje, a kompenzuje si to požadavkem na akreditaci té autority, která k soukromému klíči vystavuje kvalifikovaný certifikát.
Mimochodem: od 1.7.2016 by naší současnou právní úpravu mělo nahradit unijní nařízení eIDAS, které stejný požadavek (na použití bezpečných prostředků, bez možnosti exportu soukromého klíče) nastolí znovu. A tentokráte, díky své formě nařízení (tedy přímo účinného právního předpisu), už bez možnosti obejít tento požadavek na národní úrovni (jako to šlo u směrnice, a jak jsme to u nás skutečně udělali).
Svěřte nám svůj soukromý klíč!
Je-li samotný export soukromého klíče hodně problematickou záležitostí s výraznými bezpečnostními riziky, pak další požadavek NENu je neméně problematický a potenciálně snad ještě nebezpečnější. NEN totiž chce od uživatele, aby mu svěřil svůj soukromý klíč. Ano, ten soukromý klíč, který by jeho držitel neměl nikdy dávat z ruky.
NEN konkrétně chce, aby mu uživatel poskytl právě ten soubor s příponou PFX, do kterého uživatel někdy předtím vyexportoval (spolu se svým kvalifikovaným certifikátem) svůj soukromý klíč. Pochopitelně chce po uživateli i heslo, které tento soukromý klíč v souboru chrání.
Jak si můžete na obrázku sami povšimnout, terminologie používaná v příručce „není úplně ideální“. Zde konkrétně by chybná terminologie dokonce mohla naznačovat, že uživatel by měl sám vytvořit externí elektronický podpis konkrétního dokumentu, a teprve ten pak systému předat, aby jej nějak logicky „asocioval“ se samotným dokumentem. To by po stránce bezpečnosti mohlo být v pořádku – ale o tento případ zde nejde.
Systém zde požaduje soubor nikoli již s „hotovým“ elektronickým podpisem (který mimochodem není nutné nějak utajovat), ale soubor obsahující soukromý klíč. A také odpovídající heslo, aby jej NEN mohl z poskytnutého souboru vyextrahovat a použít – k tomu, aby sám podepsal to, co je třeba podepsat.
Příklad na předchozím obrázku přitom ukazuje příklad registrace do NENu. Požadavek na poskytnutí soukromého klíče se ale týká obecně všech případů, kdy je třeba něco podepsat. Následující obrázek (z jiné příručky) ukazuje pasáž týkající se podpisu vkládané poptávky.
Připomeňme si znovu, že jakékoli poskytnutí soukromého klíče – komukoli či čemukoli, co držitel klíče nemá pod svou výhradní kontrolou – je nejenom vysloveným bezpečnostním hazardem, ale jde i proti požadavkům zákona. Konkrétně proti §2/b3 a §5/1a, které požadují výhradní kontrolu nad soukromým klíčem, náležitou péči o něj a zabránění neoprávněnému použití soukromého klíče (a nepřímo i §5/2, který hovoří o škodě v případě zneužití soukromého klíče). A také proti obdobným požadavkům certifikačních politik autorit (příklad), které k soukromým klíčům vydávají kvalifikované certifikáty. Přičemž podmínkou pro získání takového certifikátu je souhlas s dodržováním příslušné certifikační politiky, podle které je certifikát vydáván.
Jsou nějaké další možnosti?
Pro úplnost si ještě řekněme, že NEN „pamatuje“ na tři možné varianty vytváření elektronického podpisu pro potřeby své aplikace. Kromě té právě popsané, kdy požaduje soukromý klíč (a heslo k němu), pamatuje ještě na dvě další varianty:
- uložení soukromého klíče (i samotného certifikátu) v systémovém úložišti operačního systému
- uložení soukromého klíče (i samotného certifikátu) na čipové kartě (či USB tokenu)
U obou těchto variant již nedochází k tomu, že by uživatel poskytoval svůj soukromý klíč NENu. Zde totiž samotný podpis vzniká mimo aplikaci NEN. Nicméně dostatečně bezpečná může být pouze poslední (třetí) z těchto variant, u které elektronický podpis vzniká přímo na čipové kartě, a samotný soukromý klíč tuto kartu neopouští.
U druhé varianty, s uložením soukromého klíče v systémovém úložišti, probíhá vše v rámci systémového softwaru na uživatelově počítači, a ten může být napaden nejrůznějším malwarem, stát se předmětem útoku apod. Nehledě již na jednoduchou možnost, že s počítačem jako takovým bude pracovat nějaký jiný uživatel. Z hlediska bezpečnosti to tedy není dobré řešení.
Připomeňme si ještě jednou, že po právní stránce (pro vytváření „právně platných“ elektronických podpisů, v dnešní terminologii uznávaných el. podpisů), lze dnes (v ČR) využít i tuto variantu s uložením soukromého klíče v systémovém úložišti. Za dva roky, kvůli nařízení eIDAS, už ale bude možná jen varianta s čipovou kartou (či USB tokenem). Navíc jen takovou, která úspěšně projde procesem certifikace.
Které varianty jsou k dispozici v NENu?
Jestliže NEN „pamatuje“ na tři výše popsané varianty uložení soukromého klíče, bohužel to neznamená, že by je také všechny tři již podporoval a umožňoval jejich využití.
Celá jeho uživatelská dokumentace je postavena jen na variantě „svěřte nám svůj soukromý klíč“, kterou NEN označuje poněkud zavádějícím způsobem jako „certifikát uložený jako soubor v souborovém úložišti“. Nejspíše proto, že když od uživatele vyžaduje (spolu s certifikátem) jeho soukromý klíč, příslušný soubor již musí být někde na počítači („v souborovém úložišti“) uložen, aby si jej aplikace NEN mohla načíst.
Právě tuto variantu přitom NEN považuje za výchozí, a pracují s ní i konkrétní příklady, uváděné v uživatelských příručkách (viz i předchozí obrázky, jeden z nich si připomeňme).
Tyto obrázky přitom naznačují i pravděpodobný důvod toho, proč NEN staví právě na této variantě: jeho aplikace je implementována na platformě Silverlight od společnosti Microsoft, a příslušná komponenta pro práci s elektronickými podpisy nemá ve svém standardním nastavení přístup ke kryptografickým službám místního počítače, které využívají soukromý klíč uložený v systémovém úložišti operačního systému, či uložený na čipové kartě. Proto chce po uživateli, aby jí svůj soukromý klíč poskytl přímo.
Nejspíše si tedy tvůrci NENu nechtěli přidělávat práci s tvorbou vlastní podpisové komponenty, která by tento problém neměla, nebo požadovat po uživateli, aby v Silverlight sám provedl potřebnou úpravu nastavení. Záměr to možná byl v určitém ohledu racionální – ale autoři už asi nedomysleli obrovskou cenu, kterou za to platí jak na poli bezpečnosti, tak i na své reputaci, a v neposlední míře i v souvislosti s požadavky zákonů a certifikačních politik autorit, vydávajících kvalifikované certifikáty.
Když jsem se na existenci této varianty dotazoval přímo u zdroje, dostalo se mi této odpovědi:
Implementace této varianty byla zvolena z toho důvodu, aby aplikace NEN nabídla uživatelům i takovou variantu vytváření elektronického podpisu, která nevyžaduje nadstandardní oprávnění, které jsou nutné pro přístup k systémovému úložišti nebo uložišti na čipové kartě.
A na adresu obavy z toho, že uživatel v rámci této varianty ztrácí kontrolu nad svým soukromým klíčem, když jej svěřuje NENu, jsem se dozvěděl, že:
Práci s certifikáty a privátními klíči zabezpečuje v aplikaci NEN samostatná komponenta, která je realizována v prostředí MS SilverLight. V případě vytváření elektronického podpisu za využití certifikátu a soukromého klíče, jenž je uložen v souboru na diskovém úložišti, pak musí uživatel předat tento soubor aplikaci NEN, přičemž bezpečnost této varianty je zajištěna následujícími opatřeními:
Komponenta běží na klientské straně a certifikát a privátní klíč nejsou odesílány na server.
Komponenta je podepsána certifikátem výrobce, který byl vydán důvěryhodnou certifikační autoritou.
To, že je nějaká softwarová komponenta podepsána s využitím certifikátu od jakékoli autority, ale ještě neříká nic o tom, co a jak se soukromým klíčem dělá. A to, že s ním nedělá nic „nekalého“, by bylo nutné doložit mnohem důvěryhodněji, než nějakou zmínkou typu „soukromý klíč se neodesílá na server“.
Mimochodem, samotný certifikát (který obsahuje veřejný klíč, a nikoli ten soukromý), naopak ona komponenta může odesílat kam chce, protože je plně veřejný. A nejspíše tak i činí, pokud podepsané dokumenty (ke kterým se certifikát standardně přikládá) někde centrálně ukládá.
Co se změnilo?
Připomeňme si znovu, že NEN běžel v uzavřeném zkušebním provozu od 1.4.2014, a v otevřeném zkušebním provozu funguje od 5.8.2014. K tomuto datu také jeho příručka „Principy práce s certifikáty v aplikaci NEN z pohledu dodavatelů a zadavatelů“ hovořila primárně o variantě „svěřte nám svůj soukromý klíč“ (maskované označením „certifikát uložený jako soubor v souborovém úložišti“), zatímco ostatní dvě zmiňovala jen velmi letmo, jako jakousi potenciální možnost, kterou dále nerozváděla.
Následně, k 12.8.2014, vychází nová verze (1.1) téže příručky, již významně přepracovaná. Ta sice nadále říká, že výchozí je varianta „svěřte nám svůj soukromý klíč“ – ale již reflektuje skutečnost, že ne každý je ochoten NENu svůj soukromý klíč skutečně svěřit. A tak tvrdí, že podporuje i ostatní dvě varianty.
Na podporu varianty s uložením soukromého klíče v systémovém úložišti příručka nově odkazuje na postup, jak zvýšit práva softwarové komponenty v Silverlight, aby již mohla pracovat s certifikáty a soukromými klíči, uloženými na počítači (v systémovém úložišti či na čipové kartě).
S podporou varianty, kdy je soukromý klíč uložen na čipové kartě, je to ale poněkud sporné – příručka na jedné straně tvrdí, že NEN tuto variantu podporuje (viz modře vyznačená část obrázku), zatímco červeně vyznačená část hovoří o tom, že tato varianta bude teprve zavedena, podle výsledků otevřeného zkušebního provozu.
S tím, že čipové karty nejsou ještě podporovány, koresponduje i vyjádření, které jsem dostal v odpovědi na můj dotaz:
V rámci vyhodnocení připomínek ze zkušebního provozu bude aplikace NEN doplněna o další způsob práce s certifikáty a privátními klíči a to tak, aby:
a) Podporovala uložení certifikátu a privátního klíč na čipové kartě a USB tokenu.
b) Bylo upraveno rozhraní aplikace tak, aby byly jednotlivé varianty práce s privátním klíčem zřetelněji odlišeny a obsahovaly bezpečnostní pokyny pro příslušnou variantu.
Co si o tom myslí CERTy?
Podle mého názoru ale neměli autoři NENu vůbec ani pomýšlet na variantu „svěřte nám svůj soukromý klíč“, natož ji implementovat, a dokonce ji stále prezentovat jako „výchozí možnost“ (viz i aktualizovaná verze příručky na předchozím obrázku). To je prostě daleko za hranou všech bezpečnostních pravidel, ale i zdravého rozumu a požadavků zákona a certifikačních politik.
Stejně tak je ale otázkou, zda vůbec měli připustit variantu s uložením soukromého klíče v systémovém úložišti. Když už ne z důvodů bezpečnosti, pak i z důvodů perspektivnosti: za dva roky už kvůli nařízení eIDAS budou i ze zákona nutné jen bezpečné prostředky charakteru čipové karty či USB tokenu, navíc certifikované.
Abych zde ale neprezentoval jen svůj pohled, zeptal jsem se na názor tuzemských autorit z oblasti kybernetické bezpečnosti: vládního a národního CERTu/CSIRTu. Jejich odpovědi se v zásadě nijak neliší.
Z vládního CERTu (resp. NCKB, Národního centra kybernetické bezpečnosti) mi odpověděl jeho ředitel, pan Vladimír Rohel:
Považujete variantu s uložením certifikátu a soukromého klíče v systémovém úložišti počítače za vhodné a dostatečně bezpečné řešení pro účely takových aplikací, jako je NEN?
Certifikát je digitálně podepsaný veřejný klíč, který vydává certifikační autorita. Obsahuje informace o majiteli veřejného klíče a vydavateli certifikátu, certifikační autoritě. Z tohoto důvodu ukládání certifikátu tímto způsobem nevidíme jako velký problém.
U soukromého klíče nepovažujeme variantu jeho uložení v systémovém úložišti počítače za optimální. Kdokoliv, kdo má fyzický i vzdálený přístup k PC, může soukromý klíč zcizit. Víme, že některé informační systémy tento způsob uložení využívají, ale nepovažujeme ho za zcela bezpečný a ideální. Naopak, v tomto způsobu uložení pro některé kritické aplikace vidíme bezpečnostní riziko.
Jak hodnotíte variantu s poskytnutím soukromého klíče přímo aplikaci NEN? V příručce je tato varianta označována jako „Certifikát uložený jako soubor v souborovém úložišti“?
Povinnosti podepisující osoby při zacházení se soukromým klíčem (elektronickým podpisem) upravuje zákon 227/2000 Sb., o elektronickém podpisu v paragrafu 5, odstavec 1.
Uložení soukromého klíče do adresáře v souborovém systému počítače považujeme za bezpečnostní riziko. V dnešní době není pro útočníka problém jakýkoliv soubor z počítače ukrást (fyzicky u PC nebo i vzdáleně) a pomocí škodlivého kódu získat i heslo k tomuto souboru. Soubory v souborovém systému nejsou nijak zvlášť chráněny a jejich zjištění i zcizení je opravdu velmi jednoduché.
Ani jedna z uvedených variant podle nás není vhodná pro „kritickou“ aplikaci, např. typu NEN.
Za národní CSIRT mi na stejné otázky odpověděla paní Andrea Kropáčová:
Považujete variantu s uložením certifikátu a soukromého klíče v systémovém úložišti počítače za vhodné a dostatečně bezpečné řešení pro účely takových aplikací, jako je NEN?
Za nejbezpečnější uložení dat typu certifikát a soukromý klíč považuji čipovou kartu, ani uložení v systémovém úložišti počítače není ideální – počítač může být napaden, zcizen, může jej používat více uživatelů atd. Uložení v systémovém úložišti počítače by měli používat pouze uživatelé velmi znalí a schopni bezpečnost takového zařízení zajistit.
Jak hodnotíte variantu s poskytnutím soukromého klíče přímo aplikaci NEN? V příručce je tato varianta označována jako „Certifikát uložený jako soubor v souborovém úložišti“.
Variantu „Certifikát uložený jako soubor v souborovém úložišti“ považuji za zcela nevhodnou a nebezpečnou. Uživatel (držitel certifikátu) se zcela vzdává kontroly nad klíčem a tak nedokáže zajistit jeho bezpečnost.
