Informatika | Informatikai biztonság » Fábián Zoltán - Nyilvános kulcsú titkosítások és hitelesítési technikák

-1- NEUMANN JÁNOS INFORMATIKAI FŐISKOLAI KAR Nyilvános kulcsú titkosítások és hitelesítési technikák SZAKDOLGOZAT BMF-NIK 2006 FÁBIÁN ZOLTÁN -2- TARTALOMJEGYZÉK B E V E Z E T Ő. 5 1. A NYILVÁNOS KULCSÚ TITKOSÍTÁSOK MÚLTJA ÉS JELENE 7 1. 1 A titkosítások megjelenéséről 7 1. 1 1 A titkosítások megjelenésének szükségessége 7 1. 1 2 Az elektronikus kommunikáció védelme 7 1. 1 3 Mindenkinek szüksége van védelemre? 8 1. 2 Az alapszintű titkosító módszerek történelmi áttekintése 8 1. 2 1 A Caesar módszer 8 1. 2 2 A Vigenere titkosítás 9 1. 2 3 A véletlen átkulcsolás módszere (one time pad) 9 1. 3 Egy titkosító módszerrel szemben támasztott követelmények 10 1. 3 1 Létezik tökéletes titkosítás? 10 1. 3 2 A támadások lehetséges típusai és a védekezés módjai 11 1. 4 A ma is használatos szimmetrikus kulcsú titkosítási rendszerek áttekintése 12 1. 4 1 Alapelv 12 1. 4 2 A legismertebb titkos kulcsú

algoritmus: a DES 13 1. 4 3 Út az AES-ig: az IDEA és az RC5 14 1. 4 4 Az AES-pályázat 15 1. 5 Kulcsok cseréje a szimmetrikus algoritmusokban 17 1. 5 1 A kommunikációs csatornák jellemzői 17 1. 5 2 A szimmetrikus kulcsú algoritmusok hátrányai 18 1. 6 Nyilvános kulcsú titkosítási módszerek 18 1. 6 1 A Diffie-Hellman kulcscsere 18 1. 6 2 A nyilvános kulcsú titkosítások alapelvei 21 1. 6 3 Az RSA algoritmus elméleti háttere 22 1. 6 4 Az RSA algoritmus 23 1. 6 5 Az RSA algoritmus megfelelő paraméterezése 24 1. 6 6 Az RSA feltörése 25 1. 6 7 Hibrid kriptorendszerek 26 1. 6 8 Az RSA algoritmus implementációját befolyásoló tényezők 27 1. 6 9 Az RSA algoritmus megvalósítása Java nyelven 28 2. Az SSH, MINT INTEGRÁLT TITKOSÍTÁSI MEGOLDÁS 31 2. 1 Az SSH áttekintése 31 2. 1 1 Bevezetés 31 2. 1 2 Az SSH különböző változatai 31 2. 2 Az SSH funkciói 32 2. 2 1 Biztonság 32 2. 2 2 Távoli parancsvégrehajtás 33 2. 2 3 Távoli

fájlátvitel 33 2. 2 4 Távoli hálózati hozzáférés 34 2. 2 5 Biztonságos felügyelet 34 2. 2 6 Proxy szolgáltatások 35 2. 2 7 Az SSH ügyfél-kiszolgáló felépítése 35 2. 2 8 Az SSH titkosító rendszere 35 2. 2 9 Az SSH biztonsági hézagai 36 -3- 2. 2 10 Az SSH ügyfelek és kiszolgálók fajtái 36 2. 3 OpenSSH, a nagyszerű ingyenes megoldás 37 2. 3 1 Az OpenSSH projekt 37 2. 3 2 Az OpenSSH szolgáltatásai 38 2. 3 3 Az OpenSSH telepítése Windows rendszerre 39 2. 3 4 Az OpenSSH szerver biztonságos beállítása 42 2. 3 5 A PuTTY kliens biztonságos beállítása 43 2. 3 6 Kapuátirányítás (tunneling) az SSH segítségével 44 2. 3 7 Esettanulmány: Webszerver biztosítása az OpenSSH segítségével 46 2. 3 8 Biztonságos fájlátvitel SSH-val 47 2. 3 9 Az SSH további lehetőségei 49 2. 4 Szoftverbe integrálható SSH megvalósítások 49 2. 4 1 A SecureBlackbox komponencsalád 49 2. 4 2 A Bitvise függvénykönyvtár 51 3. A KLIENS-SZERVER

ARCHITEKTÚRA MEGVALÓSÍTÁSI KÉRDÉSEI BIZTONSÁGOS CSATORNÁN KERESZTÜL . 52 3. 1 A Kliens-szerver architektúra működése 52 3. 2 Megvalósítási kérdések 52 3. 3 Az Indy Project 53 3. 4 Biztonsági kérdések szoftverbe integrált megoldással 53 3. 5 Nem biztonságos kliens-szerver programok biztosítása 54 3. 6 Esettanulmány: kliens-szerver alkalmazás fejlesztése 54 3. 6 1 Szerveroldali alkalmazás fejlesztése: MP3 Szerver 55 3. 6 2 Kliensoldali alkalmazás fejlesztése: MP3 Kliens 56 3. 6 3 Nem biztonságos program biztosítása SSH csatornával 57 3. 6 4 Távoli alkalmazás-menedzsment biztonságos kapcsolaton keresztül 58 4. HITELESÍTÉSI TECHNIKÁK, ADATVÉDELEM AZ INTERNETEN 59 4. 1 Hitelesítés 59 4. 1 1 A hitelesítés értelmezése 59 4. 1 2 A hitelesség érvényessége 60 4. 1 3 Hitelesítés a gyakorlatban: az SSL 61 4. 2 Digitális aláírások és hitelességi bizonyítványok 62 4. 2 1 A digitális aláírás értelmezése 62 4. 2 2 A

digitális aláírás kezelése 63 4. 2 3 A digitális aláírása tartalma 64 4. 2 4 A digitális aláírás hitelessége 65 4. 2 5 Hitelesítési szolgáltatók, bizalmi modellek 65 4. 2 6 A hitelességi bizonyítvány 66 4. 2 7 Esettanulmány: a K & H Bank Rt Hitelesítő rendszere 67 4. 2 8 A digitális aláírás jogi szabályozása Magyarországon 68 4. 3 Adatvédelem az Interneten 69 4. 3 1 A hagyományos bejelentkezési módszerek 69 4. 3 2 A Phishing és Pharming 69 4. 3 3 A Man in the Middle támadás 70 4. 3 4 A hitelkártya-csalás 71 4. 3 5 Az SSL biztonsági problémái 71 4. 3 6 A napjainkban alkalmazott internetes adatvédelmi technikák 72 -4- F E L H A S Z N Á L T I R O D A L O M. 74 Á B R A J E G Y Z É K. 76 Ö S S Z E F O G L A L Á S . 77 A B S T R A C T. 78 -5- BEVEZETŐ Szakdolgozatomban áttekintem a viszonylag egyszerű titkosítási módszerektől a szimmetrikus titkosító rendszereken át vezető utat a rendkívül biztonságos és sok

problémára megoldással szolgáló nyilvános kulcsú titkosításokig. Az egyes módszerek ismertetésekor kitérek arra, hogy milyen környezetben érdemes őket használni, illetve, hogy milyen hibákat lehet elkövetni az alkalmazásuk során. Minden módszer esetében fontos szerepet kap a hiányosságok, korlátok elemzése, s a helyes megvalósításra vonatkozó ajánlások ismertetése is. Az egyik esettanulmányban a Java-programozók számára készített szabványos függvénykönyvtárakra támaszkodva készítek el egy RSA kulcspár-generálásra és titkosításra alkalmas alkalmazást. A szakdolgozat második fejezetében az SSH-t, mint integrált titkosítási megoldást mutatom be részletesen. Központi szerepet kap a szakdolgozatban, hiszen a legtöbb informatikai biztonsági igényre megoldást kínál, a megszokott kliens-szerver környezetben. Az SSH általános jellemzői után térek rá az OpenSSH-ra, majd a konkrét beállítási és használati

megfontolások ismertetése után az SSH számos funkciójáról is szó esik; köztük a távoli parancsvégrehajtásról, a fájlátvitelről, de a protokollhelyettesítésről is. Minden fontosabb funkciót magam is kipróbálok, különböző hálózati környezetekben, Windows és Linux platformon egyaránt, ellenőrizve az operációs rendszerek átjárhatóságát is. A nagy fontosságú vagy különösen érdekes esettanulmányokat képernyőképekkel illusztráltam. Ilyen például az SSH kapuátirányítás (tunneling) funkciója is, amivel számos felmerülő problémát meg lehet oldani. A harmadik részben a kliens-szerver alkalmazások biztonságos megvalósítása következik: megvizsgálom a többszálúság, a titkosság és érintőlegesen a hitelesség kérdését is. Esettanulmányként egy MP3-fájlok megosztására képes szerver- és kliensprogramot készítettem el, amelyek egy SSH-val biztosított csatornán keresztül képesek kommunikációt

folytatni. A negyedik fejezetben áttekintem a hitelesítés mibenlétét, alkalmazásának módját, majd a napjainkban egyre terjedő digitális aláírást, s annak jogi szabályozását is. Végül az internetes adatbiztonság témakörében vizsgálom meg az általánosan elterjedt -6- támadási módszereket, majd az ezekre választ jelentő legbiztonságosabb megoldásokat, beleértve a modern kétfaktorú hitelesítési technikákon alapuló, képernyőlopó és keylogger programok ellen is védett rendszereket. -7- 1. A NYILVÁNOS KULCSÚ TITKOSÍTÁSOK MÚLTJA ÉS JELENE 1. 1 A titkosítások megjelenéséről 1. 1 1 A titkosítások megjelenésének szükségessége Az emberi együttélés során már nagyon hamar kialakult a kommunikáció olyan formája, amely szükségszerűen megkövetelte a felek közötti diszkréciót. Ennek továbbfejlesztéseként jelentkeztek az írásos kommunikáció különböző fajtái; az információt ez esetben is védeni kellett

az illetéktelen személyektől, hiszen már ekkor is előfordultak olyan esetek, hogy az egyik fél a másiknak szánt üzenetét meg akarta védeni az illetéktelen leskelődőktől, egyszóval meg akart bizonyosodni afelől, hogy üzenetét valóban csak a címzett képes elolvasni. 1. 1 2 Az elektronikus kommunikáció védelme Nincs ez másként a modern világban sem, hiszen számos esetben szükséges lehet például az Internetes kommunikáció biztosítása annak érdekében, hogy értékes információinkhoz csak azok legyenek képesek hozzájutni, akiknek ténylegesen szántuk. Az (elektronikus) kommunikáció szemszögéből vizsgálva olyan tényezők is szerepet játszhatnak az adatok védelmében, amelyek az ún. offline adattárolás esetén nem veszélyeztetik adatainkat. Ilyen lehet például annak a veszélye is, ha valaki lehallgatja az általunk információ-közvetítésre használt csatornát – legyen szó hagyományos, papír alapú levélről (gőzzel

kibontja a borítékot, elolvassa a levelet, majd visszaragasztja) vagy elektronikus levélről (egyszerűen lemásolja az adatok forgalmát). Jelen szakdolgozat a titkosításokat leginkább a kommunikáció szempontjából vizsgálja, s nem célja a különböző adatok (adatbázisok, fájlok) adatvédelmének, alkalmazott titkosításainak ismertetése. -8- 1. 1 3 Mindenkinek szüksége van védelemre? Az információ és a tudás a mai modern világban rendkívül komoly érték lehet, ezért tulajdonképpen mindenkinek szüksége van védelemre, aki fontos adatokat közvetít vagy fogad. Kiváló példa erre az otthonról történő internetes bankolás, amikor banki ügyleteink egy részének intézéséhez (átutalás, lekötés) elegendő egy honlapra bejelentkeznünk a jelszavaink segítségével. Ne feledjük, hogy ekkor minden hozzáférési adatunk (jelszavak, kódok, bankszámlaszám) az Interneten keresztül áramlik a szerver és a számítógépünk között;

képzeljük csak el, hogy mi lenne akkor, ha ezeket az adatokat bárki lehallgathatná, majd a napi banki limit erejéig egy átutalást kezdeményezne a Kajmán-szigeteken nyitott bankszámlája irányában. Így van ez az elektronikus leveleinkkel is, amelyek szerverről szerverre vándorolva számos lehetőséget kínálnak rosszindulatú embereknek arra, hogy hozzájussanak értékes üzleti információinkhoz. S mennyivel kényelmesebb módja ez egy konkurensről való információszerzésnek, mint a szemetesében való turkálás Philip Zimmermann, a PGP atyja szerint az „információs társadalomban a magánélethez való jog csak erős kriptográfia használatával őrizhető meg”. [7] 1. 2 Az alapszintű titkosító módszerek történelmi áttekintése 1. 2 1 A Caesar módszer Ennek a rendkívül egyszerű, kezdetleges titkosításnak az volt a lényege, hogy a titkosított szöveg minden betűjének egy, a nyílt szövegben megtalálható betű felel meg. A kezdeti

időkben ez a módszer fix hosszúságú eltolást alkalmazott, tehát k = 1 eltolást feltételezve lesz az ’IBM’ titkos karaktersorozatból a nyílt szöveg ’HAL’. A dekódolás nyilvánvalóan az eltolás ellenkező előjellel történő alkalmazásával végezhető el. Ez a módszer valószínűleg már Julius Caesar korában sem nyújtott kellő védelmet, hiszen az avatatlan szemlélő ugyan csak zavaros betűhalmazt látott, de aki ésszel tekintett rá, néhány próbálgatással rájöhetett az eltolás nagyságára. Ezért is fejlődött tovább ez a módszer úgy, hogy az egyes betűk már változó hosszúsággal voltak eltolva a titkosított szövegben. Ezzel az apró módosítással a visszafejtéshez már nem volt elég az eltolás ismerete, hanem egy betű-megfelelőségi -9- listára volt szükség. Ez a módszer is törhető volt, például az adott nyelvben gyakori szavak fellelésével, s azok betűire vonatkozó eltolás kiszámításával. Mindkét

módszer hátránya, hogy megőrzi a használt nyelvre jellemző betűgyakoriságot, amelynek ismeretében egy kellően hosszú szöveg számítógéppel másodpercek alatt feltörhető. 1. 2 2 A Vigenere titkosítás A Caesar módszer továbbfejlődéséből adódó ötlet az, hogy ne egy ábécét kelljen használnunk az egész folyamat során, hanem többet aszerint, hogy az adott titkosítandó karakter az eredeti szövegben hol helyezkedik el. Ennek e legegyszerűbb módja az, amikor a szöveg betűit számoknak tekintjük, s egy ismétlődő szó betűit használjuk a titkosításra úgy, hogy az így egymás alá kerülő betűket „összeadjuk”, s az eredmény lesz a titkosított szöveg. A biztonság szempontjából a Vigenere titkosítás ereje abban rejlik, hogy ugyanaz a betű mindig más hosszúságú eltolást szenved, így ez esetben a betűgyakoriság vizsgálata nem hoz eredményt. A feltörés a brute-force módszerrel nagyon sok ideig tart, hiszen k betűs

kulcs esetén 26k darab lehetőséget kell kipróbálnunk, angol nyelvet feltételezve. Ha a titkosított szöveg minden n-edik karakterére végezzük el a betűgyakoriság-vizsgálatot – ahol n a kulcs feltételezett hossza –, akkor ha a kulcs hosszát eltaláltuk, az egyenletestől eltérő eloszlást kapunk. A kulcshossz ismeretében pedig ismét használhatók a betűgyakoriságon alapuló statisztikai módszerek. 1. 2 3 A véletlen átkulcsolás módszere (one time pad) Ez az 1920-ban, Vernam által kifejlesztett módszer hasonlóan működik, mint a Vigenere titkosítás azzal a különbséggel, hogy a kulcs egy véletlenszerűen generált, egyenletes eloszlású karaktersorozat, ami pontosan olyan hosszú, mint a nyílt szöveg. Ennek köszönhetően a titkosított szöveg eloszlása is egyenletes lesz, hiszen minden karaktert véletlenszerű eltolással állítunk elő. A megoldás ereje abban rejlik, hogy irreálisan hatalmas számítógép-kapacitás birtokában sem

törhető, tehát elméleti titkosságot valósít meg [2]. - 10 - A hosszú kulcs azonban tovább bonyolítja az alkalmazást, hiszen megjegyezni nem lehet, valahol tárolnunk kell. Ennek feloldása szteganográfia alkalmazása, például egy publikus szerveren tárolt kép minden prímszám sorszámú bájtja a kulcs. Alkalmazása során hibákat is el lehet követni: például, ha kétszer használjuk ugyanazt a kulcsot. A törés csak heurisztikus módon, a valószínű szövegrészek keresésének módszerével, és kétirányú kiterjesztéssel törhető. A módszer egyetlen invariáns tulajdonságot tart meg, mégpedig a betűk egymás alattiságát. A törés is ezt használja ki 1. 3 Egy titkosító módszerrel szemben támasztott követelmények 1. 3 1 Létezik tökéletes titkosítás? A válasz egyértelműen igen, ha pusztán matematikai értelemben, az elméleti titkosságra vonatkoztatva értjük. Akkor beszélünk ilyenről, ha a nyílt és a rejtett üzenet

kölcsönös információja nulla, tehát semmilyen kapcsolat sem mutatható ki közöttük. I ( x, y ) = 0 1. 1 ábra: kölcsönös információ A titkosság mértéke akkor a legmagasabb, ha a titkos üzenetre (y) minél több lehetséges nyílt üzenetet (x) ad meg. Ebben az esetben a brute-force nehezen alkalmazható Más szóval akkor jó egy rejtjelező rendszer, ha a legkisebb lambdája is kellően nagy; ebből következően az egy-egy megfeleltetés nem nyújt kielégítő titkosságot. Tehát: λ ( y ) =| x ∈ X , x értelmes ∃k ∈ K , amire E ( x, k ) = y | , ahol λ a titkosság mérte, x a nyílt üzenet, y a titkos üzenet, k pedig a lehetséges kulcsokat jelöli. 1. 2 ábra: a titkosság mértéke - 11 - Más szemszögből tekintve akkor fejthetetlen egy titkosítás, ha az egyértelműségi pontja (M0) kisebb, mint a nyílt szöveg elemszáma. Ezzel a képlettel számolható ki egy titkosítási módszerről, hogy hány karakter hosszúságú, az adott

algoritmussal titkosított üzenet elméletileg fejthetetlen. Ez természetesen nem jelenti azt, hogy az ennél hosszabb szövegek már biztosan feltörhetők. A Caesar-módszer esetén például n–1 (n = 26) lehetséges eltolás mellett már 2 karakteres szöveg esetén sem garantált a fejthetetlenség. Ugyanez a változó eltolású módszer esetében 230 karakter hosszúság alatt elméletileg fejthetetlen. Ha a véletlen átkulcsolás módszerét használjuk, akkor a titkosított üzenetnél hosszabb üzenet sem lenne fejthető. M0 = log 2 | k | , log 2 | x | − H (ζ ) ahol log2 | k | a kulcshalmaz elemszáma, log2 | x | a nyílt halmaz elemszáma és H (ξ) a használt nyelvre jellemző forrásentrópia mértéke. 1. 3 ábra: az egyértelműségi pont 1. 3 2 A támadások lehetséges típusai és a védekezés módjai A lehetséges támadási típusokat elsősorban a támadó elhelyezkedésének szempontjából vizsgáljuk. Passzív támadásról beszélünk akkor, amikor

