Digitális aláírás Tanúsítványok Zömbik László zombik tmit bme hu

Digitális aláírás, Tanúsítványok Zömbik László zombik@tmit. bme. hu 1

Tartalom I. Bevezetés II. Algoritmusok ismertetése III. Kulcsok, Tanúsítványok IV. Hitelesítő központok V. X. 509 szabvány VI. Példák: kulcsok, hitelesítő központok, tanúsítványok VII. Elosztott CA, GKMP VIII. Törvény 2

Aranybulla Három aranybullát bocsátottak ki a magyar királyok, Az első aranybullát II. András bocsátotta ki 1222 -ben ( XIV századi másolata fent). 31 cikkelyből állt. A második aranybullát 1231 -ben adták ki, melyben II. Andrásnak meg kellett erősíteni ill. pár pontban meg kellett változtatni az első szöveget és úgy kihirdetni. A 3. Aranybullát IV Béla a tatárjárás után és fiával (I. Istvánnal) való belviszály után bocsátotta ki 1267 -ben. Jobbra az aranybulla (1222) pecsétje. * *http: //hu. wikipedia. org/wiki/Aranybulla; http: //ehumana. hu/arpad/szoveg/to 13. htm 3

I. Bevezetés Hagyományos aláírás – vmilyen (papír alapú) irat – vminek az igazolása (többek között, hogy elolvastuk, egyetértünk vele, mi írtuk) – biztosítja az iratnak, illetve az abban levő információnak a – hitelességét (az irat származása) az aláírás egyedi formája, szerződés minden oldalát aláírni – sértetlenségét (tartalom nem módosult) szerződésben üres sorok (pl. csekk), oldalak ki/áthúzása, illetve olyan anyagra tesszük az aláírást, amelyről az aláírt dokumentumot nem lehet észrevétlenül módosítani – letagadhatatlanságát (jogilag is bizonyító erejű, hogy ki volt az aláíró) olyan anyagra (papír) kell az aláírást tenni, melyről nem lehet észrevétlenül eltüntetni, szerződés minden oldalát aláírni 4

Aranybulla hiteles dokumentum Papír alapú irat Igazolás Székesfehérvári törvénynapok; Nemesek adómentessége; bírói ítélkezés; öröklés rendje; katonai szolgálat; Nádori, udvarbírói jogkör; tized, pénz, só; külföldiek tulajdonlása; országos tisztségek halmozása és szankciók (1222 - hűtlenség, 1231 kiközösítés) biztonsági eljárások hiteles – – pecsét / bulla király aláírása aranyból készült pecsét (gazdagnak kell lenni a hamisítónak) speciális pecsétminta, mely a királyra utal (előállítása bonyolult, egyedi, aki már látott korábban egy eredeti pecsétet/bullát el tudja dönteni további pecsétek/bullák hitelességét) 5

További biztonsági eljárások sértetlen – pecsétnek kapcsolódnia kell a dokumentumhoz (törékeny biztonság, nem a dokumentumot védi, hanem annak tartalmát) (Kapzsi emberek letéphetik róluk az aranypecsétet. Így tett Vencel cseh király is, mikor 1304 -ben fiáért, az ifjú Vencel vagy magyarosan László királyért egy sereggel hazánkba jött és Esztergomban kirabolta a templomot és a levéltárat)* – pergamenen, állatbőrön módosítás könnyen észrevehető, tehát pl. szankciók kitörlése, módosítása egyből észrevehető. letagadhatatlan – több példány, szétosztva az érdekelt feleknek és semleges feleknek (pl. pápa) „És hogy ez a mi engedményünk, illetõleg rendelkezésünk mind a mi idõnkben, mind utódaink idejében örökké érvényes legyen, hét példányban állíttattuk ki, és arany pecsétünkkel erõsíttettük meg. Azért, hogy egy példány küldessék a pápa úrnak, és azt õ registrumába írassa be, a második õriztessék az ispotályosoknál, a harmadik a templomban, a negyedik a királynál, az ötödik az esztergomi káptalanban, a hatodik a kalocsaiban, a hetedik pedig a mindenkori nádornál, azért, hogy eme írást állandóan szeme elõtt tartván, se maga el ne térjen valamiben az elõbb mondottaktól, se a királyt vagy a nemeseket, avagy másokat eltérni ne engedjen, hogy õk is örvendhessenek szabadságuknak, és ezért hozzánk és a mi utódainkhoz mindig hívek legyenek, és a királyi koronát megilletõ szolgálatokat meg ne tagadják. ”** * http: //hu. wikipedia. org/wiki/Aranybulla ** 1222 -es aranybulla szövege, http: //ehumana. hu/arpad/szcim/to 12 -2. htm 6

Az aláírás módja – Szignó / kézjegy – analfabéta: X + és ujjlenyomat – középkori uralkodók: szimbólum (István király, török szultán) valószínű, hogy maximum csak egy vonalat húztak be az „aláírásban” – az aláíró nevének az aláíró által egyedi formában rögzítése – További biztonsági eljárás: bélyegző – birtokolni kell – aláírás megtételére való jogosultság bizonyítása – középkorban viaszpecséttel lezárt levél: a címzetten kívül más korábban nem olvashatta az üzenetet. 7

Kézjegy – Az aláírást mindenki maga alakítja ki (ezért egyedi) – idővel változik az aláírás a SZIG-ban, melyet tizenévesként tettünk meg nem biztos, hogy azonos lesz a későbbi aláírásmintánkkal, így pl. kártyás fizetéskor probléma lehet. – Változás oka pl. : életkor, divat, felhasználási terület pl. Dékán index aláírásakor: mechanikus és hivatalos kézjegy, mely különbözhet pl. a karácsonyi képeslapokétól. Ábra: István Kiráy aláírása, I Szulejmán szultán (1520 -66) tugra-ja. (The Metropolitan Museum of Art, Turkish, Istanbul Mid-16 th century, Ottoman period Gouache and gold leaf on paper 20 1/2 x 25 3/8 in. (52. 1 x 64. 5 cm) Rogers Fund Acquired in 1938) A tugra nem más, mint az uralkodó hivatalos monogrammja, mellyel minden, az udvar által kibocsátott dokumentumot elláttak. Hivatásos kalligráfusok készítették a tugrát, tehát nem a szultán írta alá. A tugra tartalmazza a Szultán címeit neveit majd a BN (bin -fia) kötőszó után az apja nevét, a Han (uralkodó), Muzzafer (győzedelmes) dâima (mindörökké) Sah (Perzsául uralkodó) címeket. I. Sulejmán (Mohács): Kanuni Sultan Suleyman bin Selim Han Muzzafer dâima Sah 8

