certifikačná autorita

Certifikačná autorita

Doc. Ing. Ladislav Hudec, CSc.

1

Certifikačná autorita - ÚvodCertifikač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ť nimi ponúkaným službám, a pochopiteľne ich bezpečnostnej politike.

2

CCAA – – ZZáákladnkladnáá sch schéémama

3

Žiadatelia

Používatelia

Registračné autority

Používateľ posielajúci žiadosť cez sieť

Registračná autorita OnLine

Certifikačná autorita

Adresárové služby

(certifikáty a CRL)

LDAP server

WWW server

IVR pre odvolávanie certifikátov OCSP server

Archív súkromných šifrovacích kľúčov

CMC server

Archív listín, certifikátov a

CRL DVCS server

Time stamp server

Zúčtovanie (billing)

Súkromný kľúč CA

Databáza používateľov

používateľov

CA - aktívaCA - aktíva

Certifikačná autorita má štyri najdôležitejšie aktíva, ktoré musí maximálne chrániť:o Súkromný kľúč CA je tým najväčším aktívom CA. Jeho ukradnutie je pre CA

katastrofou, po ktorej už zrejme nemá zmysel obnovovať činnosť tejto CA. So súkromným kľúčom musí CA ochraňovať tiež sekvenciu vydaných čísel certifikátov. Vydanie dvoch rôznych certifikátov s rovnakým sériovým číslom je opäť katastrofou, ktorú by CA asi neprežila.

o Databázu použí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áza používateľov obsahuje osobné údaje používateľov (identifikácia preukazu

totožnosti, rodné číslo apod.).o Archív súkromných šifrovacích kľúčov použí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.

o 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


Ďalej certifikačná autorita môže mať:o 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.

o OnLine RA slúži na 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.

o 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


Ďalej certifikačná autorita môže mať:o 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.

o 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ť.

o V súčasnosti sú tiež k dispozícii špeciálne servery poskytujúce iba č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ľoch sú totiž dvojaké:

o Informácie nevyhnutné 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ácie sú spolu s vydaným certifikátom uložené v databáze používateľov a ide o osobné údaje používateľov, ktoré podliehajú režimu podľa zákona na ochranu osobných údajov.

o Informácie nevyhnutné 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


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ázy použí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že používatelia budú na CA pristupovať z Internetu, tak oddeľujúcim prvkom nemôže byť iba bezpeč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ípadne aj OCSP server.

Na nasledujúcom obrázku je samostatne tiež nakreslená OnLine registračná autorita. To je však skorej iba 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

CA – pripojenie na InternetCA – pripojenie na Internet

8

Internet

FrontEnd (LDAP, WWW, OCSP,DVCS)

Záložný LDAP a WWW


Time stamp servery


OnLine

CMC server

Intranet CA Certifikačná

autorita

Používateľ posielajúci žiadosti cez sieť

CMC

CMC

CMC

CA – Reťazec certifikátovCA – Reťazec certifikátov

Reťazec certifikátovo Pokiaľ verifikujeme certifikát, potom musíme mať k dispozícii množinu certifikátov, z

ktorej je možné vybrať reťazec, až ku koreňovému certifikátu. Všetky certifikáty do zostavovaného reť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ý.

o Pokiaľ mi niekto pošle množinu certifikátov aj s koreňovými certifikátmi, tak tieto koreňové certifikáty môžem použiť iba na ľahšie vyhľadanie reť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.

o 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).

o Ďalej je nevyhnutné pri jednotlivých certifikátoch skontrolovať, či nie sú odvolané (nie sú na zozname CRL).

o 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ácia vykonáva iba k tomuto dôveryhodnému certifikátu a celé overovanie sa tým výrazne zrýchli.

9


10

Verzia Sériové číslo Vydavateľ Platnosť Predmet

Certifikát používateľa

Certifikát CA1

Certifikát CA2

Certifikát CA-n

Koreňový certifikát

Verejný kľúč Rozšírenie: ID kľúča CA ID predmetu Použitie kľúča CA politika - OID

Zákl.obmedz. - cA = 0 Distibučné URI ...

Verzia Sériové číslo Vydavateľ Platnosť Predmet Verejný kľúč


ID predmetu CA politika - OID Policy mapp. - OID1 - OID2

- cA = 1 - path = 0 Distibučné URI ...


- cA = 1 - path = 1 Distibučné URI ...



- cA = 1 - path = (n-1) Distibučné URI ...


ID predmetu CA politika - OID

- cA = 1 - path = n Distibučné URI ...

Podpis CA1 Podpis CA2 Podpis CA3 Podpis koreňom

Podpis koreňom

V E R I F I K Á C I A

= = = =

Rozšírenie: Rozšírenie: Rozšírenie: Rozšírenie: ID kľúča CA ID kľúča CA ID kľúča CA

Použitie kľúča Použitie kľúča Použitie kľúča Použitie kľúča

Zákl.obmedz. Zákl.obmedz. Zákl.obmedz. Zákl.obmedz.





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ým radom 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

CA – Krížová certifikáciaCA – Krížová certifikácia

Krížová certifikáciao Doposiaľ sme predpokladali, že certifikačné autority tvoria stromovú štruktúru. Avšak je

možná i iná štruktúra – krížová.o 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ť.

o 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, ktorej používateľ A dôveruje. Tj. používatelia A a B spoločne dôverujú certifikačnej autorite CA1.