a támadó csak lehallgatja csatornát, aktív támadásról pedig akkor, amikor a támadó képes beépülni a kommunikációba, mintegy átvéve az üzenettovábbító szerepét. A kommunikáció titkosításának legegyszerűbb módja a klasszikus Shamir-módszer használata. Ekkor az A és B közötti üzenetváltás a következőképpen zajlik: - A ráteszi a saját lakatját az üzenetére, majd elküldi B-nek - B is ráteszi a saját lakatját az üzenetre, majd visszaküldi A-nak - A leszedi a saját lakatját az üzenetről, majd visszaküldi B-nek - B megkapja az üzenetet, amin a saját lakatja van; leszedi, és elolvassa az üzenetet - 12 - Követelmény, hogy a két fél titkosító mechanizmusa különböző, s tetszőleges sorrendben alkalmazható legyen. Az egyik ilyen például a xor művelet lehet A fenti módszer alkalmazása során a problémát az jelenti, hogy valaki B-nek adhatja ki magát anélkül, hogy A el tudná dönteni, kivel beszélget

valójában (aktív támadó). A gyakorlatban mégis alkalmazható: A addig nem veszi le a kulcsot, ameddig B egy másik csatornán vissza nem igazolta, hogy megkapta az előző csomagot; az A pedig csak egyszer hajlandó levenni a lakatját. Ez esetben a kölcsönös információ nulla, mivel a különböző titkosítási módszerek használatából adódóan az azonos kulcs használatának valószínűsége nulla. Ahhoz azonban, hogy a kellően biztonságos védekezési módszert dolgozzunk ki, minden ismeretünket, feltételezésünket össze kell foglalnunk a támadóról aszerint, hogy mekkora veszélyt jelent a kommunikációra nézve. Ezt négy veszélyességi fokozattal szokás jellemezni: a.) A támadó rendelkezik a titkos üzenettel b.) Birtokában van nyílt és titkos üzenetpároknak c.) Ismeri a rejtjelező algoritmust, így egy tetszőleges nyílt üzenetből képes előállítani a titkos változatot d.) Képes a titkosító algoritmus inverz függvényének

előállítására is Elfogadható védelmet csak az olyan titkosító módszer jelent, amely a d.) pontnak is ellenáll. Ez csak akkor teljesülhet, ha az ún lavinahatás érvényesül: a bemenet egy bitjének megváltozása a kimenet legalább fele bitjét meg kell, hogy változtassa. Ha ez a kitétel teljesül, akkor a támadó nem tudja, hogy az algoritmus próbálgatása során jó irányba halad-e. 1. 4 A ma is használatos szimmetrikus kulcsú titkosítási rendszerek áttekintése 1. 4 1 Alapelv A korábban ismertetett titkosítási módszerekben közös tulajdonság, hogy a titkosító és a megfejtő eljárás, illetve a műveletekhez használt kulcs ugyanaz. Ezt a kulcsot a kommunikáló feleknek meg kell osztaniuk egymással, majd titokban kell tartaniuk, hiszen ez védelmük egyetlen biztosítéka. - 13 - A titkosító módszerek tervezésénél érdemes elfogadni, hogy az algoritmusoknak nyilvánosaknak kell lenniük, különben nem terjedhetnek el széles körben,

ha nem övezi őket nagyfokú bizalom. Ez azért is fontos, mert ideális esetben egymásnak ismeretlen emberek is kommunikálhatnak egymással; ez az, amit lehetetlenné tenne egy nem szabványos algoritmus alkalmazása az egyik oldalon, hiszen a szoftvereknek mindkét oldalon támogatniuk kell az alkalmazott módszert. 1. 4 2 A legismertebb titkos kulcsú algoritmus: a DES Maga a szabvány a DES (Data Encryption Standard) nevet viseli; ez a betűszó terjedt el a módszer egészére vonatkozóan annak ellenére, hogy az algoritmusnak a szabványban más neve van (DEA). Az alapvető elvárások az algoritmussal szemben a következők voltak: - Nyújtson magas szintű biztonságot - Egyszerű felépítésű, könnyen érthető legyen - A biztonság csak a kulcstól függjön, ne az algoritmustól - Gazdaságosan alkalmazható legyen elektronikus eszközökben is (hardveres úton) A fentiek tükrében eredetileg kitűzött 128 bites kulcs- és blokkméretet az NSA (National

Security Agency) lecsökkenttette 64 bitre sokak szerint azért, hogy az így titkosított üzeneteket az USA nemzetbiztonsági hivatala még fel tudja törni, de más szervezet már ne. A végső kulcsméret további 8 bit ellenőrzési célokra történő lefoglalását követően 56 bit lett, amellyel gyakorlatilag az eredeti kulcstér 99%-át eldobták. Az algoritmust 1975-ben hozták nyilvánosságra, s hamarosan nagyon gyors hardveres implementációk is megjelentek, ezért széles körben elterjedt a polgári élet minden területén. Érdekes, hogy minősített adatok védelmére már akkor sem ajánlotta az amerikai kormányzat. A DES algoritmus működése nagy vonalakban: - Az első lépésben a kulcstól függetlenül a 64 bites bemenet bitjeit összekeveri - Az iterációs lépések mindegyike két darab 32 bites értékként értelmezi a bementére adott adatot, s ennek megfelelően két darab 32 bites kimenetet ad - Az utolsó előtti lépésben a két 32 bites

részt felcseréli - 14 - - A maradék 16 lépés működése egységes és mindegyik paramétere, a kulcsból származtatott érték, a körkulcs (Ki) A DES napjainkig a kriptográfusok egyik kedvenc témája. Elvi módot ugyan nem sikerült találni a feltöréshez, azonban 1990-ben az Eli Biham és Adi Shamir által bevezetett differenciális kriptoanalízis segítségével a DES feltöréséhez szükséges 255 brute-force műveletigényét 238 művelet körülire csökkentették [2]. Megjelenésekor a DES ereje pont abban rejlett, hogy célhardverrel gyorsan megvalósítható volt. Ma már ez hátránynak tekinthető, hiszen elég, ha 1998-ban Michael Wiener által kifejlesztett Deep Crack DES törő célgépre gondolunk. A mai elérhető technológia segítségével a DES egy 1 millió dolláros célgéppel mintegy 1 óra alatt feltörhető. 1. 4 3 Út az AES-ig: az IDEA és az RC5 Az IDEA egy szimmetrikus kulcsú rejtjelező algoritmus, tehát mind a küldőnek, mint a

címzettnek ismernie kell ugyanazt a titkos kulcsot. Az IDEA 64 bites blokkos eljárás, azonban 128 bites kulcsot használ, melyből 52 darab 16 bites körkulcsot származtat. A feldolgozást 8 iterációban végzi, majd egy kimeneti transzformációval zárja le. Minden lépéshez hat darab, a kimeneti transzformációhoz pedig négy darab kulcs tartozik. Az algoritmus gyors, hardveres környezetben is hatékonyan implementálható. Jelenleg nem ismert olyan módszer, ami az IDEA-t feltörné, így az egyetlen támadási módként a brute-force kínálkozik. A nagy kulcsméretnek köszönhetően azonban még brute-force-szal sem törhető a technika mai szintjén. Az algoritmus mégis lassan háttérbe szorult. Ma már csak egy a sok közül Az RC5 egy olyan blokkorientált algoritmus, amely 16, 32 vagy 64 bites környezetben működik a legjobban. A felépítése egyszerű, hardveres és szoftveres implementációi egyaránt hatékonyak. Nemcsak a blokkméret, hanem a körök

száma és a kulcs hossza is paraméterezhető. Az algoritmus érdekessége, hogy a szokásos rögzített vagy származtatott lépésszám helyett a pillanatnyi adattól függő lépésszámmal hajtja végre a forgatásokat. Gyakorlatilag nem lehet előre megjósolni, hogy mikor hány bittel fog történni a forgatás [2]. - 15 - 1. 4 4 Az AES-pályázat Mintegy két évtizedes múlt után a DES elérte életciklusának végét, mára egyszerűen idejétmúlttá vált. Bár a TripleDES és a 3DES még ma is jó alternatíva, 1996-ban a NIST (National Institute for Standards and Technology) megkezdte egy új algoritmus előkészítését, majd az elvárások deklarálása után útjára indította az AES-projektet (Advanced Encryption Standard). Az AES fejlődése a teljes nyilvánosság előtt zajlott Elvárások az új algoritmussal szemben: ƒ Szimmetrikus kulcsú, blokkos algoritmus, 128 bites blokkmérettel ƒ 128 – 192 – 256 bites kulcsmérettel kell dolgoznia ƒ

Gyorsabb legyen, mint a 3DES és nyújtson annál jobb védelmet ƒ Hatékony megvalósíthatóság (számítási teljesítmény, kód- és memória szükséglet) ƒ Flexibilitás az egyes platformok és későbbi fejlesztések tekintetében A pályázatra 21 nevezés érkezett, amiből 15-öt fogadtak el. A 2000-ben megtartott döntő öt résztvevője közül (MARS, RC6, RIJNDAEL, SERPENT, TWOFISH) Vincent Rijmen egyetemi oktató és Joan Daemen számítógépes szakértő munkája, a Rijndael (réjndáel) lett a győztes, így a DES hivatalos utóda. Az indoklás szerint mind az öt döntős versenyző kiállta a támadásokat és a vizsgálatokat, lényeges különbség nem volt köztük, azonban a Rijndael nyújtotta a biztonság, a teljesítmény, a hatékonyság, illetve a rugalmasság legjobb kombinációját. A Rijndael struktúrája a titkosító és a megoldó oldalon hasonló (de nem azonos); a műveletek pedig jól párhuzamosíthatók. A mai nagy teljesítményű

RISC és CISC processzorokon éppúgy megvalósítható, mint egy 8 bites kártyán. Az algoritmus nem áll szabadalom alatt és ilyen jellegű védelmét nem is tervezik. Jelenlegi ismereteink szerint ellenáll minden ismert támadási módnak, így egyetlen gyakorlati módszer alkalmas csak a feltörésére: a brute-force [2]. 2002 végén Nicolas Curtois és Josef Pieprzyk publikáltak egy cikket, amely igen nagy port kavart és tartalmával jelentősen megosztja a nagy kriptográfusokat is. Az XSL-nek nevezett eljárás lényege, hogy az AES-t egy többezer tagot számláló egyenletrendszerré konvertálja, többezer ismeretlennel. Így az AES-128 feltörésének komplexitása a brute- - 16 - force 2128 eredményével szemben mintegy 2100 műveletigényű (8000 egyenlet és 1600 bináris ismeretlen). Az eljárás fő ereje abban rejlik, hogy a feltörés bonyolultsága nem exponenciálisan arányos a kulcshosszal: vagyis az AES-256 hasonló módon történő megtörésének

nem 2100+128 az erőforrásigénye, hanem jóval kevesebb: körülbelül háromszoros. Szerencsére mindkettő jelentősen túlmutat a gyakorlati lehetőségeken, így a DES gyengeségén is [3]. Az NSA ajánlása az AES-re vonatkozóan: ƒ Az AES-128 ún. titkos besorolást kapott, tehát minősített adatok védelmére nem ajánlják („SECRET level”) ƒ Az AES-256 fokozottan titkosnak minősül („TOP SECRET level”) Nicolas Curtois szerint az AES a differenciális és a lineáris kriptoanalízis szempontjából nagyon erős, viszont az algebrai jellegű támadások tekintetében „nehéz gyengébb titkosítást elképzelni” [3]. Ezért nem is tartja biztonságosnak olyan alkalmazásokhoz, amelyeknél a hosszú távú titkosítás fontos követelmény. Diffie és Landau szerint egy bevált algoritmus körülbelül 20 évig van használatban, míg a kódolt üzeneteknek 10-40 évig biztonságban kell lenniük (ami jó esetben hosszabb a használati időnél). Mindez

annak fényében érdekes, hogy fogalmunk sincs, milyen számítási kapacitás birtokában lehetünk akár 10 év múlva [18]. - 17 - 1. 5 Kulcsok cseréje a szimmetrikus algoritmusokban A titkos kulcsú rejtjelezés nagyon jó módszer, azonban kétségkívül a legfőbb hátránya, hogy a titkos kulcsban a kommunikáló feleknek előre meg kell egyezniük. Ehhez valamilyen kellően biztonságos kommunikációs csatornára van szükség, amely nem hallgatható le. Ez a csatorna azonban valamilyen értelemben biztosan drága vagy nem mindig biztonságos, ellenkező esetben ezen a csatornán lehetne az üzenetet is elküldeni [2]. 1. 5 1 A kommunikációs csatornák jellemzői Fizikailag biztonságos csatornáról beszélünk akkor, ha a támadó csak úgy férhet hozzá a csatornához, ha a fizikai védelmet (kábel) megbontja; ez pedig valamilyen mértékű fizikai rongálást jelent. Szabotázs-védelemmel figyelhető: a csatorna szerepét betöltő kábelt egy gázzal

töltött csőben vezetik, így ha a támadó a csövet megbontja, a nyomásváltozást azonnal észlelni lehet. Ez a megoldás csak kisebb földrajzi távolságokban kivitelezhető, dedikált vonalnak tekinthető és meglehetősen drága. Biztosított a csatorna, ha nincs fizikai védelemmel ellátva, de a felek kommunikációját valamilyen védelmi szintű protokollok segítik (törlés, beszúrás, olvasás ellen). A küldött és fogadott adatokhoz a támadó hozzáférhet, ezeket manipulálhatja. A végberendezések, szoftverek, protokollok feladata a kommunikáció felügyelete. Nem biztonságos egy csatorna abban az esetben, ha a támadó nemcsak csatlakozni tud a csatornához, hanem ott adatokat megváltoztatni, törölni vagy beszúrni is képes. Az ilyen csatornából fizikai védelemmel biztonságos, míg megfelelő protokollokkal, titkosító algoritmusokkal biztosított csatornát lehet létrehozni. A legtöbb kommunikációs közeg ilyen. Abszolút biztonságos,

ún. Shannon-féle csatorna, mely abszolút biztonságot garantálna, nem létezik. Ha létezne egy tökéletes biztonságot nyújtó algoritmus, akkor a támadó – akármennyi nyílt üzenetet fog el, és akármennyi erőforrással rendelkezik is – csak a nyílt szöveg hosszát tudja meghatározni (perfect forward secrecy) [2]. - 18 - 1. 5 2 A szimmetrikus kulcsú algoritmusok hátrányai Az első probléma, hogy a titkosított kommunikációban résztvevő minden párnak meg kell egyezni egy titkos kulcsban: n kommunikáló partner esetén, ha mindenki mindenkivel kommunikálni akar, akkor már n=50 esetén is 1225 kulcs biztonságos menedzselésére van szükség. Sőt, ha figyelembe vesszük, hogy a kulcsokat a minél nagyobb biztonság érdekében gyakran kell cserélni, a helyzet tovább romlik. A második problémát az jelenti, hogy a titkos kulcsú rejtjelezés használatakor élünk azzal a feltételezéssel, hogy a kulcs csak a felek birtokában van, más nem

ismeri azt. Ebből következően a titkos kulccsal megfejthető üzenettel kapcsolatban azt is bizonyítva látjuk, hogy az üzenet kitől érkezett. Ha azonban a fenti 50 résztvevő mindegyike ugyanazt a kulcsot használja, hogyan tudjuk bizonyítani, hogy kitől jött az üzenet? A fenti két probléma jelentős enyhítését teszi lehetővé a nyilvános kulcsú titkosítások megjelenése [2]. 1. 6 Nyilvános kulcsú titkosítási módszerek A nyilvános kulcsú rejtjelezés alapötlete az, hogy a titkosítás folyamatát elválasztja a megfejtéstől, és olyan algoritmust használ, amelyben a titkosító paraméter nem azonos a megfejtéshez használt paraméterrel. 1. 6 1 A Diffie-Hellman kulcscsere Diffie, Hellman és Merkle tett közzé először olyan kriptográfiai eljárást, ami a nyilvános kulcsú elméleten alapult (1976). Megmutatták, hogyan tud két résztvevő a kommunikációhoz szükséges közös titokban megegyezni anélkül, hogy bármit előzetesen

egyeztetniük kellene. A klasszikus, két résztvevős algoritmus menete a következő: A választ két speciális nagy prímszámot, n-t és g-t, melyek tipikusan 192-512 bit hosszúak. Ezután mindketten előállítanak egy-egy hasonló méretű véletlenszámot, amiket titokban tartanak. Legyenek ezek x és y úgy, hogy mindkettő kisebb, mint n-1. Először A elküldi B-nek k1=(gx mod n) és (n,g) -t. B válaszában k2=(gy mod n) -t küld vissza A a kapott válasz alapján kiszámolja k3 = k 2x mod n = (gy mod n)x mod n értékét, B pedig az első üzenet - 19 - alapján k4 = k1y mod n = (gy mod n)y értékét. Mindkét kifejezés (k3 és k4) egyenlő gxy mod n -nel, ami közös, titkos kulcsként használható. Lépések A B Nyilvános paraméterek A választ: B megkapja: g = 13 és n = 37 >> 0. Titkos paraméterek A választ: g = 13 és n = 37 B választ: x = 23 1. Kulcselőkészítés A számol: y = 14 B számol: K1 = gx mod n = 1323 mod 37 = 2 K2 = gy

mod n = 1314 mod 37 = 25 2. Kommunikáció A elküldi az eredményt: B elküldi az eredményt: K1 >> << K2 3. Egyeztetett kulcs A számol: A számol: K2x = (gy)x = gxy = K (mod n) K1y = (gx)y = gxy = K (mod n) 2523 mod 37 = 30 214 mod 37 = 30 1. 4 ábra: Diffie-Hellman kulcscsere két résztvevővel Az algoritmus használatához figyelembe kell venni g és n viszonyát. A g számnak olyannak kell lennie, hogy az n-nél kisebb számok előállíthatók legyenek gx mod n alakban. Hiszen, ha A és B egy n = 11 mellé g = 10 -et választana, mindössze két kulcs generálására lennének képesek. Azokat a számokat, amelyek teljesítik a fenti feltételt, generátornak, vagy n-re nézve primitívnek nevezzük. Azonban annak eldöntése, hogy egy szám generátor-e vagy sem, nem egyszerű és szükséges az n-1 prímtényezős felbontása is. Ha egy esetleges támadó lehallgatta az üzenetváltást, akkor megismerte gx és gy értékeit, valamint a nyilvános n és

