Kerberos

Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2020. március 21-én felülvizsgált verziótól ; az ellenőrzéshez 21 szerkesztés szükséges .

A Kerberos /kɛərbərəs/ egy hálózati hitelesítési protokoll , amely mechanizmust kínál a kliens és a szerver kölcsönös hitelesítésére, mielőtt kapcsolatot létesítenek közöttük. A Kerberos megbízható, harmadik féltől származó hitelesítési szolgáltatásként végzi el a hitelesítést egy megosztott kriptográfiai titok használatával, feltéve, hogy a nem biztonságos hálózaton áthaladó csomagokat a támadók elfoghatják, módosíthatják és felhasználhatják. A Kerberos szimmetrikus kulcskriptográfiára épül, és kulcselosztó központot igényel. A Kerberos-bővítmények bizonyos hitelesítési lépésekben nyilvános kulcsú kriptográfia használatát is lehetővé teszik.

Létrehozási előzmények

A Kerberos protokoll első változatát 1983-ban hozták létre a Massachusetts Institute of Technology -ban (MIT) az Athena projekt részeként.. A projekt fő célja egy terv kidolgozása volt a számítógépek MIT oktatási folyamatban való bevezetésére és a kapcsolódó szoftverekre. A projekt oktatási jellegű volt, de a végeredmény több olyan szoftverterméket is tartalmazott, amelyeket ma is széles körben használnak (például az X Window System ). Ez a protokoll a 4-es verzió óta nyilvánosan elérhető.

Alapfogalmak

Vázoljuk fel a Kerberos protokoll alapkoncepcióját. Tegyük fel, hogy két ember ismeri ugyanazt a titkot, csak ők ketten. Akkor bármelyikük könnyen megbizonyosodhat arról, hogy párjával van dolga. Ehhez csak azt kell ellenőriznie, hogy beszélgetőpartnere ismeri-e a megosztott titkot.

Példa.

1. tétel: Megállapodás a jelszóról. Hadd kommunikáljon Alice Bobbal. Ebben az esetben Bob csak akkor használja fel az információt, ha biztos abban, hogy az információt Alice-től kapta. A hamisítás elkerülése érdekében megegyeztek egymás között egy jelszóban, amelyet csak ők ketten tudnak. Üzenet fogadásakor Bob a levélből arra következtethet, hogy beszélgetőpartnere tudja-e a jelszót. Ha Bob beszélgetőpartnere ismeri a jelszót, akkor vitatható, hogy a beszélgetőpartnere Alice.

2. tétel. Jelszóátviteli probléma fellépése. Most határozzuk meg, hogyan mutassuk meg Alice-nek és Bobnak a jelszó ismeretét. Természetesen a jelszót egyszerűen beleírhatja az e-mail törzsébe. Például: „Szia Bob. A jelszavunk. Ha Bob és Alice biztosak lennének benne, hogy senki sem olvassa el a leveleiket, akkor ezt a módszert lehetne használni. De sajnos a leveleket olyan hálózaton továbbítják, amelyben más felhasználók dolgoznak, köztük van egy kíváncsi Éva. Eve azt a feladatot tűzte ki maga elé, hogy kiderítse a csak Bob és Alice által ismert jelszót, amellyel üzenetet váltanak egymással. Most már teljesen világos, hogy nem adhatja meg a jelszót egyszerűen a levél törzsében. Ez azt jelenti, hogy nem beszélhet nyíltan a jelszóról, ugyanakkor tudatnia kell a beszélgetőpartnerrel, hogy ismeri a jelszót.

3. pont A jelszóátvitel problémájának megoldása. A Kerberos protokoll titkos kulcsú titkosítással oldja meg a jelszóátvitel problémáját. A kommunikációs munkamenet résztvevői ahelyett, hogy jelszót mondanának egymásnak, kriptográfiai kulcsot cserélnek, amelynek ismerete megerősíti a beszélgetőpartner kilétét. De ahhoz, hogy egy ilyen technológia lehetséges legyen, a megosztott kulcsnak szimmetrikusnak kell lennie , vagyis a kulcsnak biztosítania kell az üzenet titkosítását és visszafejtését.

