Infra

1
Infraštruktúra verejného klúca - PKI

• Doc. Ing. Ladislav Hudec, CSc.

1
2
PKI rozšírenie certifikátu, Key Usage

• Použitie klúca Key Usage
• Pomocou tohto rozšírenia je možné obmedzit spôsob
  použitia verejného klúca obsiahnutého
  v certifikáte (resp. jemu prislúchajúceho
  súkromného klúca). Toto rozšírenie obsahuje
  bitový ratazec. Každý bit z retazca 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žívat. Rozšírenie se môže oznacit ako
  kritické, cím sa zamedzí použitia certifikátu
  k iným úcelom než k úcelom vyznaceným
  v certifikáte.
• Význam jednotlivých bitov rozšírenia
• digitalSignature (bit 0) certifikát je urcený
  k elektronickému podpisovaniu dát. Nastavenie
  tohto bitu neoprávnuje k
• Overovaniu pravosti (k tej je nevyhnutné
  nastavenie bitu císlo 1).
• Podpisovaniu certifikátov (k tomu je potrebné
  nastavenie bitu císlo 5)
• Podpisovanie CRL (k tomu je potrebné nastavenie
  bitu císlo 6)  
• nonRepudation (bit 1) certifikát je urcený na
  overovanie pravosti dat (overovanie
  elektronického podpisu)
• keyEncipherment (bit 2) certifikát je urcený na
  šifrovanie klúcov. Klasickým prípadom je
  elektronická obálka, kedy data sú zašifrované
  náhodným symetrickým šifrovacím klúcom, ktorý je
  ku správe pribalený a zašifrovaný práve verejným
  klúcom z takto oznaceného certifikátu.
• dataEncipherment (bit 3) verejný klúc z takto
  oznaceného certifikátu je urcený na šifrovanie
  dat (iných než šifrovacích klúcov)
• keyAgreement (bit 4) certifikát je urcený na
  výmenu klúcov (napr. DH metóda výmeny klúcov)

2
3
PKI rozšírenie certifikátu, Key Usage, Extended
Key Usage

• Význam jednotlivých bitov rozšírenia
• keyCertSign (bit 5) verejný klúc uvedený
  v tomto certifikáte je urcený na verifikáciu
  certifikátov. T.j. súkromný klúc prislúchajúci
  k tomuto verejnému klúcu je možné použit na
  podpisovanie certifikátov.
• cRLSign (bit 6) verejný klúc uvedený v tomto
  certifikáte je možné použit k verifikácii CRL.
• Pokial by sme chceli vydat certifikát so všetkými
  nastavenými bitmi, potom ho vydáme bez tohto
  rozšírenia.
• Rozšírené použitie klúca Extended Key Usage
• Je všeobecnejším riešením pre urcenie úcelov,
  k akým je certifikát urcený
• Pri vydávaní certifikátov je potrebné zaistit,
  aby údaje v rozšíreniach Použitie klúca a
  Rozšírené použitie klúca boli vzájomne
  konzistentné.
• RFC-3280 zavádza tieto objekty Extended Key
  Usage
• Objekt id-kp-serverAuth urcuje, že certifikát je
  urcený na autentizáciu webového servera. Tento
  objekt je konzistentný s nasledujúcimi
  nastavenými bitmi rozšírenia Použitie klúca
  bud digitalSignature a keyEncipherment alebo
  keyAgreement.
• Objekt id-kp-clientAuth urcuje, že certifikát je
  urcený na autorizáciu webového klienta. Tento
  objekt je konzistentný s nasledujúcimi
  nastavenými bitmi rozšírenia Použitie klúca
  digitalSignature aleb keyAgreement.
• Objekt id-kp-codeSigning urcuje, že certifikát je
  urcený na podpisovanie stahovaného software
  (napr. digitálne podpísaných ActiveX komponentov
  alebo digitálne podpísaných Java appletov). Tento
  objekt je konzistentný s nastaveným bitom
  rozšírenia Použitie klúca digitalSignature.

3
4
PKI rozšírenie certifikátu, Subject Alternative
Name

• RFC-3280 zavádza tieto objekty Extended Key
  Usage
• Objekt id-kp-timeStamping urcuje, že certifikát
  je urcený na vydávanie casových peciatok. Tento
  objekt je konzistentný s týmito nastavenými bitmi
  rozšírenia Použitie klúca digitalSignature a
  nonRepudiation.