g paramétereket. A gx –ből elméletileg ki tudja számolni x-et és B válaszüzenetéből y-t is. Azonban a módszer pontosan azon alapul, hogy a moduláris aritmetikában bizonyos esetekben igen nehéz logaritmust számolni: - 20 - nem ismert olyan használható algoritmus, amely nagy prímszám modulus mellett a kívánt logaritmust gyorsan lenne képes előállítani. Ehhez ugyanis x = log g k1 mod n és y = log g k 2 mod n értékét kellene kiszámítania. A Diffie-Hellman kulcscsere némi általánosítással több résztvevős kommunikáció biztosítására is alkalmas. Három résztvevő esetén (A, B, C) a kulcscsere a következőképpen zajlik. Lépések A B C n és g n és g n és g 0. Titkos paraméterek x y z 1. Kulcselőkészítés gx gy gz Nyilvános paraméterek A elküldi B-nek gx-et, B elküldi C-nek gy-t, majd C küldi A-nak gz-t. gz 2. Kommunikáció után gx gy A kapott csomagokra mindenki alkalmazza a titkos paraméterét. gzx

3. Kulcselőkészítés gxy gyz Az eredményt mindenki továbbküldi, a korábban megismert módon. 4. Kommunikáció után gyz gzx gxy A kapott csomagokra mindenki alkalmazza a titkos paraméterét. 5. Kulcselőkészítés gyzx gzxy gxyz 1. 5 ábra: Diffie-Hellman kulcscsere három résztvevővel A táblázat alapján a módszer lényege, hogy a g szám addig vándorol a kommunikáló felek között, amíg nem alkalmazza rá mindenki a titkos paraméterét. A titkos kulcsú algoritmusok esetében használt „titkot” itt is meg kell beszélniük, azonban biztonságos csatornára nincs szükség, mert a felek nem a teljes titkot, csak egy speciális részét küldözgetik egymásnak. A további kutatások ezt is megoldották: már nincs szükség arra, hogy ugyanaz a kulcs legyen a felek birtokában. Ez az aszimmetrikus rejtjelezés a nyilvános kulcsú titkosítás [2]. - 21 - 1. 6 2 A nyilvános kulcsú titkosítások alapelvei A nyilvános kulcsú rendszerekben

minden résztvevő két kulcsot birtokol: egy nyilvános kulcsot és egy titkos kulcsot. Az üzenetet a titkos kulccsal lehet megfejteni, amennyiben a nyilvános kulccsal kódolták, és fordítva. Ennek tükrében a rejtjelezett üzenetet csak az tudja elolvasni, akinek birtokában van a titkos kulcs – vonatkozik ez a feladóra is, ha visszakapja az eredetileg általa elküldött üzenetet. A nyilvános kulcsú titkosításokat hitelesítésre is használhatjuk, kiaknázva azon tulajdonságukat, hogy a titkosító algoritmus működik a nyilvános kulccsal, illetve a megfejtő algoritmus is működik a titkos kulccsal. A címzett a következőképpen tudja ellenőrizni az üzenet küldőjét: 1. Küldés előtt a feladó a saját titkos kulcsával kódolja az üzenetet Ezzel olyan átalakítást végez az üzeneten, amire senki más nem képes. 2. A következő lépésben az előbbi eredményt titkosítja a címzett nyilvános kulcsával, ezzel elérve, hogy az üzenet ne utazzon

védtelenül. 3. A címzett saját kulcsával és a megfejtő algoritmussal kibontja a csomagot, feloldva ezzel az üzenet védelmét. 4. A kapott eredményt pedig a küldő nyilvános kulcsával alakíthatja olvasható, kódolatlan formára. A fenti folyamat során a feladó biztos lehet abban, hogy az általa elküldött csomagot csak a címzett képes elolvasni, hiszen az mindig védve utazott. A címzett pedig biztos lehet abban, hogy az üzenet valóban a feladótól érkezett, hiszen a feladó titkos kulcsával kódolt üzenetet egyedül a nyilvános kulcs nyitja. Mivel a publikus kulcsokat egyáltalán nem kell védeni, létrehozhatunk egy nyilvános, telefonkönyvhöz hasonló kulcstárat, amely a résztvevők nyilvános kulcsait tartalmazza (n darabot). Így bárki tud üzenetet küldeni a kulcstárban szereplőknek, minden előzetes egyeztetés nélkül. A kulcstárból ugyanezzel a módszerrel juthatunk hozzá a kívánt résztvevő nyilvános kulcsához: a szerver

aláírja saját titkos kulcsával a „kulcsot”, mi pedig a szerver nyilvános kulcsával bizonyosodunk meg az üzenet hitelességéről. - 22 - Ezeket a lekért publikus kulcsokat a helyi gépünkön is tárolhatjuk, egyedül arra kell ügyelnünk, hogy a helyi adatok mindig szinkronban legyenek a szerveren tároltakkal [2]. 1. 6 3 Az RSA algoritmus elméleti háttere A nyilvános kulcsot használó módszerek gyakran a nagy prímszámok szorzásán, s az így létrejövő még nagyobb szám prímtényezőkre bontásának nehézségén alapulnak. Az RSA biztonságát is ez a probléma adja. A kis Fermat-tétel kimondja, hogy ha egy a számot egy p prímhatványra emelünk, akkor az eredmény p-vel való osztás utáni maradékaként visszakapjuk az eredeti a számot. Ez természetesen csak akkor működik, ha p nagyobb, mint a, különben az osztás során a-t is elosztanánk, s más maradékot kapnánk. A fenti tétel általánosabb formáját Euler fogalmazta meg, miszerint:

a Φ (n ) ≡ 1(mod n ) , ha a és n relatív prímek, azaz nincs más osztójuk, csak és kizárólag az 1. Ha az n helyére prímszámot választunk, akkor egyértelműen adódik a Φ(n ) = n − 1 összefüggés, hiszen egy prímszámhoz minden más szám relatív prím. Prímszámot választani azért is előnyös, mivel ilyen esetben minden n-nél kisebb számra működik a tétel. Ahhoz azonban, hogy több felhasználó számára is lehetővé váljon a rendszer használata, n-t két prímszám szorzataként érdemes definiálni (p és q). Így az új modulus n = pq, a kitevő pedig ed = k(p-1)(q-1)+1. Ekkor azt kapjuk, hogy a ed ≡ a mod pq , ahol ed ≡ 1 mod ( p − 1)(q − 1) . Legyen a nyilvános kulcs az (e, n) számpáros, a titkos kulcs pedig a (d, n) páros. Ekkor a támadónak Ф(n) kiszámolásához n prímtényezős felbontására lenne szüksége, azaz pre és q-ra. Mi azonban ezt a két számot úgy választjuk meg, hogy n hatalmas legyen, - 23 - majd

eldobjuk az előállításhoz szükséges számokat. A tudomány mai állása szerint egy ekkora szám prímtényezős felbontása reménytelen feladat [2]. 1. 6 4 Az RSA algoritmus A titkosításhoz az üzenetet először számokká alakítjuk úgy, hogy a számok (blokkok) mindegyike kisebb legyen, mint n. Ezt például úgy tehetjük meg, hogy minden karakter helyére az ASCII kódját írjuk, majd átszámítjuk egy másik számrendszerbe. Az így nyert üzenetdarabokat a képletünkben az a helyére helyettesítjük be, majd az egyes m számokból (üzenetekből) az M = m e mod n képlettel előállítjuk a rejtjelezett M üzenetet, ami az m = M d mod n képlet alapján lehet megfejteni. Az algoritmus elnevezése a tervezők nevének első betűit őrzi: Rivest, Shamir, Adleman. Az RSA algoritmust 1977-ben szabadalmaztatták, azonban ez a védelem 2000-ben lejárt, így bárki liszenszdíj-mentesen készíthet RSA algoritmuson alapuló hardver- vagy szoftvereszközt. A

kulcsgenerálás lépései tehát a következők: 1.) Véletlenszerűen válasszunk két elég nagy, legalább 100 jegyű prímszámot Legyen ez P és Q. 2.) Ekkor N = PQ és Ф(n) = (P-1)(Q-1) 3.) Válasszunk egy véletlen E számot úgy, hogy relatív prím legyen Ф(n)-re 4.) Keressünk egy olyan D-t, amelyre ED = 1 mod Ф(n) teljesül Egy példán keresztül illusztrálva pedig: 1.) Legyen ez P = 17 és Q = 23 2.) Ekkor N = PQ = 391 és Ф(n) = (P-1)(Q-1) = 352 3.) Legyen E = 21 Ekkor (21, 352) = 1 teljesül 4.) Legyen D = 285, mert 285 x 21 mod 352 = 1 - 24 - 5.) Az elküldendő üzenet legyen „T”, amelynek az ASCII kódja 84 Ez kisebb, mint 391, ezért megfelelő. 6.) A titkosított üzenet így: 8421 mod 391 = 135 Ezt kell elküldeni 7.) A fogadó oldalon pedig a 135285 mod 391 = 84 számítással áll elő az eredeti üzenet. A példában használt értékek a gyakorlatban természetesen nem alkalmazhatók, mivel az N számot még fejben is gyorsan prímtényezőkre

lehet bontani. Ezután pedig előállítható Ф(n), majd inverzszámítással D is. Ha azonban két többszáz-jegyű prímszámot választunk, akkor az előálló N prímtényezős felbontása a mai eszközökkel lehetetlen feladat [2]. 1. 6 5 Az RSA algoritmus megfelelő paraméterezése Az RSA a DES-hez hasonló blokkos titkosító algoritmus, a blokkok méretét n határozza meg. Az algoritmusban E és D szerepe felcserélhető, ezért az RSA alkalmas digitális aláírásra is. A gyakorlati alkalmazások során jelenleg a 2048-4096 bites modulosokat tekintjük biztonságosnak. Az RSA kulcsainak hosszát mindig a modulus n hossza határozza meg, hiszen n adja meg a feltörés bonyolultságát. A faktorizáció területén elért újabb eredmények (elliptikus görbe faktorizáció) miatt ajánlott közel azonos méretű prímszámokat felhasználni a kulcsok generálásához: például egy 1024 bites modulust célszerű két 512 bites prím alapján kiszámolni. Azonban vigyázni

kell arra is, hogy a két szám ne kerüljön túl közel egymáshoz [2]. Az RSA algoritmus elleni támadások hatékonyságát sokak szerint növelheti az, ha a kulcs speciális tulajdonságokkal rendelkezik. Ilyen feltétel lehet, hogy a 23 bit a kulcsban „0”, vagy az utolsó 5 bit „1’ értékű legyen. Ezeket a kulcsokat gyenge kulcsoknak is nevezik (weak key). A támadó ekkor viszont egy feltételezésen alapuló megoldással próbálkozik, amely könnyen kudarcba fulladhat. Számos vizsgálat eredményeképpen a prímeknek (P és Q) a következő tulajdonságokkal kell rendelkezniük akkor, ha erősek akarnak lenni (strong key) [4]: 1.) A választott prím (R) nagy, legalább 400-500 bit hosszú 2.) R - 1 legnagyobb prímosztója (R–) nagy 3.) R– - 1 legnagyobb prímosztója (R– –) nagy 4.) R + 1 legnagyobb prímosztója nagy - 25 - A fő érv az erős prímek használatára Pollard faktorizáló algoritmusa volt, ezért az 1970-es évektől jó darabig a

gyenge prímekből előállított RSA kulcsokat gyenge kulcsoknak tekintették, használatukat nem javasolták. 1985-ben azonban Lenstra kidolgozott egy olyan, elliptikus görbén alakuló eljárást, amely erős prímek használata esetén is ugyanolyan hatékony, egyedül a prímszámok közel egyforma hosszúsága okoz neki problémát. Rivest és Silverman mindezt egy 1998-ban publikált közös tanulmányukban foglalták össze [4]. Egyúttal megmutatták, hogy az erős prímek használata felesleges, mert alkalmazásuk véd ugyan bizonyos faktorizálási módszerek és az iteratív támadás ellen, de nem véd azok általánosítása, Lenstra módszere ellen. Használatuk tehát nem baj, de nem is szükséges [2]. 1. 6 6 Az RSA feltörése Az RSA feltöréséhez nem érdemes a brute-force módszerrel nekifogni, mivel már az elavultnak tekinthető 512 bites kulcsméret is kellő védelmet nyújt ellene. Ugyanezt a számot prímtényezőkre bontani azonban lényegesen könnyebb

– de szintén nagyon erőforrás-igényes feladat. Az idők folyamán az egyes új módszerek és egyre gyorsuló számítógépek jelentős haladást tettek lehetővé a faktorizálás terén. Érdekes, hogy a feltört RSA kulcsok hossza és az eltelt évek között nagyjából lineáris kapcsolat van, ami valószínűleg annak köszönhető, hogy a számítási teljesítmény és az egyre nagyobb számok faktorizálásának erőforrás-igénye egyaránt exponenciálisan növekszik [2]. Az RSA Laboratories által meghirdetett RSA Factoring Challenge keretében 2005. május 10-én vált nyilvánossá a legutóbbi, 200 digit hosszú szám sikeres faktorizálása [5]. Íme a versengés tárgya, a 200 digit hosszú RSA kulcs: 2799783391 1221327870 8294676387 2260162107 0446786955 4285375600 0992932612 8400107609 3456710529 5536085606 1822351910 9513657886 3710595448 2006576775 0985805576 1357909873 4950144178 8631789462 9518723786 9221823983 A fenti szám

lényegesen kisebb a legnagyobb ismert prímszámtól, amely 9 152 052 digit hosszú, s a neve Mersenne-prím (M43) [1]. Ebből is látszik, hogy egy számról lényegesen könnyebb eldönteni, hogy prím-e, mint faktorizálni. [5] - 26 - Bruce Schneier az egyik Cryptogram hírlevelében arról ír, hogy az 1024 bites RSA kulcsok egy 1 milliárd dolláros Bernstein-féle architektúrán alapuló célgéppel már néhány perc alatt faktorizálhatók. Ez nem is tűnik olyan horribilis összegnek annak fényében, hogy az USA által rendszeresen fellőtt Sigint műholdak ára a 2 milliárd dollárhoz közelít. Ha Bernstein gépét megépítik, az összes népszerű protokoll, amely ma leginkább 1024 bites RSA kulcsokat használ (HTTPS, SSH, IPsec, PGP), mind kompromittálódik. A legtöbb neves kriptográfus szerint a fentiek miatt érdemes a rendszereinket átállítani a 2048 bites kulcsok használatára, hiszen nem tudhatjuk, hogy az NSA megépíttette-e már a Bernstein-féle

gépet. A digitális szatellit-adásokat nem véletlenül védik már 4096 bites RSA kulcsok Európában [6] 1. 6 7 Hibrid kriptorendszerek A nyilvános kulcsú algoritmusok gyakorlati alkalmazása során nem az egész üzenetet kódolják például az RSA-val, mert nagyon lassú lenne. A hagyományos szimmetrikus kulcsú algoritmusok hardvermegoldásban átlagosan ezerszer gyorsabbak, de szoftveres megoldás esetén is legalább százszor [7]. Ezért az aszimmetrikus titkosítások nem alkalmasak hosszú üzenetek titkosítására. A szokásos eljárás az, hogy az üzenetet egy gyorsabb, titkos kulcsú algoritmussal, az ehhez használt kulcsot pedig nyilvános kulcsú módszerrel titkosítják, és a kettőt együtt küldik el. Ez az egyszer használt kulcs a viszonykulcs (session key). Így dolgozik a PGP is: az RSA segítségével titkosítja a szimmetrikus kulcsot, majd a tömörített üzenet tényleges kódolása az IDEA/CAST algoritmussal történik. A tömörítés nemcsak az

átviteli időt csökkenti, de lényegesen megnehezíti a mintakeresést, növeli az entrópiát és elrejti a nyílt szöveg jellemző tulajdonságait. A fenti borítékolásnak (enveloping) is nevezett módszernek azonban van egy igen nagy hátránya: a nyilvános kulcs hosszából származó előny, ami eddig a brute-force alkalmazását megakadályozta, elveszik. A támadó egyszerűen úgy kezeli a titkosított üzenetet, mintha az egész szimmetrikus kulcsú algoritmussal lenne kódolva, hiszen itt most a nyilvános kulcsú algoritmus csak a kulcscserét segíti [2]. - 27 - Mindezek fényében a hibrid kriptorendszerek biztonságát az alkalmazott szimmetrikus kulcsú algoritmus, és az aszimmetrikus kulcsú algoritmus együttesen határozzák meg. 1. 6 8 Az RSA algoritmus implementációját befolyásoló tényezők Az RSA algoritmus alapját a hatalmas prímszámok adják, így nyilvánvaló a szükséglet ilyen prímek előállítására vonatkozóan. Azonban

jelenleg nem áll rendelkezésünkre olyan módszer, amely közvetlen módon lehetne meghatározni egy prímszámot, ezért az egyetlen esélyünk, hogy véletlenszerűen generálunk egy nagy számot, majd megnézzük, hogy prím-e. Ha viszont egy tetszőleges számról kell eldöntenünk, hogy prím-e, akkor egyetlen teljes biztonságos jelentő módszer adódik: végig kell néznünk az 1 és a szám négyzetgyöke közötti egész számok mindegyikét, hogy nem-e osztója a számunknak. Ezt a sorozatos osztást természetesen nem tudjuk elvégezni, még az erasztothenészi szita segítségével sem, hiszen pontosan ennek megakadályozása a célja a hatalmas prímek alkalmazásának. Az egyetlen megoldásként a prímteszt algoritmusok kínálkoznak, amelyek tetszőleges biztonságú becslést képesek szolgáltatni arra vonatkozóan, hogy a vizsgált szám prím-e. Ilyen teszt a Fermat-teszt és a Solovay-Strassen-teszt, de jelenleg a legbiztosabb a Miller-Rabin-teszt. Ha ezen a

teszten a vizsgált szám százszor átmegy, akkor a szám már kellően összetett, ha nem is biztosan prím [2]. Bármelyik tesztet választjuk is, mindenképpen hatalmas számokon kell aritmetikai műveleteket elvégeznünk, ami természetesen a jelenleg elterjedt 32 bites, általános célú processzorokkal nem oldható meg adattípus-szinten. Így, ha ezen algoritmusok megvalósítására adjuk a fejünket, kénytelenek vagyunk egy ALU-t (Arithmetical Logical Unit) készíteni az általunk alkalmazott programozási nyelven, amely egy karaktersorozatot számként értelmezve blokkosan képes a műveletek elvégzésére. Olyan ez, mint az általános iskolai matematika: a nagy számok összeadásához kisebb számokra kell bontanunk azokat, helyértékenként összeadnunk, majd a maradékot (átvitelt) kezelnünk. Bemutató jelleggel egy programot készítettem, amely a fent definiált ALU-ból az összeadást megvalósítja. A program forráskódja és futtatható változata a CD