Az aláírás ellenőrzése – Az aláírás mintájának ismerete – egyedi aláírásminta nem mindig olvasható => aláíró nevét/azonosítóját is mellékelni kell – Az aláírást és az aláírót össze kell rendelni egyértelműen lebukott bliccelő a BKV ellenőrnek megadja a Dr. Lefül Elek, Bp. XXXVI. Korrum Pál u. 500. nevet és címet, és aláírja a büntetőcédulát. – Harmadik fél általi igazolás (pl. anyakönyvi hivatal, okmányiroda) – Igazolás megadásakor személyes megjelenés 9

Problémák az aláírással – – – Az aláírásminták nem titkosak (hamisítás) nincsenek általános szabályok (hogyan, ki írhat alá) aláírásminta változhat felszívódó vegytinta: letagadhatatlanság bélyegző ellopható / másolható / készíthető ha olyan aláírással lesz a dokumentum jegyezve, mely nem az aláíró szokványos mintája, akkor később sikeresen letagadható 10

Aláírások az elektronikus világban Elektronikus aláírás – Elektronikus dokumentumhoz, azonosítás céljából logikailag hozzárendelt (és azzal elválaszthatatlanul összekapcsolt) elektronikus adat. – Minden, amit egy elektronikus irat végére teszünk aláírás céljából Minősített elektronikus aláírás(TÖRVÉNY) Fokozott biztonságú elektronikus aláírás (TÖRVÉNY) – hitelesség, sértetlenség, letagadhatatlanság követelményeit teljesíti – nem azonos a digitális aláírással, azonban a realizációja a nyilvános kulcsú kriptográfia 11

Digitális aláírás – Nyilvános kulcsú kriptográfián alapuló elektronikus aláírás Nyilvános kulcsú infrastruktúra (PKI) – Azoknak az eljárásoknak, sw és hw-eknek, emberi erőforrásoknak, és szabályoknak a gyűjteménye, melyek a nyilvános kulcsú kriptográfián alapuló tanúsítványok előállításához, menedzseléséhez, (tárolásához, szétosztásához, visszavonásához) szükségesek – elosztott: PGP / centralizált: CA Tanúsítvány Hitelesítő központ (CA) 12

Digitális aláírás előnyei, felhasználási területei Elektronikus iratok: – kevesebb helyet foglalnak, – könnyebb keresni bennük. – Cél: a dokumentumok életciklusa legalább a hagyományos, papír alapú biztonsági szinten valósuljon meg. Elektronikus kommunikáció, világ: – levelezés (tágabb értelemben üzenetküldés) – biztonságos web szerver elérés – sw hitelesítés (pl. M$ Macromedia, Linux programmok) – szerző azonosítás – letöltött program sértetlenségének, hitelességének megállapítása – VPN (pl. IPSec) – azonosítás és beléptetés 13

Digitális aláírás eszközei Aláírás – Digitális adat (melyet aláírnak) – Aláírás létrehozó adat (privát kulcs) – Aláíró eszköz/környezet Ellenőrzés – digitális adat (melyhez aláírás tartozik) – aláírás ellenőrző adat (publikus kulcs) – Aláírás ellenőrző környezet 14

Digitális aláírás problémái – Mobilitás (laptop, PDA, mobil telefon) – transzparens működés (a felhasználó nem érzékeli, nem kell küszködnie) – beépített, hiteles/megbízható eszközök – több különböző szabvány/kezdeményezés - nem kompatibilisek – jogi szabályozás – felhasználók bizalmatlansága/tájékozatlansága – Dokumentumok hitelesítése: elektronikus okiratot kinyomtatják, hagyományos módon aláírják. =>párhuzamosság a dokumentum kezelésben => mégtöbb erőforrás. –. . . 15

Megbízhatatlan kommunikációs csatorna Hagyományos kommunikáció – galamb: lenyilazzák, megsütik. Pitbull vs. postás – hírnök, kurír: megkínozzák, lecserélik Az információk formalizált módon továbbítódnak (0/1) olyan kommunikációs csatornán, mely pont e miatt észrevétlenül támadható. Támadások az elektronikus világban – eltérítés A – késleltetés A – üzenet lehallgatás P – visszajátszás A – üzenettagadás P – üzenet módosítás A – megszemélyesítés. A – forgalom elemzés P – Aktív támadás: üzenet tartalmába, üzenetküldés menetébe való beavatkozás 16

Megbízhatatlan komm csatornán biztonság biztosítása. . . 17

II. Algoritmusok Tartalom: Lenyomatkészítő: 1. MD 5 2. SHS szabvány, mely tartalmazza: SHA-0, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 Asszimetrikus: 1. RSA, 2. DSS szabvány , mely tartalmazza: DSA, Elliptikus DSA (EDSA) Szimmetrikus: AES Key escrow: EES 18

Hash függvények Hash függvény: leképzés: tetszőleges hosszú üzenetből fix hosszú lenyomatot képezünk: – pl. Lenyomat, sűrítmény (compression function): hash mérete kisebb, mint az üzenet Egyirányú hash: h nem invertálható, ill. nehéz/lehetetlen egy adott s-hez olyan x-et talalálni, melyre h(x)=s. – Pl. CRC nem egyirányú – nehéz/lehetetlen v. keresztülvihetetlen azt jelenti, az x (hash inverzének) keresése esetek túlnyomó többségében sikertelen, mert a keresés túl sok időt, helyet igényel. – Pl. legyen p egy 1024 bites, véletlenül kiválasztott prím, g relatív prím, és h’ hash: akkor h’ egyirányú hashnek tekinthetjük, hiszen könnyű hatványozni, viszont nehéz diszkrét logaritmust számolni 19

