fb
IT Systems 12/2004 1. 12. 2004

Certifikáty jako základ e-podpisu, autentizace i šifrování

jsou základem elektronického podpisu, autentizace i šifrování

V současné době se pro zvýšení bezpečnosti, případně pro zajištění některých služeb IT často využívá asymetrické kryptografie. Příkladem takového využití je elektronické podepisování, šifrovaná spojení s využitím digitálních certifikátů, často využívané například v elektronickém bankovnictví. Při využití asymetrické kryptografie hraje zásadní roli použití tzv. certifikátů, které jsou nositeli klíčů používaných při autentizaci, šifrování nebo zabezpečené komunikaci. Každá ze zúčastněných stran zabezpečené komunikace má dva klíče – jeden soukromý (privátní), druhý veřejný. Často se ovšem nejedná pouze o jednu, ale o více dvojic klíčů pro každého účastníka, kdy se různé páry klíčů užívají pro různé účely. Ale v zásadě jde o to, že soukromý klíč musí být pečlivě uschován např. na čipové kartě, na disketě, která je chráněna, na pevném disku s řízeným přístupem do operačního systému apod., zatímco veřejný klíč je naopak zveřejněn.

Zveřejnění provádí certifikační autorita (CA) obvykle tak, že veřejný klíč uvede jako jeden z údajů v tzv. certifikátu, což je elektronický dokument s přesně danými položkami. Jednou z nich je tedy veřejný klíč, dále např. identifikace algoritmu podpisu, sériové číslo certifikátu, označení certifikační autority, která certifikát vydala, místo, kde lze nalézt certifikační politiku, nadřízené certifikáty z certifikační cesty, dobu platnosti certifikátu, další položkou je identita vlastníka klíče (common name), pro zasílání podepsaných e-mailů je vhodné mít v certifikátu e mailovou adresu. Existují normy a doporučení, které položky mají být obsaženy v certifikátu i způsob jejich naplnění. Přesto existují určité dohady, jak certifikát naplnit, resp. které údaje do jakého pole v certifikátu umístit, takže je nutné se dohodnout, aby alespoň v dané lokalitě byly údaje strukturovány stejně. Příkladem tohoto problému je umístění identifikátoru občana, nahrazujícího rodné číslo pro kontakt s veřejnou správou - I.CA (První certifikační autorita) jej po zvážení dává do Alternative name/Other name a ostatní tuto skutečnost budou zřejmě respektovat, protože jinak by zkomplikovali vývoj aplikací, které tento údaj potřebují.




Certifikáty mohou sloužit jednak k podepisování, (zaručení nepopiratelnosti odpovědnosti, zachování integrity dokumentu, zajištění autenticity dokumentu), k šifrování či k autentizaci. Často se setkáváme se serverovými certifikáty, které slouží k identifikaci serverů. Novela zákona o elektronickém podpisu přinesla nové označení kvalifikovaný systémový certifikát - jedná se o certifikát, kde může být v názvu (common name) uvedena právnická osoba a podepisování, resp. označování se může provádět automatizovaně.

Identita vlastníka certifikátu
Spojení určitého vlastníka dvojice klíčů a jeho veřejného klíče zajišťují certifikační autority, resp. registrační autority. Registrační autorita je místo, na kterém se ověřuje identita osoby. Certifikační autorita zajistí spojení certifikátu a jeho držitele a na důkaz, že je certifikát v pořádku, jej elektronicky podepíše. Certifikát bývá často přirovnáván k občanskému průkazu ve světě internetu, v takovém případě certifikační autorita hraje roli úřadu, který nejprve ověří totožnost a poté vydá, resp. potvrdí platnost občanského průkazu (průkaz jako takový si vlastně vydá sám uživatel tím, že vygeneruje pár klíčů, z nichž jeden, soukromý, si ponechá u sebe a druhý, veřejný, přinese nebo pošle certifikační autoritě k potvrzení). Na rozdíl od občanských průkazů, nejsou ale všechny certifikáty na stejné právní ani technické úrovni. Úroveň takového certifikátu je pak dána jednak důkladností, s jakou dochází k ověření identity žadatele o certifikát, a dále přímo technickým vybavením a použitou technologií certifikační autority. Existuje tedy možnost koupit si kvalifikovaný certifikát od akreditovaného poskytovatele, samostatně si nainstalovat certifikační autoritu a vydat certifikáty sobě a svým známým, případně využít nějaké internetové služby, kdy obdržíme zdarma certifikát na základě žádosti po internetu, aniž by nás kdokoliv identifikoval. Proto se zde hovoří o důvěryhodnosti a úrovni záruk, kterou je při použití a přijetí daného certifikátu nutno zvážit.