4. pont A jelszócsere problémája. A fent leírthoz hasonló egyszerű protokollok használatakor van egy fontos probléma. Bob és Alice esetében meg kell értened, hogyan állapodnak meg egy titkos kulcsban, hogy megfeleljenek egymásnak. Természetesen az emberek találkozhatnak és megegyezhetnek, de a gépek is részt vesznek a hálózati tárgyalásokon. Ha Alice alatt kliensprogramot értünk, Bob pedig egy hálózati kiszolgálón lévő szolgáltatást, akkor semmilyen módon nem találkozhatnak. A probléma az, hogy amikor egy kliensnek több szerverre kell üzenetet küldenie, ebben az esetben minden szerverhez külön kulcsot kell beszereznie. És akkor a szervernek annyi titkos kulcsra lesz szüksége, ahány kliense van. Az, hogy ilyen sok kulcsot kell tárolni minden számítógépen, kockázatot jelent az egész biztonsági rendszerre nézve.

5. pont A jelszavak cseréjének problémájának megoldása. E problémák megoldására az Athena projekt egy speciális protokollt fejlesztett ki - a Kerberost. Az ókori görög mitológia analógiájára ezt a protokollt a háromfejű kutyáról nevezték el, amely megvédte a Hádész - Cerberus , pontosabban - Cerberus királyságából való kilépést. A Cerberus három feje a protokollban a biztonságos kommunikáció három résztvevőjének felel meg: egy kliensnek, egy szervernek és egy megbízható közvetítőnek közöttük. A közvetítő szerepét itt a Key Distribution Center, a KDC tölti be.

Key Distribution Center KDC (vagy TGS - jegy- vagy engedélyszerver)

A Key Distribution Center (KDC) egy olyan szolgáltatás, amely fizikailag biztonságos kiszolgálón fut. A Központ adatbázist vezet az összes hálózati kliens fiókjáról. Az egyes előfizetőkre vonatkozó információkkal együtt a kulcselosztó központ adatbázisa tárol egy kriptográfiai kulcsot, amelyet csak ez az előfizető és a központ szolgáltatás ismer. Ez a kulcs a kliens és a központ összekapcsolására szolgál.

Klienstől szerverig KDC-n keresztül

Ha az ügyfél kapcsolatba kíván lépni a szerverrel, üzenetet küld a kulcselosztó központnak. A Központ minden munkamenet-résztvevőnek elküldi a munkamenetkulcs rövid ideig érvényes másolatát. E kulcsok célja a kliens és a szerver hitelesítése. A kiszolgálónak küldött munkamenetkulcs másolatát a kiszolgáló hosszú távú kulcsával, a kliensnek küldött pedig az ügyfél hosszú távú kulcsával titkosítják. Elméletileg a megbízható közvetítő funkcióinak ellátásához elegendő, ha egy kulcselosztó központ közvetlenül küldi el a munkamenet kulcsait a biztonsági előfizetőknek. A gyakorlatban azonban rendkívül nehéz egy ilyen rendszert megvalósítani. Ezért a gyakorlatban más jelszókezelési sémát használnak, ami sokkal hatékonyabbá teszi a Kerberos protokollt.

Menetjegyek

