PKI, Névtár Hitelesítés

Átírás

1 PKI, Névtár Hitelesítés Networkshop Tutoriál Győr, április 4. Bajnok Kristóf MTA-SZTAKI ITAK április 4. MTA Sztaki / ITAK 1

2 Miről lesz szó? PKI és rokonsága A teljesség igénye nélkül: SSL, PKCS #[1-12], hierarchiák, CRL, az internetes felhasználás szemszögéből Ahogyan a PKI használja a névtárat Repository, validáció,... Autentikáció és autorizáció PMI Házilagos LDAP megoldás április 4. MTA Sztaki / ITAK 2

3 Matematika Algoritmusok Miről nem lesz szó? (Bár lehetne...) RSA, Diffie-Hellman, MD5 Smart Cardok Protokollok részletes ismertetése SSL/TLS API Tanúsítványokat alkalmazó protokollok 802.1X, (L)EAP, IPSec, április 4. MTA Sztaki / ITAK 3

4 Biztonságos kommunikáció Adatokat akarunk A helyről B helyre juttatni megbízhatatlan csatornán keresztül Követelmények: Távoli fél azonosítása Bizalmasság Integritás Letagadhatatlanság április 4. MTA Sztaki / ITAK 4

5 Szimmetrikus Kriptográfia A felek előzőleg megállapodnak egy közös titkos kulcsban A kulcs segítségével kódolt üzenetek csak ugyanazzal a kulccsal dekódolhatók Gyakrabban használt algoritmusok: 3des idea blowfish RC2, RC4, RC5 AES április 4. MTA Sztaki / ITAK 5

6 Szimmetrikus Kriptográfia Előnyök gyors nagy mennyiségű adat kódolható Hátrány blokk- és folyamkódolás a biztonságos kulcscserét meg kell oldani április 4. MTA Sztaki / ITAK 6

7 Aszimmetrikus Kriptográfia Privát kulcs, nyilvános kulcs Nehéz matematikai problémákon alapul Pl. nagy számok prímfaktorizációja nem bizonyított, de erős sejtés Elterjedt algoritmusok RSA DSA április 4. MTA Sztaki / ITAK 7

8 Aszimmetrikus Kriptográfia Előny nem kell közös titkos kulcsban megegyezni alkalmazható digitális aláírásra sértetlenség titkosításra bizalmasság azonosításra a másik fél publikus kulcsával kódolt üzenet csak a hozzá tartozó privát kulccsal jeleníthető meg Hátrány lassú nagy mennyiségű adatra használhatatlan április 4. MTA Sztaki / ITAK 8

9 Digitális Aláírás Kriptográfiai hash változó hosszúságú bemenetből fix hosszúságú kimenetet előállító függvény nem megfordítható algoritmikusan nem generálható két ugyanolyan kimenetet adó bemenet Elterjedt algoritmusok MD5 SHA-1 SSHA április 4. MTA Sztaki / ITAK 9

10 Digitális Aláírás (2.) Az üzenet kriptográfiai ellenőrzőösszegét képezzük Az ellenőrző-összeget a privát kulcsunkkal kódoljuk a nyilvános kulcsunkkal bárki kinyithatja A vevő fél bizonyos lehet abban, hogy tőlünk származik az üzenet különben nem tudná dekódolni a publikus kulcsunkkal az üzenet nem változott meg különben más ellenőrző-összeget kapna április 4. MTA Sztaki / ITAK 10

11 Kulcscsere Ötvözni az aszimmetrikus és a szimmetrikus kriptográfia előnyeit Aszimmetrikus módon megállapodnak a közös titkos kulcsban A kommunikációt a közös titkos kulccsal titkosítják Honnan tudhatjuk a távoli fél publikus kulcsát?! Man-in-the-Middle támadás április 4. MTA Sztaki / ITAK 11

12 Megoldás Cél: a távoli fél publikus kulcsának hiteles megállapítása Szükség van megbízható harmadik félre aki meggyőződik arról, hogy a publikus kulcs tényleg az entitáshoz tartozik ezt tanúsítványban rögzíti Nyilvános Kulcsú Infrastruktúra / Public Key Infrastructure (PKI) április 4. MTA Sztaki / ITAK 12

13 Digitális Tanúsítvány Egy entitás neve és publikus kulcsa Harmadik fél által digitálisan aláírva április 4. MTA Sztaki / ITAK 13

14 PKI felépítés április 4. MTA Sztaki / ITAK 14