mellékleten található. - 28 - 1. 6 ábra: hatalmas, karaktersorozatként kezelt számok összeadása 1. 6 9 Az RSA algoritmus megvalósítása Java nyelven A korábban említett megvalósítási kérdésekkel kapcsolatban fontos megemlíteni, hogy a legtöbb esetben, amikor az RSA algoritmus gyakorlati alkalmazására kerül sor, nem ajánlott saját implementációra törekedni. Ennek a legfőbb oka az, hogy nem szabványos megoldások segítségével – az algoritmus publikus volta ellenére – könnyen a látszatbiztonság hitébe kerülhetünk. A legtöbb esetben nincs is szükség saját megvalósításra, hiszen a ma elterjedt mindegyike vagy eredendően támogatja az RSA algoritmust és az ahhoz szükséges egyéb programozási eszközöket, vagy külön komponensként beszerezhető hozzájuk. A Java nyelv is ilyen: támogatja az RSA algoritmus megvalósítását, szabványos függvénykönyvtárán keresztül, ami bárki számára hozzáférhető. A korábban

említett nagy számok előállításához és kezeléséhez a BigInteger típusra van szükségünk, amely a háttérben egy fix méretű integer értékekből álló tömb. Ez minden, a megvalósításhoz szükséges aritmetikai műveletre képes kellő hosszúságú számokra. A java.mathBigInteger könyvtár tartalmazza a Miller-Rabin prímteszt algoritmust is; a metódus neve isProbablePrime, amit vélt prímszámra meghívva, és paraméterül adva, hogy hány körben vizsgálja a szám prím mivoltát, tetszőleges valószínűséggel (amennyi „időnk” van a vizsgálatra) hozhatunk döntést. Általánosan elmondható, hogy 100 körben vizsgálva a számot, már kellően nagy valószínűséggel állíthatjuk (1 / 2100), hogy prímszámot találtunk, s a művelet sem tart sokáig. Moduló-inverzet is számolhatunk, a modInverse kiterjesztett Euklideszi-algoritmus segítségével. metódusban implementált - 29 - 1. 7 ábra: RSA implementáció Java-ban Ahhoz

azonban, hogy mindezeknek hasznát vegyük, valamilyen módon nagy prímszámokat kell előállítanunk. Titkosítási célokra nem alkalmasak a programozási nyelvekbe beépített, hagyományos módon működő Random függvények, mivel túlságosan determinisztikusak (pl. az órajel állásából keletkezik a pszeudovéletlen érték). A valódi véletlenszerűség általánosan használt forrása a felhasználói adatbevitel – például az egyes billentyűleütések között eltelt idő, vagy az egér mozgatásának módja, illetve ezek kombinációja. Egy elterjedt megoldás, hogy a billentyűleütések közötti időablakot mikrosecundumban lemérve, majd az értéket bitsorozattá alakítva, s a bitsorozat LSB-jét véve (Least Significant Bit, Legkisebb Helyértékű Bit) áll elő egy véletlen érték. Ezek a megoldások kellően véletlenszerűek, még kriptográfiai célokra is Manapság egyre több operációs rendszer kernelje tartalmazza ezt a funkciót, ami azért is

különösen előnyös, mivel így sokkal több idő kínálkozik egy „entrópia készlet” előállítására, mint amennyi egy egyszerű folyamatnak rendelkezésére áll [8]. A fentieknek megfelelő, biztonságos véletlen értékek előállítására képes a java.securitySecureRandom könyvtár - 30 - A megvalósításhoz elő kell állítani a titkos- és a nyilvános kulcsot és a modulót, illetve elkészíteni az elküldendő vagy a visszafejtendő üzenetet bájtokká alakító, majd azokat kódolni, dekódolni képes metódusokat. Már egy ilyen kezdetleges bemutatóprogramon keresztül is jól érzékeltethető, hogy mennyivel hosszabb lehet a kódolt üzenet a nyilvánosnál. Ez főleg akkor igaz, ha az előírtnak megfelelő hosszú (2048 bites) modulót alkalmazunk. Ha a lehető leghatékonyabb aritmetikára van szükségünk, akkor érdemes a GNU LGPL szabad liszensz alá tartozó GMP függvénykönyvtárat alkalmazni, amely napjainkban az egyik legmegfelelőbb

eszközt jelenti. - 31 - 2. Az SSH, MINT INTEGRÁLT TITKOSÍTÁSI MEGOLDÁS 2. 1 Az SSH áttekintése Az SSH (Secure Shell, Biztonságos Héj) egy olyan segédprogram, amit számos módon szoktak definiálni aszerint, hogy konkrétan mely funkcióját tekintik kiemelkedően fontosnak. Mondhatnánk, hogy protokoll, titkosító eszköz, hogy ügyfél-kiszolgáló alkalmazás, illetve, hogy parancsfelület. Ez nem is véletlen, hiszen az SSH egy olyan összetett, rugalmas programcsomag, ami szinte bármilyen hálózati biztonsággal kapcsolatos problémára megoldást kínál; ezért is előnyös az integrált titkosítási megoldás, mint definíció elfogadása [10]. 2. 1 1 Bevezetés Az SSH tulajdonképpen egy olyan alkalmazás, ami két fél között zajló kommunikációt tesz biztonságossá, a kliens-szerver modellnek megfelelően. Az SSH kliensek futnak a Windows minden változatán, illetve a UNIX, Linux vagy Macintosh munkaállomások számos verzióján is. A szerverek

vonatkozásában pedig a fentiek mellett a Sun Solaris is támogatott. A speciális felhasználást az jelenti, amikor a különböző Cisco hálózati eszközök (Router, Switch, Access Point) közötti kommunikációt, illetve a távmenedzselést oldják meg a biztonságos héj segítségével. Neve ellenére az SSH nem parancsértelmező héj, hanem az egyedek között titkosítást biztosító eszköz. Az SSH-ban használt titkosítási módszerek és algoritmusok pedig olyan ipari szabványokon alapulnak, mint a 3DES vagy az AES [10]. 2. 1 2 Az SSH különböző változatai Az SSH első változata az SSH 1 volt, amely számos területen korlátozott képességekkel bírt, illetve titkosítási megoldásai sem voltak kellően biztonságosak. Mindez az SSH 1 átdolgozásához vezetett – így jelent meg az SSH 2. Az SSH 2-t nem az SSH 1 kódjának alapján, hanem elölről kezdve írták meg, így a korábbi változatnál biztonságosabb, nagyobb teljesítményű és rugalmasabb is

lett. Az SSH 1-et a fentiek miatt már nem fejlesztik, így a szakdolgozat további részében az SSH alatt SSH 2-t értem. - 32 - Az SSH sokféleképpen használható, a hálózati környezettől és az üzleti követelményektől függően. A program által nyújtott rugalmasság jelentős előnyt jelent más, hasonló segédprogramokkal szemben, akár biztonsági célú protokollokról van szó (IPSEC), akár nem biztonsági célúakról (FTP). Az SSH-t egyszerre több felhasználó is használhatja, méghozzá egyetlen folyamaton (démon) vagy szolgáltatáson belül, ami a szerveren fut, a beállítások nagy részét mégis a klienseken adhatjuk meg. 2. 2 Az SSH funkciói Az SSH képességeit, funkcióit érdemes a felhasználásuk szerint kategóriákba rendezni, és ezeknek megfelelően tárgyalni 2. 2 1 Biztonság Az SSH alkalmazása bármely IPv4-et alkalmazó hálózatban megbízható védelmet nyújt. Azért különösen fontos ez, mert az IPv4-nek számos

biztonsági hiányossága van, mint például a TCP fejléccsomagok kezdő sorozatszámainak (Initial Sequence Numbers, ISN) munkamenet-eltérítésre lehetőséget adó hiányossága, vagy a hálózaton terjesztett, hitelesítetlen ARP (Address Resolution Packet) címfeloldó csomagok [10]. Az SSH nem csak a fenti, LAN-ok elleni támadások ellen véd, hanem az alábbi támadástípusoktól is: ƒ Az IP cím álcázása: egy távoli eszköz (általában az operációs rendszer) megváltoztatja saját IP címét, és úgy tesz, mintha egy másik, megbízható forrás lenne. ƒ Adatmódosítás: ahogy adatok haladnak át a hálózaton, az átvitel közben egy harmadik fél módosíthatja az adatokat. ƒ ARP szennyezés: helytelen ARP csomagok terjesztése annak érdekében, hogy a megszerzendő adatokat máshová lehessen irányítani. ƒ Munkamenet-eltérítés: egy harmadik fél kiszámolja, vagy kitalálja a TCP fejlécben lévő ISN-t, s így jut ellenőrzéshez a Telnet és

az RSH munkamenetek felett. ƒ Támadás szöveges adatokkal: egy harmadik fél lehallgathatja kommunikációs csatornát, jelszavakat vagy parancsokat fogva el ezzel. a - 33 - Az SSH népszerűségének legfőbb oka, hogy képes megakadályozni a kémkedést mind a helyi hálózatokon, mind a nagy kiterjedésű hálózatokon (Internet). A legtöbb egyszerű protokoll, mint amilyen a Telnet is, egyszerű szöveg formájában továbbítják az adatokat. Ez azért jelent problémát, mert a jelszavakhoz hasonló kényes információk elfogását leggyakrabban a következő, közönséges és sérülékeny kapcsolatokon keresztül kísérlik meg: FTP, POP3, SMTP, HTTP [10]. Az SSH az összes, fent említett protokoll biztosítására képes, a következő kulcsfontosságú biztonsági szolgáltatásokat nyújtva: ƒ Titkosítás: a teljes kommunikáció titkosítása, különféle (választható) rejtjelező algoritmusok segítségével. ƒ Kéttényezős hitelesítés:

a hitelesítéshez megkövetelhető a felhasználónév és jelszó vagy egy nyilvános kulcs megadása. A kettő együtt is használható, ekkor beszélünk kéttényezős hitelesítésről (mint a PGP esetében is). ƒ Adatépség (konzisztencia) biztosítása: Az adatokhoz fűzött ellenőrző összeg (CRC, Hash) segítségével az adatok harmadik fél általi módosítása észlelhető. 2. 2 2 Távoli parancsvégrehajtás Az SSH lehetővé teszi, hogy egy távoli operációs rendszeren (PC vagy Hálózati eszköz), a biztonságos kapcsolaton keresztül parancsokat hajtsunk végre. A UNIX esetében ez azt jelenti, hogy az SSH a távoli felhasználó számára biztosítja az /etc könyvtár passwd állományában megadott shell-t. Az SSH tehát nem igényli saját felhasználók létrehozását, mivel az operációs rendszer – ez esetben a UNIX passwd fájlbeli – felhasználóit használja. Windows esetében is hasonló a helyzet, de mivel ott nem választhatunk shell-t,

minden SSH felhasználó egy parancssori ablakot (Windows 2000 és XP esetén „cmd”) vagy annak valamilyen formáját kapja. A UNIX-hoz hasonlóan a Windows rendszerekben is az operációs rendszer tárolt jelszavait (SAM vagy ntds.dit fájlok) használja az SSH. 2. 2 3 Távoli fájlátvitel UNIX-on a távoli fájlátvitelnek két formája létezik. Az SSH 1 és az SSH 2 különböző változatai az SCP-t (Secure Copy Protocol), míg az SSH 2 főleg az SFTP-t (Secure File - 34 - Transfer Protocol) kínálja fel. Windowson csak az SFTP használható Mindkettő hasonló szolgáltatásokat nyújt, céljuk pedig azonos: fájlok biztonságos cseréje egy távoli géppel. Erre a legtöbb SSH ügyfél beépítve tartalmaz valamilyen fájlátviteli segédprogramot, de külön alkalmazást is használhatunk, mint amilyen a PuTTY és a WinSCP. Bár az SFTP-t alapvetően az FTP lecserélésére találták ki, mégis sok esetben a Windows SMB-jét (Server Message Block) és a UNIX NFS-ét

(Network File Server) is helyettesítik vele. Az SFTP így nemcsak biztonságosabbá teszi a fenti alkalmazásokat, hanem teljesen megszünteti az SMB-től és az NFS-től való függést [10]. Igaz ugyan, hogy a fájlátvitel az FTP-hez képest lassabb, a nyújtott biztonsághoz képest ez azonban csekély mértékű. 2. 2 4 Távoli hálózati hozzáférés Nem csupán a szó szokványos értelmében vett VPN szolgáltatást (Virtual Private Network, Virtuális Magánhálózat) biztosítja, hanem olyan szolgáltatásokat is, amelyek számos VPN-felhasználó számára fontosak lehetnek. Például elektronikus levelezést, fájlátvitelt, illetve belső hálózati, intranetes szolgáltatásokat vagy bármi mást, ami kapuátirányítással biztonságossá tehető. 2. 2 5 Biztonságos felügyelet Számos mai hálózat rossz felügyeleti gyakorlatot folytat, mivel az egyébként biztonságosan konfigurált számítógépek és operációs rendszerek gyenge felügyeleti protokollokat

használnak, mint amilyen a Telnet és az SNMP is. Más felügyeleti programok pedig, mint amilyen a pcAnywhere vagy a VNC, az érzékeny adatokat nem elég erős titkosítással továbbítják. Sőt, az alkalmazások ügyfél-változatát bárki letöltheti magának, s megkísérelhet illetéktelenül csatlakozni az ügynökprogramhoz például egy elfogott jelszó segítségével. Ennek feltétele csak annyi, hogy ne legyen külön felügyelő hálózat, ami megakadályozná, hogy csatlakozhasson az ügynökhöz. Az ilyen elszigetelt hálózatok biztonságos felügyeletére is kiválóan alkalmas az SSH. Nemcsak a távoli parancssor biztonságos kezelésére képes megoldást nyújtani, hanem a különböző grafikus felhasználói felületek (Graphical User Interface, GUI) kezelésére is. - 35 - Emellett az SSH minden felügyeleti hozzáférésnél kéttényezős hitelesítést igényel, nyilvános kulcsot és jelszót kérve. Végül, az SSH kiküszöbölheti egy önálló

felügyelő hálózat szükségességét, így jelentős összegeket takaríthat meg, illetve egyszerűsítheti az eszközök és a rendszerek kezelését [10]. 2. 2 6 Proxy szolgáltatások Az SSH a közvetítő (proxy) szolgáltatások biztonságossá tételére is használható – ez egyike a legkevésbé ismert lehetőségeinek. Az SSH közvetítők képesek együttműködni az olyan hagyományos közvetítő szolgáltatásokkal, mint a SOCKS; ilyenkor a SOCKS kiszolgálót az SSH-n keresztül kell beállítani az adott környezethez és csatornaforgalomhoz, így olyan távoli alkalmazások, mint például az Oracle SQL*PLUS ügyfélprogramja, biztonságos kapcsolaton keresztül érhetők el. 2. 2 7 Az SSH ügyfél-kiszolgáló felépítése Az SSH megvalósítása kliens-szerver rendszerű: egy SSH kiszolgálóhoz több SSH ügyfél is csatlakozhat. A megszokott sémának megfelelően az SSH szerver egy démon vagy szolgáltatást futtat, ami egy meghatározott portot

(tipikusan a 22-est) figyel. Az SSH TCP kapcsolat használata esetén bármelyik kaput figyelheti. A különböző beállítási lehetőségeket – jelszavas vagy nyilvános kulcsú hitelesítés, kapubeállítások, kezdőkönyvtárak – egy beállítófájlban adhatjuk meg. Az SSH ügyfeleknek csak a kiszolgáló IP címét kell tudniuk, illetve a figyelt port számát. A bejelentkezés után csak az ügyfél hitelesítésére van szükség, hogy hozzáférhessen a munkamenethez (session) – akár SSH-ról, akár SFTP-ről van szó. 2. 2 8 Az SSH titkosító rendszere Az SSH képes együttműködni a ma alkalmazott főbb titkosító algoritmusokkal, amelyek közé az alábbiak tartoznak: DES, 3DES, Blowfish, Twofish, AES (128, 192, és 256 bites), CAST, RC4, Arc Four. A titkosító módszerek mellett az SSH MAC (Message Authentication Code, Üzenethitelesítő kód) kivonatokat is felkínál, melyek közül a legtöbb SSH-változatban elérhető az MD5 és az SHA 1 is. Ezek az

átvitt adatokról egyedi kriptográfiai aláírást készítenek, - 36 - amely segítségével a fogadó fél meggyőződhet arról, hogy az adatokat nem módosította „út közben” senki. 2. 2 9 Az SSH biztonsági hézagai Mivel az SSH is hagyományos, emberek által készített szoftver, ezért ne gondoljuk, hogy a rengeteg előnyével szemben nem lehetnek benne hiányosságok, hibák. Fontos tudatosítani, hogy az SSH-t is érdemes rendszeresen – tesztelés után – javítófoltokkal ellátni, felülvizsgálva ezzel az SSH szolgáltatásokat. Különösen fontos ez azért is, mert az informatika világában igen gyorsan kiderülhet egy algoritmusról, hogy egy új, vagy rég elfeledett módszerrel villámgyorsan törhető – ezért nem árt, ha tájékozottak maradunk az alapvető biztonsági kérdésekben az SSH-val kapcsolatban (is). 2. 2 10 Az SSH ügyfelek és kiszolgálók fajtái SSH ügyfeleket és kiszolgálókat rengeteg vállalat fejleszt. Elérhetők

hagyományos, különálló, telepítendő változatok is, mint amilyen az OpenSSH, de találunk – többnyire fizetős – megoldásokat is, amelyek közvetlenül egyedi szoftvereinkbe integrálhatunk egy komponens segítségével. SSH kiszolgálók ƒ OpenSSH (www.opensshcom) - Windowsra és UNIX-ra egyaránt ingyenesen elérhető, nagy tudású programcsomag - Létezik egyszerűen telepíthető változata is, amit a népszerű CYGWIN segédprogram segítségével ültettek át Windowsra. ƒ SSH2 (www.sshcom) - Az SSH kereskedelmi változata, amelynek üzleti célú használatáért fizetni kell. ƒ Windowsra és UNIX-ra is elérhető Vandyke Software (www.vandykecom) - Csak kereskedelmi SSH-változatot készít, aminek használatáért minden esetben fizetni kell. - 37 - - Kiszolgálójuk (VShell) és ügyfelük (SecureCRT) Windowsra és UNIXra egyaránt elérhető. SSH ügyfelek ƒ OpenSSH ƒ PuTTY ƒ SecureCRT ƒ WinSCP Szoftverbe integrálható SSH

