Vyšlo na Lupě, 20.08.2016
Vytištěno z adresy: http://www.earchiv.cz/b19/b0820001.php3

Podepisujeme se s eliptickými certifikáty, část I: kde to ještě drhne

Řada potřebných nástrojů a služeb, včetně naší nové eOP, je na elektronické podpisy s eliptickými křivkami již připravena a pracuje s nimi. Problémy jsou zatím spíše s ověřováním důvěryhodnosti nových certifikátů.

S možností využívat kryptografii eliptických křivek (ECC, Elliptic-Curve Cryptography) pro elektronické podepisování počítala naše právní úprava již od samého počátku: mezi využitelnými možnostmi je explicitně uváděla již vyhláška č. 366/2001 Sb., stejně jako na ni navazující vyhláška 212/2012 Sb. Současné nařízení eIDAS ani jeho prováděcí předpisy do takovéto „hloubky“ nejdou, ale využití eliptických křivek pro elektronické podepisování alespoň nijak nebrání.  

Přesto trvalo docela dlouho, než se i u nás začaly podpisové certifikáty s využitím eliptických křivek skutečně vydávat. Jako první s nimi přišla v polovině letošního července I.CA. Byť je zatím vydává pouze v poněkud omezeném provozu (jen v sídle společnosti a jen konkrétním zájemcům, viz následující obrázek).

 
Oznámení I.CA
 

Nejde přitom jen o podpisové certifikáty, přesněji o kvalifikované certifikáty pro elektronický podpis. Jak vyplývá z oznámení na obrázku, jsou nově – s využitím kryptografie eliptických křivek – vydávány i kvalifikované certifikáty pro elektronické pečeti. A také (osobní) komerční certifikáty, i (serverové, technologické) komerční certifikáty. Trochu překvapivě zde nejsou zmíněny SSL certifikáty, u kterých by se výhody eliptických křivek mohly projevit asi nejvíce.

Další dvě certifikační autority (kvalifikovaní poskytovatelé), vydávající kvalifikované certifikáty pro veřejnost, signalizují obdobný záměr s technologií eliptických křivek, ale na jeho uskutečnění zatím teprve pracují:

PostSignum: Problematikou vydávání certifikátů s ECC se zabýváme již od roku 2016, ale tehdy nám z analýz vyplynulo, že některé systémy a aplikace mají s tímto algoritmem problémy. Proto jsme tuto problematiku zatím odložili. Vybudování nové certifikační autority s podporou ECC máme v plánu až v příštím roce, tj. v roce 2020.
eIdentity: Problematikou se zabýváme, jsme ve stadiu příprav a úprav SW i dokumentace. Bohužel se prozatím neblížíme testování vydávání takových certifikátů.

A k eliptickým křivkám má do budoucna cestu otevřenou i nová Národní certifikační autorita (NCA), která teprve nedávno prošla nezbytnou certifikací a která poskytuje své služby pouze „pro vybrané subjekty veřejné správy a jejich zaměstnance“. Usuzuji tak z toho, že jediným prostředkem, který si tento nový kvalifikovaný poskytovatel nechal zařadit na seznam vydávaných kvalifikovaných prostředků, je rovnou ta varianta čipové karty Starcos (3.5 ID ECC C1R), která eliptické křivky podporuje. Zatím ale nová NCA zveřejnila certifikační politiku (pro vydávání kvalifikovaných certifikátů pro elektronický podpis) jen pro „tradiční řešení“ na bázi RSA (viz dále).

ECC certifikát k soukromému klíči na kvalifikovaném prostředku

Abych mohl vyzkoušet, jak nová technologie v praxi funguje a jak je či není podporována, nechal jsem si u I.CA vystavit dvojici nových certifikátů s eliptickými křivkami: kvalifikovaný certifikát pro elektronický podpis a (osobní) komerční certifikát.

Přitom jsem využil toho, že na eliptické křivky je už připravena i nová elektronická občanka (vydávaná od července 2018). Ta má celkem 8 kontejnerů pro soukromé klíče a certifikáty „klasického provedení“ (na bázi RSA, na následujícím obrázku nahoře a modře) a dalších 8 kontejnerů pro klíče a certifikáty na bázi eliptických křivek.

 
obsah úložiště na čipové kartě v rámci eOP
 

Na informačním webu SZR, který je věnován nové eOP, lze k tomu najít docela prorocká slova, zřejmě ještě z loňského roku:

