Nyilvános kulcsú titkosítás

Hálózat biztonság Legyen Alice és Bob két ember aki “biztonságosan” szeretne kommunikálni. Hálózati nyelven Alice és Bob lehet: Két router Két host Két e-mail applikáció Alice és Bob “bizonytalan” környezetben kommunikálnak, ahol a betolakodók elolvashatják és módosíthatják egymásnak küldött üzeneteiket A biztonságos kommunikáció jellemzői: Titoktartás: csak Alice és Bob értheti az üzenet tartalmát Azonisítás (hitelesség): mindenki az-e akinek vallja magát? Sértetlenség (épség)

Hálózat biztonság Internetes hálózat-biztonság Tényleg léteznek ilyen “betolakodók” amelyek lehallgatják a hálózaton közlekedõ üzeneteket? A válasz: IGEN. A "szaglászó" (packet sniffer) olyan program, mely a hálózat egy egységén fut és lehetővé teszi a hálózaton áthaladó valamennyi adatcsomag elolvasását. Az Ethernet LAN környezet esetén ez azt jelenti, hogy a szaglászó megkapja mind azokat a frame-eket ameyleket bármely LAN- host küldi vagy kapja.

Hálózat biztonság Internetes hálózat-biztonság Bármely internethez csatlakozó egység adatgrammokat küld a hálózatba. Ezek a küldő IP címét is tartalmazzák, amit viszont a küldő nek lehetősége van megváltoztatni. Ezt a technikát IP spoofing-nak nevezzük.

Kriptográfia Kriptográfiai technikák segítségével a küldő kódolhatja az üzenetet úgy, hogy a betolakodók ne értsék a lehallgatott adatokat.  Viszont a címzett képes kell legyen ezt megfejteni, hogy megértse. Szimmetrikus (titkos) kulcsú titkosítás elve a P nyílt szövegből egy C titkosított szöveget állítunk elő egy E titkosító függvénnyel és a kulccsal az alábbi módon: hasonlóan, a titkosított szövegből, a kulcs és egy D megfejtő függvénnyel az eredeti nyílt szöveget megkapjuk, mint: Megjegyzés:

Kriptográfia Nyilvános kulcsú titkosítás elve Mindkét fél (Alice és Bob) két kulccsal rendelkezik: nyilvános (K): mindenki ismeri privát (K*): csak a tulajdonos ismeri A kódoló algoritmus mindenki rendelkezésére áll Ahhoz, hogy Alice titkosított üzenetet küldhessen Bobnak, Bob nyilvános kulcsát kell ismernie => ennek segítségével kódolja az üzenetet=>az így titkosított szöveget csak a Bob titkos kulcsával lehet megfejteni

Kriptográfia Nyilvános kulcsú titkosítás elve Problémák: A betolakodók nem értik ugyan az Alice által küldött üzenetet, viszont módosíthatják, hozzáfûzhetnek hiszen ismerik Bob nyilvános kulcsát és a kódoló algoritmust is. A betolakodók Alice nevében üzenetet küldhetnek Bobnak Ezek megoldásáról szó lesz a továbbiakban. A leg ismertebb nyilvános kulcsú kódoló algoritmus az RSA

Hitelesítés Gyakran előfordul, hogy a hálózat elemeinek (pl. routerek vagy kliens/szerver folyamatok) azonosítani kell egymást. Hálózaton át ez csak üzenetek segítségével lehetséges, egy authentication(hitelesítési) protocol részeként. Általában egy hitelesítési protokoll bármely más protokoll futtatása előtt fut. (pl.  Megbízható adatátvitel protokoll vagy email protocol).  A hitelesítési protokoll előbb megállapítja a felek identitását (egymás számára) és csak utána mûködhetnek együtt.

Hitelesítés A továbbiakban a hitelesítési protokoll különböző verzióit követjük végig. Tételezzük fel, hogy Alice azonosulni akar Bob előtt. Ap1.0 Alice egyszerûen az “Alice vagyok” üzenetet küldi Bobnak Bob nincs honnan tudja, hogy azt tényleg Alice küldi Ap2.0 Ha Alice mindig ugyanarról a hálózati címről (IP címről) kommunikál, akkor Bob ezt leellenőrizheti az üzenet adatgrammjában IP spoofing történhet=> az így kapott adatgrammokat az első router elutasíthatja, ha úgy konfigurálják de ez nem biztos

