Utekly kódy je to pohroma!

Letošní únorový pátek třináctého byl, přinejmenším pro společnost Microsoft
Corporation, vskutku nešťastným dnem. Došlo totiž k neautorizovanému zveřejnění

části zdrojových kódů operačních systémů Windows NT4 a 2000. Co vše to může

znamenat pro svět a pro internet, nebo pro telekomunikace vůbec? Znamená to

hodně. První zprávy hovořily o tom, že vyzrazené kódy představují pouze malou

část celých Windows. Posléze se ale ukázalo, že zhruba dvousetmegabajtový

archiv obsahuje velké množství podstatných komponent tvořících OS. Z toho, co

uteklo, sice není možné zkompilovat funkční Windows, ale to není příčinou, proč

kódy zmizely.



Zdrojový kód

Prakticky každý program a operační systém je vlastně velice složitá sada

počítačových programů, a může existovat ve dvou podobách. První z nich tvoří

zkompilovaný binární (pseudobinární) kód. To jsou všechny ty soubory s

příponami .exe, .dll, .sys a další. Právě ony mohou fungovat, mohou být

spuštěny a vykonávat nějakou činnost. Proto se distribuují uživatelům.

Kromě toho ale každý program existuje ve formě takzvaných zdrojových kódů nebo

textů. Jsou to skutečně textové soubory obsahující struktury programovacího

jazyka, ve kterém je program napsán. Teprve po zpracování těchto textů aplikací

nazvanou Kompilátor je vytvořen například náš soubor .exe, který již lze běžným

způsobem spustit a provozovat.

Zkompilovaný kód lze spustit, ale není jej možno změnit. Všechny změny v

programu nebo jeho modulu (s výjimkou některých, pokud to program umožňuje) je

proto třeba provádět v jeho zdrojových textech. Aby se jakákoliv změna promítla

do fungujícího programu, musí být po jejím provedení znovu zkompilován. Proto

jsou zdrojové kódy tak chráněným a cenným zbožím, tedy alespoň pro společnosti

tvořící proprietární software, mezi něž se řadí i Microsoft.



Kód ve službách zločinu

Uteknuvší zdrojové texty Windows mohou být snadno zneužity proti jejich autorům

a především uživatelům. Předpokládá se, že kód obsahuje množství chyb. Na

některé lze přijít i z jeho zkompilované podoby, jiné jsou naopak zřejmé pouze

ze zdrojového textu. Pokud tento text máme k dispozici, můžeme takové chyby

odhalit a zneužít je například k průniku do zabezpečeného operačního systému.

Stejně tak jimi může být systém zastaven, restartován, anebo výrazně pozměněna

jeho funkčnost. To je ohromné riziko, kterého si je výrobce velmi dobře vědom.

Ukradené kódy sice patří dnes již zastaralým systémům, respektive jejich

verzím, avšak i tak se vyskytují i v nových OS Windows XP a připravovaném

systému Longhorn, stejně tak jako ve Windows Serveru 2003. Díky tomu se riziko

přesouvá i na tyto operační systémy. Všechny červy, kterým se až doposud

povedlo masivní rozšíření, s jedinou významnou výjimkou, vyžadovaly být

spuštěny uživatelem. Znalost zdrojových kódů však otevírá cestu k novým,

dokonalejším škodlivým kódům. Takovým, které se podobně jako loňský Blaster

mohou do OS dostat jinak než e-mailem, formou přímého útoku. Navíc hrozí, že

záplatování využité chyby bude ztíženo její složitostí, nebo že takový škodlivý

kód bude využívat důležitých služeb, které nelze dost dobře změnit.



Kód ve službách lidstva

Existují ovšem i pozitivní věci spojené s útěkem zdrojového kódu z Microsoftu.

Především programátoři, kteří se ke zdrojovým kódům (ilegálně) dostali, se

mohou konečně podívat, jak Windows uvnitř ve skutečnosti pracují. V důsledku

toho mohou být jejich aplikace lépe naprogramované. Mohou také lépe využívat

vnitřních služeb operačního systému, díky tomu běžet rychleji, lépe a být méně

poruchové. Nedostatky, které vyplynou kvůli nechtěnému zveřejnění kódů na

povrch, mohou být opraveny dříve, než jsou zneužity. Už samotný fakt, že se

zdrojové texty dostaly na veřejnost, donutil výrobce systému k masivní vlně