Většina kvalifikovaných certifikačních autorit dnes používá kryptografický algoritmus RSA. Držitelé občanských průkazů tedy v dohledné době budou využívat především certifikáty a klíče pro algoritmus RSA. (Pozice pro klíče a certifikáty algoritmu ECC zatím zůstanou nevyužity.) Ve střednědobém horizontu se očekává relativní slábnutí algoritmu RSA. Předpokládá se, že certifikační autority budou na tuto situaci reagovat přechodem na modernější algoritmus ECC, založený na eliptických křivkách. Občanský průkaz je na tuto (budoucí) změnu připraven. Držitelé nebudou muset pro využívání certifikátů s kryptografií ECC vyměňovat své občanské průkazy. Jakmile budou certifikační autority připraveny, mohou využívat pozice pro klíče a certifikáty s kryptografií ECC.

Jak si ještě řekneme (hlavně ve třetím, závěrečném dílu tohoto malého seriálu), hlavní předností kryptografie eliptických křivek je skutečně jejich „větší síla“, oproti dnes používanému řešení na bázi algoritmu RSA. Přesněji: možnost dosažení stejné či větší „síly“ (úrovně kryptografické bezpečnosti), a to při nižší „režii“ (menších klíčích a menší náročnosti na výpočetní kapacity).

Zatím se ale vraťme zpět k naší nové eOP: ta je kvalifikovaným prostředkem pro vytváření elektronických podpisů (QSCD). Jako taková sice není uvedena ani na příslušném unijním seznamu, ani na našem národním seznamu kvalifikovaných prostředků (možná i proto, že není vydávána kvalifikovaným poskytovatelem). Ale podle našeho MV ČR splňuje všechny příslušné požadavky.

Proto když jsem si (v rámci žádosti o nové certifikáty) nechal vygenerovat příslušná párová data přímo na nové eOP, mohla certifikační autorita nastavit v kvalifikovaném certifikátu příznak o umístění soukromého klíče na kvalifikovaném prostředku (QSCD):

 
Nastavení příznaku o umístění soukromého klíče na kvalifikovaném prostředku
 

Dovolím si připomenout, že právě tento příznak rozhoduje o tom, jestli elektronický podpis, založený na tomto certifikátu, bude kvalifikovaným elektronickým podpisem (pokud je příznak nastaven), nebo pouze zaručeným elektronickým podpisem, založeným na kvalifikovaném certifikátu (neboli: „českým“ uznávaným elektronickým podpisem).

Jaké křivky jsou podporovány?

Při generování žádostí o nový certifikát, využívající kryptografie eliptických křivek, nabízí I.CA tři varianty křivek podle následujícího obrázku.

 
Volba křivky při generování žádosti o certifikát
 

Jde o křivky, známé též jako (NIST) P-256, P-384 a P-521, přičemž trojice čísel u každé z nich je současně i délkou klíče, se kterým zvolená varianta pracuje. Jde o křivky, které patří mezi dnes nejpoužívanější – ale pokud mohu tipovat, při jejich výběru určitě sehrála významnou roli i podpora v běžně dostupných kvalifikovaných prostředcích.

Spolu s řadou dalších křivek by tuto trojici měla podporovat i výše zmiňovaná karta Starcos 3.5 ID ECC C1R (kterou může vydávat jak I.CA, tak i nová NCA).

Trochu jinak je na tom karta ProID+Q, která podle dostupných specifikací podporuje kromě tří výše uvedených křivek už jen jednu další – křivku P-224, resp. secp224r1, která je vzhledem k ostatním „nejslabší“. I ta je ovšem srovnatelně silná jako dnes běžně používané RSA s klíčem o velikosti 2048 bitů (viz dále).

Mimochodem, karta ProID+Q není mezi těmi, které I.CA vydává jako kvalifikované prostředky – takže vám nejspíše nevystaví kvalifikovaný certifikát s příznakem uložení klíče na tomto QSCD. Můžete si ale na tuto kartu nahrát soukromý klíč s kvalifikovaným certifikátem bez tohoto příznaku (a pak vytvářet jen zaručené elektronické podpisy, založené na kvalifikovaném certifikátu).

Hlavně ale: naše nové elektronické občanky (které I.CA jako QSCD již podporuje), vychází ze stejného technologického řešení jako karty ProID+Q: podle stanoviska MV ČR jde konkrétně o certifikované technologie „IAS Classic V4.4 with MOC Server 1.1 on MultiApp V4“, umístěné na čipu M7892 G12. Z toho, při absenci jiných veřejně dostupných informací, dovozuji, že by naše nové eOP měly podporovat stejné křivky jako karty ProID+Q. Tedy křivky P-224, P-256, P-384 a P-512.