Problém důvěryhodnosti e-podpisu
Pokud jste již experimentovali s elektronickým podpisem v e-mailové komunikaci, narazili jste pravděpodobně na situaci, kdy se při přijetí zprávy podepsané elektronickým podpisem objevila příjemci informace o tom, že odesilatel není důvěryhodný. Přesněji řečeno, že poskytovatel certifikačních služeb, který vystavil certifikát, jímž byla zpráva podepsána, není důvěryhodný. Takové varování bohužel může vést k nepochopení a odmítnutí elektronockého podpisu. Problém přitom tkví pouze v tom, že sám uživatel (příjemce podepsané zprávy) si musí rozhodnout, které certifikační autoritě bude důvěřovat. Pokud tedy přijde zpráva podepsaná certifikátem, který vydal poskytovatel certifikačních služeb, jehož kořenový certifikát ještě u daného uživatele není považován za důvěryhodný, jeví se takový podpis jako nedůvěryhodný, dokud není tento kořenový certifikát akceptován. Ve chvíli, kdy příjemce přijme kořenový certifikát příslušného poskytovatele certifikačních služeb jako důvěryhodný, a nainstaluje jej tedy do svého úložiště důvěryhodných kořenových certifikátů, bude se mu již podpis zobrazovat jako důvěryhodný.


Ověření platnosti podpisu/certifikátu
Certifikát je buď rovnou připojován například k zasílanému e-mailu nebo je možno si ho stáhnout z nějakého veřejného serveru. Podle novely zákona o e-podpisu je možné požádat, aby certifikát nebyl zveřejněn na seznamu veřejných certifikátů, v případě, že tedy obdržíme zprávu, která je podepsána na základě nezveřejněného certifikátu, a tento certifikát není ke zprávě připojen (např. S/MIME certifikát připojuje), je nutné o něj druhou stranu požádat. Protože může dojít k porušení bezpečnosti soukromého klíče (nebo k uplynutí doby jeho platnosti), a poté by užití celého systému dvou klíčů již nebylo bezpečné, zveřejňují certifikační autority pravidelně seznam zneplatněných certifikátů (CRL, certificate revocation list), kde je možno zjistit, zda je určitá klíčová dvojice ještě bezpečná. Pokud se tedy sériové číslo certifikátu na tomto seznamu nenachází, resp. k určitému okamžiku zde nebylo zveřejněno, neskončila doba platnosti certifikátu a nebyla narušena integrita certifikátu (a pokud totéž platí i o všech nadřízených certifikátech v certifikační cestě), je certifikát platný. Je zde však problém určit, kdy byl certifikát použit - tato doba nemusí být totožná například s dobou odeslání, nehledě na skutečnost, že čas na poštovním či webovém serveru není příliš spolehlivý údaj. Proto existuje institut časového razítka, které dokládá existenci dokumentu v daném čase. Samozřejmě ani časové razítko neurčí dobu, kdy byl např. učiněn podpis, ale lze určit, že v době před orazítkováním již byla zpráva podepsána. Banky většinou seznamy zneplatněných certifikátů nezveřejňují (CRL je dostupné jen uvnitř jejich interní sítě), proto je pro ostatní subjekty problematické ověřit, jestli ke zneplatnění nedošlo. Certifikační autority obvykle mají kromě vydávání certifikátů a zveřejňování CRL ještě celou řadu dalších funkcí a celému tomuto systému se říká PKI. PKI je koncept bezpečnostních mechanismů, softwaru, technologií, kryptografických technik a administrativních pravidel a postupů, pomocí nichž se zavádí potřebné bezpečnostní prvky autentizace, identifikace, důvěrnosti a dostupnosti. PKI začleňuje kryptografii s veřejnými klíči, digitální certifikáty, certifikační autority a registrační autority do bezpečnostního komplexu na dané úrovni (podniková, státní či otevřené systémy). Systém založený na PKI zajišťuje vydávání digitálních certifikátů fyzickým osobám i pro serverové aplikace, rozšiřování a správu softwaru, integraci s knihovními službami certifikátů, nástroje pro správu a obnovování certifikátů a další služby. Certifikáty mají široké použití, je možno je používat pro oblast elektronického podpisu, šifrování ale i autentizace apod. Certifikát nemusí mít pouze osoba, ale i server, případně existují atributové certifikáty, které umožňují svému držiteli členství v nějaké skupině, roli nebo určité oprávnění v systému.