prověření jeho bezpečnosti, k preventivnímu vyhledávání možných slabých míst.

Dá se předpokládat, že texty využije ke stejné činnosti také mnoho dalších

dobrovolníků, a tak se to, k čemu došlo, může stát vlastně užitečným jak

uživatelům, tak v konečném důsledku i Microsoftu.



Klon na cestě?

O klonování lidí se vedou dalekosáhlé spory, ale jak je to s klonováním

operačního systému? Jak už bylo řečeno, z toho, co uteklo, funkční Windows

neuděláme. Přesto mohou být texty využity při tvorbě řekněme nového operačního

systému, nebo při vývoji současných napodobenin. Například pod operačním

systémem Linux lze již nyní provozovat některé aplikace pro Windows, včetně

například Microsoft Office. Poznání původních zdrojových textů bude mít

pravděpodobně za následek zdokonalení technologií, jež toto umožňují, tak, že i

ty aplikace, které nyní nefungují, ani na specializovaných distribucích jako

jsou Lindows, fungovat budou (jsou to především hry).

Útěk zdrojových textů Microsoftu, respektive Mainsoftu, byl v první řadě

intelektuální krádeží. Tato krádež přináší mnoho nových rizik, ale také mnoho

pozitiv, obojí v globálním měřítku. Zdrojáky OS Windows jsou na veřejnosti

velikým pozitivem, stejně tak jako nebezpečnou zbraní. Záleží jen na tom, jakým

způsobem se jich využije.

§§§§§

Důvěřuj, ale prověřuj



Patrik Malina



C04P0188

V první části našeho článku o nezpochybnitelné identitě v kybernetickém světě,

jejž najdete v minulém vydání PC WORLDu, jsme se věnovali zvláště základním

principům a ukázkám, jak vlastně vypadá certifikát a jakým způsobem s ním lze

pracovat. V minulém dílu našeho článku jsme si objasnili základní vlastnosti

asymetrické kryptografie a přiblížili jsme si její principiální vlastnosti,

jejichž výhod v současné době využíváme. Jednou ze zásadních aplikací tohoto

univerzálního schématu je postup, běžně zjednodušeně označovaný jako digitální

podpis. Protože se jedná o funkci klíčového významu, blíže si zde osvětlíme

její podstatu, a v následujících odstavcích pak předvedeme praktické nasazení

při poštovní komunikaci. Pokud jsme pár veřejný a privátní klíč dosud využívali

při šifrování, postup byl vždy jednoznačný: veřejný klíč adresáta-příjemce

posloužil pro operaci zašifrování a jeho příslušný privátní klíč pak posloužil

k rozšifrování utajených dat. Tento postup tedy vyřeší utajení, ovšem naší

snahou je zajistit ještě neméně důležitý druhý cíl, kterým je ověření pravosti

odesílatele a potvrzení, že zprávu v průběhu cesty nic nepozměnilo a

nepoškodilo, tedy nebyla např. podvržena.

Právě tuto fázi zajistí digitální podpis, při němž jsou klíče použity odlišným

způsobem. Na rozdíl od šifry musí při podpisu odesílatel mimo jakoukoliv

pochybnost prokázat, že zpráva pochází od něj. To znamená, že ji musí označit

nějakým „otiskem“, jehož autorem nemůže být nikdo jiný. Pomocí čeho to provede?

Hádáte správně jediná utajená „věc“, kterou má každý uživatel ve své absolutní

moci a střeží ji jako tajemství, je privátní klíč. Myšlenka je tedy taková, že

sestavená zpráva je v zásadě podepsána privátním klíčem odesílatele a posléze

vypuštěna do internetu běžnou cestou (v případě, že netrváte na utajení,

nemusíte obsah šifrovat to je zcela nezávislá možnost). Jakmile příjemce obdrží

tradičním způsobem váš e-mail, zjistí, že jeho náplň lze ověřit pomocí

platnosti elektronického podpisu. Jak to provede? Ano, samozřejmě použije

veřejný klíč odesílatele, neboť to je jediná část systému, jež se cizímu

příjemci může dostat do ruky. A otázka, kde jej vezme, je pro poctivé čtenáře z

minula snadná: veřejný klíč odesílatele digitálně podepsaného e-mailu je

obsažen v certifikátu, jejž vám samotný odesílatel do zprávy může přiložit.

Takže máme doručenou zprávu, „přešifrovanou“ privátním klíčem odesílatele, jeho