Hitelesítés Ap3.0 Legyen egy jelszó amit csak Alice és Bob ismer és ennek alapján azonosítsa Bob Alicet Packet sniffing történhet => a betolakodók megtudhatják a jelszót Ap3.1 Alice szimmetrikus kulcsú titkosítással kódolja a jelszót, így a betolakodók nem tudják meg => Alice elküldi Bobnak az üzenetet (“Alice vagyok”) és a kódolt jelszót => Bob dekódolja Packet sniffing történhet: bár a betolakodók nem tudhatják meg a jelszót, viszont megtudják kódját és a továbbiakban ezt elküldhetik Bobnak az Alice nevében

Hitelesítés Ap4.0 Alice minden alkalommal más-más jelszót használ. Erre több mód is van: Előre megegyeznek Bobbal egy jelszó-sorozatban Megegyeznek egy jelszó-generáló algoritmusban A 3.0 verzióval csak az volt a gond, hogy Bob nem tudott különbséget tenni az erededeti azonosítás és a playback között.

Hitelesítés Ap4.0 Hogyan bizonyíthatja be Alice, hogy “élőben” küldte a jelszót? Alice elküldi Bobnak az “Alice vagyok ” üzenetet Bob elküld Alicenek egy olyan számot, amelyet nagyon hosszú idő alatt csak egyszer használ (“nonce”) Ezt Alice a mindkettőjük által ismert titkos kulcs segítségével kódolja és visszaküldi Bobnak Bob dekódolja a visszakapott (kódolt) üzenetet és ha ugyanazt kapja mint amit elküldött, akkor Alice “élő”.

Hitelesítés Ap5.0 Használhatunk-e nyilvános kulcsú kriptográfiát az azonosítás megoldására? Hogyan? Alice elküldi az "Alice vagyok" üzenetet Bobnak Bob kiválaszt egy “nonce” számot (R) és elküldi Alicenek. Alice alkalmazza a dekódoló algoritmust saját titkos kulcsával ( ) a kapott számra: majd az eredményt elküldi Bobnak. Bob alkalmazza Alice nyilvános kulcsát és kódoló algoritmusát ( ) a kapott értékre: Ha ez az érték megegyezik az eredetileg küldött számmal (R), akkor azonosítja Alicet.

Hitelesítés Ap5.0 annyira biztonságos, mint Ap4.0? Tekintsük a következő példákat (legyen Trudy a betolakodó): I. példa

Hitelesítés Ap5.0 annyira biztonságos, mint Ap4.0? I. Példa, magyarázat: Trudy elküldi Bobnak az “Alice vagyok ” üzenetet Bob elküldi a kiválasztott “nonce” számot Alicenek, viszont Trudy elfogja ezt a számot, majd saját dekódoló algoritmusát és titkos kulcsát és alkalmazza rá: és a kapott értéket küldi Bobnak. Bob elküldi Alicenek az üzenetet, amelyben Alice nyilvános kulcsát ( )kéri. Trudy elfogja ezt az üzenetet is és saját nyilvános kulcsát ( ) küldi el.  Bob kiszámolja a értéket és azonosítja Alicet…

Hitelesítés Ap5.0 annyira biztonságos, mint Ap4.0? II. Példa

Sértetlenség Előfordulhat, hogy Alice és Bob nem élőben kommunikálnak, hanem levélben. Kérdés: Hogyan lehet biztos Bob, hogy egy levél valóban Alicetól érkezett és út közben nem módosult? Megoldás: Alice digitális aláírása alapján mely a következő tulajdonságokkal rendelkezik: lehetővé teszi az aláíró személyének egyértelmű meghatározását egyértelműen megállapítható az aláírt elektronikus irat az aláírást követő módosulása

Sértetlenség Digitális aláírás megvalósítása I. Alice saját titkos kulcsát alkalmazza az üzenetre, majd elküldi Bobnak Bob Alice dekódoló algoritmusát és nyilvános kulcsát alkalmazza a kapott üzenetre és visszakapja az eredeti szöveget, hiszen

Sértetlenség Digitális aláírás megvalósítása II. Elég csak az üzenet egy részét kódolni mivel ez is biztosítja az integritást Alice a H hash-függvénnyel meghatározza az üzenetkivonatot (message digest) Megjegyzés: A H hash-függvény ugyanahhoz az üzenethez mindig ugyanazt a kivonatot rendeli, de két különböző üzenethez sosem rendeli ugyanazt

Sértetlenség Digitális aláírás megvalósítása II. helyett elég kiszámolni a értéket és ezt elküldeni Bobnak az üzenettel együtt Bob Alice nyilvános kulcsával dekódolja a kapott digitális aláírást és kiszámolja a H(m) értéket. Ha a kettő megegyezik akkor a Bobhoz ért üzenet sértetlen és hiteles.