Ütközések (Collisions) Ütközés (collision): találunk olyan párt, melyre azonos lenyomat generálódik. Weak collision resistant (gyenge ütközés álló): kivitelezhetetlen ütközést számítani egy adott x üzenethez pl. adatbázis/program stb. (x) lenyomata y=h(x). A lenyomat értékét (y) magunknál tartjuk, miközben magára hagyjuk (munka után hazamegyünk) az x adatot. A támadó kicserélheti az x-t x’-re, de ha a hash algoritmusunk weak collision resistant, akkor nem lesz képes a támadó olyan x’-t generálni, melyre h(x)=h(x’). Így észleljük a támadást Strong collision resistant (erős ütközés álló): kivitelezhetetlen bármilyen ütközést generálni ilyen algoritmusokat kell digitális aláíráshoz használni 20

Secure Hash algoritmusok biztonságos v. egyirányú hash erős ütközés álló tulajdonság ne lehessen egy adott lenyomathoz üzenetet találni ne lehessen két olyan üzenetet találni, amelynek ugyanaz a lenyomata az üzenetekben bármely változás nagy valószínűséggel eltérő lenyomatot eredményezzen MD 5, RIPEMD-160, SHA 21

Secure Hash algoritmusok felhasználása üzenet lenyomat (message digest) – e. g. kernel. tgz md 5 checksum digitális aláírás – tanúsítványok, végponti hitelesítés, . . . elekronikus okiratok üzenet hitelesítés (Message Athentication Code) – e. g. HMAC véletlenszám generálás 22

Lenyomatok jósága Elméleti maximum: – csak véletlenül találunk két üzenetet, melynek azonos a lenyomata – csak véletlenül tudunk találni egy adott lenyomathoz egy üzenetet A lenyomat méretével arányos n bit hosszú lenyomat esetén 2^n számú lenyomat lehetséges 2^(-n) annak az esélye, hogy egy próbálkozásból – találunk két üzenetet, melynek azonos a lenyomata ill. – találunk egy adott lenyomathoz üzenetet. Születésnapi paradoxon: többször próbálkozunk 23

Születésnapi paradoxon I. egy teremben k ember n db különböző születésnap (tipikusan n=365, de általánosítunk) az i-edik ember születésnapja bi , (1 i k) egyenlő valoszínűséggel eshet az n különböző születésnapra. A k ember születésnapja nk féleképp lehetséges, azaz annak az esélye, hogy a k ember egy adott (b 1…, bi, …, bk) -nak felel meg: Pr((b 1…, bi, …, bk) |b 1=B 1, …, bi=Bi, …, bk=Bk ) =1/nk Annak a valószínűsége, hogy leggalább két embernek ugyanazon a napon van a születésnapja legyen p, ill q=1 -p annak a valószínűsége, hogy a k emberből bármely kettőnek nincs ugyanazon a napon a születésnapja. – n(n-1)(n-2)…(n-k+1) számú születésnap „kiosztás” lehetséges, úgy: (b 1…, bi, …, bj, …, bk) | bi bj i, j 24

Születésnapi paradoxon II. Annak az esélye, hogy két embernek nincs ugyanazon a napon a születésnapja: minden valós számra igaz, hogy: Azaz: Tegyük fel, hogy q 1/2, azaz annak az esélye, hogy két személynek ugyanazon a napon lesz a születésnapja: n=365 esetén k=23 adódik, azaz 23 személynek kell egy teremben lenni, hogy nagyobb mint 50% valószínűséggel két embernek ugyanarra a napra (pl. febr 28) essen a születésnapja n=30 esetén k=8 adódik, azaz 8 személy esetén több, mint 50% az esély, hogy két embernek egy hónapon belül ugyanarra a napra (pl. 28 -adika) esik a születésnapja. 25

Születésnapi támadás I. erős ütközésálló tulajdonságot támadja tetszőleges üzenetek és lenyomataik generálása – annyi párt generálunk, amennyit az időnk, tárhelyünk, CPU kapacitásunk, stb. bír. Születésnapi paradoxonon alapszik – egy bizonyos számú üzenet-lenyomat pár felett az esélyünk az ütközésre meghalad egy elfogadható valószíműség-értéket pl. 50% Feltételezzük, hogy a hash függvény bemenetét (x üzeneteket) úgy választjuk, hogy a lehetséges lenyomatok teréből minden lenyomat-érték egyennlő valószíműséggel következzen be. – Megj. Szándékosan nem tudunk úgy üzeneteket választani, hogy azonos eloszlású legyen a kimenet, viszont feltételezhetjük, hogy a hash függvény kb. így működik. 26

Születésnapi támadás II. Lenyomat értékek a születésnapi paradoxon születésnapjaival egyenlő. (n db születésnap van egy évben, azonos valószínűséggel ~ N db lenyomat lehetséges, azonos valószínűséggel) Az üzenet-lenyomat párok száma analóg a születésnapi paradoxon személyek számával (k db személy a teremben ~ K db üzenet-lenyomat pár) ha mérete: azaz a hash értékkészlete ennek a (n bit hosszú lenyomat esetén) 27

Születésnapi támadás III. a születésnapi paradoxonból következik, hogy az ütközés valószínűsége nagyobb, mint 50% azaz: Akkor, ha legalább K db üzenet-lenyomat pár ismert: mivel azaz legalább kb. kell legenerálni. nagyságrendű üzenet-lenyomat párt 28

Yuval támadása (klasszikus születésnapi támadás) I. Eredeti szöveg: x 1 hamis szöveg (az eredeti torzítottja): x 2 h hash függvény, m-bit kimenettel Cél olyan x’ 1 , x’ 2 generálás, melyek csak kissé (space, enter, tördelés, ékezetek, helyesírási hibák) térnek el az x 1 , x 2 szövegektől, és h(x’ 1)=h(x’ 2) – Így ha x’ 1 -t aláírják, akkor x’ 2 -t is hitelesítik 29