veřejný klíč, jemuž důvěřujeme (ověřili jsme si pravost certifikátu, jak víme z

minula), a nic nám nebrání provést dešifrování. Pokud se operace podaří a

obdržíme původní, korektní zprávu, je vše v pořádku a původnost je ověřena.

Jenže jistě zde cítíte určité drobné nedostatky, jež bude potřeba vyřešit. V

první řadě, asymetrická kryptografie je poměrně pomalá, a rutinní šifrování

celých zpráv (třeba včetně objemných příloh) by bylo tak obtížné, že bychom se

možná dostali na hranici použitelnosti. Dále je tu jiný nedostatek v podobě

skutečnosti, že celou digitálně podepsanou zprávu, jejíž původní verzi jsme

získali díky použití veřejného klíče odesílatele, nemáme s čím srovnat nemáme

zkrátka referenční verzi téže zprávy. Naštěstí se celý postup odehrává ve

skutečnosti v trošku upravené verzi.

Pokud se odesílatel pokusí digitálně podepsat odchozí zprávu, dojde nejprve k

provedení určité výpočetní funkce, jejímž výsledkem je jedinečný otisk, běžně

označovaný jako hash. Jde o jakýsi zhuštěný vzorek, jenž se vyznačuje

důležitými vlastnostmi. V první řadě má konstantní délku, která je typicky

velmi malá v poměru k objemu celé zprávy, a pochopitelně právě toto značně

urychlí následné kryptografické operace. Dále je hash prakticky jedinečným

obtiskem a platí, že drobounká změna původní zprávy vyvolává značnou změnu

vystupující hashe. A v neposlední řadě platí další důležitá skutečnost, a to že

výpočet hashe je jednosměrná operace, takže z její hodnoty nelze zpětně

rekonstruovat obsah zprávy. Přesněji řečeno, při snaze o zpětné sestavení

výchozí podoby zprávy by vám nevznikla jediná varianta, ale řada verzí, z nichž

byste stejně nic kloudného nevybrali, a navíc byste vše počítali velmi dlouho.

Celý postup se díky hashi projasňuje a dostává pevné obrysy. Odesílatel tedy ve

skutečnosti sestaví kolekci, zahrnující původní zprávu, certifikát se svým

veřejným klíčem a vypočtenou hash, zašifrovanou svým privátním klíčem. A

příjemce? Asi tušíte, že uchopí doručenou zprávu, vypočte dohodnutým postupem

svou variantu hashe (algoritmus je veřejný a nijak to neohrožuje bezpečnost),

následně z certifikátu odesílatele vytáhne jeho veřejný klíč, s jeho pomocí

dešifruje doručenou hash a pak obě varianty porovná. Pokud se odeslaná

podepsaná varianta hashe shoduje s verzí, kterou si příjemce pořídil sám pod

vlastní kontrolou, pravost obsahu zprávy je stvrzena a její přenos je považován

za důvěryhodný.

Postup je názornou ukázkou, že samotné šifrování není jediným využitím

asymetrické kryptografie a její geniální podstata nabízí i další, velmi

důležité aplikace. Dodejme, že příklad, popsaný na elektronické poště, popisuje

obecnější schéma, neboť digitálně podepisovat lze celou řadu jiných entit, jako

třeba programové komponenty, instalační balíky či třeba ovladače pro zařízení v

operačním systému.



Podepisujeme a šifrujeme poštu

Jedním z nejdůležitějších využití prostředků pro elektronickou identifikaci a

silné asymetrické kryptografie je nasazení pro posílení důvěryhodnosti v

oblasti e-mailové komunikace. Elektronická pošta se stala běžnou součástí

našeho života, a protože se ve výchozí podobě v podstatě jedná o velmi

nedůvěryhodný komunikační kanál (podvrhnout e-mail je neuvěřitelně snadné), je

nasazení certifikátů žádoucí. Použití elektronické identity a šifry s sebou

přináší řadu výhod a kýžených vlastností: příjemce si může ověřit pravost

odesílatele, jenž zároveň nemůže dodatečně autenticitu své zprávy popřít (jeho

„značka“ je nezaměnitelná), a obsah zprávy je pochopitelně možno ochránit

silnými šifrovacími postupy, čímž navíc zajistíte naprostou privátnost

přenášených dat. Použití certifikátu pro uvedené účely je umožněno díky

zavedení protokolu S/MIME, což je prostředek pro přímé začlenění možností

