Systémy elektronických podpisů

Název algoritmu RSA je zkratkou ze jmen Rona Rivesta, Adi Sharmira a Len Adlemana. Metoda RSA byla poprvé popsána v časopise Scientific American v srpnu roku 1977 [5]. Autoři v ní nabízeli zaslání podrobné dokumentace poštou komukoliv kdo o ní projeví zájem. Dostali i do pozornosti známé organizace NSA. Později vyšla práce [6] už s podrobným popisem RSA. Ještě později se ukázalo, že podobný systém [2] byl popsán už v roce 1973, ale až do roku 1997, podléhala tato práce utajení. V roce 1982 autoři algoritmu založili společnost RSA Security. Algoritmus v roce 1983 patentovala MIT (exkluzivně pro RSA Security) na území USA s číslem U.S. Patent 4405829. Platnost patentu skončila v roce 2000.

Je třeba zmínit, že jde skutečně jen o holý princip. RSA implementované popsaným jednoduchým způsobem není v žádném případě bezpečné.

Zmíněný postup je teoretický. V praxi se většinou postupuje od bodu 4, kdy se zvolí pevně hodnota veřejného exponentu e. Pak se teprve generují p a q, tak aby e bylo nesoudělné s (n).

Obtížnost prolomení RSA je založena na následujícím matematickém problému:

Jsou zadány hodnoty veřejného klíče (N, e) a zašifrovaný text C, jenž je výsledkem operace C = M^e (mod N). Úkolem je dešifrovat C a odhalit tak zprávu M.

Předpokládá se, že problém RSA je co do složitosti řešení ekvivalentni úloze faktorizace (rozložení na součin prvočísel) složeného čísla N. Dokázán byl zatím pouze jeden směr ekvivalence tj. v případě schopnosti faktorizovat modul N, lze z veřejného klíče (N, e) spočítat soukromý klíč (N, d) a odtud oklikou řešit i problém RSA. Důkaz tohoto tvrzení lze najít např. v [1]. Prolomení RSA tedy není obtížnější než faktorizace. Opačný směr zatím dokázán nebyl. Důkaz byl podán [1] jen případě malých hodnot exponentu e ve dvojici veřejného klíče (N, e) např. pro hodnotu e rovnu 3. Pro větší hodnoty e není důkaz znám.

Generování klíčů v RSA je v podstatě proces nalezení dvou velkých prvočísel délek N/2, kde N je délka RSA modulu. Správné generování klíčů má zásadní význam pro bezpečnost RSA. Je vcelku jednoduché najít a podvrhnout uživateli slabý snadno faktorizovatelný modul N výběrem prvočísla p v součinu N = p.q takového, že čísla (p - 1) nebo (p + 1) mají jen malé dělitele. Bezpečná implementace RSA tedy musí při generování prvočísel používat nějaký vhodný ověřený algoritmus, a zároveň vyřadit případné slabé klíče (pravděpodobnost vygenerování slabého klíče je však velmi malá). Podrobný rozbor jak takové kontroly modulu N probíhají, či jak zkontrolovat prvočísla p a q nezávislou třetí stranou bez možnosti odhalení jejich hodnoty lze najít v [19].

Nalézání velkých prvočísel realizuje příslušná implementace RSA zpravidla generováním řady náhodných čísel (standard ANSI X9.31 [20] definuje způsob jak taková čísla hledat) a testováním zda jde o prvočísla. Pravděpodobnost nalezení prvočísla při generování čísla délky N je přibližně rovna hodnotě 1/log(N). Pravděpodobnost nalezení se zvyšuje explicitním vyřazováním sudých čísel. Pokud je použit pevný exponent e, musí se vyřadit i čísla s ním soudělná.

Pro testování prvočíselnosti lze použít buď deterministické nebo pravděpodobnostní algoritmy, které určí zda vygenerované náhodné číslo je prvočíslo s určitou pravděpodobností. Např. standard FIPS 186-2 [23] pro algoritmus DSA používá upraveny Rabin-Millerův algoritmus, který určí prvočíslo s pravděpodobností chyby (1/4)ⁿ, kde n je počet opakování testu na prvočíselnost. Hodnota padesáti opakování se již považuje za dostatečný důkaz, že číslo je prvočíslem. Rabin-Millerův pravděpodobnostní algoritmus je také součástí standardu ANSI X9.31 [20]. Standard PKCS #1 [24] kupodivu žádný postup pro generování klíčů nedefinuje.

Kromě generování modulu N, generuje RSA ještě veřejný a soukromý klíč. Hodnota veřejného klíče je v praxi většinou pevně daná např. 65537. Tato hodnota je doporučena i standardem PKCS #1 [24]. Hodnota soukromého klíče se odvozuje z hodnoty modulu a veřejného klíče. Lze ji velmi rychle realizovat rozšířeným Euklidovým algoritmem.

Přímý způsob jak prolomit RSA je nalezení prvočíselného rozkladu (faktorizace) modulu N na součin prvočísel. Jde o problém, jenž je předmětem zájmu matematiků po staletí počínaje Gaussem a Fermatem. V souvislosti s RSA je dnes stále aktuální. V zásadě se známé algoritmy pro faktorizaci N dají rozdělit na dva typy.

Algoritmy prvního typu využívají případu, kdy N má nějaké speciální vlastnosti. Mezi ně patří např. Pollardova (p - 1) metoda [25]. Metoda využívá případu, kdy prvočíselný faktor (p - 1), má kromě dvojky (p je prvočíslo a (p - 1) je tedy sudé) ještě nějaký malý dělitel. Další metodou je faktorizace pomocí eliptických křivek (ECM Elliptic Curve Method) [26]. Má zajímavou dobu běhu, která závisí nikoliv na velikosti N, ale na velikosti nejmenšího z faktorů N. Maximální velikost faktoru pro použití ECM se v současnosti pohybuje okolo 55 cifer (187 bitů), což je pro faktorizaci běžného RSA modulu stále málo. Problematika faktorizace modulu N majícího některé zmíněné speciální vlastnosti je podrobně rozebrána v [29].

