Certifikačná autorita

1. Certifikačná autorita Doc. Ing. Ladislav Hudec, CSc. 1

2. Certifikačná autorita - Úvod • Pre bežného zákazníka je napríklad automobilka továreň vyrábajúca automobily. Avšak pri podrobnejšom skúmaní zistíme, že se skladá z motorárni, lakovni, karosárni a ostatních prevádzok. Podobne je to aj s certifikačnou autoritou, ktorej základná schéma nasleduje. • Na začiatku je treba zdôrazniť, že mnohé časti certifikačnej autority znázornenej na obrázku nemusia reálne certifikačné autority vôbec mať. Reálne certifikačné autority budú mať tiečasti, ktoré budú odpovedaťnimiponúkaným službám, a pochopiteľne ich bezpečnostnej politike. 2

3. CA – Základná schéma 3

4. CA - aktíva • Certifikačná autorita má štyri najdôležitejšie aktíva, ktoré musí maximálne chrániť: • Súkromný kľúč CA je tým najväčším aktívom CA. Jeho ukradnutie je pre CA katastrofou, po ktorejužzrajme nemá zmysel obnovovaťčinnosť tejto CA. So súkromným kľúčom musí CA ochraňovať tiež sekvenciu vydaných čísiel certifikátov. Vydanie dvoch rôznych certifikátov s rovnakým sériovým číslom je opäť katastrofou, ktorú by CA asi neprežila. • Databázupoužívateľov musí CA taktiež chrániť, a to hneď z dvoch dôvodov: • CA nesmie vydať dvom rôznym osobám certifikát s rovnakým predmetom. • Databázapoužívateľov obsahuje osobné údaje používateľov (identifikácia preukazu totožnosti, rodné číslo apod.). • Archív súkromných šifrovacích kľúčovpoužívateľov. Pokiaľ CA túto službu poskytuje, tak nesmie dopustiť, aby sa súkromný kľúčpoužívateľa dostal do nepovolaných rúk. • Archív listín uložených na CA a archív vydaných certifikátov a CRL. V prípade certifikátov a CRL síce ide o verejné informácie, ale minimálne po celú dobu existencie CA musia byť tieto informácie dostupné pre verifikáciu dokumentov podpísaných certifikátmi vydanými touto CA. Ich strata by znamenala, že sa nedajú príslušné podpisy verifikovať. 4

5. CA - aktíva • Ďalej certifikačná autorita môže mať: • Registračné autority, kam prichádzajúžiadatelia o certifikáty. Žiadateľ môže na registračnú autoritu priniesť priamo žiadosť o certifikát, registračná autorita overí totožnosťžiadateľa, verifikuje žiadosť o certifikát a odovzdážiadosť (spravidla podpísanú RA) certifikačnej autorite. Certifikačná autorita overí údaje zožiadosti používateľa a údaje doplnené RA a vydá (či nevydá) príslušný certifikát. Vydaný certifikát môže byť vrátený na RA, kde je odovzdanýžiadateľovi. Iná stratégia spočíva v tom, že RA vydá iba jednorázové heslo na vydanie certifikátu a používateľžiadosť o certifikát pošle elektronicky cez OnLine RA. • OnLine RA slúžina prijímaniežiadostí elektronickou cestou. OnLine RA komunikuje protokolom CMC – Certificate Management Messages over CMS (Cryptographic Message Standard) (resp. CMP - Certificate Management Protocol). Žiadateľ môže cez OnLine RA žiadať o: • Vydanie nového certifikátu v dobe platnosti starého certifikátu žiadateľa. • O vydanie nového certifikátu na základe jednorázového hesla na vydanie certifikátu. • V prípade, že má platný podpisový certifikát, potom môže žiadať o ďalšie certifikáty. Žiadosti podpisuje platným certifikátom. (Teoreticky se môže žiadateľ autentizovať i šifrovacím certifikátom.) • O svoj súkromný šifrovací kľúč, ktorý má archivovaný na CA. • O odvolanie certifikátu. • O CRL alebo iný certifikát vydaný CA. • IVR alebo telefónny záznamník slúží na odvolávanie certifikátu inou cestou (telefónom). Používateľ se autentizuje jednorázovým heslom na odvolanie certifikátu. Odvolané certifikáty sa jednak radia do frontu certifikátovčakajúcich na odvolanie a jednak informácia o odvolaní certifikátu môže byť OnLine obratom k dispozícii pomocou OCSP servera. 5

