Certifikacn

1
Certifikacná autorita

• Doc. Ing. Ladislav Hudec, CSc.

1
2
Certifikacná 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
3
CA Základná schéma
3
4
CA - 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
5
CA - 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
6
CA - 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
7
CA - 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
8
CA pripojenie na Internet
8
9
CA 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
10
CA Retazec certifikátov
10
11
CA 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
12
CA 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
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
  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
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 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
17
CA 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
18
CA 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
19
CA 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
20
CA 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
21
CA 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
22
CA 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
23
CA 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
24
CA Bezpecnostné požiadavky na kryptografické
moduly
24
EFP - Environmental Failure Protection, EFT -
Environmental Failure Testing
25
CA Bezpecnostné požiadavky na kryptografické
moduly
25
26
CA 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
27
CA 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
28
CA 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
29
CA Bezpecnostné požiadavky na kryptografické
moduly
29
30
CA 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
31
CA 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