Kulcs kiosztás és igazolás A hitelesítés keretén belül az utolsú példa arra hívta fel a figyelmet, hogy a nyilvános kulcs nem biztos, hogy elér a címzetthez hiszen a betolakodók hamisíthatják. Hogyan kerülhetjük ezt el? Szükség van egy megbízható közvetítőre. A szimmetrikus kriptográfia közvetítője a Key Distribution Center (KDC) A nyilvános kulcsú kriptográfia a Certification Authority (CA)-t használja

Kulcs kiosztás és igazolás - KDC Hogyan használható a KDC? Minden KDC-felhasználó rendelkezik egy-egy titkos kulccsal, amelyet a KDC is ismer. Pl.

Kulcs kiosztás és igazolás - CA A CA célja egy nyilvános kulcs egy entitással való összekötése. Hitelesség-vizsgálat: egy entitás valóban az, akinek vallja magát? => identitás ellenőrzés (azonosítás) Olyan tanúsítvány (certificate) létrehozása, amely tartalmazza a nyilvános kulcsot és a kulcs tulajdonosára vonatkozó azonosító információt A tanúsítványt CA digitálisan aláírja

Kulcs kiosztás és igazolás - CA Miért szükséges a CA?

Kulcs kiosztás és igazolás - CA Hogyan használja Bob a tanúsítványt? Az üzenettel együtt Bob elküldi a tanúsítványt is Alicenak Alice a CA nyilvános kulcsával ellenőrzi, hogy a tanúsítvány a Bob tanúsítványa-e Megjegyzés: feltételezzük hogy a CA publikus kulcsát mindenki ismeri és hogy megbízható körülmények között tették ismertté

Internetes biztonság Az Internet Protokoll Verem (IP Stack) felső 4 rétegét biztonsággal láthatjuk el. Miért nem elég csak a hálózai réteget biztonságba helyezni? A hálózati szint biztonsága nem vonja maga után a felhasználói szintû biztonságot (egy IP cím alapján nem azonosíthatjuk a felhasználót) Az internetet által nyújtott szolgáltatásokat könnyebb a protokoll verem felső rétegein fejleszteni, így a biztonsági szolgáltatásokat is application transport network link physical

Biztonságos e-mail Megjegyzés: ebben a fejezetben az alkalamazási réteg biztonságáról lesz szó, az e-mail egy sajátos alkalmazás réteg protokoll (case of study). Ha egy specifikus applikáció réteg protokollnak biztoságot nyújtunk, akkor az összes applikáció amely ezt a réteget használja, biztonságot fog élvezni Az e-mail esetén fontos a biztonság mindhárom részét betartani (titoktartás, hitelesség, sértetlenség) => gondoljunk arra, hogy Alice és Bob e-maileznek

Biztonságos e-mail Törődjünk előbb a titoktartással A szimmetrikus kriptográfia használata esetén a közös titkos kulcs megállapítása nehézkés A nyilvános kulcsú kriptográfia nagyon lassú lenne A megoldás: a két kriptográfia kombinált használata Alice kiválaszt egy szimmetrikus kulcsot és kódolja az üzenetet, a szimmetrikus kulcsot pedig kódolja Bob nyilvános kulcsával és mindkettőt elküldi Bobnak Bob saját titkos kulcsával megfejti a titkos szimmetrikus kulcsot, majd a szimmetrikus kulccsal megfejti az üzenetet

Biztonságos e-mail Titoktartás a két kriptográfia kombinált használata

Biztonságos e-mail A következőkben olyan rendszert tervezünk, amely hitelességet és sértetlenséget nyújt, a titoktartás most nem érdekel Alice a H hash-függvénnyel megkapja az üzenetkivonatot, majd ezt saját titkos kulcsával kódolja és a sima üzenettel együtt elküldi Bobnak Bob Alice nyilvános kulcsával megfejti az elektronikus aláírást és összehasonlítja az üzenetkivonattal,amit ő is megkapott a H függvénnyel=> ha a kettő megegyezik, akkor tudja hogy Alicetól kapta a levelet és út közben nem módosult

Biztonságos e-mail Most tervezzünk olyan rendszert, amely titoktartást, hitelességet és sértetlenséget nyújt => kombináljuk az előzőleg megtervezett két rendszert

Biztonságos e-mail PGP (Pretty Good Privacy) A leg elterjedtebb e-mail titkosító módszer, standarddá vált Szerkezete megegyezik a leg utóbbi ábrán látható szerkezettel Hogyan mûködik? Amikor installáljuk, létrehoz egy titkos és egy nyilvános kulcsot A nyilvános kulcs feladható egy web-oldalra vagy nyilvános kulcs-szerverre, tanúsítvány is készíthető hozzá A titkos kulcs jelszóval védett, minden hozzáférés csak jelszóval lehetséges Lehetőséget ad kódolni és digitálisan aláírni az üzeneteket

