Certifikacn - PowerPoint PPT Presentation

About This Presentation
Title:

Certifikacn

Description:

Certifika n autorita Doc. Ing. Ladislav Hudec, CSc. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Certifika n autorita - vod Pre be n ho ... – PowerPoint PPT presentation

Number of Views:36
Avg rating:3.0/5.0
Slides: 33
Provided by: lhu54
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com