15 X.509 tanúsítvány április 4. MTA Sztaki / ITAK 15

16 Tanúsítvány készítése Kulcsgenerálás Certificate Request Aláírás Tanúsítvány tárolása, formátumok április 4. MTA Sztaki / ITAK 16

17 Kulcsgenerálás Hardveres támogatás lehetséges véletlenszám-generálás privát kulcs a hardveren maradhat Szempontok Kulcs archiválás elvesztett, megsemmisült kulcsok helyreállítására Publikus kulcs ellenőrzése RA ellenőrizni tudja, hogy a hozzá tartozó privát kulcs van a felhasználónál Véletlen szám digitális aláírásával elvégezhető április 4. MTA Sztaki / ITAK 17

18 Kulcsgenerálás OpenSSL genrsa, rsa csomag privát kulcs generálás: openssl genrsa -des3 -out privatekey.pem publikus kulcs generálás (certificate request nélkül): openssl rsa -in privatekey.pem -pubout -out publickey.pem április 4. MTA Sztaki / ITAK 18

19 Certificate Signing Request Két elterjedt formátum PKCS #10 MS Internet Explorer SPKAC Mozilla, Opera Tartalmazza Nyilvános kulcs Attribútumok információk a CA számára Distinguished Name (DN) felhasználó által kívánt lejárati idő, kiterjesztések Az entitás által digitálisan aláírva április 4. MTA Sztaki / ITAK 19

20 CSR OpenSSL PKCS #10 Request Létező nyilvános és privát kulccsal openssl req -new -key privatekey.pem -out client.csr Új kulcs generálásával openssl req -new -newkey rsa:1024 -keyout client_priv.pem -out client.csr április 4. MTA Sztaki / ITAK 20

21 Tanúsítvány aláírása RA azonosítja az igénylőt pl. személyes adatok igazolásával ellenőrzi a nyilvános kulcsot és az aláírást ellenőrzi, véglegesíti a CSR tartalmát Lejárati idő Kiterjesztések (extensions), megkötések (constraints) a CSR-t eljuttatja a CA-nak saját titkos kulcsával aláírva gyakran offline módon április 4. MTA Sztaki / ITAK 21

22 Tanúsítvány aláírása CA Ellenőrzi az igénylés hitelességét (aláírását) Egyedi sorozatszámot ad a tanúsítványnak Az megadott attribútumok alapján elkészíti az X.509 formátumú tanúsítványt A digitálisan aláírt tanúsítványt az entitás rendelkezésére bocsátja általában PKCS #7 formátumban Publikálja az aláírt tanúsítványt Repository: LDAP adatbázis április 4. MTA Sztaki / ITAK 22

23 Tanúsítvány aláírása OpenSSL CA tanúsítvány szükséges Self-signed CA certificate készítése: openssl req -x509 -newkey rsa:2048 -days 365 -out cacert.pem Konfiguráció (openssl.cnf) Aláírás Certificate / CRL repository Matching Policy Kiterjesztések openssl ca -in client.csr -out client_cert.pem április 4. MTA Sztaki / ITAK 23

24 Kulcs és tanúsítvány tárolása A privát kulcs és az aláírt tanúsítvány együtt egy önálló identitást határoz meg Védeni kell PKCS #12 privát kulcs tanúsítvány (tartalmazza a nyilvános kulcsot) CA tanúsítvány(ok) Jelszavas (PKCS #5) vagy egyéb kriptográfiai védelem szimmetrikus kódolás április 4. MTA Sztaki / ITAK 24

25 PKCS #12 OpenSSL Tanúsítvány, titkos kulcs és CA tanúsítvány (ok) tárolása egy titkosított állományba: openssl pkcs12 -export -inkey privatekey.pem -certfile client_cert.pem -CAfile CAcert.pem április 4. MTA Sztaki / ITAK 25

26 PKI Bizalmi láncok Bárki készíthet és aláírhat tanúsítványt Honnan tudhatjuk, hogy az aláíró CA megbízható? Ellenőrizni kell a tanúsító hitelességét is Hitelesnek elfogadott forrástól megkapjuk a CA publikus kulcsát Egy hitelesnek elfogadott CA tanúsítja az aláíró CA-t Cél: minél kevesebb CA-ban kelljen vakon megbízni április 4. MTA Sztaki / ITAK 26