A kiszolgálóhoz csatlakozni kívánó ügyfél kérésére a KDC szolgáltatás a munkamenetkulcs mindkét példányát elküldi az ügyfélnek. Az ügyfélnek szánt üzenet egy, az ügyfél és a KDC között megosztott hosszú távú kulccsal van titkosítva, és a kiszolgáló munkamenetkulcsa az ügyfélre vonatkozó információkkal együtt egy munkamenetjegynek nevezett adatblokkba van beágyazva. A teljes munkamenetjegyet ezután egy hosszú távú kulccsal titkosítják, amelyet csak a KDC szolgáltatás és ez a szerver ismer. Ezt követően a titkosított munkamenet-kulcsot hordozó jegy feldolgozásáért minden felelősség a klienst terheli, akinek el kell juttatnia azt a szerverhez. A KDC válasz vételekor a kliens kibontja belőle a jegyet és a munkamenetkulcs másolatát, amelyet biztonságos tárhelyen helyez el (nem lemezen, hanem RAM -ban van ). Amikor kapcsolatba kell lépnie egy szerverrel, a kliens üzenetet küld neki, amely egy jegyből áll, amely továbbra is a szerver hosszú távú kulcsával van titkosítva, és egy saját hitelesítőjéből, amelyet a munkamenet kulccsal titkosítanak. Ez a hitelesítő adat a hitelesítővel együtt alkotja azt a hitelesítő adatot, amely alapján a szerver meghatározza az ügyfél "azonosságát". A szerver, miután megkapta a kliens "azonosító kártyáját", mindenekelőtt annak titkos kulcsát használva dekódolja a munkamenet jegyet, és kinyeri belőle a munkamenet kulcsát, amivel visszafejti a kliens hitelesítőt. Ha minden jól megy, a rendszer arra a következtetésre jut, hogy az ügyfélazonosítót egy megbízható közvetítő, vagyis a KDC szolgáltatás adta ki. A kliens megkövetelheti a szervertől kölcsönös hitelesítés végrehajtását. Ebben az esetben a szerver a munkamenetkulcs másolatát felhasználva titkosítja a kliens hitelesítőjének időbélyegét, és elküldi azt a kliensnek, mint saját hitelesítőjét. A munkamenet hitelesítő adatok használatának egyik előnye, hogy a kiszolgálónak nem kell munkamenetkulcsokat tárolnia az ügyfelekkel való kommunikációhoz. A kliens "hitelesítési adatok gyorsítótárában" tárolódnak, amely minden alkalommal továbbítja a jegyet a szervernek, amikor kapcsolatba akar lépni vele. A szerver a maga részéről, miután megkapta a jegyet a klienstől, dekódolja azt és kibontja a munkamenet kulcsát. Ha a kulcsra már nincs szükség, a szerver egyszerűen törölheti azt a memóriájából. Ennek a módszernek van egy másik előnye is: a kliensnek nem kell felvennie a kapcsolatot a KDC-vel minden egyes munkamenet előtt egy adott szerverrel. A munkamenet hitelesítő adatai újra felhasználhatók. Ellopásuk esetén a jegy lejárati dátuma kerül beállításra, amit a KDC magában az adatstruktúrában feltüntet. Ezt az időt a tartomány-specifikus Kerberos-házirend határozza meg. A jegyek érvényességi ideje jellemzően nem haladja meg a nyolc órát, vagyis egy munkamenet normál időtartamát a hálózatban. Amikor a felhasználó kijelentkezik, a hitelesítő adatok gyorsítótára alaphelyzetbe áll, és az összes munkamenet hitelesítő adata a munkamenetkulcsokkal együtt megsemmisül.

Protokoll evolúció

Korai verziók

Az MIT azért fejlesztette ki a Kerberost, hogy biztosítsa az Athena projekt által biztosított hálózati szolgáltatásokat. A jegyzőkönyv nevét a görög mitológiai szereplőről, Kerberoszról (vagy Cerberusról ) kapta, akit a görög mitológia a szörnyű, háromfejű Hádész őrkutyaként ismer. A protokollnak több változata is létezik. A Kerberos korai verzióit (1–3) az MIT belsőleg hozta létre, és tesztelési célokra használták. Ezek a megvalósítások jelentős korlátokat tartalmaztak, és csak új ötletek feltárására és a fejlesztés során felmerülő problémák azonosítására voltak hasznosak.

Steve Miller és Clifford Neuman , a Kerberos 4-es verziójának fő tervezői (amely a DES titkosítási algoritmust használta 56 bites kulcsokkal), 1989-ben adták ki ezt a verziót, bár akkor még elsősorban ezt tervezték.az Athena projektben.

Kerberos 4

A Kerberos 4 először 1989. január 24- én jelent meg . Ez volt az első, az MIT-n kívül terjesztett verzió, amely arra készült, hogy több gyártó beépítse operációs rendszerébe. Ezenkívül más nagy elosztott rendszerprojektek (például Andrew File System ) a Kerberos 4 ötleteit használták hitelesítési rendszereikhez.

A Kerberos 4-é váló alapjait az Athena whitepaper [1] írta le, a végső verziót pedig az MIT által közzétett referencia-implementáció forráskódja szilárdította meg.

A titkosított szoftverek exportjára vonatkozó amerikai kormányzati korlátozások miatt azonban a Kerberos 4 nem terjeszthető az Egyesült Államokon kívül. Mivel a Kerberos 4 a DES algoritmust használta a titkosításhoz , az Egyesült Államokon kívüli szervezetek nem használhatták legálisan a szoftvert. Válaszul az MIT fejlesztőcsapata elkészítette a Kerberos 4 egy speciális verzióját, amelyből kizárt minden titkosítással kapcsolatos kódot. Ezek az intézkedések lehetővé tették az exportkorlátozás megkerülését.