K vynechání „nejslabší“ křivky P-224 z nabídky I.CA pak nejspíše vedlo to, že tuto křivku nepodporují produkty Adobe (Acrobat a Reader): podle dostupných informací podporují od verze 11 výše právě a pouze křivky P-256, P-384 a P-521.

Produkty Adobe se tak zdají být „nejužším místem“ celého řetězce, potřebného pro podepisování a práci s elektronickými podpisy, které využívají kryptografie eliptických křivek – protože jinde je podpora přeci jen širší, co do počtu různých eliptických křivek. Například operační systém Windows 10 podporuje podstatně více křivek. Nutno ovšem dodat, že tuto podporu nabízí až jeho novější API s názvem CNG (Cryptography API: Next Generation), které nahradilo původní rozhraní MS CAPI.

Jak dopadl první „eliptický“ podpis?

Sám jsem si od I.CA nechal vystavit nové certifikáty s využitím „nejsilnější“ křivky P-521, resp. secp521r1, a vše proběhlo hladce. Včetně následného „využití“, resp. vytvoření kvalifikovaného elektronického podpisu – v „běžném“ prostředí MS Windows 10, pomocí programu Signer od SW 602.

Když jsem pak takto podepsaný dokument předložil kvalifikované službě pro ověřování platnosti elektronických podpisů SecuSign, vyhodnotila jej správně jako kvalifikovaný elektronický podpis.

 
Výsledek ověření pomocí kvalifikované služby SecuSign
 

Stejně tak jej správně (jako kvalifikovaný elektronický podpis) vyhodnotila i služba I.CA QVerify. Mimochodem, tato služba předává výsledek ověření systémům na straně klienta/uživatele v XML, a teprve tyto systémy (např. spisové služby) se starají o jejich interpretaci a „vizualizaci“. Proto na následujícím obrázku vidíte právě takovýto XML kód, který je ale vcelku samovypovídající.

 
Výsledek ověření pomocí kvalifikované služby QVerify
 

Obdobně (správně) to dopadlo, když jsem stejný dokument předložil „unijnímu validátoru“:

 
Výsledek ověření pomocí tzv. unijního validátoru
 

Problém nastal až v okamžiku, kdy jsem si dokument otevřel v Adobe Acrobat Readeru DC a chtěl ověřit platnost jeho elektronického podpisu. Výsledkem bylo pokrčení ramen neboli zjištění, že platnost podpisu je neznámá. A to proto, že Adobe Reader můj nový certifikát nezná a nemá odkud (z čeho) dovodit, zda mu může důvěřovat (viz text v modrém rámečku).

 
Výsledek voěření v Adobe Readeru
 

Stejně tak Reader nedokázal dovodit, jakého druhu certifikát je – že je kvalifikovaný. Takže nemohl dojít ani k závěru, že podpis jako takový je kvalifikovaný.

Nepomáhá ani to, co jste viděli již na dnešním třetím obrázku a co si zde můžeme připomenout: že samotný certifikát má v sobě (v položce QC Statements, resp. Výpisy QC) formou příznaků explicitně uvedeno jak to, že jde o certifikát pro elektronický podpis, tak i to, že jde o kvalifikovaný certifikát. I to, že byl vystaven k soukromému klíči, který byl vygenerován (a je umístěn) v kvalifikovaném prostředku (QSCD).

 
Zobrazení obsahu položky QCStatements
 

Kde je problém?

Potíž je v tom, že certifikát s takto (či úplně jinak) nastavenými příznaky by si mohl snadno vytvořit kdokoli a sám – a jeho obsah tak vůbec nemusí být pravdivý, resp. odpovídat skutečnosti. Proto každý program, který ověřuje platnost elektronických podpisů (tedy nejenom Adobe Reader), potřebuje vědět, zda příslušný certifikát může považovat za důvěryhodný a zda se může spoléhat na jeho obsah.

Jak si podrobněji rozvedeme později, standardním řešením je odvozování důvěry v koncový certifikát z důvěry v jeho vydavatele a ze znalosti podmínek služby, v rámci které byl vystaven. Program Adobe Acrobat Reader ale v daném případě neměl k dispozici žádnou takovouto informaci. Proto výsledek ověření skončil oním „pokrčením ramen“.

Mimochodem: stejně je na tom i operační systém Windows. Ani ten můj nový „eliptický“ certifikát nezná a nemá odkud si odvodit jeho důvěryhodnost – protože ani on nezná jeho vydavatele.

 
(Ne)důvěra v certifikát v systému Windows
 

