Gyakorlati problémák a PKI területén

Átírás

1 Gyakorlati problémák a PKI területén BERTA István Zsolt Microsec Kft., K+F és folyamatszervezési igazgató <istvan.berta@microsec.hu> István Zsolt BERTA <istvan.berta@microsec.hu> 1/21

2 Elefánt Mszaki kérdések Gazdasági kérdések Jogi kérdések István Zsolt BERTA 2/21

3 Mirl fogok beszélni? Rövid összefoglalás a PKI-rl Hazai helyzet Mszaki + gazdasági + jogi aspektus Gyakorlati problémák István Zsolt BERTA <istvan.berta@microsec.hu> 3/21

4 Bevezetés a PKI-rl István Zsolt BERTA <istvan.berta@microsec.hu> 4/21

5 PKI röviden Minden résztvevnek van magánkulcsa (csak ismeri) és hozzá tartozó nyilvános kulcsa (bárki megismerheti). A nyilvános kulccsal titkosítunk, a magánkulccsal lehet visszafejteni. A magánkulccsal aláírunk, a nyilvános kulccsal lehet ellenrizni. Más nyilvános kulcsához hiteles módon kell hozzájutni, pl. úgy, hogy egy hitelesítés szolgáltató tanúsítványba foglalja és aláírja. Minden szerepl ismeri és elfogadja bizonyos gyökér hitelesítés szolgáltatók nyilvános kulcsát. Egyes szereplk tanúsítványuk szerint idbélyegzés szolgáltatók. Ha k állítják valamirl, hogy mikor készült. Az elektronikus aláíráshoz (minsített/fokozott) és az idbélyegzéshez (minsített) jogkövetkezmény is kapcsolódik. István Zsolt BERTA <istvan.berta@microsec.hu> 5/21

6 Terminológia root CA, gyökér HSZ köztes CA végfelhasználó (alany/aláíró) érintett fél István Zsolt BERTA 6/21

7 CA-hierarchia User1 CA1 root CA CA2 User2 User3 Mi az a CA? Szervezet/vállalat? Szervezeti egység? Számítógép? Domain név? Fizikai eszközök összessége? Tanúsítvány? Kulcspár? István Zsolt BERTA <istvan.berta@microsec.hu> 7/21

8 Mivel foglalkozik egy CA? A CA azonosítja, regisztrálja a felhasználót Tanúsítványt bocsát ki a számára Nyilvánosságra hozza a tanúsítványokat* Nyilvánosságra hozza, ha a felhasználó visszavonja a tanúsítványt Garanciát vállal (a saját mködésére). Cserébe rendszeres (pl. éves) díjat kap a felhasználóktól István Zsolt BERTA <istvan.berta@microsec.hu> 8/21

9 Hazai helyzet István Zsolt BERTA 9/21

10 2001. évi XXXV tv. az elektronikus aláírásról EU direktíva (1999/93) az elektronikus aláírásról Elektronikus aláírással kapcsolatos szolgáltatások meghatározása hitelesítés szolgáltatás (tanúsítvány-kibocsátás) idbélyegzés szolgáltatás eszköz szolgáltatás archiválás szolgáltatás Minsített és nem minsített szolgáltatók, és a szolgáltatásaikhoz kapcsolódó bizonyító er Nyilvántartás, felügyelet (Nemzeti Hírközlési Hatóság) A szolgáltatókra vonatkozó biztonsági követelmények, szolgáltatók felelssége stb. István Zsolt BERTA <istvan.berta@microsec.hu> 10/21

11 Hazai piac Szabályozott piac A hitelesítés szolgáltatók vállalatok, a Nemzeti Hírközlési Hatóság felügyeli a mködésüket Négy hitelesítés szolgáltató mködik Magyarországon: Microsec, Magyar Telekom, eszigno.t-systems.magyartelekom.hu systems.magyartelekom.hu Máv Informatika, Netlock, +GIRO, IHM, Biztonsági Hitelesítés Szolgáltató (nem mködik) e-cégeljárás korábban: Ügyfélkapu, Magánnyugdíjpénztári bevallás István Zsolt BERTA <istvan.berta@microsec.hu> 11/21