6. CA - aktíva • Ďalej certifikačná autorita môže mať: • Adresárové služby ponúkajú informácie o používateľoch, ktoré si používatelia o sebe prajú publikovať, a najmä poskytujú vydané certifikáty a CRL. Dôležité je, že adresárov môže byť viacej. To je dôležité najmä pri výpadku príslušného servera CA. • DVCS server poskytuje protokolom DVCSP informácie o platnosti certifikátu, o platnosti listín a ďalej môže poskytovaťčasové pečiatky. Platnosť certifikátu poskytovaného DVCSP protokolom je zaujímavá najmäpri starších certifikátoch, kedy je už obťažné zisťovať, či certifikát v dobe podpisu nejakého staršieho dokumentu náhodou nebol odvolaný. CA má všetky tieto informácie k dispozícii a na jednoduchý dopyt dá odpoveď, ktorú by bolo inak pomerne komplikované zaobstarať. • V súčasnosti sú tiež k dispozíciišpeciálne servery poskytujúceibačasové pečiatky. Dôležité je, že TimeStamp server nemusí mať prístup do archívu CA, tj. môže byť umiestnený i mimo CA a teda dostupný i pri hypotetickom výpadku CA. • Poslednou súčasťou je zúčtovací systém, ktorého cieľom je za poskytnuté služby vystaviťpoužívateľovi faktúru. Mohlo by sa zdať, že to sem snáď ani nepatrí, ale nie je to až taký triviálny problém. Informácie o používateľochsú totiž dvojaké: • Informácienevyhnutné na vydanie samotného certifikátu, tj. zistené pri overení totožnosti používateľa (číslo občianskeho preukazu, ďalšie údaje z občianskeho preukazu apod.). Tieto informáciesú spolu s vydaným certifikátom uložené v databázepoužívateľov a ide o osobné údaje používateľov, ktoré podliehajú režimu podľa zákona na ochranu osobných údajov. • Informácienevyhnutné na vystavenie faktúry používateľovi. Tieto údaje sa tlačia na faktúru a sú tým pádom verejnými údajmi. Kto tieto údaje nechce zverejniť, tak zaplatí hotovosťou (peniaze sú anonymné). Tieto údaje sú vedené v zúčtovacej databáze. 6

7. CA - aktíva • Dôležité je, že oba údaje musia byť prijaté od používateľa na RA. RA potom na CA posiela oba údaje. Osobné údaje uloží CA do databázypoužívateľov a obchodné údaje odovzdá zúčtovaciemu subsytému. Dôležité je i to, že protokol CMC (resp. CMP), ktorým RA komunikujú s CA, musí mať možnosť (a tiež má možnosť) prenášať oba údaje. • Ďalšou otázkou je, ako CA pripojiť na Internet. Na nasledujúcom obrázku je jedna z takýchto eventualít. CA musí byť od Internetu bezpečne oddelená. Pretožepoužívatelia budú na CA pristupovať z Internetu, tak oddeľujúcim prvkom nemôže byťibabezpečnostná brána, ale musí ním byť Internetový FrontEnd. • Na Internetovom FrontEnde potom pobežia príslušné servery. Dôležité je, či môžu niektoré servery bežať niekde inde. To je dôležité napr. pri výpadku CA ako takej. Samostatne môže bežať server načasovépečiatky, záložné adresárové služby (LDAP a WWW) a prípadneaj OCSP server. • Na nasledujúcom obrázku je samostatne tiež nakreslená OnLine registračná autorita. To je však skorejiba hypotetická možnosť, ktorá by mala zmysel snáď v prípade, keby OnLine RA bolo viacero. V takom prípade môžu byť niektoré RA dislokované napr. na intranetoch významných zákazníkov CA. 7

8. CA – pripojenie na Internet 8

