Certifikační autorita SU

Transkript

1 Certifikační autorita SU Semestrální projekt (36SEM) ZS 2004/2005 Martin Fiala FEL ČVUT 4.ročník

2 - 2 -

3 Obsah 1. Úvod Studentská unie Certifikační autorita Význam šifer Symetrické šifrování Asymetrické šifrování Hybridní šifrování Privátní a veřejný klíč Man in the middle attack Certifikáty Funkce certifikační autority X.509 certifikát Extenze certifikátu Privátní klíč Důvěra prostřednictvím X.509 certifikátů Ověřování důvěryhodnosti Žádost o certifikát Vydání certifikátu Využití certikátu Elektronický podpis Hash funkce Seznam zneplatněných certifikátů Certifikační autorita SU Struktura Studentské unie Databáze uživatelů Příklad exportu seznamu členů klubu XML schéma exportu LDAP Požadavky na CA SU Uživatelské role Scénáře Příklad podání žádosti o certifikát Datový model Certifikáty Users (uživatelé) Cert_types (typy certifikátů) Relace Typy certifikátů Implementace

4 2.8 Podepisování certifikátů Podávání žádosti pomocí webového prohlížeče Pracujeme s OpenSSL Vytvoření certifikátu kořenové CA Zobrazení informací o certifikátu Podávání žádosti o serverový certifikát Kontrola údajů uvedených v žádosti / certifikátu Pravidelné kontroly a zálohování Instalace Certifikační politika Testování certifikační autority Stručný přehled zdrojových kódů Uživatelské rozhraní Menu uživatele Administrátor Správa certifikátu Závěrem

5 1. Úvod Certifikační autorita Studentské unie (CA SU) vzniká jako potřeba pro komunikaci mezi kluby Studentské unie a jejími řadovými členy. Žijeme v moderní době, a proto se také učíme používat věci jako elektronický podpis, který byl umožněn prostřednictvím objevu asymetrických šifer. Uživatelé počítačových sítí již pochopili, že výměna citlivých informací po těchto sítích není bez použití kryptografie bezpečná. Zvykají si již na zabezpečenou výměnu informací s převážně webovými servery a SU v tomto směru nechce být pozadu. Komunikace s některými webovými servery probíhá šifrovaně, před začátkem komunikace je však třeba ověřit totožnost serveru a právě to se děje prostřednictvím certifikátu. Kromě elektronického podpisu nám certifikáty umožňují ověřování klienta/serveru a šifrování u. Prvním velkým využitím certifikátů vydaných prostřednictvím CA SU budou právě zabezpečené servery, především zabezpečený přístup k poště. Dále komunikace mezi představenstvy jednotlivých klubů SU a nakonec certifikáty pro samotné uživatele. Cílem projektu je tedy vytvořit fungující certifikační autoritu pro organizaci Studentská unie (při ČVUT v Praze). 1.1 Studentská unie Studentská unie je občanské sdružení, které zahrnuje kluby působící na vysokoškolských kolejích ČVUT v Praze. Některé kluby se starají také o připojení studentů ubytovaných na kolejích. Kluby provozují spoustu serverů a služeb, např. webové servery, mailservery, tiskové služby, FTP, audiovizuální centrum, diskusní servery a mnoho dalších. U služeb ověřovaných heslem se používá zabezpečené připojení přes SSL/TLS. Zabezpečené připojení znemožní odposlechnutí přenosů mezi serverem a uživatelem a nedojde k narušení soukromí uživatele, případně k zneužití odposlechnutých dat třetí stranou. Je též třeba zaručit autenticitu dat přicházejících ze serveru. Kromě komunikace se servery komunikují mezi sebou také samotné kluby a jejich členové, případně lidé z vedení. Provozování tak velké organizace jako SU vyžaduje též určitou míru administrativy. Studenti pracují společně na různých zajímavých projektech, ale nemají příliš mnoho času stýkat se osobně. Proto pokud je to možné, používá se v hojné míře elektronická komunikace, která však nezaručuje autenticitu zasílaných zpráv. K tomu slouží elektronický podpis

6 1.2 Certifikační autorita Certifikační autorita vystavuje digitální certifikáty, které se používají pro elektronický podpis a šifrování dat. Pro správné pochopení funkce certifikační autority je nutné zavést některé další pojmy. 1.3 Význam šifer Šifry umožňují zakódování a pozdější dekódování nějaké informace. Znemožňují komukoli, kdo má možnost odposlouchávat samotný přenos zakódované informace, přečíst nebo dokonce změnit obsah informace. Šifry dělíme podle použitého klíče na obou stranách zabezpečeného kanálu na: symetrické obě strany používají stejný klíč asymetrické strany používají rozdílný klíč hybridní strany nejprve použijí asymetrickou šifru k předání společného klíče, který pak dále používají pro symetrické šifrování K elektronickému podpisu se nejlépe hodí asymetrické šifry, nicméně si všechny šifry popíšeme podrobněji Symetrické šifrování Při symetrickém šifrování se zpráva X transformuje pomocí klíče K na C(X, K)=Y. V zašifrované podobě Y se informace přenese k druhé straně, která informaci zpět dešifruje funkcí D(Y, K)=X. Symetrické šifrování z principu nelze využít pro elektronický podpis. Obrázek 1.1: Symetrické šifrování Velkou výhodou symetrických šifer je především rychlost. Problematická je ovšem počáteční výměna klíčů, kdy je nutné, aby obě komunikující strany buď znaly klíč dopředu nebo si ho vyměnily před začátkem komunikace zabezpečeným kanálem. Dalším problémem je počet potřebných klíčů. Při komunikování více stran mezi sebou roste - 6 -

7 počet klíčů s druhou mocninou komunikujících stran. Příkladem symetrických šifer jsou AES, RCx, BlowFish, DES, 3DES, IDEA, Asymetrické šifrování Šifrování zde probíhá proti symetrickému odlišně. Každá strana si vytvořila dvojici komplementárních klíčů veřejný a privátní klíč, přičemž privátní klíč nikdy nezveřejňuje. Veřejný klíč předá straně, s kterou chce komunikovat. Předání informace pak probíhá následovně: zpráva X se nejprve transformuje veřejným klíčem druhé strany K A na C(X, K A ) =Y. Zašifrovaná informace Y se opět přenese nezabezpečenou cestou k druhé straně. Druhá strana pak po přijmutí zašifrované zprávy dešifruje svým privátním klíčem K B : D(Y, K B ) =X. Obrázek 1.2: Asymetrické šifrování Asymetrické šifrování již řeší problém při větším počtu komunikujících stran, počet klíčů roste lineárně s počtem komunikujících stran. Tento způsob šifrování je již vhodný k elektronickému podpisu. Velkou nevýhodou proti symetrickému šifrování je velká výpočetní náročnost, protože asymetrické šifrování je založené na operacích s velkými prvočísly. Typickými asymetrickými šiframi jsou Diffie-Hellman, RSA a DSA Hybridní šifrování Hybridní šifrování je založené na kombinaci symetrického a asymetrického šifrování. Odesílatel nejprve vygeneruje tzv. klíč relace L, tímto klíčem zakóduje předávanou informaci (symetricky), klíč relace zakóduje asymetricky veřejným klíčem protistrany. Druhá strana nejprve svým privátním klíčem dekóduje klíč relace a s ním dékoduje samotný obsah zprávy

