Скачать презентацию PKI Infraštruktúra verejného kľúča certifikáty a digitálny podpis Скачать презентацию PKI Infraštruktúra verejného kľúča certifikáty a digitálny podpis

3cab5d4a58e18cf77c7ae05f1044810a.ppt

  • Количество слайдов: 30

PKI (Infraštruktúra verejného kľúča), certifikáty a digitálny podpis Doc. Ing. Ladislav Hudec, CSc. , PKI (Infraštruktúra verejného kľúča), certifikáty a digitálny podpis Doc. Ing. Ladislav Hudec, CSc. , CISA 1

PKI - Úvod q q q PKI je sústavou technických a predevšetkým organizačných opatrení PKI - Úvod q q q PKI je sústavou technických a predevšetkým organizačných opatrení spojených s vydávaním, správou, používaním a odvolávaním platnosti kryptografických kľúčov a certifikátov. Jednu z možných noriem PKI definuje sada internetových štandardov RFC opisujúcich základné využitie asymetrickej kryptografie na Internete. Nadväzujúcimi normami sú potom normy pre bezpečnú elektronickú poštu (S/MIME) a norma pre bezpečnú komunikáciu nielen s webovým servom (TLS). História PKI v Internete: o o o q najprv vzniklo niekoľko noriem využívajúcich kryptografii s verejnými kľúčmi tieto normy na sebe príliš nenadväzovali a najmä nepokrývali celú škálu problémov jednotliví dodavatelia softvéru tak začali dodávať programy, ktoré medzi sebou vzájomne niekedy komunikovali dobre a niekedy nie v Internete preto vznikla pracovná skupina, ktorá sa pokúsila vytvoriť sústavu noriem prekonávajúcich tieto ťažkosti výsledkom je nová generácia noriem, ktorá nie je ideálna, ale je krokom vpred v Internete pod skratkou PKI rozumieme systém týchto protokolov. Poznáme ich podľa toho, že väčšinou majú v názve slovo „PKI“. Okrem uvedeného použitia asymetrickej kryptografie a certifikátov existujú na Internete aj iné aplikácie využívajúce certifikáty: o napríklad systém SET určený na platbu platobnými kartami cez Internet, který tiež používa certifikáty podľa X. 509, ale POZOR!, protokol SET sice používa certifikáty podľa X. 509, ale NIE podľa RFC-5280, tj. nie podľa PKI. (Protokol SET je analógiou 2 PKI – oba vychádzajú z X. 509, ale protokol SET je výlučne na platby na Internete. )

PKI q q Na začiatku treba zdôrazniť, že normy PKI vychádzajú z noriem ITU-T PKI q q Na začiatku treba zdôrazniť, že normy PKI vychádzajú z noriem ITU-T radu X. 500 (napr. na opis certifikátu konkrétne z normy X. 509), ale špecifikujú konkrétnu množinu parametrov a praktík určených pre Internet. Tj. napr. nie všetky rozšírenia certifikátov opísaných v norme ITU-T X. 509 sú normami PKI podporované. Softvér určený pre Internet potom iné rozšírenia ako tie, ktoré sú uvedené v PKI, nemusí podporovať. Nemali by sme tak v Internete používať označenie: „certifikát podľa X. 509 verzie 3“, ale „certifikát podľa RFC-5280“. Naopak normy PKI zavádzajú niektoré rozšírenia, ktoré normy ITU-T neuvádzajú. Certifikát je štruktúra obsahujúcí identifikačné údaje klienta, verejný kľúč klienta, identifikáciu vydavateľa, číslo certifikátu, platnosť certifikátu a ďalšie údaje týkajíce se najmä vymedzenia spôsobu použitia certifikátu. Táto štruktúra je digitálne podpísaná certifikačnou autoritou (vydavateľom certifikátu). K čomu slúži táto pomerne komplikovaná konštrukcia? o o Na nasledujúcom obrázku je znázornený prípad, kedy používateľ A chce používateľovi B zaslať správu, ktorú chce zabezpečiť šifrovaním asymetrickou šifrou. V takomto prípade je nevyhnutné, aby príjemca B najprv vygeneroval dvojicu kľúčov : verejný kľúč (VK-B) a súkromný kľúč (SK-B) (1). Súkromný kľúč si uloží ako svoje tajomstvo napríklad na disk alebo čipovú kartu (2). Verejný kľúč (VK-B) nejakým kanálom distribuje používateľovi A (3). 3

