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

PKI, Névtár – Hitelesítés Networkshop – Tutoriál Győr, 2004. április 4.

Bajnok Kristóf [email protected]

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: ● ●

●

Ahogyan a PKI használja a névtárat –

●

SSL, PKCS #[1-12], hierarchiák, CRL, … az internetes felhasználás szemszögéből

Repository, validáció, ...

Autentikáció és autorizáció –

PMI

–

„Házilagos” LDAP megoldás

2004. április 4.

MTA Sztaki / ITAK

2

Miről nem lesz szó? (Bár lehetne...) ●

Matematika –

Algoritmusok ●

RSA, Diffie-Hellman, MD5…

●

Smart Cardok

●

Protokollok részletes ismertetése

●

SSL/TLS API

●

Tanúsítványokat alkalmazó protokollok –

2004. április 4.

802.1X, (L)EAP, IPSec, ... 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: ● ● ● ● ●

2004. április 4.

3des idea blowfish RC2, RC4, RC5 AES MTA Sztaki / ITAK

5

Szimmetrikus Kriptográfia ●

Előnyök –

gyors

–

nagy mennyiségű adat kódolható ●

●

blokk- és folyamkódolás

Hátrány –

2004. április 4.

a biztonságos kulcscserét meg kell oldani

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 – –

2004. április 4.

lassú nagy mennyiségű adatra használhatatlan 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 ● ● ●

2004. április 4.

MD5 SHA-1 SSHA 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 ●

–

az üzenet nem változott meg ●

2004. április 4.

különben nem tudná dekódolni a publikus kulcsunkkal különben más ellenőrző-összeget kapna 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?! –

2004. április 4.

Man-in-the-Middle támadás 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 ●

–

Publikus kulcs ellenőrzése ●

●

2004. április 4.

elvesztett, megsemmisült kulcsok helyreállítására 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ő 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 –

2004. április 4.

Repository: LDAP adatbázis 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) ● ● ●

●

Certificate / CRL repository Matching Policy Kiterjesztések

Aláírás 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 ● ● ●

–

Jelszavas (PKCS #5) vagy egyéb kriptográfiai védelem ●

2004. április 4.

privát kulcs tanúsítvány (tartalmazza a nyilvános kulcsot) CA tanúsítvány(ok)

szimmetrikus kódolás 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 –

●

2004. április 4.

pl. visszavonás

Nagyon nagy adminisztratív teher

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 – –

2004. április 4.

túl nagy hatalom túl nagy üzlet 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 ●

2004. április 4.

SSL/TLS ad erre lehetőséget 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 ●

–

a CA és a tanúsítvány birtokosa közötti viszony megszűnik ●

–

2004. április 4.

ellopják, elvesztik, „gyanús” lesz

pl. kilépő dolgozó

tanúsítványban tárolt információ megváltozik

MTA Sztaki / ITAK

36

Certificate Revocation List ●

Védett struktúra

●

Elérhetővé kell tenni –

●

Periodikusan újat kell kiadni –

●

http, ldap

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? ●

2004. április 4.

és ha a Root CA privát kulcsát ellopták?... 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 ●

2004. április 4.

RemoveFromCRL reason code MTA Sztaki / ITAK

40

Distribution Point CRL ●

crlDistributionPoints –

a tanúsítványban

–

particionálható a CRL ●

●

2004. április 4.

különböző frissítési gyakoriság több CA által kiadott tanúsítvány lehet egy CRL-ben

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) ● ●

2004. április 4.

Kliens: „Ez a sorozatszám OK?” Szerver: <„OK” | „Nem OK” | „Nem tudom”> 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 –

2004. április 4.

a válasz előre elkészíthető és aláírható 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? ●

–

hogyan vonjuk vissza? ●

●

el kell tárolni a publikus kulcsát (Trusted Responder) 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 ● ●

–

2004. április 4.

megbízhatónak tekintett Root CA-k CRL-ek, OCSP Responderek

PKIX Internet Draft 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 ● ● ● ● ● ● ●

– 2004. április 4.

keyCertSign: csak CA tanúsítványokban cRLSign nonRepudiation digitalSignature keyEncipherment dataEncipherment keyAgreement

javasolt kritikusnak megjelölni MTA Sztaki / ITAK

49

Szabványos kiterjesztések ●

extendedKeyUsage –

tetszőleges további feladat specifikálható ●

●

privateKeyUsage –

●

pl. OCSP Responder

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 ●

●

subjectAlternativeName –

a tanúsítvány birtokosának további megnevezései ●

–

●

CA tanúsítványokban

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 ●

●

nameConstraints –

●

ha 0, akkor nem adhat ki CA tanúsítványokat

korlátozás a kiadott tanúsítványok DN-jére

policyConstraints –

2004. április 4.

a kiadott tanúsítványoknak tartalmazniuk kell a megadott Policy OID-t a certificatePolicies mezőben 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 –

2004. április 4.

a tanúsítványhoz tartozó adatok elérési pontja ●

timestamping

●

caRepository 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 ● ●

2004. április 4.

csoport tagság, szerepek (role) korlátok (hozzáférés ideje, tranzakció nagysága, stb) 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 ●

2004. április 4.

delegáció, helyettesítés MTA Sztaki / ITAK

55

Privilege Management Infrastructure ●

X.509, RFC 3281

●

Attribute Certificate (AC)

●

●

●

●

PKC

AC

Issuer: Attribute Authority (AA) Holder: Identity Certificate sorozatszám Nincs nyilvános kulcs információ Érvényesség: néhány óra

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 –

●

●

Érvényes tanúsítványok biztosítása a felhasználók számára Önálló infrastruktúrát igényel –

●

ACRL: Attribute Certificate Revocation List

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) –

2004. április 4.

az objektum attribútuma alapján kapnak meg egy vagy több szerepet 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: ●

–

gyakorlati: ● ● ●

2004. április 4.

sérülékenységi ablak, globális tanúsítvány-validáció, ... inkompatibilis (nem szabványos) megvalósítások privát kulcsok biztonsága Social Engineering 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