8 Obrázek 1.3: Hybridní šifrování Tento typ šifrování se používá např. při komunikaci pomocí SSL/TLS. Hybridní šifrování spojuje výhody obou předchozích: lineární počet klíčů přijatelná výpočetní náročnost umožňuje digitální podpis 1.4 Privátní a veřejný klíč K čemu vlastně potřebujeme 2 klíče? Při asymetrickém šifrování používáme privátní a veřejný klíč. Pokud chceme předat nějakou zprávu v zašifrované podobě, transformujeme ji pomocí veřejného klíče druhé strany a ta pak zprávu dešifruje svým veřejným klíčem. Tím je zaručeno, že si zprávu nepřečte nikdo další. Dvojici klíčů však můžeme využít i k zaručení autenticity poskytnuté informace, kdy informace je transformována naším privátním klíčem, druhá strana zná náš veřejný klíč a pomocí něj informaci dešifruje. Tento způsob komunikace se obvykle používá při elektronickém podpisu. Pro šifrování většího bloku dat se používá ještě ovšem tzv. hash. Bezpečnost komunikace pomocí dvojice privátního a veřejného klíče je zaručena především díky matematice - nalezení privátního klíče k veřejnému klíči je časově velmi náročná operace, která by i nejvýkonějším počítačům dnešní doby trvala několik let. Jedním z nejpoužívanějších přístupů je počítání s velkými prvočísly, které používají algoritmy RSA i DSA. Použití asymetrického širování ovšem přináší jeden problém. Jak máme vlastně zaručeno, že komunikujeme skutečně s tím s kým chceme komunikovat, pokud neznáme dopředu jeho veřejný klíč? 1.5 Man in the middle attack Neznalosti veřejného klíče protistrany (případně hlouposti uživatele) využívá právě tzv. Man - 8 -

9 in the middle attack (Muž uprostřed). Alice chce komunikovat s Bobem, ale ve skutečnosti se spojí s Mallorym, který Alici nabídne svůj podvržený veřejný klíč, pomocí kterého se vydává za Boba. Poté naváže spojení s Bobem. Alice pošle Bobovi zprávu zašifrovanou veřejným klíčem, ovšem ve skutečnosti se jedná o Malloryho, který zprávu dešifruje, zašifruje Bobovým veřejným klíčem a předá Bobovi. Alice ani Bob nic nepoznají a zatím si Mallory čte informace, které si mezi sebou vyměňují. Obrázek 1.4: Man in the middle attack 1.6 Certifikáty Certifikát je veřejný klíč podepsaný od nějaké třetí důvěryhodné strany. Máme více druhů: PGP (=Pretty Good Privacy) - model distribuované důvěry X hierarchický princip důvěry. Při používání tohoto modelu důvěry stojí nejvýše kořenová certifikační autorita, která podepisuje certifikáty podřízených certifikačních autorit. Ty potom vydávají běžné certifikáty. Tento model důvěry je považován za standard v elektronickém podpisu a je základem Certifikační autority SU. Obrázek 1.5Hierarchický princip 1.7 Funkce certifikační autority Pojem certifikační autorita spojujeme především s X.509 certifikáty. Certifikační autorita vydává certifikáty různých typů - serverové, uživatelské a pak také certifikáty podřízených certifikačních autorit. Měla by být nezávislá a dostatečně důvěryhodná

10 Certifikační autorita ověřuje pravdivost informací zadaných v žádosti o certifikát, zneplatňuje certifikáty, prodlužuje platnost certifikátů a zveřejňuje seznam zneplatněných certifikátů. 1.8 X.509 certifikát X.509 certifikáty jsou kódované pomocí ASN.1. Obsahují: veřejný klíč držitele certifikátu informace o držiteli certifikátu Common Name address Organization, Organizational Unit Country, State, Locality sériové číslo, platnost od/do informace o vystaviteli certifikátu (issuer) podpis vystavitele certifikátu možnosti využití certikátu (extenze) 1.9 Extenze certifikátu SSL client, SSL server - certifikáty pro ověřovanou komunikaci client/server signing, encryption - podepisování a šifrování ů CRL signing - podepisování Certificate Revocation Listu (seznamu zneplatněných certifikátů) OCSP helper (OCSP=Online Certificate Status Protocol) basicconstraints=ca:{true, FALSE} - zda může certifikát sloužit jako certifikační autorita nepovinné extenze extendedkeyusage=clientauth, protection a další 1.10 Privátní klíč Privátní klíč musí být především bezpečně uložen (token, jakékoli přenosné medium, souborový systém s nastavením přístupových práv pro uživatele, bezpečné úložiště v systému, bezpečný počítač). Klíč by měl být chráněný heslem (3DES). Privátní klíč (i chráněný heslem) nesmí nikdy získat jiná osoba. V případě kompromitace privátního klíče jeho držitel co nejdříve oznámí ztrátu privátního klíče certifikační autoritě, která certifikát vydala