Algoritmy druhého typu pracují s obecným složeným číslem N. Patří mezi ně algoritmus Quadratic sieve (QS) z roku 1982 a také nejefektivnější v současnosti známý algoritmus pro faktorizaci velkých (115 cifer a víc) složených čísel Number field sieve (NFS) z roku 1990. Lze se také setkat s názvem GNFS (General number field sieve). Algoritmus pracuje se subexponenciální složitostí, popis algoritmu lze najít v [28].

RSA podpis je součástí mnoha standardů [29]. ISO (Internation Standards Organization) specifikuje podpis v současné verzi standardu ISO/IEC 9796-2:2002. RSA je také součástí mezinárodního bankovního standardu pro zasílání zpráv SWIFT, francouzského bankovního standardu ETEBAC 5. Organizace IEEE specifikuje RSA ve standardu IEEE P1363 a P1363a. Nejčastěji se lze setkat se standardem pro americký finanční sektor ANSI X9.31 a standardy PKCS přímo od firmy RSA Security.

V prostředí EU se lze s RSA setkat ve specifikaci ETSI TS 102 176-1  Algorithms and Parameters for Secure Electronic Signatures  Hash functions and asymmetric algorithms definující algoritmy a další postupy pro vytváření digitálních podpisů. Norma nedefinuje vlastní schémata, ale odkazuje na dvě podpisová schémata PKCS #1 v1.5 a PKCS #1 PSS z PKCS #1 [24]. Protože PKCS standardy neobsahují metody pro generování klíčů, definuje si tato specifikace své vlastní

V českém prostředí platí Výklad k příloze č. 2 vyhlášky č. 366/2001 Sb. [17], který obsahuje v případě RSA zhruba to samé co norma ETSI.

Americký standard FIPS-186-2 [23] povoluje RSA podpis dle normy ANSI X9.31. Draft standardu FIPS-186-3 [61] pak bude pravděpodobnost povolovat i schémata ze standardu PKCS #1 a to PKCS #1 v1.5 a PKCS #1 PSS.

        padded(M) = 6b bb ... bb ba || hash(M) || 3x cc

        

        padded(M) = 00 01 FF ... FF 00 || hashid || hash(M) 
      

Podpis dle PKCS #1 PSS

Zmínka o podpisovém schému PSS (Probabilistic Signature Scheme) se poprvé objevila ve standardu PKCS #1 v2.0 a schéma se objevilo ve verzi 2.1. Oproti původnímu podpisovému schématu je podstatně robustnější a složitější. Vnáší do procesu vytváření podpisu určité množství náhodných prvků, které jsou pak svázány s hašem zprávy a při přijetí zprávy je celek kontrolován na konzistenci. Podpis stejných zpráv se liší v závislosti na přidaných náhodných datech (tzv. salt) a použité maskovací funkci MGF.

Obrázek 3.1. Schéma RSA-PSS ze standardu PKCS #1 2.1

• Parametry vstupující do procesu podpisu jsou k jako délka RSA modulu, H jako hašovací funkce. Předpokládá se, že její výstup má délku kratší než k. MGF je maskovací funkce, která pro vstup (x, i), kde x je řetězec bytů, vrací celočíselný řetězec o i bytech. Posledním volitelným parametrem je délka saltu .

• Maskovací funkcí MGF se v následujícím textu rozumí pseudonáhodná funkce, která má jako vstup libovolný bajtový řetězec, a vrací řetězec zadané délky. Řetězec je pro stejný vstup vždy stejný. Funkce je většinou založena na hašovacích funkcích. Konkrétně v případě PKCS #1 je pro MGF k dispozici pouze SHA-1.

• Pro podepisovanou zprávu M se vypočte hodnota haše H(M), doplní se osmi nulovými byty a náhodně vygenerovaným saltem . Vznikne mezikrok M' takto:

  

• Dále je generován mezikrok s označením DB. Jeho součástí je náhodná posloupnost bytů PS (může být i nulové délky), salt zůstává stejný. Celková délka DB je k - h_len₀ - 1 bytů. Proměnná h_len označuje délku haše.

  

• Poslední mezikrok EM' vznikne následujícím spojením:

  

  Mezi DB a výstupem maskovací funkce se provádí operace XOR.

• Zakódovaná posloupnost EM vznikne nulováním prvních 8 bytů z řetězce EM' zleva.

  Výsledný řetězec EM má délku k bytů a je rovnou podepisován příslušnou podepisovací funkcí.

• Pokud se M' rovná položce H z dekódovaného podpisu, je podpis platný.

V srpnu roku 1991 navrhnul americký NIST (The Natinal Institute of Standards and Technology) nový standard pro vytváření elektronického podpisu. Návrh standardu nesl název DSS je veden pod označením FIPS-186 (Federal Information Processing Standard).

V návrhu byly zmíněny tyto cíle:

V roce 1994 byl nakonec tento návrh přijat jako standard [8] pro práci s informacemi bez označení stupně utajení (unclassified information). V roce 2000 pak byl do standardu přidán i zmíněný algoritmus RSA (ve stejné době vypršel i patent na RSA) odkazem na standard ANSI X9.31.

Základem FIPS-186 byl v původní verzi pouze jeden algoritmus označený jako DSA (Digital Signature Algorithm). Zveřejnění návrhu vyvolalo tehdy řadu rozporuplných reakcí:

DSA je založen na obtížnosti rešení problému diskrétního logaritmu v konečných grupách s násobením v Z_n. Pro jednoduchost si lze problém představit takto. Je definována grupa G a ní operace násobení *. Např. operace g³ v ní odpovídá provedení operace g*g*g. Problém diskrétního logaritmu je určen rovnící g^x = h, kde g i h jsou známé a úkolem je najít hodnotu x. Zapisuje se jako x = log_g h. První kryptosystém využívající problém diskrétního logaritmu popsali Diffie a Hellman v roce 1976 v návrhu protokolu pro ustavení sdíleného klíče. V roce 1984 byl navržen na stejném základě algoritmus El-Gamal pro šifrování a podpis.

Z popisu parametrů DSA je patrné, že řešení problému diskrétního logaritmu v případě DSA implikuje řešení problému zjištění hodnoty soukromého klíče z veřejného klíče. Obdobně jako u faktorizace velkých složených čísel chybí stále u diskrétního logaritmu důkaz, že jde skutečně o těžký problém. Mezi nejlepší algoritmy řešící problém diskrétního logaritmu patří rošířená varianta algoritmu Number Field Sieve pracující se subexponenciální složitostí.

Podpis je dvojice (r, s) a formátuje se jako řetězec dvou 160-bitových čísel. Podepsaná zpráva je pak trojicí (M, r, s).

Pokud platí, že v = r', pak je podpis platný. Podrobný důkaz tohoto tvrzení lze najít v [8].

V případě, že v <> r', došlo buď k modifikaci zprávy, nebo ji podepsal někdo jiný nebo byla chybně podepsána. V takovém případě je podpis zprávy odmítnut.

Pro generování náhodných čísel potřebných pro vytváření klíčů a klíčů zpráv definuje standard FIPS-186 povolené algoritmy pro generování náhodných čísel (parametry g a k) a klíčů (parametry p a q). Standard nepovoluje žádné jiné metody.

Parametr L zmíněný v úvodu popisu principu DSA hraje v algoritmu podobnou roli jako parametr N v případě RSA. Jeho velikost přímo určuje míru práce jakou by útočník musel vynaložit při pokusu o prolomení algoritmu. Míra poskytnuté bezpečnosti je pro stejnou velikost L v případě DSA a N v případě RSA přibližně stejná [11]. V původním návrhu se počítalo s jeho pevně danou velikostí pouhých 512 bitů, což vyvolalo značnou kritiku. NIST pak ve finální verzi [5] určil tento parametr jako volitelný a to až do velikost 1024 bitů. V blízké době [11] a s předpokládaným vznikem další verze normy FIPS 186-3 se počítá s dalším zvětšováním tohoto parametru až na masivních 15360 bitů.

Parametr q přímo souvisí s podepisováním. Protože je dle standardu volen jaké malé číslo, značně urychluje operaci vytváření podpisu. V budoucnu se počítá se zvyšováním jeho velikosti dle tabulky 3.1 Přibližné srovnání délek klíčů v bitech (srpen 2005) (kde je označen jako N) až na velikost 512 bitů. Velikost soukromého klíče přímo souvisí s použitou hašovací funkcí, jejíž výstup musí být stejně dlouhý.

Definice.  Řádem eliptické křivky E se rozumí celkový počet bodů této křivky a značí se #E. Řádem bodu P se rozumí nejmenší možné přirozené číslo n pro které platí nP = O, kde O je nulový bod.

Problém diskrétního logaritmu nad eliptickou křivkou (ECDLP Elliptic curve discrete logarithm problem), na kterém je ECDSA založeno, je následující úloha:

Je dána eliptická křivka E nad konečným tělesem. Bod P je prvkem E. Dále je zadán bod Q, takový, že platí Q = xP, a x je menší než řád prvku P a platí 1 x < n - 1. Úkolem je nalézt hodnotu x. Úloha je v podstatě stejná jako v případě problému DSA (viz. Problém DSA ), jen se změní operace umocňování g.g.g ... .g = g^x na násobení P + P + P + P ... + P = x.P

Nalezení hodnoty x pro velké hodnoty P je v současné době považováno za obtížný problém.

ECDSA je standardizováno organizací ANSI ve standardu ANSI X9.62 z roku 1998, aktualizovaného v roce 2005 [62]. ECDSA je ve formě odkazu na ANSI standard také součástí FIPS 186-2 [23]. Mezi další aktivity patří:

Ze zmíněných standardů je nejkonkrétnější standard FIPS 186-2, který doporučuje i použití konkrétních konečných prvočíselných těles a binárních těles.

Hašovací funkce jsou kryptografické funkce, které z jakéhokoliv vstupu vypočítají výstup (haš) pevné a krátké délky. Výstup je pro stejný vstup vždy stejný. Délka vstupu může být omezena, např. u SHA-1 na 2⁶⁴ bitů. Délka výstupu se pohybuje mezi 160 bity u funkce SHA-1 až k 512 bitům u funkcí SHA-512 nebo WHIRLPOOL. Hašovací funkce mají široké použití při vytváření elektronického podpisu, neboť podpis nějaké zprávy pomocí technik asymetrické kryptografie vždy probíhá jako podpis haše zprávy.

U výstupu hašovací funkce se předpokládají následující vlastnosti:

Fakt, že kolize je obtížné najít, neznamená, že neexistují. Hašovací funkce má krátký výstup a možných hašů je vždy jen 2^N, kde N je délka výstupu hašovací funkce v bitech. Okolní svět samozřejmě může nabývat hodnot větších než 160 bitů, proto množství vzájemně kolidujících zpráv je velmi veliké, ale stále zůstává problémem jejich nalezení.