Később Errol Young , az ausztrál Bond Egyetem munkatársa hozzáadta a DES saját megvalósítását ehhez a kiadáshoz. "E-Bones"-nak (a "titkosított csontoknak" [2] rövidítése ) hívták, és szabadon terjeszthető volt az Egyesült Államokon kívül.

2006-ban bejelentették a Kerberos 4 támogatását [3] .

Kerberos 5

Az előző verzió biztonsági problémáinak leküzdése érdekében John Kohl és Clifford Neuman kidolgozta a protokoll 5-ös verzióját, amely 1993-ban jelent meg RFC 1510 -ben . Idővel, 2005-ben, az IETF Kerberos munkacsoportja kezdett foglalkozni a specifikációval. Az általuk közzétett dokumentumok a következők:

2006 júniusában mutatták be az RFC 4556 -ot, amely az 5-ös verzió PKINIT nevű kiterjesztését írja le ( nyilvános  k ey c kriptográfia a Kerberos kezdeti hitelesítéséhez ). Ez az RFC leírja, hogyan kell az aszimmetrikus titkosítást használni a kliens hitelesítési szakaszban .

A következő évben (2007) az MIT megalakította a Kerberos Konzorciumot a további fejlődés elősegítése érdekében.

Felhasználás és terjesztés

A Kerberos implementáció terjesztése a BSD jogokhoz hasonlóan szerzői jogok alatt történik.

Jelenleg sok operációs rendszer támogatja ezt a protokollt, többek között:

Hogyan működik

Kerberos 4

A Kerberos 4 nagyrészt a Needham-Schroeder protokollon alapul , de két jelentős változtatással.

Ennek eredményeként a Kerberos 4 protokoll két logikai összetevőt tartalmaz:

Ezeket az összetevőket általában egyetlen programként szállítják, amely egy kulcselosztó központon fut (KDC – a Kerberost használó felhasználók és szolgáltatások bejelentkezési/jelszavainak adatbázisát tartalmazza).

A hitelesítési szerver egy funkciót lát el: fogadja a hitelesítést kérő kliens nevét tartalmazó kérést, és visszaküld neki egy titkosított jegyet a jegy megszerzéséhez (TGT). A felhasználó ezután ezt a jegyet használhatja további jegyek kérésére más szolgáltatásokhoz. A legtöbb Kerberos implementációban a TGT élettartama 8-10 óra. Ezt követően a kliensnek újra le kell kérnie a hitelesítési szervertől.

A kulcselosztó központnak küldött első üzenet egy kérés a hitelesítési kiszolgálóhoz, más néven AS_REQ. Ezt az üzenetet egyértelmű szöveggel küldjük el, és tartalmazza az ügyfél azonosítóját, az ügyfél időbélyegét és a jegykiadó szerver (TGS) azonosítóját.

Amikor a kulcselosztó központ AS_REQ üzenetet kap, ellenőrzi, hogy létezik-e az a kliens, amelytől a kérés érkezett, és az időbélyegzője közel van-e a központ helyi idejéhez (általában ± 5 perc). Ez az ellenőrzés nem a visszajátszások elleni védelemre szolgál (az üzenet szöveges formában kerül elküldésre), hanem az időzítés ellenőrzésére. Ha az ellenőrzések közül legalább az egyik sikertelen, hibaüzenetet küld a kliensnek, és a rendszer nem hitelesíti.

Ha sikeres, a hitelesítési kiszolgáló egy véletlenszerű munkamenet-kulcsot generál, amely meg lesz osztva az ügyfél és a jegy- vagy engedélyezési kiszolgáló között (ez a kulcs védi az egyéb szolgáltatások jövőbeli jegykérelmeit). A Kulcselosztó Központ 2 másolatot készít a munkamenetkulcsról: egyet az ügyfélnek, egyet pedig a jegykiadó szervernek.

A kulcselosztó központ ezután egy hitelesítési szerver üzenettel (AS_REP) válaszol az ügyfélnek, amely az ügyfél hosszú távú kulcsával van titkosítva. Ez az üzenet tartalmazza a TGS-kulccsal titkosított TGT-t, az ügyfél munkamenet-kulcsának másolatát, a jegy élettartamát és a TGS-azonosítót (a TGT tartalmazza: a TGS munkamenet-kulcsának másolatát, az ügyfél-azonosítót, a jegy élettartamát, Key Distribution Center (KDC) időbélyegzője, IP-cím kliens).