11 1.11 Důvěra prostřednictvím X.509 certifikátů V certifikátu jsou uvedené informace jednoznačně identifikující subjekt, který žádá o certifikát. Certifikační autorita ověří pravost informací uvedených v certifikátu a ověří žadatele. V kladném případě takovou žádost o certifikát podepíše a žadateli pošle hotový certifikát. Pro ověření totožnosti žadatele nám tedy stačí věřit certifikační autoritě a znát její veřejný klíč. Pokud tedy věříme certifikační autoritě, věříme zároveň i všem certifikátům touto autoritou podepsaným. Před tím, než začneme nějaké autoritě věřit, měli bychom si zjistit, jakým způsobem prověřuje certifikační autorita totožnost žadatelů a pravost údajů uvedených v certifikátu. Můžeme si uvést typický příklad komunikace: Alice a Bob spolu nikdy nekomunikovali a neznají veřejný klíč druhé strany Alice naváže spojení s Bobem předají si navzájem certifikáty a zjistí, zda se jedná o důvěryhodný certifikát Alice má podepsaný certifikát od certifikační autority, které Bob důvěřuje Bob má podepsaný certifikát od certifikační autority, které Alice důvěřuje oba mají ověřenou totožnost druhé strany a mohou tedy pokračovat v komunikaci 1.12 Ověřování důvěryhodnosti V systému máme seznam certifikátů, kterým důvěřujeme, mezi ně patří i certifikační autority. U jednotlivých certifikátů můžeme obvykle určit, jakému jejich použití důvěřujeme. V systému jsou obvykle některé certifikační autority již předinstalované. Další certifikáty může doinstalovat sám uživatel. Pokud se připojujeme k nějakému serveru pomocí zabezpečeného připojení, server nám nejdříve pošle svůj certifikát. Po přijetí certifikátu zkusíme vyhledat certifikát v seznamu důvěryhodných certifikátů. Pak prověříme, zda certifikát není podepsaný od certifikační autority, které důvěřujeme. Certifikační autorita obvykle nabízí online seznam zneplatněných certifikátů, tento seznam stáhneme a prohledáme, zda prověřovaný certifikát není mezi odvolanými. Pokud certifikát serveru neznáme a ani neznáme certifikační autoritu, která certifikát podepsala, můžeme certifikát odmítnout, přijmout pro dané spojení nebo přijmout a nainstalovat do systému Žádost o certifikát Nejprve si vybereme vhodnou certifikační autoritu. Zjistíme podmínky za jakých nám tato

12 autorita vydá certifikát. Typicky to spočívá ve vytvoření žádosti o certifikát (CSR=Certificate Signing Request): do certifikátu vyplníme údaje o sobě vygenerujeme pár privátní a veřejný klíč privátní klíč bezpečně uschováme, veřejný klíč přiložíme k žádosti hotovou žádost předáme certifikační autoritě Vytvoření žádosti provedeme pomocí vhodného programového vybavení. Např. pomocí balíčku OpenSSL, CryptoAPI v našem webovém prohlížeči nebo nějaké speciální aplikace či zařízení Vydání certifikátu Certifikační autorita nyní musí ověřit oprávněnost žádosti o certifikát. Pokud se jedná o certifikační autoritu nějaké organizace, zjistí, zda je žadatel skutečně členem této organizace. Dále musí ověřit, že žadatel je skutečně ten, za koho se vydává. Toto už většinou záleží na konkrétní certifikační autoritě, některé to řeší pouhým ověřením u uvedeného v žádosti, další ověřují, zda držitel uvedeného u drží také privátní klíč. Toto je umožněno díky dříve známému u, který uživatel získal při vstupu do organizace. Veřejné certifikační autority ověřují totožnost žadatele osobním stykem a prokázáním totožnosti nějakým dokladem. Ověřovateli oprávněnosti žádosti o certifikát se obvykle říká registrační autorita. V případě, že splníme všechny náležitosti, podepíše certifikační autorita náš certifikát, přidá k němu informace o sobě a hotový certifikát nám předá Využití certikátu Serverové certifikáty slouží k ověření autenticity serveru a vylučuje Man in the middle attack, mezi používané služby patří https, pop3s, imaps, smtps, ftps a další. Klientské certifikáty se používají pro ověření totožnosti klienta při připojování místo hesla. V elektronické komunikaci můžeme využít Obrázek 1.6: Elektronický podpis elektronický podpis a šifrování ů, musíme však znát dopředu veřejný klíč protistrany

13 1.16 Elektronický podpis Asymetrická šifra přes celý dokument je příliš náročná. Pomocí hash funkce vytvoříme otisk zprávy, který zašifrujeme privátním klíčem a připojíme k dokumentu. Výsledná strana oddělí zašifrovanou hash od dokumentu, dešifruje hash veřejným klíčem, spočítá znovu hash celého dokumentu a porovná výsledek. V případě shody máme zaručenou autenticitu dokumentu i autora. Pokud by dokument někdo změnil, změní se výsledná hash. Ovšem hash může zašifrovat a připojit zpět k dokumentu pouze držitel certifikátu. Obrázek 1.7: Elektronický podpis s využitím hash funkce 1.17 Hash funkce Hash funkce je funkce, která transformuje velký objem dat do mnohem kratšího otisku (bezpečný výtah zprávy=message digest), který má typicky 128 bitů (MD5) nebo 168 bitů (SHA-1). Dobrá hash funkce musí splňovat určité předpoklady, výpočet hash musí být jednoduchý a jednocestný, tzn. z otisku není možné zpět spočítat data, která byla na vstupu hash funkce. Jakákoli drobná změna na vstupu funkce musí výrazným způsobem ovlivnit výstup hash funkce. Vymyslet zprávu, která by měla konkrétní otisk musí být velmi obtížné. Nedávno ovšem byly ovlivněny kolize v hojně používané hash funkci MD5. Hash funkce SHA-1 je zatím považována za bezečnou Seznam zneplatněných certifikátů Každá certifikační autorita musí udržovat a publikovat seznam zneplatněných certifikátů- CRL=Certificate Revocation List, seznam obsahuje zneplatněné certifikáty. Důvodem k předčasnému ukončení platnosti certifikátu může být změna údajů uvedených v certifikátu,

