In fraštruktúra verejného kľúča - PKI

1. Infraštruktúra verejného kľúča - PKI Doc. Ing. Ladislav Hudec, CSc. 1

2. PKI – rozšírenie certifikátu, Key Usage • Použitie kľúča – Key Usage • Pomocou tohto rozšíreniaje možné obmedziťspôsob použitia verejného kľúča obsiahnutého v certifikáte (resp. jemu prislúchajúceho súkromného kľúča). Toto rozšírenie obsahuje bitový raťazec. Každý bit z reťazca potom odpovedá konkrétnemu spôsobu použitia certifikátu. Ak je príslušný bit nastavený na 1, potom je certifikát k danému použitiu možné používať. Rozšírenie se označí ako kritické, čím sa zamedzí použitia certifikátu k iným účelom než k účelom vyznačeným v certifikáte. • Význam jednotlivých bitov rozšírenia: • digitalSignature (bit 0) – certifikát je určený k elektronickému podpisovaniu dat. Nastavenie tohto bitu neoprávňuje k: • Overovaniu pravosti (k tej je nevyhnutné nastavenie bitu číslo 1). • Podpisovaniu certifikátov (k tomu je potrebné nastavenie bitu číslo 5) • Podpisovanie CRL (k tomu je potrebné nastavenie bitu číslo 6) • nonRepudation(bit 1) – certifikát je určenýna overovanie pravosti dat (overovanie elektronického podpisu) • keyEncipherment(bit 2) – certifikát je určenýna šifrovanie kľúčov. Klasickým prípadom je elektronická obálka, kedy data súzašifrované náhodným symetrickým šifrovacím kľúčom, ktorý je kuspráve pribalený a zašifrovaný práve verejným kľúčom z takto označeného certifikátu. • dataEncipherment(bit 3) – verejný kľúč z takto označeného certifikátu je určenýna šifrovanie dat (iných než šifrovacích kľúčov) • keyAgreement(bit 4) – certifikát je určenýna výmenu kľúčov (napr. DH metóda výmeny kľúčov) 2

3. PKI – rozšírenie certifikátu, Key Usage, Extended Key Usage • Význam jednotlivých bitov rozšírenia: • keyCertSign(bit 5) – verejný kľúč uvedený v tomto certifikáte je určenýna verifikáciu certifikátov. Tj. súkromný kľúč prislúchajúci k tomuto verejnému kľúču je možné použiťna podpisovanie certifikátov. • cRLSign(bit 6) – verejný kľúč uvedený v tomto certifikáte je možné použiť k verifikácii CRL. • Pokiaľ by sme chceli vydať certifikát so všetkými nastavenými bitmi, potom ho vydáme bez tohto rozšírenia. • Rozšírené použitie kľúča– Extended Key Usage • Je všeobecnejším riešením pre určenie účelov, k akým je certifikát určený • Pri vydávaní certifikátov je potrebné zaistiť, aby údaje v rozšíreniach „Použitie kľúča“ a „Rozšírené použitie kľúča“ boli vzájomne konzistentné. • RFC-3280 zavádza tieto objekty Extended Key Usage: • Objekt id-kp-serverAuth určuje, že certifikát je určenýna autentizáciu webového servera. Tento objekt je konzistentný s nasledujúcimi nastavenými bitmi rozšírenia „Použitie kľúča“: buď digitalSignature a keyEncipherment alebo keyAgreement. • Objekt id-kp-clientAuth určuje, že certifikát je určenýna autorizáciu webového klienta. Tento objekt je konzistentný s nasledujúcimi nastavenými bitmi rozšírenia „Použitie kľúča“: digitalSignature aleb keyAgreement. • Objekt id-kp-codeSigning určuje, že certifikát je určenýna podpisovanie sťahovaného software (napr. digitálne podpísaných ActiveX komponentovalebo digitálne podpísaných Java appletov). Tento objekt je konzistentný s nastavenýmbitom rozšírenia „Použitie kľúča“ digitalSignature. 3