V ideální formě se hašovací funkce chová jako náhodné orákulum (random oracle). Orákulum je zařízení, které pro libovolný vstup dává náhodný výstup vždy se stejnou pravděpodobností pro všechny možné prvky výstupní množiny hodnot. Jediným omezením je, že pro stejné vstupní hodnoty dává stejné výstupní hodnoty. Hašovací funkce by se měla chovat právě jako orákulum.

Současné hašovací funkce mají chování blízké náhodnému orákulu, bohužel dokonalé náhodné orákulum zatím stále chybí.

Nejpoužívanější hašovací funkcí je v současnosti SHA-1 publikovaná v roce 1993 nejprve jen jako SHA, později vylepšená a označená jako SHA-1. Původní verze se někdy označuje jako SHA-0. Funkce je standardizována organizací NIST v dokumentu FIPS 180. Funkce produkuje haše délky 160 bitů. Mezi ostatní používané hašovací funkce patří např. RIPEMD-160.

U popisu hašovacích funkcí se lze setkat s pojmem security bits , který je poloviční hodnoty než je délka haše. Označuje se jím míra úsilí, jakou je třeba vynaložit k nalezení dvou libovolných kolidujících zpráv. Uplatňuje se zde tzv. narozeninový paradox. Příkladem může být funkce SHA-1, kde pro nalezení kolize s pravděpodobností 50% je třeba vyzkoušet 1,17.2⁸⁰ možností.

U hašovací funkce SHA-1 se povedlo začátkem roku 2005 čínským kryptologům snížit obtížnost nalezení kolize na 2⁶⁹ operací a později téhož roku na 2⁶³ operací. Potvrdila se tak správnost aktuální snahy nahradit hašovací funkci SHA-1 jinou bezpečnější funkcí.