komponensek ƒ SecureBlackBox (http://www.eldoscom/sbb/) o NET C#, Borland Delphi 4-2006, Borland C++ Builder 4-6 és Kylix 2-3 alá is elérhető ƒ BitVise SSH2 Library (www.bitvisecom) o Csak C++ alá érhető el 2. 3 OpenSSH, a nagyszerű ingyenes megoldás A következő fejezetek leginkább az OpenSSH Windows alapú változataira vonatkoznak, de a UNIX-os beállítások, vagy a használatra vonatkozó útmutatások nem térnek el lényegesen a különböző operációs rendszereken (Linux, Unix, Windows). 2. 3 1 Az OpenSSH projekt Az OpenSSH egy szabadon felhasználható szoftver, amely támogatja az SSH protokollt (1.3, 15 és 20), az SFTP-t és az SCP-t is, továbbá kliens és szerveroldali programmal egyaránt rendelkezik. Az OpenSSH-t elsősorban az OpenBSD csapat fejleszti, ezért is volt a BSD 2.6 az első olyan operációs rendszer, amely tartalmazta a programot. A szoftvert az USA-n kívül fejlesztik, kódja nagyjából tíz ország programozóitól származik – s

természetesen szabadon felhasználható és átírható a BSD liszensz értelmében. Az egyik csapat tisztán BSD alapokra fejleszt, s egyszerű, minél biztonságosabb kód létrehozására törekszik. Ezután veszi a másik csapat az elkészült kódot, majd portolhatóvá teszi, amely ezáltal számos más operációs rendszeren is futtathatóvá válik. - 38 - Ezek a verzió az úgynevezett p kiadások, amelyek verziószáma például így néz ki: „OpenSSH 4.2 p1” Az első OpenSSH verzió az SSH 1.212-re épült, amelyből számos hiba el lett távolítva, s új szolgáltatások lettek hozzáadva. A forráskódból minden korlátozó részt, pl. a szabadalmak miatt más, külső forrásokkal (pl OpenSSL) kellett helyettesíteni, hogy a szoftver teljesen ingyenes és nyílt forráskódú lehessen. Az első, SSH 1 és SSH 2 protokollokat egyaránt támogató verziót Markus Friedl készítette el 2000. júniusában, ami először az OpenBSD 27-es kiadásában jelent meg

[11]. 2. 3 2 Az OpenSSH szolgáltatásai Nyílt forráskód és szabad felhasználhatóság: a forráskód bárki számára elérhető az Interneten keresztül, ami a kód újrafelhasználására, biztonsági vizsgálatára buzdít. A hibák fellelésének és kijavításának ez egy fontos feltétele. Erős titkosítás: a projekt fejlesztői nem tartották indokoltnak szabadalom által védett titkosítási algoritmusok alkalmazását, hiszen a nyílt változatok is legalább olyan biztonságosak. A legfontosabbak a 3DES, a Blowfish, az AES és az Arcfour – ez utóbbi egy olyan gyors folyamtitkosító, ami elvileg kompatibilis az RC4-gyel. X11 továbbítás: titkosíthatjuk az X-Window forgalmat is. A program automatikusan beállítja a display-t a kiszolgáló gépen, és minden X11 kapcsolatot biztonságos csatornán továbbít. Port-továbbítás: egy távoli géppel létesített TCP/IP kapcsolat kódolt csatornára továbbítható. A hagyományos alkalmazásokat, mint amilyen a

POP is, így lehet biztonságossá tenni. Erős hitelesítés: megakadályozza az IP cím hamisítását (spoofing), a hamis irányítást (routing) és a DNS hamisítást. Használható módszerek: rhosts és RSA alapú host authentikáció együtt, tisztán RSA hitelesítés, egyszer használható jelszó és session kulcs együtt, végül pedig Kerberos-t használó hitelesítés. Ügynök-továbbítás: a felhasználó gépén lévő hitelesítő ügynök tárolja az RSA vagy DSA hitelesítő kulcsokat. Az OpenSSH automatikusan ennek az ügynöknek továbbítja a kapcsolatot, így az csak ellenőrzi a kulcsokat, azokat sohasem adja ki. - 39 - Kompatibilitás: Az OpenSSH 2.0 támogatja az 13, 15 és 20 protokollokat, az RSA algoritmus használata pedig elkerülhető, mivel a 2.0 protokoll még a szabadalom lejárta előtt született. A szabadon használható Diffie-Hellman és DSA algoritmusokat használja. SFTP támogatás az SSH1 és SSH2 protokollokban: az OpenSSH a 2.50

verzió óta tartalmaz teljes SFTP támogatást, beleértve a kliens és a szerver oldalt is. Kerberos és AFS jegy átadás: az OpenSSH átadja a jegyeket (ticket) a Kerberos-nak és az AFS-nek a távoli gépen, így a felhasználó minden szolgáltatását a jelszó újrabegépelése nélkül érheti el. Adattömörítés: a titkosítás előtti adattömörítés megnöveli az átviteli sebességet, és növeli az entrópiát [11]. 2. 3 3 Az OpenSSH telepítése Windows rendszerre Az OpenSSH-t Windowsra a népszerű CYGWIN segédprogram segítésével portolták, így egyszerűen, telepítőprogram segítségével installálhatjuk rendszerünkre. A példában egy VMWare Workstation-ön futó Windows XP rendszerre kerül fel az OpenSSH 35p1-3 változata, ami szerverként fog funkcionálni. 2. 1 ábra: Az OpenSSH Windows-ra portolt verziójának telepítése Ha a telepítés befejeződött, kézzel szerkesztenünk kell az OpenSSH beállító-fájljait, amire a telepítő is felhívja

a figyelmünket. Először azonban létre kell hoznunk egy - 40 - felhasználót a Windows-ban, hiszen az OpenSSH nem rendelkezik saját felhasználókkal – az operációs rendszer szolgáltatásaira támaszkodik. Ehhez a Vezérlőpult/Felhasználói Fiókok menüben érdemes létrehozni egy új felhasználót. A példában ez a ’user’ felhasználó lesz, korlátozott jogosultságokkal Ezután az OpenSSH telepítési mappájának bin könyvtárában található parancsfájlok segítségével létre kell hozni egy új felhasználói csoportot, az mkgroup -l >> .etcgroup paranccsal, majd engedélyeznünk kell a ’user’ felhasználó számára az SSH használatát, az mkpasswd -l -u username >> .etcpasswd paranccsal. Ha minden rendben van, a program nem válaszol semmit, csak egy sortörést jelenít meg. Ezután el kell indítani az OpenSSH démont a net start opensshd utasítással. Az eredményt ellenőrizhetjük is: a netstat –an utasítás

eredményeképpen látható, hogy az alapértelmezett 22-es portot figyeli az SSH démon. A helyes működés ellenőrzésére fogjunk egy SSH-ügyfelet a 2.210-es fejezetben ismertetett programok közül, és kíséreljünk meg csatlakozni a gazdagépről a virtuális gépen futó SSH szerverhez. A példában a PuTTY szerepel Ha csatlakozunk a szerverhez, a PuTTY egyből felhívja figyelmünket arra, hogy az RSA-ujjlenyomat még ismeretlen, ezért legyünk óvatosak. Esetünkben ez természetes, hiszen most először csatlakozunk az SSH szerverhez. Ha bejelentkezünk a rendszerbe a korábban beállított azonosító segítségével, máris hozzáférünk a szervergép parancssorához. Egyelőre azonban hagyjuk a szerverünket, mivel a biztonságos működés érdekében pontosan be kell állítanunk a használni kívánt funkciókat, s letiltani a szükségtelen lehetőségeket, ezzel is csökkentve a támadások okozta potenciális kockázatot. - 41 - 2. 2 ábra:

Bejelentkezés az OpenSSH szerverre a PuTTY segítségével 2. 3 ábra: Sikeres bejelentkezés az OpenSSH szerverre - 42 - 2. 3 4 Az OpenSSH szerver biztonságos beállítása Az SSH biztonságos beállítására vonatkozó ajánlások minden operációs rendszerre egyaránt vonatkoznak, hiszen maguk az SSH konfigurációs fájlok szinte ugyanazt tartalmazzák. Az első szerkesztendő fájl a telepítési mappa etc könyvtárában található, neve sshd config. A fájlban található egyes sorok által reprezentált beállítások akkor vannak érvényben, ha nincs előttük # jel. Elsőként az alapvető hálózati beállításokra, a kulcskezelésre és a naplózásra vonatkozó beállításokat vizsgáljuk meg: Port 22 Az SSH-szerver által figyelt port száma. Alapértelmezetten 22. Protocol 2 A támogatott SSH protokoll száma. Biztonsági okokból érdemes csak az SSH 2-es protokollt engedélyezni. Az SSH-1-gyel való kompatibilitás esetünkben nem fontos.

ListenAddress 0.000 Az SSH által figyelt IP-cím. Ha minden felületen engedélyezni szeretnénk a szolgáltatásokat, állítsunk be 0.000-t Ha viszont van olyan cím, amit nem szeretnénk figyeltetni, kézzel kell megadnunk a figyelendő címeket. KeyRegenerationInterval 3600 Először meghatározzuk (másodpercben), ServerKeyBits 2048 azt aminek az időtartamot letelte után újragenerálódik a szerver kulcsa, majd definiáljuk a kulcs hosszát. A esetünkben a kereskedelmi adatok védelmére is megfelelőnek tartott 2048 bites lett. - 43 - LogLevel INFO Beállítjuk a naplózás szintjét, ami INFO esetén csak a tájékoztató jellegű üzeneteket rögzíti, FascistLogging esetén viszont mindent részletesen naplóz. Ezután következnek a hitelesítéssel kapcsolatos beállítások: LoginGraceTime 120 A felhasználó számára a hitelesítés folyamat befejezésére rendelkezésre álló idő. # PermitRootLogin yes A rendszergazda belépésének

engedélyezése. Alapértelmezetten ez engedélyezve van, de jobb ha letiltjuk, ha képesek vagyunk az egyes felhasználók feladatköreit pontosan definiálni. RSAAuthentication yes Az RSA-alapú hitelesítés engedélyezése. Alapértelmezetten tiltva van, de a fokozott biztonság érdekében érdemes bekapcsolni [10]. 2. 3 5 A PuTTY kliens biztonságos beállítása A PuTTY egy SSH és Telnet ügyfélprogram Windows rendszerekhez. Ingyenesen letölthető, beállításai egyszerűen érthetőek, s még telepíteni sem kell. A Connection pont SSH alpontjában adhatjuk meg az SSH-ra vonatkozó beállításokat. Konkrétan: • Remote Command: A kapcsolat létrehozása után automatikusan végrehajtandó parancsok a kiszolgálón. • Enable Compression: Engedélyezi a továbbított adatfolyam tömörítését. Ajánlott. - 44 - • Preferred SSH protocol version: Az előnyben részesített SSH protokoll. Érdemes csak az SSH2-t engedélyezni. • Encryption options: A

használt adatfolyam-titkosító algoritmus neve. Ajánlott az AES. 2. 4 ábra: A PuTTY SSH Beállításai 2. 3 6 Kapuátirányítás (tunneling) az SSH segítségével Az SSH egyik leghasznosabb és leghatékonyabb szolgáltatása a kapuátirányítás: az SSH ügyfél képes egy SSH szerverhez kapcsolódni, majd más kapuk forgalmát a felépült kapcsolaton keresztül továbbítani. Ennek lényege, hogy a különböző programok által használt, titkosítatlan TCP csomagokat az alkalmazások számára transzparens módon, titkosítva továbbíthatjuk. Így az egyébként nem biztonságos protokollok (IMAP, POP3, FTP, NFS, Telnet) észrevétlenül tehetők biztonságossá. A kapuátirányítás beüzemeléséhez a kiszolgáló beállításait általában egyáltalán nem szükséges módosítani, mindössze engedélyezni kell ezt a funkciót. A legtöbb SSH környezetben – így az OpenSSH esetén is – alapértelmezetten be van kapcsolva, A kapuátirányításnak két fajtája

van: a helyi és a távoli. - 45 - Helyi kapuátirányításról beszélünk akkor, amikor a használni kívánt kliensprogramunkkal a helyi gép egy portjára csatlakozunk, kérésünk pedig egy SSH csatornán keresztül kerül a szerverhez. A működés menete egyszerűbben megvilágítható egy példán keresztül. Tekintsünk egy kliens-szerver alkalmazást, ami egyszerű HTTP protokollt használ, továbbá egy SSH-ügyfélt és egy SSH-kiszolgálót, amelyek a biztonságos kapcsolat fenntartásáért felelnek. A feladatot a kliens szemszögéből vizsgáljuk, így a kliens címe 127.001; a szerver pedig a 192.128239129 címmel rendelkezik, s a 2400-as kaput figyeli Az SSH-szerver ugyanazon a gépen van, amin a szerver, s a 22-es portot figyeli. A működés menete tehát: 1. Létrehozunk egy biztonságos csatornát a kliensen található SSH-ügyfél (pl 2419-es port) és a szerveren található SSH-szerver között. 2. A klienssel csatlakozunk a helyi gép

egy tetszőleges portjához Példánkban: 127.001:2419 3. Az átirányítás következtében kérésünk az SSH-szerverhez kerül, a 22-es portra. Ez a kérés kerül a távoli gép 2400-as portjára, amit a szerver figyel 4. A kapcsolat innentől ugyanúgy folyik tovább, mintha hagyományos HTTP protokollt használnánk. A kliens-szerver modell csak a kapcsolat létrejöttéig szükséges; ezután a kliens és a szerver is tehet adatot a csatornára. A távoli kapuátirányítás pontosan a helyi ellentéte. Ekkor a távoli kiszolgálóról érkező forgalmat továbbítjuk az SSH-ügyfél egy helyi kapujához. A távoli átirányításra jó példa egy FTP-kiszolgálórendszer biztosítása: 1. Telepítsünk egy SSH-kiszolgálót, ami a 22-es portot figyeli, illetve egy SSH ügyfelet az FTP-kiszolgálóra. 2. Állítsuk be a távoli kapuátirányítást az FTP-kiszolgáló SSH-ügyfelénél Ekkor az SSH-kiszolgáló 21-es portjára érkező kérések az FTP-kiszolgáló 21-es

portjához lesznek továbbítva. 3. A biztonságos FTP-eléréshez így az SSH-kiszolgáló 21-es portjára kell csatlakozni. - 46 - 2. 3 7 Esettanulmány: Webszerver biztosítása az OpenSSH segítségével Példánkban a 2. 3 3 pontban telepített virtuális gépen futó OpenSSH szervert fogjuk igénybe venni. Erre a gépre fog kerülni egy komplett webkiszolgáló-megoldás, az AppServ 2.45 változata (Apache 13, PHP 441, MySQL 50) Az Apache webszerver a 80-as porton várja a kéréseket. A kapcsolat biztonságossá tétele tehát: 1. Telepítsük fel az AppServ-et a virtuális gépre, majd állítsuk a 80-as kapura (192.168239129:80) 2. A virtuális gépen található OpenSSH szerveren a kapuátirányítás alapértelmezetten engedélyezve van, így azzal nem kell foglalkoznunk. 3. A gazda operációs rendszerre telepítsünk egy OpenSSH klienst, majd irányítsuk át a gazdagép 2400-as portjára érkező forgalmat a virtuális gép SSH-szerverére (22-es port). SSH

192.168239129 –l user –p 22 –L 2400:192168239129:80 4. Ha az átirányítás sikeres volt, kedvenc böngészőnkbe beírva a http://localhost:2400/ címet, elérjük a virtuális gép webszerverét, immáron biztonságos kapcsolaton keresztül. 2. 5 ábra A háttérben látható a virtuális gépből elért szerver; az előtérben pedig a gazdagépről történő biztonságos elérés a 2400-as porton keresztül - 47 - Ez természetesen azt jelenti, hogy adott esetben csak azok a felhasználók nézhetik meg a weboldalt, akik rendelkeznek valamilyen SSH klienssel. Ez ma még jelentős bonyodalmat jelenthet az egyszerű felhasználó számára, hiszen a legelterjedtebb operációs rendszerben, a Windowsban gyárilag semmilyen SSH kliens nincsen (a UNIX-ban és a Linux-ban van, bár ezek parancssori ügyfelek). A jövőben azonban változhat a helyzet, hiszen az igény növekedésével megjelenhetnek akár SSH-képes böngészők is, amelyek néhány kattintással

létrehozhatnak egy SSH-csatornát, maximalizálva ezzel az internetező biztonságát. Azért lenne ez különösen előnyös, mert számos támadásnak lehetne elejét venni vele (MITM, titkosítatlan jelszavak). 2. 3 8 Biztonságos fájlátvitel SSH-val A fájlátviteli protokollokat (SMB, NFS) gyakran használják különböző hálózati környezetekben a fájlok kiszolgálók közötti megosztására. A Windows például erősen támaszkodik a NetBIOS-ra, ami helyi hálózaton nem jelent (akkora) biztonsági problémát, távoli elérés esetén azonban az idegen hálózatok jelenléte jelentős kockázatot jelent. Annak ellenére, hogy az SMB-t nem célszerű az Interneten keresztül használni, a távoli felhasználóknak hozzá kell férniük a vállalat kiszolgálóihoz, köztük a Windows rendszerekhez is. A fájlok távoli elérését is biztosíthatjuk az SSH segítségével. Az SSH azzal enyhíti a sebezhető fájlátviteli protokollok használatából eredő

problémákat, hogy a nem biztonságos adatforgalmat titkosított csatornára tereli. Ezzel nemcsak jelentősen mérsékeljük a csomagok elfogásásában rejlő kockázatot, hanem a kéttényezős hitelesítéssel megnövelhetjük a fájlátvitel általános biztonságát. Ehhez az SSH-kiszolgálón nincs szükség további beállításokra, a kapuátirányítás alapértelmezetten engedélyezve van. A tűzfalon természetesen át kell engednünk a megfelelő portok forgalmát. Az SSH-ügyfelen viszont a 2. 3 6 pontban ismertetett módon létre kell hoznunk egy csatornát azzal a különbséggel, hogy itt az SMB-hez a 445-ös portot kell használnunk. SSH 192.168239129 –l user –p 22 –L 2400:192168239129:80 - 48 - A szemléltetés kedvéért osszunk meg egy könyvtárat a Windows XP szerveren, s adjunk olvasási jogokat a user felhasználó részére. Ezután fogjunk egy Linuxot (a példában SuSe Linux 10.0 szerepel, szintén a VMware Workstation-ön fut), hozzunk létre

egy SSH csatornát a fent említett módon, majd az smbclient SMB ügyféllel lépjünk be a korábban megosztott könyvtárba, és töltsünk le egy fájlt. smbclient \\127.001\c -U user -p 445 Domain=[XP] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager] smb: AppServ> get startup.jar getting file AppServstartup.jar of size 32567 as startupjar smb: AppServ> cd smb: > quit 2.6 ábra: Távoli elérés és fájlmegosztás Windows XP és SuSe Linux 10 között, SSHval titkosítva - 49 - 2. 3 9 Az SSH további lehetőségei A 2. 3 fejezetben ismertetett képességeken kívül az SSH-nak számos más felhasználása is létezik, mint például - a hálózati eszköz felügyelet (például Cisco hozzáférési pontokban, tűzfalakban) - a virtuális magánhálózatok biztosítása (PPP SSH felett) - a protokollhelyettesítés (Terminálelérés, SFTP). Ezekre azonban a szakdolgozat szűk keretei, illetve más orientációja miatt nem térek ki. 2. 4 Szoftverbe

integrálható SSH megvalósítások A korábban megismert SSH-felhasználások közös tulajdonsága az volt, hogy az SSH-t külön, a kliens-szerver architektúrának megfelelően kellett a kommunikációban résztvevő számítógépekre telepíteni. Láthatóvá is vált az a hátránya ennek a megoldásnak, hogy a szakértelemmel nem rendelkező felhasználók nem képesek boldogulni az SSH-val, ha azt kézzel kell beállítaniuk, ha pedig a rendszergazdára bízzák a beállítások elvégzését (új SSH csatorna), akkor bizonyára hónapokat kell várniuk. Erre a problémára kínálnak megoldást a szoftverbe integrálható SSH megvalósítások, amelyek a felhasználó számára transzparens módon képesek kezelni saját SSH csatornájukat, a kezdeti alapbeállítások elvégzése után. Képzeljük csak el, milyen jó lenne, ha a 2.37 pontban ismertetett módon csatlakozhatnánk minden webkiszolgálóhoz, például egy böngészőbe integrált SSH kliens