PKI o o q Používateľ A potom použije verejný kľúč používateľa B (na obrázku PKI o o q Používateľ A potom použije verejný kľúč používateľa B (na obrázku označený VK-B) k zašifrovaniu odosielanej správy (4). Používateľ B potom takto zašifrovanú správu dešifruje svojím súkromným kľúčom (SKB) a získa tak pôvodnú správu (5). Pri asymetrickej kryptografii nespočíva nebezpečie vo vyzradení verejného kľúča. Avšak aj pri asymetrickej kryptografii je nebezpečím podvrhnutie kľúča. 4

PKI q Na nasledujúcom obrázku nám vstupuje do hry útočník X (útok Man in PKI q Na nasledujúcom obrázku nám vstupuje do hry útočník X (útok Man in the Middle): o o q ktorý si vygeneruje svoju dvojicu kľúčov: verejný kľúč (VK-X) a súkromný kľúč (SK-X) útočník svoj verejný kľúč VK-X podvrhne za kľúč používateľa B. Tj. používateľ A si myslí, že VK-X je verejným kľúčom používateľa B a vykoná týmto kľúčom šifrovanie odosielanej správy. Správu odchytí útočník X a dešifruje si ju svojím súkromným kľúčom SK-X. Útočník tak získa správu. Aby si používateľ B nesťažoval, že nedostane správu, tak mu ju útočník zašifruje a odošle šifrovanú jeho kľúčom (VK-B). Proti podvrhnutiu verejného kľúča sa bránime certifikáciou verejného kľúča – tj. pomocou certifikátu. Používateľ B vygeneruje dvojicu verejný a súkromý kľúč, pričom súkromý kľúč si ako tajomstvo starostlivo uloží. Avšak verejný kľúč neodosiala používateľovi B samotný, ale ako súčasť certifikátu. 5

PKI – Podvrhnutie verejného kľúča 6 PKI – Podvrhnutie verejného kľúča 6

PKI – Certifikácia verejného kľúča q Certifikácia verejného kľúča používateľa sa vykoná takto (viď PKI – Certifikácia verejného kľúča q Certifikácia verejného kľúča používateľa sa vykoná takto (viď nasledujúci obrázok): o o o q Certifikát okrem iného obsahuje informácie o tom: o o o q q Používateľ B vygeneruje dvojicu verejný a súkromný kľúč (1), pričom súkromný kľúč si ako tajomstvo starostlivo uloží. Po vygenerovaní dvojice kľúčov používateľ B zostaví štruktúru „žiadosť o certifikát“. Táto štruktúra obsahuje identifikačné údaje používateľa B, verejný kľúč používateľa B a prípadne ďalšie data, ktorá sú opísané ďalej. Túto štruktúru digitálne podpíše svojím práve vygenerovaným súkromným kľúčom a pošle certifikačnej autorite (2). Certifikačná autorita overí totožnosť používateľa a verifikuje elektronický podpis na žiadosti o certifikát. Pokiaľ je žiadosť v poriadku, potom certifikačná autorita vystaví certifikát. kto ho vydal sériové číslo certifikátu identifikačné údaje používateľa platnosť certifikátu verejný kľúč používateľa Certifikát je digitálne podpísaný súkromným kľúčom certifikačnej autority (CA). Certifikačná autorita má svoju dvojici kľúčov: verejný kľúč CA (VK-CA) a súkromný kľúč (SK-CA). Na bezpečnost uloženia súkromného kľúča CA sú kladené extrémne nároky (FIPS 140 -2). Verejný kľúč CA sa distribuje ako súčasť certifikátu CA. 7

PKI – Certifikácia verejného kľúča q q q Certifikát CA môže byť podpísaný súkromným PKI – Certifikácia verejného kľúča q q q Certifikát CA môže byť podpísaný súkromným kľúčom samotnej CA (self signed) alebo súkromným kľúčom inej CA (nadradená autorita alebo krížová certifikácia). Používateľovi B je certifikačnou autoritou vrátený vystavený certifikát (3). S vystaveným certifikátom by mal používateľ obdržať tiež jeden alebo viacero certifikátov certifikačných autorít. Pomocou certifikátov CA môže byť overený vystavený certifikát. Teraz môže používateľ B svoj certifikát odoslať (4) používateľovi A, ktorý ho overí a v prípade, že je vystavený pre používateľa A dôveryhodnou CA a elektronický podpis na certifikáte je v poriadku, potom môže z tohto certifikátu použiť verejný kľúč na zašifrovanie správy, ktorú chce odoslať používateľovi B. Zašifrovanú správu odošle používateľovi B (5). Používateľ B potom pomocou svojho súkromného kľúča dešifruje správu (6) a získa tak pôvodnú správu. 8

PKI – Certifikácia verejného kľúča 9 PKI – Certifikácia verejného kľúča 9

PKI – Certifikácia verejného kľúča q q Certifikát se často prirovnáva k občianskemu preukazu. PKI – Certifikácia verejného kľúča q q Certifikát se často prirovnáva k občianskemu preukazu. Zatiaľ čo občiansky preukaz se vydáva v tlačenej podobe, tak certifikát se opisuje ako štruktúra v jazyku ASN. 1 a medzi počítačmi se prenáša v kódovaní DER (podmnožina BER). Zásadný rozdiel medzi občianskym preukazom a certifikátom je, že občiansky preukaz neobsahuje šifrovací kľúč. V Internete je certifikát opísaný normou RFC-5280 (predtým norma RFC-3280). Táto norma je odvodená od odporúčaní ITU (predtým CCITT) X. 509. Pôvodná verzia číslo 1 certifikátu podľa normy X. 509 z roku 1988 bola postupne rozšírená až do dnes nejbežnejšej verzii 3. Okrem certifikátov podľa RFC-5280 (resp. odporúčaní X. 509) sa v praxi môžeme stretnúť i s certifikátmi iných formátov - napríklad EDI. Forma takýchto certifikátov je síce iná, ale princíp zostáva rovnaký. 10

PKI - Porovnanie položiek občianskeho preukazu a certifikátu 11 PKI - Porovnanie položiek občianskeho preukazu a certifikátu 11

PKI – Certifikát, jedinečné mená q q q q Jedinečné mená se používajú na PKI – Certifikát, jedinečné mená q q q q Jedinečné mená se používajú na opis vystaviteľa certifikátu a na opis predmetu certifikátu. Jedinečné meno (Distinguished name) je typu Name zavedeného normou X. 501. Cieľom noriem radu X. 500 je vytvoriť celosvetovú adresárovú štruktúru. Adresárom se pritom nerozumie adresár súborov, ale adresár ako zoznam adries. Cieľom je vytvoriť obdobu celosvetových bielych stránok telefónnych zoznamov. Jeden záznam v takom zozname odpovedá potom jedinečnému menu. Záznam v takej bielej knihe by potom bol hypoteticky tvorený informáciami o štáte, telefónnej spoločnosti, telefónnom obvode, mene, adrese, telefónnom čísle. Podobne aj jedinečné meno bude tvorené relatívnymi jedinečnými menami. Jednotlivé relatívne jedinečné mená budú opisovať napr. : štát, kraj, organizáciu, meno, adresu elektronickej pošty atď. Jedinečné meno (niekedy tiež absolútme jedinečné meno alebo RDNSequence) je vždy postupnosť relatívnych jedinečných mien (Relative Distinguished Name). Pritom v jedinečnom mene sa môžu aj relatívne jedinečné mená opakovať. Relatívne jedinečné meno je množina dvojíc tvorených identifikátorom objektu (napr. Country, Organization, Common. Name apod. ) a reťazcom (napr. SK). Textovo potom často relatívne jedinečné meno zapisujeme napr. Country=SK. Jedinečné meno opisujúce jedinca je potom sekvenciou relatívnych jedinečných mien. Napr. : Country=SK, Organization=STU, Common. Name=Ivan Biely Tento zápis sa často skracuje pomocou skratiek pre identifikátory objektov 12 relatívnych jedinečných mien: C=SK, O=STU, CN= Ivan Biely

PKI – Certifikát, jedinečné mená q Aj keď relatívne jedinečné meno je množinou dvojíc PKI – Certifikát, jedinečné mená q Aj keď relatívne jedinečné meno je množinou dvojíc identifikátor objektu + hodnota, tak v praxi býva táto množina jednoprvková, tj. obsahuje z dvojice len jeden. Jedinečné mená sú tvorené vždy vetvou v strome relatívnych jedinečných mien. 13

PKI – Certifikát, jedinenčné mená q Zaujímavé je, že Ivan Biely môže byť v PKI – Certifikát, jedinenčné mená q Zaujímavé je, že Ivan Biely môže byť v štruktúre uvedený mnohými spôsobmi: o o o q Ako obyvateľ Slovenska, konkrétne Bratislavského kraja, konkrétne Bratislavy: C=SK, SP=BA, L=BA, CN=Ivan Biely Ako zamestnanec firmy STU s adresou elektronickej pošty [email protected] sk , C=SK, O=STU, CN=Ivan Biely, [email protected] sk Ako zamestnanec firmy STU, fakulty FIIT: C=SK, O=STU, OU=FIIT, CN=Ivan Biely Bolo použité meno Biely, tj. bez slovenskej diakritiky, ale nič nebráni používať diakritiku, pretože PKI vo všetkých reťazcoch, v ktorých prichádza do úvahu použitie diakritiky, pripúšťa kódovanie UTF-8. 14

PKI – Prehľad atribútov relatívnych jedinečných mien 15 PKI – Prehľad atribútov relatívnych jedinečných mien 15

PKI – Prehľad atribútov relatívnych jedinečných mien 16 PKI – Prehľad atribútov relatívnych jedinečných mien 16

PKI – Identifikačné údaje CA a používateľa q Identifikačné údaje CA (vystaviteľa certifikátu) - PKI – Identifikačné údaje CA a používateľa q Identifikačné údaje CA (vystaviteľa certifikátu) - Issuer o o q obsahuje jedinečné meno certifikačnej autority, ktoré je ako celok tiež identifikáciou certifikačnej autority. Je potrebné, aby certifikačná autorita mala jednoznačnú identifikáciu (jedinečné meno) v rámci všetkých certifikačných autorít. je tvorená kombináciou atribútov relatívnych jedinečných mien. Musia byť podporovné tieto atribúty: country, organization. Unit, dn. Qualifier, state. Or. Province. Name, common. Name a podpora domain. Component. Programy by mali byť ďalej podporované atribútmi: locality, title, surname, given. Name, initials, a generation. Qualifier. Identifikačné údaje používateľa (predmet certifikátu) - Subject o obsahuje jedinečné meno objektu, ktorému je certifikát vydaný. Predmet certifikátu musí byť jedinečný v rámci všetkých objektov certifikovaných danou CA. V prípade, že pre dva rôzne objekty by vychádzal rovnaký predmet, potom sa pre rozlíšenie objektov použije atribút DNQualifier (v prípade kvalifikovaných certifikátov použijeme atribút serial. Number). Dôležité je, že pre rovnaký objekt môže tá istá CA vydať niekoľko rôznych certifikátov, ktoré majú rovnaký predmet (rovnaké jedinečné meno). Tj. NN môže mať viacej rôznych certifikátov s rovnakým predmetom, pretože sa jedná o rovnakého NN. Ale jeho menovec, ktorý sa iba zhodou okolností tiež menuje NN, musí mať iný predmet. Môže mať napr. inú lokalitu (mesto), ale keby aj všetky ostatné údaje boli rovnaké, potom CA použije k rozlíšeniu jedinečné meno dn. Qualifier alebo jedinečné meno serial. Number pri kvalifikovaných certifikátoch. 17

PKI – Identifikačné údaje používateľa, rozšírenia certifikátu o o o V predmete certifikátu spravidla PKI – Identifikačné údaje používateľa, rozšírenia certifikátu o o o V predmete certifikátu spravidla využívame širšiu paletu atribútov jedinečných mien ako pri jedinečnom mene vystaviteľa, kde by sme mali byť striedmy, aj keď softvér má podporovať nejrôznejšie atribúty. Pri certifikátoch koreňových CA obsahuje predmet aj vystaviteľ rovnaké údaje. Koreňová CA si podpisuje certifikáty sama sebe – vydáva tzv. self-signed certifikáty. Mnohé údaje, ktoré se „nevojdú“ do predmetu certifikátu, je možné uložiť do rozšírenia certifikátu. q Rozšírenia certifikátu o o To, čo sa nevošlo do predchádzajúcich položiek certifikátu, sa snažíme uložit do niektorého z rozšírení Aj keď rozšírenie je definované vcelku všeobecne, tak je aj pri rozšírení ťažkosť, podobne ako pri atribútoch predmetu certifikátu, spočívajúca v tom, že aplikácia s niektorým rozšírením nebude počítať – nebude poznať, k čomu nejaké konkrétne rozšírenie slúži. Tento problém rieši položka závažnosť rozšírenia (critical). Táto položka oznamuje, či je rozšírenie kritické alebo nie. V prípade, že je táto položka nastavená na TRUE, potom je rozšírenie označené ako kritické. 18

PKI - Najčastejšie používané rozšírenia certifikátu 19 PKI - Najčastejšie používané rozšírenia certifikátu 19

PKI – rozšírenie certifikátu, Authority Key Identifier q Identifikátor kľúča certifikačnej autority – Authority PKI – rozšírenie certifikátu, Authority Key Identifier q Identifikátor kľúča certifikačnej autority – Authority Key Identifier o o o CA má tak pomerne dlhú dobu dva certifikáty, ktoré sa prekrývajú. Niektorí používatelia majú svoj certifikát podpísaný „starým“ certifikátom CA a iní „novým“ certifikátom CA. Oba certifikáty CA budú mať rovnaký predmet. Budú sa líšiť sériovým číslom a verejným kľúčom. V certifikáte používateľa je však v položke vydavateľ (issuer) uvedený iba predmet z certifikátu CA, ktorým je certifikát používateľa podpísaný. Lenže ako zostaviť reťazec certifikátu, keď máme dva certifikáty CA s rovnakým poľom predmet? Na identifikáciu je možné použiť sériové číslo alebo samotný verejný kľúč z certifikátu, ale použitie rozšírenia „Identifikátor rozšírenia verejného kľúča CA“ je podstatne jednoduchšie. Príkladom využitia tohto rozšírenia je na nasledujúcom obrázku. CA vystavuje svojim používateľom certifikáty platné najviac 1, 5 roka. Sama CA si vydáva certifikáty CA platné 4 roky. Preto 1, 5 roka pred vypršaním svojho certifikátu si musí vydať nový certifikát. Pokiaľ by napr. 1 rok pred vypršaním certifikátu CA vydala používateľovi certifikát podpísaný súkromným kľúčom prislúchajúcim k starému certifikátu, potom by v poslednom 0, 5 roku platnosti takto vydaného používateľského certifikátu bola ťažkosť s overovaním certifikátu: certifikát používateľa by bol platný, ale pri overovaní tohto certifikátu by sa narazilo na to, že už nie je platný príslušný certifikát CA. V dobe označenej na obrázku otáznikom sú platné dva certifikáty CA. 2. používateľov certifikát je podpísaný starým certifikátom CA a 3. používateľov certifikát novým certifikátom CA. Pritom v 2. aj 3. certifikáte je uvedená rovnaká CA. Ako má teda softvér poznať, ktorým certifikátem CA má overovať 2. a ktorým 3. používateľov certifikát? Tj. na overenie certifikátu je treba vytvoriť reťazec certifikátov až ku koreňovému certifikátu. Pre uľahčenie tvorby tohto reťazca certifikátov slúži rozšírenie 20 identifikátor kľúča certifikačnej autority.

PKI – rozšírenie certifikátu, Authority Key Identifier 21 PKI – rozšírenie certifikátu, Authority Key Identifier 21

PKI – rozšírenie certifikátu, Authority Key Identifier q q Na predchádzajúcom obrázku je otáznikom PKI – rozšírenie certifikátu, Authority Key Identifier q q Na predchádzajúcom obrázku je otáznikom vyznačená doba, počas ktorej platia dva certifikáty CA. Pre overenie 2. certifikátu používateľa je nevyhnutný verejný kľúč zo starého certifikátu CA a pre overenie 3. certifikátu používateľa je treba verejný kľúč z nového certifikátu CA. Pretože položka issuer vo všetkých certifikátoch používateľa môže byť rovnaká, tak práve identifikátor kľúča CA určuje, ktorý z certifikátov CA je nevyhnutný na overenie certifikátu používateľa. Identifikátor kľúča certifikačnej autority, ktorá certifikát vydala, je vo svojej podstate rozšírením poľa vystaviteľ certifikátu (issuer) o identifikáciu kľúča. Zatiaľ čo v poli vystaviteľ certifikátu je iba predmet certifikátu, ktorého príslušným súkromným kľúčom bol certifikát vydaný, tak v rozšírení „identifikátor kľúča CA“ môže byť naviac i sériové číslo certifikátu, ktorého príslušným súkromným kľúčom bol certifikát podpísaný. Tj. potom je ľahko vytvárať reťazce certifikátov na overenie cerifikátu. 22

PKI – Kvalifikované certifikáty q Kvalifikovaný certifikát je zvláštny typ certifikátu, ktoré používa EÚ PKI – Kvalifikované certifikáty q Kvalifikovaný certifikát je zvláštny typ certifikátu, ktoré používa EÚ vo svojej legislatíve. o o o Zvláštny nie je ani svojou syntaxou (RFC-5280). Zvláštnosť je v právnej oblasti. Cieľom kvalifikovaného certifikátu je aj po právej stránke nahradiť rukou písaný podpis elektronickým podpisom. Kvalifikovaný certifikát je uvedený v RFC-3039. (Je asi jediné RFC, ktoré vychádza z európskych skúseností. ) Kvalifikovaný certifikát sa vydáva fyzickej osobe (nie napríklad serveru). Kvalifikovaný certifikát obsahuje identifikáciu držiteľa certifikátu založenú na oficiálnej identifikácii osoby alebo na jeho pseudonyme. Certifikačná autorita vždy pozná konkrétnu osobu, kterej certifikát vydala. Predmet certifikátu musí byť jednoznačný pre konkrétnu osobu, tj. dve rôzne osoby nemôžu mať vydaný certifikát so zhodným predmetem. Táto podmienka musí byť splnená po celú dobu existencie konkrétnej CA. Na dosiahnutie tejto podmienky je možné použiť atribút serial. Numer. Keby dve osoby mali mať rovnaké predmety, potom se odlíšia hodnotou v položke serial. Numer. Pri kvalifikovaných certifikátoch nestačí, aby bol iba predmet jednoznačný pre konkrétnu osobu, ale certifikačná autorita nesmie vydať dvom rôznym osobám certifikát, ktorý by mal rovnaký verejný kľúč. Tj. certifikačná autorita musí po dobu svojej existence archivovať i verejné kľúče, ktoré používateľom podpísala. Podľa zákona o elektronickom podpise je nevyhnutné, aby boli kvalifikované certifikáty používané pre styk so štátnou správou vydávané štátom akreditovaným certifikačnými autoritami. RFC-3039 určuje atribúty položiek vydavateľa certifikátu, predmet certifikátu a aké rozšírenia môžu byť použité v kvalifikovanom certifikáte. 23

PKI – Žiadosť o odvolanie certifikátu q Žiadosť o odvolanie certifikátu o o o PKI – Žiadosť o odvolanie certifikátu q Žiadosť o odvolanie certifikátu o o o Používateľ príjde o svoj súkromný kľúč (stratí ho, vyzradí ho). Potom je potrebné príslušný certifikát verejného kľúča odvolať. Pri odvolávaní certifikátu nejde o to, postupovať podľa nejakých noriem, ale ide předevšetkým o rýchlosť. Pokiaľ súkromný kľúč máte, potom pošlete žiadosť o odvolánie certifikátu na CA napr. elektronickou poštou. Správu elektronickej pošty podpíšete súkromným kľúčom patriacemu verejnemu kľúču v odvolávanom certifikáte. (Pokiaľ je certifikát určený na podpisovanie pošty. ) Pokiaľ o súkromný kľúč používateľ príjde alebo certifikát nie je určený na overovanie elektronického podpisu, potom elektronické cesty zlyhávajú. Niektoré CA pri vydaní certifikátu pre také prípady vystavia jednorázové heslo pre odvolanie certifikátu. Pokiaľ toto heslo používateľ pozná, potom je možné odvolať certifikát telefonicky, faxom alebo nepodpísanou elektronickou poštou s uvedením jednorázového hesla. Pokiaľ nepoznáte ani jednorázové heslo, potom nezbýva používateľovi nič iné, ako s dokladmi totožnosti a zmluvou o vydaní certifikátu vydať sa na registračnú autoritu. Pokiaľ príjdete úplne o všetko, potom máte problém. V takomto prípade to ale asi nie je ten najväčší problém ktorý máte. 24

PKI – Zoznam odvolaných certifikátov q Zoznam odvolaných certifikátov – CRL (Certificate Revocation List) PKI – Zoznam odvolaných certifikátov q Zoznam odvolaných certifikátov – CRL (Certificate Revocation List) o Certifikát môže stratiť svoju platnosť tak, že v v v o o o vyprší, tj. uplyne čas not. After uvedený v certifikáte Držiteľ certifikátu alebo jeho zamestnávateľ požiada o odvolanie certifikátu Samotná CA odvolá certifikát. CA odvolaný certifikát zverejní na zozname odvolaných certifikátov (Certificate Revocation List - alebo CRL). Mechanizmus žiadosti o odvolanie certifikátu zverejňuje CA v dokumente „Certifikačná politika CA“. Žiadost o odvolanie certifikátu nemusí být vykonaná ani elektronickou formou, ale CA môže vyžadovať napr. osobnú účasť používateľa. CRL obsahuje sériové čísla odvolaných certifikátov (CRL môže byť i prázdny). Odvolané certifikáty sa zverejňujú v CRL až do vypršania ich pôvodnej doby platnosti (not. After). Spôsob zverejňovania CRL je opäť uvedený v dokumente „Certifikačná politika CA“. Môže ju napr. vystavovať na webovom servere atď. V rozšírení certifikátu „Distribučné miesta odvolaných certifikátov“ sú uvedené URI, na ktorých CA dává k dispozici CRL. Mechanizmus CRL spočíva v tom, že CA vydáva CRL spravidla v pravidelných intervaloch. V intervale medzi vydávaním CRL zbiera jednotlivé žiadosti o odvolanie certifikátu, ktoré potom zhrnie do nasledúceho CRL. Tj. účinnosť odvolania CRL nie je okamžitá, ale až s vydaním nasledujúceho CRL. Tvar CRL špecifikovala norma X. 509. V Internete sa používa CRL, ktorá vychádza zo špecifikácie CRL podľa normy X. 509 verzia 2, ale táto štruktúra je opísaná v RFC-5280. Podľa nej musí CRL obsahovať: pravdepodobný dátum a čas vydania nasledujúceho CRL, číslo CRL uvedené v príslušnom rozšírení CRL a rozšírenie „Identifikátor kľúča 25 certifikačnej autority“.

PKI – On Line zisťovanie platnosti certifikátu – protokol OCSP q On Line zisťovanie PKI – On Line zisťovanie platnosti certifikátu – protokol OCSP q On Line zisťovanie platnosti certifikátu - OCSP o o o V prípade, že držiteľ certifikátu zistí, že jeho súkromný kľúč bol stratený alebo ukradnutý, potom mechanizmus CRL mu nebude príliš vyhovovať, protože do vydania ďalšieho CRL môže byť jeho súkromný kľúč zneužitý. Pokiaľ používateľ používa certifikát iba v jednej aplikácii (napr. pri styku s bankou), potom najskorej okamžite kontaktuje prevádzkovateľa tejto aplikácie a certifikát si nechá zablokovať. V tomto prípade snáď ani CRL nepotrebuje. Ale pokiaľ používateľ používa certifikát k viacero účelom, potom takúto službu vyžaduje od CA. Túto problematiku rieši protokol OCSP (Online Certificate Status Protocol). Protokol OCSP je protokol typu klient/server. Klient pošle na OCSP server dopyt obsahujúci identifikáciu certifikátu a OCSP server vráti informáciu o tom, či je certifikát odvolaný alebo nie, alebo vráti odpoveď, že mu táto informácia nie je známa alebo nejakú chybovú hlášku. V prípade, že bol odvolaný certifikát CA, potom OCSP server odpovedá na všetky dopyty na platnosť certifikátov touto CA vydaných informáciou, že sú neplatné. Vo svojej podstate protokol OCSP môže byť užitočný i v prípade, že CRL obsahujú príliš veľké množstvo odvolaných certifikátov. Potom pri každej manipulácii s certifikátom by prechádzanie rozsiahleho CRL tak zabralo príliš mnoho času – kdežto protokol OCSP na jednoduchý dopyt vráti jednoduchý výsledok. Problém vyhľadania certifikátu v CRL sa tak presúva na server, ktorý ho môže vedieť riešiť omnoho efektívnejšie. 26

PKI – On Line zisťovanie platnosti certifikátu – protokol OCSP q On Line zisťovanie PKI – On Line zisťovanie platnosti certifikátu – protokol OCSP q On Line zisťovanie platnosti certifikátu - OCSP o o OCSP server môže prevádzkovať samotná CA, potom odpovede OCSP servera (OCSP responder) sú podpísané kľúčom samotnej CA. CA však môže delegovať svoju právomoc na iný server. Potom vydá tomuto serveru certifikát s rozšírením „Rozšírené použitie kľúča“ obsahujúci objekt id-kp-OCSPSigning. Z dôvodov vyvažovania záťaže služby OCSP respondera je možné riešiť službu viacerými servermi. Poslednou možnosťou je, že certifikát OCSP servera nie je ani certifikát CA, ktorý dopytovaný certifikát vydala, ani neobsahuje zmienené rozšírenie, potom v lokálnej konfigurácii OCSP klienta musí byť tento certifikát explicitne uvedený. Táto možnosť sa dá použiť aj v intranete, odkiaľ nie je priame spojenie na oficiálne OCSP servery. Naopak používateľský certifikát môže obsahovať privátne rozšírenie „Prístupové informácie CA“ s objektom id-ad-ocsp špecifikujúce napr. URI, na ktorom beží OCSP server. 27

Digitálny podpis q Jedným zo spôsobov ako preniesť vlastnoručný podpis do elektronického sveta a Digitálny podpis q Jedným zo spôsobov ako preniesť vlastnoručný podpis do elektronického sveta a zaviesť digitálny podpis, je využitie asymetrického šifrovacieho systému. Asymetrický šifrovací systém je možné využiť na vytvorenie digitálneho podpisu používateľa ako napodobenie mechanizmu vlastnoručného podpisu používateľa z reálneho sveta. o Digitálny podpis sa vždy vzťahuje k niečomu, najčastejšie k digitálnemu podpisu súboru (správy). To znamená, že nie je možné digitálne podpísať prázdny súbor (v reálnom svete je podpis prázdneho papiera principiálne možný). o Podpisovateľ pri digitálnom podpise súboru musí najskôr vytvoriť kontrolný súčet súboru (napríklad SHA-2). Po vytvorení kontrolného súčtu súboru podpisovateľ tento kontrolný súčet zašifruje svojím privátnym kľúčom. Zašifrovaný kontrolný súčet predstavuje digitálny podpis súboru. Digitálny podpis sa logicky pripojí k súboru (napríklad zazipovaním do jedného zip súboru). Pri overovaní digitálneho podpisu overovateľ najprv oddelí podpis od súboru a ďalej vykoná tieto činnosti: o q o o Digitálny podpis súboru overovateľ dešifruje verejným kľúčom podpisovateľa. Verejný kľúč vyberie z certifikátu verejného kľúča podpisovateľa. Tento certifikát sa štandardne tiež logicky pripája k podpisovanému súboru. Overovateľ podpisu opäť vypočíta kontrolný súčet súboru a porovná ho s dešifrovaným digitálnym podpisom (čo je kontrolný súčet súboru vypočítaný podpisovateľom). Ak sa oba kontrolné súčty rovnajú, potom digitálny podpis bol úspešne overený. Pokiaľ sú oba kontrolné súčty rôzne, potom digitálny podpis overený nebol a podpis je neplatný. 28

Digitálny podpis 29 Digitálny podpis 29

Digitálny podpis q Celý postup digitálneho podpisovania súboru a overenie digitálneho podpisu je zaznamenaný Digitálny podpis q Celý postup digitálneho podpisovania súboru a overenie digitálneho podpisu je zaznamenaný na predchádzajúcom obrázku. Len pre zaujímavosť si treba všimnúť, že digitálny podpis v elektronickom svete je ešte silnejší ako vlastnoručný podpis v reálnom svete, pretože: o o Digitálny podpis zabezpečuje aj integritu súboru. Ak sa po podpísaní zmení obsah súboru, pri overovaní podpisu sa vypočíta iná kontrolná suma než bola tá kontrolná suma, čo vypočítal podpisovateľ pri podpisovaní súboru, a podpis sa neoverí. Túto vlastnosť vlastnoručný podpis nemá, pretože občan sa podpisuje vždy rovnako a jeho podpis nezáleží od toho, či podpisuje zmluvu na kúpu auta alebo zmluvu na pripojenie sa do internetu. Ako už bolo spomenuté, nie je možné digitálne podpísať prázdny súbor. V reálnom svete je podpísanie prázdneho listu možné. 30