Amikor a felhasználó hozzá kíván férni a szolgáltatáshoz, egy üzenetet készít a TGS_REQ számára, amely 3 részből áll: a szolgáltatás azonosítója, a korábban kapott TGT másolata és a hitelesítő (a hitelesítő egy időbélyegből áll, amelyet a szolgáltatótól kapott munkamenet kulccsal titkosítanak. hitelesítési szerver, és az ismétlődések elleni védelemre szolgál).

Amikor egy ügyféltől jegykérést kap, a KDC új munkamenetkulcsot generál az ügyfél/szolgáltatás interakcióhoz. Ezután válaszüzenetet (TGS_REP) küld a hitelesítési szervertől kapott munkamenetkulccsal titkosítva. Ez az üzenet tartalmazza az új munkamenetkulcsot, a hosszú távú szolgáltatási kulccsal titkosított szolgáltatási jegyet, a szolgáltatásazonosítót és a jegy élettartamát (tartalmazza az új munkamenetkulcs másolatát, az ügyfél-azonosítót, a jegy élettartamát, a kulcselosztó központ helyi idejét, az ügyfél IP-címét ).

Az utolsó lépés, a szolgáltatási jegy alkalmazáskiszolgálóra küldése részleteit a Kerberos 4 nem szabványosítja, így megvalósítása teljes mértékben alkalmazásfüggő.

Kerberos 5

A Kerberos 5 a negyedik verzió fejlesztése, tartalmazza az összes korábbi funkciót, és számos bővítményt tartalmaz. A megvalósítás szempontjából azonban a Kerberos 5 egy teljesen új protokoll.

Az ötödik verzió megjelenésének fő oka a bővítés lehetetlensége volt. Idővel a Kerberos 4-ben használt DES elleni brute-force támadás aktuálissá vált, de az üzenetekben használt mezők fix méretűek voltak, és nem lehetett erősebb titkosítási algoritmust használni.

A probléma megoldására egy olyan bővíthető protokoll létrehozását határozták el, amely ASN.1 technológián alapuló különféle platformokon használható. Ez lehetővé tette a különböző típusú titkosítások használatát a tranzakciókban. Ennek köszönhetően megvalósult a kompatibilitás az előző verzióval. Ezenkívül a KDC-nek lehetősége van kiválasztani a résztvevő felek által támogatott legbiztonságosabb titkosítási protokollt.

Ezenkívül az eredeti Kerberos 4 protokollra szótári felsorolás vonatkozik. Ez a sérülékenység azzal a ténnyel kapcsolatos, hogy a KDC kérésre titkosított TGT-t ad ki bármely ügyfélnek. A probléma fontosságát az is hangsúlyozza, hogy a felhasználók általában egyszerű jelszavakat választanak.

A támadás megnehezítése érdekében a Kerberos 5 bevezette az előzetes hitelesítést. Ebben a szakaszban a KDC megköveteli a felhasználótól, hogy igazolja személyazonosságát, mielőtt jegyet kaphat.

A KDC házirend felelős az előzetes hitelesítésért, ha szükséges, akkor a felhasználó az első kéréskor KRB_ERROR üzenetet kap a hitelesítési szerver felé. Ez az üzenet felszólítja a klienst, hogy küldjön AS_REQ kérést a hitelesítési adataival a hitelesítés érdekében. Ha a KDC nem ismeri fel őket, akkor a felhasználó újabb KRB_ERROR üzenetet kap, amely hibát jelez, és nem ad ki TGT-t.

Formai leírás A hitelesítésben és a kulcscsere protokollokban használt kriptográfiai jelölések
Alice ( Alice ), a foglalkozás kezdeményezőjének azonosítói
Bob ( Bob ) azonosítója, amely oldalról a munkamenet létrejön
Trent ( Trent ), egy megbízható közvetítő fél azonosítója
Alice, Bob és Trent nyilvános kulcsai
Alice, Bob és Trent titkos kulcsai
Adatok titkosítása Alice kulcsával vagy Alice és Trent közös kulcsával
Adatok titkosítása Bob kulcsával vagy Bob és Trent közös kulcsával
Adattitkosítás Alice, Bob titkos kulcsaival (digitális aláírás)
Munkamenet sorszáma (az ismétléses támadások elkerülése érdekében)
Véletlenszerű munkamenetkulcs a szimmetrikus adattitkosításhoz
Adatok titkosítása ideiglenes munkamenet kulccsal
Alice és Bob időbélyegeket adott hozzá az üzenetekhez
Véletlen számok ( nonce ), amelyeket Alice és Bob választott ki