asymetrické kryptografie do programů pro zasílání elektronické pošty. Řada

klientských aplikací, včetně produktu Outlook Express, tento protokol

podporují, a nabízejí uživatelům pohodlné rozhraní, jež tyto jinak poměrně

komplikované postupy zajistí. Nemusíte se obávat, vše je dobře zvládnutelné.

Obr. 1: Postup zavedení chráněné komunikace si ukážeme na příkladu MS Outlook

Expressu, přesněji v jeho verzi 6.00, jež je součástí MS Internet Exploreru

6.0, vše v operačním systému MS Windows XP. Základem úspěchu je v první řadě

existence certifikátu uživatele, jenž chce svou poštu chránit. Pro pokusné

účely si můžete potřebný certifikát nechat zdarma vystavit např. certifikační

autoritou I.CA, podobně jako jsme to udělali my (na adrese http://Lobkowiczova/

cer_ test_standardnostmi). Takto či jinak získaný osobní certifikát se musí

vyznačovat jednou zásadní vlastností: jako předmět se musí v jeho záznamech

vyskytovat právě ta e-mailová adresa, kterou hodláte příslušným veřejným klíčem

z certifikátu podepisovat či šifrovat. Nejde o formalitu, neboť Outlook Express

vám použití nekorektně vystaveného certifikátu nedovolí a celá procedura nebude

funkční, přesněji bude nedostupná. Pokud na uvedené webové stránce vyplníte

testovací žádost včetně zadání e-mailu, bude vám autoritou obratem zaslán

takovýto certifikát, jejž lze následně otestovat.

Obr. 2: Doručený osobní certifikát je nutno po uložení na disk nejprve

naimportovat do osobního úložiště. Toho dosáhnete dvojklikem na samotný soubor

(máte-li jich více variant, což je běžné, pak vyberte třeba ten s

příponou .der), načež v následujícím průvodci importem pro jistotu ručně

zadejte, že cílem certifikátu je úložiště Osobní (Personal). Dokončením této

procedury jsme dosáhli výchozí konfigurace, totiž toho, že náš „podepisovací a

šifrovací e-mailový“ certifikát je uložen v operačním systému a můžeme jej

předhodit poštovnímu programu. Než pokročíme dále, vzpomeňte si ještě na minulý

díl a případně si do operačního systému obdobným postupem naimportujte

certifikát samotné vydavatelské certifikační autority, v našem případě tedy

I.CA. Však víte, důvěryhodný kořen je základem!

Obr. 3: Takto vybaveni můžeme vstoupit do poštovní aplikace, v tomto případě

Outlook Expressu. Ještě než začneme, vezměte na vědomí jednu drobnost: tvůrci

systému si příliš nelámali hlavu s názvoslovím, a proto vás nesmí zmást, že

standardní struktuře jménem certifikát se občas v programu říká Digitální ID.

Nuže k věci. Zde bude prvním krokem napojení certifikátu na konkrétní,

existující poštovní účet. Vstupte pomocí volby Nástroje/Účty do dialogu Účty v

Internetu, vyberte příslušné e-mailové konto a stiskněte tlačítko Vlastnosti. V

následujícím dialogu přejděte na kartu Zabezpečení, neboť právě zde se ono

propojení provádí. Jak je patrné i z obrázku, máte možnost k otevřenému účtu

přiřadit dva certifikáty, nezávisle pro podepisování a šifrování zpráv.

Pochopitelně lze přiřadit jediný pro obě operace. Ve výchozí podobě jsou pole

prozatím prázdná.

Obr. 4: Zvolte tedy v jednom z případů tlačítko Vybrat, a vstoupíte tak do

vlastního dialogu pro výběr konkrétního certifikátu. A právě zde dochází na

„lámání chleba“: pokud bude otevřený seznam prázdný, znamená to, že Outlook

Express nenašel žádný použitelný certifikát, a vy se nemůžete pohnout dále a

operaci dokončit. Jak se toto mohlo stát? Možností je několik: buďto jste

Osobní prozatím vůbec nenaimportovali (pak to udělejte dle postupu výše), nebo

jste certifikát naimportovali na špatné místo mimo úložiště Osobní (což je ta

méně pravděpodobná varianta, pokud jste byli důslední), případně jste využili

osobní certifikát, jehož Předmět (Subject) obsahuje jinou e-mailovou adresu,