• Objekt id-kp-emailProtection urcuje, že
  certifikát je urcený na bezpecný mail. Tento
  objekt je konzistentný s týmito nastavenými bitmi
  rozšírenia Použitie klúca bud digitalSignature
  a nonRepudiation alebo keyEncipherment a
  keyAgreement.
• Objekt id-kp-OCSPString je urcený pre protokol
  OCSP. Toto rozšírenie je urcené pre certifikát
  OCSP servera.
• Alternatívne meno predmetu - Subject Alternative
  Name
• Toto rozšírenie umožnuje vložit do certifikátu
  dalšie identifikacnéí údaje, ktoré se nevošli do
  predmetu. Pri vydávaní certifikátu nesmie byt
  opomenutá kontrola aj údajov uvedených v tomto
  rozšírení. Môže tam byt uvedené
• rfc822Name - adresa elektronickej pošty podla
  RFC-822 (napr.biely_at_stu.sk)
• dNSName - DNS meno (napr. meno servera
  www.stu.sk)
• x400Address - adresa elektronickej pošty podla
  noriem radu X.400
• directoryName - adresárové meno podla noriem
  radu X.500
• ediPartyName - meno podla 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

• Certifikacné politiky - Certificate Policies
• Certifikacná politika je skupina dokumentov
  vydaných certifikacnou autoritou. V týchto
  dokumentoch sú opísané postupy, praktiky a ciele
  certifikacnej autotity (CA). T.j. pravidlá, za
  ktorých CA vydáva certifikáty a najmä ako za
  vydané certifikáty rucí. Na rozdiel od niektorých
  iných dokumentov CA je certifikacná politika
  verejným dokumentom.
• Prevádzkovatel CA si spravidla zaregistruje
  identifikátor objektu (OID Object Identifier)
  pre svoje dokumenty. Identifikátory objektu
  certifikacnej politiky sa potom uvádzajú
  v rozšírení certifikátu nazývanom Certifikacná
  politika. Pokial je toto rozšírenie oznacené ako
  kritické, potom softvér overujúci certifikát môže
  certifikát akceptovat jedine v prípade, že je
  schopný interpretovat toto rozšírenie vrátane
  jeho parametrov. Inými slovami musí pre nu byt
  akceptovatelná uvedená certifikacná politika.
• Základné omedzenie - Basic Constraints
• Jadrom cinnosti CA je to, že svojím podpisom rucí
  za údaje uvedené vo vydaných certifikátoch. Na
  nasledujúcom obrázku je znázornené nebezpecie pre
  CA spocívajúce v tom, že CA vydáva certifikáty
  svojim používatelom a zrazu používatel 3 sa
  svojvolne prehlási za CA a vydá certifikáty
  používatelom X a Y. Problém je v tom, že CA rucí
  za takto vydané certifikáty používatelov X a Y
  vdaka tomu, že napr. používatel X dostane retazec
  certifikátov obsahujúci certifikát používatela
  X, certifikát používatela 3 a certifikát CA. To
  znamená, že nie je problém overit platnost takého
  certifikátu (tj. zodpovednost CA za takto vydaný
  certifikát).
• Jeden mechanismus, ako takémuto pocínaniu
  používatela zamedzit, je pomocou rozšírenia
  Použitie klúca, ktorým v certifikátoch
  vydávaných používatelom ich klúc neoznacíme, že
  je ho možné používat 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žnuje oznacit
  certifikát, aby bolo zrejmé, ci sa jedná o
  certifikát CA alebo certifikát koncového
  používatela, nastavením položky cA (ak je
  nastavená na TRUE, potom ide o certifikát CA).
  Pomocou položky pathLenConstraint potom oznámime,
  kolko môže v certifikacnej ceste nasledovat
  certifikátov certifikacný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
  certifikacnej autority môže v certifikacnej ceste
  vyskytovat iba certifikát koncového používatela
  (nie certifikát CA).

6
7
PKI Žiadost o certifikát v tvare PKCS10

• Žiadost o certifikát
• Používatel žiada o certifikát pomocou žiadosti o
  certifikát. Existuje viacero noriem
  špacifikujúcich žiadost o certifikát
• Pomocou formátu PEM. Tento protokol sa ale v
  praxi neujal. Definuje ho RFC 1424.