9. CA – Reťazec certifikátov • Reťazec certifikátov • Pokiaľ verifikujeme certifikát, potom musíme mať k dispozícii množinu certifikátov, z ktorejje možné vybraťreťazec, až ku koreňovému certifikátu. Všetky certifikáty do zostavovanéhoreťazca môžeme získať z lubovoľných zdrojov vrátane adresárových služieb s výnimkou koreňového certifikátu – ten musím maťdopredu získaný bezpečnou cestou, pretože ten je podpísaný samým sebou a nedá sa overiť prostredníctvom elektronického podpisu. Preto môže byť veľmiľahko podvrhnutý. • Pokiaľ mi niektopošle množinu certifikátovaj s koreňovými certifikátmi, tak tieto koreňové certifikáty môžem použiťibanaľahšie vyhľadaniereťazca certifikátov. Avšak vždy sa musí skontrolovať, či príslušný koreňový certifikát je zhodný s niektorým koreňovým certifikátom získaným inou – bezpečnou cestou. • Ak uvažujeme, že jednotlivé CA môžu maťaj obnovené certifikáty, potomreťazec certifikátov bez rozšírenia certifikátu „Identifikácia kľúča CA“ je možné zostaviťiba veľmi zle. • V neposlednom rade nesmieme zabudnúť na bezpečnostnú politiku. Je treba, aby raťazec kvalifikátorov bezpečnostných politík (OID bezpečnostných politík) siahal tiež až ku koreňovému certifikátu. (Microsoft certifikáty s týmito rozšíreniami nazýva kvalifikovanými certifikátmi a vo Windows XP túto kontrolu podporuje). • Ďalej je nevyhnutné pri jednotlivých certifikátochskontrolovať, či nie sú odvolané (nie sú na zozname CRL). • Za dôveryhodný certifikát nie je nevyhnutné vždy prehlásiť až koreňový certifikát. Pokiaľ sa za dôveryhodný certifikát prehlási niekterý z certifikátov uprostred reťazca medzi certifikátom používateľa a koreňovým certifikátom, potom sa verifikáciavykonáva iba k tomuto dôveryhodnému certifikátu a celé overovanie sa tým výrazne zrýchli. 9

10. CA – Reťazec certifikátov 10

11. CA – Reťazec certifikátov • Pre bezpečnosť počítača je zásadnýzoznam dôveryhodných certifikátov, ktorý je inštalovaný na počítači. Pokiaľ sa na tento zoznam podarí podvrhnúť napr. certifikát niektorej z testovacích certifikačných autorít, tak máme o nepríjemnosti postarané. Pritom staršie verzie prehliadačov boli distribuované s celýmradom certifikátov certifikačných autorít, o ktorých sme nikdy nemohli vedieťči sú dôveryhodné. A tak prvou operáciou po instalácii prehliadača bolo zrušenie týchto certifikátov a vloženie dôveryhodných certifikátov (dôveryhodných certifikačných autorít). • Windows 2000 zavádza tzv. CTL (Certificate Trusted List) tj. zoznam dôveryhodných certifikátov, ktorý je podpísaný správcom firemnej siete. Windows 2000 potom akceptujú ako dôveryhodné iba certifikáty z tohto zoznamu. 11

12. CA – Krížová certifikácia • Krížová certifikácia • Doposiaľ sme predpokladali, že certifikačné autority tvoria stromovúštruktúru. Avšak je možná i iná štruktúra – krížová. • Dve certifikačné autority, ktoré nie sú zaradené do tej istej stromovejštruktúry, si môžu vzájomne podpísať svoje certifikáty – vykonať krížovú certifikáciu. Pre úplnosť je treba dodať, že krížovo sa môžu certifikovať i CA patriace do spoločného stromu – to má však význam, keď je strom príliš košatý a CA ležia na veľmi vzdialených vetviach stromu; potom je možné krížovou certifikáciou ich vzdialenosť zmenšiť. • Na nasledujúcom obrázku sú dve certifikačné autority CA1 a CA2. Používateľ A bez problémov komunikuje s používateľom B, pretože používateľ A uznáva CA1 ako dôveryhodnú. V prípade, že používateľ A obdrží certifikát používateľa B, tak si zostaví raťazec certifikátov z certifikátu použíateľa B a certifikátu CA1. CA1 je koreňová certifikačná autorita, ktorejpoužívateľ A dôveruje. Tj. používatelia A a B spoločne dôverujú certifikačnej autorite CA1. • V prípade, že ale chce s použíateľom B komunikovaťpoužívateľ C, tak je tomu už inak. Používateľ C si zostaví reťazec certifikátovzačínajúcí certifikátom používateľa B – ten ale končí vždy na CA1, ktorejpoužívateľ C nedôveruje, pretože junepozná. 12

13. CA – Krížová certifikácia, CA1 nie je krížovo certifikovaná s CA2 13