než jaká je zapsána v právě ošetřovaném účtu (typická situace). Nepříjemné je,

že Outlook Express neoznámí chybu, ale prostě pouze nenabídne žádný certifikát

k přiřazení, a na vás je vypátrání důvodu. Pokud vše proběhlo korektně, bude v

seznamu alespoň jedna dostupná položka, jako na našem obrázku.

Obr. 5: je vše v pořádku případně si certifikát pro kontrolu prohlédněte a

následně potvrďte výběr tlačítkem OK bude karta Zabezpečení realizované

připojení signalizovat připojeným jménem držitele certifikátu. Naprosto

identickým postupem pak přiřaďte též certifikát pro šifrování obsahu zpráv. V

dolní části karty si povšimněte volby Algoritmus, v jejímž menu máte možnost

ovlivnit, jakým postupem se bude provádět utajení poštovních zpráv. Pamatujte

si především fakt, že nejsilnější zde dostupnou variantou je 3DES. Po úspěšném

nastavení by karta měla vypadat asi jako na našem obrázku.

Obr. 6: Po úspěšné přípravě zázemí můžeme přistoupit ke konkrétní ochraně

jednotlivých zpráv. Ještě jednou si připomeňme, že pokud se vám procedura s

přiřazením certifikátů nezdařila, následující funkce nebudou korektně dostupné.

Samotný proces šifrování a podepisování zpráv lze řídit ručně pro každý

jednotlivý případ či nastavit všeobecně, pro všechny odesílané e-maily.

Nejdříve tedy přejděte do menu Nástroje/Možnosti na kartu Zabezpečení, kde v

dolní části můžete využít zaškrtávacích polí pro výchozí ovlivnění všech zpráv.

Vřele doporučujeme obzvláště šifrování na tomto místě nezapínat a řešit jej

případ od případu, na druhou stranu digitální podpis všem e-mailům nijak

zásadně nemůže uškodit.

Obr. 7: Pomocí tlačítka Upřesnit dále přejděte do podrobnějšího dialogu s

větším množstvím parametrů, jejichž prostřednictvím dále můžete ovlivnit

chování programu. Horní část pojednává o šifrování a dovoluje v rolovacím menu

definovat úroveň zabezpečení, již v příchozích zprávách očekáváte. Pokud

nastavíte laťku vysoko, příchozí e-maily se slabší šifrou budou varovně

označeny jako „slabší“ a vy budete moci posoudit, zdali jejich utajení věříte.

V praxi klidně používejte pravidlo, že co je nad 128 bitů, je pro běžnou

komunikaci velmi bezpečné. Nastavení v prostřední sekci ovlivňují nakládání

programu s certifikáty. Obzvláště první a třetí volba jsou důležité a

využívejte jich příjemci vaší pošty rovnou obdrží krom podpisu i certifikát s

vaším veřejným klíčem, a pokud vám doručené e-maily budou certifikáty

odesílatelů také zahrnovat, budou tyto automaticky uloženy do systému do

příslušného zásobníku. Poslední dolní volba spouští klíčovou funkcionalitu, o

níž jsme si důkladně pohovořili minule, a to je Kontrola odvolání certifikátů

(revokace). Chcete-li zajistit seriózní důvěryhodnost, měli byste kontrolu

zapnout.

Obr. 8/9: Takto vybaveni již můžeme konečně napsat a odeslat první digitálně

podepsanou zprávu. Postup při sestavení e-mailu je pochopitelně standardní,

takže prostě udělejte, na co jste zvyklí, a zastavte se před odesláním. Pokud

chcete aplikovat elektronický podpis, poslouží vám k tomu tlačítko obálky s

pečetí, po jehož stisku se vedle pole „Od:“ objeví malý grafický symbol,

znázorňující že se chystáte odeslat digitálně podepsaný e-mail.Teď můžete poštu

běžným postupem zaslat příjemci.

Obr. 10/11: Co nastane v případě doručení takovéto zprávy protistraně? V každém

případě bude příjem podepsané zprávy avizován příslušnou ikonou v jejím

záhlaví. Další situace bude především závislá na skutečnosti, zda příjemce

e-mailu důvěřuje stejnému vydavateli certifikátů, od nějž obdržel odesílatel

ten svůj. O významu důvěryhodných kořenových autorit jsme hovořili minule,

takže vám jistě neušlo, že důvěryhodnost digitálního podpisu závisí na prestiži