Yuval támadása II. 1. Az x 1 eredeti szövegből darab x’ 1 generálás 2. Az x’ 1 üzenetek lenyomatainak képzése. A h(x’ 1) lenyomatok alapján rendezve az üzenet-lenyomat párokat adatbázisban tárolás. (Így az adatbázisban keresés O(t) időt igényel) 3. Az x 2 hamis szövegből x’ 2 hibás-hamis szöveg generálása és h(x’ 2) lenyomatának képzése. 4. Az adatbázisban levő h(x’ 1) lenyomatok összehasonlítása a h(x’ 2) -vel. Ha h(x’ 1) =h(x’ 2) , akkor sikerült két szöveget találni, melynek ugyanaz a lenyomata, és nagyjából egyezik az eredeti szöveggel. Ha nem egyezik h(x’ 2) az adatbázis elemeivel, akkor a 3. Pontra ugorva újabb hibás-hamis szöveg generálás. Megj. : ütközés t darab x’ 2 generálás után várható 30

Yuval támadásának alkalmazása Támadó az aláíró: – az x 1 üzenetet befogadja, majd az x’ 1 üzenetet írja alá – később letagadja az üzenet aláírását, és azt állítja, hogy az x’ 2 üzenetet írta alá Támadó az aláírás ellenőrzője/szerződő fél: – meggyőzi, hogy írja alá az x’ 1 üzenetet/szerződést – majd azt állítja, hogy az aláírás az x’ 2 üzeneten/szerződésen szerepel. (fogja az aláírást és az x’ 2 szerződés végére helyezi) Ha a lenyomat kimenete 160 bit, akkor alapján csak 80 darab olyan pontnak kell lenni az üzenetben/szerződésben, ahová hibát szúrhatunk be! A hibás dokumentumok szemantikailag ugyanolyan üzenetek, csak spacek, enterek, v. helyesírasi hibák szerepelnek! => valós fenyegetés 31

HMAC XXX FIPS RFC Mire való Egyenlet 32

Hash algoritmusok MD 5 SHA család RIPEMD-160 33

MD 5 NA 34

Secure Hash Signature Standard (SHS) NIST (US, National Institute of Standards and Technology) ITL (Information Technology Laroratory) által kibocsátott szabvány FIPS 180, 180 -1, 180 -2 (jelenleg FIPS 180 -2) FIPS 180: SHA v. SHA-0 algoritmus tartalmazta XXXév FIPS 180 -1: SHA-1 (1993) FIPS 180 -2: SHA-1, SHA-256, SHA-384, SHA-512 (2002 év) FIPS 180 -2 kiegészítése: SHA-224 (2004 év) Alkalmazandó minden US kormányzati kommunikációban: – érzékeny, de nem minősített info (for sensitive and unclassified info) – mindenhol ahol secure hash algoritmus használata szükséges http: //csrc. nist. gov/publications 35

Igények az SHS algoritmusaival szemben ne lehessen egy adott lenyomathoz üzenetet találni ne lehessen két olyan üzenetet találni, amelynek ugyanaz a lenyomata az üzenetekben bármely változás nagy valószínűséggel eltérő lenyomatot eredményezzen “Ne lehessen” (computationally infeasible): XXX strong collision resistant 36

SHA Algoritmuscsalád felépítése Ismert konstansok, függvények, logikai operátorok Előfeldolgozás – üzenet padding – üzenet blokkokra tagolása – kezdeti értékek (H) beállítása Hash számolás (minden blokkra) – “message schedule” generálás (az egyes blokkok kiterjesztése nagyobb méretű adathalmazra) – függvények, konstansok, logikai operátorok segítségével hash sorozat generálása – az utolsó blokk kimeneti hash sorozata lesz a sűrítmény 37

SHA algoritmuscsalád összehasonlítása * születésnapi támadást feltételezve, 2^[(lenyomat merete)/2] próbálkozás esetén az ütközés valószínűsége nagy 38

Az egyes SHA aloritmusok használata nagyobb üzenetméret aláírás algoritmusa: 160 v. nagyobb bit , . . . 39

SHA-0 SHA v. SHA-0 Secure Hash Algorithm FIPS 180 szabvány (XXXév) max. üzenethossz: XXX lenyomat mérete: XXX 1993 -ban átvizsgálták, módosították: – körkörös bal eltolás operátort hozzáadtak – Az így módosított szabvány neve SHA-1 (FIPS PUB 180 -1) 40

SHA-1 Tetszőleges hosszú (de kevesebb mint 2^64 bit) üzenetből 160 bit lenyomatot/sűrítményt készít 41

SHA-1 függvények 42

SHA-1 konstansok, kezdeti hash értékek 43

SHA-1 padding 44

SHA-1 előfeldolgozás 45

SHA-1 lenyomat számítás 46

SHA-224 és SHA-256 47

SHA-256, SHA-224 függvények 48

SHA-224 kezdeti hash 49

SHA-256 kezdeti hash értékek 50

SHA-224, SHA-256 konstansok 51

SHA-224, SHA-256 Előfeldolgozás u. az, mint SHA-1 52

SHA-224, SHA-256 lenyomat számítás 53

SHA-224 vágás (Kell? ? ? ) 54

Az egyes hashfüggvények összehasonlítása sebesség biztonság 55

hashfüggvények sebességbeni összehasonlítása Konfiguráció: openssl, linux, hw, . . . táblázat algoritmus – üzenetméret – kísérletszám 56

hashfüggvények biztonsága 57

aszimetrikus algo RSA DSA Elliptikus El gammal 58

RSA NA 59

DSA, DSS Digital Signature Standard FIPS PUB 186 -2 , algoritmusa a DSA RSAhoz hasonló módszer, prímszámokon manipuláció, de nem faktorizálás, hanem diszkrét logaritmuson alapul NSA fejlesztette ki: bizalmatlanság: lehet, hogy van benne kiskapu, de: – elterjedt, így a civil világ megtalálja, ha létezik, – NSA feladata a kódolt üzenetek olvasása, és nem dokumentumok hamisítása Kevesebb ismert lehetséges támadási pontja van, mint az RSAnak Kb. 25 ször lassabb az ellenőrzése, mint az RSAnak. Az aláírás kb. ugyanolyan sebességű Titkosításra nem ? ? LEHET HASZNALNI, MIERT? ? ? 60