14. CA – Krížová certifikácia • Riešením je, že CA1 si okrem svojho pôvodného koreňového certifikátu nechá vydaťďalší certifikát, teraz certifikačnou autoritou CA2 (viď nasledujúci obrázok). CA1 tak má svoj koreňový certifikát a naviacďalší krížový certifikát, ktorý je vydaný CA2. • V prípade, že používateľ C chce komunikovať s používateľom B, tak B mu pošle množinu certifikátov obsahujúcu: • Certifikát B • Certifikát CA1 podpísaný CA1 (koreňový certifikát CA1) • Certifikát CA1 podpísaný CA2 • (Certifikát CA2 podpísaný CA2 by mal používateľ C mať, pretože mu sám dôveruje). • Používateľ si nájde reťazec, ktorému môže dôverovať. Jedná sao nasledujúciraťazec zakončený pre neho dôveryhodnou CA2: B -> CA1 podpísaný CA2 -> CA2 podpísaný CA2. Tak sa stane certifikát používateľa B dôveryhodným i prepoužívateľa C, ktorý dôveruje CA2. • Je zaujímavé, že rovnakú množinu certifikátov môže od B obdržať i A, ten si ale vybere z tejto množiny kratší reťazec: B -> CA1 podpísaný CA1. • Touto krížovou certifikáciou sa CA1 a jej používatelia stali dôveryhodní pre CA2 a jej používateľov. Nie je tomu však naopak. 14

15. CA – Krížová certifikácia, CA2 krížovo certifikovala CA1 15

16. CA – Krížová certifikácia, obojstranná krížová certifikácia CA1 a CA2 • Aby tento vzťah bol obojstranný, tak je nevyhnutné, aby i CA2 si nechala vydať certifikát u CA1, podľa obrázku nižšie. • Výsledkom je, že máme štyri certifikáty: • CA1 podpísaný CA1 • CA2 podpísaný CA2 • CA1 podpísaný CA2 • CA2 podpísaný CA1. 16

17. CA – Obnovenie certifikátu CA • Obnovenie certifikátu CA • So skutočnosťou, že je nevyhnutné obnovovať i certifikáty samotnej certifikačnej autority, sme sauž oboznámili (vypršanie platnosti certifikátu CA). Nový certifikát CA je nevyhnutné vydať s takým predstihom, aby súkromným kľúčompatriacemu k starému certifikátu neboli vydané certifikáty, ktorých platnosť skončí neskoršie než platnosť kľúča, ktorým boli podpísané. • Lenže v dobe, kedy platia oba certifikáty CA, starý i nový, tak niektorípoužívatelia majú podpísané svoje certifikáty starým a niektorípoužívatelia novým súkromným kľúčom CA. Je to vlastne obdoba krížovej certifikácie. • Aby používatelia s certifikátom podpísaným starým kľúčom dôverovali certifikátom podpísaným novým kľúčom, tak je ideálneurobiť krížovú certifikáciu. Opäť získame štyri certifikáty: • Nový • Starý • Nový podpísaný starým • Starý podpísaný novým. • Druhé dva by mali mať omedzenú platnosť na dobu, po ktorú sa prekrýva platnosť dvoch prvých certifikátov. Pretože PKI nedoporučuje používať rozšírenie „Doba platnosti súkromného kľúča“, ktoré je pre tieto účely určené, tak sa to musí urobiť pomocou doby platnosti certifikátu. • Podpísanie nového certifikátu CA starým súkromným kľúčom CA je posledná akcia, ktorú by sme mali so starým súkromným kľúčom urobiť. Na to by mal byť zlikvidovaný, lebo je zbytočné ochraňovať to, čo je už nepotrebné. 17

18. CA – Certifikačné politiky • Certifikačné politiky • Už skorej bolo ukázané, že pri verifikácii certifikátov sa neoveruje iba elektronický podpis certifikátu, ale tiež certifikačná politika. Tá by mala byť v celom reťazci certifikátovrovnaká. V zložitejšom prípade môže byť pomocou rozšírenia certifikátu Policy Mapping vykonaná transformácia politiky podriadenej CA na odpovedajúcu politiku nadradenej CA. Tento zložitejší prípad je aktuálnym napr. v prípade krížovej certifikácie. • Certifikačná politika je dokument (text), z ktorého by malo byť jasné pre aké aplikácie je vydaný certifikát určený. Ďalej by malo byť v certifikačnej politike opísané aký je vzťah medzi používateľom a údajmi uvedenými v certifikáte, tj. ako a akým spôsobom overuje certifikačná autorita totožnosťžiadateľa o certifikát. V certifikáte môže byť uvedené viacero certifikačných politík. • Certifikačná autorita si pre jednotlivé svoje certifikačné politiky nechá priradiť identifikátory objektov. V rozšírení certifikátu „Certifikačné politiky“ sa potom uvádzajú tieto identifikátory objektov v položkepolicyIdentifier. • Otázkou je či má praktický zmysel v jednej firme vydávať certifikáty s rôznymi certifikačnými politikami. Príklad je asi nasledujúcí: V našej firme vydáme všetkým zamestnancom certifikát, aby mohli komunikovať bezpečnou elektronickou poštou. Pre tieto certifikáty použijeme „všeobecnú certifikačnú politiku“. Avšak pre zamestnancov, ktorí budú podpisovať finančné transakcie vydáme „finančnú certifikačnú politiku“ a do ich certifikátov budeme vkladať identifikátor objektu tejto „finančnej certifikačnej politiky“. Niekterí zamestnanci tak môžu mať vo svojom certifikáte identifikátory objektov oboch politík. Vo finančných aplikáciách potom zaistíme, aby fungovali iba certifikáty splňujúce „finančnú certifikačnú politiku“. 18

