Kriptoprotokollok és alkalmazásuk határvédelmi eszközökön
Scheidler Balázs <bazsi@balabit.hu>
BalaBit IT Kft.
Kezdetben az Internet elsosorban kutatási célokat szolgált, és ennek megfeleloen egyetemek és kutatási intézetek kapcsolódtak rá. A csatlakozott intézmények kis száma miatt az egymás iránti bizalom inkább jellemzo volt egy privát-, mint egy világméretu nyilvános hálózatra. Ebben az idoben alakultak ki a legfontosabb protokollok, például maga a TCP/IP, illetve a TCP-re épülo telnet vagy FTP alkalmazási protokollok.
A kialakult protokollokban a hitelesítés alapja általában egy felhasználói név illetve egy jelszó megadása, melyek mindenfajta védelem (titkosítás) nélkül kerülnek a hálózatra.
A hálózat növekedésével a helyzet megváltozott, egyre több szervezet kapcsolódott az Internetre, a korábban kialakult bizalom elúszni látszott. Ez elsosorban abban nyilvánult meg, hogy a betörés veszélyeitol tartva sokkal jobban kellett védeni a hálózati végpontokat (a szervezetek hálózatait), illetve abban, hogy az átvitt adatokat is védelemmel kellett ellátni. A megoldást a kriptográfia jelenti, melyet óvatosan kell a probléma megoldása érdekében felhasználni. A két cél (szervezetek hálózatainak védelme határvédelmi eszközökkel), valamint az adatok védelme kriptográfiai módszerekkel ellentmondásban van. Titkosított adatokat nem lehet ellenorizni egy tuzfalon, ami alááshatja egy teljes hálózat biztonságát. Jelenleg két lehetoségünk van: 1. átengedni a titkosított forgalmat, megnyitva egy potenciális veszélyforrást, 2. nem átengedni a titkosított forgalmat, így
érzékeny adatokat veszélyeztve.
Ebben a fejezetben egy gyors áttekintést adok a kriptográfiában gyakran használt komponensekrol, melyeket egy konkrét alkalmazás megvalósításákor felhasználhatunk. Itt kell megjegyezni azonban, hogy egy ilyen alkalmazás megtervezésekor, és megvalósításakor nagyon körültekintoen kell eljárnunk, ugyanis a legkisebb hiba is a teljes rendszer sebezhetoségéhez vezethet.
Legfontosabb fogalmak, melyeket ebben a fejezetben használni fogok:
cleartext: titkosítás nélküli szöveg
ciphertext: titkosítás utáni szöveg
cipher: titkosítási algoritmus, mely a bemenetén valamilyen transzformációt végez
kulcs: olyan információ, mely a titkosítás a cleartexten kívül a cipher bemenete, és mely nélkül a titkosítás nem megfordítható
Az algoritmusok ezen osztályába a hagyományos értelemben vett titkosítási algoritmusok tartoznak. A kódoláshoz és a dekódoláshoz felhasznált kulcs ugyanaz.
2-1. Ábra: A kódolás menete szimmetrikus cipherrel
kulcs
|
cleartext ---> cipher ---> ciphertext
2-2. Ábra: A dekódolás menete szimmetrikus cipherrel
kulcs
|
ciphertext ---> decipher ---> cleartext
A különbözo cipherek közti különbség lehet például a kulcs hossza, illetve az egyszerre átalakított bitek száma (blokkméret). Példa a szimmetrikus cipherekre például a DES (Digital Encryption Standard), illetve a nemrégiben elfogadott AES (Advanced Encryption Standard), melyett Rijndael néven is ismerhetünk.
Ezek az algoritmusok hasonlítanak a szimmetrikus változatukhoz annyiban, hogy cleartext-bol ciphertextet állítanak elo, mégpedig egy kulcs segítségével. A különbség abban áll, hogy a kódoláshoz és a dekódoláshoz használt kulcs különbözo, és bár egymástól nem függetlenek, a kódoláshoz használt kulcsból meghatározni a dekódoláshoz megfelelot olyan probléma, melyet megfeleloen választott kulcsméret esetén szinte lehetetlen végbevinni.
Az aszimmetrikus algoritmusok körülbelül 3 nagyságrenddel lassabbak, mint szimmetrikus társaik, így ezeket elsosorban a kulcsmenedzsment megkönnyítéséhez, valamint hitelesítéshez használják, nagymennyiségu adatok kódolásához szinte mindig szimmetrikus ciphert választanak.
Aszimmetrikus algoritmus például az RSA, melynek 2000. szeptember 20-án járt le a szabványügyi védettsége.
A két kulcs közül az egyiket publikus kulcsnak, a másikat pedig titkos kulcsnak hívjuk. Mint azt nevük is mutatja, a publikus kulcsot nem kell titokban tartanunk, sot cél a publikus kulcs minél jobb elterjesztése. Egy elterjesztett publikus kulccsal lekódolt üzenetet, kizárólag csak a privát kulccsal rendelkezo személy tudja majd dekódolni.
Az aszimmetrikus ciphereknek fontos felhasználási területe a titkosításon kívül a digitális aláírás. Ilyenkor nem az üzenet tartalmának titokban tartása a cél, hanem hogy 1) az üzenet eredetiségét igazolja, 2) hogy az aláírót kösse, mint ahogy egy igazi szerzodés aláírása is köti az aláíróját annak betartásához.
2-3. Ábra: A digitális aláírás menete
titkos kulcs
|
cleartext (hash) ---> cipher ---> aláírás
A titkos kulcsal lekódolják az üzenetet (illetve annak egy digitális újlenyomatát, ld a 2.3. fejezetet), melynek az eredményét, az aláírást csatolják a dokumentumhoz. Az aláírást a publikus kulccsal dekódolva megkapjuk az eredeti szöveget (illetve az újlenyomatot), és mivel a titkos kulcs csak az aláíró személynél található meg, így helyes aláírást is csak o generálhatott.
A hash függvény a változó méretu bemeno adatokat egy fix hosszúságú adathalmazra képezi le. A kriptográfiailag jó hash függvények elég nagy valószínuséggel ütközésmentesek, azaz annak a valószínusége, hogy két különbözo bemeno adathalmaz ugyanarra az eredményre vezet, elhanyagolhatóan kicsi.
Egy adathalmaz ilyen módon generált képét nevezzük az adott adathalmaz digitális újlenyomatának is.
Ilyen algoritmus például az MD5, melynek eredménye 128 bites, vagy az SHA1, mely 160 bites kimenetet generál. Így annak az esélye, hogy két különbözo adathalmazra ugyanazt a kimenetet generálják 1:2128 ill 1:2160, feltéve persze, hogy a lehetséges kimenetek valószínusége egyforma.
A véletlenszám generátoroknak legfontosabb szerepe a kulcsok generálásában van. Egy egyszeru jelszó entrópiája túl alacsony, ha kulcsként használnánk, akkor az könnyen a kriptográfiai rendszerünk leggyengébb pontjává válna.
Egy komplex rendszerben számos esetben van szükségünk kulcsokra, így véletlenszám generátorra is. Ha véletlenszám generátorunk gyenge, kiszámítható, a titkosítást ott támadják meg, ahol legkevésbé számítunk rá: meghatározható a kulcs, mely a teljes rendszer biztonságáért felel.
Mielott valakivel titkosított kommunikációt kezdenénk, a túloldalt hitelesíteni kell, hiszen hiába minden titkosítás, ha nem a szándékukban álló emberrel társalgunk. Ez a problémakör a hitelesítés
problémája, és a következokben áttekintett lehetoségeink vannak.
A hitelesítés általában annyit tesz, hogy a hitelesítendo fél valamilyen módon bizonyítja, hogy birtokában van valamilyen, az azonosságát bizonyító adatnak (angolban erre használják a credentials kifejezést). Nyilván a bizonyítás közben maga az adat nem kerülhet megbízhatatlan csatornára, ezért nem lehet egyszeruen a másik oldalra elküldeni.
Közös titkok
Amennyiben a két fél rendelkezik egy közös titokkal, melyet korábban megbízható útvonalon (futárral, telefonon stb) juttattak el egymáshoz, akkor a hitelesítés a titok meglétének bizonyítását jelenti.
Nyilvánvaló, hogy nem jó megoldás a még titkosítatlan útvonalon egyszeruen átküldeni a titkot, mert az ezután már nem lesz titok. A probléma egyik megoldása lehet az, hogy egy random számot (ún. challenge-t), melyet a hitelesíto fél küld a hitelesítendonek, a titokkal, mint kulccsal lekódoljuk, majd az eredményt visszajuttatjuk.
Itt a hitelesítést az jelenti, hogy bizonyítjuk, hogy egy publikus kulcshoz rendelkezünk a megfelelo titkos kulccsal. Az elozoekben ismertett módszer itt is muködoképes, azaz egy challenge aláírásával bizonyíthatjuk a titkos kulcs meglétét.
Ha a publikus kulcsot a közös titkokhoz hasonlóan független csatornán juttatjuk el a célszemélyhez, akkor nincs problémánk, viszont nyilván a teljes hitelesítés megbízhatóságát alááshatja az, hogy a hitelesíto nem a megfelelo publikus kulccsal rendelkezik. Annak érdekében, hogy a publikus kulcsot ne kelljen futárral eljuttatni a célszemélyhez és a hitelesítés mégis megbízható legyen találták ki a különbözo tanusítványokat (certificate). A tanusítvány feladata, hogy egy publikus kulcsot (felfoghatjuk digitális azonosságnak) összerendel egy valós személyiséggel (valódi azonosság), azaz Kis Istvánt összerendeli a hozzá tartozó publikus kulccsal, oly módon, hogy a kötodést egy (szintén digitális) aláírással igazolja. Ha megbízunk az aláírásban, akkor elhihetjük, hogy az adott publikus kulcs tényleg Kis Istváné. A tanusítványok aláíróját, kiállítóját szokás Certificate Authority-nek (CA-nak), tanusítványkiadó központnak is nevezni.
Egy tanusítványkiadó hozhat létre újabb tanusítványkiadókat (aláírva a tanusítványkiadó tanusítványát), ilyen módon egy teljes hierarchia építheto fel CA-kból, és elég ha a hierarchia tetején levoben megbízunk (Ezek azok, melyek a böngészok "Signers" menüjében elérhetok).
Az eddig leírt modell alapvetoen az X.509 modellje, a PGP és az SPKI ennél jóval flexibilisebb.
Az X.509 tanusítványformátum ISO szabvány, az X.500-as címtárszolgáltatáshoz, és az X.400-as levelezési szolgáltatáshoz illeszkedik.
A tanusítványban az alanyt illetve a kibocsátót egy X.500-as (illetve LDAP) distinguished name (dn) jelöli:
alany: cn=Balázs Scheidler, o=BalaBit IT Ltd., l=Budapest, c=HU
kibocsátó: cn=CA, o=BalaBit IT Ltd., l=Budapest, c=HU
A formátum a kulcson kívül lehetové teszi érvényességi idotartam megadását, illetve - korlátozott módon - kiegészíto (extensions) adatok tárolását. Nem tartalmaz azonban a tanusítvány felhasználására vonatkozó információkat, és nem tesz lehetové több tanusító aláírást.
Bovebben az ISO szabványleírásokban olvashatunk errol a formátumról.
A PGP egy olyan program, melyet eredetileg Internetes elektronikus levelek titkosítására, és digitális alárírására használtak. Saját tanusítvány formátuma van, mely jóval rugalmasabb, mint az X.509 szigorú hierarchikus felépítése.
PGP-ben az alanyt és a kibocsátót egy e-mail cím és egy név jellemzi, pl:
alany: Balázs Scheidler <bazsi@balabit.hu>
kibocsátó: Zoltán Györkő <gyorkoz@balabit.hu>
A PGP a bizalmat az ún. bizalmi háló (web of trust) segítségével alakítja ki. Ez annyit jelent, hogy mindenki gyujtheti a saját publikus kulcsára az aláírásokat (tehát egy tanusítvány számos aláírást tartalmazhat), majd a publikus kulcs megosztásakor minden aláíró potenciális bemutató (introducer) szerepét töltheti. Bármelyikükben is bízik meg az, aki a kulcsot megkapta, az elegendo lesz ahhoz, hogy a tanusítványt megbízhatónak tekintse.
Láthatjuk, hogy a PGP rugalmasabban kezeli a bizalom kialakítását (szigorú hierarchia helyett háló), viszont továbbra sem tartalmaz arra vonatkozóan eloírásokat, hogy miként lehet az adott tanusítványt felhasználni.
Bovebben az RFC2440-ben olvashatunk errol a formátumról.
Az SPKI egy betuszó, jelentése Simple Public Key Infrastructure, és modellje szerint a tanusítvány nem csak egy személy publikus kulcshoz való kötését végzi, hanem jogosultságok átvitelét is. Tehát a tanusítvány nem egy alany, kibocsátó, aláírás hármas, inkább a meghatalmazáshoz hasonlítható: A kibocsátó meghatalmazza az alanyt valamire, így az igénybe vehet egy olyan szolgáltatást, melyet eredetileg csak a kibocsátó vehetett igénybe.
Ez a legrugalmasabb formátum, viszont a legújabb is, úgyhogy elterjedésére még várnunk kell.
Bovebben az RFC2693-ban olvashatunk errol a formátumról.
A 2. fejezetben ismertetett algoritmusok önmagukban még nem teszik a kommunikációt biztonságossá, szükség van a tervezett, szakszeru és körültekinto "összeszerelésükre" is. Ezeket végzik a lent bemutatott protokollok, melyek közül ketto, az SSL és az SSH, az átviteli rétegben-, egy pedig a hálózati rétegben végzi az adatok védelmét.
Az összes lenti protokollra igaz, hogy a protokoll kezdetén egy egyeztetés keretében a két fél kiválasztja a megfelelo algoritmusokat. Használhatunk egyszeru DES-t 56 bites kulccsal, de 3DES-t is 168-al.
Elsosorban a titkosított web oldalaknál találkozunk ezzel a protokollal, melyet eredetileg a Netscape fejlesztett ki. Az SSL protokoll a TCP-re épülve egy csoszeru, biztonságos csatornát alakít ki.
A hitelesítéshez X.509 tanusítványokat használ. A szervernek kötelezo tanusítványt bemutatnia, a kliensnek csak akkor, ha ezt a szerver megköveteli.
Az SSH a Secure Shell rövidítése, eredetileg Tatu Ylonen fejlesztette ki távoli kiszolgálók biztonságos interaktív eléréséhez. A protokoll ezen kívül képes beágyazott TCP csatornák átvitelére (TCP forwarding) és interaktív X Window alkalmazások adatforgalmának átvitelére is.
A szerver hitelesítése egy egyszeru publikus kulccsal történik, melyet a kliens megjegyez, majd esetleges megváltozásáról tájékoztatja a felhasználót. A folyamat leggyengébb pontja a kulcs kezdeti elfogadása. A teljesen újratervezett SSH2 protokoll már képes tanusítványok fogadására is,
azonban ezt egyetlen megvalosítás sem támogatja. A hoszt hitelesítése után a felhasználó hitelesítését is támogatja jelszó, ketkulcsos hitelesítés (RSA), valamint különbözo OTP módszerekkel (S/Key).
Az IPSec az itt felsoroltak közül az egyetlen olyan, mely a titkosítást hálózati rétegben végzi, csomagok titkosításával. A két végpont hitelesítése történhet megosztott kulcsokkal, tanusítványokkal, vagy one time password alkalmazásával is.
Egészen idáig arról volt szó, hogy milyen eszközeink vannak arra, hogy egy megbízhatatlan hálózaton érzékeny adatokat vigyünk át. A probléma ott kezdodik, hogy ezek az eszközök bizonyos szempontból túlzottan hatékonyak. Egy megfeleloen kódolt adatot nem lehet ugyanis belátható idon belül visszafejteni. Ez persze természetes, hiszen pont ez volt a célunk. Miért akarnánk akkor visszafordítani a folyamatot?
A válasz a határvédelemben rejlik. Minden szervezet igyekszik védeni a hálózati határait, hogy a rosszfiúkat kívül tartsa, ehhez viszont látnia és ellenoriznie kell, hogy mi megy keresztül a tuzfalon. A kódolt adat kulcs nélkül csak egy véletlen bitsorozatnak tunik, belelátni csak a kulcs segítségével lehet, a probléma viszont az, hogy az összes fenti protokollt úgy tervezték, hogy a kulcs csak a két végponton legyen meg, és ne szerezhesse meg senki középen (Man in the middle attack).
Ennek ellenére a feladat nem lehetetlen, bár a kliens vagy a szerver tisztában lesz azzal, hogy a tuzfal végzi a feladatát (tehát a tuzfal jelenléte nem lesz letagadható).
A továbbiakban elsosorban az SSL-re és az SSH-ra koncentrálunk, az IPSec-et elsosorban virtuális magánhálózatok kialakításához használják, így az egyik végpont általában amúgy is a határvédelmi eszköz.
Ahogy azt a protokollnál leírtam, a szerver hitelesíti magát a kliens felé egy hoszt kulccsal (hostkey). Ezt a hosztkulcsot a kliens aztán megjegyzi, és ezentúl az adott szervert ehhez a publikus kulcshoz hitelesíti.
A tuzfal feladata tehát az, hogy saját hosztkulcsát küldje a kliensnek, és kliensként viselkedjen a szerver felé, a forgalmat pedig a ketto között olyan módon közvetítse, hogy az a helyi Informatikai Biztonsági Szabályzatnak megfeleljen.
Amennyiben a kliens a tuzfal középre helyezése elott már megjegyezte a szerver kulcsát, úgy a kliensprogram jelezni fogja a hosztkulcs változását. Innen a kulcs ellenorzésével, majd elfogadásával tudunk továbblépni.
Ezt a képet annyiban lehet bonyolítani, hogy a kliensek felé a tuzfal célszervertol függo kulcsot küld, így a különbözo célcímekhez - a valós helyzethez hasonlóan - különbözo hosztkulcs tartozik, melyeknek privát felét valójában a tuzfal tárolja.
Miután a hoszt azonosítás megtörtént, az átvitt adatok már gond nélkül átvihetok, kivéve az kétkulcsos felhasználói authentikációt, ehelyett alkalmazhatunk más eros hitelesítést, például CryptoCard-ot, vagy felokosíthatjuk a tuzfalunkat olyan szintre, hogy képes legyen a felhasználók nevében tovább authentikálni.
Az SSL protokoll alkalmazásánál bonyolultabb a helyzet, mert az rendes tanusítványokat használ, nem pedig egyszeru publikus kulcsot.
A kliens a szerverrel való kommunikációja kezdetén megkapja a szerver tanusítványát, melyet a kliens ellenorzésnek vet alá. Ellenorzi, hogy
a tanusítvány alanya a megcímzett szerver-e
a tanusítvány megbízható-e a tanusítvány kiadója alapján
Ha bármelyik ellenorzés sikertelen, a böngészo megkérdezi a felhasználót, hogy ennek ellenére szeretné-e folytatni a kommunikációt.
Ha a tuzfal mindig a sajat tanusítványát küldi a kliensnek, akkor az ellenorzés mindig sikertelen lesz, hiszen a tuzfal certificate-je nem tartalmazza az eredetileg megcímzett hoszt nevét. Ez a probléma feloldható automatikus kulcs-generálással, olyan módon, hogy a beérkezo kéréskor generálunk olyan tanusítványt, ami a szerver címét tartalmazza.
Jelenleg kapható határvédelmi eszközök a protokollokat maximálisan egy szinten értelmezik, azaz nem képesek feldolgozni egy protokollban érkezo beágyazott alprotokollt (például SSL-ben HTTP vagy POP3). A Zorp moduláris szerkezete lehetové teszi az ilyen komplex protokollok értelmezését is.
A tuzfalak alapvetoen két osztályba sorolhatók:
melyek a forgalom ellenorzését csomag szinten végzik
melyek a forgalom ellenorzését kapcsolat szinten végzik.
Az elso csoportba tartoznak a csomagszuro routerek és az állapottartó csomagszurok. Tartalomellenorzést egyáltalán nem, vagy csak kismértékben végeznek.
A második csoportba tartoznak általában a proxy tuzfalak, melyek a protokollt alkalmazás szinten megvalósítva közvetítik a forgalmat a védett és a külso zóna között. Fontos különbség tuzfalak között, hogy az átmeno adatfolyamot milyen szinten értelmezi a proxy tuzfal. A muködéshez elegendo szint általában jóval alacsonyabb a valóban elvárhatónál.
A Zorp moduláris proxy tuzfal ez utóbbi csoportba tartozik, fejlesztésénél ügyeltünk arra, hogy minden protokollt a legmélyebben elemezzünk, a leheto legtöbb információt jutassuk az adminisztrátor kezébe, hogy aztán o az adatok alapján meghozhassa a döntését.
Egy tuzfal akkor jó, ha az adminisztrátor kezébe adjuk azokat az eszközöket, mely a helyi Informatikai Biztonsági Szabályzat betartatásához szükségesek. A Zorp lehetové teszi, hogy minden protokoll-eseményt befolyásolhasson az adminisztrátor, és saját döntést hozzon. A döntési pontokon meghívodik egy programozási nyelven megfogalmazott szubrutin, minden szóba jöheto
paraméterrel, majd a visszatérési érték befolyásolja a proxy muködését.
Az eseményekkel illetve azok lekezelésével egy betörés detektáló rendszer (intrusion detection system) is megvalósítható, hiszen a protokoll elemeiben mintát keresve megtalálhatjuk a számunkra kellemetlen próbálkozásokat. (Pl.: '../' szurése fájltölto parancsoknál az ún. dotdot bug kiszurésére).
Amellett, hogy a Zorp olyan proxykat tartalmaz, melyek mélyen és pontosan értelmezik az áthaladó protokollt, ezek a proxyk összekapcsolhatók, így egészen komplex protokoll együttesek is lekezelhetoek. Nem okoz problémát az SSL-be csomagolt alprotokoll feldolgozása, de a tervezoasztalon levo SSH proxy elkészültével lehetoségünk lesz az SSH-ban folyó beágyazott TCP
kapcsolatok (TCP forwarding) és az interaktív kapcsolat egyenkénti ellenorzésére is. (SSH-ban POP3, X és interaktív terminálkapcsolat).
A lenti példa lehetové teszi, hogy a kliens a tuzfalig titkosítás nélkül, utána SSL-el titkosítva érjen el egy, az interneten lévo, POP3S szervert, és mindezt transzparensen.
...
# POP3S cleartext -> TLS transzparens proxy
class MyPop3s(PsslProxy):
# beágyazott POP3 proxy definíciója
class MyPop3(Pop3Proxy):
# A beágyazott proxy konfigurációja
def config(self):
# felvesszük a default beállításokat
Pop3Proxy.config(self)
# engedjük az APOP-t
self.commands["APOP"] = (Pop3.POP3_CMD_ACCEPT)
# az SSL proxy beállításai
def config(self):
# szerver oldalon kérünk SSL-t (alapból nincs)
self.server_need_ssl = TRUE;
# a szervert keményen ellenőrizzük
self.verify_type = SSL_VERIFY_REQUIRED
# kérjük a beágyazni a fenti POP3 proxy-t
self.stack_proxy = self.MyPop3
# pop3s példány definíciója
def pop3s():
Service("pop3s", TransparentChainer(forced_port=995), MyPop3s)
Listener(SockAddrInet("10.0.0.254", 50110), "pop3s")