Kvalifikovaný certifikát na dvě věci - III.

Minulý týden jsem zde na Lupě psal o problémech s použitím kvalifikovaných certifikátů od I.CA v produktech Microsoftu, zejména v jeho emailových klientech. V prvním článku jsem upozorňoval na to, že Outlook ani Outlook Express nedovolují použít kvalifikovaný certifikát od I.CA pro podepsání odesílané zprávy, a že příčina je zřejmě v chybějícím nastavení bitu DigitalSignature v rozšiřující položce KeyUsage těchto certifikátů. Současně jsem se pozastavoval nad tím, že si I.CA dopředu neověřila, že její kvalifikované certifikátu nejdou takto použít. Ve druhém článku jsem psal o tom, že problém je důsledkem nejednoznačnosti relevantních standardů, konkrétně dokumentů RFC 2459 (o certifikátech obecně) a RFC 3039 (o kvalifikovaných certifikátech), které připouští dva možné výklady: o jeden z nich se opírá fungování produktů Microsoftu, o druhý se zase opírala I.CA.

Zdá se, že ke stejnému závěru ohledně naplnění položky Key Usage došly i obě zúčastněné strany. Na webu I.CA vystavili společné stanovisko MS a I.CA, které říká:

Řešení společnosti Microsoft v oblasti e-mailových aplikací se opírá především o doporučení v RFC 2459 - Internet X. 509 Public Key Infrastructure - Certificate and CRL Profile.

I.CA vycházela také z tohoto doporučení, zároveň však brala v potaz doporučení RFC 3039 - Internet X . 509 Public Key - Infrastructure - Qualified Certificates Profile a na něj navazující dokument ETSI - TS 101 862. Tato doporučení jsou však novějšího data, což bylo také jednou z příčin nekonzistence.

I.CA a Microsoft se shodli v názoru, že obě řešení jsou možná a každé řešení má své opodstatnění v mezinárodních doporučeních vztahujících se k této problematice.

V současnosti I.CA poskytuje volnost ve využívání naplnění této položky a každý klient má možnost si zvolit parametry nastavení této položky dle svého uvážení.

Pojďme se proto podívat, jak se to projevilo prakticky, konkrétně na žádosti o vystavení nového kvalifikovaného certifikátu.

Co je potřeba nastavit pro podepisování?

V žádosti o vystavení nového kvalifikovaného certifikátu (v provedení Standard) přibyla na první stránce možnost explicitního nastavení čtyř bitů položky Key Usage, viz obrázek:

Bohužel zde chybí jakékoli vysvětlení významu jednotlivých nastavení (což nepovažuji za příliš seriózní vůči žadateli, který nemusí být dostatečně "v obraze"). Zde je alespoň mé doporučení, s důrazem na červeně orámované položky:

• Implicitně jsou nyní (před)nastaveny bity digitalSignature a nonRepudiation. To způsobí, že bude vygenerován takový certifikát, který bude v poštovních klientech Microsoftu použitelný pro podepisování i pro ověřování podpisů. Nikoli ale pro možnost šifrování (viz dále).
• pokud žadatel zruší implicitní nastavení bitu digitalSignature (tj. ponechá nastavený pouze bit nonRepudiation), bude vygenerován takový certifikát, který nebude možné využít pro podepisování v produktech Microsoftu. To však nevylučuje možnost jeho použití pro podepisování v jiných produktech a aplikacích (například v rámci systémů, kde uživatel vytváří svou zprávu vyplňováním formulářů na WWW stránce). Toto nastavení odpovídá původnímu stavu, kritizovanému v předchozím dvou článcích.
• pokud žadatel bude chtít používat svůj nový kvalifikovaný certifikát nejen pro podepisování, ale i pro šifrování, měl by si nechat nastavit všechny čtyři bity. Platí to přitom pro možnost šifrování oběma směry - jak pro šifrování odesílaných zpráv, tak i pro přijímání šifrovaných zpráv (viz dále). Připomínám, že toto nastavení není implicitní a musíte si jej udělat sami!

Po vyplnění první stránky žádosti o certifikát se dostanete na následující stránku, kde jsou jednak rekapitulovány vámi zadané údaje, ale hlavně zde musíte provést některé další volby (viz obrázek):