• Pomocou formátu PKCS10. Definuje ho RFC 2314.
• Pomocou formátu CRMF. Definuje ho RFC 2511.
• Žiadost o certifikát v tvare PKCS10
• Formát tejto žiadosti o certifikát je vo svojej
  podstate akoby certifikátom vydaným samotným
  žiadatelom, t.j. podpísaný privátnym klúcom
  žiadatela. Niektoré položky certifikátu v tejto
  žiadosti pochopitelne nemôžu zadané, pretože ich
  stanovuje CA (SerialNumber, Signature, Issuer a
  pod.)
• Žiadost je podpísaná žiadatelovým privátnym
  klúcom, ktorý odpovedá verejnému klúcu uvedeného
  v žiadosti. Ide teda o dôkaz, že žiadatel vlastní
  príslušný privátny klúc.
• Žiadosti nepodpísané privátnym klúcom žiadatela
  registracná autorita (RA) spravidla odmietne.
  Registracná autorita príjme žiadost a verifikuje
  jej obsah pomocou verejného klúca uvedeného v
  žiadosti. Tým overí, že údaje neboli cestou
  zmenené. Verifikované žiadosti o certifikát
  odovzdá RA certifikacnej autorite na dalšie
  spracovanie.
• Formát, v akom RA odovzdáva overenú žiadost CA,
  štandard RFC 2314 nešpecifikuje. (Touto
  problematikou sa zaoberajú až protokoly CMP a
  CMC.)

7
8
PKI Žiadost o certifikát v tvare PKCS10, CRMF

• Žiadost o certifikát v tvare PKCS10
• Aj ked formát žiadosti podla PKCS10 nie je
  kompatibilný so žiadostou podla PEM, v praxi sa
  ujalo oznacenie žiadost PKCS10 vo formáte PEM.
  Táto žiadost má vo svojej podstate spolocné s
  formátom PEM iba to, že je kódovaná v Base64 a že
  je pred nou vložený retazec BEGIN CERTIFICATE
  REQUEST a za žiadostou je vložený retazec END
  CERTIFICATE REQUEST
• Žiadost o certifikát v tvare CRMF (Certificate
  Request Message Format)
• Je podstatne bohatší formát ako formát PKCS10.
  Rieši niektoré problémy, s ktorými sa žiadost
  PKCS 10 nevie vysporiadat. Žiadost PKCS10 je
  elektronicky podpísaná privátnym klúcom, ktorý
  odpovedá verejnému klúcu v žiadosti. Co ale
  spravit v prípade, ked certifikát nemá byt
  používaný na elektronický podpis? V takomto
  prípade nie je korektné použit elektronický
  podpis co i len v žiadosti o certifikát.
• Žiadost tvaru CRMF umožnuje ako súcast žiadosti
  zaslat aj úctovacie informácie. Žiadost CRMF
  obsahuje tieto položky
• certReq vlastná žiadost o certifikát
• pop obsahuje dôkaz, že žiadatel vlastní
  privátny klúc k verejnému klúcu, ktorý je uvedený
  v žiadosti. Táto položka už nemusí obsahovat
  elektronický podpis.
• regInfo obsahuje dodatocné informácie,
  napríklad kontakt na žiadatela, úctovacie údaje
  za vydanie certifikátu.
• Dôkaz vlastníctva privátneho klúca je potrebné
  vykonat na inom princípe pre klúc urcený na
  elektronický podpis, na šifrovanie a na výmenu
  klúcov. V prípade, že žiadost obsahuje verejný
  klúc na overenie elektronického podpisu, tak sa
  vytvorí elektronický podpis žiadosti ako dôkaz
  (obdoba PKCS10).

8
9
PKI Žiadost o certifikát v tvare CRMF

• Žiadost o certifikát v tvare CRMF (Certificate
  Request Message Format)
• V prípade, že žiadost obsahuje verejný klúc na
  šifrovanie, je nevyhnuté vykonat dôkaz na základe
  šifrovania napríklad tak, že certifikát vydaný CA
  sa zašifruje verejným klúcom žiadatela. Nikto iný
  nemôže takto zašifrovaný certifikát dešifrovat a
  dat ho k dispozícii iba vlastník privátneho klúca.

9
10
PKI Protokoly PKCS7 a CMS

• Protokoly PKCS7 a CMS
• Už bolo ukázané, ako sa certifikát vydá, ako sa
  odvolá. Ako certifikát použit? V Internete sa
  najskôr stretneme so štyrmi spôsobmi
• Použitie certifikátu na elektronické podpisovanie
  a šifrovanie správ (PKCS7 a CMS)
• Použitie certifikátu na prístup na bezpecný
  webový server (SSL ci 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ádace
  pre Windows 2003)