27 Egyetlen Root CA Egy CA bocsátja ki az összes tanúsítványt Egy CA-ban kell megbízni Egy CA-t kell lekérdezni pl. visszavonás Nagyon nagy adminisztratív teher április 4. MTA Sztaki / ITAK 27

28 Hierarchikus modell Egy Root CA-ban kell megbízni Többlépcsős ellenőrzés Elosztott adminisztráció szervezeti struktúra Root CA túl nagy hatalom túl nagy üzlet április 4. MTA Sztaki / ITAK 28

29 Független hierarchiák A felhasználónak az összes Root CA-ban meg kell bíznia Új Root CA hozzáadásakor módosítani kell a programon április 4. MTA Sztaki / ITAK 29

30 Cross-certification A CA-k elismerik az egymás által kiadott tanúsítványokat április 4. MTA Sztaki / ITAK 30

31 Bridge CA április 4. MTA Sztaki / ITAK 31

32 Tanúsítvány validáció A tanúsítvány akkor érvényes, ha sértetlen nem vonták vissza a kritikusnak megjelölt kiterjesztéseket a felhasználó entitás értelmezni tudja az aktuális idő a tanúsítványban tárolt érvényességi perióduson belül van április 4. MTA Sztaki / ITAK 32

33 Sértetlenség ellenőrzése Ha tudjuk az aláíró CA publikus kulcsát egyszerű aláírás-ellenőrzés a CA-t azonosítja a tanúsítvány Issuer mezője az elterjedtebb nyilvános CA-k tanúsítványai bele vannak kódolva a szoftverekbe Ha nem tudjuk: rákattintunk az Accept gombra megkérdezzük valakitől (protokollon kívül) megkeressük és validáljuk a CA tanúsítványát április 4. MTA Sztaki / ITAK 33

34 CA tanúsítvány keresése Nincs rá általános eljárás LDAP támogatás CA objektum (certificationauthority) cacertificate, crosscertificatepair Probléma: melyik LDAP szerverben keressünk? Protokoll támogatás A távoli fél a saját tanúsítványával együtt elküldi a teljes tanúsítvány-láncot SSL/TLS ad erre lehetőséget április 4. MTA Sztaki / ITAK 34

35 Tanúsítvány validáció A tanúsítvány akkor érvényes, ha sértetlen nem vonták vissza a kritikusnak megjelölt mezőket a felhasználó entitás értelmezni tudja az aktuális idő a tanúsítványban tárolt érvényességi perióduson belül van április 4. MTA Sztaki / ITAK 35

36 Tanúsítvány visszavonása Vissza KELL vonni a tanúsítványt, ha a titkos kulcs kompromittálódik ellopják, elvesztik, gyanús lesz a CA és a tanúsítvány birtokosa közötti viszony megszűnik pl. kilépő dolgozó tanúsítványban tárolt információ megváltozik április 4. MTA Sztaki / ITAK 36

37 Certificate Revocation List Védett struktúra Elérhetővé kell tenni http, ldap Periodikusan újat kell kiadni CPS szabályozza Offline működésre optimalizált április 4. MTA Sztaki / ITAK 37

38 CRL Problémák Hogy találjuk meg? crldistributionpoints ( ) kiterjesztés certificaterevocationlist;binary attribútum (CA objektumban) Mikor / milyen gyakran frissítsük? sávszélesség-, tár- és processzorigény beágyazott kliensek? sérülékenységi ablak Root CA tanúsítvány visszavonása? és ha a Root CA privát kulcsát ellopták? április 4. MTA Sztaki / ITAK 38

39 CRL méretének csökkentése A tanúsítványból csak a sorszámot tárolja Csak nem lejárt tanúsítványokat tartalmaz Csak a felhasználónak fontos információt kellene tartalmaznia: Delta CRL Distribution Point CRL április 4. MTA Sztaki / ITAK 39

40 Delta CRL DeltaCRLIndicator (kritikus) kiterjesztés Base CRL: periodikusan publikált teljes CRL Δ: változások a legutóbbi Base vagy Δ óta Start Date Sequence Number így lehet ellenőrizni, hogy nem maradt ki Δ Tanúsítvány eltávolítása a CRL-ből a visszavont tanúsítvány lejárt RemoveFromCRL reason code április 4. MTA Sztaki / ITAK 40

41 Distribution Point CRL crldistributionpoints a tanúsítványban particionálható a CRL különböző frissítési gyakoriság több CA által kiadott tanúsítvány lehet egy CRL-ben április 4. MTA Sztaki / ITAK 41