19. CA – Certifikačné politiky • Certifikačné politiky • Rozšírenie certifikátu „Certifikačné politiky“ môže byť označené ako kritické. V tomto prípade pre príznak kritičnosti rozšírenia certifikátu platí dôležitá výnimka. Totiž pokiaľ je rozšírenie „Certifikačné politiky“ označené ako kritické, potom použitie takto označeného certifikátu je obmedzenéiba na aplikácie vyhovujúceaspoň jednejz certifikačných politík uvedených v certifikáte. Pokiaľ vyviniem aplikáciu A pre svojich zákazníkov a vydám im firemné certifikáty, potom sa môžem brániť tomu, aby zákazník podpísal nejaký dokument menom firmy tým, že vydám certifikačnú politiku pre aplikáciu A a identifikátor objektu tejto certifikačnej politiky uvediem v rozšírení „Certifikačné politiky“, ktoré označím ako kritické. • Rozšírenie „Certifikačné politky“ môže obsahovať parametry (kvalifikátory): • Hypertextový odkaz (URI) na Certifikačnúvykonávaciu smernicu (Certification Practice Statement - CPS). • Poznámku označovanú tiež ako „prehlásenie vystaviteľa“ alebo „používateľské oznámenie“ explicitText, ktorá v najviac 200 znakochjasne charakterizuje účel použitia certifikátu. • CPS je zrejme najdôležitejší dokument CA. V  ňomsú detailne uvedené pravidlá a praktiky vykonávané zamestnancami CA pri vydávaní certifikátu. Jedná se o dokument, ktorý musí byť dostupný klientom CA (je naň hypertextový odkaz v certifikáte). • CPS nevytvárameiba preCA, ale vytvárajú si ju i firmy, ktoré si nechávajú vystaviť certifikáty od externých (verejných) certifikačných autorít. Každá firma využívajúca PKI by mala mať vytvorenú CPS. Netreba sa báť vytvorenia tohto dokumentu. Využijeme RFC-3280, ktoré je kuchárkou na tvorbu CPS. 19

20. CA – Testovacie certifikačné autority • Testovacie certifikačné autority • Pre testovacie účely súčasto prevádzkovanéCA, ktoré nijako nepreverujú totožnosťžiadateľa. Zašlete na takútoCAžiadosť a ona vám automaticky vydá certifikát. Takáto CA garantuje jedinú vec – a to, že nevydá dva rôzne certifikáty s rovnakým sériovým číslom. Pri takto vystavených certifikátoch je slušné, aby v „prehlásení vystaviteľa“ bolo jasne uvedené, žeide o testovacie certifikáty. • Pokiaľ byste chceli testovací certifikát použiťna praktickú komunikáciu, potom sa jedná o certifikát ako každý iný – iba neprebehlo overenie totožnosti žiadateľa. Takže si overenie totožnosti musíte vykonať pri použití certifikátu sami. • Napr. šéf bandy lupičov si nechá vystaviť certifikát na testovacejCA. Distribuuje ho tak, že všetkým svojim podozrivým banditom rozošle týmto certifikátom elektronicky podpísaný mail s bezvýznamným textom obsahujúcím napr. pozdrav k Vianociam. • Jednotliví lupiči sapotom telefonicky spojujú so svojim šéfom a overují si jeho totožnosť napr. na nejaký spoločný zážitok: „Pamätáš sa šéf, ako sme boli minulý týždeň na ťahu … Koľko tam bolo blondýnok?“ Pokiaľ šéf správne odpovie, že tam nebola žiadna blondýnka, tak lupičskutočne vie, že hovorí so svojim šéfom. Ostáva už iba otázka: „Zarecituj mi odtlačok (thumbprint, kontrolný súčet) certifikátu, ktorýmsi podpísal svoj mail. Pokiaľ napr. odpovie: „D96F 563E E0EC 3570 94BB DF05 75D6 300E 563E E0EC“, tak si lupič zobrazí podrobnosti o inkriminovanom certifikáte a podíva sači položka „Odtlačok“ skutočne obsahuje šéfom zarecitovaný kontrolný súčet. Pokiaľáno, potom lupič zafungoval ako registračná autorita a vie, že certifikát môže použiťnazašifrovanie svojich pravidelných hlásení šéfovi. 20