Americký NIST, který se věnuje standardizaci hašovacích funkcí v dokumentu FIPS 180-2 [78], vydal seznam doporučených hašovacích funkcí (viz. tabulka 3.2 Doporučené hašovací funkce z FIPS 180-2 , přičemž funkce SHA-1 je uvedena jen z důvodu kompatibility s existujícími systémy. NIST předpokládá ukončení používání funkce SHA-1 v roce 2010.

Bezpečnost hašovacích funkcí je aktuálním problémem z několika důvodů. Zatím nebyla nalezena prokazatelně bezpečná hašovací funkce. Narůstají také obavy z definitivního prolomení SHA-1, které by mělo nepředstavitelné následky. Vhodný materiál zabývající se podrobně bezpečností hašovacích funkcí lze nalézt v [77].

Z hlediska algoritmů a elektronických podpisů lze jednoznačně doporučit nasměrování největšího úsilí na správnou implementaci. Který algoritmus vybrat je až sekundární problém. Volba by měla vycházet z konkrétního zadání, které bude implementací řešeno. Např. pro širokou kompatibilitu a rychlé ověřování podpisu lze zvolit RSA. Pro implementaci v prostředí s velmi omezeným výpočetním výkonem pak eliptické křivky.

Pozornost je třeba věnovat také použitým hašovacím funkcím. Příkladem může být ještě donedávna používaná MD5, pro kterou už byly nalezeny postupy pro generování kolizí v řádu minut [76]. U aktuální široce využívané funkce SHA-1 (všechny certifikáty vydávané certifikačními autoritami v České republice) se předpokládá v dohledné době také prolomení. Příkladem může být standardizační organizace NIST, která vydala doporučení zastavit nasazování funkce SHA-1 a používat výhradně hašovací algoritmy ze skupiny SHA-2, konkrétně SHA-224, SHA-256, SHA-384 a SHA-512. Dalším příkladem může být už zmíněná skupina NSA Suite B algoritmů, která uvádí už jen dvě povolené funkce SHA-256 a SHA-384. V nových implementacích je proto třeba použít jiné algoritmy než SHA-1.

Z hlediska obecné bezpečnosti elektronických podpisů bude rozumné podpisové schéma pravděpodobně tím posledním místem, na které bude veden případný útok. Pravděpodobnější bude útok na implementaci podpisového schématu. Nejpravděpodobnější stále zůstává útok na získání soukromého klíče. Operace podepisování s použitím soukromého klíče by proto měla být vždy realizována zabezpečeným zařízením např. čipovou kartou. I když samozřejmě lze realizovat útok i na takový postup, jedná se významný posun proti stavu, kdy je soukromý klíč uložen jen tak na disku.

Má původ ve standardu pro zabezpečení elektronické pošty (PEM Privacy Enhanced Mail), proto je v ASCII formátu a vznikl pomocí kódování Base64. ASCII formát je dále obalen hlavičkami. Kromě certifikátu může obsahovat soukromé i veřejné klíče.

  -BEGIN CERTIFICATE  -
MIIDYzCCAsygAwIBAgIJAPK2Nw+F4NefMA0GCSqGSIb3DQEBBQUAMH8xCzAJBgNV
...
          

Binární formát pro klíče i certifikáty. Jeho překódováním do Base64 a obalením hlavičkami vznikne formát PEM. Standard ASN.1 se věnuje popisu dat a standard DER pak jejich uložení a transportu.

Binární formát pro klíče a certifikáty dle stejnojmenného standardu firmy RSA Security.

Čitelný formát. Je možné jej vytisknout a podepsat a může dobře sloužit jako např. důkaz u soudu.

Certificate:
  Data:
    Version: 3 (0x2)
    Serial Number: 103946 (0x1960a)
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=CZ, CN=I.CA - Test CA, O=Prvni certifikacni autorita a.s.
    Validity
      Not Before: Mar 10 07:59:15 2006 GMT
      Not After : Mar 24 07:59:15 2006 GMT
    Subject: C=CZ, CN=Petr Svoboda/emailAddress=xsvobod7@fi.muni.cz
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      RSA Public Key: (1024 bit)
        Modulus (1024 bit):
          00:b9:85:22:a0:33:15:fb:07:f9:53:90:ef:b3:ec:
            ...
          1e:ff:33:6b:89:df:86:15:af
        Exponent: 65537 (0x10001)
    X509v3 extensions:
      X509v3 Subject Key Identifier:
        82:83:D2:04:7C:55:8D:1A:E4:47:B3:D8:56:...
     X509v3 Certificate Policies:
        Policy: 1.3.6.1.4.1.6625.1.1.3
          User Notice:
            Explicit Text: Jen pro TESTOVACI ucely. 
           (Only for TESTING purposes.)

      X509v3 CRL Distribution Points:
        URI:http://ca.ica.cz/test_ica.crl

      X509v3 Key Usage:
        Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
        S/MIME Capabilities: ......0...+....0050...*.H....*.H..

      Signature Algorithm: sha1WithRSAEncryption
        3e:de:f3:e5:ab:c8:01:02:fd:59:21:43:45:82:37:6e:99:bc:
          ...
        37:73:3b:e4

    

Jedním ze způsobů jak zneplatnit certifikát je umístění jeho sériového čísla do seznamu zneplatněných certifikátů (angl. Certificate Revocation List  CRL). Tento seznam v definovaném formátu je pak pravidelně zveřejňován a aktualizován. Odkaz na umístění seznamu zneplatněných certifikátů je také součástí certifikátu. Na obrázku 4.2 CRL certifikační autority I.CA je certifikát vydaný certifikační autoritou I.CA, který obsahuje odkaz na dvě umístění CRL.

Obrázek 4.2. CRL certifikační autority I.CA

Seznam je číslovaný, obsahuje datum vydání, datum vydání příštího seznamu a je podepsán certifikační autoritou. S postupujícím časem jsou ze seznamu odstraňovány certifikáty u nichž vypršela doba platnosti. Takto popsaný systém je také součástí specifikace X509 verze 2.

Certificate Revocation List (CRL):
  Version 2 (0x1)
  Signature Algorithm: sha1WithRSAEncryption
  Issuer: /C=CZ/CN=I.CA - 
  Qualified root certificate/O=První certifikační autorita, a.s.
  Last Update: Mar 16 04:51:30 2006 GMT
  Next Update: Mar 16 16:51:30 2006 GMT
  CRL extensions:
  X509v3 Authority Key Identifier:
    keyid:51:2E:5F:59:81:25:FF:D1:FE:86:E8:87:2E:D6:8D:0D:59:34:2B:BD

  X509v3 CRL Number:
    776

Revoked Certificates:
  Serial Number: 9A1D2A
    Revocation Date: Jun 30 21:23:00 2005 GMT
...

      

V příkladu je uveden seznam zneplatněných certifikátů certifikační autority I.CA. Je vydáván každých 12 hodin.

Online Certificate Status Protocol (OCSP) představuje další mechanismus jak zjistit, zda byl daný certifikát zneplatněn. Protokol je definovaný v RFC 2560 a funguje jako klient/server. Klient pošle OCSP serveru žádost obsahující identifikaci certifikátu, OCSP server vrátí podepsanou informaci o tom, zda je certifikát platný či nikoliv, případně chybové hlášení, že certifikát nemá v databázi. Oproti CRL přináší OCSP hned několik výhod:

OCSP může být provozován samotnou certifikační autoritou nebo může být tato pravomoc delegována na jiný server. Informace o OCSP serverech může být také přímo součástí certifikátu.

Nevýhodou OCSP je potenciálně zneužitelný záznam provozu OCSP serveru, ze kterého lze rekonstruovat kdo s kým komunikoval.

Problémem ověřování platnosti certifikátů se zabývá pracovní skupina PKIX organizace IETF. Mezi další metody ověřování certifikátů patří například protokol DVCSP pro ověřování dokumentů několik let starých nebo protokol SCVP, který přesunuje veškerou práci s ověřováním z klienta na server.

CMS v RFC 3852 specifikuje strukturu ContentInfo jako zapouzdření pro 6 různých druhů elementů, přičemž zapouzdřen může být vždy jen jeden element. Zapouzdření lze vnořovat. Obsah elementu je specifikován identifikátorem Content Type ve struktuře ContentInfo.

Obsahem contentType mohou být:

      ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

Tato dvojice Content Type a Content tj. srozumitelněji data s označením co jsou zač postupně vstupují do CMS procesu, který s nimi vždy něco provede. Může je např. podepsat, nebo už podepsaná data připravit k odeslání nebo postupně data podepisovat jednotlivými autory.

Budoucí podepsaná zpráva může obsahovat žádný, jeden nebo více podpisů. Pro její vytvoření jsou třeba následující data:

      SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
        signerInfos SignerInfos }

SignerInfos je separátní struktura obsahující kromě podpisů i další důležitá data jako čas podpisu, typ podepsaných dat a kontrolní součet zprávy (tyto hodnoty se také podepisují). Má následující strukturu:

SignerInfo ::= SEQUENCE {
  version CMSVersion,
  sid SignerIdentifier,
  digestAlgorithm DigestAlgorithmIdentifier,
  signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
  signatureAlgorithm SignatureAlgorithmIdentifier,
  signature SignatureValue,
  unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

SignerIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier }

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {
  attrType OBJECT IDENTIFIER,
  attrValues SET OF AttributeValue }

AttributeValue ::= ANY

SignatureValue ::= OCTET STRING

Nakonec zbývá zmínit některé podepisované nepovinné atributy:

Secure MIME je rozšířením standardu MIME o použití šifrování a podpisu v e-mailu. CMS je jednou z jeho součástí. V současnosti je ve verzi 3 a v návrhu je verze 3.1. Standard má pět částí:

Content-Type: application/x-pkcs7-mime;
  smime-type=enveloped-data;
  name="smime.p7m"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;
  filename="smime.p7m"

      

S/MIME má pro svoje rozšíření vyhrazen Content-Type application/pkcs7-mime. Tento MIME objekt nese některý z popsaných typů CMS obsahů. Součástí označení typu je specifikace neseného obsahu v poli Content-Disposition: attachment; filename="smime.p7m", kde je typ nesených dat specifikován příponou souboru (v příkladu 4.9 S/MIME hlavičky klient MS Outlook Expres používá název smime a příslušnou příponu s následujícím možným významem:

Pro podpis definuje S/MIME dva formáty: application/pkcs7-mime s podepsanými daty zapouzdřenými v podpisu a multipart/signed, kde podepsaná data jsou umístěna mimo MIME element s popisem. Výhoda druhého formátu je jasná. Podpis je tvořen jakoby přílohou ke zprávě a poštovní klient nemusí umět interpretovat S/MIME, aby si zprávu přečetl. První formát zas do určité míry chrání zprávu před změnami po cestě k adresátovi.

Při využití systému X.509 je nutné vzít do úvahy, že úkolem certifikátu je svázání identity osoby s jejím veřejným klíčem a zajištění identifikace a autentizace. Ostatní aktéři při vytváření a ověřování elektronického podpisu věří certifikační autoritě, resp. její certifikační politice. Odkaz na certifikační politiku je i součástí certifikátu (toto např. chybělo v X.509 v1).

X.509 certifikát funguje jako identifikátor, kterým lze svou identitu prokázat na dálku. Ideálně se hodí v použití se Zákonem o elektronickém podpisu, který striktně zužuje pojem elektronický podpis na identitu jedné osoby. Výhodné je použití certifikátů pro komunikaci s veřejnou správou. Jde o komunikaci s místem kam může v běžném životě přijít kdokoliv bez speciálního oprávnění, prokázat se občanským průkazem a činit další úkony. Otevřenou otázkou zůstává jaké identifikátory v certifikátu uvádět, aby nedošlo k porušení soukromí vlastníka certifikátu.

X.509 certifikáty se tedy hodí do prostředí, kde je třeba provádět identifikaci a autentizaci. V souvislosti s ostatními mechanismy (např. časovými razítky lze řešit i nepopiratelnost). Sekundárním využitím je zajištění důvěrnosti. Lze s nimi dobře kopírovat stávající hieararchické struktury. Naopak nelze slepě zavádět PKI založené na X.509 v prostředích, pro které se alespoň zatím nehodí.

X.509 historicky neřešilo autorizaci tj. přidělení určité množiny práv, zpravidla následující po autentizaci. Proto se v roce 1997 staly součástí X.509 i atributové certifikáty, které kromě identity obsahují i sadu atributů pro autorizaci. Standardizaci atributových certifikátů se věnuje organizace IETF v pracovní skupině PKIX.

Kromě atributových certifikátů se objevily v polovině 90. let i aktivity založené na úplně jiných principech než X.509. Příkladem může být návrhy SPKI (Simple Public Key Infrastructure), která se pozdějí sloučila s návrhem SDSI (Simple Security Infrastructure). Tyto přístupy vypouštějí vazbu identita certifikát. Místo toho zavádí pouze veřejné klíče a předpokládají, že soukromé klíče si drží každá entita v tajnosti a slouží jako důkaz pro vazbu mezi entitou a veřejným klíčem. Architektura pak zavádí i certifikáty ve formě autentizačních tvrzení, které tvoří pětice (Vydavatel, Koho se týká, Lze dále delegovat práva, Přidělená práva, Doba platnosti). Celá pětice je pak podepsána vydavatelem. Entita provádějící ověření podpisu se pak rozhodne na základě kompletní certifikační cesty a přidělených práv.

Na obrázku 4.1 Struktura akreditovaných certifikačních autorit v České republice je zobrazena současná hierarchie mezi certifikačními autoritami v České republice. Nabízí se otázka k čemu je českému občanovi certifikát v zahraničí. V současné době pomalu vznikají certifikační autority, které fungují jako mosty (Bridge CA) mezi jednotlivými certifikačními autoritami, které splňují definované podmínky. V USA například funguje Federal Bridge Certification Authority. Obdobný projekt se připravuje i v EU s názvem Bridge/Gateway Certification Authority (BGCA).

Algoritmus El-Gamal pro vytváření podpisů popsal [47] kryptolog Taher ElGamal v roce 1984. Je založen stejně jako jeho pozdější varianta DSA na problému diskrétního logaritmu. Na stejném problému funguje i šifrovací algoritmus El-Gamal, který ale používá jiné funkce než v El-Gamal podpisovém schématu. Protože použití obou algoritmů není vázáno patenty, stal se El-Gamal součástí zejména volně šiřitelného GnuPG. Podpisové schéma El-Gamal funguje následujícím způsobem.

Bezpečnost El-Gamal schéma přímo závisí na problému diskrétního logaritmuu.

V souvislosti s použitím podpisového schématu El-Gamal v GnuPG, byla v roce 2003 objevena závažná chyba v jeho GnuPG implementaci. Pro urychlení operace umocňování při operaci šifrování přišli tvůrci v roce 2000 s nápadem používat menší hodnoty soukromého klíče x a klíče zprávy k. Pokud byl pak takový klíč použit místo k šifrování k podpisu zprávy, existoval způsob jak odhalit soukromý klíč z podepsané zprávy a veřejného klíče [48]. E-mail s informací o tomto problému od jednoho z autorů lze najít v [49] a podrobnou analýzu problému v [50].

Proces ověření podpisu může skončit třemi způsoby.

WS-Security přidává do SOAP zprávy element <Security> s bezpečnostními informacemi. Element je vždy buď bez určení příjemce nebo s jedním daným příjemcem (SOAP Actor) jako atribut v hlavičce Security. Elementy se mohou v SOAP zprávě opakovat. Základem bezpečnostní informace je nějaké tvrzení, např. jsem uživatel xsvobod7 . Tvrzení se podloží důkazem, např. zde je podpis mého jména a přiložený X.509 certifikát.

Element <Security> může obsahovat následující tokeny.

Vytvoření podpisu probíhá stejně jako při podpisu XML dokumentu. Při vytváření podpisu je třeba vzít k úvahu, že nelze podepsat celou SOAP zprávu, neboť její hlavičky se mohou měnit. Podepisující by tedy neměl používat formu XML podpisu Enveloped signature (podle obrázku 6.2 Enveloped Singature ). Podpis se umisťuje do elementu <Security>, který by měl být v SOAP právě před všemi ostatními elementy. Lze v něm umístit i více podpisů, přičemž nové podpisy se umisťují před staré.

Dále už pro podpis platí celkem jasná pravidla. Neměl by se podpisovat obsah, u něhož se dá čekat nějaká změna při předávání SOAP zprávy. Komunikující strany by také neměly měnit obsah již jednou podepsaných dat.

Ověřování podpisu probíhá stejně jako ve standardu pro XML podpis. WS-Security přidává další dvě okolnosti, za kterých může být podpis odmítnut.

Standard WS-Security je velmi jednoduchý základ pro budování dalšího zabezpečení webových služeb. Například zasílání podepsaných zpráv nezabezpečeným kanálem je vystaveno riziku útoku přehráním. Skutečné implementace už musí zahrnovat další mechanismy, které nejsou součástí WS-Security. Zprávy mohou obsahovat např. podepsaná časová razítka, podepsaná sekvenční čísla. Lze definovat také expiraci zpráv.

Specifikací navazujících na WS-Security je celá řada na různém stupni standardizace. Většinou pochází od firem IBM a Microsoft. Několik příkladů aktivit:

Tento draft vydala organizace EESSI poprvé v květnu 2001. Poslední verze byla vydaná v červenci 2005 jako dvojice

Z hašovacích funkcí se v poslední verzi objevily zejména SHA funkce s prodlouženou délkou haše SHA-224 a SHA-256. Ve standardu samozřejmě zůstaly i původní SHA-1 a RIPEMD-160 z důvodu kompatibility. Standard doporučuje nové implementace zakládat výhradně na prodloužených SHA funkcích. Nově byla také začleněna hašovací funkce WHIRLPOOL (standardizovaná v ISO/IEC 10118-3) jako doporučení z projektu NESSIE. Přehled hašovacích algoritmů je v tabulce 8.1 Hašovací funkce .

Z asymetrických algoritmů zůstává trojice RSA, DSA, ECDSA (a varianta ECGDSA). Z podpisových schémat s paddingem je v případě RSA doporučeno použit RSA-PSS (viz. Podpis dle PKCS #1 PSS ). Oproti původnímu návrhu z roku 2001 se objevila ještě podpisová schémata pro RSA podle ISO/IEC 9796-2. Maji stejně jako RSA-PSS náhodný výstup. Ve standardech ISO jsou označena jako digital signature scheme 2 a digital signature scheme 3 .

K podpisovým schématům ještě přibyly varianty RSA s SHA-224 a RSA s SHA-256. Jinak jsou povolené kombinace vždy asymetrický algoritmus a SHA-1, v případě RSA i RIPEMD-160.

Pro generování klíčů je možné použít jak generátory náhodných, tak i pseudonáhodných čísel. Pro generování klíčů, které se použijí více než jednou (např. soukromý/veřejný klíč) se doporučuje použít náhodná čísla.

Nakonec standard uvádí tabulku 8.2 Podpisová schémata v čase dle ETSI v roce 2005 s odhadem jak dlouho zvolené délky klíčů vydrží v čase:

Draft standardu ETSI ES 201 733 Electronic Signature Formats pro formáty elektronického podpisu se poprvé objevil v roce 1999 a konečná verze 1.1.3 tohoto standardu byla schválena v květnu 2000. Standard měl následující obsah:

Tato norma byla následně rozšířena a aktualizována technickou specifikací ETSI TS 101 733. Název zůstal stejný. První verze 1.2.2 byla vydána v prosinci 2000. Norma ETSI 101 733 je v současné době ve verzi 1.6.3 ze září 2005 a na vydání čeká draft 1.7.3 z ledna 2006. Novější norma také změnila název na CMS Advanced Electronic Signatures (CAdES) .

ETSI TC ESI vydalo krátkou technickou specifikaci ETSI TR 102 047  Internation Harmonization of Electronic Signature Formats shrnující výsledky pokusů o sladění evropské standardizační práce s mezinárodními organizacemi. U organizace IETF jde hlavně o RFC 3126  Electronic Signature Formats for long term electronic signatures, které má stejná obsah jako ETSI TS 101 733. V tomto případě jde o běžné podpisy. V oblasti XML podpisů získal u W3C status poznámky standard XML Advanced Electronic Signatures (XAdES) v poslední verzi z února 2003. Opět jde o stejný obsah jako má standard ETSI TS 101 903  XML Advanced Electronic Signatures (XAdES) . V oblasti podpisů v XML dokumentech spolupracuje ETSI také s organizací OASIS.

Dokument ETSI TR 102 040  International Harmonization of Policy Requirements for CAs issuing Certificates shrnuje výsledky práce na harmonizaci požadavků týkajících se práce certifikačních autorit (ETSI TS 101 456 a ETSI TS 102 042) s ostatními mezinárodními standardy. Jde zejména o:

V přípravě je také ETSI TR 102 458  US Federal PKI to EU Qualified Certificate Policy (ETSI TS 101 456) mapping. Ale specifikaci zatím ETSI neuvolnilo ke stažení.

Požadavky na postupy certifikační autority vydávající kvalifikované certifikáty definuje ETSI TS 101 862  Qualified Certificate Profile. První verze 1.1.1 byla vydána v prosinci 2000. V současné době je dokument ve verzi 1.3.3 z ledna 2006. Vychází z RFC 3739  Internet X.509 Public Key Infrastructure: Qualified Certificates Profile, která je založena na RFC 3280  Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Pro obsah kvalifikovaného certifikátu zavádí ETSI TS 101 862 některé povinné prvky:

Zabývá se jimi ETSI TS 101 456  Policy requirements for certification authorities issuing qualified certificates. První verze 1.1.1 byla vydána v prosinci 2000. V současné době je dokument ve verzi 1.4.1 z února 2006. Tato norma byla ve verzi 1.3.1 přejata jako vůbec první česká přejatá ETSI norma ČSN ETSI TS 101 456 v1.3.1. s platností od 1.3.2006. Norma se týká hlavně realizace certifikační politiky. Zabývá se životností klíčů, certifikátů, ochranou klíčů atd. Neřeší časová razítka, atributové certifikáty ani šifrování. Má původ v RFC 2527 Certificate Policy and Certification Practices Framework .

Další specifikace TS 102 042 Policy requirements for certification authorities issuing public key certificates se týká certifikačních autorit vydávajících obyčejné certifikáty a ETSI TS 102 158  Policy requirements for Certification Service Providers issuing attribute certificates usable with Qualified certificates pro certifikační autority vydávající atributové certifikáty ke kvalifikovaným certifikátům.

Tento okruh je zpracován v technické specifikaci ETSI TS 102 023  Policy requirements for time-stamping authorities. V současné době je v druhé verzi 1.3.1 z ledna 2006. Tato norma v původní verzi byla přejata spolu s předchozí normou jako ČSN ETSI TS 102 023 v1.2.1 s platností od 1.3.2006. Norma vychází z protokolu pro vytváření časových razítek ETSI TS 101 861 a RFC 3161  Time-Stamp Protocol (TSP).

Specifikuje zejména životní cyklus klíče pro vydávání časových razítek, formát časového razítka a jen všeobecně doporučuje pravidla pro synchronizaci času.

Specifikace ETSI TR 102 045  Signature policy for extended business model zavádí zejména vícenásobné podpisy (např. podpis svědků atd.), zabývá se platností podpisů v čase, závazky vyplývajícími z podpisu a podpisovými politikami.

Cílem specifikace ETSI TS 102 280  X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons je podle [58] umožnit interoperabilní zpracování a zobrazování informace obsažené v certifikátech a kvalifikovaných certifikátech.

Specifikace ETSI TR 102 044  Requirements for role and attribute certificates se věnuje atributovým certifikátům.

Jedna se o dokument rozdělený na čtyři části. Zkratka CM označuje Cryptographic Module .

Je součástí specifikace CWA 14355  Guidelines for the implementation of Secure Signature-Creation Devices v poslední verzi z roku 2004. Zavádí tři typy zařízení:

Dokument dále zmiňuje různé vhodné implementace (životní cyklus klíčů, princip funkce podpis atd.), např. čipové karty, mobilní telefony, PC a také možné útoky proti těmto zařízením. Bezpečnou implementací se rozumí splnění požadavků z CWA 14169 viz. sekce Bezpečná zařízení pro vytváření podpisu na úrovni EAL 4+ .

Dokument CWA 14169 Secure signature-creation devices EAL 4+ se věnuje zabezpečení třech typů zařízení specifikovaných v sekci Postup pro bezpečnou implementaci elektronického podpisu .

Dokument CWA 14170 Security requirements for signature creation applications v první části popisuje jak vytvářet správně aplikace pro vytváření elektronického podpisu. Druhá část se týká bezpečnostních požadavků na jednotlivé funkční komponenty. Popis jak ověřit splnění těchto požadavků u konkrétní aplikace je už součástí jiné specifikace.

Doporučený postup ověřování elektronického podpisu specifikuje dokument CWA 14171 General guidelines for electronic signature verification v poslední verzi z roku 2004.

Následující sada osmi specifikací definuje postupy pro ověření bezpečnosti systémů pracujících s elektronickým podpisem.

Právní stránkou elektronických podpisů, které z nějakých důvodů nesplňující požadavky direktivy Evropské komise [42] o elektronickém podpisu, se zabývá CWA 14365-1  Guide on the Use of Electronic Signatures  Part 1: Legal and Technical Aspects v poslední verzi z roku 2004.

Právní stránkou elektronických podpisů, které z nějakých důvodů nesplňují požadavky směrnice EU [42] sekce 5.1 o elektronickém podpisu, se zabývá CWA 14365-2 Guide on the Use of Electronic Signatures Part 2: Protection Profile for Software Signature Creation Devices v poslední verzi z roku 2004.

API čipových karet použitých jako prostředek pro bezpečné vytváření elektronického podpisu se věnuje dokument CWA 14890-1 Application Interface for smart cards used as Secure Signature Creation Devices - Part 1: Basic requirements. Hlavním cílem je zajištění kompatibility mezi jednotlivými kartami. Volitelná rozšíření čipových karet jsou specifikována v dokumentu CWA 14890-2 Application Interface for smart cards used as Secure Signature Creation Devices - Part 2: Additional Services.