autority, jež jej posvětila. Pokud příjemce prozatím autoritě nedůvěřuje,

dostane se mu varovné zprávy, že něco není v pořádku, přičemž případné

nejasnosti lze okamžitě zjistit.

Obr. 12/13: Pokud příjemce i odesílal v případě otevírání e-mailu již důvěřují

stejné autoritě, poštovní program nebude poukazovat na potíže a korektně

naznačí, zdali doručená zpráva je v pořádku, tedy zda nebyla platnost podpisu

narušena v průběhu přepravy jakýmkoliv vnějším zásahem. Velmi důležitá je

skutečnost, že pokud vám odesílatel poskytnul jako přílohu svůj certifikát s

veřejným klíčem, uložením jeho identifikačních údajů do adresáře aplikace dojde

také k současnému archivování certifikátu pro budoucí využití.

Obdobným způsobem jsou prováděny potřebné operace v průběhu šifrování zprávy.

Na počátku je opět odesílatel, jeho nový e-mail a tlačítko, jež pro změnu

obsahuje visací zámek. Zprávu lze zároveň zašifrovat i podepsat, čímž v

podstatě využijeme dostupné možnosti pro její ochranu.

Obr. 14: Zde, v případě šifrování, však mohou nastat obtíže již při snaze

e-mail odeslat. Jak správně tušíte, při snaze o ukrytí dat šifrou vás může

zaskočit absence certifikátu příjemce, bez nějž nemáte šanci získat jeho

veřejný klíč, pro šifrování nezbytný. Jak situaci řešit? Jednou z možností je

nechat si protějškem zaslat potřebný certifikát jako přílohu, pochopitelně v

pěkně podepsaném e-mailu…

Obr. 15/16: Naplníte-li předpoklady a zprávu korektně před odesláním

zašifrujete, situace u příjemce bude opět odpovídat provedené operaci příchozí

e-mail bude opatřen ikonkou, indikující ochranu, a po otevření se vám může

dostat vysvětlující informace o dešifrovací proceduře.

Obr. 17/18/19: Pokud je vše v pořádku, obdržíte po stisku tlačítka již tradiční

okno s přijatou zprávou, jejíž obsah je běžně zobrazen, jako by šifra

neexistovala. V případě, že jste využili obou možností podpisu i šifry budou se

výsledné dialogy a vzhled obdržených zpráv mírně lišit dle aktuální varianty.

Obr. 20/21: Grafické rozhraní, jež nabízí zobrazení takto ošetřených poštovních

zpráv, však není jen kosmetickou parádou ikony podpisu (pečeti) a šifry (zámku)

lze totiž využít pro zobrazení detailních informací o celé proceduře. Pokud

kliknete na jednom ze symbolů (pečeti, zámku), jsou vám dostupné v následném

dialogu na kartě Zabezpečení detailní informace o provedené kontrole

celistvosti přenesených dat a jejich ukrytí. Využijete-li navíc tlačítko

Zobrazit certifikáty, máte možnost detailně prozkoumat důvěryhodnost autora

e-mailu, jím využité předvolby a navíc zde lze snadno vytvořit novou položku v

adresáři, pochopitelně včetně potřebných certifikátů.

Jak již bylo uvedeno výše, pro nastolení automaticky ověřovaného důvěryhodného

vztahu mezi stranami, jež si zasílají digitálně podepsané e-mailové zprávy, je

klíčová shoda a podložená důvěra v případě kořenové certifikační autority.

Pokud se komunikující strany shodnou buďto na stejném vydavateli certifikátů,

nebo považují navzájem autoritu svého protějšku za důvěryhodnou, mohou tento

vztah stvrdit instalací certifikátu inkriminované kořenové autority do svého

systému, čímž dojde k dosažení plné funkcionality příslušných aplikací a

veškeré ovládání pak bude jednoduché a transparentní.



Záloha certifikátů a klíčů

V tomto i předchozím článku jsme si na různých příkladech ukázali, jak užitečné

mohou být v praxi moderní šifrovací postupy a použití certifikátů. Jistě vám

neušla jedna velmi důležitá skutečnost: funkcionalita celé struktury stojí a

padá s tím, že máte k dispozici svůj klíčový pár, tedy dvojici veřejný a

privátní klíč, a navíc musíte být schopni zajistit v případě privátního klíče

jeho maximální utajení. Stejně jako vše ostatní na pevném disku vašeho