Digital Signature Algorithm (DSA) p: prime modulus q: prime divisor of p-1 h, g x, k random y p, q, g can be public x, k private key y public key 61

DSA aláírás mechanizmusa r , s maga az aláírás M az üzenet, SHA-1 a hash (160 bit) k-1 multiplicative inverse of k in mod q if r, s=0 => új k generálás 62

DSA aláírás ellenőrzése p, q, g ismert, y nyilvános kulcs M*, r*, s* a bizonyításra bemutatott M, s, r 1. Ellenőrzés: 0<r*, s*<q ha nem teljesül, az aláírás érvénytelen 2. 3. 4. 5. 6. ha igaz, akkor a küldő rendelkezik az x titkos kulccsal, és aláírta az üzenetet. 63

Bizonyítás, hogy v=r’ Lemma 1 Lemma 2 Biz. 64

DSS - Digital Signature Standard 65

III. Kucsok, Tanúsítványok Kulcsmanagement – – – Kulcs generálás Kulcs tárolás Kulcs letét Beolvasás felhasználás megsemmisítés Tanúsítvány – felépítése – osztályzása 66

Kulcsgenerálás Helye: – hitelesítés szolgáltatónál: – hitelesítő egységnél – regisztrációs egységnél – felhasználási helyén – felhasználó számítógépében (sw-es, file) – felhasználó hw-ében hitelesítésszolgáltató generálja -> visszaélhet felhasználó generálja -> bizonyítania kell a hitelesítés szolgáltatónak, hogy rendelkezik a publikus kulcshoz tartozó magánkulccsal. CA randomot küld a priv. kulcs tulajdonosának ha be tudja titkosítani/aláírni, akkor a CA a publikus kulccsal ellenőrizheti legjobb megoldás: az user generálja, de a szolgáltatónál (user a CAban) 67

Kulcs tárolás, beolvasás Kulcs tárolás – fileban (észrevétlenül másolható) – hw tokenben (intelligens kártya, Hardware Security Module) hordozható, nehezen kiolvasható – titkosítva tárolva Beolvasás – A tárolás helyéről ne kerüljön nyilvános területre – pl. a felhasználó a crypto filejából beolvassa a titkát, ezalatt a root a /proc/mem -ből kiolvassa ugyanezt – a kulcsok felhasználási helyének is védettnek kell lennie 68

Kulcsok felhasználása Különböző célokra – gyakori használat esetén kriptanalízis – mások a felhasználási körülmények – Hitelesítő szolgáltatók bevétel Külön kulcspár külön célokra – Tanúsítványban jelzik, hogy milyen célra használhatók/lettek kibocsátva a kulcsok – export korlátozások (titkosítás: kisebb kulcshossz) – céges/felhasználói politika: pl. különböző kulcshosszak titkosítás aláírás ügyvédi iroda közepes erős bank erős levelezés közepes nincs Egy kulcspár - (több célra is) - egy tanúsítvány 69

Kulcsok megsemmisítése/tárolása Kükönböző feltételek: Aláíró kulcspár – nyilvános kulcs: Archiválás szükséges (régebbi aláírások ellenőrzéséhez) – magánkulcs: – csak a tulajdonosé – nincs biztonsági mentés, újragyártják – lejárat után megsemmisítés Titkosító kulcspár – nyilvános kulcs: eldobják, nem kell archiválni – magánkulcs: – titkos csatornán, meghatalmazottak közt osztva – mentés lehetséges (titkos infok későbbi visszafejtéséhez) – lejárta után sem biztos, hogy megsemmisítik (visszafejtés) 70

Kulcsok megsemmisítése/tárolása 2. Lejárat után a magánkulcs aláírás esetén mindenképp érvénytelenné vállik, de titkosítás esetén a támadó a korábban megszerzett, kódolt információt visszaállíthatja. Ezért a magánkulcsot ekkor is védeni kell. 71

Kulcs letét – – Magán kulcs elhelyezése megbízható harmadik résztvevőnél általában hitelesítő központokban, biztonságos archiválás key escrow: US más is rendelkezik ugyanazzal a titkos kulccsal, így lehetősége van… – csak titkosításhoz szükséges privát kulcsot tesznek letétbe, aláíráshoz nem 72

Tanúsítványok Hagyományos tanúsítvány – olyan dokumentum, amely valamilyen hivatalos állítást tartalmaz vminek alátámasztására – pl. SZIG, TAJ, útlevél – vmilyen független, megbízható intézmény hitelesíti Digitális tanúsítvány – olyan elektronikus irat, melyet, illetve amelyben lévő információt, digitális aláírással igazol egy megbízható hamadik résztvevő (trusted third party) – ebben a résztvevőben a felhasználók egy közössége megbízik 73

Tanúsítványok 2. megbízható hamadik résztvevő – lehet központosított (hitelesítő központ - CA), a közösségnek egy objektumban kell megbízni – elosztott (PGP tanúsítványánc) a közösség saját maga által kiépített bizalmi láncban bízik – CA tanúsítványa nagyobb biztonságot nyújt, de a CA-nak erős védelem kell. PGP esetén a leggyengébb láncszem buktatja a bizalmi láncot 74

Tanúsítványok 3. Célja – Dokumentumot hitelesítse – Hitelesítés hatékony legyen sok ezer dokumentum esetében is Megoldás – Digitálisan aláírt dokumentumot az aláíró publikus kulcsa hitelesíti – Az aláíró publikus kulcsát pedig a digitálisan aláírt tanúsítvány hitelesíti – a tanúsítvány az aláíró személye és publikus kulcsa között erős kapcsolatot teremt, hogy a hitelesítés teljesüljön 75

Tanúsítványok felépítése – – – Tulajdonos azonosító adatai összekötés Tulajdonos publikus kulcsa Hitelesítés szolgáltató azonosító adatai (azonosítás) Egyéb paraméterek, attribútumok (módja, helyzete) Hitelesítő központ digitális aláírása További tulajdonnságok – Azonosító adatok: a felhasználói közösségnek a tulajdonos felismerésére alkalmas azonosító (James Bond helyett csak „ 007”) – nyilvános – nem kell további kiegészítő információ (kompakt) – hitelességet, letagadhatatlanságot, sértetlenséget is biztosít 76