42 Online státusz lekérdezés Online Certificate Status Protocol egy bizonyos sorozatszámú tanúsítványt nem vontak-e vissza OCSP Responder szolgáltatás az OCSP Responder hozzáfér a CRL-ekhez (és/vagy a Repository-hoz) a kliensek egyszerű kérdéseire egyszerű válaszokat küld (digitálisan aláírva) Kliens: Ez a sorozatszám OK? Szerver: < OK Nem OK Nem tudom > április 4. MTA Sztaki / ITAK 42

43 OCSP Egy OCSP Responder több CA-nak is nyújthat szolgáltatásokat a kérésben meg kell adni a kibocsátót is Gyorsabb kiszolgálás érdekében a válasz előre elkészíthető és aláírható április 4. MTA Sztaki / ITAK 43

44 OCSP problémák Hitelesség, OCSP Responder tanúsítvány hogyan ellenőrizzük a Responder hitelességét? el kell tárolni a publikus kulcsát (Trusted Responder) hogyan vonjuk vissza? CRL-ben ( sehogyan sem) Támadások DoS, Man-In-The-Middle (hibaüzenetek) Visszajátszás április 4. MTA Sztaki / ITAK 44

45 SCVP Az OCSP csak annyit mond meg, hogy egy tanúsítványt visszavontak-e Simple Certificate Validation Protocol a teljes validációt elvégzi a kliens elküldi a tanúsítványt és a validációhoz szükséges adatokat megbízhatónak tekintett Root CA-k CRL-ek, OCSP Responderek PKIX Internet Draft április 4. MTA Sztaki / ITAK 45

46 Tanúsítvány validáció A tanúsítvány akkor érvényes, ha sértetlen nem vonták vissza az értelmezett kiterjesztések ezt nem tiltják meg, és a kritikusnak jelölt kiterjesztések értelmezhetők az aktuális idő a tanúsítványban tárolt érvényességi perióduson belül van április 4. MTA Sztaki / ITAK 46

47 X.509 v3 Extensions Szabványos és privát kiterjesztések további attribútumok segítség a megbízhatósági lánc felépítéséhez Szerkezet: OID Kritikusság (criticality indicator) Tartalom RFC 3281: kiterjesztés április 4. MTA Sztaki / ITAK 47

48 Szabványos kiterjesztések authoritykeyidentifier információ az aláíró nyilvános kulcsáról aláírás ellenőrzéséhez nem használható!!! CA tanúsítványok esetén kötelező kivétel: self-signed subjectkeyidentifier információ az alany nyilvános kulcsáról CA tanúsítványok esetén kötelező április 4. MTA Sztaki / ITAK 48

49 Szabványos kiterjesztések keyusage felhasználási esetek keycertsign: csak CA tanúsítványokban crlsign nonrepudiation digitalsignature keyencipherment dataencipherment keyagreement javasolt kritikusnak megjelölni április 4. MTA Sztaki / ITAK 49

50 Szabványos kiterjesztések extendedkeyusage tetszőleges további feladat specifikálható pl. OCSP Responder privatekeyusage privát kulcs felhasználásának időbeli korlátozása certificatepolicies CP, CPS OID-k, amely alapján a tanúsítványt kiállították Opcionális szöveges mező (pl. URL) április 4. MTA Sztaki / ITAK 50

51 Szabványos kiterjesztések policymappings CP/CPS megfelelőségek definiálása CA tanúsítványokban subjectalternativename a tanúsítvány birtokosának további megnevezései cím, URI, stb. bizonyos esetekben helyettesítheti a Subject DN-t issueralternativename április 4. MTA Sztaki / ITAK 51

52 Szabványos kiterjesztések basicconstraints a tanúsítvány CA tanúsítvány-e korlátozza a hitelesítési út hosszát ha 0, akkor nem adhat ki CA tanúsítványokat nameconstraints korlátozás a kiadott tanúsítványok DN-jére policyconstraints a kiadott tanúsítványoknak tartalmazniuk kell a megadott Policy OID-t a certificatepolicies mezőben április 4. MTA Sztaki / ITAK 52

53 Internet kiterjesztések authorityinformationaccess információ arról, hogy hol találjuk a CA-hoz tartozó adatokat (CRL, tanúsítvány...) caissuers: http, ldap, ftp URI OCSP: szerver neve subjectinformationaccess a tanúsítványhoz tartozó adatok elérési pontja timestamping carepository április 4. MTA Sztaki / ITAK 53

