A CRL és az OCSP technológiák összehasonlítása

 

A CRL és az OCSP technológiák összehasonlítása
Berta István Zsolt

2008. november

Bevezetés

Ha egy tanúsítványhoz tartozó titkos kulcs elvész (kompromittálódik), a tanúsítványt vissza kell vonni. Például, ha egy tanúsítványhoz tartozó intelligens kártyát ellopják, a kártyabirtokos haladéktalanul be kell, hogy jelentse ezt a tanúsítványt kibocsátó hitelesítés szolgáltatónak, aki visszavonja a tanúsítványt.

A hitelesítés szolgáltató köteles a visszavonást közzétenni, hogy minden érintett fél értesüljön a visszavonásról. Aki a tanúsítványt ellenőrzi, annak minden esetben meg kell vizsgálnia, hogy a hitelesítés szolgáltató nem tette-e még közzé a tanúsítvány visszavonását. A fentiek miatt a visszavont tanúsítványokkal többé nem lehet visszaélni.

A tanúsítványok visszavonásának közzétételére ma két különböző technológia terjedt el. Az egyik a visszavonási lista (CRL), a másik pedig az online tanúsítvány-állapot szolgáltatás (OCSP). E dokumentum e két technológiát hasonlítja össze.

Egy példa

Tételezzük, fel, hogy az "aláíró" tanúsítványát "CA1" bocsátotta ki, CA1 tanúsítványát pedig a "root CA".


1. ábra - Példa tanúsítványlánc

A tanúsítványok ellenőrzésének módját az , az aláírások ellenőrzésének módját a írja le. Ezen specifikációk, illetve a tanúsítványokra és elektronikus aláírásokra vonatkozó egyéb szabványok és ajánlások szerint A következő lépéseket mindenképpen el kell végeznünk:

  1. Ellenőrizni kell, hogy az aláíró tanúsítványa az aláírás időpillanatában érvényes volt-e, a dokumentumot az aláíró tanúsítványában szereplő nyilvános kulcshoz tartozó titkos kulccsal írták-e alá. Ellenőrizni kell, hogy az aláíró tanúsítványát valóban CA1 bocsátotta ki, és CA1 tanúsítványát valóban a root CA bocsátotta-e ki. Ha a root CA tanúsítványát hitelesen megszereztük, e lépés rövid idő alatt elvégezhető.
  2. Ellenőrizni kell, hogy az aláíró tanúsítványát nem vonták-e vissza. Ehhez CA1 visszavonási nyilvántartását kell megnézni.
  3. Ellenőrizni kell, hogy CA1 tanúsítványát nem vonták-e vissza. Ehhez a root CA visszavonási nyilvántartását kell megnézni.

A fent hivatkozott nemzetközi specifikációk szerint az ellenőrzést - beleértve a visszavonási nyilvántartások lekérdezését is - a teljes tanúsítványláncra el kell végezni. A fenti listából a 3. lépés sem hagyható el, mert - bár a CA-k vigyáznak az aláírókulcsaikra - mégis van rá esély, hogy azok kompromittálódnak; ezért a fenti specifikációk is megkövetelik e lépés elvégzését.

(A fenti lépések alapján az aláírás érvényességére vonatkozó PKI bizonyítékokat vizsgáljuk meg. Megjegyezzük, hogy az aláírás elfogadásához nem kizárólag PKI bizonyítékokra lehet szükség (pl. előfordulhat, hogy az aláíró tévedésből vagy kényszer alatt írt alá egy dokumentumot, vagy nem jelentette kulcsának kompromittálódását), így egy elektronikus aláírás befogadásáról - a papír alapú aláírások esetéhez hasonlóan - célszerű az összes rendelkezésre álló információ alapján dönteni, és az esetleges nem PKI alapú bizonyítékokat is figyelembe venni.)

Ha a fenti ellenőrzéseket elvégeztük, az összegyűjtött hiteles visszavonási információkból időbélyegek segítségével szabványos (pl. az ETSI TS 101 903 (XAdES) specifikációban definiált XAdES-C vagy XAdES-A formátumú) blokk képezhető, mellyel később is igazolhatjuk, hogy a szükséges ellenőrzési lépéseket elvégeztük, és ésszerűen hagyatkoztunk a tanúsítványra.

  Kattintson ide, ha a szabványos, XAdES aláírás formátumokról szeretne olvasni.