počítače, i certifikáty a klíčové páry uložené v útrobách operačního systému

mohou snadno podlehnout zničení. Zhroutí-li se vám aplikace, nainstalujete ji

znovu, ovšem přijdete-li o privátní klíč, není cesty zpět.

V zásadě nejjednodušší metodou pro zálohování certifikátů, případně i s

privátním klíčem, je export z úložiště v operačním systému na nějaké přenosné

médium, jež následně uchováváte na přiměřeně dobře utajeném místě. Tato

procedura dovoluje v podstatě vyrobit záložní kopie certifikátů i s klíči, a to

opakovaně v neomezeném počtu. Než k této proceduře přistoupíte, ještě jednom si

připomeňme, že následná ochrana záložního média je absolutní nutností. Je tomu

tak mimo jiné i proto, že po provedení exportu ztrácí certifikát (včetně klíče)

jakousi ochrannou vazbu na účet v operačním systému Windows: dokud byl v nitru

systému, nebylo možno s ním disponovat bez platného přihlášení, ovšem z

ukradené diskety jej může kdokoliv naimportovat do svého, jinak zcela cizího

účtu, a použít jej k nejtěžšímu útoku formou podvržení vaší identity.

Obr. 22: Export certifikátu z osobního úložiště můžete provádět na více

místech, například prostřednictvím MS Internet Exploreru, kde přejděte v menu

Nástroje/Možnosti Internetu na kartu Obsah a stiskněte tlačítko Certifikáty. Z

tohoto nám již důvěrně známého místa lze označit žádoucí položku a stiskem

tlačítka Exportovat zahájit samotné zazálohování.

Obr. 23: Pokud se rozhodnete provádět zálohu včetně privátního klíče, jež vám

dovolí jako jediná v případě pádu systému či hardwaru obnovit přístup k

zašifrovaným datům, musíte ve druhé obrazovce proběhnuvšího Průvodce použít

volbu „Ano, exportovat soukromý klíč“.

Obr. 24: Následující dialog dovoluje nastavit podrobnější parametry exportu.

Volba „Zahrnout všechny certifikáty…“ je výhodná z toho důvodu, že spolu s

vaším certifikátem budou zálohovány i nadřízené položky, případně až k

certifikátu důvěryhodné kořenové autority. Následná obnova při poškození

systému bude o to snazší, že si nebudete moci dodatečně ostatní certifikáty

shánět. Rozhodně také neváhejte s použitím prostřední volby, jež dovolí

exportovaný soubor ještě dodatečně ochránit heslem. Třetí, spodní možnost, je

užitečná v případě, že jste se rozhodli certifikát exportovat s tím, že na

daném počítači dočasně či trvale nebude používán. Jde o situace, jako je

plánovaná reinstalace Windows či záměna „železa“ za nové, takže citlivý

privátní klíč bude po exportu odstraněn z útrob systému.

Obr. 25: V dalším dialogu již zadáte ochranné heslo k souboru (pozor, jeho

ztrátu nelze napravit!) a následně cestu, kam bude balíček po exportu uložen.

Výsledkem akce je soubor jako každý jiný, a proto při nakládání s ním

nezapomeňte na zásady důsledné ochrany, o nichž jsme mluvili.

V případě, že opravdu dojde k poruše systému či jiné nemilé kalamitě a budete

nuceni certifikát ze zálohy obnovit, postup není o nic složitější. Protože

Windows formát souboru rozpoznají již podle asociované přípony, stačí

„dvojklik“ k tomu, aby byl spuštěn průvodce importem, tedy zavedením

certifikátu do systému. Před jeho započetím nezapomeňte na skutečnost, že

přenést certifikát do osobního úložiště lze provést pouze pro účet, do něhož

jste aktuálně přihlášeni. Po spuštění zaváděcí procedury budete v jednom z

dialogů požádání o zadání ochranného hesla (opravdu to nepodceňujte!) a zároveň

máte na téže obrazovce možnost nastavit dva veledůležité parametry. Silná

ochrana privátního klíče spočívá v tom, že operační systém po vás bude při

každém jeho použití vyžadovat dodatečné potvrzení, což je sice méně pohodlné,

ale mnohem bezpečnější. Volba druhá je zaměřena na vaše budoucí záměry s

certifikátem a privátním klíčem: chystáte-li se někdy znovu ze systému, kam

klíč nyní zavádíte, provádět export, musíte tuto volbu zatrhnout. Pokud na to

