300 likes | 437 Views
PKI (In fraštruktúra verejného kľúča ) , certifikáty a digitálny podpis. Doc. Ing. Ladislav Hudec, CSc., CISA. 1. PKI - Úvod.
E N D
PKI (Infraštruktúra verejného kľúča), certifikáty a digitálny podpis Doc. Ing. Ladislav Hudec, CSc., CISA 1
PKI - Úvod • 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: • 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“. • Okremuvedeného použitia asymetrickej kryptografie a certifikátov existujú na Interneteaj iné aplikácie využívajúce certifikáty: • 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 PKI – oba vychádzajú z X.509, ale protokol SET je výlučne na platby na Internete.) 2
PKI • 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šíreniaako 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ä vymedzeniaspô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? • 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 • Používateľ A potom použije verejný kľúčpoužívateľa B (na obrázku označený VK-B) k zašifrovaniu odosielanejsprávy (4). • Používateľ B potom takto zašifrovanúsprávu dešifruje svojím súkromným kľúčom (SK-B) 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 • Na nasledujúcom obrázku nám vstupuje do hry útočník X(útok Man in the Middle): • 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 odosielanejsprá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ískasprá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 tajomstvostarostlivo uloží. Avšak verejný kľúč neodosialapoužívateľovi B samotný, ale ako súčasť certifikátu. 5
PKI – Certifikácia verejného kľúča • Certifikácia verejného kľúča používateľa sa vykoná takto (viď nasledujúci obrázok): • Používateľ B vygeneruje dvojicu verejný a súkromný kľúč (1), pričom súkromný kľúč si ako tajomstvostarostlivo uloží. • Po vygenerovaní dvojice kľúčovpoužívateľ Bzostaví š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. • Certifikát okrem iného obsahuje informácie o tom: • 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 • Certifikát CA môže byť podpísaný súkromným kľúčomsamotnej 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 malpouží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ôžepoužívateľ B svoj certifikát odoslať (4) používateľovi A, ktorý ho overí a v prípade, že je vystavený prepouží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šifrovaniesprá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 • 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ávarovnaký. 10
PKI - Porovnanie položiek občianskeho preukazu a certifikátu 11
PKI – Certifikát, jedinečné mená • 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 takomzozname 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 aleboRDNSequence) je vždy postupnosť relatívnych jedinečných mien(Relative Distinguished Name). Pritom v jedinečnommene sa môžuaj relatívne jedinečnémená opakovať. • Relatívne jedinečnémeno je množina dvojíc tvorených identifikátorom objektu (napr. Country, Organization, CommonName 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, CommonName=Ivan Biely • Tento zápis sačasto skracuje pomocouskratiek pre identifikátory objektov relatívnych jedinečných mien:C=SK, O=STU, CN= Ivan Biely 12
PKI – Certifikát, jedinečné mená • 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 dvojicelen jeden. Jedinečnémenású tvorené vždy vetvou v strome relatívnych jedinečných mien. 13
PKI – Certifikát, jedinenčné mená • Zaujímavé je, že Ivan Biely môže byť v štruktúre uvedený mnohými spôsobmi: • 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 biely@stu.sk, C=SK, O=STU, CN=Ivan Biely, E=biely@stu.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ýchreťazcoch, v ktorých prichádzado úvahu použitie diakritiky, pripúšťa kódovanie UTF-8. 14
PKI – Identifikačné údaje CA a používateľa • Identifikačné údaje CA (vystaviteľa certifikátu) - Issuer • 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ýchmien. Musia byť podporovnétieto atribúty: country, organization, organizationUnit, dnQualifier, stateOrProvinceName, commonName a podpora domainComponent. Programy by mali byťďalej podporované atribútmi: locality, title, surname, givenName, initials, a generationQualifier. • Identifikačné údaje používateľa (predmet certifikátu) - Subject • 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 serialNumber). • Dôležité je, že prerovnaký 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ý saibazhodou okolností tiež menuje NN, musí mať iný predmet. Môže mať napr. inú lokalitu (mesto), ale kebyaj všetky ostatné údaje bolirovnaké, potom CA použije k rozlíšeniu jedinečné meno dnQualifieralebo jedinečné meno serialNumberpri kvalifikovaných certifikátoch (nezameňovať s číslom certifikátu – to musí byť v každom prípade rôzne). 17
PKI – Identifikačné údaje používateľa, rozšírenia certifikátu • V predmete certifikátu spravidla využívame širšiu paletu atribútov jedinečných mienakopri jedinečnommene 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. • Rozšírenia certifikátu • 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évcelkuvš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 – rozšírenie certifikátu, Authority Key Identifier • Identifikátor kľúča certifikačnej autority – Authority Key Identifier • 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átepouží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 akozostaviť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 svojimpouží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 identifikátor kľúča certifikačnej autority. 20
PKI – rozšírenie certifikátu, Authority Key Identifier • 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átovna overenie cerifikátu. 22
PKI – Kvalifikované certifikáty • Kvalifikovaný certifikát je zvláštny typ certifikátu, ktoré používa EÚ vo svojej legislatíve. • 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ópskychskúseností.) • Kvalifikovaný certifikát sa vydávafyzickej osobe (nie napríklad serveru). Kvalifikovaný certifikát obsahuje identifikáciu držiteľa certifikátu založenú na oficiálnej identifikáciiosobyalebo 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 sozhodný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 serialNumer (nezameňovať s položkou sériové číslo certifikátu). Keby dve osoby mali maťrovnaké predmety, potom se odlíšia hodnotou v položke serialNumer. • 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 • Žiadosť o odvolanie certifikátu • 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 patriacemuverejnemu 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á, potomje 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 • Zoznam odvolaných certifikátov – CRL (Certificate Revocation List) • Certifikát môžestratiť svoju platnosť tak, že • vyprší, tj. uplyne čas notAfter 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 (notAfter). • 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é potomzhrnie 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 certifikačnej autority“. 25
PKI – On Line zisťovanie platnosti certifikátu – protokol OCSP • On Line zisťovanie platnosti certifikátu - OCSP • V prípade, že držiteľ certifikátu zistí, že jeho súkromný kľúč bolstratený 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 • On Line zisťovanie platnosti certifikátu - OCSP • 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 • 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. • 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ý). • 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: • 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 • 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: • 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