o V prípade, že ale chce s používateľom B komunikovať používateľ C, tak je tomu už inak. Používateľ C si zostaví reťazec certifikátov začínajúcí certifikátom používateľa B – ten ale končí vždy na CA1, ktorej používateľ C nedôveruje, pretože ju nepozná.

12

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

13

CA1

cert CA1

Podpis CA1

CA2

cert CA2

Podpis CA2

Používateľ A Používateľ B Používateľ C

Používateľ A

Podpis CA1

Používateľ B

Podpis CA1

Používateľl C

Podpis CA2

CA – Krížová certifikáciaCA – 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:

o Certifikát Bo Certifikát CA1 podpísaný CA1 (koreňový certifikát CA1)o Certifikát CA1 podpísaný CA2o (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á sa o nasledujúci rať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 pre použí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 vyberie 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

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

15

CA1 CA1

Podpis CA1

CA2

Podpis CA2

CA1

Podpis CA2

CA2 CA2

Podpis CA2


CA – Krížová certifikácia, obojstranná krížová certifikácia CA1 a CA2CA – 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:o CA1 podpísaný CA1o CA2 podpísaný CA2o CA1 podpísaný CA2o CA2 podpísaný CA1.

16

CA1 CA1

Podpis CA1

CA2

Podpis CA2

CA1

Podpis CA2

CA2 CA2

Podpis CA2


CA1

Podpis CA1

CA2

Podpis CA1

CA – Obnovenie certifikátu CACA – Obnovenie certifikátu CA

Obnovenie certifikátu CAo So skutočnosťou, že je nevyhnutné obnovovať i certifikáty samotnej certifikačnej

autority, sme sa už oboznámili (vypršanie platnosti certifikátu CA). Nový certifikát CA je nevyhnutné vydať s takým predstihom, aby súkromným kľúčom patriacemu k starému certifikátu neboli vydané certifikáty, ktorých platnosť skončí neskoršie než platnosť kľúča, ktorým boli podpísané.

o 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.

o 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álne urobiť krížovú certifikáciu. Opäť získame štyri certifikáty:

Nový Starý Nový podpísaný starým Starý podpísaný novým.

o 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.

o 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

CA – Certifikačné politikyCA – Certifikačné politiky

Certifikačné politikyo 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átov rovnaká. 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.

o 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.

o 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žke policyIdentifier.

o 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

CA – Certifikačné politikyCA – Certifikačné politiky

Certifikačné politikyo 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úce aspoň jednej z 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é.

o Rozšírenie „Certifikačné politiky“ 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 znakoch jasne charakterizuje účel použitia certifikátu.o CPS je zrejme najdôležitejší dokument CA. V ňom sú 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).

o CPS nevytvárame iba pre CA, 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

CA – Testovacie certifikačné autorityCA – Testovacie certifikačné autority

Testovacie certifikačné autorityo Pre testovacie účely sú často prevádzkované CA, ktoré nijako nepreverujú totožnosť

žiadateľa. Zašlete na takúto CA ž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é, že ide o testovacie certifikáty.

o Pokiaľ by ste 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.

o Napr. šéf bandy lupičov si nechá vystaviť certifikát na testovacej CA. 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.

o Jednotliví lupiči sa potom 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ým si 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ť na zašifrovanie svojich pravidelných hlásení šéfovi.

20

CA – Vytvorenie žiadosti o certifikátCA – Vytvorenie žiadosti o certifikát

Vytvorenie žiadosti o certifikáto 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č.

o Otázkou je ako vytvoriť bežným prehliadačom žiadost o certifikát. V praxi sa stretávame s dvomi spô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

o Netscape definuje zvláštnu HTML značku <keygen> slúžiacu na vygenerovanie dvojice verejný/súkromný kľúč. Odoslanie tohto formulára spô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>.o 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 CA ho často podporujú.

o 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

CA – Aké typy certifikátov budeme používaťCA – Aké typy certifikátov budeme používať

Aké typy certifikátov budeme používaťo 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 je celkom ideálne mať spoločný certifikát na podpis a na autentizáciu (autentizácia je i napr. prihlásenie do Windows 2000 atp.).

o 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.

o Naopak v prípade elektronického podpisu starý súkromný kľúč zlikvidujem akonáhle ho 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!

o 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ť najskorej tiež čipovej karte. Na šifrovanie (presnejšie na dešifrovanie elektronických obálok) ho budem mať na disku a

zálohovaný v nejakom doveryhodnom úložisku. o 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

CA – CA – BezpeBezpečnostné požiadavky na kryptografické modulyč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.

o 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


24EFP - Environmental Failure Protection, EFT - Environmental Failure Testing


25


Špecifikácia kryptografického modulu. o 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.

o 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.

o 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.o 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.

o 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).

o Interfejs aplikačného programu softvérového komponentu kryptografického modulu môže byť definovaný ako jeden alebo viac logických interfejsov.

26


Role, služby a autentifikácia. o 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.

o 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).

o 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.

o 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).

o 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


Stavový model.o 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. o 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.

o 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ť.o 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.

o 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


Prevádzkové prostredie.o Prevádzkové prostredie kryptografického modulu zodpovedá spravovaniu softvéru, firmvéru

a/alebo hardvérových komponentov potrebných k činnosti modulu.o 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).

o 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.o 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.

o 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


EMI/EMC. o 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.o 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).

o 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.o 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

ĎAKUJEMZA POZORNOSŤ

32

certifikačná autorita

Documents