21. CA – Vytvorenie žiadosti o certifikát • Vytvorenie žiadosti o certifikát • Minule sme opísali formáty žiadosti o certifikát tvaru PKCS#10 a CRMF. Tieto žiadosti môže žiadateľ vytvoriť nejakým svojim programom. Také programy sú dodávané napr. s webovými servermi. Ale bežný používateľ, ktorý si chce vystavit certifikát spravidla nemá tieto programy k dispozicii. Má k dispozícii iba bežný prehliadač. • Otázkou je ako vytvoriť bežným prehliadačomžiadost o certifikát. V praxi sa stretávame s dvomispôsobmi generovaniažiadosti o certifikát v prehliadači: • Využitím programového komponentu, ktorý je súčasťou webovej stránky. • Použitím špeciálnej značky, ktorá rozširuje jazyk HTML o možnosť generovaniažiadosti o certifikát. • Žiadosť formátu SPK • Netscape definuje zvláštnu HTML značku <keygen>slúžiacuna vygenerovanie dvojice verejný/súkromný kľúč. Odoslanie tohto formuláraspôsobí: • Vygenerovanie dvojice kľúčov verejný/súkromný kľúč • Verejný kľúč podpíše vygenerovaným súkromným kľúčom • Base64 kódovaný verejný kľúč vrátane jeho podpisu vloží do obsahu poľa HTML stránky, ktorá obsahuje značku <keygen>. • Táto žiadosť o certifikát se označuje akožiadosť formátu SPK. Žiadosť formátu SPK je neštandardný typ žiadosti o certifikát, pretože neobsahuje elektronický podpis celejžiadosti, ale iba podpis verejného kľúča. Normy PKI tento formát žiadosti v podstate nepoznajú, ale CAhočasto podporujú. • Ako príklady generovaniažiadostí formátu SPK („žiadostí pre Netscape“) môžu opäť slúžiťžiadosti o vydanie certifikátu vystavené na www.netscape.com 21

22. CA – Aké typy certifikátov budeme používať • Aké typy certifikátov budeme používať • Z technického hľadiska môžeme mať jeden certifikát na všetko. Na podpisovanie, na autentizáciu i na šifrovanie (obálkovanie). Ako sme si ukázali skorej tak nie jecelkom ideálne mať spoločný certifikát na podpis a na autentizáciu (autentizácia je i napr. prihlásenie do Windows 2000 atp.). • Iný problém je so šifrovacími certifikátmi. Pokiaľ totižstratím súkromný kľúč, potom nie som schopný dešifrovať staré správy zašifrované príslušným verejným kľúčom. Je teda praktické archivovať súkromné šifrovacie kľúče. Túto službu môže poskytovaťaj CA. • Naopak v prípade elektronického podpisu starý súkromný kľúč zlikvidujemakonáhleho už nepotrebujem. Staré elektronické podpisy sa verifikujú pomocou verejného kľúča a ten je v certifikáte. A certifikát, ten musí byť archivovaný minimálne na CA. Súkromný kľúčna elektronický podpis nikdy nedávam z ruky – ani certifikačnej autorite! • Výsledkom sútri aktuálne certifikáty: • Na elektronický podpis. Príslušný súkromný kľúč budem mať najskorej na čipovej karte. • Na autentizáciu. Príslušný súkromný kľúč budem mať najskorejtiežčipovej karte. • Na šifrovanie (presnejšiena dešifrovanie elektronických obálok) ho budem mať na disku a zálohovaný v nejakom doveryhodnomúložisku. • Inými kritériami je dĺžka kľúča. Kvalifikované certifikáty môžu mať v rozšírení špecifikovanú hodnotu transakcie, do ktorej je elektronický podpis verifikovaný týmto certifikátom poistený atď. 22

23. CA – Bezpečnostné požiadavky na kryptografické moduly • Bezpečnostné požiadavky na kryptografické moduly (podľa FIPS-140-2). V súčasnosti je v schvaľovacom pokračovaní FIPS-140-3. • Bezpečnostné požiadavky, ktoré musia splňovať kryptografické moduly, pokrývajú oblasti: • Špecifikácia kryptografického modulu • Porty a interfejsy modulu • Role, služby a autentifikácia • Stavový model • Prevádzková bezpečnosť • Správa šifrovacích kľúčov 23