Tanúsítványok osztályzása – Hitelesítő központban nem választhatjuk meg egyedileg, milyen kulcshosszt, érvényességi időt, algoritmust, és egyéb más jellemzőket szeretnénk, hanem “csomagok” közül kell választanunk – csoportosítás: Típusok és osztályok. Osztály és típus mátrixot alkot, melyből választhat. (Erősség X felhasználás célja) – Típusok – Felhasználás módja (Banki Webezés/ általános Web/ minősített/ levelezés) – Felhasználás célja (magán/ céges/ hardware -tűzfal, token) – kulcs felhasználása (csak aláír/ csak titkosít/ midkettő) a fentiekbők következik 77

Tanúsítvány osztályok – Biztonsági szintek szerint – algoritmus biztonság – azonosítás módszere – magánkulcs biztonság – CA általi egyébb biztonsági intézkedések – Jelzés szerint: betűjelzés - (A, B, C), számjelzés: (1, 2, 3) mutatja a szinteket, de hogy melyik szint mit ér: hitelesítés szolgáltatóktól erősen függ – Még hitelesítési központok között sem feleltethetők meg a biztonsági szintek, mindig az adott CA dokumentációja specifikálja – EU, Magyar szabályozás: – Minősített tanúsítvány (EU, Mo. ) speciális előírások, követelmények - legerősebb – Fokozott biztonságú (Mo. ) 78

IV. Hitelesítő központok 1. Tanúsítványok kibocsátása 2. Tanúsítványok visszavonása 3. Aláíró eszközök 4. Hitelesítésszolgáltató felépítése 79

1. Tanúsítványok kibocsátása – – – Igénylés megújítás/frissítés igénylő azonosítása adatok ellenőrzése Tanúsítványok elkészítése Tanúsítványok szétosztása 80

Igénylés – Üzleti művelet: jogi és adminisztratív vonatkozások – szerződési feltételek – forma nyomtatvány (igénylő űrlap) – Papír alapú – elektronikus forma (az űrlapot aláíró kulcsnál csak gyengébb tanúsítványt bocsátanak ki) – igénylő és felhasználói adatok rögzítése (egy része a tanúsítványban megjelenik, másik a szolgáltatónál belső használarta) – publikus kulcsot, és a bizonyítékot mellékelni, mellyel bizonyítja, hogy a magánkulccsal rendelkezik (CA által generált random, a privát kulccsal aláírva) – igényelt osztály, típus, egyéb paraméterek 81

Tanúsítványok megújítása, frissítése 1. – Érvényességi idő lejárta előtt lehet – Privát kulcsnak érvényesnek kell lennie (pl. CA certificatehez tartozó privát kulcs hamarabb jár le, mint a publikus kulcs a tanúsítványban) – Ekkor digitálisan aláírható az igénylés – Nyilatkozat (akár elektronikusan): minden személyes adat érvényes, változatlan (különben teljes igénylési procedúra) – régi kulcspár is felhasználható, de célszerű új kulcspár generálása (felhasználó generálja: challenge-response alapú bizonyítás a privát kulcs birtoklásának alátámasztására; CA generálja a kulcspárt: privát kulcsot el kell juttatni biztonságosan) – időközönként (2 -5 év) személyes megjelenés kell (igénylés folyamata) – ha a hitelesítéshez felhasznált okmányok érvényessége lejár, nem lehet hosszabbítani – Frissítéskor, megújításkor a régi tanúsítványt, mely még nem járt le, vissza szokták vonni 82

Tanúsítványok megújítása, frissítése 2. – Ha a magánkulcs kompromittálódott, a tanúsítványt visszavonják, így nem lehet frissíteni, teljes igénylési procedúra szükséges – A CA saját gyökér tanúsítványait is meg kell újítani – olyan felhasználói tanúsítványt nem ad ki a CA, mely meghaladná saját tanúsítványának érvényességét – Hitelesítési központ tanúsítványaival (pl. root certificate) rövidebb ideig lehet aláírni, mint ameddig ellenőrzésre érvényes. Tehát a magánkulcs érvényességi ideje rövidebb, mint a tanúsítványban szereplő publikus kulcsé. – Ha egy root certificate/hitlesítés szolgáltató tanúsítványához tartozó magánkulcs kompromittálódik, akkor az összes alatta levő tanúsítvány érvénytelen lesz 83

Az igénylő azonosítása 1. – Nem világméretű egyedi azonosító, hanem csak a hitelesítő központban egyedi (azonosító szám) – Azonosító általában a felhasználó neve + cégnév + lakhely (nem kell több, adatvédelmi okok) – egyetlen egyedi azonosító a közigazgatásban (pl. APEH, TAJ, … ): tanúsítványunkat el kell juttatnunk minden hivatalhoz, mellyel kommunikálni akarunk, megállapítják személyünkhöz tartozását – egyetlen tanúsítványba az összes azonosító (TAJ, APEH, SZIG) befoglalása – tulajdonos jogosítványait (pl. osztályvezető, gazdasági ig. , marketing, alkirály. . . ) fel szokták tüntetni, hogy a tranzakcióra (pl. szerződés aláírására) jogosult-e – hardware az azonosító: IP cím, domainnév, URL, … 84

Az igénylő azonosítása 2. – Az azonosító nem szabadul fel a tanúsítvány lejártakor, visszavonáskor, hiszen később is lehet rá hivatkozás – Hitelesítő központban több adat van eltárolva, mint amennyi megjelenik a tanúsítványban Álnév – üzleti célokra kevésbé alkalmas – kommunikáló felek anonimitást szeretnének, de erős végpont hitelesítés mellett. – Valódi adataik ugyanúgy el vannak tárolva a hitelesítő központban – Példa: titkosított levelezés, de nem csak a levél tartalma, hanem a feladója is rejtett marad. 85

Adatok ellenőrzése Különböző ellenőrzési szintek az egyes biztonági szintekhez Példa: Erősség Adat forrás Azonosítási eljárás 0 gyenge Interneten elküldve email cím ellenőrzés (https, levél) faxon, aláírva telefonon közepes személyes megjelenés megvizsgálása erős azonosító okmányok személyes megjelenés azonosító okmányok megvizsgálása, nyilvános adatbázisokban való (on line) ellenőrzés (pl. lakcím nyilvántartó) 86