14 kompromitace privátního klíče, ukončení členství v organizaci,... Certifikační autorita by měla poskytovat co nejaktuálnější seznam. Samotný seznam by měl dostupný dvěma na sobě nezávislými cestami. 2. Certifikační autorita SU Již jsme si vysvětlili, co je to certifikační autorita a co by měla umět a také jsme stručně popsali, co je to Studentská unie. Nyní se zaměříme více na její strukturu. 2.1 Struktura Studentské unie SU je složená z mnoha klubů, které sdružují členy se společnými zájmy. V čele SU stojí prezident s Centrálou, v čele klubů stojí předsedové s Představenstvem. Jedná se tedy o hierarchický princip, který můžeme vhodně využít při budování stromu certifikačních autorit. Nejvýše bude stát CA SU a pod ní budou certifikační autority jednotlivých klubů. Kluby potom mohou zvolit ze 2 způsobů. Mohou si vytvořit další podřazené certifikační autority pro konkrétní účely - např. vydávání certifikátů pro uživatele a vydávání certifikátů pro servery. Tento přístup bude jistě vhodnější u větších klubů typu Silicon Hill ( Menší kluby mohou podepisovat všechny certifikáty jednou autoritou, ale záleží to na nich, čemu dají přednost. Doporučený způsob je však vytvořit zvlášť další certifikační autoritu pro servery. Díky hierarchickému principu důvěry používánému u X.509 certifikátů potom uživateli stačí naimportovat si certifikát certifikační autoritu v libovolné úrovni stromu, běžnému uživateli však stačí naimportovat certifikát autority stojící nejvýše, tj. CA SU. Při kontrole autenticity certifikátu je pak využito certificate chainingu (viz. PKCS#7), kdy server zasílá celou strukturu certifikátů od listu až ke kořeni a klient kontroluje, zda důvěřuje některému z nadřazených certifikátů. Z výše uvedeného vyplývá, že náš projekt CA SU se nestará jen o jediný certifikát v kořeni stromu, ale o všechny certifikáty v tomto stromu obsažené. Z bezpečnostních důvodů se žádný privátní klíč nevyskytuje na serveru. Server je pouze databáze certifikátů, kde si uživatelé mohou prohlížet již vydané certifikáty, žádat o nové či zneplatňovat certifikáty, správci certifikačních autorit pak mohou přijímat nebo zamítat žádosti o certifikát, vyzvedávat žádosti k podepsání a uploadovat podepsané certifikáty. Podepisování žádostí (vytváření nových certifikátů) probíhá na počítači držitele privátního klíče k dané certifikační autoritě. Tento je povinen uchovávat privátní klíč bezpečně na přenosném médiu a v šifrované podobě. V případě kompromitace privátního klíče by bylo nutné zneplatnit i

15 všechny podřízené certifikáty. 2.2 Databáze uživatelů Pro autentizaci uživatelů, kteří chtějí podat žádost o certifikát by bylo nutné, aby se tito uživatelé v systému registrovali. Všechny kluby dnes již mají vlastní databázi uživatelů v elektronické podobě včetně jména a hesla a je tedy výhodné využít tyto informace. Avšak protože ne všechny kluby používají stejný způsob ukládání dat a řešit import dat s každým z klubů zvlášť by bylo problematické, navrhl jsem univerzální formát pro export v XML. Zajímají nás údaje ID, jméno, příjmení, , číslo pokoje, uživatelské jméno, heslo a zda-li je uživatel stále členem klubu. Exporty a importy se budou provádět každou noc, údaje tak budou maximálně jeden den staré. Výhodou je vznik jakési centrální databáze členů SU, která zatím neexistuje. Importní skript je realizován pomocí konečného automatu, který zpracovává jednotlivé položky a také kontroluje, zda mají správný formát. Případné chyby se zašlou administrátorovi systému em. Při importu je vytvořena dočasná tabulka, do které jsou vloženy všechny položky importu a SQL příkazem se vyberou rozdílné položky proti aktuální databázi. Poté se s těmito položkami pracuje dle druhu rozdílu, uživatel se buď vloží, aktualizují se informace o něm nebo se odstraní úplně z databáze Příklad exportu seznamu členů klubu <?xml version="1.0" encoding="iso "?> <klub id="2" name="jmeno_klubu" xsi:nonamespaceschemalocation="vzor.xsd" xmlns:xsi=" <clen> <id>1</id> <jmeno>frantisek</jmeno> <prijmeni>vomacka</prijmeni> < > @klub.cvut.cz</ > <pokoj>301</pokoj> <login>username</login> <password>md5_hash</password> <aktivni>true</aktivni> </clen> </klub> XML schéma exportu <xs:schema xmlns:xs=" <xs:simpletype name="jmenotype"> <xs:restriction base="xs:string"> <xs:minlength value="1"/> <xs:maxlength value="30"/> </xs:restriction> </xs:simpletype>

16 <xs:simpletype name=" type"> <xs:restriction base="xs:string"> <xs:pattern <!-- <xs:pattern --> </xs:restriction> </xs:simpletype> <xs:simpletype name="pokojtype"> <xs:restriction base="xs:string"> <xs:minlength value="0"/> <xs:maxlength value="10"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="logintype"> <xs:restriction base="xs:string"> <xs:minlength value="1"/> <xs:maxlength value="10"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="passwordtype"> <xs:restriction base="xs:string"> <xs:minlength value="0"/> <xs:maxlength value="32"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="aktivnitype"> <xs:restriction base="xs:boolean"/> </xs:simpletype> <xs:element name="klub"> <xs:complextype mixed="false"> <xs:sequence minoccurs="0" maxoccurs="unbounded"> <xs:element name="clen"> <xs:complextype mixed="false"> <xs:all minoccurs="1" maxoccurs="1"> <xs:element name="id" type="xs:integer"/> <xs:element name="jmeno" type="jmenotype"/> <xs:element name="prijmeni" type="jmenotype"/> <xs:element name=" " type=" type"/> <xs:element name="pokoj" type="pokojtype"/> <xs:element name="login" type="logintype"/> <xs:element name="password" type="passwordtype"/> <xs:element name="aktivni" type="aktivnitype"/> </xs:all> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="id" type="xs:integer" use="required"/> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complextype> </xs:element> </xs:schema>

17 2.2.3 LDAP Do budoucna se plánuje exportovat takto získaný seznam všech členů SU do LDAPu včetně uživatelského certifikátu. Tuto databázi by pak bylo možné využívat pro centrální autentizaci členů, neboť by v ní mohlo být uloženo jméno, heslo a uživatelský certifikát, který lze též používat k autentizaci vůči serveru, navíc výhodou oproti používání jména a hesla je výrazně zvýšená bezpečnost. 2.3 Požadavky na CA SU Nyní si podrobně uvedeme uživatelské role a scénáře Uživatelské role Administrátor - správce systému, může upravovat naprosto všechno, práva uživatelů, určovat předsedy klubů, měnit vlastníky certifikátů atd. Předseda klubu - může přiřazovat jednotlivé uživatele do klubu, měnit informace o klubu, vytvářet certifikační autoritu Registrovaný uživatel - podává žádosti o certifikát, prohlíží svoje certifikáty, zneplatňuje, mění práva ostatních uživatelů nad svým certifikátem, může si změnit heslo Neregistrovaný uživatel - prohlíží veřejně vystavené certifikáty a může si je stáhnout a nainstalovat do svého systému Scénáře Registrace uživatele uživatel vyplní informace o sobě, jméno, heslo a získává konto v systému oprávnění uživatelé mu mohou přiřadit práva nad jinými certifikáty, zařadit ho do klubu Podání žádosti o certifikát uživatel si ve stromě vybere certifikační autoritu, u které chce získat certifikát zpravidla si vybírá autoritu, která je svázána s jeho klubem vygeneruje si dvojici privátní-veřejný klíč a žádost o certifikát (CSR) odešle žádost o certifikát se uloží do databáze a čeká na podepsání Přijmutí/zamítnutí žádosti o certifikát uživatel s právem podepisování nad danou certifikační autoritou prohlíží seznam žádostí špatně vyplněnou žádost nebo žádost podanou u nesprávné autority rovnou zamítne žadatel se dostaví za touto důvěryhodnou osobou, prokáže svou totožnost a tím pravdivost údajů uvedených v certifikátu

18 oprávněná důvěryhodná osoba nyní může označit žádost jako vhodnou k podepsání Podepisování certifikátů osoba držící privátní klíč k certifikační autoritě (vlastník CA) si prohlédne seznam žádostí, doporučených k podepsání seznam žádostí si stáhne k sobě a podepíše pomocí privátního klíče jednotlivé žádosti hotové certifikáty nahraje do databáze, vlastníkům certifikátů pošle em oznámení o podepsání certifikátu a adresu, kde je možné si certifikát vyzvednout Prohlížení certifikátů uživatel vstoupí do systému prohlíží si strom s certifikačními autoritami a podepsanými žádostmi, případně si zjistí informace o držiteli certifikátu či správci certifikační autority Zneplatňování certifikátů pokud došlo ke kompromitaci privátního klíče nebo ke změně údajů uvedených v certifikátu, je držitel certifikátu povinen podat žádost o zneplatnění certifikátu informace o zneplatnění certifikátu je zapsána do databáze na webové stránce je k dispozici ke stažení seznam zneplatněných certifikátů (CRL) 2.4 Příklad podání žádosti o certifikát Co musí člověk udělat, aby dostal certifikát? 1) přihlásit se do webového rozhraní CA SU 2) najít si vhodnou autoritu a u ní podat žádost o certifikát, uvést mailovou adresu z domény cvut.cz 3) dojde k ověření, zda zadaná ová adresa je jeho 4) přijde za Registrační autoritou (RA) = důvěryhodný člověk z klubu, který ověří jeho totožnost na základě OP nebo indexu a označí žádost jako vhodnou k podepsání 5) správce dané certifikační autority (držitel privátního klíče) vyzvedne jednou týdně žádosti k podepsání, na bezpečném počítači je podepíše a hotové certifikáty uploadne zpět do CA SU 6) žadateli o certifikát se zašle informace o možnosti vyzvednout si hotový certifikát

