Title: Certifikacn
1Certifikacná autorita
- Doc. Ing. Ladislav Hudec, CSc.
1
2Certifikacná autorita - Úvod
- Pre bežného zákazníka je napríklad automobilka
továren 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 certifikacnou
autoritou, ktorej základná schéma nasleduje. - Na zaciatku je treba zdôraznit, že mnohé casti
certifikacnej autority znázornenej na obrázku
nemusia reálne certifikacné autority vôbec mat.
Reálne certifikacné autority budú mat tie casti,
ktoré budú odpovedat nimi ponúkaným službám, a
pochopitelne ich bezpecnostnej politike.
2
3CA Základná schéma
3
4CA - aktíva
- Certifikacná autorita má štyri najdôležitejšie
aktíva, ktoré musí maximálne chránit - Súkromný klúc CA je tým najväcším aktívom CA.
Jeho ukradnutie je pre CA katastrofou, po ktorej
už zrajme nemá zmysel obnovovat cinnost tejto CA.
So súkromným klúcom musí CA ochranovat tiež
sekvenciu vydaných císiel certifikátov. Vydanie
dvoch rôznych certifikátov s rovnakým sériovým
císlom je opät katastrofou, ktorú by CA asi
neprežila. - Databázu používatelov musí CA taktiež chránit, a
to hned z dvoch dôvodov - CA nesmie vydat dvom rôznym osobám certifikát s
rovnakým predmetom. - Databáza používatelov obsahuje osobné údaje
používatelov (identifikácia preukazu totožnosti,
rodné císlo apod.). - Archív súkromných šifrovacích klúcov
používatelov. Pokial CA túto službu poskytuje,
tak nesmie dopustit, aby sa súkromný klúc
používatela 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 byt 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 verifikovat.
4
5CA - aktíva
- Dalej certifikacná autorita môže mat
- Registracné autority, kam prichádzajú žiadatelia
o certifikáty. Žiadatel môže na registracnú
autoritu priniest priamo žiadost o certifikát,
registracná autorita overí totožnost žiadatela,
verifikuje žiadost o certifikát a odovzdá žiadost
(spravidla podpísanú RA) certifikacnej autorite.
Certifikacná autorita overí údaje zo žiadosti
používatela a údaje doplnené RA a vydá (ci
nevydá) príslušný certifikát. Vydaný certifikát
môže byt vrátený na RA, kde je odovzdaný
žiadatelovi. Iná stratégia spocíva v tom, že RA
vydá iba jednorázové heslo na vydanie certifikátu
a používatel žiadost o certifikát pošle
elektronicky cez OnLine RA. - 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). Žiadatel
môže cez OnLine RA žiadat o - Vydanie nového certifikátu v dobe platnosti
starého certifikátu žiadatela. - 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 žiadat o dalšie certifikáty. Žiadosti
podpisuje platným certifikátom. (Teoreticky se
môže žiadatel autentizovat i šifrovacím
certifikátom.) - O svoj súkromný šifrovací klúc, 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žívatel se autentizuje
jednorázovým heslom na odvolanie certifikátu.
Odvolané certifikáty sa jednak radia do frontu
certifikátov cakajúcich na odvolanie a jednak
informácia o odvolaní certifikátu môže byt OnLine
obratom k dispozícii pomocou OCSP servera.
5
6CA - aktíva
- Dalej certifikacná autorita môže mat
- Adresárové služby ponúkajú informácie o
používateloch, ktoré si používatelia o sebe prajú
publikovat, a najmä poskytujú vydané certifikáty
a CRL. Dôležité je, že adresárov môže byt 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
dalej môže poskytovat casové peciatky. Platnost
certifikátu poskytovaného DVCSP protokolom je
zaujímavá najmä pri starších certifikátoch, kedy
je už obtažné zistovat, ci 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á odpoved,
ktorú by bolo inak pomerne komplikované
zaobstarat. - V súcasnosti sú tiež k dispozícii špeciálne
servery poskytujúce iba casové peciatky. Dôležité
je, že TimeStamp server nemusí mat prístup do
archívu CA, tj. môže byt umiestnený i mimo CA a
teda dostupný i pri hypotetickom výpadku CA. - Poslednou súcastou je zúctovací systém, ktorého
cielom je za poskytnuté služby vystavit
používatelovi faktúru. Mohlo by sa zdat, že to
sem snád ani nepatrí, ale nie je to až taký
triviálny problém. Informácie o používateloch sú
totiž dvojaké - Informácie nevyhnutné na vydanie samotného
certifikátu, tj. zistené pri overení totožnosti
používatela (císlo obcianskeho preukazu, dalšie
údaje z obcianskeho preukazu apod.). Tieto
informácie sú spolu s vydaným certifikátom
uložené v databáze používatelov a ide o osobné
údaje používatelov, ktoré podliehajú režimu podla
zákona na ochranu osobných údajov. - Informácie nevyhnutné na vystavenie faktúry
používatelovi. Tieto údaje sa tlacia na faktúru a
sú tým pádom verejnými údajmi. Kto tieto údaje
nechce zverejnit, tak zaplatí hotovostou (peniaze
sú anonymné). Tieto údaje sú vedené v zúctovacej
databáze.
6
7CA - aktíva
- Dôležité je, že oba údaje musia byt prijaté od
používatela na RA. RA potom na CA posiela oba
údaje. Osobné údaje uloží CA do databázy
používatelov a obchodné údaje odovzdá
zúctovaciemu subsytému. Dôležité je i to, že
protokol CMC (resp. CMP), ktorým RA komunikujú
s CA, musí mat možnost (a tiež má možnost)
prenášat oba údaje. - Dalšou otázkou je, ako CA pripojit na Internet.
Na nasledujúcom obrázku je jedna z takýchto
eventualít. CA musí byt od Internetu bezpecne
oddelená. Pretože používatelia budú na CA
pristupovat z Internetu, tak oddelujúcim prvkom
nemôže byt iba bezpecnostná brána, ale musí ním
byt Internetový FrontEnd. - Na Internetovom FrontEnde potom pobežia príslušné
servery. Dôležité je, ci môžu niektoré servery
bežat niekde inde. To je dôležité napr. pri
výpadku CA ako takej. Samostatne môže bežat
server na casové peciatky, 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 registracná autorita. To je
však skorej iba hypotetická možnost, ktorá by
mala zmysel snád v prípade, keby OnLine RA bolo
viacero. V takom prípade môžu byt niektoré RA
dislokované napr. na intranetoch významných
zákazníkov CA.
7
8CA pripojenie na Internet
8
9CA Retazec certifikátov
- Retazec certifikátov
- Pokial verifikujeme certifikát, potom musíme mat
k dispozícii množinu certifikátov, z ktorej je
možné vybrat retazec, až ku korenovému
certifikátu. Všetky certifikáty do zostavovaného
retazca môžeme získat z lubovolných zdrojov
vrátane adresárových služieb s výnimkou
korenového certifikátu ten musím mat dopredu
získaný bezpecnou cestou, pretože ten je
podpísaný samým sebou a nedá sa overit
prostredníctvom elektronického podpisu. Preto
môže byt velmi lahko podvrhnutý. - Pokial mi niekto pošle množinu certifikátov aj
s korenovými certifikátmi, tak tieto korenové
certifikáty môžem použit iba na lahšie vyhladanie
retazca certifikátov. Avšak vždy sa musí
skontrolovat, ci príslušný korenový certifikát je
zhodný s niektorým korenovým certifikátom
získaným inou bezpecnou cestou. - Ak uvažujeme, že jednotlivé CA môžu mat aj
obnovené certifikáty, potom retazec certifikátov
bez rozšírenia certifikátu Identifikácia klúca
CA je možné zostavit iba velmi zle. - V neposlednom rade nesmieme zabudnút na
bezpecnostnú politiku. Je treba, aby ratazec
kvalifikátorov bezpecnostných politík (OID
bezpecnostných politík) siahal tiež až ku
korenové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). - Dalej je nevyhnutné pri jednotlivých
certifikátoch skontrolovat, ci nie sú odvolané
(nie sú na zozname CRL). - Za dôveryhodný certifikát nie je nevyhnutné vždy
prehlásit až korenový certifikát. Pokial sa za
dôveryhodný certifikát prehlási niekterý
z certifikátov uprostred retazca medzi
certifikátom používatela a korenový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
10CA Retazec certifikátov
10
11CA Retazec certifikátov
- Pre bezpecnost pocítaca je zásadný zoznam
dôveryhodných certifikátov, ktorý je inštalovaný
na pocítaci. Pokial sa na tento zoznam podarí
podvrhnút napr. certifikát niektorej
z testovacích certifikacných autorít, tak máme o
nepríjemnosti postarané. Pritom staršie verzie
prehliadacov boli distribuované s celým radom
certifikátov certifikacných autorít, o ktorých
sme nikdy nemohli vediet ci sú dôveryhodné. A
tak prvou operáciou po instalácii prehliadaca
bolo zrušenie týchto certifikátov a vloženie
dôveryhodných certifikátov (dôveryhodných
certifikacný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
12CA Krížová certifikácia
- Krížová certifikácia
- Doposial sme predpokladali, že certifikacné
autority tvoria stromovú štruktúru. Avšak je
možná i iná štruktúra krížová. - Dve certifikacné autority, ktoré nie sú zaradené
do tej istej stromovej štruktúry, si môžu
vzájomne podpísat svoje certifikáty vykonat
krížovú certifikáciu. Pre úplnost je treba dodat,
že krížovo sa môžu certifikovat i CA patriace do
spolocného stromu to má však význam, ked je
strom príliš košatý a CA ležia na velmi
vzdialených vetviach stromu potom je možné
krížovou certifikáciou ich vzdialenost zmenšit. - Na nasledujúcom obrázku sú dve certifikacné
autority CA1 a CA2. Používatel A bez problémov
komunikuje s používatelom B, pretože používatel A
uznáva CA1 ako dôveryhodnú. V prípade, že
používatel A obdrží certifikát používatela B, tak
si zostaví ratazec certifikátov z certifikátu
použíatela B a certifikátu CA1. CA1 je korenová
certifikacná autorita, ktorej používatel A
dôveruje. Tj. používatelia A a B spolocne
dôverujú certifikacnej autorite CA1. - V prípade, že ale chce s použíatelom B
komunikovat používatel C, tak je tomu už inak.
Používatel C si zostaví retazec certifikátov
zacínajúcí certifikátom používatela B ten ale
koncí vždy na CA1, ktorej používatel C
nedôveruje, pretože ju nepozná.
12
13CA Krížová certifikácia, CA1 nie je krížovo
certifikovaná s CA2
13
14CA Krížová certifikácia
- Riešením je, že CA1 si okrem svojho pôvodného
korenového certifikátu nechá vydat další
certifikát, teraz certifikacnou autoritou CA2
(vid nasledujúci obrázok). CA1 tak má svoj
korenový certifikát a naviac další krížový
certifikát, ktorý je vydaný CA2. - V prípade, že používatel C chce komunikovat
s používatelom B, tak B mu pošle množinu
certifikátov obsahujúcu - Certifikát B
- Certifikát CA1 podpísaný CA1 (korenový certifikát
CA1) - Certifikát CA1 podpísaný CA2
- (Certifikát CA2 podpísaný CA2 by mal používatel C
mat, pretože mu sám dôveruje). - Používatel si nájde retazec, ktorému môže
dôverovat. Jedná sa o nasledujúci ratazec
zakoncený pre neho dôveryhodnou CA2 B -gt CA1
podpísaný CA2 -gt CA2 podpísaný CA2. Tak sa stane
certifikát používatela B dôveryhodným i pre
používatela C, ktorý dôveruje CA2. - Je zaujímavé, že rovnakú množinu certifikátov
môže od B obdržat i A, ten si ale vybere z tejto
množiny kratší retazec B -gt CA1 podpísaný CA1. - Touto krížovou certifikáciou sa CA1 a jej
používatelia stali dôveryhodní pre CA2 a jej
používatelov. Nie je tomu však naopak.
14
15CA Krížová certifikácia, CA2 krížovo
certifikovala CA1
15
16CA Krížová certifikácia, obojstranná krížová
certifikácia CA1 a CA2
- Aby tento vztah bol obojstranný, tak je
nevyhnutné, aby i CA2 si nechala vydat certifikát
u CA1, podla 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
17CA Obnovenie certifikátu CA
- Obnovenie certifikátu CA
- So skutocnostou, že je nevyhnutné obnovovat i
certifikáty samotnej certifikacnej autority, sme
sa už oboznámili (vypršanie platnosti certifikátu
CA). Nový certifikát CA je nevyhnutné vydat
s takým predstihom, aby súkromným klúcom
patriacemu k starému certifikátu neboli vydané
certifikáty, ktorých platnost skoncí neskoršie
než platnost klúca, 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 klúcom CA. Je to
vlastne obdoba krížovej certifikácie. - Aby používatelia s certifikátom podpísaným starým
klúcom dôverovali certifikátom podpísaným novým
klúcom, tak je ideálne urobit krížovú
certifikáciu. Opät získame štyri certifikáty - Nový
- Starý
- Nový podpísaný starým
- Starý podpísaný novým.
- Druhé dva by mali mat omedzenú platnost na dobu,
po ktorú sa prekrýva platnost dvoch prvých
certifikátov. Pretože PKI nedoporucuje používat
rozšírenie Doba platnosti súkromného klúca,
ktoré je pre tieto úcely urcené, tak sa to musí
urobit pomocou doby platnosti certifikátu. - Podpísanie nového certifikátu CA starým súkromným
klúcom CA je posledná akcia, ktorú by sme mali so
starým súkromným klúcom urobit. Na to by mal byt
zlikvidovaný, lebo je zbytocné ochranovat to, co
je už nepotrebné.
17
18CA Certifikacné politiky
- Certifikacné politiky
- Už skorej bolo ukázané, že pri verifikácii
certifikátov sa neoveruje iba elektronický podpis
certifikátu, ale tiež certifikacná politika. Tá
by mala byt v celom retazci certifikátov rovnaká.
V zložitejšom prípade môže byt 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. - Certifikacná politika je dokument (text), z
ktorého by malo byt jasné pre aké aplikácie je
vydaný certifikát urcený. Dalej by malo byt
v certifikacnej politike opísané aký je vztah
medzi používatelom a údajmi uvedenými
v certifikáte, tj. ako a akým spôsobom overuje
certifikacná autorita totožnost žiadatela o
certifikát. V certifikáte môže byt uvedené
viacero certifikacných politík. - Certifikacná autorita si pre jednotlivé svoje
certifikacné politiky nechá priradit
identifikátory objektov. V rozšírení certifikátu
Certifikacné politiky sa potom uvádzajú tieto
identifikátory objektov v položke
policyIdentifier. - Otázkou je ci má praktický zmysel v jednej firme
vydávat certifikáty s rôznymi certifikacnými
politikami. Príklad je asi nasledujúcí V našej
firme vydáme všetkým zamestnancom certifikát, aby
mohli komunikovat bezpecnou elektronickou poštou.
Pre tieto certifikáty použijeme všeobecnú
certifikacnú politiku. Avšak pre zamestnancov,
ktorí budú podpisovat financné transakcie vydáme
financnú certifikacnú politiku a do ich
certifikátov budeme vkladat identifikátor objektu
tejto financnej certifikacnej politiky.
Niekterí zamestnanci tak môžu mat vo svojom
certifikáte identifikátory objektov oboch
politík. Vo financných aplikáciách potom
zaistíme, aby fungovali iba certifikáty splnujúce
financnú certifikacnú politiku.
18
19CA Certifikacné politiky
- Certifikacné politiky
- Rozšírenie certifikátu Certifikacné politiky
môže byt oznacené ako kritické. V tomto prípade
pre príznak kriticnosti rozšírenia certifikátu
platí dôležitá výnimka. Totiž pokial je
rozšírenie Certifikacné politiky oznacené ako
kritické, potom použitie takto oznaceného
certifikátu je obmedzené iba na aplikácie
vyhovujúce aspon jednej z certifikacných politík
uvedených v certifikáte. Pokial vyviniem
aplikáciu A pre svojich zákazníkov a vydám im
firemné certifikáty, potom sa môžem bránit tomu,
aby zákazník podpísal nejaký dokument menom firmy
tým, že vydám certifikacnú politiku pre aplikáciu
A a identifikátor objektu tejto certifikacnej
politiky uvediem v rozšírení Certifikacné
politiky, ktoré oznacím ako kritické. - Rozšírenie Certifikacné politky môže obsahovat
parametry (kvalifikátory) - Hypertextový odkaz (URI) na Certifikacnú
vykonávaciu smernicu (Certification Practice
Statement - CPS). - Poznámku oznacovanú tiež ako prehlásenie
vystavitela alebo používatelské oznámenie
explicitText, ktorá v najviac 200 znakoch jasne
charakterizuje úcel použitia certifikátu. - CPS je zrejme najdôležitejší dokument CA. V nom
sú detailne uvedené pravidlá a praktiky
vykonávané zamestnancami CA pri vydávaní
certifikátu. Jedná se o dokument, ktorý musí byt
dostupný klientom CA (je nan hypertextový odkaz
v certifikáte). - CPS nevytvárame iba pre CA, ale vytvárajú si ju i
firmy, ktoré si nechávajú vystavit certifikáty od
externých (verejných) certifikacných autorít.
Každá firma využívajúca PKI by mala mat vytvorenú
CPS. Netreba sa bát vytvorenia tohto dokumentu.
Využijeme RFC-3280, ktoré je kuchárkou na tvorbu
CPS.
19
20CA Testovacie certifikacné autority
- Testovacie certifikacné autority
- Pre testovacie úcely sú casto prevádzkované CA,
ktoré nijako nepreverujú totožnost žiadatela.
Zašlete na takúto CA žiadost 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 císlom. Pri takto
vystavených certifikátoch je slušné, aby v
prehlásení vystavitela bolo jasne uvedené, že
ide o testovacie certifikáty. - Pokial by ste chceli testovací certifikát použit
na praktickú komunikáciu, potom sa jedná o
certifikát ako každý iný iba neprebehlo
overenie totožnosti žiadatela. Takže si overenie
totožnosti musíte vykonat pri použití certifikátu
sami. - Napr. šéf bandy lupicov si nechá vystavit
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. - Jednotliví lupici sa potom telefonicky spojujú so
svojim šéfom a overují si jeho totožnost napr. na
nejaký spolocný zážitok Pamätáš sa šéf, ako sme
boli minulý týžden na tahu Kolko tam bolo
blondýnok? Pokial šéf správne odpovie, že tam
nebola žiadna blondýnka, tak lupic skutocne vie,
že hovorí so svojim šéfom. Ostáva už iba otázka
Zarecituj mi odtlacok (thumbprint, kontrolný
súcet) certifikátu, ktorým si podpísal svoj mail.
Pokial napr. odpovie D96F 563E E0EC 3570 94BB
DF05 75D6 300E 563E E0EC, tak si lupic zobrazí
podrobnosti o inkriminovanom certifikáte a podíva
sa ci položka Odtlacok skutocne obsahuje šéfom
zarecitovaný kontrolný súcet. Pokial áno, potom
lupic zafungoval ako registracná autorita a vie,
že certifikát môže použit na zašifrovanie svojich
pravidelných hlásení šéfovi.
20
21CA Vytvorenie žiadosti o certifikát
- Vytvorenie žiadosti o certifikát
- Minule sme opísali formáty žiadosti o certifikát
tvaru PKCS10 a CRMF. Tieto žiadosti môže
žiadatel vytvorit nejakým svojim programom. Také
programy sú dodávané napr. s webovými servermi.
Ale bežný používatel, ktorý si chce vystavit
certifikát spravidla nemá tieto programy
k dispozicii. Má k dispozícii iba bežný
prehliadac. - Otázkou je ako vytvorit bežným prehliadacom
žiadost o certifikát. V praxi sa stretávame
s dvomi spôsobmi generovania žiadosti o
certifikát v prehliadaci - Využitím programového komponentu, ktorý je
súcastou webovej stránky. - Použitím špeciálnej znacky, ktorá rozširuje jazyk
HTML o možnost generovania žiadosti o certifikát. - Žiadost formátu SPK
- Netscape definuje zvláštnu HTML znacku ltkeygengt
slúžiacu na vygenerovanie dvojice
verejný/súkromný klúc. Odoslanie tohto formulára
spôsobí - Vygenerovanie dvojice klúcov verejný/súkromný
klúc - Verejný klúc podpíše vygenerovaným súkromným
klúcom - Base64 kódovaný verejný klúc vrátane jeho podpisu
vloží do obsahu pola HTML stránky, ktorá obsahuje
znacku ltkeygengt. - Táto žiadost o certifikát se oznacuje ako žiadost
formátu SPK. Žiadost formátu SPK je neštandardný
typ žiadosti o certifikát, pretože neobsahuje
elektronický podpis celej žiadosti, ale iba
podpis verejného klúca. Normy PKI tento formát
žiadosti v podstate nepoznajú, ale CA ho casto
podporujú. - Ako príklady generovania žiadostí formátu SPK
(žiadostí pre Netscape) môžu opät slúžit
žiadosti o vydanie certifikátu vystavené na
www.netscape.com
21
22CA Aké typy certifikátov budeme používat
- Aké typy certifikátov budeme používat
- Z technického hladiska môžeme mat 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
mat spolocný 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.
Pokial totiž stratím súkromný klúc, potom nie som
schopný dešifrovat staré správy zašifrované
príslušným verejným klúcom. Je teda praktické
archivovat súkromné šifrovacie klúce. Túto službu
môže poskytovat aj CA. - Naopak v prípade elektronického podpisu starý
súkromný klúc zlikvidujem akonáhle ho už
nepotrebujem. Staré elektronické podpisy sa
verifikujú pomocou verejného klúca a ten je
v certifikáte. A certifikát, ten musí byt
archivovaný minimálne na CA. Súkromný klúc na
elektronický podpis nikdy nedávam z ruky ani
certifikacnej autorite! - Výsledkom sú tri aktuálne certifikáty
- Na elektronický podpis. Príslušný súkromný klúc
budem mat najskorej na cipovej karte. - Na autentizáciu. Príslušný súkromný klúc budem
mat najskorej tiež cipovej karte. - Na šifrovanie (presnejšie na dešifrovanie
elektronických obálok) ho budem mat na disku a
zálohovaný v nejakom doveryhodnom úložisku. - Inými kritériami je dlžka klúca. Kvalifikované
certifikáty môžu mat v rozšírení špecifikovanú
hodnotu transakcie, do ktorej je elektronický
podpis verifikovaný týmto certifikátom poistený
atd.
22
23CA Bezpecnostné požiadavky na kryptografické
moduly
- Bezpecnostné požiadavky na kryptografické moduly
(podla FIPS-140-2). V súcasnosti je v
schvalovacom pokracovaní FIPS-140-3. - Bezpecnostné požiadavky, ktoré musia splnovat
kryptografické moduly, pokrývajú oblasti - Špecifikácia kryptografického modulu
- Porty a interfejsy modulu
- Role, služby a autentifikácia
- Stavový model
- Prevádzková bezpecnost
- Správa šifrovacích klúcov
23
24CA Bezpecnostné požiadavky na kryptografické
moduly
24
EFP - Environmental Failure Protection, EFT -
Environmental Failure Testing
25CA Bezpecnostné požiadavky na kryptografické
moduly
25
26CA Bezpecnostné požiadavky na kryptografické
moduly
- Špecifikácia kryptografického modulu.
- Kryptografický modul môže byt 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 volitelne generovanie klúca, a modul
je uložený v rámci definovaných hraníc. - Pre bezpecnostné úrovne 1 a 2 môže bezpecnostná
politika kryptografického modulu špecifikovat,
kedy sa nachádza kryptografický modul v
odsúhlasenom režime prevádzky. - Pre bezpecnostné úrovne 3 a 4 musí kryptografický
modul indikovat, kedy je vybratý odsúhlasený
režim prevádzky. Kryptografické hranice modulu
musia pozostávat z explicitne definovanej zóny,
ktorá urcuje fyzické hranice kryptografického
modulu. - Porty a interfejsy kryptografického modulu.
- Kryptografický modul musí obmedzit 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 byt
logicky odlíšené od ostatných aj ked môžu
využívat jeden spolocný fyzický port (napr.
vstupné údaje môžu vstupovat a výstupné údaje
môžu vystupovat prostredníctvom toho istého
portu) alebo môžu byt distribuované cez jeden
alebo viacero fyzických portov (napr. vstupné
údaje môžu vstupovat prostredníctvom dvoch
portov, sériovým aj paralelným). - Interfejs aplikacného programu softvérového
komponentu kryptografického modulu môže byt
definovaný ako jeden alebo viac logických
interfejsov.
26
27CA Bezpecnostné požiadavky na kryptografické
moduly
- Role, služby a autentifikácia.
- Kryptografický modul musí podporovat autorizované
role pre operátorov a odpovedajúce služby v rámci
každej roli. Ak kryptografický modul podporuje
súcasných oprátorov, potom modul musí interne
udržiavat oddelenie rolí predpokladané role
každého operátora a odpovedajúce služby. - Operátor nemusí pracovat v autorizovanej role v
prípade, že vykonáva služby, pri ktorých nie sú
modifikované, zvrejnené alebo nahradené
kryptografické klúce a kritické bezpecnostné
parametre (napríklad show status, self-test a iné
služby, ktoré nemajú vplyv ma bezpecnost modulu).
- Autentifikacný mechanizmus môže byt 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ávat
požadovanú rolu a vykonávat služby v rámci roli.
Kryptografický modul musí podporovat autorizované
role používatela a kryptomanažéra. - Ak kryptografický modul umožnuje operátorom
vykonávat službu údržby, potom modul musí
podporovat autorizovanú rolu údržby (všetky
tajomstvá v otvorenom tvare, privátne klúce a
nechránené kritické bezpecnostné parametre musia
byt resetované-vynulované pri vstupe do tejto
role). - Kryptografický modul musí poskytovat operátorm
služby ukáž stav (show status), vykonaj self-test
a vykonaj odsúhlasenú bezpecnostnú funkciu. V
závislosti na bezpecnostnej úrovni musí
kryptografický modul podporovat aspon 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
28CA Bezpecnostné požiadavky na kryptografické
moduly
- Stavový model.
- Prevádzka kryptografického modulu musí byt
špecifikovaná použitím stavového modelu (alebo
ekvivalentného modelu) reprezentovaného diagramom
stavových prechodov a tabulkou stavov. - Diagram prechodu stavov a tabulka stavov zahrnuje
všetky prevádzkové a chybové stavy
kryptografického modulu, odpovedajúce prechody z
jedného stavu do druhého, vstupnú udalost
spôsobujúcu prechod z daného stavu do
nasledujúceho a výstupnú udalost rezultujúcu z
prechodu medzi stavmi. - Kryptografický modul musí zahrnovat stavy
zapnutia a vypnutia napájacieho napätia, stavy
kryptomanažéra, stavy vkladania klúcov a
kritických bezpecnostných parametrov, stavy
používatelov, stavy samocinného testovania a
chybové stavy. Modul môže zahrnovat aj dalšie
stavy ako napríklad stavy bypass a stavy údržby.
- Fyzická bezpecnost.
- Kryptografický modul musí uplatnovat 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 byt
chránené v rámci kryptografických hraníc. - Požiadavky na fyzickú bezpecnost sú špecifikované
pre tri definované uspôsobenia kryptografického
modulu a to jednocipové kryptografické moduly,
viaccipový vnorený kryptografický modul (karta do
PC, adaptér) a viaccipový samostatný
kryptografický modul (samostané zariadenia napr.
šifrovací smerovac). Sumárne požiadavky na
fyzickú bezpecnost sú v nasledujúcej tabulke.
28
29CA Bezpecnostné požiadavky na kryptografické
moduly
29
30CA Bezpecnostné 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 cinnosti
modulu. - Prevádzkové prostredie môže byt nemodifikovatelné
(t.j. firmvér obsiahnutý v ROM alebo softvér na
pocítaci bez vstupných a výstupných zariadení)
alebo modifikovatelný (t.j. firmvér obsiahnutý v
RAM alebo softvér vykonávaný na univerzálnom
pocítaci). - Operacný systém je dôležitým komponentom
prevádzkového prostredia kryptografického modulu.
Ak v prevádzkovanom prostredí kryptografický
modul využíva operacný systém, potom sa pre
bezpecnostné úrovne 2, 3 a 4 vyžaduje PP
(Protection Profile - ochranný profil) a
príslušná úroven záruk. - Správa šifrovacích klúcov.
- Bezpecnostné požiadavky pre správu
kryptografických klúcov obsahuje celý životný
cyklus klúcov a ich komponentov a kritických
bezpecnostných parametrov používaných
kryptografickým modulom. - Správa klúcov zahrnuje generovanie náhodných
císel a klúcov, zriadenie klúcov, distribúciu
klúcov, vkladanie a vyberanie klúcov, uloženie
klúcov a resetovanie klúcov. Kryptografický modul
môže tiež využívat mechanizmus správy klúcov
dalších kryptografických modulov. Tajné klúce,
privátne klúce a kritické bezpecnostné parametre
musia byt chránené v kryptografickom module pred
neautorizovaným zverejnením, modifikáciou a
substitúciou. Verejné klúce musia byt chránené v
kryptografickom module pred neautorizovanou
modifikáciou a substitúciou.
30
31CA Bezpecnostné požiadavky na kryptografické
moduly
- EMI/EMC.
- Kryptografické moduly musia splnovat požiadavky
pre EMI a EMC. Dokumentácia musí dokladovat
kompatibilitu modulov s týmito požiadavkami. - Samocinné testovanie.
- Kryptografický modul musí vykonat samocinný test
pri zapnutí napájacieho napätia a podmienený
samocinný test, aby sa zaistilo, že modul funguje
správne. Podmienecný samocinný test sa musí
vykonat, ked sa vyvolá príslušná bezpecnostná
funkcia alebo operácia (pri ktorej je požadovaný
samocinný test). - Ak samocinný test kryptografického modulu
indikuje poruchu, musí modul prejst do chybového
stavu a prostredníctvom stavového interfejsu musí
indikovat chybu. Kryptografický modul nesmie
vykonávat žiadne kryptografické operácie, pokial
sa nachádza a v chybovom stave, a všetky výstupné
údaje na výstupnom údajovom interfejse musia byt
zablokované. - Záruky návrhu.
- Záruky návrhu zodpovedajú použitiu najlepšej
praxe výrobcom/dodávatelom kryptografického
modulu pocas 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. Bezpecnostné požiadavky sú
špecifikované pre manažment konfigurácie, dodávku
a prevádzku, vývoj a návody.
31
32 DAKUJEM ZA POZORNOST
32