A hitelességvizsgálat (authentication) olyan módszer, amivel egy folyamat ellenőrizheti, hogy kommunikációs partnere valóban az-e, akinek lennie kell, nem pedig egy csaló. Egy távoli folyamat azonosságának ellenőrzése meglehetősen nehéz, egy rosszakaratú, aktív támadó jelenlétében és titkosításon alapuló komplex protokollokat igényel. Ebben a részben megvizsgálunk néhány olyan hitelességvizsgáló protokollt, amelyek a nem megbízható számítógépes hálózatokban használatosak.
Félreértésből néhányan keverik a hitelesség- és jogosultságvizsgálat fogalmát. A hitelességvizsgálat azzal foglalkozik, hogy valóban a megfelelő folyamattal történik-e a kommunikáció. A jogosultságvizsgálat pedig a folyamat hatáskörének eldöntésére vonatkozik. Például egy fájlszerverhez fordul egy ügyfélfolyamat, és azt kéri: „Én Scott folyamata vagyok, és le akarom törölni a cookbook.old fájlt.” A fájlszerver szempontjából két kérdés merül fel:
Ez tényleg Scott folyamata-e (hitelességvizsgálat)?
Scott letörölheti-e a cookbook.old fájlt (jogosultságvizsgálat)?
A kérést csak azután lehet teljesíteni, miután mindkét kérdésre egyértelműen igenlő a válasz. A hangsúly az első kérdésen van. Miután a szolgáltató tudja, kivel beszél, a jogosultságvizsgálathoz már csak meg kell nézni egy helyi táblázat megfelelő bejegyzését. Éppen ezért ebben a részben a hitelességvizsgálatra koncentrálunk.
A hitelességvizsgáló protokollok a következő általános modellt használják. Aliz azzal kezdi, hogy elküld egy üzenetet vagy Bobnak, vagy egy megbízható kulcselosztó központnak (Key Distribution Center, KDC). Feltesszük, hogy a központ mindig szavahihető. Ezután számos üzenetváltás történik mindkét irányban. Az elküldött üzeneteket Trudy elfoghatja, módosíthatja vagy visszajátszhatja, hogy becsapja Alizt és Bobot, vagy hogy egyszerűen csak megzavarja a munkájukat.
Mindazonáltal, amikor a protokoll tökéletes, Aliz biztos lehet, hogy Bobbal beszél, és Bob is biztos lehet, hogy Alizzal beszél. Ezenkívül, a protokollok többségében létrejön egy kettejük kapcsolatára jellemző titkos viszonykulcs (session key), amit ezután a párbeszédhez használnak. A gyakorlatban, hatékonysági okokból, minden adatforgalmat titkos kulcsú titkosítással kódolnak annak ellenére, hogy a nyilvános kulcsú titkosítás széles körben használatos magában a hitelességvizsgáló protokollban és a viszonykulcs létrehozásánál.
A véletlenszerűen választott friss viszonykulcs azért hasznos, mert használatával minimalizálni lehet a felhasználó saját titkos vagy nyilvános kulcsával kódolt adatforgalmat, ezáltal csökkentve a támadó által megkaparintható titkosított szöveget, és mert minimális lehet a kár, ha egy folyamat összeomlik, és a memóriamentés rossz kezekbe kerül. A viszony felépítése után minden visszamaradó kulcsot gondosan ki kell nullázni.
Első protokollunkhoz feltételezzük, hogy Aliznak és Bobnak már van egy osztott titkos kulcsa, KAB . (A protokollok formális leírásában Alizt A, Bobot pedig B helyettesíti.) A felek a megosztott kulcsot megbeszélhetik telefonon vagy személyesen, de semmiképpen sem a (nem megbízható) hálózaton.
Ez a protokoll is azt az alapötletet használja, amit számos más hitelességvizsgáló protokoll: az egyik résztvevő egy véletlen számot küld a másiknak, aki azt speciális módon transzformálja, majd az eredményt visszaküldi. Az ilyen típusú protokollokat kihívás-válasz (challenge-response) protokolloknak nevezzük. Ebben és az ezt követő hitelességvizsgáló protokollokban a következő jelölések érvényesek:
A, B Aliz és Bob azonosítója.
-k a kihívások, ahol az i index a kihívót azonosítja.
-k kulcsok, ahol i a tulajdonosra vonatkozik.
a viszonykulcs.
Az első osztott kulcson alapuló hitelességvizsgáló protokollunk üzenetváltásait a 8.32. ábra mutatja. Az első üzenetben Aliz elküldi azonosítóját, A-t Bobnak, mégpedig Bob által értelmezhető formában. Bob természetesen nem tudhatja, hogy az üzenet Aliztól vagy Trudytól jött-e, ezért kiválaszt egy nagy véletlen számot, -t, amit kihívásként visszaküld az állítólagos Aliznak a 2-es számú, kódolatlan üzenetben. Ezután Aliz a Bobbal közös titkos kulcs segítségével kódolja az üzenetet, majd a titkosított szöveget,
-t visszaküldi Bobnak a 3-as számú üzenetben. Amikor Bob megkapja ezt az üzenetet, már biztos lehet benne, hogy az Aliztól jött, hiszen Trudy nem ismeri
-t, így ő nem generálhatott ilyen üzenetet. Továbbá, mivel
véletlenszerűen lett kiválasztva egy nagy halmazból (mondjuk 128 bites számok közül), nagyon kicsi az esélye annak, hogy Trudy egy korábbi viszonyban már láthatta az
-t és az arra adott választ. Éppen ilyen valószínűtlen az is, hogy bármely kihívásra csak úgy ki tudná találni a helyes választ.
Ekkor Bob már biztos benne, hogy Alizzal beszél, de Aliz még nem biztos semmiben. Amit Aliz tud, az még nem biztosítja arról, hogy Trudy nem hallgatta le az 1-es üzenetet, és nem ő küldte vissza -t. Lehet, hogy Bob az éjszaka meghalt. Ahhoz, hogy megtudja, kivel beszél, Aliz választ egy nagy véletlen számot,
-t, és a kódolatlan 4-es üzenetben elküldi Bobnak. Ha Bob
-val válaszol, akkor Aliz már tudja, hogy Bobbal beszél. Ha ezek után szeretnének megbeszélni egy viszonykulcsot, akkor Aliz kitalál egyet, és elküldi Bobnak
-vel titkosítva.
A 8.32. ábra protokollja öt üzenetet tartalmaz. Nézzük meg, hogy egy kis fejtöréssel sikerül-e megspórolnunk ezek közül néhányat! A 8.33. ábra egy lehetséges megközelítést mutat. Itt Aliz nem vár Bobra, hanem rögtön kezdeményezi a kihívás-válasz protokollt. Hasonlóképp, Bob is rögtön elküldi a saját kihívását az Aliznak küldött válaszában. Ezzel az egész protokollt öt helyett három üzenetre lehet rövidíteni.
Vajon ez az új protokoll jobb-e, mint az eredeti? Egy szempontból igen: rövidebb. Sajnos azonban rosszabb is. Bizonyos körülmények között Trudy legyőzheti ezt a protokollt, a visszatükrözéses támadás (reflection attack) segítségével. Gyakorlatilag Trudy betörhet, ha lehetséges egyszerre több viszonyt létrehozni Bobbal. Ez lehet a helyzet például, ha Bob egy bank, amely kész több szimultán, a pénzkiadó automatáktól jövő hívás fogadására.
Trudy visszatükrözéses támadása a 8.34. ábrán látható. Először is Trudy Aliznak adja ki magát, és elküldi -t. Bob szokás szerint válaszol saját kihívásával,
-vel. Most Trudy tehetetlen. Mit csinálhatna? Nem tudja
-t.
Kezdeményezhet egy másik kapcsolatot a 3-as üzenettel, amiben elküldheti azt az -t mint kihívást, amit a 2-es üzenetben kapott. Bob gyanútlanul titkosít, és visszaküldi
-t a 4-es üzenetben. Ezzel Trudy megkapta a hiányzó információt, és be tudja fejezni az első kapcsolat felépítését, a másodikat pedig megszakítja. Bob meg van győződve róla, hogy Trudy Aliz, és mikor a bankszámla egyenlegét lekérdezi, szó nélkül megadja a választ. Nem kételkedik akkor sem, mikor arra kéri, hogy mindent utaljon át egy titkos svájci bankszámlára.
A történet tanulsága:
Egy korrekt hitelességvizsgáló protokoll készítése nehezebb, mint amilyennek látszik.
A következő négy általános szabály gyakran segít a tervezőknek a gyakori hibák kiküszöbölésében:
A kezdeményezőnek előbb kell igazolnia magát, mint a fogadónak. Ez magakadályozza Bobot abban, hogy értékes infirmációt adjon ki, mielőtt Trudy egyáltalán igazolná kilétét.
A kezdeményezőnek és a fogadónak különböző kulcsokat kell használni a hitelesítéshez még akkor is, ha ehhez két megosztott kulcs és
kell.
A kezdeményezőnek és a fogadónak különböző halmazokból kell választania a kihívást. Például a kezdeményezőnek páros, a fogadónak pedig páratlan számokat kelljen használnia.
A protokollnak ellenállónak kell lennie az olyan támadásoknak, melyek egy második, párhuzamos viszonyt használnak fel, és az egyik viszonyban megszerzett információt a másikban hasznosítják.
Elég, ha csak egy szabályt nem tartunk be, és a protokollunk máris sok esetben feltörhető lesz. Példánkban mind a négy szabályt megsértettük, ez pedig katasztrofális következményekkel járt.
Most pedig menjünk egy kicsit vissza és vegyük jobban szemügyre a 8.32. ábrát! Biztos, hogy a protokollt nem veszélyezteti a visszatükrözéses támadás? Nos, az attól függ. Erre a kérdésre elég körülményes választ adni. Trudynak azért sikerült visszatükrözéses támadással legyőzni a protokollunkat, mert meg tudott nyitni egy második viszonyt Bobbal, és rá bírta venni arra, hogy a saját kérdéseit válaszolja meg. Vajon mi történik akkor, ha Aliz sem egy gép előtt ülő ember, hanem egy általános célú számítógép, mely több viszonyt is tud létesíteni? Nézzük meg, mit tehet ilyenkor Trudy.
Trudy támadását a 8.35. ábra segítségével érthetjük meg. Aliz először közli személyazonosságát az 1-es üzenetben. Trudy ezt elfogja, új viszonyt kezd a 2-es üzenettel, azt állítván, hogy ő Bob. A 2. viszonyhoz tartozó üzeneteket sötét színnel jelöltük. Aliz a 3-as üzenetben így válaszol: „Azt mondod, te vagy Bob? Bizonyítsd be!” Itt Trudy megakad, hiszen nem tudja bizonyítani, hogy ő lenne Bob.
Mit tehet ilyenkor Trudy? Visszatér az első viszonyhoz, ahol neki kell kihívást küldenie, és elküldi a 3-as üzenetben kapott -t. Aliz készségesen válaszol erre az 5-ös üzenetben, ezzel megadja azt az információt, amire Trudynak a 2. viszonyban a 6-os üzenet elküldéséhez szüksége van. Ezen a ponton Trudy gyakorlatilag révbe ért, hiszen sikeresen megválaszolta Aliz kihívását a 2. viszonyban. Ekkor megszakíthatja az 1. viszonyt, a 2. viszony hátralévő részében pedig bármilyen régi számot elküldhet, és máris lesz egy hitelesített viszonya Alizzal.
Csakhogy Trudy még ennél is gonoszabb, és még nagyobb bajt akar keverni. Ahelyett, hogy elküldene egy régi számot, és ezzel befejezné a 2. viszonyt, megvárja, míg Aliz elküldi a 7-es üzenetet, vagyis az 1. viszonyhoz tartozó kihívását. Trudy természetesen megint nem tudja, hogyan válaszoljon, ezért ismét a visszatükrözéses támadást alkalmazza, és 8-as üzenetként az -t küldi vissza. Aliz minden további nélkül kódolja
-t a 9-es üzenetben. Trudy ekkor visszavált az 1. viszonyhoz, és a 10-es üzenetben elküldi Aliznak az általa kért számot, amit egyszerűen csak ki kell másolnia Aliz 9-es üzenetéből. Ezen a ponton Trudynak már két, teljesen hitelesített viszonya van Alizzal.
Ennek a támadásnak az eredménye némiképp eltér a 8.34. ábrán látott háromüzenetes protokoll támadásának eredményétől. Trudynak ezúttal két hitelesített összeköttetése lesz Alizzal, míg az előző példában egy hitelesített összeköttetése volt Bobbal. Itt is igaz az, hogy ha betartottuk volna az előbb tárgyalt általános szabályokat a hitelesítési protokollokra vonatkozóan, akkor ez a támadás kivédhető lett volna. Az ilyenfajta támadásokról és az ellenük való védekezés módjairól Bird és mások [1993] adnak részletes leírást. Írásukban azt is megmutatják, hogyan lehet szisztematikus úton megalkotni olyan protokollokat, melyek bizonyíthatóan helyesen működnek. Mindazonáltal még a legegyszerűbb ilyen protokoll is elég komplikált, ezért mi most egy másik protokollosztályt mutatunk be, mely szintén hatásos.
A Bird és mások [1993] által leírt új hitelességvizsgáló protokollt a 8.36. ábra mutatja be. A protokoll az IPsec tárgyalásánál látott HMAC-hez hasonló kódot használ. Aliz első üzenetében elküldi Bobnak az egyszer használatos véletlen számot. Bob erre saját véletlen számával,
-vel válaszol, amit egy HMAC-kóddal együtt küld vissza. Ehhez előbb létrehoz egy adatszerkezetet, amely Aliz véletlen számából, a saját véletlen számából, kettejük személyazonosságaiból, és a közös titkos kulcsból,
-ből áll. Ezt az adatszerkezetet aztán a HMAC-be hash-eli, például az SHA-1 használatával. Amikor Aliz megkapja a 2-es üzenetet, ismerni fogja
-t (hiszen azt ő választotta), a nyílt szövegként érkezett
-t, a két személyazonosságot, és a
titkos kulcsot is, hiszen azt mindig is ismerte. Mindebből ő is kiszámíthatja a HMAC-t. Ha az megegyezik az üzenetben található HMAC-vel, akkor biztos lehet benne, hogy Bobbal beszél, hiszen Trudy nem ismeri
-t, így azt sem tudhatja, milyen HMAC-t kellene küldenie. Aliz ezután egy olyan HMAC-vel válaszol Bobnak, ami csak a két véletlen számot tartalmazza.
Feltörheti-e vajon Trudy ezt a protokollt? Nem, mivel egyik felet sem tudja rávenni arra, hogy egy általa választott értéket kódoljon vagy hash-eljen, mint ahogy azt a 8.34. és a 8.35. ábránál tette. Itt mindkét HMAC-kód a küldő fél által választott értéket tartalmazza, azt a választást pedig Trudy nem tudja befolyásolni.
Ezt az ötletet nemcsak HMAC-kódok használatával lehet megvalósítani. Gyakran használják azt a megoldást is, hogy az elemek sorozatára nem HMAC-kódokat számolnak ki, hanem az egyes elemeket sorban egymás után kódolják a titkosított blokkok láncolásának módszerével.
Eddig feltételeztük, hogy Aliznak és Bobnak van egy osztott titkos kulcsa. Mi van, ha még sincs? Hogyan beszélhetnek meg egyet? Egy lehetséges módszer az lenne, ha Aliz felhívná Bobot telefonon, és megmondaná neki a sajátját, de ő valószínűleg azt mondaná: „Honnan tudjam, hogy tényleg Aliz vagy és nem Trudy?” Vagy megbeszélhetnének egy találkozót, ahova mindketten elviszik az útlevelüket, a jogosítványukat, és három közismert hitelkártyát, de mivel elfoglalt emberek, valószínűleg hónapokba telne, mire mindkettejüknek megfelelő időpontot találnának. Hihetetlenül hangzik, de szerencsére létezik egy megoldás, mely segítségével vadidegenek is megbeszélhetnek egy osztott titkos kulcsot fényes nappal, annak ellenére, hogy Trudy minden üzenetet gondosan rögzít.
A protokollnak, amely lehetővé teszi, hogy idegenek is megbeszélhessenek egy osztott titkos kulcsot, Diffie–Hellman-kulcscsere (Diffie–Hellman key exchange) a neve [Diffie és Hellman, 1976], és a következőképpen működik. Aliznak és Bobnak meg kell egyeznie két nagy számban, n-ben és g-ben, ahol n és is prímszám, és néhány követelmény teljesül g-re is. Ezek a számok nyilvánosak lehetnek, azaz bármelyikük választhat egy n-et és g-t, majd nyíltan elküldheti a másiknak. Ezután Aliz kisorsol egy nagy (mondjuk 1024 bites) számot, x-et, és ezt titokban tartja. Hasonlóképpen Bob is kisorsol egy nagy titkos számot, y-t.
Aliz kezdeményezi a kulcscsere-protokollt azzal, hogy elküldi Bobnak egy üzenetben -et (lásd 8.37. ábra). Bob válaszol Aliznak, és elküldi
-et. Aliz a kapott számot az x-edik hatványra emeli, így megkapja
-et. Bob hasonló módon előállítja
-et. A modulusos aritmetika szabályai szerint mindkét kifejezés megegyezik
-nel. Íme Aliz és Bob ezzel megbeszélték megosztott kulcsukat,
-et.
Természetesen Trudy mindkét üzenetet látta. Ismeri tehát g-t és n-et az 1. üzenetből. Ha ki tudná számolni x-et és y-t, akkor meghatározhatná a titkos kulcsot. A probléma az, hogy -ből nem tudja meghatározni x-et. Nem ismert olyan használható algoritmus, amely nagy prímszám modulo diszkrét logaritmusát állítja elő.
A fenti példa konkretizálása érdekében az és
(gyakorlatban használhatatlan) számokat használjuk. Aliz
-at sorsol, míg Bob
-et. Ezeket mindketten titokban tartják. Aliz üzenete Bobnak (47, 3, 28), mert
. Bob üzenete Aliznak (17). Aliz kiszámolja
-et. Bob kiszámolja
-et. Aliz és Bob függetlenül megállapította, hogy a titkos kulcs most 4. Trudynak meg kell oldani a
egyenletet, ami kimerítő kereséssel valósítható meg kis számokra, de nem megy, ha a számok mind százbites nagyságrendűek. Minden eddig ismert algoritmus egyszerűen túl sok időt venne igénybe, még egy nagy teljesítményű párhuzamos szuperszámítógéppel is.
A Diffie–Hellman-kulcscsere algoritmus eleganciájának ellenére felmerül egy probléma: honnan tudja Bob, amikor megkapja a (47, 3, 28) számhármast, hogy ez tényleg Aliztól származik-e, és nem Trudytól. Nincs rá mód, hogy megbizonyosodjon efelől. Sajnos Trudy kihasználhatja ezt a tényt, hogy megtévessze mind Alizt, mind Bobot, amint azt a 8.38. ábra mutatja. Miközben Aliz és Bob külön-külön kisorsolja x-et és y-t, addig Trudy is kiválasztja saját véletlen számát, z-t. Aliz elküldi az 1-es üzenetet, amit Bobnak szán. Trudy ezt elfogja, és egy 2-es üzenetet küld Bobnak, a helyes g és n számokkal (amelyek amúgy is nyilvánosak), de x helyett saját véletlen számával, z-vel. Ezenkívül a 3-as üzenetben visszaüzen Aliznak. Később Bob elküldi a 4-es üzenetet Aliznak, amit Trudy ismét elfog.
Ekkor mindenki alkalmazza a modulos aritmetikát. Aliz titkos kulcsként -et számol, és Trudy is ezt kapja (Alizzal történő üzenetváltásokhoz). Bob eredménye
, és Trudy is ezt kapja (Bobbal való üzenetváltásokhoz). Aliz azt hiszi, hogy Bobbal beszél, és létrehoz egy viszonykulcsot (Trudyval). Bob is így tesz. Trudy elfog és tárol, vagy tetszés szerint módosít minden üzenet, amit Aliz a titkosított viszonyon küld, majd (ha akarja) továbbküldi Bobnak. A másik irányban is hasonló a helyzet. Trudy minden üzenetet lát, és tetszés szerint módosíthat, miközben Aliz és Bob mindketten abban az illúzióban vannak, hogy egy biztonságos csatorna van köztük. Ezért ez a fajta támadás közbeékelődéses támadás (man-in-the-middle attack) néven ismert. Másik neve élőlánc-támadás (bucket brigade attack), mert némileg emlékeztet a hajdani önkéntes tűzoltókra, akik élő láncot alkottak a tűzoltókocsitól a tűzig, és úgy adogatták egymásnak a vödröket.
Egy idegennel megosztott titok megbeszélése kis híján sikerült már, de tulajdonképpen mégsem. Ha jól belegondolunk, nem is biztos, hogy érdemes. Ezzel a módszerrel, ha n partnerrel tartjuk a kapcsolatot, n kulcsot kell tárolnunk. Egy népszerű embernek a kulcsok karbantartása komoly terhet jelenthet, főleg, ha minden kulcsot különálló műanyag chipkártyán kell tárolnia.
Egy másik megközelítés, ha bevezetünk egy megbízható kulcselosztó központot (Key Distribution Center, KDC). Ebben a modellben minden felhasználónak csak egy a KDC-vel megosztott kulcsa van. A hitelességvizsgálat és a kulcskarbantartás így a KDC-n keresztül történik. A legegyszerűbb, két felhasználót és egy megbízható KDC-t tartalmazó hitelességvizsgáló protokoll látható a 8.39. ábrán.
A protokoll alapötlete egyszerű: Aliz kisorsol egy viszonykulcsot, -t, és megüzeni a KDC-nek, hogy
-t használva Bobbal szeretne beszélni. Ez az üzenet titkosítva van azzal a
titkos kulccsal, amit Aliz (csak) a kulcselosztó központtal oszt meg. A KDC visszakódolja az üzenetet, és kiveszi belőle Bob azonosítóját és a viszonykulcsot. Ezután létrehoz egy új üzenetet, ami tartalmazza Aliz azonosítóját és a viszonykulcsot, majd elküldi Bobnak. A titkosítás a Bob és a KDC között megosztott
kulccsal történik. Bob az üzenetet visszakódolva megtudja a viszonykulcsot, és azt, hogy Aliz szeretne beszélni vele.
A hitelességvizsgálat itt ingyen történik. A KDC tudja, hogy az 1-es üzenet biztosan Aliztól származik, hiszen azt más nem tudta volna titkosítani Aliz titkos kulcsával. Hasonlóan, Bob tudja, hogy a 2-es üzenet biztosan a KDC-től jött, amiben megbízik, hiszen más nem tudja az ő titkos kulcsát.
Sajnos ennek a protokollnak van egy súlyos hibája. Trudy pénzszűkében van, így keres valami legális Aliz által igényelt szolgáltatást, kecsegtető ajánlatot tesz, és megkapja a munkát. A munka végeztével Trudy udvariasan megkéri Alizt, hogy banki átutalással fizessen. Aliz tehát megbeszél egy viszonykulcsot bankárával, Bobbal. Ezután egy üzenetben arra kéri Bobot, hogy utaljon át pénzt Trudy számlájára.
Eközben Trudy visszatér régi énjéhez, és a hálózatot kémleli. Felveszi mind a 8.39. ábrán látható 2-es üzenetet, mind az azt követő pénzátutalási kérelmet. Később visszajátssza mindkettőt Bobnak. Bob megkapja őket, és azt hiszi: „Aliz biztosan megint felbérelte Trudyt. Ezek szerint érti a dolgát.” Bob ismét átutalja a pénzösszeget Aliz számlájáról Trudyéra. Valamikor az 50-edik üzenetpáros vétele környékén Bob kirohan irodájából, hogy megkeresse Trudyt, és felajánljon neki egy nagyobb hitelt, hogy fejleszthesse a nyilvánvalóan sikeres vállalkozását. Ezt a problémát nevezik visszajátszásos támadásnak (replay attack).
Jó pár megoldás van a visszajátszásos támadás kivédésére. Egyik lehetőség, hogy minden üzenetet időbélyeggel látunk el. Ha valaki egy idejemúlt üzenetet kap, eldobhatja azt. Ezzel a megközelítéssel az a gond, hogy az órák sohasem teljesen szinkronizáltak egy hálózatban, ezért az időbélyeg egy bizonyos időtartamig érvényes kell legyen. Trudy ebben az időtartamban még sikeresen visszajátszhatja az üzenetet.
A második megoldás az egyszer használatos, egyedi véletlen üzenetszám beillesztése minden üzenetbe, amit általában egyszer használatos véletlen számnak (nonce) neveznek. Így minden résztvevőnek tárolnia kell az elhasznált üzenetszámokat, és kidobni a régi üzenetszámmal érkező leveleket. Az üzenetszámokat azonban örökre meg kell őrizni, nehogy Trudy egy 5 éves üzenetet próbáljon visszajátszani. Továbbá, ha egy gép összeomlik, és elveszti az üzenetszámok listáját, ismét sebezhetővé válik a visszajátszásos támadással szemben. Az időbélyegek és az üzenetszámok kombinálhatók úgy, hogy csak korlátos ideig kelljen tárolni az üzenetszámokat, természetesen azonban így sokkal komplikáltabb lesz a protokoll.
A hitelességvizsgálat kifinomultabb megközelítése a többutas kihívás-válasz protokoll, amelynek közismert változata a Needham–Schroeder-féle hitelességvizsgáló protokoll [Needham–Schroeder, 1978], ennek egy változata látható a 8.40. ábrán.
A protokoll első lépésében Aliz megüzeni a kulcselosztó központnak, hogy Bobbal szeretne beszélni. Ez az üzenet tartalmaz egy nagy véletlen számot, -t, mint egyszer elküldött, egyedi üzenetszámot. A KDC visszaküldi a 2-es üzenetben Aliz véletlen számát,
-t, egy viszonykulcsot és egy jegyet, amit elküldhet Bobnak.
azért szükséges, hogy Aliz biztosítva legyen afelől, hogy az üzenet friss, nem pedig egy visszajátszás. Bob azonosítója szintén mellékelve van arra az esetre, ha Trudynak az az ötlete támadna, hogy kicseréli az 1-es üzenetben B-t a sajátjára azért, hogy a KDC a 2-es üzenetben a jegyet
-vel titkosítsa, és nem
-vel. A
-vel titkosított jegyet a titkosított üzenet tartalmazza, nehogy Trudy az Alizhoz vezető visszaúton kicserélhesse valamivel.
Aliz ezután elküldi a jegyet Bobnak, egy új véletlen szám, kíséretében, amit
-sel titkosít. A 4-es üzenetben Bob visszaküldi
-et, hogy biztosítsa Alizt arról, hogy az igazi Bobbal beszél.
visszaküldése nem lenne jó, hiszen azt Trudy egyszerűen kilophatja a 3-as üzenetből.
A 4-es üzenet kézhezvétele után Aliz biztos benne, hogy Bobbal beszél, valamint, hogy eddig nem történhetett visszajátszás. Hiszen pár ezredmásodperccel ezelőtt generálta -t. Az 5-ös üzenet célja, hogy Bob is meggyőződjön róla, hogy tényleg Alizzal beszél, és itt sem történt visszajátszás. Azzal, hogy mindkét fél generált egy kihívást, és válaszolt is egyre, a visszajátszásos támadás lehetősége kizárható.
Annak ellenére, hogy ez a protokoll elég megbízhatónak látszik, mégis van egy gyenge pontja. Ha Trudy egyszer megszerez egy régi viszonykulcsot kódolatlan formában, akkor a 3-as üzenet visszajátszásával egy viszonyt kezdeményezhet Bobbal, és elhitetheti vele, hogy ő Aliz [Denning és Sacco, 1981]. Ezúttal kifoszthatja Aliz bankszámláját anélkül, hogy törvényesen valaha is dolgozott volna neki.
Needham és Schroeder később publikáltak egy protokollt, amely megoldja ezt a problémát [Needham és Schroeder, 1987]. Ugyanannak a folyóiratnak ugyanabban a számában Otway és Rees [1987] szintén ismertetett egy rövidebb protokollt, ami szintén kiküszöböli ezt a hibát. A 8.41. ábrán az Otway–Rees-protokoll egy kismértékben módosított változata látható.
Az Otway–Rees-protokollban Aliz először előállít egy véletlen számpárost, R-et, ami egy általános azonosító, és -t, amit Aliz majd kihívásként használ Bob felé. Mikor Bob megkapja ezt az üzenetet, létrehoz egy új üzenetet Aliz üzenetének titkosított részéből, és egy hasonlót saját magától. A
-val és
-vel titkosított mindkét rész azonosítja Alizt és Bobot, tartalmazza az általános azonosítót, és tartalmaz egy kihívást.
A KDC ellenőrzi, hogy R mindkét részben ugyanaz-e. Lehet, hogy nem, hiszen Trudy megváltoztathatta R-et az 1-es üzenetben, vagy kicserélhette a 2-es üzenet egy részét. Amennyiben az R-ek megegyeznek, a KDC elhiszi, hogy a Bob által üzent kérés érvényes. Ezután generál egy viszonykulcsot, és két példányban titkosítja azt, egyszer Aliznak, egyszer pedig Bobnak. Mindegyik üzenet tartalmazza a fogadó véletlen számát biztosítékul arra nézve, hogy nem Trudy hozta létre azokat. Ezek után mind Aliz, mind Bob birtokában van ugyanannak a viszonykulcsnak, és elkezdhetnek kommunikálni. Mikor először cserélnek adatot tartalmazó üzenetet, mindketten láthatják, hogy a másiknak is birtokában van tökéletesen azonos másolata, ezzel a hitelességvizsgálat befejeződött.
Sok valódi rendszerben (köztük a Windows 2000-ben is) használják a Kerberos hitelességvizsgáló protokollt, mely a Needham–Schroeder egyik variációján alapul. Egy sokfejű kutyaszörnyetegről kapta nevét, amely a görög mitológiában Hadész bejáratát őrizte (feltételezhetően a nemkívánatosak távoltartása végett). A Kerberost az M.I.T.-n fejlesztették ki azért, hogy a munkaállomások felhasználói biztonságosan hozzáférhessenek a hálózati erőforrásokhoz. Legfontosabb különbsége a Needham–Schroeder-hez képest az a feltételezés, hogy az órák meglehetősen jól szinkronizáltak. A protokoll sok változtatáson ment keresztül. A V5 változat az, amelyet az iparban széles körben használnak és az RFC 4120 definiálja. Az előző változatot, a V4-et nyugdíjazták, miután komoly hiányosságokat találtak benne [Yu és mások, 2004]. A V5 tulajdonképpen a V4 feljavítása egy sor kisebb protokollváltoztatással és néhány továbbfejlesztett lehetőséggel, például hogy a továbbiakban nem kapcsol át a ma már elavult DES-re. További információért lásd Neuman és Ts’o [1994] munkáját.
A Kerberos három további szervert is igénybe vesz az Aliz (egy kliens-munkaállomás) mellett:
1. hitelességvizsgáló szervert (Authentication Server, AS): ellenőrzi a felhasználót belépéskor,
2. jegyadó szervert (Ticket-Granting Server, TGS): „személyazonosságot igazoló jegyeket” ad,
3. Bobot, a szervert: elvégzi az Aliz által kért munkát.
A hitelességvizsgáló szerver (AS) a KDC-hez hasonlóan, minden felhasználóhoz fenntart egy titkos jelszót. A jegyadó (TGS) feladata, hogy olyan jegyeket adjon, amelyek biztosítják a valódi szervereket, hogy a jegytulajdonos tényleg az, akinek mondja magát.
Egy viszony kezdeményezéséhez Aliz odaül egy tetszőleges nyilvános munkaállomáshoz és begépeli nevét. A munkaállomás nyílt szövegként kódolatlanul elküldi Aliz nevét és a TGS nevét az AS-hez (a 8.42. ábrán az 1-es üzenetet). Válaszul kap egy viszonykulcsot és egy jegyet, , a TGS számára. A viszonykulcsot Aliz titkos kulcsával titkosítja úgy, hogy csak Aliz tudja megfejteni. A munkaállomás csak akkor kérdezi meg Aliz jelszavát, amikor a 2-es üzenet megérkezik – előbb nem. A jelszót használja ezután a
előállításához annak érdekében, hogy a 2-es üzenetet megfejtse és megkapja a viszonykulcsot
Ezután a munkaállomás felülírja Aliz jelszavát, hogy az legfeljebb néhány ezredmásodpercig legyen a munkaállomásban. Ha Trudy megpróbál belépni Aliz helyett, az általa begépelt jelszó nem lesz jó, és ezt a munkaállomás észreveszi, hiszen a 2-es üzenet szerkezetileg helytelen lesz.
Aliz, miután belépett, megmondhatja a munkaállomásnak, hogy Bobbal, a fájlszerverrel szeretne kapcsolatot teremteni. A munkaállomás ezután a TGS-nek küldött 3-as üzenetben kér egy Bobbal való viszonyában használható jegyet. A kulcselem itt a , ami a TGS titkos kulcsával van titkosítva, és arra szolgál, hogy bizonyítsa, hogy a küldő tényleg Aliz. A TGS azzal válaszol, hogy létrehoz Aliznak egy Bobbal használható viszonykulcsot,
-t. Ennek kétféle változata megy vissza. Az első csak
-sel van titkosítva, hogy Aliz el tudja olvasni. A második egy másik jegy, amely Bob kulcsával,
-vel van titkosítva, így Bob el tudja olvasni.
Trudy lemásolhatja a 3-as üzenetet, és megpróbálhatja újra használni, de ezt meghiúsítja az üzenethez kapcsolódó titkosított t időbélyeg. Trudy nem tudja lecserélni az időbélyeget egy frissebbel, mert nem ismeri -t, a viszonykulcsot, amelyet Aliz a TGS-sel való beszédhez használ. Még ha Trudy gyorsan visszajátssza is a 3-as üzenetet, akkor is csak egy újabb másolatát szerezhetné meg a 4-es üzenetnek, amit már elsőre sem volt képes visszakódolni, és másodszorra sem fog tudni.
Most már Aliz elküldheti -t Bobnak, hogy létrehozzon egy viszonyt. Ez az üzenetváltás is időbélyeget tartalmaz. A válasz biztosítja Alizt afelől, hogy tényleg Bobbal és nem Trudyval beszél.
Az üzenetváltások sorozatának lezajlása után Aliz védelme alatt kommunikálhat Bobbal. Ha később úgy dönt, hogy egy másik szerverrel, Carollal is beszélnie kell, egyszerűen megismétli a 3-as üzenetet azzal a különbséggel, hogy ezúttal B helyett C-t küld. A TGS azonnal válaszol, megküldve a
-vel titkosított jegyet, amit Aliz elküldhet Carolnak, akit ez biztosít arról, hogy az Aliztól jött.
Ennek a sok munkának az az értelme, hogy most már Aliz minden hálózaton elérhető szerverhez biztonságosan hozzákapcsolódhat, és a jelszavát sohasem kell a hálózaton keresztül küldenie. Sőt annak csak néhány ezredmásodpercre kell a saját munkaállomásában lennie. Vegyük észre azonban, hogy minden szerver saját maga végzi a jogosultságvizsgálatot. Mikor Aliz megmutatja a jegyét Bobnak, ez Bobot csupán arról győzi meg, hogy azt ki küldte. Pontosabban szólva, hogy Aliz mit tehet, azt Bob dönti el.
Minthogy a Kerberos fejlesztői nem várták, hogy az egész világ egyetlen hitelességvizsgáló szerverben bízzon meg, ezért gondoskodtak róla, hogy több birodalom (realm) létezhessen, külön-külön saját AS-sel és TGS-sel. Aliz úgy szerezhet jegyet egy távoli szerverhez, ha saját TGS-étől kér egy jegyet, amit a távoli TGS is elfogad. Ha a távoli TGS-t számon tartja a helyi TGS (hasonlóan a helyi szerverekhez), akkor a helyi TGS ad Aliznak egy jegyet, amely a távoli TGS-re érvényes. Ezután elintézheti ügyét a távoli birodalomban is, például szerezhet jegyet ottani szerverekhez. Vegyük észre azonban, hogy ahhoz, hogy két különböző birodalombeli fél együttműködhessen, mindkettőnek meg kell bíznia a másik TGS-ében. Különben nem tudnak együttműködni.
A kölcsönös hitelességvizsgálat megoldható nyilvános kulcsú titkosítás használatával is. Induljunk ki abból, hogy Aliznak szüksége van Bob nyilvános kulcsára. Ha adott egy PKI, és annak van egy olyan könyvtárszolgáltatása, amely a nyilvános kulcsokról ad ki tanúsítványokat, akkor Aliz elkérheti Bob tanúsítványát. Ezt a kérést jelöltük a 8.43. ábrán az 1-es üzenettel. A 2-es üzenetben lévő válasz egy X.509 tanúsítvány, amely tartalmazza Bob nyilvános kulcsát. Miután ellenőrizte az aláírást, Aliz egy újabb üzenetben elküldi Bobnak az azonosítóját és egy egyszer használatos véletlen számot (nonce).
Amikor Bob megkapja ezt az üzenetet, még fogalma sincs arról, hogy az vajon Aliztól vagy Trudytól jött-e, de belemegy a játékba, és elkéri a könyvtárszolgáltatástól Aliz nyilvános kulcsát (4-es üzenet), amit hamarosan meg is kap (5-ös üzenet). Ezután elküldi Aliznak a 6-os üzenetet, mely tartalmazza az Aliz-féle -t, saját véletlen számát,
-t, és a javasolt viszonykulcsot,
-et.
Mikor Aliz megkapja a 6-os üzenetet, visszakódolja azt saját egyéni kulcsának segítségével. Megtalálja benne az -t, ami jóleső melegséggel tölti el: az üzenet csakis Bobtól jöhetett, mivel Trudy nem találhatja ki az
-t. Továbbá biztosan friss, hiszen épp az előbb küldte el az
-t Bobnak. Aliz tehát a 7-es üzenet elküldésével beleegyezik a viszonyba. Amikor Bob meglátja az imént generált viszonykulccsal titkosított
-t, tudni fogja, hogy Aliz megkapta a 6-os üzenetet és ellenőrizte az
-t. Bob most egy boldog ember.
Hogyan próbálhatja Trudy megfúrni ezt a protokollt? Összeeszkábálhat egy 3-as üzenetet, és cselesen ráveheti Bobot arra, hogy próbára tegye Alizt, de Aliz ekkor egy olyan -t fog kapni, amit nem ő küldött, és nem folytatja tovább. Trudy nem tud hamis 7-es üzenetet visszaküldeni Bobnak, mert nem ismeri sem
-t, sem
-et, és nem is tudja megállapítani ezeket Aliz egyéni kulcsa nélkül. Nincs szerencséje.