19 2.5 Datový model Obrázek 2.1: E-R model vytvořený pomocí programu ER modeller Některé položky a role si zřejmě zaslouží bližší komentář. Popíšu tedy jednotlivé entity, jejich atributy a poté i vztahy i mezi entitami Certifikáty Zde jsou uloženy všechny žádosti o certifikát, platné i zneplatněné, případně expirované certifikáty a certifikáty certifikačních autorit. Vysvětlení některých atributů: název, popis - pole sloužící k zobrazování certifikátu v systému, ve výsledném certifikátu se nevyskytují CN, country, state, locality, organization, organizational unit - běžná povinná pole certifikátu - kontaktní adresa na držitele certifikátu stav - stav ve kterém se právě nachází certifikát conf - podaná žádost čekající na potvrzení pomocí URL zaslané em request - žádost čekající na ověření registrační autoritou

20 accepted - přijatá žádost čekající na podepsání rejected - zamítnutá žádost cert - platný certifikát expired - certifikát, kterému vypršela platnost revoked - odvolaný certifikát visible - {public, private}definuje zda je certifikát publikován veřejně nebo zda ho vidí jen pověřené osoby serial - sériové číslo certifikátu důvod - důvod odvolání certifikátu (např. kompromitace priv. klíče, konec členství v klubu,...) cert - binární data certifikátu req - binární data žádosti o certifikát chain - binární data certificate chainu (PKCS#7) uid - user ID, ID uživatele v rámci klubu caserial - sériové číslo dalšího certifikátu, který vydá tato certifikační autorita Users (uživatelé) práva - globální oprávnění uživatele v systému 0 = superuživatel - může editovat účty administrátorů 1 = administrátor - má v systému absolutní moc kromě editace účtu ostatních administrátorů 2 = předseda klubu - může zakládat certifikační autoritu a nový klub 3 = registrovaný uživatel - běžný uživatel Cert_types (typy certifikátů) ext_id - pomocí tohoto jména jsou v openssl.cnf definované parametry certifikátu ca - {y,n} definuje zda se jedná o certifikát certifikační autority browser_req - {y,n} definuje, zda je možné vygenerovat žádost pomocí webového prohlížeče Relace je_predseda - uživatel je předsedou nějakého klubu ma_pravo - uživatel má nějaká práva nad konkrétním klubem prava=1 - správce prava=2 - přidávání podklubů (kluby je možné hierarchicky uspořádat)

21 prava=3 - člen klubu prava=4 - žádné právo (vyhrazené) je_nadrazeny - relace sloužící k hierarchickému uspořádání klubů bydli_na_koleji - uživatel bydlí na nějaké koleji, k tomu se pak vztahuje také číslo pokoje je_typu - certifikát musí být nějakého konkrétního typu vydava_certy_typu - pokud je certifikát certifikační autoritou, musí mít definováno jaké typy certifikátů nabízí je_podepsany - certifikát je podepsán nějakou certifikační autoritou (jiným certifikátem), pokud se ovšem nejedná o kořenovou certifikační autoritu ma_pravo - uživateli jsou přidělena práva pro práci s konkrétním certifikátem level=1 - správce level=2 - ověřovací právo nad certifikační autoritou level=3 - čtení certifikátu a podávání žádosti (má smysl jen pro private certifikáty) level=4 - žádné právo (vyhrazené) podal_zadost - uživatel podal žádost o certifikát overil - uživatel s ověřovacími právy nad certifikační autoritou (registrační autorita) akceptoval žádost o certifikát a označil ji jako vhodnou k podepsání 2.6 Typy certifikátů CA - certifikační autorita SSL server - serverový certifikát SSL klient - klientský certifikát SMTP server - poštovní server, SSL klient+ssl server objsigning - podepisování CRL a OCSP - podepisování a kódování ů uživatelský - běžný uživatelský certifikát, SSL client + signing and encryption SSL CA - certifikační autorita vydávající SSL server a SSL klient certifikáty CA - certifikační autorita vydávající certifikáty 2.7 Implementace Samotný projekt je napsaný v PHP, používá databázi MySQL a několik bash skriptů. Tento model byl zvolen kvůli rozšířenosti, spousta lidí ovládá právě PHP a umí používat MySQL, takže na tento projekt může bez problémů navázat někdo další. Pro spuštění projektu tedy potřebujeme jeden dobře zabezpečený server, momentálně se nabízí jeden starší vyřazený

22 server na architektuře PPC s operačním systémem *BSD. K provozu stačí webový server Apache s mod_ssl a mod_php, dále MySQL server a binárka openssl. Jiná platforma než x586 je vhodná proti řadě exploitů, které se dají najít na internetu po nalezení a zveřejnění chyby v nějakém programu. Zdrojové kódy je ještě nutné prověřit z bezpečnostního hlediska nějakou další osobou a projekt podrobit důkladnému testování. 2.8 Podepisování certifikátů Od certifikační autority drží privátní klíč obvykle pouze jedna osoba a tento má bezpečným způsobem uložen. Podepisování by mělo probíhat nejlépe na počítači, který není připojen jakýmkoli způsobem do internetu, takový počítač lze považovat za bezpečný, pokud se nachází na uzamykatelném místě, kam má přístup omezený počet oprávněných osob. V praxi je však pravděpodobnější, že se kluby zařídí co nejlépe dle svých možností. Systém tedy umožňuje stažení žádostí k podepsání a po podepsání jejich následný upload zpět. Ze systému si tedy správce certifikační autority nejdříve stáhne speciální soubor (obyčejný tar.bz2 archiv) se žádostmi včetně informace, jakého typu má být vystavený certifikát a dále obsahuje připravený seznam zneplatněných certifikátů k vystavení CRL. Tento soubor pak přenese správce na počítač, na kterém chce provádět vlastní podepisování. Do stejného adresáře přidá privátní a veřejný klíč certifikační autority a spustí podepisovací skript. Po skončení je vytvořen nový soubor (opět tar.bz2 archiv), který je ovšem navíc podepsaný certifikační autoritou. Tento soubor si pak přenese do počítače s připojením k internetu a uploadne ho do systému CASU. Nyní dojde k ověření autentičnosti souboru a zpracování informací v něm obsažených. Lidem, kterým byl vystaven certifikát dojde em oznámení o možnosti vyzvednout si hotový certifikát. Nyní se podíváme na obsah podepisovacího skriptu: #!/bin/bash echo Extracting requests archive... tar -jxvf reqs.tar.bz2 echo -n Need password for private key: read -s heslo export heslo echo echo echo Signing certificates... cd openssl for i in reqs/* ; do ext=`echo "$i" sed "s/.*\///"`

23 echo $ext extensions echo echo `ls "$i"/* 2> /dev/null wc -l` requests to sign cnt=`ls "$i"/* 2> /dev/null grep \\.req wc -l` if [ $cnt -gt 0 ]; then for d in "$i"/* ; do days=`basename "$d"` openssl ca -config openssl.cnf -extensions $ext -notext -batch -passin env:heslo -days "$days" -infiles "$d"/*.req done fi if [ `ls "$i"/* 2> /dev/null grep \\.spk wc -l` -gt 0 ] ; then for d in "$i"/* ; do days=`basename "$d"` for x in "$d"/*.spk ; do openssl ca -config openssl.cnf -extensions $ext -notext -batch -passin env:heslo -days "$days" -spkac "$x" done done fi echo done echo Generating \& signing CRL openssl ca -config openssl.cnf -gencrl -out crl.pem -passin env:heslo openssl crl -in crl.pem -outform der -out ca.crl echo echo Creating signed certificates archive... tar -cjvf newcerts.tar.bz2 newcerts ca.crl openssl sha1 -sign../cakey.pem -out sha1.sgn newcerts.tar.bz2 tar -cvf../newcerts.dat newcerts.tar.bz2 sha1.sgn cd.. rm -rf openssl unset heslo Podepisování rozdílných typů certifikátů je vyřešeno pomocí jmen adresářů, ve kterých jsou uložené žádosti. Toto jméno se shoduje s identifikátorem extenzí uvedených v openssl.cnf, kde jsou přesně definovány vlastnosti nového certifikátu (zda lze použít jako CA, jaké jsou možnosti použití, kde se nachází CRL k vydaným certifikátům,...). Následuje ukázka extenzí typu CA: [ casu_ca ] subjectkeyidentifier=hash authoritykeyidentifier=keyid:always,issuer:always nscomment = "Certifikat Studentske unie CVUT" basicconstraints = CA:true keyusage = crlsign, keycertsign crldistributionpoints = URI:%CRLDIST% authorityinfoaccess = caissuers;uri:%caissuer%

24 2.9 Podávání žádosti pomocí webového prohlížeče Nejjednodušším způsobem získání certifikátu je podávat žádost prostřednictvím webového prohlížeče. Moderní webové prohlížeče v sobě totiž obsahují tzv. CryptoAPI, které se využívá právě pro práci s certifikáty a podávání žádostí. Náš systém je kompatibilní s prohlížeči MSIE, Mozilla a Opera, pomocí kteréhokoli z těchto prohlížečů je tedy možné podat žádost o certifikát. Prohlížeč vygeneruje privátní klíč, který bezpečně uloží do svého úložiště certifikátů, a serveru odešle data žádosti o certifikát (výjimkou je Mozilla používající formát SPKAC). Po vystavení certifikátu a nainstalování do prohlížeče dojde ke spárování privátního klíče a certifikátu a nyní můžeme certifikát naplno využívat. Důležitou věcí je povolit export privátního klíče, jinak při přeinstalování operačního systému o certifikát nenávratně přijdeme. Tento způsob nevyžaduje prakticky žádné hlubší znalosti uživatele a je vhodný k vydávání uživatelských certifikátů. K ostatním typům je nutné použít binárku OpenSSL Pracujeme s OpenSSL Vytvoření certifikátu kořenové CA Pro vytvoření certifikátu kořenové certifikační autority nemusíme nikde podávat žádost, nemáme totiž u koho. Takovýto certifikát se nazývá self-signed (vlastnoručně podepsaný, resp. podepsaný sám sebou). Vytvoříme ho jednoduše pomocí binárky openssl příkazem: openssl req -new -x509 -out cacert.pem -keyout cacert.key -days 3650 Budeme vyzvání nejprve k zadání hesla, které bude chránit privátní klíč a pak k zadání informací k dané CA (CN, Country, Organization,...). Do souboru cacert.pem se nám uloží veřejný klíč s certifikátem a do souboru cacert.key se uloží privátní klíč. Ihned mu odstraníme příkazem chmod 600 cacert.key možnost čtení ostatními uživateli a někam ho bezpečně uložíme Zobrazení informací o certifikátu Pokud chceme zjistit informace o vytvořeném certifikátu a máme certifikát uložen v souboru cert.pem, můžeme pomocí openssl tyto informace zobrazit příkazem: openssl x509 -in cert.pem -purpose -text -noout Na výstup se nám tak vypíšou možnosti využití certifikátu a pak informace v certifikátu uložené v čitelné podobě Podávání žádosti o serverový certifikát Při podávání žádosti o serverový certifikát je vhodné použít openssl.cnf vygenerovaný

25 systémem CASU, máme tak zaručeno správné nastavení všech údajů. K vytvoření žádosti pak stačí příkaz: openssl req -new -config openssl.cnf -out cert.req -keyout cert.key Privátnímu klíči opět změníme atributy a bezpečně uložíme. Informace o vygenerované žádosti můžeme zjistit příkazem: openssl req -in cert.req -text -noout 2.11 Kontrola údajů uvedených v žádosti / certifikátu Při podání žádosti u nějaké certifikační autority systém testuje shodu dědičných položek s údaji uvedenými v certifikátu dané CA, v případě neshody je taková žádost odmítnuta. Kontroluje se též duplicita s jakýmkoli platným certifikátem. Podobně při nahrávání nových certifikátů do systému se testuje spárování certifikátu se žádostí Pravidelné kontroly a zálohování Každý den se kromě importů certifikátů musí provádět kontroly databáze. Certifikáty s prošlou platností se označí jako expired. Žádosti s prošlou platností se označí jako zamítnuté a pošle se . Toto je realizováno pomocí php skriptu kontrola.php spouštěného z cronu. Také je nutné celou databázi pravidelně zálohovat. Toho lze dosáhnout přidáním příkazu do cronu: mysqldump ca -c gzip > /var/backups/ca`date +%Y%m%d`.gz Ke správné funkci je nutné mít v konfiguračním souboru MySQL serveru uvedenu sekci client: [client] password=heslo Kde heslo je heslo používané klientskými programi spouštěnými pod uživatelem root. Opět je nutné správně nastavit oprávnění ke čtení tohoto souboru Instalace Libovolný počítač a OS, na kterém poběží následující: Apache + mod_ssl - zkonfigurováno tak, že při přístupu přes HTTP se přesměrovává na zabezpečené HTTPS PHP ve verzi 4 (mod_php) s podporou sessions pomocí cookies, HTTP uploadu, openssl, vypnutými varovnými hlášeními a register_globals=off openssl cron

26 doporučený je též phpmyadmin pro správu MySQL databáze Počítač by měl být dobře zabezpečený. Správce by měl provádět pravidelně analýzu logů a instalovat bezpečnostní záplaty. Narušení systému by mohlo znamenat kompromitaci celé certifikační autority, a to i přes to, že se v systému nevyskytují privátní klíče certifikačních autorit. Mohlo by totiž dojít k podepsání falešných žádostí o certifikát. Po nakopírování hlavního adresáře na server je třeba upravit soubor goptions.php a nastavit heslo pro přístup k databázi ca a zadat zde administrátorské heslo k MySQL databázi. Vytvoření databáze, uživatele a tabulek se provede spuštěním skriptu install.php. Po úspěšném vytvoření odstraňte soubor install.php a smažte administrátorské heslo ze souboru goptions.php. Do systému se přihlásíme jako supervizor, změníme heslo a vytvoříme další konta Certifikační politika Správcem kořenové certifikační autority je technický manažer SU. Tato certifikační autorita vydává (podepisuje) certifikáty všech podřazených certifikačních autorit jednotlivých klubů. Certifikační autority vlastněné kluby mohou vystavit certifikát další podřazené certifikační autoritě dle požadavků konkrétního klubu. Např. u síťařských klubů je vhodné dělení na certifikační autoritu pro servery, pro uživatele a případně představenstvo klubu. Klub, který má zájem o zřízení certifikační autority si podá prostřednictvím svého předsedy žádost o certifikát od CA SU. Po ověření potřebných údajů (předsedové klubů a technický manažer SU se většinou znají osobně, případně se potkávají na Grémiu) je předsedovi klubu vydán certifikát. Předseda klubu je povinen privátní klíč bezpečně uchovávat - nenechávat ho nešifrovaný na jakémkoli paměťovém médiu, nenechávat jej na počítači s víceuživatelským přístupem a nedostatečným zabezpečením, nenechávat jej na počítači přístupném z internetu či vnitřní sítě. Předseda může privátní klíče k certifikátu dát někomu z představenstva. Pokud si klub vytvoří nějaké nižší certifikační autority, je povinen s privátními klíči těchto autorit nakládat stejným způsobem. Správci certifikačních autorit klubu jsou povinni pravidelně vyzvedávat a podepisovat nové žádosti o certifikát a podepisovat seznam zneplatněných certifikátů. Předseda pověřuje osobu, která bude kontrolovat totožnost žadatelů o certifikát a ověřovat informace uvedené v certifikátu. Tato osoba je považována za důvěryhodnou a je za informace uvedené v podepsaných certifikátech zodpovědná. Tato osoba se obvykle nazývá registrační autorita. Každý člen Studentské unie má právo podat žádost o certifikát u patřičné certifikační autority

27 příslušející k jeho klubu. Žádost o certifikát podá prostřednictvím webového rozhraní u zvolené certifikační autority. Následné obdrží ověřující, zda skutečně podal žádost o certifikát a v certifikátu uvedená ová adresa je jeho. Pak přijde k předsedou klubu pověřenému člověku, prokáže svou totožnost a pravdivost údajů obsažených v certifikátu, nyní je žádost označena jako platná. Teď je již na správci certifikační autority, kdy bude certifikát podepsán. Po podepsání certifikátu je držiteli certifikátu odeslán s oznámením o možnosti vyzvednutí podepsaného certifikátu. Všechny certifikáty vydané certifikačními autoritami jednotlivých klubů jsou evidovány CA SU. Webové stránky CASU umožňují download certifikátů jednotlivých certifikačních autorit, certifikačních řetězců (PKCS #7), veřejných klíčů jednotlivých certifikátů, aktuálního seznamu zneplatnětných certifikátů a ověření totožnosti držitele cetifikátu. V případě kompromitace privátního klíče, jeho ztrátě nebo změně údajů obsažených v certifikátu je držitel certifikátu povinen neprodleně podat prostřednictvím webového rozhraní žádost o zneplatnění certifikátu Testování certifikační autority Testování funkčnosti certifikační autority a její bezpečnosti nelze považovat za triviální úkol. Sestavil jsem proto pro betatestery pokyny, jakým způsobem by měli postupovat. 1. Přečíst si veškerou dokumentaci, která je k CA SU a jejímu používání k dispozici. Očekávám připomínky k dokumentaci projektu, FAQ, certifikační politice atd. 2. Přihlásit se do systému, prohlédnout si, co systém uvnitř umí, vyzkoušet, zda všechny nabízené možnosti správně fungují. Pak vyzkoušet nainstalovat do Vámi používaných prohlížečů certifikát certifikační autority SU a zkusit, zda při přístupu na se prohlížeč chová správně, tedy bez varování o špatném certifikátu otevře požadovanou stránku. 3. Prověřit správnou implementaci práv z pohledu vlastníka certifikační autority. Podejte žádost o novou certifikační autoritu (budete potřebovat binárku openssl), napsat a já žádost potvrdím a vystavím certifikát. Nyní si můžete hrát s certifikační autoritou, podávat žádosti, přijímat, odmítat, revokovat podřazené certifikáty, vyzvedávat žádosti k podepsání, podepisovat a uploadovat hotové certifikáty. Komu se tento bod zdá SLOŽITÝ, může ho přeskočit a více se zaměřit na bod 4. Při testování tohoto bodu je důležité především kontrolovat správnou implementaci práv v systému, tzn. abyste nesměli udělat víc, než je nutné, ale přitom abyste mohli dělat vše, co považujete za potřebné

28 4. Prověřit generování žádostí o certifikát pomocí dostupných prohlížečů (fungovat by měly MSIE, Opera, Mozilla). Podejte si u nějaké certifikační autority žádosti různých typů. Pošlete mi mejl (v případě, že nemáte zřízenu vlastní CA) o tom, že jste si podali nějaké žádosti a já vám žádost podepíšu. Pak zkuste spárovat obdržený certifikát s privátním klíčem uloženým v prohlížeči a poslat si mejl podepsaný získaným certifikátem, případně můžete zkusit i jiné věci, co vás napadnou Stručný přehled zdrojových kódů V hlavním adresáři certifikační autority nalezneme podadresáře crls a import. Do adresáře crls, jak již napovídá název se ukládají vygenerované CRL listy certifikačních autorit ve formátu id.crl, kde id je pořadové číslo certifikátu dané certifikační autority. Na tento CRL soubor je uveden odkaz ve všech certifikátech touto autoritou vydaných. V adresáři import je možné nalézt soubory týkající se importu a exportu uživatelských dat. Nyní se zaměříme na jednotlivé zdrojové soubory: asnutil.php - knihovna používaná pro parsování obsahu certifikátů cert.php - tento skript posílá na výstup data certifikátu uloženého v databázi, slouží tedy ke stažení/instalaci certifikátu certs.php - hlavní skript starající o zobrazování seznamu certifikátů a práci s nimi conf .php - skript pro aktivování žádosti o certifikát faq, kontakt, login, menu, news, odkazy, politika, pravidla.php - statická část stránek funcs.php - knihovna různých funkcí getreqs.php - připraví k downloadu žádosti, seznam revokovaných certifikátů, vytvoří tar.bz2 archiv a odešle na výstup goptions.php - nastavení systému, hesla pro přístup k MySQL index.php, header.php, footer.php - základ zobrazovacího systému stránek install.php - instalační skript, vytvoří databázi, tabulky, uživatele kluby.php - seznam klubů a práce s nimi openssl.cnf - konfigurační soubor speciálně pro podepisování certifikátů s definovanými extenzemi výsledných certifikátů podepis - podepisovací skript napsaný v bashi registrace.php - registrace nového uživatele a editace existujících req* - soubory týkající se podávání žádosti o certifikát v různých prohlížečích users.php - seznam a práce s uživateli zenrlinf.cab - soubor potřebný k podání žádosti v MSIE

29 3. Uživatelské rozhraní Jak již bylo řečeno, projekt Certifikační autorita SU je založen na webových technologiích, k jeho používání nám tedy bude stačit prakticky libovolný webový prohlížeč na libovolné platformě. Mezi podporované prohlížeče patří MSIE, Mozilla (Firefox) a Opera, ovšem funkce je ověřena např. i v Konqueroru. Jediný problém, který se při používání jiného prohlížeče může vyskytnout je při podávání žádosti o uživatelský certifikát pomocí webového prohlížeče, to totiž používá CryptoAPI daného prohlížeče. Nicméně i v tomto případě existuje možnost vytvoření žádosti pomocí openssl podobně jako u žádosti o serverový certifikát. Po vstupu na webové stránky uvidíme něco podobného následujícímu obrázku: Obrázek 3.1: Webové rozhraní Certifikační autority SU Na horním panelu můžeme vidět různé položky, které jsou veřejně přístupné, včetně stromu certifikačních autorit pod položkou Certifikáty. Napravo pak je tlačítko pro přihlášení do systému a registraci. Registrace je zatím přechodně dovolena během testování a také než budou plně funkční importy uživatelů z databází ostatních klubů. I když pravděpodobně bude funkce registrace zachována pro menší kluby, které nebudou mít databázi uživatelů v elektronické podobě

30 3.1 Menu uživatele Uživateli se po přihlášení do systému nejprve zobrazí stránka s certifikáty, nad kterými má nějaké právo. U běžného uživatele se jedná právě o jeho certifikáty a žádosti, které podal. Kromě tohoto se na pravé straně objeví menu, ve Obrázek 3.2: Menu uživatele kterém se uživateli nabízí další akce, které může provádět - úprava přihlašovacích údajů, zobrazení seznamu uživatelů, klubů a certifikátů. 3.2 Administrátor Administrátor po přihlášení vidí stejné menu jako uživatel, ovšem při zobrazování seznamů se mu nabízí u jednotlivých položek další akce. Podobně to funguje u uživatelů, kteří mají nad objektem nějaké právo. 3.3 Správa certifikátu Pokud vybereme z Menu uživatele položku Certifikáty, zobrazí se nám strom certifikátů. V tomto stromě si můžeme vybrat nějaký certifikát a kliknout na něj. Zobrazí se nám stručné informace o certifikátu, jeho stav a akce které můžeme s certifikátem provádět. Obrázek 3.3: Správa certifikátu

31 4. Závěrem Certifikační autorita SU je projektem pro studenty velmi přínosným. Pomůže jim seznámit se v praxi s možnostmi digitálního podpisu, ověření totožnosti a zajištění soukromí při komunikaci prostřednictvím internetu. Hlavním důvodem je úspora času, některé věci není třeba projednávat osobně, ale je potřeba mít jistotu, že komunikujeme se správným člověkem. Budeme si moci jednoznačně ověřit autenticitu protistrany s kterou hovoříme, zjistit zda daný psala skutečně ona, zda zaslaný soubor nebyl cestou změněn apod. Ovšem nezbytným krokem je mezi uživateli průbežně provádět osvětu na téma, co je to zabezpečení, certifikát a k čemuže to potřebují, neboť osvícených je stále žalostně málo