segítségével, szinte észrevétlenül. Ennek egyetlen akadálya van, mégpedig az, hogy jelenleg nincs elérhető, függvénykönyvtár-szerű, ingyenes (GPL) SSH megvalósítás, amit például a Firefox böngésző következő főverziójába be lehetne építeni. 2. 4 1 A SecureBlackbox komponencsalád A SecureBlackbox egy olyan komponenscsalád, ami a legtöbb ma gyakori hálózati biztonsági problémára megoldást kínál az elterjedt protokollok segítségével; s mindezt szoftverbe integrálva. A SecureBlackbox kétféle változatban kapható: a Standard - 50 - tartalmazza az összes alapcsomagot, míg a Professional változat ehhez képest a jelszóvédett PDF dokumentumok előállításának, és az XML szabványú fájlok titkosításának lehetőségével nyújt többet. A Standard változat részei: ƒ PKIBlackbox: az X.509 tanúsítványok kezelését valósítja meg. Ezt használják az SSL, az IPSec és a Secure Mail (S/MIME) hitelesítésére és

titkosítására ƒ SSHBlackbox: az SSH protokoll megvalósítását tartalmazza, beleértve a kliens és a szerver oldalt is. Kompatibilis a népszerű SSHmegvalósításokkal, mint az SSH Communications, az F-Secure és az OpenSSH. A szerveroldali komponensek csak VCL és .NET változatban érhetők el ƒ PGPBlackbox: PGP-kompatibilis kulcskezelést, aláírást és hitelesítést kínál. Megfelel az OpenPGP Message Format (RFC 2440) formátumnak. ƒ FTPSBlackbox: SSL/TLS felett futó FTP protokollt valósít meg. ƒ SSLBlackbox: a weboldalakkal kiépített kapcsolat titkosítására használt SSL/TLS protokoll integrált változata. Az FTPSBlackbox komponens része, de külön is elérhető. ƒ MIMEBlackbox: komplett megoldás a MIME (Multipurpose Internet Mail Extensions) e-mailes csatolmánykezelésre. ƒ HTTPSBlackbox: HTTP protokoll SSL felett. A PKI-modul is helyett kapott ebben a komponensben, így hitelességvizsgálattal véd a MITM támadások ellen. A

SecureBlackbox összes fent említett komponense külön-külön is elérhető, változó áron. Az ár kétféle konstrukcióban van meghatározva Vagy fejlesztőnként fizetünk (500 dollár környékén a Standard változat), vagy cégenként (2000 dollár környékén a Standard változat). A család VCL, NET és ActiveX alá egyaránt elérhető (Delphi, C++, Kylix, stb.) [12] - 51 - 2. 4 2 A Bitvise függvénykönyvtár A Bitvise ssh2lib egy függvénykönyvtár, ami a Crypto++ titkosítási csomagon alapul. Támogatja az SSH protokoll összes népszerű funkcióját. A készítők szerint kódja rendkívül hatékony, még a legnagyobb erőforrás igényű feladatoknak is képes maradéktalanul megfelelni. A könyvtárat akkor használhatjuk, ha nem a cég által készített WinSSHD és Tunnelier alkalmazásoknak akarunk konkurenciát teremteni vele. Éves díja piacra kerülő alkalmazásokban történő használat esetén 3000 dollár, és 1000 dollár, ha csak belső

használatra szánt szoftverekbe építjük be. Jellemzői: ƒ Szokásos SSH-képességek: SFTP, Tunneling ƒ Kulcscsere: Diffie-Hellman, akár Kerberos 5-tel is ƒ Kiszolgáló oldali kulcsok típusa: ssh-rsa (bármekkora méretben), ssh-dss (1024 bites) ƒ Kliensoldali hitelesítés: jelszóalapú, nyilvános kulcsú (RSA, DSA), NTLM, stb. ƒ Titkosító algoritmusok: AES-256, Twofish, Blowfish, TripleDES ƒ Hash-algoritmusok: SHA-1, MD5 ƒ Tömörítés: zlib ƒ Kompatibilitás: SSH Communications, F-Secure SSH ƒ Megvalósítás: C++ A készítők szerint a függvénykönyvtár magja rendkívül hordozható, így elméletben bármilyen operációs rendszeren alkalmazható, ami a hagyományos BSD-socketekre épül. Elmondásuk szerint a könyvtárat már HP NonStop GUARDIAN platformra is sikerült portolni, minimális módosításokkal [13]. - 52 - 3. A KLIENS-SZERVER ARCHITEKTÚRA MEGVALÓSÍTÁSI KÉRDÉSEI BIZTONSÁGOS CSATORNÁN KERESZTÜL 3. 1 A

Kliens-szerver architektúra működése A hagyományos TCP/IP protokollon alapuló hálózatkezelés során a kommunikáció megkezdéséhez, vagyis a kommunikáló felek meghatározásához két adatra van szükség: az IP-címre és a portra (socket, foglalat). A socket egy kétoldalú hálózati kapcsolat egyik végpontja. A kliens-szerver architektúrájú programok esetén csak kétoldalú hálózati kapcsolatról beszélhetünk, hiszen hiába kapcsolódunk több számítógéphez egyszerre, a portok szempontjából mindig párokat lát az operációs rendszer és az általunk fejlesztett program is. Ha tehát minden szükséges adat a birtokunkban van a kapcsolat létrehozásához, már csak egy szerverre és egy kliensre van szükségünk az adatátvitel megkezdéséhez. A szerver és a kliens szerepe csak addig meghatározott, amíg a kapcsolat fel nem épül, utána viszont egyenrangú feleknek is tekinthetjük őket. A kapcsolódás menete a következő: • Telepítünk

egy szervert egy adott, szabadon lévő portra. A program ezt a portot fogja figyelni, innen várja majd a beérkező kéréseket. • Amint egy klienssel rácsatlakozunk a távoli gép szerver által figyelt portjára, ideális esetben a kapcsolat létrejön. Innentől a szerver és a kliens egyaránt tehet adatot a csatornára, és le is veheti onnan, amit számára a másik rátett. • A kapcsolatot bármelyik fél tetszőleges pillanatban bonthatja, ideális esetben egy munkamenet lezárultával [16]. 3. 2 Megvalósítási kérdések A szerveroldali programozást tekintve ideális megoldás a többszálú működés megvalósítása, hiszen az egyes kliensek általában kevés műveletet kérnek a szervertől, idejük többségét a felhasználó aktivitására történő várakozással töltik. Nem is lenne logikus, hogy a távoli szerver egyetlen kliens billentyűleütésére várjon. Többszálú - 53 - megvalósítás esetén minden kliens kaphat egy szálat, így

amíg nem igényel műveletvégzést, várakozó állapotba helyezhető, nem foglalva ezzel feleslegesen a processzoridőt. A gyakorlatban ez úgy történik, hogy készítünk egy vezérlő szálat, ami az egyes kiszolgáló-szálak menedzselését végezni fogja. Ezen belül minden egyes kapcsolathoz létrehozunk egy szálat, amelyek referenciáit például egy láncolt listában tároljuk. A vezérlő szál folyamatosan fut, ez észleli a kliensek kapcsolódását a figyelt portra. A kapcsolat megszűnésével az adott szál léte értelmetlenné válik, fel lehet szabadítani. A gyakorlatban azonban egy meghatározott ideig megtartják a nem használt szálakat, hiszen olyan rendszerekben, ahol sok rövid élettartamú kapcsolat van (webszerver), ez hasznos lehet. Az újonnan érkező kapcsolódási igényhez csak inicializálni kell egy korábban használt szálat; az ehhez szükség idő lényegesen kisebb, mint amennyi egy új szál létrehozásához szükséges. 3. 3 Az Indy

Project A fent ismertetett megvalósítási kérdésekkel nem kell foglalkoznunk akkor, ha egy már kiforrott, széles körben elérhető komponenscsaládot alkalmazunk. Az Indy nyílt forráskódú, s számos platformon képes megoldást kínálni a hálózatkezeléssel kapcsolatos feladatokra: támogatja klienseket, a szervereket, s a TCP, UDP, SMTP, POP3 és HTTP protokollok mellett még több mint 100 magas szintű protokollt is. Az Indy elérhető C#, C++, Delphi, NET és Kylix platformra egyaránt Az esettanulmányként készített programhoz is az Indy családot alkalmaztam egyszerű kezelhetősége, kiforrott működése miatt. Az Indy jelenleg a 10 főverziónál tart, s például a Borland Delphi fejlesztőeszközben évek óta fontos szerepet kap [20]. 3. 4 Biztonsági kérdések szoftverbe integrált megoldással Ha kliens-szerver architektúrájú alkalmazásainkat biztonságossá szeretnénk tenni (natív módon), számos megvalósítási kérdésre kell figyelemmel

lennünk. A legfontosabb, hogy az adott esetben nyílt hálózaton keresztül forgalmazott adataink védve legyenek a különböző támadási módoktól, mint amilyen a MITM vagy a csomaglehallgatás. Egyértelmű, hogy adatainkat valamilyen korábban említett módszerrel (aszimmetrikus - 54 - vagy szimmetrikus) titkosítanunk kell. Erre szolgálhatnak a bemutatott algoritmusok: az AES, a 3DES és az RSA. A sebesség és a titkosság legjobb összhangját viszont akkor érhetjük el, ha a két fő típust kombináljuk, amint a hibrid-kriptorendszerek fejezetben (1.67) olvasható Ha titkosított módon kommunikálunk, még nem jelenti azt, hogy a felhasználók (kliensek) hitelesítése mellőzhető. Hiszen munkamenet-eltérítéssel könnyen beékelődhet egy támadó a kliens és a szerver közé. Ennek megoldási lehetőségeire szakdolgozatom Hitelesítési Technikákkal foglalkozó részében térek ki részletesen. Ha a biztonság szoftverbe integrált útját

választjuk, számos kérdésre figyelnünk kell, még ha komponens alapon valósítjuk is meg az egyes biztonsági intézkedéseket (jelszavak hashelése, titkosítás, tömörítés, programkód-védelem). 3. 5 Nem biztonságos kliens-szerver programok biztosítása Ha valamilyen oknál fogva nem választhatjuk a biztonság szoftverbe integrálásának útját, akkor utólagos biztosításra van szükség, különben a program csak nagy kockázatok árán használható. Akkor merülhet fel ilyen eset, ha a fejlesztésre szánt erőforrások nem teszik lehetővé a nagyfokú biztonság szoftverbeli megvalósítását vagy, ha egy korábban nagy költséggel elkészített szoftverben alkalmazott biztonsági megoldás mára kompromittálódott, s átírása rendkívül nagy ráfordítást igényelne (gondolok itt arra, hogy néhány bankban fellelhető még Fortranban írt szoftver). A fent említett problémákra jelent megoldást a korábban bemutatott SSH, amely egy csatornával

képes biztonságossá tenni az egyébként nem biztonságos alkalmazásokat, számukra teljesen észrevétlenül. Ez a megoldás arra az időre is alkalmazható, amíg a kompromittálódott programot továbbfejlesztik, kijavítják. 3. 6 Esettanulmány: kliens-szerver alkalmazás fejlesztése Az általam elkészített program a fent említett okokból az Indy alkalmazáscsomagra épül, amelynek 9-es verziója a fejlesztéshez használt Borland Delphi 7-es verziójában is helyet kapott. A megoldáshoz az IdTCPClient és az IdTCPServer komponenseket alkalmaztam. A Szerver komponens implicit módon tartalmazza a 32 pontban ismertetett többszálú megvalósítást, így az adott kapcsolathoz tartozó szálra a - 55 - programozónak már nem kell explicit módon hivatkoznia, azt egy tömb segítségével érheti el. 3. 6 1 Szerveroldali alkalmazás fejlesztése: MP3 Szerver Az első feladat az volt, hogy a szerveroldali alkalmazás nem hálózatfüggő részeit elkészítsem.

Mivel a választott téma az MP3 volt, elsőként egy listát kellett készíteni azokról a fájlokról, amelyeket meg kívánunk osztani a kliensekkel. Egy OpenDialog segítségével egy láncolt listába kerülő fájlok alapján töltöttem ki a fájlok elérési útját és nevét, az MP3-mak bitrátáját, a fájlméretet és az utolsó módosítás dátumát. Az MP3fájlokból kiolvasható információkhoz feldolgoztam az MP3 szabványt, beleértve a mintavételezést, a típusokat (layer), a bitrátát, a headert és a különböző flag-ek jelentését (copyright, emphasize, stb.) [17] Ezek a programban mind értelmezve vannak, azonban a listában csak a bitrátát jelenítettem meg, a tömörség kedvéért. Ha a listát létrehozzuk, egy típusos fájl is készül a háttérben, amely majd alkalmas lesz arra, hogy a kliensekhez kerüljön, így nem kell minden kapcsolat során frissíteni a fájllistát. Ezután nincs is más dolgunk, mint szólni a szervernek, hogy kezdje

figyelni a beállított portot (ez az 1700-as lett). Az üzenetkezelésre és kommunikációra egy egyszerű protokollt dolgoztam ki. Amint egy kliens rácsatlakozik a figyelt portra, egy üzenetet ír a naplóba a szerver (Connected). Minden üzenet előtt szögletes zárójelben szerepel az adott kliens azonosítója. Ha a kliens lekéri a fájllistát, akkor a szerver eseménykezelője a (GETLIST) kérésre reagálva továbbítja azt, majd a naplóba a FileList Sent Successfully üzenetet írja. A kliens ekkor letöltheti a neki tetsző fájlokat (GETFILE;elérési út), amiről a szerver a 102 File Sent Successfully üzenettel tájékoztat annyiszor, ahány fájl átvitele megtörtént. Sikertelen átvitel vagy fájllista-lekérés esetén a hibaüzenet értelemszerű. Dolga végeztével a kliens bontja a kapcsolatot, a szerver pedig felszabadítja a kezelésére létrehozott szálat. Az egyszerű kezelhetőség kedvéért a szerveralkalmazás ikonját hozzáadtam a Windows

tálcaikonjai közé a Shell NotifyIcon(dwMessage, lpData) Windows API függvény segítségével. A függvény első paramétere egy üzenet, amely meghatározza, - 56 - hogy mit teszünk az ikonnal, a második pedig egy, az ikon adatstruktúrájára vonatkozó mutató (pointer). Az ikonhoz regisztráltam még egy PopUpMenu komponenst is, a WndProc(var Msg: TMessage) eljárás felülírásával, így lehetővé vált a szerveralkalmazás minimalizálása a tálcára, működés közben. 3. 1 ábra: az MP3 Szerver program működés közben 3. 6 2 Kliensoldali alkalmazás fejlesztése: MP3 Kliens A második feladat, hogy a kliens egyrészt képes legyen felcsatlakozni a szerverhez, másrészt pedig le tudja onnan tölteni a fájllistát. Ehhez a beállítások menü alatt meg kell adni a távol szerver IP-címét és portját, az alapértelmezett letöltési könyvtárat és a hatékony letöltés érdekében az alkalmazandó pufferméretet (32K, 64K, 128K). 3. 2 ábra:

A kliens beállítása - 57 - A kliens beállítása után csatlakozunk a szerverre, majd lekérjük a fájllistát. Ha minden rendben zajlott (de ha nem, akkor is), a vonatkozó üzenet a naplóba kerül, amit később el is menthetünk. A kiválasztott fájlok a letöltési listába kerülnek, amelyet egy gombnyomással végrehajthatunk: a fájlok úgy tűnnek el a listából, ahogy az adatátvitel sikeresen megtörtént. 3. 3 ábra: Fájllista végrehajtása a klienssel A szerver ikonja a tálcán látható 3. 6 3 Nem biztonságos program biztosítása SSH csatornával A kapcsolat biztonságossá tétele a 2.37 pontban ismertetett módon zajlik: 5. Telepítsük fel a szervert a távoli gépre, majd állítsuk az 1700-as kapura (Pl 192.168239129:1700) 6. A távoli gépen található OpenSSH szerveren a kapuátirányítás alapértelmezetten engedélyezve van, így azzal nem kell foglalkoznunk. - 58 - 7. A kliens számítógépre telepítsünk egy OpenSSH klienst, majd

irányítsuk át az 1700-as portjára érkező forgalmat a távoli gép SSH-szerverére (22-es port). SSH 192.168239129 –l user –p 22 –L 1700:192168239129:1700 8. Ha az átirányítás sikeres volt, a kliens-szerver programunk immáron biztonságos kapcsolaton keresztül kommunikál, számára teljesen észrevétlenül, ha a localhost:1700-ra csatlakozunk a klienssel. 3. 6 4 Távoli alkalmazás-menedzsment biztonságos kapcsolaton keresztül Ahhoz, hogy alkalmazásainkat biztonságos kapcsolaton keresztül menedzselhessük távolról, szükségünk lesz egy megfelelő alkalmazásra, amellyel a távoli gépen futó operációs rendszer felett átvehetjük a vezérlést. Ez történhet a Windows Távoli Asztali Kapcsolatával, azonban a VNC sokkal inkább ajánlott erre a célra, mivel sokrétűbb tudással rendelkezik. Ekkor a szokásos SSH-csatornát a VNC-szerver és VNC-kliens között létesítjük, megoldva ezzel alkalmazásunk távmenedzselését, szintén a

szoftverkörnyezet számára észrevétlen módon. - 59 - 4. HITELESÍTÉSI TECHNIKÁK, ADATVÉDELEM AZ INTERNETEN 4. 1 Hitelesítés Az 1. 6 fejezetben bemutatott nyilvános kulcsú algoritmusok (DH kulcscsere) akkor segítenek, ha egy szimmetrikus kulcsú titkosításhoz kell egyeztetni a kulcsot. Ha csak nyilvános kulcsú módszert használunk, ilyen probléma természetesen nem merül fel. Ha azonban több résztvevős kommunikációt folytatunk, a kulcsokat egy központi adatbázisban kell tárolnunk, mint egy telefonkönyvet. Az adatbázist a kulcsszerveren tárolják, ahonnan letölthető a címzett nyilvános kulcsa, aminek segítségével előzetes egyeztetés nélkül küldhetünk üzenetet a kulcs birtokosának. A legelterjedtebb megvalósítás itt a kliens-szerver architektúrára épül, de semmit sem csökkent a módszer értékéből az, ha a címzett maga küldi el nyilvános kulcsát [2]. 4. 1 1 A hitelesítés értelmezése A kulcsszerver, amikor elküldi