54 Tanúsítvány alapú autentikáció és autorizáció Autentikáció az identitás ellenőrzése egy tanúsítvány és a hozzá tartozó titkos kulcs alapján megvalósítható, AMENNYIBEN a tanúsító entitásban megbízunk Autorizáció feltételezi az autentikációt jogosultság-ellenőrzés csoport tagság, szerepek (role) korlátok (hozzáférés ideje, tranzakció nagysága, stb) április 4. MTA Sztaki / ITAK 54

55 Autorizáció Miért nem jó a PKI tanúsítvány? az identitás ritkán változik a tanúsítvány kiadása, meghosszabbítása és visszavonása bonyolult tipikus érvényességi idő ~ 1 év ha mégis így akarjuk: subjectdirectoryattributes Autorizáció esetén jogosultságok sokkal gyorsabban változnak delegáció, helyettesítés április 4. MTA Sztaki / ITAK 55

56 Privilege Management Infrastructure X.509, RFC 3281 Attribute Certificate (AC) Issuer: Attribute Authority (AA) Holder: Identity Certificate sorozatszám Nincs nyilvános kulcs információ Érvényesség: néhány óra PKC AC április 4. MTA Sztaki / ITAK 56

57 PMI Delegáció Egy AA csak olyan jogosultságokat adhat egy felhasználónak, amellyel maga is rendelkezik Source Of Authority: SOA minden jogosultsággal rendelkezik jogosultságokat delegál az AA-k felé Root CA április 4. MTA Sztaki / ITAK 57

58 PMI Problémák Sérülékenységi ablak ACRL: Attribute Certificate Revocation List Érvényes tanúsítványok biztosítása a felhasználók számára Önálló infrastruktúrát igényel nem illeszkedik be a meglévő rendszerekbe Csak egy-két nagyon eltérő implementáció létezik április 4. MTA Sztaki / ITAK 58

59 LDAP Autentikáció Bind egy megnevezett entitás nevében (DN) Általában további információ szükséges: jelszó megadása challenge-response hitelesítés tanúsítvány alapú kulcscsere Alkalmazások: felhasználótól megkapott információk alapján kapcsolódnak a névtárhoz ha sikerül: az alkalmazás elfogadja a felhasználót április 4. MTA Sztaki / ITAK 59

60 LDAP Autorizáció (Directory) Policy alapján bizonyos attribútumok jogosultságokat jelenthetnek ezt a helyi policy írja elő, nem általános az LDAP objektum nem védett struktúra Csoportok (group) a csoport definíciójában felsorolt objektumok tartoznak a csoportba Szerepek (role) az objektum attribútuma alapján kapnak meg egy vagy több szerepet április 4. MTA Sztaki / ITAK 60

61 LDAP Autorizáció LDAP objektumokra (ágak, bejegyzések) hozzáférési szabályok definiálhatók ACI: Access Control Informations Group Membership és Role alapján Ha az alkalmazás a felhasználó nevében bizonyos műveletet végre tud hajtani tudható, hogy a névtárban erre feljogosították A névtár-jogosultságok leképezhetők alkalmazás-jogosultságokra április 4. MTA Sztaki / ITAK 61

62 LDAP Autorizáció Előny kis módosítás elégséges a meglévő alkalmazásautentikációs mechanizmusokhoz pl. Apache támogatja a csoporttagság-ellenőrzést az autentikáció és az autorizáció is a névtárban menedzselhető Hátrány nem tanúsított jogosultság nem szabványos, csak lokálisan alkalmazható április 4. MTA Sztaki / ITAK 62

63 Összefoglalás PKI jól menedzselhető, egyszerűen használható biztonsági rendszer alapja lehet Számos megoldandó problémát vet fel elméleti: sérülékenységi ablak, globális tanúsítvány-validáció,... gyakorlati: inkompatibilis (nem szabványos) megvalósítások privát kulcsok biztonsága Social Engineering április 4. MTA Sztaki / ITAK 63

64 Összefoglalás A helyzet: talán túl vagyunk a kezdeti fellángoláson és kiábránduláson egyre több tanúsítvány-alapú eljárás lát napvilágot eljön az idő, mikor ezeket integrálni kell a digitális aláírás általánossá válása várhatóan nagyot lök a technológián is De vajon a kommunikáció biztonságosabb lesz-e? április 4. MTA Sztaki / ITAK 64