Výběr certifikačních autorit působících v ČR:
I.CA www.ica.cz
CA Globe Internet http://certifikacniautorita.cz, http://ca.cz
CA Czechia http://caczechia.cz
CA České pošty http://www.postsignum.cz
CA InWay http://ca.inway.cz
CA KPNQwest Czechia http://ca.kpnqwest.cz
CA Decent Hosting www.decent.cz/cert.php
AEC TrustPort CA www.trustport.cz
CESNET www.cesnet.cz/cesnet-ca/
Certifikační autorita Masarykovy univerzity http://crl.muni.cz
Certifikační autorita Univerzity Karlovy www.cuni.cz/cucc/ca
CA VŠB TU www.vsb.cz/CA/
CA VŠE http://ca.vse.cz/certsrv/v
CA Mendelovy univerzity http://is.mendelu.cz/navod/


Používání certifikátů v ČR
Pro kontakt se státní správou a samosprávou je nutno využívat služeb akreditované ceritifikační autority (viz zákon o elektronickém podpisu č. 227/2000 Sb). Tuto akreditaci může vydat ministerstvo informatiky na základě splnění podmínek daných zákonem o elektronickém podpisu a prováděcí vyhláškou. Dále je nutné se řídit věstníkem MIČR, kde jsou zveřejněny normy, které mají být akreditovanými poskytovateli dodržovány, případně další upřesnění. Skutečnost, že jsou tyto normy naplňovány, je dokládána kontrolou bezpečnostní shody. Zatím je akreditovaný poskytovatel certifikačních služeb v České republice pouze jeden, a to První certifikační autorita. Veškeré informace o jejích certifikátech je možno najít na stránkách www.ica.cz. Problém je, že její certifikáty jsou pro občana poněkud drahé a že zatím neexistuje dostatečné množství aplikací, ve kterých by bylo možno je využít. Vláda se snaží podpořit rozšíření použití aplikací, kde je využíván e-podpis, jednak přidáváním této možnosti do ustanovení zákonů a dále podporuje například vydávání certifikátů pro obce zdarma. Vzhledem k frekvenci komunikace občana se státní správou se zřejmě nemůže pro jednotlivce nákup certifikátu vyplatit. Rozvoj lze naopak očekávat v podnikatelské sféře, která je nucena komunikovat s úřady mnohem častěji. Patrně nejrozšířenější využívání služeb CA lze zaznamenat v bankovnictví, kde je využívání certifikátů pro elektronické bankovnictví nezbytné. Tím lze vysvětlit nákup akcií společnosti I.CA ČSOB, a novější nákup akcií I.CA Českou spořitelnou. Svůj podíl v I.CA vlastní i jeden z mobilních operátorů, společnost Eurotel, která se chystá implementovat certifikát do SIM karty, a tím pádem jej využívat pro autentizaci a další zabezpečené služby přes mobilní telefon.