A protokoll csak szimmetrikus titkosítást használ, és feltételezi, hogy minden levelező (Alice és Bob) megoszt egy titkos kulcsot egy megbízható harmadik féllel (Trent).

Alice elküldi az igazolványát és Bobot a megbízható félnek (Trent):

Trent két üzenetet generál. Az első tartalmazza az időbélyeget , a kulcs élettartamát , Alice és Bob új munkamenetkulcsát , valamint Bob azonosítóját . Ez az üzenet Alice és Trent megosztott kulcsával titkosítva van. A második üzenet ugyanazt tartalmazza, kivéve az azonosítót - azt Alice azonosítójával helyettesítették . Maga az üzenet Trent és Bob megosztott kulcsával van titkosítva:

Alice létrehoz egy üzenetet a saját azonosítójából és egy időbélyegből , majd titkosítja az üzenetet a munkamenet kulccsal , és elküldi Bobnak a Trent második üzenetével együtt:

A saját hitelesítés érdekében Bob egy megosztott munkamenetkulccsal titkosítja a módosított időbélyeget, és elküldi Alice-nek:

Fontos feltételezés, hogy a protokoll összes résztvevőjének órája szinkronban van. A gyakorlatban azonban a szinkronizálást több perces pontossággal alkalmazzák, az átviteli előzményeket (az ismétlés észlelése érdekében) egy ideig tárolva.

Részletes leírás

A Kerberos 5 jelenleg a következőképpen működik:

Bejelentkezés:

  1. A felhasználó beír egy felhasználónevet és jelszót az ügyfélgépen.
  2. A kliens gép egyirányú funkciót (általában hash-t) hajt végre a jelszóban, és az eredmény a kliens/felhasználó titkos kulcsa lesz.

Ügyfél hitelesítés:

  1. A kliens kérelmet (AS_REQ) küld a CA-nak a hitelesítési hitelesítési adatok beszerzésére, majd a TGS-szervernek való átadására (később a hitelesítési adatok beszerzésére használja őket anélkül, hogy további kéréseket kellene kérnie a felhasználó privát kulcsának használatához).
    • Az ügyfélazonosító, az időbélyegző és a szerverazonosító.
  2. Ha a KDC házirend előhitelesítést igényel, akkor a felhasználó KRB_ERROR üzenetet kap, amelyre válaszul egy második kérést küld, de hitelesítési adatokkal.
  3. A CA ellenőrzi, hogy van-e ilyen ügyfél az adatbázisban. Ha igen, a CA visszaküld egy üzenetet (AS_REP), amely tartalmazza:
    • Az ügyfél munkamenet-kulcsa vagy TGS, a TGS-azonosító és a jegy élettartama , az ügyfél privát kulcsával titkosítva .
    • A TGS titkos kulccsal titkosított TGT (amely tartalmazza az ügyfél-azonosítót és a hálózati címet, a KDC időbélyegét, a jegy érvényességi időszakát és az ügyfél-munkamenet kulcsát vagy TGS-ét).

Ha nem, akkor az ügyfél új üzenetet kap, amely jelzi, hogy hiba történt.

  1. Az üzenet kézhezvételekor a kliens visszafejti annak részét, hogy megszerezze az ügyfél munkamenetkulcsát vagy TGS-ét. Ez a munkamenetkulcs a TGS-kiszolgálóval való további cserére szolgál. (Fontos: Az ügyfél nem tudja visszafejteni a TGT-t, mert az a TGS titkos kulccsal van titkosítva) Ezen a ponton a felhasználónak elegendő hitelesítő adata van a TGS-be való bejelentkezéshez.