12 Minsített elektronikus aláírás Minsített elektronikus aláírás: olyan - fokozott biztonságú - elektronikus aláírás, amelyet az aláíró biztonságos aláírás-létrehozó létrehozó eszközzel hozott létre, és amelynek hitelesítése céljából minsített tanúsítványt bocsátottak ki. Teljes bizonyító erej magánokirat Minsített aláírást csak természetes személy készíthet. A CA aláírása csak fokozott biztonságú lehet. István Zsolt BERTA <istvan.berta@microsec.hu> 12/21

13 Minsített CA-ra vonatkozó biztonsági követelmények Önálló, független szervezeti egység A minsített és nem minsített rendszereket el kell választani egymástól Minségirányítási (ISO9000) és információbiztonság- irányítási rendszer (BS7799, ISO27001) Folyamatos rendelkezésre állás (99,9%) Bizalmi munkakörök általánosan felels vezet biztonsági tisztvisel regisztrációs tisztvisel független rendszervizsgáló rendszeradminisztrátor, rendszerüzemeltet Felelsségbiztosítás, bankgarancia István Zsolt BERTA <istvan.berta@microsec.hu> 13/21

14 CA-k nyilvános dokumentumai Hitelesítési rend (Certificate( Policy) Szolgáltatási szabályzat (Certificate( Practica Statement) Tartalmazzák: tanúsítvány ellenrzésének módját a a tanúsítványok értelmezését a a tanúsítványok kibocsátásával és a kulcskezeléssel kapcsolatos védelmi intézkedéseket a a tanúsítványhoz tartozó felelsségvállalásokat a a szolgáltatások elérhetségét István Zsolt BERTA <istvan.berta@microsec.hu> 14/21

15 Minsített tanúsítványra vonatkozó fbb követelmények Kizárólag minsített hitelesítés szolgáltató bocsáthatja ki Biztonságos aláírás-létrehozó létrehozó eszköz (BALE) Személyes azonosítás Adategyeztetés közhiteles adatbázisokkal Felelsségvállalás! István Zsolt BERTA 15/21

16 Tranzakciós limit Eat.. 9 (1) A hitelesítés s szolgáltat ltató a minsített tanúsítv tványban meghatározhatja a tanúsítv tvánnyal egy alkalommal vállalhatv llalható kötelezettség g legmagasabb mértm rtékét. t. A tranzakciós limit segítségével a hitelesítés szolgáltató csökkentheti a kockázatát Tranzakciós limit (érintett fél felé) vs. szolgáltatói felelsségvállalás (ügyfél felé) István Zsolt BERTA <istvan.berta@microsec.hu> 16/21

17 Tanúsítványok felépítése István Zsolt BERTA 17/21

18 Egy tanúsítvány mezi Sorozatszám Kiállító DN (azaz a CA) Érvényesség kezdete, vége Tulajdonos DN (a tanúsítvány alanya) Tanúsítvány-irányelv (Certificate( Policies) QCStatement (csak minsített tanúsítványban) Tranzakciós limit (csak minsített tanúsítványban) Visszavonási információk elérhetsége Kulcshasználat (Key( Usage) Nyilvános kulcs, a CA aláírása, aláíró és hash algoritmusok megnevezése stb. István Zsolt BERTA <istvan.berta@microsec.hu> 18/21

19 A tanúsítvány alanyának DN-je Az LDAP szerint definiált Distinguished Name Common Name, Surname, GivenName stb. Title Organization, Organization Unit Locality Country Pseudonym Address Serial Number, Distinguished Name Qualifier stb. Álnév kezelése Szervezethez tartozás, szervezet képviselete Ki illetve mi igazolja az egyes mezk érvényességét? István Zsolt BERTA 19/21

20 Key Usage (RFC 3280) KeyUsage ::= BIT STRING { digitalsignature (0), nonrepudiation (1), keyencipherment (2), dataencipherment (3), keyagreement (4), keycertsign (5), crlsign (6), encipheronly (7), decipheronly (8) } István Zsolt BERTA <istvan.berta@microsec.hu> 20/21

21 Aláírás, titkosítás, authentikáció Az Eat.. kizárólag az aláírásról szól, a másik két területre nemigen van szabályozás. Eat 13. (4) Az aláíró az aláírás-létrehozó létrehozó adatot kizárólag az aláírás létrehozására használhatja, betartva a tanúsítványban jelzett esetleges egyéb korlátozásokat is. E három területet szét szokás választani egymástól. E három esetben masszívan különböz kulcsmenedzsmentre van szükség. István Zsolt BERTA <istvan.berta@microsec.hu> 21/21

22 Aláírás - NR (+DS) Az Eat.. kizárólag aláírásról szól. A magánkulcsot kulcsot felesleges/tilos letétbe helyezni. A magánkulcs megsemmisülése nem okoz problémát. A lejárt tanúsítvány cserélhet, a magánkulcsa nem kell. A tanúsítványt egy korábbi idpontra (a magánkulcs használatának idpontjára) vonatkozóan kell ellenrizni (letagadhatatlanság). Célszer kivárási idt alkalmazni. A visszavont tanúsítvánnyal már nem lehet visszaélni, de a felfüggesztettel igen, ha késbb visszaállítják. Az Eat.. szerint el kell választani minden más funkciótól. István Zsolt BERTA <istvan.berta@microsec.hu> 22/21

23 Authentikáció, hitelesítés (DS+KA+...) Az Eat.. nem vonatkozik rá. A magánkulcsot kulcsot felesleges/tilos letétbe helyezni. A magánkulcs megsemmisülése nem okoz problémát. A lejárt tanúsítvány cserélhet, a magánkulcsa nem kell. A tanúsítványt mindig az aktuális idpontra vonatkozóan kell ellenrizni. Értelmetlen kivárási idt alkalmazni. A visszavont tanúsítvánnyal már nem lehet visszaélni, és a felfüggesztettel sem. A magánkulccsal véletlen kihívást kódolunk, vigyázni kell, nehogy aláírjunk/dekódoljunk valamit. István Zsolt BERTA <istvan.berta@microsec.hu> 23/21

24 Titkosítás/dekódolás - KE+DE Az Eat.. nem vonatkozik rá. A magánkulcsot letétbe szokás helyezni. A magánkulcs megsemmisülése óriási károkat okozhat. Ha lecseréljük a tanúsítványt/magánkulcsot, vagy mindent át kell titkosítani, vagy a korábbi kulcsokat is használni kell A tanúsítványt az aktuális idpontra vonatkozóan kell ellenrizni - ez is tökéletlen megoldás. Értelmetlen kivárási idt alkalmazni. A felfüggesztés/visszavonás nem akadályozza meg a támadót, hogy visszaéljen a magánkulccsal, csak a késbbi károkat enyhíti az érintett felek értesítésével. István Zsolt BERTA <istvan.berta@microsec.hu> 24/21

25 Certificate Policies A hitelesítés szolgáltató hitelesítési rendjére és/vagy szolgáltatási szabályzatára tartalmaz hivatkozást Megállapítható belle, hogy a szolgáltató milyen feltételek mellett bocsátotta ki a tanúsítványt és mekkora felelsséget vállal érte QCStatements István Zsolt BERTA <istvan.berta@microsec.hu> 25/21

26 CRL és OCSP István Zsolt BERTA 26/21

27 Visszavonási állapot közzététele Visszavonási lista (CRL) A A CA által rendszeresen kibocsátott, aláírt lista Eseményvezérelt CRL Delta CRL OCSP Online Certificate Status Protocol kérdés: x tanúsítvány érvényes-e aláírt válasz: igen/nem István Zsolt BERTA <istvan.berta@microsec.hu> 27/21

28 Felfüggesztés, visszaállítás, visszavonás Felfüggesztés Érvényes tanúsítvány Felfüggesztett tanúsítvány Visszaállítás Visszavonás Visszavonás Visszavont tanúsítvány István Zsolt BERTA 28/21

29 Kivárási id (grace period) felfüggesztés az aláírás eltti CRL aláírás kivárási id id Az aláírást követ els CRL A következ CRL-t t meg kell várni az aláírás ellenrzéséhez. A magyar CA-k általában 24 óránként bocsátanak ki CRL-t. Mindezt a tanúsítványlánc minden elemére el kell végezni. Mikor ellenrizhet egy aláírás??? István Zsolt BERTA <istvan.berta@microsec.hu> 29/21

30 Visszavonás idpontja a CRL-ben felfüggesztés visszaállítás újra felfüggesztés aláírás id CRL OCSP CRL István Zsolt BERTA <istvan.berta@microsec.hu> 30/21

31 Tanulság A tanúsítvány érvényességét az aláírás pillanatában kell vizsgálni A CRL lehet, hogy csak sokkal késbb jelenik meg, elképzelhet, hogy a CRL-alapú ellenrzés nem helyes eredményhez vezet A legbiztonságosabb megoldás a tanúsítvány visszavonási állapotát az aláírás pillanatában OCSP segítségével lekérdezni István Zsolt BERTA <istvan.berta@microsec.hu> 31/21

32 Hogyan ellenrizzük az OCSP válaszadó tanúsítványát? CRL alapján ellenrizni lassú, annak nincsen értelme. OCSP segítségével ellenrizhetjük, de akkor ki adja a választ? Ha nem ellenrizzük az OCSP válaszadó tanúsítványát, mi történik, ha a válaszadó kulcsa mégis kompromittálódik? István Zsolt BERTA <istvan.berta@microsec.hu> 32/21

33 Rövid lejáratú OCSP tanúsítvány Az OCSP válaszadó tanúsítványa legfeljebb néhány percig érvényes A CA úgy érvényteleníti a kompromittálódott kulcsot, hogy nem ad ki hozzá új tanúsítványt A kulcsot megszerz támadó az utolsó tanúsítvány lejárta után nem tud a kulccsal visszaélni a a tanúsítvány már nem érvényes visszadátumozott idbélyeget nem tud szerezni István Zsolt BERTA <istvan.berta@microsec.hu> 33/21

34 Microsec e-szignó hierarchia István Zsolt BERTA 34/21

35 Elektronikus aláírás és ellenzése István Zsolt BERTA 35/21

36 Hogy kell ellenrizni egy aláírást? A tanúsítványt kibocsátó hitelesítés szolgáltató által kibocsátott, az adott tanúsítványra vonatkozó hitelesítési rend szerint kell eljárni. A hitelesítési rendre való hivatkozás megtalálható a tanúsítványban (tanúsítvány irányelv, certificate policies mezk). István Zsolt BERTA <istvan.berta@microsec.hu> 36/21

37 Aláírás ellenrzésének lépései 1. Mi állapítható meg az aláíróról (pl. álnév, képviselet)? 2. Tranzakciós limit ellenrzése 3. Az aláírás valóban az aláíró tanúsítványához tartozik? 4. Az aláíró tanúsítványa nem járt-e e le, vagyis az aláírás idpontja a tanúsítvány érvényességi idején belülre esik? Honnan tudom utólag, hogy mikor történt az aláírás? 5. Ellenriznie kell a tanúsítvány visszavonási állapotát. 6. A tanúsítványlánc minden elemére el kell végezni a 2., 3. és 4. lépéseket, amíg egy megbízható root tanúsítványhoz (trust( anchor) ) nem jutunk. István Zsolt BERTA <istvan.berta@microsec.hu> 37/21

38 Letagadhatatlanság Mszaki szempontból létezik letagadhatatlanság, jogi szempontból nem Letagadhatatlan az aláírásom, ha lejárt a tanúsítványom? nem elérhet a visszavonási információ? A minsített aláírásból nem következik, hogy az hosszú távon is letagadhatatlan. István Zsolt BERTA <istvan.berta@microsec.hu> 38/21

39 Idbélyeg ellenrzése Az idbélyeg valóban az idbélyegz tanúsítványához tartozik? Az idbélyegz tanúsítványának visszavonási állapota Kulcskompromittálódás miatt visszavont tanúsítványú idbélyegzvel létrehozott minden idbélyeg visszamenleg is érvénytelen Ellenrzés a teljes tanúsítványláncra István Zsolt BERTA <istvan.berta@microsec.hu> 39/21

40 OCSP válasz ellenrzése OCSP válasz kizárólag akkor érvényes, ha a a válaszadó tanúsítványa még érvényes az OCSP válaszon idbélyeg van, és a válaszadó tanúsítványa az idbélyegen szerepl idpontban érvényes volt István Zsolt BERTA <istvan.berta@microsec.hu> 40/21

41 Szabványos aláírás-formátumok Alap aláírások: CMS - cryptographic message syntax (ASN1) XMLDSIG - xml alapon Egyéb információkat is csatolni szokás: XMLDSIG XAdES CMS CAdES Alapveten en ugyanazokat a funkciókat kat oldják meg ASN1, illetve XML alapon. István Zsolt BERTA <istvan.berta@microsec.hu> 41/21

42 XAdES aláírások XML Advanced Electronic Signature W3C által kidolgozott formátum ETSI TS szabvány Többfajta aláírást definiál, van közöttük egyszer, idbélyeggel ellátott, és hosszú távon letagadhatatlan is István Zsolt BERTA 42/21

43 XAdES-BES István Zsolt BERTA 43/21

44 XAdES-T és XAdES-C XAdES-BES aláírás (az aláírás idpontja bizonyítható) XAdES-T idbélyeg az aláíráson (középtávú letagadhatatlanság ) XAdES-C hivatkozás a teljes tanúsítvány- láncra és a visszavonási információra István Zsolt BERTA <istvan.berta@microsec.hu> 44/21

45 XAdES-X és XAdES-XL XAdES-BES aláírás XAdES-C XAdES-T XAdES-X idbélyeg a referenciákon VAGY idbélyeg a referenciákon és az aláíráson XAdES- X-L teljes referenciák és István Zsolt BERTA <istvan.berta@microsec.hu> 45/21

46 XAdES-A, archív aláírás XAdES-BES aláírás XAdES-C XAdES-T XAdES-X-L XAdES-X XAdES-A további archív idbélyegek István Zsolt BERTA 46/21

47 XAdES formátumok XAdES-BES nem sok mindenre jó XAdES-T igazolható az aláírás idpontja XAdES-C középtávú letagadhatatlanság XAdES-X-L minden információt tartalmaz XAdES-A hosszú távú archiválás nem csak formátum, hanem eljárás archív szolgáltató István Zsolt BERTA 47/21

48 Root CA Nincsen egyetlen root CA Magyar nemzeti root?, közigazgatási root? Tanúsítványtár a Windowsban, Mozillában stb. Az aláírást létrehozó fél létrehozza az aláírását, visszavezeti a tanúsítványát valamely root-ra ra. Az aláírást fogadó fél is megpróbálja a tanúsítványt egy általa ismert root-ra ra visszavezetni István Zsolt BERTA <istvan.berta@microsec.hu> 48/21

49 PKI alkalmazások tesztelése Az alkalmazásokat tesztelni kell. PKI esetén hitelességet nem a dokumentumok helye, hanem a dokumentumok kódolása biztosítja. Az éles rendszer leklónozásával leklónozásával nem homokozó tesztrendszert, hanem másik éles rendszert kapunk. Külön tesztrendszereket szokás felállítani, külön kulcsokkal. Ez különbözik az éles rendszertl. Az éles rendszerben éppen a kulcsokat kell megváltoztatni, így épp a kulcskezelést nem könny tesztelni István Zsolt BERTA <istvan.berta@microsec.hu> 49/21

50 Microsec e-szignó teszt rendszerek Teszt hitelesítés, idbélyeg stb. szolgáltatás: e-szignó program: További info: István Zsolt BERTA 50/21

51 Összefoglalás Az elektronikus aláíráshoz kapcsolódó technológiák rendelkezésre állnak Jogszabályi háttér szintén létezik E kett összekapcsolása illetve az alkalmazásokhoz való illesztése még nem teljesen kiforrott, ezen dolgozunk István Zsolt BERTA <istvan.berta@microsec.hu> 51/21

52 Köszönöm a figyelmet! István Zsolt BERTA <istvan.berta@microsec.hu> 52/21

53 Gyakorlati problémák a PKI területén BERTA István Zsolt Microsec Kft., K+F és folyamatszervezési igazgató <istvan.berta@microsec.hu> István Zsolt BERTA <istvan.berta@microsec.hu> 53/21