Komerční certifikační autority (CA) Dále existuje celá řada komerčních certifikačních autorit, které poskytují různé certifikáty pro různé účely, není je ale možno využít pro podepisování při kontaktu se státní správou. Vlastní komerční certifikační autority mají i banky, které využívají digitální certifikáty pro podpis transakcí v elektronickém bankovnictví.


MIČR nezasahuje do provozu komerčních CA, ani pro ně není stanovena oznamovací povinnost. Pro poskytování kvalifikovaných certifikačních služeb je však třeba požádat o akreditaci, případně pokud se jedná o certifikační autoritu akreditovanou v zemích EU, je ze zákona kvalifikovaným poskytovatelem i v České republice. V současné době se očekává žádost od České pošty pro působení jako akreditovaný poskytovatel. MIČR jedná i s dalšími subjekty, ale obecně je možno říci, že technologicky jsou společnosti, které takové služby poskytují, na slušné úrovni, ale po stránce procesní a dokumentační ještě mají rezervy. Vzhledem k tomu, že je třeba dokumentovat celý životní cyklus CA, většinou je pro ně vhodné postavit pro účel poskytování kvalifikovaných služeb úplně novou CA, protože jinak nejsou schopni dostát požadavkům zákona.

Propojení certifikačních autorit
Certifikační autority vytvářejí hierarchickou strukturu. Vrcholem této struktury je kořenový (root) certifikát. Certifikáty podřízených certifikačních autorit, příp. certifikáty konkrétních uživatelů, jsou vždy podepsány nadřazeným certifikátem, kořenový certifikát je podepsán vlastním soukromým klíčem, který musí být velmi dobře uložen, protože jeho prozrazení by vedlo k popření důvěry ve všechny podřízené certifikáty. Díky tomu došlo k situaci, že většina CA má svůj vlastní kořenový certifikát, případně existují domény daných CA. Proto si musí uživatelé nainstalovat mnoho kořenových certifikátů a situace se stává nepřehlednou (viz vsuvka). Pro uživatele je navíc rozhodování o důvěryhodnosti daných CA problematické, protože většinou nemají dostatečné množství údajů, případně času takové údaje zkoumat. Proto byly vyvinuty systémy, které umožňují další způsoby, jak si vzájemně uznávat certifikáty mezi doménami. Příkladem takových systémů může být cross-certification, nebo bridge CA. Při cross-certification dochází k vzájemnému uznání kořenových certifikátů ve dvou či více doménách. V současné době vznikají projekty propojující certifikační autority prostřednictvím bridge CA, což je nová CA, která vydává seznamy s důvěryhodnými službami certifikačních autorit. Příkladem může být European Bridge/Gateway CA, v průběhu příštího roku proběhne pilotní projekt. Tato aktivita se jeví jako velmi slibná, například vzhledem k neexistenci kořenové CA pro celou ČR. Česká republika se s velkou pravděpodobností tohoto projektu zúčastní, což i oficiálně potvrdila, a také jediná CA akreditovaná jako poskytovatel certifikačních služeb (společnost I.CA) vyjádřila vůli se zúčastnit.

Dagmar Brechlerová působí na Provozně ekonomické fakultě ČZU a také jako lektor a konzultant v oblasti bezpečnosti IS.
Lenka Nezdarová je studentkou doktorandského studia oboru informační management na téže fakultě.

Kalendář akcí
Konference - Semináře - Školení
Časopis IT Systems/Speciál
Aktuální číslo časopisu IT Systems Aktuální číslo časopisu příloha #1
Archív časopisu IT Systems
IT Systems 3 IT Systems 1-2 IT Systems 12 IT Systems 11
Archív časopisu IT Systems Special
Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1