Elektronikus kereskedelem Nem más, mint az interneten át történő vásárlás A ’90es években sok terv készült az e-kereskedelem megvalósítására, ezek közül azonban csak keveset implemetáltak A mai internetes tranzakciók nagyrésze az SSL-t (Secure Socket Layer) használja, de az SET (Secure Electronic Transactions ) komoly konkurenciát jelent neki a jövőre nézve Az e-kereskedelem 3 “főszereplője”: Kliens Eladó Az eladó “bankja”

Elektronikus kereskedelem Legyen Bob a vevő,aki az Alice site-járól akar vásárolni => ki is tölti az “ûrlapot” Milyen meglepetések érhetik Bobot, ha a biztonságról nem gondoskodunk? Pl.: A betolakodók leolvassák a Bob hitelkártyájáról szóló információt (titoktartás sértés) A Trudy oldalán megjelenhet Alice cégének reklámja, aki viszont elzsebeli a pénzt és Bob nem jut a megrendelt termékhez(hitelesség sértés) Az SSL egy protokoll réteg, amely a hálózati (Network layer) és az alkalmazási rétegek (Application layer) között van. Mindenféle forgalom titkosítására használható.

Elektronikus kereskedelem Mit nyújt az SSL? SSL-szerverazonosítás: a kliens meggyőzödhet egy szerver azonosságáról. Egy SSL-felhatalmazott böngésző megbízható CA-listát tart fenn a nyilvános kulcsokkal együtt. Ha a Web-böngésző “üzletelni” akar egy SSL-felhatalmazott szerverrel, akkor kéri tanúsítványát és nyilvános kulcsát Titoktartás: a böngésző és a szerver között küldött adatok titkosítása, sőt a betolakodókat is leleplezi SSL-kliensazonosítás: a szerver lekérheti a kliens CA-tanúsítványát, hogy azonosítsa (opcionális)

Elektronikus kereskedelem SET Kimondottan a bankkártyás fizetések Internetes tranzakciójának biztonságos lebonyolítására tervezett protokoll. 1997-ben a MasterCard, a VISA, az IBM és más informatikai vállalatok együttesen fejlesztették ki Fő jelemvonásai: Fizetéssel kapcsolatos üzenetek titkosításának céljából tervezték, így nem alkalmas szöveg vagy képek titkosítására A 3 “főszereplő” között közlekedő üzeneteket mind kódolja, midhárom CA-tanusítvánnyal kell rendelkezzen A kliens hitelkártya-száma úgy jut az eladó bankjához, hogy az eladó nem is látja. Ez megelőzi azt, hogy a tisztességtelen eladók ellopják a kártyaszámot

Hálózati réteg biztonsága: IPsec Mit jelent a titoktartás, hálózati szinten? Az összes IP adatgramm titkosítása, amely a hálózaton áthalad Mit jelent az azonosítás, hálózati szinten? Ha egy adatgramm bizonyos IP címmel érkezik, meg kell bizonyosodni arról, hogy valóban az az IP címû host generálta => IP spoofing megelőzése

Hálózati réteg biztonsága: IPsec Az IPsec protokoll-készletnek két fő protokollja van, minden host ezek egyikét használja: Authentication Header (AH) protokoll: hitelesítés, integritás Encapsulation Security Payload (ESP) protokoll: integritás, titkosítás Mindkét protokoll (AH, ESP) esetén még az adatgramm elküldése előtt a két host között kézszorítás történik megteremtődik a logikai kapcsolat (hálózati réteg szintjén), a Security Agreement (SA)

Hálózati réteg biztonsága: IPsec Az AH protokollt alkalmazo adatgramm Az AH fejlécének mezői: Next Header: az adatszegmens típusát adja meg Security Parameter Index (SPI): 32-bites érték, amely hozzájárul az SA-kapcsolat azonosításához.

Hálózati réteg biztonsága: IPsec Az AH fejlécének mezői: Sequence Number: 32-bites érték, az adatgramm sorszáma Authentication Data: változó hosszúságú mező, digitális aláírást tartalmaz a csomaghoz Az üzenetkivonat az eredeti IP adatgrammból származik, a küldő hostot azonosítja és sértetlenséget biztosít. A digitális aláírás algoritmusát az SA adja meg, ez lehet DES, MD5 vagy SHA.

Hálózati réteg biztonsága: IPsec Az ESP protokollt alkalmazó adatgramm ESP Trailer: a Next Header mezőt is tartalmazza, így azt is kódoljuk az adatokkal együtt => a betolakodó nem tudja meghatározni a használt szállítási protokoll típusát