Ügyfél engedélyezése a TGS-ben:

  1. A szolgáltatás igényléséhez az ügyfél egy kérést generál a TGS-re (TGS_REQ), amely a következő adatokat tartalmazza:
    • A TGT korábban kapott és szervizazonosítót.
    • Egy hitelesítő (ügyfélazonosítóból és időbélyegből áll), amely az ügyfél/TGS munkamenetkulcson van titkosítva.
  2. A TGS_REQ kézhezvételekor a TGS kivonja belőle a TGT-t, és a TGS titkos kulcs segítségével visszafejti. Ez megadja neki az ügyfél munkamenet-kulcsát, vagyis a TGS-t. Ezzel dekódolja a hitelesítőt. Ezután létrehoz egy kliens/szolgáltatás munkamenet kulcsot, és választ küld (TGS_REP), amely tartalmazza:
    • szolgáltatási jegy (amely tartalmazza az ügyfél-azonosítót, az ügyfél hálózati címét, a KDC időbélyegét, a jegy lejárati idejét és az ügyfél/szolgáltatás munkamenetkulcsát) a szolgáltatás titkos kulcsával titkosítva.
    • Az ügyfél/szolgáltatás munkamenet kulcsa, szolgáltatásazonosítója és a jegy élettartama az Ügyfél/TGS munkamenetkulcson titkosítva.

Ügyfél szolgáltatásigénye:

  1. A TGS_REP kézhezvétele után az ügyfél elegendő információval rendelkezik ahhoz, hogy engedélyezze a szolgáltatást. A kliens csatlakozik hozzá, és üzenetet küld, amely tartalmazza:
    • A korábban kapott titkosított szervizjegy .
    • Új hitelesítő , amely az ügyfél/szolgáltatás munkamenetkulcsával van titkosítva, és tartalmazza az ügyfélazonosítót és az időbélyeget.
  2. A szolgáltatás visszafejti a jegyet a privát kulcsával, és beszerzi a kliens/szolgáltatás munkamenet kulcsát. Az új kulccsal dekódolja a hitelesítőt, és a következő üzenetet küldi a kliensnek annak megerősítésére, hogy készen áll az ügyfél kiszolgálására, és hogy a szerver valóban az, akinek állítja magát:
    • A kliens által megadott időbélyeg + 1 , az ügyfél/szolgáltatás munkamenet kulccsal titkosítva.
  3. Az ügyfél visszafejti a megerősítést a kliens/szolgáltatás munkamenetkulcsával, és ellenőrzi, hogy az időbélyeg valóban megfelelően frissült-e. Ha igen, akkor a kliens megbízhat a szerverben, és elkezdhet kéréseket küldeni a szervernek.
  4. A szerver biztosítja a kliensnek a kért szolgáltatást.

PKINIT

A PKINIT kiterjesztés érintette a kliens előzetes hitelesítési szakaszát, amely után a következőképpen kezdett el jelentkezni:

  1. A felhasználó azonosításra kerül a rendszerben, és bemutatja privát kulcsát.
  2. Az ügyfélgép egy kérést küld a CA-nak (AS_REQ), jelezve, hogy aszimmetrikus titkosítást fognak használni. Ennek a kérésnek az a különbsége, hogy aláírt (a kliens privát kulcsát használja) , és a szabványos információkon túl tartalmazza a felhasználó nyilvános kulcsú tanúsítványát.
  3. A kérelem beérkezésekor a KDC először ellenőrzi a felhasználó tanúsítványának érvényességét, majd a digitális aláírást (a felhasználó nyilvános kulcsát használva) . Ezt követően a KDC ellenőrzi a kérésben elküldött helyi időt (az újrajátszások elleni védelem érdekében) .
  4. A kliens hitelességének ellenőrzése után a KDC választ generál (AS_REP), amelyben a standard verziótól eltérően a munkamenet kulcsa a felhasználó nyilvános kulcsával van titkosítva. Ezenkívül a válasz tartalmazza a KDC-tanúsítványt, és annak privát kulcsával van aláírva (hasonlóan az ügyfél kéréséhez) .
  5. A válasz megérkezésekor a felhasználó ellenőrzi a KDC aláírását, és visszafejti a munkamenetkulcsát (a privát kulcsával) .

A további lépések a Kerberos V5 szabványos leírása szerint történnek.