Takže i ty programy, které při ověřování platnosti elektronických podpisů využívají funkcí operačního systému Windows – jako například aplikace MS Office – skončí stejně jako Adobe Acrobat Reader: pokrčením ramen a konstatováním, že platnost podpisu není známa (resp. že se ověření platnosti nepodařilo provést).

 
Výsledek ověření v programu MS Word
 

Příčina problému – chybějící informace o důvěryhodnosti certifikátu a možnosti spoléhat se na jeho obsah – je tedy v obou případech (u Adobe Acrobat Readeru i samotných Windows) stejná. Ale konkrétní důvod, proč tomu tak je, je v obou případech jiný – a tím pádem jsou jiná i potřebná řešení. Těmi se ale budeme zabývat až v dalším dílu tohoto malého seriálu.

Dnes si místo toho povíme ještě o dalších možných problémech, které mohou vznikat (či již vznikají) při použití certifikátů využívajících kryptografii eliptických křivek.

Online podepisování a přihlašování je zatím problematické

Kvalifikované certifikáty jsou určeny právě a pouze k podepisování. To se obvykle odehrává na počítači uživatele, a o využitelnosti nových certifikátů tak rozhodují jak schopnosti „nosičů“ (čipových karet a tokenů) a jejich obslužných programů, tak i schopnosti dalších utilit a aplikací běžících přímo na počítači uživatele.

Někdy ale potřebujeme něco podepsat online, v rámci nějaké online aplikace – například když podáváme daňové přiznání v rámci aplikace EPO. Podepisování pak probíhá skrze applet vložený do webových stránek, který pracuje s příslušnými utilitami a ovladači (tzv. CSP providery) na počítači uživatele. I zde je ale nutná podpora, resp. připravenost na certifikáty, využívající kryptografie eliptických křivek, včetně možnosti získat informace o jejich důvěryhodnosti.

Otestovat reálnou využitelnost nových „eliptických“ certifikátů konkrétně v aplikaci EPO skrze skutečné podání jsem raději neriskoval – ale vyzkoušet jsem mohl alespoň přihlašování do daňové informační schránky na Daňovém portále Finanční správy.

Mimochodem, toto přihlašování (k daňové informační schránce, resp. k daňovému portálu) vyžaduje kvalifikovaný certifikát – což je ale ve sporu se skutečností, že kvalifikované certifikáty se smí používat jen k podepisování a k ničemu jinému. Zde konkrétně se to ale obchází tak, že uživatel se pomocí svého kvalifikovaného certifikátu formálně nepřihlašuje, ale podepisuje žádost o přihlášení. Podle názoru našeho MV ČR to je v pořádku.

Nicméně se svým novým (kvalifikovaným) „eliptickým“ certifikátem jsem na Daňovém portále neuspěl. Certifikát byl sice rozpoznán a byl mi nabídnut k podepsání žádosti o přihlášení – ale při samotném podepisování došlo k chybě, viz následující obrázek.

 
Pokus o přihlášení k daňové informační stránce
 

Moc jsem neuspěl ani při skutečném přihlašování pomocí „eliptického“ komerčního certifikátu.

Zkoušel jsem to u datových schránek, které znají rozdíl mezi komerčními a kvalifikovanými certifikáty a vyžadují ty komerční – ale můj nový komerční certifikát, využívající kryptografii eliptických křivek, nebyly ochotné přijmout. Přesněji: ani mi nebyl nabídnut mezi těmi, které lze pro přihlášení využít.

To třeba portál Moje VZP, který „vidí“ (a nabízí k využití) i kvalifikované certifikáty, mi nový komerční certifikát jako možnost nabídl.

 
Výběr certifikátu při přihlašování do služby Moje VZP
 

Následně mi ale přihlášení pomocí „eliptického“ komerčního certifikátu stejně neprošlo.

 
Neúspěšné přihlášení do služby Moje VZP
 

Důvodem všech těchto neúspěchů může být jak chybějící podpora kryptografie s využitím eliptických křivek, tak absence možnosti odvodit důvěru v použitý certifikát.

To už jsou ale věci, kterým se budeme věnovat v další části tohoto seriálu. V té si povíme o tom, že I.CA si pro vydávání nových „eliptických“ certifikátů musela vytvořit novou certifikační autoritu. Řekneme si také, v jakém stavu je zařazení certifikátů této nové autority na unijní seznam důvěryhodných seznamů (LOTL) a do seznamu/programu Trusted Root Program společnosti Microsoft. Protože právě to jsou věci, které rozhodují o tom, zda konkrétní nástroje budou považovat nové „eliptické“ certifikáty za důvěryhodné, či nikoli.