• Protokol PKCS7 bol prevzatý ako RFC pod
  oznacení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 casto hovoríme o PKCS7, a pritom by sme
  mali hovorit o CMS.
• Protokol CMS se snaží byt maximálne spätne
  kompatibilný s protokolom PKCS7.
• Protokoly PKCS7 a CMS sú urcené na zabezpecenie
  dát. Lenže pod slovom zabezpecenie rozumieme ako
  elektronický podpis, tak elektronickú obálku ci
  autentizáciu dat.
• Spracovávané a zabezpecené (výsledné) dáta sú
  vždy urcené dvojicou identifikátor objektu typu
  dat a vlastné data. Ako je znázornené na
  nasledujúcom obrázku, tak do spracovania PKCS7
  (resp. CMS) vstupuje jedna dvojica (napr.
  identifikátor nezabezpecených dat, tj. data
  nezabezpecené data). PKCS7 (resp. CMS) vykoná
  elektronický podpis, tj. výsledkom je dvojica
  identifikátor objektu pre podpísaná data
  podpísané data. Táto dvojica opät vstúpí do
  procesu PKCS7 (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).

10
11
PKI Protokoly PKCS7 a CMS

• PKCS7 môže data spracovávat cyklom napr.
  najprv ich elektronicky podpísat a výsledok potom
  zašifrovat

11
12
PKI Protokoly PKCS7 a CMS