Igénylés szervezet nevében – Az igénylő személyét azonosítani – szervezet azonosságát igazolni (pl. cégbírósági bejegyzés) – jogosultság igazolása, hogy az igénylés (és más ügylet) végrehajtásában jogosult az igénylő 87

Tanúsítvány elkészítése – Űrlap felvétele és ellenőrzése – kulcspár generálása – tanúsítvány összeállítása és aláírás – adatbázisba helyezni a tanúsítványt – tanúsítványt közzétenni, naplózás – számla : ) 88

Tanúsítványok szétosztása Saját tanúsítványom, aláíróm tanúsítványa, …tanúsítvány lánc, … root CA tanúsítvány. -> kevésbé skálázható Tanúsítvány tárak – – Összes kiadott, nem lejárt tanúsítvány visszavont tanúsítványok opcionálisan: lejárt tanúsítványok támadás: tanúsítvány nem elérhető LDAP (Lightweight Directory Access Protocol) – – v 3 az X. 500 könyvtárszolgáltatás egyszerűsített lekérdezési protokollja kompatíbilis az X. 500 -al TCP/IP-re épül 89

2. Tanúsítványok visszavonása Tanúsítványok érvényessége, állapota Visszavonás okai Visszavonás folyamata Tanúsítvány visszavonási lista – típusok – generálása – szétosztása Visszavonás hatásai 90

Érvényességi idő, állapot Jogi értelemben korlátozás Algoritmikus biztonság nem sérül szükségszerűen az érvényességi idő lejártával Állapot: OK/kompromittálódott (visszavont) Érvényességi idő: (tól-ig) gyártási idő- max használható – Korlátozás: kriptanalízis algoritmus/kulcshossz változtatható kompromittálódással a veszteségek csökkenthetők tanúsítvány visszavonási lista mérete kisebb CA üzleti bevétel – addig igazolja (vállal felelősséget) a benne foglalt adatok érvényességét (valódiságát) – Privát kulcs érvényességi ideje rövidebb lehet, mint a publikus kulcsé/tanusítványé 91

Tanúsítvány visszavonás Érvényességi időn belül Nem lehet tanúsítvánt módosítani, ha valami változik, vissza kell vonni Nyilvántartás a visszavont tanúsítványokról – ezek az érvénytelen tanúsítványok – PGP-nél nincs ilyen (kp-i helyen, . . . ) Kulcsot nem lehet visszavonni, csak tanúsítványt 92

Visszavonás kérelmezői/kezdeményezői Felhasználói kezdeményezés Tanúsítványban azonosított szervezet kezdeményezése Szolgáltató Bárki által Egyéb (felügyeleti szerv) 93

Visszavonás okai - Felhasználói kérelem Privát kulcs kompromittálódás v. annak az esélye Magán kulcsot védő adatok (pl. PIN kód) kompromittálódás Privát kulcs megsemmisülése Kulcs hordozó eszköz elvesztése vagy meghibásodása felhasználói adat változás hibás felhasználói adat Osztály/típus (v. egyéb más szolgáltatás) váltás indoklás nélkül 94

Szolgáltató kezdeményezés oka Szerződési feltételek/kötelezettségek megszegése nem fizet felhasználói adatok nem valódiak szolgáltatói adatok változása szolgáltató privát kulcsának kompromittálódása felhasználó biztonsági hanyagságának tudomására jutása szolgáltatás megszűnése 95

További kezdeményezők indítékai Tanúsítványban azonosított szervezet: – – u. az, mint a felhasználói kezdeményezés, plussz: szervezet adatainak változása szervezet megszűnése felhasználó és a szervezet közti kapcsolat megszűnése Bárki által – a fenti esetek (pl. kompromittálódás) bizonyításakor Egyéb – felügyeleti szervek döntése 96

Visszavonás folyamata Kérelmező azonosítása jogosultság ellenőrzés (pl. szervezet hivatalos, felhatalmazott képviselője) Visszavonás okainak, körülményeinek dokumentálása Lejárt tanúsítványt NEM lehet visszavonni utólag, még akkor sem, ha lejárat előtt kompromittálódott a privát kulcs, és erre rájövünk visszavonás végleges, újat kell készíteni (teljes procedúra) Felfüggesztés: időleges visszavonás 97

Tanúsítvány felfüggesztés Temporális visszavonás Nem elterjedt szolgáltatás ha „gyanús” a privát kulcs állapota rövid ideig lehet csak felfüggesztve, addig, amíg meg nem állapítják, hogy a magánkulcs kompromittálódott v. sem nem lehet meghosszabbítani a felfüggesztést, lejárta után el kell dönteni, hogy érvényes v. vissza kell vonni. Nem arra való, hogy inaktív periódusokban (pl. szabadságolás) esetén „letiltsuk” a tanúsítványt 98

Tanúsítvány visszavonási lista I. Certificate Revocation List (CRL) visszavonáskor a tanúsítványt nem töröljük az adatbázisból, hanem egy másik (CRL) listába tesszük Oka: – korábbi aláírások ellenőrzéséhez – ha kitörölnénk, nem lenne nyom, mi történt – ha jóhiszeműen kitöröljük, akkor man-in-the-middle támadás: lekérdezéskor a kommunikációba beinjektáljuk a kompromittálódott tanúsítványt, így az ismét érvényesé válik. (ezek a listák nyilvánosak és csak dig. aláíás védi az egyes tanúsítványokat, mely nem elegendő ilyen támadás esetén) CRL kb. hasonló, mint a korábbi credit card lista, melyet az összes céghez kiküldtek (v. szlovák határőr körözési lista) 99

Tanúsítvány visszavonási lista II. Visszavonási listába belekerül: – – tanúsítvány sorszáma visszavonás/felfüggesztés ténye ideje oka CRL-ből kikerül, ha – felfüggesztést visszavonják – lejár az érvényessége Root Certificate – nem lehet CRL-t generálni a root CA-nak, más módszer kell – pl. weben (hiteles módon) közzétesszük, ha a root CA kompromittálódott 100

