Hlavní navigace

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

2. 5. 2002
Doba čtení: 8 minut

Sdílet

S kvalifikovanými certifikáty od I. Certifikační autority se již můžete elektronicky podepisovat i v produktech Microsoftu. Jak je to ale s možností šifrování? I to s kvalifikovanými certifikáty jde, ale musíte správně překonat nástrahy spojené s generováním žádosti o certifikát. Pokusím se vám poradit jak.

Minulý týden jsem zde na Lupě psal o problémech s použitím kvalifikovaných certifikátů od I. Certifikační autority (I.CA) v produktech firmy Microsoft, zejména v jejích emailových klientech. V prvním článku jsem upozorňoval na to, že Outlook ani Outlook Express nedovolují využí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áty 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ů společnosti Microsoft, o druhý se zase opírala I.CA.

Zdá se, že ke stejnému závěru ohledně naplnění položky KeyUsage došly i obě zúčastněné strany. Na webu I.CA vystavily společné stanovisko, 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í?

žá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 KeyUsage, viz obrázek:

Bohužel zde chybí jakékoli vysvětlení jeji významu (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ý je v poštovních klientech firmy Microsoft 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é pro podepisování v produktech společnosti Microsoft využít. To však nevylučuje možnost jeho použití v jiných programech 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). Tato volba odpovídá původnímu stavu, kritizovanému v předchozím dvou článcích.
  • Chce-li žadatel 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 tato volba není implicitní a musíte si ji udělat sami!

Po vyplnění první stránky žádosti o certifikát se dostanete na následující, kde jsou jednak rekapitulovány vámi zadané údaje, ale hlavně zde musíte provést některá další nastavení (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ů, 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 počítači, kde jste jej vytvořili a kde jste také zanechali svůj soukromý klíč. Odtud ho 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ý. Když naopak při generování žádosti volbu potvrdíte, 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 umožnit export.
  • Povolit silnou ochranu soukromého klíče: zde se jedná o to, zda si budete moci explicitně nastavit úroveň ochrany při využití svých 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 jej opatřili. „Střední úroveň“ zaručí upozornění na to, že bude aplikován váš soukromý klíč. Při „nízké úrovni“ se tak nestane. V případě, že si nezvolíte „Povolit silnou ochranu soukromého klíče“, bude automaticky vybrána nízká úroveň. Pokud volbu zaškrtnete, je výběr na vás. Osobně doporučuji povolit silnou ochranu soukromého klíče a následně zvolit vysokou úroveň zabezpečení.
  • Typ klíče: pokud je dostupná možnost „Enhanced Cryptographic Provider“, volte ji.
  • 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 vybíráte, zda budete chtít používat svůj certifikát pouze pro podepisování, nebo pro podepisování i š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ř 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 podepisování (i v produktech firmy Microsoft). Samotný elektronický podpis ale nezahrnuje důvěrnost, realizovanou šifrováním. Pokud ji však žadatel o certifikát bude požadovat, 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ě označit nastavení všech čtyř bitů položky KeyUsage.

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 proč 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 nejde použít pro šifrování. Přitom jsem zjistil, že mi dokonce brání i v tom, abych sám využíval k šifrování certifikáty jiných uživatelů, které je 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íči – a jelikož tento je součástí mého certifikátu, 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 ž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ý email, 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) emailu, 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 email 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 elektronického podpisu, ale „v obráceném gardu“: odesilatel „zamkne“ 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. Takže pokud byl pro „zamknutí“ (zašifrování) použit veřejný klíč oprávněného příjemce, může email snadno „odemknout“ (odšifrovat).

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í veřejného klíče příjemce, 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 mně?

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, 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ílaný email, 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, který pak s dešifrovaným tajným klíčem dešifruje i samotný email.

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

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 – abych já mohl někomu poslat něco zašifrovaného, pomocí jeho veřejného klíče. Ani to mi nedovolí.

BRAND24

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

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

Dokážete si představit situaci, kdy je k něčemu dobrý kvalifikovaný certifikát bez šifrování?

Byl pro vás článek přínosný?

Autor článku

Autor byl dlouho nezávislým konzultantem a publicistou, od 8.6.2015 je členem Rady ČTÚ. 35 let působil také jako pedagog na MFF UK v Praze.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).