• Ako je znázornené na nižšie uvedenom obrázku,
  správa PKCS7 (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žíva najmä
  pri elektronicky podpisovaných správach, a to
  jednak pre tzv. externý elektronický podpis a
  jednak pre distribúciu samotných certifikátov.

12
13
PKI Protokoly PKCS7 a CMS, typ dat

• PKCS7 š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ároven zašifrované data
  s identifikátorom objektu id-signedAndEnvelopedDat
  a
• Digested Data - data s kontrolným súctom
  s identifikátorom objektu id-digestedData
• Encrypted Data zašifrované data iným spôsobom
  s identifikátorom objektu id-encryptedData.
• CMS prináša tieto úpravy
• Nepodporuje typ Signed And Enveloped Data. Je
  rozumné oddelit šifrovanie dat od elektronického
  podpisovania. Šifrovaním zabezpecujeme data na
  ich prenos Internetom a potom už elektronická
  obálka stráca zmysel . Kdežto elektronický podpis
  mnohokrát chceme aj archivovat. Pokial sa
  podpisovanie spojí so šifrováním, tak je
  nevyhnutné archivovat aj súkromné šifrovacie
  klúce používatelov, co je dlhodobo prakticky
  možné snád iba ako služba CA. Nedá sa predstavit,
  že bežný obcan si sám zaistí archiváciu
  súkromného klúca napríklad po dobu dvadsat rokov.
  Pokial by sa namietalo, že predsa v archíve
  archivujeme šifrované správy, potom sa ale
  najskôr archivujú zašifrované šifrovacím klúcom
  archívu.
• Zavádza typ Authenticated Data autorizované
  data s identifikátorom objektu id-ct-authData.

13
14
PKI Protokoly PKCS7 a CMS, Typ správy Signed
Data

• Typ správy Signed Data
• Tento typ sa používa pri elektronicky podpísanej
  správe. Jedna správa môže obsahovat aj viacero
  elektronických podpisov. Zaujímavostou je, že
  tento typ správy môže byt aj degenerovaný na
  prípad, ked správa neobsahuje žiadny elektronický
  podpis. Tento degenerovaný prípad se používa na
  distribúciu certifikátov a CRL, ked nezáleží na
  obsahu správy.
• Vnútri podpísanej sprá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. Dalšou zaujímavostou je, že položka
  vstupných dat môže byt prázdna. To môže mat dva
  dôvody
• Môže íst o už uvedenú degenerovanú správu
  slúžiacu na distribúciu certifikátov.
• Môže íst o tzv. externý elektronický podpis, kedy
  podpisované data sú prepravované mimo vlastnú
  štruktúru pre elektronický podpis. To je casté
  napr. pri elektronickej pošte. Pri elektronickej
  pošte potom správu rozdelíme na data a
  elektronický podpis. Príjemca, ktorý nemá softvér
  na spracovanie elektronického podpisu, potom môže
  aspon prvú cast správy precítat, co je velakrát
  velmi praktické.

14
15
PKI Protokoly PKCS7 a CMS, Typ správy Signed
Data

• Formát elektronicky podpísanej sprá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ísanej správy. PKCS7 používa
  verziu 1, CMS doporucuje používat verziu 3.
  V prípadoch, ked sú zásadne používané certifikáty
  nemajúce žiadne rozšírenia a ked podpisovaná
  správa je iba typu id-data, tak použit verziu 1.
• Položka digestAlgorithmus obsahuje množinu
  identifikátorov algoritmov použitých na výpocet
  kontrolného súctu.
• Položka encapContentInfo môže obsahovat
  podpisovaná data. Ide opät o dvojicu
  identifikátor objektu (tj. co 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 obsahovat certifikáty,
  ktoré sú pre používatela užitocné na to, aby
  zostavil certifikacnú cestu až ku korenovému
  certifikátu. Nikde však nie je povedané, že by
  tam museli byt všetky certifikáty, ktoré
  používatel bude potrebovat na verifikáciu
  elektronického podpisu, a môžu tam byt aj
  certifikáty, ktoré používatel vôbec nepotrebuje.
  Ale teoreticky by tam mali byt všetky, o ktorých
  si autor správy myslí, že používatel bude
  potrebovat na verifikáciu elektronického podpisu.
  Pri tvorbe takejto správy je dobré si uvedomit,
  že verifikovat ju bude nevyhnutné trebárs za 10
  rokov a mnohé certifikáty v tej dobe už prešlé
  môže byt obtažné obstarávat.
• Položka crls môže obsahovat CRL. O CRL platí to
  isté, co bolo uvedené pri certifikátoch. Opät je
  treba sa vžit do role toho, kto bude elektronický
  podpis po rokoch overovat a teda bude hladat
  príslušné CRL platné v dobe podpísania správy.
• Položka signerInfos obsahuje množinu
  elektronických podpisov. Elektronický podpis
  nemusí byt pocítaný iba zo vstupných dat, ale aj
  napr. z aktuálneho dátumu a casu všeobecnejšie
  z tzv. podpisovaných atribútov.

15
16
PKI Protokoly PKCS7 a CMS, Typ správy Signed
Data
16
17
PKI Protokoly PKCS7 a CMS, Typ správy Signed
Data

• Všeobecne môže správa obsahovat 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 byt požadované
  tiež dva podpisy. Ešte bežnejšie je podpisovanie
  zmlúv. Zmluva je vztah minimálne medzi dvoma
  stranami, takže na zmluve budú tiež minimálne dva
  podpisy atd.
• Posledná položka SignerInfos obsahuje množinu
  elektronických podpisov. Teraz sa podívame na
  elektronický podpis podrobnejšie. Elektronický
  podpis (štruktúra signerInfo) je sama štruktúrou
  zobrazenou na nasledujúcom obrázku.

17
18
PKI Protokoly PKCS7 a CMS, Položka SignerInfos
18
19
PKI Protokoly PKCS7 a CMS, Položka SignerInfos

• Štruktúra SignerInfos obsahuje tieto položky
• Položka version obsahuje verziu. V prípade, že je
  podpisovaný certifikát identifikovaný jedinecným
  menom CA a císlom certifikátu, potom sa použije
  verzia 1 (obdoba PKCS7). V prípade, že je
  podpisovaný certifikát identifikovaný
  identifikátorom klúca 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 byt bud
  sekvencia (jedinecné meno CA, císlo certifikátu)
  alebo identifikátor klúca 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äcším prekvapením bude spôsob,
  akým sa pocíta kontrolný súcet pre vytvorenie
  elektronického podpisu. Problém je totiž v tom,
  že je nevyhnutné vypocítat kontrolný súcet 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úcet pocíta
  z niecoho iného
• Správa neobsahuje žiadny podpisovaný atribút.
  V tomto prípade sa kontrolný súcet vypocíta zo
  vstupných dat, tj. z položky eContent.
• Správa obsahuje podpisované atribúty. V tomto
  prípade musí byt ako podpisované atribúty
  uvedené Kontrolný súcet správy a Typ
  podpisovaných dat. Pre výpocet kontrolného súctu
  na vlastný elektronický podpis sa potom vezmú
  všetky podpisované atribúty. Kontrolný súcet
  podpisovanej správy je tak obsiahnutý nepriamo
  v kontrolnom súcte, z ktorého sa vytvára
  elektronický podpis.
• Položka unsignedAttrs obsahuje nepodpisované
  atribúty podpisu, ktoré se nezahrnujú do výpoctu
  elektronického podpisu. Syntax je podobná
  podpisovaným atribútom.

19
20
PKI Protokoly PKCS7 a CMS, Položka SignerInfos

• Štruktúra SignerInfos obsahuje tieto položky
• Dôležité podpisované atribúty
• Atribút Kontrolný súcet správy (Message Digest)
  obsahuje kontrolný súcet podpisovanej správy.
  Kontrolný súcet sa pocí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 podpisovanej správy atribútom
  Kontrolný súcet 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 cas podpisu (Signing Time)
  obsahuje dátum a cas podpisu.
• Dôležité nepodpisované atribúty
• Atribút Kontrasignatúra (Countersignature)
  obsahuje podpis z podpisu. Každý elektronický
  podpis správy môže obsahovat jeden alebo viacej
  atribútov kontrasignatúra. Tento atribút sa opät
  skladá zo štruktúry SignerInfo, tj. opät obsahuje
  položku sid, z ktorej sa identifikuje certifikát
  nevyhnutný na overenie kontrasignatúry.
  Vstupnými datami na výpocet kontrasignatúry je
  elektronický podpis, tj. položka signature.
• Kontrasignácia je známa napr. pri uzatváraní
  zmlúv. Zmluvy podpíšu ministri zahranicných vecí,
  ale až po schválení parlamentom je kontrasignuje
  prezident republiky.

20
21
PKI Protokoly PKCS7 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 spocívá
  v tom, že správa (vstupné data) sa zašifruje
  náhodne generovaným symetrickým klúcom. 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ý klúc. Ale ho
  neobsahuje len tak, ale zašifrovaný verejným
  klúcom z certifikátu adresáta.
• Takto to perfektne pracuje v prípade, že
  adresátov certifikát obsahuje asymetrický
  šifrovací klúc adresáta napr. pre algoritmus
  RSA. Asi preto, norma PKCS7 je podnikovou
  normou RSA, tak sa jej tvorcovia nezaoberali
  inými možnostami. Norma CMS opisuje celkom tri
  možnosti
• Symetrický šifrovací klúc obsahu správy je
  zašifrovaný verejným klúcom adresáta (už
  spomínaná metóda PKCS7).
• Z verejného klúce adresáta a súkromného klúca
  odosielatela sa vypocíta symetrický šifrovací
  klúc, ktorým odosielatel zašifruje obsah správy
  (metóda Diffie-Hellmanovej výmeny klúca). Adresát
  potom z verejného klúca odosielatela a svojho
  súkromného zistí symetrický šifrovací klúc
  správy. Adresát tak potrebuje verejný klúc
  odosielatela. Preto štruktúra Enveloped Data
  musela byt rozšírená o položku recipientInfos
  obsahujúcu certifikáty odosielatela a prípadne
  CRL.
• Symetrický šifrovací klúc obsahu správy je
  zašifrovaný symetrickým šifrovacím klúcom
  predchádzajúcej správy (master key). Správa preto
  musí obsahovat identifikáciu klúce, ktorým je
  symetrický šifrovací klúc zašifrovaný. Tento
  prípad v podstate nevyžaduje žiadnu asymetrickú
  šifrovaciu metódu (prvýkrát môže byt klúc
  distribuovaný inou cestou).

21
22
PKI Protokoly PKCS7 a CMS, Typ správy
Enveloped Data

• Na obrázku vlavo je elektronická obálka pre dvoch
  adresátov.
• Vytvorenie elektronickej obálky správy je možné
  zhrnút do týchto bodov (dokumentované na
  nasledujúcom obrázku)
• Vygeneruje sa náhodné císlo, ktoré bude použité
  ako symetrický šifrovací klúc pre zašifrovanie
  textu zprávy (1)
• Náhodné císlo (šifrovací klúc) sa zašifruje
  verejnými klúcmi 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 sa oi. vloží 
  zašifrované náhodné císlo (zašifrovaný klúc)
  verejným klúcom príjemcu z jeho certifikátu.
• Data správy sa zašifrujú náhodným císlem
  symetrickým šifrovacím klúcom (6)
• Vytvorí sa štruktúra EncryptedContentInfo (7),
  do ktorej sa vložia zašifrované data.
• Vytvorí sa výsledná správa typu EnvelopedData
  skladajúca sa z verzie, množiny štruktúr
  RecipientInfo a štruktúry EncryptedContentInfo.

22
23
PKI Protokoly PKCS7 a CMS, Typ správy
Enveloped Data
23
24
PKI Protokol DVCSP

• Protokol DVCSP
• Ak obdržím elektronicky podpísané data, potom
  spravidla budem chciet overit elektronický podpis
  týchto dat. Na overenie elektronického podpisu
  dokumentu musím
• Nájst certifikát obsahujúci príslušný verejný
  klúc na overenie tohto dokumentu
• Overit platnost tohto certifikátu. Co je casto
  tažkost, protože
• Musím zistit, ci certifikát nie je na CRL.
  Presnejšie musím zistit, ci certifikát nebol na
  CRL v dobe vytvorenia elektronického podpisu. Tj.
  musím zistit, ci bol certifikát v dobe podpisu
  platný.
• Pokial ide o cerstvý dokument (napr. práve došlú
  elektronickú poštu), potom by som sa mal spýtat
  OCSP servera, ci certifikát nie je odvolaný a na
  aktuálnom CRL nie je iba preto, že od odvolania
  certifikátu proste nové CRL ešte nevyšlo.
• Musím overit elektronický podpis certifikátu. Tj.
  musím nájst certifikát certifikacnej autority,
  ktorá certifikát vydala, a overit jeho platnost.
  Tiež musím overit elektronický podpis certifikátu
  certifikacnej autority tzn., že musím nájst
  retazec certifikátov až k certifikátu, který
  považujem za platný vdaka nejakej predchádzajúcej
  relácii, a u všetkých medzilahlých certifikátov
  overit ich platnost a ich elektronický podpis.
• Pri konecnom certifikáte (certifikát korenovej
  autority) musím zistit, ci sa zhoduje
  s certifikátom, ktorý mám lokálne uložený a
  ktorému dôverujem vdaka nejakej predchádzajúcej
  relácii (napríklad telefonické overenie odtlacku
  verejného klúca v certifikáte). V mnohých
  prípadoch býva týmto certifikátom korenový
  certifikát CA.
• Nakoniec, ked je príslušný certifikát platný,
  môžem jeho verejným klúcom verifikovat dokument.

24
25
PKI Protokol DVCSP

• Ale ono je to ešte zložitejšie v prípade, že  na
  certifikáty aplikujeme certifikacnú politiku. Tj.
  používame rozšírenie certifikacná politika a
  rozšírenie obmedzujúce mená alebo certifikacnú
  politiku apod. V tomto prípade máme v ruke
  overený certifikát z hladiska platnosti
  certifikátu i overený elektronický podpis na nom,
  ale nevieme, ci ho môže použit pre konkrétnu
  aplikáciu. Musíme se vnorit do týchto
  nepríjemných rozšírení a opät overit celý
  retazec certifikátov.
• Je to zložité, ale v prípade, že potrebujeme
  overit dokument niekolko rokov starý, potom
  získanie CRL platných v dobe podpisu dokumentu aj
  získanie všetkých starých certifikátov do
  retazca certifikátov je znacne obtaž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 overit nejaký elektronicky podpísaný
  dokument, potom ho protokolom DVCSP zašleme na
  DVCS server, ktorý nám vráti bud chybové hlásenie
  alebo nám overí pravost (tj. platnost) zaslaného
  dokumentu. Pravost overuje vystavením
  overovacieho certifikátu Data Validation
  Certificate - DVC.

25
26
PKI Protokol DVCSP

• DVCS server je urcený pre dôveryhodné tretie
  strany, ktoré môžu vystavovat overovacie
  certifikáty o
• Držaní dat (vlastníctva dat). Tj. používatel chce
  od DVCS servera certifikát o tom, že v konkrétnom
  case mal nejaké data. Tieto data zašle DVCS
  serveru, ktorý vystavením DVC certifikátu potvrdí
  túto skutocnost. Príkladom môže byt napr.
  overovací certifikát pre vyvinutý softvér.
• Kontrolnom súcte z držaných dat. Je obdobou
  predchádzajúcej možnosti, avšak necertifikujú sa
  celé data, ale iba kontrolný súcet z dat.
  Certifikácia kontrolného súctu sa tiež v
  špeciálnom prípade môže nazývat casovou peciatkou
  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. Pokial má
  dokument viacero elektronických podpisov a iba
  niektoré z nich sa DVCS serveru javia ako
  nedôveryhodné, tak to ešte nemusí znamenat, že
  dokument je celkovo nedôveryhodný. Naopak DVCS
  server môže dokument prehlásit za nedôveryhodný,
  aj ked všetky elektronické podpisy sú na nom
  v poriadku, ale celkový pocet elektronických
  podpisov je nesprávny.
• Platnosti certifikátu. Tj. DVCS server overí, ci
  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 casu v minulosti.
  Tj. ak chcem verifikovat starší dokument
  podpísaný v konkrétnom case, tak se spýtam na
  platnost príslušného certifikátu k danomu case.
  DVCS server by mal mat k dispozícii všetky údaje
  pre zistenie príslušných informácií.

26
27
PKI Protokol DVCSP

• Je zjavné, že overovanie platnosti certifikátov a
  elektronických podpisov dokumentov je netriviálna
  záležitost, pre ktorú je naviac treba i znacné
  množstvo informácií (napr. staré CRL ci staré
  certifikáty certifikacných autorít). Je preto
  výhodné napr. na vnútropodnikovej sieti zriadit
  DVCS server, ktorý tieto záležitosti bude
  vybavovat centrálne. Tým se zamedzí nevyhnutnosti
  všetky uvedené krkolomné overovania vykonávat v
  každej aplikácii.
• Vo verejnom sektore je zase pre používatela
  praktické, ked služby DVCS servera ponúkne
  verejná certifikacná autorita.
• DVCS server môže byt kombinovaný s Evidencnou 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. 

27
28
PKI Protokol TSP

• Time Stamp Protocol (TSP)
• Zatial co protokol DVCSP je pomerne komplikovaným
  protokolom, pri ktorom sa predpokladá, že napr.
  na overovanie elektronického podpisu dokumentu
  budú aplikácie spociatku implementovat iba cast
  protokolu, tak protokol TSP je jednoduchým
  protokolom na vydávanie casových peciatok
  (RFC-3161).
• Protokol TSP je urcený pre server oznacovaný ako
  autorita na vydávanie casových peciatok (Time
  Stamping Authority TSA). Predpokladá sa, že TSA
  bude prevádzkovat nejaká dôveryhodná nezávislá
  organizáce (napríklad CA).
• Ako sme opísali už v prípade protokolu DVCSP, tak
  casovú peciatku elektronického dokumentu
  používatel získa tak, že na TSA zašle kontrolný
  súcet z tohoto dokumentu a TSA mu vráti casovú
  peciatku, co je elektronicky podpísaný zaslaný
  kontrolný súcet.
• Pretože je casová peciatka elektronicky podpísaný
  dokument, tak si hypoteticky môžeme casové
  peciatky nechat overit DVCS serverom.
• TSA je povinná
• Používat dôveryhodný zdroj casu
• Vkladat do každej casovej peciatky cas
• Každá casová peciatka musí mat svoje jednoznacné
  sériové císlo
• Každá casová peciatka musí obsahovat
  identifikátor objektu politiky TSA (obdoba
  certifikacnej politiky pre CA), tj. za akých
  podmienok je možné vydanú casovú peciatku
  používat. Politika TSA by tiež mala obsahovat
  údaj o tom, ci TSA archivuje log vydávania
  casových peciatok, tj. poskytuje možnost dohladat
  žiadost a príslušnú vydanú casovú peciatku.

28
29
PKI Protokol TSP

• TSA je povinná
• TSA nesmie skúmat, z akej správy je kontrolný
  súcet vypocítaný. Iba formálne skontroluje tvar
  kontrolného súctu. (Žiadatel s kontrolným súctom
  zasiela identifikátor objektu algoritmu na
  výpocet kontrolného súctu, takže TSA môže
  skontrolovat napr. dlžku kontrolného súctu apod.)
• TSA nesmie do casovej peciatky vkladat
  identifikáciu žiadatela
• TSA smie svoje súkromné klúce používat iba
  na podpisovanie casových peciatok, a to spôsobom
  uvedeným v politike TSA. Tj. TSA môže mat viacero
  certifikátov a odpovedajúcich súkromných klúcov.
  Každý potom používa pre konkrétnu politiku TSA.
  TSA môže používat klúce rôznej dlžky ci rôznych
  algoritmov tak, aby požívatel bol schopný
  verifikovat elektronický podpis alebo aby se
  optimalizovala réžia pre verifikáciu podpisu.
• TSA môže mat viacero certifikátov. Všetky však
  musia mat práve jedno rozšírenie Rozšírené
  použitie klúca (na podpisovanie casových
  peciatok).

29
30
DAKUJEM ZA POZORNOST
30