4. PKI – rozšírenie certifikátu, Subject Alternative Name • RFC-3280 zavádza tieto objekty Extended Key Usage: • Objekt id-kp-timeStamping určuje, že certifikát je určenýna vydávaniečasových pečiatok. Tento objekt je konzistentný s týmito nastavenými bitmi rozšírenia „Použitie kľúča“: digitalSignature a nonRepudiation. • Objekt id-kp-emailProtection určuje, že certifikát je určenýna bezpečný mail. Tento objekt je konzistentný s týmito nastavenými bitmi rozšírenia „Použitie kľúča“: buď digitalSignature a nonRepudiation nebo keyEncipherment a keyAgreement. • Objekt id-kp-OCSPString je určený pre protokol OCSP. Toto rozšírenie je určené pre certifikát OCSP servera. • Alternatívnemeno predmetu - Subject Alternative Name • Toto rozšírenie umožňuje vložiť do certifikátu ďalšie identifikačnéí údaje, ktoré se nevošli do predmetu. Pri vydávaní certifikátu nesmie byť opomenutá kontrola aj údajov uvedených v tomto rozšírení. Môže tam byť uvedené: • rfc822Name - adresa elektronickej pošty podľa RFC-822 (napr.biely@stu.sk) • dNSName - DNS meno (napr. meno servera www.stu.sk) • x400Address - adresa elektronickej pošty podľa noriem radu X.400 • directoryName - adresárové meno podľa noriem radu X.500 • ediPartyName - meno podľa noriem EDI • uniformResourceIdentifier - URI (napr. http://www.stu.sk) • iPAddress - IP adresa • registeredID - identifikátor objektu. 4

5. PKI – rozšírenie certifikátu, Certificate Policies, Basic Constraints • Certifikačné politiky -Certificate Policies • Certifikačná politika je skupina dokumentov vydaných certifikačnou autoritou. V týchto dokumentoch sú opísané postupy, praktiky a ciele CA. Tj. pravidlá, za ktorých CA vydáva certifikáty, a najmä ako za vydané certifikáty ručí. Na rozdiel od niektorých iných dokumentov CA je certifikačná politika verejným dokumentom. • Prevádzkovateľ CA si spravidla zaregistruje identifikátor objektu (OID – Object Identifier) pre svoje dokumenty. Identifikátory objektu certifikačnej politiky sa potom uvádzajú v rozšírení certifikátu nazývanom „Certifikačná politika“. Pokiaľ je toto rozšírenie označené ako kritické, potom softvér overujúci certifikát môže certifikát akceptovať jedine v prípade, že je schopný interpretovať toto rozšírenie vrátane jeho parametrov. Inými slovami: musí preňu byť akceptovateľná uvedená certifikačná politika. • Základné omedzenie - Basic Constraints • Jadrom činnosti CA je to, že svojím podpisom ručí za údaje uvedené vo vydaných certifikátoch. Na nasledujúcom obrázku je znázornené nebezpečie pre CA spočívajúce v tom, že CA vydáva certifikáty svojimpoužívateľom a zrazu používateľ 3 sa svojvoľne prehlási za CA a vydá certifikáty používateľom X a Y. Problém je v tom, že CA ručí za takto vydané certifikáty používateľov X a Y vďaka tomu, že napr. používateľ X dostane reťazec certifikátov obsahujúci: certifikát používateľa X, certifikát používateľa 3 a certifikát CA. To znamená, že nie je problém overiť platnosť takého certifikátu (tj. zodpovednost CA za takto vydaný certifikát). • Jeden mechanismus, ako takémuto počínaniupoužívateľa zamedziť, je pomocou rozšírenia „Použitie kľúča“, ktorým v certifikátoch vydávaných používateľom ich kľúč neoznačíme, že je ho možné používať k verifikácii certifikátov. 5

6. PKI – rozšírenie certifikátu, Basic Constraints • Základné omedzenie - Basic Constraints • Rozšírenie „Základné obmedzenie“ umožňuje označiť certifikát, aby bolo zrejmé, či se jedná o certifikát CA alebo certifikát koncového používateľa, nastavením položky cA (ak je nastavená na TRUE, potomide o certifikát CA). Pomocou položky pathLenConstraint potomoznámime, koľko môže v certifikačnej ceste nasledovať certifikátov certifikačných autorít pod týmto certifikátom. Napr. Ak je táto položka nastavená na nulu, potom sa pod týmto certifikátom certifikačnej autority môže v certifikačnej ceste vyskytovaťiba certifikát koncového používateľa (nie certifikát CA). 6

7. PKI – Žiadosť o certifikát v tvare CRMF • Žiadosť o certifikát v tvare CRMF • Žiadosť o certifikát v tvare CRMF (Certificate Request Message Format) je podstatne bohatšiaakožiadosť PKCS#10. Rieši totiž niektoré problémy, s ktorými sa žiadosť PKCS#10 nedokáže vyrovnať. Žiadosť PKCS#10 je digitálne podpísaná súkromným kľúčomodpovedajúci verejnému kľúču v žiadosti. Ale čo si počať v prípade, že certifikát nemá byť používaný pre elektronický podpis? V takomto prípade je nekorektné použiť elektronický podpis už len v žiadosti o certifikát. 7

8. PKI – Protokoly PKCS#7 a CMS • ProtokolyPKCS#7 a CMS • Užbolo ukázané, ako sa certifikát vydá, ako sa odvolá. Ako certifikát použiť? V Internete sa najskôr stretneme so štyrmi spôsobmi: • Použitie certifikátu na elektronické podpisovanie a šifrovanie správ (PKCS#7 a CMS) • Použitie certifikátu na prístup na bezpečný webový server (SSL či TLS) • Použitie certifikátu pro vytváranie virtuálnych privátnych sietí (IPsec) • Použitie certifikátu na elektronické podpisovanie kódu (Java aplety, ActiveX komponenty, ovládače pre Windows 2003) • Protokol PKCS#7 bol prevzatý ako RFC pod označením RFC-2315. Avšak postupne i v tejto oblasti došlo k niektorým úpravám, a tak vyšla norma RFC-2630: Cryptographic Message Standard – CMS. Postupne prechádzame na protokol CMS, ale stále často hovoríme o PKCS#7, a pritom by sme malihovoriť o CMS. • Protokol CMS se snaží byť maximálnespätne kompatibilný s protokolom PKCS#7. • Protokoly PKCS#7 a CMS sú určenéna zabezpečenie dát. Lenže pod slovom zabezpečenie rozumieme ako elektronický podpis, tak elektronickú obálku či autentizáciu dat. • Spracovávanéa zabezpečené (výsledné) dáta sú vždy určené dvojicou: identifikátor objektu typu dat a vlastné data. Ako je znázornené na nasledujúcom obrázku, tak do spracovania PKCS#7 (resp. CMS) vstupuje jedna dvojica (napr. identifikátor nezabezpečených dat, tj. „data“ + nezabezpečené data). PKCS#7 (resp. CMS) vykoná elektronický podpis, tj. výsledkom je dvojica identifikátor objektu pre podpísaná data + podpísané data. Táto dvojica opäť vstúpí do procesu PKCS#7 (resp. CMS) a výsledkom je dvojica identifikátor objektu pre data v elektronickej obálke + elektronicky zaobálkované data (vnútri elektronickej obálky sú podpísané data). 8

9. PKI – Protokoly PKCS#7 a CMS • PKCS#7 môže data spracovávať cyklom – napr. najprv ich elektronicky podpísať a výsledok potomzašifrovať 9

10. PKI – Protokoly PKCS#7 a CMS • Ako je znázornené na nižšie uvedenom obrázku, správa PKCS#7 (resp. CMS) sa skladá z identifikátora objektu typu dat (contentType) a vlastných prenášaných dat (content). Vlastné data sú nepovinné. Nepovinných dat sa používanajmä pri elektronicky podpisovaných správach, a to jednak pre tzv. externý elektronický podpis a jednak pre distribúciu samotných certifikátov. 10

11. PKI – Protokoly PKCS#7 a CMS, typ dat • PKCS#7 špecifikuje tieto typy obsahu správ: • Data - všeobecné data s identifikátorom objektu id-data • Signed Data - elektronicky podpísané data s identifikátorom objektu id-signedData • Eenveloped Data – data v elektronickej obálke (zašifrované data) s identifikátorem objektu id-envelopedData • Signed And Enveloped Data - elektronicky podpísané a zároveň zašifrované data s identifikátorom objektu signedAndEnvelopedData • Digested Data - data s kontrolným súčtom s identifikátorom objektu id-digestedData • Encrypted Data – zašifrované data iným spôsobom s identifikátorom objektu id-encryptedData. • CMS prinášatieto úpravy: • Nepodporuje typ Signed And Enveloped Data. Je rozumné oddeliť šifrovanie dat od elektronického podpisovania. Šifrovaním zabezpečujeme data na ich prenos Internetom a potom už elektronická obálka strácazmysel . Kdežto elektronický podpis mnohokrát chceme aj archivovať. Pokiaľ sa podpisovanie spojí so šifrováním, tak je nevyhnutné archivovaťaj súkromné šifrovacie kľúčepoužívateľov, čo je dlhodobo prakticky možné snáďiba ako služba CA. Nedá sa predstaviť, že bežný občan si sám zaistí archiváciu súkromného kľúčanapríklad po dobu dvadsať rokov. Pokiaľ by sa namietalo, že predsa v archíve archivujeme šifrované správy, potom sa ale najskôr archivujúzašifrované šifrovacím kľúčom archívu. • Zavádza typ: Authenticated Data – autorizované data s identifikátorom objektu id-ct-authData. 11

12. PKI – Protokoly PKCS#7 a CMS, Typ správy Signed Data • Typ správy Signed Data • Tento typ sa používapri elektronicky podpísanejspráve. Jedna správa môže obsahovaťaj viacero elektronických podpisov. Zaujímavosťou je, že tento typ správy môže byťaj degenerovaný na prípad, keďspráva neobsahuje žiadny elektronický podpis. Tento degenerovaný prípad se používana distribúciu certifikátov a CRL, keď nezáleží na obsahu správy. • Vnútri podpísanejsprávy je vnorenáspráva, ktorá se podpisuje (vstupné data). Vstupné data sa opät skladajú z identifikátora typu dat a vlastných dat. Ďalšou zaujímavosťou je, že položka vstupných dat môže byť prázdna. To môže mať dva dôvody: • Môže ísť o už uvedenú degenerovanúsprávu slúžiacuna distribúciu certifikátov. • Môže ísť o tzv. externý elektronický podpis, kedy podpisované data sú prepravované mimo vlastnúštruktúru pre elektronický podpis. To je časté napr. pri elektronickej pošte. Pri elektronickej pošte potomsprávu rozdelíme na data a elektronický podpis. Príjemca, ktorý nemá softvérnaspracovanie elektronického podpisu, potom môže aspoň prvúčasťsprávy prečítať, čo je veľakrát veľmi praktické. 12

13. PKI – Protokoly PKCS#7 a CMS, Typ správy Signed Data • Formát elektronicky podpísanejsprávy je znázornený na nasledujúcom obrázku. Význam jednotlivých položiek je tento: • Položka version obsahuje verziuštruktúry elektronicky podpísanejsprávy. PKCS#7 používa verziu 1, CMS doporučuje používať verziu 3. V prípadoch, keďsú zásadne používané certifikáty nemajúcežiadne rozšírenia a keď podpisovaná správa je iba typu id-data, tak použiť verziu 1. • Položka digestAlgorithmus obsahuje množinu identifikátorov algoritmov použitých na výpočet kontrolného súčtu. • Položka encapContentInfo môže obsahovať podpisovaná data. Ide opät o dvojicu identifikátor objektu (tj. čo je to za typ dat, ktoré podpisuje) a prípadne vlastných dat. Nepovinnésúiba vlastné data (a nie identifikátor objektu). • Množina certifikátov môže obsahovať certifikáty, ktoré sú prepoužívateľa užitočné na to, aby zostavil certifikačnú cestu až ku koreňovému certifikátu. Nikde však nie jepovedané, že by tam museli byť všetky certifikáty, ktoré používateľ bude potrebovaťna verifikáciu elektronického podpisu, a môžu tam byťaj certifikáty, ktoré používateľ vôbec nepotrebuje. Ale teoreticky by tam mali byť všetky, o ktorých si autor správy myslí, že používateľ bude potrebovaťna verifikáciu elektronického podpisu. Pri tvorbe takejtosprávy je dobré si uvedomiť, že verifikovať ju bude nevyhnutné trebárs za 10 rokov a mnohé certifikáty v tej dobeuž prešlé môže byť obťažné obstarávať. • Položka crls môže obsahovat CRL. O CRL platí to isté, čo bolo uvedené pri certifikátoch. Opäť je treba sa vžiť do role toho, kto bude elektronický podpis po rokoch overovať a teda bude hľadať príslušné CRL platné v dobe podpísaniasprávy. • Položka signerInfos obsahuje množinu elektronických podpisov. Elektronický podpis nemusí byť počítanýiba zo vstupných dat, ale aj napr. z aktuálneho dátumu a času – všeobecnejšie z tzv. podpisovaných atribútov. 13

14. PKI – Protokoly PKCS#7 a CMS, Typ správy Signed Data 14

15. PKI – Protokoly PKCS#7 a CMS, Typ správy Signed Data • Všeobecne môže správa obsahovať viacero elektronických podpisov. To je bežné aj pri rukou písaného podpisu. Napr. pre platobné príkazy v banke nad stanovený limit môžu byť požadované tiež dva podpisy. Ešte bežnejšie je podpisovaniezmlúv. Zmluva je vzťah minimálne medzi dvoma stranami, takže na zmluve budú tiež minimálne dva podpisy atď. • Posledná položka SignerInfos obsahuje množinu elektronických podpisov. Teraz sa podívame na elektronický podpis podrobnejšie. Elektronický podpis (štruktúrasignerInfo) je sama štruktúrou zobrazenou na nasledujúcom obrázku. 15

16. PKI – Protokoly PKCS#7 a CMS, Položka SignerInfos 16

17. PKI – Protokoly PKCS#7 a CMS, Položka SignerInfos • Štruktúra SignerInfos obsahujetieto položky: • Položka version obsahuje verziu. V prípade, že je podpisovaný certifikát identifikovaný jedinečným menom CA a číslom certifikátu, potom sa použije verzia 1 (obdoba PKCS#7). V prípade, že je podpisovaný certifikát identifikovaný identifikátorom kľúča predmetu, potom sa použije verzia 3. • Položka sid obsahuje identifikáciu podpisovaného (konkrétne obsahuje identifikáciu jeho certifikátu).Identifikáciou môže byť buď sekvencia (jedinečné meno CA, číslo certifikátu) alebo identifikátor kľúča predmetu. • Položka signatureAlgorithm definuje algoritmus použitý na elektronický podpis vrátane jeho príslušných parametrov. • Položka signature obsahuje príslušný elektronický podpis. Asi najväčším prekvapením bude spôsob, akým sa počíta kontrolný súčet pre vytvorenie elektronického podpisu. Problém je totiž v tom, že je nevyhnutné vypočítať kontrolný súčet nielen zo samotných vstupných dat, ale aj z podpisovaných atribútov. Preto se rozlišujú dva prípady a v každom sa kontrolný súčet počíta z niečoho iného: • Správa neobsahuje žiadny podpisovaný atribút. V tomto prípade sa kontrolný súčet vypočíta zo vstupných dat, tj. z položky eContent. • Správa obsahuje podpisované atribúty. V tomto prípade musí byť ako podpisované atribúty uvedené: „Kontrolný súčet správy“ a „Typ podpisovaných dat“. Pre výpočet kontrolného súčtu na vlastný elektronický podpis sa potom vezmú všetky podpisované atribúty. Kontrolný súčet podpisovanejsprávy je tak obsiahnutý nepriamo v kontrolnom súčte, z ktorého sa vytvára elektronický podpis. • Položka unsignedAttrs obsahuje nepodpisované atribúty podpisu, ktoré se nezahrňujú do výpočtu elektronického podpisu. Syntax je podobná podpisovaným atribútom. 17

18. PKI – Protokoly PKCS#7 a CMS, Položka SignerInfos • Štruktúra SignerInfos obsahujetieto položky: • Dôležité podpisované atribúty: • Atribút „Kontrolný súčet správy“ (Message Digest) obsahuje kontrolný súčet podpisovanejsprávy. Kontrolný súčet sa počíta z položky eContent. Identifikátor tohto atribútu je id-messageDigest. • Atribút „Typ podpisovaných dat“ (Content Type) obsahuje identifikátor objektu typu podpisovaných dat. Tým, že sa do elektronického podpisu zahrnie ako obsah podpisovanejsprávy atribútom „Kontrolný súčet správy“, tak typ dat atribútom „Typ podpisovaných dat“, tak sa do elektronického podpisu zahrnú všetky informácie o podpisovaných datach. • Atribút „Dátum a čas podpisu“ (Signing Time) obsahuje dátum a čas podpisu. • Dôležité nepodpisované atribúty: • Atribút „Kontrasignatúra“ (Countersignature) obsahuje „podpis z podpisu“. Každý elektronický podpis správy môže obsahovať jeden alebo viacej atribútov kontrasignatúra. Tento atribút sa opät skladá zoštruktúrySignerInfo, tj. opäť obsahuje položku sid, z ktorej sa identifikuje certifikát nevyhnutný na overenie kontrasignatúry. Vstupnými datamina výpočet kontrasignatúry je elektronický podpis, tj. položka signature. • Kontrasignácia je známa napr. pri uzatváranízmlúv. Zmluvy podpíšu ministri zahraničných vecí, ale až po schválení parlamentom je kontrasignuje prezident republiky. 18

19. PKI – Protokoly PKCS#7 a CMS, Typ správy Enveloped Data • Typ správy Enveloped Data • Táto správa obsahuje data v elektronickej obálke. Na vytvorenie elektronickej obálky správy sú nevyhnutné certifikáty všetkých príjemcov (adresátov). Princíp elektronickej obálky spočívá v tom, že správa (vstupné data) sazašifruje náhodne generovaným symetrickým kľúčom. Každý adresát správy má potom v správe jeden výskyt položky „Informácia pre adresáta“. Štruktúra „Informácia pre adresáta“ v sebe obsahuje ten náhodne generovaný symetrický kľúč. Ale ho neobsahuje len tak, ale zašifrovaný verejným kľúčom z certifikátu adresáta. • Takto to perfektne pracuje v prípade, že adresátov certifikát obsahuje asymetrický šifrovací kľúč adresáta – napr. pre algoritmus RSA. Asi preto, norma PKCS#7 je podnikovou normou RSA, tak sa jej tvorcovia nezaoberali inými možnosťami. Norma CMS opisuje celkom tri možnosti: • Symetrický šifrovací kľúč obsahu správy je zašifrovaný verejným kľúčom adresáta (už spomínaná metóda PKCS#7). • Z verejného kľúče adresáta a súkromného kľúča odosielateľa savypočíta symetrický šifrovací kľúč, ktorým odosielateľzašifruje obsah správy (metóda Diffie-Hellmanovej výmeny kľúča). Adresát potom z verejného kľúča odosielateľa a svojho súkromného zistí symetrický šifrovací kľúčsprávy. Adresát tak potrebuje verejný kľúč odosielateľa. Preto štruktúra Enveloped Data musela byť rozšírená o položku recipientInfos obsahujúcu certifikáty odosielateľa a prípadne CRL. • Symetrický šifrovací kľúč obsahu správy je zašifrovaný symetrickým šifrovacím kľúčom predchádzajúcejsprávy (master key). Správa preto musí obsahovať identifikáciu kľúče, ktorým je symetrický šifrovací kľúčzašifrovaný. Tento prípad v podstate nevyžaduje žiadnu asymetrickú šifrovaciu metódu (prvýkrát môže byť kľúč distribuovaný inou cestou). 19

20. PKI – Protokoly PKCS#7 a CMS, Typ správy Enveloped Data • Na obrázku vľavo je elektronická obálka pre dvoch adresátov. • Vytvorenie elektronickej obálky správy je možnézhrnúť do týchto bodov (dokumentované na nasledujúcom obrázku): • Vygeneruje sa náhodné číslo, ktoré bude použité ako symetrický šifrovací kľúč prezašifrovanie textu zprávy (1) • Náhodné číslo (šifrovací kľúč) sazašifruje veřejnými kľúčmi z certifikátov príjemcov (2, 3 a 4) • Pre každého príjemcu sa vytvorí štruktúra RecipientInfo (5) obsahujúca informácie pre príjemcu. Do tejtoštruktúry saoi. vloží  zašifrované náhodné číslo (zašifrovaný kľúč) verejným kľúčom príjemcu z jeho certifikátu. • Data správy sazašifrujú náhodným číslem – symetrickým šifrovacím kľúčom (6) • Vytvorí saštruktúra EncryptedContentInfo (7), do ktorej sa vložiazašifrované data. • Vytvorí sa výsledná správa typu EnvelopedData skladajúca sa z verzie, množiny štruktúr RecipientInfo a štruktúry EncryptedContentInfo. 20

21. PKI – Protokoly PKCS#7 a CMS, Typ správy Enveloped Data 21

22. PKI – Protokol DVCSP • Protokol DVCSP • Ak obdržím elektronicky podpísané data, potomspravidla budem chcieť overiť elektronický podpis týchto dat. Na overenie elektronického podpisu dokumentu musím: • Nájsť certifikát obsahujúci príslušný verejný kľúčna overenie tohto dokumentu • Overiť platnosť tohto certifikátu. Čo je často ťažkosť, protože: • Musím zistiť, či certifikát nie je na CRL. Presnejšie: musím zistiť, či certifikát nebol na CRL v dobe vytvorenia elektronického podpisu. Tj. musím zistiť, či bol certifikát v dobe podpisu platný. • Pokiaľ ide o čerstvý dokument (napr. práve došlú elektronickú poštu), potom by som sa mal spýtať OCSP servera, či certifikát nie je odvolaný a na aktuálnom CRL nie jeiba preto, že od odvolania certifikátu proste nové CRL ešte nevyšlo. • Musím overiť elektronický podpis certifikátu. Tj. musím nájsť certifikát certifikačnej autority, ktorá certifikát vydala, a overiť jeho platnosť. Tiež musím overiť elektronický podpis certifikátu certifikačnej autority tzn., že musím nájsťreťazec certifikátov až k certifikátu, který považujem za platný vďaka nejakej predchádzajúcej relácii, a u všetkých medziľahlých certifikátov overiť ich platnosť a ich elektronický podpis. • Pri konečnom certifikáte (certifikát koreňovej autority) musím zistiť, či sazhoduje s certifikátom, ktorý mám lokálne uložený a ktorému dôverujemvďaka nejakej predchádzajúcej relácii (napríklad telefonické overenie odtlačku verejného kľúča v certifikáte). V mnohých prípadoch býva týmto certifikátom koreňový certifikát CA. • Nakoniec, keď je príslušný certifikát platný, môžem jeho verejným kľúčom verifikovať dokument. 22

23. PKI – Protokol DVCSP • Ale ono je to eštezložitejšie v prípade, že  na certifikáty aplikujeme certifikačnú politiku. Tj. používame rozšírenie „certifikačná politika“ a rozšírenie„obmedzujúcemená“alebo certifikačnú politiku apod. V tomto prípade máme v ruke overený certifikát z hľadiska platnosti certifikátu i overený elektronický podpis na ňom, ale nevieme, či ho môže použiť pre konkrétnu aplikáciu. Musíme se vnoriť do týchto „nepríjemných“ rozšírení a opät overiť celý reťazec certifikátov. • Je to zložité, ale v prípade, že potrebujeme overiť dokument niekoľkorokov starý, potom získanie CRL platných v dobe podpisu dokumentu aj získanie všetkých „starých“ certifikátov do reťazca certifikátov je značne obťažné. Riešením je protokol DVCSP. • Protokol DVCSP - Data Validation and Certification Server Protocols je špecifikovaný v RFC-3029. Tento protokol v žiadnom prípade nenahradzuje CRL alebo protokol OCSP. Ak potrebujeme overiť nejaký elektronicky podpísaný dokument, potomho protokolom DVCSP zašleme na DVCS server, ktorý nám vráti buď chybové hláseniealebo nám overí pravosť (tj. platnosť) zaslaného dokumentu. Pravosť overuje vystavením overovacieho certifikátu Data Validation Certificate - DVC. 23

24. PKI – Protokol DVCSP • DVCS server je určený pre dôveryhodné tretie strany, ktoré môžu vystavovať overovacie certifikáty o: • Držaní dat (vlastníctva dat). Tj. používateľ chce od DVCS servera certifikát o tom, že v konkrétnom čase mal nejaké data. Tieto data zašle DVCS serveru, ktorý vystavením DVC certifikátu potvrdí túto skutočnosť. Príkladom môže byť napr. overovací certifikát pre vyvinutý softvér. • Kontrolnom súčte z držaných dat. Je obdobou predchádzajúcej možnosti, avšak necertifikujú sa celé data, ale iba kontrolný súčet z dat. Certifikácia kontrolného súčtu sa tiež v špeciálnom prípade môže nazývať časovoupečiatkou dat. • Pravosti elektronického podpisu dat. Tj. DVCS server vykoná všetky uvedené body verifikácie elektronického podpisu pre všetky elektronické podpisy uvedené v zaslanom dokumente k dátumu uvedenom v žiadosti o DVC certifikát. Pokiaľ má dokument viacero elektronických podpisov a iba niektoré z nich sa DVCS serveru javia ako nedôveryhodné, tak to ešte nemusí znamenať, že dokument je celkovo nedôveryhodný. Naopak DVCS server môže dokument prehlásiť za nedôveryhodný, aj keď všetky elektronické podpisy sú na ňom v poriadku, ale celkový počet elektronických podpisov je nesprávny. • Platnosti certifikátu. Tj. DVCS server overí, či certifikát je platný (napr. nie je odvolaný). Dôležité je, že DVCS server to zistí i  k uvedenému dátumu. Dôležité je i to, že DVCS server to zistí i v k uvedenému času v minulosti. Tj. ak chcem verifikovať starší dokument podpísaný v konkrétnom čase, tak se spýtam na platnosť príslušného certifikátu k danomu čase. DVCS server by mal mať k dispozícii všetky údaje pre zistenie príslušných informácií. 24

25. PKI – Protokol DVCSP • Je zjavné, že overovanie platnosti certifikátov a elektronických podpisov dokumentov je netriviálna záležitosť, pre ktorú je naviac treba i značné množstvo informácií (napr. staré CRL či staré certifikáty certifikačných autorít). Je preto výhodné napr. na vnútropodnikovej sieti zriadiť DVCS server, ktorý tieto záležitosti bude vybavovať centrálne. Tým se zamedzí nevyhnutnosti všetky uvedené krkolomné overovaniavykonávať v každej aplikácii. • Vo verejnom sektore je zase prepoužívateľa praktické, keď služby DVCS serveraponúkne verejná certifikačná autorita. • DVCS server môže byť kombinovaný s „Evidenčnou a záznamovou autoritou“, tj. s aplikáciou udržujúcou logy a ukladajúcou overené data pre prípad odmietnutia zodpovednosti za tieto data. 25

26. PKI – Protokol TSP • Time Stamp Protocol (TSP) • Zatiaľ čo protokol DVCSP je pomerne komplikovaným protokolom, pri ktorom sa predpokladá, že napr. na overovanie elektronického podpisu dokumentu budú aplikáciespočiatku implementovaťibačasť protokolu, tak protokol TSP je jednoduchým protokolom na vydávaniečasových pečiatok (RFC-3161). • Protokol TSP je určený pre server označovaný ako „autorita na vydávaniečasových pečiatok (Time Stamping Authority –TSA)“. Predpokladá sa, že TSA bude prevádzkovať nejaká dôveryhodná nezávislá organizáce (napríklad CA). • Ako sme opísali už v prípade protokolu DVCSP, tak časovú pečiatku elektronického dokumentu používateľ získa tak, že na TSA zašle kontrolný súčet z tohoto dokumentu a TSA mu vrátičasovú pečiatku, čo je elektronicky podpísaný zaslaný kontrolný súčet. • Pretože je časovápečiatka elektronicky podpísaný dokument, tak si hypoteticky môžeme časové pečiatky nechať overiť DVCS serverom. • TSA je povinná: • Používať dôveryhodný zdroj času • Vkladať do každejčasovej pečiatkyčas • Každáčasovápečiatka musí mať svoje jednoznačné sériové číslo • Každáčasovápečiatka musí obsahovať identifikátor objektu politiky TSA (obdoba certifikačnej politiky pre CA), tj. za akých podmienok je možné vydanúčasovúpečiatku používať. Politika TSA by tiež mala obsahovať údaj o tom, či TSA archivuje log vydávaniačasových pečiatok, tj. poskytuje možnosť dohľadaťžiadosť a príslušnú vydanúčasovúpečiatku. 26

27. PKI – Protokol TSP • TSA je povinná: • TSA nesmieskúmať, z akejsprávy je kontrolný súčet vypočítaný. Iba formálneskontroluje tvar kontrolného súčtu. (Žiadateľ s kontrolným súčtom zasiela identifikátor objektu algoritmu na výpočet kontrolného súčtu, takže TSA môžeskontrolovať napr. dĺžku kontrolného súčtu apod.) • TSA nesmie do časovej pečiatky vkladať identifikáciužiadateľa • TSA smie svoje súkromné kľúče používaťibana podpisovaniečasových pečiatok, a to spôsobom uvedeným v politike TSA. Tj. TSA môže mať viacero certifikátov a odpovedajúcich súkromných kľúčov. Každý potom používa pre konkrétnu politiku TSA. TSA môže používať kľúče rôznej dĺžky či rôznych algoritmov tak, aby požívateľ bol schopný verifikovať elektronický podpis alebo aby se optimalizovala réžia pre verifikáciu podpisu. • TSA môže mať viacero certifikátov. Všetky však musia mať práve jedno rozšírenie „Rozšírené použitie kľúča“ (na podpisovanie časových pečiatok). 27

28. ĎAKUJEM ZA POZORNOSŤ 28