nekünk a kért nyilvános kulcsot, saját titkos kulcsával aláírja azt, így biztosak lehetünk abban, hogy a kapott kulcs azonos a szerveren tárolttal. Ez azonban még nem jelent védelmet az ellen, hogy már a szerveren is tárolódhat rossz pár: például a címzett neve mellett egy támadó kulcsa szerepel. A szerver aláírása ilyenkor csak a hamis biztonság látszatát kelti. A fentiekből következően a kulcsok hitelessége a nyilvános kulcsú rendszerek legsebezhetőbb pontja. Erre jelentenek megoldást a kulcshitelesítő szervek (Certification Authory, CA), amelyek ellenőrzik és igazolják a nyilvános kulcs tulajdonoshoz tartozását – az ezt bizonyító igazolást nevezzük hitelességi bizonyítványnak (certificate). Az ellenőrzés első lépése az lehet, hogy a hitelesítést kérő aláírja saját nyilvános kulcsát a titkos kulcsával, elismerve ezzel, hogy a nyilvános kulcs az övé, s bizonyítva, hogy a titkos kulcs pedig a

birtokában van (self-signed key). Ebben a hierarchikus fában (root of certification tree) kell lennie egy olyan, általánosan elismert szervezetnek, akinek kulcsát nem írta alá senki, hitelessége csak közvetett módon értelmezhető. A másik megoldás a hitelesítés problémakörére a bizalmi háló elve, ahol a szereplők mellérendeltségi viszonyban vannak egymással: ha egy olyan személy által aláírt - 60 - kulcsot kapunk, akiben megbízunk, megbízhatunk az általa aláírt kulcsban is. Szabályozhatjuk, hogy milyen mélységben fogadunk el hitelességi igazolást, de azt is, hogy hány „partner” ajánlása kelljen ahhoz, hogy egy új kulcsot valóban hitelesnek fogadjunk el. Ha van egy olyan személy vagy szervezet, akinek az aláírását egy adott körben mindenki hitelesnek tekint, akkor ez a személy bárki számára hitelesíthet kulcsokat vagy dokumentumokat. Ez a személy lesz az elektronikus közjegyző (public e-notary) Az általa hitelesített

dokumentumokat a polgári életben, az államigazgatásban és a jogrendszerben is használhatjuk. Megbízhatósága elismert [2] 4. 1 2 A hitelesség érvényessége A kulcsok kezelésének másik problémája az érvényesség. Minden kulcskezelő rendszer lehetővé teszi, hogy valaki érvénytelenné nyilvánítsa saját kulcsait, ha azokat például ellopták tőle. Ez természetesen a hitelességi bizonyítványok visszavonását (revoking of certification) eredményezi, érvénytelenné téve az e kulccsal aláírt bizonyítványokat is. Ha ezt nem tesszük meg, egyértelműen támogatjuk az okirat-hamisítást. Az érvénytelen kulcsot nem szabad törölni a nyilvántartásból, hiszen az érvénytelenítés előtt keletkezett dokumentumok ellenőrzésekor szükség van rá. Az ilyen kulcsokat egy érvénytelenségi listán kell tárolni, ahol mindenki ellenőrizheti, hogy kulcsa érvényes-e. Hasonló lista tartalmazhatja a visszavont hitelességi bizonyítványokat is

(Certificate Revocation List, CRL). Egy érvénytelen bizonyítvány azonban nem jelenti egyértelműen azt, hogy a hozzátartozó kulcs kompromittálódott; lehet, hogy csak határozott időre szólt és lejárt. A titkos kulcsok tárolása ugyanolyan fontos, mint a szimmetrikus rendszerekben, sőt a digitális aláírások jogkövetkezményei miatt még fontosabb. Ha elkerülhetetlen, a titkos kulcsokat tároljuk valamilyen védett USB-kulcson, s ha mégis ideiglenesen gépünkre kerülne, diszkünk adatterületét használat után teljesen „nullázzuk ki” (pl. a PGP wipe megoldása). Az igazi védelmet az intelligens kulcstároló eszközök jelentik, hiszen ezek „életük árán” is megvédik a bennük tárolt kulcsot. - 61 - 4. 1 3 Hitelesítés a gyakorlatban: az SSL A nyilvános kulcsú algoritmusok megfelelő módon megvalósítva alkalmasak olyan hálózati kapcsolatok titkosítására is, amelyek eredetileg nem képesek titkos forgalom lebonyolítására. Egy

(helyi) Ethernet-hálózaton az általunk generált forgalmat sokan olvashatják. Például egy arra alkalmas hálózati kártyát kevert módba (promiscuous mode) állítva a hálózat teljes forgalmát lehallgathatjuk. Az Interneten ezek természetesen nem feltétlenül igazak. Ennek egyik oka, hogy az Internet különféle fizikai felépítésű hálózatokat kapcsol össze, de a helyi hálózat fizikai forgalma általában a helyi hálózaton belül marad. Ha a fenti hálózati környezetek egyikében szeretnénk titkosítva kommunikálni, akkor a feleknek meg kell egyezniük egy közös algoritmusban. A kérdés az, hogy a titkosítás hova épüljön be? Ha alkalmazáshoz vagy szolgáltatáshoz kötjük a titkosítást, akkor minden jelentkező problémát szoftverszinten kell megoldani, a hálózati forgalomtól függően. Ha a titkosítást hálózati protokollokhoz kötjük, akkor megoldásunk alkalmazásfüggetlen lesz, így olyan szoftvereket is biztosíthatunk, amelyek

nincsenek (eléggé) felkészítve a biztonságos kommunikációra. Az alkalmazásoknak emiatt nem is kell mindig tudniuk, hogy biztonságos csatornán beszélgetnek egymással. Ez utóbbi megoldást választották az SSL tervezői is. Az SSL (Secure Socket Layer, vagy újabb nevén TLS – Transport Layer Security) napjaink igen elterjedt, titkosított kommunikációt biztosító protokollja, amely nyílt hálózatokban, kapcsolatorientált kommunikációban nyújt védelmet. Eltérően az olyan protokolloktól, mint az IPSec, amely az egész hálózatot teszi biztonságossá, az SSL csak egy-egy kommunikációs csatornát biztosít. Az SSL az alkalmazásréteg alá és a szállítási réteg fölé kerül, maga is egy protokollréteget alkot. Kliens- és szerveroldalon egyaránt szükség van támogatásra; így, ha ez biztosítva van, az e felett futó alkalmazások szempontjából az SSL-réteg átlátszó. Az SSL legelterjedtebb alkalmazását a HTTP-protokoll egy kiterjesztése

jelenti, a https://, amely biztonságos kommunikációt tesz lehetővé a szerver és kliensei között. Az SSL minden egyes kapcsolatot egyedi kulccsal titkosít, függetlenül attól, hogy több - 62 - kommunikációs csatorna is végződhet ugyanannál a kliensnél. Sőt, a kliens Æ szerver, szerver Æ kliens irányokat is más-más kulccsal titkosítja. Az SSL szinte minden lehetőségét kihasználja a nyilvános kulcsú technológiáknak: ƒ Minden munkafolyamat (session) titkosításához külön véletlen kulcsot használ. A véletlen kulcsot a szerver titkos kulcsával titkosítva küldi el a klienshez, a tényleges kommunikáció megkezdése előtt. ƒ A tanúsítvány igazolja a szervert (X.509) A tanúsítványban lévő nyilvános kulccsal a kliens kibonthatja a viszonykulcsot, ha a tanúsítványt rendben lévőnek találja. A kliens tanúsítványának alkalmazása nem kötelező, de a szerver előírhatja. ƒ Azzal a szimmetrikus algoritmussal titkosítja a

kliens és a szerver közötti adatforgalmat, melyben a felek megegyeztek. Ez a DES, 3DES, TripleDES, RC2, RC4, IDEA, AES algoritmusok egyike lehet. ƒ Biztosítja az adatintegritást (MD5, SHA-1), melyet kulcsolt MD függvényekkel ér el (MAC) [2]. 4. 2 Digitális aláírások és hitelességi bizonyítványok A nyilvános kulcsú algoritmusok által használt két kulcs nemcsak a kulcscsere problémakörének megoldását jelenti, hanem megteremti a digitális aláírás feltételeit. A jó digitális aláírás a hagyományos aláírás minden jó tulajdonságát hordozza, de ki is egészíti azt. Az elektronikus aláírás feladata, hogy tanúsítsa az aláíró személyazonosságát és azt, hogy az üzenetet nem változtatták meg az aláírás időpontja óta. 4. 2 1 A digitális aláírás értelmezése A megfelelő értelmezés érdekében vegyük sorra az aláírással szembeni követelményeket, és hasonlítsuk össze, hogy mit nyújt e tekintetben a

hagyományos (H)- és a digitális (D) aláírás. a.) Az aláírás nem helyezhető el más dokumentumon, észrevétlenül nem vihető át ƒ H: Az aláírást el lehet lopni (lemásolni, begyakorolni). Az aláírásnak nincs kapcsolata az aláírt dokumentum tartalmával, mindig ugyanolyan. - 63 - ƒ D: Az aláírás függ a dokumentum tartalmától (logikailag). b.) Az aláírt dokumentum tartalma nem változtatható meg észrevétlenül ƒ H: A dokumentum megváltoztatható az aláírás után is. ƒ D: A dokumentum megváltozását az aláírás ellenőrzése kimutatja. c.) Az aláírás bizonyítja, hogy a dokumentum az aláírás tulajdonosától származik ƒ H: A jó hamis aláírást szinte semmi sem különbözteti meg a valóditól. ƒ D: Ha titkos kulcsunkat megőrizzük, senki sem tud a nevünkben aláírni. Aláírásunk nem hamisítható és letagadhatatlan d.) Az aláíró nem tagadhatja le az aláírását ƒ H: Az aláírásunk letagadhatjuk, de

nekünk kell igazolnunk a hamisságát. ƒ D: A titkos kulcsunkkal aláírt dokumentumot csak a nyilvános kulcs nyitja, így az aláírás letagadhatatlan. Ha titkos kulcsunkat ellopták, annak tényét nekünk kell bizonyítanunk. e.) Az aláírás tárgya szerinti különbségek ƒ H: Csak papíralapú dokumentumot lehet aláírni. ƒ D: Bármilyen digitális anyagot (fájlt) alá lehet vele írni. f.) Az aláírt dokumentumok másolása ƒ H: A másolat nem hiteles, ha az aláíró nem írja alá újra, vagy harmadik fél nem hitelesíti (közjegyző). ƒ D: A másolat az eredetivel egyenértékű, hiszen a másolat bitről-bitre megegyezik. 4. 2 2 A digitális aláírás kezelése A digitális aláírást kezelő rendszernek minimálisan meg kell valósítania az aláírás és az ellenőrzés funkcióit. Az aláírás azt jelenti, hogy egy adott üzenethez tartozó aláírást el kell tudnia készíteni, ami magában foglalja az aláírás körülményeire vonatkozó

adatokat is (dátum, időpont, hely). - 64 - Az ellenőrzés pedig azt jelenti, hogy az üzenet hitelességét ellenőrizni kell tudnia. Ha az üzenet és az aláírás egyértelműen összetartozik, a vizsgálat eredménye igaz, egyébként pedig nem igaz. Az aláírásnak valamilyen módon biztosítania kell a hamisíthatatlanságot. Erre az egyik megoldás az lehetne, hogy az aláíró algoritmust titokban kell tartani, míg egy olyan ellenőrző függvényt kell kitalálni, amiből nem reprodukálható az aláíró függvény. Ez azonban amellett, hogy kényelmetlen megoldás, nem nyerné el a szakma bizalmát sem, hiszen az utóbbi néhány évtizedben azt tekintjük biztonságos megoldásnak (algoritmusnak), amely nyilvános, így kiállta a szakemberek analízisének, támadásainak próbáját [19]. A másik lehetőség, hogy nyilvános és egységes algoritmusokat használunk. Az ellenőrzéshez szükséges kulcs tehát a nyilvános kulcs lesz, az aláírásra alkalmas

pedig a titkos kulcs. Ezzel a helyzet nem tér el lényegesen a megszokott PIN kódos megoldásoktól, hiszen a titkos kulcsot lehet egy csipkártyán tárolni, amit a PIN kód véd. Ezzel azonban továbbra is azt feltételezzük, hogy a titkos kulcs egyedül a tulajdonos birtokában van, így senki sem tud a nevében aláírni. A jelenleg legbiztosabb megoldás tehát ezek kombinációja a biometrikus azonosítással (ujjlenyomat, írisz). Ha a tulajdonos tudomást szerez kulcsának eltulajdonításáról, visszavonhatja azt. Ha viszont a támadó erről tudomást szerez, rendszerórájának visszaállításával elhitetheti egy dokumentumról, hogy a visszavonás előtt lett aláírva. Erre jelent megoldást az időbélyeg-szolgáltató (TSA), aki soha nem ad ki igazolást múltbéli vagy jövőbeli időpontról. Például, ha a TSA maga is aláírja a dokumentumot, bizonyítható, hogy a dokumentum valóban létezett már az adott időpont előtt [2]. 4. 2 3 A digitális aláírása

tartalma A digitális aláírás elkészítésének technikai folyamata a gyakorlatban: ƒ Szükség van egy hash-algoritmusra. Ez általában az SHA-1 (160 bit) vagy az MD5 (128 bit). Ezek egy fix hosszúságú bitsorozatot adnak eredményül Ez a viszonylag rövid bitsorozat képviseli a továbbiakban a dokumentum tartalmát. ƒ A bitsorozathoz hozzáfűzzük a következő kiegészítő információkat: o Az aláíró nevét vagy más azonosítóját - 65 - o Az aláírás idejét o A használt hash-algoritmus nevét vagy azonosítóját o Az aláírás helyét ƒ Ezután az egész csomagot kódolja az aláíró a titkos kulcsával, így az eredmény a nyilvános kulcsával olvasható. ƒ Az aláírt dokumentumot és az iménti kódolást is elküldi a címzetthez, szükség esetén csatolva a nyilvános kulcsot is. ƒ A fogadó oldal megfejti a csatolt adatot, kiszámolja a kapott dokumentum bitsorozatát, amit utána összehasonlít az aláírás megfelelő részével.

Ha a kettő egyezik, minden rendben van. 4. 2 4 A digitális aláírás hitelessége Mint korábban már láttuk, a nyilvános kulcsú technikák legsebezhetőbb pontját a MITM támadások jelentik. Esetünkben ez a következőképpen zajlik: ƒ A elküldi az aláírt levelet ƒ X elkapja, leválasztja A aláírását, megváltoztatja a dokumentumot, majd aláírja az általa generált ál-A kulccsal, és elküldi B-nek. ƒ Ha B aláírva válaszol, X ugyanígy járhat el, de most egy ál-B kulcsot generál. Erre a problémára a hitelesítő szolgáltatók (CA) jelentenek megoldást. Ha elmegyünk egy ilyen hitelesítő szervezethez a személyi igazolványunk társaságában, kaphatunk egy hitelességi bizonyítványt arról, hogy a nyilvános kulcs valóban a miénk. A fenti példában így B könnyen ellenőrizheti, hogy az adott kulcs ténylegesen A-hoz tartozik-e, hiszen a bizonyítvány bárki számára hozzáférhető [2]. 4. 2 5 Hitelesítési szolgáltatók, bizalmi

modellek A hitelesítők és a hitelesítettek kapcsolata alapján a következő szerveződések különíthetők el, melyeket bizalmi modelleknek nevezünk (trust models): ƒ Szigorúan hierarchikus viszony: a szereplők között egyértelműen meghatározható alá- vagy fölérendeltség van. A hierarchia csúcsán a root-CA áll, akit mindenki hitelesnek ismer el, jóllehet ő maga nincs hitelesítve. Az általa hitelesített hitelesítők (subordinate CA) további CA-kat és kulcsokat hitelesíthetnek úgy, hogy a hitelesített fél a hierarchia alsóbb szintjén áll. A - 66 - nyomon követés alulról felfelé történhet. Ha egy root-CA kiesne, az a teljes kapcsolatrendszert felborítaná, ezért ezek titkos kulcsait gyakran elzárják (megsemmisítik). ƒ Egyenrangú kapcsolatok: a bizalmi hálóhoz hasonlóan bármelyik CA hitelesítheti bármelyik CA-t (bridge). Sokkal hibatűrőbb, de a „családfát” nehéz feltérképezni. Hurkok is kialakulhatnak,

azonban ez a gyakorlatban ritkán fordul elő, mivel egy kulcsot csak egy CA hitelesíthet. ƒ Hibrid megoldások: több root-CA van, de minden nonroot-CA csak abban a csoportban végezhet hitelesítéseket, amelybe maga is tartozik. Egy nonroot-CA csak a saját csoportjában lévő, felette álló hitelesítőtől kaphat bizonyítványt, de a root-CA-k egymás között szabadon hitelesíthetnek az egyenrangú modell szerint [2]. 4. 2 6 A hitelességi bizonyítvány Többféle formátumú bizonyítvány is kialakult az utóbbi időben, de alapvetően mindegyik a következő adatokat tartalmazza: 1. A kulcs tulajdonságának adatai ƒ Név vagy azonosító ƒ A nyilvános kulcs ƒ A kulcs hash-lenyomata 2. A bizonyítvány adatait ƒ A kibocsátó neve vagy azonosítója ƒ A bizonyítvány sorszáma / azonosítója, verziószáma ƒ Érvényességi ideje ƒ Az aláíráshoz használt hash-algoritmus azonosítója ƒ Az aláíráshoz használt algoritmus neve 3. A

bizonyítvány érvényességi köre (certified usage) ƒ Mire használható: pl. aláírásra, titkosításra, szerver-azonosításra, szoftver eredetének igazolására, SSL-kapcsolathoz, stb. ƒ Ki használhatja: szervezet (cégszerű aláírás) vagy személy használhatja, illetve eszköztanúsítványként használható - 67 - 4. 1 ábra: Az OTP Bank Rt Hitelességi bizonyítványa A Részletek fülön láthatók a fentebb ismertetett tanúsítvány-adatok. 4. 2 7 Esettanulmány: a K & H Bank Rt Hitelesítő rendszere Ha a K&H banknál vezetjük vállalkozói számlánkat, lehetőségünk nyílik áttérni az elektronikus ügyintézésre. Ehhez nem kell mást tennünk, mint elfáradni egy bankfiókba, s megkötni egy e-bank szerződést. Cserébe kapunk majd egy csipkártyát, amin látható a nevünk és a kártya sorozatszáma is, egy kártyaolvasót, egy telepítő CD-t és egy PIN borítékot. Ha igénybe szeretnénk venni az elektronikus banki

szolgáltatást, telepítenünk kell a kártyaolvasó szoftverét a számítógépre (csak Windows operációs rendszer támogatott), majd behelyezni a kártyát és egy arra alkalmas böngészővel rácsatlakozni az e-bank webhelyére (SSL, RC4). Mozilla Firefox használata esetén egy beépülő modult (plugin) kell telepítenünk, hogy a böngésző kezelni tudja a kártyát. Ezután meg kell adnunk a PIN-kódunkat, majd hozzáláthatunk a rendszer kezeléséhez (átutalás, egyenleg, mobiltelefon-feltöltés, stb.) - 68 - Ha több személy is szeretné használni cégünk e-bank rendszerét, nekik is igényelhetünk hozzáférést, jól meghatározott jogosultságokkal és saját csipkártyával. A definiált jogok a következők lehetnek: ƒ Lekérdezési jog számlánként meghatározva ƒ Lekérdezési jog az összes számlára vonatkozóan ƒ Aláírási jog számlánként ƒ Cégszintű aláírási jog Az adott kártyát eltulajdonítás esetén letilthatjuk. A

