Bajecny svet elektronickeho podpisu | online podpora stejnojmenne knihy z Edice CZ.NIC

5.1.1         Vlastní certifikáty vs. certifikáty třetích stran

Nejčastěji budeme chtít vyjadřovat svou důvěru kořenovým certifikátům konkrétních certifikačních autorit, a právě ty ukládat do úložišť důvěryhodných certifikátů. Díky principům infrastruktury veřejného klíče (hlavně principu delegace důvěry) tím vždy vyjádříme důvěru celému „podstromu“, neboli všem certifikátům, vydaným danou certifikační autoritou.

Pro obrázek ve větší kvalitě klikněte na odkaz pod číslem obrázku v legendě

 Příklad certifikátu, se kterým je v úložišti uložen i odpovídající soukromý klíč

Obrázek 5 - 1: Příklad certifikátu, se kterým je v úložišti uložen i odpovídající soukromý klíč

Někdy ale můžeme udělat výjimku a vyjádřit svou důvěru i konkrétním certifikátům, bez ohledu na jejich příslušnost do nějakého konkrétního „stromu důvěry“. Tedy například konkrétnímu serverovému certifikátu či osobnímu certifikátu konkrétní osoby apod. Nebo nějakému certifikátu s vlastním podpisem (self-signed), který není kořenovým certifikátem certifikační autority. Vždy samozřejmě jen za podmínky, že máme proč těmto certifikátům důvěřovat.

Všechny tyto certifikáty ale budou certifikáty třetích stran, a nikoli „naše“. Jsou to certifikáty plně veřejné, a my je budeme využívat pouze pro vyhodnocování platnosti (cizích) podpisů, značek či razítek. Proto na spolehlivost jejich uložení nejsou kladeny žádné zvýšené požadavky[1]. A důvěrnost tohoto uložení (tj. aby je nemohl získat někdo jiný) již není zapotřebí vůbec.

Přesně opačné to je v případě našich vlastních certifikátů, které chceme využívat při vytváření našich elektronických podpisů či dokonce značek. Tyto certifikáty jsou samy o sobě veřejné, takže jejich kompromitace by nás také nemusela nijak bolet. Ale problém je v tom, že spolu s těmito certifikáty si do úložišť potřebujeme ukládat i jim odpovídající soukromé klíče.

A tady již jsou nároky na spolehlivost a důvěrnost uložení naopak velmi vysoké, protože případná kompromitace soukromého klíče (jeho zkopírování, smazání apod.) by  byla zcela zásadním problémem[2].

Určitým řešením je aplikování zvýšené ochrany soukromého klíče v úložišti, která se uplatňuje v situacích, kdy má být se soukromým klíčem nějak manipulováno. Tedy při vytváření konkrétního elektronického podpisu.

V prostředí MS Windows máme k dispozici tři různé úrovně ochrany soukromého klíče, mezi kterými můžeme volit:

·         vysoká úroveň: při každém požadavku na použití soukromého klíče bude nutná autentizace (zadání správného hesla)

·         střední úroveň: každý požadavek na použití soukromého klíče je nutné explicitně odsouhlasit (odkliknout, ale bez nutnosti zadání hesla)

·         nízká úroveň: při použití soukromého klíče nebude vyžadována žádná akce uživatele

Nastavení těchto úrovní, včetně volby hesla, se provádí již při prvotním generování soukromého klíče (pro potřeby žádosti o vydání certifikátu, viz část 5.5.2.2). Stejně tak se ale provádí (znovu, s novou volbou hesla) při případném vkládání (importu) certifikátu i se soukromým klíčem do jiného úložiště.

Samotné nastavení je přitom dvoustupňové: nejprve se volí mezi „silnou ochranou“ (zahrnující vysokou a střední míru ochrany) a žádnou ochranou (nízkou).

Pro obrázek ve větší kvalitě klikněte na odkaz pod číslem obrázku v legendě

Příklad povolení silnější ochrany  (vysoké či
střední, při instalování certifikátu spolu se soukromým klíčem)

Obrázek 5 - 2: Příklad povolení silnější ochrany  (vysoké či střední, při instalování certifikátu spolu se soukromým klíčem)

Teprve při volbě „silné ochrany“ je následně možné volit mezi vysokou a střední mírou zabezpečení, a zadat heslo.

Pro obrázek ve větší kvalitě klikněte na odkaz pod číslem obrázku v legendě

Příklad volby mezi nejvyšší a střední úrovní zabezpečení

Obrázek 5 - 3: Příklad volby mezi nejvyšší a střední úrovní zabezpečení


[1] Na rozdíl od „správnosti“ jejich uložení: je třeba je uložit na správné místo do  správného úložiště certifikátů

[2] Byť také řešitelným, skrze předčasné zneplatnění, neboli revokaci



© Jiří Peterka, 2011, profil na Google+
Valid HTML 4.01 Transitional Ověřit CSS!
3A2E
5665
6E6F
7661
6E69
2E3A
0D0A
5475
746F
206B
6E69
6875
2076
656E
756A
6920
7376
6520
7A65
6E65
2049
7265
6E65
2C20
7379
6E6F
7669
204A
6972
696D
7520
6120
6463
6572
6920
4576
652E
0D0A
5620
5072
617A
652C
204C
5032
3031
3020
4A69
7269
2050
6574
6572
6B61