• povolit export soukromého klíče: zde je třeba si uvědomit, že svá párová data (dvojici soukromý a veřejný klíč) generujete prostřednictvím aplikace vložené do WWW stránek na určitém konkrétním počítači. Soukromý klíč, který přitom vznikne, bude uložen do standardního uložiště certifikátů na tomto počítači, a pouze veřejný klíč bude přiložen k vaší žádosti, kterou odnesete (na disketě) na I.CA. Až ta vám vystaví váš certifikát, vy si jej musíte nejprve instalovat na tom počítači, kde jste jej vytvořili a kde jste také zanechali svůj soukromý klíč. Z tohoto počítače jej také můžete nadále používat. Pokud jste v žádosti nezatrhli možnost "povolit export soukromého klíče", budete na tento počítač odkázáni a nebude moci svá párová data (hlavně soukromý klíč) přenést na jiný počítač. Pokud naopak při generování žádosti možnost exportu zaškrtnete, budete moci následně "vyexportovat" svá párová data např. na disketu a přenést je (importovat) na jiný počítač, nebo si je ponechat jako záložní kopii. Doporučuji povolit export.
• povolit silnou ochranu soukromého klíče: zde se jedná o to, zda si budete moci explicitně nastavit úroveň ochrany při použití vašich párových dat: "vysoká úroveň" bude znamenat, že před každým použitím soukromého klíče budete muset zadat heslo, kterým jste svůj soukromý klíč opatřili. "Střední úroveň" znamená, že budete pokaždé upozorněni na to, že bude použit váš soukromý klíč. Při "nízké úrovni" nebudete ani upozorněni. V případě, že si nenastavíte "povolit silnou ochranu soukromého klíče", bude automaticky nastavena nízká úroveň. Pokud volbu zaškrtnete, budete si moci vybrat. Osobně doporučuji povolit silnou ochranu soukromého klíče a následně zvolit vysokou úroveň ochrany.
• typ klíče: pokud je dostupná možnost "Enhanced Cryptographic Provider", volte tuto možnost
• název klíče: (položka je vyplněna automaticky)
• klíč pro podpis, resp. klíč pro podpis a šifrování: pomocí tohoto přepínače volíte, zda budete chtít používat svůj certifikát pouze pro podepisování, nebo pro podepisování i pro šifrování. Přesný mechanismus fungování této volby mi zůstal utajen, z vlastní zkušenosti však mohu potvrdit, že samotné zaškrtnutí této položky (bez současného nastavení všech čtyř volitelně nastavitelných bitů na předchozí stránce, v položce Key Usage) nezajistí, že certifikát bude použitelný pro šifrování!!!

Jak je to se šifrováním?

Jak jsem již naznačoval v úvodu, s možností šifrování (a ne pouze podepisování) je stále určitý problém. Implicitní nastavení žádosti je takové, že výsledkem bude certifikát použitelný pro podpis (i v produktech Microsoftu). Samotný elektronický podpis ale nezahrnuje důvěrnost, realizovanou šifrováním. Pokud ale žadatel o certifikát bude požadovat důvěrnost, neboli používat šifrování, pak by si jistě mohl myslet, že stačí na druhé webové stránce s generováním žádosti zaškrtnout "klíč pro podpis i pro šifrování". Nikde ale není varován, že to nestačí a že ještě musí (na předchozí stránce!!!) explicitně zaškrtnout nastavení všech čtyř bitů položky Key Usage.

Zde se opravdu velmi přimlouvám za to, aby I.CA nenechávala svého zákazníka na holičkách a informovala ho, co a jak musí udělat. Jak už nejspíše vyplývá z předchozích řádků, sám jsem na to také doplatil, a tak mám nový kvalifikovaný certifikát, který sice jde použít pro podepisování, ale nikoli pro šifrování. Nezaškrtnul jsem si totiž nastavení bitu keyEncipherment, který je podle RFC 2459 používán pro šifrování klíčů, ale nastavil jsem si "navíc" (k nonRepudiation a digitalSignature) pouze bit dataEncipherment (pro šifrování dat). To ale byla chyba.

Proč nejde šifrovat?

Když už se mi ale poštěstilo vydat se jednou ze slepých uliček, mohl jsem ji alespoň podrobněji prozkoumat a zjistit, proč můj certifikát bez nastaveného bitu keyEncipherment nejde použít pro šifrování. Přitom jsem zjistil, že mi dokonce brání i v tom, abych sám využíval pro šifrování certifikáty jiných uživatelů, které šifrování připouští.

Zde musím, v zájmu srozumitelnosti, udělat malou exkurzi do teorie a naznačit, jak funguje samotný elektronický podpis a jak šifrování. Když to řeknu opravdu hodně zjednodušeně, pak si lze představit, že při podpisu zprávu "zamknu" svým soukromým klíčem, a "odemknout" pak jde právě a pouze mým veřejným klíčem. Odemknout ji tedy může kdokoli, kdo má přístup k mému veřejnému klíč - a jelikož tento je součástí mého certifikátu, který je veřejně dostupný, může to být skutečně každý. Celý "fígl" elektronického podpisu je tedy založen na tom, že nikdo jiný kromě mne, vlastníka disponujícího soukromým klíčem, nemohl zprávu "zamknout" (a dále že ze znalosti veřejného klíče nejde vypočítat klíč soukromý).