bankok általában nem számítanak fel külön költséget a vállalkozói számlavezetésért szükséges havidíjon (2500-10 000 Ft) felül, hiszen ez nekik is jelentős egyszerűsítést jelent (kevesebb ember a bankfiókban) [14]. Az OTP-nél mindez mobiltelefonos hitelesítéssel van megoldva, aminek legfőbb hátránya, hogy az SMS-ekért fizetni kell. Működése a következő: a szokásos jelszavas hitelesítés után minden tranzakció megerősítő kódját SMS-ben kapjuk meg a mobiltelefonunkra, amellyel megerősíthetjük vagy visszautasíthatjuk a tranzakciót. A szolgáltatás havidíja jelenleg jelképes, 99 Ft. Egyéni ügyfeleknek 24 éves kor alatt az SMS-ek is ingyenesek csakúgy, mint a számlavezetési díj. 4. 2 8 A digitális aláírás jogi szabályozása Magyarországon 2000. augusztus végén kormányhatározat rendelte el az elektronikus aláírást szabályzó törvény megalkotását, előkészítését. A törvénytervezetet 2001 májusában fogadta el az

Országgyűlés és szeptember elején lépett hatályba. A törvény az Európai Parlament és Tanács elektronikus aláírásokra vonatkozó irányelvein alapszik. Az aláírás jogi szabályozásának az EU irányelvek szerint technológiától függetlennek kell lennie. A digitális aláírás jellemzői közül jogilag is fontosak a következők: ƒ Könnyen létrehozható és ellenőrizhető ƒ Nem hamisítható és letagadhatatlan ƒ Az aláírás hitelesíti a dokumentum tartalmát és az aláíró személyét is ƒ Szavatolni kell a nyilvános kulcs személyhez kötöttségének valódiságát ƒ Meg kell oldani a hagyományos keltezés elektronikus megfelelőjét is - 69 - A törvény jelentősége abban áll, hogy – néhány kivételtől eltekintve – az elektronikus aláírást minden szempontból egyenlővé teszi a hagyományossal (polgári perek, bűnvádi eljárások, államigazgatás, üzleti élet). Magyarországon viszonylag későn születettek meg

az Internetre és az elektronikus adatvédelemre vonatkozó jogszabályok annak ellenére, hogy a technológiák már régóta rendelkezésre álltak [2]. 4. 3 Adatvédelem az Interneten Amikor az Interneten keresztül kommunikálunk, sokszor eszünkbe sem jut, hogy számos esetben valójában mindenfajta védelem nélkül vagyunk kénytelenek ezt tenni. Gondoljunk például a megszokott beléptető (login) képernyőkre, ahol jelszavaink egyszerű szöveges módban utaznak az Interneten (pl. freemailhu) Ennek kivédésére szolgálna az SSL, azonban ennek is vannak hiányosságai, amiket a felhasználói figyelmetlenségnek köszönhetően ki lehet használni. Ezen fenyegetettségekre kívánok rámutatni, nagyobb hangsúlyt helyezve a napjainkban divatossá vált támadási technikákra és az ellenük való védekezésre. 4. 3 1 A hagyományos bejelentkezési módszerek A legtöbb, online rendszerrel rendelkező bank teljesen vagy részlegesen egy PIN kódot vagy jelszót alkalmaz.

Ez jelenti az információ-biztonság alapszintjét, ami az Internet megjelenése óta fontos tényező. Mindez azt jelenti, hogy a felhasználónak be kell írnia a PIN-kódját vagy jelszavát teljesen, vagy részben (első, harmadik és ötödik számjegyét). Néhány bank olyan módszereket vezetett be, amelyek egyszer használatos jelszavakon alapulnak, s egyre több jel mutat ezek irányába. Ez azóta ajánlott, amióta az amerikai Federal Financial Institutions Examination Council (FFIEC) lefektette a pénzügyi intézmények irányelveit, a biztonság minimális követelményeit szabványosítva. 4. 3 2 A Phishing és Pharming Az „owning the desktop” (az asztal birtoklása) egy hackerek által alkalmazott kifejezés, ami arra utal, hogy a támadó képes figyelni valaki más tevékenységét a saját gépén. Ezt úgy lehet elérni, hogy a megtámadott PC-re programokat telepítenek, amik elfogják az - 70 - adatokat böngészés közben, például a begépelt

karaktereket. Ezzel a képességgel a hacker hozzájuthat a bejelentkező adatainkhoz. Ez ahhoz a social engineering támadási módhoz vezet, aminek a neve: phishing. A módszer azt jelenti, hogy a hackerek több ezer e-mail kiküldésével keltik azt a látszatot, hogy adategyeztetésre van szükség valamelyik pénzzel kapcsolatos cégnél (PayPal, eBay). Az áldozatok egy tökéletesen ugyanolyan hamis oldalra kerülnek, így sokan bejelentkeznek, majd megadják minden adatukat, beleértve a felhasználónevüket, PINkódjukat és jelszavukat. A pharming egy fejlett phishing technika, amelynek megvalósítására a legelterjedtebb módszer a trójai falovak alkalmazása. A következő eset ennek tipikus példája A hacker levélben küld egy vírust, például a Banker Trojan-t, ami felülírja a PC localhost fájlját. Ez egy olyan fájl, ami az URL címek (pl googlecom) és a numerikus IP címek (pl. 64553322) közötti megfeleltetést tárolja Így a bank URL-jéhez tartozó

IP-címet átírva a gyanútlan felhasználó nem a kívánt oldalra kerül, hanem egy teljesen hasonló, hamis weboldalra. Amikor tehát böngészőben a kedvencekre kattintunk, akkor is tudtunk nélkül kerülünk a hacker által készített oldalra. A Domain Name Server (DNS) poisoning pedig azt teszi lehetővé, hogy egy nagy halom felhasználó a hamis oldalra legyen irányítva. 4. 3 3 A Man in the Middle támadás A másik problémát a MITM támadás jelenti, ami nagyon alattomos, így rendkívül hatékony. Ez a támadási mód akkor jelenhet meg, ha a hacker hozzáféréshez jut a hálózat egyik fizikai eszközéhez, vagy az ARP Spoofing technikát alkalmazza. Ez lehetővé teszi, hogy az egyik gép a másiknak adhassa ki magát. A hacker azonosít két pontot a hálózaton, majd ezeket – az általában egyedülálló gépeket – támadja meg. Ingyenes programokat használva lehet megoldani ezután, hogy a forgalom a hacker gépén át kerüljön megtámadott PC-hez és

fordítva. A veszély itt egyértelmű - a hacker könnyen kihallgathatja a forgalmat. Képzeljük csak el, hogy mi történhet akkor, amikor az online bankban a kijelentkezésre kattintunk; a MITM látszólag valódi kijelentkezési megerősítést jeleníthet meg, miközben valójában nyitva hagyja a kapcsolatot a bankkal. - 71 - Technikai nyelven szólva a bejelentkezés után a munkamenet- és a tranzakció-kezelés folyamatos, amíg a felhasználó ki nem jelentkezik vagy a kapcsolat meg nem szakad. 4. 3 4 A hitelkártya-csalás A hitelkártyák sajátosságait kihasználva terjedt el egy veszélyes támadási módszer. Konkrétan: ƒ Minden hitelkártya 13-16 számjegyből álló számmal azonosítható, amit egy megadott módon állítanak elő, a Luhn Formula nevű matematikai algoritmus segítségével. Ezt arra találták ki, hogy meg lehessen bizonyosodni arról, hogy csak bizonyos számok használhatók - megakadályozva ezzel a próbálkozásokat. ƒ Egy ingyen

letölthető program segítségével egyszerűen generálhatunk rengeteg érvényes számot. Csak megadunk egy érvényes hitelkártya számot, s ez alapján megadott mennyiségű további számmal lát el minket. ƒ Jogos azt hinni, hogy a számból generált más számokhoz tartozó kártyák lejárati ideje hasonló. ƒ A hacker ellátogat egy webáruházba, s vesz valami letölthető programot. ƒ Álnéven és címen belép, majd megad egy hamis biztonsági kódot és az előbb generált kártyaszámot, a kártya lejárati idejével együtt. ƒ Ha ezt a számot egy bank már kiadta egy ügyfelének, akkor szorgalomtól függően a fizetség el is jut az áruházhoz. Ez azért lehetséges, mivel a fizetőkapuk (payment gateway) általában csak adatokat tárolnak, de azok hitelességét nem ellenőrzik. Így, ha minden adat megfelelő volt, és a lejárati idő is stimmel, akkor a fizetség eljut az áruházhoz, s a letöltés megkezdődhet. ƒ Ha a kártya valódi

tulajdonosa nem jön rá a hackelésre, akkor sohasem veszik észre, a hacker további (értékesebb) árucikkeket vásárolhat a megszerzett hitelkártya-adatokkal. 4. 3 5 Az SSL biztonsági problémái Az SSL két pont között teremt kapcsolatot; az egyik miért ne lehetne egy gépi vezérlésű MITM támadásra felkészített kliens? A másik a pharming, ami ellen az SSL nem nyújt védelmet. - 72 - A desktop attack ellen sem véd az SSL, mivel a böngésző és az internetes oldal között épül fel. Ha egy trójai vagy egy spyware dolgozik a gépünkön, az adatokat azelőtt manipulálják, mielőtt azok titkosítva lennének. Akkor nyújthat védelmet, ha a hitelességi bizonyítvány hamisságát felismeri a felhasználó. De vajon hány átlagfelhasználó ismeri fel? A fentiek kezelése érdekében a US FFIEC irányelveket dolgozott ki, amelyek minimumként kéttényezős hitelesítést jelölnek meg. 4. 3 6 A napjainkban alkalmazott internetes adatvédelmi technikák

Egyfaktorú és kétfaktorú hitelesítésről beszélünk attól függően, hogy hány különböző forrásból származnak a belépéshez szükséges adatok. Egy faktorú hitelesítési megoldások: a jelszavakat nem tömörítik vagy álcázzák olyan módon, hogy védettek legyen a keyloggerek, képernyőlopók vagy phishing technikák ellen. Típusai: ƒ Teljesen elküldött jelszó: a PIN-kódot teljes egészében be kell ütnünk ƒ Részlegesen elküldött jelszó: a PIN-kód adott betűit kell beütnünk; a phishinget csak kicsit teszi nehezebbé ƒ Virtuális billentyűzet: nem a billentyűzettel, hanem egérrel visszük be a karaktereket; képernyőlopók ellen nem véd Két (külön) faktorú hitelesítési megoldások: két különböző tényező segítségével állítjuk elő a bejelentkezési információt, vagyis a beírt jelszót más forrásból származó kóddal egészítjük ki. Típusai: ƒ Bingó kártya (Static Grid kártya): A felhasználó először

beírja a szokásos jelszavát, majd egy grid kártyáról származó adatot kell megadnia, amit például egy PDA-val kezel. Az egyetlen gond az adminisztrációval adódhat, ugyanis minden alkalommal, amikor egy adathalmazt megadunk, ezt ki kell zárnunk a további lehetőségek közül, különben a biztonsági szint csökken. ƒ TAN lista: a Transactional Access Number rövidítés eredménye, amit a Bingótípusú grid kártyánál gyengébbnek tekintenek. A TAN lista különböző - 73 - hosszúságú számokat tartalmaz, amiket a készítők választanak, s a kártyára helyeznek. Ez a megoldás elterjedt az EU-ban ƒ Mobiltelefonos SMS Jelszó: az egyszer használatos jelszavakat SMS-ben kapjuk meg a bejelentkezés során. Ennek a megoldásnak az lehet a korlátja, hogy az SMS-üzeneteket meghatározott időn belül el kell juttatni a felhasználó telefonjára – s persze nem is mindenki rendelkezik mobiltelefonnal (főleg külföldön. Két (kombinált) faktorú

hitelesítési megoldások: a felhasználó kombinálja jelszavát és egy másik karaktersorozatot annak érdekében, hogy a jelszó egy kódolt változatát hozza létre, vagy egy egyszer használatos jelszót (One Time Password, OTP) kap mobiltelefonon. Ebbe a kategóriába a következők tartoznak: ƒ Dinamikus Grid Kártyás OTP: ezek hasonlók a Bingó-kártyához azzal a különbséggel, hogy itt a jelszó vagy PIN a gép monitorán megjelenő információval lesz kombinálva, majd egy tokenné lefordítva. ƒ Mobiltelefonos/PDA-s OTP: egy kezdeményezés már útjára indult, ami azt célozza meg, hogy a mobiltelefonok és a PDA-k képesek legyenek olyan kódolt szavak előállítására a PIN-kódjukból, amiket ilyen célra fel lehet használni. A dolog hasonlít az elektronikus tokenre, de olyan megoldással szolgálhat, ami a potenciális vásárlóknak egyből a birtokába kerül, csökkentve ezzel a költségeket [15]. - 74 - FELHASZNÁLT IRODALOM [1] Mathworld,

Mersenne-prímek http://mathworld.wolframcom/news/2005-12-25/mersenne-43/ [2] Virasztó Tamás – Titkosítás és adatrejtés (2004) NetAcademia Oktatóközpont [3] Nicolas T. Courtois honlapja, az XSL-módszerről http://www.minrankorg/aes/ [4] Rivest és Silverman – Are strong primes needed for RSA? http://theory.lcsmitedu/~rivest/RivestSilverman-AreStrongPrimesNeededForRSApdf [5] Mathworld, RSA-Challenge http://mathworld.wolframcom/news/2005-05-10/rsa-200/ [6] Lucky Green - 1024 bit RSA keys in danger of compromise http://lists.saigoncom/vault/security/encryption/rsa1024html [7] Philip Zimmermann – An introduction to cryptography (2000) Network Associates [8] Paul Johnston biztonsági szakértő honlapja http://pajhome.orguk/crypt/rsa/ [9] Mathworld, prímtesztek http://mathworld.wolframcom/news/2002-08-07/primetest/ [10] Himanshu Dwivedi – Implementing SSH (2004) Wiley Publishing - 75 - [11] Az OpenSSH projekt honlapja http://www.opensshcom/ [12] A

SecureBlackBox komponenscsalád honlapja http://www.eldoscom/sbb/ [13] A BitVise SSH Library honlapja http://www.bitvisecom/sshlibhtml [14] K&H Bank Általános szerződési feltételek, https://ebank.khbhu/vallalat/download/aszf hupdf [15] Pat McKenna An Introduction to Internet Security Part 1-5 http://www.tomshardwarecom [16] Kiss Krisztián tanár honlapja http://www.sztveinhu/~kisskri/delphi2/felev2html [17] Az MP3 szabvány leírása http://www.id3org/ [18] Bruce Schneier Crypto-Gram Hírlevel (2002) http://www.schneiercom/crypto-gram-0209html [19] Pásztor Miklós honlapja (MTA SZTAKI) http://www.ppkehu/~pasztor/ Pásztor Miklós [20] Marco Cantú – Mastering Delphi 7 (I., II) (2003) SYBEX - 76 - ÁBRAJEGYZÉK 1. 1 ábra: kölcsönös információ 10 1. 2 ábra: a titkosság mértéke 10 1. 3 ábra: az egyértelműségi pont 11 1. 4 ábra: Diffie-Hellman kulcscsere két résztvevővel 19 1. 5 ábra: Diffie-Hellman kulcscsere három résztvevővel 20 1. 6

ábra: hatalmas, karaktersorozatként kezelt számok összeadása 28 1. 7 ábra: RSA implementáció Java-ban 29 2. 1 ábra: Az OpenSSH Windows-ra portolt verziójának telepítése 39 2. 2 ábra: Bejelentkezés az OpenSSH szerverre a PuTTY segítségével 41 2. 3 ábra: Sikeres bejelentkezés az OpenSSH szerverre 41 2. 4 ábra: A PuTTY SSH Beállításai 44 2. 5 ábra A háttérben látható a virtuális gépből elért szerver; az előtérben pedig a gazdagépről történő biztonságos elérés a 2400-as porton keresztül . 46 2.6 ábra: Távoli elérés és fájlmegosztás Windows XP és SuSe Linux 10 között, SSHval titkosítva 48 3. 1 ábra: az MP3 Szerver program működés közben 56 3. 2 ábra: A kliens beállítása 56 3. 3 ábra: Fájllista végrehajtása a klienssel A szerver ikonja a tálcán látható 57 4. 1 ábra: Az OTP Bank Rt Hitelességi bizonyítványa A Részletek fülön láthatók a fentebb ismertetett tanúsítvány-adatok. 67 - 77 -

ÖSSZEFOGLALÁS Szakdolgozatomban áttekintettem az egyes titkosítási rendszerek múltját és jelenét, figyelembe véve az egyes megoldásokig vezető utat. Szóba kerültek a kezdetleges titkosítási módszerek, a szimmetrikus (DES, AES-pályázat nevezői), az aszimmetrikus módszerek (Diffie-Hellman, RSA), de az ezek kombinációját jelentő hibridkriptorendszerek (PGP) is. Részletesen bemutattam az RSA-algoritmust magát, ajánlott használatát és paraméterezését, illetve egy alkalmazást is készítettem Java-nyelven, amely a szabványos függvénykönyvtárak alkalmazásával képes megoldani a kulcsgenerálás és titkosítás-visszafejtés feladatát. Ismertettem a különböző, általánosan elterjedt programnyelveket (C++, C#, Delphi, Java) használók számára ajánlott gyors és hatékony megoldásokat is, külön figyelmet fordítva a liszenszelési feltételekre és a függvénykönyvtárak, komponensek áraira is. Az SSH-val foglalkozó fejezetben minden

fontos funkciót megvizsgáltam és a gyakorlatban is kipróbáltam, megadva a helyes beállításokat és felhasználási tanácsokat a magas fokú adatvédelem érdekében. A szakdolgozat utolsó fejezetét a hitelesítésnek, a digitális aláírásnak és az ehhez szorosan kapcsolódó, napjainkban egyre terjedő Internetes csalásoknak és az ellenük való hatékony védekezés módszereinek szenteltem. - 78 - ABSTRACT In my thesis I looked over the past and present of encryption systems, taking into consideration the path to each solution. First, the elementary cipher methods came into question, then the symmetric (DES, entrants of the AES-competition) and asymmetric (Diffie-Hellman, RSA) systems, but the combinations of these, the hybrid cryptosystems (PGP) were also mentioned. I presented the RSA-algorithm itself and the ways of recommended usage of parameters in detail, and I made an application using the Java programming language, solving the task of key generation and

encryption-decryption while using the standard libraries. I introduced the different, high speed and efficient solutions for the users of wide-spread programming languages (C++, C#, Delphi, Java), paying distinct attention to the licensing conditions and the prize of the libraries and components. In the chapter dealing with SSH, I examined every important functionality, trying out all of them in practice, providing the appropriate configuration and usage recommendations for the sake of high-level data security. I devoted the last chapter of my thesis to authentication, digital signatures and the closely related and spreading online fraud, regarding the efficient defence against them