PKI, Névtár Hitelesítés Networkshop Tutoriál Győr, 2004. április 4. Bajnok Kristóf kristof.bajnok@sztaki.hu MTA-SZTAKI ITAK 2004. április 4. MTA Sztaki / ITAK 1
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 2004. április 4. MTA Sztaki / ITAK 2
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,... 2004. április 4. MTA Sztaki / ITAK 3
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 2004. április 4. MTA Sztaki / ITAK 4
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 2004. április 4. MTA Sztaki / ITAK 5
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 2004. április 4. MTA Sztaki / ITAK 6
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 2004. április 4. MTA Sztaki / ITAK 7
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 2004. április 4. MTA Sztaki / ITAK 8
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 2004. április 4. MTA Sztaki / ITAK 9
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 2004. április 4. MTA Sztaki / ITAK 10
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 2004. április 4. MTA Sztaki / ITAK 11
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) 2004. április 4. MTA Sztaki / ITAK 12
Digitális Tanúsítvány Egy entitás neve és publikus kulcsa Harmadik fél által digitálisan aláírva 2004. április 4. MTA Sztaki / ITAK 13
PKI felépítés 2004. április 4. MTA Sztaki / ITAK 14
X.509 tanúsítvány 2004. április 4. MTA Sztaki / ITAK 15
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 2004. április 4. MTA Sztaki / ITAK 16
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ő 2004. április 4. MTA Sztaki / ITAK 17
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 2004. április 4. MTA Sztaki / ITAK 18
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 2004. április 4. MTA Sztaki / ITAK 19
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 2004. április 4. MTA Sztaki / ITAK 20
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 2004. április 4. MTA Sztaki / ITAK 21
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 2004. április 4. MTA Sztaki / ITAK 22
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 2004. április 4. MTA Sztaki / ITAK 23
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 2004. április 4. MTA Sztaki / ITAK 24
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 2004. április 4. MTA Sztaki / ITAK 25
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 2004. április 4. MTA Sztaki / ITAK 26
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 2004. április 4. MTA Sztaki / ITAK 27
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 2004. április 4. MTA Sztaki / ITAK 28
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 2004. április 4. MTA Sztaki / ITAK 29
Cross-certification A CA-k elismerik az egymás által kiadott tanúsítványokat 2004. április 4. MTA Sztaki / ITAK 30
Bridge CA 2004. április 4. MTA Sztaki / ITAK 31
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 2004. április 4. MTA Sztaki / ITAK 32
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 2004. április 4. MTA Sztaki / ITAK 33
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 2004. április 4. MTA Sztaki / ITAK 34
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 2004. április 4. MTA Sztaki / ITAK 35
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 2004. április 4. MTA Sztaki / ITAK 36
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 2004. április 4. MTA Sztaki / ITAK 37
CRL Problémák Hogy találjuk meg? crldistributionpoints (2.5.29.31) 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?... 2004. április 4. MTA Sztaki / ITAK 38
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 2004. április 4. MTA Sztaki / ITAK 39
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 2004. április 4. MTA Sztaki / ITAK 40
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 2004. április 4. MTA Sztaki / ITAK 41
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 > 2004. április 4. MTA Sztaki / ITAK 42
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ó 2004. április 4. MTA Sztaki / ITAK 43
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 2004. április 4. MTA Sztaki / ITAK 44
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 2004. április 4. MTA Sztaki / ITAK 45
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 2004. április 4. MTA Sztaki / ITAK 46
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: 16 + 2 kiterjesztés 2004. április 4. MTA Sztaki / ITAK 47
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ő 2004. április 4. MTA Sztaki / ITAK 48
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 2004. április 4. MTA Sztaki / ITAK 49
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) 2004. április 4. MTA Sztaki / ITAK 50
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 e-mail cím, URI, stb. bizonyos esetekben helyettesítheti a Subject DN-t issueralternativename 2004. április 4. MTA Sztaki / ITAK 51
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 2004. április 4. MTA Sztaki / ITAK 52
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 2004. április 4. MTA Sztaki / ITAK 53
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) 2004. április 4. MTA Sztaki / ITAK 54
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 2004. április 4. MTA Sztaki / ITAK 55
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 2004. április 4. MTA Sztaki / ITAK 56
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 2004. április 4. MTA Sztaki / ITAK 57
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 2004. április 4. MTA Sztaki / ITAK 58
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 2004. április 4. MTA Sztaki / ITAK 59
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 2004. április 4. MTA Sztaki / ITAK 60
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 2004. április 4. MTA Sztaki / ITAK 61
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ó 2004. április 4. MTA Sztaki / ITAK 62
Ö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 2004. április 4. MTA Sztaki / ITAK 63
Ö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?... 2004. április 4. MTA Sztaki / ITAK 64