Visszavonási lista generálása Előre meghatározott rendszerességgel előbb lehet CRL-t kibocsátani, de később nem mindig tartalmazza a várható kibocsátás idejét (ha nem tudjuk, hogy mikor lesz a következő kibocsátás: könnyű támadás) akkor is lecserélik, ha nincs változás (időbélyeg frissítés) Támadás: CRL-t eltüntetni, elérését megakadályozni (pl. az alkalmazások túlnyomó többsége nem figyelmeztet, de még nem is veszi hibának ha az új, érvényes CRL nem elérhető) 101

CRL szétosztása, ellenőrzése Nyilvánosan közzétéve LDAP / web / postázás CRL mérete megnőhet (kb. 10%-a a kulcsoknak kompromittálódik), nagyobb hálózati forgalom Teljes CRL lista letöltése, ellenőrzése sok hálózati, processzálási erőforrást igényel 102

Tanúsítványok ellenőrzés hatékonyságának növelése I. CRL lista „particionálása” – egyedi azonosító (ID) alapján pl. k=10000, 10%-os kompromittálódás esetén |CLRi| ~1000 – visszavonás oka alapján (kompromittálódott, adat változott, . . . ) Delta CRL – – előző listához képesti változások kisebb hálózati forgalom előző CRL-eket is ellenőrizni kell, hogy konzisztens legyen kevésbé elterjedt 103

Tanúsítványok ellenőrzés hatékonyságának növelése II. Indirekt CRL – – több CRL-ek egyesítése nagy közösségek több szolgáltatók több CRL helyett csak ebben az egyben kelljen keresni. – Pl. kormány/egyetem, stb. 3 főbb egysége 3 különböző szolgáltatóhoz tartozik, szolgáltatónként 3 különböző szolgáltatási szinttel. A 9 lehetséges részhalmaz nem, vagy nehezen képes egymás tanúsítványait elismerni. Megoldás: az inézmény egy pontba osszegyűjti a CRL-eket, és készít egy indirekt CRL-t. 104

Tanúsítványok ellenőrzése CRL letöltés CRL ellenőrzése (sértetlen, hiteles) Érvényesség ellenőrzés: CRL-ben rögzített időpont vs. – Pontos idő; – előző CRL-ben jósolt idő Visszavonási lista felülírása Ezután a frissített adatbázisban keresés 105

Visszavonás és hatásai 106

Visszavonás és hatásai II. Ha nincs időbelyegzo az aláírt dokumentumon, akkor csak úgy lehet eljárni, hogy: ellenőrzés ideje <visszavonás ideje (CRL-ben szerepel) 107

Felelősségek és visszavonás 108

Periódikus CRL kibocsátás CA nem motivált a visszavonást hatékonnyá tenni 109

Aszinkron CRL kibocsátás CA motivált (jogilag, gazdaságilag, bizt-i szint) kibocsátani 110

Szolgáltató felelősségének csökkentése I. Azonnali érvényesség ellenőrzés Üzleti szabályzatban leírja, hogy minden tanúsítvány elfogadása előtt várja meg a következő CRL lista kibocsátását. – Ha szerződés, akkor még elfogadható – Ha kommunikáció (pl. banki elérés) -várj egy napot v. órát - akkor nem 111

Azonnali érvényesség ellenőrzés On-line Certificate Status Protocol (OCSP) RFC XXXX Kérdés a szolgáltatóhoz: egy adott tanúsítvány megfelelő? Hitelesített (aláírt) válasz: igen/nem, ha nem, akkor visszavont/ felfüggesztett tanúsítványok jelenlegi állapotáról ad információt Erőforrás igény a szolgáltatónál adatvédelem -nem lesz közismert (közzétéve egy nyilvános listában) a visszavont tanúsítványok tulajdonosai nincs CRL szétosztási probléma utólagos bizonyításhoz OCSP válasz bemutatható Hátránya: szolgáltató is CRL -ből veheti az információt 112

OCSP protokoll leírás? ? ? XXX kell? ? 113

Time Stamp Protocol 114

3. Aláíró eszközök Kulcstároló eszközök csak tárolják (pl. pendrive, floppy, smartcard) aláíró eszközök: kulcsot védve tárolják és aláírásra is képesek (magánkulcs nem hagyja el az aláíró eszköz környezetét) pl. PDA, PC-PCI kártya aláíró környezet: teljes környezet, melyben az aláírás folyamata lejátszódik (HDD, keyboard, CPU eszközök kapcsolata) 115

Kompakt aláíró eszköz 116

Aláíró környezet - Aláírás Létrehozó Eszközök Aláírandó adatot jelenít meg, de mást ír alá Más kulcssal ír alá ALE / BALE (Biztonságos Aláírás Létrehozó Eszközök) Intelligens kártya 117

Aláírás létrehozó eszközök belső felépítése 118

4. Hitelesítés szolgáltató felépítése Funkcionális felépítés 119

Hitelesítés szolgáltató belső felépítése Regisztrációs egység Egyedinév kiosztó egység regisztrációs adatbázis Hitelesítő egység Terjesztő egység Tanúsítvány könyvtár kulcs letét Pontos idő egység real-time állapotinformációs egység Tanúsítvány archívum külső érvényesség szolgáltató egység külső pontos idő egység 120

121

V. X. 509 A történetíró (a Képes Krónikából) 1360 körül, Pergamen 122

VI. Példák Kulcsgenerálás (RSA, DSA) CA generálása Certificate Képes Krónika, 1360 körül Pergamen https apache modssl, apache-ssl stunnel 123

VII. Elosztott CA, Küszöbkriptográfia, GKMP? ? ? Koppány lefejezése, Képes krónika, 1360 körül, Pergamen “Elosztott Koppány” 124

Irodalomjegyzék I. SHS DSS MD 5 HMAC Elektronikus Aláírás Törvény Buchmann: Intrduction to Cryptography, Springer Almási: Elektronikus aláírás és társai, Sans Serif openssl 125

Irodalomjegyzék II. RFC CA policy certificate X. 509 LDAP OCSP TSP X. 509 Threshold crypto MD 5, SHA toresek szolgáltatók homepagei, szolgáltatói szabályzatok 126