Zdůrazněme si ale, že samotný elektronický podpis nezajišťuje důvěrnost, neboli to že si podepsanou zprávu nebude moci přečíst někdo nepovolaný. Samotná zpráva, opatřená elektronických podpisem (tedy "zamknutá", ve výše uvedeném smyslu) je stále stejně čitelná jako zpráva nepodepsaná. Ve skutečnosti totiž podpis vzniká tak, že se sejme jakýsi otisk (tzv. hash) zprávy, ten se zašifruje soukromým klíčem a přiloží k původní zprávě v roli jejího elektronického podpisu.

Pokud ale má být dosaženo důvěrnosti, neboli toho aby si zprávu nemohl přečíst nikdo jiný než oprávněný příjemce, pak je nutné použít šifrování (buďto v kombinaci s elektronickým podpisem nebo bez něj). Princip je analogický jako u el. podpisu, ale "v obráceném gardu": odesilatel "zamkne" odesílanou zprávu pomocí veřejného klíče příjemce. Tentokráte ale jde o "zamknutí" ve smyslu zašifrování celé zprávy. Dešifrovat ji lze pouze s pomocí soukromého klíče, který "pasuje" k použitému veřejnému klíči. Takže pokud byl pro "zamknutí" (zašifrování) použit veřejný klíč oprávněného příjemce, může zprávu zase "odemknout" (odšifrovat) pouze oprávněný příjemce disponující svým soukromým klíčem.

Potud tedy princip šifrování, s maximální zjednodušením. Co z toho ale vyplývá pro použitelnost kvalifikovaného certifikátu? Pomocí mého veřejného klíče by šifroval ten, kdo by chtěl poslat něco zašifrovaného mě. Naopak já, při odesílání šifrované zprávy někomu jinému, musím šifrovat pomocí příjemcova veřejného klíče, z jeho veřejného certifikátu.

Když ale můj kvalifikovaný certifikát má nastavený bit dataEncipherment, proč nedovolí jiným zašifrovat datovou zprávu posílanou mě?

Důvod je skryt v tom, jak konkrétně probíhá přenos šifrovaných zpráv. Zde se totiž využívá příznivějších vlastností tzv. symetrického šifrování (s jediným tajným klíčem místo dvou klíčů, soukromého a veřejného). Důvodem jsou výrazně nižší nároky na výpočetní kapacitu. Když tedy má odesilatel zašifrovat odesílanou zprávu, vygeneruje si nejprve tajný klíč, kterým celou zprávu zašifruje pomocí technik symetrického šifrování (což je jednodušší a rychlejší než při použití soukromého či veřejného klíče a asymetrických technik). Aby však příjemce mohl obsah zprávy dešifrovat, musí mu odesilatel poslat i příslušný tajný klíč, samozřejmě ale ne "jen tak". Proto je tento tajný klíč také zašifrován, a to již asymetrickým šifrováním, veřejným klíčem příjemce. Dešifrovat jej může, pomocí svého soukromého klíče, právě a pouze oprávněný příjemce, který pak s dešifrovaným tajným klíčem dešifruje i samotnou zprávu.

Pokud ale nečí veřejný klíč nedovoluje šifrování klíčů, pak mu nejde poslat takto zašifrovanou zprávu.

Proč nejde šifrovat ani s cizími certifikáty?

Při experimentování se svým novým kvalifikovaným certifikátem jsem dále zjistil, že nefunguje ani obrácený směr - to, abych já mohl někomu poslat něco zašifrovaného, pomocí jeho veřejného klíče. Ani to mi můj kvalifikovaný certifikát nedovolí.

Problém je nejspíše v tom, že poštovní klienti (MS Outlook, Outlook Express) standardně uchovávají kopii odeslaných zpráv (v příslušné složce s odeslanou poštou). Aby takováto zašifrovaná kopie byla stále zašifrovaná, ale současně byla čitelná pro mne jako odesilatele, poštovní klient se snaží zašifrovat tajný klíč také mým veřejným klíčem, abych zprávu mohl následně, ve složce s odeslanou poštou, někdy později zase dešifrovat a přečíst. Ale můj veřejný klíč bez nastaveného bitu keyEncipherment nejde použít pro zašifrování tajného klíče, a MS Outlook mi proto nedovolí odesílat zašifrované zprávy (s poukazem na neplatnost mého certifikátu).

Bohužel nepomáhá ani když se vypne ukládání zpráv do příslušné složky s odeslanou poštou. To už je ale problém produktů Microsoftu, ne samotného kvalifikovaného certifikátu.