Ha ezt nem tesszük meg, később nem feltétlenül tudjuk bizonyítani, hogy a szükséges ellenőrzési lépéseket valóban elvégeztük. Így ha valaki megkérdőjelezheti aláírásunkat arra hivatkozva, hogy az aláírás más időpontban készült, vagy akkor a kérdéses tanúsítvány már lejárt vagy felfüggesztésre esetleg visszavonásra került. Ha az elektronikus alárást fontos célra használjuk - különösen ha teljes bizonyító erejű magánokiratot vagy közokiratot szeretnénk a segítségével létrehozni - elemi érdekünk, hogy az aláírást később ne lehessen megkérdőjelezni vagy letagadni, vagyis a visszavonási információkat (vagy azok hivatkozásait) hitelesen csatolnunk kell az aláíráshoz.

 

A kivárási idő jelentette probléma

Ha a fenti 2. és a 3. lépést a CRL technológia segítségével szeretnénk elvégezni, a következő probléma merül fel: A CWA 14171 szerint azt kell ellenőriznünk, hogy a tanúsítvány az aláírás időpontjában érvényes volt-e, de az aláírás pillanatában jellemzően csak egy korábbi, az aláírás időpontját megelőzően kibocsátott CRL áll rendelkezésre. Ennek megfelelően - a CWA 14171 és az ETSI TS 101 933 szerint - a következő CRL megjelenését kell megvárnunk, és az aláíráshoz a következő CRL-t kell csatolnunk.

A magyar hitelesítés szolgáltatók végfelhasználói tanúsítványokat kibocsátó hitelesítő egységei 24 óránként bocsátanak ki CRL-t (de amennyiben visszavonási kérés érkezik hozzájuk 4 órán belül soron kívüli CRL-t bocsátnak ki). Ez annyit jelent, hogy az elektronikus aláírás létrehozását követően akár 24 órát kell várnia annak, aki később igazolni szeretné, hogy valóban körültekintően járt el az aláírás elfogadása során. (Az aláírás érvényességéről már akkor is meggyőződhetünk, ha az aláírás időpontját követően 4 óráig nem jelent meg új CRL. Csakhogy, ekkor még nincs a kezünkben olyan bizonyíték - CRL vagy OCSP válasz - amely alapján később igazolhatjuk, hogy valóban körültekintően jártunk el.)

Azon leghosszabb időtartamot, amit az aláírás létrehozását követően ki kell várnunk ahhoz, hogy az aláírást elfogadhassuk, kivárási időnek (grace period) nevezzük. (Ezen időtartam a fenti esetben 4 óra.) Ha archív (XAdES-A) aláírást szeretnénk létrehozni (ami célszerű, ha fontos aláírásról van szó, amit később is meg szeretnénk őrizni), akkor ennél tovább kell várnunk; meg kell várnunk az első, az aláírást időpontját követően kibocsátott, az aláírás szempontjából releváns visszavonási információ megjelenését. (Ezen időtartam a fenti esetben legfeljebb 24 óra.) A gyakorlatban súlyos problémát jelenthet, ha egy ügynek pusztán az aláírás ellenőrizhetősége miatt kell várakoznia. Továbbra is jelentősen több időbe telhetne a dokumentum hitelesítése, mint a dokumentum elkészítése.)


2. ábra - Példa a kivárási idő jelentette problémára

Bár az eseményvezérelt CRL-ek - amikor a hitelesítés szolgáltató vállalja, hogy felfüggesztés vagy visszavonás esetén azonnal új CRL-t bocsát ki - bizonyos alkalmazásokban enyhíthetik ezt a problémát, velük szemben más, súlyos problémák is felmerülnek. Az CRL-ek formátumát leíró RFC 5280 szerint nem állapítható meg a CRL alapján, hogy a CRL eseményvezérelt-e, és visszavonás esetén mennyi időn belül jelenik meg az új CRL, így a CRL-t feldolgozó alkalmazások nem tudnak különbséget tenni az eseményvezérelt és a csak periodikusan megjelenő CRL között. Az RFC 5280 szerint az alkalmazás nem köteles megnézni, hogy van-e újabb CRL, ha az aktuális CRL még érvényes, így ha a szolgáltató eseményvezrelt CRL-en teszi közzé a tanúsítvány megváltozott visszavonási állapotát, a felhasználó alkalmazása - amely az RFC 3280 szerint helyesen működik - ezt valószínűleg nem veszi figyelembe.