24. CA – Bezpečnostné požiadavky na kryptografické moduly 24 EFP - Environmental Failure Protection, EFT - Environmental Failure Testing

25. CA – Bezpečnostné požiadavky na kryptografické moduly 25

26. CA – Bezpečnostné požiadavky na kryptografické moduly • Špecifikácia kryptografického modulu. • Kryptografický modul môže byť zostavený z hardvéru, softvéru a firmvéru alebo ich kombinácie, ktorá implementuje kryptografické funkcie alebo procesy, vrátane kryptografických algoritmov a voliteľne generovanie kľúča, a modul je uložený v rámci definovaných hraníc. • Pre bezpečnostné úrovne 1 a 2 môže bezpečnostná politika kryptografického modulu špecifikovať, kedy sa nachádza kryptografický modul v odsúhlasenom režime prevádzky. • Pre bezpečnostné úrovne 3 a 4 musí kryptografický modul indikovať, kedy je vybratý odsúhlasený režim prevádzky. Kryptografické hranice modulu musia pozostávať z explicitne definovanej zóny, ktorá určuje fyzické hranice kryptografického modulu. • Porty a interfejsy kryptografického modulu. • Kryptografický modul musí obmedziť všetok tok informácií a body fyzického prístupu na fyzické porty a logické interfejsy, ktoré definujú všetky vstupné a výstupné body do a z modulu. • Interfejsy kryptografického modulu musia byť logicky odlíšené od ostatných aj keď môžu využívať jeden spoločný fyzický port (napr. vstupné údaje môžu vstupovať a výstupné údaje môžu vystupovať prostredníctvom toho istého portu) alebo môžu byť distribuované cez jeden alebo viacero fyzických portov (napr. vstupné údaje môžu vstupovať prostredníctvom dvoch portov, sériovým aj paralelným). • Interfejs aplikačného programu softvérového komponentu kryptografického modulu môže byť definovaný ako jeden alebo viac logických interfejsov. 26

27. CA – Bezpečnostné požiadavky na kryptografické moduly • Role, služby a autentifikácia. • Kryptografický modul musí podporovať autorizované role pre operátorov a odpovedajúce služby v rámci každej roli. Ak kryptografický modul podporuje súčasných oprátorov, potom modul musí interne udržiavať oddelenie rolí predpokladané role každého operátora a odpovedajúce služby. • Operátor nemusí pracovať v autorizovanej role v prípade, že vykonáva služby, pri ktorých nie sú modifikované, zvrejnené alebo nahradené kryptografické kľúče a kritické bezpečnostné parametre (napríklad show status, self-test a iné služby, ktoré nemajú vplyv ma bezpečnosť modulu). • Autentifikačný mechanizmus môže byť požadovaný v rámci kryptografického modulu na autentifikáciu operátora, ktorý pristupuje k modulu, a na verifikáciu, že operátor je autorizovaný zastávať požadovanú rolu a vykonávať služby v rámci roli. Kryptografický modul musí podporovať autorizované role používateľa a kryptomanažéra. • Ak kryptografický modul umožňuje operátorom vykonávať službu údržby, potom modul musí podporovať autorizovanú rolu údržby (všetky tajomstvá v otvorenom tvare, privátne kľúče a nechránené kritické bezpečnostné parametre musia byť resetované-vynulované pri vstupe do tejto role). • Kryptografický modul musí poskytovať operátorm služby ukáž stav (show status), vykonaj self-test a vykonaj odsúhlasenú bezpečnostnú funkciu. V závislosti na bezpečnostnej úrovni musí kryptografický modul podporovať aspoň jeden z týchto mechanizmov riadenia prístupu k modulu a to autentifikáciu založenú na roli a autentifikáciu založenú na identite. 27