Hátrányok és korlátok

  • Egyetlen hibapont: Mindig központi szerverre van szükség. Amikor a Kerberos szerver leáll, az új felhasználók nem tudnak bejelentkezni. Ez több Kerberos-kiszolgálóval és tartalék hitelesítési mechanizmusokkal javítható.
  • A Kerberos szigorú időkövetelményeket ír elő, ami azt jelenti, hogy a résztvevők óráit szinkronban kell tartani meghatározott határokon belül. A hitelesítési adatok élettartama megvan, és ha az ügyfél órája nincs szinkronizálva a Kerberos szerver órájával, a hitelesítés sikertelen lesz. Az alapértelmezett konfiguráció megköveteli, hogy az órák között legfeljebb öt perc legyen egymástól. A gyakorlatban a Network Time Protocol démonokat általában az ügyfelek óráinak szinkronizálására használják.
  • Az adminisztrációs protokoll nem szabványos, és az adott szerver megvalósításától függ. A jelszó módosítását az RFC 3244 írja le.
  • Szimmetrikus kriptográfia esetén (a Kerberos szimmetrikus és aszimmetrikus (nyilvános kulcsú) titkosítással is működhet), mivel az összes hitelesítési módszert központilag a kulcselosztó központ (KDC) kezeli, a hitelesítési infrastruktúra ezen tulajdonsága lehetővé teszi, hogy a támadó megszemélyesítse magát. egy felhasználó.
  • Minden gazdagépnév-módosítást igénylő hálózati szolgáltatásnak frissítenie kell a saját Kerberos-kulcskészletét. Ez bonyolítja a megosztott tárhely és a fürtök használatát.
  • A Kerberos megköveteli, hogy a kiszolgáló felhasználói fiókjai, kliensei és szolgáltatásfelhasználói megbízzanak a Kerberos-kiszolgálóban (mindegyiknek ugyanabban a tartományban kell lennie a Kerberos-szal, vagy olyan tartományokban, amelyek bizalmi kapcsolatban állnak egymással). A Kerberos nem használható olyan esetekben, amikor a felhasználók ismeretlen/nem megbízható kliensek szolgáltatásaihoz szeretnének csatlakozni, például a normál interneten.

Sebezhetőségek

A DES-rejtjel használható Kerberos-szal, de már nem internetes szabvány, mert sebezhető. A sebezhetőség azonban számos Kerberos-t használó termékben található, amelyeket nem frissítettek, hogy a DES-t újabb titkosításokra, például AES-re cseréljék.

2014 novemberében a Microsoft kiadott egy javítást (MS14-068), hogy kijavítsa a KDC-kiszolgáló Windows-megvalósításának biztonsági rését. A sérülékenység a közlemény szerint lehetővé tette a felhasználók számára, hogy jogosultságaikat tartományi szintre "emelhessék".

Lásd még

Jegyzetek

  1. ↑ Műszaki terv archiválva : 2016. január 1. az Athena Project Wayback Machine -nél.
  2. ↑ Az E-Bones név története  (elérhetetlen link)
  3. ↑ Hirdetmény a Kerberos 4-es verziójáról . Letöltve: 2011. november 11. Az eredetiből archiválva : 2011. november 3..

Irodalom

  • Schneier B. 3. fejezet Alapvető protokollok. Kerberos Protokoll // Alkalmazott kriptográfia. Protokollok, algoritmusok, forráskód C nyelven = Applied Cryptography. Protokollok, algoritmusok és forráskód in C. - M .: Triumf, 2002. - P. 81. - 816 p. - 3000 példányban.  - ISBN 5-89392-055-4 .
  • Schneier B. 24. fejezet Gyakorlati megvalósítási példák. KERBEROS Protokoll // Alkalmazott kriptográfia. Protokollok, algoritmusok, forráskód C nyelven = Applied Cryptography. Protokollok, algoritmusok és forráskód a C.- M. -ben: Triumf, 2002. - S. 627-633. — 816 p. - 3000 példányban.  - ISBN 5-89392-055-4 .
  • Jason Garman . 1-3 // Kerberos: The Definitive Guide  (neopr.) . - 2003. - ISBN 0-596-00403-6 .
  • Schneier B. 24.5. fejezet Kerberos Bruce Schneier // Alkalmazott kriptográfia. Protokollok, algoritmusok, forráskód C nyelven = Applied Cryptography. Protokollok, algoritmusok és forráskód in C. - M .: Triumph, 2002. - 816 p. - 3000 példányban.  - ISBN 5-89392-055-4 .

Linkek

 Hitelesítési és kulcscsere protokollok
Szimmetrikus algoritmusokkal
Szimmetrikus és
aszimmetrikus algoritmusokkal
Az interneten használt protokollok és szolgáltatások