A CWA 14171 szerint az ellenőrzést a teljes tanúsítványláncra el kell végezni. Ez azt jelenti, hogyha a CA1 tanúsítványát a root CA hitelesíti felül, akkor - a fenti gondolatmenetnek megfelelően - meg kell várni a root CA következő CRL-jét is, és csak ezt követően rendelkezünk minden olyan információval, amely segítségével bizonyíthatjuk, hogy az aláírás ellenőrzése során körültekintően jártunk el. Azon CA, amely csak havonta bocsát ki root CRL-t - más közzétételi mód híján - nehezen alkalmazható a gyakorlatban, hiszen a rá visszavezethető aláírásokat nagyon nehéz ellenőrizni (illetve nagyon nehéz később bizonyítani, hogy az ellenőrzést valóban elvégeztük).

 

Tanúsítvány ellenőrzés OCSP szolgáltatás segítségével

Tekintetbe véve, hogy a CRL technológia segítségével nincsen lehetőség a kivárási idő elkerülésére, az ügyfelek számára pedig - különösen közokiratok és teljes bizonyító erejű magánokiratok létrehozása esetén - nem megengedhető meg sem a 24 órás, sem a 4 órás várakozás, a Microsec Kft. - Magyarországon elsőként - úgy döntött, hogy OCSP szolgáltatás segítségével is közzéteszi a tanúsítványok visszavonási állapotát.

Az OCSP az RFC 2560 specifikációban definiált online szolgáltatás, amelynek keretében egy tanúsítvány állapotára kérdezhetünk rá, és azonnali, hiteles, aláírt választ kapunk a kérdésre.

OCSP segítségével megoldható, hogy friss, hiteles bizonyítékra tegyünk szert a tanúsítvány aktuális visszavonási állapotáról. Ehhez az szükséges, hogy a hitelesítés szolgáltató nagyon gyorsan (akár az aláírás készítésével, illetve ellenőrzésével összemérhető idő alatt) feldolgozza a visszavonási kérelmeket, és közzétegye a tanúsítványok megváltozott visszavonási állapotát. Ekkor megoldható, hogy ha az aláírás pillanatát követően rákérdezünk a tanúsítvány visszavonási állapotára, akkor azonnali, friss, hiteles, és az adott időpontra vonatkozó választ kapjunk. Ekkor OCSP segítségével közvetlenül az aláírás létrehozása után is megbizonyosodhatunk az aláírás érvényességéről, és akár archív (XAdES-A) aláírást is készíthetünk.

Megjegyezzük, hogy az RFC 2560 szerint a fent leírtaktól eltérő módon is nyújtható az OCSP szolgáltatás: A specifikáció megengedi, hogy a hitelesítés szolgáltató a CRL-hez hasonló módon előre generált OCSP válaszokat adjon, amelyek nem jelentenek friss bizonyítékot, és a kivárási idő problémái ugyanúgy felmerülnek. Ekkor az OCSP mindössze anniyban előnyösebb a CRL-nél, hogy az OCSP válaszok jellemzően kisebbek, mint a CRL-ek.

Mikor elegendő a CRL használata is?

Az OCSP szolgáltatás a CRL-nél gyorsabb, korszerűbb, rugalmasabb és - a hatékonyabb ellenőrzés miatt - biztonságosabb a CRL technológiánál. Mégis előfordulhat, hogy valakinek nincsen szüksége az OCSP nyújtotta előnyökre és elég neki a CRL használata is.

Aki valóban ki szeretné használni az elektronikus aláírásra alapuló elektronikus ügyintézés nyújtotta gyorsaságot, annak egyértelműen OCSP szolgáltatásunkat ajánljuk.


Első változat: 2005. július
Frissítve: 2008. 11. 19.