28. CA – Bezpečnostné požiadavky na kryptografické moduly • Stavový model. • Prevádzka kryptografického modulu musí byť špecifikovaná použitím stavového modelu (alebo ekvivalentného modelu) reprezentovaného diagramom stavových prechodov a tabuľkou stavov. • Diagram prechodu stavov a tabuľka stavov zahrňuje všetky prevádzkové a chybové stavy kryptografického modulu, odpovedajúce prechody z jedného stavu do druhého, vstupnú udalosť spôsobujúcu prechod z daného stavu do nasledujúceho a výstupnú udalosť rezultujúcu z prechodu medzi stavmi. • Kryptografický modul musí zahrňovať stavy zapnutia a vypnutia napájacieho napätia, stavy kryptomanažéra, stavy vkladania kľúčov a kritických bezpečnostných parametrov, stavy používateľov, stavy samočinného testovania a chybové stavy. Modul môže zahrňovať aj ďalšie stavy ako napríklad stavy bypass a stavy údržby. • Fyzická bezpečnosť. • Kryptografický modul musí uplatňovať mechanizmy fyzickej ochrany, aby sa obmedzil neautorizovaný fyzický prístup k obsahu modulu a znemožnilo neautorizované použitie alebo modifikácia inštalovaného modulu (vrátane náhrady celého modulu). Všetky hardvérové, softvérové, firmvérové a údajové komponenty musia byť chránené v rámci kryptografických hraníc. • Požiadavky na fyzickú bezpečnosť sú špecifikované pre tri definované uspôsobenia kryptografického modulu a to jednočipové kryptografické moduly, viacčipovývnorený kryptografický modul (karta do PC, adaptér) a viacčipovýsamostatný kryptografický modul (samostané zariadenia napr. šifrovací smerovač). Sumárne požiadavky na fyzickú bezpečnosť sú v nasledujúcej tabuľke. 28

29. CA – Bezpečnostné požiadavky na kryptografické moduly 29

30. CA – Bezpečnostné požiadavky na kryptografické moduly • Prevádzkové prostredie. • Prevádzkové prostredie kryptografického modulu zodpovedá spravovaniu softvéru, firmvéru a/alebo hardvérových komponentov potrebných k činnosti modulu. • Prevádzkové prostredie môže byť nemodifikovateľné (t.j. firmvér obsiahnutý v ROM alebo softvér na počítači bez vstupných a výstupných zariadení) alebo modifikovateľný (t.j. firmvér obsiahnutý v RAM alebo softvér vykonávaný na univerzálnom počítači). • Operačný systém je dôležitým komponentom prevádzkového prostredia kryptografického modulu. Ak v prevádzkovanom prostredí kryptografický modul využíva operačný systém, potom sa pre bezpečnostné úrovne 2, 3 a 4 vyžaduje PP (Protection Profile - ochranný profil) a príslušná úroveň záruk. • Správa šifrovacích kľúčov. • Bezpečnostné požiadavky pre správu kryptografických kľúčov obsahuje celý životný cyklus kľúčov a ich komponentov a kritických bezpečnostných parametrov používaných kryptografickým modulom. • Správa kľúčov zahrňuje generovanie náhodných čísel a kľúčov, zriadenie kľúčov, distribúciu kľúčov, vkladanie a vyberanie kľúčov, uloženie kľúčov a resetovanie kľúčov. Kryptografický modul môže tiež využívať mechanizmus správy kľúčov ďalších kryptografických modulov. Tajné kľúče, privátne kľúče a kritické bezpečnostné parametre musia byť chránené v kryptografickom module pred neautorizovaným zverejnením, modifikáciou a substitúciou. Verejné kľúče musia byť chránené v kryptografickom module pred neautorizovanou modifikáciou a substitúciou. 30

31. CA – Bezpečnostné požiadavky na kryptografické moduly • EMI/EMC. • Kryptografické moduly musia splňovať požiadavky pre EMI a EMC. Dokumentácia musí dokladovať kompatibilitu modulov s týmito požiadavkami. • Samočinné testovanie. • Kryptografický modul musí vykonať samočinný test pri zapnutí napájacieho napätia a podmienený samočinný test, aby sa zaistilo, že modul funguje správne. Podmienečný samočinný test sa musí vykonať, keď sa vyvolá príslušná bezpečnostná funkcia alebo operácia (pri ktorej je požadovaný samočinný test). • Ak samočinný test kryptografického modulu indikuje poruchu, musí modul prejsť do chybového stavu a prostredníctvom stavového interfejsu musí indikovať chybu. Kryptografický modul nesmie vykonávaťžiadne kryptografické operácie, pokiaľ sa nachádza a v chybovom stave, a všetky výstupné údaje na výstupnom údajovom interfejse musia byť zablokované. • Záruky návrhu. • Záruky návrhu zodpovedajú použitiu najlepšej praxe výrobcom/dodávateľom kryptografického modulu počas návrhu, rozmiestnenia a prevádzky modulu, poskytujúc záruku, že modul je primerane testovaný, konfigurovaný, dodaný, inštalovaný a vyvinutý a je poskytnutý vhodný návod pre operátora. Bezpečnostné požiadavky sú špecifikované pre manažment konfigurácie, dodávku a prevádzku, vývoj a návody. 31

32. ĎAKUJEM ZA POZORNOSŤ 32