zapomenete, klíč bude po importu v systému uvězněn a už nikdy jej nedostanete

ven! Obr. 26: V následujícím kroku se operační systém ptá, zdali může úložiště

certifikátu vybrat sám. Protože se Windows běžně trefují do správného cíle,

není potřeba v normálních situacích položku měnit. Nezbývá, než operaci

dokončit a počkat si na potvrzovací okno.

Popsaná metodika je pochopitelně určena nejen k zálohování certifikátů a klíčů,

ale rovněž k jejich univerzálnímu přenosu mezi počítači a operačními systémy.

Formát certifikátu spolu s privátním klíčem, jejž obdržíte při exportu, je

definován univerzální normou (označovanou jako PKCS 12), a proto takto uložený

soubor lze dále univerzálně využívat.



Závěrem

V našem dvoudílném miniseriálu jste mohli narazit na nejčastější použití

principů moderního šifrování dat a navazování důvěryhodnosti v kybernetickém

světě. Ačkoliv tato problematika je poměrně široká, při pečlivém čtení a

experimentování jste si mohli osahat jedny z nejběžnějších operací, jež vám

zároveň mohou přinést bezprostřední užitek, především v oblasti zabezpečení

osobní komunikace a zvýšení důvěryhodnosti obchodování na internetu. Dobré

pochopení základů vás však bude spolehlivě provázet i při nasazení dalších,

pokročilejších aplikací geniálního principu asymetrické kryptografie, jenž

zásadně ovlivnil elektronický svět.



Když nepoužívám Outlook Express

Přestože náš příklad s ochranou elektronické pošty byl prováděn na

komunikačních programech společnosti Microsoft, nikde není řečeno, že byste si

nemohli stejnou ochranu nasadit do jiného nástroje. Pro doplňující ukázku jsme

zvolili volně dostupný klient Mozilla Thunderbird, jenž je součástí jinak dobře

známého internetového balíku.

Obr. 27: Jediný zásadní rozdíl oproti produktům Microsoftu je zde v tom, že

aplikace nabízí vlastní úložiště certifikátů a nevyužívá prostor operačního

systému. Nic to však nemění na konkrétních postupech, neboť všechny související

operace jsou totožné. Správu zabezpečení pomocí certifikátů najdete v tomto

programu v menu Tools/ Account Settings a dále pod položkou Security. V

dialogu, jenž je poměrně podobný oknům v Outlook Expresu, máte možnost přiřadit

certifikát zvlášť pro šifrování a zvlášť pro podpis.

Obr. 28: Nezapomeňte však nejdříve naimportovat svůj certifikát, jenž bude k

těmto operacím sloužit. Provedete to v příslušném dialogu po stisku tlačítka

Manage Certificates, kde při zobrazení karty Your Certificates zvolte tlačítko

Import a vyberte soubor, v němž jsou potřebný klíčový pár a certifikát uloženy.

Obr. 29: Po úspěšném importu lze již po návratu do dialogu Security pomocí

tlačítek Select přiřadit certifikát pro šifrování i podpis. Všimněte si, že

dialogy aplikace jsou zpracovány velmi hezky a mají velmi vysokou informační

hodnotu, takže můžete samotný obsah certifikátu důsledně kontrolovat.

Obr. 30: Použití podpisů a šifry u jednotlivých zpráv je poté opět poměrně

jednoduché. Pokud píšete nový e-mail, pomocí voleb pod tlačítkem Security

můžete specifikovat, zdali použijete podpis, šifru, či oboje zároveň.

Obr. 31: Rovněž práce s přijatou chráněnou poštou je poměrně jednoduchá a

intuitivní. E-mail je po otevření v pravé části okna opatřen výraznými ikonami,

které uživateli signalizují stav šifrování a podpisu.

Obr. 32: Pokud došlo k porušení zprávy a podpis již není platný či nastala jiná

nesrovnalost, např. že e-mail byl podepsán certifikátem od autority, jíž

nedůvěřujete, aplikace vám tuto skutečnost dá výrazně najevo (ikona zlomené

tužky) a poklepáním si zobrazíte detaily, jež důvod potíží objasní.

Z uvedených příkladů je patrné, že poštovní klient Thunderbird z balíku Mozilla

je naprosto plnohodnotně vybaven pro práci s certifikáty a chráněnou

elektronickou poštou, a nic vám v tomto ohledu nebrání v jeho nasazení.